AltME groups: search

Steeve, to-block is used in a lot of code to *copy* and/or convert 
to blocks. We depend on the copying behavior a lot.

to-string does the same oas to-block.  even I have come to depend 
on the copying aspects of it, and I can assume that many others do 
to.

one question I have... does the object type also copy every series 
included like in R2 ?  that, IMHO one of the biggest regressions 
in rebol's history.   reversing the copy is impossible to do perfectly 
(scanning the new object, and attempting to link back the old series). 
plus it slows down rebol in a few ways.

MAKE object should just copy blocks, parens and functions - those 
are what can be bound. It shouldn't copy anything else.

That is why I suggested AS and AS-* functions, Graham. The AS-* functions 
in R2 won't work in R3, but something non-aliasing would..

A continue should skip the rest of a loop cycle and advance the loop 
to the next cycle based on the condition of the loop.  This means 
it is far more efficient than our current methods.

You may be disappointed in continue then.....At least in the current 
alpha some evaluation takes place.
     R3 ---  for n 1 5 1 [print n continue xxx: 999]
     R2 ---  for n 1 5 1 [loop 1 [print n  break xxx: 999]]
Both R2 and R3 end up with xxx as an unset word in system/words

Sunanda try profiling the R3 version with and without the xxx word 
and see if there is a speed difference. If not, then the word appears 
due to binding on first use of the block.

CONTINUE has the same overhead as BREAK, EXIT and RETURN, so be sure 
to factor that in in your performance calculations.

Brian, is it possible to expand on that (setjump/longjump), or is 
there a Carl post that summarises?  This is good to know - specifically 
as it relates to R2 and R3 implementation...

By the way, doing

	find first system/words 'any-word-you-like


will always succeed, because before the console evaluates this line, 
it first loads it, so the word will be added, and thus, be found.

READ of file and http ports is binary, so no /lines.

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

I read through the Virtual Block Scheme thread on rebdev and it looks 
quite cool.

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.

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.

yes Paul it uses 2 files: an index and the data

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.

No Henrik, the data are stored like rebol values (not in binary or 
other obfuscated format).

It means that you can load the data files (with load %data) and you 
will load that whole block into memory.

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

it might be useful in cases where you want to store images and such.

Steeve, aside from the REBOL-syntax-storage aspect, your virtual 
block scheme sounnds like the RIF (REBOL Indexed Files) proposal 
that was at one point intended for inclusion in R3 (and may still 
be).

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?

It can be used on binary data as well as ascii data and will carve 
out the blocks of the buffer.

>> 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]

Which is incompatible semantically with overloaded functions. You 
can only overload functions in languages where functions are declared, 
not where they are constructed and assigned.

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

Yup, likely using the same function construction functions as R3 
if you like. Unlike FUNCT and FUNCTOR, that problem doesn't sound 
like it would require anything new to make things easier.

C and REBOL, with some C++ in linked libraries (AGG).

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.

and i have no ftp currently T_T

the main objective it to allow programers, to switch between normal 
blocks and virtual blocks when they want without the need to rewrite 
their code

Really? That's new. I'll test that and mark the associated ticket 
as tested if so :)

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 :)

Strange again, i do my script as-is and it works...

ELSE hasn't been used since R1, and has thrown an error since the 
first R2 betas. Can we get rid of it now?

(ouf i'm saved, i have cigarettes and whisky)

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.

Lies, damned lies, and statistics
 :

525 tickets on CureCode Rebol3
41 dimissed
2 completed
482 outstanding

The 2 completed are documentation requests. The reason the tested 
and dismissed ones are not marked completed is because I don't know 
the policy for making that distinction.

virtual block looks very cool !   how were you able to use the same 
words insert,copy,etc.. on new datatype (I suppose without changing 
the initial insert functions) .. can this be done in rebol, I thought 
it's not possible but being able to define something like generic 
words on custom datatypes would be very important function? hm.. 
while I am at it... I realized I have no idea about what datatypes 
in rebol are and if one can make it's own..

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.

Ahaa.. I saw ports and schemes mentioned and that you can define 
your own, but still have no idea what they are, will need to read 
more about it..

rebol is both very small and very big at the same time

yes, I realized .. that's why I said big.. usually there are functions 
and variables, here are so many things, dialects, schemes .. etc 
:)

that link doesn't work for me , and I also don't have r3 to test 
it

I work on the GUI and point out bugs to Carl.

C is only Carl and Cyphre. Everyone else only work with REBOL. But 
we are allowed to contribute C code if he wants something specific.

Yes, but he is very busy with QTask for the moment. He has contributed 
HTTP, REBOL/Services and the first prototype of the VID3 GUI.

