AltME groups: search

How do I submit a request for Carl to include a feature in R3?

except, rebdev seems to be down. he said that some changes were going 
to be made... will see if it comes back up in a few hours.

Henrik my request is a change for ports.

So a block of blocks would be returned.

Oh, didn't know that.  Got a link?

Other port schemes will differ. Steeve is working on a block port 
that looks really cool.

Oh I know it would be possible to do but at a cost in performance 
I would suppose.

Performance of ports is greater overall, so that is a tradeoff I 
am willing to make :)

Paul, please read those ones:

http://www.rebol.net/wiki/Port_Implementation
http://www.rebol.net/wiki/Ports
http://www.rebol.net/wiki/Port_Examples(a good one ....)
http://www.rebol.net/r3blogs/0127.html"Pruning down

Well that is why I do currently in the newer Tretbase.  I actually 
read blocks from a file and they contain REBOL values.

We can afford to wait for now: It will be a while before there are 
enough messages for that kind of optimization to be needed.

Steeve, can you explain in a few lines what it does? It simply stores 
a block as a file and lets you seek/edit it?

Right Brian,  but more the client grows more it will  need time to 
rewrite it.

The hard work doesn't come from the replacement of blocks with  virtual 
blocks (it's minor).

The problem comes from useless needs to reload and sort blocks in 
memory after each connection.

Outside the big respect i have for Carl, it's a poor conception, 
sorry.

So virtual blocks is a storage of blocks in a blocks that is then 
loaded into memory?

Henrik, yes a virtual block act like a block, you can use most natives 
which handle blocks as is.

The gain is that there is no block bloating the memory, all actions 
are converted to file actions.

So you can work with blocks containg millions of data with no pain 
and overhead.

Your storing data in blocks into a file that is one large container 
block?

So is a virtual block in essence a file?

This is a bit like Tretbase.

so the data is a plain binary?

Tretbase uses data and a index.

yes Paul like your tretbase conception, the only difference is that 
it's a scheme and there is no new functions to deal with.
The programmer can continue to think is working with a block.

Mine is a bit different.

Paul, i can't test the perfs currently, because there is some remaining 
bugs in the file scheme, so that i have to open close the ports each 
time a value is append in the block.

In Tretbase, I decide to incorporate a second method that uses just 
the data file and reads blocks from it.

It required that I had to create a block parser.

So can specify how many blocks of data you want to read at a time? 
 Like say I want to read 10 blocks and stop and then read 10 more 
where that one left off?

Sorry I got distracted - I had to use some mighty puddy on a chair.

I have a function called get-block which I use to handle block reading 
currently.

It seems rebdev mobile is down right now, so I made a screenshot 
of Steeve's example post:

http://rebol.hmkdesign.dk/files/r3/gui/182.png

>> a: "this is a test [now a block] garbage [another block with a 
block in it []][and another] garbage..

 == {this is a test [now a block] garbage [another block with a block 
 in it []][and another] garbage..}
>> get-block a
== [now a block]
>> 
 get-block a
== [another block with a block in it []]
>> get-block 
 a
== [and another]

Correct, how about default parameter values when no arguments are 
passed and a function is invoked?  That would be a nice feature to 
have.

We can do this now in a more complicated manner.

No, that's feasible in theory, but only for arguments that are optional 
in the REBOL style, using refinements (or any-type! for the last 
arguments) - REBOL's evaluation model depends on knowing the number 
of arguments. In practice the current method may be more efficient 
- we can see. That could be handled by a function construction function, 
i.e. FUNC, HAS or DOES.

I can already do something like this:


fnc: func [a [unset! string!]][either value? 'a [a][a: "I got value"]]

but it would nice to be able to do something like this:

fnc: func[a [string!] /default $10 ][print a]

fnc 
>> $10

where anything after /default is a default value for the respective 
parameter.

I didn't know how deep changes were being made with respect to R3. 
 Maybe a wish for R4.

It has nothing to do with the implementation language though - it's 
a syntax thing.

Languages that wrap function arguments in parentheses (like C and 
Pascal) or are line-oriented (like Basic and Python) or at least 
have statement separators (like ; ) have a way of telling where their 
argument lists end. REBOL can only do so if the arity of a function 
is determinable at the call site. This is the price we pay for getting 
rid of the parentheses.

That is not a matter of internals, it really is a consequence of 
REBOL's evaluation rules. You can't change it without changing the 
language in drastically incompatible and slower ways.

Ok, i made a demo using the virtual block scheme (tested only with 
the last alpha)
Sorry for my frenglish
http://www.MegaShare.com/573256

Why you use such a site instead of using for example rebol.org?

Oldes, it's a first try, then i will post it in rebol.org

Paul, try reloading the page a few times. It worked here.

I'll check it out in a few months.  ;-)

Watch out: R3 currently doesn't support documentation or anything 
other than whitespace (if that) before the REBOL header. Yes, it's 
a bug. You will need to remove the docmentation from the beginning 
of the script for this to run.

Brian write them please i'm a bit lazy with that bugs.

That was a comment on 2 messages past.

ot, Brian: could you have Carl build a 2.7.7 alpha/beta with all 
the work you have done? shouldn't take much time for him 8)

Will, I haven't done a lot of work for R2 lately - only Anton has, 
afaik, and we haven't even gone over his submissions yet. After the 
R3 public release happens and the next DevBase is running we can 
work on a R2 release. More backports I hope :)

