AltME groups: search

Great, I was just looking over it, and couldn't see anything wrong 
yet

Very cool Doc (and Rudolf).

We'll see how far we can get with sound and graphics without floats

I can open and close a window now. Imagine VIEW [ ] :-)

Hm. I'm developing on Syllable Server. On Syllable Desktop, I can 
load the SDL library and print its version, but it segfaults on opening 
a window

Maybe you could find out what is causing that in Syllable and fix 
it?

Most of the adaptation of Syllable to standard software is in the 
C library. This is where the handshake between kernel and userland 
is done in common systems

BTW, this call could prevent Red from working on Syllable as that 
libC init is a blackbox. I especially fear a clash with Red and libC 
thread init routines.

It would be much worse if it weren't a black box. :-) You'd have 
to duplicate all the initialisations done in there for all systems 
and all C libraries and all versions of them

BTW, Red will probably be distributed both as a standalone exe and 
as a dynamic library. So if people wants or needs to deeply rely 
on C libs, they could embed Red in a C project easily.

For Syllable Desktop I have to disable CDROM support, because we 
have only recently ported that to SDL. But now I get the windows, 
both with and without border

View is events, basic graphics structure, DRAW and window handling, 
as I see it.

Now that variable arguments and RTTI are available, I have re-designed 
the basic screen printing functions. I have inserted a _ character 
in front of all PRIN-* functions, as they should not be used anymore 
in the general case (I might drop them completly later if they are 
not useful anymore). 


Before releasing it, I would like to get some feedback first. Now 
only the polymorphic PRINT and PRINT-WS (inserting spaces) functions 
should be needed. LF, CR, TAB, SPACE have been declared, so can be 
freely used in print blocks (or anywhere else). Variadic and typed 
functions have now a relaxed syntax, allowing to pass a single argument 
without enclosing [ ] brackets.

PRINT: print one or several arguments one after each other.

PRINT-WS: print one or several arguments, inserting a space character 
between each arguments.

Here how it looks now:

* printing without newline

    print "hello"
    print 123
    print ["hello" 123 tab "world"]

* printing with newline

    print ["hello" lf]
    print [123 lf]
    print ["hello" 123 tab "world" lf]

* printing with space inserted

    print-ws ["hello" 123 "world"]
    print-ws ["hello" 123 tab "world" lf]

In PureBasic, there are Print and PrintN functions. PrintN adds new-line 
to the end.
For Print-ws, what about Print-Form ?

I will publish these changes tomorrow morning and will bump the version 
number, as they would break most of existing scripts. I will write 
a blog entry to describe the changes.

Did you do any performance improvements? I just updated after a bit 
over a month and my SDL test, drawing a gradient, is a lot faster 
:-)

LF is shorter, and newline was already defined

And float is planned, right?

What's becoming a problem first is the lack of 16 bits integers. 
They're in structs and arrays, so I have to do trickery now to access 
them

Maybe I imagined the speed improvement. My previous experiments were 
the night before, and I don't have those executables anymore

16 bits arrays also need to be manipulated, with 16 bits access and 
pointer arithmetic

List of tasks: yes, on my paper notebook. They usually cover 1 to 
3 days of work and are updated frequently.

Mostly working on Red now (memory allocator is done, tokenizer will 
start soon), but some Red/System improvements and fixes are still 
needed.

Tasking

 will be brought by actor! datatype which will use a pool of OS threads 
 underneath. I am not sure what you mean precisely by "events". Liboop 
 and libevent are nice libraries, but probably overkill for Red, so 
 I will implement similar low-level OS bindings specifically for Red 
 (probably merged in the actor abstraction). For OS threads, I will 
 pick up the API provided natively by each OS.

I'm programming redshift now and I've already found fault with the 
first SDL example ;-)

I can finally paint a pixel in any video mode, but the SDL example 
for 24 bits is broken, and I've also hit another bug in Red

I can read a bitmap image now and blit it to the screen

http://www.colineau.fr/rebol/downloads/demoTTS_Red.zip


Demo of a dialog, using the Google TTS api.

a custom dll has been 
written, based on the reference :
http://www.codeproject.com/KB/audio-video/GoogleTTS-Ebook-Reader.aspx

This demo is only executable under windows, and requests an Internet 
link

Tested with Windows XP and red/system 0.2.1

