World: r3wp

(well maybe more than 7.1MPixel. but anyways... the fact that REBOL's 
memory footprint grows everytime I do load on a .png... and never 
shrinks... means it will eventually crash, whatever I do  :-/

Sounds so familiar :(

I have a script that invariably dies doing png stuff.

Unless I disable gc.

but then I guess ram grows even faster!  no?

yeah ... so makes it unusable.

And then I call 'recycle .. and boom!

Did you try [save] as it states that this attribut saves the stuct 
from the GC?

but that means it *never* gets GC'ed

Maxim, does it also happen if you load it into a pre-allocated binary 
and clear it when you're done?

Yes, you could try to reuse it.

henrik: you mean something like:

imgbin: read/binary %image.png
img: to-image imgbin

?

>> loop 10 [load http://imgtops.sourceforge.net/bakeoff/o-png24.png
probe stats]
8182845
9736970
7443459
8997056
7443107
8996528
7442755
8997056
7443811
9001104

So no dangers there at least.

Maxim, no forget my question (takes too long for me to come up with 
a solution, and I must get back to work).

when I was doing my app, I was able to break rebol just with a make 
image! and some use of it in a function... but right now... can't 
remember the exact pattern I was using... calling make image! 10000x10000 
twice is currently behaving correctly, growing to 800mb and shrinking 
back to 400mb

it was probably related to using the image in view or AGG specifically, 
or maybe specifically to using a png format image.

and using 'recycle actually throws the bitmap data away... so I just 
look dumb right now, cause I can't figure out exactly what pattern 
led me to give up... but anyways, I tried getting it to work for 
3 hours... and it always crashed, because of memory footprint... 
 ' :-/

image magic rendered the equivalent of 100GB of image data for 1h30 
at 100% CPU usage (and only a few hundred MB or RAM) and didn't fail... 
so I was very impressed by it, in any case

Maxim - try asking Cyphre - he is now our low level gfx guru. He 
might know, how it is implemented. Also - with R3, entire compositing 
engine is replaced by AGG one.

if I ever get back to that project (which is related to a visual 
arts project) I'll investigate further, but in any case, I'd try 
first within R3.  I imagine that its better to debug them there within 
the gobs, if there is still an issue related to this... which I expect 
not to be the case anymore, since most if not all of this was rewritten.

back to windows windows GDI integration within R2   ' :-(

Reichart: "the core routines take care of themselves" - that's R3, 
once we get to add all the conversions that you need when you deal 
with the outer world (web, files stored in charsets other than unicode 
for reasons i will never comprehend, etc.)

I'm having a memor issue too.

I have an app that uses a scroll panel that I fill with text and 
images (a "page"). Each time I change the panel data (the "page") 
the memory footprint increases. But If I reload a "page" that was 
previously displayed memory size  does not change.

I can see if the memory holding the "page" does not clear properly 
but how does it know that the "page" is already in memory?
I'm holding the composed data in a block - 
	page: copy [ composed page data ] 
and I clear it befrore rebuilding it - 
	page: copy [ ]

memor = memory

as long as you have a single word pointing to data, it stays in ram. 
 so if you re-link it within the face without changing it, all its 
doing is basically a window refresh.

did I understand your question correctly?

I'm changing the content (text and images) of the page each time 
I "show" it in the scroll panel. And each time I "show" a new "page" 
memory use increases but if I re-"show" a page that was previously 
viewed memory use does not change significantly.

yes that is normal.  the GC already has the memory somewhere.  you 
new images probably are being held up by some stray pointer to them.

R3 plan for January - http://www.rebol.com/article/0386.html

I am not very experienced in how making bindings in various scripting 
languages work but I have fiddled around this a little... python 
by itself doesn't do anything automatic I think - and to my knowledge 
python isn't the best example of easy binding to c libs, but there 
are comunity provided tools that help you generate the interface 
code etc...  most people I saw used SWIG (which works for a lot of 
languages) http://swig.sourceforge.net/.. but the chat was that 
if you use that tool you geet quite a bloated code for interface.

many people link the stuff on the C side and recompile python itself.

If you want to look for languages that provide very elegant way of 
making bindings you should to my knowledge look at Lua (lua started 
with this) , lua provides simple to understand stack approach. Then 
there is haxe which provides even more elegant way to do this . Both 
languages also enable to embed the VM/interpreter into C++ app. I 
have used both to do both and it was very simple as I am not a power 
low level programmer

haxe = nekovm (nekovm.org)

The most elegant binding I have seen so far was done by Factor .. 
there you don't even have to "code" in a classical sense, you just 
define the interface and that's it ... as I said I am not very experienced 
in all this (I hacked factor's sqlite binding and to add another 
c function inthere I just added 1 line.)

this is a link to nekovm's FFI , pretty simple to use http://nekovm.org/doc/ffi

uh, R3 plan... I hope the public alpha will come out soon so I can 
also start playing with it

Rebdev only R3?  Or can a R2 client be written?

Graham, Carl says an R2 client can be written, but is low priority.

Does anyone know if REBOL3 will include REBCODE functionality?  If 
not, then it would be cool if we could DO rebcode from a REBOL3 script 
somehow.  Such as DO %rebcode.bin to give us the functions of REBCODE 
to use in our scripts.

There is no rebcode in R3 as it would be a different challenge to 
put it in there than in R2. R2 also offered certain tricks that are 
not possible in R3, which would make rebcode run slower in R3. BrianH 
has explained this a few times (but I can never remember the exact 
explanation :-)).

Would be nice to just pass the arguments to a rebcode module and 
have it pass them back.  Even giving rebcode networking features 
might enable that.

Henrik, do you know if Carl  would be up to building a rebcode based 
2.7.6?

Old BrianH quote:


The new function binding model in R3 makes Rebcode not as fast in 
R3 as it was in R2, if it uses the same semantic model. In order 
to be worth including we would have to change the semantic model 
accordingly.

I could really benefit from having rebcode in 2.7.6 then.

Paul, I don't know. I don't think he wants to spend much time in 
2009 on R2. The schedule for R3 is pretty long as it stands.

But I would think it would be somethign that he just drops in and 
compiles isn't it?

He already has it in 2.6.x?

I don't know that process, so I don't know. :-)

Maybe Brian can provide more insight.

That's a special build. Also rebcode was never really finished as 
there are security issues with it.