Sylvain Beucler wrote:
> I have seen that there is now an improved DinkC parser. I have several
> comments on it.
> First, I am unsure whether is it the best way to improve Dink
> scripting. From what I have understood (I cannot find any of its
> source in the latest co), it seems it is a code based on the current
> DinkC parser, by hand, and with about everything from scratch. Feel
> free to contradict me.
Well, that's because the code has not been added to the CVS Repository.
:-) And, to answer your question, some of the source was "borrowed"
from GNU's GCC compiler.
> Creating a good programming language is quite difficult and lots of
> mistakes can be done when specifying it, above all when you try to
> keep it compatible with such a strange language as DinkC.
Right....unless you improve upon what's already there.
> Creating a parser is also a difficult task, and people use high-level
> tools such as Flex&Bison or AntLR, allowing the programmer to specify
> regular expressions to find lexems, a grammar for the syntax of the
> language, and a set a C (and Java for AntLR) code for the semantic
> part. Besides, those tools make the code a lot more maintainable and
> secure. I think the current parser is made by modifying the current
> ugly and slow parsing code from Seth, which IMHO is reproducing the
> same mistakes from the past.
And, what was the point of that whole paragraph? :-P
> Since there is ASM related functions, I'd also say a new assembly
> language is not easy, above all when it is supposed to be portable,
> and especially when you have already available an documented virtual
> machines such as Z (Inform) or the Java Virtual Machine.
So? Be happy you're not the one writing it. :-)
> It seemed better and simplier to me to keep the DinkC language as is -
> and compatible - or to remake it 'from scratch' or from existing C
> grammars using these high-level tools, possibly breaking compatibility
> with badly written DMods that work only thanks to (because of) DinkC's
> lack of strict syntax.
Right. We picked the second one, with the compatibility. Heh.
> Of course, improving scripting is a need that the Dink projet has to
> fulfil. The solution I saw was to use one of several of the robust,
> well-know scripting language that already exist, binding it with the
> internal Dink methods already provided by DinkC, and possibly some
> others. I think of Guile, which is designed for that task, or Perl, or
> widely-available scripting language. This would also keep up from
> maintaining a new scripting language. Maintaining an interpreter is an
> interesting task, but giving the DMods authors a stable, powerful,
> simple and flexible tool is IMHO far more than we can currently do,
> asides from the fact we still have more urgent tasks to complete right
> now like a fully-compatible portable Dink engine, so I suggest such a
> programming experience be done on another project.
1) Who's "we"?
2) Why should TDP require people to have another package. We're already
using uncommon packages (SDL_ttf).
3) Once the interpreter is made, it won't require much upkeep unless
more commands need to be added.
4) We are (re)making a fully-compatible portable Dink engine. Why
should we not make it better also?
5) Are you suggesting that the [new] DinkC interpreter code has been wasted?
> Feel free to post your thoughs on it.
> The other comments is on CVS use. CVS perfectly fits in the Open
> Source development model, which is well described in Eric Raymond's
> "The Cathedral and the Bazaar" article (available at his website:
> http://catb.org/~esr/writings/cathedral-bazaar/). CVS gives all the
> developper access to an up-to-date and rapidly changing base of source
> code, possibly broken or non-fully usable, on which everyone
> contribute without messing up each others changes, with a complete
> history of each source file. Source code is usually controlled by a
> maintainer and/or a core a active developpers, checking and merging
> episodical contributions and putting development in the right way.
> Some advanced features also permits to "tag "stable (often 'Exp')
> bases so that users can checkout usable versions, and branching, to
> make experimental releases that can be merged with the main one
> eventually. Key points are world-wide access, versions control,
> up-to-date, centralized and collaborative work.
> Unfortunately, we got the bad habit of working 'privately' until we
> feel the work is well-done, which is the opposite of CVS philosophy,
> since it multiplies the risk of parallel efforts on same code
> portions, prevent easy collaborative work, and communications between
> staff. That behavior prevented me, among others, to see the possible
> development of changes on DinkC parser, that could have been put in a
> separate branch in the CVS available for all developper comments and
> maybe changes.
Well, I don't know about his philosophy, but this is the way we're
currently doing it. If you feel comfortable enough screwing with the
Repository, go right ahead. :-), 'cause I sure don't.
> Communication is even less easy when there is no strictly up-to-date
> ChangeLog. Another kind of ChangeLog is the IRC channel, and that's
> why I tried to keep an eye on it using a logger - but it is seems even
> that is not enough since some important discussion always happen
> privately between developpers, by e-mail or by IM. The logs are
> interesting though (and can still be publicly accessed at
> www-mips.unice.fr/~beuclers/logs if anyone need them). Of course
> presence is better than logging, and I'll fix that problem within one
> week as soon as I get some permanent connexion, since most common
> discussions happen at night here, when my university is closed :)
> Anyway chat may not be the perfect way to share ideas between staff
> members, and this mailing-list could help.
Well, I actually thought about this problem about 2 days before I
received this e-mail message. I will most likely be creating a dink-cvs
mailing list (or similar) for people to announce CVS changes and/or
communicate any discrepancies that may result from our current setup.
> So use the CVS as a central base for all your source code, share your
> work, list your changes and communicate with all the staff; our work
> can only be better.
Actually, I think it can be much worse. We just need to hire Seth.
Just think about that. :-)