AltME groups: search

Didn't help take you to a web page on www.rebol.com once?

How about a native to create temporary filenames? It's something 
I need quite often.

Yes, I would like that as well.


For a proper solutation that avoids race conditions, it should create 
temporary files, not file_names_, though. So that would probably 
require a temp:// scheme?

using a scheme is a good idea.  then we can add various options to 
how to build them including things like auto naming, manual naming, 
prefixed naming, numbered, and the way it reports if a tmp file already 
exists.

Definitely sounds like a job for an extension.

there are ~450 functions in total. many of them are redundant but 
I guess I will hit ~150. it's more diligent work because it's just 
a thin wrapper.

yes, but this extension will be the foundation of  a nix/serverbased 
rebol.

controlling hardware resources will be very important here. just 
a quick fork, setaffinties, done. (so far in theory) ;-)

btw, andreas any plans for a tokyo/kyoto extension? if so, I could 
strike this from my todo list otherwise I would start after posix. 
(asking just to avoid double work)

After the current build streamlining work, I plan to look into better 
stdio and a more versatile "call" next.

Still should be an extension though, since not everyone is running 
R3 on a server. And definitely if it is limited to server platforms, 
or any platform limits.

Brian, the posix extension is also to refresh my lost C skills (heck, 
I lost half of rebol in only 6 month I was buys with Lua) and I have 
no claim this extension need to run everywhere nor do I want to pollute 
the rebol way. it's just a component to fill some gaps for serverbased 
processing on linux machines.

Is this a bug in R3?

>> mi: #00000002
== #00000002

>> save %mi.txt mi

** Script error: encode does not allow issue! for its data argument
** Where: if save
** Near: if lib/all [
    not header
    any [file? where url? where]...

looks like a bug to me

>> file-type? %mi.txt
== text
>> file-type? %mi.r
== none


Text is considered a file type in R3, like .jpg and such. I think 
it was intentional, though I'm not sure whether we should continue 
to intend this. We should check with Carl.

This does a post

to-string write http://www.rebol.net/cgi-bin/r3-echo.r"trest"

There is a bug here


  if headers/last-modified [info/date: attempt [to date! headers/last-modified]]

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

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

I don't remember if there was a reason for that

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.

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.

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.

That has been discussed too many times. It's a pity you cannot find 
the discussing in some archive...

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?

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.

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

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?

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.

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

IIRC those are from a standard color library.

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
	]

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.

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.

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

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

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

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.

A simple error is still easy:
>> probe make error! "this is an error"
make error! [
    code: 800
    type: 'User
    id: 'message
    arg1: "this is an error"
    arg2: none
    arg3: none
    near: none
    where: none
]

I'm trying to understand network schemes again, after a 3 year gap.

As you can see, there's no error handling yet .. I thought there 
was a field in the scheme object to store errors but I've lost it.

Pavel used a read/lines to format the date in local date format. 
 I replaced that with write options

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

Args (params, whatever) is more specific. read/custom is a bit woolly.

So, is it just a case of adding the /args or whatever refinement 
there?

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

I certainly see a read/args as being quite distinct in purpose from 
write.  I use it with my sandbox scheme (http://reb4.me/r/wrt) to 
filter directory contents.


 read/custom wrt://system/ [thru %.r] ; shows only rebol scripts in 
 this folder
	write wrt://system/ [thru %.r] ; means something else entirely

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

I'm appreciative of a return value from write. For example, on a 
hypothetical Twitter scheme, write twitter:// "My Tweet" would return 
the new tweet id.

Similarly most http write operations return a value of some kind.

A casual user of http, for sure : )

So, if you're reading a HTTP form, you can either use GET or POST 
 ....

Well, I usually use POST to collect a token to allow me to proceed 
on the site

For a developer, the intent is far clearer.

	read/custom http://google.com[q "Gordon Strachan"]

 write http://my-site.com[title "A Blog Post" content "Today I..."]

Adrian, the actors are used to provide a series abstraction on ports. 
 But as developers I think it might be clearer to have specific methods. 
 Otherwise you're reading the options block to see exactly what is 
being done.

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.

An HTTP POST is not a read, for instance, it's more like a write 
because it is supposed to have side effects.

