AltME groups: search

You should be able to pass 2 integers (if it's a 'double or just 
one if it's a 'single), then do the float->integer (by doing a * 
100 e.g.). Probably fun to code. :-)

Right, if you want them in a variable. What I was proposing here 
is to split them from the stack by declaring 2 integers, so that 
the float gets stored in 2 arguments (supposing it is a double).

Got cURL to read a website and print it:

Added a higher level interface that reduces that to

They say it's a man year work to port it

But I can upload a file to FTP now

I've implemented a callback framework and used that to implement 
sending a data block from memory, instead of direct from a file

A callback used internally by cURL is fine, yes, on Linux. We'll 
see what a progress callback does with trying to print floats

Are you using a version of Red/System that includes my deeper fix 
for callbacks from 2011-06-30 (commit log: Merge branch 'callbacks-cconv')?

Two days seems like a long time ago. :-) If that was the final fix 
for 0MQ on Linux, then I already had it

I only had to make a few changes to the example scripts

I've extended the read function in the cURL binding to store a file 
being received directly to disk, instead of just printing it

Yeah, it's a tricky one

If you can provide a minimal example exhibiting the issue, I should 
be able to locate the problem from the disassembled code.

I will make post a news on freshmeat.net tonight (I still have some 
things to change on the web site).

I'm not used to working at that low level, so I'm moving a bit slowly 
on it

GDB on Syllable currently only supports real-time debugging, as crashed 
applications do not generate a 
core" file (crash dump)."

If GDb still works, I guess that prevents me from getting a backtrace

1. compile a binary using red as usual
2. instead of running the binary directly, run it via gdb:

    $ gdb builds/hello
    (gdb) run

3. when the program segfaults, you should be back in gdb
4. print a backtrace using "backtrace":

    (gdb) backtrace

The issue with shared libraries seems to be limited to the fact that 
cURL can use libdl. I don't know what was different now, but I got 
a GDb trace. Will put it on the tracker

The crashes seem to happen when cURL calls the C library, so outside 
the Red program. I'm not sure it's useful to disassemble a minimal 
Red example

silly question: is it possible now to build a CSV parser in Red?

There is no Red yet, only Red/System which is a low-level dialect. 
So, yes it is possible, but there's no special feature that would 
help you much for that task.

just found this... it could be a good reference for low-level bit 
handling in Red.
  

though the code is in C, its probably easier to understand this way 
and convert to Assembly after (when no comparable machine instruction 
exists).
http://graphics.stanford.edu/~seander/bithacks.html

Got a very simple Red/System program running on OS X: 
    Red/System [ ] quit 42
;-)

It took me a few hours to write the file emitter but a full day of 
debugging to make it work. It seems that the issue was related to 
stricter stack alignment requirement on OS X (16 bytes alignment) 
and a different ABI for syscalls. 


It currently works thanks to a few hacks, but I need to extend the 
IA-32 emitter to implement these new requirements in order to make 
it output correct code for OS X.

Doc, another stupid question: Are there going to be certain platform 
specific parts of code in a Red/System program?

Just reading %rsc.r, it seems Andreas already added such feature...there's 
probably a bug in compiler.r preventing it from working properly...

Make a docs directory in the rebol installation folder and type in 
REBOL console :
do http://perso.numericable.fr/frajouen/Red/editor.r

About calling functions in shared libraries and calling conventions, 
there seem to be differences between CPUs and compilers across operating 
systems. There's a lib, called libffi, to help with this, and it 
has bee widely ported.
http://en.wikipedia.org/wiki/Libffi


Why isn't a lib like libffi used in Red? Is it because of overhead, 
making it slower? Or maybe using such a lib makes little sense the 
way Red is implemented?


When looking at the host-kit for R3, I see functions to open, close 
and find functions in DLLs, but I don't see the calling of those 
functions. Shouldn't that be part of the host kit?

Ok, it's probably because I don't understand Red completely. At "load 
time", is that when the system starts up? (Maybe comparable to compile 
time.)


FFI is, as I understand it, a way for high-level languages like Python, 
Ruby, Rebol, etc., to load a library at runtime and call its functions. 
Like we do in R2 with load/library and then some make routine! and 
finally call the functions.

Red/System does not have a block datatype.

