From kirill.kirillov at gmail.com  Mon Jun  1 00:17:53 2009
From: kirill.kirillov at gmail.com (Kirill Kirillov)
Date: Mon, 01 Jun 2009 02:17:53 +0400
Subject: [Scilab-Dev] x_mdialog for editing matrices
Message-ID: <1243808273.4016.17.camel@faith.universe>

Hi!

I've tried to use x_mdialog function for editing matrices using idea
found in Scilab demos (GUI dialog example), but it seems that this
function is not suitable for this.

Take a look at the following example:
rows = ['row1' 'row2'];
cols = ['col1' 'col2' 'col3'];
test = [1 1 1; 0 0 0];
x_mdialog('Testing', rows, cols, string(test))

Results:
1) [1 0 1; 0 1 0] in row1 and row2 instead original [1 1 1; 0 0 0];
2) col1, col2 and col3 should be shifted to be above correspondent cells

Are these bugs?

-- 
Kirill Kirillov
<><



From vincent.lejeune at institutoptique.fr  Mon Jun  1 20:02:29 2009
From: vincent.lejeune at institutoptique.fr (Vincent Lejeune)
Date: Mon, 1 Jun 2009 20:02:29 +0200
Subject: [Scilab-Dev] Issue with the Stack in Linux
In-Reply-To: <200905302353.39964.vincent.lejeune@institutoptique.fr>
References: <200905302353.39964.vincent.lejeune@institutoptique.fr>
Message-ID: <112B7E3BBBE24E0B8FF679801ECE6488@VLJMAISON>

Sorry, in fact my installation was corrupted.
I don't know why, but the SciLab binaries on kubuntu repository (version 
5.1, not 5.1.1) seems not to accept the use of SCILAB_POINTER_TYPE. However, 
everything work fine with the binary from scilab.org.

--------------------------------------------------
From: "Vincent Lejeune" <vincent.lejeune at institutoptique.fr>
Sent: Saturday, May 30, 2009 11:53 PM
To: <dev at lists.scilab.org>
Subject: [Scilab-Dev] Issue with the Stack in Linux

> Hi,
>
> I'm trying to make my toolbox running on Kubuntu 9.04 (Jaunty 64bits),
> and I'm facing a issue with the management of
> SCILAB_POINTER_DATATYPE.
>
> It seems that the pointer is not recorded into the stack : when I'm
> tryng to get it back, I only get a NULL pointer, according to gdb and
> several sciprint in my code.
> I'm using CreateListVarFromPtr and GetListRhsVar to put and retrieve
> the pointer. It works on my Windows Vista 32 bits, however, so I
> suspected an issue with pointer size : I changed (unsigned long) cast
> to (intptr_t), but it didnt change anything.
>
> gMatrix is an alias to a pointer.
> I've attached my gatewayfunctions in sci_togpu.c, the header file
> cuLU.h (needed for compilation), and libcuLU.so, the library generated
> by my /src (with -g flags, so it holds debugging symbol) in order to
> make the problem reproduceable if necessary.
>
> I think that I'm just misusing the stk() function with 64bits code...
> 



From vincent.lejeune at institutoptique.fr  Tue Jun  2 16:27:34 2009
From: vincent.lejeune at institutoptique.fr (Vincent Lejeune)
Date: Tue, 2 Jun 2009 16:27:34 +0200
Subject: What is the Fortran function maxvol ?
Message-ID: <200906021627.34636.vincent.lejeune@institutoptique.fr>

Hi,

In SciLabs Fortran part of code, there is a "maxvol" function that come 
several time, for instance in intdgesv3.f, intdgecon.f, sci_f_mucomp.f ...
The function is typically called this way :
LWORK=maxvol(10,'d')

(when the function is acting on complex, 'd' is replaced by 'z')
I am no Fortran expert, but I'd like to know what this function does. I 
dont find its definition in scilab's git repository (I used nepomuk...), and I 
didnt catch any results on any google search. I suspect this function has 
to deal with some parallel activities, as it is frequently summoned 
besides Lapack call...

Thanks for the help !



From bernard.hugueney at scilab.org  Wed Jun  3 09:14:29 2009
From: bernard.hugueney at scilab.org (bernard.hugueney at scilab.org)
Date: Wed, 03 Jun 2009 09:14:29 +0200
Subject: [Scilab-Dev] What is the Fortran function maxvol
 =?UTF-8?Q?=3F?=
In-Reply-To: <200906021627.34636.vincent.lejeune@institutoptique.fr>
References: <200906021627.34636.vincent.lejeune@institutoptique.fr>
Message-ID: <0b29511bc9593cd63fa9a415e7362bfa@localhost>

