World: r3wp

Um, you must not be working on the same things I am. I do tough stuff 
in pure REBOL quite often. The only C I see is there to implement 
low-level dialects used by REBOL, but those aren't as often needed 
as DO or PARSE dialect code.

that's only usefull if your are sure this extension will be extensively 
used. What interrest me is doing rebol and ways to bring into rebol 
the now in day possibilities .. remember that rebol was designed 
around 1998 at that time processors where mono cores GPU  where a 
joke.(GPU 100MHz with 64Mo do GRAM and CPU 433Mhz SDRAM 133 MHz)

we are 10  years after that design ... can rebol continue to say 
ok the harward evolved but i refuse to use it ?

One of the things that the modern multi-core language research has 
discovered is that shared-memory multithreading is often a bad idea, 
and that multiprocessing with asynchronous IPC is more reliable and 
scales better. And cooincidently enough, multiprocessing is the method 
REBOL uses. Now all we have to do is get the processes smaller and 
the IPC (/Services) more efficient.

i think now in day hardware capabilities are introducing alot of 
 problems in software parallelisation strategies (wich had been always 
the case) that's a field i think rebol should explore and propose 
it's originality  to solve that increasing difficulty.

hum yeah but that  solution apears to the rest of the world like 
a joke .. face it ... we are less than a thousand people really caring 
about rebol's futur ...

The strength that REBOL has is that it is relatively easy to create 
a dialect with different semantics, because we have so many good 
tools to help with the implementation, more all the time. So REBOL 
becomes a good platform on which to do those experiments. And we 
always have the old-school single-process DO dialect to fall back 
on.

try to talk asynchronous processing with a guy doing java threads 
programing all day long that's interesting ...

Yeah, we could probably boost all view stuffs by isolating the rendering 
engine in a distinct process.

asynchronous have a weak point the data flow processed should not 
be to much ..  so for example if you want to put cheyenne on his 
needs you make it relay a webradio streaming for example

Threads was considered to be the solution last decade. And that is 
why we have a multi-core crisis now, because threads are not a good 
solution. That is why the main research not is in active objects 
and green processes.

on his needs  = on it's knees ...

not -> now

BrianH ok but who promote that way of thinking and multicore crisis 
is mainly do to the shared memory and to the weak memory controller 
completly saturated with date flow from CPU and from GPU

that's why intel/ nvidia  APPLE (in a lower extends all smartphone) 
and AMD/ATI are doing or announcing he merge of the Memory controller 
the CPU and the GPU  into a single unit

Um, that is not the multi-core crisis. The real crisis is that it 
is very difficult to break a program into threads, and even more 
difficult to manage shared state. This is why there are so many issues 
with locking and such.

It's a programming problem, not a hardware problem.

the A1 chip in the ipad for example already is a allin one chip  
and the preformances are better because the software is better too 
but because the hardware is specificly designed to feat it

that's a thing only a closed disgn 100% controled  like the apple 
one can offer

Chips in handheld and embedded systems aren't that multicore yet, 
so they can still be programmed in the old ways (like Java).

brianH that's why before the multi core processor you had multi single 
cores dedicated memory architecture and you still have that design 
in the MEGA ULTRA COMPUTERS

and yes writing programs on those computers means a specific knowledge 
.... Problem is the industry said to the code continu to code the 
way you did so fare the hardware will optimise it

wich obviously isn't the case

Yes, but those mega-utlre computers are just a sign of where things 
are going. On the bitty computers you can still party like it's 1979, 
but on servers you are starting to see cores in the hundreds.

And only on the manyi-core computers is multitasking a real problem 
that needs new language semantics. On the old or bitty systems REBOL-as-it-is 
will do fine.

(I agree, sometimes you have to use the aA button to increase the 
font size.)

well problem is when you have several chips then you have to design 
alot of bus wich enhance alot the price of the computer imagine those 
computer have over a hundred or a thousand processor

ich individual processor is weak  but all together with a well coded 
software they are blasting

anyway you won't play halo 4 on them so what ever what the people 
buys today are games

game industry is a 90 billon dollars market ...  if rebol can be 
used to solve most ot the coding problems there i would say why not 
?

I don't design hardware, I design software, or tools to build software. 
And different hardware sometimes demands different semantic constraints 
on the tools to build the software. The multi-core crisis isn't affecting 
hardware as much as it is a crisis of development tools that need 
to write software for that hardware.

BrianH that's why we need rebol there

but rebol using 100% my CPU  to draw 3 lines on screen i say NO ! 
you see my point

I like REBOL because it makes it easy to write development tools. 
And that will inevitably include tools for massive multitasking.

ok the software can be optimised and R3 and  R2 differencies in software 
design and rendering potential already shown a big improvement

Tools for graphics too, which others are actively working on now. 
And once AGG is reliably in the host then the whole (qualified portion 
of) the community can work on optimizing it.

and that's not even using the grace of my new hardware   i use that 
rebol script on my desktop computer or on netbook the results will 
be the same even if my desktop is hella goliath and my netbook is 
hella the small thing ... So people will say hey that's fantastic 
same animation run anywhere with same results (much or less ) but 
i would say  ... hum no

But GPGPU tools are a separate issue, really, even if they run on 
the same hardware. The workloads are semarate and have different 
semantics.

semarate ->separate

every time carl share a benchmarking with us on altme i come with 
a benchmark 70% percent (minimum) under this benchmark ... for non 
graphical computing  so this deferency exist in rebol in fact

but  when you enter the graphical area it like a normalised dimension 
where any hardware produce the same rendering

and i like to optimise things i  like to be able to detect hardware 
and adapt my code to it and there  i think the ability of rebol to 
write in fly it's own code could be interresting

Yes, and? We can create dialects in R3 right now that are processed 
with native code; we've had that ability since the first extension 
model came out. If you want to make an optimized dialect, go right 
ahead. Cyphre is working on one, I have one on my list, others are 
considering working on them too.

i don't even know how to use parse lol ... doing a dialect maybe 
next life ...

OK then :) It's all well and good to complain about stuff, but getting 
stuff done requires contributions, either of effort, money or in 
some cases research. If you can write a good enough spec, it makes 
it easier for someone to implement it. Short of that, it gets a little 
tiring to hear that REBOL isn't good for this or that workload, when 
it is already good for other workloads. If you think that REBOL has 
a weakness that can be resolved in some way, help resolve it. Otherwise, 
use another tool :)

For instance, I remember some guy named shadwolf helping resolve 
the lack of a rich text editor in REBOL :)

I can express needs and do remarks without knowing how to do them 
 and brianH i think i proved when i know how to do something i do 
it and then share my knowledge with the bigest number possible

yeah but the solution i  proposed could be way more sexy and without 
alot of work ...

and redering a text only document is not the same as rendering a 
web page for example ... we are one step closer to that goal when 
i proposed a AGG only engine people told me it's impossible and steeve 
made that vision come true ...

Maybe I'm just interpreting the vast amount of words you write about 
any subject as harping. If I could type that fast, I'm sure I'd be 
as verbose :)