World: r3wp

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.

Great!

It would also be very neat if you could upload the (stripped) libr3.o 
as well, if that's ok for you. Would allow us to build self-contained 
binaries by statically linking in libr3.

Same for Linux (and FreeBSD, and ...), of course. Not sure if this 
is possible on Windows (I doubt it, actually).

guess it would be a .lib

Yes, but no idea if partial linking is possible with COFF.

(I.e. on Win32.)

A: yes, can export static lib for OS X and Linux.

Lovely!