AltME groups: search

We had some tea at Hekovnik (hackerspace) and one very experienced 
programmer here started talking about new language Red .. I was what?? 
Did you say Red :) .. he read about it on the OSNews

You'll note that only a few trolls have responded to the article, 
and one person who already knew REBOL. This is typical when you introduce 
something that people don't understand. They'll hold back from responding 
in fear of saying something that makes them look stupid. However, 
so far four thousand of them have traveled from the article to the 
Red site, which is more than we get on a typical Syllable article

He was interested about it all so I hope Doc's (and comunity's) progress 
will go well. ( BTW: Doc, He also noted you have a little familiar 
name ;) )

Kaj - what is your take on the Red & Syllable? I mean - Syllable 
is open-source. You used Boron for some stuff, and then you thought 
of using R3. Are you now thinking about the switch to Red?

And maybe few questions to Doc:


1) R3 got some stuff as codecs (not yet implemented) and devices 
for async. Will you think about such abstractions too? (e.g. ports), 
or is Red going to be more "straighforward"/traditional?


2) as View is mostly open-sourced too - will event system allow to 
eventually port View engine to Red later?


3) as 2) requires 'parse, do you plan to have kind of R3 parse too? 
Is that even possible? (as Red is not so dynamic as REBOL?)

1) Ports and devices: yes, definitely. What features does exactly 
"codecs" cover in R3?


2) I was not aware that it was allowed to use View sources with anything 
else than R3?


3) Parse: absolutely. Not sure yet if it will be 100% compatible 
with R3, but it will at least, support R2's whole parse dialect. 
Red should be as "dynamic" as REBOL for the code<=>data paradigm 
once the JIT compiler will be in place.

Petr, it has been a bit of a process in my head in the past few months, 
but to be honest, I've decided to move all my R3 developments and 
plans to Red. All of those also apply to Syllable

I've been waiting for a decade to be able to use REBOL, because it 
never ran on Syllable, and for the past half decade, all subsystems 
were planned to be replaced, seemingly making it uneconomical to 
start using R2 on other platforms

In the past two years I made a lot of effort to get R3 running on 
Syllable Server and then Syllable Desktop, and just now that it was 
becoming somewhat usable, it's being abandoned

This after going through the Atari trauma, and having decided never 
to do that again, seeing all those other people go through the Commodore 
trauma, the Amiga trauma, the RISC OS trauma and the BeOS trauma

I made an exception for REBOL because it's brilliance couldn't be 
found anywhere else, and I paid dearly

The Rebol source headers say .. free to use as long as you keep the 
headers intact.  And then refers you to the full license .. whereever 
that may lie.

I think they are complete, but the official word is that the host 
kit will be separated under two licenses: one part open source and 
one part not open source. Both projected licenses are still unspecified

The interfaces between REBOL and AGG are rather REBOL specific. I'm 
not sure it's worth it to try to use them in Red

2.4 is BSD. 2.5 is only slightly improved. A residual community around 
AGG has been continuing with 2.4 and has made a few fixes to it

There are basically four options: AGG, Fog, Cairo and Skia

AGG and FOG may perform better, but I'm not sure. The choice between 
those two is difficult. AGG is basically abandoned, but still more 
popular than Fog

I'd like to know how it compares to AGG and Skia

Implemented character set tests and case conversion in the C library 
binding

Kaj, you stated: "In the past two years I made a lot of effort to 
get R3 running on Syllable Server and then Syllable Desktop, and 
just now that it was becoming somewhat usable, it's being abandoned."


What exactly is being abandoned? I tried to read back through the 
previous messages, but I'm missing something.

Robert: being free from any dependency (including C lib) is my intention, 
but:
- C lib is available as system library in any major OS

- C lib functions are more optimized, so will run faster than Red/System 
alternatives


However, as I would like to be able to make Red (or just Red/System) 
run on many embedded platform too (e.g. Arduino and NXT), I don't 
want to have to statically link with C lib there (because of the 
memory footprint). My current idea is to provide both: C lib bindings 
and alternative functions coded in Red/System only, in a transparent 
way for the user.

With all the plug computers coming with server sized ARM processors, 
being able to create bare-matel appliances that you just plug in 
and which are than balzing fast, is a pretty cool setup.

Endo: I will not let those sub-projects interfere with the main roadmap, 
they should just blend in. For example, the SheevaPlug could be a 
nice platform to develop and test the ARM port for Red/System: http://en.wikipedia.org/wiki/SheevaPlug

and stock prediction tools

Implemented ABSOLUTE, quicksort and binary search

Again, SORT and binary search may not work yet, because they take 
a comparison function, that should be cdecl

As Robert mentioned Photothead library few days ago ( http://www.sics.se/~adam/pt/
), I do remember finding some interesting event libraries in the 
past - liboop ( http://freshmeat.net/projects/liboop/)          
     and libevent ( http://monkey.org/~provos/libevent/- some other 
references there too) ... so just for a sake of a reference ...

it's awesome to see the growing of a language and the environment 
around it being fully documented! it will be very useful for the 
next generations

Kaj: regarding chimpanzees...

my father in law has some monkeys which normally help to twist off 
coconuts from palm trees. as these little guys get older, they get 
slower and also grumpier. 2 different ones already bit my father 
in law.

we might give these retired, veteran monkeys a second life as random 
number generator! i would be a great business in thailand if i think 
about how many coconut trees and monkeys do they have here :)

