World: r3wp

Mike, I got the DLL versions for Windows from the official Windows 
download from the GTK site

Although it may just have been followed up by a newer version

I have 2.22.1-20101227 here

Nope, still the same bundle on the site

There are individual packages for the new 2.24, though, which replaces 
2.16 as the stable Windows version

Thanks there is no guarantee that I am doing it right but I am anxious 
to get it working. Thanks for the help guys.

Nice. All examples now  working now except GTK-widgets

With empirical debugging, this line passes the compile but make sthe 
execution fail  "fixed button [50 25  "Print"  :get-lines lines] 
gtk-tight"

Yes ... lots of those in the example ... it is the last one ... commented 
out and the executable does not fail.

How does it fail?

GTK-widgets.exe has encountered a problem and needs to close.  We 
are sorry for the inconvenience.

Exception Information/Code: 0xc000005  /Flags 0x0000000

p.s. thanks Kaj. That is an awesome amount of work you have taken 
on for the bindings.   Almost Doc-like.

Thanks :-)

Maybe Doc can see some meaning in that exception report. I'm not 
familiar with it

Are you starting it from a command prompt? If you do, do you get 
any extra output?

Same result from cmd or clicking on file icon or Git/Mingw32

No extra info

That vbox works if you comment out the vbox before it.

Works if you stick a fixed block in that hbox block ... well at least 
at the beginning

Which GTK version are you using?

libgtk-win32-2.0-0.dll

checksum/method read/binary %libgtk-win32-2.0-0.dll 'md5
== #{387C74458D7A43EBDD37FB61D39E28D0}

Back in a few hours ... Friday mid-night approaching.

That's only a very coarse library version that has stayed the same 
for a long time. What package version did you install?

I confirm the crash on GTK-widgets.exe, but it is working fine if 
compiled in debug mode (using -g), so I guess this qualifies as an 
heisenbug. :-)

I will investigate that issue later today.

It seems that the import section in the binary is corrupted when 
that script is compiled.

MikeL: I've pushed a fix in Red's master branch for the issue with 
gtk-widgets.exe, it now works fine on Win7 (should be ok on XP too).

Thanks. Works on XP.

Cool. :-)

The gtk-widgets.exe demo is really cool, it shows both the quality 
of the binding and the dialecting possibilities of Red/System (kudos 
for Kaj for inventing it!). Kaj really pushed it very far...and this 
is only v0.2.2 of Red. ;-)

Agreed. I tried to combine a GTK with a ZMQ.... I start to get collisions 
on #includes.      Is there an #include/check option that I didnot 
see in Section 10  http://static.red-lang.org/red-system-specs-light.html#section-10.2

No /check option (is that an option from Ladislav's #include?).

Collisions: we are currently lacking modules in Red/System, I plan 
to introduce them at some point, I'm waiting to go deeper in Red 
runtime implementation first to figure out the adequate approach 
for modules support.

Yes Ladislav's gem ...  include/check prevents scripts from being 
re-included (included more than once).   http://www.rebol.net/wiki/INCLUDE_documentation

IIRC, there's already such feature built in Red/System preprocessor, 
but it's based on absolute paths of included files.

I will try your example of including both GTK and ZMQ to see if something 
is going wrong in the preprocessor.

Harking back to the discussion of Red strings, it might interest 
you to know that the SMS character set uses the 0 position for the 
@ character. Just one of many character sets that won't work with 
C strings. C string support is good for Red/System apps that have 
to access C string library functions, but is a bit too limiting for 
Red itself.

I never planned to base the Red string! type on the Red/System c-string! 
type. All Red datatypes will have their own specific implementation. 
In some cases, for the sake of optimization, we should be able to 
substitute some Red scalar values to Red/System scalar values (mainly 
integer! in fact).

to => with

The current Red memory allocator is already providing the low-level 
layer for storing those Red values, but the datatypes constructors 
are not  implemented yet.

That should be my next step once I finish the ARM port.

I was just going through the SMS character set standards to see what 
characters were supported. It's interesting that you can send REBOL 
or C-like code, though you might need to escape some characters; 
to send Lisp code you need to not use macros since the ` character 
isn't supported. One of the surprises is that there is an additional 
standard where you can send UCS-2 (for those Lisp macros, or Perl), 
but you are limited to 70 characters and not all phones and SMS gateways 
support that type of thing.

I wonder if Twitter's character set is similarly limited, since it 
was originally an overlay service on SMS, IIRC.

Interesting, but I guess that a specific data encoding would be more 
appropriate than plain REBOL or C? Something like the Golf dialect 
(wrote by hostilefork?).

I was mostly interested in code sharing over text messages, but something 
like AltME or a code editor on my phone would be invaluable. A code 
editor that can send code snippets over SMS or other sharing services 
sounds interesting. I only mention this in this group because Red 
looks like it will end up on my phone before R3, barring a miracle.

Though, technically, I might be able to get Topaz running on the 
phone even quicker...

I guess that Topaz should already run on it, have you tried the Topaz 
demo URL?

Not on the phone yet, but I'll try that today :)