Ok, I will keep this in mind.
I would like to point out this(part of the project description):
"See Panotools::Script for a perl approach to this. Note that the PanoTools
script format is is a bit hard to understand, there is a proposal in the
SoC2007 project Panotools Architecture to replace it with a more workable
XML file format, so work should concentrate on the workflow aspects instead
of another panotools script parser."
...according to this, arguing whether to use perl or python is unnneccessary
at this moment. I was thinking designing PTButcher in such way that it can
be easily extendable with any scripting language, because The PTButcher core
should be, however, based on c++ and as a part of hugin(or even loaded as a
module or extensions). The scripting language support should only provide
functionalities needed to implement some features.
From: dmg@... [mailto:dmg@...]
Sent: Friday, March 23, 2007 11:18 PM
To: Zoran Mesec
Subject: Re: [PanoTools-devel] [SoC] PTButcher
Keep in mind. We need tools that we can maintain. I don't know how
many of us know Ruby or Python. Bruno has been maintaining perl for
some time, so there is already precedent in the use of that languae. A
proposal to use a different language will have to be approved first. I
believe (and others can add their opinions) we do not want a system
that we can't maintain in the future, now matter how great it might
be. BTW, Perl can interface with C and C++.
Zoran> I agree with Pablo, some parts of PTButcher should be written in a
Zoran> scripting language. I have not digged into the code yet, so, I can
Zoran> say much more, however I believe python is better because we can use
Zoran> swig to call some existing c functions(I am not sure whether there a
Zoran> similar bridge between Ruby and c++).
Zoran> Yes, I would like to take part in this project. I intend to use and
Zoran> develop hugin/panotools also after we finish SoC.
Zoran> Zoran Mesec
Zoran> On 23/03/07, Daniel M. German <dmg@...> wrote:
>> yuval levy twisted the bytes to say:
yuval> --- Zoran Mesec <zoran.mesec@...> wrote:
>> >> I understand now the purpose of this
>> >> project - e.q. to search for pto files, read them
>> >> and then use the existing tools, according to the
>> >> data in the project files.
>> >> Ok, that should not be a problem.
yuval> excellent! do you want to take this project and run
yuval> with it? as Pablo stated, it will probably be better
yuval> done in a scripting language. Something like Ruby or
>> >> You should also think of having the project file
>> >> written in XML
yuval> good idea. you could make it part of your project. And
yuval> if you do, don't remember the daunting thing called
yuval> "legacy support". there are plenty of older project
yuval> files out there, in the original format. A converter
yuval> will be highly appreciated.
>> I think designing an XML format, and implementing an API to access it
>> from C/C++ would be great. This would be in line replacing the parser
>> in panotools.
>> Daniel M. German "One thing I have learned in a long
>> that all our science, measured against
>> reality, is primivite and childlike
>> --and yet it is the most precious thing
>> Albert Einstein -> we have. "
>> dmg (at) uvic (dot) ca
>> replace (at) with @ and (dot) with .
Zoran> Take Surveys. Earn Cash. Influence the Future of IT
Zoran> Join SourceForge.net's Techsay panel and you'll get the chance to
Zoran> opinions on IT & business topics through brief surveys-and earn cash
Zoran> PanoTools-devel mailing list
Daniel M. German "All the fun of sitting still, being
Principal Skinner (Simpsons) -> writing down numbers, yes science has it
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .