World: r3wp

well, that'll do too :-)

there is a trick to get the function name, if you don't mind the 
overhead.

>> f: has [err] [err: disarm try [1 / 0] print ["My name is" err/where]]
>> f
My name is f

I was using this in a profiler I did which just replaced FUNC and 
did something like Henrik wants above. It did however create problems 
with more complex REBOL scripts, eg. it made the PDF Maker 2 blow 
up. I never spent the time to figure out why.

it's probably better to not try to find the name during runtime, 
but simply create the debug-func function as above. With that in 
mind, it's necessary to ask how pervasive this functionality has 
to be. I don't mind that it's only useful for 'func.

Of note, as it may not be clear from the above, it's not the error 
trick that created problem, but the replacement of FUNC with my own 
profiling and stack tracking version.

it may be safer if you use a different name though. i don't think 
i was supporting catch and throw though.

yes, agree

this is what i was doing:

func*: func [
    "Defines a user function with given spec and body."
    [catch]

    spec [block!] {Help string (opt) followed by arg words (and opt type 
    and string)}
    body [block!] "The body block of the function"

    /local f
] [
    throw-on-error [
        use [*temp*] [
            f: make function! spec compose/only/deep [
                in-func *temp*: do this-function-name
                out-func *temp* (body)
            ]
            body: second :f
            body/7: make function! [] body/7
            :f
        ]
    ]
]

this-function-name: [get in disarm try [1 / 0] 'where]

with in-func: func [name] [...] and out-func: func [name return-value 
[any-type!]] [... get/any 'return-value]

Ladislav's TFUNC probably handles more cases. The problem is however 
making it "transparent" enough which is a bit tricky, especially 
since you need to catch return and exit so i think you can't avoid 
having a sub function.

if I'm being consistent, wouldn't it be enough to simply scan for 
RETURN and EXIT words?

it limits flexibility of what I can do in a function, I know.

That this-function-name is kinda cool, but a trick with an overhead. 
Would it be an idea, if we could get the function name with self/name 
or something like that?

I just hit the following issue (2.7.6 on Windows XP SP3 and Linux 
Libc6, same in 2.7.7) :
>> wait [596:0:0]
(escape)
>> wait [597:0:0]
== none


It seems that 597 hours is the maximum accepted by WAIT (Why the 
hell this kind of information is not in the online documentation 
of WAIT native?)

Will this issue be fixed if reported to RAMBO? Very doubtful.
Should REBOL be open-sourced? Yes.

I don't think you should report it to RAMBO. Keep it predictably 
unfixed and undocumented forever.

This issue is making my scheduler lib useless for general purpose 
usage (won't work for jobs scheduled in more than 24 days). As usual, 
stuck at 99% of the goal...

post it to RAMBO and I'll flag Carl on R3 chat

Henrik: how many native bugs have been fixed in R2 from RAMBO reports 
since 2 years? There's currently 959 open tickets in RAMBO, how much 
of the reported issues and bugs will ever be fixed?

Fine, don't report it. Then you can be absolutely sure it will never 
be fixed.

Doc, how many R2 releases have happened in 2 years? One, and it wasn't 
a bug-fix release. But more releases are coming, and more often. 
So report stuff in RAMBO - it will do until we get those tickets 
migrated to CureCode.

Dockimbel, couldn't you split longer jobs into multiple shorter waits?

Just wrap the wait in a loop  ;-)

Huh? Code should never WAIT that long.... Bad coding practice because 
time-of-day and timers are not always in-sync.  Wake up at least 
once an hour, and check NOW/precise, then recompute.  I suppose this 
could be a mezz.

The docs need to add that WAIT is a low level function, intended 
mainly for port event timing, not for TOD cron style timing.

Cyphre: yes, that was one of the options I've considered at the beginning, 
but when I saw that I could have timers working for more than 24 
hours, I've choosed the long waiting timer way, because it was much 
simplier to implement and looked more reliable.

Docs are the key. If you can go up to almost 600 hours, why does 
it stop there, at what seems like an arbitrary value?

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.