AltME groups: search

And Topaz?

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.

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.

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.

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.

why not just build a list and store them as a continuously growing 
setup on rebol.org?

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?

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.

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

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

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.

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

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

I create little Rebol/Services from time to time.  Would be nice 
to have a spec that makes it quick and easy.

SDL: I just tried an app using it with OSX. That's not really end-user 
friendly. Needs to be totally self-contained. No config etc. just 
download and start.

I still have some rebol services stuff in production, and always 
had high hopes for it. And while I would like a self-contained, dialected 
model, I also want to be able to easily use 0MQ as a transport and 
REST interfaces to map over services.

I've updated the time scheme and uploaded it to github here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-time.r

Well, currently 'read doesn't have a custom refinement.  But I guess 
that can be added and then we can use that.

Should get some concensus on this as it will affect all the schemes, 
and may need a little rewriting of the http scheme which uses write 
to pass options

On the http scheme, it could be the difference between adding a query 
string to a GET request (read/custom), and adding post data on a 
POST/PUT request (write).

and HEAD ?

the thing is that GET sends information and gets something back. 
 Same as POST.  What's the difference?

Not at all. Particularly if you consider the HTML form -- GET sends 
parameters in the URL, POST sends parameters in the body. And consider 
the usage of each: GET is usually some type of search/filter facility, 
POST is sending data to be stored.

It would be simpler if we just used 

GET and POST instead of read/write

Graham, HTTP GET is supposed to be repeatable without side effects, 
and thus safe to cache. HTTP POST is supposed to generate side effects, 
and thus not be safe to cache.

You have to see it in terms of the whole model. READ and WRITE don't 
just operate on HTTP and files, they can operate on a wide variety 
of port types.

Looked in chat #1097 (the area where standard options were discussed) 
and we haven't brought it up there yet, but Carl did a blog about 
it.

Change the signature of query to always include a mode field: QUERY 
target mode, then you could "default" read actions with READ, read 
actions with options with QUERY and the options as second parameter, 
write actions with options with WRITE.

mezz/boot-files.r ... add protocols here and they get included into 
the binary.
I managed to add a new scheme to the binary this way

So, Andreas and I tipped a priori. So, what's your tip?

17 digits aren't sufficient to represent the difference between 0.10000000000000001 
and 0.1000000000000000055511151231257827021181583404541015625, so 
if you say that the real IEEE754 value is 0.1000000000000000055511151231257827021181583404541015625 
then you can't show that difference in 17 digits.

You are ignoring the definitions:


1) there is the IEEE 754 "definition" specifying which number corresponds 
to 0.1 - I know (using my Rebol script), that it actually is the 
number 0.1000000000000000055511151231257827021181583404541015625

2) there is my definition specifying which strings "accurately enough" 
represents the IEEE 754 number 0.1000000000000000055511151231257827021181583404541015625. 
According to my definition (you can find it defined as a Rebol function 
in the ML) all of "0.1", "0.10000000000000001" and "0.1000000000000000055511151231257827021181583404541015625" 
"accurately enough" represent the number.

Why are you trying to push this change into MOLD without /all?

 - aha, this may be a misunderstanding. I am not that far yet. What 
 I said was that it was possible to define which string may be considered 
 "accurate enough" when representing a given Rebol value VALUE. There 
 may be more than one such string. Now it is interesting that neither 
 MOLD nor MOLD/ALL needs a longer string than the one that is already 
 "accurate enough". Thus, it might make sense to just use the shortest 
 "accurate enough" string (which may have even less than 15 digits) 
 for both MOLD and MOLD/ALL..

I can probe system/schemes/tls and /https

Graham, the TLS protocol scheme works transparently on tcp ports. 
So you just need to change the port/scheme from 'tcp to 'tls and 
you have the tcp connection secured. Then you can build any higher-level 
protocol over it. Having made the TLS scheme transparent I needed 
to make only few minor changes to the Gabriele's HTTP scheme to be 
able support HTTPS as well.

