> Anthony: I'm not sure to which diagram you are
> referring. Please send me a copy.
> I don't have any file called "NuParser.png" around
> here. And the mail archive search is down.
http://ufp.uqam.ca/opencard/graphics/NuParser.png
> Adrian: I'll send you a copy when I can (I've moved
> again and am just starting to reorganize).
Alain: Don't bother. Use the above URL instead.
> Adrian: Has documentation relating to NuParser
> been uploaded to the UFP server yet?
> Anthony: No. NuParser is not done yet, and has not
> been documented yet. It has
> online help, the incomplete version of which has
> been pasted to the end of this message.
Alain: NuParser has its own background in our
web-stack (CGI). Click on "FC-application" on the
HomeStack page, then click on "interpreter" in the
table of contents.
> Adrian: Okay. I will look carefully at these docs
> in the next few days.
Alain: We will then integrate this new information
into our web stack, in the background I pointed out
above.
> Anthony: NuParser is a parser generator, like bison.
> NuInterpreter is the (presently nonexistant)
> new interpreter generated with NuParser instead
> of Bison. Interpreter is the old snapshot from
> summer(?). The naming confusion will be
> straightened out sometime. Anyone with suggestions
> for better names should mail me.
Alain: Our application and collaboration go by the
name FreeCard. Our scripting language is called
FreeScript. So how about FreeParser ?
> Look in the Interpreter sources... That's the best
> documentation available. Most of it is fairly
> obvious, some is based in HT, and some in PPCAsm
> Adrian: this will need to be improved on
> (I would think).
Alain: Definitely.
> Adrian: Code is generally not suitable docs -
> though it should contain documentation.
Alain: Quite right.
> Adrian: I'll take a look and see what I can come
> up with, this is dependant on me understanding it
> though.
Alain: Please keep me informed. I am now confident
that the documentation of FreeCard will be the first
tangible product of our collaboration. As it should
be, no doubt. The HyperTalk docs that I am currently
finishing off will amount to a detailed specification
of FreeScript 1.x, for example.
> The Interpreter is _not_ a good place to try and
> understand C/C++. The interpreter is the only
> place that when the choice is a 1% speed gain
> vs. 100x more readability, the speed gain is chosen.
> You can see all sorts of evils, such as a single
> string being used a both a C and Pascal string
> in OTVar.h (which, stunningly, is well-documented)
> Adrian: Unfortunately, a great deal of C code is
> written like this.
Alain: I believe that this is unfortunate. We are an
open source collaboration. People will be viewing our
source with the intention of understanding it and
contributing to it. Hence, we should avoid hacks like
the above, or document them profusely, so that we
won't end up with only ONE programmer that can do
anything with our source code.
> I would rather invest more time in learning and
> achieve something useful at the same time than less
> time learning without making useful progress.
Alain: I hear what you are saying, Adrian, but
producing something useful has its own imperatives,
particularly if you have to make it
hyper-user-friendly for those less-experienced folks
and/or you have a lot of content. The time you
dedicate to these production details, you are not
using to test new ideas.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
