World: r3wp

Let me know what you think about this solution.

Great, I'll try it

What I'm a bit worried about, though, is binary compatibility. How 
are the values of type IDs determined?

I suppose they shift when the program uses different aliases. That's 
no problem for monolithic programs, but it would be when you try 
to define an interface to a library or other subsystem

They are source-specific, they represent the order of each alias 
definition encountered by the compiler.

Yes, so they're not suitable for standard interfaces

Anyway, whatever value is attributed it should be transparent to 
users.

As long you as you use system/alias/ path accessors.

That's source compatibility, not binary compatibility

The value are calculated at compilation-time.

values

If I ask GTK to determine an object's type, it takes care that it 
works across versions of the GTK library. You can't use these aliases 
to build such a library

You can't build libraries yet in Red/System anyway.

Sure, but we will in the future. In other words, we need some sort 
of ReBin standard

We'll deal with that when library generation will be possible. Until 
that, the current solution should be enough.

OK

If Carl should decide not to continue developing rebol is there anyone 
else who could take it over?

Sure, but I doubt that would happen, since Carl is not likely to 
hand his baby over to someone else.

SO why the mysterious behavior?

Carl is very busy with another project.

(let's move to REBOL3 group)

I'm trying to make a decision about which language to learn for my 
own use.

OK see you on REBOL3

Help! The current Red is incapable of compiling anything:

Compiling /resources/Red/tests/empty.reds ...

*** Compiler Internal Error: Script Error : Cannot use path on none! 
value 
*** Where: build-debug-lines 
*** Near:  [records: job/debug-info/lines/records 
files: job/debug-info/lines/files 
rec-size:
]

Strange...I ran the whole tests suite, as usual, without any issue 
before committing.

Simple scripts are compiling OK for Linux too.

Testing from Linux, the tests are not passing.

hmm, nope. seems there's a bug in my debug fix

Fix pushed. Sorry for the mess.

No problem, thanks

Thanks Andreas.

Can't test the new struct detection due to a new bug

It will be very hard to fix if there's no way for me to reproduce 
the issue.

The code part where the compiler script breaks is not related to 
function return values, but only to function arguments code generation.

It's a Heisenbug, so I'll check in the broken code

I have posted debugging instructions in the ticket comments.

It might be caused by a uncaught wrong definition in your imports, 
that is messing up the imported function arguments parsing code.

It's in Fossil now

I didn't change the imports, only the type definition

Got closer, will change the bug description

If it's heisenberg, that means it still might work some of the time?

Yes, when you're not using it :-)

Wave function collapsed, cat saved, bug fixed.

Eh, the cat survived?

Added Hello World examples to the GTK repository

Here's the simplest:

Red/System [ ]

#include %GTK.reds

gtk-begin
gtk-view window label "Hello, Red/System GTK+ world!"

Here is how that is customarily written in other bindings in other 
languages:

Red/System [ ]

#include %GTK.reds

argc-reference: declare integer-reference!
argv-reference: declare handle-reference!
argc-reference/value: system/args-count
argv-reference/value: as-handle system/args-list

_gtk-begin argc-reference argv-reference

_window: gtk-new-window gtk-window-top-level
_label: as gtk-widget! 0

either as-logic _window [
	_label: gtk-new-label "Good riddens!"

	either as-logic _label [
		gtk-append-container  as gtk-container! _window  _label
	][
		print "Failed to create label.^/"
	]


 g-connect-signal  as-handle _window  "destroy"  as-integer :gtk-quit 
  none
	gtk-show-all _window
	gtk-do-events
][
	print "Failed to create window.^/"
]