And are you going to implement SHA256 ?

I simply wrote the TLS scheme :-) I've also added the neccessary 
crypto algorithms at the native level (only RSA with ARC4 cipher 
suite is supported at the moment).

IMO this solution gives us much better flexibility: the encryption 
code is native(fast) and the TLS protocol logic is in REBOL so it 
is possibel to enhance it much more easily.

(so for example we can later implement also the certificate handling 
and TLS server mode)

so has to be compatible license and in plain C ?

I have AES algo prepared for integration. Currently we are looking 
for good implementations of: SHA256, DH and 3DES

compatible are GPL, MIT and Apache?

BTW getting the TLS/HTTPS to run on Android proves that our solution 
is good and can be easily used in crossplatform way. No need for 
any OpenSSL-like bloat anymore in R3 ;)

I haven't searched for SHA256 yet so that is possible. I'm now looking 
more for the DH and 3DES...

http://www.codeguru.com/cpp/misc/misc/cryptoapi/article.php/c8195/Portable-Cryptography-API-for-Triple-DES.htm

C and C++ implementations

The time protocol mentioned in Vanity seems to need a change in design. 
There should never be a need for READ to have an /args option - that 
is what the path and query stuff are for.

Instead of this:
    read/args time://time.nist.gov [ GMT ]
it should be this:
    read time://time.nist.gov/gmt

`There should never be a need for READ to have an /args option - 
that is what the path and query stuff are for`


That's obviously problematic for systems which already make use of 
URLs including path and query components.

Are you talking about HTTP, the only scheme that has query and paths 
built into the URL spec standard? Because we have WRITE for that 
situation. For other schemes, we can define our own meaning of the 
query (and in some cases path) so we don't break the model.

I think you mentioned above that write should be used for non idempotent 
actions and read for the idempotent ones.

There are more port actions than just WRITE and READ. Don't limit 
yourself to just those two. Most of the metadata operations for HTTP-like 
schemes are handled by QUERY.

And the mode, and it can take a url! or block spec. But there are 
other url! and port! actions than just those 3.

There's a lot we can tell about the intended design by looking at 
the actions and their options. The actions were pared down deliberately, 
lowering overhead and getting rid of unnecessary options. Any action 
that can operate on a port is pert of the interface of ports, and 
the same goes for URLs. Plus, we have Carl's blogs and docs on the 
subject.

And we have people who discussed the design with Carl.

Again, I think that adapting QUERY would be a nice alternative to 
READ/custom and give us a neutrally sounding general action.

Andreas, QUERY already takes a parameter, but it's optional. QUERY/mode 
retrieves a particular bit of information, and QUERY without /mode 
returns an object full of standard bits of information.

Andreas, QUERY already takes a parameter, but it's optional.

Yes, and I propose to change that.

Where READ/args wins for me is that instead of, for example, composing 
a custom query string for HTTP -- you don't have to worry about that 
conversion. It's encoded and appended for you as defined by the port.

I'd have to review the code, the main problem with errors is that, 
again, port behavior is really not defined explicitly for that, and 
Carl never answered.

ah, you're right, then there must be something that is global and 
should not be.

Anyone happens to know who we have as admins of the R3 project CureCode?
 Carl, BrianH and me.

what's the intended meaning of the 

reviewed" status for R3 CC tickets?" It means that the ticket has 
been acknowledged/accepted and will be processed. At least, that 
was the initial meaning, maybe Carl and Brian used it differently 
afterward.

Who decides an issue is closed?

 Depends on the convention set for R3 project. I usually consider 
 that it should be closed by the developer processing it, once the 
 issue is fixed. It could also be closed by the one that opened it 
 if he's satisfied by the provided answer or the fix.

Who can re-open issues?

 Admin can, Developer should too. Currently in addition to admins, 
 there are 3 people with Developer roles/rights: Henrik, Cyphre and 
 Gabriele.

Pekr, my schemes are still available on github.  They are all async 
and need to be rewritten as sync.
to get them to work you need to make the following changes:

