[Scilab-users] Release Scilab 6.0.0 alpha 2
Dear Scilab users, We're happy to announce the recent release of the second alpha of Scilab 6.0.0, the next major release of Scilab. As an alpha, it is not yet ready for production usage. If you are new to Scilab, or only a casual user, you should probably continue using the 5.5.2 release, and wait for a beta version before trying the 6 family. However, if you maintain tools developed on Scilab, or rely on Scilab for your own developments, it is the right moment to look at it, in particular to evaluate the upgrade of toolboxes you have developed. Please see the release notes for details and download information. Also, please provide feedback via the mailing lists, and report bugs on the bug tracker. Thank you! François Granade francois.gran...@scilab-enterprises.com +33(0)1 80 77 04 60 http://www.scilab-enterprises.com - http://www.scilab.org ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] nightly builds of scilab 6 ?
hi Stéphane, We've (somewhat) fixed the website; the page http://www.scilab.org/development/nightly_builds/master now has the latest builds listed. Some are a few days old, and there are still other issues (the commit date seem to be wrong, as well as the size) -- but at least they are recent builds. It'll most likely continue to be this way... not perfect, but at least available... François Granade On Sep 16, 2015, at 5:05 PM, Antoine ELIAS <antoine.el...@scilab-enterprises.com> wrote: > Hello Stéphane, > > We have some troubles with documentation generation that prevent nightly > builds release. > I hope we can solve it quickly. > > Thank you for reporting > Antoine > > Le 16/09/2015 14:46, Stéphane Mottelet a écrit : >> Hello, >> >> When will be recent nighty builds of Scilab 6 available ? Some important >> bugs have been fixed since the alpha version so it would be nice to benefit >> from these fixes. >> >> S. >> > > > -- > Antoine ELIAS > Software developer > --- > Scilab Enterprises > 143bis rue Yves Le Coz - 78000 Versailles > Phone: 01.80.77.04.70 > http://www.scilab-enterprises.com > > ___ > users mailing list > users@lists.scilab.org > http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
Re: [Scilab-users] threading model in Scilab 6 (alpha)
hi Jasper,
Yes, we made a decision - and in fact we implemented it already: and we changed
it to be simply always use the same thread. That should work for you, right ?
Regarding your other question (api scilab): I believe that there is string
support for cpp (we implemented it), however this is still in development, and
may still change before the release...
François Granade
On Sep 3, 2015, at 4:51 PM, jasper van baten <jas...@amsterchem.com> wrote:
> Hi François,
>
> Is there a decision on the threading model yet?
>
> Many thanks, best wishes,
>
> Jasper.
>
> On 8/5/2015 10:44, jasper van baten wrote:
>> Hi François,
>>
>> Many thanks for your reply. As soon as you know more, I would be very
>> pleased to test again in a new alpha. I would like to have my software back
>> up-and-running before the actual release of Scilab 6. Before doing so I will
>> have to decide how to handle the threading issue.
>>
>> If the solution will be that all is single threaded but in different
>> threads, I suppose my best work-around would still be to synchronize access
>> to the underlying objects over a private thread. I hope you will decide to
>> keep the core thread alive and recycle it between calls, so that all calls
>> are made on the same thread.
>>
>> If on the other hand your solution will be full multi-threaded execution, I
>> would welcome that too. Also in this case I hope you will create a fixed
>> number of threads and recycle them, for the same reason. In this case I can
>> simply create a corresponding number of COM objects under the hood.
>>
>> I am not sure why events from outside the thread would have to make that you
>> stop the thread and start another one (unless you forcefully terminate the
>> thread, but I suppose you do not as this will surely lead to memory leaks
>> and other trouble). You can simply set up your calculation thread to do
>> something like
>>
>> void core_threadproc() {
>>
>> for (;;) {
>> //wait until next command
>> synchronizationObject.wait();
>> //pick up next (set of) command(s) and execute
>> if (nextCommand==CommandTerminate()) break;
>> ...
>>
>> }
>>
>> }
>>
>> For interrupting calculations you could poll between individual commands and
>> during length commands.
>>
>> On another note: removal of the intersci exe forced me to switch to the
>> api-scilab (short of keeping previous builds of scilab around). I am pleased
>> with this interface, it is a lot nicer than intersci. The C++ interface is
>> nicer than the C interface, I think, but does not seem to have support for
>> strings and some other data types (unless I missed something). So I am now
>> mixing my approach: "csci" interfaces for all routines that take string
>> matrices as in- our output, and "cppsci" interfaces for all routines that
>> only deal with numeric matrices. Support for string (and other) data types
>> from the cppsci interface would be welcome in the future.
>>
>> Best wishes,
>>
>> Jasper
>>
>>
>>
>> On 8/5/2015 10:21, François Granade wrote:
>>> Hi Jasper,
>>>
>>> Looks like you have found an interesting question here...
>>>
>>> First - there are no multiple concurrent threads in the core. So we are
>>> safe (and so is the API, without being thread-safe).
>>>
>>> However, what you saw is right: each command executes in a new thread. We
>>> designed it on purpose, with one of the reason being that this thread can
>>> be what we call the "storeCommand" which manages events from outside the
>>> main thread (UI, interruption). Another idea was that - later - to allow
>>> multithreaded execution (under some serious constraints).
>>>
>>> Now, your point about COM loading, and thread-local storage, is very valid,
>>> and may very well mean that we should change this.
>>>
>>> We will study if/how we could modify that... we'll keep you posted.
>>>
>>> Thanks *a lot* for reporting this; it's exactly what we released the alpha
>>> for, and even though we were hoping we would not have such questions, it's
>>> better to have them now than later...
>>>
>>> for the Scilab team,
>>> François Granade
>>>
>>>
>>>
>>> On Aug 4, 2015, at 9:21 AM, jasper van baten <jas...@amsterchem.com> wrote:
>>>
>>>> Does anybody know what threading
Re: [Scilab-users] threading model in Scilab 6 (alpha)
Hi Jasper, Looks like you have found an interesting question here... First - there are no multiple concurrent threads in the core. So we are safe (and so is the API, without being thread-safe). However, what you saw is right: each command executes in a new thread. We designed it on purpose, with one of the reason being that this thread can be what we call the storeCommand which manages events from outside the main thread (UI, interruption). Another idea was that - later - to allow multithreaded execution (under some serious constraints). Now, your point about COM loading, and thread-local storage, is very valid, and may very well mean that we should change this. We will study if/how we could modify that... we'll keep you posted. Thanks *a lot* for reporting this; it's exactly what we released the alpha for, and even though we were hoping we would not have such questions, it's better to have them now than later... for the Scilab team, François Granade On Aug 4, 2015, at 9:21 AM, jasper van baten jas...@amsterchem.com wrote: Does anybody know what threading model is used in Scilab 6 alpha? I am referring to the default mode of operation, and not while executing parallel_for, or MPI as described here (http://wiki.scilab.org/Documentation/ParallelComputingInScilab). If there are multiple core threads that execute concurrently, then all api-scilab code needs to be written in a thread-safe re-entrant safe manner. I doubt this is the case. If there is one core thread alive at any point, it would make sense for this to remain the same thread, which does not appear to be the case. If not the same thread, any application that depends on apartment threaded COM objects or thread local storage will no longer function as it did in Scilab 5. The solution may be to synchronize such applications over a private thread, but that surely will come at a performance cost. Having some idea about the threading model that is intended and used would be helpful. Best wishes, Jasper. On 7/31/2015 18:35, jasper van baten wrote: All, What's the story with threading in Scilab 6? Whereas previous versions appeared to be single threaded from an external DLL point of view, I see that the DLLmain function gets called by a one thread, whereas interface routines get called from another thread. Worse, looks like each interface routine call is made from a new thread. What is the threading model?? Is there a limited number of threads, or are threads created on the fly? Thanks, best wishes, Jasper ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users ___ users mailing list users@lists.scilab.org http://lists.scilab.org/mailman/listinfo/users
