World: r3wp

Gabriele - could you please pass my latest comments/links to Carl? 
I looked into Io slide-show and found they do use libevent library. 
I posted links into TechNews group. There is interesting reading 
in-there, also hidden is some links - liboop and The C10K problem 
..... Maybe we will find another libraries for further rebol improvements, 
like Cyphre did find agg.

http://www.liboop.org/why/

I've got a question for RT about rebcode. Is rebcode going to support 
paths and/or some kind of binding? Thanks

Carl is pretty busy right now, se we should maybe pass the links 
later on. please remember me about it.

Kru, one of the list of suggestions we compiled for rebcode was a 
BIND opcode.

What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?

Charles - the page is empty ...

Please, could RT post a small update in a form of short blog article 
about current state of developments? 14.11. was missed without single 
note ...

One of my rebol friends was also curious, if RIF will make it for 
the next update?

thanks a lot ...

14.11: only RichText is late, actually. And, you have seen it at 
DevCon, so you know it's real. I agree with you an official update 
would be great, though.

Gabriele, your introductory posts in this group said: "I will post 
answers here each wednesday."

There are some questions that are several wednesdays overdue for 
a response.
Are there issues with continuing this group?

Gabriele - I know about rich-text, but from Cyphre I also know, that 
at DevCon, IIRC, it was part of an external library, so hopefully 
there is no problem with further integration, all goes well, and 
we will hear some updated status info soon ... would be nice.

Sunanda: I can only post answers if i get them. :(

Gabriele - just curious - do you know if RIF will be in-there for 
e.g.?

RIF is quite high priority. But there have been changes in priorities 
in the last couple weeks, so other things are going to happen first.

changes re technology, or just that platform changes, so e.g. OS-X 
gets priority etc.? :-)

anyway - thanks for the answer ... so RIF might or might not come 
.... hopefully it stays high enough for the next wave of updates 
...

Q about encryiption within rebservices: my *guess* is if you are 
using core or view, then rebservices can' t use rsa encryption method 
but must use encloack/decloack method. And there is no plans to upgrade 
for rsa support in the next releases of  core and view . I'm rigth?

About current yes, about plans i guess not. But maybe ssh-tunnel? 
I heard about an installer for that in rebol.

Interesting!. Do you have a link?...

No. IIRC Gregg was involved? I guess a google with "rebol" could 
help

yep. already googling, thanks

stunnel could do the job, good tool ...

thanks Pekr!

I worked on an STunnel installer and portal for SURFNet. Not sure 
what parts of it are public. Maybe Maarten will chime in.

AFAIK the free versions of REBOL will have to make do with ENCLOAK/DECLOAK.

Alberto: AFAIK, that is correct. Only CLOACK if you don't have /Pro 
or /Command.

Some questions for tommorows Q&A wednesday: 1. What is fixed/added 
in 2.6.2/1.3.2 (change-log, please) ? 2. What is planned for 1.4.0 
(rebcode, rebservices, rich-text, RIF, and last but not least, fixed 
sound ...) ? 3. When can we expect 1.4.0 ? Thanks.

fixed in 1.3.2
: There are 41 tickets that match your query.

In Carl's blog is written "More than 50 RAMBO tickets have been implemented 
or fixed." so there's at least ten more fixed bugs and convolve effect 
has been added, so there are some new features (or at least one :)

or he forget to mark?

some are labeled "fixed in Core 1.3.2" and other names... don't know 
if it searches single words or exact phrases

Hm, if you search for 1.3.2 51 tickets match the query

Thats exactly the "ore than 50 RAMBO" :))

yes :)

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

many thanks, guys!

Q: "Is rebcode going to support paths and/or some kind of binding?"

A: "I estimate that rebcode would be about two times slower than 
it is now."

Its about passing objects as parameters. Then binding is not known 
at compile-time, and changing anyway. It can be an ugly extra instruction.

set w 'action

(argh, switched "send on enter" on)

set w 'action
bind w object
getw value w

would not slow down the other statements.

Q: "One Laptop Per Child"

A: "My current understanding is that the target software is Smalltalk 
based"

Why not integrate rebol into smalltalk? You proposed a rebservice-access-library 
anyway, which - ups - is accidentally a real rebol under the hood. 
I expect that smalltalk is squeak, as i saw Alan Kay within the supporters, 
and Child and latops is his long-running topic. If, its multi-platform 
too, maybe we could even use squeaks multimedia in our lacking areas.

In response to the answer to my question about the path action (thanks!) 
I wonder, why do internal functions like path and native need to 
be assigned to global words at all? Can't they be assigned to some 
internal object fields, or in some way be hidden? I know that encapsulation 
isn't really REBOL's style, but littering the public interface with 
undocumented natives that can't even be used by mezzanine code seems 
a little silly.

As for the question about rebcode binding, let me make it clearer:


It would solve all of the object field retrieval problems in rebcode 
to have an opcode added that would be the equivalent to the IN native, 
or maybe BIND. You wouldn't need path evaluation to be added - you 
could just retrieve an object field word and use setw/getw with it. 
Yes, you can use apply, but it is very slow in comparison with opcodes. 
Working with object fields is a pretty basic operation that doesn't 
have any direct support in rebcode, and some have come to miss it, 
particularly those that use objects in data structures. I often use 
blocks for data structures when I can because of the context overhead 
of objects, but some are more used to thinking in object-oriented 
terms. Plus, there's all of those built-in object-based structures. 
Still, I suspect that many of these questions would go away if apply 
was faster :(

Yes, this bind-like opcode was one of the requests that we came up 
with when we were compiling a list of rebcode enhancements. Thank 
you for implementing many of the other enhancements on that list 
:)

Do I need to compile a RAMBO request?