1. In the header, change from 

module: 'name 

to 

type: 'module
name: 'name

make-scheme => sys/make-scheme


There's also some odd about contexts inside modules.  You need to 
declare your variables inside /local as you can get a context error 
if they are used but not so defined.

Yes. Actually, there's a pull request that represents the current 
intended design of the module system ( https://github.com/rebol/r3/pull/40
). And I'm working on a set of tests that should help document it 
as well.

The module system was almost complete in implementation with the 
last closed-source release, needing only the fixes we (and I mean 
me and you, Andreas) did in the first week of the open source release. 
We have only been waiting for Carl to add that pull request to get 
the current design working as intended, though that request doesn't 
only apply to modules in particular, but to scripts in general. Once 
it is accepted, I need to do another round of optimization, but the 
external effects are set already.

So we are at the stage of writing docs and tests.

The only reason the user-level docs aren't yet written is because 
I am really bad at writing user-level docs of any kind. I was hoping 
that I could write some guru-level docs and then let someone read 
them and write something user-level.

As for that blog, the behavior described there has some practical 
problems. There is nothing in the code itself (I mean the example 
code in the blog, not the implementation code) to indicate that 'last-stock 
is a free variable, but 'if and 'not are not - they are all words 
not declared at the top level of the module (by using them as set-words, 
like in an object) or elsewhere in the code. This means that if you 
want it to have 'last-stock be made local to a module, you would 
have to make 'if and 'not local as well. That works if lib words 
can only be set once, but not if they can be reset, since changes 
wouldn't propagate to the other modules or user scripts (since those 
values are copied to words in other contexts).


We determined that the behavior described in that blog could be useful 
enough to be worth supporting, but had some nasty side effects that 
made it not be what we wanted to do by default. That is why we made 
it an option, in particular the isolate option. If you specify the 
isolate option, your module acts like it does in the blog, and this 
has the effect of isolating your module from all external changes 
to the lib context.

There is also a content option (it acts like content: true from R2), 
and a compress option (for scripts that are stored compressed, and 
automatically decompress on load).

The content and compress options don't require type: module - they 
work on regular scripts too.

Scripts can also be checked against checksums, and can be limited 
to a length, but those aren't flags so they need their own header 
words.

Btw, "Reviewed" has generally meant that someone has gone over the 
ticket and not immediately found a good reason to dismiss it, and 
that we haven't found a problem yet. It is not an indication that 
the ticket should be implemented - we frequently have competing contradictory 
tickets. So it sometimes means that more debate is needed before 
we can accept or reject it. On the other hand, it sometimes means 
that we haven't gotten around to it yet. Nonetheless, some reviewed 
tickets will eventually be rejected. Carl and I were the reviewers 
for the most part, except in the case of bugs that needed some domain-specific 
knowledge, like the math bugs we referred to Ladislav.

In general, when there are competing proposals and we finally pick 
and implement one, we dismiss the competing ones, even if they were 
"reviewed" before.

Basically, "reviewed" with a consensus. No specific marker. We need 
to have the people who are familiar with the arguments go through 
the tickets that aren't still under debate and implement them.

Just that I had a proposal which was accepted and marked as built 
and then you reviewed and found it wasn't built

We might want to rethink that now that Carl and I aren't the only 
ones implementing things :)

I haven't had a chance to go over the remaining tickets yet. And 
there are some that weren't implemented yet because Carl didn't want 
to, but hadn't yet convinced the rest of us as to why. Those might 
be dismissed if we get a good argument against them, which we can 
do in some cases ourselves now that we can see the native source.

And we need to go through the old previously implemented but now 
invalid tickets, to mark them as such so we don't have bad tests 
added for them.

For some of the early tickets, more thought and experience caused 
us to change our minds later on.

Graham, was that proposal state change recent? Was it changed to 
"pending"? We've had a bit of a definitional problem with the "built" 
state lately. Until we actually get official builds, with version 
numbers, we don't really have a defined "built" state. We need a 
state for "implemented and accepted as a pull request into Carl's 
repo, but not in an official build yet", but we've just been callung 
that "pending" for short.

