World: r3wp

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!

This libr3.o of which you speak.. that should work for Amiga as well 
shouldn't it?

It would have to be one specific for Amiga, like the dynamic one

I just got compositing working on the Amiga (via AGG).

congratulations!

funny that R3/view ends up working on Amiga before OSX and Linux 
 :-D