open discussion about first nsp version

154 views
Skip to first unread message

bruno

unread,
Mar 6, 2012, 9:22:37 AM3/6/12
to tu...@googlegroups.com

Hi All,

We would like to open a discussion on the following topic: We have in mind that releasing a first version of nsp would be important and we would therefore like to have feedbacks from users to determine if they consider that there are blocking or important missing features in the current cvs version. You can post your comments here or on the following wiki: http://code.google.com/p/tumbi/wiki/LackingFeaturesForFirstNspVersion

where there is a first wish list to comment or complete.

Best regards
Bruno and Jean-Philippe

Simone Mannori

unread,
Mar 6, 2012, 10:03:02 AM3/6/12
to tu...@googlegroups.com, Paolo Gai, Roberto Bucher
Bonjour Bruno, Bonjour Jean-Philippe,

my two cents, in priority order:

0./ prepare a really impressive demo of NSP graphics capability; NSP
has native _very_fast_ OpenGL 3D support: you should maximize this
advantage in order to gain new users and developpers;

1./ release a well tested binary version for Windows. Unfortunately,
for one Linux download you will have ten Windows download.

2./ relase the usual binary builds for Ubuntu (deb) and Fedora (rpm)

3./ make sure that the nsp help pages works

4./ a Mac OSX build could be useful

5./ (optional) provide a precompiled Scicos build

In the following days I will update my cvs version, I will play with a
bit and - eventually - I will give you some feedback but don't expect
miracles: I'm a Scicos/Simulink power user, my experience with
scilab/nsp/matlab is quite limited.

Thank you for developping Tumbi :-)

Simone

//** --------------------------------------------------------------------------------------------------

> --
> You received this message because you are subscribed to the Google Groups
> "tumbi" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/tumbi/-/ZZEQhR5uhAsJ.
> To post to this group, send email to tu...@googlegroups.com.
> To unsubscribe from this group, send email to
> tumbi+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/tumbi?hl=en.

Simone Mannori

unread,
Mar 7, 2012, 2:39:41 AM3/7/12
to tu...@googlegroups.com
Bonjour,

after yesterday's fix NSP (CVS) runs ok (including help pages).

One newbie question: "There is function to know how much free memory I have?"

Two suggestions / observations :

1./ in a world where most of the people have 4Gbyte RAM, a native 64
bit version could be very useful;

2./ the GTK tutorial on the web site is nice, but it is not enough to
show NSP (graphics) potential. Is it possible have a list of all the
graphics primitives implemented in NSP?

I have found the MacOSX build at the bottom of the list on the web
site, so I see that you are already sensitive to the needs of this
community.

Finally, I'm a bit concerned about the Windows version. Could you
provide a beta that I can test? The cross compilation chain is
difficult to install ?

Thanks

Simone

bruno

unread,
Mar 7, 2012, 5:51:13 AM3/7/12
to tu...@googlegroups.com
 

One newbie question: "There is function to know how much free memory I have?"

      There is no "stacksize" in nsp so you have as many memory as your OS  
    could provide to the nsp application without playing with the famous stacksize
    function of scilab (well it should have disappeared in v 6). But may I don't
   understand the point.
   

Two suggestions / observations :

1./ in a world where most of the people have 4Gbyte RAM, a native 64
bit version could be very useful;

      There are already 64-bits packaged version for Ubuntu, Debian and Fedora.
   
 

2./ the GTK tutorial on the web site is nice, but it is not enough to
show NSP (graphics) potential. Is it possible have a list of all the
graphics primitives implemented in NSP?

      This is a point already in our TODO list ;-)  There are most of the scilab
    graphics old primitives (plot2d, ...) but we think to provide more ergonomic
    interfaces (like plot and it is possible to do better than plot, we have a draft
    with some ideas somewhere). But to code easily these ergonomic plotting
    functions we need to finish the new graphic object underlying system. 
    
  Bruno

Simone Mannori

unread,
Mar 8, 2012, 12:19:28 AM3/8/12
to tu...@googlegroups.com
>> 1./ in a world where most of the people have 4Gbyte RAM, a native 64
>> bit version could be very useful;
>
>       There are already 64-bits packaged version for Ubuntu, Debian and
> Fedora.

Question: But they support objects bigger than 4Gbytes ?

Question: compiling NSP on 64 bit Linux, the 64 bit support is
automatically activated?

Thanks

Simone

Jean-Philippe Chancelier

unread,
Mar 8, 2012, 1:43:13 AM3/8/12
to tu...@googlegroups.com, simone....@gmail.com

Simone> Question: But they support objects bigger than 4Gbytes ?
Simone> Question: compiling NSP on 64 bit Linux, the 64 bit support is
Simone> automatically activated?

Hi Simone,
Objects with indices are accessed with int32 indices and thus
you are limited because of that point even if object bigger that
4Gb can be allocated.
jpc


Simone Mannori

unread,
Mar 8, 2012, 2:01:00 AM3/8/12
to tu...@googlegroups.com

Switch to 64 point is too difficult or it is a choice (motivated by reasons) ?

Thanks :-)

Simone

Jean-Philippe Chancelier

unread,
Mar 8, 2012, 2:48:22 AM3/8/12
to tu...@googlegroups.com, simone....@gmail.com

Simone> Switch to 64 point is too difficult or it is a choice (motivated by
Simone> reasons) ?
Simone> Thanks :-)

We haven't investigated that much on the subject and I agree that
it's important. Keep in mind that all nsp versions have to be
compatible through save/load thus activating something just for 64 bits
architecture is maybe not a good idea, many libraries assume that
indices are integers etc...
Thus, we have to spend a bit of time on this topic before taking decisions.
Regards,
jpc

Reply all
Reply to author
Forward
0 new messages