World: r4wp

Kaj: ok, I will have a deeper look in mmap syscall later, I'm currently 
debugging the OS X version.

Nick: I'll try to do that.

Please remember we want to contribute but without a reasonable clue 
this is hard to do. (Besides the closed-source issue this is what 
Carl ran into when expecting others to contribute). Me and Github 
wil never become friends for example, I managed to get some source 
long ago but no clue how to update to the newest sources and github 
has informed me they do not wish to support their macosX tool for 
Leopard that I am running, nor remove the useless (?) check on OS 
number 10.5, and I am NOT updating my system and learning all the 
commandlines to upgrade etc is too much effort, (maybe someone can 
build a REBOL interface).

Kaj: I can reproduce a similar memory allocation error on OS X too, 
so I hope that fixing it there will fix it on Syllable too.

I don't think you should use syscalls. It's not the POSIX interface: 
that is implemented in the C library on Linux, and probably most 
other systems

http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html

Note that you need to get the system page size with sysconf():

http://www.gnu.org/software/libc/manual/html_node/Memory_002dmapped-I_002fO.html

Ok, got Red working fine on OS X too.

Syscalls: given how much a programming language has to call OS services, 
I don't see why we shouldn't try to avoid an unnecessary layer. But 
I'm pragmatic, if we get more troubles than benefits, we'll adopt 
a more classical approach.

Also, syscalls usage gives you a smaller executable (smaller import 
section).

You won't want to use syscalls for memory management on Syllable 
Desktop, because they're very different. So you'll have to implement 
the POSIX C library wrapper for Syllable Desktop, anyway

sysconf:I guess it's the right time to add it.

We already use some C calls, so no problem for adding Syllable specific 
code for that.

NickA - it's impossible to setup a USA bank account without being 
there in person to do so.  I've tried ... you have to present your 
credentials in person.

Any Paypal limitations are set by the EU ?  I don't have an issue 
with Paypal here.

Yes, it's a EU limitation.

Are protocols going to be like R2 or R3 ?

Probably more like what they were intended to be in R3. (Does R3 
have anything besides HTTP support?)

No, I think Kaj produced a Curl binding for https

I did write a ftp, smtp and hylafax protocol for R3

Red should have a more "modern" set of schemes than the one provided 
by R2, though.

And imap, and a JDBC bridge

But they were just first passes waiting for Carl to have a look and 
give advice, which never came, so they never went past that stage

So, I hope the underlying support is there to rewrite these protocols 
easily!

This is the ftp scheme Andreas and I did https://github.com/gchiu/Rebol3/blob/master/protocols/prot-ftp.r

So, yes, there are a few of us waiting to contribute when Red reaches 
that point for us

I will provide the basic ones for Red: TCP, UDP, DNS, HTTP(S), SSL, 
SSH/SFTP, SMTP. Also, I would like to have a few more for remote 
or local storage builtin: Dropbox, MySQL, Postgresql. 


You are welcome to contribute other ones to that list (IMAP, SMTP, 
MongoDB, CouchDB would be nice additions).

What are your plans for a code repository?

I will probably host a server that will provide packaged and selected 
libraries for Red (with builtin support in Red for getting them). 
For sharing code, my plan was to built some support for that right 
into the IDE.

I was looking at Amazon's glacier ( ultracheap S3 storage ) but that 
requires SHA256

( no need for dropbox if we can have that :) )

Wasn't Amazon's glacier for archiving data you don't need everyday?

Yea

And that's what I use dropbox for ...

as background backup

Not for syncing across multiple PCs

I use it mainly as way to share data between all my computers and 
my mobile devices.

I'd like to see SIP and secure SIP eventually, and the ability to 
use video streaming :)

Imagination is your only limit. ;-)

Doc - what are your plan re Uniserve? Will basic engine be present 
directly in Red, or a separate product?

Glacier allows files to be retrieved over a few hours

I've started some convesations here about helping fund Red, but no 
commitments yet.

Wasn't it NickA? I think that so far, donations come from the community 
members, in an insufficient amount. Are you talking about more solid 
funding? So far only NickA expressed his will to eventaully fund 
Red ...

Uniserve: we'll see how it fits in the Red I/O model (not written 
in stone yet), we'll probably use a newer approach with sequential 
code instead of having to write callbacks.

and concurrency? Kind of what Carl have planned? Don't remember where 
he briefly described it, but we once pushed him to say few words 
about it on Altme? Or maybe you plan on more lightweight solution, 
like green threading?

So far, the plan was to use Actor abstraction, but I might decide 
to use a more lightweight approach (something like goroutines). The 
basic idea for the low layer is to have cheap concurrent threads 
of execution that are dispatched over a limited number of OS threads. 
On the upper layer, they might appear as task! or actor! values, 
that you could create in various ways (do/task, read/write on I/O, 
...).

I also have a few ideas about specializing CPU cores in order to 
avoid costly context switching, but I need to test that on paper 
first.

It would be nice if we had something like apt-get to fetch and update 
both yours and 3rd party software

We'll probably have something like an "import" function that would 
work locally and remotely from an organized online repo.