World: r3wp

I think, that having really good /library component could bring us 
many more wrapped external libraries - call it a deployment. Currently, 
we are missing on most of outer library stuff, and we are living 
in rebol-only world.

yess. doing a C/C++ importer is possible.  especially for dll stuff 
which is autodocumenting in many cases.

or has .h to explain it in the least.

isn't Python e.g. being able to almost automate wrapping C definitions?

but my .dll question was the opposite.... using rebol.dll within 
a C application... are there any docs about doing this yet?  compiling 
your own interpreter, linking in your stuff on the C/C++ side of 
things is probably easier.  than trying to tie them up from the rebol 
side of things...

Maxim, no docs on .dll yet. The current alpha is a single .exe.

yes... for python its rather easy because the first class values 
follow most of C rules... series are static, for example.

Maxim - not much word on it. I do remember there was posted main 
wrapper even for R2 (look at plug-in groups here). But, there will 
be both .dll and also object file for static lingage with R3.

yess.... static linkage is what I would need more than anything.

I am slowly working towards elixirOS and that is a C version of elixir 
with rebol being the conscious brain, driving subconscious C datatypes 
and binary code...

not ready yet, but just wanting to see where things are now, so I 
can place my time and efforts properly.   Already started to look 
at OpenGL a bit and started doing C++ again.

I think that you gurus should take care of new /library definition 
on wiki (that way it does not get lost in discussions). We could 
start with revision of prior discussions in DLL (or was it library?) 
group here.

If you set it up, I will participate :-)   I have done library stuff 
a few times, even fixing ladislav's memcopy hacks once. 


 right now, I am faced with an signed/unsigned issue related to 16 
 bit values needed for a lib call... I honestly can't say from the 
 library docs, if the negative 32bit value in rebol's integer will 
 stay negative once converted to 16bits... for example. 

 this kind of information is Crucial for stability.

also, for lib usage a GC-independant alloc() dealloc() equivalent 
would be VERY usefull.  something we can manually free, in order 
to work with large dataset we really don't want the GC to grab.  
for example, using image magic, I can work with 10GB image files. 
 composing 100 of those images into another.  I can't let rebol's 
GC play around with such specific needs... this is just one example, 
but there are others.


sometimes handling stuff manually is easier than hoping an automatic 
system will do so properly.  in R2, images are never freed, for example, 
so for a task which rebol would be the ultimate image manipulator, 
I can't use it cause the third image I load from disk craps out rebol, 
since it grows beyond 1.5GB of RAM.

one question - isn't there any cute, cross-platform C compiler, which 
would not add more than 30KB to REBOL.exe, and could be included 
as a variant of rebcode? :-)

would /Command's 'free function by of any help here?

... hmm, according to help frees library or struct types only ...

nope...  its all working within the GC ... from the library docs: 
"For example, if a REBOL word that was defined as a struct! is reused 
to make another struct!, the memory used by the first struct! becomes 
unreferenced. Any unreferenced struct! values may be reclaimed by 
the REBOL garbage collector, even though the memory is owned by an 
external function."

so this means that the memory being used never actually gets freed 
back to the os, only to the internal GC pool, which never really 
shrinks.

Have you thought about using CALL to create temporary extra versions 
of REBOL.exe for the image processing? That's solve some of the issues. 
Though it would be clunky!

yess I did, but in this case, the goal is to do interactive AGG manipulation 
of one image at a time and stamp it on a layered composition.  by 
the time I load the third image (from a digital camera at 7.1 MPixel), 
rebol crashes  :-(

(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