KPovModeler Tutorial

[Hugo Ferreira]

Luis,

Thanks for the feedback. You have given me valid arguments against Bison/Flex 
(yes, I was thinking of those tools specifically). In fact the Object 
orientated argument had already presented itself but I did not give it much 
importance becuase I found an application to be used specifically with Bison 
when trying to generate C++ (bisonpp). 

On more argument againts Flex/Bison: I have seen another person's attempt to 
use these tools to parse povray files. His complaint was that there ir no 
formal specification of the grammer and that parsing such a file using these 
tools becomes very difficult. 

Anyway, it was just a question. I will first try and work on the object data 
structure and its viewing and then it's export and finally import. 

Regards,
Hugo.

P.S.: I am now living in the "backlands" where I only have access to analog 
telephony trunks, in other words no ADSL for me. Oh brother ! 8-(


On Monday 14 Jul 2003 6:52 pm, CARVALHO Luis Passos wrote:
> > -----Original Message-----
> > From: Hugo Ferreira [mailto:hmf at inescporto.pt]
> > Sent: segunda-feira, 14 de Julho de 2003 9:04
> > To: kpovmodeler-devel at mail.kde.org
> > Subject: Re: KPovModeler Tutorial
> >
> >
> > Hi,
> >
> > Sorry for only replying now. I have no connection at home.
> > (Gave up on cable modem, service was really bad).
>
> Try ADSL. I live in Barcelos and never had any complaints.
> At least for my uses 2Gb/month are more than enough.
>
> > Kwrite, Kate, (maybe KEdit ) and Kdevelop have code folding.
> > I tried Gideon
> > and this seems to work ok.
>
> Yes, I know. However, I keep doing esc+i to edit. What can I say.
> You can't teach an old horse new tricks. :)
>
> > Unfortunatelly I don't have much time. Basically I just
> > wanted to support the
> > polygons. I can go on giving some of my time, but I cannot give u any
> > guarantees. 8-(
> >
> > I will be looking at the tutorial and asking some questions,
> > of course ;-).
> > Andreas, thanks for the info. Any way I could add comments to
> > the code to
> > reflect this information?
>
> More comments are always A Good Thing(tm). :)
>
> The most simple objects to implement are those that don't require 3d.
> We'll, at least for me as I don't really understand openGL. For now,
> I'll study it eventually.
>
> > I would like to ask a related question. I had a look at the
> > parser and see
> > that it is a major part of the work. I have also realized
> > that parsing and
> > supporting all the PovRay objects is a constant battle for
> > any application
> > that interfaces with povray. So may question is, have any of
> > you considred
> > using automatic parser generators to do this work? If not,
> > why? Please note:
> > this is not a suggestion to change Kpovmodeler. I am merely
> > interested in the
> > reasons for your decisions.
>
> I assume you're talking about bison and flex.
>
> Hmmm, although I didn't actually make the decision here are a few ideas:
> 	* Reverse engineering from povray -> povray doesn't use bison/flex
> 	* Less compile time precedences -> kdegraphics didn't require
> bison/flex
> 	* Object oriented parsers -> as far as I know, from my limited
> experience
> with it at university bison/flex are not object oriented. How well do they
> fit in
> this methodology I do not know.
>
> In fact, if you look at the code there is not much to change when the
> parsing changes.
> 	* PMScanner -> Token parser. Does flex's job, even if only for
> povray.
> Maybe it could be generalized to contain different token dictionaries.
> 	* PMPovrayParser -> using a PMScanner instance to feed it with
> tokens, implements
> the parsing rules for povray.
>
> When I had to develop a new object, I had only to add one or two missing
> tokens to
> PMScanner and develop a new method in PMPovrayParser, eventually using
> other methods as
> components for the new parse. Anyway, most of the code is not for the
> parsing itself but
> more for the construction of the object tree.
>
> New plugins for different grammars may be interesting to develop using
> parser generators.
>
> However, really cool would be to have a user configurable grammar parser to
> avoid compile-time
> dependencies. If you know of such a parser (that is fast), I'm sure we
> could have advantages
> in adopting it. :)
>
> Cheers,
> Luis
>
> List archive and information:
> http://mail.kde.org/mailman/listinfo/kpovmodeler-devel