World: r3wp

didn't you say Carl will go for two week vacation? I was expecting 
he will not be so active for a while

Yes, he mentioned vacation in France, but dunno if he went there, 
or if he took his notebook with him, so he builds R3 in the evenings 
:-)

The r3 GUI demo code at r3/demo.r offers a Halt when running the 
test but only a Quit in the Demo launcher itself - and, at least 
on Windows XP, it blows out your rebol session - whereas the Halt 
in the demo does not.  Rather annoying as a GUI demo feature ... 
 does anyone have a moment to throw another button onto the demo 
launcher?

I am trying to traverse paths that I am using at http://cl1p.net
where a path might be http://cl1p.net/wp-aule///c2/Is there 
any way that I can use this to search for any path 3 deep such as 
http://cl1p.net/wp-aule/wiki/history/c2and  http://cl1p.net/wp-aule/wiki/alternate/c2
  and   http://cl1p.net/wp-aule/smalltalk/wiki/c2???   That is, 
can we tolerate null in paths as, say , type unset!   ??   I think 
of these as incomplete nestings of blocks where there happen to be 
unbound keys  blk: [k1 [  blka ]   where :blka  might sometimes be 
[ k3 blka1 ]  and sometimes just  [blka1]

I will go back to R2 Liguid and see what these would look like as 
data vars whose values are not yet known.   That cl1p.net tolerates 
these pseudo-URLs is immensly useful ...  for example, we tolerate 
the URL fine even in R2 as  in  test: read http://cl1p.net/wp-aule///test
 and test: read http://cl1p.net/wp-aule//path42/testand http://cl1p.net/wp-aule/path21/path43/test/

I'm having a little trouble understanding your question. File/URL 
paths have nothing to do witth the REBOL path! type - file! and url! 
are string types, so they don't have inner blocks or unset! values 
in them.

For url! values with multiple consecutive / characters in them, it 
is up to the server you are accessing to interpret them.

R3 file! paths ignore multiple / characters, though the CLEAN-PATH 
function replicates the leading multiple / fill-in-the-blanks behavior 
of R2 file! access, relative to a cuurrent directory.

when we don't find a word in a slot, we fail;  my question is COULD 
we tolerate an unset! where a word! is now expected ... the Rebol 
path! type is just too useful to ignore here ...  and our use of 
the character '/' does have "something" to do with our natural interpretaion 
of file and url - files assume valid hierarchy depth at time of tracversal, 
a web server need not ...  at the moment we have no type corresponding 
to what follows an HTTP schema and domain other than string .... 
or am I mistaken?

perhaps if someone knows an OS where the user (without recourse to 
a custom GLOB script) can search for any file, say cfg.txt at "depth 
5 " ,e.g.,

/home////cfg.txt as finding /home/local/bin/scripts.cfg.txt  and 
/home/lib/ruby/site/rules/cfg.txt

Of course at the moment in current r3, test: read http://cl1p.net/wp-aule///test
 pitches back with binary  ;-)

The problem is that an http server has the option to provite a directory 
of their resources, but there is no generally agreed-on machine readable 
format for providing such a directory, and the human readable format 
(a Site Map), isn't implemented on most sites. If the site you are 
interested in has a site map you can grab and parse that, or you 
can trace throuugh the links on the site and hope for the best, or 
you can make use of an external service like Google that has already 
traced through the links.

Most sites that do provide a site map only include a brief overview 
of their resources, not a comprehensive directory.

You are not mistaken - the path portion of a URL is just a string, 
which is interpreted by the server as it sees fit to do so.

I am trying to think through this as a "clade" and not a fixed "hierarchy" 
... as in every case of c2.com as a "terminal" tag there is a common 
"phylogenic" ancestor in "smalltalk" or "wiki"      Tagging is usally 
seen as in conflict with hierarchical ontoly and I am trying to get 
my head around this in looking at REBOL versus ICON to parse thses 
cl1p.net paths if I opt to go with them.   Gabriele last looked at 
some of my odd notions here ... they come from working in a PROLOG 
variant ...

read ontology.  ( as Heidegger rolls in grave to sound of Heraclitus 
laughing)

I realize I should just use parse for that post-domain string ... 
but the path! type looks so obviously right ...

The problem with ontologies on the web is that you have to get the 
server and the client to agree what the ontology should be, because 
the interface between them is just a string and a bunch of headers.

For instance, there isn't anything in the HTTP or URL standards that 
say that the path is necessarily a hierarchy, though the (poor) cookie 
standards definitely imply it. Ignoring the cookie standards, you 
could easily look at it as a tag list. However, you would need to 
be writing the server app to do so, since the server is what decides 
what the path means.

Debugging capabilites enchanced - track/back - http://www.rebol.net/r3blogs/0224.html

