The Scilab Team is pleased to announce the release of Scilab 5.1.1.
Misc information about this version:
http://www.scilab.org/download/index_download.php?page=5.1.1
Main changes between Scilab 4 & Scilab 5 :
http://www.scilab.org/changes_5/
Changes between Scilab 5.0.x & Scilab 5.1 :
http://www.scilab.org/download/index_download.php?page=CHANGES_5.1
Changes between Scilab 5.1 & Scilab 5.1.1 :
http://www.scilab.org/download/index_download.php?page=CHANGES_5.1.1
The release notes :
http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_5.1.1
Pierre
Do I read the section titled "Scilab / Scipad synchronization bugs"
correctly? Does this mean that you got the debugger working again?
I've heard that you broke Scicos when you went to 5.x. Does it work again?
If you've got the debugger working and if it'll work on my
Ubuntu-powered laptop I can go back to Scilab from Scicoslab. I'm
looking forward to it.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
YC
> How can I choose german localization?
Under Linux/Unix/Mac Os X,
export LANG=de_DE
bin/scilab
Under Windows, use setdefaultlanguage()
http://www.scilab.org/product/man/setdefaultlanguage.html
and restart Scilab to update all the interface.
Sylvestre
I need to change user interface language?
Is there possible?
Thank you
It works
Well, since nobody answered your question in three days, let me do it.
Unfortunately the Scipad debugger is not working again. Worst, it will
never work in Scilab 5.
What comes out from discussions with the operational team of the
scilab consortium is that they have just no solution to fix what they
broke when they rewrote the Tcl interface and event loop for Scilab
5.0. This includes the debugger.
The last message of such discussions has been forwarded to the
development list and is recorded here:
http://lists.scilab.org/cgi-bin/ezmlm-browse?list=dev&cmd=showmsg&msgnum=1324
Further references are bug 2789 and pointers therein:
http://bugzilla.scilab.org/show_bug.cgi?id=2789
In short, for the future the plan of the opteam summarizes in 3 steps:
1. to fix the issues in the Scilab/Tcl issues created by the
rewriting process and that ended up in broking the "Load into Scilab"
command from Scipad. Thus a number of bug reports could be closed in
the bugzilla. I disagreed with the way this was fixed, especially
because the proposed fix did not address the broader case of the
debugger, but they went on anyway. This part of the plan is now over
and the fix is included in scilab 5.1.1 that was just released.
2. to not invest any effort in fixing the event loop and ScilabEval
Tcl command, which implies the debugger cannot be fixed.
3. to write a new editor in java. This editor is aimed at replacing
Scipad and is said to become available in Scilab 5.2. There is no
mention about whether this new editor will include a debugger or not.
Since ged is also planned to be rewritten in java there will be
virtually no remaining Tcl tool in scilab and one can infer that Tcl
as a whole will be thrown away from scilab at some point of time.
Let me state that I'm quite sad about this approach and that I regret
this situation very much. I don't think any U-turn is possible. I
tried quite hard to fix the design but I failed. I also tried to
discuss with the opteam but I failed as well.
> I've heard that you broke Scicos when you went to 5.x. Does it work again?
>
> If you've got the debugger working and if it'll work on my
> Ubuntu-powered laptop I can go back to Scilab from Scicoslab. I'm
> looking forward to it.
Scicoslab is the only maintained environment featuring the debugger.
Scicoslab-4.3 provides a reasonably recent version of Scipad (7.4.BP3
- 20/09/08) that includes all the latest major improvements of the
debugger (e.g. conditional breakpoints). If you want the debugger I
don't see any other possible choice.
Francois
Thank you for your answer.
That's a pity about the debugger. I have no particular attachment to
Tcl, but a debugger is a timesaver that goes well beyond convenience --
so a new editor with a working debugger works just as well for me as Scipad.
(Come to think of it -- if they're all editor-happy, why not just figure
out a way to integrate a Scilab session into Eclipse? That'll give them
a really nice editor with more features than any one of them would be
able to implement in a lifetime, at a low low price).
Of course, nobody of the OP team will answer this kind of questions. I
have thought for some time that the team became more open and
communicative with "ordinary" users. But now I realize that this seems
to have been wishful thinking.
> Unfortunately the Scipad debugger is not working again. Worst, it will
> never work in Scilab 5.
This is very bad news.
> What comes out from discussions with the operational team of the
> scilab consortium is that they have just no solution to fix what they
> broke when they rewrote the Tcl interface and event loop for Scilab
> 5.0. This includes the debugger.
>
> The last message of such discussions has been forwarded to the
> development list and is recorded here:http://lists.scilab.org/cgi-bin/ezmlm-browse?list=dev&cmd=showmsg&msg...
Reading that post gives me the idea that the scicoslab fork could have
happened in a similar way...
> In short, for the future the plan of the opteam summarizes in 3 steps:
>
> 1. to fix the issues in the Scilab/Tcl issues created by the
> rewriting process and that ended up in broking the "Load into Scilab"
> command from Scipad. Thus a number of bug reports could be closed in
> the bugzilla. I disagreed with the way this was fixed, especially
> because the proposed fix did not address the broader case of the
> debugger, but they went on anyway. This part of the plan is now over
> and the fix is included in scilab 5.1.1 that was just released.
>
> 2. to not invest any effort in fixing the event loop and ScilabEval
> Tcl command, which implies the debugger cannot be fixed.
>
> 3. to write a new editor in java. This editor is aimed at replacing
> Scipad and is said to become available in Scilab 5.2. There is no
> mention about whether this new editor will include a debugger or not.
> Since ged is also planned to be rewritten in java there will be
> virtually no remaining Tcl tool in scilab and one can infer that Tcl
> as a whole will be thrown away from scilab at some point of time.
>
> Let me state that I'm quite sad about this approach and that I regret
> this situation very much. I don't think any U-turn is possible. I
> tried quite hard to fix the design but I failed. I also tried to
> discuss with the opteam but I failed as well.
So it came true what was anticipated by Francois some time ago (http://
groups.google.com/group/comp.soft-sys.math.scilab/browse_thread/thread/
a2ae15933e5f3aa3/), and at that time denied by the Scilab team.
What a pity.
Scipad is a very nice piece of software, and namely the debugger is
most useful. Maybe even more important, the Scipad developpers were
very responsive - bug reports and feature requests were often done
overnight.
Thank you Francois and Enrico for your work and your willingness to
help users and continuously improve Scipad.
> Scicoslab is the only maintained environment featuring the debugger.
> Scicoslab-4.3 provides a reasonably recent version of Scipad (7.4.BP3
> - 20/09/08) that includes all the latest major improvements of the
> debugger (e.g. conditional breakpoints). If you want the debugger I
> don't see any other possible choice.
So I will continue using Scilab 4.1.2 as long as possible.
And if new features are relly needed, I'll check out Scicoslab.
Will Scipad continue to be maintained within Scicoslab?
Matthias
> Scipad is a very nice piece of software, and namely the debugger is
> most useful. Maybe even more important, the Scipad developpers were
> very responsive - bug reports and feature requests were often done
> overnight.
I misformulated - of course I wanted to say that bug reports and
feature requests were often _reacted to_ overnight!
> On Apr 17, 10:06 pm, Francois Vogel <fsvogelnew5NOS...@free.fr> wrote:
>> Tim Wescott said on 14/04/2009 19:26:
>> > Do I read the section titled "Scilab / Scipad synchronization
>> > bugs"
>>
>> > correctly? Does this mean that you got the debugger working again?
>>
>> Well, since nobody answered your question in three days, let me do it.
>
> Of course, nobody of the OP team will answer this kind of questions. I
> have thought for some time that the team became more open and
> communicative with "ordinary" users. But now I realize that this seems
> to have been wishful thinking.
We already communicate about this point here in the release notes:
http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_5.1.1
Btw, we are opening more and more ... but we prefer to communicate on the
Scilab' mailing list not the newsgroup... See the SEPs and so on.
About the "Scilab/Scipad synchronization" part in the Changelog, we fixed
a critical bug (which has been reported many time). You will find the
list of these bugs in the change file.
>> Unfortunately the Scipad debugger is not working again. Worst, it will
>> never work in Scilab 5.
>
> This is very bad news.
Indeed, we are not happy to see this feature broken but we are dealing
with pretty hard issues here.
Sylvestre
thank you for reacting.
On Apr 20, 12:20 pm, Sylvestre Ledru <sylvestre.le...@scilab.org>
wrote:
> We already communicate about this point here in the release notes:http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_...
You say there that the debugger will be "plugged back as soon as
possible".
There is no mention there that Scipad will be replaced.
> Btw, we are opening more and more ... but we prefer to communicate on the
> Scilab' mailing list not the newsgroup... See the SEPs and so on.
You are talking about the developper's list, right?
You know this discussion better than I do.
I have just noticed that there seems to be a sudden decision by the OP
team to throw away Scipad for Scilab 5.2. I do not know if there would
have been another solution. But it seems to me that this decision and
the way it was taken and communicated results in at least two very
frustrated external developpers, who have done a very good job and
devoted much time and effort to Scipad (and thereby also to Scilab).
> >> Unfortunately the Scipad debugger is not working again. Worst, it will
> >> never work in Scilab 5.
>
> > This is very bad news.
>
> Indeed, we are not happy to see this feature broken but we are dealing
> with pretty hard issues here.
I cannot argue on a technical level here, I just find the "solution"
to replace Scipad and frustrate its developpers most deplorable.
Matthias
> Hi Sylvestre,
>
> thank you for reacting.
You are welcome.
> On Apr 20, 12:20 pm, Sylvestre Ledru <sylvestre.le...@scilab.org> wrote:
>
>> We already communicate about this point here in the release
>> notes:http://www.scilab.org/download/index_download.php?
page=RELEASE_NOTES_...
>
> You say there that the debugger will be "plugged back as soon as
> possible".
> There is no mention there that Scipad will be replaced.
Scipad won't be replaced in the version 5.2. If new editor is equivalent
to Scipad in term of main features, we are going to change the "Editor"
item in the menu to the new one and leave scipad available in command
line. Anyway, Scipad will remain available in the future through ATOMS
(the future toolbox packaging system of Scilab).
Mainly for three reasons:
* This would enable the integration of the editor into the docking system
* We haven't been able to make Tk working under Mac OS X within the same
environnement (Mac OS X requires the use of CoreFoundation for the GUI
and the SWING and Tk seems to somehow conflict here). It is the reason
why Tclsci is deactivated under Mac OS X.
* Uniformalisation of the technologies
>> Btw, we are opening more and more ... but we prefer to communicate on
>> the Scilab' mailing list not the newsgroup... See the SEPs and so on.
>
> You are talking about the developper's list, right?
Yep.
> You know this discussion better than I do. I have just noticed that
> there seems to be a sudden decision by the OP team to throw away Scipad
> for Scilab 5.2. I do not know if there would have been another solution.
> But it seems to me that this decision and the way it was taken and
> communicated results in at least two very frustrated external
> developpers, who have done a very good job and devoted much time and
> effort to Scipad (and thereby also to Scilab).
Don't imagine that we enjoy this situation and it is everything but
sudden...
We do appreciate the quality, the skill and the involvement of François
as contributor.
Sylvestre
It maybe won't be replaced _in version 5.2_, but the decision not to
fix the broken debugger and also what you are saying above suggests
that you want to replace it in a later version.
> >> Btw, we are opening more and more ... but we prefer to communicate on
> >> the Scilab' mailing list not the newsgroup... See the SEPs and so on.
>
> > You are talking about the developper's list, right?
>
> Yep.
Well, as far as I can see, _this_ point has _not_ been discussed on
the list.
But it should have been discussed there.
I understand very well that Francois and Enrico are frustrated about
this way to communicate.
> Don't imagine that we enjoy this situation and it is everything but
> sudden...
> We do appreciate the quality, the skill and the involvement of François
> as contributor.
I am not saying that I don't believe you.
I guess that the present situation has its origins in the java choice,
and is now already next to unsolvable in a way everybody can live
with.
It would have been desirable to make a sincere effort to reconcile the
different positions and people. I am afraid that this effort has not
really been made, but of course as an "outsider" and simple user, I
cannot judge it and I am not in a position to do so.
We will see what the future will bring for Scilab, Scipad and
Scicoslab...
Matthias