well, there's me (GUI), BrianH (smart guy), Brian Tiffin (docs), 
Cyphre (graphics), Gabriele (network/GUI), Pekr (communications), 
Maarten (network), and about 10 others who've made contributions. 
Didn't really want to mention people in case I forget important ones.

I think Steeve and Doc are involved in some manner as well.

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

OCaml for example has optional arguments , but you HAVE to use parentesis 
like this oneorwto 2 ( add 3 2 ) and every value that get's returned 
from expression must sink into something explicitly ..  so if you 
don't need it you have to still use     >> let _ = somefunc 10 in 
<<.. or >> ignore ( somefunc ) ; ..

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

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)

give me a convenient place and i post it

And crashes them.

and move all related msg please (Argh...) :)

Oh... excuse me Henrik, you requested it and you could do that too...

(lightweing in sense that they can be created and destroyed quickly 
and that there can be many of them)

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

Janko, the problem is that REBOL at least in R2 doesn't give us the 
control of memory and such as I would like.

But the real attribute that we would need to take advantage of is 
registers and we can't do that.

his loading the full database in memory, in 2 different blocks (the 
second one rebuild and sorted each time you connect)

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 !!!!!

And you have the light version currently, the console version.

It will be worst with the GUI if Carl doen't change his conception

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.

The chat can be changed now because it's tiny enough, 

But 50% of his conception is wrong and has to be rewritten to deal 
with direct access in files instead of loading all in memory.

Yes i read carefully his script, 50% of it must be rewritten now...

More Carl will developp the GUI and the console version with wrong 
choices (to my mind) more it will be painfull to rewrite all later.

The chat database will be tiny enough for months. We aren't even 
done with the feature set. The internals can change easily. There 
are less than 700 messages, and we don't start having problems til 
100000. I think we have time for this.

I only reacted with your false statement, that it's easy to modify 
the chat to kill the memory overhead.
You didn't studied it carrefully enough.

I know there is no chance that Carl and other gurrus follow my advices.
But I know i'm right, i hope you will not regret it later...

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)."

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.

Gabriele, it's your opnion not mine. we shouln't have to use DBMS 
or other external products (having to install them) for rebol applications 
which are standalone and not multi-user.

The file scheme of Rebol can do the job with a simple scheme wrapper 
(to hide complexity).

This has been requested by the community since long time ago. If 
you don't see the interest, good for you but let the other hope.

By the way, as Brian say, RebDev can stay as it is for a moment. 
It's simple Rebol data, so it could be easily transform to whatever 
new storage mechanism is needed when the time will require.

And, I don't think the client need to load the whole msgs db as most 
of the time (99.9%) user just read the lasts msgs. So It can be changed 
to cache last 10000 msgs and will only deal with the full db if user 
ask it to do (ie : search).