On Tue, 2 Jun 2009 16:27:34 +0200, Vincent Lejeune
<vincent.lejeune at institutoptique.fr> wrote:
> Hi,
> 
> In SciLabs Fortran part of code, there is a "maxvol" function that come 
> several time, for instance in intdgesv3.f, intdgecon.f, sci_f_mucomp.f
...
> The function is typically called this way :
> LWORK=maxvol(10,'d')
> 
> (when the function is acting on complex, 'd' is replaced by 'z')
> I am no Fortran expert, but I'd like to know what this function does. I 
> dont find its definition in scilab's git repository (I used nepomuk...),
> and I 
> didnt catch any results on any google search. I suspect this function has

> to deal with some parallel activities, as it is frequently summoned 
> besides Lapack call...
> 
> Thanks for the help !
> 

If I am not mistaken, this function returns the max number of elements in
 a matrix of type double ('d') or complex ('z') that can be allocated on 
the Scilab stack. It is called before Lapack functions that require 
a temporary workspace of unbounded size (the more the better).

The Fortran routine can allocates all the size available on the stack
because 
no further allocation will be neded before the temporary workspace is
needed. 

When coding in C, you won't use the Scilab stack for temporary workspace
because
 you can use malloc fir dynamic memory allocation (well, MALLOC in fact,
with #include "MALLOC.h"). 
However, you cannot malloc all the heap memory available like Fortran could

alloc all the scilab stack memory available ! So you have to choose the
best size 
and you can know which size is best by calling the Lapack routine with 
a special query mode by passing a worksize of -1 (but still passing
relevent values
 for nb of rows/cols for exemple because Lapack will use them to compute 
the optimal size). Lapack routines will then return the computed optimal
size at 
the begining of the "workspace" (so you cannont pass NULL, but should
instead 
pass &a_variable_of_type_double ). As small an example is worth a thousand
words :
 " with : 
static int dsyevWorkSizes(int iCols, int* optWorkSize, int* minWorkSize) {
 int info=0, query=-1; 
 double opt; 
 C2F(dsyev)("N", "U", &iCols, NULL, &iCols, NULL, &opt, &query, &info);
 *optWorkSize= (int)opt;
 *minWorkSize= Max(1, 3*iCols -1); /* this is documented in Lapack API
specifications */
 return info;
 }

 you could write : 

int optWs, minWs; 
if(!dsyevWorkSizes(cols, &optWs, &minWs) {
 double* workspace= NULL;
 int wsSize= 0;

 workspace=MALLOC(optWs);
 if(workspace) { wsSize= optWs; } 
 else { 
   workspace= MALLOC(minWs);
   if(workspace){ wsSize= minWs; }
 }
 if(workspace) {
 /* now you can call Lapack routine with dynamicaly allocated workspace of
size wsSize */
 } 
[...]


 HTH. (feel free to ask again if I was not clear).

Regards,

Bernard 


From stephane.mottelet at utc.fr  Thu Jun  4 12:34:32 2009
From: stephane.mottelet at utc.fr (=?UTF-8?B?U3TCjsOpcGhhbmUgTW90dGVsZXQ=?=)
Date: Thu, 04 Jun 2009 12:34:32 +0200
Subject: Bizarre figure_size convention in 5.1.1
In-Reply-To: <4A0C2878.7020202@utc.fr>
References: <4A02F34E.8020205@utc.fr> <1241786374.4977.34.camel@zlarin>	 <4A0BCBD1.60305@utc.fr> <1242287201.4719.13149.camel@korcula.inria.fr>	 <4A0BCE8E.1090200@utc.fr>	 <1242288182.4719.13210.camel@korcula.inria.fr>	 <4A0BD177.4020802@utc.fr> <f3a3df490905140414h651e45ady46471ffc92e43178@mail.gmail.com> <4A0C2878.7020202@utc.fr>
Message-ID: <4A27A338.4010309@utc.fr>

Hi all,

this as been bugzilled #4521, but I discovered that really big problems are
a consequence of this issue. I am currently developping a feature
which needs to identify the handle of an axis where a mouse
clik occured (with an event_handler function). Since the coordinates
recovered in the event handler function are integer coordinates in
the *real*canvas of the figure, it is impossible to compute the
real limits of the axis in pixel coordinates (using the axis_bounds
property), since the figure_size property is wrong (the height is
not equal to the height of the canvas).

I now there may be more critical bugs, but this one is really
problematic for people developping some stuff related
to graphics...

S.

St??phane Mottelet a ?crit :
> Hi again,
>
> seems that the figure_size definition has changed in 5.1.1, this 
> causes some
> different behaviour between e.g. 4.1.2 and scilab>5.
>
> In Scilab 5.1.1, at least under windows xp, the height of the figure 
> given
> by get(gcf(), figure_size)  is equal to the full height of the window, 
> taking
> into account the height  of the scilab toolbar and the height of the 
> window
> manager's window bar.
>
> In Scilab 4.1.2, the height given by figure_size is equal to the 
> height of
> the canvas + the height of the Scilab toolbar.
>
> In Matlab, the height of the window given by get(gcf,'Position') is 
> equal to
> the height of the canvas, which seems to be the most logical option (i.e.
> platform independent).
>
> S.
>


From ycollette at free.fr  Thu Jun  4 23:37:22 2009
From: ycollette at free.fr (Collette Yann)
Date: Thu, 04 Jun 2009 23:37:22 +0200
Subject: problem building the macros
Message-ID: <4A283E92.9040307@free.fr>

Hello,

Since today, I can't build the macros of the latest master. Here is the 
error of the make macros:

./bin/scilab-cli -ns -f 
modules/functions/scripts/buildmacros/buildmacros.sce
  !--error 241
Le fichier "" n'existe pas ou n'est pas accessible en lecture.


YC


From pierre.marechal at scilab.org  Fri Jun  5 08:05:13 2009
From: pierre.marechal at scilab.org (Pierre MARECHAL)
Date: Fri, 05 Jun 2009 08:05:13 +0200
Subject: [Scilab-Dev] problem building the macros
In-Reply-To: <4A283E92.9040307@free.fr>
References: <4A283E92.9040307@free.fr>
Message-ID: <4A28B599.5030809@scilab.org>

Collette Yann a ?crit :
> Hello,
>
> Since today, I can't build the macros of the latest master. Here is 
> the error of the make macros:
>
> ./bin/scilab-cli -ns -f 
> modules/functions/scripts/buildmacros/buildmacros.sce
>  !--error 241
> Le fichier "" n'existe pas ou n'est pas accessible en lecture.
>
>
> YC
Hi Yann,

The following commands should fix the problem :

[$SHELL] cd SCI
[$SHELL] make clean-macros
[$SHELL] make macros

Pierre

-- 
==============================================
Pierre MARECHAL
                   ------
Fondation DIGITEO - Consortium Scilab
Domaine de Voluceau - B.P. 105
78153 Le Chesnay Cedex
B?timent 23 - Bureau 24
                   ------                  
Email : pierre.marechal at scilab.org
T?l : +33 (0)1 39 63 56 81
Fax : +33 (0)1 39 63 55 94
==============================================



From ycollet at freesurf.fr  Fri Jun  5 12:56:54 2009
From: ycollet at freesurf.fr (Collette Yann)
Date: Fri, 05 Jun 2009 12:56:54 +0200
Subject: [Scilab-Dev] problem building the macros
In-Reply-To: <4A28B599.5030809@scilab.org>
References: <4A283E92.9040307@free.fr> <4A28B599.5030809@scilab.org>
Message-ID: <4A28F9F6.3000102@freesurf.fr>

Pierre MARECHAL a ?crit :
> Collette Yann a ?crit :
>> Hello,
>>
>> Since today, I can't build the macros of the latest master. Here is 
>> the error of the make macros:
>>
>> ./bin/scilab-cli -ns -f 
>> modules/functions/scripts/buildmacros/buildmacros.sce
>>  !--error 241
>> Le fichier "" n'existe pas ou n'est pas accessible en lecture.
>>
>>
>> YC
> Hi Yann,
>
> The following commands should fix the problem :
>
> [$SHELL] cd SCI
> [$SHELL] make clean-macros
> [$SHELL] make macros
>
> Pierre
>
No, does not work. I've still got the same error message. Damn Mandriva !!

YC


From ycollet at freesurf.fr  Fri Jun  5 18:26:30 2009
From: ycollet at freesurf.fr (Collette Yann)
Date: Fri, 05 Jun 2009 18:26:30 +0200
Subject: [Scilab-Dev] problem building the macros
In-Reply-To: <4A28B599.5030809@scilab.org>
References: <4A283E92.9040307@free.fr> <4A28B599.5030809@scilab.org>
Message-ID: <4A294736.9010207@freesurf.fr>

Pierre MARECHAL a ?crit :
> Collette Yann a ?crit :
>> Hello,
>>
>> Since today, I can't build the macros of the latest master. Here is 
>> the error of the make macros:
>>
>> ./bin/scilab-cli -ns -f 
>> modules/functions/scripts/buildmacros/buildmacros.sce
>>  !--error 241
>> Le fichier "" n'existe pas ou n'est pas accessible en lecture.
>>
>>
>> YC
> Hi Yann,
>
> The following commands should fix the problem :
>
> [$SHELL] cd SCI
> [$SHELL] make clean-macros
> [$SHELL] make macros
>
> Pierre
>
Finally, I done:

git checkout --
make distclean
configure
make and the problem has gone.

The error I had under mandriva has gone too. Cool.

YC



From vincent.lejeune at institutoptique.fr  Fri Jun  5 23:27:07 2009
From: vincent.lejeune at institutoptique.fr (Vincent Lejeune)
Date: Fri, 5 Jun 2009 23:27:07 +0200
Subject: In intdgesv3.f : there is something I don't understand
Message-ID: <200906052327.07974.vincent.lejeune@institutoptique.fr>

Hi,

I'm trying to reproduce the behaviour of the intdgesv3 function (that is, the 
"backslash" function between 2 double matrix).

After several check of input argument, if the, let's say A matrix in the A\B 
expression, is a square matrix, the function copy the A matrix in another 
matrix AF, call DGETRF that compute the LU decomposition of the AL matrix 
inplace, and then call DGETRS, which resolve the A*X=B system, with the help 
of the previous LU decomposition. The matter is, that DGETRS is called on the 
lB pointer : according to the documentation of the DGETRS function, the lB 
matrix should be modified, that means that the B matrix is not the same after 
the computation.

A quick run into Scilab prooves me that this assertion is wrong, B stay 
unchanged before and after using A\B.

Which step miss I ?

Thanks, Vincent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090605/4af887a1/attachment.htm>

From vincent.lejeune at institutoptique.fr  Sat Jun  6 22:55:04 2009
From: vincent.lejeune at institutoptique.fr (Vincent Lejeune)
Date: Sat, 6 Jun 2009 22:55:04 +0200
Subject: [Scilab-Dev] What is the Fortran function maxvol ?
In-Reply-To: <0b29511bc9593cd63fa9a415e7362bfa@localhost>
References: <200906021627.34636.vincent.lejeune@institutoptique.fr> <0b29511bc9593cd63fa9a415e7362bfa@localhost>
Message-ID: <200906062255.04852.vincent.lejeune@institutoptique.fr>

Thank for your answer, 
infact I don't use lapack routine, but I try to reproduce them partially in C 
:)
I could do it whithout using maxvol, and in fact it seems that you were right 
about the role of the routine (I didn't know until wenesday that FORTRAN has 
not always allowed dynamic allocation...)

By the way, what is the main difference between OS malloc() and SciLab MALLOC ?
I always use classical malloc and I didnt encoutered any issue by now, but 
perhaps I'm missing something...

Vincent

Le mercredi 3 juin 2009 09:14:29, bernard.hugueney at scilab.org a ?crit :
> On Tue, 2 Jun 2009 16:27:34 +0200, Vincent Lejeune
>
> <vincent.lejeune at institutoptique.fr> wrote:
> > Hi,
> >
> > In SciLabs Fortran part of code, there is a "maxvol" function that come
> > several time, for instance in intdgesv3.f, intdgecon.f, sci_f_mucomp.f
>
> ...
>
> > The function is typically called this way :
> > LWORK=maxvol(10,'d')
> >
> > (when the function is acting on complex, 'd' is replaced by 'z')
> > I am no Fortran expert, but I'd like to know what this function does. I
> > dont find its definition in scilab's git repository (I used nepomuk...),
> > and I
> > didnt catch any results on any google search. I suspect this function has
> >
> > to deal with some parallel activities, as it is frequently summoned
> > besides Lapack call...
> >
> > Thanks for the help !
>
> If I am not mistaken, this function returns the max number of elements in
>  a matrix of type double ('d') or complex ('z') that can be allocated on
> the Scilab stack. It is called before Lapack functions that require
> a temporary workspace of unbounded size (the more the better).
>
> The Fortran routine can allocates all the size available on the stack
> because
> no further allocation will be neded before the temporary workspace is
> needed.
>
> When coding in C, you won't use the Scilab stack for temporary workspace
> because
>  you can use malloc fir dynamic memory allocation (well, MALLOC in fact,
> with #include "MALLOC.h").
> However, you cannot malloc all the heap memory available like Fortran could
>
> alloc all the scilab stack memory available ! So you have to choose the
> best size
> and you can know which size is best by calling the Lapack routine with
> a special query mode by passing a worksize of -1 (but still passing
> relevent values
>  for nb of rows/cols for exemple because Lapack will use them to compute
> the optimal size). Lapack routines will then return the computed optimal
> size at
> the begining of the "workspace" (so you cannont pass NULL, but should
> instead
> pass &a_variable_of_type_double ). As small an example is worth a thousand
> words :
>  " with :
> static int dsyevWorkSizes(int iCols, int* optWorkSize, int* minWorkSize) {
>  int info=0, query=-1;
>  double opt;
>  C2F(dsyev)("N", "U", &iCols, NULL, &iCols, NULL, &opt, &query, &info);
>  *optWorkSize= (int)opt;
>  *minWorkSize= Max(1, 3*iCols -1); /* this is documented in Lapack API
> specifications */
>  return info;
>  }
>
>  you could write :
>
> int optWs, minWs;
> if(!dsyevWorkSizes(cols, &optWs, &minWs) {
>  double* workspace= NULL;
>  int wsSize= 0;
>
>  workspace=MALLOC(optWs);
>  if(workspace) { wsSize= optWs; }
>  else {
>    workspace= MALLOC(minWs);
>    if(workspace){ wsSize= minWs; }
>  }
>  if(workspace) {
>  /* now you can call Lapack routine with dynamicaly allocated workspace of
> size wsSize */
>  }
> [...]
>
>
>  HTH. (feel free to ask again if I was not clear).
>
> Regards,
>
> Bernard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20090606/24498578/attachment.htm>

From bernard.hugueney at scilab.org  Mon Jun  8 09:46:27 2009
From: bernard.hugueney at scilab.org (bernard.hugueney at scilab.org)
Date: Mon, 08 Jun 2009 09:46:27 +0200
Subject: [Scilab-Dev] In intdgesv3.f : there is something I don't understand
In-Reply-To: <200906052327.07974.vincent.lejeune@institutoptique.fr>
References: <200906052327.07974.vincent.lejeune@institutoptique.fr>
Message-ID: <1d21c946493a0c450f80578fb03e7173@localhost>

Hi,

On Fri, 5 Jun 2009 23:27:07 +0200, Vincent Lejeune
<vincent.lejeune at institutoptique.fr> wrote:

> of the previous LU decomposition. The matter is, that DGETRS is called on
> the 
> lB pointer : according to the documentation of the DGETRS function, the
lB 
> matrix should be modified, that means that the B matrix is not the same
> after 
> the computation.
> 
> A quick run into Scilab prooves me that this assertion is wrong, B stay 
> unchanged before and after using A\B.
> 
> Which step miss I ?
> 

Sad, but true : getrhsvar() does a *copy* of the argument matrix. So dgetrs
modifies the copy, not the original data.

Regards,

Bernard


From sylvestre.ledru at scilab.org  Mon Jun  8 14:58:45 2009
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Mon, 08 Jun 2009 14:58:45 +0200
Subject: [Scilab-Dev] What is the Fortran function maxvol ?
In-Reply-To: <200906062255.04852.vincent.lejeune@institutoptique.fr>
References: <200906021627.34636.vincent.lejeune@institutoptique.fr>
	 <0b29511bc9593cd63fa9a415e7362bfa@localhost>
	 <200906062255.04852.vincent.lejeune@institutoptique.fr>
Message-ID: <1244465925.26763.788.camel@korcula.inria.fr>

Le samedi 06 juin 2009 ? 22:55 +0200, Vincent Lejeune a ?crit :

> By the way, what is the main difference between OS malloc() and SciLab
> MALLOC ?
Under Linux, it is some checks over the standard malloc function. 
However, it is important for Windows since it is going to use HeapAlloc
which is faster than malloc under Windows.

Sylvestre




From bernard.hugueney at scilab.org  Mon Jun  8 15:15:57 2009
From: bernard.hugueney at scilab.org (bernard.hugueney at scilab.org)
Date: Mon, 08 Jun 2009 15:15:57 +0200
Subject: [Scilab-Dev] What is the Fortran function maxvol
 =?UTF-8?Q?=3F?=
In-Reply-To: <1244465925.26763.788.camel@korcula.inria.fr>
References: <200906021627.34636.vincent.lejeune@institutoptique.fr> <0b29511bc9593cd63fa9a415e7362bfa@localhost> <200906062255.04852.vincent.lejeune@institutoptique.fr> <1244465925.26763.788.camel@korcula.inria.fr>
Message-ID: <3bcd418e98feff64945495b6ec6ae657@localhost>

On Mon, 08 Jun 2009 14:58:45 +0200, Sylvestre Ledru
<sylvestre.ledru at scilab.org> wrote:
> Le samedi 06 juin 2009 ? 22:55 +0200, Vincent Lejeune a ?crit :
> 
>> By the way, what is the main difference between OS malloc() and SciLab
>> MALLOC ?
> Under Linux, it is some checks over the standard malloc function. 
> However, it is important for Windows since it is going to use HeapAlloc
> which is faster than malloc under Windows.
> 
> Sylvestre
> 

Another difference that bit me is that malloc allows a size of 0 [*], while
MALLOC complains.

Regards,

Bernard


[*] as per fine manual: "If size is  0,  then  malloc()  returns  either
NULL, or a unique pointer value that can later be successfully passed to
free()."


From sylvestre.ledru at scilab.org  Tue Jun  9 07:34:54 2009
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Tue, 09 Jun 2009 07:34:54 +0200
Subject: [Scilab-Dev] problem building the macros
In-Reply-To: <4A294736.9010207@freesurf.fr>
References: <4A283E92.9040307@free.fr> <4A28B599.5030809@scilab.org>
	 <4A294736.9010207@freesurf.fr>
Message-ID: <1244525694.10285.31.camel@zlarin>

Le vendredi 05 juin 2009 ? 18:26 +0200, Collette Yann a ?crit :
> Pierre MARECHAL a ?crit :
> > Collette Yann a ?crit :
> >> Hello,
> >>
> >> Since today, I can't build the macros of the latest master. Here is 
> >> the error of the make macros:
> >>
> >> ./bin/scilab-cli -ns -f 
> >> modules/functions/scripts/buildmacros/buildmacros.sce
> >>  !--error 241
> >> Le fichier "" n'existe pas ou n'est pas accessible en lecture.
> > Pierre
> >
> Finally, I done:
> 
> git checkout --
> make distclean
> configure
> make and the problem has gone.
(cd modules/core/; make clean all) && make macros
fixed the problem for me.

Sylvestre




From sylvestre.ledru at scilab.org  Tue Jun  9 09:20:43 2009
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Tue, 09 Jun 2009 09:20:43 +0200
Subject: malloc.c
Message-ID: <1244532043.7669.22.camel@zlarin>

Hello,

This file has been the object of many discussions on the IRC channel and
in the Scilab team.
I finally made a change which, I hope, will simplify the life of the
packager of Scilab.

I just pushed a commit which disable the build of
libs/MALLOC/src/malloc.c (it used to be built for 64 
bits archs). 
Note that if Scilab is built on a 64 bits and triggers a seg fault on
startup, uncomment the related line in libs/MALLOC/Makefile.am and
launch autoreconf.

Commit 2f763680a73ce3fe3d6e57bd27a97223078379df in the master branch
(Scilab 5.2)

Sylvestre




From danaf at drfconsulting.com  Sat Jun 13 17:57:21 2009
From: danaf at drfconsulting.com (danaf at drfconsulting.com)
Date: Sat, 13 Jun 2009 10:57:21 -0500
Subject: make errors
Message-ID: <NGEBJEKALJIHDNKBNCOBMEOFEHAA.danaf@drfconsulting.com>

I am trying to make scilab-branches-5.1-1244468876 on
Centos 5. After installing all the dependencies I ran
make and received the following errors:

make[3]: Leaving directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/output_stream'
make[2]: Leaving directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/output_stream'
Making install in action_binding
make[2]: Entering directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/action_binding'
make  install-am
make[3]: Entering directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/action_binding'
/bin/sh: line 3: /usr/local/scilab/scilab-branches-5.1-1244468876/java/ant:
is a directory
make[3]: *** [java] Error 126
make[3]: Leaving directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/action_binding'
make[2]: *** [install] Error 2
make[2]: Leaving directory
`/usr/local/scilab/scilab-branches-5.1-1244468876/modules/action_binding'
make[1]: *** [install-recursive] Error 1

Can someone help with this problem?

Thanks,
Dana



From calixte.denizet at ac-rennes.fr  Tue Jun 16 14:22:07 2009
From: calixte.denizet at ac-rennes.fr (Calixte Denizet)
Date: Tue, 16 Jun 2009 14:22:07 +0200
Subject: New toolbox to overload user-defined functions
Message-ID: <1245154927.2278.10.camel@debian>

Hi,

You can get this toolbox at the address

http://www.scilab.org/contrib/index_contrib.php?page=displayContribution&fileID=1221

I developped it under Linux for Scilab 5.1 and it was not tested under
an other system. Normally, the code (C and fortran) is portable and no
problems should occure.

I'm waiting for the opinions of Scilab's users.

Calixte Denizet





From nicolas.fezans at gmail.com  Wed Jun 24 10:30:00 2009
From: nicolas.fezans at gmail.com (Nicolas FEZANS)
Date: Wed, 24 Jun 2009 10:30:00 +0200
Subject: Pseudo code
Message-ID: <e63fb8d30906240130p77dfce2dm3f8daa8fd43d6b18@mail.gmail.com>

Dear dev people,

I was wondering (concerning a possible toolbox development) whether
there exists any possibility for making pseudo-code (more or less like
the .p file of Matlab) with Scilab (my guess is no). If no, is it part
of any planning or even development wish?

I know that pseudo-code is not really in the spirit of open-source
community, but not having this kind of possibility will clearly
prevent a lot of developments from being made on Scilab and that could
lead to some high quality freely accessible (but not open-source)
toolboxes that could then been converted later into open-source
project. Some of the best open-source programs were indeed non
open-source project before (e.g. Firefox, OpenOffice,... ;-) ).
Long-term interest for open-source project is not necessarily to
prevent such contributions by adopting too restrictive rules. Indeed
one cannot prevent contributions from being made accessible in any
compiled form, the only difference is that cross-platform
compatibilities will probably be quite bad.

Of course there is also the technical aspect on how to implement such
a possibility within an open-source project. If a piece of code in
open-source makes the conversion between the pseudo-code and normal
Scilab code or if the encrypted code is stored in memory without any
protection, pseudo-codes won't really be protected (what can be read,
can be copied!).


Regards,

Nicolas


From florent.lebeau at scilab.org  Wed Jun 24 11:27:42 2009
From: florent.lebeau at scilab.org (Florent LEBEAU)
Date: Wed, 24 Jun 2009 11:27:42 +0200
Subject: [Scilab-Dev] Pseudo code
In-Reply-To: <e63fb8d30906240130p77dfce2dm3f8daa8fd43d6b18@mail.gmail.com>
References: <e63fb8d30906240130p77dfce2dm3f8daa8fd43d6b18@mail.gmail.com>
Message-ID: <4A41F18E.5040509@scilab.org>

Dear Nicolas,
Indeed, such a possibility does not exist in Scilab currently. However, 
because of the reasons you mentioned, there is a wish to implement such 
a tool. This would help Scilab achieve further development. The team is 
working on this subject. We might be heading towards a solution using 
cryptographic means.
If you have any suggestions or requests, feel free to contact me.
Best regards,

Florent Lebeau



Nicolas FEZANS a ?crit :
> Dear dev people,
>
> I was wondering (concerning a possible toolbox development) whether
> there exists any possibility for making pseudo-code (more or less like
> the .p file of Matlab) with Scilab (my guess is no). If no, is it part
> of any planning or even development wish?
>
> I know that pseudo-code is not really in the spirit of open-source
> community, but not having this kind of possibility will clearly
> prevent a lot of developments from being made on Scilab and that could
> lead to some high quality freely accessible (but not open-source)
> toolboxes that could then been converted later into open-source
> project. Some of the best open-source programs were indeed non
> open-source project before (e.g. Firefox, OpenOffice,... ;-) ).
> Long-term interest for open-source project is not necessarily to
> prevent such contributions by adopting too restrictive rules. Indeed
> one cannot prevent contributions from being made accessible in any
> compiled form, the only difference is that cross-platform
> compatibilities will probably be quite bad.
>
> Of course there is also the technical aspect on how to implement such
> a possibility within an open-source project. If a piece of code in
> open-source makes the conversion between the pseudo-code and normal
> Scilab code or if the encrypted code is stored in memory without any
> protection, pseudo-codes won't really be protected (what can be read,
> can be copied!).
>
>
> Regards,
>
> Nicolas
>   



From sylvestre.ledru at scilab.org  Thu Jun 25 14:44:48 2009
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Thu, 25 Jun 2009 14:44:48 +0200
Subject: Update of launchpad to simplify the localization
Message-ID: <1245933888.4681.35376.camel@korcula.inria.fr>

Hello,

Following a request I made a few months ago [1], the Launchpad
developers just released a new great feature in the translation area:
https://translations.launchpad.net/scilab/

It is now much easier to detect which languages are full translated,
which need some more works...
It is possible also for each language to detect which module is OK:
For example, here is the status of the 
Brazilian Portuguese localization:
https://translations.launchpad.net/scilab/trunk/+lang/pt_BR

When you think that your translation is better and should be included
into Scilab, just drop a mail on the dev mailing list or to me.

Don't hesitate if you have any questions,
Sylvestre
[1] https://bugs.launchpad.net/rosetta/+bug/273096




From z-saito at guitar.ocn.ne.jp  Thu Jun 25 15:52:53 2009
From: z-saito at guitar.ocn.ne.jp (Hiroshi Saito)
Date: Thu, 25 Jun 2009 22:52:53 +0900
Subject: Update of launchpad to simplify the localization
References: <1245933888.4681.35376.camel@korcula.inria.fr>
Message-ID: <D7DF57124AA94FEEB640B4CD4523D7BB@HIRO57887DE653>

Hi Sylvestr-san, and all.

Great!

Thank you for helpful information. I wish contributing in Japanese. Then, the work has 
sufficient quantity to be used although it has not completed yet. Therefore, I registered 
to the place, and this URL of work will be shown the japanese status.!

Ooops, one question.

==Register a branch on Scilab==  I entered as follows
Branch URL: https://translations.launchpad.net/scilab/trunk/+lang/ja_JP
== Error Message. 
=>For Launchpad to mirror a branch, the original branch cannot be on Launchpad.net

Have I missed something? 
Thanks!

Regards,
Hiroshi Saito

----- Original Message ----- 
From: "Sylvestre Ledru" <sylvestre.ledru at scilab.org>

> Hello,
> 
> Following a request I made a few months ago [1], the Launchpad
> developers just released a new great feature in the translation area:
> https://translations.launchpad.net/scilab/
> 
> It is now much easier to detect which languages are full translated,
> which need some more works...
> It is possible also for each language to detect which module is OK:
> For example, here is the status of the 
> Brazilian Portuguese localization:
> https://translations.launchpad.net/scilab/trunk/+lang/pt_BR
> 
> When you think that your translation is better and should be included
> into Scilab, just drop a mail on the dev mailing list or to me.
> 
> Don't hesitate if you have any questions,
> Sylvestre
> [1] https://bugs.launchpad.net/rosetta/+bug/273096
> 
> 
>



From sylvestre.ledru at scilab.org  Thu Jun 25 16:22:13 2009
From: sylvestre.ledru at scilab.org (Sylvestre Ledru)
Date: Thu, 25 Jun 2009 16:22:13 +0200
Subject: [Scilab-Dev] Re: Update of launchpad to simplify the
 localization
In-Reply-To: <D7DF57124AA94FEEB640B4CD4523D7BB@HIRO57887DE653>
References: <1245933888.4681.35376.camel@korcula.inria.fr>
	 <D7DF57124AA94FEEB640B4CD4523D7BB@HIRO57887DE653>
Message-ID: <1245939733.4681.35798.camel@korcula.inria.fr>

Bonjour,

This interface is a bit tricky at first.
In the preferences of your launchpad account, you must select Japanese
as one of your preferred languages and it is going to activate it as
potential Scilab translation.
I just did it for you in order to "open" the Japanese translation of
Scilab.

Sylvestre


Le jeudi 25 juin 2009 ? 22:52 +0900, Hiroshi Saito a ?crit :
> Hi Sylvestr-san, and all.
> 
> Great!
> 
> Thank you for helpful information. I wish contributing in Japanese. Then, the work has 
> sufficient quantity to be used although it has not completed yet. Therefore, I registered 
> to the place, and this URL of work will be shown the japanese status.!
> 
> Ooops, one question.
> 
> ==Register a branch on Scilab==  I entered as follows
> Branch URL: https://translations.launchpad.net/scilab/trunk/+lang/ja_JP
> == Error Message. 
> =>For Launchpad to mirror a branch, the original branch cannot be on Launchpad.net
> 
> Have I missed something? 
> Thanks!
> 
> Regards,
> Hiroshi Saito
> 
> ----- Original Message ----- 
> From: "Sylvestre Ledru" <sylvestre.ledru at scilab.org>
> 
> > Hello,
> > 
> > Following a request I made a few months ago [1], the Launchpad
> > developers just released a new great feature in the translation area:
> > https://translations.launchpad.net/scilab/
> > 
> > It is now much easier to detect which languages are full translated,
> > which need some more works...
> > It is possible also for each language to detect which module is OK:
> > For example, here is the status of the 
> > Brazilian Portuguese localization:
> > https://translations.launchpad.net/scilab/trunk/+lang/pt_BR
> > 
> > When you think that your translation is better and should be included
> > into Scilab, just drop a mail on the dev mailing list or to me.
> > 
> > Don't hesitate if you have any questions,
> > Sylvestre
> > [1] https://bugs.launchpad.net/rosetta/+bug/273096
> > 
> > 
> >
> 



From z-saito at guitar.ocn.ne.jp  Thu Jun 25 16:59:43 2009
From: z-saito at guitar.ocn.ne.jp (Hiroshi Saito)
Date: Thu, 25 Jun 2009 23:59:43 +0900
Subject: [Scilab-Dev] Re: Update of launchpad to simplify the localization
References: <1245933888.4681.35376.camel@korcula.inria.fr> <D7DF57124AA94FEEB640B4CD4523D7BB@HIRO57887DE653> <1245939733.4681.35798.camel@korcula.inria.fr>
Message-ID: <15089BEDF3E14323A39FF01E421BB2F7@HIRO57887DE653>

Hi Sylvestre-san.

----- Original Message ----- 
From: "Sylvestre Ledru" <sylvestre.ledru at scilab.org>


> Bonjour,

Bonjour!:-)

>
> This interface is a bit tricky at first.

Um,  I fought with the page now.

> In the preferences of your launchpad account, you must select Japanese
> as one of your preferred languages and it is going to activate it as
> potential Scilab translation.
> I just did it for you in order to "open" the Japanese translation of
> Scilab.

Yeah, thanks!
It seems that I found the place which works. I saw the results of status with red all. :-)
Thank you very much.  anyway, I will commit there little by little.

P.S)
today work finished so far in the reason now of midnight in Japan.

With kindest regards,
Hiroshi Saito

>
> Sylvestre
>
>
> Le jeudi 25 juin 2009 ? 22:52 +0900, Hiroshi Saito a ?crit :
>> Hi Sylvestr-san, and all.
>>
>> Great!
>>
>> Thank you for helpful information. I wish contributing in Japanese. Then, the work has
>> sufficient quantity to be used although it has not completed yet. Therefore, I registered
>> to the place, and this URL of work will be shown the japanese status.!
>>
>> Ooops, one question.
>>
>> ==Register a branch on Scilab==  I entered as follows
>> Branch URL: https://translations.launchpad.net/scilab/trunk/+lang/ja_JP
>> == Error Message.
>> =>For Launchpad to mirror a branch, the original branch cannot be on Launchpad.net
>>
>> Have I missed something?
>> Thanks!
>>
>> Regards,
>> Hiroshi Saito
>>
>> ----- Original Message ----- 
>> From: "Sylvestre Ledru" <sylvestre.ledru at scilab.org>
>>
>> > Hello,
>> >
>> > Following a request I made a few months ago [1], the Launchpad
>> > developers just released a new great feature in the translation area:
>> > https://translations.launchpad.net/scilab/
>> >
>> > It is now much easier to detect which languages are full translated,
>> > which need some more works...
>> > It is possible also for each language to detect which module is OK:
>> > For example, here is the status of the
>> > Brazilian Portuguese localization:
>> > https://translations.launchpad.net/scilab/trunk/+lang/pt_BR
>> >
>> > When you think that your translation is better and should be included
>> > into Scilab, just drop a mail on the dev mailing list or to me.
>> >
>> > Don't hesitate if you have any questions,
>> > Sylvestre
>> > [1] https://bugs.launchpad.net/rosetta/+bug/273096
>> >
>> >
>> >
>>
>
>