AltME groups: search

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.

I would be suprized if there was no C compiler for all those plug 
computers, but anyway, I will do my best to have a dependency-free 
Red core option. I will keep all the core bindings in separate per-OS 
files, so it will be easier to track them.


I guess it would be fun to implement a micro-OS in Red/System for 
these micro-platforms, I always wanted to get my hand on a custom 
TCP/IP stack implementation :-) .

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

Doc, I have a SheevaPlug here. :-) That's the bare metal system I 
want to use :-)

So you can now for example make a server program that properly reacts 
to system signals

To get a handle on why Red/System tries to replace C, I think it's 
interesting to compare this function prototype:

Here's the Red binding, basically the same prototype in Red/System:

on-signal: "signal" [  ; Register handlers for receiving system signals.
	signal		[integer!]
	handler		[function!]  ; Flag or callback with integer! parameter
	return:		[function!]
]

my father would be a happy user probably, since he is using rebol/view 
now to write interfaces for those pic controllers he was programming 
in flash forth. however, im not sure if we can beat the interactivity 
of a forth system on such a resource constrained device...

onetom: I am also glad to see how it is evolving. About PIC support, 
these platforms might be too restricted for Red, but Red/System should 
be portable on some of them.

Doc - as Red/System is relatively close to its completion, are you 
already thinking about the implementation plan of RED itself? I still 
might not understand the architecture well enough (my fault, have 
not read properly docs yet), but what e.g. networking port code? 
Will that be written in RED? RED/System? Or will it be just some 
BSD library code linked to Red?

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.

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

Netduino: this is a platform that could be easily supported by Red/System 
once we'll have an ARM native code emitter.

Pushed a new commit:

- added support for callbacks (just place 'callback in a function 
attribute block, see http://static.red-lang.org/red-system-specs.html#section-6.3)
- specification draft revision 11

A few features are waiting for extra support in Red/System

Kaj: you can do an explicit casting, if is allowed by this matrix: 
http://static.red-lang.org/red-system-specs.html#section-4.7

So you are asking to make the type system even weaker, I thought 
you were a proponent of strong typing ;-)

Like in the case where users would link to their own external libs, 
where return values are prepared specifically for Red/System.

So, probably when Red/System will be rewritten in Red.

I would also adopt a fastcall convention as default for Red/System 
function calls.

Red/System can now generate dynamically linked ELF binaries.

Along with some additional pre-processor directives added (#if, #either, 
#switch), this now enables the Red/System runtime being fully writen 
in Red/System itself.

Steeve: which system image file have you used?

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

No console, but you can just use the system's console

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

That might only be useful with integer! as it should be extended 
to 64-bit when Red/System will be ported to 64-bit platforms. But 
I think that a specific macro would be more appropriate (something 
like integer-size?).

There is no such thing as a generic pointer in Red/System.

Well, I have already answered that question above. I am sorry if 
that change breaks existing code. Once again, the C void pointer 
is a very confusing concept that should not be used outside of C 
language. If you refer to a C void pointer without any context, it 
is just a memory address, so integer! (or handle!) would be the closest 
corresponding concept. If you refer to a C function returning a void 
pointer like malloc(), the closest transposition in Red/System would 
be ALLOCATE returning a byte! pointer.

So, in summary, there is no 1 to 1 transposition of the C void pointer 
concept in Red/System, it is 1 to 2 (or more), depending on the context.

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

There is no generic pointer in Red/System.

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.

on-signal: "signal" [  ; Register handlers for receiving system signals.
			signal		[integer!]
			handler		[function! [signal [integer!]]]  ; Flag or callback
;			return:		[function! [signal [integer!]]]
			return:		[handle!]
		]

Kaj has not yet updated the C library binding to the latest Red/System 
version.

Float support will either be added at Red level or at Red/System 
level, depending on how the Red compiler will be built.

Yes, it's not great, either. The problem with PRIN is compounded 
in Red/System because now you get prin-int and such

Another option could be WRITE, if it is not used latter in Red/System.

At Red/System level, we might have something like READ-PORT, WRITE-PORT.

Nope. I guess you have a console system now?

I should blame myself first to not have paid more attention in the 
beginning to avoid making Red/System's compiler dependent on REBOL/View 
features.

Have a look at the current ELF/PE emitters, for example:

https://github.com/dockimbel/Red/blob/master/red-system/formats/ELF.r#L87

https://github.com/dockimbel/Red/blob/master/red-system/formats/PE.r#L145

Well, I guess that we should start to do the same with Red/System 
very soon.

That would be good for the public. Myself, I would probably keep 
updating from trunk. I'm running a Git download through my Syllable 
build system to install a new version

unless all [
	(
		message: receive socket 0
		as-logic message
	)(

  prin "Received request: "  print as-c-string message-data message
		end-message message
	)(
		;wait 1
		send socket  as [byte-ptr!] reply  1 + length? text  0
	)
][
	print zmq-form-error system-error
]

You can't do such construction in Red/System.

Btw, allowed expressions are now documented: http://static.red-lang.org/red-system-specs.html#section-5.1

Red/System is not meant to be a REBOL replacement, you will need 
to wait for Red.

Red/System cannot be a REBOL replacement, it doesn't live at the 
same level of abstraction.

Btw, your code snippet could be rewritten as:

message: receive socket 0
unless all [
	as-logic message
	end-message message
	;wait 1
	send socket  as [byte-ptr!] reply  1 + length? text  0
][

 prin "Received request: "  print as-c-string message-data message
	print zmq-form-error system-error
]

I'll just rewrite it in EITHERs for now. I'm just noting that it 
can be made very nicely REBOL like to distinguish Red/System from 
C

Red/System will go beta as soon as I:
- fix the remaining bugs from the tracker,

- decide on 2 last syntax issues discussed on the ML (concerning 
struct/pointer literal syntax and aliases)
- make a pass on the specification to fix/update/complete it.

And then? RED language implementation, generating Red/System code? 
That will actually mean reimplementing all REBOL natives - how long 
do you expect it to take to get to an alpha? One year? More?

Yes, I should take the Red->Red/System compilation road.

It seems to be there : https://github.com/dockimbel/Red/blob/58afdfbf99699c7bcd3f57231edae9c495e00f99/red-system/tests/source/function-test.reds

Yes, I know a few potential Red/System testers that are waiting for 
that too.

Yes, I should take the Red->Red/System compilation road.

Right, I wanted to make a direct native compilation for Red too, 
but emitting Red/System might be shorter way to reach the goal.

As Red/System is a dialect of Red, the compilation should be quite 
easy to achieve.

I'm pretty certain that Nenad has said that he won't be adding binary 
floating point numbers to Red/System as they will not be needed to 
build the Red runtime. So at the moment, I would only expect them 
once Red is available.

Not anymore, because he has now decided to compile Red to Red/System, 
so Red/System will need full support

Floating point support should be added to Red/System if my tests 
shows that I can safely do the Red->Red/System compilation, else 
it will be supported at Red level. Anyway, it is not a priority for 
me, so it probably won't be added before Q4 2010 (unless someone 
wants to contribute by adding it to Red/System).

