World: r4wp

Joke, most rebol scripts are just a continuous stream of code, lines 
don't have any significance except for legibility

Line numbers don't make any sense. You want a good stack trace instead.

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}]

Thks, that's more like it...

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.

Certainly there are some common ones -- alpha, numeric, hex, url, 
etc -- that'd at least be as useful to have as predefined colours...

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.

Why not just make it a module that anyone can import?

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?

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.

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.

So, where to put them?

Module?

I'm forever defining digit, digits, alpha etc

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. 
:-)

I use about 4 colours

IIRC those are from a standard color library.

That would make sense then Max, though it would be interesting to 
see how many of them are ever used.

Were they chosen for html use?

Is this the best way to perform this check in http://www.rebol.com/r3/demo.r:

errout case [

 not value? 'size-text ["This R3 release does not provide a graphics 
 system."] ; this one
	load-gui <> 0.2.1 ["Wrong GUI version for this test script."]
	true [none]
]

http://www.curecode.org/rebol3/ticket.rsp?id=1918&cursor=1

a htt error doesn't appear to reset the port or something.

A second read after the error doesn't actually do anything but uses 
a cached copy of the error's headers etc

A further read corrects the error in the port

parse-url in R2 gives us a target, but sys/*parse-url/decode-url 
doesn't

How about adding that in eg.


 decode-url: func ["Decode a URL according to rules of sys/*parse-url." 
 url] [
		--- "This function is bound in the context of sys/*parse-url."
		out: make block! 8
		parse/all url rules
		emit target last split-path url
		out
	]

in https://github.com/rebol/r3/blob/master/src/mezz/sys-ports.r

http://www.rebol.net/wiki/Ports:_Synchronous_and_Asynchronous_Operations

Is this example supposed to work still?

 port: make port! http://www.rebol.com
   port/awake: func [event] [
       switch event/type [
           connect ready [
               write event/port [get %/]
           ]
           done [
               result: copy event/port
               return true
           ]
       ]
       false
   ]
   open port
   wait port

Return true in the 'done block does not exit the event loop

Since I didn't get any response, next try: What do you think about 
re-activating Rebol/Service?

if there is no license issue why not use zmq or another mature transport/protocol 
layer?. R/S was not bad but to instable for real apps. 

Of course this will raise the old question what should be mezz, what 
native etc. but adding some 100kb to the source for well proven
components shouldn't hurt too much.

with an additional lightweight scheme for user/authentication on 
the rebol site and the zmq workhorse lives on the C side, with all 
it's advantages (speed/thread).

For me the value was not the transport layer but the integration 
and the structure of the messaing, service look up etc.


IMO we shouldn't use a HTTP only transport layer for R/S and this 
layer shouldn't be done on the mezz level.

Robert - do you mean IOS? I still think, that it was kind of superior, 
although it lacked cross-reblet API. Can you see all those Google 
drives, SkyDrives? Cross device, cross user file syncing could be 
done agas ago with IOS (/Services), if RT would have some product 
manager. Pity for lost oportunity. I still think, that something 
like IOS kernel/layer could or even should be used for OpenME ...

Pekr: http://www.rebol.com/docs/services/

ah, those services. I wrote some doc about what do I don't like about 
them (naming conventions, other design issues (from my pov)), and 
Carl told me, that he is going to completly overhaul them once GUI 
is finished. That never happened though ....

Just wondering why I can't even get the old daytime protocol working 
from 3 years ago.

don't want o open this bottle now but another construction zone are 
the codecs like jpeg or zlib. at quick overview shows them very outdated. 
zlib e.g. from 1998 but don't know if carl has 

updated at least critical bugs. this has to be checked, the changelog 
is quite heavy until current. I like the Lua way here. the creators 
just take care about the real core, nothing else but 

this at a very agil and serious level, one reason the core is rock 
solid and very portable. the disadvantage of course is lack of a 
standard lib and a kind of wild growing but I guess this is
the price you have to pay for open source.

I would love to see rebol/services and asynchronous R3 tools as well.

I didn't use R/S except for testing/playing but I like to see it 
working. But I think we have other priorities like GUI, Android etc., 
R3 itself..

I once used it and even the existing version works quite well. It's 
very simple to use and straight forward. That's what I like about 
its design.

Well, my gripes were with the architecture a bit - all those functions 
with replicated names - do-servise, open-service, close-service. 
IIRC, old IOS used rsp-* functions, it was easy to list in help, 
and it used even rsp:// port scheme IIRC. Other thing I did not like 
much was, that the code seems to be plain pure parse code, but surely 
if the need is there, it could be abstracted. Carl admitted, that 
he would somehow change the design, no specific things I remember 
about his thoughts though ...

OTOH - I alway liked Rugby - dunno why. So some rpc mechanism might 
be welcomed. If R/S really worked, why not to use it?

IIRC some ppl reported some hangs in regards to R/S. Difficult to 
say, if ti was problematic R/S code itself, or some internal R3 networking 
bugs, which might disapper in later releases?

Does one have already explore the possibility to us SDL as a Rebol 
interface to OS graphic/sound/event interface ?

It seems there as many OSs supported now. Android, BSDs, Linuxes, 
OSX, Win32...

The DLL is only 132KB on Win32. Dunno an other platform!?

us=use

as=are