• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

GrahamC
9-Jan-2013
[421x7]
since this is the trace

HEAD /index.html HTTP/1.0
Accept: */*
Accept-Charset: utf-8
Host: www.rebol.com
User-Agent: REBOL

HTTP/1.1 200 OK
Date: Wed, 09 Jan 2013 09:03:18 GMT
Server: Apache
Last-Modified: Sat, 15 Dec 2012 07:02:21 GMT
Accept-Ranges: bytes
Content-Type: text/html
Via: 1.1 BC5-ACLD
Content-Length: 7407
Connection: close
There is a bug here


  if headers/last-modified [info/date: attempt [to date! headers/last-modified]]
>> write http://www.rebol.com/index.html[ HEAD ]
make object! [
    name: none
    size: none
    date: none
    type: 'file
    response-line: "HTTP/1.1 200 OK"
    response-parsed: none
    headers: make object! [
        Content-Length: "7407"
        Transfer-Encoding: none
        Last-Modified: "Sat, 15 Dec 2012 07:02:21 GMT"
        Date: "Wed, 09 Jan 2013 09:24:53 GMT"
        Server: "Apache"
        Accept-Ranges: "bytes"
        Content-Type: "text/html"
        Via: "1.1 BC5-ACLD"
        Connection: "close"
    ]
]
But to-date will not work with "Sat, 15 Dec 2012 07:02:21 GMT" so 
info/date gets set to none
There's likely the same bug in 'query wherever that is defined
digit: charset [ #"0" - #"9" ]
alpha: charset [ #"a" - #"z" #"A" - #"Z" ]
idate-to-date: func [ date [string!] /local day month year zone]
[

 either parse date [ 5 skip copy day 2 digit space copy month 3 alpha 
 space copy year 4 digit space copy time to space space copy zone 
 to end ][
		if zone = "GMT" [ zone: copy "+0" ]
		to date! rejoin [ day "-" month "-" year "/" time zone ]
	][ none ]
]


if headers/last-modified [info/date: attempt [ idate-to-date headers/last-modified] 
]
		
seems to work
Hmm.  Will this fail if your locale is not english, and the web server 
is giving dates in enlish?
Chris
9-Jan-2013
[428]
second load/next/header some-script

^^^^^^^^

In R2, this would get you to the point in a string immediately after 
a Rebol header.  How do you get there in R3? Consider R2:

>> load/next/header "#!/some/path 1foo^/REBOL []^/script here"
== [<header> "^/script here"]
Chris
10-Jan-2013
[429]
Seemingly using 'script? helps locate "REBOL [" then can just 'transcode/next 
on the block.
GrahamC
10-Jan-2013
[430x2]
enlish => English
Gab, it says here that http 1.1 is partially supported http://www.rebol.net/docs/prot-http.html
 but you still pass 1.0
Gabriele
10-Jan-2013
[432]
I don't remember if there was a reason for that
GrahamC
10-Jan-2013
[433]
to pass 1.0 ?
Gabriele
10-Jan-2013
[434x4]
yes.
keep in mind, this was something that i did in a couple days IIRC, 
then waited for over a month for Carl to tell me how to proceed.
not sure if port behavior is better defined now
for example, synchronous operations are just a hack, they fail if 
you try to download a larger file as there is a time limit to the 
whole operation.
GrahamC
10-Jan-2013
[438]
And nearly 6 years ago
Gabriele
10-Jan-2013
[439]
yeah, time flies. :)
GrahamC
10-Jan-2013
[440]
Are you intending to do any more work on R3 now that it's OS?
Gabriele
10-Jan-2013
[441]
not in the short term, i don't really have time for it. no idea what 
happens long term. :)
GrahamC
10-Jan-2013
[442]
And Topaz?
Gabriele
10-Jan-2013
[443]
it's higher priority than R3 for me, but i'm not sure if i'll be 
able to work on it in the next 2-3 months. things should settle after 
that though, and hopefully i'll be able to plan again and carve some 
serious time for it.
Robert
10-Jan-2013
[444]
I can remember that Reb/Service got stuck because of some limitations 
of R3. Not which one it were. So, can we bring R/S back to life? 
Is it worth the effort?
AdrianS
10-Jan-2013
[445]
I don't recall - was there a big difficulty in reporting errors more 
accurately in Rebol? It would be nice to have a line number in a 
script. As it is the context given around the error is often pretty 
vague and doesn't help much.
Ladislav
10-Jan-2013
[446x2]
That has been discussed too many times. It's a pity you cannot find 
the discussing in some archive...
err: "discussion"
GrahamC
10-Jan-2013
[448]
Adrian, all errors occur in line 1.
AdrianS
10-Jan-2013
[449]
I remember some sort of discussion, but I think it was at least a 
couple of years ago on the REBOL3 world - can't log in there any 
longer.

Graham, what do you mean all occur in line 1?
GrahamC
10-Jan-2013
[450]
Joke, most rebol scripts are just a continuous stream of code, lines 
don't have any significance except for legibility
Henrik
10-Jan-2013
[451]
Line numbers don't make any sense. You want a good stack trace instead.
BrianH
10-Jan-2013
[452x3]
Chris, the easiest way to do what you are trying to do is to use 
sys/load-header, which returns a block of the decoded header object, 
the position of the script after the header (after decompressing 
it if need be), and the position after the whole script (useful for 
embedded scripts. If the script is embedded in a block it will decode 
the whole script and return the decoded block at the position after 
the header, but that can't be helped. R3 scripts are binary, not 
text, so the returned script position is binary.

>> sys/load-header "#!/some/path 1foo^/REBOL []^/script here"
== [make object! [
        title: "Untitled"
        name: none
        type: none
        version: none
        date: none
        file: none
        author: none
        needs: none
        options: none
        checksum: none
    ] #{7363726970742068657265} #{}]


>> to-string second sys/load-header "#!/some/path 1foo^/REBOL []^/script 
here"
== "script here"


Note that it will skip past one trailing newline after the header, 
if one exists.
The sys/load-header function is the same function that R3's LOAD, 
DO and IMPORT use to decode headers.
Here's an example of that script-in-a-block embedding I mentioned:


>> sys/load-header "#!/some/path 1foo^/[REBOL []^/script here] other 
stuff"
== [make object! [
        title: "Untitled"
        name: none
        type: none
        version: none
        date: none
        file: none
        author: none
        needs: none
        options: none
        checksum: none
    ] [
        script here
    ] #{206F74686572207374756666}]
Chris
10-Jan-2013
[455]
Thks, that's more like it...
GrahamC
10-Jan-2013
[456]
I asked this a few years ago but where would be a good place to collect 
charsets for reuse in parse rules.  They are defined in protocols 
and duplicated which seems a shame.
Chris
11-Jan-2013
[457]
Certainly there are some common ones -- alpha, numeric, hex, url, 
etc -- that'd at least be as useful to have as predefined colours...
Maxim
11-Jan-2013
[458x2]
why not just build a list and store them as a continuously growing 
setup on rebol.org?
In my dev, I have a central file for all of these.
BrianH
11-Jan-2013
[460]
Why not just make it a module that anyone can import?
Chris
11-Jan-2013
[461]
What makes predefined bitsets different from predefined colours? 
Wouldn't the case use for 'digit and 'alpha be more common than 'red, 
'green and 'blue? Or should colours move to a separate module too?
BrianH
11-Jan-2013
[462]
Predefined colors don't take a lot of memory because they're immediate 
values. Bitsets are much larger, so you don't necessarily want them 
hanging around if you don't need them. As for why they should be 
in a module, all community-provided code should go in modules. Maybe 
the colors should go in a module too.
Gregg
11-Jan-2013
[463]
http://www.rebol.org/view-script.r?script=common-parse-values.r


I think having some predefined would be great. No doubt we all have 
our own, and just having standard names for them would help.
GrahamC
11-Jan-2013
[464x3]
So, where to put them?
Module?
I'm forever defining digit, digits, alpha etc
Gregg
11-Jan-2013
[467]
Me too, Graham.


Why would we *not* want to put them in %base-constants.r, or a new 
%base-charsets.r? Colors are in %mezz-colors.r, and I would certainly 
vote to remove a number of those. Pretty sure I've never used 'papaya. 
:-)
GrahamC
11-Jan-2013
[468]
I use about 4 colours
Maxim
11-Jan-2013
[469]
IIRC those are from a standard color library.
Gregg
11-Jan-2013
[470]
That would make sense then Max, though it would be interesting to 
see how many of them are ever used.