Jarrett Billingsley wrote:
> I'm bad at meeting deadlines.  Partly because I mismanage my time, but
> a large part of it is also because being a perfectionist, I never know
> when to _stop working on something_.  After nearly two years in
> development, I think I'm ready to call MiniD 2 "gold."
> 
> http://www.dsource.org/projects/minid
> 
> I write lots of docs.  Please read them.
> 
> = Oh wow, an interpreted version of D! =
> 
> NO!  That was the aim _three years ago_ but by now it's a completely
> different language.  Please read the docs before you form your
> opinions on what it is :)
> 
> = What's changed since MiniD 1? =
> 
> Lots.  It's enough to say that it's practically a different language.
> To be honest, I don't even consider MiniD 1 - either the language or
> the implementation thereof - anything more than a crude, unfinished
> work.  MiniD 2 is what I consider to be the first _actual_
> language/implementation.
> 
> The MiniD 2 reference implementation is far more mature, complete, and
> efficient than its predecessor.  It has been reimplemented pretty much
> from scratch and now features its own heap and GC separate from D's.
> While this does incur a bit of a hit on the terseness of the native
> API, it also manifests itself in a frankly _incredible_ increase in
> performance, as well as features that would have been difficult or
> impossible to implement using the native GC (like weak references and
> class finalizers).
> 
> What kind of performance, you ask?  Well, almost every test I've run
> kicks the crap out of Python, and is more in the ballpark of Lua.  The
> only tests that don't quite measure up are those which are GC-heavy.
> The current implementation uses a simple mark-and-sweep GC, but that
> is one of my main development priorities after this release.  If I can
> reach Lua's performance - awesome!
> 
> The API is much more like Lua's now, though with some nice perks due
> to overloading that aren't possible in a C API.  Writing code for what
> is essentially a stack language is kind of nice, in some ways.  Being
> such a departure from what most people are used to, though, it can
> take some getting used to.
> 
> The API is also much more "there is one way to do it."  The old MiniD
> 1 - and early MiniD 2 - APIs sometimes had several, inconsistent
> methods of acquiring information.  This has been entirely done away
> with.  That being said, D's current protection mechanisms (and DMD's
> forward reference issues) are woefully inadequate for dividing up the
> API the way I want to, forcing almost all of the public API functions
> into a single module.  Sorry for that.
> 
> = I'm bearophile, and I don't think it performs as well as <X>, and
> isn't similar enough to Python. =
> 
> OK.  Give me some benchmarks, and I'll see what's taking so long.  As
> for the language style?  Tough luck ;)  I admit the standard library
> probably doesn't have as many lazy-evaluation functions and datatypes
> as it could, but that can certainly change.  I am open to suggestions!
> 
> = Why do I need it? =
> 
> I don't know!  Maybe you're just interested in learning new languages.
>  Maybe you've got a legitimate need for a scripting language in one of
> the D apps you're writing.  Whatever.  I can't tell you why you need
> it.  Only you know that.
> 
> For a high-level, pseudo-philosophical introduction to the language,
> see http://www.dsource.org/projects/minid/wiki/Introduction2
> 
> I recommend you read the spec and the language tutorial if you're
> wondering what the language is all about.  _Then_ can you tell me what
> you do and don't like.
> 
> = What prerequisites do I need, and how do I install it? =
> 
> D1 with Tango 0.99.8, currently.  That's about it, as far as the core
> language and its standard libraries are concerned.
> 
> Installation instructions are available here:
> http://www.dsource.org/projects/minid/wiki/Installation  I plan on
> putting some more detailed docs up especially w.r.t. feti's sandbox
> script, since I haven't been able to get some configurations to work.
> 
> If you're having trouble installing a D compiler or build tool or
> Tango, I'm sorry, but I just don't have the time or patience to help
> you install the prerequisites.  I have spent far too much time helping
> others install those and it's just.. well, it's not my fault that the
> D toolchain is currently so fractured and hard-to-use, and I've kind
> of lost the will to help anyone else.  Sorry :\
> 
> MiniD works fine with DMD and LDC.  GDC is too old to compile it.  Bug
> David Friedman or Arthur about that.  :|
> 
> = How do I <x>? =
> 
> Please ask me.  Here on the newsgroups is OK, but for more long-term
> conversations, *please* sign up for a dsource account and post your
> questions to the MiniD dsource forum
> (http://www.dsource.org/forums/viewforum.php?f=94).  If you don't have
> a dsource account already, why not? ;)  If you're one of those people
> who refuses to post on one of those "dirty, slow, inefficient" web
> forums, well, I guess you're not getting any help!  Or you could just
> email me, but by doing that, you'll be depriving anyone else from
> seeing your question and the resulting answer.  Your choice.
> 
> I love writing documentation, and if you find any part of it
> inadequate or confusing, *let me know*.  If there is a particular
> style of documentation you respond particularly well to, *let me
> know*.  I'm pretty responsive to communication, so if you've got
> questions, ideas, suggestions, comments, flames - WHATEVER - please
> let me know.
> 
> = You're drunk, aren't you? =
> 
> A little.
> 
> = What else? =
> 
> Nothing!  Really.  Except maybe if you're interested in 3D graphics,
> there _are_ SDL and OpenGL bindings for MiniD already.  <_<
> 
> = I want to help! =
> 
> Then submit a patch!  I have to admit, I'm a bit like Walter in that I
> might not accept your code unless I review it, know you personally to
> be a skilled developer, and/or believe that it is a worthwhile
> addition.  However, "unofficial" patches can be just as useful to
> others as core language features.  Development is fun!  Contribute!
> 
> = What are your plans for the future? =
> 
> Some performance improvements; a better GC would be nice.  Haven't
> done much GC research so I'd like to get into that.  Maybe a JIT
> compiler a little further off.  More addon libraries, definitely!
> 
> That's all.  I don't think I'll have any kind of versioning scheme
> save for the most important revisions.  Other than that, I think I'll
> just base the "versions" off of the SVN revision that they correspond
> to.  It's not like any other D library really has any kind of reliable
> release schedule :P
> 
> Any questions, just ask, please!

