AltME groups: search

Carl's question on R3 Chat:

#7301: post from Carl 36m ago:
FOR can include tail. Do we want to keep that behavior?

>> for a b: "abc" tail b 1 [probe a]
abc
bc
c



This happens because FOR is inclusive on its END value. (Remind me 
if we've talked about this before.)

So slow that we are better off not having such a feature, having 
to rewrite our code so we don't need to do that at all.

Remember, IN whatever block! is usually preceded by DO. You don't 
want to remove words from code you are going to DO.

yes Carls is struggling, but by what I hear, he really is committed 
to doing it.   he WANTS to do it... its just that he's realizing 
how deeply rooted the view code is... all kinds of tricks now have 
to be architectured and properly APIed.

Wouldn' t it be nice to do something like this:
a:   5
b: a < 10

where b gets set to the value of a instead of true?

See wouldn't that be a better way to do things?

That seems to be in line with simple thigns should be simple to do.

The feature I use often is a reference to the boolean stuff.  We 
can do that part in REBOL already - always have been as far as I 
can remember.

Paul, aha, you do not like the prefix form, and insist on the infix 
form you wrote. Then I have a surprise for you: it isn't REBOL Do 
dialect, since the Do dialect does not allow the infix op to take 
more than two arguments. Nevertheless, you are totally missing the 
point stating, that it would require changing the tokenization - 
that is patently wrong.

Sure it would be - just do a TRACE and you will see that it has to 
be changed.  Do evaluates - it has to be supplied the correct structure 
in order to evaluate correctly.

It cannot help you state that. I can prove you false if I decide 
to do so.

No change in syntax or parsing would be required. However, the DO's 
evaluation rules for the set-word expression *would* need to be changed. 
Note that these evaluation rules are *not* performed by a parser, 
so changing parsing would not be required, Paul.


However, this change to the evaluation rules of the DO dialect would 
be so fundamental that we would essentially be changing the semantics 
of the language to that of another language. And that other language 
would resemble Icon more than it would REBOL, semantically. And changing 
the behavior of the SET, LESSER?, ... functions would not be enough 
because DO doesn't actually call those functions directly - it calls 
internal code, which may or may not also be called by those functions.


But this is not a problem, because at least you wouldn't have to 
change the parsing. This means that all you would have to do is write 
your own evaluator and pass the code to that instead of DO. And create 
new versions of all the functions that call DO internally, behaving 
the same but calling your DO replacement instead. And create a context 
to reference those functions, and bind to that context instead of 
the standard system context. Basically, all you have to do is create 
a new dialect on the scale of the DO dialect, using the same REBOL 
parser, but different semantic rules.

`b: a - 3 > 11` is *not* syntactic sugar for `set 'b greater? subtract 
a 3 11`, instead it is sugar for the internal code that those functions 
call. So changing the meaning of those functions wouldn't be enough. 
To really make the change, you would have to replace DO. But not 
completely, because all of our code depends on DO remaining as it 
is - so you would need to make a new sort-of DO-like dialect that 
would be used in addition to DO, for those circumstances where you 
need this semantic model. Just like any other additional dialect, 
really.

On the other hand, if you want to change DO's behavior to this, then 
it would require you to create a *new* language, with the same parser 
as REBOL, or one that is completely compatible. Basically, an incompatible 
REBOL clone. It would be hard to use the same parser though because 
the existing runtime code depends on the current semantics, so you'd 
have to replace that code too.

Perhaps Carl has not had time to test it under R3, so it is not properly 
certified.


Superficially, parse-xml seems to work under R3......If you had the 
time to do some more comprehensive testing, that may encourage Carl 
to make it part of the official release.

To export parse-xml from R2 and import it to R3:

In an R2 session: [r3-path] is the path to your r3 executable

    save %[r3-path]/xml-language.r join "xml-language: " mold xml-language

    save %[r3-path]/parse-xml.r    join "parse-xml: "    mold :parse-xml

In an R3 session:
    do load %xml-language.r
    do load %parse-xml.r

Prove me false ladislav.

 - I do not want to, having observed other people to do just that 
 without their effort being of any observable help to you.

pekr... stripping view out of core and making it work again is probably 
the most complex task Carl has had to do since he's been working 
on R3.


it means he has to formalize quite a few of the core as official 
APIs which he didn't need or intend to do at first.  He  didn't  
*design*  the core with view extraction in mind.  it was a far distant 
goal... as in "someday we could extract view and make it an extension".

Claude, the R2 mezzanine source, including PARSE-XML, is in DevBase 
(aka R3 chat). It shouldn't be too difficult to adapt it to R3, for 
a library module. It would probably be a bad idea to include it in 
R3 as mezzanine though: History has shown that most people don't 
need to parse XML, and the ones who do usually need to parse XML 
differently from how PARSE-XML does so, and differently from each 
other as well. This kind of situation is what the module system and 
community libraries are for :)

why not rebol ,,, serriously if you have to fall that low as using 
javascipt + QT for you gui only to say we do quick qt developpements 
why not using rebol?

Max... I'm curious... how do you know that Core was not designed 
for View to be extracted? Did Carl tell you this or are you guessing? 
Because, you know, Core was developed by Carl and View by Cyphre, 
and Cyphre never had any access to the Core sources.

brian, do you think it would be possible to have postix operators 
in REBOL's do dialect?

yes I can see that there would require a little change in the op! 
datatype to let do know how to handle values before & after, but 
the dialect itself isn't limited in the sense that it couldn't be 
modified...  just being curious for discussion's sake... not a request

Peterwood not only C/C++ the ++ operand exists in most of the languages 
now in days compiled or interpreted... (python, perl, tcl/tk, ruby, 
java, etc...)

most people want i++, instead of i= i + 1 but i always thought the 
right operand instead of "++" should be "=+"  somthing like i=+ is 
in my opinion more explicit...


Pekr; some time the Carl says things we can't understand and mainly 
cause we don't have a full view on the source code he is talking 
about...

modular coding is obvious but  you have several ways to realise it... 
puting preporcesor flag to include or not part of the code when you 
compile is one solution

having them indeferent folders and binaries or libraries is another.. 
And that was always one of my  biggest comment rebol wants to do 
all every where so it ends being

weak every where and doing incompletly most of the things it pretends 
to do ...

Graham:

If I want to set something to the index of a series, or something 
else if it's not there I have to do this

b: either a: find series var [
	index? a
][ 	default ]

when I'd rather do

 b: any [ index? find series var default ]

So how about letting index? also take none as an argument ?

Do we have anything in R3 that equals PREBOL? I use this pre-processing 
quite a lot to include code (features), logos, colors etc. user dependent.

Is it really so bad to do conditional code with conditional code? 
We have IF, EITHER and UNTIL for a reason. They are not awkward.

Btw, "it's on my list" is more of a desperate cry for help nowadays. 
It's more of a "it's on my list to get done, because it's needed". 
Actually doing it myself is the last resort; getting someone else 
to do it is the preferred method. I'm more than happy to provide 
advice, but it's hard for me to budget time to program this myself.

Mixins in R3 often serve the purpose that #include did in PREBOL, 
but currently need to be loaded from files at runtime. We need a 
preprocessor in order to get the mixin functionality from embedded 
modules. This is what is needed to do the R3 equivalent of encapping 
(host builds).

If I have to do this, I won't even be able to start until some time 
in June - I'm mostly out of town this month.

Carl is working on bug-fixing, did two releases last week, and is 
working on extracting view from the core, which he has stated a while 
ago.


What do you want Carl to do more?     AFAIK, there is nothing "unknown" 
right now.   we are simply waiting for Carl to finish this cumbersome 
task before any  of the above *can* be done.


so far, Carl has been telling us everything he's doing every step 
of the way.   some things just take time.  its not as if Carl is 
waiting doing nothing.  

He's been working his ass off  tackling huge items on the list.  
Some of the very things you (and many of us) have been "complaining" 
about for years.

You do realize that Carl went to a conference after a99, right? He 
twittered about it and everything.

Max, Robert - thanks for offering Carl a help with the Help Kit maintanance. 
If we do it, I buy Android phone to test R3 :-) I was also thinking 
about the Beagle board, etc. Simply I would like to see R3 on ARMs, 
as in mobile sphere, they are - everywhere ...

Are these more versatile than a plug computer? I guess so if you 
want to use 3D and the other media related IO ports, but otherwise 
how do they compare?

I don't think you should do that yet. Wait 6-12 months and see what 
tools are around. What RM Asset is developing is mostly backend/tools 
stuff, to make sure that developing boring business apps becomes 
a smooth and quick process and some of these things wouldn't work 
well in R2 or would be hampered by various already known showstoppers. 
We have to think forward and build this stuff under R3 now, otherwise 
we will have two things: A fast and poorly supported platform to 
build apps on (R3) and a slow and limited platform to build apps 
on (R2), and we don't want that, do we? Besides, RM Asset already 
has some target apps in mind for R3.


Also given how R3 uses a hostkit, gives everyone much more control 
over how they want certain things done or add special extensions 
to, say, graphics or database capability without having to ask Carl 
to add it.


I think you will appreciate that this stuff is done first, so you 
can build a good app in a few days, rather than spending 2 months 
doing it. It'll save you a good bit of money too. This involves GUI 
test tools, customer feedback mechanisms built into the GUI, quickly 
integrating a GUI with a database, completing the GUI generally, 
various extensions, such as the high speed networking extensions 
needed for xpeers-II.

why I can't do [to word! #issue], while I can do [to word! to string! 
#issue] ?

I know some people got a hold of it a while back - is it just a matter 
of asking? Actually (I posted about this in chat), I need to do callbacks 
into REBOL so if that's not working yet, I'm out of luck. This is 
in regards to creating an external lexer for the Scintilla based 
editors out there.

I know I'm a freak  and that most of my asks / comments are shaking 
you in fear but is there any rebol3  dicussion group   in  google 
WAVE ? 



How could such a tool help us  to get a better link with carl or 
maybe on some specific point  get a better help fro the community.


For example i don't feel able to make a whole R3/Vid alone but i 
feel like to contribute apporting ot R3/VID what i do best some widgets 
 and as i'm not alone able of it maybe a goo emulation can be created.

Max, tell AND show us how you do the callbacks. IMO if you have found 
a way to do it now, we all should know it. It would speed-up R3 extension 
development a lot. And a good base of extensions is mandatory for 
R3 success. So every day we are faster helps us all.

the simplest solution I found was:


1) make an extensions which has storage for both  Reb_Do_String and 
Reb_Print    

2) add a function which accepts two function pointers and assigns 
them to these (library local) pointers
3) load the library in your host, use the callback setup function
3) call these functions pointers within wrappers.

4) that's it  works  VERY well, very fast, and bug free in my tests. 
 :-)


This works under MSVC , and when I researched the dll memory allocation, 
it was totally safe, by all accounts.

In windows, On dll allocation, each process gets its own library 
memory space. 



exerpts of code I had to screw around to find and make work (should 
be obvious to C coders):


the following was broken up in a few files, again, how to split this 
up will be obvious to those
who really need it.


#define EXPORT __declspec(dllexport)

typedef REBFLG (__cdecl *DoFunc)(REBYTE *text);
typedef void (__cdecl *PrintFunc)(REBYTE *text, ...);


DoFunc Reb_Do_String = 0;
PrintFunc Reb_Print = 0;


void EXPORT SetupCallBacks(DoFunc callback, PrintFunc pcallback){
	Reb_Do_String = callback;
	Reb_Print = pcallback;
}

void EXPORT DoREBOL(REBYTE *text){
	Reb_Do_String(text);
}


void EXPORT PrintREBOL(REBYTE *text){
	Reb_Print(text);
}



//----------------
// call_def.h
//

// don't forget to include this in the host build and extension code
//----------------
extern void SetupCallBacks(DoFunc callback, PrintFunc pcallback);
extern void DoREBOL (REBYTE *text);
extern void PrintREBOL (REBYTE *text);

Thanks, Max. I'm going to ask some probably naive questions if you 
don't mind. Can you confirm that the code you're showing is intended 
to call back into custom code you've added to the host? Would it 
work for calling into native REBOL functions as well? Also, if the 
intent would be to call back into a function defined by a script, 
do you know if RX_Call can take a function! datatype in the frame? 
The docs don't show an RXA_FUNCTION macro, but should this not be 
possible? Then you could call the extension to set up the callback 
into the script with the appropriate function passed in.

do you know if Carl intends to add support for the function! datatype 
in the near future?

so, basically you can do what I was asking for (calling scripts functions), 
but you have the limitation of having to know in advance the signature 
of the script function you're going to call, no?

I was able to trigger button & keyboard events from  a GLut  (OpenGL) 
window,  running arbitrary code like normal view actions.


Nice thing is that the errors do not stop the interpreter, just that 
call to Reb_Do_String() so its like if your code was wrapped within 
an attempt by default  :-)

sure - it'll have to do for now, in any case. You didn't answer about 
any enhancement to this that Carl might be working on, though - do 
you know if he is?

As I mentioned in chat, I'm thinking of implementing an external 
REBOL lexer for the Scintilla based editors. I was thinking that 
one way it could work is if the external lexer was a REBOL extension, 
but thinking about it again, maybe the whole callback thing could 
be avoided by having a custom host that is built as a dll, with the 
additional functions added to satisfy the Scintilla external lexer 
interface. Max, BrianH, do you know if it would be possible to compile 
the host as a dynamic library?

do you know if Carl is still giving access to the hostkit if he's 
asked nicely in chat?

if you look at the startup code, its dead simple, so you probably 
just need to remove that and you're done... then use do_string, just 
like the read line loop does.

I wonder what performance you could expect if the host was called 
for evey keystroke in the editor and was passed the complete script 
(with possible included modules) to be parsed  - do you have any 
guess? Of course the host instance would be cahced between invocations.

if you're having to do partial parsing, I'm guessing it can get pretty 
complicated quickly as you'd have to keep track of contexts that 
might be split, no?

its not an easy thing to do in any case  ;-)

if all you want to do is give rebol a string, and use the return 
string, and plug it back into scintilla, then its going to be a piece 
of cake.

I guess you might be able to do this as another type of editor plugin 
- Notepad++ has the concept of plugins that can do various higher 
level actions, but at the Scintilla level, you'd have to be mucking 
around with Scintilla code

Here I come with a nuclear bomb Ask .... This document requieres 
Viewer Advise if upon reading those line your retina blow up I could 
not held responsible for that.


I was htinking of the possible logical reasons why rebol is  not 
used  widly in today's computing area.


First i can say  compared to other scripting language it's source 
code is not freely accessible.

Second I can say most of the script laguages use now in days is in 
a role where the script source code isn't available to read to the 
client.

And so most of those script use are around Webserver, server side 
so the scripts are hiden to the view of the consumer (the cleint).

And most of  the time when a company needs to broadcast a software 
to their customer (a game, a client software, etc...) then they 

need to hide their source code. So most of the time they use compiled 
or speudo compiled programing language.


On an ideologic side what rebol offers is  "take my blackbox but 
you have to broacast your software source code viewable for all" 

Personnally i like that part .... that's what allowed me to build 
most of my softwares and contribute to most of some of other ones
project.


But I perfectly understand that for the industry they need to hide 
their "know how". So they use java so they use what ever compiled 
language to hide their "know how" 

Next is the fact that most of the time companies choose a langage 
more for the extension related to their project than for any other 
consideration.

Compiled language are faster the script languages most of the time.
So my ask is could rebol be like java compiled like language? 


I'm not talking about rebol/SDK  to me fusing the VM binary with 
 the script and somehow hiding the script is not the right solution 
that's just a cheap way to 
achieve that goal and rebol deserves better than cheap ways.


My point is to have like java does the need to go to the rebol.com 
and install the REBOL runtime environement  -> That strategy 1 rule 
1 modo 1 in spreading your technology 
Why sun Java and  Microsoft .NET  does it and rebol not ? 

And there we fall to what Carl noticed and shared with us some years 
ago while initiating the R3 projet  wich was  "Administrators on 
IT companies doesn"t knows about REBOL so when they see it they kill 
it from running tasks" 

Maybe the whole R.E (runtime Environement) thing was made to make 
most of the people look at the juava or .net dedicated websites and 
so be informed of what is jvm or what is netvm. At taht time when 
CArl tried to talk about us with that the solution Carl proposed 
was -> "Lets change rebol names" and  my reply was cold "If people 
after 6 years don't know rebol they won't know better anyother name 
the problem so i not the name is the way we spread the information". 
So in a way a runtime environement is the best way to populate your 
idea without investing to much.


Next thinking is about the compiled / speudo compiled is faster than 
any possible scripting language.
FASTER ????  IN WHAT ?  those are the questions ...

Most of people whould reply faster in execution ... Ok bu if i remamber 
well what i learn at school (yes i went to school stop laughing ...) 
before running a binary program you need to build the script ...

and that's where most of the work time is bruned up and where the 
need of a IDE (intergrated Developement Environement) is needed and 
most of the time those IDE ends up in being a Click and feel the 
form ... wich is adding a complexity layer instead of simplifying 
the scriptiing. Intents like small talk for example that push this 
aspect to it's core limits were hum not widely accepted as a suitable 
way to build software. Mainly because they make nearly impossible 
to extend easyly their selfves in comparasion of  other compiled 
languages.


So we are then saying rebol is the fastest way to build applications 
in the world. It's a ight weight very well though scripting langages 
with alot of possibilities.

Most of the time in one line of rebol you do as much as  tens of 
lines in any other languga (or even more) and that's because in my 
opinion rebol doesn't need a heavy script 

grammar to exist.   But you can stil make an IDE to help organise 
your work and speed it up and make it easyly more cooperative. But 
this is not the part we are discussing.


So in fact what really  matters in comuting area is less the time 
you spend building you application than the need to hide your 'how 
I did it'  and to then have the closest possible level to your hardware 
for your software. 


And for that my friends rebol need to be speudo compiled able. And 
maybe the step further java in our industry is to have a keep it 
simple language hiding your industrial secrets but allowing you if 
you want to share your work in full view full access like it's actually 
the case. Some will say to me  yes but  with R3 we have new extendsions 
so the industrial secret can be hidden in that layer. that's right 
but then you don't do rebol anymore you do C and what id the purpose 
of embeding rebol into a complexifed C layer ... C layer is to extend 
our language capabilities the fastest way but not to make the need 
of our language to desapear ... Because in the end what we want to 
promote is REBOL  not C language....


It's a long post I'm sorry for that  but I'm thinking about it since 
a long long time and tonight i feeled like sharing those thoughts

maybe i wasn't clear. Sorry i readed my post and some things appears 
not to be clear anough... 


1) Rebol runtime environement already exists that's the VM you install 
on your computer when you want to run scripts 

But a) it's not called a runtime environement  b) it's need disappears 
when you use REBO/SDK to "hide" your industrial secrets or when you 
don't want on purpose the client to install or know that  it's rebol 
behind.


2) by speudo compiling (byte code compilation) you allow people that 
need it to be a step closer to the hardware but keeping the portability 
effect so a rebol VM in my opinion should be able to  run both  a 
speudo binary file or a text script rebol file. Of course  like in 
java people would feel the need to share their software with embeded 
 Rebol Runtime Environement.


3) Having a runtime environement is the best modular way ...  core 
will be the base then you have View and lot of othe modules that 
wil clip to rebol. for example if i  put  import  "oracle" at the 
begining of my script then rebol runtime environement knows that 
he need the oracle package and goes to rebol.com to retrieve it and 
install it to the proper rebol runtime place in order for the vm 
to find it. Something close to what apt-get is to debian. REbol Environement 
doesn't comes with the whole thing but if the script tells it he 
can expend it selves in the fastest way. Well this runtime organisaton 
in  fact already exists but it's not pushed to it's extend, you know 
the point where the good idea become the best idea. the rebol/view 
2 implies a /desktop which implies a local scrit library (like a 
cache) to store the rebol script see the idea is there but once again 
it's not pushed to it's limits. Only rebgui used this system to store 
an extension to rebol.


4) by being closer to what people extend as an output you make them 
interessted in your input . To be more explicite by giving to peope 
what they are used to get in the end of their creation process then 
you allow them to be confident in your solution and to be more interressted 
on the way you propose to build your software.


5) i took java and .net as main example but if you look closely this 
is an expending tendency. For example Adobe Flash do that.


6) the other interrest in the compiled way is to merge the source 
code and the related resourcies at the same place (1.exe  file for 
example) and then forbiding the people to change their contents ... 
and this leaded then to the skining my application modo. Wich is 
just the we don't merge in the resulting binary the resourcies . 
In rebol we can already easyly build a script merger with data to 
output a .r file containing both but then people can still extract 
the ressourcies and change them etc...

One has to take the help, give some control away, live with the fact 
that not 100% will be as if you would do it yourself. But that's 
how woring in a team / with others is.

No, duplicating that info on the projects page is fine. If someone 
is willing to do the work, they deserve to be recognized.

Anton, do you happen to know any example that would show 96-bit = 
48x48 bits with 16-bit subpixels to have an advantage over 2 floats?

it would also be VERY nice to be able to do tripplets or quads.

All protocols are async unless you do special trickery to try and 
make them look sync

I don't understand why in the actor block, we can do this:

		close: func [
			port [port!]
		] [
			if open? port [
				close port/state/connection
				port/state/connection/awake: none
				port/state: none
			]
			port
		]


In the r2 schemes we had to specify the system word 'close, but in 
r3, we don't ... so what stops the stack overflow here?

having a working DRAW img [] in R3 would be nice too - and probably 
easier to do once we get it in hostkit?

It's not about x-mas and what we would like to see in R3. I have 
a very simple priority list: What do we need to get to scale R3 development 
and avoid Carl being a bottelneck? What do we need to do to use R3 
to do a commerical app?

There are still some questions to answer and quite a lot of little 
things to do. But IMO it's a big step ahead that the host-kit now 
builds.

Internal release made of hostkit for A99. Still some work to do before 
a public release can be made.

one trivial but important question: 


OK rebol is a programing language that get most of its interest when 
used in the internet area.

So for example i use my brand new software made in rebol  it connects 
to internet and check for version update.

Updating a software from the software itself is a common feature 
now in day.


But with rebol how do we do that mechanics ? ok i can log to the 
webserver where are stored the release i can do a CRC comparasoin 
betwin 

my software and the  one on the distant server repository. So i get 
to know if the repository is different from the version installed 
on my computer.

Once my local copy is aware the distant repository evolved i can 
download the new copy.

And that's where the poblems appears ... I can't make the new version 
downloaded from the server to be subtituated like all the other software 

made in c, C++ etc... does. What i mean is i can do 97% of the update 
from the webtask but the automatic stop the current app and launch 
the new version is 
not possible...


if you want to better understand what i mean think about your firefox 
update for example

 at your firefox start it performs a version check then download the 
 new version
then close the current running firefox and launch the new one.

Does rebol 3 will introduce that kind of mecanics ?

Be careful though, you have to design your modules for this on purpose, 
you can't just count on it happening automatically. Module state 
migration is not difficult, but it is a different process every time 
since it depends on what state you need to migrate. The R3 module 
system can make it possible, but your module needs to do the actual 
work.

This is essentially what several of my applications do to restart 
themselves. Not quite what you want, but as close as I could get:
   http://www.rebol.org/ml-display-message.r?m=rmlPPPJ

yeah in fact i could do this check the version then download the 
new version from server maning the file .TMP then create from my 
script a install-app.r  and call it then close the current app

and have that temporary script install-app.r to rename the .TMP file 
to my main script and then start the app. It could display popup 
message like "Configuring the new version please be patient..."

but it's lot of work for a thing i will be the only one to use ... 
and that's not the meaning of my ask ...

The easiest way to do this is to maintain your source in an encrypted 
and signed compressed binary.  So, you have the stub which does the 
update and executes the source.  It checks for new source, overwrites 
the old one and then executes it.  Since it is not updating the exe, 
there are no file locking issues.

Shadwolf, for scripts, there is no file locking. So the process is 
much easier if you are getting and writing the new script, saving 
your data, shutting down and starting up with the new script (similar 
to what Ladislav's function is doing for exes). If you just want 
to reload the script in place in the current interpreter instance, 
you have to do the live state migration I mentioned above.

CARL ONE ASK CAN AGG   BE MERGED WITH AMD/ATI OPEN CL Technology 
? ( some thing like a background application that would detect what 
hardware you have and use multi hardware CPUs GPUs to run those expensive 
task. Once again  what in rebol can be an very expensive task .... 
answer a state of art webbrowser rendering engine with flash silverlight 
support....  IF we can bring rebol to that state i think no one will 
look at it as a toy ... then the question is way doing a webbrowser 
in rebol ?  REply is because i love rebol :). But on a ground level 
if you want to enter in competition with the other languages and 
prove the interrest of the rebol method then you have to be able 
to do what the others can do )


This open CL adition can too benefits non graphical applications 
i don't know how but  why not saying look rbeol is not dead it's 
the futur and as the futur it provides the best way to use the futurs 
technology. And that's a field none of hte interpreted languages 
now in day have done ...

Steeve Matrix are costly in computations only if you do it with a 
CPU not designed on purpose to do those kind of tasks.... But with 
a GPU it's EASY CAKE ...Question is can we be hardware ignorant or 
not ?

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

since unreal shows you can do blasting High definition photorealistic 
close to the perfection 3d real time rendering engine with DirectX 
then the other will say ok we need our own DX engine cause DX is 
the only one able to do this ... Then you have the GPU founders that 
will say ok since the game industry wants and need DX then we will 
enclose in our harware GPU alot of  optimisations for DX ... or even 
the next DX version noone use now in day .. buuuuut we will be ready 
!

Brianh hum actually when i we display things using agg the cu is 
used only and if we want to do extensive computing visual effects 
like zoom spining things etc ... hten the cpu will be extensively 
used ... and since rebol doesn"t take advantage of  multi CPU  or 
CPU <- to ->GPU communication then the extensive computation loops 
are not enhanced. Problem is now in day NVIDIA is so expensiv no 
one buy it  10 ATi cards are sold for 1 nvidia card and in a very 
near future AMD CPU will be mixed with ATI GPU  into a single chip 
(APU fusion). This is the tendency of the computing area so if you 
have to support 1 paralelle design i would go for the AMD /ATI  couple 
instead of  betting on a close to death horse...

As for seeing a partial pixel, the writer of AGG demonstrated (in 
an unrelated post) using anti-aliasing to do 1/256 horizontal pixel 
positioning.

The semantics for a GPGPU dialect in REBOL would likely be pretty 
high-level, and could be translatable to different GPUs by using 
different compiler backends. It's not necessarily a good idea to 
bet it all on one horse when you can support them all just by being 
a bit general. We wouldn't have to do major tweaking for a specific 
GPU architecture, since the level of speedup would be great for even 
a half-assed translation.

BrianH probleme is  rebol doesn"t tends to relay on a spécific thing 
or another it's phylosophy is to be an easy way to do easyly easy 
things ... when you want to get your self out of that scope you are 
 facing hella difficulties  why should i code 99% of a project in 
C and then do a  dialect to do the last 1% of rebol action code

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)

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.

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.

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

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

you don't imagine all the task it takes me to do a single line of 
rebol rebol can understaand without errors :)

then i have mister ubuntu netbook 10.04 wild thing animal thing dot 
thing then faster to start good perf extensible with thousand of 
applications just with a single click then i have android fast starting 
no apps and a web browser so slow that i can go take a coffee before 
the page gets full rendered. android is a close poratage without 
access to android market  so it comes wth some apps and that's all 
you can get but it boots in 5 secs ... sooooooooooo what do i use 
?

wolfie, there's lots to do before r3 is ready .. why not work with 
what we have?

hum ?? ok so i can speak here if i do an opencl extension and its 
dialect and then do the port of cheyenne to it and a demo called 
that's my web server running on my ATI 5670 ?

In general, one doesn't. There is no infrastructure code around tasks, 
no way to stop or track them that I know of (they may stop on their 
own), and the only testing of them that I have done is to track down 
errors. But they seem to do something. The task-local user context 
is for the moment by definition rather than actual - it hasn't yet 
been implemented. But you can MAKE a task! and it will do something.

>> do task [] [print 42]
stack size: 50000
[New Thread 0xf7d75b70 (LWP 25615)]
waiting for task to become ready
Begin Task
REBOL System Error:
REBOL System Error #1411: REBOL System Error

Brianh's bad point: 
 

4) hum yes but maybe you will attrack some more hella programers 
ultra specialised that will help us do the translation ...

5) the semantic and datatypes of rebol have few in comon with C/C++ 

6) yes but looking at the jobs offers now in day most of them aorund 
70% are based on java jdbc job offers ... 

7) slow but now we have 4 to 6 cores processors that was a good excuses 
10 years ago but today that's not...

4) "ultra specialised that will help us do the translation" Manual 
translation. The code would not be comparable, and the entire implementation 
strategy would need to change because of the differences between 
C and Java.

5) REBOL doesn't have classes. And accessing C libraries from REBOL 
is awkward too.

So? That is not an excuse to do the number-one worst thing that you 
can ever do as a programmer.

all i can do in rebol is selling the  programs i do using rebol... 
but what credibility i have imagine my clients how they work they 
give me specs i propose them to do it in rebol they say no because 
if you get any problem we the client will not be able to get easyly 
a substitute to you  to retake your work and get it enhanced ...

Since you haven't been participating as much, you don't know how 
far along we are, so you don't understand how incredibly dumb it 
would be to scrap the code base and start over. We are only working 
on one VM. If someone else wants to start another project, fine, 
but they should have a good case for allocating the resources, and 
not do anything to preclude others from helping them.

oop means it's a you can do objects but you are not forced to do 
this ...  it's like php ?

Basing some REBOL-related tools on Silverlight and/or the DLR would 
be a plus. Keep in mind that we don't have to make the whole of REBOL 
run within the JVM or DLR - REBOL is great for making development 
tools, which can be used to generate Silverlight applications, just 
like they generate Flash applications. Or R3 could be used as a library 
by Java, or as a supplemental developemtn tool, or a code generator, 
whatever. Remember, most of REBOL is a set of awesome libraries and 
dialects. REBOL without most of DO or AGG is still useful.

It's only a lot of work if you add it up. Noone will need all of 
this. The small part that they need will be a smaller bit of work. 
And others will need different things, and will do their own work. 
As long as people contribute back to the community and don't say 
things like "I don't work for free for a project that will bring 
money to someone else", without realizing that you will befefit from 
those other people's contributions, then we will all benefit.

Janko, i'll gather the videos from 2005 and make them available to 
you. if you have the time and patience to upload them to youtube, 
that would be great. i don't know when i'll ever get around to do 
that. :)

You guys are welcome to use the software again if you'd like to do 
the conference virtually.