Rudy typed : 
> Sorry! No offense intended! I really thought so, but I must have had another
> program in mind. I thought I remembered your program needed the VB runtimes.
> Must have been one of the other utilities I recently downloaded. And now you
> mention it, I remember the RXLib type of spin buttons (the diagonal ones).
hehe, glad you noticed, they are far easier to hit with the cursor, as
well as taht they handle percision a bit better.

> To the innocent bystander I *must* explain, that telling someone who is a
> Delphi freak, that he is using VB is one of the worst accustions a person
> can make <g> (like telling Kenneth Starr voted for Bill Clinton last
> election).
Actully, I tried VB 3 on my old 3.1 system, before delphi time, and
found taht it really sucked... (Have the install disks here somewhere,
no deletium container yet)
 
> >Yes, it is. That's why I made the prog. the allocation takes around 4-8
> >seconds, depending on the size of the tree.
> 
> Hmmm. I must definitely have a look at the parser and allocation code one
> day. It's said to be plain ANSI C, so I think I can read it well enough.
hehe, as I said, I don't have a compiler... :-)
 
> What would interest me, if there are big differences in parsing/rendering
> ratio on various systems, and using different compilers on the same system.
> E.g. are the different patches for Win32 almost equally efficient, or is one
> more efficient in parsing and the other more in rendering? I think Ron
> should be able to answer part of that. I think he uses VC6, while the
> official build is done in Watcom C. Perhaps someone should try BCB and BC
> too. (Sorry guys, don't know the other platforms well enough).
I doubt it is much difference, since a optimization in the compiling
wouldn't be noticeable that very much in the parser... But, I can't
answer this either.. (Anyone here can ?)
 
> >> Perhaps there would be demand for a small program, which unravels #while
> >> loops and macros and creates (huge) include files out of them, taking a
> bit
> >> out of the parsing POV-Ray does. This could work like WinTree, but
> perhaps a
> >> bit more generalized.
> 
> [...]
> 
> >yes, this might be helpful, but perhaps not good enough. This is a thing
> >too look deper into.
> 
> I think Ron Parker had some very good suggestions on this.
Perhaps..
I came to think of it like this :

on every #macro it finds, it places the macro in macroname.par file, and
the parsed call is #included at the parse storage, and the next time, it
is compared, byte/byte to the macro with the same name8and the call) and
if there is a change, it reparses, if there isn't one, it simply
includes the old parsed info.

just an idea on the solving..

//Spider

Post a reply to this message