World: r3wp
[All] except covered in other channels
older newer | first last |
Steeve 1-Apr-2009 [3462x2] | To be honest, i can see his point. If instead of failing on the first error encountered, we could have a load-foreign which accept a user call back function, each time an error occurs. Then, we could do some handy conversions meanwhile the loading process. Don't say it would be a useless thing guys. |
it's easy to simulate with transcode and parse but we need speed here | |
BrianH 1-Apr-2009 [3464] | Failure is your friend. If it doesn't fail on errors, you can't trust the output and yo have to do the error checking in your code. |
Steeve 1-Apr-2009 [3465] | i'm not talking about the standard behavior of LOAD here |
BrianH 1-Apr-2009 [3466] | But he was. |
Chris 1-Apr-2009 [3467] | 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... |
Gabriele 2-Apr-2009 [3468x2] | 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. | |
Steeve 2-Apr-2009 [3470x3] | 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) | |
[unknown: 5] 2-Apr-2009 [3473] | 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. |
Steeve 2-Apr-2009 [3474x2] | want to be done in real-time, with a jit library. Not with intermediate files and slow compile time |
need to inject code | |
[unknown: 5] 2-Apr-2009 [3476] | SLOW compile time? Assemblers are using macro's already and compiling extremely fast. |
Steeve 2-Apr-2009 [3477] | 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 |
[unknown: 5] 2-Apr-2009 [3478x3] | 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. | |
Steeve 2-Apr-2009 [3481x2] | 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 | |
[unknown: 5] 2-Apr-2009 [3483] | Go for it Steeve. |
BrianH 2-Apr-2009 [3484] | 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). |
btiffin 3-Apr-2009 [3485] | 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. |
BrianH 3-Apr-2009 [3486] | 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 :) |
btiffin 3-Apr-2009 [3487] | Go Hawley Go! |
Maxim 3-Apr-2009 [3488] | an accessor like /load ? ;-) |
Oldes 3-Apr-2009 [3489x2] | 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. | |
Pekr 3-Apr-2009 [3491] | What about JIT method for AGG I posted earlier? |
Oldes 3-Apr-2009 [3492] | that's it.. blitjit is based on asmjit |
Pekr 3-Apr-2009 [3493] | is that cross platform? |
Steeve 3-Apr-2009 [3494] | yep cross platform |
Pekr 3-Apr-2009 [3495] | Then we should order Cyphre to do few AGG tests :-) |
Steeve 3-Apr-2009 [3496] | Simulating AGG is not the main aim here. The first target is to replace rebcode in R3 |
Pekr 3-Apr-2009 [3497x2] | 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 | |
Steeve 3-Apr-2009 [3499] | i started my own thread :-) |
Pekr 3-Apr-2009 [3500] | HLA? |
Steeve 3-Apr-2009 [3501x2] | no |
here | |
Graham 3-Apr-2009 [3503x2] | just wondering .. how many error free LOC should one expect from a REBOL programmer in an hour? |
I'm guessing one line a minute. | |
PeterWood 4-Apr-2009 [3505x3] | 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. | |
Graham 4-Apr-2009 [3508] | 50 lines per day? wow. |
PeterWood 4-Apr-2009 [3509] | 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"]]] |
Graham 4-Apr-2009 [3510] | I'd rate the 2nd line as 5 lines |
PeterWood 4-Apr-2009 [3511] | 50 lines per day was twice the average for in-house companies which was one factor in the company's success. |
older newer | first last |