Will there be a way for R2 users to call the R3 dll and use it that 
way?

In theory something like that could be possible, but it would run 
into the limits of R2's DLL wrapping support pretty hard. The official 
answer to that question continues to be REBOL/Services, once that 
is revamped.

File Paths for Windows Servers - http://www.rebol.net/r3blogs/0225.html

Glad to hear it, and look forward to finding out if you will be able 
to change-dir to those paths :)

BrianH: is there any difference between R2 and R3 'call functions? 
I would like to test the boot time of R2 vs R3, and I thought I might 
use one REBOL process to call another one in a loop. I want test 
R3 vs R2 and R3 vs Rebbase. What methodology would you eventually 
suggest?

I don't want to go the way of installing and configuring Apache, 
and using some scripts to test throughput in real CGI scenario, as 
R3 CGI mode is not properly implemented yet ...

At least not on non-posix platforms (Windows) from what I hear. REBOL 
CGI on posix systems (Linux, OS X) should work fine.

CALL has been completely rewritten in R3 - it has almost nothing 
in common with CALL in R2, and is much lower-level. If you want to 
compare the startup times, if you use the same method to call all 
of them you should have something comparable. R3's CALL doesn't wait 
for apps to return yet on Windows, so writing your wrapper script 
in R2 might be easier.

BrianH: looking at tickets ... have we reached some positive point, 
where we fixed most of datatype conversion related tickets, and hence 
can move on ... to finally see the plugins released? :-) What can 
you see as the next logical priority to take? Or should we move to 
let's say networking? Networking is still not comparable to R2 - 
many protocols missing ....

Why is 'call limited in functionality in comparison to r2 version, 
and why also 'shift misses all its refinements?

CALL is lower-level, and thus faster in theory, and easier to implement 
on different platforms which might not have all of the concepts in 
the old R2 CALL. SHIFT doesn't need any refinements, and is *much* 
faster without them. Refinement processing overhead is really significant, 
even for natives, so low-level math functions tend to not have them.

Datatype conversions: I think that once TO-HEX is removed for most 
datatypes the conversion issues of the TO-* set will be done. The 
rest will be handled by proper conversion functions, that we don't 
need to write immediately. We should probably wait on implementing 
those as natives until the APIs are worked out in REBOL versions, 
or plugin code. We can speed them up later once their behavior is 
agreed on.

As for what's next: Carl is working on finalizing the plugin model 
- apparently getting the decoupling right has been tricky. I am fixing 
module importing and making a semi-formal model for the module system, 
and working on R2/Forward. I have an idea on how to simplify the 
specification of port schemes - implementation of port schemes is 
already simplified - but the module stuff is stuck in my head so 
I have to work on it first. If someone else wants to work on protocols, 
go right on ahead, preferably the useful ones first :)

There are a few data making/conversion tickets pending (some classified 
as "problem"): 984, 1001, 1034, 1056, 1081, 1109,1110. They don't 
seem too difficult to me, but then again, I have no accesss to source 
code.

Rudolf, can you set your user color slightly different? I can barely 
see your name. Thanks.

984 is no longer a problem, but might be misguided. 1001 and 1056 
had one attempt to implement them that hasn't worked yet. 1081 is 
probably a bad idea (no offence intended, meijeru). 1109 and 1110 
are dependent on the result of the blog #222 discussion. 1034 is 
critical in the long run, but not as important in the short run.

Thanks for bringing up #984 - I had forgotten to remove the problem 
status when the problem was solved.

hmm... immediate! and internal! typesets. I wonder what the first 
one is?

My guess is that immediate! types are ones whose values fit within 
a value slot of a block or context, and thus are not reference types. 
I would put all of the numeric types including money! in that set, 
as well as date!, time!, tuple!, and event!. Most of the time gob! 
can fit in there too, afaict, as can error! with codes less than 
100.

I was requesting such a typeset for documentation purposes months 
ago.

Henrik, my copy of ALTME does not allow me to change my colors anymore 
(or I haven't found the trick).

Robert, go to Home and Settings. There you can set your user color.

Rudolf, that is. :-) Sorry.

Third icon from the right on the upper right of the screen. The "Your 
User Color" setting.

#984 is not solved, because mold/all still does not reproduce the 
header -- I accept fully that the value is not recoverable , but 
mold/all should preferably provide the information

It is not solved, but it is no longer a problem.

I take that to mean that you know HOW to solve it, but haven't gotten 
around to it...

Having "problem" status means that there is some (possibly temporary) 
reason it can't be solved at the moment. Then you look to the comments 
for why.

As to #1081, I merely pointed out the inconsistency, and did not 
advance a solution. The more inconsistencies, the more documentation 
is needed, and the more there is for the user to remember.