Compiling Scilab scripts
johnb
does anyone know how to compile a scilab script into an executable
file to speed up processing time?
Many thanks,
John
Matthias Zenker
johnb wrote:
> does anyone know how to compile a scilab script into an executable
> file to speed up processing time?
AFAIK there is no such thing. There is a request filed in 2006 (#308,
http://requestzilla.scilab.org/show_bug.cgi?id=308), yet unaddressed.
MATLAB has it since a long time...
Matthias
Sylvestre Ledru
> johnb wrote:
>> does anyone know how to compile a scilab script into an executable file
>> to speed up processing time?
>
> AFAIK there is no such thing. There is a request filed in 2006 (#308,
> http://requestzilla.scilab.org/show_bug.cgi?id=308), yet unaddressed.
There is this kind of thing in Scicos.
We also have a project under development:
http://www.hartes.org/index.php?
option=com_content&task=view&id=22&Itemid=40
But as you can imagine, it is not a quick&easy work ;)
Sylvestre
Matthias Zenker
Sylvestre Ledru wrote:
> There is this kind of thing in Scicos.
AFAIK, you can generate C code for a standalone application from
scicos. But what I think he (and others, me included) would want a way
to generate a standalone application directly from a scilab script
without scicos and an external C compiler. In brief, we would like to
have a Scilab compiler similar to the Matlab compiler (see
http://www.mathworks.com/products/compiler/), which already exists for
many years...
> We also have a project under development:
> http://www.hartes.org/index.php?
> option=com_content&task=view&id=22&Itemid=40
Hmmm, I don't really see a thing looking like a scilab compiler in the
project goals (I admittedly only had a quick look on it).
> But as you can imagine, it is not a quick&easy work ;)
This is certainly true... ;-)
Is a Scilab compiler anywhere on the to-do list of the scilab team, so
that we can hope to have it in the foreseeable future?
Just asking... :-)
Matthias
Sylvestre Ledru
compiler (see
> http://www.mathworks.com/products/compiler/), which already exists for
> many years...
priorities are not the same.
But Scilab is free and contributions are welcome. Feel free to help.
>> We also have a project under development:
>> http://www.hartes.org/index.php?
>> option=com_content&task=view&id=22&Itemid=40
>
> Hmmm, I don't really see a thing looking like a scilab compiler in the
> project goals (I admittedly only had a quick look on it).
> Is a Scilab compiler anywhere on the to-do list of the scilab team, so
> that we can hope to have it in the foreseeable future? Just asking...
> :-)
Please read in detail the URL I sent before. You will have your answer in
it.
Sylvestre
Richard Owlett
>[snip]
>
>>>We also have a project under development:
>>>http://www.hartes.org/index.php?
>>>option=com_content&task=view&id=22&Itemid=40
>>
>>Hmmm, I don't really see a thing looking like a scilab compiler in the
>>project goals (I admittedly only had a quick look on it).
>>Is a Scilab compiler anywhere on the to-do list of the scilab team, so
>>that we can hope to have it in the foreseeable future? Just asking...
>>:-)
>
> Please read in detail the URL I sent before. You will have your answer in
> it.
>
> Sylvestre
I think he may have missed that the URL got slit unto 2 lines.
Let's see if my newsreader keeps it on one line ;)
http://www.hartes.org/index.php?option=com_content&task=view&id=22&Itemid=40
Matthias Zenker
Sylvestre Ledru wrote:
> You may not know that but Scilab is not as big as The Mathworks and the
> priorities are not the same.
> But Scilab is free and contributions are welcome. Feel free to help.
Hi Sylvestre,
I know that Scilab is not Matlab, and of course nobody expects Scilab
to have the wealth of functionality offered by Matlab, Simulink and
its toolboxes.
But nevertheless, Scilab is somehow intended as Matlab replacement. I
therefore find it natural that from time to time, users are asking for
features which are present in Matlab but not in Scilab.
Don't take me wrong. I do appreciate the work of the Scilab team and
all contributors making Scilab the powerful tool it is today. And I
would like to have the time to contribute myself, which is
unfortunately not the case.
I also appreciate helpful hints given by members of the team in this
newsgroup permitting users to solve problems or to find a tricky
workarounds.
But sometimes it is frustrating for an ordinary user (i.e. a user not
member of the Scilab consortium) that questions for the status of
requests, for priorities and such are simply not answered by the team.
At my place, when you filed a request in bugzilla, wouldn't you be
interested to know if the team considers to address it at all, and if
so, when? Or if not, why not?
> > Hmmm, I don't really see a thing looking like a scilab compiler in the
> > project goals (I admittedly only had a quick look on it).
> > Is a Scilab compiler anywhere on the to-do list of the scilab team, so
> > that we can hope to have it in the foreseeable future? Just asking...
> > :-)
> Please read in detail the URL I sent before. You will have your answer in
> it.
I only got the first half of the url. Thank you, Richard, for pointing
this out.
The Scilab2C project looks interesting, it will certainly be a first
step towards a true scilab compiler.
Matthias
Guillaume Dutilleux
I would like to point out that the availability of a Scilab compiler
is not only of interest for speed. I agree that dynamic typing is very
nice on small projects. But when the amount of code grows, yes it
happens too for Scilab code, it tends to be quite painful and time-
consuming to have to locate bugs at run-time.
About the way to write a compiler for Scilab, has anybody ever
considered transforming Scilab code into Caml code ? Besides being
reasonably fast, Caml has many interesting features I am afraid you
will not find in C, like type inference, garbage collection, generic
data structures. Isn't Caml developed at INRIA too ?
Best regards,
G. Dutilleux
On Jun 4, 3:34 pm, Matthias Zenker <matthiaszen...@nurfuerspam.de>
wrote:
xa.m...@laposte.net
Transforming Scilab code into Caml code is a clever idea, which
unfortunately
is not among the future Scilab plans (at least not in the roadmap
items).
Yet, Caml is developed at Inria and provides all the necessary
features for building an
efficient Scilab compiler...
Once you have realized this fact, you may also consider to use Caml as
your
favorite programming language! Caml has its own built-in compiler and
Caml code
is not far from compiled C code.
Xavier.
On 12 juin, 21:14, Guillaume Dutilleux <guillaume.dutill...@free.fr>
wrote:
Matthias Zenker
On Jun 4, 3:34 pm, Matthias Zenker <matthiaszen...@nurfuerspam.de>
wrote:
> But sometimes it is frustrating for an ordinary user (i.e. a user not
> member of the Scilab consortium) that questions for the status of
> requests, for priorities and such are simply not answered by the team.
You see, this is exactly what is frustrating. No answer.
Same for http://groups.google.com/group/comp.soft-sys.math.scilab/browse_thread/thread/6ff19d2c4aa7d6f7.
You see, we users would just like to know if we can hope for the
realization of our requests in the foreseeable future. Something like
"on to-do list for Version 5" or "postponed to Version 6" or "will not
be realized in Version 5" or whatever, so that we know that the
request is not simply ignored.
I don't think this is unreasonable. Do you?
Matthias
Sylvestre Ledru
> On Jun 4, 3:34 pm, Matthias Zenker <matthiaszen...@nurfuerspam.de>
> wrote:
>> But sometimes it is frustrating for an ordinary user (i.e. a user not
>> member of the Scilab consortium) that questions for the status of
>> requests, for priorities and such are simply not answered by the team.
>
> You see, this is exactly what is frustrating. No answer.
taking time.
> Same for
> http://groups.google.com/group/comp.soft-sys.math.scilab/browse_thread/
thread/6ff19d2c4aa7d6f7.
> You see, we users would just like to know if we can hope for the
> realization of our requests in the foreseeable future. Something like
> "on to-do list for Version 5" or "postponed to Version 6" or "will not
> be realized in Version 5" or whatever, so that we know that the request
> is not simply ignored.
> I don't think this is unreasonable. Do you?
Well, please have a look on our website.
The URL http://www.scilab.org/developers/index_developers.php?page=roadmap
has been only for a long time.
And, thanks to the update of the bugzilla we did recently, we are
currently using more and more tags in Scilab. See:
http://bugzilla.scilab.org/describekeywords.cgi
And please note that Scilab is driven by a consortium, each member can
influence the roadmap. Your institut/corporation can subscribe for this.
Btw, it is not always easy to know if a request would be useful for 2 or
3 users or 200/300... but we are thinking about setting something like
the TIP (Tcl Improvement Proposal) http://www.tcl.tk/cgi-bin/tct/tip
http://wiki.tcl.tk/983 for Scilab (idea of Francois Vogel).
Sylvestre
Francois Vogel
> Btw, it is not always easy to know if a request would be useful for 2 or
> 3 users or 200/300... but we are thinking about setting something like
> the TIP (Tcl Improvement Proposal) http://www.tcl.tk/cgi-bin/tct/tip
> http://wiki.tcl.tk/983 for Scilab (idea of Francois Vogel).
TIPs are not really targeted to assessing how many users a request
would be useful to, but much more to have a written specification and
a reason for the proposed changes, in an attempt to rationalize the
development, reach a common agreement between developers, and to
remember later why things were done that way. Today Scilab has exactly
zero specification document.
For knowing whether a request would have a large audience, I think
voting for requests/bugs in the bugzilla would be more adequate, but I
have already been kicked on this hence I don't insist again.
Francois
Matthias Zenker
> Well, we are pretty busy... We try to answer to every question but it is
> taking time.
I appreciate that you took the time to answer nevertheless. :-)
> You see, we users would just like to know if we can hope for the
> > realization of our requests in the foreseeable future. Something like
> > "on to-do list for Version 5" or "postponed to Version 6" or "will not
> > be realized in Version 5" or whatever, so that we know that the request
> > is not simply ignored.
> > I don't think this is unreasonable. Do you?
>
> Well, please have a look on our website.
> The URLhttp://www.scilab.org/developers/index_developers.php?page=roadmap
> has been only for a long time.
I knew this page, it gives a rough sketch about the major priorities
and objectives. But we cannot get information on the status of a
request from there.
The roudmap page seems to have been extended recently to Scilab
version 6, where a C code generator is planned among other things.
Good. But even better would be a way to generate an .exe file from a
scilab script without the need for a C compiler...
> And, thanks to the update of the bugzilla we did recently, we are
> currently using more and more tags in Scilab. See:http://bugzilla.scilab.org/describekeywords.cgi
Looks good - here we can see at last when a bug is planned to be
fixed. Will this be implemented for requests as well?
> And please note that Scilab is driven by a consortium, each member can
> influence the roadmap. Your institut/corporation can subscribe for this.
I know - but unfortunately, we are not enough scilab users here to
justify a subscription.
Keep up the good work!
Matthias
Matthias Zenker
> Sylvestre Ledru said on 24/06/2008 11:59:
>
> > Btw, it is not always easy to know if a request would be useful for 2 or
> > 3 users or 200/300... but we are thinking about setting something like
> > the TIP (Tcl Improvement Proposal)http://www.tcl.tk/cgi-bin/tct/tip
>
> TIPs are not really targeted to assessing how many users a request
> would be useful to, but much more to have a written specification and
> a reason for the proposed changes, in an attempt to rationalize the
> development, reach a common agreement between developers, and to
> remember later why things were done that way. Today Scilab has exactly
> zero specification document.
So it would be a good thing for the developpers to have it, I suppose.
> For knowing whether a request would have a large audience, I think
> voting for requests/bugs in the bugzilla would be more adequate, but I
> have already been kicked on this hence I don't insist again.
I second that - why not use the voting feature in bugzilla? It would
not harm anybody, and can help to classify the requests.
The only problem I can think of is that the priorities are defined by
the consortium and its commitees. But the vote of "ordinary" users
could be seen as additional element in the decision on whether a
request should at least be discussed, and a decision on its priority
taken.
Matthias
Sylvestre Ledru
> On Jun 24, 1:07 pm, Francois Vogel <fsvogelnew5NOS...@free.fr> wrote:
>> Sylvestre Ledru said on 24/06/2008 11:59:
>>
>> > Btw, it is not always easy to know if a request would be useful for 2
>> > or 3 users or 200/300... but we are thinking about setting something
>> > like the TIP (Tcl Improvement
>> > Proposal)http://www.tcl.tk/cgi-bin/tct/tip
>> >http://wiki.tcl.tk/983for Scilab (idea of Francois Vogel).
>>
>> TIPs are not really targeted to assessing how many users a request
>> would be useful to, but much more to have a written specification and a
>> reason for the proposed changes, in an attempt to rationalize the
>> development, reach a common agreement between developers, and to
>> remember later why things were done that way. Today Scilab has exactly
>> zero specification document.
>
> So it would be a good thing for the developpers to have it, I suppose.
Please have a look on the current conversation here:
http://thread.gmane.org/gmane.comp.mathematics.scilab.devel/415/focus=454
Don't hesitate to participate.
>> For knowing whether a request would have a large audience, I think
>> voting for requests/bugs in the bugzilla would be more adequate, but I
>> have already been kicked on this hence I don't insist again.
>
> I second that - why not use the voting feature in bugzilla? It would not
> harm anybody, and can help to classify the requests. The only problem I
> can think of is that the priorities are defined by the consortium and
> its commitees. But the vote of "ordinary" users could be seen as
> additional element in the decision on whether a request should at least
> be discussed, and a decision on its priority taken.
We could do that.
Francois, AFAIR, I said that I didn't like the idea of vote for the bugs.
For the request, this could be interesting.
Sylvestre
Sylvestre Ledru
> On Jun 24, 11:59 am, Sylvestre Ledru <sylvestre.le...@inria.fr> wrote:
>> Well, we are pretty busy... We try to answer to every question but it
>> is taking time.
>
> I appreciate that you took the time to answer nevertheless. :-)
I would have replied sooner if I wasn't in holidays ;)
>> Well, please have a look on our website. The
>> URLhttp://www.scilab.org/developers/index_developers.php?page=roadmap
>> has been only for a long time.
>
> I knew this page, it gives a rough sketch about the major priorities and
> objectives. But we cannot get information on the status of a request
> from there.
> The roudmap page seems to have been extended recently to Scilab version
> 6,
Hmm, it is at least 6 months old I would say.
> where a C code generator is planned among other things. Good. But
> even better would be a way to generate an .exe file from a scilab script
> without the need for a C compiler...
Well, sorry but you are dreaming on this. ;)
It is a huge work to do this (and useless btw).
>> And, thanks to the update of the bugzilla we did recently, we are
>> currently using more and more tags in Scilab.
>> See:http://bugzilla.scilab.org/describekeywords.cgi
>
> Looks good - here we can see at last when a bug is planned to be fixed.
> Will this be implemented for requests as well?
We could do that too. But it is an important work too. Ping me on this
when we will have released the version 5 of Scilab. I will see what we
can do.
>> And please note that Scilab is driven by a consortium, each member can
>> influence the roadmap. Your institut/corporation can subscribe for
>> this.
>
> I know - but unfortunately, we are not enough scilab users here to
> justify a subscription.
Give it a try ! ;)
Sylvestre
Matthias Zenker
> Le Wed, 25 Jun 2008 01:20:06 -0700, Matthias Zenker a écrit:
>
> > On Jun 24, 11:59 am, Sylvestre Ledru <sylvestre.le...@inria.fr> wrote:
> >> Well, we are pretty busy... We try to answer to every question but it
> >> is taking time.
>
> > I appreciate that you took the time to answer nevertheless. :-)
>
> I would have replied sooner if I wasn't in holidays ;)
Oh, I see. I was a bit too impatient, then... ;)
> > The roudmap page seems to have been extended recently to Scilab version
> > 6,
>
> Hmm, it is at least 6 months old I would say.
I admittedly don't visit it that often.
Suggestion: you could announce updates of that page in this newsgroup.
> > even better would be a way to generate an .exe file from a scilab script
> > without the need for a C compiler...
>
> Well, sorry but you are dreaming on this. ;)
> It is a huge work to do this (and useless btw).
Not knowing enough about Scilab internals, I have to trust you on the
first point. ;)
Is there a comprehensible description of what Scilab does to execute a
user script, so that I get an idea of all that myself?
IMO there are arguments for a Scilab compiler (see also
http://groups.google.com/group/comp.soft-sys.math.scilab/browse_thread/thread/ce83d006cab4e078/cc0cb334bcb93cd6).
* I could write a program in Scilab and distribute it to others,
without them having to install the full Scilab on their computer.
Since scilab is free, costs are not an argument, but it would be more
convenient nevertheless.
* In the industrial world, one might want not to disclose the code of
such a program.
* This is principally possible with the method described in the
examples/callsci directory. I admittedly had only a quick look into
that, but at a first glance, the method seems tedious to me if I want
to embed a 1000+ lines Scilab program. And it needs a separate C, C++
or Fortran compiler (BTW, does it work for Delphi also?). So it
requires quite some extra work to transform a Scilab program into a
standalone executable that way - compiling directly from Scilab would
be far more convenient.
* A Scilab compiler could check the syntax before execution of the
script. This can be useful.
> >> And, thanks to the update of the bugzilla we did recently, we are
> >> currently using more and more tags in Scilab.
> >> See:http://bugzilla.scilab.org/describekeywords.cgi
>
> > Looks good - here we can see at last when a bug is planned to be fixed.
> > Will this be implemented for requests as well?
>
> We could do that too. But it is an important work too. Ping me on this
> when we will have released the version 5 of Scilab. I will see what we
> can do.
OK. :)
> >> And please note that Scilab is driven by a consortium, each member can
> >> influence the roadmap. Your institut/corporation can subscribe for
> >> this.
>
> > I know - but unfortunately, we are not enough scilab users here to
> > justify a subscription.
>
> Give it a try ! ;)
Hmmm, there are only two people regularly using Scilab in our company,
and perhaps two occasional users. I would have a hard time to justify
the subscription costs (we would be "B College", which means 8000 €/
year) compared to the costs of a Matlab licence... ;)
Matthias
Matthias Zenker
> Please have a look on the current conversation here:http://thread.gmane.org/gmane.comp.mathematics.scilab.devel/415/focus...
> Don't hesitate to participate.
Is this the developper's newsgroup? I had a quick look and could only
display some of the contributions. Bu I will lokk again from time to
time.
> We could do that.
> Francois, AFAIR, I said that I didn't like the idea of vote for the bugs.
> For the request, this could be interesting.
Fine - so you will consider to do it?
Matthias
Ledru Sylvestre
wrote:
> On Jun 25, 7:52 pm, Sylvestre Ledru <sylvestre.le...@inria.fr> wrote:
>
> > Please have a look on the current conversation here:http://thread.gmane.org/gmane.comp.mathematics.scilab.devel/415/focus...
> > Don't hesitate to participate.
>
> Is this the developper's newsgroup? I had a quick look and could only
> display some of the contributions. Bu I will lokk again from time to
> time.
localization MLs).
See:
http://www.scilab.org/contactus/index_contactus.php?page=mailing_lists
> > We could do that.
> > Francois, AFAIR, I said that I didn't like the idea of vote for the bugs.
> > For the request, this could be interesting.
>
> Fine - so you will consider to do it?
After the release of Scilab 5, I will ask to the other people in the
team but at least for me, I think that could be a good idea as long as
people understand that won't obligate us to develop it (our vision of
Scilab may be different from users on some points).
S
Matthias Zenker
wrote:
> Not a newsgroup. It is our dev mailing list (we also have user and
> localization MLs).
> See:http://www.scilab.org/contactus/index_contactus.php?page=mailing_lists
Thank you for the hint.
> After the release ofScilab5, I will ask to the other people in the
> team but at least for me, I think that could be a good idea as long as
> people understand that won't obligate us to develop it (our vision ofScilabmay be different from users on some points).
OK, I will remind you... ;)
Matthias
TideMan
> > In brief, we would like to have a Scilab compiler similar to the Matlab
> compiler (see
> >http://www.mathworks.com/products/compiler/), which already exists for
> > many years...
>
Well, I wouldn't hold up the Matlab compiler as a shining example of
what should be done in Scilab. Here are a few "features" of the
Matlab compiler:
1. It is very expensive.
2. It only works on some functions.
3. It generates huge .exe files.
4. It is idiosyncratic: it works sometimes, but not others.
My strategy is to translate any .m programs I want to distribute into
Fortran.