World: r3wp

1. script interrupt: does a halt
2. program interrupt: does an exit

Because the host-kit side cannot know the state of execution in the 
core, it is necessary to use RL_Escape() to signal the event.

What we want eventually is for host-kit to detect ESC, and call RL_Escape 
for that too.  But, that requires that we use raw stdio processing 
(or use an OS that's good enough to detect and signal us on a specific 
key press), so it's not implemented yet.

Notice that on Windows, your WAIT example above will interrupt as 
expected on CTRL-C. So that part of the basic mechanism is implemented.

+1 Close_Window() in host layer.

The scenarios I'm thinking of (eg. where an app delays the closing 
of the window to dialog you with "data is not saved!") seem pretty 
cheap in this day and age, and justifiably should not be allowed 
to preempt the window close.
There could be scenarios I haven't thought of, though.

Amiga has CTRL-D which means interrupt script and CTRL-C which means 
interrupt command (from the shell).

By script I mean a shell script but it could also mean REBOL script. 
:)

It is also possible for a window close to fail if the EVT_CLOSE event 
cannot be queued. This situation is currently ignored in the Windows 
implementation.

I just implemented CTRL-C checking in OS event handler and I call 
RL_Escape() when it is detected. Seems to work fine now.


On Amiga, all signals must be explicitly checked for. This is both 
good and bad of course. The control is nice but the code duplication 
for things like CTRL-C is not.

Inability to catch window close is a defect in desing, easy as that 
...

I can't imagine my browser does not ask me, if I want to save tonnes 
of opened tabs. Why should we miss that R2 feature?

I think that insert-event-func was good mechanism to use ....

So you mean that the OS should be able to control the closing of 
the window and REBOL should not be able to interrupt that?

exactly the opposite ...

Ah, so REBOL is in control and the OS must obey.

Rebol can be in control, but does not have to be. IIRC in R2, you 
used something like insert-event-func, which inserted your handler 
into an event loop, where you could catch such events ....

As it is now, I simply post an EVT_CLOSE event and if successful, 
close the window. There is no opportunity to receive information 
from R3 on whether the EVT_CLOSE was successful or not.

The EVT_CLOSE may fail if out of memory only.

I don't understand low level implementations much, but once again 
- I regard eventual non-ability to control such behaviour as windows 
closure from my script, a defect, not a feature :-)

... and R3 should add flexibility in comparison to R2, not to remove 
it ...

As it stands right now, R3 accepts the EVT_CLOSE and can do nothing 
to stop it.

I don't know how R2 did it, but IIRC it was possible ...

I don't use it in my scripts. Maybe I used it once. But - I don't 
want to explain to eventual client, that REBOL as a platform can't 
offer such a feature as a dialog box warning before the close of 
the window happens ...

In user terms, if I hit the close gadget on my window then it closes. 
The only time it may not close is if the event queue is full. There 
is no "are you sure?" opportunity. This is why I asked about it. 
:)

I suppose I should go file a bug report right now so we don't forget...

If you don't have the ability to intercept the closing of the window, 
then you will cause data loss in apps, and not giving the program 
a chance to clean up (temp files, file locks, etc.) when quitting. 
Tthis deals with more than plain warnings of window closure. This 
is a UI and app specific behavior issue and should really not be 
controlled on a low level.

I'm with Petr and Henrik here. We need to get the event and not have 
our process end before we can clean up. Hard terminating an runaway 
or zombie is a different issue.

I am currently doing cleanup in the RDC_QUIT vector of the OS Events 
device.

Filed a bug report.. bbl

Carl, Andreas: I tried to update the Xcode to 2.5 but the compiled 
result of the test from Andreas is the same as with the older version 
:-/

Ha, Cyphre!

I think I figured it out even for older toolchains.

Would you like to help me testing?

sure, I can..let me boot and login to my old mac mini ;)

Ok, let's use PM to reduce the noise :)

ok

Ok, seems we solved the OS X linking issue even for older toolchains.

The trick is to partially link all objects into an (internally resolved) 
single object and then use this to create the shared library. So, 
for Carl's example, that boils down to:

  ld -r -x -o lib.so a.o b.o
  gcc -dynamiclib -o lib.so lib.o

Here's a full package illustrating this:
http://bolka.at/2010/misc/exports2.tar.gz

Sorry, subtle but critical typo in the above. Should be:

  ld -r -x -o lib.o a.o b.o
  gcc -dynamiclib -o lib.so lib.o

Ah, very good. This solution looks like it does what is needed!  
I should have the OS X .so out soon.

The link failed...

ld: lib.o malformed object (section (__TEXT,___textcoal_nt) no symbol 
at start of coalesced section)

Using -t ... the above ld failure happens in the system files, not 
the R3 side.

I've confirmed that /core builds and runs... so this is not likely 
to be related to the gcc update.

Hm, does the link succeed if you leave out the -x option to ld?

yes

Ok. Then try make an unstripped .so from the unstripped .o and strip 
-x the .so afterwards.

I.e.:
  ld -r -o lib.o a.o b.o
  gcc -dynamiclib -o lib.so lib.o
  strip -x lib.so

Actually... I tried that earlier... 1 min...

I misinterpreted the result... that does actually seem to work.

I'll do some tests, and if they pass, will upload the new .so.