AltME groups: search

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.

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

I am also thinking of buying a beagle board, for robotic experimentation 
with my kids.

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.

the graphics actually aren't that bad  (10 million polys a second!)

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.

Perhaps something in 2-3 months, but also depending on hostkit. Customer 
feedback is mostly RM Asset related. It doesn't necessarily mean 
direct feedback from customers, but methods to more easily debug 
crashed apps without demanding anything from the user, such as a 
record of which buttons are clicked, replay mechanisms, etc.

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.

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.

There is a rebol wave .. not sure if it is active still

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.

Yes, Max - could you give us a bit more detail on how you would use 
the global context for callbacks?

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.

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.

not really,   Reb_Do_String  just executes a string of REBOL text 
on the global context.

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

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

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

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.

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?

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

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

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

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.

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

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.

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?""

Asking Sarah Palin for a job?

I think there is currently no progress, but I can't say it loudly, 
as Max will jump here telling me, that Carl is working hard on a 
host kit :-)

But Carl said he finished the host kit for windows a month ago ...

the only thing I can complain about is that Carl has been VERY silent 
for a month, even on R3 chat.

or in a catatonic state

No, he said he had a build that worked. Since the new host kit represents 
a new API, I would guess that he has to make a few other platforms 
to sort out the platform-dependencies in the API.

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

but it doesn't move us forward. As long as we don't get R3 out-of-the-door 
I don't need a R3 project page.

Looks like he needs a project manager

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

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.

Each of those pages needs to point to a page on rebol.net's wiki 
so we can edit them

Think of the projects page as a summary.

Right. Redundancy is fine on a summary page.

The purpose of a summary page is to allow people to get a quick overview 
without having to go to the detail pages if they don't need to.

Fine, but I don't expect the details page to have a summary of the 
status, I expect it to have a detailed status. If you are expecting 
projects to have a lot of activity, is it so implausible to imagine 
the projects page being maintained?

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.

I think not necessarily. R2 supported proxies (at least some proxies) 
too. There was an idea to have networking protocols use OS specific 
layers. That would still be imo a possibility.

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)

Some of the value types require 2 pointers. On a 64bit build, pointers 
are the same size as doubles. It's an internal matter anyways.

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.

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?

An extension like AGG, which also uses doubles. But we can't fit 
two doubles in a value slot on a 32bit build, sorry.

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

well, I guess they could just be stored as a two double struct, but 
then we still get the added indirection everytime they are used.

I guess I need to serialize the data on the java side so that it 
looks like Rebol values .. a la 'mold

doing a java bridge to access a database ? hum really ? but what 
would be the gain ? instead of having it in direct access i thought 
rebol had odbc acces through odbc://

A bit of host kit news:


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

Database work is only waiting for a community discussion of the semantic/dialect 
model, afaik. Something to integrate with the new port model, not 
the old one.

With a handler, like in R3?

My jdbc protocol is a R3 protocol ... this is the R3 group!

Cool. So set up a discussion for the database semantic/dialect model. 
I think one of those DocBase wiki discussions would work for this, 
with chat in the DB Chat group here.

The R2 model wasn't very good, in my experience, so a refined model 
that can also be adapted to NoSQL databases would help here.

Sounds really cool. Getting DRAW to work might be a bit more difficult. 
If I understand it correctly, DRAW dialect is processed by the kernel, 
whereas drawn by the HostKit, hence draw api will have to be created 
in the HostKit layer, which will be called by the kernel?

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

There is a new command block evaluator that needs to be used a bit 
differently. Hence the DRAW dialect loop needs to be adjusted. As 
the AGG interface

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

They may be overwritten though, if instead of giving a block of specs 
you furnish an object of actors to the make-scheme function:)

Not only that, you may replace the actors of a port at anytime.

yeah, I was hoping to have a bit more feedback published from the 
daily scrums

The daily scrum is not that interesting as there is nothing DONE 
until the end of a sprint. We are currently using 1 week sprints. 
This means every Friday afternoon we review what has been DONE.

I'm looking forward what will be done with the host-kit. Not sure 
why it's a mandatory component for so many to use R3 but OK, maybe 
I just don't get it.

IMO it's more critical to use to get a good GUI up & running with 
a broad set of styles.

Is the lack of developer activity just a sign of lack of interest 
in R3?

Robert is pulling a lot of strings (namely by getting hold of all 
the right people, while they are not busy) to focus R3 development 
and I'm impressed that he was able to get Carl in on it. It's what's 
needed now to move forward at greater speed, just like any other 
serious development effort. Robert's motivation is to deliver products 
as soon as possible and there is nothing strange about that.

ANd Pekr, who has also done a lot of behind-the-scenes work.

Please don't call Pekr a politician. That would require Pekr not 
to know what he's doing and generally not really care about REBOL. 
:-)

>> a: [a 1 2 b 3 4 c 5 6 d 7 8]
== [a 1 2 b 3 4 c 5 6 d 7 8]

>> head move/to/skip find copy a 'd 1 3
== [a 1 d 7 8 2 b 3 4 c 5 6]


Looks like a bug to me. [d 7 8] should be at offset 1 rather than 
3. This is also present in R2 forward.

Nope, 2.7.7 has the R2/Forward code. I see the bug, though have a 
question: Should the index obey the skip?

When /to is not specified and /skip is, offsets are multiplied by 
the record length, so you are counting in records. This is intentional, 
to allow you to work with fixed records without messing them up. 
If we keep that behavior then the index will be the record index, 
not the series index. It's not a difficult trick, but it should be 
noted.

It's so sad that after 3-4 years there's so few people working on 
R3

 - I can take it if it would be "...working with R3". That's true. 
 People should use it and tell what's the most critical (that means, 
 what blocks you from making a product) thing that needs to be done 
 in R3.

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?

Sure.  If the remote server closes a connection, can you re-use the 
sub-port to re-open the port?

Do you have a workaround?

Ok, as the current focus on R3 is to get the infrastructure and basic 
things done first, these detailed questions (even if valueable) are 
not our focus. But this doesn't mean, that it's a showstopper for 
you to use R3.

How about adding a category in CureCode to collect these so it's 
not lost?

My goal is to get R3 out of alpha, beta to release. To get the GUI 
to a state that you can create apps with it.