World: r3wp

New REBOL3 group started.

Ahhh... finally some sanity. For a short time at least.

(If you peek at worlds/rebol/chat/453.set you'll notice it's over 
20'000 messages that must be loaded into memory on server and every 
client.)

!REBOL3 -OLD1    20905 messages
Core                         15498 messages

So, start a new group after 20000 messages?  For higher access speed

WJ: It will be much faster.

I would just use a DB and avoid loading it into memory...

yes, SQLite is ideal :-)

21K messages ...whaow we like to talk about R3 ...  one of the most 
passionate debate should have been rebol/core mathematic engine lol 
... (no i'm not trying to start another 5 K message feud lol... well 
you know i'm all crazy that's me ...)

21K messages ...whaow we like to talk about R3 ...  one of the most 
passionate debate should have been rebol/core mathematic engine lol 
... (no i'm not trying to start another 5 K message feud lol... well 
you know i'm all crazy that's me ...)

double post? :-)

We should start creating subgroups ... .. as we have for  R3 GUI 
and R3 Schemes

Maybe would be good to make RIF for it. Thatis supposed to be the 
killer app for RIF. (and that is what I understand the use of RIF)

Anyway should the RIF be object wise or schema wise? Ie:  Rebol3/add 
[message ..] or add-message Rebol3 [message..]

Or use Database thru port by Ross Gill, maybe some indexes would 
be added

those 20k+ !REBOL3 messages are a mere 4.4MB on disk ...

Will there be any R3 update soon? I can see last update (Host kit) 
was on December 12 :-)

Yes, it's been a while... so I'd first like to do a quick bug fix 
release, then move into the other changes, as we've talked about.

Robert, It's interesting the tradeoff these days between a DB and 
loading REBOL data files.  For example, the MySQL that runs the wiki 
on REBOL.net consumes 130MB of main memory on that machine!

By comparison, the RebDev server (R3 Chat backend) is using about 
9MB.  IOS is using 12MB.

I drove IOS to the limit, it's using around 140MB. Would be much 
less with a DB and it's just faster if you need to slice & dice data-records 
form one or the other side.

But the DB needs to be small, I agree.

Wow, that is quite large.

And If I send a 20MB file it bombs... but you know that ;-). But 
that's not a critism. IMO one just needs to know when a DB can be 
of value to allow small-footprint scaling.

Why to use mySQL? FF, Chrome - those are using SQLite ... small and 
cool engine ...

I use firebird and it's only less than 1Mb .. so why is mysql consuming 
130mb ?

If you're not using innodb, you should switch it off by uncommenting 
skip-innodb in /etc/mysql/my.cnf (default place for the config file). 
This will save you ~70MB. For the remaining 49MB, I don't know, I 
guess that a good part of that is used by caches.

R3 is picking up speed.  


USERS are starting to take charge of various projects.  I just wanted 
to make everyone realize just how different & better the R3 ecosystem 
is today than it ever was for R2. 

congrats everyone  :-)

we need to get back to proper R3 releases though. You know, some 
few months ago, there was something like 80 tickets implemented per 
month. Now R3 development is a bit halted. It is important to finish 
some features, before jumping to different tasks. The most important 
right now is to enhance extensions and finish Host Kit (especially 
move View to command! interface), so that ppl can continue with their 
contributions. But that is not happening. I can see even some questions 
towards Extension usability to not being answered on R3 Chat. We 
should really refocus ....

having played with customizing the extension kit by merging some 
of the extension code into (on my own)... and building a generic 
call-back system for R3, I can see how it was a bit of a pain when 
Carl extracted View out of the core and put into an extension.  its 
not a trivial task and there are one or two things missing which 
where probably added to the last host kit and extension package to 
fill the gaps.


for one thing, Carl must have had to unify the source files and possibly 
re-organise a bit of the includes.  this is the kind of work that 
is tricky, painfull and extremely bug prone... with ZERO gratification. 
 it just craps out over and over, until you resolve all the dependencies, 
