From simon.lipp at scilab.org Mon Sep 1 09:47:47 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 09:47:47 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> References: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901094747.44976619@caprera.inria.fr> > I was probably misapplying the patch. FWI, from revision 27087, you don't have to apply any patch. > /usr/share/scilab/modules/gui/.libs/libscigui.so.5: undefined > reference to > `org_scilab_modules_gui_bridge::CallScilabBridge::getFontChooserItalic(JavaVM_*, > long)' You aren't compiling from a clean tree, are you ? Try with "make clean all". From enrico.segre at weizmann.ac.il Mon Sep 1 10:44:39 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 11:44:39 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901094747.44976619@caprera.inria.fr> References: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> <20080901094747.44976619@caprera.inria.fr> Message-ID: <48BBAB77.1050601@weizmann.ac.il> Simon Lipp wrote: > You aren't compiling from a clean tree, are you ? Try with "make clean > all". > Correct. Indeed with make clean all I could compile (without help, I have to care for docbook). Now at least I can get again # SIGSEGV (0xb) at pc=0x00002aaaac12c294, pid=18007, tid=46912666758288 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode linux-amd64) # Problematic frame: # C [libscicore.so.5+0x67294] intglobal_+0x504 At the fourth attempt the gui opens. Another apparently harmless problem with configure, btw: rm: cannot remove `core': Is a directory repeated several times. Thanks, Enrico From enrico.segre at weizmann.ac.il Mon Sep 1 10:47:39 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 11:47:39 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901094747.44976619@caprera.inria.fr> References: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> <20080901094747.44976619@caprera.inria.fr> Message-ID: <48BBAC2B.6070005@weizmann.ac.il> ah, and I got also # Problematic frame: # C [libc.so.6+0x7a58a] which I think is new. And a crash running the demo introduction. Well... From enrico.segre at weizmann.ac.il Mon Sep 1 10:49:56 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 11:49:56 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901094747.44976619@caprera.inria.fr> References: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> <20080901094747.44976619@caprera.inria.fr> Message-ID: <48BBACB4.3080502@weizmann.ac.il> and # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode linux-amd64) # Problematic frame: # C [libscigui.so.5+0x1933b] sci_messagebox+0x1cb From simon.lipp at scilab.org Mon Sep 1 10:56:29 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 10:56:29 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <48BBAB77.1050601@weizmann.ac.il> References: <1220176217.30566.13.camel@segre-pc2.weizmann.ac.il> <20080901094747.44976619@caprera.inria.fr> <48BBAB77.1050601@weizmann.ac.il> Message-ID: <20080901105629.0f46beb7@caprera.inria.fr> What's the result of: egrep 'IS_64_BITS_CPU|USE_DYNAMIC_STACK' modules/core/includes/machine.h From bruno.jofret at inria.fr Mon Sep 1 11:21:50 2008 From: bruno.jofret at inria.fr (Bruno JOFRET) Date: Mon, 01 Sep 2008 11:21:50 +0200 Subject: [Scilab-Dev] Re: bug debugguer scipad,... In-Reply-To: <48BAF845.8010003@free.fr> References: <48B8F0D6.809@inria.fr> <48BAF845.8010003@free.fr> Message-ID: <48BBB42E.2010108@inria.fr> Hi there, After some discussion with Serge (and some mysterious BUG showing off under windows with the last modification) we decided to revert the GetCommandLine to previous version. But it is only during the time we need to Tag the 5.0 version. I will do the commit back right after the tag. It is a very good step for the resolution of our problems but not safe enough with the close deadline of Scilab 5.0. Regards, Fran?ois Vogel a ?crit : > Serge, > > Many thanks for looking at this thorny problem. New eyes on a muddy > problem proves efficient, well done. > > It seems that you have indeed made a good step forward. Now the debugger > is no longer locked. Well, at least most of the time. > > Sometimes the user still has to hit enter in the Scilab shell in order > to make things move, but definitely you have made progress. > > Example that almost works: > > 1. Launch Scilab > > 2. Launch Scipad. > > 3. Now, after Scipad is open: > > TCL_EvalStr("set bug2789_fixed true","scipad") > > (this will unlock the debugger - I had locked it two days ago in r27121 > upon opteam request) > > 4. Paste this in scipad: > > function stupid > a=1 > b=2 > endfunction > > 5. Configure (F10) and click OK. > > 6. Step in (F8). > ----> The debugger correctly goes into DebugInProgress mode (red tag > on the lower left of Scipad window). However, the active breakpointed > line does not show up. > > 7. Hit enter in the Scilab shell (this should not be needed if it would > work correctly). > ----> The current stop point is shown in Scipad. > > 8. F8 again > ----> The new stop point is shown > > etc. > > > Try with other examples, perhaps a bit more complicated, you will see > that it often works but not always. Sometimes you need to hit enter in > the shell to make things move. > > > I have also experienced a number of crashes, where Scilab unexpectedly > closes with no message at all. > Also: > Warning !!! > Scilab has found a critical error (EXCEPTION_ACCESS_VIOLATION) > with "TCL_EvalStr" function. > Save your data and restart Scilab. > > > Finally, for the debuggger to work OK, bug 1469 and 3407 should be fixed > too. There are still many problems with continued lines, that were > counted differently in 4.x than they are now in 5.0 > > > As a conclusion I think we are still not fully OK, but progress is > clear. A lot of testing and bug fixing will be needed in the next days > if the debugger is to be replugged. Please let me know what you think > and what is your plan with respect to the upcoming Scilab 5. > > Francois > > > Serge Steer said on 30/08/2008 09:03: >> Je pense avoir corrige le bug qui empechait le debugguer de scipad de >> fonctionner et qui faisait que dans certains cas scilab se mettait a >> boucler avec l'execution d'un callback >> >> zzledt (GetCommandLine.c) ne signifiait pas que la lecture a ete >> interrompu par la presence d'un callback dans la queue et retournait une >> ligne blanche comme instruction. >> >> voir la modif que j'ai committe dans modules/shell/GetCommandLine.c >> >> Serge >> >> -- Bruno JOFRET Software Designer ___ SCILAB - DIGITEO ___ Tel : (+33/0)1.39.63.58.63 Mailto : bruno.jofret at scilab.org http://www.scilab.org http://www.digiteo.fr From enrico.segre at weizmann.ac.il Mon Sep 1 11:40:33 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 12:40:33 +0300 Subject: linux 64 bits support Message-ID: <1220262033.8220.0.camel@segre-pc2.weizmann.ac.il> > What's the result of: > egrep 'IS_64_BITS_CPU|USE_DYNAMIC_STACK' modules/core/includes/machine.h #define IS_64_BITS_CPU From simon.lipp at scilab.org Mon Sep 1 11:51:39 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 11:51:39 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220262033.8220.0.camel@segre-pc2.weizmann.ac.il> References: <1220262033.8220.0.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901115139.4fad011f@caprera.inria.fr> You should have #define USE_DYNAMIC_STACK, then. Try: rm -f modules/core/includes/machine.h && ./config.status If it still doesn't work, try rm -f modules/core/includes/machine.h modules/core/includes/machine.h.in && autoheader and relaunch the configure script (a simpler way is to restart from a clean tree ;)) From vincent.couvert at scilab.org Mon Sep 1 12:07:23 2008 From: vincent.couvert at scilab.org (Vincent COUVERT) Date: Mon, 01 Sep 2008 12:07:23 +0200 Subject: [Scilab-Dev] Re: Scipad debugger In-Reply-To: <48B872BA.9060709@free.fr> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48B872BA.9060709@free.fr> Message-ID: <48BBBEDB.9000905@scilab.org> Fran?ois Vogel a ?crit : > Vincent COUVERT said on 29/08/2008 10:42: >>> 1. Deactivation of Scipad's debugger >>> What is the last date for commit in trunk before Scilab 5? > >> No problem for me to let you do this work. >> The last date for commit in TRUNK before Scilab 5 is next Monday (1st >> September) at 12am. > > Done (Scipad 6.155). > > The last thing I plan to do on Monday morning before the deadline is > to push the Scipad version tag to 7.0 for distribution with Scilab 5. > I will take care of this too. > Thank you for your work. > >> We are going to update this page and explain what work and what does >> not work. > > Thanks. Please proceed. > > >> A diagram explaining how the TCL thread works is currently written. > > Seen. I still have to analyze it more in depth but thank you anyway > for the documentation effort. > > >> The modifications to do in "Scilab debugging system" could be the >> object of a new SEP. > > Yes, certainly. However, before writing a SEP we should know what the > problem is more precisely, and identify a solution, as you mentioned. > So a SEP, yes, but only later because I wouldn't know what to write > there right now. > > >> For the moment, no idea of the version where debugging actions will >> be available again. It will depend on the amount of work needed to >> make it work. > > Of course, but it's also a matter of priorities. What are your > priorities after Scilab 5.0 release? > > What I really mean is: Do you think Scilab 5.1 is a realistic target? > The roadmap on your website says "a minor version every 9 months", > which is already a huge delay (in my opinion) for fixing the debugger. > > What I fear is that you want to delay this up to Scilab 6 because you > seem to say that part of the problem is in the parser, and this parser > will be rewritten for Scilab 6. Since Serge has found a solution that fix some of the broken functionalities of Scilab debugger, I think that Scilab 5.1 is a realistic target. We plan to reduce the delay between our minor versions and then plan a 5.1 version for next December where Scipad debugger will be fully functional and where many bugs will be fixed. What do you think about it ? Vincent > > Francois -- ============================================== Vincent COUVERT Centre de Recherche INRIA Paris-Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex ============================================== Equipe Projet SCILAB B?timent 1B - Bureau 013 Email : vincent.couvert at inria.fr T?l : +33 (0)1 39 63 54 46 Fax : +33 (0)1 39 63 55 94 ============================================== From bruno.jofret at scilab.org Mon Sep 1 12:13:29 2008 From: bruno.jofret at scilab.org (Bruno JOFRET) Date: Mon, 01 Sep 2008 12:13:29 +0200 Subject: [Scilab-Dev] TCl-thread graphs In-Reply-To: <48BA632B.4010908@weizmann.ac.il> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48BA632B.4010908@weizmann.ac.il> Message-ID: <48BBC049.7020205@scilab.org> Hi Enrico, > [...] > > Anyway, first question, about the new (at least!) flowcharts in > http://wiki.scilab.org/Tcl_Thread : the various boxes of the state > machines have some functional characterization besides their numerical > labels? No, no there is no hidden feature or whatsoever besides the numerical labels. This is only the grafcet standard that force you to add some label among states. Here you can find some information about this standard : http://fr.wikipedia.org/wiki/Grafcet (Sorry it's in french but I have not found a similar one in english) > With what were the graphs produced, in case we want to suggest, > graphically, new structures? Though I understand it, I'm not familiar > with the graphical notation of the flowcharts currently on wiki; could > you send me a pointer for the scheme (I guess it is a standard one) used? > > Not seeing these graphs, I was once considering to produce them with > graphviz, decoding the previous content of the wiki page. I stopped at > some point for lack of time, but for reference I attach what I managed > to do (certainly unfinished and with errors, but possibly a little more > descriptive?). > > Enrico Hope with the help of the pointer it will appear less obscure. I will soon add the last missing part "sendCommandToSlave" that will complete the all process. Regards, -- Bruno JOFRET Software Designer ___ SCILAB - DIGITEO ___ Tel : (+33/0)1.39.63.58.63 Mailto : bruno.jofret at scilab.org http://www.scilab.org http://www.digiteo.fr From enrico.segre at weizmann.ac.il Mon Sep 1 12:19:29 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 13:19:29 +0300 Subject: linux 64 bits support Message-ID: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> > You should have #define USE_DYNAMIC_STACK, then. Try: > rm -f modules/core/includes/machine.h && ./config.status > > If it still doesn't work, try I miss: -what- doesn't work? That I see #define USE_DYNAMIC_STACK in machine.h? > rm -f modules/core/includes/machine.h > modules/core/includes/machine.h.in && autoheader > and relaunch the configure script did both and have still egrep 'IS_64_BITS_CPU|USE_DYNAMIC_STACK' modules/core/includes/machine.h #define IS_64_BITS_CPU or? I'll try adding the #define at hand and recompile; should that remove the SIGSEGVs, or am I misunderstanding? Enrico From simon.lipp at scilab.org Mon Sep 1 12:55:53 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 12:55:53 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901125553.6e51f929@caprera.inria.fr> At the end of machine.h and machine.h.in you should have: /* Force usage of dynamically located stack on 64 bits */ #ifdef IS_64_BITS_CPU #define USE_DYNAMIC_STACK #endif > I'll try adding the #define at hand and recompile; should that remove > the SIGSEGVs, or am I misunderstanding? Normally, you don't have to add it manually... The modification in machine.h.in is in the patch (or current trunk) ; the machine.h file is generated by the configure script. So, if regenerating machine.h didn't solved the problem, that's probably because machine.h.in has not been patched properly. Revert the patch, sync with trunk & reconfigure. From sylvestre.ledru at scilab.org Mon Sep 1 13:13:01 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 01 Sep 2008 13:13:01 +0200 Subject: [Scilab-Dev] Re: bug debugguer scipad,... In-Reply-To: <48BAF845.8010003@free.fr> References: <48B8F0D6.809@inria.fr> <48BAF845.8010003@free.fr> Message-ID: <1220267581.3832.17.camel@korcula.inria.fr> > As a conclusion I think we are still not fully OK, but progress is > clear. A lot of testing and bug fixing will be needed in the next days > if the debugger is to be replugged. Not only in the debugger, this modification causes an infinite loop when trying to build the doc under Linux. Sylvestre From enrico.segre at weizmann.ac.il Mon Sep 1 13:50:50 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 14:50:50 +0300 Subject: [Scilab-Dev] TCl-thread graphs In-Reply-To: <48BBC049.7020205@scilab.org> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48BA632B.4010908@weizmann.ac.il> <48BBC049.7020205@scilab.org> Message-ID: <48BBD71A.8030900@weizmann.ac.il> > This is only the grafcet standard that force you to add some label > among states. > Here you can find some information about this standard : > http://fr.wikipedia.org/wiki/Grafcet ah, grafcet. Francois prompted it to me when we were considering to draw the flowcharts ourselves, then I pushed for graphviz. Understood, thanks. Enrico From enrico.segre at weizmann.ac.il Mon Sep 1 14:09:22 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 15:09:22 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901125553.6e51f929@caprera.inria.fr> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> <20080901125553.6e51f929@caprera.inria.fr> Message-ID: <48BBDB72.2040002@weizmann.ac.il> Simon Lipp wrote: > At the end of machine.h and machine.h.in you should have: > > /* Force usage of dynamically located stack on 64 bits */ > #ifdef IS_64_BITS_CPU > #define USE_DYNAMIC_STACK > #endif > this I understand; indeed I had a conflicting machine.h.in (result probably of my previous patch attempts), so the part was not included. Anyway, the single #define USE_DYNAMIC_STACK I added at hand in machine.h should have been equipotent. Now the inclusion above is automatic, so far so good. But what should I have gained? less SIGSEGVS? One # Problematic frame: # C [libscigui.so.5+0x1933b] sci_messagebox+0x1cb I've just reproduced. A side question: does the scicos module support make -j ? I see the compilation load drop to 1 cpu when make enters that directory. Enrico From sylvestre.ledru at scilab.org Mon Sep 1 14:18:25 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 01 Sep 2008 14:18:25 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <48BBDB72.2040002@weizmann.ac.il> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> <20080901125553.6e51f929@caprera.inria.fr> <48BBDB72.2040002@weizmann.ac.il> Message-ID: <1220271505.3832.50.camel@korcula.inria.fr> > Now the inclusion above is automatic, so far so good. But what should I have gained? less SIGSEGVS? > One > # Problematic frame: > # C [libscigui.so.5+0x1933b] sci_messagebox+0x1cb > I've just reproduced. Could you send your hs_*log file ? > > A side question: does the scicos module support make -j ? I see the > compilation load drop to 1 cpu when make enters that directory. It doesn't (bien vu ;). The reason is pretty simple. In this module, we are building sundials (Yes, I know it is bad) + Scicos. Obviously, Scicos needs sundials to work. The problem with the parallel make in this case is that I must guarantee that libsundials is built before libscicos. Therefore, I must say that they cannot be built in the meantime [1]. There is probably a way of saying "please, could you built sundials before libscicos but do it in parallel" in automake but I don't have time to look into. Sylvestre [1] Makefile.am: .NOTPARALLEL: libscisundials.la libsciscicos.la From simon.lipp at scilab.org Mon Sep 1 14:20:01 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 14:20:01 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <48BBDB72.2040002@weizmann.ac.il> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> <20080901125553.6e51f929@caprera.inria.fr> <48BBDB72.2040002@weizmann.ac.il> Message-ID: <20080901142001.5cfd20f3@caprera.inria.fr> > I added at hand in machine.h should have been equipotent. Yes... if no other merges had problems. For example, do you have integer, pointer :: stack_reserved_for_c__ in modules/core/includes/stack.h ? (but a SIGSEGV in sci_messagebox is not unbelievable, gui and graphics modules loves to store pointers in integers, and I don't think I found all of these. How do you reproduce it ?) From enrico.segre at weizmann.ac.il Mon Sep 1 14:24:43 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 15:24:43 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220271505.3832.50.camel@korcula.inria.fr> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> <20080901125553.6e51f929@caprera.inria.fr> <48BBDB72.2040002@weizmann.ac.il> <1220271505.3832.50.camel@korcula.inria.fr> Message-ID: <48BBDF0B.4070901@weizmann.ac.il> Sylvestre Ledru wrote: >> Now the inclusion above is automatic, so far so good. But what should I have gained? less SIGSEGVS? >> One >> # Problematic frame: >> # C [libscigui.so.5+0x1933b] sci_messagebox+0x1cb >> I've just reproduced. >> > Could you send your hs_*log file ? > is there an implied sarcasm in using the singular form? :) Here are a few of the last ones. -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid844.log Type: text/x-log Size: 64273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid704.log Type: text/x-log Size: 71499 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid18169.log Type: text/x-log Size: 64353 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid18115.log Type: text/x-log Size: 64579 bytes Desc: not available URL: From enrico.segre at weizmann.ac.il Mon Sep 1 14:44:54 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 15:44:54 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901142001.5cfd20f3@caprera.inria.fr> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il><20080901125553.6e51f929@caprera.inria.fr><48BBDB72.2040002@weizmann.ac.il> <20080901142001.5cfd20f3@caprera.inria.fr> Message-ID: <48BBE3C6.7000308@weizmann.ac.il> Simon Lipp wrote: >> I added at hand in machine.h should have been equipotent. >> > Yes... if no other merges had problems. For example, do you have > integer, pointer :: stack_reserved_for_c__ in > modules/core/includes/stack.h ? > Right, more conflicts due to my previous patch attempt discovered. This one was missing to. Well, now I erased all */*/*/*.../*.in, sanitized around and rechecked out, but I'm back to where I was yersterday (before patch): configure ... checking whether g77 understands -c and -o together... yes configure: error: 64 bits support needs a fortran 90 compiler. Might be very well my dirty local copy, but are you 100% sure that something of the patch hasn't been left out in the svn commit? I'm a little resilient to create a fresh checkout still, because I don't want, again, to have to reconstruct what goes where in thirdparty/ (x64). > (but a SIGSEGV in sci_messagebox is not unbelievable, gui and graphics > modules loves to store pointers in integers, and I don't think I found > all of these. How do you reproduce it ?) > # Problematic frame: # C [libscigui.so.5+0x1933b] sci_messagebox+0x1cb with demos/GUI/dialog and sometimes some click. (last working build, with no stack_reserved_for_c__, so possibly flawed). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid1283.log Type: text/x-log Size: 69221 bytes Desc: not available URL: From simon.lipp at scilab.org Mon Sep 1 14:58:19 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 14:58:19 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <48BBE3C6.7000308@weizmann.ac.il> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il> <20080901125553.6e51f929@caprera.inria.fr> <48BBDB72.2040002@weizmann.ac.il> <20080901142001.5cfd20f3@caprera.inria.fr> <48BBE3C6.7000308@weizmann.ac.il> Message-ID: <20080901145819.5cf53534@caprera.inria.fr> > but are you 100% sure that > something of the patch hasn't been left out in the svn commit? Yes :) I work with git. The patch is generated with git, the merge in the trunk is done than git. And git is more reliable than me ;) Moreover, one person here (Simone) successfully built and run current trunk on its 64 bits machine. > I don't want, again, to have to reconstruct what goes where in > thirdparty/ Sorry if it sounds stupid, but you just have to make a backup of this folder, isn't it ? (I totally forgot how to use properly svn, but there's no way to tell to svn to clean all the crud to make the working copy exactly like the current revision ?) > checking whether g77 understands -c and -o together... yes > configure: error: 64 bits support needs a fortran 90 compiler. We use AC_PROG_F77, perhaps it's related to this, I'll investigate that. Right now, please try with --with-gfortran. From enrico.segre at weizmann.ac.il Mon Sep 1 15:18:09 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 16:18:09 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901145819.5cf53534@caprera.inria.fr> References: <1220264369.8220.5.camel@segre-pc2.weizmann.ac.il><20080901125553.6e51f929@caprera.inria.fr><48BBDB72.2040002@weizmann.ac.il><20080901142001.5cfd20f3@caprera.inria.fr><48BBE3C6.7000308@weizmann.ac.il> <20080901145819.5cf53534@caprera.inria.fr> Message-ID: <48BBEB91.4020102@weizmann.ac.il> Simon Lipp wrote: >> I don't want, again, to have to reconstruct what goes where in >> thirdparty/ >> > Sorry if it sounds stupid, but you just have to make a backup of this > folder, isn't it ? > naa, too complicate. >> checking whether g77 understands -c and -o together... yes >> configure: error: 64 bits support needs a fortran 90 compiler. >> > We use AC_PROG_F77, perhaps it's related to this, I'll investigate > that. Right now, please try with --with-gfortran. > good guess, --with-gfortran (never needed so far) at least configure completes normally. Currently building again, will tell you with what progress. Enrico From sylvestre.ledru at scilab.org Mon Sep 1 15:35:49 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 01 Sep 2008 15:35:49 +0200 Subject: [Scilab-Dev] To be able to develop Scilab interface in C++ In-Reply-To: <48B827C3.8050504@freesurf.fr> References: <1220010927.3592.305.camel@korcula.inria.fr> <48B827C3.8050504@freesurf.fr> Message-ID: <1220276149.3832.100.camel@korcula.inria.fr> Le vendredi 29 ao?t 2008 ? 18:45 +0200, Collette Yann a ?crit : > Hello, > > I was thinking about something else. > First add some #ifdef to allows the compilation of a C++ interface via > g++. I found that it was necessary to remove some cast to void * in > CreateVar and to declare the main function as extern "C". > if you compile a C++ scilab interface via g++, g++ emit some warnings > related to cast from strings to char * which are deprecated. So, soon, > it will not be possible to compile using g++. > But my idea was to develop a "real" C++ interface like the one from octave. OK, then, a better name would be a Scilab C++ API. Isn't it? ;) Cheers, Sylvestre From enrico.segre at weizmann.ac.il Mon Sep 1 15:41:39 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 16:41:39 +0300 Subject: linux 64 bits support Message-ID: <1220276499.8220.14.camel@segre-pc2.weizmann.ac.il> Result: Apparently: # SIGSEGV (0xb) at pc=0x00002aaaac1019b6, pid=32377, tid=46912664280032 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0-b19 mixed mode linux-amd64) # Problematic frame: # C [libscicore.so.5+0x5a9b6] inisci_+0x2c6 hs_err attached. btw > Another apparently harmless problem with configure, btw: > > rm: cannot remove `core': Is a directory > > repeated several times. this one a local problem too, due to a wrong patch -p attempt of mine - a core/ directory created at the wrong level. -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid32377.log Type: text/x-log Size: 67146 bytes Desc: not available URL: From simon.lipp at scilab.org Mon Sep 1 16:11:35 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 16:11:35 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220276499.8220.14.camel@segre-pc2.weizmann.ac.il> References: <1220276499.8220.14.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901161135.1b64cdcd@caprera.inria.fr> Attached files are the key files for 64 bits support, double check that they are the same... and that scimem64.c relocstack.f are really compiled (conditionnal compilation) -------------- next part -------------- A non-text attachment was scrubbed... Name: machine.h Type: text/x-chdr Size: 12603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stack.h Type: text/x-chdr Size: 3132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stack-def.h Type: text/x-chdr Size: 10058 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scimem.c Type: text/x-csrc Size: 2708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scimem64.c Type: text/x-csrc Size: 3922 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inisci.f Type: application/octet-stream Size: 9508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: relocstack.f Type: application/octet-stream Size: 1046 bytes Desc: not available URL: From enrico.segre at weizmann.ac.il Mon Sep 1 17:26:44 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 18:26:44 +0300 Subject: linux 64 bits support Message-ID: <1220282804.15583.6.camel@segre-pc2.weizmann.ac.il> > Attached files are the key files for 64 bits support, double check that > they are the same... and that scimem64.c relocstack.f are really > compiled (conditionnal compilation) tomorrow, perhaps. By now I arranged a clean checkout with thirdparty/ + the necessary jogl & C .so in bin/. I can compile neatly, get a slightly more stable scilab gui (opens at first attempt), which I'm able to crash anyway with little effort. I have seen so far # Problematic frame: # C [libc.so.6+0x78350] strlen+0x30 # Problematic frame: # C [libscigui.so.5+0x2da45] _ZN29org_scilab_modules_gui_bridge16CallScilabBridge20setMessageBoxMessageEP7JavaVM_iPPci+0x105 # Problematic frame: # C [libscigui.so.5+0x193cb] sci_messagebox+0x1cb Besides, I would like to understand where the hell to put docbook in order to compile the help. --with-docbook=/usr/share/xml/docbook is apparently not it, maybe I don't even have the right package. Anyway, later on. Thanks so far for the assistance, Enrico ________________________________________________________________________ From sylvestre.ledru at scilab.org Mon Sep 1 17:28:01 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 01 Sep 2008 17:28:01 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220282804.15583.6.camel@segre-pc2.weizmann.ac.il> References: <1220282804.15583.6.camel@segre-pc2.weizmann.ac.il> Message-ID: <1220282881.3832.119.camel@korcula.inria.fr> Le lundi 01 septembre 2008 ? 18:26 +0300, Enrico Segre a ?crit : > > > Besides, I would like to understand where the hell to put docbook in > order to compile the help. --with-docbook=/usr/share/xml/docbook is > apparently not it, maybe I don't even have the right package. Anyway, > later on. What is the result of `locate javahelp.xsl` ? Under debian/ubuntu, the name of the package is docbook-xsl Sylvestre From enrico.segre at weizmann.ac.il Mon Sep 1 17:50:11 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Mon, 01 Sep 2008 18:50:11 +0300 Subject: linux 64 bits support Message-ID: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> > What is the result of `locate javahelp.xsl` ? /usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/javahelp/javahelp.xsl /usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/javahelp/profile-javahelp.xsl > Under debian/ubuntu, the name of the package is docbook-xsl rpm -qa | grep docbook docbook-style-xsl-1.69.1-5.1 docbook-simple-1.0-2.1.1 docbook-dtds-1.0-30.1 docbook-style-dsssl-1.79-4.1 docbook-utils-0.6.14-5.1 rpm -qa | grep xsl docbook-style-xsl-1.69.1-5.1 libxslt-python-1.1.17-2.el5_2.2 libxslt-1.1.17-2.el5_2.2 openoffice.org-xsltfilter-2.4.1-9310 libxslt-1.1.17-2.el5_2.2 libxslt-devel-1.1.17-2.el5_2.2 From simon.lipp at scilab.org Mon Sep 1 18:42:29 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 18:42:29 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220282804.15583.6.camel@segre-pc2.weizmann.ac.il> References: <1220282804.15583.6.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901184229.146c98f9@caprera.inria.fr> I can confirm the last one -- yet another damn "let's store a pointer into an integer" *sigh*. Fixed in r27178. To see if your scilab is as stable as mine, run: test_run(['string','data_structures','fileio','elementary_functions','m2sci',.. 'statistics','io','time','genetic_algorithms','integer','double','randlib',.. 'differential_equations','simulated_annealing','special_functions','sparse',.. 'parameters','overloading','output_stream','completion','boolean','arnoldi',.. 'symbolic','spreadsheet','data_structures','interpolation','javasci',.. 'sound','compatibility_functions','polynomials','linear_algebra','functions',.. 'signal_processing','matio','graphic_export','fftw','metanet','localization',.. 'umfpack','scicos']); You should have zero segfault. Zero errors except the tests which are using getmemory (getmemory is unreliable on linux) If so, if you find any bug, please send me the backtrace (so, don't forget ulimit -c unlimited before running scilab). I'll see tomorrow if I can find an automatic way to find most of these bugs. Simon From simon.lipp at scilab.org Mon Sep 1 19:18:37 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Mon, 1 Sep 2008 19:18:37 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> References: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> Message-ID: <20080901191837.3996a2b8@caprera.inria.fr> /usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/javahelp/javahelp.xsl then --with-docbook=/usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1 Simon From enrico.segre at weizmann.ac.il Tue Sep 2 08:20:28 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Tue, 02 Sep 2008 09:20:28 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901161135.1b64cdcd@caprera.inria.fr> References: <1220276499.8220.14.camel@segre-pc2.weizmann.ac.il> <20080901161135.1b64cdcd@caprera.inria.fr> Message-ID: <48BCDB2C.3040602@weizmann.ac.il> Simon Lipp wrote: > Attached files are the key files for 64 bits support, double check that > they are the same... V inisci.f V relocstack.f V scimem.c V scimem64.c V stack.h V stack-def.h machine.h: --- /usr/share/scilab/modules/core/includes/machine.h 2008-09-01 16:56:05.000000000 +0300 +++ /data/enrico/Desktop/sci64/machine.h 2008-09-02 08:58:09.000000000 +0300 @@ -123,10 +123,10 @@ #define HAVE_MALLOC_H 1 /* Define to 1 if you have the header file. */ -/* #undef HAVE_MATIOCONFIG_H */ +#define HAVE_MATIOCONFIG_H 1 /* Define to 1 if you have the header file. */ -/* #undef HAVE_MATIO_H */ +#define HAVE_MATIO_H 1 /* Define to 1 if you have the `memmove' function. */ #define HAVE_MEMMOVE 1 @@ -153,7 +153,7 @@ #define HAVE_NETINET_IN_H 1 /* Define to 1 if you have the header file. */ -#define HAVE_NLIST_H 1 +/* #undef HAVE_NLIST_H */ /* Define to 1 if you have the header file. */ #define HAVE_PCRE_H 1 @@ -331,7 +331,7 @@ #define LIBXML_FLAGS "-I/usr/include/libxml2" /* libXML2 library */ -#define LIBXML_LIBS "-lxml2 -lz -lm" +#define LIBXML_LIBS "-L/usr/lib -lxml2 -lz -lm" /* Define to 1 if `lstat' dereferences a symlink specified with a trailing slash. */ @@ -362,13 +362,13 @@ #define PATH_SEPARATOR ":" /* PCRE flags */ -#define PCRE_CFLAGS "" +#define PCRE_CFLAGS "-I/usr/local/include" /* PCRE library */ -#define PCRE_LIBS "-lpcreposix -lpcre" +#define PCRE_LIBS "-L/usr/local/lib -lpcreposix -lpcre" /* PCRE version */ -#define PCRE_VERSION "7.0" +#define PCRE_VERSION "7.7" /* Define as the return type of signal handlers (`int' or `void'). */ #define RETSIGTYPE void @@ -398,13 +398,13 @@ #define VERSION "5" /* With the FFTW library */ -/* #undef WITH_FFTW */ +#define WITH_FFTW > and that scimem64.c relocstack.f are really > compiled (conditionnal compilation) Quick check: I have these files /usr/share/scilab/modules/core/.libs/libscicore_la-scimem.o /usr/share/scilab/modules/core/libscicore_la-scimem.o /usr/share/scilab/modules/core/.libs/relocstack.o /usr/share/scilab/modules/core/relocstack.o with recent dates. > then --with-docbook=/usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1 > That is it, thanks. Enrico From enrico.segre at weizmann.ac.il Tue Sep 2 08:40:01 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Tue, 02 Sep 2008 09:40:01 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080901191837.3996a2b8@caprera.inria.fr> References: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> <20080901191837.3996a2b8@caprera.inria.fr> Message-ID: <48BCDFC1.5030707@weizmann.ac.il> Simon Lipp wrote: > /usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1/javahelp/javahelp.xsl > > then --with-docbook=/usr/share/sgml/docbook/xsl-stylesheets-1.69.1-5.1 > > Simon > except that typing help in the shell is another example of vavavuma gringo: stdout spits a stream of help text, the help browser displays only scicos stuff, Exception in thread "Thread-7" java.lang.NullPointerException at javax.help.MergeHelpUtilities.mergeNodeChildren(MergeHelpUtilities.java:89) at javax.help.plaf.basic.BasicTOCNavigatorUI.loadData(BasicTOCNavigatorUI.java:218) at javax.help.plaf.basic.BasicTOCNavigatorUI.access$000(BasicTOCNavigatorUI.java:75) at javax.help.plaf.basic.BasicTOCNavigatorUI$NavSwingWorker.construct(BasicTOCNavigatorUI.java:262) at com.sun.java.help.impl.SwingWorker$2.run(SwingWorker.java:139) at java.lang.Thread.run(Thread.java:619) and a crash is one or two clicks away. # Problematic frame: # C [libscigui.so.5+0x1a8d9] sci_helpbrowser+0x2d9 Well, enough for this morning. From simon.lipp at scilab.org Tue Sep 2 09:24:01 2008 From: simon.lipp at scilab.org (Simon Lipp) Date: Tue, 2 Sep 2008 09:24:01 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <48BCDFC1.5030707@weizmann.ac.il> References: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> <20080901191837.3996a2b8@caprera.inria.fr> <48BCDFC1.5030707@weizmann.ac.il> Message-ID: <20080902092401.7648d943@caprera.inria.fr> > except that typing help in the shell is another example of vavavuma > gringo: stdout spits a stream of help text, the help browser displays > only scicos stuff, I have to rebuild doc to be sure, but I can't remember such a bug... > and a crash is one or two clicks away. Probably fixed in r27185, as for dialog demo From enrico.segre at weizmann.ac.il Tue Sep 2 09:32:10 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Tue, 02 Sep 2008 10:32:10 +0300 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080902092401.7648d943@caprera.inria.fr> References: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il><20080901191837.3996a2b8@caprera.inria.fr><48BCDFC1.5030707@weizmann.ac.il> <20080902092401.7648d943@caprera.inria.fr> Message-ID: <48BCEBFA.7000702@weizmann.ac.il> >> and a crash is one or two clicks away. >> > Probably fixed in r27185, as for dialog demo > probably so. After the checkout, for the little I've tried, I can't reproduce the crash (help and gui/dialog), before it was almost sure. From sylvestre.ledru at scilab.org Tue Sep 2 09:36:45 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 02 Sep 2008 09:36:45 +0200 Subject: [Scilab-Dev] Re: Re: linux 64 bits support In-Reply-To: <20080902092401.7648d943@caprera.inria.fr> References: <1220284211.15583.9.camel@segre-pc2.weizmann.ac.il> <20080901191837.3996a2b8@caprera.inria.fr> <48BCDFC1.5030707@weizmann.ac.il> <20080902092401.7648d943@caprera.inria.fr> Message-ID: <1220341005.3832.125.camel@korcula.inria.fr> Le mardi 02 septembre 2008 ? 09:24 +0200, Simon Lipp a ?crit : > > > > > except that typing help in the shell is another example of vavavuma > > gringo: stdout spits a stream of help text, the help browser > displays > > only scicos stuff, > I have to rebuild doc to be sure, but I can't remember such a bug... We are aware of this bug and working on it! Sylvestre From fvogelnew1 at free.fr Wed Sep 3 05:50:44 2008 From: fvogelnew1 at free.fr (fvogelnew1 at free.fr) Date: Wed, 03 Sep 2008 05:50:44 +0200 Subject: [Scilab-Dev] Re: Scipad debugger In-Reply-To: <48BBBEDB.9000905@scilab.org> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48B872BA.9060709@free.fr> <48BBBEDB.9000905@scilab.org> Message-ID: <1220413844.48be0994e7472@imp.free.fr> Selon Vincent COUVERT : > We plan to reduce the delay between our minor versions and then plan a > 5.1 version for next December where Scipad debugger will be fully > functional and where many bugs will be fixed. > > What do you think about it ? Well, OK for me (what else can I say, anyway?). Let me know what I can do to help in making the debugger functional, be it on the Scilab side or on the Scipad or testing side. We will have to resolutely tackle the problem. We should start right after Scilab 5 is out, and pay attention in not letting this problem get stuck. My understanding is that the ball is in your courtyard, agreed? Francois From fvogelnew1 at free.fr Wed Sep 3 10:40:17 2008 From: fvogelnew1 at free.fr (fvogelnew1 at free.fr) Date: Wed, 03 Sep 2008 10:40:17 +0200 Subject: [Scilab-Dev] Re: Scipad debugger In-Reply-To: <48BBBEDB.9000905@scilab.org> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48B872BA.9060709@free.fr> <48BBBEDB.9000905@scilab.org> Message-ID: <1220431217.48be4d71ed706@imp.free.fr> Hi Vincent, Selon Vincent COUVERT : > >>> What is the last date for commit in trunk before Scilab 5? > > > >> The last date for commit in TRUNK before Scilab 5 is next Monday (1st > >> September) at 12am. I have seen some activity wrt to tagging the trunk for Scilab 5 but then the tag has been removed. I plan to fix bug 3416 for Scilab 5. Is there any change in your deadline above or is it already too late for me to include this fix in Scilab 5? Thanks for keeping us up-to-date. Francois From sylvestre.ledru at scilab.org Wed Sep 3 10:51:16 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 03 Sep 2008 10:51:16 +0200 Subject: [Scilab-Dev] Re: Scipad debugger In-Reply-To: <1220431217.48be4d71ed706@imp.free.fr> References: <48B41BCC.5030409@scilab.org> <1219914033.48b66931ae5cf@imp.free.fr> <48B7B66B.5000701@scilab.org> <48B872BA.9060709@free.fr> <48BBBEDB.9000905@scilab.org> <1220431217.48be4d71ed706@imp.free.fr> Message-ID: <1220431876.17043.60.camel@korcula.inria.fr> Hello Fran?ois, > Selon Vincent COUVERT : > > >>> What is the last date for commit in trunk before Scilab 5? > > > > > >> The last date for commit in TRUNK before Scilab 5 is next Monday (1st > > >> September) at 12am. > > I have seen some activity wrt to tagging the trunk for Scilab 5 but then the tag > has been removed. Yep, it was quite unexpected (it is the kind of bug, you can spend 5 minutes or 5 days) but we *almost* fixed the bug #3443. http://lists.scilab.org/cgi-bin/ezmlm-browse?list=dev&cmd=showmsg&msgnum=548 However, since it requires some work, we dropped the tag because it is quite painful to work with the trunk & the tag. We will freeze it again when this bug is fixed. > I plan to fix bug 3416 for Scilab 5. Is there any change in > your deadline above or is it already too late for me to include this fix in > Scilab 5? Yep, with pleasure, go ahead ! :) Sylvestre From BlanchardJ at ieee.org Sun Sep 7 19:28:35 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Sun, 7 Sep 2008 14:28:35 -0300 Subject: Scilab compilation cannot find header files. Message-ID: When compiling Scilab if I do not build Scilab inside it's source tree some part of the compilation process do not correctly find some included files. For example when compiling misc.c which include machine.h the following error message is generated. gmake[2]: Entering directory `/export/home/jo/build/scilab/libs/libst' /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/export/home/jo/build/scilab/scilab-5.0-rc1/libs/libst -I../../modules/core/includes -O2 -DNDEBUG -DSVR4 -DSYSV -Dsolaris -I/export/home/jo/build/scilab/scilab-5.0-rc1/libs/MALLOC/includes/ -I/export/home/jo/build/scilab/scilab-5.0-rc1/modules/localization/includes/ -MT misc.lo -MD -MP -MF .deps/misc.Tpo -c -o misc.lo /export/home/jo/build/scilab/scilab-5.0-rc1/libs/libst/misc.c gcc -DHAVE_CONFIG_H -I. -I/export/home/jo/build/scilab/scilab-5.0-rc1/libs/libst -I../../modules/core/includes -O2 -DNDEBUG -DSVR4 -DSYSV -Dsolaris -I/export/home/jo/build/scilab/scilab-5.0-rc1/libs/MALLOC/includes/ -I/export/home/jo/build/scilab/scilab-5.0-rc1/modules/localization/includes/ -MT misc.lo -MD -MP -MF .deps/misc.Tpo -c /export/home/jo/build/scilab/scilab-5.0-rc1/libs/libst/misc.c -fPIC -DPIC -o .libs/misc.o In file included from /export/home/jo/build/scilab/scilab-5.0-rc1/libs/libst/misc.c:14: ./../../modules/core/includes/machine.h:459:22: error: PATH_MAX.h: No such file or directory ./../../modules/core/includes/machine.h:462:18: error: BOOL.h: No such file or directory ./../../modules/core/includes/machine.h:465:20: error: PARAMS.h: No such file or directory I use the following build script : export LDFLAGS="-R $HOME/local/gcc/lib -R $HOME/local/ncurses/lib -R $HOME/local/pcre/lib -R $HOME/local/libxml/lib" export LD_OPTIONS=$LDFLAGS export PATH=$HOME/local/gcc/bin:$PATH ./scilab-5.0-rc1/configure --build=i386-pc-solaris2.11 --prefix=$HOME/local/scilab LDFLAGS="-R $HOME/local/gcc/lib -R $HOME/local/ncurses/lib -R $HOME/local/pcre/lib -R $HOME/local/libxml/lib" --without-gui --without-javasci --with-libxml2=$HOME/local/libxml --with-pcre=$HOME/local/pcre --without-matio --without-tk --srcdir=$HOME/build/scilab/scilab-5.0-rc1 time gmake Any insight on this situation would be appreciated as it is kind of annoying. A workaround is to add the quite a few include path to the CC env. var. but there is around 10 of them. Jonathan Blanchard From ycollette at free.fr Sun Sep 7 15:55:55 2008 From: ycollette at free.fr (Collette Yann) Date: Sun, 07 Sep 2008 15:55:55 +0200 Subject: Internationalisation of a toolbox Message-ID: <48C3DD6B.1050703@free.fr> Hello, I have a small toolbox and I would like to use internationalization support for it. The directories are: toolbox/macros toolbox/locales/en_US In macros, I've got a simple function: function test_int(msg) printf(gettex("Your message: %s\n"),msg); endfunction To extract the messages: xgettext test_int.sci then: mv messages.po ../locales/en_US I translate these messages using poedit But how do I teel scilab-5 to load my locales ? Is it implicitly done ? YC From ronan.scaife at dcu.ie Tue Sep 9 13:50:04 2008 From: ronan.scaife at dcu.ie (Ronan Scaife) Date: Tue, 09 Sep 2008 12:50:04 +0100 Subject: mex problems Message-ID: <48C662EC.7060406@dcu.ie> Dear all, I am trying to build pa_wavplay for Scilab 4.1.2 on Windows XP. Pa_wavplay is a freely available set of MEX dlls (with source) to enable Matlab or Octave to perform simultaneous audio recording and playback under Windows, using a soundcard: and would be a very useful add-on for Scilab. I have been trying to use the examples/mex-examples/cppmex code and MS Visual Studio 2005 Express to build the dll. The cppmex example code builds and runs OK, but I have persistent problems with pa_wavplay at the linking stage. It may be relevant that the MS express package only provides multi-threaded libraries, but the distributed Scilab 4.1.2 has been compiled with multithreading *disabled* because PVM has been turned on. Has anyone successfully used the Scilab mex emulation to port similar dlls? Is there anything I should know about the choice of compiler (again, v4.1.2 was compiled using MS .NET 2003 and Intel fortran?) As I wish to use the code very soon for teaching, I would prefer a solution that will work with the current release of Scilab, rather than v 5. Any help would be appreciated, From sylvestre.ledru at scilab.org Tue Sep 9 14:48:48 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 09 Sep 2008 14:48:48 +0200 Subject: [Scilab-Dev] SEP #3 Add of a build documentation function In-Reply-To: <48726A7D.7070800@free.fr> References: <1215447505.2748.209.camel@korcula.inria.fr> <48726A7D.7070800@free.fr> Message-ID: <1220964528.29429.59.camel@korcula.inria.fr> Le lundi 07 juillet 2008 ? 21:11 +0200, Fran?ois Vogel a ?crit : > For me, updating the help files usually takes > around an hour per language on a not so old machine. This just kills > any good will for updating the help pages. A trick if you want to see if the documentation is building correctly and to see the result , you can try to generate the PDF documentation: --> xmltopdf(); It is pretty quick (a few minutes max). PDF are generated: SCI/modules/helptools/build/doc/scilab_en_US_help/scilab_en_US_help.pdf SCI/modules/helptools/build/doc/scilab_fr_FR_help/scilab_fr_FR_help.pdf Why is it that fast with PDF and that slow with HTML ... I don't have a clue. S From sylvestre.ledru at scilab.org Thu Sep 11 10:37:29 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 11 Sep 2008 10:37:29 +0200 Subject: Debug options added for C, C++ & Fortran Message-ID: <1221122249.11028.55.camel@korcula.inria.fr> Hello guys, I committed an update which increases the number of warnings. ====== For C ====== -Wold-style-definition: warning about the old style declaration void myBloodyFunction(plop) int plop { It will also complain about: void myGreatFucking(){ (void is missing) -g3: added more symbols into the binary (like macros). ====== For C++ ====== -Weffc++ (copy & paste of the man g++) Warn about violations of the following style guidelines from Scott Meyers? Effective C++ book: ? Item 11: Define a copy constructor and an assignment operator for classes with dynamically allocated memory. ? Item 12: Prefer initialization to assignment in constructors. ? Item 14: Make destructors virtual in base classes. ? Item 15: Have "operator=" return a reference to *this. ? Item 23: Don?t try to return a reference when you must return an object. Also warn about violations of the following style guidelines from Scott Meyers? More Effective C++ book: ? Item 6: Distinguish between prefix and postfix forms of increment and decrement operators. ? Item 7: Never overload "&&", "||", or ",". When selecting this option, be aware that the standard library headers do not obey all of these guidelines; use grep -v to filter out those warnings. -g3 has been also added here ====== For Fortran ====== (if you don't care about Fortran warnings, stop using --enable-debug and use --enable-debug-C & --enable-debug-CXX) -Wimplicit: Warn when implicit declaration are used (yet, we have tones of them) -Wsurprising, once more, a lazy C/P: Produce a warning when "suspicious" code constructs are encountered. While technically legal these usually indicate that an error has been made. This currently produces a warning under the following circumstances: ? An INTEGER SELECT construct has a CASE that can never be matched as its lower value is greater than its upper value. ? A LOGICAL SELECT construct has three CASE statements. ? A TRANSFER specifies a source that is shorter than the destination. Sylvestre From BlanchardJ at ieee.org Thu Sep 11 17:42:59 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Thu, 11 Sep 2008 12:42:59 -0300 Subject: Scilab compilation cannot find header files. Message-ID: Finally, I successfully built Scilab for Solaris. Thanks to the help I received from this mailing list. So here are a the few problems I ran into and the workaround I used. First of all and most importantly I figured that VPATH build does not work so it is imperative the scilab is configured and built inside it's source directory. I think this should be added to the compilation instructions. Next building without tk does not seem to work as make complain that rules are missing for some targets. Finally I ran into some make problem when it complained that targets rules where missing for some pdfs files in the differential equations demos. I just deleted them from the makefile.am and ran autoreconf. This issue seem to be fixed in TRUNK now I think. So now Scilab is working including it's gui on x86 but it still complain a bit at start up about localization but everything else look fine. I think I or someone else if anyone is interested should update the wiki about building Scilab for Solaris. Again thanks everyone for the help and a great piece of software. Jonathan Blanchard From sylvestre.ledru at scilab.org Thu Sep 11 23:27:17 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 11 Sep 2008 23:27:17 +0200 Subject: [Scilab-Dev] Re: Scilab compilation cannot find header files. In-Reply-To: References: Message-ID: <1221168437.16670.16.camel@zlarin> Le jeudi 11 septembre 2008 ? 12:42 -0300, Jonathan Blanchard a ?crit : > Finally, I successfully built Scilab for Solaris. Thanks to the help I > received from this mailing list. Thanks for your input ! > So here are a the few problems I ran into and the workaround I used. > > First of all and most importantly I figured that VPATH build does not > work so it is imperative the scilab is configured and built inside > it's source directory. I think this should be added to the compilation > instructions. Or I can make VPATH build works! ( and I probably should do that...) I will have a look on this. > Next building without tk does not seem to work as make complain that > rules are missing for some targets. Well, I think it is a broken feature :$ I have to see why. > Finally I ran into some make problem when it complained that targets > rules where missing for some pdfs files in the differential equations > demos. I just deleted them from the makefile.am and ran autoreconf. > This issue seem to be fixed in TRUNK now I think. Very bad luck for you. That means that you checkouted the trunk between the removal of these files and the update of the Makefile.am > So now Scilab is working including it's gui on x86 but it still > complain a bit at start up about localization but everything else look > fine. What is your error ? > I think I or someone else if anyone is interested should update the > wiki about building Scilab for Solaris. I am really interested! This would be very helpfull. I started these pages: http://wiki.scilab.org/Scilab_on_Solaris_10 http://wiki.scilab.org/Sun_Solaris_howtos Sylvestre From BlanchardJ at ieee.org Fri Sep 12 02:36:55 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Thu, 11 Sep 2008 21:36:55 -0300 Subject: [Scilab-Dev] Re: Scilab compilation cannot find header files. In-Reply-To: <1221168437.16670.16.camel@zlarin> References: <1221168437.16670.16.camel@zlarin> Message-ID: I get this warning message when starting scilab from a command line. ~/local/scilab/bin$ Warning: Localization issue: Error while binding the domain from /export/home/jo/local/scilab/share/scilab//../locale/ or /export/home/jo/local/scilab/share/scilab//locale/: Switch to the default language (English). So is it normal that VPATH build does not work or is it just me and/or Solaris? Jonathan Blanchard On Thu, Sep 11, 2008 at 6:27 PM, Sylvestre Ledru wrote: > Le jeudi 11 septembre 2008 ? 12:42 -0300, Jonathan Blanchard a ?crit : >> Finally, I successfully built Scilab for Solaris. Thanks to the help I >> received from this mailing list. > Thanks for your input ! > >> So here are a the few problems I ran into and the workaround I used. >> >> First of all and most importantly I figured that VPATH build does not >> work so it is imperative the scilab is configured and built inside >> it's source directory. I think this should be added to the compilation >> instructions. > Or I can make VPATH build works! ( and I probably should do that...) > I will have a look on this. > >> Next building without tk does not seem to work as make complain that >> rules are missing for some targets. > Well, I think it is a broken feature :$ I have to see why. > > >> Finally I ran into some make problem when it complained that targets >> rules where missing for some pdfs files in the differential equations >> demos. I just deleted them from the makefile.am and ran autoreconf. >> This issue seem to be fixed in TRUNK now I think. > Very bad luck for you. That means that you checkouted the trunk between > the removal of these files and the update of the Makefile.am > >> So now Scilab is working including it's gui on x86 but it still >> complain a bit at start up about localization but everything else look >> fine. > What is your error ? > >> I think I or someone else if anyone is interested should update the >> wiki about building Scilab for Solaris. > I am really interested! > This would be very helpfull. > > I started these pages: > http://wiki.scilab.org/Scilab_on_Solaris_10 > http://wiki.scilab.org/Sun_Solaris_howtos > > Sylvestre > > From BlanchardJ at ieee.org Fri Sep 12 17:31:10 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Fri, 12 Sep 2008 12:31:10 -0300 Subject: GMP/MPFR and scilab. Message-ID: Hi, I see that one of the scilab development ideas is adding GMP/MPFR support in scilab. Is there currently any activities on this project? Jonathan Blanchard From ycollet at freesurf.fr Fri Sep 12 18:10:38 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 12 Sep 2008 18:10:38 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: References: Message-ID: <48CA947E.5000207@freesurf.fr> Jonathan Blanchard a ?crit : > Hi, > > I see that one of the scilab development ideas is adding GMP/MPFR > support in scilab. Is there currently any activities on this project? > > Jonathan Blanchard > > Hello, Not yet. A Matlab toolbox exists which should be relatively easy to port to scilab. But a presentation of the wiki page shows that the approach used in the matlab toolbox (store the results in strings) is slow and another approach can be used (defined a special scilab type). This approach seems a little bit hard for me. But the first one is easy. I am currently on another task, so I will not wok on this one. Yann From BlanchardJ at ieee.org Sat Sep 13 19:03:15 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Sat, 13 Sep 2008 14:03:15 -0300 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <48CA947E.5000207@freesurf.fr> References: <48CA947E.5000207@freesurf.fr> Message-ID: How would one add a type in scilab anyways? I peeked at the source code but the core module is not that well commented(no offense). Jonathan Blanchard On Fri, Sep 12, 2008 at 1:10 PM, Collette Yann wrote: > Jonathan Blanchard a ?crit : >> >> Hi, >> >> I see that one of the scilab development ideas is adding GMP/MPFR >> support in scilab. Is there currently any activities on this project? >> >> Jonathan Blanchard >> >> > > Hello, > > Not yet. A Matlab toolbox exists which should be relatively easy to port to > scilab. > But a presentation of the wiki page shows that the approach used in the > matlab toolbox (store the results in strings) is slow and another approach > can be used (defined a special scilab type). > This approach seems a little bit hard for me. But the first one is easy. I > am currently on another task, so I will not wok on this one. > > Yann > From ycollet at freesurf.fr Sat Sep 13 19:11:00 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Sat, 13 Sep 2008 19:11:00 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: References: <48CA947E.5000207@freesurf.fr> Message-ID: <48CBF424.6010802@freesurf.fr> Good question. I'm looking at how to add overloading of a macro in the source code and it's a nightmare :) YC Jonathan Blanchard a ?crit : > How would one add a type in scilab anyways? I peeked at the source > code but the core module is not that well commented(no offense). > > Jonathan Blanchard > > > > On Fri, Sep 12, 2008 at 1:10 PM, Collette Yann wrote: > >> Jonathan Blanchard a ?crit : >> >>> Hi, >>> >>> I see that one of the scilab development ideas is adding GMP/MPFR >>> support in scilab. Is there currently any activities on this project? >>> >>> Jonathan Blanchard >>> >>> >>> >> Hello, >> >> Not yet. A Matlab toolbox exists which should be relatively easy to port to >> scilab. >> But a presentation of the wiki page shows that the approach used in the >> matlab toolbox (store the results in strings) is slow and another approach >> can be used (defined a special scilab type). >> This approach seems a little bit hard for me. But the first one is easy. I >> am currently on another task, so I will not wok on this one. >> >> Yann >> >> > > From ycollet at freesurf.fr Sun Sep 14 13:23:53 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Sun, 14 Sep 2008 13:23:53 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <48CBF424.6010802@freesurf.fr> References: <48CA947E.5000207@freesurf.fr> <48CBF424.6010802@freesurf.fr> Message-ID: <48CCF449.3020306@freesurf.fr> Hello, In the presentation from Zimmerman (http://www.loria.fr/~zimmerma/talks/mpfr-scilab.pdf) - slide 24: Serge Steer made some comments: - all the operations are made via strings - not efficient, and possible lost of precision (if the basis are different) - loops interpreted in Matlab - fixed roundoff (to the closest) What should be the best strategy to implement a GMP/MPFR toolbox in matlab ? I thought that the best strategy was to: - define a new type - overload some operators for this new type but because overloading doesn't work yet on macros (just on primitives), this is not yet the best strategy. Serge, can you give us some advices ? Yann COLLETTE From sylvestre.ledru at inria.fr Mon Sep 15 08:02:05 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Mon, 15 Sep 2008 08:02:05 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: References: <48CA947E.5000207@freesurf.fr> Message-ID: <1221458525.7300.41.camel@zlarin> Hello Jonathan, First, yes, don't waste anytime trying to do it yourself. For two reasons, it is just too hard and especially because we are starting to work on a new core of Scilab. This kind of things are going to be much easier! Sylvestre Le samedi 13 septembre 2008 ? 14:03 -0300, Jonathan Blanchard a ?crit : > How would one add a type in scilab anyways? I peeked at the source > code but the core module is not that well commented(no offense). > > Jonathan Blanchard > > > > On Fri, Sep 12, 2008 at 1:10 PM, Collette Yann wrote: > > Jonathan Blanchard a ?crit : > >> > >> Hi, > >> > >> I see that one of the scilab development ideas is adding GMP/MPFR > >> support in scilab. Is there currently any activities on this project? > >> > >> Jonathan Blanchard > >> > >> > > > > Hello, > > > > Not yet. A Matlab toolbox exists which should be relatively easy to port to > > scilab. > > But a presentation of the wiki page shows that the approach used in the > > matlab toolbox (store the results in strings) is slow and another approach > > can be used (defined a special scilab type). > > This approach seems a little bit hard for me. But the first one is easy. I > > am currently on another task, so I will not wok on this one. > > > > Yann > > From fvogelnew1 at free.fr Mon Sep 15 08:40:39 2008 From: fvogelnew1 at free.fr (=?ISO-8859-15?Q?Fran=E7ois_Vogel?=) Date: Mon, 15 Sep 2008 08:40:39 +0200 Subject: [Fwd: Announce: Tcl3D 0.3.3 released] Message-ID: <48CE0367.2060809@free.fr> FYI, just in case... Francois -------- Message original -------- Sujet : Announce: Tcl3D 0.3.3 released Date : Sun, 14 Sep 2008 22:19:55 +0200 De : Tcl3D Info Organisation : (posted via) M-net Telekommunikations GmbH Forum : comp.lang.tcl Dear Tcl'ers, I'm pleased to announce version 0.3.3 of Tcl3D. Tcl3D offers the 3D functionality of OpenGL and other 3D libraries at the Tcl scripting level. This is accomplished by wrapping the libraries with the help of SWIG. The Tcl3D package consists of the following building blocks: tcl3dTogl Enhanced Togl widget, a Tk widget for OpenGL content. tcl3dUtil Tcl3D utility library (math, shapes, stop watch, ..). tcl3dOgl Wrapper for basic OpenGL functionality. tcl3dOglExt Wrapper for enhanced OpenGL functionality. tcl3dCg Wrapper for NVidia's Cg shading language. tcl3dSDL Wrapper for the Simple DirectMedia Library. tcl3dFTGL Wrapper for the OpenGL Font Rendering Library. tcl3dGl2ps Wrapper for the OpenGL To Postscript library. tcl3dOde Wrapper for the Open Dynamics Engine. tcl3dGauges A Tcl3D package for displaying gauges. tcl3dDemoUtil Utilities in C/C++ needed for some demo applications Tcl3D comes with lots of demo and test programs. Tcl3D sources, binaries and demos are available at http://www.tcl3d.org/ Please send questions, bug reports or any other feedback about Tcl3D to , or visit the Tcl3D related pages on the Wiki: http://wiki.tcl.tk/15278 (Tcl3D) http://wiki.tcl.tk/16057 (Tcl3D Discussion) http://wiki.tcl.tk/17771 (Tcl3D Demo of the Month) Regards, Paul Obermeier Version history: Version 0.3.3, released 2008/09/14 Bug fix and maintenance release - Enhancements: + Enhanced documentation: Reference manual for Tcl3D specific functions. User manual updated and enhanced. + Added 64-bit Linux to the supported list of platforms. + Improved Mac OS X support: Fixed resize problems in presentation framework. Consistent mouse button behaviour across operating systems. + Trackball module supports multiple windows. CAUTION: Incompatible change. Additional Togl window parameter in procedures tcl3dTbAnimate, tcl3dTbInit, tcl3dTbMatrix. Thanks to Michael Magoga for this patch. + New OpenGL utility procedures: tcl3dOglGetIntState, tcl3dOglGetFloatState, tcl3dOglGetDoubleState. tcl3dOglGetMaxTextureSize, tcl3dOglGetMaxTextureUnits, tcl3dOglGetViewport, tcl3dOglGetShaderInfoLog, tcl3dOglGetProgramInfoLog, tcl3dOglGetShaderSource, tcl3dOglShaderSource, tcl3dOglGetInfoLogARB. + New low-level routines for copying Tcl lists into a vector: tcl3dListToVector_TYPE Tcl utility procedure tcl3dVectorFromList updated to transparently use the new low-level routines. + Starpacks now allow drag-and-drop of TclKit files. + tcl3dGetExtFile not constrained to Starkits anymore. Thanks to Jean-Claude Gohard for supplying a vfs and zvfs enabled version. + New utility functions for random number generation (same algorithm at C and Tcl level). - Bug fixes: + Bug fix in tcl3dGauges: Eliminated bgerror procedures. Thanks to Alexandre Ferrieux and Synic for hints on this bug. + Several bug fixes in the presentation framework. Thanks to Philip Quaiffe for hints and other useful discussions. + Several other minor bug fixes. - New demos: + 19 new demos added since release 0.3.2. These have been previously released as Tcl3D Demo of the month. Version 0.3.2, released 2007/02/25 Demo cleanup and first official Mac OS X support - Unification of demo applications and presentation framework. - New module tcl3dDemoUtil for C/C++ based utility functions needed by some of the demos for speed issues. - More NeHe tutorials added: Lessons 14, 22-24, 26, 28, 33, 36, 37, 41, 45-48. - Nine demos from www.GameProgrammer.org added. - Updated Tcl3D manual. Created separate demo overview document. - Added support to capture screenshots (Module tcl3dCapture). - Added new functionality to tcl3dUtil: ArcBall emulation. - Added windowing system specifics (SwapInterval, Multisampling) to the tcl3dTogl widget. - Added support for Visual Studio 2003 (7.1) and 2005 (8.0). - Enhanced tcl3dVector functionality. + Utility functions for manipulation of image data stored in tcl3dVectors: tcl3dVectorCopy, tcl3dVectorCopyChannel, tcl3dVectorManip, tcl3dVectorManipChannel + tcl3dVector member functions for content independent manipulation: setvec, addvec, mulvec - tcl3dOde now uses ODE version 0.7 and is available for Windows, Linux, Mac OS X and Irix. Wrapper still in alpha version and not complete. - tcl3dGl2ps now uses GL2PS version 1.3.2. - tcl3dCg now uses Cg version 1.5.0015. The 1.4 versions of Cg did not work with OS X on Intel platforms. Version 0.3.1, released 2006/06/19 Starpack support for Tcl3D - Starpack version of Tcl3D, including demos and external libraries. First shown at TclEurope 2006. - New optional module tcl3dGl2ps, wrapping the OpenGL To Postscript library. (Thanks to Ian Gay for idea and first implementation) - New optional module tcl3dOde, wrapping the Open Dynamics Engine. Very alpha preview, Windows only !!! - More NeHe tutorials added: Lessons 19-21. Version 0.3, released 2006/02/12 MacOS X and enhanced font support - Support for Mac OS X added. (Thanks to Daniel A. Steffen for supplying patches and binaries) - New optional module tcl3dFTGL, wrapping the OpenGL font rendering library FTGL, based on freetype fonts. - Corrected and enhanced font handling under Windows in the tcl3dTogl widget. No more private Tcl header files needed. - Added new font related demo programs: tcl3dFont.tcl, tcl3dToglFonts.tcl, ftglTest.tcl, ftglDemo.tcl. - Added new SDL demo related to CD-ROM handling: cdplayer.tcl - Added some of NeHe's OpenGL tutorials. - If an optional library is not installed, no error message is created. New procedures to check existence of optional modules: tcl3dHaveCg, tcl3dHaveSDL, tcl3dHaveFTGL. - Get information on Tcl3D subpackages with tcl3dGetPackageInfo and tcl3dShowPackageInfo. - Information program tcl3dInfo.tcl enhanced to support commands and enums of SDL and FTGL modules. - Added new functionality to tcl3dUtil: Simple, scrollable Tk widgets for demo programs, trackball emulation (used in FTGLdemo.tcl). - Added new functionality to tcl3dUtil: tcl3dVectorFromByteArray, tcl3dVectorToByteArray. Convert Tcl binary strings to tcl3dVectors and vice versa (see demo bytearray.tcl). - Bug fix in OglExt wrapping: Parameters of type "float *" and "double *" were wrapped incorrectly. Version 0.2, released 2006/01/07 Major rewrite of TclOgl - Major rewrite and inclusion of several new 3D libraries: + OpenGL 2.0 and extensions + NVidia's Cg library + SDL, the Simple Direct Media Library + 4 gauge widgets (Thanks to Victor G. Bonilla for supplying this library) + Utility library - Renamed from TclOgl to Tcl3D - Created domain tcl3d.org Version 0.1, released 2005/05/29 Initial version - First version (called TclOgl) introduced at the Tcl Europe 2005 conference. - Supported features include basic OpenGL wrapping. From pierre.marechal at scilab.org Mon Sep 15 11:29:08 2008 From: pierre.marechal at scilab.org (Pierre MARECHAL) Date: Mon, 15 Sep 2008 11:29:08 +0200 Subject: Scilab 5.0.1 is released ! Message-ID: <48CE2AE4.7000008@scilab.org> Hello, The Scilab Team is pleased to announce the release of Scilab 5.0.1. Misc information about this version: http://www.scilab.org/download/index_download.php?page=5.0.1 List of changes: http://www.scilab.org/download/index_download.php?page=CHANGES_5.0.1 The release notes (short bug list... and of course not full): http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_5.0.1 Pierre -- ============================================== Pierre MARECHAL INRIA - Unit? de Recherche de Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex ============================================== Projet Scilab B?timent 1B - Bureau 008 Email : pierre.marechal at scilab.org ============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Mon Sep 15 14:18:10 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 15 Sep 2008 14:18:10 +0200 Subject: [Scilab-Dev] Re: Scilab compilation cannot find header files. In-Reply-To: References: <1221168437.16670.16.camel@zlarin> Message-ID: <1221481091.25606.4.camel@korcula.inria.fr> Le jeudi 11 septembre 2008 ? 21:36 -0300, Jonathan Blanchard a ?crit : > I get this warning message when starting scilab from a command line. > > ~/local/scilab/bin$ Warning: Localization issue: Error while binding > the domain from /export/home/jo/local/scilab/share/scilab//../locale/ > or /export/home/jo/local/scilab/share/scilab//locale/: Switch to the > default language (English). Try: --enable-build-localization It should work better. > So is it normal that VPATH build does not work or is it just me and/or Solaris? It is normal. I have been working on this lately. You can now build Scilab it self (dyn library + scilab-bin binary). However, it still requires some work to be able to build macros + doc this way. But it should be pretty fast to fix. Revision: 27636 http://viewvc.scilab.org/bin/cgi/viewvc.cgi?limit_changes=100&view=rev&revision=27636 configure.ac & */*/Makefile.am are the interesting files. Thanks again for point this out! Sylvestre > > Jonathan Blanchard > > > > On Thu, Sep 11, 2008 at 6:27 PM, Sylvestre Ledru > wrote: > > Le jeudi 11 septembre 2008 ? 12:42 -0300, Jonathan Blanchard a ?crit : > >> Finally, I successfully built Scilab for Solaris. Thanks to the help I > >> received from this mailing list. > > Thanks for your input ! > > > >> So here are a the few problems I ran into and the workaround I used. > >> > >> First of all and most importantly I figured that VPATH build does not > >> work so it is imperative the scilab is configured and built inside > >> it's source directory. I think this should be added to the compilation > >> instructions. > > Or I can make VPATH build works! ( and I probably should do that...) > > I will have a look on this. > > > >> Next building without tk does not seem to work as make complain that > >> rules are missing for some targets. > > Well, I think it is a broken feature :$ I have to see why. > > > > > >> Finally I ran into some make problem when it complained that targets > >> rules where missing for some pdfs files in the differential equations > >> demos. I just deleted them from the makefile.am and ran autoreconf. > >> This issue seem to be fixed in TRUNK now I think. > > Very bad luck for you. That means that you checkouted the trunk between > > the removal of these files and the update of the Makefile.am > > > >> So now Scilab is working including it's gui on x86 but it still > >> complain a bit at start up about localization but everything else look > >> fine. > > What is your error ? > > > >> I think I or someone else if anyone is interested should update the > >> wiki about building Scilab for Solaris. > > I am really interested! > > This would be very helpfull. > > > > I started these pages: > > http://wiki.scilab.org/Scilab_on_Solaris_10 > > http://wiki.scilab.org/Sun_Solaris_howtos > > > > Sylvestre > > > > From voronaam at yandex.ru Mon Sep 15 14:51:04 2008 From: voronaam at yandex.ru (Vorona Aleksey) Date: Mon, 15 Sep 2008 16:51:04 +0400 Subject: [Scilab-Dev] Scilab 5.0.1 is released ! In-Reply-To: <48CE2AE4.7000008@scilab.org> References: <48CE2AE4.7000008@scilab.org> Message-ID: <48CE5A38.10205@yandex.ru> I didn't see alert about release coming, sorry. Russian translation is not finished, and if nobody added recent translation from launchpad, then it is very old in svn. Are there plans to release another version soon? I mean, is there schedule? I'll try to complete translation till next release... Anyway, Congrats! :) Pierre MARECHAL wrote: > Hello, > > The Scilab Team is pleased to announce the release of Scilab 5.0.1. > Misc information about this version: > http://www.scilab.org/download/index_download.php?page=5.0.1 > > List of changes: > http://www.scilab.org/download/index_download.php?page=CHANGES_5.0.1 > > The release notes (short bug list... and of course not full): > http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_5.0.1 > > > Pierre > -- WBR, Vorona Aleksey. From ycollet at freesurf.fr Tue Sep 16 08:34:00 2008 From: ycollet at freesurf.fr (ycollet at freesurf.fr) Date: Tue, 16 Sep 2008 08:34:00 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <1221458525.7300.41.camel@zlarin> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> Message-ID: <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> Hello, So, maybe a good first solution should be to "just translate" the mpfr toolbox to scilab ? By doing this, we will have a toolbox to test and define what are the needs in multiprecision computation. YC Sylvestre Ledru a ?crit?: > Hello Jonathan, > > First, yes, don't waste anytime trying to do it yourself. For two > reasons, it is just too hard and especially because we are starting to > work on a new core of Scilab. > This kind of things are going to be much easier! > > Sylvestre From BlanchardJ at ieee.org Wed Sep 17 16:27:58 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Wed, 17 Sep 2008 11:27:58 -0300 Subject: [Scilab-Dev] Re: Scilab compilation cannot find header files. In-Reply-To: <1221481091.25606.4.camel@korcula.inria.fr> References: <1221168437.16670.16.camel@zlarin> <1221481091.25606.4.camel@korcula.inria.fr> Message-ID: Yes it did clear the problem. I wrote a page in the wiki about compiling Scilab under Solaris and Gcc, you might want to take a look as I might have complicated things a bit. Anyways thanks for all the info. Jonathan Blanchard On Mon, Sep 15, 2008 at 9:18 AM, Sylvestre Ledru wrote: > Le jeudi 11 septembre 2008 ? 21:36 -0300, Jonathan Blanchard a ?crit : >> I get this warning message when starting scilab from a command line. >> >> ~/local/scilab/bin$ Warning: Localization issue: Error while binding >> the domain from /export/home/jo/local/scilab/share/scilab//../locale/ >> or /export/home/jo/local/scilab/share/scilab//locale/: Switch to the >> default language (English). > Try: > --enable-build-localization > > It should work better. > > >> So is it normal that VPATH build does not work or is it just me and/or Solaris? > It is normal. > I have been working on this lately. You can now build Scilab it self > (dyn library + scilab-bin binary). However, it still requires some work > to be able to build macros + doc this way. But it should be pretty fast > to fix. > Revision: 27636 > http://viewvc.scilab.org/bin/cgi/viewvc.cgi?limit_changes=100&view=rev&revision=27636 > configure.ac & */*/Makefile.am are the interesting files. > > Thanks again for point this out! > > Sylvestre > > > >> >> Jonathan Blanchard >> >> >> >> On Thu, Sep 11, 2008 at 6:27 PM, Sylvestre Ledru >> wrote: >> > Le jeudi 11 septembre 2008 ? 12:42 -0300, Jonathan Blanchard a ?crit : >> >> Finally, I successfully built Scilab for Solaris. Thanks to the help I >> >> received from this mailing list. >> > Thanks for your input ! >> > >> >> So here are a the few problems I ran into and the workaround I used. >> >> >> >> First of all and most importantly I figured that VPATH build does not >> >> work so it is imperative the scilab is configured and built inside >> >> it's source directory. I think this should be added to the compilation >> >> instructions. >> > Or I can make VPATH build works! ( and I probably should do that...) >> > I will have a look on this. >> > >> >> Next building without tk does not seem to work as make complain that >> >> rules are missing for some targets. >> > Well, I think it is a broken feature :$ I have to see why. >> > >> > >> >> Finally I ran into some make problem when it complained that targets >> >> rules where missing for some pdfs files in the differential equations >> >> demos. I just deleted them from the makefile.am and ran autoreconf. >> >> This issue seem to be fixed in TRUNK now I think. >> > Very bad luck for you. That means that you checkouted the trunk between >> > the removal of these files and the update of the Makefile.am >> > >> >> So now Scilab is working including it's gui on x86 but it still >> >> complain a bit at start up about localization but everything else look >> >> fine. >> > What is your error ? >> > >> >> I think I or someone else if anyone is interested should update the >> >> wiki about building Scilab for Solaris. >> > I am really interested! >> > This would be very helpfull. >> > >> > I started these pages: >> > http://wiki.scilab.org/Scilab_on_Solaris_10 >> > http://wiki.scilab.org/Sun_Solaris_howtos >> > >> > Sylvestre >> > >> > > > From BlanchardJ at ieee.org Wed Sep 17 16:30:59 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Wed, 17 Sep 2008 11:30:59 -0300 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> Message-ID: Concerning Scilab 6 is there an updated roadmap about it's development. When can we expect to see some code and is it going to be happening in the public repository? Also sorry about all the questions but can we expect to see some preliminary info about the new api? Jonathan Blanchard On Tue, Sep 16, 2008 at 3:34 AM, wrote: > Hello, > > So, maybe a good first solution should be to "just translate" the mpfr > toolbox to scilab ? > By doing this, we will have a toolbox to test and define what are the needs > in multiprecision computation. > > YC > > Sylvestre Ledru a ?crit : > >> Hello Jonathan, >> >> First, yes, don't waste anytime trying to do it yourself. For two >> reasons, it is just too hard and especially because we are starting to >> work on a new core of Scilab. >> This kind of things are going to be much easier! >> >> Sylvestre > > > From sylvestre.ledru at scilab.org Wed Sep 17 18:40:01 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Wed, 17 Sep 2008 18:40:01 +0200 Subject: Leaving SVN to GIT Message-ID: <1221669601.25606.214.camel@korcula.inria.fr> Hello guys, We are thinking about leaving Subversion to Git. This change is considered because we are going to work more and more as "flavour" of Scilab. I don't mean that we are going to create different kind/versions but more that some people in the team are going to work on the new kernel, other on graphics, Scicos ... (of course, everything would be finally merge in the master). Therefor, we need to be able to exchange easily changes between one branch to the other without committing on-going work into the trunk. SVN is a pain when dealing with branches. Git is probably the best way to organize our daily work. Any opinions on this ? Sylvestre From ycollet at freesurf.fr Wed Sep 17 18:50:55 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 17 Sep 2008 18:50:55 +0200 Subject: [Scilab-Dev] Leaving SVN to GIT In-Reply-To: <1221669601.25606.214.camel@korcula.inria.fr> References: <1221669601.25606.214.camel@korcula.inria.fr> Message-ID: <48D1356F.7010603@freesurf.fr> Sylvestre Ledru a ?crit : > Hello guys, > > We are thinking about leaving Subversion to Git. > > This change is considered because we are going to work more and more as > "flavour" of Scilab. I don't mean that we are going to create different > kind/versions but more that some people in the team are going to work on > the new kernel, other on graphics, Scicos ... (of course, everything > would be finally merge in the master). > Therefor, we need to be able to exchange easily changes between one > branch to the other without committing on-going work into the trunk. > > SVN is a pain when dealing with branches. Git is probably the best way > to organize our daily work. > > Any opinions on this ? > > Sylvestre > > What about having a SVN and GIT repository in sync for a short period ? I think that in several projects, they have done such a thing (maybe kde ?). YC From barry.cardiff at gmail.com Wed Sep 17 20:08:29 2008 From: barry.cardiff at gmail.com (Barry Cardiff) Date: Wed, 17 Sep 2008 19:08:29 +0100 Subject: Compilation problem on vista Message-ID: <82bf75360809171108i25193003p7214fd103b4627c3@mail.gmail.com> Hi all, I recently tried to compile Scilab on my Vista machine and it failed. The problem was caused by a 'realloc' problem in the f2c.exe program used to convert some Fortran source to C. It only failed on certain Fortran files so the build was partially complete. To fix the problem I downloaded a version of f2c.exe from: http://netlib.sandia.gov/master/index.html (untar the tar ball and you'll find the source plus a prebuilt .exe in one of the sub directories - I used the prebuilt version). I copied the f2c.exe over the one in the scilab/bin directory and then after a "clean solution" and a "build solution" in MS visual studio express edition all is good. Hope this is helpful to someone else. Barry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Thu Sep 18 18:12:20 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 18 Sep 2008 18:12:20 +0200 Subject: [Scilab-Dev] Leaving SVN to GIT In-Reply-To: <48D1356F.7010603@freesurf.fr> References: <1221669601.25606.214.camel@korcula.inria.fr> <48D1356F.7010603@freesurf.fr> Message-ID: <1221754340.4023.3.camel@zlarin.inria.fr> Le mercredi 17 septembre 2008 ? 18:50 +0200, Collette Yann a ?crit : > Sylvestre Ledru a ?crit : > > Hello guys, > > > > We are thinking about leaving Subversion to Git. [...] > > > What about having a SVN and GIT repository in sync for a short period ? Well, we could but if you are using a VCS for commit/update, switching to git is easy. Sylvestre From sylvestre.ledru at scilab.org Thu Sep 18 21:06:30 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 18 Sep 2008 21:06:30 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> Message-ID: <1221764790.3747.6.camel@zlarin.inria.fr> > Concerning Scilab 6 is there an updated roadmap about it's > development. You will find the roadmap on Scilab's website. (sorry for not giving you the URL, I am writing this email offline). > When can we expect to see some code and is it going to be > happening in the public repository? It is why we are thinking to use GIT. It is going to be easier to work on the new core and maitaining the current core... Keeping important stuffs synchronized. Therefor, they will be available. Scilab has a few APIs (what we call stackX, 1 to 3). Each one of them built over the other. The easiest and better (at least for me) is the stack3. For now, the current step is the migration of the different gateways (a link between the Scilab engine and the feature itself) to this version of the stack in order to use a unique API (Antoine & Bruno, please correct me if I am wrong). > Also sorry about all the questions > but can we expect to see some preliminary info about the new api? It is an on going work that we will share. For the API, I think it is going to be as close as possible to the stack3 API + missing functions (on tlist for example). And since the v5 has been released, we have more time to write some documentation (on our wiki). Sylvestre > Jonathan Blanchard > > > > On Tue, Sep 16, 2008 at 3:34 AM, wrote: > > Hello, > > > > So, maybe a good first solution should be to "just translate" the mpfr > > toolbox to scilab ? > > By doing this, we will have a toolbox to test and define what are the needs > > in multiprecision computation. > > > > YC > > > > Sylvestre Ledru a ?crit : > > > >> Hello Jonathan, > >> > >> First, yes, don't waste anytime trying to do it yourself. For two > >> reasons, it is just too hard and especially because we are starting to > >> work on a new core of Scilab. > >> This kind of things are going to be much easier! > >> > >> Sylvestre > > > > > > From fvogelnew1 at free.fr Thu Sep 18 21:28:35 2008 From: fvogelnew1 at free.fr (=?UTF-8?B?RnJhbsOnb2lzIFZvZ2Vs?=) Date: Thu, 18 Sep 2008 21:28:35 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <1221764790.3747.6.camel@zlarin.inria.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> Message-ID: <48D2ABE3.4090704@free.fr> Sylvestre Ledru said on 18/09/2008 21:06: >> Concerning Scilab 6 is there an updated roadmap about it's >> development. > You will find the roadmap on Scilab's website. What is currently on your website is pretty outdated I think. For instance Scilab 5.0 is advertised to be out in March 2008 in this sketch: http://www.scilab.org/developers/images/Scilab_roadmap.png There is no target date for 5.1, from the picture it can be guessed that Scilab 6.1 will be out in 2010 and Scilab 6.0 some time before. Well, something more precise wouldn't hurt, no? > (sorry for not giving you the URL, I am writing this email offline). That's probably why you pointed the OP to the website. Have a look. The roadmap is almost entirely targeted to Scilab 5.0, with very few information about the future releases. Obviously you must have a plan for the next few releases, why not communicating about it? Francois From sylvestre.ledru at scilab.org Thu Sep 18 21:38:22 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 18 Sep 2008 21:38:22 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <48D2ABE3.4090704@free.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> Message-ID: <1221766702.3747.14.camel@zlarin.inria.fr> I would have been surprised not having an answer from you on this email ;) Le jeudi 18 septembre 2008 ? 21:28 +0200, Fran?ois Vogel a ?crit : > Sylvestre Ledru said on 18/09/2008 21:06: > >> Concerning Scilab 6 is there an updated roadmap about it's > >> development. > > You will find the roadmap on Scilab's website. > > What is currently on your website is pretty outdated I think. For > instance Scilab 5.0 is advertised to be out in March 2008 in this sketch: > http://www.scilab.org/developers/images/Scilab_roadmap.png I was more thinking about: http://www.scilab.org/developers/index_developers.php?page=roadmap_family6 which is still what we are going to do. > There is no target date for 5.1, from the picture it can be guessed > that Scilab 6.1 will be out in 2010 and Scilab 6.0 some time before. > > Well, something more precise wouldn't hurt, no? > > > (sorry for not giving you the URL, I am writing this email offline). > > That's probably why you pointed the OP to the website. Have a look. > The roadmap is almost entirely targeted to Scilab 5.0, with very few > information about the future releases. > > Obviously you must have a plan for the next few releases, why not > communicating about it? Because we were focused on the version 5.0, not the version 6.0. Things will come in time, please be patient! ;) Sylvestre From fvogelnew1 at free.fr Thu Sep 18 21:41:43 2008 From: fvogelnew1 at free.fr (=?UTF-8?B?RnJhbsOnb2lzIFZvZ2Vs?=) Date: Thu, 18 Sep 2008 21:41:43 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <1221766702.3747.14.camel@zlarin.inria.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> <1221766702.3747.14.camel@zlarin.inria.fr> Message-ID: <48D2AEF7.9030908@free.fr> Sylvestre Ledru said on 18/09/2008 21:38: > I was more thinking about: > http://www.scilab.org/developers/index_developers.php?page=roadmap_family6 > which is still what we are going to do. Sure. The question is not about "what" but about "when". Dates, you see what I mean? Francois From sylvestre.ledru at scilab.org Thu Sep 18 21:50:30 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Thu, 18 Sep 2008 21:50:30 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <48D2AEF7.9030908@free.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> <1221766702.3747.14.camel@zlarin.inria.fr> <48D2AEF7.9030908@free.fr> Message-ID: <1221767430.3747.26.camel@zlarin.inria.fr> Le jeudi 18 septembre 2008 ? 21:41 +0200, Fran?ois Vogel a ?crit : > Sylvestre Ledru said on 18/09/2008 21:38: > > I was more thinking about: > > http://www.scilab.org/developers/index_developers.php?page=roadmap_family6 > > which is still what we are going to do. > > Sure. The question is not about "what" but about "when". Dates, you > see what I mean? Thanks. I know what "when" means ;) For the version 5.0.2, by the end of the month. For the 5.1, december normally. For the version 6.0, I cannot answer you right now. I personnally don't know (I am more focus on the 5.X for now) but I know there is a bit of work on it! Sylvestre From fvogelnew1 at free.fr Fri Sep 19 08:25:54 2008 From: fvogelnew1 at free.fr (=?UTF-8?B?RnJhbsOnb2lzIFZvZ2Vs?=) Date: Fri, 19 Sep 2008 08:25:54 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <1221767430.3747.26.camel@zlarin.inria.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> <1221766702.3747.14.camel@zlarin.inria.fr> <48D2AEF7.9030908@free.fr> <1221767430.3747.26.camel@zlarin.inria.fr> Message-ID: <48D345F2.2060307@free.fr> Sylvestre Ledru said on 18/09/2008 21:50: > For the version 5.0.2, by the end of the month. For the 5.1, december > normally. Valuable bits of information, thanks. Francois From fvogelnew1 at free.fr Fri Sep 19 21:27:27 2008 From: fvogelnew1 at free.fr (=?ISO-8859-1?Q?Fran=E7ois_Vogel?=) Date: Fri, 19 Sep 2008 21:27:27 +0200 Subject: [Scilab-Dev] Leaving SVN to GIT In-Reply-To: <1221669601.25606.214.camel@korcula.inria.fr> References: <1221669601.25606.214.camel@korcula.inria.fr> Message-ID: <48D3FD1F.1020607@free.fr> Sylvestre Ledru said on 17/09/2008 18:40: > SVN is a pain when dealing with branches. Git is probably the best way > to organize our daily work. Interesting. In fact I think at the first place you're advocating switching from SVN to a distributed version control system. I can't tell if this is a good idea or not, you certainly have a better view of what you want to do next than I have, thus a better assessment of whether a distributed VCS should be used. The question I have is rather why GIT, because there are other distributed version control systems around, for instance SVK, which looks closer to SVN (easing switching perhaps, then). Francois From BlanchardJ at ieee.org Fri Sep 19 22:51:09 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Fri, 19 Sep 2008 17:51:09 -0300 Subject: [Scilab-Dev] Leaving SVN to GIT In-Reply-To: <48D3FD1F.1020607@free.fr> References: <1221669601.25606.214.camel@korcula.inria.fr> <48D3FD1F.1020607@free.fr> Message-ID: I am not working with the Scilab repository so I have no real opinion on the subject apart that the new version of svn have some very nice new feature. But just on question, what do you mean by branching in svn is a pain? If i remember correctly svn was created to replace cvs and branching was one of the compelling reason to do so. Anyways I'm just curious. Jonathan Blanchard On Fri, Sep 19, 2008 at 4:27 PM, Fran?ois Vogel wrote: > Sylvestre Ledru said on 17/09/2008 18:40: >> >> SVN is a pain when dealing with branches. Git is probably the best way >> to organize our daily work. > > Interesting. In fact I think at the first place you're advocating switching > from SVN to a distributed version control system. I can't tell if this is a > good idea or not, you certainly have a better view of what you want to do > next than I have, thus a better assessment of whether a distributed VCS > should be used. > > The question I have is rather why GIT, because there are other distributed > version control systems around, for instance SVK, which looks closer to SVN > (easing switching perhaps, then). > > Francois > > From sylvestre.ledru at scilab.org Sat Sep 20 00:36:47 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Sat, 20 Sep 2008 00:36:47 +0200 Subject: [Scilab-Dev] Leaving SVN to GIT In-Reply-To: <48D3FD1F.1020607@free.fr> References: <1221669601.25606.214.camel@korcula.inria.fr> <48D3FD1F.1020607@free.fr> Message-ID: <1221863807.3747.48.camel@zlarin.inria.fr> Hello Fran?ois, > The question I have is rather why GIT, because there are other > distributed version control systems around, for instance SVK, which > looks closer to SVN (easing switching perhaps, then). With SVK, there is still a one repository. Two users can not merge with each other and then push the changes to the repo. Sylvestre From sylvestre.ledru at scilab.org Sat Sep 20 17:00:59 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Sat, 20 Sep 2008 17:00:59 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <48D345F2.2060307@free.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> <1221766702.3747.14.camel@zlarin.inria.fr> <48D2AEF7.9030908@free.fr> <1221767430.3747.26.camel@zlarin.inria.fr> <48D345F2.2060307@free.fr> Message-ID: <1221922859.9808.15.camel@zlarin.inria.fr> Le vendredi 19 septembre 2008 ? 08:25 +0200, Fran?ois Vogel a ?crit : > Sylvestre Ledru said on 18/09/2008 21:50: > > For the version 5.0.2, by the end of the month. For the 5.1, december > > normally. > > Valuable bits of information, thanks. You are welcome. We are also going to publish the detailled roadmap (at least for the 5.0.2 & 5.1)... Next week normally. Sylvestre From fvogelnew1 at free.fr Mon Sep 22 10:10:10 2008 From: fvogelnew1 at free.fr (fvogelnew1 at free.fr) Date: Mon, 22 Sep 2008 10:10:10 +0200 Subject: Scipad / Scilab In-Reply-To: <48D74EA1.9070203@fivesgroup.com> References: <48D74EA1.9070203@fivesgroup.com> Message-ID: <1222071010.48d752e2d93b8@imp.free.fr> Hello Jean-Michel, I'm answering you cc-ing the Scilab development mailing list since this may be of interest to others. Also, my reply will be in English because the language on this mailing list is English, I hope this is fine for you. I see what you mean in your post. I don't think however that this problem is a Scipad problem. Indeed I can have a wrong output in the Scilab shell simply by: --> printf("measure: 1 ?m") So it seems that there is a bug in the Scilab shell console first. Browsing the Scilab bugzilla http://bugzilla.scilab.org I think what you are reporting is bug 3070: http://bugzilla.scilab.org/show_bug.cgi?id=3070 Regards, Francois Selon Jean-Michel Eck : > > > > > > Bonjour, > > > > Je suis entrain de tester la nouvelle version de scilab (5.0.1) > > Je n'obtiens pas le caract?re "?" en sortie sur > la console ? partir de l'ex?cution d'un script. > > > exemple la commande > suivante : > > > ra = 3.2 > > printf(? '\nRugosit? de la surface de > friction des labyrinthes? ra = %6.1f??? ?m',ra*1.e6) > > > donne le r?sultat suivant dans la console > lorsqu'elle est charg? dans scilab ? partir de l'?diteur scipad : > > > "Rugosit? de la surface de > friction des labyrinthes? ra =??? 3.2??? m" > > > > > Que puis-je faire pour obtenir le caract?re ? ? l'ex?cution du script ? > > Merci pour tout votre travail ! > > > > Meilleures salutations,? > > > > > > > > > > > Eck Jean-Michel > > > > R&D - > Calculation Engineer > > > Fives Cryomec > AG > > > > > > Binningerstrasse 85a CH - 4123 Allschwil > > > Switzerland > > > > Phone : +41 61 487 33 41 > - Fax : +41 61 487 33 99 > > > Mailto : > jean-michel.eck at fivesgroup.com > > > > > > > > > > > From yjlee123 at gmail.com Mon Sep 22 14:05:19 2008 From: yjlee123 at gmail.com (Yung-Jang Lee) Date: Mon, 22 Sep 2008 20:05:19 +0800 Subject: [Scilab-Dev] Re: Scipad / Scilab In-Reply-To: <1222071010.48d752e2d93b8@imp.free.fr> References: <48D74EA1.9070203@fivesgroup.com> <1222071010.48d752e2d93b8@imp.free.fr> Message-ID: <9371b4280809220505q7d777a8cma55f30c37db5cec1@mail.gmail.com> Hi, A patch related to encoding converter is prepared. This is the results of this patch based on current SVN, ----------------------------------------------- -->mprintf("?") ? -->mprintf("?") ? -->printf("measure: 1 ?m") measure: 1 ?m ---------------------------------------------- This patch already send to Sylvestre for committing. Regards, YungLee 2008/9/22 > Hello Jean-Michel, > > I'm answering you cc-ing the Scilab development mailing list since this may > be > of interest to others. Also, my reply will be in English because the > language on > this mailing list is English, I hope this is fine for you. > > I see what you mean in your post. > > I don't think however that this problem is a Scipad problem. Indeed I can > have a > wrong output in the Scilab shell simply by: > > --> printf("measure: 1 ?m") > > So it seems that there is a bug in the Scilab shell console first. > > Browsing the Scilab bugzilla http://bugzilla.scilab.org I think what you > are > reporting is bug 3070: > http://bugzilla.scilab.org/show_bug.cgi?id=3070 > > Regards, > Francois > > > Selon Jean-Michel Eck : > > > > > > > > > > > > > Bonjour, > > > > > > > > Je suis entrain de tester la nouvelle version de scilab (5.0.1) > > > > Je n'obtiens pas le caract?re "?" en sortie sur > > la console ? partir de l'ex?cution d'un script. > > > > > > exemple la commande > > suivante : > > > > > > ra = 3.2 > > > > printf( '\nRugosit? de la surface de > > friction des labyrinthes ra = %6.1f ?m',ra*1.e6) > > > > > > donne le r?sultat suivant dans la console > > lorsqu'elle est charg? dans scilab ? partir de l'?diteur scipad : > > > > > > "Rugosit? de la surface de > > friction des labyrinthes ra = 3.2 m" > > > > > > > > > > Que puis-je faire pour obtenir le caract?re ? ? l'ex?cution du script ? > > > > Merci pour tout votre travail ! > > > > > > > > Meilleures salutations, > > > > > > > > > > > > > > > > > > > > > > Eck Jean-Michel > > > > > > > > R&D - > > Calculation Engineer > > > > > > Fives Cryomec > > AG > > > > > > > > > > > > Binningerstrasse 85a CH - 4123 Allschwil > > > > > > Switzerland > > > > > > > > Phone : +41 61 487 33 41 > > - Fax : +41 61 487 33 99 > > > > > > Mailto : > > jean-michel.eck at fivesgroup.com > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry.cardiff at gmail.com Mon Sep 22 23:57:17 2008 From: barry.cardiff at gmail.com (Barry Cardiff) Date: Mon, 22 Sep 2008 22:57:17 +0100 Subject: Leaving SVN to GIT Message-ID: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> Hi, I'm not a regular contributor to this dist list, and in fact only discovered scilab a couple of weeks ago so feel free to ignore my feelings on this subject - I do however have 15 years experience in software development and have used many version control tools along the way. I'm hoping to use scilab and to help with its development, but I'm concerned about this potential move to GIT for a number of reasons: - I, like many potential developers, am a windows user and am very happy with SVN (i.e. tortoise SVN) and don't wish to learn yet another version control tool. - Why? lets face it, many of us have worked on large software projects (as big or bigger than scilab) using SVN with no problems, - its track record is very impressive - the same can't (yet) be said for GIT. I feel that there should be a very compelling reason to move away from SVN and right now I don't see one. - OK, haven't not use a distributed version control system, I'm guilty of not fully understanding the work flow - but I can't help thinking that its a bit over-the-top and will lead to mass confusion. What we need prior to making a firm decision on this is a document that clearly illustrates the desired work flow, pointing out how GIT enables this work flow and how SVN doesn't. Further to this a discussion on you vision for the future work flow is also necessary. Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Tue Sep 23 00:45:18 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 00:45:18 +0200 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> Message-ID: <1222123518.4063.45.camel@zlarin.inria.fr> Hello Barry, Nice to have new people coming into the discussion. ;) (Jonathan, I am also trying to answer to your questions in this email) First, if you have time, listening Linus talking about git is a pleasure: http://www.youtube.com/watch?v=4XpnKHJAok8 > What we need prior to making a firm decision on this is a document > that clearly illustrates the desired work flow, pointing out how GIT > enables this work flow and how SVN doesn't. Further to this a > discussion on you vision for the future work flow is also necessary. Moving to git is not for fun or to be fashion. It has a cost and it is harder than SVN to use. Our main concern here is more about organisation than technical. The gap between version 4.X & 5.0 was much too long. We don't want to reproduce the same "mistake". Therefor, we need to be able to work on two versions in the meantime. For the next year and half coming, we will be working on three versions: The 5.0.X, 5.X and 6.0 Keeping track of changes, we need to push the changes from one version to the other but we also need a new structure. Let me take an example. We have a few people who are currently working on rewriting the core of Scilab (rewriting gateways, memory management, parser, etc). We obviously cannot put these changes into the current trunk of Scilab. It is a long work. But we do need a few things: * this stuff must be synchronized with the actual trunk (bug fix, new features) * let other people get access to this branch. For example, I am not working on this for now but I would like to be able to checkout this and use for some experiments (I love getting seg faults ;). * we can experiment stuffs quickly and easily together. An other example, I am going to work on a new Scilab-MPI version. Yann Collette asked me to have a look asap on this. Thanks to git, I will just have to publish my branch and that's it. I won't have to worry to sync with the main trunk and the v6.X version (I will probably needs improvement from both). Of course, I won't compare Scilab with the Linux Kernel but I like the idea of organisation which drives the dev of Linux. Sorry for the URL, I had a better example but I cannot find it right now [1]: http://www.firstmonday.org/Issues/issue10_5/iannacci/#i3 (Don't look this graph is term of person but more in term of "version"). If I am unclear here, let me know :) About the fact that there is no good click-click-double-clik Windows client for Git, I admit that it is an issue... but not a blocker issue for us (at least for now). Sylvestre [1] Well, I am lying here, I know a better one but it is in a video: http://www.free-electrons.com/pub/video/2008/ols/ols2008-james-bottomley-git.ogg From sylvestre.ledru at scilab.org Tue Sep 23 09:40:21 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 09:40:21 +0200 Subject: [Scilab-Dev] Re: Scipad / Scilab In-Reply-To: <9371b4280809220505q7d777a8cma55f30c37db5cec1@mail.gmail.com> References: <48D74EA1.9070203@fivesgroup.com> <1222071010.48d752e2d93b8@imp.free.fr> <9371b4280809220505q7d777a8cma55f30c37db5cec1@mail.gmail.com> Message-ID: <1222155621.17745.120.camel@korcula.inria.fr> Le lundi 22 septembre 2008 ? 20:05 +0800, Yung-Jang Lee a ?crit : > Hi, > > A patch related to encoding converter is prepared. This is the > results of this patch based on current SVN, > > ----------------------------------------------- > -->mprintf("?") > ? > -->mprintf("?") > ? > -->printf("measure: 1 ?m") > measure: 1 ?m > ---------------------------------------------- > > This patch already send to Sylvestre for committing. Indeed, it is my fault. I didn't want to commit his patch in the 5.0.X branch. I am going to apply Yung-Jang's patch in the trunk asap. Sylvestre From sylvestre.ledru at scilab.org Tue Sep 23 14:11:04 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 14:11:04 +0200 Subject: Proposal: SEP#5 Message-ID: <1222171864.9198.2.camel@korcula.inria.fr> Hello, I would like to add a new function in Scilab. The goal of this function is to convert old documentation XML to the current format. You will find the details into the SEP #5. Any opinion ? Sylvestre PS: note that they all are available here: http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/SEP/ -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP_5_xmlconvert5.pdf Type: application/pdf Size: 191018 bytes Desc: not available URL: From shiqi.yu at gmail.com Tue Sep 23 14:24:15 2008 From: shiqi.yu at gmail.com (Shiqi Yu) Date: Tue, 23 Sep 2008 20:24:15 +0800 Subject: Proposal: SEP#5 In-Reply-To: <1222171864.9198.2.camel@korcula.inria.fr> References: <1222171864.9198.2.camel@korcula.inria.fr> Message-ID: <296f12ef0809230524i3157c9efod08b6e2f399bb16@mail.gmail.com> Dear Sylvestre, This function is extremely useful for me! But after the xml files are converted, this function will no longer be used. I wonder if it will be better to provide it as a separate toolbox. Regards Shiqi Yu 2008/9/23 Sylvestre Ledru > Hello, > > I would like to add a new function in Scilab. > The goal of this function is to convert old documentation XML to the > current format. > You will find the details into the SEP #5. > > Any opinion ? > > Sylvestre > PS: note that they all are available here: > http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/SEP/ > > -- Shiqi Yu Shenzhen Institute of Advanced Technology, Chinese Academy of Sciences. Homepage: http://yushiqi.cn -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Tue Sep 23 14:28:51 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 14:28:51 +0200 Subject: [Scilab-Dev] Re: Proposal: SEP#5 In-Reply-To: <296f12ef0809230524i3157c9efod08b6e2f399bb16@mail.gmail.com> References: <1222171864.9198.2.camel@korcula.inria.fr> <296f12ef0809230524i3157c9efod08b6e2f399bb16@mail.gmail.com> Message-ID: <1222172931.9198.8.camel@korcula.inria.fr> > > But after the xml files are converted, this function will no longer > be used. > I wonder if it will be better to provide it as a separate toolbox. Yep, you are right. As a toolbox would be better. Thanks for the input. Sylvestre From yjlee123 at gmail.com Tue Sep 23 15:10:48 2008 From: yjlee123 at gmail.com (Yung-Jang Lee) Date: Tue, 23 Sep 2008 21:10:48 +0800 Subject: [Scilab-Dev] Re: Scipad / Scilab In-Reply-To: <1222155621.17745.120.camel@korcula.inria.fr> References: <48D74EA1.9070203@fivesgroup.com> <1222071010.48d752e2d93b8@imp.free.fr> <9371b4280809220505q7d777a8cma55f30c37db5cec1@mail.gmail.com> <1222155621.17745.120.camel@korcula.inria.fr> Message-ID: <9371b4280809230610i1e3bc336x7e5ec2db5c19ef83@mail.gmail.com> Sylvestre, Since I have change the internal charset encoding of C/C++ in Sicalb5 form system locale to UTF in the patch I send to you, this may have some side effects to other components. I myself consider it ought to be more careful to apply this patch. So if you need time to integrate this patch, don't be rushed. Regards, YungLee 2008/9/23 Sylvestre Ledru > Le lundi 22 septembre 2008 ? 20:05 +0800, Yung-Jang Lee a ?crit : > > Hi, > > > > A patch related to encoding converter is prepared. This is the > > results of this patch based on current SVN, > > > > ----------------------------------------------- > > -->mprintf("?") > > ? > > -->mprintf("?") > > ? > > -->printf("measure: 1 ?m") > > measure: 1 ?m > > ---------------------------------------------- > > > > This patch already send to Sylvestre for committing. > Indeed, it is my fault. I didn't want to commit his patch in the 5.0.X > branch. > I am going to apply Yung-Jang's patch in the trunk asap. > > Sylvestre > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Tue Sep 23 15:15:16 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 15:15:16 +0200 Subject: [Scilab-Dev] Re: Scipad / Scilab In-Reply-To: <9371b4280809230610i1e3bc336x7e5ec2db5c19ef83@mail.gmail.com> References: <48D74EA1.9070203@fivesgroup.com> <1222071010.48d752e2d93b8@imp.free.fr> <9371b4280809220505q7d777a8cma55f30c37db5cec1@mail.gmail.com> <1222155621.17745.120.camel@korcula.inria.fr> <9371b4280809230610i1e3bc336x7e5ec2db5c19ef83@mail.gmail.com> Message-ID: <1222175716.9198.15.camel@korcula.inria.fr> Le mardi 23 septembre 2008 ? 21:10 +0800, Yung-Jang Lee a ?crit : > Sylvestre, > > Since I have change the internal charset encoding of C/C++ in Sicalb5 > form system locale to UTF in the patch I send to you, this may have > some side effects to other components. I myself consider it ought to > be more careful to apply this patch. So if you need time to > integrate this patch, don't be rushed. It is going to be incorporated soon the current trunk which will become the version 5.1... Sylvestre From sylvestre.ledru at scilab.org Tue Sep 23 17:17:32 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 17:17:32 +0200 Subject: [Scilab-Dev] Re: Proposal: SEP#5 In-Reply-To: <296f12ef0809230524i3157c9efod08b6e2f399bb16@mail.gmail.com> References: <1222171864.9198.2.camel@korcula.inria.fr> <296f12ef0809230524i3157c9efod08b6e2f399bb16@mail.gmail.com> Message-ID: <1222183052.9198.43.camel@korcula.inria.fr> Le mardi 23 septembre 2008 ? 20:24 +0800, Shiqi Yu a ?crit : > Dear Sylvestre, > > This function is extremely useful for me! > > But after the xml files are converted, this function will no longer > be used. > I wonder if it will be better to provide it as a separate toolbox. If you want to play with it before the toolbox is ready, here is the patch. You need to apply this patch in the base directory of the source tree: $ ./config.status $ make $ ./bin/scilab -nw -e 'XMLConvert5("/your/path/to/sivp-0.4.3/man/mat2gray.xml","/tmp/plop.xml")' Note: * it has to go to the java to work. It is why we have to use GIWS here. (ie: auto generated code). * this patch is not for Microsoft Visual (TM)(C). Sylvestre -------------- next part -------------- A non-text attachment was scrubbed... Name: XMLConvert5.diff Type: text/x-patch Size: 25083 bytes Desc: not available URL: From ycollette at free.fr Tue Sep 23 19:52:27 2008 From: ycollette at free.fr (Collette Yann) Date: Tue, 23 Sep 2008 19:52:27 +0200 Subject: Problem with current trunk ? Message-ID: <48D92CDB.5000401@free.fr> Hello, I think there is a little problem with the current trunk: gcc -DHAVE_CONFIG_H -I. -I../../modules/core/includes -I./includes/ -I../../modules/output_stream/includes/ -g -O2 -pipe -Wformat -Wshadow -Wfloat-equal -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-noreturn -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wwrite-strings -Winline -Wredundant-decls -Wall -Wchar-subscripts -Wextra -Wuninitialized -Wno-format-y2k -Wmissing-format-attribute -Wno-missing-field-initializers -Wno-strict-aliasing -Wold-style-definition -g3 -fdiagnostics-show-option -fno-stack-protector -Dlinux -DNARROWPROTO -I../../modules/core/includes/ -I../../libs/MALLOC/includes/ -I../../modules/localization/includes/ -MT libsciinteger_la-i_nextj.lo -MD -MP -MF .deps/libsciinteger_la-i_nextj.Tpo -c src/c/i_nextj.c -fPIC -DPIC -o .libs/libsciinteger_la-i_nextj.o In file included from src/c/genmin2.h:18, from src/c/genmin2.c:13: ./includes/def.h:19: erreur: conflicting types for ?integer? ../../modules/core/includes/machine.h:471: erreur: previous declaration of ?integer? was here In file included from src/c/i_nextj.h:18, from src/c/i_nextj.c:13: ./includes/def.h:19: erreur: conflicting types for ?integer? ../../modules/core/includes/machine.h:471: erreur: previous declaration of ?integer? was here make[2]: *** [libsciinteger_la-genmin2.lo] Erreur 1 src/c/i_nextj.c: In function ?inextj_?: src/c/i_nextj.c:83: attention : passing argument 5 of ?gengetcol? from incompatible pointer type src/c/i_nextj.c:83: attention : passing argument 6 of ?gengetcol? from incompatible pointer type src/c/i_nextj.c:88: attention : passing argument 5 of ?gengetcol? from incompatible pointer type src/c/i_nextj.c:88: attention : passing argument 6 of ?gengetcol? from incompatible pointer type make[2]: *** [libsciinteger_la-i_nextj.lo] Erreur 1 make[2]: quittant le r?pertoire ? /home/collette/scilab-dev/scilab/modules/integer ? make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le r?pertoire ? /home/collette/scilab-dev/scilab/modules ? make: *** [all-recursive] Erreur 1 YC From sylvestre.ledru at scilab.org Tue Sep 23 23:48:45 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 23 Sep 2008 23:48:45 +0200 Subject: [Scilab-Dev] Problem with current trunk ? In-Reply-To: <48D92CDB.5000401@free.fr> References: <48D92CDB.5000401@free.fr> Message-ID: <1222206525.4063.53.camel@zlarin.inria.fr> > ./includes/def.h:19: erreur: conflicting types for ?integer? Yep, I removed the useles typedef integer (replaced to int) but I didn't commit everything. It should be now OK (r 27807). Sylvestre From ycollet at freesurf.fr Wed Sep 24 09:40:47 2008 From: ycollet at freesurf.fr (ycollet at freesurf.fr) Date: Wed, 24 Sep 2008 09:40:47 +0200 Subject: SEP: Object oriented programming under scilab Message-ID: <20080924094047.308274u1zzu5dyww@horde.freesurf.fr> Hello, You will find in this SEP some thoughts related to object oriented programming under scilab: what do we need to be able to start building objects under Scilab. This is a first version. I am waiting for a lot of comments ... Your sincerely, Yann COLLETTE -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP_Object.pdf Type: application/pdf Size: 98883 bytes Desc: not available URL: From ycollet at freesurf.fr Wed Sep 24 09:44:59 2008 From: ycollet at freesurf.fr (ycollet at freesurf.fr) Date: Wed, 24 Sep 2008 09:44:59 +0200 Subject: SEP: linpro replacement Message-ID: <20080924094459.12761fply6ie1t7o@horde.freesurf.fr> Hello again, Here is a new SEP related to add a new linear programming tool under Scilab. This new tool is based on CLP (which is a C++ library downloadable at http://www.coin-or.org). This linear programming library can do mixed integer programming, supports sparse matrixes and was before 2004 a commercial product from IBM (OSL). This library was competing (and is still competing) with CPLEX. An interface has been designed between CLP and Scilab. I am currently converting it for scilab-5.0 and for windows (it has been tested under linux / scilab-4.1.2). Has soon as a new version will be available, I will post this new package on the contrib. Your sincerely, Yann COLLETTE -------------- next part -------------- A non-text attachment was scrubbed... Name: SEP_CLP.pdf Type: application/pdf Size: 81153 bytes Desc: not available URL: From enrico.segre at weizmann.ac.il Wed Sep 24 09:49:14 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Wed, 24 Sep 2008 10:49:14 +0300 Subject: [Scilab-Dev] SEP: Object oriented programming under scilab In-Reply-To: <20080924094047.308274u1zzu5dyww@horde.freesurf.fr> References: <20080924094047.308274u1zzu5dyww@horde.freesurf.fr> Message-ID: <48D9F0FA.9060803@weizmann.ac.il> > This is a first version. I am waiting for a lot of comments ... > Relation with http://wiki.scilab.org/emulateOO-1 , which appeared yesterday and goes along the same lines? Enrico From ycollet at freesurf.fr Wed Sep 24 15:35:26 2008 From: ycollet at freesurf.fr (ycollet at freesurf.fr) Date: Wed, 24 Sep 2008 15:35:26 +0200 Subject: [Scilab-Dev] SEP: Object oriented programming under scilab In-Reply-To: <48D9F0FA.9060803@weizmann.ac.il> References: <20080924094047.308274u1zzu5dyww@horde.freesurf.fr> <48D9F0FA.9060803@weizmann.ac.il> Message-ID: <20080924153526.11841shyi67bdhr4@webmail-html.freesurf.fr> Hello, Yes, I have looked at this page. I had also M. Baudin at the phone yesterday. It seems that we wrote our documents independantly. I finally decided to post my SEP to the list to gather new comments (I hope) and if these comments are good, they will be included in the emulateOO-1 ASAP. Yann Enrico Segre a ?crit?: > >> This is a first version. I am waiting for a lot of comments ... >> > > Relation with http://wiki.scilab.org/emulateOO-1 , which appeared > yesterday and goes along the same lines? > > Enrico > -- Transmis via le Webmail FreeSurf: http://www.freesurf.fr From barry.cardiff at gmail.com Wed Sep 24 22:33:52 2008 From: barry.cardiff at gmail.com (Barry Cardiff) Date: Wed, 24 Sep 2008 21:33:52 +0100 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: <1222123518.4063.45.camel@zlarin.inria.fr> References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> Message-ID: <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> Hi, Yes Linus certainly seems to have strong views on the subject, but lets not loose sight of a couple of things: - Linux (for some reason) had to change version control system from bitkeeper anyway - Scilab doesn't - by Linus' own admission SVN works and works well for many complex projects. Don't get me wrong, in a perfect world, I'd say 'go for it' so long as the workflow and responsibilities are clearly defined. It does appear to be a technically a better solution but we have to be careful not to do something that raises the barrier to entry for part-time scilab contributors to a point where they'll just not bother. One of Scilab's strengths is that MS visual studio express is a supported development environment making the addition of new code pretty easy - I fear that moving to GIT will turn off some windows developers. With regard to you 'workflow' examples, I don't see any problems using branching on SVN to achieve the desired result. With a branch one team can work independently from the others on some new 'rdically different' code whilst allowing others to see (and use) this 'work in progress', without effecting the main trunk. Furthermore it is possible to 'cherrypick' changes (bug fixes / new features) on the trunk to be replicated on the branch as required. Despite what Linus claims in his talk - all merging is a painful process - there will always be conflicts. What I fear is that (unlike Linux, where Linus is the boss) we'll end up in a situation where lots of people will have perfectly good trunks but yet at some point we'll need to make a single binary release and these two situations are at odds with each other, and its not clear to me how they be resolved. Barry 2008/9/22 Sylvestre Ledru > Hello Barry, > > Nice to have new people coming into the discussion. ;) > (Jonathan, I am also trying to answer to your questions in this email) > > First, if you have time, listening Linus talking about git is a > pleasure: http://www.youtube.com/watch?v=4XpnKHJAok8 > > > What we need prior to making a firm decision on this is a document > > that clearly illustrates the desired work flow, pointing out how GIT > > enables this work flow and how SVN doesn't. Further to this a > > discussion on you vision for the future work flow is also necessary. > Moving to git is not for fun or to be fashion. It has a cost and it is > harder than SVN to use. > > Our main concern here is more about organisation than technical. > > The gap between version 4.X & 5.0 was much too long. We don't want to > reproduce the same "mistake". Therefor, we need to be able to work on > two versions in the meantime. > > For the next year and half coming, we will be working on three versions: > The 5.0.X, 5.X and 6.0 > Keeping track of changes, we need to push the changes from one version > to the other but we also need a new structure. > > Let me take an example. > We have a few people who are currently working on rewriting the core of > Scilab (rewriting gateways, memory management, parser, etc). > We obviously cannot put these changes into the current trunk of Scilab. > It is a long work. > But we do need a few things: > * this stuff must be synchronized with the actual trunk (bug fix, new > features) > * let other people get access to this branch. For example, I am not > working on this for now but I would like to be able to checkout this and > use for some experiments (I love getting seg faults ;). > * we can experiment stuffs quickly and easily together. An other > example, I am going to work on a new Scilab-MPI version. Yann Collette > asked me to have a look asap on this. Thanks to git, I will just have to > publish my branch and that's it. I won't have to worry to sync with the > main trunk and the v6.X version (I will probably needs improvement from > both). > > Of course, I won't compare Scilab with the Linux Kernel but I like the > idea of organisation which drives the dev of Linux. Sorry for the URL, I > had a better example but I cannot find it right now [1]: > http://www.firstmonday.org/Issues/issue10_5/iannacci/#i3 > (Don't look this graph is term of person but more in term of "version"). > If I am unclear here, let me know :) > > About the fact that there is no good click-click-double-clik Windows > client for Git, I admit that it is an issue... but not a blocker issue > for us (at least for now). > > Sylvestre > > [1] Well, I am lying here, I know a better one but it is in a video: > > http://www.free-electrons.com/pub/video/2008/ols/ols2008-james-bottomley-git.ogg > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BlanchardJ at ieee.org Thu Sep 25 00:36:52 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Wed, 24 Sep 2008 19:36:52 -0300 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> Message-ID: Although I am not a Scilab developer and do not contribute I do have a bit of a concern about git. To resume, perhaps a bit bluntly, my attempt at looking at git I came to the same conclusion I did when I first tried Linux. It's a very powerful piece of software for sure but it is also a huge badly documented mess. I'm really sorry but like a lot of stuff in the opensource community it seem like if it was written for the people coding it. Now over with the rambling, on the other side git seem to be oriented toward extremely non-linear project where branch and merge are common especially between branch. The idea of branching is generally not to break the trunk but on the other hand having all the work in progress in different branch is the same thing to users. They do not have access to the pseudo Trunk wich is no longer the HEAD but a combination sof countless branches. Just looking at what project use svn, gcc and Openoffice come to mind as some of the largest project I know using svn. We can see from these projects some successful use of the branch-merge pattern of svn[1]. All in all, not to discourage anything as I won't be profoundly affected by the switch to git I do believe that git shift the difficulty of working with a distributed revision system from the projects managers toward the users and collaborators. ---- [1] Ok, Openoffice might not be a good example as they use the entire CollabNET framework and svn is only a part of it. Jonathan Blanchard From sylvestre.ledru at scilab.org Fri Sep 26 20:42:39 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Fri, 26 Sep 2008 20:42:39 +0200 Subject: [Scilab-Dev] GMP/MPFR and scilab. In-Reply-To: <1221922859.9808.15.camel@zlarin.inria.fr> References: <48CA947E.5000207@freesurf.fr> <1221458525.7300.41.camel@zlarin> <20080916083400.1450728b34thwqkg@webmail-html.freesurf.fr> <1221764790.3747.6.camel@zlarin.inria.fr> <48D2ABE3.4090704@free.fr> <1221766702.3747.14.camel@zlarin.inria.fr> <48D2AEF7.9030908@free.fr> <1221767430.3747.26.camel@zlarin.inria.fr> <48D345F2.2060307@free.fr> <1221922859.9808.15.camel@zlarin.inria.fr> Message-ID: <1222454559.9198.267.camel@korcula.inria.fr> Le samedi 20 septembre 2008 ? 17:00 +0200, Sylvestre Ledru a ?crit : > Le vendredi 19 septembre 2008 ? 08:25 +0200, Fran?ois Vogel a ?crit : > > Sylvestre Ledru said on 18/09/2008 21:50: > > > For the version 5.0.2, by the end of the month. For the 5.1, december > > > normally. > > > > Valuable bits of information, thanks. > You are welcome. We are also going to publish the detailled roadmap (at > least for the 5.0.2 & 5.1)... Next week normally. Not this week finally. Sorry. Sylvestre From BlanchardJ at ieee.org Sat Sep 27 16:18:04 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Sat, 27 Sep 2008 11:18:04 -0300 Subject: Scilab MALLOC function. Message-ID: Quick question. Can we assume that the scilab MALLOC function work the same way as the standard malloc. More precisely, is the pointer returned by MALLOC always going to be valid until freed? Jonathan Blanchard From ycollette at free.fr Sat Sep 27 12:59:38 2008 From: ycollette at free.fr (Collette Yann) Date: Sat, 27 Sep 2008 12:59:38 +0200 Subject: trunk not compilatble Message-ID: <48DE121A.4040801@free.fr> Hello, The trunk is currently not compilable. Here is the error message: mkdir .libs gcc -g -O2 -pipe -Wformat -Wshadow -Wfloat-equal -Wpointer-arith -Wcast-align -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wmissing-noreturn -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wwrite-strings -Winline -Wredundant-decls -Wall -Wchar-subscripts -Wextra -Wuninitialized -Wno-format-y2k -Wmissing-format-attribute -Wno-missing-field-initializers -Wno-strict-aliasing -Wold-style-definition -g3 -fdiagnostics-show-option -fno-stack-protector -Dlinux -DNARROWPROTO -I./modules/core/includes/ -I./libs/MALLOC/includes/ -I./modules/localization/includes/ -o .libs/scilab-bin scilab_bin-main_linux.o -L/usr/lib -L/usr/lib/sse2 ./modules/.libs/libscilab.so ./modules/shell/.libs/libscishell.so ./modules/localization/.libs/libscilocalization.so ./modules/core/.libs/libscicore.so -Wl,--rpath -Wl,/local/stow/scilab-5//lib/scilab /usr/bin/ld: warning: libjava.so, needed by ./modules/shell/.libs/libscishell.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libverify.so, needed by ./modules/shell/.libs/libscishell.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libjvm.so, needed by ./modules/shell/.libs/libscishell.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libhpi.so, needed by ./modules/shell/.libs/libscishell.so, not found (try using -rpath or -rpath-link) /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `CreatePrettyGradsFromNax' /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `AllocUserGrads' /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `buildTListForTicks' /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `FreeUserLabels' /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `AllocAndSetUserLabelsFromMdl' /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: undefined reference to `CopyUserGrads' collect2: ld returned 1 exit status make[1]: *** [scilab-bin] Erreur 1 make[1]: quittant le r?pertoire ? /home/collette/scilab-dev/scilab ? YC From sylvestre.ledru at scilab.org Sat Sep 27 21:17:02 2008 From: sylvestre.ledru at scilab.org (sylvestre.ledru at scilab.org) Date: Sat, 27 Sep 2008 21:17:02 +0200 Subject: [Scilab-Dev] Scilab MALLOC function. In-Reply-To: References: Message-ID: <68e784e9445b96bd2daaeeca7382ec2f@localhost> On Sat, 27 Sep 2008 11:18:04 -0300, "Jonathan Blanchard" wrote: > Quick question. Can we assume that the scilab MALLOC function work the > same way as the standard malloc. More precisely, is the pointer > returned by MALLOC always going to be valid until freed? Under Linux, in Scilab, it is calling the standard malloc: http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/libs/MALLOC/src/sci_mem_alloc.c?revision=26187&view=markup no more. Under Windows, we are using heap functions because it is faster. I am showing off here ;). I am just repeating what Allan explained me (our Windows specialist) Sylvestre From sylvestre.ledru at scilab.org Sat Sep 27 21:20:34 2008 From: sylvestre.ledru at scilab.org (sylvestre.ledru at scilab.org) Date: Sat, 27 Sep 2008 21:20:34 +0200 Subject: [Scilab-Dev] trunk not compilatble In-Reply-To: <48DE121A.4040801@free.fr> References: <48DE121A.4040801@free.fr> Message-ID: Jb (Silvy) did some cleanup on the graphic... but seems he has been too violent! Revert to an older revision; We will fix this on monday. Sylvestre On Sat, 27 Sep 2008 12:59:38 +0200, Collette Yann wrote: > Hello, > > The trunk is currently not compilable. Here is the error message: > > > mkdir .libs > gcc -g -O2 -pipe -Wformat -Wshadow -Wfloat-equal -Wpointer-arith > -Wcast-align -Wmissing-prototypes -Wmissing-declarations > -Wstrict-prototypes -Wmissing-noreturn -Wendif-labels -Wpointer-arith > -Wbad-function-cast -Wcast-qual -Wwrite-strings -Winline > -Wredundant-decls -Wall -Wchar-subscripts -Wextra -Wuninitialized > -Wno-format-y2k -Wmissing-format-attribute > -Wno-missing-field-initializers -Wno-strict-aliasing > -Wold-style-definition -g3 -fdiagnostics-show-option > -fno-stack-protector -Dlinux -DNARROWPROTO -I./modules/core/includes/ > -I./libs/MALLOC/includes/ -I./modules/localization/includes/ -o > .libs/scilab-bin scilab_bin-main_linux.o -L/usr/lib -L/usr/lib/sse2 > ./modules/.libs/libscilab.so ./modules/shell/.libs/libscishell.so > ./modules/localization/.libs/libscilocalization.so > ./modules/core/.libs/libscicore.so -Wl,--rpath > -Wl,/local/stow/scilab-5//lib/scilab > /usr/bin/ld: warning: libjava.so, needed by > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > -rpath-link) > /usr/bin/ld: warning: libverify.so, needed by > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > -rpath-link) > /usr/bin/ld: warning: libjvm.so, needed by > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > -rpath-link) > /usr/bin/ld: warning: libhpi.so, needed by > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > -rpath-link) > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `CreatePrettyGradsFromNax' > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `AllocUserGrads' > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `buildTListForTicks' > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `FreeUserLabels' > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `AllocAndSetUserLabelsFromMdl' > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > undefined reference to `CopyUserGrads' > collect2: ld returned 1 exit status > make[1]: *** [scilab-bin] Erreur 1 > make[1]: quittant le r?pertoire ? /home/collette/scilab-dev/scilab ? > > > YC From BlanchardJ at ieee.org Sat Sep 27 21:50:46 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Sat, 27 Sep 2008 16:50:46 -0300 Subject: [Scilab-Dev] Scilab MALLOC function. In-Reply-To: <68e784e9445b96bd2daaeeca7382ec2f@localhost> References: <68e784e9445b96bd2daaeeca7382ec2f@localhost> Message-ID: Oh ok. So if we use MALLOC it does not consume the Scilab stack space? I'm asking this because I hacked myself a way to use gmp in Scilab and I was trying to override the gmp memory management functions to use the Scilab stack space instead. Jonathan Blanchard On Sat, Sep 27, 2008 at 4:17 PM, wrote: > > > On Sat, 27 Sep 2008 11:18:04 -0300, "Jonathan Blanchard" > wrote: >> Quick question. Can we assume that the scilab MALLOC function work the >> same way as the standard malloc. More precisely, is the pointer >> returned by MALLOC always going to be valid until freed? > Under Linux, in Scilab, it is calling the standard malloc: > http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/scilab/libs/MALLOC/src/sci_mem_alloc.c?revision=26187&view=markup > no more. > > Under Windows, we are using heap functions because it is faster. I am > showing off here ;). I am just repeating what Allan explained me > (our Windows specialist) > > Sylvestre > > > From sylvestre.ledru at scilab.org Sun Sep 28 13:01:11 2008 From: sylvestre.ledru at scilab.org (sylvestre.ledru at scilab.org) Date: Sun, 28 Sep 2008 13:01:11 +0200 Subject: [Scilab-Dev] Scilab MALLOC function. In-Reply-To: References: <68e784e9445b96bd2daaeeca7382ec2f@localhost> Message-ID: > Oh ok. So if we use MALLOC it does not consume the Scilab stack space? Indeed, it does not. CreateVarFromPtr and the functions defined in stack3 are. Sylvestre From fvogelnew1 at free.fr Sun Sep 28 22:55:41 2008 From: fvogelnew1 at free.fr (=?ISO-8859-1?Q?Fran=E7ois_Vogel?=) Date: Sun, 28 Sep 2008 22:55:41 +0200 Subject: and idea for the development of Scipad In-Reply-To: <48DFB0AF.20308@broadpark.no> References: <48DFB0AF.20308@broadpark.no> Message-ID: <48DFEF4D.80204@free.fr> Hi Tobj?rn, Your idea looks interesting to me, thanks for submitting it. I have a few comments on this. At the first place I'm wondering if having your idea implemented in Scipad would not provide the user with a feature that few of them will use. Is it not too specific? After all, Scilab and Matlab are different, and we already have a function head_comments in Scilab. Also, having documentation of a function in both its header comments and in an xml file will sooner or later lead to sync issues between these two. For that reason I'm not sure it is desirable. On the practical side I'm wondering about implementation. Indeed, the Scipad menu entry "File/Create help skeleton" basically is a wrapper around the Scilab function help_skeleton. It is easy to call another function instead of help_skeleton. You can see the details in proc helpskeleton (in file scilabexec.tcl). Calling help_from_sci instead of help_skeleton is straightforward. However, first of all I would add another entry in the file menu (e.g. "File/Create help from function header comments" or something alike), rather than replacing the existing entry. Some users would like to keep the vanilla help_skeleton perhaps. Then, function help_from_sci must be known by Scilab. Two ways: 1) check for presence of your contrib to enable or not the new entry in the File menu 2) include this function in Scilab Proposition 2) could be done either by including it in the help module (would be the best place I think), or alternatively in the Scipad module itself. Licenses to be checked if in help module, no problem in scipad module (which is GPL, as your contrib is). I have not yet looked at help_from_sci more than very cursively, but I will soon try it in practice. As a first step I would like to open the discussion about your proposal to other people. That's why I cc the developers mailing list on this, I hope you will forgive me to do so without first consulting you. Some people on the dev list perhaps have basic things to say about it, for instance on the principle of having comments in both function headers and xml files. Also, the opteam could state whether they consider your function help_from_sci as a feature they could integrate in the help module (if you agree, obviously). Finally, especially Enrico, who is maintaining Scipad with me, may have an opinion on this. Thanks, Francois Torbj?rn Pettersen said on 28/09/2008 18:28: > Hi Francois Vogel > I just noticed a nice feature in your excellent SciPad editor - the File > - Create help_skeleton function, which I guess runs the current open > file through the help_skeleton function in Scilab. > > I was wondering - is it easy to make Scipad use an alternative function > to help_skeleton for the generation of the xml help file? > > The reason I ask is that I have created a modified version of > help_skeleton which is based on the idea that help files > should preferably be written and maintained as part of the scilab source > file. > As a former matlab user I find it annoying to have to maintain both a > .sci and a .xml file for every function I write. > > The revised function called help_from_sci, which is part of a recently > uploaded toolbox > http://www.scilab.org/contrib/index_contrib.php?page=displayContribution&fileID=1145 > > generates a complete .xml help file based on the initial comment section > of the .sci source file - much in the same way as matlab does. > In order to format the .xml file correctly some key words should be used > when writing the documentation section. > If it was possible to run help_from_sci directly from SciPad it would > provide a quick verification that the automatically generated xml files > looks as intended. > > -Regards > Torbj?rn. > From sylvestre.ledru at scilab.org Sun Sep 28 23:40:41 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Sun, 28 Sep 2008 23:40:41 +0200 Subject: [Scilab-Dev] trunk not compilatble In-Reply-To: References: <48DE121A.4040801@free.fr> Message-ID: <1222638041.3416.18.camel@zlarin> I fixed it with a temporary fix (r 27944) Sylvestre Le samedi 27 septembre 2008 ? 21:20 +0200, sylvestre.ledru at scilab.org a ?crit : > Jb (Silvy) did some cleanup on the graphic... but seems he has been too > violent! > Revert to an older revision; We will fix this on monday. > > > Sylvestre > > > > On Sat, 27 Sep 2008 12:59:38 +0200, Collette Yann > wrote: > > Hello, > > > > The trunk is currently not compilable. Here is the error message: > > > > > > mkdir .libs > > gcc -g -O2 -pipe -Wformat -Wshadow -Wfloat-equal -Wpointer-arith > > -Wcast-align -Wmissing-prototypes -Wmissing-declarations > > -Wstrict-prototypes -Wmissing-noreturn -Wendif-labels -Wpointer-arith > > -Wbad-function-cast -Wcast-qual -Wwrite-strings -Winline > > -Wredundant-decls -Wall -Wchar-subscripts -Wextra -Wuninitialized > > -Wno-format-y2k -Wmissing-format-attribute > > -Wno-missing-field-initializers -Wno-strict-aliasing > > -Wold-style-definition -g3 -fdiagnostics-show-option > > -fno-stack-protector -Dlinux -DNARROWPROTO -I./modules/core/includes/ > > -I./libs/MALLOC/includes/ -I./modules/localization/includes/ -o > > .libs/scilab-bin scilab_bin-main_linux.o -L/usr/lib -L/usr/lib/sse2 > > ./modules/.libs/libscilab.so ./modules/shell/.libs/libscishell.so > > ./modules/localization/.libs/libscilocalization.so > > ./modules/core/.libs/libscicore.so -Wl,--rpath > > -Wl,/local/stow/scilab-5//lib/scilab > > /usr/bin/ld: warning: libjava.so, needed by > > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > > -rpath-link) > > /usr/bin/ld: warning: libverify.so, needed by > > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > > -rpath-link) > > /usr/bin/ld: warning: libjvm.so, needed by > > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > > -rpath-link) > > /usr/bin/ld: warning: libhpi.so, needed by > > ./modules/shell/.libs/libscishell.so, not found (try using -rpath or > > -rpath-link) > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `CreatePrettyGradsFromNax' > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `AllocUserGrads' > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `buildTListForTicks' > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `FreeUserLabels' > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `AllocAndSetUserLabelsFromMdl' > > > /home/collette/scilab-dev/scilab/modules/graphics/.libs/libscigraphics.so.5: > > undefined reference to `CopyUserGrads' > > collect2: ld returned 1 exit status > > make[1]: *** [scilab-bin] Erreur 1 > > make[1]: quittant le r?pertoire ? /home/collette/scilab-dev/scilab ? > > > > > > YC > From pierre.marechal at scilab.org Mon Sep 29 10:59:53 2008 From: pierre.marechal at scilab.org (Pierre MARECHAL) Date: Mon, 29 Sep 2008 10:59:53 +0200 Subject: Scilab 5.0.2 is released ! Message-ID: <48E09909.5030509@scilab.org> Hello, The Scilab Team is pleased to announce the release of Scilab 5.0.2. Misc information about this version: http://www.scilab.org/download/index_download.php?page=5.0.2 Main changes between Scilab 4 & Scilab 5 : http://www.scilab.org/changes_5/ Changes between Scilab 5.0.1 & Scilab 5.0.2 : http://www.scilab.org/download/index_download.php?page=CHANGES_5.0.2 The release notes : http://www.scilab.org/download/index_download.php?page=RELEASE_NOTES_5.0.2 Pierre -- ============================================== Pierre MARECHAL INRIA - Unit? de Recherche de Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex ============================================== Projet Scilab B?timent 1B - Bureau 008 Email : pierre.marechal at scilab.org ============================================== From torbjorn.pettersen at broadpark.no Mon Sep 29 18:37:37 2008 From: torbjorn.pettersen at broadpark.no (=?ISO-8859-1?Q?Torbj=F8rn_Pettersen?=) Date: Mon, 29 Sep 2008 18:37:37 +0200 Subject: and idea for the development of Scipad In-Reply-To: <48DFEF4D.80204@free.fr> References: <48DFB0AF.20308@broadpark.no> <48DFEF4D.80204@free.fr> Message-ID: <48E10451.5030601@broadpark.no> Fran?ois Vogel skrev: > Hi Tobj?rn, > > Your idea looks interesting to me, thanks for submitting it. I have a > few comments on this. > > > At the first place I'm wondering if having your idea implemented in > Scipad would not provide the user with a feature that few of them will > use. Is it not too specific? After all, Scilab and Matlab are > different, and we already have a function head_comments in Scilab. > > Also, having documentation of a function in both its header comments > and in an xml file will sooner or later lead to sync issues between > these two. For that reason I'm not sure it is desirable. Hi Fran?ois I think all your points are valid. It doesn't make much sense to use help_from_sci() if one later intends to edit the xml help file. My idea is that documentation could be written and maintained as part of the head_comment section of the .sci file, and that help_from_sci should be used for generation of the final xml files. This would eliminate any sync issues. In terms of arguments for adding another help related function to Scilab I'm on very thin ice, especially since I was not aware of the "head_comments" function :-) So adding yet another help function is not something I will argue for. If one wants to include some of the functionality from help_from_sci into Scilab on a permanent basis, my suggestion is to merge the functionality into the existing help_skeleton function. This would avoid any new functions being introduced. > > > On the practical side I'm wondering about implementation. > > Indeed, the Scipad menu entry "File/Create help skeleton" basically is > a wrapper around the Scilab function help_skeleton. It is easy to call > another function instead of help_skeleton. You can see the details in > proc helpskeleton (in file scilabexec.tcl). Calling help_from_sci > instead of help_skeleton is straightforward. > > However, first of all I would add another entry in the file menu (e.g. > "File/Create help from function header comments" or something alike), > rather than replacing the existing entry. Some users would like to > keep the vanilla help_skeleton perhaps. This sounds interesting. I'll take a look at the tcl files. It could be a nice feature to add to the toolbox. > > Then, function help_from_sci must be known by Scilab. Two ways: > > 1) check for presence of your contrib to enable or not the new entry > in the File menu > > 2) include this function in Scilab > > Proposition 2) could be done either by including it in the help module > (would be the best place I think), or alternatively in the Scipad > module itself. Licenses to be checked if in help module, no problem in > scipad module (which is GPL, as your contrib is). > > I have not yet looked at help_from_sci more than very cursively, but I > will soon try it in practice. > > > As a first step I would like to open the discussion about your > proposal to other people. That's why I cc the developers mailing list > on this, I hope you will forgive me to do so without first consulting > you. > > Some people on the dev list perhaps have basic things to say about it, > for instance on the principle of having comments in both function > headers and xml files. > > Also, the opteam could state whether they consider your function > help_from_sci as a feature they could integrate in the help module (if > you agree, obviously). > > Finally, especially Enrico, who is maintaining Scipad with me, may > have an opinion on this. Thanks for the response - and not least for providing Scipad and Scilab! Regards, -Torbj?rn. > > Thanks, > Francois > > > Torbj?rn Pettersen said on 28/09/2008 18:28: >> Hi Francois Vogel >> I just noticed a nice feature in your excellent SciPad editor - the >> File - Create help_skeleton function, which I guess runs the current >> open file through the help_skeleton function in Scilab. >> >> I was wondering - is it easy to make Scipad use an alternative >> function to help_skeleton for the generation of the xml help file? >> >> The reason I ask is that I have created a modified version of >> help_skeleton which is based on the idea that help files >> should preferably be written and maintained as part of the scilab >> source file. >> As a former matlab user I find it annoying to have to maintain both a >> .sci and a .xml file for every function I write. >> >> The revised function called help_from_sci, which is part of a >> recently uploaded toolbox >> http://www.scilab.org/contrib/index_contrib.php?page=displayContribution&fileID=1145 >> >> generates a complete .xml help file based on the initial comment >> section of the .sci source file - much in the same way as matlab does. >> In order to format the .xml file correctly some key words should be >> used when writing the documentation section. >> If it was possible to run help_from_sci directly from SciPad it would >> provide a quick verification that the automatically generated xml >> files looks as intended. >> >> -Regards >> Torbj?rn. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Mon Sep 29 20:06:08 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Mon, 29 Sep 2008 20:06:08 +0200 Subject: pb avec la compilation. In-Reply-To: <48E116FC.2080608@free.fr> References: <48E116FC.2080608@free.fr> Message-ID: <1222711568.3301.22.camel@zlarin> On the dev ML if others have the issue: Le lundi 29 septembre 2008 ? 19:57 +0200, Collette Yann a ?crit : > Salut, > > Encore un petit pb dans le module spreadsheet: > > gcc -DHAVE_CONFIG_H -I. -I../../modules/core/includes -I./includes/ > -I./src/c/ -I./src/c/ripole -I../../libs/MALLOC/includes/ > -I../../modules/output_stream/includes -g -O2 -pipe -Wformat -Wshadow > -Wfloat-equal -Wpointer-arith -Wcast-align -Wmissing-prototypes > -Wmissing-declarations -Wstrict-prototypes -Wmissing-noreturn > -Wendif-labels -Wpointer-arith -Wbad-function-cast -Wcast-qual > -Wwrite-strings -Winline -Wredundant-decls -Wall -Wchar-subscripts > -Wextra -Wuninitialized -Wno-format-y2k -Wmissing-format-attribute > -Wno-missing-field-initializers -Wno-strict-aliasing > -Wold-style-definition -g3 -fdiagnostics-show-option > -fno-stack-protector -Dlinux -DNARROWPROTO > -I../../modules/core/includes/ -I../../libs/MALLOC/includes/ > -I../../modules/localization/includes/ -MT > libscispreadsheet_la-sci_xls_open.lo -MD -MP -MF > .deps/libscispreadsheet_la-sci_xls_open.Tpo -c > sci_gateway/c/sci_xls_open.c -o libscispreadsheet_la-sci_xls_open.o > >/dev/null 2>&1 > mv -f .deps/libscispreadsheet_la-sci_xls_open.Tpo > .deps/libscispreadsheet_la-sci_xls_open.Plo > make: *** Pas de r?gle pour fabriquer la cible ? > src/c/olestream-unwrap.c ?, n?cessaire pour ? > libscispreadsheet_la-olestream-unwrap.lo ?. Arr?t. > [collette at localhost spreadsheet]$ try $ rm -rf modules/spreadsheet/.deps && ./config.status && make it should fix your issue. I have been moving files into dedicated directories when they have been taken from thirdparty libs. Sylvestre From BlanchardJ at ieee.org Mon Sep 29 21:13:06 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Mon, 29 Sep 2008 16:13:06 -0300 Subject: Gmp in scilab revisited. Message-ID: Sorry to bother everyone on the list again about this subject. I have a question to Ledru you said yes to my question earlier but I'm not sure which. Is there any plan for gmp/mpr in scilab in the future and is there a developer currently looking at this? I also didn't listen to your warning and hacked myself a way to use gmp in scilab. Sadly because of the nature of gmp it is impossible to create a toolbox for Scilab 5 as I would have loved to create one. Anybody got feedback on this(Yann?). Jonathan Blanchard From sylvestre.ledru at inria.fr Mon Sep 29 21:18:13 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Mon, 29 Sep 2008 21:18:13 +0200 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: References: Message-ID: <1222715893.3301.27.camel@zlarin> Le lundi 29 septembre 2008 ? 16:13 -0300, Jonathan Blanchard a ?crit : > Sorry to bother everyone on the list again about this subject. > > I have a question to Ledru you said yes to my question earlier but I'm > not sure which. Is there any plan for gmp/mpr in scilab in the future > and is there a developer currently looking at this? No and no ;) At least, as far I know. Yann is the one who added this idea to the Wiki. Maybe he knows someone who is working on it. > I also didn't listen to your warning and hacked myself a way to use > gmp in scilab. Seems you did the right choice ;) > Sadly because of the nature of gmp it is impossible to > create a toolbox for Scilab 5 as I would have loved to create one. Why is it impossible ? Too tightly linked with Scilab's internal stuff? Sylvestre From BlanchardJ at ieee.org Mon Sep 29 21:28:42 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Mon, 29 Sep 2008 16:28:42 -0300 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: <1222715893.3301.27.camel@zlarin> References: <1222715893.3301.27.camel@zlarin> Message-ID: Well I mean it's manipulating a new type. I do not see a way of adding a new type in Scilab from a toolbox perspective. Anyone correct me on that. Right now my "hack" I made for myself was to use the Scilab Matrix of double as a carrier for the gmp structure. It kind of work but is not really a distributable solution. (It's also a huge party of (void*) pointer which tend to make computers crash). All in all it all come down to memory management. Gmp have a major shortcoming in that you can't deny it any memory operation so i'm using the system malloc to allocate memory. If one want the entire gmp operand to be in the scilab stack it must be copied into the Scilab stack after each operations. The operand can also stay in the heap but then the scilab clear function and everything that destroy a Scilab variabl must be sure to de-allocate the memory used by the operand. I tried to resume what I found, hope you all can understand it. Jonathan Blanchard On Mon, Sep 29, 2008 at 4:18 PM, Sylvestre Ledru wrote: > Le lundi 29 septembre 2008 ? 16:13 -0300, Jonathan Blanchard a ?crit : >> Sorry to bother everyone on the list again about this subject. >> >> I have a question to Ledru you said yes to my question earlier but I'm >> not sure which. Is there any plan for gmp/mpr in scilab in the future >> and is there a developer currently looking at this? > No and no ;) > At least, as far I know. Yann is the one who added this idea to the > Wiki. Maybe he knows someone who is working on it. > >> I also didn't listen to your warning and hacked myself a way to use >> gmp in scilab. > Seems you did the right choice ;) > >> Sadly because of the nature of gmp it is impossible to >> create a toolbox for Scilab 5 as I would have loved to create one. > Why is it impossible ? Too tightly linked with Scilab's internal stuff? > > Sylvestre > > > From ycollet at freesurf.fr Mon Sep 29 22:17:33 2008 From: ycollet at freesurf.fr (Yann COLLETTE) Date: Mon, 29 Sep 2008 22:17:33 +0200 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: <1222715893.3301.27.camel@zlarin> References: <1222715893.3301.27.camel@zlarin> Message-ID: <48E137DD.5060606@freesurf.fr> Hello, I don't know anybody currently working on this topic today. I have some idea for the interface: use the pointer type "p". With this type, you can allocate the memory required to store the gmp number. Then, you store the pointer to the memory allocated in a mlist (here, the type of the mlist is fannlist and the fann field contains the pointer). To retrieve the gmp number, use the GetRhsVar with the "p" type. Here are some examples I use in a FANN (Fast Artificle Neural Network) interface. For the basic operations like +, -, etc ..., maybe you can use overloading: for the + operator: function c = gmplist_a_gmplist(a,b) c = gmp_add(a,b); endfunction int createScilabFannStructFromCFannStruct(struct fann* ann,unsigned int StackPos) { int m_list_labels, n_list_labels; int m_fann_pointer, n_fann_pointer; int m_extra, n_extra, l_extra; //The struct field names static char *fieldnames[] = {"fannlist","fann"}; m_fann_pointer = 1; n_fann_pointer = 1; m_extra = 2; n_extra = 1; CreateVar(StackPos, "m", &m_extra, &n_extra, &l_extra); m_list_labels = 2; n_list_labels = 1; CreateListVarFromPtr(StackPos, POS_LABELS, "S", &m_list_labels, &n_list_labels, fieldnames); // Put the type and the labels CreateListVarFromPtr(StackPos, POS_FANN_POINTER, "p", &m_fann_pointer, &n_fann_pointer, ann); return 0; } int createScilabFannStructFromCFannStruct(struct fann* ann,unsigned int StackPos) { int m_list_labels, n_list_labels; int m_fann_pointer, n_fann_pointer; int m_extra, n_extra, l_extra; //The struct field names static char *fieldnames[] = {"fannlist","fann"}; m_fann_pointer = 1; n_fann_pointer = 1; m_extra = 2; n_extra = 1; CreateVar(StackPos, "m", &m_extra, &n_extra, &l_extra); m_list_labels = 2; n_list_labels = 1; CreateListVarFromPtr(StackPos, POS_LABELS, "S", &m_list_labels, &n_list_labels, fieldnames); // Put the type and the labels CreateListVarFromPtr(StackPos, POS_FANN_POINTER, "p", &m_fann_pointer, &n_fann_pointer, ann); return 0; } I hope this will help ... YC Some ideas for the Sylvestre Ledru a ?crit : > Le lundi 29 septembre 2008 ? 16:13 -0300, Jonathan Blanchard a ?crit : > >> Sorry to bother everyone on the list again about this subject. >> >> I have a question to Ledru you said yes to my question earlier but I'm >> not sure which. Is there any plan for gmp/mpr in scilab in the future >> and is there a developer currently looking at this? >> > No and no ;) > At least, as far I know. Yann is the one who added this idea to the > Wiki. Maybe he knows someone who is working on it. > > >> I also didn't listen to your warning and hacked myself a way to use >> gmp in scilab. >> > Seems you did the right choice ;) > > >> Sadly because of the nature of gmp it is impossible to >> create a toolbox for Scilab 5 as I would have loved to create one. >> > Why is it impossible ? Too tightly linked with Scilab's internal stuff? > > Sylvestre > > From BlanchardJ at ieee.org Mon Sep 29 22:24:35 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Mon, 29 Sep 2008 17:24:35 -0300 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: <48E137DD.5060606@freesurf.fr> References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> Message-ID: I see what you mean I think. But what happen when it get destroyed. Let say for example the following code. a = gmpinit(123); b = gmpinit(234); a = gmpmul(a,b); In this code the initial variable 'a' get cleared but if memory was allocated out of the Scilab stack it won't be freed. Jonathan Blanchard On Mon, Sep 29, 2008 at 5:17 PM, Yann COLLETTE wrote: > Hello, > > I don't know anybody currently working on this topic today. > I have some idea for the interface: use the pointer type "p". With this > type, you can allocate the memory required to store the gmp number. > Then, you store the pointer to the memory allocated in a mlist (here, the > type of the mlist is fannlist and the fann field contains the pointer). > To retrieve the gmp number, use the GetRhsVar with the "p" type. > Here are some examples I use in a FANN (Fast Artificle Neural Network) > interface. > > For the basic operations like +, -, etc ..., maybe you can use overloading: > for the + operator: > function c = gmplist_a_gmplist(a,b) c = gmp_add(a,b); endfunction > > int createScilabFannStructFromCFannStruct(struct fann* ann,unsigned int > StackPos) > { > int m_list_labels, n_list_labels; > int m_fann_pointer, n_fann_pointer; > int m_extra, n_extra, l_extra; > > //The struct field names > static char *fieldnames[] = {"fannlist","fann"}; > > m_fann_pointer = 1; n_fann_pointer = 1; > m_extra = 2; n_extra = 1; > > CreateVar(StackPos, "m", &m_extra, &n_extra, &l_extra); > > m_list_labels = 2; n_list_labels = 1; > CreateListVarFromPtr(StackPos, POS_LABELS, "S", &m_list_labels, > &n_list_labels, fieldnames); // Put the type and the labels > CreateListVarFromPtr(StackPos, POS_FANN_POINTER, "p", &m_fann_pointer, > &n_fann_pointer, ann); > > return 0; > } > > int createScilabFannStructFromCFannStruct(struct fann* ann,unsigned int > StackPos) > { > int m_list_labels, n_list_labels; > int m_fann_pointer, n_fann_pointer; > int m_extra, n_extra, l_extra; > > //The struct field names > static char *fieldnames[] = {"fannlist","fann"}; > > m_fann_pointer = 1; n_fann_pointer = 1; > m_extra = 2; n_extra = 1; > > CreateVar(StackPos, "m", &m_extra, &n_extra, &l_extra); > > m_list_labels = 2; n_list_labels = 1; > CreateListVarFromPtr(StackPos, POS_LABELS, "S", &m_list_labels, > &n_list_labels, fieldnames); // Put the type and the labels > CreateListVarFromPtr(StackPos, POS_FANN_POINTER, "p", &m_fann_pointer, > &n_fann_pointer, ann); > > return 0; > } > > I hope this will help ... > > YC > > Some ideas for the > Sylvestre Ledru a ?crit : >> >> Le lundi 29 septembre 2008 ? 16:13 -0300, Jonathan Blanchard a ?crit : >> >>> >>> Sorry to bother everyone on the list again about this subject. >>> >>> I have a question to Ledru you said yes to my question earlier but I'm >>> not sure which. Is there any plan for gmp/mpr in scilab in the future >>> and is there a developer currently looking at this? >>> >> >> No and no ;) >> At least, as far I know. Yann is the one who added this idea to the >> Wiki. Maybe he knows someone who is working on it. >> >> >>> >>> I also didn't listen to your warning and hacked myself a way to use >>> gmp in scilab. >>> >> >> Seems you did the right choice ;) >> >> >>> >>> Sadly because of the nature of gmp it is impossible to >>> create a toolbox for Scilab 5 as I would have loved to create one. >>> >> >> Why is it impossible ? Too tightly linked with Scilab's internal stuff? >> >> Sylvestre >> >> > > From sylvestre.ledru at scilab.org Tue Sep 30 14:25:28 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 30 Sep 2008 14:25:28 +0200 Subject: [Scilab-Dev] Re: and idea for the development of Scipad In-Reply-To: <48E10451.5030601@broadpark.no> References: <48DFB0AF.20308@broadpark.no> <48DFEF4D.80204@free.fr> <48E10451.5030601@broadpark.no> Message-ID: <1222777528.31019.74.camel@korcula.inria.fr> > My idea is that documentation could be written and maintained as part > of the head_comment section of the .sci file, and that help_from_sci > should be used for generation of the final xml files. This would > eliminate any sync issues. So, if I understand correctly, for a 3 pages documentation, you would put everything into the source ? > > > > On the practical side I'm wondering about implementation. > > > > Indeed, the Scipad menu entry "File/Create help skeleton" basically > > is a wrapper around the Scilab function help_skeleton. It is easy to > > call another function instead of help_skeleton. You can see the > > details in proc helpskeleton (in file scilabexec.tcl). Calling > > help_from_sci instead of help_skeleton is straightforward. > > > > However, first of all I would add another entry in the file menu > > (e.g. "File/Create help from function header comments" or something > > alike), rather than replacing the existing entry. Some users would > > like to keep the vanilla help_skeleton perhaps. > This sounds interesting. I'll take a look at the tcl files. It could > be a nice feature to add to the toolbox. Yep, this could be a great feature for Scipad to automatically generate a help from the profile! Sylvestre From sylvestre.ledru at scilab.org Tue Sep 30 16:45:29 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 30 Sep 2008 16:45:29 +0200 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> Message-ID: <1222785929.31019.141.camel@korcula.inria.fr> Le mercredi 24 septembre 2008 ? 19:36 -0300, Jonathan Blanchard a ?crit : > I do believe that git shift the > difficulty of working with a distributed revision system from the > projects managers toward the users and collaborators. Hmm, most of the developers of Scilab are working closely at the INRIA. We see each others every day. Therefor, shifting the difficulty upon the dev is no big deal. To detail why we need it, I can take an example how it is working now. At the moment, almost all the team & contributor are working on the current trunk. However, we have some people who are working on cleaning up and rewriting some functions in the elementary functions module. These modifications are risky, therefor, we don't want to include them in the trunk but we want to be able to take modifications (on this module) from the trunk and merge them into this branch. For this, each night, an email is sent to the guy in charge of this to check if the modification on trunk/elementary_functions should be incorporated in his branch. It is a boring work and it is common to forget things... We intend to address this kind of issue. We also expect to develop collaborative works (ie, some guys working on a distinct branch and pushing in the master their work once it is good enough). Sylvestre From BlanchardJ at ieee.org Tue Sep 30 17:25:22 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Tue, 30 Sep 2008 12:25:22 -0300 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: <1222785929.31019.141.camel@korcula.inria.fr> References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> <1222785929.31019.141.camel@korcula.inria.fr> Message-ID: First It's true that I do not know the amount of contribution from the community out of the INRIA. Indeed If external contribution are rare it will not affect people too much. Now on the other hand I really do not see how git will fix the problem you just said. Commit are still made either to branch or trunk in git. The model is not that different from svn you need to manually shift around and merge stuff between branches and trunk. (Well that is the way I see it). I mean each modification from the trunk will either be fully merged on the branches or merged manually by selecting which modification get merged into branches. Git work somewhat the same way. I do not try to discourage your choice. I mean at the end it's your(Scilab dev team) concerns and this could be more of a philosophical debate but I do often use the svn repo as I'm coding from the trunk and the idea of dealing with git is a bit discouraging. Especially the type of work flow and repository structures git encourage. Or maybe it's just me who fear changes :) (Or most of Linus's opinions....). Jonathan Blanchard On Tue, Sep 30, 2008 at 11:45 AM, Sylvestre Ledru wrote: > Le mercredi 24 septembre 2008 ? 19:36 -0300, Jonathan Blanchard a > ?crit : >> I do believe that git shift the >> difficulty of working with a distributed revision system from the >> projects managers toward the users and collaborators. > Hmm, most of the developers of Scilab are working closely at the INRIA. > We see each others every day. Therefor, shifting the difficulty upon the > dev is no big deal. > > To detail why we need it, I can take an example how it is working now. > > At the moment, almost all the team & contributor are working on the > current trunk. > However, we have some people who are working on cleaning up and > rewriting some functions in the elementary functions module. > These modifications are risky, therefor, we don't want to include them > in the trunk but we want to be able to take modifications (on this > module) from the trunk and merge them into this branch. For this, each > night, an email is sent to the guy in charge of this to check if the > modification on trunk/elementary_functions should be incorporated in his > branch. > > It is a boring work and it is common to forget things... > > We intend to address this kind of issue. > > We also expect to develop collaborative works (ie, some guys working on > a distinct branch and pushing in the master their work once it is good > enough). > > Sylvestre > > > From barry.cardiff at gmail.com Tue Sep 30 17:38:33 2008 From: barry.cardiff at gmail.com (Barry Cardiff) Date: Tue, 30 Sep 2008 16:38:33 +0100 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> <1222785929.31019.141.camel@korcula.inria.fr> Message-ID: <82bf75360809300838m18f4d1aai6df00894a4fa97ec@mail.gmail.com> Hi, I agree fully with Jonathan here. Sylvestre pointed out a problem with the current work flow, i.e. that of keeping a development Branch up to date with ongoing fixes in the trunk - this I agree is a pain and I'm not envious of the configuration managers job. But (and its a big but) you stopped short of saying how git will solve this - all you said was "We intend to address this kind of issue". As far as I can see if you want the development branch to contain recent bug fixes then someone somewhere is going to have the pain of merging them in and the choice of version control tool won't change this - you'll still have this problem. Maybe I'm missing the point here.... Barry 2008/9/30 Jonathan Blanchard > First It's true that I do not know the amount of contribution from the > community out of the INRIA. Indeed If external contribution are rare > it will not affect people too much. > > Now on the other hand I really do not see how git will fix the problem > you just said. Commit are still made either to branch or trunk in git. > The model is not that different from svn you need to manually shift > around and merge stuff between branches and trunk. (Well that is the > way I see it). I mean each modification from the trunk will either be > fully merged on the branches or merged manually by selecting which > modification get merged into branches. Git work somewhat the same way. > > I do not try to discourage your choice. I mean at the end it's > your(Scilab dev team) concerns and this could be more of a > philosophical debate but I do often use the svn repo as I'm coding > from the trunk and the idea of dealing with git is a bit discouraging. > Especially the type of work flow and repository structures git > encourage. Or maybe it's just me who fear changes :) (Or most of > Linus's opinions....). > > Jonathan Blanchard > > > > On Tue, Sep 30, 2008 at 11:45 AM, Sylvestre Ledru > wrote: > > Le mercredi 24 septembre 2008 ? 19:36 -0300, Jonathan Blanchard a > > ?crit : > >> I do believe that git shift the > >> difficulty of working with a distributed revision system from the > >> projects managers toward the users and collaborators. > > Hmm, most of the developers of Scilab are working closely at the INRIA. > > We see each others every day. Therefor, shifting the difficulty upon the > > dev is no big deal. > > > > To detail why we need it, I can take an example how it is working now. > > > > At the moment, almost all the team & contributor are working on the > > current trunk. > > However, we have some people who are working on cleaning up and > > rewriting some functions in the elementary functions module. > > These modifications are risky, therefor, we don't want to include them > > in the trunk but we want to be able to take modifications (on this > > module) from the trunk and merge them into this branch. For this, each > > night, an email is sent to the guy in charge of this to check if the > > modification on trunk/elementary_functions should be incorporated in his > > branch. > > > > It is a boring work and it is common to forget things... > > > > We intend to address this kind of issue. > > > > We also expect to develop collaborative works (ie, some guys working on > > a distinct branch and pushing in the master their work once it is good > > enough). > > > > Sylvestre > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvestre.ledru at scilab.org Tue Sep 30 17:39:13 2008 From: sylvestre.ledru at scilab.org (Sylvestre Ledru) Date: Tue, 30 Sep 2008 17:39:13 +0200 Subject: [Scilab-Dev] Re: Re: Leaving SVN to GIT In-Reply-To: References: <82bf75360809221457h1b77e3bcpabb114054e51c03@mail.gmail.com> <1222123518.4063.45.camel@zlarin.inria.fr> <82bf75360809241333j42dbdf36qcef4dafce440daa5@mail.gmail.com> <1222785929.31019.141.camel@korcula.inria.fr> Message-ID: <1222789153.31019.152.camel@korcula.inria.fr> > Now on the other hand I really do not see how git will fix the problem > you just said. Because from a checkout of a git repository, you can have multiple references to misc branches: Ie, you can say "please, get me the change from this branch" or "this time, the trunk". > I do not try to discourage your choice. I mean at the end it's > your(Scilab dev team) concerns and this could be more of a > philosophical debate but I do often use the svn repo as I'm coding > from the trunk and the idea of dealing with git is a bit discouraging. To be more pragmatic, svn is what ? 5 commands ? $ svn add $ svn remove $ svn checkout (once!) $ svn commit $ svn update (ok, svn diff & svn log but for power user). With git, the commands become: $ git add $ git rm $ git clone $ git commit -a $ git pull You need these commands to do the same as SVN. Sylvestre From ycollet at freesurf.fr Tue Sep 30 18:42:53 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Tue, 30 Sep 2008 18:42:53 +0200 Subject: [Scilab-Dev] Re: and idea for the development of Scipad In-Reply-To: <1222777528.31019.74.camel@korcula.inria.fr> References: <48DFB0AF.20308@broadpark.no> <48DFEF4D.80204@free.fr> <48E10451.5030601@broadpark.no> <1222777528.31019.74.camel@korcula.inria.fr> Message-ID: <48E2570D.4070400@freesurf.fr> And what about a doxygen for scilab ? You get everything after // With some markups, you fill an xml fill and then generate the help page. If then help page is younger than the sci file, the help page is not regenerated ... YC Sylvestre Ledru a ?crit : >> My idea is that documentation could be written and maintained as part >> of the head_comment section of the .sci file, and that help_from_sci >> should be used for generation of the final xml files. This would >> eliminate any sync issues. >> > So, if I understand correctly, for a 3 pages documentation, you would > put everything into the source ? > > >>> On the practical side I'm wondering about implementation. >>> >>> Indeed, the Scipad menu entry "File/Create help skeleton" basically >>> is a wrapper around the Scilab function help_skeleton. It is easy to >>> call another function instead of help_skeleton. You can see the >>> details in proc helpskeleton (in file scilabexec.tcl). Calling >>> help_from_sci instead of help_skeleton is straightforward. >>> >>> However, first of all I would add another entry in the file menu >>> (e.g. "File/Create help from function header comments" or something >>> alike), rather than replacing the existing entry. Some users would >>> like to keep the vanilla help_skeleton perhaps. >>> >> This sounds interesting. I'll take a look at the tcl files. It could >> be a nice feature to add to the toolbox. >> > Yep, this could be a great feature for Scipad to automatically generate > a help from the profile! > > Sylvestre > > > From ycollet at freesurf.fr Tue Sep 30 18:47:40 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Tue, 30 Sep 2008 18:47:40 +0200 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> Message-ID: <48E2582C.3030907@freesurf.fr> Good example. With a pointer stored in a structure: it's the mess. With a "binary array" stored in a mlist of this kind: mlist(['gmplist','array'],[]) it should be better. The memory is managed by scilab, in the array, you always allocate a multiple of typeof(double) so as to store your gmp number. You have to write 2 functions: one to translate a gmp struct into an array of double and another to translate an array of double into gmp struct. What was your strategy ? Do you store gmp numbers into strings ? YC Jonathan Blanchard a ?crit : > I see what you mean I think. But what happen when it get destroyed. > Let say for example the following code. > > a = gmpinit(123); > b = gmpinit(234); > > a = gmpmul(a,b); > > In this code the initial variable 'a' get cleared but if memory was > allocated out of the Scilab stack it won't be freed. > > Jonathan Blanchard > > > > From BlanchardJ at ieee.org Tue Sep 30 19:09:03 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Tue, 30 Sep 2008 14:09:03 -0300 Subject: [Scilab-Dev] Gmp in scilab revisited. In-Reply-To: <48E2582C.3030907@freesurf.fr> References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> <48E2582C.3030907@freesurf.fr> Message-ID: Well hum I don't know if I should discuss my current strategy as most computer programming expert would kill me because of it. Right now I only wanted to test using gmp in Scilab so I needed something to hole my gmp variable. I choose to use the matrix of double type for a quick hack. It's kind of weird as the matrix doesn't hold meaningful value when seen as a matrix of double but it's just a temporary hack. So I had two way of doing this. The first one : void C2F(GmpCreateVarFromPtr) ( int StkPos, mpz_t GmpVar, int *StkAdd ) { int m1 = 2; int n1 = 1; CreateVar(StkPos,MATRIX_OF_DOUBLE_DATATYPE, &m1, &n1, StkAdd); memcpy( stk(*StkAdd), (void*)GmpVar, 12 ); return; } It just memcpy the mpz operand inside the memory allocated to a matrix of double. The value of the operand stay in the heap allocated by malloc. In this situation if the initial Scilab variable is destroyed it's a memory leak as some memory is not freed. If Scilab would somehow be aware of the it would be simple to free the memory when variable are cleared from the stack. This approach have the advantages of being relatively fast and using gmp in scilab would be very fast. And would approach native speed for big operands as the call overhead would only be a small portion of the processing done. Second solution is basically the same thing but the whole limb of the gmp operand is copied inside the Scilab stack. This is kind of slow in the long run but ensure that all the memory is freed. This is a bit like you said, using an mlist would be better for this purpose but then again if you overload some operators aren't you overloading the mlist type and not a new type you defined yourself? As I said this is just a quick hack. In a perfect world a native Scilab type would be better but this is a bit to complicated to me and cannot be bundled in a toolbox. I also do not know what are the policies and enthusiasm of the Scilab developers to integrate external contributions in the core code. Jonathan Blanchard On Tue, Sep 30, 2008 at 1:47 PM, Collette Yann wrote: > Good example. > With a pointer stored in a structure: it's the mess. > With a "binary array" stored in a mlist of this kind: > mlist(['gmplist','array'],[]) > it should be better. The memory is managed by scilab, in the array, you > always allocate a multiple of typeof(double) so as to store your gmp number. > You have to write 2 functions: one to translate a gmp struct into an array > of double and another to translate an array of double into gmp struct. > > > What was your strategy ? Do you store gmp numbers into strings ? > > YC > > Jonathan Blanchard a ?crit : >> >> I see what you mean I think. But what happen when it get destroyed. >> Let say for example the following code. >> >> a = gmpinit(123); >> b = gmpinit(234); >> >> a = gmpmul(a,b); >> >> In this code the initial variable 'a' get cleared but if memory was >> allocated out of the Scilab stack it won't be freed. >> >> Jonathan Blanchard >> >> >> >> > > From sylvestre.ledru at inria.fr Tue Sep 30 22:27:24 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Tue, 30 Sep 2008 22:27:24 +0200 Subject: How to add features in Scilab Was: Gmp in scilab revisited. In-Reply-To: References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> <48E2582C.3030907@freesurf.fr> Message-ID: <1222806444.3231.24.camel@zlarin> Le mardi 30 septembre 2008 ? 14:09 -0300, Jonathan Blanchard a ?crit : > I also do not know what are the > policies and enthusiasm of the Scilab developers to integrate external > contributions in the core code. It depends :) We have in our todo list to create a policy to incorporate stuff into Scilab. But writing a SEP is a first step! Sylvestre From BlanchardJ at ieee.org Tue Sep 30 22:44:14 2008 From: BlanchardJ at ieee.org (Jonathan Blanchard) Date: Tue, 30 Sep 2008 17:44:14 -0300 Subject: [Scilab-Dev] How to add features in Scilab Was: Gmp in scilab revisited. In-Reply-To: <1222806444.3231.24.camel@zlarin> References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> <48E2582C.3030907@freesurf.fr> <1222806444.3231.24.camel@zlarin> Message-ID: Hmm I see. That would be interesting. Would writing this module or toolbox require that the people working on it sign the Scilab developer agreements or it could just be submitted as a whole using the proper license? I was saying to myself that by committing to doing this I might be exaggerating the amount of time I have free for this project. But I would really like to see this function in Scilab. So I was thinking of maybe implementing part of the GMP interface module using a temporary hack that would not require modification of the core Scilab code. Something in the range of what Yann proposed. And then following satisfactory results it could be possible to integrate it with a future version of Scilab. Jonathan Blanchard On Tue, Sep 30, 2008 at 5:27 PM, Sylvestre Ledru wrote: > Le mardi 30 septembre 2008 ? 14:09 -0300, Jonathan Blanchard a ?crit : >> I also do not know what are the >> policies and enthusiasm of the Scilab developers to integrate external >> contributions in the core code. > It depends :) > We have in our todo list to create a policy to incorporate stuff into > Scilab. > > But writing a SEP is a first step! > > Sylvestre > > > From sylvestre.ledru at inria.fr Tue Sep 30 22:53:23 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Tue, 30 Sep 2008 22:53:23 +0200 Subject: [Scilab-Dev] How to add features in Scilab Was: Gmp in scilab revisited. In-Reply-To: References: <1222715893.3301.27.camel@zlarin> <48E137DD.5060606@freesurf.fr> <48E2582C.3030907@freesurf.fr> <1222806444.3231.24.camel@zlarin> Message-ID: <1222808003.3231.35.camel@zlarin> Le mardi 30 septembre 2008 ? 17:44 -0300, Jonathan Blanchard a ?crit : > Hmm I see. That would be interesting. Would writing this module or > toolbox require that the people working on it sign the Scilab > developer agreements or it could just be submitted as a whole using > the proper license? For a toolbox, you can do whatever you want. You pick up the license you like. For Scilab, you have to sign a dev agreement but, since our legal structure has changed, the old dev agreement must be updated. I will have to get to you on this. > I was saying to myself that by committing to doing this I might be > exaggerating the amount of time I have free for this project. But I > would really like to see this function in Scilab. So I was thinking of > maybe implementing part of the GMP interface module using a temporary > hack that would not require modification of the core Scilab code. This would be the best move for now. Btw, we are working on a packaging system for toolboxes (like apt/urpmi/yast) which will greatly facilitate the diffusion of toolbox. Sylvestre