Re: MiniD 2 - Might as well be done
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.
Re: MiniD 2 - Might as well be done
Jarrett Billingsley jarrett.billings...@gmail.com wrote in message news:mailman.264.1245108702.13405.digitalmars-d-annou...@puremagic.com... I recommend you read the spec and the language tutorial if you're wondering what the language is all about. Where is the language tutorial? = You're drunk, aren't you? = A little. lol. Watch out for the localized glitches in gravity :)
Re: MiniD 2 - Might as well be done
Jarrett Billingsley wrote: 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. How does it compare to stackless python at doing the tasks stackless was designed for and is good at? If not then have you ever considered such design goals? (Disclaimer: I haven't looked into pretty much anything about minid)
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 3:58 AM, Nick Sabalauskya...@a.a wrote: Jarrett Billingsley jarrett.billings...@gmail.com wrote in message news:mailman.264.1245108702.13405.digitalmars-d-annou...@puremagic.com... I recommend you read the spec and the language tutorial if you're wondering what the language is all about. Where is the language tutorial? On the front page, in the section marked language tutorial. ;) http://www.dsource.org/projects/minid#LanguageTutorial Some of the later pages aren't yet complete, but I've got nothing but time. = You're drunk, aren't you? = A little. lol. Watch out for the localized glitches in gravity :) Hehe :)
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 10:31 AM, Robert Clipshamrob...@octarineparrot.com wrote: Jarrett Billingsley wrote: Any questions, just ask, please! Congrats on finally making a release! The only question I have really, is do you plan on making some release binaries/libraries? You mentioned about the tool chain being difficult to use, it might be nice if there were some premade binaries/libraries people could use to play with mdcl/minid. That's a very good idea. :) http://svn.dsource.org/projects/minid/trunk/mdcl.zip It contains binaries for both Windows and Linux (32-bit).
Re: Serialization for D. Comments, please!
BCS wrote: Well, I can switch the default but, in my experience, most of the time repetition doesn't matter. I also dissagree on the relatively useless Oh really? I haven't used a graph data structure in some time. Most of them have been trees. And the cases I can think of, the repeated reference bit has been central the the structure so the chances of getting it wrong (or of missing it under test) are about nil. IMO, most tree-like structures are still full graphs in memory, because they often contain parent pointers, or point back to a parent indirectly (e.g. even if a generic tree data structure is implemented without parent pointers, the data element itself might contain such pointers). OTOH pointers to struct are not value types... Pointers are a whole different thing. A pointer can still point to a value type, because that struct might be embedded within an object (a class member that's a struct). interfaces are not supported either. But supporting interfaces would be very simple. It wouldn't be hard in the current form (you would add a mixin to the interface as well) but the non-mixin, outside in approach would have all sorts of interesting issues like how to get the correct sterilizer function. Huh? You can simple cast the interface to an object. And then cast the object to the serializeable type. You need to be able to do that anyway, because object references can be of the type Object, and there's no way you'd add your serialize mixin to Object. Also, is you writing sterilizer a typo or not?
Re: Serialization for D. Comments, please!
Hello grauzone, BCS wrote: Well, I can switch the default but, in my experience, most of the time repetition doesn't matter. I also dissagree on the relatively useless Oh really? I haven't used a graph data structure in some time. Most of them have been trees. And the cases I can think of, the repeated reference bit has been central the the structure so the chances of getting it wrong (or of missing it under test) are about nil. IMO, most tree-like structures are still full graphs in memory, because they often contain parent pointers, or point back to a parent indirectly (e.g. even if a generic tree data structure is implemented without parent pointers, the data element itself might contain such pointers). I'm referring to data structure that I could add serialization to, e.i. ones where I would know of they have parent references. I still stand by my assertion. OTOH pointers to struct are not value types... Pointers are a whole different thing. A pointer can still point to a value type, because that struct might be embedded within an object (a class member that's a struct). pointers to members won't be supported any time soon. interfaces are not supported either. But supporting interfaces would be very simple. It wouldn't be hard in the current form (you would add a mixin to the interface as well) but the non-mixin, outside in approach would have all sorts of interesting issues like how to get the correct sterilizer function. Huh? You can simple cast the interface to an object. That is not safe. not all interface instances are D objects. And then cast the object to the serializeable type. Cast only works if you know /at compile time/ what type to cast to so I don't think that's going to work. You need to be able to do that anyway, because object references can be of the type Object, and there's no way you'd add your serialize mixin to Object. And that just brought up another issue: how do you serialize a class that only ever shows up as a base class reference? The lib has no way to /find/ the type at compile time so it has no way to generate code to deal with it. Also, is you writing sterilizer a typo or not? typo (is it in the lib or just this thread?) I'd be even worse without a spellchecker :(
Re: Serialization for D. Comments, please!
Huh? You can simple cast the interface to an object. That is not safe. not all interface instances are D objects. There are people who care for COM and C++ interfaces? COM is Windows specific, and C++ vtables are... uh, I don't know, platform/architecture/compiler vendor specific? In any case, serializable objects shouldn't contain references to such interfaces in the first place. And that just brought up another issue: how do you serialize a class that only ever shows up as a base class reference? The lib has no way to /find/ the type at compile time so it has no way to generate code to deal with it. But you already handle this. One of your mixins contains a static this ctor (which, btw., makes it impossible to use serializable types in cyclic dependent modules). It seems right now this ctor is only for registering the demarshaller function, but the same can be done with the marshaller function.
Re: MiniD 2 - Might as well be done
Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) However, guess like anybody else, I just can say: Thanks for this interesting new language. Björn
Re: Serialization for D. Comments, please!
Hello grauzone, Huh? You can simple cast the interface to an object. That is not safe. not all interface instances are D objects. There are people who care for COM and C++ interfaces? COM is Windows specific, and C++ vtables are... uh, I don't know, platform/architecture/compiler vendor specific? In any case, serializable objects shouldn't contain references to such interfaces in the first place. I think there are ways to have a D interface implemented by a non D object. And that just brought up another issue: how do you serialize a class that only ever shows up as a base class reference? The lib has no way to /find/ the type at compile time so it has no way to generate code to deal with it. But you already handle this. One of your mixins contains a static this ctor (which, btw., makes it impossible to use serializable types in cyclic dependent modules). It seems right now this ctor is only for registering the demarshaller function, but the same can be done with the marshaller function. The demarshaller function is indexed via a string derived from the original object. What would the marshaller function key on? The best I can think of right now is the typeinfo and as of now, that's broken under DLLs --- The solution I have now works. Unless someone can show an intractable problem with it I'm keeping it. The only significant issue so far voiced is the concern about what all that mixin is adding and I think I can kill that one with some minor refactoring and documentation. p.s. could you please not delete the citation line from the quote, it makes it easier (at least with good NG clients) for people to find replies to there posts.
Re: MiniD 2 - Might as well be done
On Wed, 17 Jun 2009 00:39:01 +0200, BLS wrote: Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) However, guess like anybody else, I just can say: Thanks for this interesting new language. Björn I agree in regards to both Jarrett having good documentation on MiniD and Jesse Liberty being a good author leading to the conclusion that Jarrett should write a book on D. While I have yet to use MiniD, the language looks very impressive and complete. Good work Jarrett.
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 10:54 PM, Jesse Phillipsjessekphill...@gmail.com wrote: On Wed, 17 Jun 2009 00:39:01 +0200, BLS wrote: Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) However, guess like anybody else, I just can say: Thanks for this interesting new language. Björn I agree in regards to both Jarrett having good documentation on MiniD and Jesse Liberty being a good author leading to the conclusion that Jarrett should write a book on D. While I have yet to use MiniD, the language looks very impressive and complete. Good work Jarrett. Thanks.
Re: MiniD 2 - Might as well be done
On Wed, Jun 17, 2009 at 1:06 AM, BLSwindev...@hotmail.de wrote: Jarrett Billingsley wrote: On Tue, Jun 16, 2009 at 6:39 PM, BLSwindev...@hotmail.de wrote: Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. It's funny you mention Jesse Liberty's C++ in 21 days. Guess what was the first programming book I ever read? ;) Maybe it influenced me? I would bet on it. NO You are kidding me. Ha! No, I'm serious. :) So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) It'd certainly be an interesting proposition. I also don't know if writing a book on D _now_ is the best idea. If it were based on D1, it might just be obsolete in two or three years. If it were based on D2, well, Andrei has a much better idea of where it's going than I do, and I also doubt Phobos2 has seen the last major changes. But maybe in a bit, when things settle down. I can see a D2-Phobos2 based book next year-ish being much more solid. Well the Cognac can wait and becomes better, not that sure about you... :) However, a promise is a promise. Just marked one with Jarret. (Hint for me ' don't touch) :D However, guess like anybody else, I just can say: Thanks for this interesting new language. Sure! No seriously.
