« Return to Thread: .oct files - keeping state across calls
Re: .oct files - keeping state across calls
by Christophe Tournery-2
::
Rate this Message:
Attached is an example .cpp file that can be compile with mkoctfile,
demonstrating the issue. I have included a simple makefile to compile
it and create the necessary symlinks.
The code tries to store handles to a library in a map. The key to the
map is passed back to octave such that the "user" can choose on which
instance of the library a function is called.
Thanks for testing and I am curious to know if you guys think it is a
bug in 3.2 or if it was "un-intentionally" working in 3.0.
Christophe Tournery
Testing in Octave 3.0.5:
------------------------
octave:1> h1 = mylib_init()
h1 = 0
octave:2> h2 = mylib_init()
h2 = 1
octave:3> mylib_destroy(h1)
octave:4> mylib_destroy(h2)
Testing in octave 3.2.0:
------------------------
octave:1> h1 = mylib_init()
h1 = 0
octave:2> h2 = mylib_init()
h2 = 1
octave:3> mylib_destroy(h1)
error: mylib_destroy: handle '0' does not exist!
octave:3> mylib_destroy(h2)
error: mylib_destroy: handle '1' does not exist!
On Jul 9, 2009, at 8:41 PM, David Bateman wrote:
> Christophe Tournery wrote:
>> Thanks for the tip, I did not know mlock().
>>
>> However the problem is still there. The list of handles has a
>> different memory address when calling the mylib_init() function and
>> when calling the mylib_process() function. Has there been major
>> changes from 3.0 to 3.2 regarding loading oct files?
>>
>> Do you guys encounter this design problem often or is there a very
>> simple solution I do not see?
>>
> At this point I'm not sure there is a problem at all. Could you send
> a complete simple example demonstrating the problem..
>
> D.
>
>
> --
> David Bateman dbateman@...
> 35 rue Gambetta +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
>
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
demonstrating the issue. I have included a simple makefile to compile
it and create the necessary symlinks.
The code tries to store handles to a library in a map. The key to the
map is passed back to octave such that the "user" can choose on which
instance of the library a function is called.
Thanks for testing and I am curious to know if you guys think it is a
bug in 3.2 or if it was "un-intentionally" working in 3.0.
Christophe Tournery
Testing in Octave 3.0.5:
------------------------
octave:1> h1 = mylib_init()
h1 = 0
octave:2> h2 = mylib_init()
h2 = 1
octave:3> mylib_destroy(h1)
octave:4> mylib_destroy(h2)
Testing in octave 3.2.0:
------------------------
octave:1> h1 = mylib_init()
h1 = 0
octave:2> h2 = mylib_init()
h2 = 1
octave:3> mylib_destroy(h1)
error: mylib_destroy: handle '0' does not exist!
octave:3> mylib_destroy(h2)
error: mylib_destroy: handle '1' does not exist!
On Jul 9, 2009, at 8:41 PM, David Bateman wrote:
> Christophe Tournery wrote:
>> Thanks for the tip, I did not know mlock().
>>
>> However the problem is still there. The list of handles has a
>> different memory address when calling the mylib_init() function and
>> when calling the mylib_process() function. Has there been major
>> changes from 3.0 to 3.2 regarding loading oct files?
>>
>> Do you guys encounter this design problem often or is there a very
>> simple solution I do not see?
>>
> At this point I'm not sure there is a problem at all. Could you send
> a complete simple example demonstrating the problem..
>
> D.
>
>
> --
> David Bateman dbateman@...
> 35 rue Gambetta +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
>
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
octtest.zip (1K) « Return to Thread: .oct files - keeping state across calls
| Free embeddable forum powered by Nabble | Forum Help |
