World: r3wp

yes ...

under Windows, if you open file in one process, another one can't 
delete it. Easy enough. Prevents the case, where process does not 
remove the lock, but crashes. Then you would be in locked situation. 
But if app crashes, you can remove the log. Under linux, dunno how 
to do it. One chance is e.g. the need for process to update timestamp, 
and if timestamp is not updated, then app most probably crashed, 
so you can start another instance ...

open a listen port, there can only one be open

sqlab ... yes, but requires firewall approval ...

maybe you can use rename in the same way I used it to implement simple 
locking just before in DB Chat channel

One way:

On startup:
-- check for your timestamp file

-- If it does not exist or  (it exists and timestamp is over 2 minutes 
in past), proceed to run

-- otherwise, wait 65 seconds.  Test if timestamp has changed: yes-halt; 
no-proceed

While running:

-- write the  timestamp file at least once a minute with an updated 
time

On clean closedown:
-- delete the timestamp file.

Drawbacks:

-- application could take over a minute to restart if immediately 
restarted after a crash.

-- manual deletion of timestamp file can lead to multiple instances 
running (you can minimise this by re-reading file and aborting if 
timestamp is not the last one you set)
-- all those writes of the file.

Sunanda,  does your timestamp file mean a file with the timestamp 
as content or just the date and time of the file?

I have many times seen, that the timestamp of a file under windows 
does not change, although there is always data added to the file.

You can use set-modes to update the timestamp

sqlab -- I mean a file whose contents is just a timestamp, eg:
  write %timestamp.txt mod now/precise

In practice, the actual method is a little more convoluted (to avoid, 
for example, two instances both starting at once -- so neither sees 
a pre-existing timestamp.txt file).

I need to issue the combination ALT+RETURN into a string. How can 
I do this? Is there a control character for ALT like for CTRL?

AFAIK, due to multi-platform issues and various platforms not supporting 
it the ALT-key has never been utilized for the view event engine, 
hence it's probably not possible to detect the ALT-key. There's no 
/ALT refinement for the EVENT! datatype like there is /SHIFT and 
/CONTROL, so most likely there's also no control sequence for the 
ALT-key for /CORE to work with, too.

I tried various HEX codes I found in google but none worked. Excel 
just printed strange chars instead of doing a line-break.

is alt+return really a char?

IIRC, Alt is supported under View. What might not be supported is 
combination of some keys, e.g. ctrl + tab, so you can't tab between 
the tabs in an OS compatible manner. It would require some tricks 
to register for such events. Dunno if Alt + Enter should work or 
not ...

In R2 View, Alt is not supported. If you look at the event datatype, 
there are fields only for control and shift.

ah, my bad, Anton is right ....

Robert, you're mentioning Excel, so you're probably trying to do 
ALT+RETURN hard line-breaks with Excel thru comlib?

Maybe you can use the actual character code that Excel uses whenever 
one presses Alt+Enter. The web says Excel just inserts a line feed 
#"^/", have you tried that?

Alt+RETURN is not a character

Christian, right, I try to insert a hard line-break in Excel. I tried 
inserting NEWLINE, which doesn't work. Will try just the LN. Thanks.

Apart from chucking an error, what is the best way to determine if 
a path exists inside an object?  So, the path might be 10 deep ...

As far as I know, Graham, there is not a simpler way than provoking 
an error.
If you are already at the bottom of the structure FIND can help:

    a: make object! [b: make object! [c: 1]]
    find next first a/b 'd     ;; is a/b/d valid?
    == none
    find next first a/b 'c     ;; is a.b.c valid?
   == [c]


But recursing to the bottom may be slower than just trying the error?:
   error? try [a/b/d]
   error? try [a/b/c]

Seems ugly to have to use an error ...

It's a poorly specified way of obtaining some information.

perhaps there is merit for a feature to quickly determine the existence 
of a deeply stored value?

can't even do this

in object 'path/to/rebol

because 'in expects a word

How is this done in R3 ??

Same as in R2:
in object/path/to 'rebol

The problem is that at some point the field names can turn into function 
refinements, depending on the values assigned...

And why is that such a problem?

I mean, it's a solvable problem. IN could theoretically be enhanced 
to also accept paths, but, iIrc, Carl wasn't keen on the idea because 
he wanted IN to remain simple and fast. He said something like "it's 
for words".

The only thing we can do is make our own mezz version of IN that 
accepts paths.

(Ok, it's not a solvable problem for paths with dynamic elements 
in them like functions, but of course, there are many more "static" 
paths which this would be darned useful for.)

GET and SET work with paths in R3. Perhaps as you describe could 
be added as well, to handle the IN function for paths. And functions 
wouldn't be traced through.

the problem with object/path/to 'rebol is that it assumes object/path/to 
exists

Yup.

So you have to check for 'to in object/path first, and so on. I didn't 
say it would be a fast mezzanine :(

The way this kind of thing is resolved in R3 is through liberal use 
of the ASSERT/type function, and not representing XML as objects.

I guess there's a lot of advantages to just using blocks ... as it 
is now, some elements in my object are blocks and some are objects 
which makes it very messy

OTOH, blocks could get messy too ...


at present I have structures like ccr/body/alerts/alert where alert 
can be either a single alert object, or a block of alert objects

Ideally if I were to use blocks, it would end up that alert is always 
a block .. 0 ... n blocks

The R3 GUI is structured as a mix of objects, maps, blocks and gobs, 
but it is very consistent and not messy.

I presume it can't change though ... if a particular item is an object!, 
it won't be a block of objects in another instance ....

very consistent
, yes :)

That's my issue ... because the standard for the data has not been 
tightly defined, there are varying implementations leading to somewhat 
variable structures

Sounds like you need a tighter definition, or to resign yourself 
to slow code.

It's an ASTM standard ... I can't change the XSD!

But you can use a consistent REBOL representation of it, and don't 
need objects.

Google health has solved the issue by only working with a subset 
of the XSD.

Well, you can clean it up to a usable structure on read, process 
it nicely, then regenerate the bad XML on write.

Yeah .. I guess I was getting to that.