World: r3wp

Gabriele, I know that R3 handles case-insensitiveness of Latin1 characters 
in Unicode text better than R2 with UTF-8, but beyond that I don't 
know. There is still some stuff to do relative to Unicode. The implications 
of Unicode support on the rest of the system are mostly implemented 
though, with the glaring exception of PARSE.

Are there any good tutorials on using asyncronous networking in R3? 
 That changed from R2, right?

Good tutorials: Not yet. Turorials: Sort of. Changed: Drastically.

TimW, you can find some information on DocBase, notably here: http://www.rebol.net/wiki/Ports

Is there implementation information available for students?

Thanks.  The port information is pretty good.

alpha 37 is now available for OSX.

Brian: if it's just latin1, does it really change things? it won't 
always work anyway. but, there's plenty of code to convert utf-8 
to latin1 in R2, so why not just doing that if it's really important 
to have case insensitive accented character in the user names?

I'm wondering now if r3 eats a lot of CPU when running the upgrade 
procedure under linux or just by using READ with HTTP. It does so 
under OSX.

Gabriele, Unicode isn't done, so I don't understand this: "does it 
really change things?". I was just answering your question about 
R3. Whether R2 can handle case insensitivity of UTF-8 when third-party 
libraries are added is another issue.


I can't say what Carl's priorities are beyond where he had me mark 
CureCode tickets as urgent, so I can't say when or if Unicode will 
be "finished". User account creation is reenabled, so the whole reason 
this conversation started is moot now.

I noticed the GUI demo in R3 is very buggy.  Sometimes it just eats 
CPU and does nothing.

Paul, have you found patterns for the slowness?

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Pekr, there was an opinion for a name-change. See group "Survey Group" 
in R2-Alpha world, that you have access to. I guess, they ended up 
as mezz to be more compatible with existing code.

Henrik, not really - its intermittent.  But usually as soon as I 
bring up the demo is when it sometimes locks up.

I actually have to kill the process to regain control on Vista.

I've experienced some pauses in VMWare, but attributed them to R3 
building the text for the Text View pane. There is also a bug that 
causes it to lock up if you click buttons too quickly in the HTTP 
pane.

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Because we are cleaning down the core in R3, and those functions 
are rarely used. They are fast enough as mezzanines - the FORSKIP 
loop they call is native in R3.


Mezzanines can be better for some purposes too - REBOL is a much 
more powerful language than C for some things, so it is sometimes 
a good idea to write the functions in REBOL instead, particularly 
when it needs to be flexible. This is why LOAD is a mezzanine in 
R3 (which calls native code to parse the REBOL data), and half of 
DO is an intrinsic (a built-in function written in REBOL that is 
called by native code).

Part of the R3 boot-up process is an intrinsic too, as is part of 
the MAKE port! and MAKE module! actions.

BrianH: what is exactly happening now? Are we seeing start of formation 
of new DevBase? Some files are uploaded already. Or is there still 
some functionality missing, to replace devbase?

The new DevBase (3) mostly works now. I posted some suggestions today, 
but it is usable as-is. I'm only using DevBase 2 for historical reference 
now. DevBase 3 doesn't have a reviewer concept, so I'm going to ask 
Carl what the new acceptance policy is - I have the rank to accept, 
but the guidelines need to be updated for the new model. Most of 
my todo list for DevBase 2 is already implemented in DevBase 3, so 
in many ways it is already a vast improvement.

I find I'm using the help function in the console all the time. It 
would be good if the help function could have some refinements for 
searching throughout the function definitions, or limit the search 
to specific parts of the definitions. Would this be a difficult enhancement?

this would be really cool  just like searching the man pages in unix... 
the easiest way to find a shell command when you can't remember it. 
 :-)

BrianH: as for filesharing - can we share also binary files? Is it 
general mechanism, or is RebDev limited to only text files and their 
diffing?

AdrianS: some small helper, but you probably know it. What you can 
do is partial word searches. E.g. try:

help to- ; and it will list every to-* function
help pr ; it will list every function containing "pr"

Yes, I saw the partial word search, but that onl searches within 
the word, not its definition. Also nice would be something like smalltalk's 
ability to find methods by supplying a signature example - i.e. give 
me all functions where the arguments are <integer>, <string>

perhaps as a refinement to HELP, such as help/args integer!

yes, something like that would be good. Should I make this enhancement 
request in CureCode to keep track of it?

Yes, please post that to CureCode.  It's a brilliant idea!

added as http://curecode.org/rebol3/ticket.rsp?id=676

how is that usefull to you? Do you really search for function, which 
accepts some concrete args? Why would you do so? :-) What about searching 
in help string?

well, when learning a language, you need all the help you can get 
- if I know the datatype of the args, I would probably like to know 
all the things I could do with them (append one to the other, multiply, 
union, etc)

oh, I think you mean why in the ticket I didn't have the dataype 
specified with the refinement - I'll change that

typesets should also be considered

what do you mean?

wasn't aware that a set of datatypes was a type itself

it's R3 only.

I have a long time proposition for help on dialects. Imagine e.g. 
VID, where styles do have help strings too. Gabriele proposed:

help/vid button

... whereas I proposed: help/dialect vid button

Not sure, if we can make help system pluggable that way?

Pekr: "can we share also binary files?" - In theory we are supposed 
to be able to. I haven't tried it yet.

The typeset! type is a new addition in R3, and emulated in R2-Forward. 
TYPES-OF returns the type spec of a function in both.

I like the idea of a refinement to have HELP search, but I think 
all of the options can be collapsed into one /search refinement. 
Search for a datatype could check type specs, for a refinement could 
check for supported refinements, for a string can search doc strings, 
maybe more.


In general we prefer full words for options, particularly for user-level 
functions like HELP, so maybe /args is not the best name for this 
option - that's why I suggested /search. Please don't call the refinement 
/find or /all, because that makes the implementation of HELP incredibly 
awkward.

Believe me about the awkward: I wrote LOAD, and avoiding the use 
of the ALL function because of LOAD/all was annoying :(

BrainH: how would you solve the problem of documenting dialects? 
(having ability to query them for help?) Do you think we can plug 
it in default help? What about loaded modules, will they naturally 
extend help?

Maybe a /dialect 'name option, with installable dialect help? DELECT-style 
dialects like Draw and VID could have autogen docs too.

Module docs could be part of the Exports spec.

I commented the CureCode ticket listed above with the /search option 
variant, and marked it as reviewed.

Brian: the exact naming of any help refinements is not an issue to 
me - what you propose sounds good. How would you specify, using only 
the /search refinement, that you're interested in searching the descriptions 
of refinements? What about specifying the order of the types in the 
spec as opposed to searching without regard for the order?

I just added refinements to the comment, AdrianS. Typesets have no 
order, so the order in the spec is irrelevant.

If the /search option is OK with you, please add a comment to the 
ticket saying so, so that the developers will do that instead.

I just read your comments Brian and I'm not sure what you're suggesting 
allows for the flexibility I was trying to get. It seems to me that 
there are not too many 'components' in a word definition. What I 
see when I get help is USAGE, DESCRIPTION (at the top level and at 
the refinement level), ARGUMENTS (and their type).  What I was after 
was a way to compose the help query to be very specific, but it seems 
to me that what you outlined would follow a certain lookup order. 
Did I misunderstand? With only the components just mentioned, is 
it too much to specify them specifically and in parallel with each 
other?