AltME groups: search

...and it exists in R2 as well as in R3

Graham: "Neither of these systems are in general use" - wrong, actually. 
Everybody using Rebol preprocessor is compatible with Include, and 
the "generality of use" of INCLUDE is higher, than you guess.

I'm conflicted. I can see the logic of Brian's INCLUDE (though still 
wondering if it should be a set operation), but I use Ladislav's 
INCLUDE heavily. For me, the important thing is that we all, Carl 
included, keep communicating and work to leverage community efforts.

Yes, I have an old include system too, using the INCLUDE function 
name. It's hard to stop using it, unfortunately. I am quite ok to 
have a native INCLUDE added and to mean the opposite of EXCLUDE, 
however.

Gregg, I don't use the set operations very often (but I still want 
them there), but I do conditional APPENDs quite often, and I miss 
a native function for it definitely.

Ladislav, I have no problem in principle with adapting some of the 
code in your include stuff to make a PREBOL superset with inherent 
support for R3's modules. However, if your preprocessor doesn't support 
collecting modules with R3's module syntax, then it's of no direct 
use to me for R3 code. And the great thing about a PREBOL superset 
is that #include is *not* a function, it's a directive.

I have had frequent need for modifying INCLUDE and EXCLUDE, but not 
as much need for the non-modifying stuff. To each their own.

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.

I was thinking of "cinsert" and "cappend" too. But note, "adjoin" 
is a normal existing english word, from Anglo-French "ajoindre".

Just looking in the thesaurus.
Possible other names for INCLUDE / EXCLUDE:
	ENTAIL / OMIT   <- ENTAIL good for conditional append.
	ADMIT / OMIT   <-  ADMIT good for conditional insert.
Nice and short, eh?

Ladislav, I don't really need to get into the naming mess. I have 
needed the functionality I described for the modifying INCLUDE and 
EXCLUDE for a long time now, especially as modifying set functions 
rather than just single values like ALTER. But I can continue to 
get by without. And it turns out that the set functions often need 
to allocate another series anyways, for hashing, so the modifying 
versions probably don't have enough of a benefit to be worth adding.

However, that doesn't mean that I would call your preprocessor INCLUDE 
in the standard distribution. We need a superset of PREBOL to *be* 
the new PREBOL. The functionality we are missing is the bare minimum 
that we need to make it useful for R3 development, so if we make 
a standard preprocessor it would have to have that feature. And if 
your %include.r is a better codebase to start with, cool.

...and the directives are standard

Right. For one thing, the actual including is done in response to 
the directives. The function is preprocessing, and its results are 
not actually included at the point of call :)

The R3 preprocessor would most of all need to transform script modules 
to inline modules, add the code to resolve the binding issues, and 
especially handle mixins. All of the traditional PREBOL functionality 
is secondary to that, and use of the directives will be more minimal.

We all were. The first negative sign for me was, when Carl announced, 
that he is not going to post montly updates. Those were much appreciated 
and motivating. I knew, that it means just one thing - Carl going 
into the cave mode. R3 is almost on-hold for 5 months ....

stop being obsessive about deadlines and you'll feel much better.

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.

the biggest problem is not the development, or the lack of thereof, 
but the lack of communication. I think that one short message per 
week or two on Twitter would not hurt :-) Just last two working days, 
 I experienced the same - I am leading our corporate site roll-out 
to 8 branches abroad. Marketing managers involved. While I worked 
like mad for last week, I started to receive emails, asking for the 
status update - and that's it - ppl just want to plan a bit their 
things. When I explained other branches, what I am busy with, they 
stopped asking, and I will update them once per week, till I finish 
the job ... and that's it ... correct communications ....

two releases last week? where?
 - Alpha 98 and 99, in the usual place.

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

and is there a function like ALTER but that adds a value to a block 
if not present and leaves block as is if value is already present?

and in set theory, "set inclusion" is just another name for the subset 
relation

I like #INCLUDE as a preprocessor directive, and I wouldn't mind 
if the function (e.g. Ladislav's INCLUDE) had a different name, like 
ASSEMBLE. I know he has a BUILD func already,

I also don't mind if I need to port things to a new system for R3, 
as many things need to be revisited anyway. As long as I can run 
old R2 scripts side-by-side easily. The important thing, then, is 
getting everyone on the same page with regard to the various domains, 
steps, and responsibilities of design, assembly, and deployment.

just call the "missing" function UPSERT and be done with it. will 
also fit nicely, if you add special treament of "keyed" records to 
it (using the usual /skip and /part refinements).

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?

they have everything on-board (even a graphic chip IIRC) and standard 
connectors right on the board.

We are registered with Texas Instrumets, and they have new DaVinci 
gfx chip -

 http://focus.ti.com/dsp/docs/dspplatformscontento.tsp?sectionId=2&familyId=1300&tabId=1855&DCMP=dm368_041410_eu&HQS=Other+EM+dm368elp-ee

although you can find Arm based laptops for under $100. You already 
get the keyboard and screen....

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.

What VID is turning into: It's turning into a VID that will be very 
useful. I've personally been missing these features for ages and 
will eliminate many hours of tiresome debugging.

Sounds good, except the timing :-) Well, but we have been waiting 
for new VID for 2 years already, so another 2-3 months are OK. If 
you have anything to test, feel free to ask, I am willing to, and 
I did so  in the past too ...