compilation: do/args 
%rsc.r 
%demoTTS.reds -t Windows"

Nice little demo and works very well.

If he ported that C++ code, it's bound to Windows. But yes, it could 
be done with cURL. Leaves the small matters of binding sound in SDL 
and MP3 decoding :-)

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

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...

Don't the count and the pointer count?

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 :-)

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...?

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

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

#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
]

Impresive Kaj can you do us a set of widgets in SDL or just the smallest 
possible VID and the widgets will be designed later

I really like the  Idea of VID a single face that as all possibilities 
and you just activated /deactivate the parts you want or not this 
is for me the core meaning of VID.

Yes, it makes things a step more dynamic, so you move some of the 
checking to runtime. But that's actually the point: you can then 
develop interfaces that can be loosely compatible with a time range 
of interface versions. It's the philosophy of static everything versus 
declarative everything in REBOL and XML. In the beginning of computing, 
static seemed more correct, but these days it has turned out that 
everything has to be able to withstand change as well as possible

Not that any of you would have issues with creating such a thing 
but here is an R2 version of the Colineau's (Jocko) Google translate 
app he created in Red. (Note, I didn't add all of the routines but 
if you take a look at Colineau's code it's all there.)  Also, the 
female voice (use gTTS function instead of TTS function) is much 
better than the male in my opinion unless you want to hear "This 
is Amiga Speaking." and feel nostalgic.

rebol [
	title: {googletts.r}
	date: 20-aug-2011
	usage: {gtts "Hello World." or tts "Hello World."}	
]

lib: load/library %tts-jc.dll

TTS: make routine! [
	lpStr [string!]
	return: [integer!]		
] lib "TTS"

gTTS: make routine! [
	lpStr [string!]
	return: [integer!]		
] lib "gTTS"

-----

I created some nice memory tools for my son who is in law school 
with this by setting up the string and tweaking it and then recording 
it (I use Sound Forge). If I get some free time I'd like to create 
a dialect so that I can make an interactive tool with visual reinforcements. 
As I mentioned, you have to tweak the words and punctuation and that 
creates a problem with just reading the text normally, hence I'll 
require a mechanism to sort all that out.

Oh, the dll is in the http://www.colineau.fr/rebol/downloads/demoTTS_Red.zip
file

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 ...

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.

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.

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

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.

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

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

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 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.

And would be more compatible with REBOL as well.

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

And thank for mentioning Red in your interview, once again, that 
boosted Red visibility significantly.

I am proud to present my first Red/System dialect, for GTK. Here's 
an example of a window with a title, an icon, a label, an input field 
and a button with an associated action function:

I am surprised myself at how far you can get. I'm pretty certain 
this is now the most concise and efficient GTK binding in existence

Thanks. I've been talking about such techniques for many years in 
Syllable and in general, and nobody will ever believe me. I'm very 
happy to now have a tool to show them

The audience... sigh. They were friends, but there was only one programmer, 
formerly C++ and now Python. I asked him beforehand how long he thought 
his equivalent Python program would be. He didn't seem to be much 
into GUI programming, but he maintained it would be only ten lines...

for example and then check for that code. But you'd get a manual 
sort of symbol table that would take space

and have constants be real types that you can check for, you'd be 
able to stretch simple dialects a lot further

Detecting aliases would be very nice. It would replace GTK's RTTI, 
which is complex and buggy, and obviously wouldn't work cross-toolkit

People are not really supposed to use this binding

 It's a very nice binding that could motivate some C coders from Rebol 
 community (or outside) to take a closer look at Red/System and start 
 hacking with it. It could be a good way to attract new users.

It would mainly need a full backend code generator for supporting 
floating numbers. It would also require to add some runtime conversion 
with other numerical types and probably many small additions at all 
stages of compilation.

Good work Kaj, I tested the GTK binding examples also on Windows 
7 and it works flawlessly.

Thanks. It makes them backward and forward compatible to some extent

I have tested with your code example and GTK debug version. I'm getting:

type: 1005
value: 0
Window: skipping missing widget.

It demoes mouse events, drawing, program arguments and loading a 
bitmap file

You can put GTK and SDL on the website now, if you want

Is there an idiots guide for new users and developers?

I don't think there's a quide guide on getting started for people 
new to red and/or rebol ...

Red-SDL , and the PeterPaint example works under Windows XP apart 
from the name of the dll which is SDL.dll instead of libSDL-1.2.dll