bugs, missing links and figure out how to re-organize code until 
the make tree "works".  


if it where just one OS/compiler it wouldn't be that bad for such 
a fluent C coder like Carl, but having to support ALL of them in 
a consistent way is very painfull and usually laborious.

AFAIK this is working at some level, but still not released at large 
by Carl.  possibly still some stuff to iron out.

When is the next build coming?

this is my code ...

		match-mark: func [msg generator /local r] [
			trace/function on
			?? msg
			?? generator
			r: find/part msg generator 5 
			?? r
			trace off
			r
		]

And this is the trace ...


<-- trace == unset!
    --> ?? msg . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? msg
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get msg .
            <-- get == "A0003 OK [READ-WRITE] SELECT completed"
                --> mold "A0003 OK [READ-WRIT... . . .

            <-- mold == {"A0003 OK [READ-WRITE] SELECT completed"}

        <-- ajoin == {msg: "A0003 OK [READ-WRITE] SELECT completed"}
            --> print {msg: "A0003 OK [REA...
msg: "A0003 OK [READ-WRITE] SELECT completed"
        <-- print == unset!
    <-- case == true
<-- ?? == "A0003 OK [READ-WRITE] SELECT completed"
    --> ?? generator . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? generator
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get generator .
            <-- get == "A0003"
                --> mold "A0003" . . .
            <-- mold == {"A0003"}
        <-- ajoin == {generator: "A0003"}
            --> print {generator: "A0003"}
generator: "A0003"
        <-- print == unset!
    <-- case == true
<-- ?? == "A0003"

    --> find "A0003 OK [READ-WRIT... "A0003" true 5 . . . . . . . . . 
    . .
<-- find == none
    --> ?? r . .
        --> case [ any [ ... .
            --> any [ word? :name ...
                --> word? r
            <-- word? == true
        <-- any == true
            --> ajoin [name ": " mold name...
                --> get r .
            <-- get == none
                --> mold none . . .
            <-- mold == "none"
        <-- ajoin == "r: none"
            --> print "r: none"
r: none
        <-- print == unset!
    <-- case == true
<-- ?? == none
    --> trace false . .

Now if I change 

find/part to find, it returns true ...

posted to curecode

I was trying to download Rebol3 on Mac OS X today and I was not able 
to. Is there an updated alpha for R3?

Downloads are available here:

http://www.rebol.com/r3/downloads.html

but I can see the links are dead

I'll give you a private link. Hang on...

Yes, that is what I was curious about.

ok, thanks

link posted

thanks

SQLite is not that appropriate for server side apps where there can 
be multiple processes writing into it. It's awesome for client apps 
(which chrome is) but I had some very bad experiences lately using 
it on server even without the multiple writers problem because I 
was aware of that and I used it in specific way.

By that I mean it was untolerable slow on some VPS where I assume 
same disc was used for streaming media, update was taking seconds 
while I could on the same system open a 1M rebol data file change 
it and save it back in almost no time. I couldn't get it why this 
is happening, and this was at neglegibly small database. I moved 
whole app that uses sqlite to some vps where it's almost alone on 
whole server because of this. And at Site Assistant where I used 
sqlite only for "mailbox" for bots (to send them work) I had to switch 
to mysql for this (it was the same server that blocked this heavily)

---

This is a bit off topic !

On a totally different note .. I don't know if this is doable or 
not, and if it makes sense, but I vould like to propose in discussion 
that at least native functions have some flag for if function is 
pure / side effects free or not ?

Graham: I was replying to discussion above about the need to move 
R3 chat to DB like SQLite or MySQL versus REBOL data files

Yeah ... Carl was offtopic there too.

My reason is this, big aspect of rebol is it's code / data duality 
and runtime interpretation of code, meaning you can send it around 
and all. But if I want to accept sent functions/code I want in many 
cases that they work as pure functions giving me some value out of 
my values (calculate something). Not modify anything / mutate my 
runtime env. without me knowing.