World: r3wp

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.

I'm still working on the details... the draft is going to be ready 
in a few days, while I iron out an actual implementation example 
and work on the details.

but the end goal is that we have ONE api for just about any kind 
of REBOL interface.

So, when can we expect your doc to appear? :-) Maybe it pushes a 
Carl towards tasking being actually done for 3.0. I don't know why, 
but it seems to me, that concurrency is not planned for 3.0. But 
maybe just wrong feelings on my side, as I have not discussed it 
with Carl. Hope the reality is different ...

I tried putting a small draft of it earlier but the R3 wiki didn't 
let me... left a not on R3 chat, I'll see Carl's reply.

but I still have to go over the idea a few times so I can trim some 
of the fat in the whole draft.

it also has to be consistent, and there are some things I can't really 
go in depth, because the host code isn't yet available.

Max - OK. Just remember, that Carl wants to get it quick, or so is 
my feeling. So you should better finish it ASAP, as once Parse is 
done, he might be back to revisit the list, and reorder priorities. 
Hopefully I think that Extensions will remain high priority, as it 
seems they will be used even for Host to Core isolation ...

yep.  The moment I can add the page to the wiki I will at least post 
what I have, even if I edit it often, based on everyone's comments.

Its a proposal, an idea, something to reflect on... I'm not trying 
to prove that I have the best idea, but I really think we should 
see if what I propose is dooable... imagine, threads, dll interfacing, 
inter process coms, callbacks, LNS, all using the exact same client 
code, and much of the same on the driver side too  :-)

Have we a built-in function to decode xml data, currently ? Perhaps, 
i missed something...

R2 has 'parse-xml and its helper function 'xml-language.

You can copy their sources to R3 .... but they are currently seriously 
buggy there.


Gavin's XML parser was better in R2....It has no equivalent in R3 
yet:
    http://www.rebol.org/view-script.r?script=xml-parse.r


I guess we are waiting for parse to settle down before getting decent 
XML tools.

Well, i only wanted construct a block of tags and strings.
So i came with that, it's enough for me currently.

src: read %frog.svg
out: []
parse src [
	any [
		copy str to [#"<" | end]
		opt [if (not empty? str) (append out to-string str)]

  not end src: (set [data src] transcode/next src append out data) 
  :src
	]
]

demo error with sub-panel !!!!

error => append2 has no value

known bug