World: r3wp

Unknown languages are not played but you can make a lot of substitutions 
like let's say 

nl" do "de" etc. Mix sentences in different languages just for fun 
;)"

If you want to make Dutch people angry, you should do that...

Cross-posting jocko's reply from RebelBB french forum: 

There are two steps in this DLL: 


- first send a request to the Google api, for instance : http://translate.google.com/translate_tts?tl=en&q=hello+world
Google returns an audio file : translate_tts.mp3


- second, automatically open this file and play it. I use a DirectXShow 
filter (windows only), directly able to render the url. In the case 
of Linux, cUrl could do the first step, and, for instance VLC the 
second

As Nenad allready mentioned, he will give a presentation about Red 
during Software Freedom Day 2011, wednesday 14th september, at the 
Centrum Wiskunde & Informatica (CWI), Science Park Amsterdam: http://www.softwarefreedomday.eu/

TTS ...  nice.

Actually, my bindings don't work anymore with 0.2.1; they only compile

keep the good work :)

/me adds pixels too :P

Thanks.

Kaj: it seems I have introduced a regression on logic! handling in 
last commits. I will fix that asap.

Kaj: issue should be fixed now, I have added a couple new tests to 
avoid new regressions for such returned values.

Thanks! Logic! returns work again, but now I have another problem

I'm on it.

Issue fixed.

Thanks. Everything is peaceful again in paradise

Good! :) I will finally have some time to spend on the AVR port.

I hope so. I see a cload coming, but maybe it will drift past :-)

cloud

I've updated my bindings to the new PRINT form and marked them as 
needing the latest Red/System

Makes me think that having the release version stored in compiler 
and enforcing a header NEED: field might help...

Probably. I was recently looking for the compiler version, but couldn't 
find it

It would have to be quite precise, though. Currently, the first 0.2.1 
release won't do due to the bugs

Is there a limit to the number of arguments that can be passed to 
(variadic) functions?

In the current implementation for IA-32, arguments total size is 
limited to 255 bytes. No special limit is set on variadic functions 
other than that.

The number of arguments, or the combined size of the arguments?

Combined size on stack.

Have you reached that limit?

No, but I'm thinking about implementing dialects in typed function 
calls. :-)

Would that work out to 30 arguments for a typed function?

You should leave that to Red...I wonder if I didn't open a pandora 
box by allowing type to be passed with arguments...:-)

You're not going the Bjarne Stroustrup route where you declare RTTI 
evil, are you? ;-)

I think typed data should be used everywhere. It's very useful in 
PRINT, isn't it?

30 arguments: that's 30 * 4 * 2 bytes = 240 bytes, so that should 
fit in.

Don't the count and the pointer count?

ah yes, you're right, there's more to add...let me see...

hmm, I haven't looked correctly at the code, the stack limit is for 
local variables storage (255 bytes) not for function arguments.

Too many context switching today, I can't even properly read my own 
code comments. :-/

I once went on vacation for two weeks, and then stared at my code 
for a full day, fearing that I couldn't program anymore :-)

Unfortunately, my brain cells are too damaged by code to experiment 
such feeling. ;-)

About RTTI: I don't know if there are good or evil, hard to say. 
Typed data could be generalized, opening a lot of new possibilities. 
I just haven't had the time to experiment it to see if it would bring 
more advantages than issues. Your (and others) feedback on that would 
be very useful to me.

Also for fixed arity functions, the function spec block might become 
quite verbose:


foo: func [[typed] arg1 [...] type1 [integer!] arg2 [...] type2 [integer!]...] 
[ ... ]


Maybe the type numbers could be packed in a byte array and passed 
as an array pointer to make it easier to declare and use...?

Something like: 


    foo: func [ [typed] arg1 [...] arg2 [...] type [pointer! [byte!]] 
    ][
        ;-- type/1 => type of arg1
        ;-- type/2 => type of arg2
        ...
    ]

I'm very pleased with the new typed functions, as they should enable 
small low-level dialects. What I've learned from REBOL is that typed 
data with a standardised type system is sufficient to implement simple 
dialects, and that these are very useful to keep interfaces compatible 
while evolving them, because it's much more flexible than a fixed 
number of arguments with fixed types

Don't you miss the word! datatype to implement dialects in Red/System?

I probably will, but you can always define a list of constants yourself

I don't mean fullblown dynamic dialects, but a lightweight version 
for efficient low-level interfaces

I've implemented SDL events, including mouse input and key presses

Here's an SDL paint program:

#include %../SDL.reds


log-error: does [  ; Log current SDL error.
	print [sdl-form-error newline]
]


red:	as-byte FFh
green:	as-byte FFh
blue:	as-byte FFh

screen:		as sdl-surface! 0

event:			declare sdl-event!
mouse-event:	declare sdl-mouse-motion-event!

either sdl-begin sdl-init-all [
	screen: sdl-set-video-mode 640 480 32  sdl-software-surface

	either as-logic screen [
	while [all [
		sdl-await-event event
		event/type <> as-byte sdl-quit
	]][
		if event/type = as-byte sdl-mouse-moved [
			mouse-event: as sdl-mouse-motion-event! event

			if as-logic (as-integer mouse-event/pressed?) and FFh [

    unless plot screen  mouse-event/x-y and FFFFh  mouse-event/x-y >>> 
    16  red green blue [
					log-error
				]
			]
		]
	]
	][
		log-error
	]

	sdl-end
][
	log-error
]

I hereby name it PeterPaint, after the friend whose birthday we're 
going to celebrate tomorrow :-)