World: r3wp

Yes, but I think you want the /only refinement in this case.

got it!   -- Thank you

You don't need to replicate the type spec of the arguments since 
this is just a helper wrapper function.

Can R3 be run in CGI mode? There seems to be -c command line switch, 
but no CGI helper functions, nor system/options/cgi path ....

IIRC Carl posted some short notice on that, but can't find it. I 
would like to start testing it, e.g. the speed of page build in comparison 
to R2.

Pekr:

http://www.rebol.net/r3blogs/0182.html

Thanks, just found it too :-)

Disappointed by outcome of latest blog. Binary conversion issues 
are still a catastrophe. We were supposed to get it right and easy, 
ok?

Writing a reaction ...

Using issue! to encode binaries is a disaster. We need better conversion 
functions, not syntax tricks.

then issue is completly usless type - remove it

It's useful as a syntax type. We are thinking of making issue! a 
unique and immutable string as well, with supposed modifications 
generating a new issue!. It would be like words without binding or 
as many syntax limitations.

I put my reasoning into blog post ...

hmm, Carl dismissed #1113. I wonder if 'bind is used so often, that 
he was afraid of overloading it, and introduced new mezzanine instead? 
Was that really necessary? Another one to learn ...

Apparently he considers initializaton to be out-of-scope for BIND. 
Oh well, it might have been cleaner - we'll see.

BrianH: is there a bug ticket for?:

>> to-issue #{0001}
== #??


... I did not understand from your blog post, if it is supposed to 
be fixed already, so the ticket exists, or not ....

I mistook the problem you were proposing for one that had already 
been fixed :)

yes, but is above a bug? Should be reported, no? :-)

ah, damned, latest time related changes brought back so called RED 
ICONS problem once again :-) We are still not reporting timezones 
correctly, ignoring summer time ....

Ah, actually quite the reverse. The problem of R2 is gone. Summer 
shift time is different date each year .... R3 works correctly, R2 
does not ...

That's cool - even a73 was broken - when you set time back to winter 
time, it reported wrong zone information. a74 works correctly.

Pekr, the above is not a bug. Your proposed change would be the bug. 
The issue! type is a string type, not a binary type.

We don't want to encourage any tendency to see issue! as a replacement 
for binary!, especially since issue! is a collection of Unicode codepoints 
internally, not bytes. The issue! type is also poor for binary conversions, 
due to the fact that it was designed for other things. It works well 
for what it was designed for, though there are proposals to make 
it work better for that (the unique string stuff mentioned earlier).

I really don't understand your attempt to make issue! be a binary 
conversion device. It never worked as well as binary! for that, nor 
is there any reason to expect that to change. Why don't you want 
to use well-designed binary conversion functions, rather than bad 
issue! tricks? The functions could even be backported to R2.

Because historically I am far from being alone, who finds current 
R2 working as being complete mess. How can anyone defend it? I can 
easily tell you, where it comes from. I am far from good at wrapping 
libraries, but I wrapped some functionality in the end. I can often 
see constants like:

0x0010

Which are for me equivalent to:

#0010  ; which I can get via to-hex or to-issue 16

#{0010} ; to-binary 16 = #{3136} .... and this is big WTF? Now at 
least R3 gets it correctly, although padded by full of zeros to form 
64  bit value


So, as you can see, my thought pattern came from not easy way of 
how to convert between integer and binary representation. I created 
my own crazy 2-binary function :-)


to-binary*: func [value [integer!]][load rejoin ["#{" to-string copy/part 
at to-hex value 7 2 "}"]]

So - stating above in regards to R2, my further thoughts went towards 
hex being a literal representation of binary values. But I forgot 
there is no hex! type, just an issue! type, which serves also other 
purpose. Now as to-binary 16 gives me desired value, I don't need 
to go via to-hex anymore ...

Sounds good to me :)

Carl's back to security for few days - file sandboxes, IP/port masking, 
evaluation limits ...  That sounds good too :-)

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?