[Scilab-users] Get some error

[gnu]

 hello！

When i run the Modelica demos (Demos->Xcos->Electrical systems),there is an
error:

c_pass1: build the modelica meta-block failed

 xcos_simulate: Error during block parameters update.

Could you please tell me how to solve this problem?



--
View this message in context: 
http://mailinglists.scilab.org/Get-some-error-tp4036157.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Xcos Coselica blocks - Error while running - C compiller

[gnu]

Dear Paul ,

What should I do if I can't run the Modelica demos (Demos->Xcos->Electrical
systems)?

Thanks gnu



--
View this message in context: 
http://mailinglists.scilab.org/Xcos-Coselica-blocks-Error-while-running-C-compiller-tp4033072p4036158.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Xcos Coselica blocks - Error while running - C compiller

[paul . bignier]

Hello Gnu,

To run Xcos demos containing Modelica (/Coselica) blocks, you need a C 
compiler, as your message title suggests.
Please refer to the compilers page 
(https://help.scilab.org/docs/6.0.0/en_US/supported_compilers.html) for 
that.


Alternatively, you may try with Scilab 5.5.2 and even report a bug 
(http://bugzilla.scilab.org) should you encounter unexpected behavior.


Hope this helps, regards,
Paul

On 2017-04-09 13:39, gnu wrote:

Dear Paul ,

What should I do if I can't run the Modelica demos 
(Demos->Xcos->Electrical

systems)?

Thanks gnu



--
View this message in context:
http://mailinglists.scilab.org/Xcos-Coselica-blocks-Error-while-running-C-compiller-tp4033072p4036158.html
Sent from the Scilab users - Mailing Lists Archives mailing list
archive at Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Get some error

[Clément David]

Hello Kandy,

Are you using the Scilab 6.0.0 version or another one ? Could give more 
information about your
system : which OS ? hardware ?

Thanks,

PS: I suggest you to open a bug on bugzilla.scilab.org to ease communication on 
that issue. Users ML
 is more usage oriented.

--
Clément

Le dimanche 09 avril 2017 à 04:26 -0700, gnu a écrit :
>  hello！
> 
> When i run the Modelica demos (Demos->Xcos->Electrical systems),there is an
> error:
> 
> c_pass1: build the modelica meta-block failed
> 
>  xcos_simulate: Error during block parameters update.
> 
> Could you please tell me how to solve this problem?
> 
> 
> 
> --
> View this message in context: 
> http://mailinglists.scilab.org/Get-some-error-tp4036157.html
> Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
> Nabble.com.
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Get some error

[gnu]

Dear Clément ,

I'm using scilab 6.0.0,my operating system is win10.

I have try version 5.5.2 before ,I got the same problem.

Thanks

Kandy



--
View this message in context: 
http://mailinglists.scilab.org/Get-some-error-tp4036157p4036168.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Get some error

[Nikolay Strelkov]

Dear gnu!

What compiler do you use?

It is known that MinGW GCC works normally. You can install MinGW compiler
from Scilab ATOMS  (see its
Description).


--

*With best regards,Ph.D., *


*associate professor at MPEI
,IEEE member,maintainer of
Mathieu functions toolbox for Scilab
,Nikolay Strelkov.*

2017-04-10 13:04 GMT+03:00 gnu :

> Dear Clément ,
>
> I'm using scilab 6.0.0,my operating system is win10.
>
> I have try version 5.5.2 before ,I got the same problem.
>
> Thanks
>
> Kandy
>
>
>
> --
> View this message in context: http://mailinglists.scilab.
> org/Get-some-error-tp4036157p4036168.html
> Sent from the Scilab users - Mailing Lists Archives mailing list archive
> at Nabble.com.
> ___
> users mailing list
> users@lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users
>
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Scicos-OpenModelica

[Ilaria La Rocca]

  Hi, 

I have a modelica model of a simple RL circuit. This is the
code: 

model circuitoscicos 
 Modelica.Electrical.Analog.Basic.Ground
ground1 annotation( 
 Placement(visible = true, transformation(origin =
{-28, -38}, extent = {{-10, -10}, {10, 10}}, rotation = 0))); 

Modelica.Electrical.Analog.Basic.Inductor inductor1(L = 0.1) annotation(

 Placement(visible = true, transformation(origin = {8, 32}, extent =
{{-10, -10}, {10, 10}}, rotation = 0))); 

Modelica.Electrical.Analog.Basic.Resistor resistor1(R = 1) annotation( 

Placement(visible = true, transformation(origin = {-30, 32}, extent =
{{-10, -10}, {10, 10}}, rotation = 0))); 

Modelica.Electrical.Analog.Sources.ConstantVoltage constantVoltage1(V =
220) annotation( 
 Placement(visible = true, transformation(origin =
{-58, 2}, extent = {{-10, -10}, {10, 10}}, rotation = -90))); 
equation

 connect(ground1.p, constantVoltage1.n) annotation( 
 Line(points =
{{-28, -28}, {-58, -28}, {-58, -8}, {-58, -8}}, color = {0, 0, 255})); 

connect(inductor1.n, ground1.p) annotation( 
 Line(points = {{18, 32},
{20, 32}, {20, -28}, {-28, -28}, {-28, -28}}, color = {0, 0, 255})); 

connect(resistor1.n, inductor1.p) annotation( 
 Line(points = {{-20,
32}, {-2, 32}, {-2, 32}, {-2, 32}}, color = {0, 0, 255})); 

connect(constantVoltage1.p, resistor1.p) annotation( 
 Line(points =
{{-58, 12}, {-58, 32}, {-40, 32}}, color = {0, 0, 255})); 
 annotation(

 uses(Modelica(version = "3.2.2"))); 
end circuitoscicos; 

I would
like to know if it's possible to use this kind of code in Scicos using
Modelica generic block. 

Thanks in advance.  


Con Open 4 Giga a 9 euro/4 sett navighi veloce, chiami e invii SMS dal tuo 
smartphone verso tutti i fissi e mobili in Italia. Passa a Tiscali Mobile! 
http://casa.tiscali.it/mobile/

___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab release frequency ?

[Samuel Gougeon]

Hello,

I am redirecting this discussion on users@ because it shall mainly 
interest most of users,  while, after 2 weeks, palpably not developers:


http://mailinglists.scilab.org/Scilab-release-frequency-tt4035908.html

On 21/03/2017 à 15:18, Clément David wrote on dev@:

After some private discussion by direct mail, Samuel pointed that I have to 
open the discussion to ask for your needs / advises for the release frequency ; 
thanks Samuel for that. Please find also attached a Scilab version timeline for 
reference.

To clarify the discussion, I will use the convention major.minor.revision 
(6.0.0 == 6 major, 0 minor, 0 revision) where :
  * a revision only contains bug fixes and should be script compatible but 
might deprecate functions
  * a minor version remove deprecated functions
  * a major version is a Scilab partial rewrite

IMHO an expected (with no strict application) period should be :
  * 6-9 months “revision” cycle
  * 18-24 months “minor” cycle (2 to 3 revisions)
  * much more for a “major”

Do you have an opinion on the Scilab release period ? Which period will 
simplify your developments ?


In private, Clément's rationale is, mainly and AFAIU, that preparing the 
publication of each release takes some time: There is a list of things 
to do, like formating the release notes, publishing new online help 
pages, updating download pages in several languages, etc. Then, this 
time is not used for developments.


I was asking about the intentions of the Scilab team about the future 
release frequency, because i thought -- and still think -- that roughtly 
2 years between 2 consecutive minor releases is incredibly long at the 
usual Information Technologies timescale.
Keeping such a slow rate would mean that we would have to wait up to 2 
years between the inclusion of a new feature in Scilab, and its 
distribution in an official Scilab release! So to wait even longer 
between the implementation of any new feature, and its actual 
availability in Scilab. Even for the "smallest" features, as soon as 
they are new.


Obviously, we can't ignore that each publication needs or deserves some 
specific tasks that take time, and that this time should be minimized.
Moreover, we may note that contrarily to many free and open softwares, 
nighly built releases are available online for Scilab, mostly at every 
moment. From time to time, there are some short dead periods in these 
daily releases in which the most recently included features are 
available. These binary releases can be installed and used out of the 
box like every "official" release, without uninstalling the current 
"official" release from our computer. Actually, installing a new Scilab 
version never requires uninstalling other (even multiple) versions of 
Scilab on the same computer. Everyone can have as many Scilab versions 
installed on the same computer as wished, whitout any problem. It takes 
less than 5 mn to install a new Scilab. And add some additional 5-15 mn 
to reset our Preferences, install few ATOMS modules for it, etc.

This is very great and useful and safe.

So, after our last email, i came to the following conclusion: In my 
opinion, publishing revision 6.n.X releases is useless. For the future, 
we could expect


 * The publication only of official minor versions: 6.X
   This should allow publishing them at a faster rate, at least once
   per year, never less.

 * Keeping Nightly built (daily) releases for the current 6.X+ branch,
   in which bugs are fixed "on-the-fly", the documentation is improved,
   and all other safe daily modifications are included and available on
   download the day after.

 * Keeping Nightly built (daily) releases of the master preparing the
   6.(X+1) release, in which new features or modifications that could
   make Scilab unstable are progressively included.

Hence, the publication process would take less time ; new features would 
become available in the year instead of in a 2-year period ; and 
Scilab's safety will be unchanged.


Hope reading other contributions and thoughts,

Best regards
Samuel


___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

[Scilab-users] Cell insertion operation using {...} is buggy?!

[Dirk Reusch]

Hello,

Using precompiled Scilab 6.0.0 Linux 64bit, I experienced the
following:



Startup execution:
  loading initial environment
  

--> b{1}=2 // Ok
 b  = 

  [1x1 constant]


--> a=2 // Ok
 a  = 

   2.


--> a{1}=2 // Not OK, should throw an error? 
 a  = 

   1.16D-316

--

It seems, that the cell insertion operation via "{...}" when applied
on an existing variable does strange things.

Thanks for any advice and further insight,

Dirk

PS: Tested also with nightly build  branch-6.0-1488991653 ... with the
very same result!
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Get some error

[gnu]

Dear nikolay,
 
I try another compile and it runs very well now.

thanks!



--
View this message in context: 
http://mailinglists.scilab.org/Get-some-error-tp4036157p4036174.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] Xcos Coselica blocks - Error while running - C compiller

[gnu]

Dear paul,

It runs very well now , thank you very much!

gnu



--
View this message in context: 
http://mailinglists.scilab.org/Xcos-Coselica-blocks-Error-while-running-C-compiller-tp4033072p4036175.html
Sent from the Scilab users - Mailing Lists Archives mailing list archive at 
Nabble.com.
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab release frequency ?

[Dirk Reusch]

Hello,

regarding future release cycles, I would really appreciate to see
offical releases as needed and based primarily upon stability criteria.

IMHO, for production use, especially after the big step from 5.x to 6.x,
it is inevitable to have official 6.0.x bug fix releases asap, otherwise
developers and users will stick to 5.5.x and get frustrated ...

Nightly builds are fine, as a testing and development platform, but not
really suited for end users ...

Regarding the incorporation of new features, it is IMHO not that
important to know, how many releases will be made per year.
It is important to know, when will a new feature be available and
useable.

In summary, I would like to see official releases as needed, rather than
following a rigid schedule.

Best regards,

Dirk

PS: Why are Coverity Fixes not directly applied to the 6.0 branch?
___
users mailing list
users@lists.scilab.org
http://lists.scilab.org/mailman/listinfo/users

Re: [Scilab-users] [Scilab-Dev] Scilab release frequency ?

[Claus Futtrup]

Hi,

My thoughts on releases. I agree that releases have been incredibly 
slow, but haven't spent time bickering about it. Instead, I'm pleased 
when releases are finally here. I've wondered about the organization(s) 
behind Scilab. It seems we get a new release every time Scilab is 
reorganized in some way ... and that there's lots of political stuff 
going on.


I hope that the Scilab 6 milestone means that Scilab (as in the software 
itself) is organized in a way suitable for the next many years. Hereby I 
imply that any 6.X release only has to reflect incremental (and 
preferably backwards compatible) improvements.


Personally I consider "nightly builds" to be bleeding edge, for 
developers, and not something I can use for my development - just as I 
cannot distribute Scilab code and reference a nightly-build version of 
Scilab to whoever might be interested.


>each publication needs or deserves some specific tasks that take time

Yes, typically minimized by writing a developer-oriented "how-to" 
release (aka to-do list).


IMHO regarding release frequency, the second-most important reason to 
release is so that the project appears alive and not dead.


Best regards,
Claus

On 10-04-2017 13:58, Samuel Gougeon wrote:

Hello,

I am redirecting this discussion on users@ because it shall mainly 
interest most of users,  while, after 2 weeks, palpably not developers:


http://mailinglists.scilab.org/Scilab-release-frequency-tt4035908.html

On 21/03/2017 à 15:18, Clément David wrote on dev@:

After some private discussion by direct mail, Samuel pointed that I have to 
open the discussion to ask for your needs / advises for the release frequency ; 
thanks Samuel for that. Please find also attached a Scilab version timeline for 
reference.

To clarify the discussion, I will use the convention major.minor.revision 
(6.0.0 == 6 major, 0 minor, 0 revision) where :
  * a revision only contains bug fixes and should be script compatible but 
might deprecate functions
  * a minor version remove deprecated functions
  * a major version is a Scilab partial rewrite

IMHO an expected (with no strict application) period should be :
  * 6-9 months “revision” cycle
  * 18-24 months “minor” cycle (2 to 3 revisions)
  * much more for a “major”

Do you have an opinion on the Scilab release period ? Which period will 
simplify your developments ?


In private, Clément's rationale is, mainly and AFAIU, that preparing 
the publication of each release takes some time: There is a list of 
things to do, like formating the release notes, publishing new online 
help pages, updating download pages in several languages, etc. Then, 
this time is not used for developments.


I was asking about the intentions of the Scilab team about the future 
release frequency, because i thought -- and still think -- that 
roughtly 2 years between 2 consecutive minor releases is incredibly 
long at the usual Information Technologies timescale.
Keeping such a slow rate would mean that we would have to wait up to 2 
years between the inclusion of a new feature in Scilab, and its 
distribution in an official Scilab release! So to wait even longer 
between the implementation of any new feature, and its actual 
availability in Scilab. Even for the "smallest" features, as soon as 
they are new.


Obviously, we can't ignore that each publication needs or deserves 
some specific tasks that take time, and that this time should be 
minimized.
Moreover, we may note that contrarily to many free and open softwares, 
nighly built releases are available online for Scilab, mostly at every 
moment. From time to time, there are some short dead periods in these 
daily releases in which the most recently included features are 
available. These binary releases can be installed and used out of the 
box like every "official" release, without uninstalling the current 
"official" release from our computer. Actually, installing a new 
Scilab version never requires uninstalling other (even multiple) 
versions of Scilab on the same computer. Everyone can have as many 
Scilab versions installed on the same computer as wished, whitout any 
problem. It takes less than 5 mn to install a new Scilab. And add some 
additional 5-15 mn to reset our Preferences, install few ATOMS modules 
for it, etc.

This is very great and useful and safe.

So, after our last email, i came to the following conclusion: In my 
opinion, publishing revision 6.n.X releases is useless. For the 
future, we could expect


  * The publication only of official minor versions: 6.X
This should allow publishing them at a faster rate, at least once
per year, never less.

  * Keeping Nightly built (daily) releases for the current 6.X+
branch, in which bugs are fixed "on-the-fly", the documentation is
improved, and all other safe daily modifications are included and
available on download the day after.

  * Keeping Nightly built (daily) releases of the master preparing the
6.(X+1) release, in w