r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

World: r3wp

[RT Q&A] [RT Q&A] Questions and Answers to REBOL Technologies

Q: What does the world on Nov-15-2005 look like?

A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 

Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?

A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.

Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?

A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.

Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?

A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.

Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.

A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.

Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...

The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).

A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.
Thanks Gabriele and Carl.

How about web publishing the answers somewhere, so the millions without 
Altme can see them?
Perhaps as a weekly blog?
web-public already
Any reason why you can't be more specific here "Oh, and regarding 
VID: we plan to be making very big changes there. More to come soon." 
Web-public already ---- True, but only for a month or three, depending 
on the Q&A rate.

shows only the most recent 300 messages.....Many web-public groups 
have "lost" a lot of valuable discussions that way. A more permanent 
and Google-friendly home is needed for much of this.
thank you very much Gabriele and RT  - this aproach is SO MUCH appreciated, 
that you will probably not believe it!
Graham: More to come soon. :-)
Gabriele - why the secrets? :-)
The Q for next weeks round is:

(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: I'm not sure what is meant by the path for it. You mean for refinements?

Yes, that is what I meant. If it is a major slowdown to check for 
this, add the APPLYP opcode I mentioned for the more general case, 
or have APPLY for the general case and APPLYF to apply functions 
only. Or you could just apply functions and have the refinements 
case be put in a do block or a wrapper function. You can handle refinements 
in rebcode, right?
Anyway, thanks for the struct! support and the new datatypes!
Nevermind on the paths for refinements: I just saw rebcode test 10 
and your apply, putting the refinements in the argument block - it 
will do nicely :)
Some time ago I talked with Carl here on AltME and mentioned PhotoThreads. 
Carl wanted me to keep an eye on it. There is newer version now. 
What is PhotoThreads can be read here: http://www.sics.se/~adam/pt/about.html
.... maybe we are lucky enough to get concurency with Rebol 3.x family 
Gabriele, I definitely would like to be informed and involved when 
VID changes are happening. You will let us know won't you ?
There are a lot of functions in REBOL that return the value none 
to indicate failure. Could you add an opcode
    none?: ["Set flag if value is none" word!]
to test for that?
To rebcode I mean, and the flag would be the condition flag.
eq var none
Nice :)
After testing, it seems that sett considers none to be false. This 
is exactly what I needed.
Request withdwarn.
btw, i think we should have a separate channel for enhancement requests...
I agree!
Did I miss a Wednesday ?
If Wednesday has been delayed, perhaps we can find out what the secret 
developments in line for VID are ??
Gabriele or Carl, have you checked the conversation in "Rebol Enhancements" 
where we were hashing out enhancements to and comments on rebcode? 
Carl did request this in his blog...
I just fear one thing which tended to happen in the past - RT was 
silent before the release, release was done and then it was late 
for suggestions. Gabriele, please, try to avoid that :-) Tell Carl, 
please, that folks do need his attention here. You have some input 
in Rebol Enhancements group. In fact we don't know where to post, 
so some of us submit even to RAMBO. Everybody feels we are near freezing 
for 1.4/2.7, so please let's not cut some fine late enhancements.
Hey, I always read this world. maybe not every message... but I read 
good to know, some folks seem to be worried, about where to post, 
it the message gets to Carl, etc. :-)
Gabriele -- could you point Carl to Feedback message #5a5e09270?
It's been unanswered for a couple of weeks.

Basically, asks if there is any plans for formating numbers -- as 
per the discussion here (core group, 5-oct)
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.
hello, where I could  find facts and values about Rebol vs Business 
world ? with reboltof (christophe Coussement, we have the project 
to write a white paper about Rebol and Business (target date, on 
March 17, 2005, for the french Rebol Day, Paris). How many developpers 
works with Rebol ? how many dowloads of Rebol/core and View ? How 
many licenses for SDK ? Examples of Business with Rebol, tools, softwares. 
Real-world softwares.... etc.
maybe we should write about using the opensource viewtop in the rebol 
there's a place set aside for that .. go ahead.
as far as i remember, i wasnt able to try it out because the description 
was not obvious for a newcomer. maybe now i would succeed trying 
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?
I'm not sure, how to make a use of it, but it does have an effect:
>> blk: [a b c]
== [a b c]
>> path blk 3
>> blk
== [a b]
>> x: [a b c d]   path x 'c   x
== [a b c]
looks like a kind of inconsistency
yeah, strange!
Not strange. it does a path-lookup. 
!> a: [b 1 c 2 d 3]
== [b 1 c 2 d 3]
!> a/c: 22
== 22
!> a
== [b 1 c 22 d 3]
!> a/4: 222
== 222
!> a
== [b 1 c 222 d 3]
the strange thing is that it puts this strange value there, which 
stops molding.
Here's a question for RT:

Should I wait on my feedback on the new rebcode docs until the next 
version of the interpreter, after the great rename?
Brain: probably, however I think Gregg may be happy to get your feedback 
I'll do a critique this evening, then.
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.
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.