World: r3wp

Someone might argue, that if conditional functions can operate on 
almost any value, then those values would be either true or false. 
Does it makes sense, that such values are neither true or false?

That is why TRUE? is there, to convert the truth value of something 
to a logic value.

>> "hey" = true
== false
>> "hey" = false
== false
>> if "hey" [print {"hey" is true}]
hey
 is true

It does make sense to have conditionals work on more than just logic 
values. Whether or not to do so is arbitrary, and many languages 
do so (mostly the Lisp-derived languages). It's one of the two main 
models.

The Pascal-derived languages only use logic (or boolean) values. 
The assembly-derived ones use 0 and non-0. Others are weirder.

The Icon-derived ones use success and failure - those are weird, 
but useful.

Can rebol save program state as an image?

no.

R2 challenge:


Implement a debug-function that uses a call-stack. I made this context:

context [
	action-level: 0
	func-name: make block! []

 set 'hint func [str] [reform [action-level: action-level + 1 ":" 
 str]]

 set 'doing func [name] [print hint join "Doing " last append func-name 
 name]

 set 'done does [print join "Done with " first name: back tail func-name 
 remove name action-level: action-level - 1]
	set 'last-hint does [print mold func-name]
]

And I use it like this:

my-func: func [] [
	doing 'my-func
	...stuff...
	done
]


What would it take to build a function that does this automatically, 
like:

my-func: debug-func [] [
	... stuff ...
]


and also automatically catches all exits, returns and throws and 
allows the function to return a value?

As this is built into R3, this is only for R2.

debug-func: function [name spec body] [b] [b: copy body insert b 
compose [doing (name)] append b [done] tfunc spec b]

ah, that was premature :)

reminder to self: should not draft code in the altme message area 
:)

well, it's a start. keep going :-)

but ladislav's tfunc should help with most of the tough issues :)

I'm not sure it's entirely simple. I would like it to work with the 
above context. The point is also that when you don't want debugging 
to work, you can insert a line:

debug-func: :func

I've not studied that one....

if you want to pass the name to doing, you'll have pass the name 
to debug-func as well, i fear.

then I guess I can't entirely do a debug-func: :func.


that's OK as long as there will be a method to not produce much overhead 
for production code.

debug-func: func [name spec body] [make function! spec body] should 
be fine, or something similar

yes, then manipulate the body to contain DOING and DONE at the right 
spots.

i meant for the disabling case, now :)

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?