I'm pretty sure that Red will have a block datatype, not so sure 
about Red/System

I guess there will be a way to access Red blocks from Red/System. 
Until then, you can implement your own

Yes, but we're talking doing that in a high-level interpreted language, 
like Python, Ruby, Rebol, etc.

In a situation, where you don't know the function at compile time.

R3 uses dlopen/dlsym/dlclose to load R3 extensions, which have a 
clearly defined exposed API (RX_Init, RX_Call).

Yes, have a look at the hello.reds source code: https://github.com/dockimbel/Red/blob/master/red-system/tests/hello.reds

I once offered a little glowing "code protecting" angel statue to 
one of my developers. It was supposed to keep devil out of your code 
if you kept it close to your screen. Can't find it online anymore, 
maybe that would help...:-)

New Red/System document is available: BNF language grammar description 
(by Rudolf W. Meijer)
http://static.red-lang.org/A_BNF_grammar_of_Red_System.pdf

I've cleaned up my cURL binding enough to put it in a repository:

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

I can have a window without any borders, so you could make your own 
window manager

Kaj: are you working on a SDL-based View clone?

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

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.

'typeinfo is a variant of 'variadic that provides also argument type 
at runtime.

If someone has a better proposition for 'typeinfo, I am ready to 
replace it.

Callback is written like that in English (otherwise it would be a 
verb instead of a noun), but type info is written as two words

TYPED sounds good, based on a glance at the docs.

I can now draw a pixel on an SDL screen in a format of 32 bits per 
pixel

Humble beginnings, but I've had a series of issues already

I had TYPED in my short-list, so I guess it would be a better choice 
for a single word.

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]

Very nice. This takes Red/System a step beyond C

Well I consider PRINT-WS already too long, but -WIDE is nicer, so 
it might be a good alternative.

I use a lot of PRIN-* functions every day for debugging purpose, 
so this new, much more powerful PRINT alternative, will save me a 
few hundred keystrokes each day (just not having to type PRIN NEWLINE 
anymore makes me happy). :-)

:-) It also reads a lot more elegant

I considered PRINT-FORM but I've found it not meaningful enough. 
PRINT-WIDE is a better hint at what the function does.

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

I wonder why we use lf, instead of a newline. Then we add a description 
to the doc, something like lf adds a newline :-)

Did you do any performance improvements?

 I did a few small code optimizations, but they should not have noticeable 
 effects. Maybe your code relies on a tight loop that benefited from 
 them?

Of course, there is just a lot of other feature that are much higher 
in priority.

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

Arduino boards use AVR 8-bit MCU (microcontroller), the Netduinos 
use a 32-bit MCU equivalent to an ARMv4 IIRC. The port for AVR 8-bit 
has started but it is still highly experimental. The ARM port started 
by Andreas targets ARMv5 architecture IIRC.

16-bit integers: Red/System does not need them, but interfacing with 
external libraries might require it, especially for struct members. 
I wonder if adding support for a int16! pseudo-datatype, only limited 
to struct members would be hard to add...Will have a look at it, 
once all the current pending tasks will be done.

Where you will write stuff like devices (in R3 terminology), events, 
tasking/threading, simply a native stuff? As a RED/System? Or will 
it be RED itself (will not it be slow then?) I just would like to 
understand it a bit :-)

R3 -> Red/System: not sure if it would be an advantage or not. Currently, 
from a performance POV, C is still faster. (Think about current Red/System 
as C without optimizations turned on).

Aha, so Red/System is just a general REBOL/C like language. We still 
need to wrap native functionality/libraries, to get tasking, events, 
etc. Btw - do you plan to utilise liboop, libevent, pthreads libraries, 
or will you write everything from scratch/your (REBOL) way?

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.

Just a lame gradient, but I'm preparing for SylCon, September 3

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'm happy to report that raw SDL performance is almost twice as fast 
on Syllable as on Linux: a rendering that takes five seconds on Linux 
with X11 takes three on Syllable

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"

Yeah, good complement to your gfx binding to make a nice demo for 
the SFD 201. :-)

Or you can just make a wrapper on Google's TTS service using the 
cURL binding.

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 
;)"

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/

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.

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

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

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

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

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

hexadecimals used fort  event trigger comparaison could be holded 
in a meaning word ?

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