Label: ♦english
♦bug report
|
[188] On DaoStudio 0.2 several examples doesn't work |
Comment |
mingodad
created at Thursday, 2010-03-18, 21:24:14
mingodad
modified at Thursday, 2010-03-18, 23:04:31
6 Replies, 715 Hits
I've downloaded daostudio 0.2 for windows tgz and it looks very nice but the examples that come with it most of then doesn't work, also it isn't linked with thread library.
Source URL:
http://www.daovm.net/space/dao/thread/188
Comments
fu commented at Thursday, 2010-03-18, 21:37:13
which platform?
mingodad commented at Thursday, 2010-03-18, 22:54:44
mingodad modified at Thursday, 2010-03-18, 23:01:43
I thought it could be deduced when I mentioned "windows tgz", anyway the platform is windows vista home basic and daostudio 0.2 from http://dao-studio.googlecode.com/files/daostudio-0.2-dao-1.1-win32.tgz, also the daostudio isn't linked with threads.
One Example:
One Example:
# Dao Language for Scripting and Computing
(dao) stdlib.load( "D:/daostudio/demo/tuple.dao", 0 )
=======Tuple=========
( 123, 456, abc ) ( FUNCTION_17_0131D098, ( 123, 456, abc ) ) abc
tuple<int,int,string>[019CCFD0] tuple<routine<...=>string>,tuple<int,int,string>>[019CDCF0]
( 1.200000, 3.400000 ) tuple<x:float,y:float>[019CD490]
( 1.200000, 3.400000, 5.600000 ) tuple<float,float,float>[019CD350]
( 1, 3, 5 ) tuple<int,int,int>[019CD410]
Un-rescued exception raised by ::main():
At line #27, in file "D:/daostudio/demo/tuple.dao";
Error: invalid field
Un-rescued exception raised by ::main():
At line #1, in file "MainNameSpace";
Error: loading failed
(dao)
(dao) stdlib.load( "D:/daostudio/demo/tuple.dao", 0 )
=======Tuple=========
( 123, 456, abc ) ( FUNCTION_17_0131D098, ( 123, 456, abc ) ) abc
tuple<int,int,string>[019CCFD0] tuple<routine<...=>string>,tuple<int,int,string>>[019CDCF0]
( 1.200000, 3.400000 ) tuple<x:float,y:float>[019CD490]
( 1.200000, 3.400000, 5.600000 ) tuple<float,float,float>[019CD350]
( 1, 3, 5 ) tuple<int,int,int>[019CD410]
Un-rescued exception raised by ::main():
At line #27, in file "D:/daostudio/demo/tuple.dao";
Error: invalid field
Un-rescued exception raised by ::main():
At line #1, in file "MainNameSpace";
Error: loading failed
(dao)
fu commented at Friday, 2010-03-19, 08:37:29
Sorry, I just had a quick glance and miss the word "windows". Did you also try this: daostudio-0.2-dao-1.1-win32.exe?
mingodad commented at Friday, 2010-03-19, 10:56:50
No I haven't but I did tested the linux daostudio 0.2 with the same results as I mentioned on windows, no thread library linked, examples doesn't work.
fu commented at Friday, 2010-04-09, 05:32:35
Only the tuple.dao example has a real bug. This bug shows up when it is run in DaoStudio,
while from command line there is no problem. The reason is that, when run in DaoStudio,
a variable appear outside any nested scope will be automatically considered as a global
variable (it should be like this in interactive environment) instead of as a local variable as in command line mode,
so the following line of codes is compiled differently.
The error arose from the nested_class.dao example is not a real bug. The cause is the same as mentioned above. A variable compiled as local variable in command line mode is compiled as a global variable, which interferes with a supposedly local variable in a function. That variable is b in the following codes inside and outside of the function Foo() :
Again the error arose from the return_param.dao example has the same root, where only local variable can be used as reference in parameter list to return values through parameters. But in interactive mode, the local variable i was compiled as a global variable.
The const_param.dao is a counter-example, to show how constant parameters can not be modified inside functions.
At last, the coroutine.dao and coroutine_lua.dao raise exceptions when the coroutines are called for more number of times than the number of available yields they can produce. That is also what the example intended show.
To be less confusing, some of the examples will be revised, or be better documented.
t2 : Point3D = ( 1.2, 3.4, 5.6 );
The compiled code for command line mode is OK, but the compiled code for interactive mode
will show this bug. It is a typing bug, and now it is fixed.The error arose from the nested_class.dao example is not a real bug. The cause is the same as mentioned above. A variable compiled as local variable in command line mode is compiled as a global variable, which interferes with a supposedly local variable in a function. That variable is b in the following codes inside and outside of the function Foo() :
b = Bar{};
Again the error arose from the return_param.dao example has the same root, where only local variable can be used as reference in parameter list to return values through parameters. But in interactive mode, the local variable i was compiled as a global variable.
The const_param.dao is a counter-example, to show how constant parameters can not be modified inside functions.
At last, the coroutine.dao and coroutine_lua.dao raise exceptions when the coroutines are called for more number of times than the number of available yields they can produce. That is also what the example intended show.
To be less confusing, some of the examples will be revised, or be better documented.
fu commented at Friday, 2010-04-09, 07:18:15
I will make some modifications so that the compiling difference in the interactive mode only effects codes presented in the interactive console, while the codes in loaded files will work as normal.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
fu: Fixed and updated There was a minor bug in storing returned value in the DaoVmProcess structure. Now it is fixed and up ... (Sep.07,23:43)
klabim: ... Ok, I found it. It can be so easy by reading the documentation :- ). I have overseen the keyword glob ... (Aug.21,18:09)
klabim: returning a string from function to c++ code! Hi, I run in some trouble while calling a dao function from the c++ code. The dao function should re ... (Sep.07,19:44)
klabim: sharing vars between scripts Hi, how can I share a variable between 2 scripts in an embedded environment? For example: script 1: ... (Aug.21,17:55)