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

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

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

On 6 March 2012 15:22, bruno <bruno.pin...@iecn.u-nancy.fr> wrote:

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

    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.

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

      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

Question: But they support objects bigger than 4Gbytes ?

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

Thanks

   Simone

    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

On 8 March 2012 07:43, Jean-Philippe Chancelier <j...@cermics.enpc.fr> wrote:

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

Thanks :-)

   Simone

    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