World: r3wp

I imagine we do a lot of things in REBOL that we shouldn't do, because 
nobody told us not to. :-)

Carl: code (I guess you meant "application") is not waiting, this 
is the minimal code that shows the issue, in the real application, 
there's a lot of other ports (mostly network, but can be input devices 
too) in the event loop. I use a timer value to trigger CRON-like 
deferred actions for a few seconds or several days. About time-of-day 
and timers sync issue, I use online sync services to keep the local 
machine time-of-day right. Stopping a few times per day to resync 
crossed my mind but it looked overkill after a few tests. Now knowing 
the limitations, I need to rewrite my code.

Gregg: exactly. I was expecting a 24 hours limit, not that weird 
597...so I went the wrong way. I expect docs to tell me the technical 
limitations if there are any. That's one of the advantages of having 
the sources of your tools, you can just check the sources to see 
or infer the limitations and the pros/cons of your higher level choices.

>> wait 596:31:24
== none
>> wait 596:31:23
(escape)
>> to-integer 596:31:23
== 2147483


...This number looks extremely familiar, but I can't place it.  Google 
searches bring up bugs involving it in other languages, too, but 
that's it at first glance

Gotcha:  32-bit integer limits are -2,147,483,648 to +2,147,483,647

Got an overflow, this waits for 1 second:
>> wait (596:31 * 2) + 0:00:48

Well then that limit seems reasonable, if a little generous. Let's 
declare it a feature :)

In other words, the limit is 2'147'483'647 milliseconds.

Is RAMBO still monitored for R2-related bugs?

Well, seems like it is ...

I make sure every day that spam is removed and actual tickets are 
committed. Other than that, I don't know.

it doesn't matter if it's monitored now, as long as bugs are cataloged 
and documented.

Not processing user's reports on your product is a good way to not 
build a community of users. If users care to spend their (valuable) 
time in reporting issues or defects, maybe RT can also spend some 
time in fixing them  (at least those native ones). But maybe I'm 
the only one interested in R2 bug fixing...

Nope. But those bugs only get fixed in releases.

And you have said that you will help process the RAMBO tickets when 
the time comes, by assisting with migrating them to CureCode where 
they can be dealt with.

I expect that there will be a new R2 release relatively soon, but 
we can't schedule it yet due to external circumstances that affect 
the people working on it. That doesn't mean that work on it has stopped 
or should stop, and it doesn't mean that you should give up on reporting 
bugs. Please use RAMBO until we can retire it - the tickets should 
be there when we need them.

Reporting the wait bug documents it, even if it gets fixed or not, 
so other users can (as I do) browse through RAMBO to either confirm 
the bug or to see if someone offers a fix or a workaround. It would 
be a problem if RAMBO was a closed system where you could not freely 
study the reports, but you can, and Curecode is the same. Do people 
not ever take notes, when stumbling onto something unusual?

Brian: no problem for assisting in migrating RAMBO to CC, even if 
the tool is not the main issue IMO.

Right, the tool is not the (only) issue. The big issue is that since 
there isn't a schedule for when the next release of R2 will be due 
to outside considerations, people think that the bugs are being ignored, 
the release isn't coming soon and noone is working on it. None of 
those are true, so it's a perceptual problem. In the meanwhile, we 
continue to work on a new R2 as time permits, no worries.

And same applies for reporting spam on the blog comments ... no point 
in reporting it if it does not get removed.

Has anyone researched the minimum operating system environment required 
to run rebol? I think that was one of the goals of Rebol 3 at one 
point.

Does anyone know an implementation of the Fletcher checksum algorithm 
in REBOL or does REBOL 2 do this?

I checked Henrik, since it sounded familiar, but I don't have a REBOL 
version.

Anyone had/has any need / desire to make a Rebol to RServe (R - the 
statistics language) library / protocol?

I am not an R user, but I think of interest to offer such links between 
languages : I have done a simple Matlab extension for Rebol and if 
I find enough time, I will do also a Python extension

I have done several searches but haven't found what I'm looking for. 
I've looked at binding discussions until I went cross-eyed. Not a 
complaint, just an explanation of why I am consulting the "biological 
repository". I want to build a function that can access its own name, 
so I can assign it to a name and then just invoke that name to activate 
functionality using the name . The simplest example is -- name [] 
[......print name]. I would rather not use an object but will if 
necessary. My apologies if everyone else knows how to do this.

Jim, bad news first: By design functions in REBOL have no name. In 
REBOL, Functions are first class values which /may/ be referenced 
by one word, by more than one word or by no word at all

E.g.:

>> calc: reduce [func [v] [v / 2] func [v] [v * 2] func [v] [v * 
3]]
== [func [v][v / 2] func [v][v * 2] func [v][v * 3]]

>> do reduce [first calc second calc third calc 1]
== 3

>> set [half double triple] calc
== [func [v][v / 2] func [v][v * 2] func [v][v * 3]]

>> half double triple 1
== 3

>> set [a b c] first calc

Thanks Christian Is there any good news?

The functions in the CALC block have no names at all. But you can 
assign them to words, as is done later on. You can assign one function 
to different words. What's the name of the first function in CALC, 
is it 1) HALF, is it 2) A, is it 3) B or is it 4) C ? There is virtually 
no way for REBOL to decide that.

Good news there are.

There are implementation details which may be used (as in: may be 
"hacked") to get the desired effect. Just give me a moment to dig 
for the answer to your question

>> test: func [/local self] [self: get in disarm self: try [1 / 0] 
'where print ["My name is" uppercase form self]]
>> test
My name is TEST

Oops

>> test: func [/local self] [self: get in disarm try [1 / 0] 'where 
print ["My name is" uppercase form self]]
>> test
My name is TEST

But be carefull

>> again: :test
>> again
My name is AGAIN

The exact same function may return another name if assigned to another 
word.

Or it may return no name at all:

>> do reduce [:test]
My name is NONE

nice trick

Credit where credit belongs, that trick is courtesy of Gabriele.

Who was the first to come up with this trick iirc.

I probably didn't explain it well -- that's the behavior I want! 
Including the NONE.


Clever - I understand about creating an error object.  ... I could 
look look it up, but can you give me a quick explanation of  "/local" 
- sounds very interesting.

All words after the /LOCAL refinement are words local to the function, 
all words preceeding /LOCAL are function arguments

>> additon: func [one two /local three] [three: one + two] 
>> addition 1 2
== 3

The above can be written as

>> test: function [] [self] [self: get in disarm try [1 / 0] 'where 
print ["My name is" uppercase form self]]
>> test
My name is TEST

(a function with no arguments and one local word SELF)