And to finnish, 24MB is not much for 100'000 msgs. I would not bother 
until it reach 200MB (It's what FF3 take after half a day of surfing) 
so I have 800'000 msgs left :-)

Carl: "most of the scheme structure has been solid and unchanged 
for more than a year. The main disruption was Unicode, but that's 
been done for a while too. I think we should pick a few very simple 
protocols, maybe one like Finger, and j ust show how they are done... 
as an example."

Steeve: there are opinions, and there are facts. It is a fact that 
you can't be faster / more efficient than the OS. It is your opinion 
that you want to be less efficient.

Today I read acrticle about DB  market. There are going to be some 
specialised DBs in future, and the needs diversify and scenario usages 
too. E.g. IBM has SolidDB in-memory DB, which uses async syncrhonisation 
to DB2 or Informix or something like that ...

I am also sure DB's will specialise and already do (couchDB, bigtable..), 
and I plan to make few simple specialised storages to for some my 
projects.

We have not the same defintion of efficience. 

The efficience of an application is a grid which contains several 
criteria. 

When you choose an implementation. All these criteria can't  have 
the best value together

Hiding this complexity by saying i'm efficient, and you are not, 
without saying you choose to lower some criteria, only reveals one 
thing, you're pretentious.

Can anyone give a range of time where rebol 3 will be released? If 
not, can I just be notified by email when it is?? I'm sick of logging 
onto rebol.com and checking the blogs. I've been doing this for at 
least a year and I'm sick of it.

sick of it

  seems a bit extreme.... there are other good reasons to check in 
  here.


But that aside, how about simply setting up an RSS feded off Carl's 
blog, and set it to pull once a month or so?

I personally take visiting blogs as a good sport, and am always glad 
that there is another blog posted, another piece of info available. 
You now have "what's next" kind of summary on rebol.com available, 
so how can you be sick of something, which CLEARLY states facts?

... I can understand, that you might be upset because you can't probably 
touch R3 yet. But that will change rather soon enough too. But even 
then - it is still going to be unfinished alpha, so if you plan R3 
level of functionality with all protocols, etc., you will not get 
it. OTOH you might get some new things .... R3 is product under development, 
and that is what we should remember.

Nicolas, the best you can do is just wait a few months and see what 
happens.

I know of a killer app for REBOLers. A few lines really: one BIG 
RED BUTTON that launches on startup of your PC and turns GREEN the 
day R3 is released.

Steeve: again, that is your opinion here. The OS will always be more 
efficient at handling syncronization between memory and file, be 
it a swap file, or using mmap() and so on. So if your reason is "saving 
memory", then you are wrong here, because any real OS will do better 
than you. Then of course there's Windows, but that's a different 
story...

Okay, I get abuse, a good answer - "check again in 2 months", and 
banter. Pekr, "soon enough"? - what does that mean? and when I get 
it, it'll be an alpha? Now, I don't want to agravate anyone. But 
I'm tired of having absolutely no idea when rebol 3 will be out, 
and out of beta. An acceptable answer to me would be something like 
6 months give or take a year. If that kind of assurance can't be 
given then I'd like a bit of honesty. It's nice to be able to plan 
things.

Nicolas - every sane person should be able to read between the lines, 
no? So I tell you that all you can get for now is alpha, and you 
ask, if it is going to be an alpha? Waht if NOONE really knows, when 
we will be in beta stage? There were various propositions, and mine 
proposition was to create 3.0 with fixed featureset, and then go 
with 3.1 and later, adding other stuff. I can e.g. imagine 3.0 beta/full 
release just with GUI and R2 level featureset, plus Unicode, which 
is in there. Later can come things like plug-ins, threading, etc.

It's hard to plan at the alpha stage, especially since R3 is not 
at feature freeze at this moment. I use REBOL full-time here, and 
I won't be using R3 in my own projects for another year or so. It 
would be crazy to start doing that now for me. For new users, it's 
a matter of waiting. There is simply nothing else to do.

R3 development effort takes much longer, then we all initially wished 
for. But - in the end, it will pay of. What we should now concentrate 
upon and be grateful of is, that we can be involved in the development 
process, offer our ideas, influence final desing. Carl is exchanging 
ideas with the group on daily basis.

From Pekr: "I already asked Carl for some resolution towards RebDev. 
I really don't like it. We should get back to the main task - R3. 
So - my proposition is to create some plan to link apropriate RebDev 
chat to CureCode and other chat to current DevBase and get back to 
R3 GUI to get it to state, where we can rework DevBase, create RebDev 
GUI client, etc."

It is easier to add the VCS parts of DevBase to RebDev chat and rename 
RebDev to DevBase (the current plan) than it would be to get DevBase 
into a usable state. I know - I am the lead programmer of DevBase.


What we really need to do to is get the project to the point where 
we can release it to the developing public without it turning into 
a disaster and the project dying. We needed a way to enable and organize 
development discussions, completely integrated with DevBase, to help 
people cooperate instead of hinder the project. We have that now.


I agree that the CLI client for RebDev sucks, and that we need a 
GUI client. We don't need it *now* though: RebDev already works better 
than AltME for our purposes, and we can do the GUI after the public 
release. The messages we write now will still be there later, ready 
to be read in the GUI client if you want to wait for that.


We absolutely do *not* want chat in CureCode - comments in CureCode 
are *documentation*, not chat.


Because we went the route we did R3 is nearly ready for release to 
the developing public (as an alpha). If we had done as you suggested 
we would not be so close to release. Keep in mind that what you are 
suggesting we do is what we were doing before, and it failed badly. 
That is why we are doing what we are doing now, which is succeeding.

We are at a point in the development of R3 where we need the help 
of the rest of the REBOL community. This is why I think complaints 
from people impatient for R3's release are silly: Noone needs this 
release more that the people who are already working on R3. We will 
be releasing soon because we need to asap. The only delays to release 
now are practical ones, and not many, and we are focusing exclusively 
on fixing those problems right now (sorry Steeve, we'll get to the 
concerns you have been expressing recently, after release).

You might have noticed the creation of the GUI world, even though 
we already had an alpha world, and the tiny number of people who 
were invited to the GUI world, especially at first. For that matter 
remember the creation of the alpha world in the first place. These 
events happened because AltME failed as a medium for development 
discussions.


AltME lacks the moderation and organization facilities of RebDev. 
If there are more than several people in a world communications break 
down. One troll and the process grinds to a halt. If AltME was good 
enough, R3 development discussions would be happening *here*, instead 
of talk about religion and politics.