World: r3wp

(in this particular case, though, the situation is not much different 
for C)

maxim: yes

Kaj: "I tested the new section headers on Syllable Desktop.

memmap_instance() RO overlap RW (08048000 + 00001000 -> 08048000)"


besides the entry point address being a problem, this could also 
be due to segment alignment, which we basically ignore, at the moment. 
could you try changing "page-size: 4096" to "page-size: 1" and see 
where that gets us?

Judging by the tables, it looks like passing and returning structs 
in C is better done in internal code than in exported functions. 
There are too many exceptions and fallbacks.

I have to set the start address back to the Linux one to be able 
to compile with a changed page size

A page size of 1 works on Linux, but on Syllable the load error is 
still exactly the same

It seems logic! can't be used as a return value (last expression 
of a function) yet

When I use NULL I get a smaller executable than with 0. Is that correct? 
The Windows backend emits four bytes, but the ELF backend says something 
about ignoring NULL

NULL: a bit strange, need to check the sources for that.

logic!: that's odd, see the 'foo function in test-logic.reds (foo: 
func [a [logic!] return: [logic!]][a])

Types aren't checked yet, are they? I currently have the return type 
defined as integer!

Right, not yet. But the return type is checked when the function 
is used in an expression.

So, better get it right.

That doesn't make it work, though

-= Red/System Compiler =- 
Compiling /users/administrator/Red/reply-server.reds ...
*** datatype not allowed
at:  [false]
>>

Strange...will look into that in a few minutes.

The difference may be between a variable and a constant

Have you redefined 'false?

No, I'm not that militant. :-) I do

;#define no			false
#define no			0

where false doesn't work

I can't reproduce your issue here, can you give me a short example 
of a function making the compiler produce that error?

It must be this one:

send: func [  ; Send message.
	socket		[pointer!]
	data		[pointer!]
	size		[integer!]
	flags		[integer!]
	return: 	[logic!]
;	/local		message [pointer!]
][
	either zero? as-message message data size none none [
		either zero? send-message socket message flags [
			zero? end-message message
		][
			end-message message
			no
		]
	][
		no
	]
]

Ok, will try with a similar pattern of code.

Can't reproduce using:

bar: func [a [integer!] b [integer!] return: [logic!]][
	either zero? a [
		either zero? b [
			print "00"
		][
			print "11"
			false
		]
	][
		false
	]
]
either bar 1 1 [print "KO"][print "OK"]
either bar 0 1 [print "KO"][print "OK"]

I'll try that

This test code compiles and works OK.

#define no			false

is what triggers it

Ok, got it.

It is probably a 'false word reduction issue.

(in the preprocessor)

Kaj, I've just pushed a commit that should fix your issue.

Thanks!

The fix works; or at least it compiles now

Doc, did you consider using the set-word!  type for getting pointers 
to words?  much like we use them to get function values, instead 
of calling functions...

http://groups.google.com/group/red-lang/browse_thread/thread/6a7438458d2d170b

I believe that the same "get-word" syntax will be used should  function 
pointers be  introduced at a later date

Though neither of these items are on the current to-do list.

Maxim, that's the get-word! type. The set-word! type is used for 
assignment (setting).

I have already added the support for getting function's address using 
get-word! syntax (it returns an integer! value). Structs, c-strings, 
pointer are already passed by reference.

thx guys.

I'm a hudge militant of both the typed variable way (easy to interface 
C libraries) and the untype variable ( code more readable less maintenance 
etc...) This paradoxe tends to push me to imagine a world where the 
software will know what I need what ever the real sturcture behind 
is lets call it predictable type variable. How we do that ? I don't 
know but it seems fun enough to spend some brain cells  thinking 
of that. the idea is realy that interfacing external c/c++ java what 
ever library and maping it to the language innher variable and code 
will be absolutly transparent. (something like the .NET librabry 
browser but easier... Or more easyly we can have both system cohabiting 
side by side on the language schemes

though in rebol not having type for vars and () for function arg 
submition, make difficult to identify var content  distinguish var 
from function ... Maybe then  a syntaxique item like th e $ in php 
for vars or the @ in ruby for tables would be an interesting point... 
Sorry I try to think about rebol syntaxe structure like someone seing 
it for the first time

Shad, typed variables with type inference handles the readability/maintenance 
problem pretty well, which is why several statically typed languages 
have been retrofiting type inference into them recently. Fortunately, 
Red is planned around that from the start.


Your "predictable type variable" proposal (I don't know the standard 
term either) sounds useful. Many languages do this through reflection 
facilities, but that kind of thing requires dynamically typed variables 
at least as an option if you are going to use the reflection facilities 
of the language you are interfacing with - this is necessary for 
C++ at least because there isn't a shared standard for encoding that 
information in a static way. It would be more useful for integrating 
with .NET or CORBA objects, since direct field access is prohibited 
anyways for those so there's no extra overhead in the field access 
itself, just in the runtime discovery, and ahead-of-time static compilation 
has shared rules that work on a binary standard.

Somebody created an open source .NET Micro Framework port to Arduino 
http://netduino.com/netduino/specs.htm. It's an ARM7 based microcontroller. 
Is it possible that someday Red would be available on this platform 
(Reduino sounds really good)? Just dreaming... How would I start, 
if I could help?

Awi, that would be great, I would love to see Red run on such platform 
but I'm afraid Red's memory footprint would be a bit too high for 
a 60KB of RAM (but this might be specific to the netduino platform?). 
OTOH, Red/System compiler should work nicely there. If you want to 
help for such port, we need two things:


- a target file format emitter (I guess it would be the firmware 
file format)
- a native ARM7 code emitter as Red/System back-end. 


Let me know if you want to start working on these parts, I would 
provide additional documentations.

I think Red/System is already much better than .Net or C. I will 
look into both things you mentioned, but to be honest I have zero 
experience on porting. But let me see what I can do.

I think I am going to port Red to this USB key size platform, once 
available: http://www.raspberrypi.org