From vincent.couvert at inria.fr Tue Apr 1 08:21:08 2008 From: vincent.couvert at inria.fr (Vincent COUVERT) Date: Tue, 01 Apr 2008 08:21:08 +0200 Subject: [Scilab-Dev] building on x64 In-Reply-To: <1206956417.4393.50.camel@segre-pc2.weizmann.ac.il> References: <1206949444.4393.37.camel@segre-pc2.weizmann.ac.il> <47F09A7A.4010806@inria.fr> <1206950617.4393.45.camel@segre-pc2.weizmann.ac.il> <47F09D12.5040207@inria.fr> <1206954426.4393.47.camel@segre-pc2.weizmann.ac.il> <47F0ACA7.5000209@inria.fr> <1206956417.4393.50.camel@segre-pc2.weizmann.ac.il> Message-ID: <47F1D454.5010501@inria.fr> I think we have to create a repository similar to: http://viewvc.scilab.org/bin/cgi/viewvc.cgi/trunk/Dev-Tools/SE/Prerequirements/Windows_x64/ for Linux x64 versions. Vincent Enrico Segre a ?crit : > On Mon, 2008-03-31 at 11:19 +0200, Vincent COUVERT wrote: > >> Thank you Enrico. >> >> I think most of them are linked to the same problem I asked you to test >> for the bug 2826. >> >> > > except for bug 2828 > where to get correct versions of the four x64 SCI/bin/*.so? > > > -- ============================================== 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 vincent.couvert at inria.fr Tue Apr 1 11:05:50 2008 From: vincent.couvert at inria.fr (Vincent COUVERT) Date: Tue, 01 Apr 2008 11:05:50 +0200 Subject: [Scilab-Dev] Bug 2789 (debugger broken) In-Reply-To: <47F14CD6.2040509@free.fr> References: <47F14CD6.2040509@free.fr> Message-ID: <47F1FAEE.9070602@inria.fr> Hi Fran?ois, To be short and clear about the current development of Scilab and your ceaseless criticisms about the work of operational team. * About the rewriting of the TCL loop management: yes some functionalities have been broken, and particularly the functionalities used by Scipad debugger (reentrant Tcl constructs). These reentrant Tcl calls can be "quite easily" rewritten by separating calls to ScilabEval and calls to TCL_* as we did for the error handling for Scipad "Load into Scilab..." menu. We have to update the Wiki page you talk about to give workarounds for these special use cases of the TCL interface. But please stop naming a person of the operational team in your mails! When a development is done, it is done after dialogue with the whole operational team or at least a part of it. So you can invoke the whole team responsibility but please stop front attacks! * About Scilab 5.0 BETA version and Release: we are late and we have some more developments and improvements to do before a BETA version can be released and by the way for Scilab 5.0 release. * About the bugs in Bugzilla: we cleaned the database during the last past weeks and we now have a good idea of all the remaining bugs and we try to attach the same importance to each bug and not only the ones you want us (operational team) to fix. Do not hesitate to send us your encouragement instead of your criticisms, we are working hard here however we are still late... Vincent Fran?ois Vogel a ?crit : > Hi all, > > Having just fixed two Scipad bugs tonight, I was wondering what you > operational team intend to do with bug 2789 (debugger broken in trunk)? > > I have seen that wiki page: http://wiki.scilab.org/Tcl_Thread > and it explains what is the main problem. The new Tcl thread > management in Scilab 5 does not allow reentrant calls. And Scipad is > full of such reentrant Tcl constructs. > > Now, what? What's the next move? > > Is the Tcl thread management now finished in your opinion? (I didn't > see any activity on this subject for two weeks). > > Are you perhaps waiting for someone to rewrite the entire debugger in > order to work around the new limitation? On this the answer must be > no, since Bruno Jofret stated many times on this list that he didn't > want to break anything. But you're perhaps in a dead end? > > Or do you plan to allow for reentrant calls, so that the debugger will > work again with little or no change in Scipad? > > Given that Scilab 5 beta was supposed to happen in March, and that the > stable 5.0 is still scheduled in April, I'm getting a bit worried. > Could you please explain how you see the next future with respect to > that bug 2789 (and also 2596)? > > Thanks for your answers to come. > 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 enrico.segre at weizmann.ac.il Tue Apr 1 13:01:13 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Tue, 01 Apr 2008 14:01:13 +0300 Subject: Bug 2789 (debugger broken) Message-ID: <1207047673.4393.84.camel@segre-pc2.weizmann.ac.il> Vincent, > To be short and clear about the current development of Scilab and your > ceaseless criticisms about the work of operational team. I don't think that Francois is criticizing for nothing. At all. At least he is still writing to you, others just walked away. > * About the rewriting of the TCL loop management: yes some > functionalities have been broken, and particularly the functionalities > used by Scipad debugger (reentrant Tcl constructs). These reentrant Tcl > calls can be "quite easily" rewritten by separating calls to ScilabEval > and calls to TCL_* as we did for the error handling for Scipad "Load > into Scilab..." menu. Are you sure about that? At first glance and without trying, I would say it won't be that easy. > We have to update the Wiki page you talk about to > give workarounds for these special use cases of the TCL interface. Please consider also that AFAIU tcl has no more even a way to understand that the scilab interpreter is busy with a computation. This is often needed by scipad, which has to decide wether to send or not a ScilabEval command. This is not the same as sending an arbitrary command anyway and wait for its queued execution. > But please stop naming a person of the operational team in your mails! I don't see anything wrong here - someone in particular wrote on the subject, is being assigned the relevant bugs - so it seems natural to refer to him. And Francois is only saying "Bruno said this and that". > When a development is done, it is done after dialogue with the whole > operational team or at least a part of it. So you can invoke the whole > team responsibility but please stop front attacks! what the hell are are you talking about? > * About Scilab 5.0 BETA version and Release: we are late and we have > some more developments and improvements to do before a BETA version can > be released and by the way for Scilab 5.0 release. > > * About the bugs in Bugzilla: we cleaned the database during the last > past weeks and we now have a good idea of all the remaining bugs and we > try to attach the same importance to each bug and not only the ones you > want us (operational team) to fix. Again, I don't think Francois is criticizing the priorities you (the team) assigned to the various bugs, or to the works to be done. He is only asking what is the plan, if any, with respect to what we're developing more closely. If you don't communicate, the effect will just be a broken debugger in the 5.0 alpha, beta, whatever. Enrico From fvogelnew1 at free.fr Tue Apr 1 21:04:46 2008 From: fvogelnew1 at free.fr (fvogelnew1 at free.fr) Date: Tue, 01 Apr 2008 21:04:46 +0200 Subject: [Scilab-Dev] Bug 2789 (debugger broken) In-Reply-To: <47F1FAEE.9070602@inria.fr> References: <47F14CD6.2040509@free.fr> <47F1FAEE.9070602@inria.fr> Message-ID: <1207076686.47f2874e32d43@imp.free.fr> Vincent, Enrico is fully right in his answer, but maybe a few more words from me. > To be short and clear about the current development of Scilab and your > ceaseless criticisms about the work of operational team. I'm not criticizing anything. Read my post again. I'm asking what is your plan. > These reentrant Tcl > calls can be "quite easily" rewritten by separating calls to ScilabEval > and calls to TCL_* Well, I had a try already after I saw your Tcl_thread wiki page. It's not easy to do in Scipad. Really not. Have a look at proc checkendofdebug_bp (in SCI/modules/scipad/tcl/db_states.tcl) for an example. > But please stop naming a person of the operational team in your mails! > When a development is done, it is done after dialogue with the whole > operational team or at least a part of it. So you can invoke the whole > team responsibility but please stop front attacks! Again, I did not attack anyone. Nobody, and the operational team as a whole neither. If anyone is attacking somebody, then you are with your answer. You're reacting on something that did not happen, please cool down. What has been written by Bruno about the fact he doesn't want to break things is public, see last section of http://lists.scilab.org/cgi-bin/ezmlm-browse?list=dev&cmd=showmsg&msgnum=30 This is what I was referring to. Since I saw nothing happening recently in the field of the Tcl interface, I'm wondering whether the work will go on or not on your side, if you consider it's finished or not. Nothing more, nothing else. > * About the bugs in Bugzilla: we cleaned the database during the last > past weeks and we now have a good idea of all the remaining bugs That was indeed needed (and this is not a criticism, don't jump on me). > and we > try to attach the same importance to each bug and not only the ones you > want us (operational team) to fix. You misunderstood my message. I'm not asking for a favor, I'm asking whether you plan to fix that bug before 5.0 final or not. Or if you want me to do something in Scipad to work around the new limitation related to reentrant calls. Unless I misread your anger, you didn't answer that question I think. > Do not hesitate to send us your encouragement instead of your > criticisms, we are working hard here however we are still late... Once more, I made no comment on the fact you're late or not. I'm not waiting for Scilab 5, and it doesn't matter to me if it comes later than announced. The fact is that 5.0 final is announced on your website to be released in April, which is approximately now, and that I'm worried because I don't have a clue about if bug 2789 will be fixed or not in that version. If it's not, the debugger will not be working in Scilab 5. Francois From sylvestre.ledru at inria.fr Wed Apr 2 00:59:46 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 2 Apr 2008 00:59:46 +0200 Subject: [Scilab-Dev] PVM - Bug 2460 In-Reply-To: <47F0A441.9010206@freesurf.fr> References: <47F0A441.9010206@freesurf.fr> Message-ID: <2a54a71c6e8ebf96e016dd0d413617a1@korcula.inria.fr> Thanks Yann, I will have a look on this when I get back from holidays. Sylvestre On Mon, 31 Mar 2008 10:43:45 +0200, Collette Yann wrote: > Hello, > > I've located the problem related to bug 2460 (PVM and pvm_recv). > I've put some informations in the bug description: > http://www.scilab.org/cgi-bin/bugzilla_bug_II/show_bug.cgi?id=2460 > > The only work around for now is to remove the problematic line. > > I will work with this version of scilab-4.1.2 but a new solution must be > found because the problem seem to be located in scilab-5 too: > see file modules/core/src/c/stack2.c > and file modules/pvm/sci_gateway/c/sci_pvm_recv.c > > YC From ycollet at freesurf.fr Thu Apr 3 18:01:15 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Thu, 03 Apr 2008 18:01:15 +0200 Subject: How to install the documentation In-Reply-To: <2a54a71c6e8ebf96e016dd0d413617a1@korcula.inria.fr> References: <47F0A441.9010206@freesurf.fr> <2a54a71c6e8ebf96e016dd0d413617a1@korcula.inria.fr> Message-ID: <47F4FF4B.8040507@freesurf.fr> Hello, How to install the help documentation under linux ? When I start scilab, the following message is printed in the console: Startup execution: loading initial environment !--error 241 File /local/stow/scilab-5/share/scilab//modules/helptools/help/en_US/addchapter.sce does not exist or read access denied. at line 7 of function add_module_help_chapter called by : add_module_help_chapter('helptools'); line 19 of exec file called by : exec("SCI/modules/"+modules(i)+"/etc/"+modules(i)+".start",-1); line 78 of exec file called by : exec('SCI/etc/scilab.start',-1);; I've done a "make doc", the doc seems to be built, but not installed ... YC From ycollet at freesurf.fr Fri Apr 4 05:36:05 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 04 Apr 2008 05:36:05 +0200 Subject: How to "localize" a module In-Reply-To: <47F4FF4B.8040507@freesurf.fr> References: <47F0A441.9010206@freesurf.fr> <2a54a71c6e8ebf96e016dd0d413617a1@korcula.inria.fr> <47F4FF4B.8040507@freesurf.fr> Message-ID: <47F5A225.5030401@freesurf.fr> Hello, I'm looking for informations related to localization. To localize a module, you must add every text in a sci function into a gettext function, but how to generate the .po files ? YC From fvogelnew1 at free.fr Fri Apr 4 08:18:15 2008 From: fvogelnew1 at free.fr (=?UTF-8?B?RnJhbsOnb2lzIFZvZ2Vs?=) Date: Fri, 04 Apr 2008 08:18:15 +0200 Subject: [Scilab-Dev] How to "localize" a module In-Reply-To: <47F5A225.5030401@freesurf.fr> References: <47F0A441.9010206@freesurf.fr> <2a54a71c6e8ebf96e016dd0d413617a1@korcula.inria.fr> <47F4FF4B.8040507@freesurf.fr> <47F5A225.5030401@freesurf.fr> Message-ID: <47F5C827.4000806@free.fr> Hi, http://wiki.scilab.org/Localization Francois Collette Yann said on 04/04/2008 05:36: > Hello, > > I'm looking for informations related to localization. > To localize a module, you must add every text in a sci function into a > gettext function, but how to generate the .po files ? > > YC From vincent.couvert at inria.fr Fri Apr 4 15:14:31 2008 From: vincent.couvert at inria.fr (Vincent COUVERT) Date: Fri, 04 Apr 2008 15:14:31 +0200 Subject: Delete your SCIHOME/configuration.xml file Message-ID: <47F629B7.60804@inria.fr> Hi all, Due to an error of CTRL+X and CTRL+C management, I had to modify Scilab configuration file (Revision 24023). Please delete your SCIHOME/configuration.xml file and restart Scilab so that these modifications will be taken into account. Vincent -- ============================================== 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 stephane.mottelet at utc.fr Fri Apr 4 16:08:28 2008 From: stephane.mottelet at utc.fr (=?ISO-8859-1?Q?St=E9phane_Mottelet?=) Date: Fri, 04 Apr 2008 16:08:28 +0200 Subject: printf bug In-Reply-To: <6nssol$ahvmn@mail3-relais-sop.national.inria.fr> References: <6nssol$ahvmn@mail3-relais-sop.national.inria.fr> Message-ID: <47F6365C.6020502@utc.fr> Hi all, Just bugzilled #2862 (in BUILD4 and 5alpha3) -->printf("%x",2^31-1) 7fffffff -->printf("%x",2^31) 80000000 -->printf("%x",2^31+1) 80000000 --> same problems with %d, %u. Btw I have tested the 5.0alpha3 on my Imac/XP machine yesterday evening. Besides the Radeon bug which craches Scilab anytime OpenGL is used, I found it very reactive and the Java VM overhead does not seem to be an issue on a recent machine. S. -- St?phane Mottelet Laboratoire de Math?matiques Appliqu?es Universit? de Technologie de Compi?gne http://www.lmac.utc.fr/~mottelet From alextcarneiro at gmail.com Thu Apr 3 19:13:00 2008 From: alextcarneiro at gmail.com (Alex Carneiro) Date: Thu, 3 Apr 2008 17:13:00 +0000 Subject: Voronoi diagrams Message-ID: Hi, I'm a enginner and my favorite areas are computational vision, image and signals processing, neural networks and pattern recognition. I'm needing be Voronoi diagrams for clustering. The toolbox CGLAB have any problem. I don't use windows or any proprietary software since 2005. The scilab is so good for my aplications, but some times don't have functions. -- Att. Eng. Alex Carneiro. Conhe?a: http://multisign.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mann at vc.cvut.cz Fri Apr 4 21:09:27 2008 From: mann at vc.cvut.cz (Herman Mann) Date: Fri, 4 Apr 2008 21:09:27 +0200 Subject: Please, help Message-ID: <1207336167.47f67ce79a045@imap.vc.cvut.cz> Dear Scilab developers, Excuse me please for encroaching upon your time. We have developed a package called DYNAST for physical-level simulation some 25 years ago and we are still upgrading it regularly. As you can see from the enclosed paper DYNAST can export transfer functions in a semi- symbolic form fro MATLAB and also, it is capable of co-simulation with Simulink. DYNAST users ask us for merging it with your software. Could you please advice us about a source of information how to do it? Looking forward to your favorable response, With my best regards, Herman Mann P.S. Please, have a look at virtual.cvut.cz/dynlab/ Dipl.Ing. Herman Mann, PhD. ScD. Associated Professor Computing and Information Centre Czech Technical University in Prague Phone +420-22435.2933 or -60558.6485 http://virtual.cvut.cz/mann/ -------------- next part -------------- A non-text attachment was scrubbed... Name: IMECE2003-42436.pdf Type: application/pdf Size: 551654 bytes Desc: not available URL: From sylvestre.ledru at inria.fr Tue Apr 8 02:50:29 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Tue, 8 Apr 2008 02:50:29 +0200 Subject: [Scilab-Dev] Bug 2789 (debugger broken) In-Reply-To: <1207076686.47f2874e32d43@imp.free.fr> References: <1207076686.47f2874e32d43@imp.free.fr> Message-ID: <52732b4aea48d1f480f9f2671238e89d@korcula.inria.fr> >> * About the bugs in Bugzilla: we cleaned the database during the last >> past weeks and we now have a good idea of all the remaining bugs > > That was indeed needed (and this is not a criticism, don't jump on me). To tell you the truth, when I started (quickly followed by Vincent) to clean up the bug list, it was because you and a few other insisted (with reason) on this. I am glad we finally did it. Sylvestre From pierre.marechal at inria.fr Tue Apr 8 16:40:42 2008 From: pierre.marechal at inria.fr (Pierre MARECHAL) Date: Tue, 08 Apr 2008 16:40:42 +0200 Subject: Scicos online help : two jar files added Message-ID: <47FB83EA.1060007@inria.fr> Hi all, I added two jar files (scicos online help : en_US & fr_FR) in the pre-requirements Please update your pre-requirements before compiling. Pierre -- =================================================== Pierre MARECHAL INRIA - Centre de Recherche de Paris - Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex =================================================== Equipe-Projet Scilab B?timent 1B - Bureau 008 Email : pierre.marechal at inria.fr =================================================== From mann at vc.cvut.cz Sun Apr 13 14:52:01 2008 From: mann at vc.cvut.cz (Herman Mann) Date: Sun, 13 Apr 2008 14:52:01 +0200 Subject: Fwd: Please, help Message-ID: <1208091121.480201f159ab5@imap.vc.cvut.cz> Dear Scilab developers, Excuse me please for encroaching upon your time. We have developed a package called DYNAST for physical-level simulation some 25 years ago and we are still upgrading it regularly. As you can see from the enclosed paper DYNAST can export transfer functions in a semi- symbolic form fro MATLAB and also, it is capable of co-simulation with Simulink. DYNAST users ask us for merging it with your software. Could you please advice us about a source of information how to do it? Looking forward to your favorable response, With my best regards, Herman Mann P.S. Please, have a look at virtual.cvut.cz/dynlab/ Dipl.Ing. Herman Mann, PhD. ScD. Associated Professor Computing and Information Centre Czech Technical University in Prague Phone +420-22435.2933 or -60558.6485 http://virtual.cvut.cz/mann/ -------------- next part -------------- A non-text attachment was scrubbed... Name: IMECE2003-42436.pdf Type: application/pdf Size: 551654 bytes Desc: not available URL: From sylvestre.ledru at inria.fr Mon Apr 14 22:38:27 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Mon, 14 Apr 2008 22:38:27 +0200 Subject: [Scilab-Dev] Google Summer of Code 2008 & Scilab In-Reply-To: <1206194258.3807.77.camel@zlarin.inria.fr> References: <1205428983.32737.567.camel@korcula.inria.fr> <1206194258.3807.77.camel@zlarin.inria.fr> Message-ID: <1208205507.3685.11.camel@zlarin.inria.fr> Here is the response from Google: "I just took a look at your Ideas page and it is solid. Unforunately we just cannot accept everyone into the program, I wish we could." Sylvestre Le samedi 22 mars 2008 ? 14:57 +0100, Sylvestre Ledru a ?crit : > Unfortunately, we have not been selected. I asked why but didn't get any > answer. > > Sylvestre > > > Le jeudi 13 mars 2008 ? 18:23 +0100, Sylvestre Ledru a ?crit : > > Hello guys, > > > > Just to let you know that we have applied for the Google Summer of Code > > 2008. > > > > I wrote a page with some ideas. Since they are very IT oriented, more > > scientific ideas would be appreciated. Don't hesitate to add them here: > > http://wiki.scilab.org/Ideas_of_development_for_Scilab > > or reply here, I can update this page for you. > > > > Cheers, > > Sylvestre > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pierre.marechal at inria.fr Tue Apr 15 13:40:54 2008 From: pierre.marechal at inria.fr (Pierre MARECHAL) Date: Tue, 15 Apr 2008 13:40:54 +0200 Subject: [Scilab-Dev] Scicos online help : two jar files added In-Reply-To: <47FB83EA.1060007@inria.fr> References: <47FB83EA.1060007@inria.fr> Message-ID: <48049446.5060805@inria.fr> Hi all, Scicos help files have been moved from the prerequirements to svn://svn.scilab.org/scilab/trunk/scilab/modules/scicos/help/ Before updating your working copy of Scilab, you need to delete the 2 previous jar files. [$SHELL] rm -f /modules/scicos/help/en_US/scicos_help.jar [$SHELL] rm -f /modules/scicos/help/fr_FR/scicos_help.jar [$SHELL] svn up /modules/scicos/help Pierre Pierre MARECHAL a ?crit : > Hi all, > > I added two jar files (scicos online help : en_US & fr_FR) in the > pre-requirements > > Please update your pre-requirements before compiling. > > Pierre -- =================================================== Pierre MARECHAL INRIA - Centre de Recherche de Paris - Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex =================================================== Equipe-Projet Scilab B?timent 1B - Bureau 008 Email : pierre.marechal at inria.fr =================================================== From delphine.gasc at inria.fr Wed Apr 16 10:44:42 2008 From: delphine.gasc at inria.fr (Delphine GASC) Date: Wed, 16 Apr 2008 10:44:42 +0200 Subject: New in the Scilab team: presentation Message-ID: <1208335482.21730.9.camel@petitgaou> Hello, I'm doing my Master's degree training period on the site of INRIA Rocquencourt in the Scilab's team. My supervisor is Sylvestre Ledru and I am working on the toolboxes management : specification, packaging system of the toolboxes, automatization of the compiling and automatisation of the installation for the users. See link for more informations : http://wiki.scilab.org/Scilab_toolboxes_management_specifications Gasc Delphine From sabine.gauzere at inria.fr Wed Apr 16 10:41:49 2008 From: sabine.gauzere at inria.fr (Sabine GAUZERE) Date: Wed, 16 Apr 2008 10:41:49 +0200 Subject: New in the Scilab team: presentation Message-ID: <1208335309.16006.7.camel@aragnon> Hello, I?m about to obtain my Master?s degree of Mathematics, Modelisation and Simulation. I?m doing my six months training period at the INRIA with Scilab team. It's overseen by Sylvestre Ledru. I?m applying my skills in applied mathematics to add missing mathematical features in Scilab, rewrite some functions, complete the help and complete the tests on specific particular cases. Sabine Ga?z?re From sylvestre.ledru at inria.fr Wed Apr 16 11:04:28 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 11:04:28 +0200 Subject: Matio dependency Message-ID: <1208336668.6451.11136.camel@korcula.inria.fr> Hello, We added a (facultative) dependency on matio [1]. We use it to read/write matlab files. In order to manage this under Linux, we added a few options: * --without-matio => disable matio (warning: m2sci & compatibility functions will bug) * --with-matio-include=/path/to/the/includes * --with-matio-library=/path/to/the/lib Since this package in not available under any Linux, you will need to compile it yourself (there is no problem to compile it, just need a gfortran compiler and zlib). I created the debian/ubuntu package which is going to be available soon. Sylvestre [1] http://sourceforge.net/projects/matio From ycollet at freesurf.fr Wed Apr 16 11:46:40 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 16 Apr 2008 11:46:40 +0200 Subject: PVM In-Reply-To: <1208336668.6451.11136.camel@korcula.inria.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> Message-ID: <4805CB00.1040703@freesurf.fr> Hello, under mandriva-200[78], pvm is shipped as a static library (extension .a). So as to the library to recognized, you must a the "a" extension in the m4/pvm.m4 file: libexts="a so so.1.0 sl dylib" Most of the time, the pvm library is stored in a directory (let's call it DIR) which has for folliwing shape: $DIR/$PVM_ARCH. In the mandriva's case, it's /usr/share/pvm3/lib/LINUX (PVM_ARCH is set to LINUX). So, you certainly must add: - /usr/share/pvm3/lib in the dirs variable of pvm.m4 - and another "loop" to test the combination PATH_LIB_PVM/PVM_ARCH ... YC From ycollet at freesurf.fr Wed Apr 16 11:49:28 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 16 Apr 2008 11:49:28 +0200 Subject: Documentation under linux Message-ID: <4805CBA8.8050504@freesurf.fr> Hello, How to install the documentation under linux ? To compile the documentation, make doc works fine for me, but the documentation is not installed by make install ... When I start scilab, it complains about missing jar help files. YC From ycollet at freesurf.fr Wed Apr 16 11:53:44 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 16 Apr 2008 11:53:44 +0200 Subject: ATI / jogl problem Message-ID: <4805CCA8.3090405@freesurf.fr> Hello, I was looking for the Scilab / ATI bug in the bug list of jogl but wasn't able to find it. Does somebody filed a bug report at jogl ? Which one is it ? YC From sylvestre.ledru at inria.fr Wed Apr 16 11:57:15 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 11:57:15 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <4805CB00.1040703@freesurf.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> Message-ID: <1208339835.6451.11158.camel@korcula.inria.fr> Hello Yann, Are you sure there is no dynamic library of PVM under Mandriva ? Under debian: ~$ dpkg -L pvm-dev|grep pvm3.so /usr/lib/libpvm3.so /usr/lib/libgpvm3.so If you confirm, I will add this check... However, I am not really keen on linking static lib in the Scilab binary. Sylvestre Le mercredi 16 avril 2008 ? 11:46 +0200, Collette Yann a ?crit : > Hello, > > under mandriva-200[78], pvm is shipped as a static library (extension .a). > So as to the library to recognized, you must a the "a" extension in the > m4/pvm.m4 file: libexts="a so so.1.0 sl dylib" > Most of the time, the pvm library is stored in a directory (let's call > it DIR) which has for folliwing shape: > $DIR/$PVM_ARCH. > In the mandriva's case, it's /usr/share/pvm3/lib/LINUX (PVM_ARCH is set > to LINUX). > So, you certainly must add: > - /usr/share/pvm3/lib in the dirs variable of pvm.m4 > - and another "loop" to test the combination PATH_LIB_PVM/PVM_ARCH ... > > YC From sylvestre.ledru at inria.fr Wed Apr 16 12:08:34 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 12:08:34 +0200 Subject: [Scilab-Dev] ATI / jogl problem In-Reply-To: <4805CCA8.3090405@freesurf.fr> References: <4805CCA8.3090405@freesurf.fr> Message-ID: <1208340514.6451.11177.camel@korcula.inria.fr> Yep http://www.javagaming.org/forums/index.php?topic=18139.0 http://www.javagaming.org/forums/index.php?topic=18080.0 Ken Russell is the JoGL dev. The bug report was: https://jogl.dev.java.net/issues/show_bug.cgi?id=339 Sylvestre Le mercredi 16 avril 2008 ? 11:53 +0200, Collette Yann a ?crit : > Hello, > > I was looking for the Scilab / ATI bug in the bug list of jogl but > wasn't able to find it. Does somebody filed a bug report at jogl ? > Which one is it ? > > YC From ycollet at freesurf.fr Wed Apr 16 12:31:23 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 16 Apr 2008 12:31:23 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <1208339835.6451.11158.camel@korcula.inria.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> Message-ID: <4805D57B.8080005@freesurf.fr> No, just static libraries in the pvm directory. I have attached a list of files contained in this directory. YC Sylvestre Ledru a ?crit : > Hello Yann, > Are you sure there is no dynamic library of PVM under Mandriva ? > > Under debian: > ~$ dpkg -L pvm-dev|grep pvm3.so > /usr/lib/libpvm3.so > /usr/lib/libgpvm3.so > > > If you confirm, I will add this check... However, I am not really keen > on linking static lib in the Scilab binary. > > Sylvestre > > Le mercredi 16 avril 2008 ? 11:46 +0200, Collette Yann a ?crit : > >> Hello, >> >> under mandriva-200[78], pvm is shipped as a static library (extension .a). >> So as to the library to recognized, you must a the "a" extension in the >> m4/pvm.m4 file: libexts="a so so.1.0 sl dylib" >> Most of the time, the pvm library is stored in a directory (let's call >> it DIR) which has for folliwing shape: >> $DIR/$PVM_ARCH. >> In the mandriva's case, it's /usr/share/pvm3/lib/LINUX (PVM_ARCH is set >> to LINUX). >> So, you certainly must add: >> - /usr/share/pvm3/lib in the dirs variable of pvm.m4 >> - and another "loop" to test the combination PATH_LIB_PVM/PVM_ARCH ... >> >> YC >> > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: list.txt URL: From ycollet at freesurf.fr Wed Apr 16 13:44:09 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Wed, 16 Apr 2008 13:44:09 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <4805D57B.8080005@freesurf.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> <4805D57B.8080005@freesurf.fr> Message-ID: <4805E689.7020800@freesurf.fr> I am still having a compilation problem with pvm: make[2]: entrant dans le r?pertoire ? /local/scilab-dev/scilab/modules/javasci ? Buildfile: build.xml init: compile: jar: BUILD SUCCESSFUL Total time: 0 seconds make[2]: quittant le r?pertoire ? /local/scilab-dev/scilab/modules/javasci ? make[1]: quittant le r?pertoire ? /local/scilab-dev/scilab/modules ? make[1]: entrant dans le r?pertoire ? /local/scilab-dev/scilab ? ./bin/scilab -ns -nwni -f modules/functions/scripts/buildmacros/buildmacros.sce /local/scilab-dev/scilab/.libs/lt-scilab-bin: symbol lookup error: /local/scilab-dev/scilab/modules/pvm/.libs/libscipvm.so.5: undefined symbol: PvmMin make[1]: [macros] Erreur 127 (ignor?e) make[1]: quittant le r?pertoire ? /local/scilab-dev/scilab ? This symbol is used only in modules/pvm/src/c/pvm_grp.c This symbol is defined only in the library /usr/share/pvm3/lib/LINUX/libgpvm3.a I have added in modules/pvm/Makefile a definition for LDFLAGS: LDFLAGS=-L/usr/share/pvm3/lib/LINUX -lgpvm3 -lpvm3 And now, scilab with pvm compiles fine now. YC Collette Yann a ?crit : > No, just static libraries in the pvm directory. > I have attached a list of files contained in this directory. > > YC > > Sylvestre Ledru a ?crit : >> Hello Yann, >> Are you sure there is no dynamic library of PVM under Mandriva ? >> >> Under debian: >> ~$ dpkg -L pvm-dev|grep pvm3.so >> /usr/lib/libpvm3.so >> /usr/lib/libgpvm3.so >> >> >> If you confirm, I will add this check... However, I am not really keen >> on linking static lib in the Scilab binary. >> >> Sylvestre >> >> Le mercredi 16 avril 2008 ? 11:46 +0200, Collette Yann a ?crit : >> >>> Hello, >>> >>> under mandriva-200[78], pvm is shipped as a static library >>> (extension .a). >>> So as to the library to recognized, you must a the "a" extension in >>> the m4/pvm.m4 file: libexts="a so so.1.0 sl dylib" >>> Most of the time, the pvm library is stored in a directory (let's >>> call it DIR) which has for folliwing shape: >>> $DIR/$PVM_ARCH. >>> In the mandriva's case, it's /usr/share/pvm3/lib/LINUX (PVM_ARCH is >>> set to LINUX). >>> So, you certainly must add: >>> - /usr/share/pvm3/lib in the dirs variable of pvm.m4 >>> - and another "loop" to test the combination PATH_LIB_PVM/PVM_ARCH ... >>> >>> YC >>> >> >> > From Simone.Mannori at inria.fr Wed Apr 16 13:56:24 2008 From: Simone.Mannori at inria.fr (Simone Mannori) Date: Wed, 16 Apr 2008 13:56:24 +0200 Subject: [Scilab-Dev] Matio dependency (Fedora) In-Reply-To: <1208336668.6451.11136.camel@korcula.inria.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> Message-ID: <1208346984.2929.51.camel@pinarellu.inria.fr> Hello: for Fedora user "libmatio-dev" is NOT packaged : download source code from http://sourceforge.net/projects/matio unpak it "tar xjvf matio-1.3.2.tar.bz2 " change folder "cd matio-1.3.2" "./configure" "make" switch to super-user with "su" then "make install" very paranoiac user like me run also "/sbin/ldconfig" With this procedure Scilab's "./configure" will detect automatically the installed library... and everybody will live and prosper ;) Simone P.S. Yes: I like compile Scilab ;) On Wed, 2008-04-16 at 11:04 +0200, Sylvestre Ledru wrote: > Hello, > > We added a (facultative) dependency on matio [1]. We use it to > read/write matlab files. > > In order to manage this under Linux, we added a few options: > * --without-matio => disable matio (warning: m2sci & compatibility > functions will bug) > * --with-matio-include=/path/to/the/includes > * --with-matio-library=/path/to/the/lib > > Since this package in not available under any Linux, you will need to > compile it yourself (there is no problem to compile it, just need a > gfortran compiler and zlib). > I created the debian/ubuntu package which is going to be available soon. > > Sylvestre > > > [1] http://sourceforge.net/projects/matio > > From enrico.segre at weizmann.ac.il Wed Apr 16 16:48:50 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Wed, 16 Apr 2008 17:48:50 +0300 Subject: Matio dependency (Fedora) Message-ID: <1208357330.4858.47.camel@segre-pc2.weizmann.ac.il> Believe it or not, this doesn't work for me on CentOs51 (essentially RHEL5) [root at segre-pc2 matio-1.3.2]# make Making all in src make[1]: Entering directory `/usr/share/scilab/matio-1.3.2/src' make all-am make[2]: Entering directory `/usr/share/scilab/matio-1.3.2/src' /bin/sh ../libtool --mode=link -o libmatio.la -rpath /usr/local/lib snprintf.lo endian.lo io.lo inflate.lo read_data.lo mat5.lo mat4.lo mat.lo -lm libtool: unrecognized option `-o' Try `libtool --help' for more information. make[2]: *** [libmatio.la] Error 1 make[2]: Leaving directory `/usr/share/scilab/matio-1.3.2/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/share/scilab/matio-1.3.2/src' make: *** [all-recursive] Error 1 Not even [root at segre-pc2 src]# libtool --mode=link -o libmatio.la -rpath /usr/local/lib snprintf.lo endian.lo io.lo inflate.lo read_data.lo mat5.lo mat4.lo mat.lo -lm libtool: unrecognized option `-o' (that is using the systemwide libtool rather than the ones coming with matio - and I even upgraded to libtool-1.5.24-3.fc8.x86_64) Investigating why... Enrico From sylvestre.ledru at inria.fr Wed Apr 16 17:20:53 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 17:20:53 +0200 Subject: [Scilab-Dev] Re: Re: Matio dependency (Fedora) In-Reply-To: <1208357330.4858.47.camel@segre-pc2.weizmann.ac.il> References: <1208357330.4858.47.camel@segre-pc2.weizmann.ac.il> Message-ID: <1208359253.6451.11247.camel@korcula.inria.fr> It is a bug in matio. It doesn't stop when it cannot find gfortran. Check if it is well install. If it is the case, try: ./configure F77=gfortran and retry to build Sylvestre Le mercredi 16 avril 2008 ? 17:48 +0300, Enrico Segre a ?crit : > Believe it or not, this doesn't work for me on CentOs51 (essentially > RHEL5) > > [root at segre-pc2 matio-1.3.2]# make > Making all in src > make[1]: Entering directory `/usr/share/scilab/matio-1.3.2/src' > make all-am > make[2]: Entering directory `/usr/share/scilab/matio-1.3.2/src' > /bin/sh ../libtool --mode=link -o libmatio.la -rpath /usr/local/lib > snprintf.lo endian.lo io.lo inflate.lo read_data.lo mat5.lo mat4.lo > mat.lo -lm > libtool: unrecognized option `-o' > Try `libtool --help' for more information. > make[2]: *** [libmatio.la] Error 1 > make[2]: Leaving directory `/usr/share/scilab/matio-1.3.2/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/usr/share/scilab/matio-1.3.2/src' > make: *** [all-recursive] Error 1 > > > Not even > > [root at segre-pc2 src]# libtool --mode=link -o libmatio.la > -rpath /usr/local/lib snprintf.lo endian.lo io.lo inflate.lo > read_data.lo mat5.lo mat4.lo mat.lo -lm > libtool: unrecognized option `-o' > > (that is using the systemwide libtool rather than the ones coming with > matio - and I even upgraded to libtool-1.5.24-3.fc8.x86_64) > > Investigating why... > > Enrico > From sylvestre.ledru at inria.fr Wed Apr 16 19:03:01 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 19:03:01 +0200 Subject: [Scilab-Dev] building on x64 In-Reply-To: <1206950617.4393.45.camel@segre-pc2.weizmann.ac.il> References: <1206949444.4393.37.camel@segre-pc2.weizmann.ac.il> <47F09A7A.4010806@inria.fr> <1206950617.4393.45.camel@segre-pc2.weizmann.ac.il> Message-ID: <1208365381.4333.7.camel@zlarin.inria.fr> Le lundi 31 mars 2008 ? 11:03 +0300, Enrico Segre a ?crit : > On Mon, 2008-03-31 at 10:02 +0200, Vincent COUVERT wrote: > > Hi Enrico, > > > > All the issues you talk about are x64 issues only or you can reproduce > > these problems under x32 versions ? > > only x64 built from sources. I didn't try the 32bit prebuilt binary on > x64, but I can compare with a 32b on another system. > The debugger, however, is still broken on 32b. On x64, IIRC one way of > crashing is to open scipad. Hello Enrico, Jumping on your message. Which Linux are you using ? Intel or AMD CPU ? I tried again. I can compile macros but even the nwni is crashing at the end of the init (wrong size pointer) with a 64 bits intel. Thanks, Sylvestre -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sylvestre.ledru at inria.fr Wed Apr 16 22:44:55 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Wed, 16 Apr 2008 22:44:55 +0200 Subject: Link of Dynast with Scilab WAS: Please, help In-Reply-To: <1208091121.480201f159ab5@imap.vc.cvut.cz> References: <1208091121.480201f159ab5@imap.vc.cvut.cz> Message-ID: <1208378695.4333.62.camel@zlarin.inria.fr> Hello Herman, There are many way of "merging" (I would call it link) a third party software/library with Scilab. It really depends your needs. If you want to extend Scilab with your software, you can have a look to http://wiki.scilab.org/howto/Create_a_toolbox If you want to export something in the Scilab language or in Scicos, you will need to get familiar with Scilab/Scicos. You will find many information on our website, in the Scilab documentation, Wiki, mailing lists archives, and in the newsgroup. And of course, you can always send questions on this mailing list. By the way, I haven't been able to find the source of your program, is it proprietary ? Hope this helps, Sylvestre Le dimanche 13 avril 2008 ? 14:52 +0200, Herman Mann a ?crit : > Dear Scilab developers, > > Excuse me please for encroaching upon your time. We have developed > a package called DYNAST for physical-level simulation some 25 years > ago and we are still upgrading it regularly. As you can see from > the enclosed paper DYNAST can export transfer functions in a semi- > symbolic form fro MATLAB and also, it is capable of co-simulation > with Simulink. DYNAST users ask us for merging it with your software. > Could you please advice us about a source of information how to do > it? > > Looking forward to your favorable response, > With my best regards, > > Herman Mann > P.S. Please, have a look at virtual.cvut.cz/dynlab/ > > Dipl.Ing. Herman Mann, PhD. ScD. > Associated Professor > Computing and Information Centre > Czech Technical University in Prague > Phone +420-22435.2933 or -60558.6485 > http://virtual.cvut.cz/mann/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From enrico.segre at weizmann.ac.il Thu Apr 17 10:14:10 2008 From: enrico.segre at weizmann.ac.il (Enrico Segre) Date: Thu, 17 Apr 2008 11:14:10 +0300 Subject: [Scilab-Dev] building on x64 In-Reply-To: <1208365381.4333.7.camel@zlarin.inria.fr> References: <1206949444.4393.37.camel@segre-pc2.weizmann.ac.il> <47F09A7A.4010806@inria.fr> <1206950617.4393.45.camel@segre-pc2.weizmann.ac.il> <1208365381.4333.7.camel@zlarin.inria.fr> Message-ID: <1208420050.26834.13.camel@segre-pc2.weizmann.ac.il> Hi Sylvestre, > Jumping on your message. Which Linux are you using ? Intel or AMD CPU ? for what matters, CentOs5.1 on quadcore Intel(R) Xeon(R) E5345 > I tried again. I can compile macros but even the nwni is crashing at the > end of the init (wrong size pointer) with a 64 bits intel. This is more or less as far as I could get too for a long time, until a couple of months ago, then the problem autosolved - in the sense that I became able to launch the shell some 1 times every N (with N-1 different possible segfaults picked at random - isn't this a hint of thread insanity?). At that point I reported the bunch of bugs ~2820-2840, which are almost all still open. Good luck, Enrico From sylvestre.ledru at inria.fr Fri Apr 18 11:57:13 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Fri, 18 Apr 2008 11:57:13 +0200 Subject: [Scilab-Dev] building on x64 In-Reply-To: <1208420050.26834.13.camel@segre-pc2.weizmann.ac.il> References: <1206949444.4393.37.camel@segre-pc2.weizmann.ac.il> <47F09A7A.4010806@inria.fr> <1206950617.4393.45.camel@segre-pc2.weizmann.ac.il> <1208365381.4333.7.camel@zlarin.inria.fr> <1208420050.26834.13.camel@segre-pc2.weizmann.ac.il> Message-ID: <1208512633.5771.309.camel@korcula.inria.fr> > > I tried again. I can compile macros but even the nwni is crashing at the > > end of the init (wrong size pointer) with a 64 bits intel. > > This is more or less as far as I could get too for a long time, until a > couple of months ago, then the problem autosolved - in the sense that I > became able to launch the shell some 1 times every N (with N-1 different > possible segfaults picked at random - isn't this a hint of thread > insanity?). Now, we get the same issue here too. We will investigate. Sylvestre From ycollet at freesurf.fr Fri Apr 18 13:51:20 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 18 Apr 2008 13:51:20 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <1208339835.6451.11158.camel@korcula.inria.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> Message-ID: <48088B38.1090808@freesurf.fr> Sylvestre Ledru a ?crit : > Hello Yann, > Are you sure there is no dynamic library of PVM under Mandriva ? > > Under debian: > ~$ dpkg -L pvm-dev|grep pvm3.so > /usr/lib/libpvm3.so > /usr/lib/libgpvm3.so > > > If you confirm, I will add this check... However, I am not really keen > on linking static lib in the Scilab binary. > > Sylvestre > > Le mercredi 16 avril 2008 ? 11:46 +0200, Collette Yann a ?crit : > >> Hello, >> >> under mandriva-200[78], pvm is shipped as a static library (extension .a). >> So as to the library to recognized, you must a the "a" extension in the >> m4/pvm.m4 file: libexts="a so so.1.0 sl dylib" >> Most of the time, the pvm library is stored in a directory (let's call >> it DIR) which has for folliwing shape: >> $DIR/$PVM_ARCH. >> In the mandriva's case, it's /usr/share/pvm3/lib/LINUX (PVM_ARCH is set >> to LINUX). >> So, you certainly must add: >> - /usr/share/pvm3/lib in the dirs variable of pvm.m4 >> - and another "loop" to test the combination PATH_LIB_PVM/PVM_ARCH ... >> >> YC >> > > And what about to put the pvm sources into the scilab tree and compile this sources if configure can't find the pvm .so library ? Like in scilab-4.1.2 ? By the way, PVM is working really fine with the patch and I am about to have a parallel genetic algorithm (thanks to a student). YC From ycollet at freesurf.fr Fri Apr 18 14:38:43 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 18 Apr 2008 14:38:43 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <48088B38.1090808@freesurf.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> <48088B38.1090808@freesurf.fr> Message-ID: <48089653.5010506@freesurf.fr> Bug 40204 filled in mandriva bugzilla. I asked for a package rebuild. https://qa.mandriva.com/show_bug.cgi?id=40204 YC From sylvestre.ledru at inria.fr Fri Apr 18 15:09:28 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Fri, 18 Apr 2008 15:09:28 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <48089653.5010506@freesurf.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> <48088B38.1090808@freesurf.fr> <48089653.5010506@freesurf.fr> Message-ID: <1208524168.5771.403.camel@korcula.inria.fr> It is exactly what I was going to ask you to do ;) Sylvestre Le vendredi 18 avril 2008 ? 14:38 +0200, Collette Yann a ?crit : > Bug 40204 filled in mandriva bugzilla. I asked for a package rebuild. > > https://qa.mandriva.com/show_bug.cgi?id=40204 > > YC From ycollet at freesurf.fr Fri Apr 18 15:08:18 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 18 Apr 2008 15:08:18 +0200 Subject: OpenMPI Message-ID: <48089D42.5070504@freesurf.fr> Hello, I've seen a "OpenMPI" in the sum-up of the configure script. Where is openmpi used ? Is it there for scilab 6 ? YC From sylvestre.ledru at inria.fr Fri Apr 18 15:25:37 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Fri, 18 Apr 2008 15:25:37 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <48088B38.1090808@freesurf.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> <48088B38.1090808@freesurf.fr> Message-ID: <1208525137.5771.415.camel@korcula.inria.fr> > And what about to put the pvm sources into the scilab tree and compile > this sources if configure can't find the pvm .so library ? > Like in scilab-4.1.2 ? No way :p I explain you why. First, if you start to embed third party sources into your source tree, where will it end ? You know our dependency list [1]; why should I put PVM and not FFTW, matio or PCRE ? (btw, I am too unhappy about having lapack & blas into the source tree to add more dep into Scilab) Second, when you incorporate third party code, you are more entitle to edit the sources when you find a bug, instead of submitting a bug report and waiting for the new upstream version (and consequently having the risk of divergence. Third, you have to integrate the source into your compilation process. Autotools being everything but standard and straightforward, you have to redo what they have done. Have I been convincing enough ? :) > By the way, PVM is working really fine with the patch The patch from JPC ? I have to apply it in the trunk. > and I am about to > have a parallel genetic algorithm (thanks to a student). Cool, I am interested to see the result ! Sylvestre [1] http://wiki.scilab.org/Dependencies_of_Scilab_5.X From sylvestre.ledru at inria.fr Fri Apr 18 15:35:04 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Fri, 18 Apr 2008 15:35:04 +0200 Subject: [Scilab-Dev] OpenMPI In-Reply-To: <48089D42.5070504@freesurf.fr> References: <48089D42.5070504@freesurf.fr> Message-ID: <1208525704.5771.469.camel@korcula.inria.fr> > I've seen a "OpenMPI" in the sum-up of the configure script. Where is > openmpi used ? On my hard drive :p A few month ago, I started to work on a Scilab MPI. I have a few proofs of concept but nothing usable (except if you like distributed "Hello World"). I started to update the configure to manage the detection of OpenMPI and I forgot to remove it in a commit. I cleanned up the output. Thanks for pointing this out. > Is it there for scilab 6 ? Most probably the version 6; maybe the version 5.1 if my cloning machine works on me. ;) Sylvestre From ycollet at freesurf.fr Fri Apr 18 15:42:05 2008 From: ycollet at freesurf.fr (Collette Yann) Date: Fri, 18 Apr 2008 15:42:05 +0200 Subject: [Scilab-Dev] PVM In-Reply-To: <1208525137.5771.415.camel@korcula.inria.fr> References: <1208336668.6451.11136.camel@korcula.inria.fr> <4805CB00.1040703@freesurf.fr> <1208339835.6451.11158.camel@korcula.inria.fr> <48088B38.1090808@freesurf.fr> <1208525137.5771.415.camel@korcula.inria.fr> Message-ID: <4808A52D.3030303@freesurf.fr> Sylvestre Ledru a ?crit : >> And what about to put the pvm sources into the scilab tree and compile >> this sources if configure can't find the pvm .so library ? >> Like in scilab-4.1.2 ? >> > No way :p > I explain you why. > > First, if you start to embed third party sources into your source tree, > where will it end ? > You know our dependency list [1]; why should I put PVM and not FFTW, > matio or PCRE ? > (btw, I am too unhappy about having lapack & blas into the source tree > to add more dep into Scilab) > > Second, when you incorporate third party code, you are more entitle to > edit the sources when you find a bug, instead of submitting a bug report > and waiting for the new upstream version (and consequently having the > risk of divergence. > > Third, you have to integrate the source into your compilation process. > Autotools being everything but standard and straightforward, you have to > redo what they have done. > > Have I been convincing enough ? :) > > > Wow, how convincing you are !!! >> By the way, PVM is working really fine with the patch >> > The patch from JPC ? > I have to apply it in the trunk. > > Serge Steer has already submitted a simpler patch into scilab 5. So, don't need to apply the JPC one. >> and I am about to >> have a parallel genetic algorithm (thanks to a student). >> > Cool, I am interested to see the result ! > > Me too, but, you know, students .... > Sylvestre > [1] http://wiki.scilab.org/Dependencies_of_Scilab_5.X > > From mann at vc.cvut.cz Mon Apr 21 13:33:17 2008 From: mann at vc.cvut.cz (Herman Mann) Date: Mon, 21 Apr 2008 13:33:17 +0200 Subject: Co-simulation Message-ID: <1208777597.480c7b7dedf39@imap.vc.cvut.cz> Dear Dr Gomez, Excuse me please for encroaching upon your time. We have developed a package called DYNAST for physical-level simulation some 25 years ago and we are still upgrading it regularly. Since that time, DYNAST can set-up algebro-differential equations for a physical scheme of a nonlinear dynamic system automatically. Also, it can then linearize the equations and deliver the required transfer functions of the analyzed system in a semisymbolic form. Dynast can be accessed across the Internet at virtual.cvut.cz/dynlabcourse/ and virtual.cvut.cz/dyn/examples/ A paper on the software is enclosed. Some of our users export the transfer functions to the MATLAB control-design environment or link it to Simulink for co-simulation of digitally controlled plants modeled in a realistic way. Years ago, some of the users ask us for a similar option in the connection to your software. I met some of your group members during IEEE CACSD Symposia in Taipei and Munich, they seemed to like my idea, they were able to communicate in English, and promised sending me instructions how to adapt our software for its communication with Scilab. They, however, never sent me anything and did not answered my e-mails. All French people I met so far were very polite, so I have no explanation for such behavior. Looking forward to your favorable response, With my best regards, Herman Mann Dipl.Ing. Herman Mann, PhD. ScD. Associated Professor Computing and Information Centre Czech Technical University in Prague Phone +420-22435.2933 or -60558.6485 http://virtual.cvut.cz/mann/ From sylvestre.ledru at inria.fr Mon Apr 21 15:17:24 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Mon, 21 Apr 2008 15:17:24 +0200 Subject: [Scilab-Dev] Co-simulation In-Reply-To: <1208777597.480c7b7dedf39@imap.vc.cvut.cz> References: <1208777597.480c7b7dedf39@imap.vc.cvut.cz> Message-ID: <1208783844.3915.875.camel@korcula.inria.fr> Hello Herman, Seems you didn't received my email: http://lists.scilab.org/cgi-bin/ezmlm-browse?list=dev&cmd=showmsg&msgnum=285 Regards, Sylvestre Le lundi 21 avril 2008 ? 13:33 +0200, Herman Mann a ?crit : > Dear Dr Gomez, > > Excuse me please for encroaching upon your time. > > We have developed a package called DYNAST for physical-level > simulation some 25 years ago and we are still upgrading it regularly. > Since that time, DYNAST can set-up algebro-differential equations > for a physical scheme of a nonlinear dynamic system automatically. > Also, it can then linearize the equations and deliver the required > transfer functions of the analyzed system in a semisymbolic form. > Dynast can be accessed across the Internet at > virtual.cvut.cz/dynlabcourse/ and virtual.cvut.cz/dyn/examples/ > A paper on the software is enclosed. > > Some of our users export the transfer functions to the MATLAB > control-design environment or link it to Simulink for co-simulation > of digitally controlled plants modeled in a realistic way. Years ago, > some of the users ask us for a similar option in the connection to > your software. > > I met some of your group members during IEEE CACSD Symposia in Taipei > and Munich, they seemed to like my idea, they were able to communicate > in English, and promised sending me instructions how to adapt our > software for its communication with Scilab. They, however, never sent > me anything and did not answered my e-mails. All French people I met > so far were very polite, so I have no explanation for such behavior. > > Looking forward to your favorable response, > With my best regards, > > Herman Mann > > Dipl.Ing. Herman Mann, PhD. ScD. > Associated Professor > Computing and Information Centre > Czech Technical University in Prague > Phone +420-22435.2933 or -60558.6485 > http://virtual.cvut.cz/mann/ > From pierre.marechal at inria.fr Fri Apr 25 10:49:30 2008 From: pierre.marechal at inria.fr (Pierre MARECHAL) Date: Fri, 25 Apr 2008 10:49:30 +0200 Subject: Beta 1 version of Scilab Message-ID: <48119B1A.6050808@inria.fr> Hello, We just released the first beta version of Scilab. Misc information about this version: http://www.scilab.org/download/index_download.php?page=5.0-beta-1 List of changes: http://www.scilab.org/download/index_download.php?page=CHANGES_5.0-beta-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-beta-1 Pierre -- =================================================== Pierre MARECHAL INRIA - Centre de Recherche de Paris - Rocquencourt Domaine de Voluceau - B.P. 105 78153 Le Chesnay Cedex =================================================== Equipe-Projet Scilab B?timent 1B - Bureau 008 Email : pierre.marechal at inria.fr =================================================== From fvogelnew1 at free.fr Sun Apr 27 22:38:36 2008 From: fvogelnew1 at free.fr (=?ISO-8859-1?Q?Fran=E7ois_Vogel?=) Date: Sun, 27 Apr 2008 22:38:36 +0200 Subject: Breakpoints set in the pseudocode of functions Message-ID: <4814E44C.2000907@free.fr> Hi Serge, I have seen that in order to close bug 2542 you wrote macros add_profiling, remove_profiling, and so on, that use the bytecode of the function to profile. This looks very nice to me. I was wondering if the same approach could be used with some advantage to set/remove breakpoints in functions instead of using set/delbpt? I remember you mentioned such an approach a few years ago, but I think this never took shape. Currently setbpt/delbpt maintain an internal array of breakpoints (function names and line numbers), and this array is checked during execution of each line against the current execution point. The new approach would be to store a special pseudocode after each line of each function, telling whether the execution should stop at this point or not. See also http://bugzilla.scilab.org/show_bug.cgi?id=884#c1 I think you wrote me privately a long time ago that such a new approach would have some other advantages, but I can't remember which ones exactly at the moment. Do you have any thoughts on this old idea in the light of what you just achieved for profiling with pseudocodes? Thanks, Francois From sylvestre.ledru at inria.fr Tue Apr 29 11:00:27 2008 From: sylvestre.ledru at inria.fr (Sylvestre Ledru) Date: Tue, 29 Apr 2008 11:00:27 +0200 Subject: [Fwd: [Fwd: Re: Breakpoints set in the pseudocode of functions]] Message-ID: <1209459627.26024.1242.camel@korcula.inria.fr> Could be interesting for other Scilab devs -------- Message transf?r? -------- De: Serge Steer R?pondre ?: Serge.Steer at inria.fr ?: fvogelnew1 at free.fr Sujet: Re: Breakpoints set in the pseudocode of functions Date: Mon, 28 Apr 2008 10:05:10 +0000 Fran?ois Vogel a ?crit : > Hi Serge, > > I have seen that in order to close bug 2542 you wrote macros > add_profiling, remove_profiling, and so on, that use the bytecode of > the function to profile. This looks very nice to me. > > I was wondering if the same approach could be used with some advantage > to set/remove breakpoints in functions instead of using set/delbpt? I > remember you mentioned such an approach a few years ago, but I think > this never took shape. > > Currently setbpt/delbpt maintain an internal array of breakpoints > (function names and line numbers), and this array is checked during > execution of each line against the current execution point. > > The new approach would be to store a special pseudocode after each > line of each function, telling whether the execution should stop at > this point or not. > > See also http://bugzilla.scilab.org/show_bug.cgi?id=884#c1 > > I think you wrote me privately a long time ago that such a new > approach would have some other advantages, but I can't remember which > ones exactly at the moment. > > Do you have any thoughts on this old idea in the light of what you > just achieved for profiling with pseudocodes? > > Thanks, > Francois > > I am still thinking about that. But there are some difficult points with the current way the function are handled: - it is not possible to change the internal coding of a function while it is running (strictly speaking, it is not possible to change the sizes). Here a possible solution should be to prepare a function for debugging adding void pseudo codes at the end of each line (see below) . then at run time to replace these void pseudo codes by a break point pseudo-code, without changing the sizes. - if a function is modified inside a given context (for example to activate a breakpoint) the modification will be lost in the calling contexts - if a function is reloaded, the current breakpoints must be recreated. Serge ps: preparation for debugging can be made by function add_debugging(funname) //add debugging instruction bytecode after each function line nsiz=6 execstr('code=bytecode('+funname+')') lc=1 lc = lc + nsiz*double(code(lc)) + 1 lc = lc + nsiz*double(code(lc)) + 1 long=code(lc) lc = lc+1 c=code(lc:$) c1=bytecodewalk(c,15,addvoid) code=[code(1:lc-2) int32(size(c1,'*')) c1] execstr(funname+' = resume(bytecode(code))') endfunction with function [c,l]=addvoid(l) //add debugging instruction bytecode c=int32([15 0 3 0]);l=l+1; endfunction The op code 0 just make the interpretor skip n integers in the pseudo code, where n is the value just after the op code 15 is the eol opcode To introduce a break point somewhere one has then to replace the sequence [0 3 0] by [12 0 2] where 12 is the pause opcode