World: r3wp

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.

(rebcode can easily crash REBOL if used wrong)

I would use it if it were a separate process that I could access 
via networking port just to get to the computational  advantages.

I think you can do that with the special builds.

You probably right I didn't think if would have networking or not.

I'll look into that.

it's a full REBOL/View build, so it should work

ahh ok.

I knew that also but wasn't thinking.

Thanks Henrik.

Is tcp/ip going to be primarily async in R3?  Or will there be synchronous 
protocols also written?

for http, pop, smtp etc ?

I think that TCP/IP is pure async and HTTP also, but functions like 
READ would work in a synchronous manner.

On another note, a new R3 internal release was made a few hours ago 
with all of BrianH's changes submitted to DevBase. Yay!

... yes, and it seems to me we are aproaching the release .... slowly 
but surely .... http://www.rebol.net/wiki/R3_Alpha

Still work in progress, but good sign of things happening ... so 
hopefully, in one month, there will be load of devs cooperating on 
R3 development ...

yeah... something is comming...

not now plz, i have to go bed...

you can watch internal releases here - http://www.rebol.net/wiki/R3_Releases

:-)

don't expect it being out this week ... you can safely go to sleep 
:-)

i saw them early

i check  docbase several times per day ;-)

but...but... to nite there's something strange in the air...

anyway, i take the risk, i go to to sleep, nite.