World: r3wp

No, you would qualify for the mentor part. So you'd have to find 
students willing to write open source Red code, and then you have 
to mentor them

It's very hard to get into SoC, beginning with the rush to register, 
and if you don't have the organisation to conduct the mentoring, 
or your project is too eccentric for students to get into quickly, 
it's fairly pointless

It's also questionable if the students will go on to maintain their 
code. The biggest advantage if you do get in is simply the marketing, 
because people suddenly think you're associated with Google

(and google also gets to notice you a little)

Yeah, so they can steal your ideas... I figure the cost is well worth 
it to them

Kaj: thanks for the insights.

Questions about the declarations.  

1-  why are you using this syntax for *all* declarations? : 
word: [datatype value] 

ex:
my-val: [integer! 20]

woudn't just this do ?:
my-val: integer! 20

I find its a hell of a lot easier to read,


and when you add type detection, its back to 

my-val: 20   


meaning that the integer! word really is just a typecast operation 
here.

since you are compiling and pre-filtering the source code, the integer! 
word really is contextual,  what it means is inherently bound to 
where its found.   so I see no issue with this use syntax.

anyone care to debunk me?  am I missing something?

Where have you seen: my-val: [integer! 20] ?

word: [datatype value]  => I don't remember writing that in the specs? 
Maybe a typo?

Oh, I guess you're just refering to pointer! initialization?

darn... I'm completely off.. yeah... I guess the old pointer documentation 
got me all mixed up.

Doc, I have to say, the red docs are getting really nice.


its clear now, and I was talking nonsense... I should have gone over 
them... will make sure to visit each time. they've significantly 
updated since last I visited.

I was just taking a little break from all of the cheyenne dev.

they've significantly updated since last I visited

 You are too used to R3's monthly updates...it's Red here, it's updated 
 daily ;-)

hehe

yeah, I forgot that Red lives in the same space-time continuum as 
the rest of us humans  ;-)

If you have looked at Red sources since a long time (like a week 
;-)), you should look at the Quick-Test framework added yesterday 
by PeterWood: https://github.com/dockimbel/Red/tree/master/red-system/tests
(see the readme.txt)

have => haven't

cd %red-system/tests/
do %run-all.r

That's cheating, that was ported from Boron ;-)

hehe :-)

Kaj: BTW, Andreas added ELF sections table support a few days ago, 
so, does it help a bit loading executables on Syllable?

Yes, I saw that and want to test it, but I'm very busy. Maybe I'll 
get to it tomorrow

Kaj :That's cheating, that was ported from Boron ;-)


Not true. That was my initial intention but simple-test was felt 
to be too heavy for Red/System so I built a lighter one.

By the way, the boron framework was ported from REBOL ...
.... and back again :-)

OK. Sorry, I didn't mean it in the strict sense, more as predecession 
:-)

Given the potential licensing issue, it's best to be careful about 
that. *GPL is a one-way street.

simple-test.b is just a script written in boron. I don't believe 
it is GPL because of that just as all Java code is not GPL because 
Java is GPL.

Cool.

Though the "all Java code is not GPL because Java is GPL" thing doesn't 
apply to GPL2, which is why the Classpath exception was made. GPL3 
fixes this though.

Oh, I didn't realise that Java was released under GPL2. I thought 
it was only under Sun's proprietary licence until it was issued under 
GPL3.

(getting off topic) The main problem was that GPL2 code *written* 
in Java was illegal to *run on* proprietary JVMs and link to even 
the bundled Java libraries. The same goes for GPL2 code written in 
REBOL. LGPL2 is a little more legal for running on proprietary languages, 
barely.

There were and are a lot of popular GPL2 apps written in Java, but 
none of them are legal to run (ish, depending on distribution).

(closer to on topic) The same goes for GPL REBOL scripts, like the 
BEER framework before its relicensing.

Brian, please, this is just FUD. There is no GPL in play at all here. 
Boron is LGPL

I notice you write *GPL, and while I could agree with stating that 
GPL is a one-way street, LGPL is not

LGPL projects can be mixed with or incorporate code of other licenses, 
with some acceptable limits, more or less. However, the code itself 
can't be adapted to projects with more permissive or closed licenses, 
without carrying over those restrictions, or in the case of LGPL 
quaranteening the code in seperately linkable portions. Less restrictions 
than GPL, more than Classpath, but still one-way. Not FUD, but definitely 
off topic.

Porting code in Boron itself - rather than code that was just written 
in Boron - to Red itself without relicensing it would make Red mixed-license, 
BSD and LGPL. Going the other way, porting code in the Red project 
to the Boron project wouldn't affect the license of Boron; it could 
stay LGPL only.

None of this affects user code written in either language though.

And the original authors of any LGPL code in Boron could relicense 
it as BSD if they want it added to Red. No problem, if the author 
agrees to it.

quaranteening -> quaranteeing

I miss the auto-spellchecking of web browser text boxes when in AltME 
:(

I believe that it is most unlikely that any code will be ported from 
boron to Red because Red will first be written in REBOL and eventually 
in Red whilst boron is written in C.

Yes

Brian, it's FUD because you are changing the topic. You're jumping 
from the effect of the licence of platforms on application code to 
the ability to mix and match platform code

You're also steering the topic to discussing the GPL, which has nothing 
to do with this

None of this affects user code written in either language though.

When I realized that Peter was talking about user code, not code 
from Boron itself, I said "Cool." and then just clarified something 
based on what Peter said next. It was not steering the conversation, 
though I apologize if it gave that impression. License compatibility 
for contributions is a real problem (which is why I reacted to the 
FUD remark), but it is a problem with limited scope, and is solveable 
even within that scope. My response to that FUD remark gives the 
overview of the limited scope of the problem, and how to get around 
it (relicensing with author permission). No unsolveable problems.

I am firmly of the belief that all problems are solveable, so FUD 
is against my principles. Sorry if I took offence at your initial 
FUD remark.

I am sure you mean well. That's why I keep pointing out that these 
issues should not be conflated :-)

Peter changed the topic when he said "I don't believe it is GPL because 
of that just as all Java code is not GPL because Java is GPL.", and 
that is what needed clarification. Unfortunately, I couldn't move 
that message to the Licensing group, or edit my responses to be more 
clear (stupid AltME).

Sorry, that went in the wrong group.

What about using just:
	p:   integer!
instead of:
	p:   pointer [integer!]