GTK, License etc...
divid
Scilab
License. Indeed, the Scilab License is not recorded in the set of
hallmarked
free software appearing in
http://www.opensource.org/licenses/
The Scilab license should be compatible with the policy of the
commercial sponsors
of Scilab and the fact that Scilab includes non free routines.
At first glance, the Gtk license may be seen as hardly
compatible with the Scilab License (and, why not, a future commercial
distribution
of Scilab?).
Yet, what follows is quoted from the Gtk Webpage:
GTK+ is free software and part of the GNU Project. However, the
licensing terms for GTK+, the GNU LGPL, allow it to be used by all
developers, including those developing proprietary software, without
any license fees or royalties.
So what is the rationale behind this decision ?
jess...@gmail.com
shiq...@gmail.com
scilab.
It seems Scilab Team is doing this work.
They need check the licence in each source file and contact with the
original authors.
Hope they finish it as soon as possible.
François VOGEL
news:1150080136.3...@c74g2000cwc.googlegroups.com...
> To change scilab licence to GPL compatible licence will be good for
> scilab.
> It seems Scilab Team is doing this work.
? Where did you find such information?
> They need check the licence in each source file and contact with the
> original authors.
> Hope they finish it as soon as possible.
Scilab team, is he right?
Can you confirm this statement?
Francois
Serge...@inria.fr
> > original authors.
> > Hope they finish it as soon as possible.
>
> Scilab team, is he right?
> Can you confirm this statement?
Yes he is, it is planned to put Scilab under a double licence: GPL or
similar for everybody and LGPL (or similar) for the consortium members
to make it possible for them to redistribute (freely or not) Scilab or
part of it in their own codes without being obliged to put all their
code under GPL.
For that we should verify that all the files included into Scilab can
be put under such licences. We know that Scilab includes a lot of file
coming from external libraries. If most of them can be distributed
freely, it is not so easy to know if it is possible to change their
licences to GPL/LGPL. As an example it is not possible for odepack
routines, A new version now exist under LGPL, but it should be
interfaced.
All this work take a lot of time, it is some time quite impossible to
have clear answers from the copyright owner (eg netlib), we need to
replace some codes,... this explains that the licence change has not
been done yet.
On another point of view, the Scilab team and the consortium steering
comitee decided two important evolutions for the future (Scilab5):
- the reorganization of the code in modules, to ease the separate
evolution of each of them and the update of new version modules.
- the rewritting of all the GUI (console, graphic windows, menus,
...) using a portable tool, not to have to maintain 2, 3 or more source
code depending on the OS. The choice as been made on Java for that,
with something like on thread for computational engine mainly written
in C and Fortran, and one thread in Java for the intercation with the
user.
But we intend to make a clear API between the compuational engine and
the IHM, so if someone(s) want to adapt the GTK code of the GUI to this
new architecture it will be possible to have a GTK module alternative
to the Java one developped and distributed under the Scilab team
responsibility.
Serge Steer
Scilab team
jess...@gmail.com
does its GUI in Java with the result that it takes a full minute for
Matlab 7 to boot on P4. Moreover the older versions of matlab give
trouble with java runtimes from different vendors.
On the other hand, look at the choice of TCL/TK made by Modelsim.
Excellent interface, beautiful graphics, native feel, fast, reliable,
and multiplatform. Here is an article from these folks
http://aspn.activestate.com/ASPN/Tcl/TclConferencePapers2002/Tcl2002papers/griffin-lnf/Realizing_Windows_Look_Feel_with_Tk.doc
Scilab's editor already uses TCL/TK and this may be the best choice for
the whole.
shiq...@gmail.com
well.
bruno
> licences to GPL/LGPL. As an example it is not possible for odepack
> routines,
Serge,
why do you say this ? odepack is used by octave, which is a GPL
software. So may be it is GPL compatible but not LGPL compatible ?
But a 5 sec google search leads me on the odepack official web site :
http://www.llnl.gov/CASC/odepack/
which stands that :
"The following Fortran solvers for ordinary differential equation (ODE)
systems were written at LLNL. All are in the Public Domain and are
freely available from the CASC Software Download Site ."
So as Lapack they are Public Domain, that 's all.
hth
Bruno
jpc
Serge...@inria.fr wrote:
> Yes he is, it is planned to put Scilab under a double licence: GPL or
> similar for everybody and LGPL (or similar) for the consortium members
> to make it possible for them to redistribute (freely or not) Scilab or
> part of it in their own codes without being obliged to put all their
> code under GPL.
>
> For that we should verify that all the files included into Scilab can
> be put under such licences.
Hello Serge,
I know that you have very little time to devote to that important task.
But this answer is quite strange. The plans to put Scilab under a
double
licence come back to more than two years and as far as I know someone
has worked full time at Inria to try to detect which part of the code
was or was not ok for GPL.
Thus saying <<we should verify>> which seems a present or future tense
is strange.
Moreover the odepack example you cite seems not relevant as explained
by Bruno
in a latter post: Thus is it something you are seriously working on ?
You could ask the FSF to help you solve this intricate problem.
>>> On another point of view, the Scilab team and the consortium steering
>>> comitee decided two important evolutions for the future (Scilab5):
Well, Since the Scilab team is not supposed to decide I think that
you mean that the Scilab team (the scilab devpt team)
has presented a (one way) plan and that the Steering comitee has
decided !
Regards,
jpc
steve
Turning Scilab into a GPL code is really good news. Scilab is now
entering in the free
software community! At last potential contributors will have their code
protected from
being indirectly sold by the Scilab consortium (or its sponsors), as
this is the case with the current license.
There is room for Scilab and Octave and R together and even they will
have the ability to cooperate.
Of course Scilab will have to throw large pieces of proprietary code,
but the counterpart is fantastic: GSL, GMP, FFTW, UMFPACK, GLPK,
READLINE, and many other high quality scientific packages.
Based on these modern GPLed libraries Sci-Lab will become a real
Sci-entific-Lab.
The choice of Java is debatable. The Matlab GUI is nice but really
slow.
Gtk would be a good alternative, but apparently rejected (?)
Why not keeping Tcl/Tk?
Don't be double faced. You know that your Java choice implies that the
current Tcl/Tk gui and the Scipad editor will soon or later finish in a
trash can.
Many efforts for nothing!
jEdit is an excellent editor combining a GPL license and Java.
Logically, it will soon or later replace Scipad!
shiq...@gmail.com
Enrico Segre
> If not java, how about QT or wxWidgets?
my personal problems with java for scilab (and what related in this
discussion) are the following:
1) the choice has not been discussed adequately
2) java requires a jre which tends to be heavy, thus excluding
backporting to older machines
3) the better "state of the art" (so to say...) gtk gui (it was not the
ultimate, but was a good attempt) has been authoritatively removed
without anything comparable replacing it first
4) developement timeline is completely nebulous, as well as alleged
superiority as a gui
5) matlab's java for unix used to be ugly, slow and buggy, now it
improved to some extent but is still slow, fact which is a bad reference
for me.
6) promises about a published api so that everybody can supply his
flavour of scilab gui are some year old now, and outdated. We have still
to see.
Enrico
Francois Vogel
>> Java may not be the appropriate choice for GUI development.
Euphemism.
>> On the other hand, look at the choice of TCL/TK made by Modelsim.
>> Excellent interface, beautiful graphics, native feel, fast, reliable,
>> and multiplatform. Here is an article from these folks
>> http://aspn.activestate.com/ASPN/Tcl/TclConferencePapers2002/Tcl2002papers/griffin-lnf/Realizing_Windows_Look_Feel_with_Tk.doc
Excellent paper, thanks for the pointer. It's really fitted to the question.
>> Scilab's editor already uses TCL/TK and this may be the best choice for
>> the whole.
I would have also advocated this choice if the fact there was a decision to
make had been made public. But they decided on their own in the background.
The team perhaps discussed internally, but no external person was invited to
join the discussion AFAIK. This open project concept is... well, let's say
strange.
Francois
Francois Vogel
> It seems that TCL/TK can not support CJK (Chinese, Japanese, Korean)
> well.
It seems that this is (at least partially) wrong if I read this page
correctly:
http://wiki.tcl.tk/1356
Other possible reference:
http://wiki.tcl.tk/2544
Did you ever have a try using a recent Tcl/Tk version (current stable is
8.4.13, but 8.5a4 is also available)?
Francois
Francois Vogel
1150319126.8...@p79g2000cwp.googlegroups.com...
> Don't be double faced. You know that your Java choice implies that the
> current Tcl/Tk gui and the Scipad editor will soon or later finish in a
> trash can.
> Many efforts for nothing!
> jEdit is an excellent editor combining a GPL license and Java.
> Logically, it will soon or later replace Scipad!
What you say above very correctly summarizes a large amount of my thoughts
too.
Sooner or later the team will erase or rewrite Scipad. And they will do it
the way they do everything, i.e. with no discussion and without asking for
anybody's opinion. Some day I will just discover by a stroke of luck that
the scipadsources directory has suddenly disappeared from the svn version.
This is not yet officially planned, if I've heard correctly what Serge Steer
said to me.
But the truth is that I can't believe that statement.
The logical consequence is that I stopped my developments in Scipad for many
weeks.
Francois
jpc
> GREAT NEWS! AT LAST!!
Gtk is of course a good alternative.... the one I prefer.
The great advantage of Gtk is that it was designed so as to
be easily interfaced in
other languages (interpreted or not, with or without garbage
collector)
Thus you have gtk language binding in python,caml,java,erlang,
javascript, etc......
Using opengl graphics with gtk is already done (gtkglext).
Moreover gtk is the one for which an advanced project already
exists:
you can test a new scilab like kernel with gtk language bindings at
http://cermics.enpc.fr/~jpc/scilab/site/Nsp/Nsp/index.htm
(only Linux support, a native win32 version will follow soon)
The native win32 version of Gtk exists and a native MacOSX
implementation is being developped.
Matthias Zenker
Francois Vogel wrote:
> Sooner or later the team will erase or rewrite Scipad. And they will do it
> the way they do everything, i.e. with no discussion and without asking for
> anybody's opinion. Some day I will just discover by a stroke of luck that
> the scipadsources directory has suddenly disappeared from the svn version.
>
> This is not yet officially planned, if I've heard correctly what Serge Steer
> said to me.
>
> But the truth is that I can't believe that statement.
The following has been said many times before, but it doesn't hurt to
repeat it:
It is a bad thing that the development policy of scilab is absolutely
not transparent to the users, and even not to the (external)
developpers.
The development goals and roadmap for version 5 has neither been
discussed with nor been made visible to anyone (except the INRIA team
and the consortium, perhaps), but things like removing apparently
unwanted code have already been done.
That is not the way an open project works.
It is absolutely not clear why the scilab team behaves that way.
The objective to create the best possible scilab should be common to
all (scilab team, external developpers, and users), there should be
cooperation rather than confrontation.
But that implies that decisions concerning the development strategy are
discussed before they are definitively taken, and that they are
announced before the code modifications are done. Otherwise, external
developpers and users get the impression that they are completely
irrelevant for the team, or even that decisions are taken and
implemented silently because the team knows that there would be
objections from "outside".
> The logical consequence is that I stopped my developments in Scipad for many
> weeks.
Scipad is a key component of scilab, and has improved at an impressive
pace.
Scilab team, do you really want to throw it away, and discourage one of
the most active developpers?
Matthias
jpc
> implementation is being developped.
Just a complement, you can see a picture of nsp on windows
using native gtk win32 on
http://cermics.enpc.fr/~jpc/scilab/site/Nsp/Nsp/nsp.png
This should kill a rumour telling that there's a problem with gtk
on windows....
jpc
Jean-Pierre Vial
>>slow.
Maple has also moved to a java interface:
Consequences: it cannot work on low-end or old machines,
and on more powerful stations it is much slower than the previous
version: starting is so slow that my student click two or three times,
resulting in two or three instances of maple running in the end, because
nothing seem to happen during 20 or 30 seconds on the first click.
Matthias Zenker
I was hoping that someone from your side would react to my previous
post.
Let me summarize it in form of questions:
1. Why is the roadmap for scilab 5.0 not published, although it must
exist, since important decisions seem to have been taken already? Is
the roadmap considered to be confidential, and if so, why?
2. What are the reasons to use Java in spite of its slowliness?
3. Is it planned to remove the current Tcl/Tk GUI including scipad when
the move to Java is done?
Thank you for clarifying this.
Matthias
Sylvestre Ledru
Hello,
> 2. What are the reasons to use Java in spite of its slowliness?
* Multiplatform (in theory, the same code works everywhere)
* Many people know how to program in Java (more than with GTK or X11)
* Many libs available
I agree on the fact that it is slow to launch but after that,
the speed is good.
steve
*GTK and TCL/TK are also multiplatform. And many others...
*The Scilab users are NOT supposed to code in Java! The fact that many
people know Java could at most be useful for developers.
And yet, GTK, for instance, is a C library which can used by anyone
knowing the C programming language.
*Many libs ? five libs is better than four libs ???
And, IN ADDITION, Java is slow.
Remember that Matlab is a commercial package which cannot be based upon
free software.
As Scilab is moving to GPL, it can be (and should be) based on free
open source codes.
Sylvestre Ledru
> None of these reasons is relevant.
> *GTK and TCL/TK are also multiplatform. And many others...
Like QT, wx-widgets, Interview...
I am aware of this. It is not because other technologies exists that Java
cannot be chose. ;)
> *The Scilab users are NOT supposed to code in Java!
> The fact that many people know Java could at most be useful for
> developers.
Of course, I was talking about dev, not lambda user. I was not clear on
this.
> And yet, GTK, for instance, is a C library which can used by
> anyone knowing the C programming language.
I agree. But just have a look on scientific university program, every IT
course has a Java leason. It is not the case of C.
> *Many libs ? five libs is better than four libs ??? And, IN ADDITION,
> Java is slow.
Java was slow. It changed a lot during the last few years. Try to use
Azureus for example (http://azureus.sourceforge.net/). OK, it is not very
fast to start but once it is done, it is fast (as many other applications
with GTK) and efficient.
shiq...@gmail.com
It's a good lib and can give native look in different platforms.
Besides, its license is L-GPL.
Here is a presentation about wxWidgets:
http://wxwidgets.org/about/wxwidgets.swf
Some Matlab users complain Matlab is too slow to start.
Is it Java or other reasons to make Matlab slow?
Personally, I hope Scilab to be a fast program,
whatever to start or to run.
Sylvestre Ledru wrote:
> > None of these reasons is relevant.
> It is your point of view.
>
> > *GTK and TCL/TK are also multiplatform. And many others...
> Like QT, wx-widgets, Interview...
> I am aware of this. It is not because other technologies exists that Java
> cannot be chose. ;)
>
> > *The Scilab users are NOT supposed to code in Java!
> > The fact that many people know Java could at most be useful for
> > developers.
> Of course, I was talking about dev, not lambda user. I was not clear on
> this.
>
> > And yet, GTK, for instance, is a C library which can used by
> > anyone knowing the C programming language.
> I agree. But just have a look on scientific university program, every IT
> course has a Java leason. It is not the case of C.
I don't know other countries, but in China,
C, is the most common course, not java.
Matthias Zenker
Sylvestre Ledru wrote:
> > 2. What are the reasons to use Java in spite of its slowliness?
> * Multiplatform (in theory, the same code works everywhere)
> * Many people know how to program in Java (more than with GTK or X11)
> * Many libs available
>
> I agree on the fact that it is slow to launch but after that,
> the speed is good.
Hello Sylvestre,
I have just discovered that you are a member of the scilab team.
Thank you for answering to my question no. 2.
May I ask you to comment on my questions no. 1 and 3 also?
Matthias
Sylvestre Ledru
> Some Matlab users complain Matlab is too slow to start.
> Is it Java or other reasons to make Matlab slow?
the system has to load the JVM (Java Virtual Machine).
After that, there are tricks that you have to know when you build a GUI.
> Personally, I hope Scilab to be a fast program, whatever to start or to
> run.
Of course, the software has to be fast.
When (how many seconds) will you consider it as slow to start ?
Sylvestre Ledru
> Thank you for answering to my question no. 2.
> May I ask you to comment on my questions no. 1 and 3 also?
I cannot answer to 1 & 3 'cause I don't know the answer.
(I am working on the technical aspects (mainly GNU/Linux)
of Scilab).
Sylvestre Ledru
1) You will get it. Don't worry. When exactly ? I did not ask.
3) It should not be removed (upward-compatible).
ycollet
What about using python for the new scilab gui ?
Sylvestre Ledru
> What about using python for the new scilab gui ?
that many people know Java.
I like Python. However I think you will agree if I say that it is not
widely spread. ;)
Are there a lot of graphical interfaces made with Python ? (Anaconda is
the only one I know).
steve
other technologies without any specific reason.
Matlab is reasonably fast, but launching Matlab is a mess.
As a user of both programs (Scilab at home!) I am convinced that Java
is not the best choice for a (future) free software.
But of course Java is a possible choice for building the (future)
Scilab GUI.
Sylvestre Ledru a écrit :
steve
Tcl/tk interface???
On the other hand you claim that Tcl/Tk is also a good multi-platform
alternative.
Once again why adding Java to Tcl/tk ????
Sylvestre Ledru a écrit :
ycollet
Python is the interfaced language of a lot of programs like salome ().
The "native" interface of python is based on tcl/tk.
Skencil (a drawing program) uses python for it's interface
(http://www.nongnu.org/skencil/)
ycollet
Python is the interfaced language of a lot of programs like salome
(http://www.salome-platform.org/home/presentation/overview/).
jpc
Sylvestre Ledru wrote:
> > *GTK and TCL/TK are also multiplatform. And many others...
> Like QT, wx-widgets, Interview...
> I am aware of this. It is not because other technologies exists that Java
> cannot be chose. ;)
Yes you are right for every technologies you will find fans and
well done applications. But the problem is elesewhere.
Scilab is a programming language thus you want to have
a full access to a GUI not just that the frame of your application is
built with a toolkit. On that precise point which is of major
importance
Gtk is better than all the other toolkits. Now on Linux most of the
Gnome widget for configuring the system are directly programmed with
python because Gtk is fully interfaced with python. Thus people find
a script language which gives full access to a very large toolkit
without
restrictions.
Note also that GTk is fully available in java.
Interfacing gtk in a scilab like language has been done, as I
explained in a
previous mail, for nsp (a toy scilab clone in C/Gtk)
http://cermics.enpc.fr/~jpc/scilab/site/Nsp/Nsp/index.htm
Moreover the non fully explained roadmap 5 is not that precise
I have heard that java will be present but also tcl/tk and of course
C and Fortran .... the aim is just to provide a java terminal + a
java controlled
graphic window and menus (x_message etc...).
Of course this could coexist with wsci/gtk etc.....
Sylvestre Ledru
> You are chosing Java for the Scilab GUI and you are keeping the current
> Tcl/tk interface???
At the moment, we plan to leave the tcl/tk interface without mainting it.
> On the other hand you claim that Tcl/Tk is also a good multi-platform
> alternative.
> Once again why adding Java to Tcl/tk ????
I already answer to this question ;)
Sylvestre Ledru
> Python is the interfaced language of a lot of programs like salome
> (http://www.salome-platform.org/home/presentation/overview/).
> The "native" interface of python is based on tcl/tk.
Thank for the information
jpc
ycollet wrote:
> Just a little question:
>
> What about using python for the new scilab gui ?
It is bit strange to use an interpreted language to implement
the gui of an other interpreted language. More over it does not
give a clear idea of which GUI you want since python can use tk or gtk
(pygtk) and
maybe other GUIs (wxwindows i.e wxpython).
Of course it's the same for tcl/tk : in order to provide a gui to
scilab you have
to embed a full new interpreted language (tcl). Not very light.
jpc
Sylvestre Ledru wrote:
> I like Python. However I think you will agree if I say that it is not
> widely spread. ;)
There are certainly many reasons for not using python but I am not
sure
that the one you give is that pertinent.
Python is more widely spread than ....Scilab and maybe
more than java too, because it's a script language
Just do the following: Try to find a library which is not interfaced
in python ....
As for GUI design you certainly can find hundred of examples based on
http://www.pygtk.org/applications.html
for example :
http://gazpacho.sicem.biz/
and
http://matplotlib.sourceforge.net/
vtk and python
http://www.imaging.robarts.ca/~dgobbi/vtk/vtkpython.html
Sylvestre Ledru
> other technologies without any specific reason.
* Java is widely used, a "defacto standard" and competencies in Java are
easy to find
* Plenty of tools, API, documentations.
* Multiplatform support (write once, run everywhere: no need to spend
time to make lib working on each platform and adapt the software)
* A very good object model
> Matlab is reasonably fast, but launching Matlab is a mess.
> As a user of both programs (Scilab at home!) I am convinced that Java
> is not the best choice for a (future) free software.
Except that Matlab is slow to launch, do you have argument for not
using Java ?
Sylvestre Ledru
> more than java too, because it's a script language
various experiences. I don't have any prof (and anyway good luck to find
any) :)
> Just do the following: Try to find a library which is not interfaced
> in python ....
Opencascade ?
> As for GUI design you certainly can find hundred of examples based on
> http://www.pygtk.org/applications.html
I am not criticising Python. I am just saying that we don't think that it
is appropriate for what we want to do.
jpc
Sylvestre Ledru wrote:
> > Python is more widely spread than ....Scilab and maybe
> > more than java too, because it's a script language
> I really don't think that is the case. However, it is what I saw during my
> various experiences. I don't have any prof (and anyway good luck to find
> any) :)
Well now you admit that the previous affirmation you made
was pure guess based on your personnal experience.... you could
then be more prudent and add some maybe in your sentences.
>
> > Just do the following: Try to find a library which is not interfaced
> > in python ....
> Opencascade ?
Author: Niki Spahiev
Description: I started work on Python interface to Open CASCADE. Python
is WHLL found at http://www.python.org
Plan is to use metadata in order to automaticaly write SIP definitions
for Open CASCADE classes.
> I am not criticising Python.
I was aware of that point ....
> I am just saying that we don't think that it
> is appropriate for what we want to do.
maybe but the speculative wide spread argument was not convincing.
Francois Vogel
>> Tcl/tk interface???
> At the moment, we plan to leave the tcl/tk interface without mainting it.
What do you mean by "without maintaining it" exactly?
This is different from what I heard from Serge.
Francois
steve
"We plan to leave" means we plan to drop out.
"without maintaining it" means that the interface is no more supported.
And this is the very LOGICAL consequence of the Java choice.
On the other hand, you claim that both will remain (?).
This looks like a kind of schizophrenic standpoint.
Anyway, many thanks, Sylvestre, for your answers.
Steve
Sylvestre Ledru a écrit :
sylvest...@gmail.com
>
> What do you mean by "without maintaining it" exactly?
ask him ;)
You know his email.
Francois Vogel
1151712803....@y41g2000cwy.googlegroups.com...
OK, if you want to go there, let's go there.
1. Steve is right in his post:
"We plan to leave" means we plan to drop out.
"without maintaining it" means that the interface is no more supported.
Dropping out implies removing the code from Scilab.
If you really drop out the Tcl/Tk interface, how can you say at the same
time anything about maintaining it or not?
2. You said previously in this thread about the question from Matthias "Is
it planned to remove the current Tcl/Tk GUI including scipad?" that:
> It should not be removed (upward-compatible).
Unless there is a subtlety in this statement, this contradicts 1. above.
2. You perfectly know that I have already asked Serge about this, and that
he answered that the interface:
a. will be kept in Scilab, i.e. the Tcl/Tk code will remain in Scilab
b. will be maintained by *you* (well, by the team you're part of)
c. but there will be no further new development in Tcl/Tk *by the
operational team*
So I observe that you contradict yourself and that your team leader
disagrees with you, who should I trust?
Francois
sylvest...@gmail.com
> was pure guess based on your personnal experience.... you could
> then be more prudent and add some maybe in your sentences.
However, AFAIK, the only ways to know if a language is popular or not,
is to see which language are used by projects, look if it is taught at
university and read IT magazines/news site.
> > I am just saying that we don't think that it
> > is appropriate for what we want to do.
>
> maybe but the speculative wide spread argument was not convincing.
Sorry if I have not been convincing but it is my point of view, you
have yours :)
Sylvestre
> Of course it is from my experience, I am not omniscient.
> However, AFAIK, the only ways to know if a language is popular or not,
> is to see which language are used by projects, look if it is taught at
> university and read IT magazines/news site.
I know a quite good way (empiric) to know if it is used or not :
Java
: http://offres.monster.fr/jobsearch.asp?cy=fr&sort=rv&vw=d&q=Java&fn=&lid=&x=0&y=0
(more than 1000 offers)
Python
: http://offres.monster.fr/jobsearch.asp?q=python&re=0&sort=rv&tm=&cy=fr&vw=d
19 offers
I agree that it is not a perfect way for mesuring but I think that reflect
what it known and used...
Enrico Segre
> Java
> : http://offres.monster.fr/jobsearch.asp?cy=fr&sort=rv&vw=d&q=Java&fn=&lid=&x=0&y=0
> (more than 1000 offers)
>
> Python
> : http://offres.monster.fr/jobsearch.asp?q=python&re=0&sort=rv&tm=&cy=fr&vw=d
> 19 offers
>
> I agree that it is not a perfect way for mesuring but I think that reflect
> what it known and used...
proves nothing:
http://offres.monster.fr/jobsearch.asp?q=excel&re=0&sort=rv&tm=&cy=fr&vw=d
more than 1000 offers
and I'd bet excel is taught even in third age neighborhood community
centers. So why don't you write scilab in Excel and make the industry
happy?
Enrico
Sylvestre
>> Java
>> : http://offres.monster.fr/jobsearch.asp?cy=fr&sort=rv&vw=d&q=Java&fn=&lid=&x=0&y=0
>> (more than 1000 offers)
>>
>> Python
>> : http://offres.monster.fr/jobsearch.asp?q=python&re=0&sort=rv&tm=&cy=fr&vw=d
>> 19 offers
>>
>> I agree that it is not a perfect way for mesuring but I think that reflect
>> what it known and used...
>
> proves nothing:
>
> http://offres.monster.fr/jobsearch.asp?q=excel&re=0&sort=rv&tm=&cy=fr&vw=d
which is not the case of excel.
Sylvestre
>>> what it known and used...
>>
>> proves nothing:
>>
>> http://offres.monster.fr/jobsearch.asp?q=excel&re=0&sort=rv&tm=&cy=fr&vw=d
> That just shows Excel is widely used. And only "IT people" use Java/Python
> which is not the case of excel.
a GUI Java can be an asset in order to facilitate the participation of
people because Java is very used.
bruno
> I agree that it is not a perfect way for mesuring but I think that reflect
> what it known and used...
This way of comparing Java/python popularity is certainly
valid for commercial projects but seems dubtious for free projects
no ? Otherwise my feel for free scientific projects is that C++ and
C are still heavily used and also that python with scipy/numpy
begins to be a powerful Matlab alternative.
Bruno
Sylvestre Ledru
> 1. Steve is right in his post:
> "We plan to leave" means we plan to drop out.
> "without maintaining it" means that the interface is no more supported.
> Dropping out implies removing the code from Scilab.
> If you really drop out the Tcl/Tk interface, how can you say at the same
> time anything about maintaining it or not?
As I told you, I just asked Serge. I don't know anything about this. I am
a newbie in the team and I am not aware of this kind of this.
steve
-I am a newbie.
-I asked to Serge.
-I have not been able to understand his answer.
-To leave means to keep.
Conclusion: The Tcl/Tk interface is no more maintained but it is
supported.
Regarding Gtk, the code is being removed from the trunk SVN.
Question: Is it supported ?
Anyway, thank you for your posts, eventhough this topic is not
completely straightforward.
At least for me.
Steve
Sylvestre Ledru a écrit :
> > 1. Steve is right in his post:
Sylvestre Ledru
> Summing up:
> -I am a newbie.
> -I asked to Serge.
> -I have not been able to understand his answer.
> -To leave means to keep.
> Conclusion: The Tcl/Tk interface is no more maintained but it is
> supported.
Well, sorry for the misunderstanding. The verb "leave" was not appropriate.
Serge...@inria.fr
Matthias Zenker a écrit :
> Scilab team, do you really want to throw it away, and discourage one of
> the most active developpers?
As Francois reported there is no plan to erase or rewrite scipad. But
everybody can propagate rumors....
One thing that is not a rumor: the Scilab projet is not an open project
in the sourceforge or gforge way. It much more ressemble to the Mozilla
development mode. The main reason is that Scilab is now supported by a
consortium which group compagnies and academics. You also need to know
that without this consortium Scilab should have deseapeared because in
2003 INRIA refused to support the development anymore if such a
structure was not created. The consortium contribution allows to give a
much more dynamic development than before.
BUT Scilab is a free and open source as stated by the licence file. The
only restriction today is it cannot be modified AND sold without INRIA
autorisation. We are currently working to make Scilab compatible with a
GPL/LGPL licence. But this is a long run work due to the number of
files from various origin.
Serge Steer
Scilab Team
> Francois Vogel wrote:
> > Sooner or later the team will erase or rewrite Scipad. And they will do it
> > the way they do everything, i.e. with no discussion and without asking for
> > anybody's opinion. Some day I will just discover by a stroke of luck that
> > the scipadsources directory has suddenly disappeared from the svn version.
> >
> > This is not yet officially planned, if I've heard correctly what Serge Steer
> > said to me.
Serge...@inria.fr
write here and to try to give information on the Scilab development.
You take profit of a wrong english word to start a full polemic on
points that have been already fully answered. I have myself said by
mail, news, meeting, ... To Francois that the TCK/TK interface will
continue to be supported in Scilab because of compatibility with
previous versions and because TCL/TK is a good tool. If we decided to
rewritte the internal coding of this interface for Scilab 4 it is not
to remove it after that...
I just want to say. The remarks and criticisms are welcome here but
please avoid denigation and calumny!
Serge Steer
Scilab development team responsible
Francois Vogel a écrit :
steve
development team responsible
uses to qualify the above quiet and open discussion ?
Steve
Matthias Zenker
Serge...@inria.fr wrote:
> Matthias Zenker a écrit :
> > Scilab team, do you really want to throw it away, and discourage one of
> > the most active developpers?
>
> As Francois reported there is no plan to erase or rewrite scipad. But
> everybody can propagate rumors....
I think this is a little bit due to what seems to be the policy of the
scilab team: take decisions and create facts without discussion and
without informing anybody...
A little more transparency would help here.
> One thing that is not a rumor: the Scilab projet is not an open project
> in the sourceforge or gforge way. It much more ressemble to the Mozilla
> development mode. The main reason is that Scilab is now supported by a
> consortium which group compagnies and academics. You also need to know
> that without this consortium Scilab should have deseapeared because in
> 2003 INRIA refused to support the development anymore if such a
> structure was not created. The consortium contribution allows to give a
> much more dynamic development than before.
Thank you for clarifying this, and for communicating more with the
people posting here.
Suggestion: Place this kind of information on the scilab home page,
e.g. on the page about the Consortium. And add some explanations on how
the Consortium works, its role in the scilab development, the decision
path etc.
This would help all "externals" (users, developpers) to understand
these things better, and might help to avoid frustration.
Matthias