I had a kinda quick look at it; didn't dig deep into all the documentation, but I can tell that it's a solid effort and seems to be very well documented.

I might give it a deeper look sometime later, but right now I have too many things going on in my mind,

So I'll just ask a question,

Say, a guy like me, who's not very well experienced in writing useful applications (I mostly write throw-away code or university assignments).

If I want to write a small program and I want to make it "scriptable", then I suppose that I can use MiniD for that, so do the docs explain how I can do that, or do you kinda assume that I already have an experience doing this kind of thing?

On Sat, Jun 20, 2009 at 6:27 AM, hasen<hasan.aljudy@gmail.com> wrote:
>
> Say, a guy like me, who's not very well experienced in writing useful applications (I mostly write throw-away code or university assignments).
>
> If I want to write a small program and I want to make it "scriptable", then I suppose that I can use MiniD for that, so do the docs explain how I can do that, or do you kinda assume that I already have an experience doing this kind of thing?

That's a good point-of-view to ask that question from, and I hadn't considered it.  :)

As a short answer, I'll give you an account of a small experience I had making a little game.  I stubbed out a small engine in D, and wanted to make MiniD a part of it.  So the first thing I did was just use it for a configuration and level data system.  It's very nice to be able to write the data files using a fully-capable language.  A normal configuration file, stored as XML (shudder) or JSON or whatever other data-only format you can think of just seems so pedestrian compared to the flexibility and expressiveness of a programming language.  Need ten boxes in a row?  [Box(x, 0, 0) for x in 0 .. 10]. How about if you want to move all the objects over by 100 units? objects.each(\i, obj -> obj.pos.x += 100).  You'd still be typing the namespace declaration by now if you were using XML.

Then I was messing with physics, and wanted to be able to tweak the various simulation parameters on the fly, rather than changing, recompiling, running, seeing that it's horribly off, quitting, changing, recompiling.. so I bound some MiniD functions to set the physics parameters, added an in-game script console, and then I could just change things within the game until they worked right.  Then I could just write all those settings out to a file - from within the console, of course - and use them in the original program.

The game hasn't gotten much further than that, but already I can see how it's kind of working out.  The scripting seems to kind of work its way into areas of the program where it'd be nice to do runtime customization.  The in-game console alone opens up so many possibilities: setting up testing scenarios by spawning objects and enemies and  jumping to arbitrary levels or positions or events; loading various configuration files in-game to test out which ones I like better; querying all sorts of things about the game and engine on-the-fly (why is performance so bad?  ohh, there are 480,000 particles, I'm never killing them off..); and so on and so forth. It's already saved me a lot of time by eliminating the compile-run-test cycle.

Being a programmer, I tend to think in terms of computation and programmability, and embedding a scripting language in my program lets me interact with it (through a backdoor or as a matter of course) in those terms.  *That* is what I like about it.  :)

On Sat, Jun 20, 2009 at 6:27 AM, hasen<hasan.aljudy@gmail.com> wrote:
>
> Say, a guy like me, who's not very well experienced in writing useful applications (I mostly write throw-away code or university assignments).
>
> If I want to write a small program and I want to make it "scriptable", then I suppose that I can use MiniD for that, so do the docs explain how I can do that, or do you kinda assume that I already have an experience doing this kind of thing?

After I wrote the last post, I realized there are two possible
interpretations of your question.  Either you want to know in what
areas of your program it'd be possible to add scriptability - which I
already answered - or you were looking for a more practical answer.
Practically speaking, it's pretty simple.  Setting up objects in the
scripting language's namespaces is easy enough, and though it might
look a bit odd ("pushInt(t, 1); newGlobal(t, "numPlayers");"), it's
very simple and repetitive, meaning it can be abstracted and
automated.  Calling script code is equally simple: instead of doing a
normal function call, you just use a couple API functions to get the
function you want to call, call it, and get any return values (if
any).  Again, this can be abstracted out into higher-level mechanisms.
 minid.bind - horrible thing that it is[1] - tries to do some of that
for you, automatically wrapping functions, classes, and structs the
best it can so that D and MiniD code can interact with each other
almost seamlessly.  There are other options, like team0xf's xpose,
which now has support for MiniD as far as I remember.

If you'd like the docs to have some examples on common native-script interaction tasks.. well, yeah, they probably should anyway ;)

[1]I say "horrible thing that it is" because it's a tedious mess of horrible string mixins, templates, .stringof parsing hacks, and the like.  It is an expression of everything that is wrong or inadequate with D1's (and D's, in general) metaprogramming abilities.  Using it also has the potential to kill OPTLINK, since it causes lots of template instantiations in one spot.  I can only imagine how much simpler - and as a consequence, more robust - the library would be even if I had nothing more than __ident.