I have a variant: A few years ago, a TV station had some famous art 
critics comment on the paintings of a new, unknown artist. They made 
lengthy comments on how wonderful it all was and how it was a new 
style of art. They were not pleased to learn they had been tricked 
into commenting on works made by a monkey.

Picasso once said that when art critics meet, they discuss design 
and architecture and geometry, deeper meaning and social consequences; 
and when artists gather, they talk about where to get cheap turpentine

Well, the details of Red implementation are not have been yet documented, 
but the general idea is to implement as much features as possible 
in Red itself relying only on Red/System's support functions exported 
to Red level. So for networking, Red/System should publish to Red 
the low-level OS mappings required and let Red implement everything 
else. This is the plan, but it not set in stone, it could be changed 
during implementation if a better approach emerges.

Implemented some simple type conversions in the C library binding, 
parsing strings to integers and floating point

I think Steve Shireman has done TCP stacks in the past. 


My only recent thought, related to OS dependencies and such, was 
what it would be like if your only interface to files was a memory 
mapped file interface. Thinking about languages and desktop/server 
systems, not the embedded stuff.

There are also many C functions that return something else for success, 
and take integer parameters for byte values

Pekr, Doc says that he wants it to run on Arduino and NXT at least.

Some hardware will be too small for Red, but Red/System is basically 
C, so it could run on almost anything. That's why I want Red/System 
to be usable on its own, with a full C library binding and such

For some functionality, I need to have access to the stdin, stdout 
and stderr identifiers. For syscalls, they're simple integers, but 
in the C library, they're pointers to file descriptors. There's currently 
no way to get their values

Andreas: agreed for the #import extension syntax. I am adding that 
feature to the todo-list, and will look into the PE format specs 
to see how it is encoded.  What is required in ELF to support such 
imports?

Implemented date and time functions in the C library binding

I have set up a new account on Google Apps for red-lang.org and added 
MX records, so my new mailbox should be ready by tomorrow. I will 
also create a new Paypal account for Red once the mailbox will be 
ready.

Doc, I have not read anbything about RED and I am just curious.
Which are the main differences between RED and REBOL ?

And more details here: http://www.red-lang.org/p/about.html

Read ! I have understood the differences and why your are leaveing 
the REBOL world for the RED world.

Well, "leaving" might be a little strong. Red is based on REBOL, 
can coexist with REBOL very well (in theory), and most of the people 
working on it are part of the REBOL community in one way or another. 
They're complementary projects.

and REBOL 4 will be written in Red :-)

However, it can't work yet, because floats are 64 bits in most implementations, 
and Red can't pass those by value

Implemented remaining string parsing and file functions

The C and math library binding is now pretty much complete, at the 
level of the original ANSI standard. I've left out some stuff that 
is too implementation dependent and not strictly needed

The examples in 10.1 and 10.2 use hex numbers in lowercase

If Red follows REBOL's evaluation levels, NOT would have lower priority 
than all operators. Two levels: Operators, and everything else.

Operators in Red are both infix and prefix

The REBOL manual also fails to note the fundamental difference between 
NOT and the other logical functions/operators

Operators in Red are both infix and prefix

: right, same as in REBOL, so, same limitation for using an operator 
in prefix mode.

I'm currently doing explicit castings, but that requires a wrapper 
function, which takes up space in the source and in every binary. 
So I was wondering if it would be a good idea to obsolete some of 
those wrappers

I'm fine with the extra code generated. It would be like inlining 
just one as-logic operation, and only generated when needed

The alternative is always going through the wrapper function, which 
is slower, and only for the as-logic, so this strikes me as a case 
where you would want to inline. The #import spec can be a nice syntax 
touch to signal that

I am considering your request for an implicit casting for imported 
functions using a return: [logic!] declaration. I could add it, by 
forcing a type conversion if the function is imported, but if the 
function already returns the right value (0 | 1), it will have to 
pay an extra cost for a useless conversion and no way to avoid it.

Just don't use any type casting and no conversion code will be added.

So it can only be used when strictly 0 and 1 are returned in integer! 
format?

If you function return 0 for false and a positive number for true, 
it needs a runtime conversion.

Base address, really, and address alignment

btw, I tried to install syllabe within VirtualBox some weeks ago, 
And It failed/

If anyone has experience with that API on Windows, advices and tips 
are welcome. :-)

Steeve: I failed to install that version too, but here are special 
install images for Vmware and VirtualBox under "Emulate Syllable" 
bar here: http://web.syllable.org/pages/get-Syllable.html#installation-CD

Thanks Gregg, we are currently reaching the first milestone of the 
project with a fully capable Red/System language, just a few more 
implementation fixes, the specification draft to complete, and I 
will declare it beta (means "usable" for real work).

And MacOSX

and does it have a console?

Windows, Linux and Syllable, no Mac

