View mode: basic / threaded / horizontal-split · Log in · Help
March 16, 2012
Re: Dynamic language
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.730.1331851930.4860.digitalmars-d@puremagic.com...
> On Thu, Mar 15, 2012 at 06:15:39PM -0400, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
>> news:mailman.713.1331843912.4860.digitalmars-d@puremagic.com...
>> > On Thu, Mar 15, 2012 at 04:13:42PM -0400, Nick Sabalausky wrote:
>> >> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
>> >> news:mailman.709.1331842273.4860.digitalmars-d@puremagic.com...
> [...]
>> >> > It certainly is, though it does bring up the problem of what to
>> >> > do if the game scripting is editable at runtime. Does that mean
>> >> > we'll need to bundle a D compiler with the game? Doesn't seem
>> >> > practical.
>> >> >
>> >>
>> >> Why not?
>> > [...]
>> >
>> > So your game will have to ship with dmd and optlink bundled?
>> >
>>
>> As long as it's a platform on which dmd runs, and you have permission
>> from Walter, I don't see the problem with that. Sure, it'd be another
>> thing to deal with in the installation/packaging scripts, but it
>> shouldn't be too bad.
>
> Oh, I wasn't worried about the licensing part. It's more about needing
> to ship dmd + druntime sources (and possibly some game-specific .d
> libraries), plus optlink. Which is not horrible, I suppose. But it feels
> a bit like buying a chair from IKEA and getting a toolbox, a full set of
> tools, 5 boxes of nails of different types, a power-drill, an engine
> replacement kit, and a sledgehammer included in the box. :-)
>

And a robot that actually uses all of those to build your chair for you, 
then cleans up, backs off and stays out of your way ;)

>> 'Course, if you *like* dynamic interpreted languages, then yea, just
>> simply using Lua would be easier. Point is though, I don't think I'd
>> say it's impractical with D. At least for desktop/laptop games anyway
>> (platforms dmd doesn't run *on* could still use D for scripting, but
>> just not edited in-game - could still reload in-game if the platform
>> has dynamic lib support, but it'd be compiled off-line...possibly even
>> by the game sending the code to a compile server).
>
> Actually, I like this idea. Don't ship the compiler/linker (which feels
> like overkill), but user-generated scripts will be compiled by an online
> server and sent back to the game as a DLL.
>

To me, sending code off to a server to be compiled sounds like a bigger 
overkill ;) But, nonetheless, I think it could be a reasonable solution for 
targets on which the compiler won't actually run.

Actually, what got me thinking about that is the Corona SDK (for iOS/Android 
development). One, umm...interesting...thing about it is that your code is 
*always* compiled on *their* servers. I felt that would be a major drawback 
for real professinal development: I wouldn't want to have to *rely* on them 
and their servers (and me having a good connection to them) just to compile 
*my* code.

It made me uneasy about privacy and security, too: "Could someone be 
monitoring my coding?" "Could things I didn't expect (or that Corona 
themselves didn't expect - ex, if they got hacked) get inserted into my 
code?". It was clear to me though, that it was intended primarily as a 
license-enforcement measure (Corona is licensed per year): You have to login 
to use it (even for trial users), and it's the *only* way to build a Corona 
SDK application, so if you're not licensed the *only* way to use it would be 
to hack your way in. Ultimately, I thought it was one of a handful of marks 
against Corona. Nonetheless, I thought it was an interesting idea.

> Although that does have potential for abuse... somebody could figure out
> the game/server protocol and use it as a compile-farm for arbitrary D
> code. Or write a "script" that contains a complete D app and use the
> game to compile it "for free" using the game server's resources.
>

Yea, that's true. There are ways of dealing with that, of course, but it's 
one more thing you'd have to deal with.

> It can also be a security concern. Somebody could offer players an
> "awesome script" in DLL form that actually contains arbitrary exploit
> code. Or a "script" that contains D code for an exploit.
>

True, but depending on how things are implemented, trojans can exist on 
dynamic/interpreted plug-ins, too. Yea, the source would likely be 
available, but how many people - even intelligent, professional, 
security-minded professinals - ever read and audit the source of a plug-in 
before trying it out? It'd be too impractical - you'd never get anything 
done!