fixing bugs and getting control over AGG.

Difficult to say ... it depends on Carl. The bad thing is, that Twitter 
message says: "Where's the A99 host kit source and lib?", which leads 
you to latest blog article, which does not contain any link though. 
Let's hope Carl does just some last minute changes ....

Hmm... I think our jokes are better and better recently.

and don't mixup the hostkit and extension... although they are based 
on the same code, they are separate releases.  AFAIK.

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);

RXA_Handle is used to allocate pointers and provide them to the core, 
without source code being able to tamper with them.  in fact, I don't 
even thing a handle!  can be created from R3 source...  only from 
the core or extensions.   so in general, if you are given a handle! 
type as an argument, you can rely its really some pointer generated 
by some native/extension code.

it loads it, binds and runs the do dialect on it.

guess it's fairly flexible, but you're incurring quite a cost for 
this - need to stringify the script call and then this needs to be 
parsed again on the host side - seems wasteful

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.

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.

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.

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.

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.

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.

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

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.

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.

and then to query it for the up-to-date 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.

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

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.

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

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 
 ;-)

... well, that was for a host kit and maybe a GUI ... as for RIF 
and R3/Services - wait 5 years ...

What does Carl mean by his Twitte message?: "We need to update libs 
and funcs for REBOL 3. Should we host a R3 "summer of code?""

Yeah, with (and paid for by) the family :) No job, unfortunately.

Some of you may be wondering where the Host Kit is for A99?

The good news: the lib and host have been built and run on Win32.

The last Twitter message states: "We need to update libs and funcs 
for REBOL 3. Should we host a R3 "summer of code?""

Ehm, because it word! and not logic!, ignore it.

There is one thing, I hardly understand.

It was said, that he wrote R2 in a very short time, as he was not 
satisfied with R1.

Now he has the the experience with two shots, he has got a community 
with people ready to help and knowing his intentions and experience 
too.

What happens?
It fizzles out ....

which means removing the lead and status fields from the projects 
page

The lead and status won't change that often.

The lead and status summary are exactly the kind of details you want 
there.

So, use parse and extract that detail and put it on the summary page!

Yes, because they're different sites and different people.  We know 
Carl is the only one with access to rebol.com pages and history tells 
us he can't maintain them.

We know that Carl being the only one with access to rebol.com pages 
is considered by Carl to be a bug in the permissions system of the 
rebol.com site, and that he is working on it.

fromt he priorities page: "Text codec project has been deferred due 
to community input. The project will be reorganized to make codecs 
into a port datatype and allow external codec devices as well as 
streaming (with port's holding the steam state.)" ---- I really like 
it :-)

As it looks, due to the efficiency issues (speed), the implementation 
of REBOL pairs as pairs of floats looks to be the fastest (since 
AGG needs double values, and conversion from float to double is faster 
than conversion from integer subpixel count to double using a foating 
point division looks slow)

I'd prefer to get the 96-bit pairs with each x and y using 16 bits 
for subpixels, keeping the memory down, and not reducing the integer 
range. So I'd like to know just *how* much slower this implementation 
would be than using floats or doubles.

Anton, there would be no memory savings by using 48x48 integers. 
The pair would still be in a value slot, and value slots are fixed 
size. And they would be slower to access because of alignment issues, 
plus the floating point multiply to convert them to the doubles used 
internally in AGG. "So it looks like 128bits are available." - only 
on 64bit builds of R3, not on the 32bit builds we have now.

Of course, other operations, like conversion to integer, e.g., are 
needed sometimes, and for those, the situation would be the other 
way around

Ladislav, no example that shows an advantage springs to mind.

Could you also measure conversion to int for 96-bit pairs and pairs 
of floats?

We can upgrade to doubles in the future, in the 64bit builds - AGG 
uses them already. Though I don't know the effects that would have 
on rounding and such.

exactly, I wouldn't want a 64 bit build to perform different maths 
on values.  it should just be faster for bigger numbers.


if we go with floats, I feel that we'll be forced to keep them even 
in 64 bit builds.


also, generally, all graphics libs and most math related libs now 
use doubles.  so if we need to convert the floats from rebol everytime 
we use the value within an extension its going to incur some speed 
hits no?

And if we don't fit a pari into a value slot, it changes its whole 
behavior.

Yes, due to at least one added pointer indirection, and added code 
to prevent aliasing (in the pointer sense, not the graphics sense). 
And they could be modifiable, unless we are careful, and that brings 
in another whole host of issues.

A bit of host kit news:


--- Win32 window and event code now compiles and links successfully 
within the host-kit.
 - Carl.

Yes: The port model is different. For one thing, you don't insert 
to and copy from ports.

And async needs to be considered as well.

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

This is just something to get me up and running on R3 with databases

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

didn't changed and is brought in as extension, the binding should 
not change significantly (all my guess).

BTW, as I was working on this, I realized how much you are going 
to like this new R3 build.  The entire graphics, including the view-related 
mezz functions are now a module stored in the host kit.  So, all 
of our new graphics support code can go there and be updated as needed.
 - Carl

The thing is to concentrate and focus that we can deliver something. 
Disussions about non-priority things don't help us at the moment.

Graham: I expect something to be released (open-sourced), once there 
is actually something to open-source. I mean - untill the HostKit 
isolation is done, we can't proceed. Once View is completly separated 
as module, it can, and hopefully it will be released ...