World: r3wp

OK, Maxim, the MOVE/skip example you specify is not an error in MOVE, 
it is an error in the code calling MOVE in that example. MOVE was 
specifically designed to do something useful in that case, rather 
than generate an error.


The whole reason that MOVE takes one position and one offset is because 
that limit gets rid of a host of potential aliasing errors. MOVE 
is designed to be the most efficient and safe solution to the problem 
of moving stuff, and it should *never fail* unless the series is 
protected from changes. MOVE is a DWIM function: Do What I Mean. 
This goes for treating negative /skip lengths as an error too - having 
it magically constrain the /skip length to 1 or greater was a deliberate 
design choice, the result of a lot of discussion.


So the question is whether the error of having /skip lengths being 
less than 1 is worth worrying about, worth the overhead of generating 
an error and checking for that error every time you use the function. 
Don't be fooled, that overhead is really significant.


We've already changed other functions so they don't generate errors 
anymore, and just DWIM, like FIRST not complaining about bounds and 
acting like PICK 1 now. These changes have made these functions faster, 
and better to use. Generating an error is considered something to 
do when it is really important, as it sometimes is. How important 
is the /skip < 1 error?

you have been talking about the actual /skip parameter value, and 
all along I was talking about the effect of using /skip which causes 
the function to go outside of bounds of the series based on the skip 
size... 

doh!   hahahaha

I was so off, I could have landed in ireland, while trying to go 
to the corner store!  ;-)

No, I got that about your example. The behavior you describe was 
deliberately chosen.

The behavior that Henrik is concerned with is /skip lengths < 1. 
MOVE was designed to just up that to one, DWIM.

but *I* didn't get your point  ;-)

/skip size < 1 should effectively just be bound to 1


as long as its explicitely documented.   there is no real use in 
/skip < 1

and I understand that adding too much verification to series handling 
code really slows the whole a lot.

cause its exponential in the long run.  1 % becomes 1.5 then 2.  
the slowdown rate accelerates as mezz code uses other mezz code.

its like when I discovered that using 'RETURN was slowing down some 
code I had by more than 20%!

is 'RETURN any faster in R3, btw?

The problem is that DIFFERENCE/skip < 1 generates an error, and every 
other function /skip < 1 hangs. So the question is whether they should 
*all* be changed to act like MOVE (silently DWIM), or all be changed 
to act like DIFFERENCE (generate an error).

tough call, but if it can't lead to data corruption, I'd say the 
later.

No, RETURN, EXIT, BREAK, CONTINUE and error throws are just as slow 
in R3. It's the setjmp/longjmp exception frame overhead.

Finally some simple thread reading ability in Chat:

3928

lr will display all messages related to that thread.

j will jump to the previous message in the thread.

Correction. lr lists all messages previous to the current one, not 
all messages.

It's10 years (to the month)  from this slashdotting:
    http://slashdot.org/article.pl?sid=99/05/14/1921231


If REBOL3 got slashdotted, what are the huge milestones that should 
show up as progress?

There's no R3 yet. In few months, maybe. There is many usefull changes 
in it compared to R2, R3 fixes everything we wished for for so long. 
I don't understand what you mean by "milestone" here ...

wow 10 years

Progress milestones:

Single graphics engine
VID3.4
Unicode
Tasks
Modules
Built-in chat system
Built-in open source management

Completely redesigned ports (fully documented and ready to use, you 
protocol writers)

When finished:


Fixing almost every deficiency that R2 has through 10 years of use 
by expert developers.

I hope you never put "built-in chat system" as a milestone on Slashdot...

so which other language has a direct hotline to the main developer 
in the console?

But... it doesn't matter. The Slashdot crowd will laugh at anything 
thrown at them. Then there will be a few comments from developers. 
Then there will be comments like "but it's just like LISP or Scheme". 
It will be ridiculed no matter how well we do.

In general, it is a much better idea to do marketing on ReBrowse. 
People will understand what it is. The right people will want to 
learn how it's built.

The DRAW documentation has been overwritten in Docbase with an empty 
page. Document name collision?

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

Don't put tasks on the list - they are due for a redesign. Otherwise, 
cool :)

Gabriele - why not? The chat system is more powerfull than that of 
AltME, and I find AltME usefull, although it has its limitations. 
Once we create GUI for it, it will allow for some nice simple IM 
stuff. Why do you think SlashDot ppl would have problem with it?

Btw - who cares of SlahDots at all? I don't visit if for so long 
already. Those ppl are real idiots ...

BrianH: what are your plans on task related stuff? Do you mean reworking 
highere level, or even low level? So far R3 uses threads, no? Are 
we after Eiffel model?

Found this presentation - http://www.cse.yorku.ca/~eiffel/cs_eiffel/scoop_slides/Concurrency.ppt

At least don't call it a "chat system" without the description "direct 
hotline to the main developer", as that line would stand out and 
make people think it's a joke

So far, R3 tasks don't work properly and should be considered a placeholder. 
We can't do a proper task model until there are changes to the basic 
semantics of REBOL. Fortunately most of those changes were done in 
the last month.

Main developers. Carl isn't the only one working on R3. Good to emphasize 
that too.

Pekr, the concurrency model to beat nowadays in the Erlang model, 
not Eiffel.

Perhaps thorough wiki-based documentation should be mentioned as 
well.

could this be helpful in R3? http://www.gearman.org/doku.php

Steeve, apparently Carl is working on vector! for the next release. 
Enjoy :)

Ladislav, I implemented your proposed changes to FUNCTOR, then enhanced 
them. New versions posted to DevBase. Enjoy :)

Any specs on MakeDoc3...
i do not see anything in the Wiki about it..

Well, it appears that Carl has handled *all* of the vector! bugs 
today. It looks like another good release is coming this week.

and almost all skip bugs too

Except MOVE/skip - I did that one :)

we are generally ending up with error for skip < 1?

How do you know? CureCode reports?

Is Vector really so important? I am just asking, as I don't precisely 
understand, what is the datatype good for, except one note from Carl, 
when I requested some better binary conversions, so that he said 
that it should be available via the cector! type.

for one, arrays of tightly-packed values we can use in external calls 
directly... like matrix transformations.

It's good for speed and memory saving, and better binary conversions. 
Once we have vectors, we will have less people complaining about 
the lack of rebcode, except for the people who never take good enough 
for an answer :(

And yes, Carl marks the native changes as done in CureCode the moment 
he gets a working build. I mark mezzanine changes as pending as soon 
as they are submitted to DevBase, then as build when they are released.

Perhaps vector is a requirement for rebin.

Sorry, Carl marks them as "built", even before they are released. 
A release usally comes within a day of that.

this also means we should be able to use STL  in rebol   :-)