Nope, still doesn't work.
>> write %blah to-binary "hello^/rebol [] print 1"
>> do %blah
** syntax error: Script is missing a REBOL header: hello

** Note: use WHY? for more about this error

Weird. Do you use a different LOAD than the one in R3 by default, 
or a different SCRIPT?

Question for the community:

It has been a long time since REBOL 2 was first released. Is it finally 
OK to remove the ELSE native from R3?

yes !!!! got it !!!
REBOL [] must be in uppercase it not, it failes.
Give me a medal Brian

it's not a bug Brian, onl

We have a lot of hot programmers in the community... :)

f: func [n] [if n = 1 [print 1] else [print 0]]
f 2
Re else;
** Script Error: else has no value
vs
** Script Error: else is obsolete. Use the EITHER function


Second one far better for new to REBOL people imho.  The'll only 
do the second case twice in a career, the first may have them scratching 
head for 10 minutes and giving this new REBOL thing the boot.

It would be grest if you could get the tested requests marked as 
completed as the stats give such a bad false impression.

Btw, ticket should be closed by the emitter once the fix is released. 
If the user don't do that after a given period (let say 1 or 2 weeks, 
one of CC's admin or developers can do that instead).

Janko, because the supported functions like COPY works on ports, 
and virtual blocks is a port scheme, customizing how COPY works with 
that specific scheme.

(in a good way)

so it's not a new datatype, but a new scheme for port!.

I saw some tutorial about creating new "protoco handler" .. or is 
that a third thing?

if you read about ports in the wiki, they'll give a fair explanation 
of how they work.

Janko, yes, exactly. If you open a port, you get a port object with 
information about what the scheme does. When that port is passed 
to COPY, appropriate actions are taken to carry out the COPY function 
that resides inside the scheme.

Is there a list of all those contributing to R3?

Paul: when you were asking about default arguments to funcs before, 
I think it's a "conceptual" limitation because of stuff like this 
example (for example that oneortwo can take 1 or 2 arguments : >> 
oneortwo 2 add 3 2  .............  and most things like if either 
are expressions which means they return a value (which you sometimes 
need and sometimes not )  you can "assume" that you will always require 
result of add because it has no side effect, but for example : >> 
oneortwo 2 if [ insert copy [ ] 1 ] ..... there is no theoretical 
way to determine if result of if SHOULD be taken by oneortwo or not

thats probably why refinements were invented , that also add a lot 
of new

(but I am a ocaml newbie too)

[Virtual blocks] What do you think of an option to allow fixed-size 
records only, so that there is no need to create a file index (faster 
access but data file possibly bigger)

yes that would be a cool option too

well at least there is a chance :) .. well I don't know when I will 
be able to try R3 at all, and even less when I will be able to use 
in for real projects... that's why I am asking, but I don't "urgently" 
need it right now so no worries for me

will R3 have something similar than coroutines or a way to simulate 
cooperative or preemptive (green-not on os level threads) concurrency?

Tasks are very interesting, as it will render slow and large cooperative 
threading libraries for R2 moot. You create a task like you create 
a function and it can be used in the same way, except you are returned 
to the console right after calling it. Also networking is completely 
async on the lower level, which helps speed up network operations. 
You can achieve similar things in R2 through hacks, but it's not 
well documented or stable.

Janko, I can't be completely sure that they will stay that way. This 
has something to do with the Wildman project, which is about getting 
R3 to run standalone on embedded hardware with a minimal OS underneath. 
So whether R3 will then employ its own threading model or always 
use OS threading, I don't know... and Wildman is not something that 
will happen soon.