Robert: yes, as soon as we add DLL generation support in Red/System.

The 64-bit integer support might also be required in Red/System for 
that.

You mean in Red/System. Red does not exist yet.

Red/System can hardly be compared to REBOL, they don't live at the 
same level of abstraction.

As long as Red proper doesn't exist, I use Red to refer to Red/System 
:-)

Ah, yes, because it will be a binding for Red, even though the binding 
is written in Red/System

Since R3 bindings are written in C, their level is comparable to 
a binding in Red/System. But the dynamics are quite different, that's 
what I meant

The stack order for cdecl and stdcall (used by Red/System) is the 
same.

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')?

http://development.syllable.org/news/2011-07-05-02-54-Red-System-programming-language-now-beta.html

http://www.osnews.com/story/24921/Red_System_Reaches_Beta_Loads_Syllable_Shared_Libraries

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.

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

It also seems it's only required for system calls on OS X

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

But those defined in current Red/System runtime have an abstraction 
layer, so the runtime API is the same for users on all platforms.

I try to make sure that Red/System code can work the same on all 
platfoms (at least for 32/64-bit ones).

New editor in REBOL for Red/System : edit | compile | run for Windows, 
Linux, MacOSX !
http://www.red-chronicle.com/2011/07/new-red-editor-in-rebol.html

Red/System relies on shared libraries dynamic linking at load time. 
CPU and ABI specific calling conventions are handled by respectively 
Red's target emitters and file emitters. I don't see how libffi could 
make it simpler or better. From what I understand from FFI (very 
short) descriptions, it is more suitable for high-level languages 
that can't or don't want to deal with low-level interfaces.

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.

Load time = Red executable load time. The OS does the job of binding 
the required shared library and making their functions available 
to Red/System programs.

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

Red/System will not have high-level datatypes, but will be able to 
use the low-level methods of Red's datatypes if required (mainly 
for supporting Red). Anyway, Red/System is not meant to use those 
"boxed" datatypes, only low-level and close to the CPU types.

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

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

Got variable-arguments functions (with optional runtime type info) 
working in Red/System. Will release it tonight or tomorrow. RTTI 
is allowed only for variable-arguments functions for now. I could 
be extended to fixed arity functions,but only if I need it for building 
Red.

Well, then I am ok to add that libC init call in Syllable's runtime 
part (runtime/syllable.reds) as long as it doesn't need any other 
OS-specific additions in Red/System.

New attribute 'variadic documentation: http://static.red-lang.org/red-system-specs.html#section-6.3.3

New attribute 'typeinfo documentation: http://static.red-lang.org/red-system-specs.html#section-6.3.4

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

btw - what's the resolution re floating support in Red/System? Kaj 
is now trying to port SDL, so I wonder if for the gfx (which was 
not planned to be the RED's target),it will be the necessity,or not?

Floating point support will come to Red/System when the float! Red 
datatype will be implemented.

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.

so still mostly working on Red/System, to be powerfull enough to 
write RED in?