I updated

http://www.rebol.net/wiki/Decimals-64


to reflect the current state of knowledge about molding and loading

And then we can use "pending" for waiting to be accepted.

It wouldn't take much :) And there might be miore tickets that should 
be in that state than are currently marked as such.

For tickets with implementations that have been accepted into Carl's 
r3 master branch, mark the ticket with a Status of "built" and a 
Fixed in of "r3 master".

That error is exactly the same one that would be returned if there 
were no /next refinement. The print is only there to help people 
with the transition. If we don't feel that is necessary anymore, 
we should remove the /next option altogether and that entire code 
segment as well.

A poll question:


-  I am adjusting Rebol core-tests suite and doing MOLD and MOLD/ALL 
tests for decimals. There is one case I want to mention separately. 
At present it seems that for almost every decimal X the expression

same? x load mold/all x


yields true. The only exception being the "negative zero" case, because 
MOLD currently yields "0.0" when molding "negative zero".

What are your preferences in this respect?

I would prefer MOLD/all -0.0 to generate "-0.0". As for MOLD, I'm 
on the fence: If the difference between 0.0 and -0.0 is significant 
enough semantically, but not too confusing to the regular programmers 
that MOLD is targeted at, then why not? We definitely don't want 
MOLD and MOLD/all to be the same though, because there are too many 
developers that want to keep the illusion that 0.1 exists. Having 
a display setting to have the interactive console print values with 
MOLD/all instead of MOLD makes sense though.

Right, because they print approximate values. If your proposal is 
to change MOLD to generate the smallest value that, while not actually 
being the value in memory, would generate that value in memory as 
a result of the loader trying to approximate what you wrote, then 
I might be OK with that if it can be done efficiently. If it can't 
be done efficiently, I'm OK with doing what all of the other non-scientific 
languages do and just use 15 digits.

R2 says 0.0 and -0.0 are the same, but R3 does not. I replied to 
Lad's googlegroup post that I would prefer "0.0", as evaluating -0.0 
returns 0.0. So, they are equal but not the same under R3. What would 
be a scenario where you would want to maintain the sign?

R2 says 0.0 and -0.0 are the same

 - actually, in R2 it is possible to devise a test which would discern 
 -0.0 and 0.0, although SAME? can't discern them

It is possible to prove that Rebol identity does not depend on the 
SAME? function at all, in fact, and unsetting 'same? I obtain the 
same identity as when the SAME? function is defined.

This actually demonstrates that there may be some level of "arbitrariness" 
in the implementation of the SAME? function, but if the SAME? function 
is arbitrary and differs from the IDENTICAL? function then we are 
able to prove that it is arbitrary and it is not the natural identity 
existing in Rebol regardless of the SAME? function.

The problem with writing a prot-send.r is that we have no guidance 
yet on where user variables such as name, email and passwords are 
to be stored.

Graham, put the settings in a structure that is local to the prot-send.r 
module and managed by it. Non-private module contexts are global.

I apologize if this kind of thing seems complicated, but a lot of 
the module system happened as side effects of the original design. 
Carl's original module proposal was high-level and not actually implemented, 
so there were some implications that he didn't really know about 
at first. Once we worked through the details, we ended up with a 
more flexible module system than he originally specified (that was 
the first rewrite). Then we changed the interface and usage to make 
it simpler and make the code more maintainable (rewrite two), then 
refined it based on the new model and added many new ways to make 
it even simpler to use, and some new features Carl and others wanted 
(rewrite 3). So I hope that you'll bear with me for a moment.

Regular

 modules have names and versions so they can be loaded only once, 
 and upgraded in place if need be. As a side effect, this makes the 
 module's context effectively global. We have a few built-in global 
 contexts, but we don't necessarily have to make built-in global contexts 
 for stuff that is managed by modules because the module contexts 
 are themselves global.