World: r3wp

... whereas the opposite is true. Carl asks for feedback. How many 
ppl gave Carl feedback towards VID? Me, you, Henrik? How many ppl 
do comment Parse? 5 - 8? So - let's concentrate upon finishing the 
plan with what we have, and save our complaints for later.

The simulation I've been running of Carl isn't good enough to replace 
him, so forking isn't that effective :)

Only blind can't see the advancement R3 took in last 1/2 a year. 
Hundred of tickets addressed per month ....

BrianH: re tasking - any new idea of what we are going to get, with 
what Carl said yesterday?

And I am quite satisfied with the parse feedback, especially when 
you include the original enhancements and the initial proposals during 
November through January.

Re: tasking, yes, I think I got it. Now I have an idea about how 
to review/nudge the proposals/tickets.

What is the outcome of Steeve's proposals? Carl said something about 
inlining of REMOVE. Will it change from the index based aproach, 
which is now implemented?

It won't be a pure erlang-style shared-nothing approach, but the 
message-passing will be there. We can optimize accordingly.

message passing? I like that :-) Amiga anyone? :-)

In alpha 83 we had a (broken) implementation of the REMOVE 2 proposal. 
In alpha 84 we will have REMOVE 1 instead (Steeve recreated this 
proposal). Let the best proposal win - I'm hoping for REMOVE 1, since 
it's nicer (if less powerful).

REMOVE 1 was my original REMOVE proposal, back in November.

It definitely seems, we are getting Device Extensions, right? (anticipating 
it according to yesterday's discussion)

It's a really high priority.

What will it allow us to do? Any real-life example?

Asynchronous calls, callbacks, synchronizing with external code. 
Database access.

SSL

OpenGL, etc.

Why you need it for DB access for e.g.? Is it because you simply 
want async behaviour, and that is only possible via stand-alone device? 
So we will e.g. implement SQLite.device?

re REMOVE 1 vs 2 - couldn't we have both? Simply either rule is following, 
or index? :-) Both seem to be usefull ....

Yup. It will be required for synchronizing with multi-tasking R3.

We really can't have REMOVE 1 and 2 both - the rules don't match, 
there would be ambiguity.

What is the Device model though? We have not seen any examples yet. 
So you take extension API, create some SQLite.dll (extension), and 
integrate it via Devices API?

Then let's have REMOVE 1, to make Steeve happy :-) He is right that 
index aproach still can work in terms of storing a position into 
variable and doing REBOL level remove in parens ...

Look in the port model docs - they talk a lot about devices. The 
only thing added will be the ability to write your own.

Two new blog articles. Release notes updated too ...

Regarding the R3 web console: I'm bowing out as the back end seems 
much more complicated to do than I thought. There are also still 
security issues. I'll gladly hand the source to someone else, if 
they want to continue.

BrianH and I work together well, but the two of us alone are not 
enough!

.... It's about 10  years the rebol ommunity tells you can't do all 
alone and you need to open the source code... this doesn't means 
the final integration word is not yours... This doesn"t mean that 
you will have 100% ready to go additions. This doesn't  mean that 
rebol VM  will be stabilised to less than 1Mo ... More you have embeded 
feature hard written in the VM bigger it is that's why the "extension" 
approache is good.

Then the VM can be seen a minimal execution environement able to 
run any ind of things ... that the way most of the "regular" script 
languages works.

i like tht way to resume parse action car "Match then Action"  then 
the problem is when you match somthing then you when your action 
not to impact on the match thing but on the following  or preciding 
thing. The index system is the main problem in my opinion:  where 
i am ? what does i store  and until what point ?  i'm before or after 
my match ? and if my match is not  given in the right way how can 
i be sure my match tags are not taken inverted and that my action 
system will not freak out ?


Programming in parse gives you so many "asks" to care about that 
you are fast lost. But i'm agree the  result of parse rules in general 
once understoud (if it's any time the case ) is easy and beauty full.

and i think parse is already a big enhancement compared to regular 
expression ( i give a try to it past week writing a software in ruby 
... that's horrible ... I mean i'm complaining about parse but regular 
expression is so much a bore and stupid to write + they don't allow 
any action they are just made for match  only way to have regular 
expresion doing something is in ruby using them with an action mathod 
of the string class..... And that the kind of stupid things most 
of  coders in the world today found fantastic ??? HOOOO  really ???)


So when we come from mystring.match( "/\d\w***.*" ) kind of things 
of course going to the match action parse way is complicated... but 
complicated maybe not the way it's supposed to be.

Parse works better on "tags" words matching more than cabalistic 
formulas like regular exapressions. This doeasnt means it can't be 
doing that too..

what i have real difficulties to figure out in parse is the index 
system... I have a problem to see where i'm  and what my actions 
is doing.  do i "store index match then action" or do i  "match store 
then action" ? And if you add to that the sub rules i'm like completly 
lost. Cause in some cases sub rules can trigger their own particular 
special only for them actions ...

Sorry to ask what I may be able to find elsewhere, but what is the 
current policy on multiplatform alpha releases?  I've just tried 
a82 on OS X (my second foray into R3) but understand the new parse 
features are a83+.

sems like things are done for windows first then adapted to other 
OSes... That's how i understand the realease method basing me on 
what i saw alreeady you have some realease that adds new things then 
releases that only add those new things to other than windows OSes...

But how far behind might it be?

In the past Carl seemed to skip building the "big" alpha releases 
for OSX and Linux until the Windows has been tested. I would guess 
that we'll see a84 or a 85 for OSX.

The OSX version of Rebol3 is missing things that are in the Windows 
version (extensions) and has a number of bugs such as no internal 
event handling so that wait consumes 100% of the CPU, server ports 
don't work (probably related to no internal event handling) and call 
doesn't work properly.

'k, will be patient.  I've a small project set aside...

R3 will run as a CGI under OSX though, it doesn't yet do so on Windows.

about chat ... i always said it was hard to have a precise location 
of interresting exchanges ... but that's the same in altme...  in 
fact any discussion here or in chat when it pops out interresting 
ideas should then be resume into a temporary task list  but ... that's 
normal most of the time discussion here are mixed we don't only propose 
enhancements we try to figure out how things works then  we try to 
give how things could or should be working in order to make our lifes 
easier... It's a difficult task to keep tracks on every good idea 
passed throught altme or Chat  system...

i don't understand the "it will work as cgi ..." does it means outside 
an apache server and through a html page rebol won't work ? then 
rebol would be something like a custom php ?

REBOL3 cgi scripts don't work on Windows (under Apache or IIS) but 
do run on OSX (under Apache).

Are there any rebol based R3 web servers yet?

There's barely a client. Web server support was originally intended 
to be built in, but we'll see whether the work gets done. Openning 
the source doesn't magically provide more people to do the work. 
We need help.

Shadwolf, most of the code in R3 is open already.

Why does this take over a minute to complete?
    dt [
        parse [1] [some []]
        ]

(There is a similar time issue with R2)

I thought that was fixed...

it's the same with an empty ANY rule.

A SOME or ANY rule that does not advance is an endless loop. [some 
[]] is equivalent to [some [none]].

can this not be fixed? I can't see why one would want such a rule.

and I imagine a lot of beginners getting stuck in this.

Endless I can understand....but 90 seconds run time is something 
else :)
Perhaps Secure will handle it one day.