World: r3wp

I wonder if there would be someone so insane to try convert rebol 
interpreter iself into rebcode :-)

But we are talking rebcode, and rebcode can do more. for example 
you can write a forall in rebcode, but not with routines.

... hmm, that would be slower after all, forget that ....

I guess Carl will be that insane, one day, in hollydays. :))

Pekr, that's the compiler I was thinking to build :)

I guess Pekr did not mean to compile rebol, but to have a real interpreter, 
as the one which is now in c.

or?

Volker, I know, but some time ago I though that e.g. you have rebol 
block for e.g. and I thought that there might be some api, kind of 
DOM, so that from C library, you would access it via such structure 
and you would manipulate rebol datatype value directly

I e.g. did small dll some time ago to do some histogram etc. stuff 
with image. Image is easy - four bytes of values per pixel - worked 
well, but I modified binary value directly. Now imagine how would 
you work with rebol block in C level eventually :-)

Yes, that is what i would want too. then you can jit rebcode with 
a c-compiler.

Volker, I've heard that some people are trying to make tcc portable 
(to ARM so far) but they aren't that far yet.

That's why I suggested LLVM.

AFAIK AmigaDE has good compilers for various cpus, around 40k. But 
that means money.

Or for that matter, Mono is available as a library, and you can access 
the .NET runtime that way too.

Or java. Problem with that is, they are not optimized for unions, 
and rebol depends on them.

Oh well, now that there is an official (alpha) release of rebcode, 
I submitted my HERE directive to RAMBO.

But Carl said once, a good jit like ADE would take him a month. Now 
if we can put him that long on vacation.. :))

BrainH: use RT Q & A group here, that might be faster :-)

hmm, but most of that stuff is several times the size of rebol itself 
:-)

Jump on Gabriele when he shows up..

Isn't there really a stuff like 40KB, free, crossplatform, so that 
we could have it "onboard"? :-)

I tried that. It only worked with things they were already working 
on. Gabriele and my sleep schedules have very little overlap :(

IIRC tcc is around 100, but with c-parseron board.

Pekr, that would mean Forth :)

BrianH: if HERE is really important, then I suggest you to use even 
more drastic methods to get Gabriele's attention, like telling him 
Pizza and Spaggeti don't come from Italy and that Italy can't play 
decent football :-))

I've never seen an Italian try to play football. Oh, do you mean 
soccer? :)

yes, soccer, they are quite good in it :-)

Never been to Italy (that includes DevCon2005, darnit), so I'll take 
your word for it.

BrianH - where're you from?

Chicago, Illinois, USA

Spaggethi not from italy? MAybe this helps arguing? http://science.slashdot.org/article.pl?sid=05/10/15/022201&tid=14
:)

that's quite far away from here :-) But isn't it close to Sassneranch? 
Maybe you could visit Carl to talk to him personally :-)

Ah, but proper pizza is from Chicago :)

:-)

That's more than a thousand miles away. Not a quick jaunt.

Mapquest say that just to get to their zip code, it would take 31 
hours 55 minutes in time, 2194 miles in distance.

i already asked Carl about HERE. he hasn't aswered yet, but that 
does not mean he won't.

In rebcode, testing not x, before ==> after:
true  ==> false
false  ==> true
none  ==> none  (three-valued logic, SQL here we come)
1  ==> 0  (bitwise)
1.0  ==> 1.0  (unchanged)
a

  ==> REBOL goes away without warning (where's that type inferencer?)

Thanks Gabriele! I wasn't meaning to be a jerk - I meant it about 
Carl being busy :(

Now you have a nice RAMBO entry to work with.

indeed, i was referring to Petr's message, rather than yours. :-)

Well, I think putting an entry in the Rebol Enhancements group or 
in RAMBO beats drivinf 2194 miles :)

What did Carl mean about rebcode modifying memory? I'm a little worried 
about these use-an-opcode-wrong, REBOL-goes-away errors.

That  NOT x  crash can be worked around by doing a  SETT x GETT x 
 to make sure the value is compatible.

That or be extra careful with specifying those argument types to 
rebcode functions.

you should always specify argument types for REBCODE functions...

and... use the TYPE? opcode when you cannot determine the type in 
advance.

anyway... i think there's still a lot to improve in this area...

I would prefer opcodes to just don't do anything when given bad arguments, 
instead of crash REBOL with a core dump, as a general rule.

You all have been improving rebcode greatly in that respect so far.