El 14/04/11 04:21, Darren New escribió:
> On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
>> Any recommendations? (or perhaps I overlooked a way to do it only
>> with POV-Ray?)
>
> Something you can write in a portable scripting language that you can
>  wrap up as a stand-alone executable for various common platforms is
>  probably best. I use Tcl for that, personally.

   Perhaps I didn't emphasize it enough, but I really hoped not to have
to distribute an executable... the script is very simplistic right now:
it just defines some configuration variables at the top, and uses them
to read a POV-Ray include file, extract objects and material names, and
write some resulting files.

   So, at the moment, the "user" needs to edit the script before using it
on his own scenes. The ideal situation would be to write this tool with
POV-Ray SDL, so I could be sure any POV-Ray user will have the means to
use it, but I think this is not possible.

   Being that lazy, I didn't want to implement proper command-line
arguments or input dialogs, as the whole thing it's just a "proof of
concept" demo. But I would like others to test it, so I guess I will
have to...


-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> >> Any recommendations? (or perhaps I overlooked a way to do it only
> >> with POV-Ray?)
> >
> > Something you can write in a portable scripting language that you can
> >  wrap up as a stand-alone executable for various common platforms is
> >  probably best. I use Tcl for that, personally.

>    Perhaps I didn't emphasize it enough, but I really hoped not to have
> to distribute an executable... the script is very simplistic right now:
> it just defines some configuration variables at the top, and uses them
> to read a POV-Ray include file, extract objects and material names, and
> write some resulting files.

  Perhaps you could write several versions of the script for the scripting