Also, with the "on server" compiling, you could (at least in theory) do 
special checks for certain types of game exploits, security exploits, etc. 
(Although, you could do that with a customized bundled compiler, too, but 
it'd be harder to enforce.)

>
>> And all that would only matter for user-generated content. Any
>> built-in scripts would naturally just already come pre-built. Hell,
>> they could even come statically-linked if you wanted - develop them
>> using the dynamic editing tools, and then statically link when you're
>> ready to ship.
>
> I like this.
>

Yea, me too, actually. :)  I'd love to give it a shot sometime. I just love 
the idea of getting what are admittedly very good benefits from the 
dynamic/interpreted world without having to give up the benefits of a static 
natively-compiled systems langauge. I'm a product of the 80's - I want it 
all, and to hell with making tradeoffs! ;)

That's one of the reasons I like D so much in the first place - it's a 
static natively-compiled systems language that actually *realizes* that 
anything dynamic/interpreted can do, static/compiled *can* do equally well, 
if not faster and more robustly (Everyone thinks C/C++/Java when they 
"static", even though *we* know those are poor examples).

>
>> Speaking of such things, I wonder how hard it would be to port dmd to
>> run on another platform? Targeting that platform might be a lot of
>> work, but just making it run on it...it *is* written in C++, probably
>> the second-most common language in the world (just behind straight C),
>> and it's not like it does a bunch direct hardware I/O access, or GUI,
>> or anything like that. So I'd imagine mostly just some occasional OS
>> calls and assembly. Don't know how much of that there is in there.
>
> What's the point of dmd running on some platform but unable to generate
> code for it?

Heh, it probably *wouldn't* be very useful unless maybe you wanted to use 
some supercomputer as a cross-compilation server.

I guess what I really meant was: Suppose you're already using D to write, 
say, a PS3 or Android game, then naturally, at that point, your compiler 
would already be targeting that platform. So to move from *that* position to 
letting users mod the game, in-engine, in D, *without* sending the code off 
to some other computer, you would need two things:

1. Some sort of dynamic-library-like ability on the given platform ('Course, 
this would be needed even for the "server compilation" method). I have no 
idea ATM how realistic this is on those platforms, though.

2. Port the compiler to actually run on the given target machine.

I'm no expert with the internals of DMD/LDC/GDC, but my suspision is that it 
would be much easier (at least the front-end anyway) than making a D 
compiler *target* a different CPU. The one thing I see that probably would 
give some trouble is the current state of memory-usage during CTFE. (Unless 
that's yet another thing that's been recently fixed without me realizing?)

> Cross-compiling from your Android to your PC? Sounds a bit
> backwards to me. :-) (Though it might be useful if you're travelling and
> working on code on a portable device.)
>

Heh :) In that case, I think I'd rather just ssh into my home system.

Actually, that's more or less how I think a lot of this "cloud computing" 
stuff *should* work. Why trust, and maybe even pay subscription money for, 
internet-accessible space when I *already have* an internet-connected 
computer with tons of storage right at home? And yea, not everyone has their 
own reliable static IP right now, but IPv6 will solve that - and in the 
meantime, I bet a special server could be hacked up to map MAC addresses to 
an appropriate IPv4 routing path. Or something like that.

Of course, that's not to say there aren't very good uses for external 
hosting. I have a Linode account (recently switched from a shared web host) 
and I *love* it. The benefits of that sort of thing are

- You don't have to spend time or money on hardware upgrades/maintenance.

- Your server has a *much* faster/wider better outgoing connection than 
you'd get with Cable/DSL, and without spending over $1k/month for just a 
single T1 line.

- It's always on, even if you get a lot of power outages you don't need to 
get another UPS for it, and you don't have to find somewhere to keep it, 
have it heating up your house, bloating your electric bill, keep 
pets/kids/clumbsy-guests away from it, worry about transitioning if you 
move, if something happens to your house the server is still safe, etc.

All that stuff is important if, like me, you're running some websites and 
your own email server.

But if you just want to be able to access your data/settings remotely, or 
share some files, what do you need a webhost, or Flickr, or Twitface, or 
iCloud for? (And for that matter, Twitface should be a protocol like torrent 
or Jabber, not a company and a private centralized service) The stuff's 
already on your computer or other device. Your computer or whatever is 
already connected to the internet. Boom, right there you should be done. 
What's with all the middlemen worming their way in?

>
> [...]
>> > "The number you have dialed is imaginary. Please rotate your phone
>> > 90 degrees and try again."
>>
>> I love this one :)
>
> A related one: Life is complex. It consists of real and imaginary parts.
>

Heh :) Geek humour is awesome. That's part of why I like Futurama so much:

Bender (recalling a nightmare): Ones and zeroes everywhere! And I think I 
saw a two!
Fry: Don't worry, Bender. There's no such thing as two.

(Or something like that)
March 16, 2012
Re: Dynamic language
"James Miller" <james@aatch.net> wrote in message 
news:mailman.733.1331853568.4860.digitalmars-d@puremagic.com...
>
> I hate the fact that Flash games are created the way they are. For
> one, it's impenetrable to try and learn properly, I had so much
> trouble figuring out how to do things properly, you can attach scripts
> to almost any object, but sometimes it might be shared over all of the
> same objects, and other times only on that instance, depending on how
> you've placed them on the canvas.
>
> I probably wrote some terrible code when I started making Flash games,
> and now Actionscript is so foreign to me that i can barely understand
> where to start.
>

Yea, Flash is just plain insane from start to finish. Even the 
vector/scene-editing GUI is awful. Christ, this is the company that's known 
for Illustrator: That's the one part of Flash they *should* have been able 
to get right! (I dunno, maybe the Flash IDE was just drowning in too much 
MacroMedia legacy?)

One thing I learned though, is that if you're going to make something in 
Flash, your best bet is to use as *little* of what Adobe provides as 
possible:

- Cover any APIs that suck with wrappers that paper over the suck (to the 
extent possible).

- Don't use Flash's "frames" system: Just put your whole program in one 
"frame", and handle scenes manually by toggling the "_visible" attribute on 
entire groups of MovieClips. Do animation/tweening by using the timer APIs, 
a simple "lerp" formula[1], etc, stuff like that.

- *Every* piece of ActionScript code embedded into your .fla should be *one* 
line: #include "realCodeHere.hx"; Store the real code in that *REAL* text 
file, under proper version control, and edit in a *real* text/code editor. 
Hell, even if nothing else, at least this make it possible to fucking *diff 
the files*! (*grumble*Adobe doesn't understand software 
developement*grumble*)

- Abandon ActionScript entirely. Use Haxe instead, and use swfmill to embed 
assets. Now you don't need to have the Flash IDE even *installed*. Hooray!

Every single one of those changes made an order of magnitude improvement for 
me. Even with the overhead of actually making the switches, it was well 
worth it: the initial overheads easily paid for themselves in both tangible 
and intangible ways.

[1] A lerp function in Haxe, copied directly from my own production code 
(consider it "Do what the fuck you want" license), formula derived by just 
remembering basic high school algebra:

class Util
{
[...]
   // Convert a value between two scales, using a linear interpolation.
   // To use as a traditional lerp: Util.lerp(normalizedValue, 0, 1, min, 
max)
   // To convert from farenhight to celcius: Util.lerp(degreesF, 32, 212, 
0, 100)
   public static function lerp(fromVal:Float,
          fromA:Float, fromB:Float,
          toA:Float, toB:Float):Float
   {
       return toA + (fromVal - fromA) * ((toB-toA) / (fromB-fromA));
   }

[...]
}
March 16, 2012
Re: Dynamic language
"Derek Parnell" <ddparnell@bigpond.com> wrote in message 
news:op.wa8hg1dimqne79@derrick-pc.spareco.local...
>
> For a programmable language, you might want to look at Forth. I use it as 
> an embedded scripting language in a couple of my programs.
>

Forth is one of those rare ones that seems to be both a real language and a 
joke langauge at the same time :) I don't know whether to love it or hate 
it!
March 16, 2012
Re: Dynamic language
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message 
news:bighgnfjujyisywpceqt@forum.dlang.org...
>
> import std.variant;
> struct Extendable {
>     Variant[string] properties;
>     Variant opDispatch(string name)() {
>        return properties[name];
>     }
>     Variant opDispatch(string name, T)(T t) {
>        properties[name] = t;
>        return properties[name];
>     }
> }
>
> void main() {
>     auto a = Extendable();
>     a.sweet = 10;
>     a.cool = { a.sweet = a.sweet + 1; } // could probably fix ++ too..
>     // fails with std.variant but the language *could* do it
>     a.cool(); // exercise for the reader: maek this work! Gotta add 
> opCall.
> }
>

I'm compelled to make a slight tweak to that:

import std.variant;
struct Extendable
{
   Variant[string] properties;
   Variant opDispatch(string name)() {
      return properties[name];
   }
   Variant opDispatch(string name, T)(T t) {
      properties[name] = t;
      return properties[name];
   }

   // Tweak Start
   void crystal()
   {
       this.wild = true;
       this.sweet = true;
       this.cool = true;
   }
   // Tweak End
}
March 16, 2012
Re: Dynamic language
On Thursday, 15 March 2012 at 22:51:57 UTC, H. S. Teoh wrote:

> It can also be a security concern. Somebody could offer players 
> an
> "awesome script" in DLL form that actually contains arbitrary 
> exploit
> code. Or a "script" that contains D code for an exploit.

If you are compiling at runtime you can expose only certain 
header files and with d annotations like "safe" and many others 
you can also disable low level access.
March 16, 2012
Re: Dynamic language
On Thursday, 15 March 2012 at 22:37:12 UTC, Manu wrote:

> Do you expect users to be modifying the scripts in the retail 
> release?
> Surely scripting is still for what it has always been for, rapid
> iteration/prototyping during development.

You need to be able to do both.

> You only need the compiler as a part of the games 
> asset-pipeline.

That is the biggest and (only :) ) blocker.
March 16, 2012
Re: Dynamic language
That is the reason why managed environments with JIT are so popular,
you get the best of both worlds.

"Andrei Alexandrescu"  wrote in message 
news:jjtiu8$1ucs$1@digitalmars.com...

On 3/15/12 3:12 PM, Nick Sabalausky wrote:
> Anything an interpreter can do, a compiler can do. And dynamic typing
> doesn't have anything to do with interpreted vs compiled anyway.

Generating and running code during runtime is often easier in
interpreted environments.

Andrei
March 16, 2012
Re: Dynamic language
To be fair Python is not alone, all the ML languages (Ocaml, Haskell, F#, 
...) also work that way.

F# was even funnier. While the language was experimental the default mode 
was still like most
languages, and a "#light" mode was available, similar to what ML-like 
languages have.

Due to the amount of feedback received, by the time F# was an official MSVC 
language, the indentation
based "#light" mode was the default.

--
Paulo

"H. S. Teoh"  wrote in message 
news:mailman.712.1331843803.4860.digitalmars-d@puremagic.com...

On Thu, Mar 15, 2012 at 03:24:24PM -0400, Nick Sabalausky wrote:
[...]
> - If you can stomach the indent-scoping, Python is very well-regarded
> and has a lot of fancy advanced features.

I used to despise Python's indent-scoping too, though since then I've
had some opportunity to use Python for build scripts (google for SCons),
and I have to say that it certainly has its own kind of beauty to it.
You never have to worry about closing blocks in if statements and the
like, for example, and you never have subtle bugs like:

auto func(bool x) {
int y=0;
if (x)
y = 1;
writeln("x is true");

return y;
}

But I certainly sympathize with the WAT sentiment when one first learns
that Python has indent scoping. :-)

(...) cutted
March 16, 2012
Re: Dynamic language
On Friday, 16 March 2012 at 07:48:19 UTC, so wrote:
> On Thursday, 15 March 2012 at 22:37:12 UTC, Manu wrote:
>
>> Do you expect users to be modifying the scripts in the retail 
>> release?
>> Surely scripting is still for what it has always been for, 
>> rapid
>> iteration/prototyping during development.
>
> You need to be able to do both.

There are other (arguably better) ways to do post-release game 
mods.


>> You only need the compiler as a part of the games 
>> asset-pipeline.
>
> That is the biggest and (only :) ) blocker.

There's no way around it really. Virtual Machines are technically 
compilers, to one degree or another. I'd argue that unless the 
entire engine is written in a interpreted/JITed language, having 
a compiler *only* as part of the development stage would be best 
for memory, performance, and file size. Just design the engine in 
a modularized way and publish libraries (plus tutorials) for a 
Mod community.
March 16, 2012
Re: Dynamic language
Adam D. Ruppe wrote:
> import std.variant;
> struct Extendable {
>     Variant[string] properties;
>     Variant opDispatch(string name)() {
>        return properties[name];
>     }
>     Variant opDispatch(string name, T)(T t) {
>        properties[name] = t;
>        return properties[name];
>     }
> }
>
> void main() {
>     auto a = Extendable();
>     a.sweet = 10;
>     a.cool = { a.sweet = a.sweet + 1; } // could probably fix 
> ++ too..
>     // fails with std.variant but the language *could* do it
>     a.cool(); // exercise for the reader: maek this work! Gotta 
> add opCall.
> }

Alright I give up dammit! How do you use opCall() to make 
a.cool() work?
1 2 3 4 5 6
Top | Discussion index | About this forum | D home