World: r3wp

But he was.

I'd say there is a case for adapting Rebol's vocabulary, eg:


 measure! - proposed a long time ago - 2cm 3.4cl 5o (degrees) 1em 
 - found elsewhere, eg CSS

 date! - recognize some common alternate constructs - 12-Mar-2009T04:00
	money! - the suggested: $1,000.00


I'd love to see Rebol mature along these lines.  The literal types 
are the essense of Rebol's being, they make for expressive problem 
solving and efficient data exchange with some resemblence to terms 
we would use on paper - all with 'load as its core arbiter.  It'd 
be great to be able to extract meaning from any stream of data, and 
I think if any language can, it's Rebol - however, it just seems 
beyond the scope of 'load which has this specifically and valuably 
defined purpose.  Whereas 'parse can be used to describe anything! 
- even if you load junk!, you're still going to need 'parse to make 
sense of it...

callback on error
 - how is that different from using PARSE and LOAD/NEXT ??

Chris: that is a whole different issue. , in numbers does not work 
because REBOL allows 1000.00 and 1000,00 to be the same thing, though 
with some euristics we might be able to make that work. euristics 
are bad for a language's lexicon though. instead, like to date! does 
(wrt load) I'd rather have to decimal! (etc.) to be smarter.

Has someone done some test with a JIT library ?
For example to be used with a little VM to replace rebcode ?

As I see the problem, it would be:

1/ create a compile function in Rebol using parse to translate a 
dialect into some bytecodes.
2/ call an external (dll or so) tiny virtual machine.

3/ The VM uses a JIT libray (ie. AsmJIT) to convert the bytecodes 
into ASM instructions.
4/ the VM execute the code

could be faster than rebcode (especially the loops)

Well if your going to go that route why not just use REBOL to create 
a MACRO language that outputs assembly code?  That would be rather 
easy to implement.

want to be done in real-time, with a jit library. Not with intermediate 
files and slow compile time

need to inject code

SLOW compile time?  Assemblers are using macro's already and compiling 
extremely fast.

but how do you inject code in your running application without a 
good framework to do that.
You can't just throw a bynary stream in the heaven

I wasn't objecting to your comment about injection.

I'm not agreeing with it either.

But if that is what you desire go for it.

give me a dll wich accept a binary stream and run it as a function 
and i'm ok to generate assembler with rebol

*which

Go for it Steeve.

Gabriele: "callback on error" - how is that different from using 
PARSE and LOAD/NEXT ??

It's *much* slower (according to Carl). That is why he decided to 
handle this with TRANSCODE/error (which returns the data so far, 
an error object, and the next position), rather than TRANSCODE/else 
on-error (which would have called the provided on-error function 
when there was a parse error).

Gabriele; Ahh ... lights are coming on.  MAGIC lights.   ;)  Ok, 
I can see how the success backtracking could lead to more grief than 
I originally imagined.


So now I'll shutup on this ... until we see what comes of user types 
(if we get 'em) mixed with transcode/error.  Could be cool.

Don't worry, I'll be sure to play with TRANSCODE/error until I can 
make it do magic tricks - it's already helped in LOAD :)

Go Hawley Go!

an accessor like /load ?    ;-)

Steeve.. how can I help you? :)

It would be fine to have AsmJIT integrated in REBOL as it could be 
used to speed up blitting as well.

What about JIT method for AGG I posted earlier?

that's it.. blitjit is based on asmjit

is that cross platform?

yep cross platform

Then we should order Cyphre to do few AGG tests :-)

Simulating AGG is not the main aim here. The first target is to replace 
rebcode in R3

ah, but you surely noticed what initiated this discussion? It was 
some test some guys did with the lib for AGG.

http://code.google.com/p/blitjit/- BlitJit is based upon ASMJit. 
I am all for RebCode replacement, especially as RebCode turned out 
to be rather slow to R2 version

i started my own thread :-)

HLA?

no

here

just wondering .. how many error free LOC should one expect from 
a REBOL programmer in an hour?

I'm guessing one line a minute.

That would be very high but it all depends on your definition of 
LOC written. Does it include undertanding (or even analysisng) the 
requirement, desigNing the script, coding, unit testing, system testing, 
acceptance testing and documentation?

When I first started work, our LOC metric included understanding 
the spec, flowcharting the program, coding (on paper - wihich was 
then punched onto cards), compiling the program, desk checking the 
program and unit testing.

We averaged 50 line of PL/1 code per day on that basis.

It is easier to write PL/1 code than Rebol because each line does 
much less.

50 lines per day?  wow.

With extrremely powerful languages like Rebol, LOC is even less reliable 
than less powerful languages. Are these comparable:

a: a + 1


repeat n 100 [if not error? try [close open probe join tcp://localhost: 
n] [print [n "is open"]]]

I'd rate the 2nd line as 5 lines

50 lines per day was twice the average for in-house companies which 
was one factor in the company's success.

I think lines of code is a pretty useless metric. Some lines are 
much more difficult to find than others.

and it is made less useful by the million different definitions of 
writing a line of code.

Graham: A good figure for you would be to count all the lines of 
code in Synapse-EMR and divide by the total number of hours you have 
spent working on it.

That's if the program you're comparing with is similar to the size 
and complexity of Synapse-EMR.