I tried Linux loop mounting and 7-Zip, but my versions don't seem 
to support DMG. It's just much easier if someone with a Mac has a 
quick look

I have a mac but daughter has password protected it .. and she no 
longer lives here!

Graham: there's no such guide yet. You have a few basic instructions 
for installing Red/System and compiling the Hello script here: https://github.com/dockimbel/Red

It should run on Linux and Windows

There are no "standard" arrays in Red/System though I'm sure that 
there will be, or something which provides the same functionality 
in Red (when it becomes available).


args is not a standard array and is navigated through pointer arithmetic 
just like  a c-string. I suspect that args points to a list of pointers 
each of which contains the address of a command-line argument.


So the first entry in Args holds the memory address of the first 
command-line entry, the second the second command line entry, etc.


The syntax args/item gets you to the data pointed at by the relevant 
entry in args.

Where is the recommended dir to place GTK.reds, C-library.reds & 
SDL.reds? I put them in red-system. BTW. I'm using Win 7 (x64) and 
compile with do/args %rsc.r "-v 5 %tests/hello-GTK-world.reds".

BTW, I had a great time at Software Freedom Day and met very interesting 
peoples. Thanks to Bas & Kaj for organizing it and inviting me.

The C library's vprintf() function is the one that gets passed one 
argument that is a list of the variable arguments. This seems to 
match the declaration of a variadic Red function, so I thought PRINT 
would match vprintf(). Looking at it again, is it the other way around 
and does PRINT match printf() ?

About the examples in 6.3.3, I would need to rename the vprint and 
vprintf functions to avoid confusion.

About the [variadic] attribute used in imported functions declaration, 
as you can notice, you don't need to declare any arguments. In this 
context, the attribute is interpreted just as "variable number of 
arguments" and the C calling convention will be used in such case 
(the Red/System variadic stack layout is different than the C one, 
as it also passes the arguments count).

Kaj, I downloaded all files again and tried it on another PC with 
Win 7 (x64). Same compilation error, but I also noticed while running 
do/args %rsc.r "%tests/hello-GTK-world.reds"

The first run


*** Warning: type casting from pointer! to pointer! is not necessary
*** in: %tests/hello-GTK-world.reds
*** at:  [as integer! :gtk-quit null

*** Compilation Error: invalid struct member alias in: type
*** in file: %tests/hello-GTK-world.reds
*** in function: window
*** at:  [type system/alias/gdk-image! [

The next runs


*** Compilation Error: a variable is already using the same name: 
window
*** in file: %tests/hello-GTK-world.reds
*** in function: window
*** at:  [

MagnussonC: have you downloaded the latest version of Red sources 
(the "Download.zip" button and not the v0.2.1 link)?

Dockimbel, no, I didn't realize there was a difference, but now I 
have and it compiled OK. Thanks.

GTK-input-field.reds compiles OK and catches the input, but exe also 
gives *** Runtime Error 1: access violation at: 63A45193h

I was suspecting something like that. I hope it also helps the Linux 
and SDL cases

Have to get back into Red. I've been looking into Freecoin and other 
stuff for a few days

It's quite a mess, and that's why everybody is rewriting stuff

I've decided to first port some of it to Syllable and wait a while 
with the bindings

The callbacks can have different numbers of arguments, and the widgets 
will eventually have multiple callbacks

No, I mean to default to cdecl - which I thought was already implied 
by CALLBACK - and require to add stdcall only for Windows system 
callbacks

It's only for Windows system callbacks. Most all other libraries 
on Windows use cdecl, and it is only for callbacks, not for general 
Windows system functions

Will it be wrappers written in RED upon read-io, write-io Red/System 
functions?
 


Just to be sure there is no confusion: the read-io and write-io function 
mentioned in the slides have nothing to do with the REBOL homonyms. 
The Red/System ones are wrapper on CPU's IN and OUT instructions.

You should compile it in verbose mode (-v 6) and check the callbacks 
calling convention in the symbols block at the end of the compilation 
logs.

I think that I will just accept both 'stdcall and 'cdecl attribute 
in cases like this where the compiler can't determine the right calling 
convention. I will also add a check at the end of the compilation 
to raise errors for unresolved calling conventions.

I don't really see a connection between the function a pointer is 
passed to and the function that will eventually call it