World: r3wp

I already told you: we can't use it. Besides, Red won't be compatible 
with REBOL, so it won't be able to run VID. The same goes for the 
View engine: it's very REBOL specific

it does not prevent anything conceptually similar to be made, however.

Kaj - I expect RED being kind-of compatible with REBOL, or I am not 
interested in it. I expect we will have parser, and REBOL-like constructs. 
We don't need 100% compatibility for porting. It is just that I thought 
that View (apart from its possible licence restrictions) is significantly 
smaller to port, when comparing to things like GTK or SDL?

Maybe one day it will come anyway, if Carl does not appear anytime 
in foreseable future. Add 2 months, and we are one year in an R3 
develompent limbo ...

I mean - maybe one day RMA ports it themselves :-)

Any technical considerations are moot with software that you're not 
allowed to port

btw - do we know the licence of View engine?

No, that's the point

The new casting implementation has broken PeterPaint

Ah, I was expecting some regressions...

I am working on some new type casting fixes, they might fix your 
issue. I am not sure I'll be able to release them today, probably 
tomorrow.

The following class of expressions is not emitting correct native 
code: A <op> B, where A is an integer! expression and B is byte! 
variable.

It has also broken the cURL binding

I tried to not break anything with this sensible commit, so I ensured 
that all current unit tests were passing as long as all my test apps 
(including Red's memory allocator). It would be useful to identify 
your regressions, so we can add new regression tests and avoid that 
in the future.

I'll wait for your fixes. It's not useful to hunt for deep bugs that 
are already known

Do you have runtime errors reported?

No, I'm getting internal compiler errors during compilation, so I 
don't even know where they are in my source; and no pixels drawn 
in SDL

Oh, those are easier to fix. :-)

Not for me

To locate internal compiler error, just run the compiler in verbose 
mode (like -v 5), and watch for "expr: " outputs, that should help 
you locate the part of your source causing that.

Usually, the last "expr: " output is enough to locate the error.

Sorry, but I don't really have time to do such deep debugging

The "expr: " outputs code from Red/System source, not compiler source.

At least, you'll know which expression in your Red/System app is 
causing the issue.

I'll look into it when the errors are still there with your fixes

You can also send me the source code, and I'll do the internal debugging, 
it is probably a minor error.

If you want, you can compile the cURL binding for one

I've released a fix for your compilation issue.

Fixes released. Hope they will fix your issues too. I won't be able 
to work on Red tonight, so if more fixes are needed, that will be 
for tomorrow.

Thanks, cURL works again

It took me a day to hook up a (quit) signal to a GTK program. GTK 
is incredibly bloated

I can now load a GDK image and set it as the GTK window icon

Now I can add a text label to the window

And now a button with an associated action callback

I've bound the line entry field, but I'm having serious problems 
with crashing callbacks in both GTK and SDL

I'm going to return to cURL for a while to see if I can trigger the 
problem there

A regression in today's commit or an older issue?

No, it's probably always been this way, at least since I started 
the SDL binding

If you can send me a short sample, I can do some investigations.

I've only done very small things with callbacks so far. The somewhat 
bigger transfers in cURL were directly to files, with its own internal 
callbacks

Yes, if I can trigger it in cURL, that would currently be the most 
accessible example

So far I suspected multithreading in SDL's sound playing, but it 
seems the problem is more fundamental

Doc: why UNTIL doesn't return a value. It can simply return TRUE, 
because if loop is over the last expression evaluated as TRUE. So 
it can always return TRUE. No?

Do you think that UNTIL returning always TRUE is useful?

Or I should rather ask if UNTIL returning always TRUE is more useful 
than returning nothing?

I'm not sure if this is possible in Red/System,

i: 0 wait-me: until [++ i i > 5]
;do something async and check wait-me also, to be at sync.

It would be useful if there would be a BREAK that would return FALSE

Kaj: agreed.

Kaj: Yes that is more useful.

And would be more compatible with REBOL as well.