World: r3wp

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

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...

Ho one of the Runtime Environement interrest i didn't mentionned 
is the translation .... GTK for example the main purpose of having 
it's runtime enviroment is to manage the "localisation"

Shadwolf. We discussed this a lot of time and the discussion would 
be better for Advocacy.

We all hope that the host openess of REBOL3 together with its improvements 
will break the cage where REBOL has been for years.

Also remember that REBOL is difficult to understand if you come from 
classic OO languages which actually rules the world. At least, it 
was difficult for me.

i don't find rebol so hard to understand (most of it  for parse for 
example i still seek the light ...)

I have gone crazy to remove from my mind the concept of pointers; 
also the concepts covered by Ladislav articles like binding are difficult 
to digest; finally classic OOP versus Prototype Based OOP has been 
very hard until someone told me how to understand these concepts.

what may be more difficult to digest than the concepts my articles 
cover is my style of writing ;-)

(sorry for causing any headaches), and, I might have even caused 
more serious problems in one case

Headaches are caused by the innovative intrinsic nature of the concepts, 
nto ny your articles.

It's like Feynman apologizing that he couldn't make physics easier 
to understand. :-)

classic OOP

 - actually, "prototype" is "classic" (ie. what was invented by Alan 
 Kay etc.), while class-based is what came out of C++ mostly.

From now I will change "Classic OOP" to "Common OOP" :-)

Gregg, many things can became difficult due to the background "trash" 
you have in mind.

as we are already in "picky" mode: actually, dahl/nygaard's simula, 
which invented class-based OOP, predates smalltalk.

ah, i didn't remember simula was class based. hmm, so it's hard to 
say what is really "classic" I guess...

yes. talking about "mainstream oop" would be more precise, i guess

depends how you classify mainstream.... JS/ECMA is prototype and 
its the most used language on the planet   ;-)

tomorrow will be my birthday. ;-) .i wish to have some news of R3 
and host kit and R3GUI and asyn and .......... and perhaps a windows 
or linux version of R3 + R3GUI (with table widget) and RIF and R3/services 
 ;-)