There was a proposal to enhance READ with something like an /options 
or /types option, I can't remember which, but it's not in CureCode. 
It was Carl's idea, but it might be in a blog, chat or another AltME 
world. I only remember it because I was waiting for that feature 
to enhance the clipboard scheme's handling of other datatypes.

/options is better than nowt, but I'd maintain a /params (/args) 
refinement would be beneficial to at least a few different schemes.

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.

World going offline for a while.

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

We just did a codecoverage check with R3 using the test-suite.

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

What is a "codecoverage check"?

I did expect that you like this Lad. Which give a good hint, what 
kind of test-cases are missing.

I estimated 20% (based on a perceiving the C sources to contain a 
high percentage of unused code).

Ladislav, a statement you made in that Google Groups topic contradicts 
most of what you have said on the topic on other occasions:

    On the other hand, nobody doubts that the string "0.1" should suffice 
    to represent the Rebol decimal! 0.1:


That is the problem. The value 0.1 can't be precisely represented 
as an IEEE754 64bit floating point value, it can only be approximated. 
When "nobody doubts" that it can, they are wrong. MOLD not displaying 
the value with sufficient precision to show the actual value is the 
only thing that lets MOLD output a 0.1 at all. When MOLD just uses 
15 digits, it outputs "0.1", which may be what you entered, but not 
what is in memory. What is in memory is 0.10000000000000001, so if 
you have MOLD autoexpand the number of digits it uses then MOLD 0.1 
will output "0.10000000000000001".

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.

This means that any of the three strings can be used as a MOLD result 
that would be considered "accurate enough" by me.

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

For the moment at least we're pretty happy with it as a "collaboration" 
tool

Yes, got a message there saying my browser was not supported and 
I should upgrade my bosses computer.

Same reason I do not develop for Red, because Github does not support 
Snow Leopard any more, and my Mac cannot go further and I do not 
buy a new mac for  github. And the command line I consider too much 
trouble to learn.

Github has a program for Mac for Lion and up

Github p*ssed me off, for when I was on Leopard, there was a program 
for Snow Leopard and I did upgrade then and then demands had been 
pushed up.

Did not know that program, I will give it a try soon. Thank you for 
the link Graham!

downloaded GitX, it works, only a menu atm. have to run now.. cu!

I tried installing a mail program on my Linode, but the repositories 
for the debian I use are now gone. I'll have to perform a complicated 
day-long upgrade procedure to move to a newer Debian. So, you can 
neglect upgrading to a degree that going forward will be much more 
complicated than simply doing incremental upgrades.

Writing the NLPP program, one of the very biggest challenges was 
to make a no-hassle upgrade procedure. This was one of the hardest 
things to do and also one of the parts that took up most time to 
code and test.

Something is wrong in all this.


I try to see software as tiny bits and pieces, each doing a certain 
task. Like very simple Lego building blocks. So each piece takes 
some input (like a function does) and produces an output. If that 
piece needs to be updated, then it's because it has some error, or 
that there is a faster way to do, what it already does. If new building 
blocks arrive, because new software needs them, then they're just 
added to the system.


If that is done right, then updating should be very simple and only 
include very little data to be transfered to my system.

Couldn't such structures just be small files, each taking care of 
a certain part of the configuration?

Following this thought, maybe all the mezzanine functions in %cortex.w 
(in World) should be separate files in a directory? And the shell 
commands should be separate files in a %libs/shell/ directory.


Reminds me, that I should pick up my database again. It has records 
as separate files.

And then implement a system like Erlang, where every piece can be 
hot-swapped.

They are on archive.debian.org, so use a APT source like the following:

deb http://archive.debian.org/debian/$RELEASE main contrib

(Replace $RELEASE with the codename of your Debian version.)

We seem to have a somewhat limited dev pool to start with, and most 
of the people capable and willing to work on R3 are also tied up 
elsewhere (to make a living).

A constructive answer to "when would this be done" would require 
realistic planning based on more than a hypothetical offer.

(That assessment is based on my view that there is quite a bit of 
capacity available which could work full-time on R3.)

Yes, I'm trying to get a handle on "quite a bit capacity available". 
And then attach a pricetag to it to make it happen.