languages that are most "native" to each of the three major operating
systems. IIRC there's some scripting language that Windows supports
out-of-the-box, and on the linux side you have plenty to choose from
(one to consider, if possible, is using shell scripting, if its features
are enough, as that's the most ubiquitous in unix/linux). On the Mac you
could look at AppleScript, which is supported natively (or if the shell
scripting works, it should work there as well, although Mac users are not
very accustomed to using the command line).

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > > On 4/13/2011 15:38, Jaime Vives Piqueres wrote:
> > >> Any recommendations? (or perhaps I overlooked a way to do it only
> > >> with POV-Ray?)
> > >
> > > Something you can write in a portable scripting language that you can
> > >  wrap up as a stand-alone executable for various common platforms is
> > >  probably best. I use Tcl for that, personally.
>
> >    Perhaps I didn't emphasize it enough, but I really hoped not to have
> > to distribute an executable... the script is very simplistic right now:
> > it just defines some configuration variables at the top, and uses them
> > to read a POV-Ray include file, extract objects and material names, and
> > write some resulting files.
>
>   Perhaps you could write several versions of the script for the scripting
> languages that are most "native" to each of the three major operating
> systems. IIRC there's some scripting language that Windows supports
> out-of-the-box, and on the linux side you have plenty to choose from
> (one to consider, if possible, is using shell scripting, if its features
> are enough, as that's the most ubiquitous in unix/linux). On the Mac you
> could look at AppleScript, which is supported natively (or if the shell
> scripting works, it should work there as well, although Mac users are not
> very accustomed to using the command line).
>
> --
>                                                           - Warp

I fail to see the advantage of going bonkers providing multiple versions of the
same script to support multiple "native" scrpting environments when there are
multiple far better offerings than the native stuff that are both a fast and
free download and also multiplatform.

Jaime, being able to wrap your script in an executable together with the
interpreter is a bonus.  Tcl is just like any other scripting language and you
can just distribute the script and a link to where to obtain the interpreter.

I prefer python as a language, but Tcl is a good choice too.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> I fail to see the advantage of going bonkers providing multiple versions of the
> same script to support multiple "native" scrpting environments when there are
> multiple far better offerings than the native stuff that are both a fast and
> free download and also multiplatform.

  You fail to see the advantage? How about you take the script and just
run it, without having to figure out what else you need to download and
install before you can run it. The less steps one needs to run the script,
the better.

-- 
                                                          - Warp

Post a reply to this message

Am 14.04.2011 00:38, schrieb Jaime Vives Piqueres:

> At last, after some 8 months, I'm nearly finished with my
> lightmap-baking demo/tutorial. The technique I developed works great
> within the limitations of lightmapping, but I've a problem deciding
> which scripting language to use for a little external tool that is
> necessary to write some files.

Any popular general-purpose scripting language will probably do: I guess 
Perl, Python and Ruby all come with interpreters for most any platform 
you might name.

I know none of these, so like Darren I'd personally go for Tcl; as 
already mentioned, you don't need to use Tk (the most popular GUI 
toolkit for Tcl), but I find it a nice-to-have. I know of free 
interpreters for both Linux and Windows, and I guess there's something 
for the Mac available as well.

One thing that should be noted is that not all people accept all 
scripting languages equally well, and some may refuse to install 
interpreters for whatever language you choose. I, for instance, would 
hesitate to install a PHP interpreter on my machine, but would be ok 
with Perl, Python or Ruby (and, as you probably guess, have Tcl 
installed already); I must confess this is an only marginally 
rationalized preference, but I may not be alone with such a preference.

Interestingly enough, I don't recall ever hearing anyone take a 
categoric stance against Tcl, so it might raise the fewest resentments.

That said, when it comes to writing platform-independent scripts with 
the intention to distribute them, I think the most commonly used 
language for such a purpose might be Perl.

In case you should decide to split up the script into a kind of config 
file and the actual code, Java would probably be the way to go.

Post a reply to this message

On 4/14/2011 6:56, Warp wrote:
> nemesis<nam### [at] gmailcom>  wrote:
>> I fail to see the advantage of going bonkers providing multiple versions of the
>> same script to support multiple "native" scrpting environments when there are
>> multiple far better offerings than the native stuff that are both a fast and
>> free download and also multiplatform.
>
>    You fail to see the advantage? How about you take the script and just
> run it, without having to figure out what else you need to download and
> install before you can run it. The less steps one needs to run the script,
> the better.

Well, as nemesis says, my intention was to suggest a simple cross-platform 
scripting language (like Tcl or Python) for the script, *plus* do the 
up-front work of wrapping it in a native no-install executable for each of 
the major platforms if you care to promote usage. Distribute both the short 
script and the "use this if you don't want to install the scripting 
environment" version.

My MakeDF3 code[*] is like that.  It's a Tcl script that I run through 
freewrap, so you have MakeDF3.tcl if you want to edit it or you already have 
Tcl installed, or MakeDF3.exe if you're on Windows and you just want to use 
the tool and don't mind that it takes up another meg of disk space.

If you're just writing files and not using a whole bunch of utility 
libraries, writing it in C and asking someone to compile it for each 
platform for you can also work well. Once you start linking in things like 
Windows or Linux packages, that becomes less feasible.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/14/2011 8:16, clipka wrote:
> I know none of these, so like Darren I'd personally go for Tcl;

I only mentioned Tcl because on Windows at least it's trivial to wrap up the 
Tcl code into a no-install stand-alone .exe.  I don't know how OSX handles 
what Linux calls repositories, but installing the Tcl interpreter on modern 
Linux is pretty straightforward. (Pretty straightforward on Windows once you 
track it down, too, but that's an extra step people might not want to go for 
if they just want to try your code once.)

Does OSX have something like Yum to which people submit that stuff, or is it 
more like Windows where you have to track down where the software is?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Does OSX have something like Yum to which people submit that stuff, or is it 
> more like Windows where you have to track down where the software is?

  AFAIK there's no official repository/package manager, but there's a
third-party system that does exactly that: http://www.macports.org/

  It works in the same way as the command-line versions of linux package
managers.

-- 
                                                          - Warp

Post a reply to this message

On 4/14/2011 9:09, Warp wrote:
>    AFAIK there's no official repository/package manager, but there's a
> third-party system that does exactly that: http://www.macports.org/

Oh, I've heard of that. I've seen books about XYZ that say something about 
getting the XYZ interpreter from macports, for example.

Cool, thanks for the info!

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> I fail to see the advantage of going bonkers providing multiple versions of the
>> same script to support multiple "native" scrpting environments when there are
>> multiple far better offerings than the native stuff that are both a fast and
>> free download and also multiplatform.
> 
>   You fail to see the advantage? How about you take the script and just
> run it, without having to figure out what else you need to download and
> install before you can run it.

how about clicking on a link right next to the script download instead 
of "figuring it out"?

BTW, I wonder when will OS'es finally automatically download and install 
required interpreters based on file type.  You click on a script and if 
there's no interpreter, the OS informs you of the file type and required 
interpreter and if you want it to fetch, install and then execute the 
script.  Security risk?  Not like you don't have to provide an 
administrative password to install things...

I mean, it's not like python and company are completely unfamiliar to 
desktop OSes.  They've been around for so long, how come there's no 
standardized database of known scripting languages and it's file types...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message