World: r3wp

I was still able to get more than 100fps running with one callback 
creating a small object per refresh IIRC.

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?

with view extraction from the coe, he has NO CHOICE in giving us 
a means to execute loaded, bound, code, since all a GUI really does 
is trigger code.
code which is managed by the core.


I also know that vector and image datatypes will definitely be part 
of next extension, its really important.


I am in the process of requesting that the argument frame be increased 
to 15 arguments by default... 7 is ridiculously low, especially if 
you want to use refinements.

so you think he's pretty much there?

wrt the first part

note that with the above callback system,  receiving a result from 
the callback is tricky.  


it has to use one of the extension's commands to store a return value 
there,  and the extension should then look for a return value after 
the callback returns.

there ... as in Done?  not sure...  its a lot of architecture and 
design decisions, probably more thinking than coding is happening 
right now.

its a big deal, it has to be secure i.e.  an extension must not be 
able to hijack the core and get an way in so it would start  probing 
core data, and ultimately go around all the work done to improve 
R3's safe use.

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?

sure, but you'll probably have to tweak the distro, replace the main 
by the appropriate DLL init funcs.

not sure how easy it will be in linux, but on windows, exe and dlls 
actually are the same thing.  the os, just doesn't run main() on 
a dll.

yeah, you're right

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.

sure, especially to people with definite goals and cool ideas.  I 
thought it was made public, maybe not.

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 all you do is:


rebol_source = "PARSE {.... UTF-8 data from scintilla ...} parse-rules 
";
do_string (rebol_source);


probably very fast, enough for real time,  if script isn't huge :-)

if your app also has an extension which can give data to scintilla, 
then you'd just  add a command to the above string which calls the 
extension's command! with parse results.


the xtensions are very adept at parsing blocks, so converting that 
back to scintilla as native C data is possible there.

the only issue I see is intense RAM juggling, so if you can find 
ways to parse only subsets of current edit and cache the rest, then 
it might even be effective and real-time.

Why the need for the extension? If you already have a customized 
host, why would this be needed?

ah, yes, its possible the host also supports commands... but I'm 
not sure in the official release.  in the next one I think these 
have been built-in.

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?

thing is, things like intellisense in rebol aren't possible, because 
only the interpreter understands the complex binding that happens.

you can guess them, but not confidently, because you'd need access 
to actual context-like object from the C side to resolve words which 
are bound externally (not part of current context, but inherited)

but if you have control over the source building itself within scintilla, 
then it can know what things are and where they come from... that's 
the main point of using an IDE.

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

the module system provides enough information so that your editor 
could resolve the dependency on its own, and parse stuff accordingly.

now USING rebol as the scripting/macro language within an Editor 
 

THAT would be really cool.   :-D

not sure I follow...

yeah, that was my intent, if at all possible

but I think that the integration between the editor base and the 
lexer is too weak

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.

if, on the other hand, you want to use REBOL to parse the source 
for things like syntax highlighting, then its complicated, which 
is what my notes above relate to.

I need to identify what benefit I'm hoping to get over the current 
lexer which uses a static word list and regexes for capturing various 
bits

using R3 to actually LOAD and identify tokens by their datatype seems 
to be the biggest deal to me.

that was my intent

and then to query it for the up-to-date words

you would let R3 parse the source, then call various internal functions 
to return the various types of words

trick is to find a way to parse just a subset... you might want to 
chat with steeve and shadwolf, their rebol editor was pretty responsive 
even with big files, so I guess they have an optimisation that lets 
them just token what is visible, with some form of caching for before 
and after pages of data.

you could then just apply the algorithm to the C side and let R3 
parse only a small portion of the script at a time.   That's how 
I'd try it.

using  a command! to tell scintilla what to refresh directly, based 
on parse results.

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

I wouldn't want to get into that

hehe

really, Scintilla should define plugins itself

I've never played around with it... last time I looked, I was daunted 
by the sheer size of the code base.

for the component , I mean - the editors based on Scintilla could 
extend this

gotta get going for a while - thanks for the feedback, Max

I hope you get this working would be cool.

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