World: r3wp

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

http://www.rebol.net/wiki/Devices

New document on devices.

I have read that Carl asked your opinion about embedding SQLLite 
in REBOL. What about it ?

http://www.rebol.com/r3/docs/functions/bind-q.html


Carl posted a note in the BIND? function, that there are two types 
of bindings. I hadn't noticed that before, so it may be old news, 
but now we know.

Good to see the old news documented somewhere outside of CureCode 
and the blog :)

BrianH: what is Console2?

http://sf.net/projects/console/

BrianH: did you know about the 'evoke function? :-)

Only of its existence, not how to use it.

evoke 'someword gives instructions

it is now clearer, because of my stack-size request ...

I had to put new ticket there though, as we need stack keyword for 
secure ...

secure none
evoke [stack-size 1000000]

I don't like the entire removal of security in order to be able to 
raise the stack. We need secure [stack allow] or even better secure 
[stack 1000000], and in such a case evoke is not needed ...

Apart from that, I don't regards #1252 to be solved. Carl just allowed 
the stack to be settable, but he left default value to be at 1/4 
of the R2 value. 4009 recursion stack limit? Come-on ...

Secure evoke.

Secure evoke? Yes, if 'evoke will be used for some other magic things 
than setting the stack :-) I wonder what is its another usage :-)

A suggestion, not something that yet exists.

I know - you might add it as a comment to #1259

it is maybe better than secure stack ...

as for Console2 - but that is gfx console, no? Will it work on terminal 
set-up?

R3 is targeted at low-memory applications as well.

Think about it: Even on a high-memory system, you might have dozens 
of concurrently rnning R3 instances, particularly once we start compiling 
ouur own hosts. Maybe hundreds. Memory adds up - better to start 
small.

Does raising the stack to 1mil for e.g., consumes much more memory?

Yes, much more.

Hmm, more on evoke:

>> evoke '?
Flags: crash-dump delect watch-recycle watch-obj-copy crash

... so its help is not adapted to reflect stack-size parameter. Will 
CC it ...

BrianH: I DDed Console2 - how can I make R3 to open in the Console2? 
:-)

You can't, because it unnecessarily allocates its own console, as 
I noted before. To be fixed.

hmm, but even if it would not - how do you tell to general app, that 
Windows has now new console available to be used?

I want to be able to run R3 from the *Windows* command line, not 
its own copy of the Windows command line.

You call the app from that console.

aha, so it just "switches" to >> prompt, and here we go - R3?