I tried to write a console input function (no one is available up 
to now AFAK).
This one works (for windows):
#import [
	"kernel32.dll" stdcall [
		ReadConsole: "ReadConsoleA" [
		  	handle		[integer!]
		  	buffer		[c-string!]
		  	len			[integer!]
		  	read		[struct! [value [integer!]]]
		  	reserved	[integer!]
		  	return:	[integer!]
		]
	]

]

stdin: GetStdHandle WIN_STD_INPUT_HANDLE
__read: struct [value [integer!]]
	

input: func [s [c-string!] return: [c-string!] /local in][
		;in: "" ; don't work
		in: allocate 255  ; must be freed after !
		prin s
		ReadConsole stdin in 255 __read 0
		a: __read/value - 1; because of the line return symbol \n
		in/a: #"^(00)" ; necessary to add it !
		in
	]

; usage :
res: input "enter a string : "
print res

my questions : 
- is this correct ?
- how and where de-allocate the c-string ?
- why the end-string symbol is not added automatically ?

Have you tried the input functions of your C library binding ? I 
tried input-line (under windows) some time ago, and it did not work. 
At that time, i did not try to allocate the c-string

We talked that over with Nenad and it's planned

Bigger binaries: yes, it is caused by #import bindings and by runtime 
message strings.

Kaj: have you found the "struct [...]" construction somehow misleading?


I am asking this because there is a discussion about that on the 
mailing-list and I need to decide this weekend if I keep pointer/struct 
literal declarations as-is or change it.

Any feedback on this topic (and other opened questions on the ML 
and issue tracker) will be appreciated.

I've been thinking about it, but the reason it is misleading is basically 
that it's defined at the C level. You have to flip flop your mind 
between low level C thinking and high level REBOL thinking

I suppose this is inherent in the concept of Red/System, and I think 
it's mainly a matter of learning the new language

It now dawns on me that I mixed up STRUCT and ALLOCATE. I hit these 
issues last night and went to bad because I was tired and pretty 
sure that I would be able to see it more clearly today, but I had 
already formulated the questions in my head :-)

The new ALLOCATE and FREE use c-string! which makes using them on 
generic byte arrays, and comparisons with NULL, confusing

I find ALLOCATE and FREE using c-string! unintuitive

I once did, but I doubt it will now compensate for c-string! and 
NULL

Yes, so why not define NULL and byte-ptr! as integer?

That still leaves the incompatibility between byte-ptr! and the documentation

NULL, byte-ptr! and the manual use three type incompatible definitions. 
I must compare and pass these types

NULL and documentation will be fixed during this weekend.

Not really, because casts are needed on every use of ALLOCATE and 
FREE

No, because there's one exception: the type that ALLOCATE and FREE 
choose to use

They currently use c-string! I'm not sure that's the clearest one. 
It's unintuitive to me, as if the type returned is very specific 
and comes with a zero byte at the end

I know, but that gets lost during compilation. What the compiler 
complains about is that you have to cast to and from c-string!

If [pointer! [byte!]] could do the job and make C coders happy, I 
will add it to Red/System.

Well, this is certainly not the right definition a byte! pointer. 
:-) Can't you wait until monday when all the current issues regarding 
NULL and documentation will be fixed?

We have been aware that pointer [integer!] does not accurately describe 
a pointer [byte!] but you don't want to implement that in the current 
development cycle and that's fair enough. It's only a cosmetic problem 
right now

Will the NULL enhancement change the types handled by ALLOCATE and 
FREE to one generic pointer definition? Let's stop calling it void, 
but instead variant, which it really is

No, that would not change the types of ALLOCATE and FREE, I would 
only change them to pointer! [byte!] when it will be available.

I thought so, so ALLOCATE and FREE will still deliver types that 
I wouldn't expect from them, and that effectively introduce an extra 
definition of a variant pointer

The LENGTH? example is interesting, because people will now use it 
on an allocated binary, expecting that it's zero-terminated, and 
even if it is, the expected length will be off by one

But the more tangible problem is that currently, you don't have to 
cast when you allocate a string, and that will change when a proper 
byte pointer is introduced

You don't have to, because the fix is only half a line, and I don't 
need it before Monday

No conversion at all. The memset case is a old C oddity that never 
got fixed. It should have a byte in the declaration instead of int. 
The algorithm in memset uses a byte and not an int, so the Red/System 
binding is not only safe, but also cleaner than the C one. The memset 
oddity is explained there: http://stackoverflow.com/questions/5919735/why-does-memset-take-an-int-instead-of-a-char

Jocko, answering your questions:
- is this correct ?
    Yes, I tested it here, works flawlessly.

- how and where de-allocate the c-string ?

    Same as in C, when you don't need it anymore. So in your code example, 
    it would be after "print res".

- why the end-string symbol is not added automatically ?

    Red/System is a low-level language, it treats c-string! as C does 
    with string, the trailing zero is only a convention. If ReadConsole() 
    doesn't add a trailing zero, only the programmer knows if and where 
    it should be added. Red/System can only add automatically trailing 
    zero on literal c-string! because, in that case, it can easily guess 
    where the c-string! ends.