World: r3wp

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.

You fools! Rebol 3 will never be released! This has all been elaborate 
conspiracy! Hahahaha!

Petr (from Ports):
http://www.rebol.net/wiki/Port_Implementation
http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples(a good one ....)

http://www.rebol.net/r3blogs/0127.html"Pruning down Read and Write"
http://www.rebol.net/r3blogs/0128.html"Skip and Seek on ports"

http://www.rebol.net/r3blogs/0129.html- async http transfer using 
tcp

http://www.rebol.net/r3blogs/0130.html"More about port layers" (continuation 
of Pruning down Read and Write article)

thanks chris for the references

It's funny, the more mezzanine code I write for R3, the more errors 
I find in R2. There are some pretty significant design flaws in R2.