Re: 4.1 multiple assign sequence items?
- Posted by jimcbrown (admin) Feb 05, 2014
- 1706 views
i have not seen the data on 4.1, because you didn't upload the 4.1 docs.
The latest version of the 4.1 docs was definitely uploaded: http://euphoria.indonesianet.de/eu4zip/doc41/html/release_4_1_0.html#_6653_version410datetbd
I'm not sure how you could have missed these.
I did not miss them,
Then don't knowingly make contradictory false accusations like this:
i have not seen the data on 4.1, because you didn't upload the 4.1 docs.
but they did not contain the DLL unload, which should be in 4.1,
It isn't. In retrospect it probably should have been (we could have added the new library routine immediately and fixed the long standing and unrelated memory leak issue later), but it wasn't so now it'll have to wait for post-4.1
because Matt did fix the memory leak.
In 4.0, there is no way to close or unload a dll. I believe there is in 4.1, so
There isn't, AFAIK. We discussed this, but the conclusion was very discouraging: http://openeuphoria.org/forum/m/119179.wc
Due to the code freeze, this will have to wait until 4.1.1
I believe Matt fixed the problems. However, i lost the code he last supplied, and has never responded about it on irc when i asked.
Regarding the DLL leaks, the last pastey i see on it is http://openeuphoria.org/pastey/157.wc and we discussed it on irc at 5am on Monday 10/1/2012.
Then Tuesday 10/2/2012,
[15:13] <katsmeow-afk> if someone like myself and raseu, and maybe Greg, were to know the max size of the dlls we wish to load-unload, can eu make a memory hole in itself so no memory allocation would be needed to load-unload thse dlls?
And then nothing. Since Nov 2nd 2012. But i am pretty sure Matt did fix the unload memory leak.
There was some additional discussion on IRC in between these times:
2012/10/02
09:50 <@mattlewis> no more leaks: http://openeuphoria.org/pastey/157.wc#3101 10:06 <@iamlost> mattlewis: :( 10:06 <@iamlost> mattlewis: ): 10:07 <@mattlewis> ? 10:08 <@iamlost> mattlewis: there's still no way to do that automagically 10:09 <@iamlost> each individual shared object must be hand edited 10:09 <@mattlewis> yeah, the translator needs to be updated 10:10 <@mattlewis> also, that doesn't release all of the top level objects that 12:40 <@mattlewis> err....now I remember why we can't deref all vars at the end 12:40 <@mattlewis> delete_routine()s may end up accessing freed vars 12:42 <@katsmeow-afk> then have the delete_routine() free the vars 13:38 <@mattlewis> eh...hmmm.....
2012/10/02
11:58 <@mattlewis> hmm...several files in the std library allocate some memory
Basically, mattlewis hand editted a simple translated dll's C source to fix the leaks. But then he looked at what it'd take to fix the translator to do the same auomagically, and it seems he got hung up by the fact that the std library allocated some memory w/o ever freeing it, among other things. So this hasn't been entirely solved yet. (Like the rest of us, mattlewis is a very busy person, and even within Euphoria, there are other pressing tasks at hand.)
Forked into: DLL memory leaks
