World: r3wp

A87 helped on the GUI demo at least.

Cool :)

is break ignored? parse "123" ["1" "2" break "3"] throws false ....

It doesn't break loops, which is the only thing it was ever good 
for, barely.

Carl wikified the project plan - http://rebol.com/r3/docs/project.html


I am now suggesting the following aproach - to create October plan, 
describing R3 beta release. My proposal is to discuss particular 
items here and on chat, but the main channel should be blog. There 
we can post our priority lists. Once agreed, we edit the doc.


So hopefully soon enough, we open the discussion. We might already 
start, but save your comments for the blog. This group is moving 
fast with discussions, maybe we could set-up (temporarily?) an R3 
priorities group, and each of us could post his numberred/bulleted 
list of requested features? It would be then easier for Carl to look, 
or for us to gather ideas and repost them to blog, etc.

What do you think?

R3 priorities groups...  Good idea.


go ahead, I'll post righ after... even though you all know what my 
number 1   ;-)

I would also post my callbacks/device code example as a link within 
the wiki so carl doesn't loose it a 3rd time  ;-)

how can I become an editor for the wiki?  I would eventually add 
some stuff for the extensions (from me and others).

The permissions for the manual wiki are based on the R3 chat user 
rank. I don't know what the cutoff is to get editing privileges.

yeah... I'm in  :-)  I did a bit of clueless running around, then 
I got it  :-)

writting up a complete,  revised, and proper document for a devices/callbacks 
spec, which I will link within the projects plan when its done  :-)

We should discuss any changes before they go in. We don't want the 
priorities page to become a war zone :(

the goal is to make it a working document, we (those who care about 
this issue) can pitch in and improve.

this actually is something carl wanted IIRC  :-)

as I said, its a new page, I'm only going to add a link within the 
devices entry....

Agreed, and a few links in the comment column would help here and 
there :)

so carl can easily refer to it.

CureCode priorities haven't been as usefuul as we hoped, though they 
have been quite a bit better than nothing.

its funny that carl complains about people becoming lazy with parse, 
yet the only way to get Carl's attentions really is to make it ubber 
easy for him to access it (read as: it allows him to be lazy about 
it  ;-)

I consider the ability to be lazy to be an advantage :)

priorities are a matrix... everyone does the error of viewing them 
as a list.

I do to...

I work VERY hard to be as lazy as possible   :-D

I have a few security concerns that haven't made the list yet - mostly 
requiring the rest of the PROTECT tickets to be done.

I think, that naturally, such document should be part of CureCode. 
But that is for the future. Simply put - in cure-code, you post a 
wishes too. Those might be dismissed, or accepted. There should also 
be a table called releases, where admin could add version numbers. 
Then fixed-in could use shortcuts as fixed-in 'next release, and 
the correct version would be filled-in, etc. From there, such pririty 
list and milestone releases description could be automated. But - 
we don't need it now ...

I think, that we should go for the R3 priorities, or R3 priority 
group here. We should NOT edit the doc in the wild, unless we discuss 
requests. I think, that the table is also not suited for the small 
bits. If we e.g. want Security to be adressed, we should note  - 
Security - ticket x, y, z

the idea is to be sensible in any case.

like for any part of the wiki.

I'm drafting a really nice document... I have a few new ideas which 
you might like in the proposal...  :-)

(relating to my R3 devices/callback stuff)

Add these to the list:
- (UN)PROTECT /lock
- Protecting loaded module headers

ok, what I'll do is put *NEW* in the priority column for any item 
we add

That second one depends on the first: secure protect is only half 
done.

hum I get an R3 error when I save the document on wip

make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/home/rebolc5/public_html/r3/docs/devices-proposal-draft.html}
    arg2: none
    arg3: none
    near: [deline to-string read file]
    where: 'read-text
]

I have a rank of 50 on devbase... it should be sufficient no?

I am not sure if to create the priority group? Because then regular 
discussion might start there, and we will have channel split. OTOH 
why have things all in one channel? What do you think?

Well, save your changes locally and ping Carl with the error. It's 
probably a file permissions missetting on the host.

yes... create the new group, its time R3 started splitting up a bit, 
there is too much stuff all in one place already as it is.  there 
should have been a new R3 parse created a long time ago.

Done.

good

;-) newline

I think that our Linux and OS-X friends are going to get 2.100.87 
release soon too :-)

Actually - they were released already - but only for OS-X Intel and 
Linux/Fedora, so far ... I think Kaj can upload new version to his 
R3 demo site :-)

I have thought of a way to re-cycle devices as the actual interface 
for threading.  the nice thing is that my new proposal includes function 
calling and port modes... so we could build threads inter-comms using 
any of the two methods  :-)  actually, we could implement the WHOLE 
threads system ourself... we don't actually have to wait for Carl 
to do it.

I would not do it that way, as we surely want it to have in a form 
of a dtype, so unless you get utypes, you can't do it ...

this would also be re-used for LNS, which means LNS could be based 
on a DLL, or tcp, or threads... from the clients pov, he sees no 
difference.

a port is basically a datatype.

but you'd also be able to do something like:


a: import thread ; this creates a process, connects ourself to it 
using device interface.

a/do-something-in-other-thread arg1 arg2

:-)

do-something-in-other-thread  would be handled like a callback in 
the thread.


so its uber simple to setup.  you could also do a reverse device 
setup, since the R3 process would contain both driver and client 
code, all you'd need is for the device to have a command which tells 
it how to connect to you, and you become both driver and clients 
for each other.  making it very easy to provide async comms in both 
directions.