well it's very nice to know that something is being developed in 
this too.. cooperative threading and async io is a lot already.. 
if there will be native threads it's just a very big additional bonus, 
(even factor, which is very progressive lang. in terms of core features 
and libs will have os level threads only in version 2.0 for example)

[virtual blocks] it would be more convenient to create a new scheme 
for fixed-size records. I don't want double the size of the current 
 scheme just for a new option.
(Most of important actors have to be rewritten)

give me a convenient place and i post it

Brian, could you create a sub header in R3/protocols for the virtual 
block scheme ?

[VBS] Did you realize that 1 000 000 values can be fetched in a loop 
without bloating the memory in only 1 SEC

[VBS] SORRY, i made a wrong read, it took 1 sec to fetch 10 000 values 
not 1 000 000 but it's quite good too, no ?       -_-'

Here is a fetch of 10,000 records:

>> s: now/precise db/get test d t: now/precise
== 22-Jan-2009/12:13:34.534-6:00
>> difference t s
== 0:00:00.973


Pretty much about  1 second - similiar to what your seeing.  I don't 
think we can get much more performance out of REBOL than that.

this is maybe a good idea to develop something in gihert level language 
to figure out all bits and pieces and algoritms, and then when you 
have a good picture port it into c

Hum currently, it's a problem for me, he said that his RIF conception 
have better perfs than VBS.

He said too that i  have not done the best choices (missing cache 
for example).

He said too than doing such a scheme is complex (beyond my understanding 
???)

I don"t want to work on a thing which will be uselless when R3 will 
be released.
He said better perfs with RIF, so RIF works currently...
I wonder why rebdev is not using it...
I'm a little bit disapointed...

I think we just don't know all the capabilities that we can harness 
with REBOL.  Regarding caching, I know that you have to tune how 
much you send to a read/write request for optimal port usage.  Carl 
is going to know the underlying details better than we would.

hm.. I would be a little disapointed to :(  ... but when will RIF 
be available then.. isn't time in general problem with RT

RIF is not going to come right now. That is probably a feature for 
3.1.

so i can make an estimation of the memory used for 100 000 messages, 
wait a minute...

I take 16 bytes for storing a value in memory (like for R2) i don't 
 know if it's more in R3.

An unique message has a structure (a block!) of a minimum size of 
80 bytes, so i take 110 bytes (for a small message of  30 characters 
in average).

for a block containing 100 000 messages we have 100 000 * (16 + 110) 
= 12 Mb

So for the 2 blocks , we have 24 Mb, just to deal with 100 000 messages.

It's growing fast, because rebdev store many events too (remove, 
private message, move, etc...).
and it will be connected to devbase too.

I think that  thousands of messages  and events will be added per 
month when the community will have access to rebdev.

So his current implementation will resist 2 or 3 months before reaching 
tens of Megabyte in memory usage.

And when it will go over 100 000 messages (in 4 or 6 month) the perfs 
will blow !!!!!

i made a wrong statement

the second block uses references not a copy of the message, so that 
the second block has a size of 100 000 * 16 = 1,5 Mb

i can do a prediction, it will end like with Altme, using 50 Mb of 
memory after one year of usage

A couple things to realize:

- The chat client can change easily, independent of R3, and does 
change daily.

- Our priority is on making the public release happen ASAP. Chat 
reaching its limits is months down the road at worst. We have time.

Many eyes make bugs shallow. We need more developers, which means 
we need a public release. Priorities. We can fix chat *after* the 
public release. As it is, getting the file store in place is a more 
pressing need. That way we can release and track the source. Once 
the source is released we can make fixes as needed. The priority 
needs to be on testing R3 itself, not the chat client. We aren't 
even going to start the GUI chat client until after the R3 public 
release.

It's good to see a little realism about the scope of R3 when Carl 
posted this in RebDev:

Regarding RIF, it will be in 3.1 (not 3.0) and it will provide a 
lot of the 

virtualness" needed for what I think your goal is (to have very large 
blocks for large datasets)."

From what I understood, RIF would have several advantages compared 
to a mezz-level approach :

- fast indexed storage engine in C (probably btree indexes as sqlite 
storage layer was considered for RIF)

- no LOAD/MOLD overhead (direct reading/writing of values in memory)

Or it could be a UDT.

Just be thankful R3 is not a 100 year language like Paul Graham's 
ARC.

Steeve, as long as you're using a decent OS, any database should 
be kept all in memory regardless of size. Otherwise, you need a DBMS 
and a DBA.

Yes, some DBAs can do amazing things wih disks (disk tuning is a 
good selection criterion for a DBA)