World: r3wp

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.

Why don't you add it as a wish on github?

I didn't want to add it, before asking first. To not fill the list.

Done.

SDL drawing works again, and PeterPaint is now unencumbered by Red 
bugs

Finally implemented automatic buffer expansion on in-memory cURL 
receive operations

Thanks Endo

Hm, cURL has no problem with multiple callbacks

Tested now with downloads up to 56 MB, in diverse chunks from a few 
hundred bytes to 16 K

That means GTK is the simplest exhibit of the crashes. As far as 
I know, it's single-threaded, but maybe not

I've housed the GTK binding here:

http://red.esperconsultancy.nl/Red-GTK

It doesn't do much yet, but you can reference it for testing purposes

I had to go through the Blogger registration process again to post 
a comment