World: r3wp

Robert - discussion of you, networking gurus is needed. I don't know, 
where is the distinction of transport and service layer in LNS. If 
LNS is mostly services layer, which can be used over whatever transport, 
well then. But if not, why not to go with some multiplexing engine 
like Uniserve, which, via plug-ins, dynamically can "syndicate" (interconnect) 
us with the rest of the world - IRC, Jabber, ICQ, http, SOAP, webservices, 
whatever ...

RebDev messaging works at a higher layer than LNS or rmp:// - human 
messages, not program messages. Not comparable.

Uniserve works at a lower layer. You can implement LNS on top of 
Uniserve, and RebDev on top of LNS.

hmm, but LNS is also a transport in itself. It at least can work 
upon http and cgi ...

All of these are transport layers, even Uniserve (which works on 
TCP). As long as things are simple at a given layer we're fine.

Pekr, you're welcome to use the fms applications at rockfactory.us 
for any virtual conferences you want to set up, if that'll help at 
all ... that is, until we get a full REBOL video conference solution 
:)

Just lemme know if the gurus ever want to do anything like that...

My response to a query aboit REBOL3 on REBOLtalk would not make a 
marketing person happy:
-- year old alpha
-- no obvious contact details for those wanting to get involved.
Could someone better connected do a better job, please?

http://www.reboltalk.com/forum/index.php/topic,1827.msg4644.html#msg4644

I'm on it.

does R3 have library! capabilites so far?

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

Maxim, untested, I think.

No load/library in the current (ie jan-2008) public alpha.
Not sure if it is in later versions.

I don't see it here.

and are there any specs on how to use the rebol.dll itself outside 
of the environment RT is building?

Sunanda - all Carl's energy is spent on prepraration for the next 
alpha release, the public one. I think it is wise to have infrastructure 
ready first, to handle the load it might cause.

So - work on GUI is postponed right now to above mentioned activities. 
Once it is done, there will be release to more wider audience, before 
any work on GUI continues.

wrt library... ok

Petr -- But there needs to be some evidence that the project is still 
alive and deliverying.
A one-year old public alpha is not that.

Maxim - have you read my proposition to start wiki page to define 
our needs for library component? We should really do so!

You will surely agree, that so far, supporting C code is mostly a 
joke ...

rebol3 /core really should be finished before any rebol/view is released. 
 just like the very first v1 release.

yes... I am doing so right now... implementing the windows bitmap 
handling and gdi is *NOT* fun.

Maxim -- load has to some extent been replaced by transcode.
So lack of /library may mean the functionality is elsewhere.
The same is true with load/header.

(in R2)

I always tought that the load/save refinements for library and image 
formats was pretty strange.

pekr... R3 MUST support unsigned values for starters.

even if only in structs

re R3 /library. I talked about it with Carl one year ago. He was 
not sure /library component will be added as-is. Instead, he thought 
about making it a plug-in. But - plug-ins are done from some 80%? 
They also need 'modules, whicha re not finised too. But - we could 
do some preparation work.

furthermore, the ability to contain or point to structs must be explicit... 
right now, I can't deduct from the library docs if structs pointing 
to structs is even possible!

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!