World: r3wp

Way shorter:

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

(no local words here)

With DOES being shorthand for a function with no arguments.

I'm out of synch - but  --does  "self" have special meaning or is 
it just a varible name? If so how does it get set to  the name.

No, SELF is as good a word as any other, the above example with DOES 
shows that you don't need a word at all.

Just break it into little steps:

>> test: function [] [error me] [error: disarm try [1 / 0] probe 
error me: error/where print ["My name is" uppercase form me]]
>> test
make object! [
    code: 400
    type: 'math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [1 / 0]
    where: 'test
]
My name is TEST

Now I think I remember -- the error object contains the name of the 
function -- correct?

So to say. It isn't very precise, though. What's happening here is:

In the disarmed error object REBOL tells you where your code breaks; 
it breaks when trying to evaluate the word 'TEST

Yes - the "little steps" reminds me about "where". That nails it

Many many thanks.

In a strict sense, REBOL doesn't tells you the name of the function 
(it can't), it rather tells you where in your code the error occurs. 
The error occurs when you try to evaluate the TEST word.

Not sure where to put this ... so  ...


I am running a number of server processes ... not necessarily listening 
on any ports, though some are.

What's the best way of tracking them all to make sure that they are 
all working?

I guess the processes that aren't listening on a port could touch 
a file

Christian - Appreciate the clarification Works for me!

You're welcome!

Great work, would be a nice alias to add in Rebol.

>> whereof: [get in disarm try [+] 'where]

>> g: f: does [print ["my name is" do whereof]]
>> g
my name is g
>> f
my name is f

>>	I guess the processes that aren't listening on a port could touch 
a file


Likely the easiest way to go, I've always went for that approach, 
Graham. Renaming files afaik is an atomic operation, so you can toggle 
process states between %process-a.running  and %process-a.finished 
or %process-b.failed etc. Not suggesting that there aren't better 
ways ...

obviously, it can't be a mezz

Steeve, please make sure that BrianH doesn't see what you are suggesting 
here ;-) That method is so wrong!

eh why that ? :)

it's rebolish enough for me

Mainly, I was just kidding.

On the other hand, it really is just a dirty hack, not more. The 
main point is, it doesn't provide an answer to the function's "What 
is my name?"-question. Functions have no names.

(If you want BrianH accept it, just let him think he find the trick 
himself)

I'm not argueing that it wouldn't come in handy sometimes ... If 
you know what you do.

(That wasn't nice of you, but LOL)

Brian hopefully can LOL too :)

Don't worry ;-)

There is another aspect of this. Questions on functions names probably 
occur too often to not answer them by a proper language construct. 

I was always thinking that something like a SELF word in functions 
would suffice. A function would then be able to envoke itself, and 
only itself, without worrying about it's "name", whatever that is.

I am no language designer, though, I'm not able to overlook the implications 
that would have.

A SELF word in a function always evaluating to the exact same function 
wouldn't be very different from being a keyword, whilst Rebol claims 
to have no keywords. I don't see a way around this.

re 'self as a keyword: do not worry, Christian, many Rebol dialects 
have keywords, e.g. 'self is already a keyword of the object specification 
dialect, as I see it. Just the Do dialect is promoted to not have 
keywords, alghough the names of infix operators actually are treated 
as keywords in R2, as I noted elsewhere

But, when Rebol evaluates a function / the code in a function's body 
- isn't that the DO dialect at its work? 

An isn't

>> a: func [value] [value]
>> a: func [value] [do [value]]

pretty much the same?

Are you asking why whereof can't be a function ?

as far as I am concerned, I do not understand the people who ask 
for the name of the function - I never needed that, so it may be 
a design problem - they want to do something, that can be done in 
Rebol more elegantly, than they are trying to do it

I'd want it for better error reporting...
  error near append a b
  is not very helpful!
Hoping R3's stack etc functions will help.

but, I can define (easily) a special function specification dialect 
using the word 'self analogically as objects do, if that is of any 
interest

Ladislav, I think I'm with you on that. Asking for name of a function 
makes no sense in REBOL, code that relies on the name of a function 
better be rewritten to get along without.

But the fact that the question always resurfaces points to a where 
the REBOL programming paradigm isn't easy to grasp. The SELF aware 
function I mentioned above is a poorly worded mere thought experiment 
on that to ease the paradigm change, I was *not* suggesting that 
this should be standard behaviour of all functions.

yes, understood, it is OK, I just wanted to note, that you do not 
need to worry whether any specific dialect, like e.g. the function 
body specification dialect, at least for specific functions you define 
in the way that you find useful, uses any keywords you find useful 
for a specific purpose - that is the principle of Rebol dialects: 
do whatever you find useful

Don't worry, I see the humor in it :)

I asked this before .. but what's a good way of monitoring a large 
number of rebol processes on the windows platform?

Some of them are listening to ports, but others are just processing 
queues ...so the former I can open and close a port to them, the 
latter I can not.

And of course I'd like to be able to restart any processes that have 
locked up ...

One thing that I don't like is that if an encapped application dies 
with an error, it stays resident with any file locks active.  Wouldn't 
it be better to have an option to just quit ( writing a log entry 
first ) ?  So, then I can just check to see if the app is running.

can't you have a process to manage others using an udp port for instance 
?

some of these are core apps ...

R2 ?

all r2

and so, you could have a specific process which monitors the others, 
using tcp or udp, no ?