AltME groups: search

Of course, there is a limit, after which the series is grown linearly. 
I don't remember what the limit is.

At least something is usefull to know.

Never initialize the length of an empty serie with a power of 2, 
because twice this length could be really allocated (really annoying 
for large series).
Instead, reduce the length of 1.

ie.
make string! 8 * 1024 (actually, allocates 16 KB, not 8KB)

Instead i will do:
make string! 8 * 1024 - 1 (allocates 8KB, not more)

It will be a shame if Rebol3 doesn't support SSL. I think Rebol's 
buitlt-in network features such as the HTTP:// and Mail:// schemes 
used to be a big attraction. I think that not supporting them properly 
in R3, being able to read and write Gmail for example, is like shooting 
yourself in the foot from a marketing perspective.

Agreed, not being able to access GMail out of the box is a real negative...

Yes, that would be bad. Fortunately the relevant will be in the open 
source portion of R3, so it shouldn't be too difficult for the community 
to add. R3 is a community project, remember.

Being an open source part, implemented by a third party, doesn't 
mean it's not "delivered by RT" as seen from the user's perspective.

I think people are still thinking of R3 based on the situation with 
R2. With R2 if something wasn't "delivered by RT", you couldn't do 
it at all in some (lower-level) cases. This is simply not true with 
R3. R3 is not a black box, and SSL in particular would be easy to 
retrofit even if the base distribution doesn't include it. Plus, 
the pace of development of R3 is pretty fast, and any release that 
doesn't have the feature you want could be followed pretty quickly 
with a release that includes it. The only limitation is time, effort, 
and money (to buy the other two). If people don't contribute, it 
doesn't get done, period. If you want the feature, add it yourself 
or pay someone to write it. Adding it yourself will be easy in this 
case - we'll see about how easy the other method will be.

implemented by a third party

 - this is just wrong. In a community project, anyone in the community 
 is a first party. The only third-parties are the ones who don't contribute.

I'm a little surprised to hear this from you two, Pekr and Henrik, 
since both of you *do* contribute quite a lot. Good work, guys :)

WIth R3, I suppose we can include as little or as much as we want 
and still get an R3, that is a whole product as seen by an end-user.

As for me, current situation means just one thing. As a customer/developer, 
looking at feature sheet for R3, searching for the SSL and HTTPS, 
all I can see is big NO.

Not looking recently enough. However, your approach is counterproductive 
here. Asking for "RT" to provide this feature is not appropriate 
for a community project. What you should be asking for is contributions. 
RT's time is finite, and we have to triage features based on their 
feasibility, not just how "important" they are. The increasing proportion 
of R3 that is or will be open source is a testament to that. Every 
part of R3 that is open source is *our* responsibility, not just 
RT's.

People can say that a feature is important, but in a community project, 
in the community-created portion of that project, the way you express 
the importance of a feature is with time, effort, or the money to 
buy time and effort. As you have done with HTTP. If the community 
thinks that SSL in an important feature to have, then get to work. 
Complaining only has limited usefulness.

Is there a bounty on native SSL ?

I should note... HTTP stalled because I never got answers by Carl... 
about how to implement timeouts (has support for timeouts been added 
to ports in the meantime?), how to handle errors (i think i have 
a decent implementation, so maybe this is ok), what the semantic 
of QUERY should be, and so on. there are a ton of little details 
about port schemes that have not been DESIGNED yet...

Bounties may not be a bad idea, but you have to get the right people 
to do the work.

I looked a bit more on MOD, MODULO, REMAINDER and //. Isn't there 
too many of those functions? I found, MOD is giving some strange 
results:

>> mod -8. -3.
== -5.0

It makes sense to me to either just use the C ways of doing modulus, 
if it's fast:

% for integer! and
fmod () for decimal!


or do it in a more correct way mathematically, maybe (pseudocode):

result of a // b = a - floor (a, b) * b

I searched the scripts in the library at rebol.org, and only a handful 
(which is very few) use MOD. A script or two even make their own 
version of MOD to give correct output.

Ask yourself, if you were going to use a modulus function, which 
one would you use? And why?

I suppose it depends on the situation. I guess there would be three 
different versions, because Carl saw a need for them all. I discovered 
the difference when I used MOD in a situation where // worked as 
it should.

I tried mod 3.3 1.1 - it reutrns a negtative number - I have reported 
this in CureCode

There are related bugs, it seems. This should return a value close 
to zero:

>> 3.3 - ((round/floor 3.3 / 1.1) * 1.1)
== 1.1


It's not good, that there still are bugs on such a basic level. (Often 
when I dig into these things, I say to myself, that I should shut 
up and wait for a release.)

I'm not questioning, that we need a modulus function (REMAINDER). 
I'm questioning, if we really need 3 of them. If REMAINDER doesn't 
do, what it's supposed to, then I would fix that instead of adding 
2 new functions.

Brian, no they can't be fixed right away. See my example with round/floor 
above. That's the way to calculate a modulus, and it doesn't work. 
:)

From your code, it looks like this is the problem:
>> round/floor 3.3 / 1.1
== 2.0
>> 3.3 / 1.1
== 3.0


1.1 and 3.3 aren't exactly representable in IEEE754 encoding, so 
the 3.0 value you see is actually a little less than 3.0.

If you want exact decimal math, you have to switch to a different 
underlying representation, such as that used by money!:
>> round/floor $3.3 / $1.1
== $3
>> $3.3 / $1.1
== $3.0000000000000000000000000

I think, I see, what happening now. If 3.3 / 1.1 is just below 3.0, 
then the round/floor will return 2.0, which is ok. So my example 
might not be a real problem after all, unless it give different results 
on different platforms.

Geomol, that inaccuracy is built into the standard, and floating 
point hardware tends to follow that standard. It's a side effect 
of the fact that IEEE754 floating point numbers are internally base 
2, and in base 2 the decimal value 0.1 is an infinite number just 
like 1/3 is in base 10.

I think that the difference between // and MOD is in how they handle 
negative numbers. Modulus (as a math concept, as I recall) isn't 
defined for negative numbers at all. Programming languages tend to 
punt when it comes to this, so // works the most common way, and 
MOD converts it to the next most common way.

The $ in this case just being a sigil for a different numeric representation 
that works better in this kind of situation.

I also tested, that it takes equal amount of cpu time to do this 
in C, where a and b are of type double:

fmod (a, b)

or

a - floor (a / b) * b

Same can be said for integers, where we would use % in C.

And if you look in HELP MODULO, it looks like a hack to fix some 
problem:


Wrapper for MOD that handles errors like REMAINDER. Negligible values 
(compared to A and B) are rounded to zero.

Ops, I said something wrong, when saying, the division can be on 
either side of zero. The division is of course close to a whole number, 
but can be on either side of that number, so the rounding can be 
that number (if the result lie above) or one below that number (if 
the result is below). Using ROUND instead of ROUND/FLOOR solves it.

So the difference is only, when the division give a remainder close 
to zero. Example of same results:

>> mod 0.3 0.2
== 0.1
>> remainder 0.3 0.2
== 0.1
>> modulo 0.3 0.2
== 0.1


And then there are some differences, when dealing with negative numbers.

So the difference is only, when the division give a remainder close 
to zero.

 - actually not, the difference is visible, if the Remainder function 
 gives a result close to the B value

The disadvantage is that MOD might be a less-specific name.

My suggestion is to get rid of moth MOD and MODULO, and then deside 
on a way, REMAINDER should work. People can always make some function 
in special cases. And remember rule no. 1!
K.I.S.S.

I'm studying Lua these days, and they just have one function, that 
do:
a - floor (a / b) * b
Simple to understand.

What would be the consequences of such a change? I remember you going 
on about IEEE754 predictability, and this would seem to reduce precision 
- all that rounding...

So, Geomol, what is the result of a - floor (a / b) * b, if a = 0.3 
and b = 0.1?

It might be a good idea to split the problem between integer and 
decimal behaviour. In the case of integer, there should be one way 
to do it. Today we have two different outcome:

>> -8 // 3
== -2
>> mod -8 3
== 1

(MODULO give same result as MOD.)

as a side note, when would I ever use a modulus function with decimals? 
Maybe in special cases, where I need to write a special ROUND function 
myself or something? What is this use for else?

The difference in the handling of negative numbers is sufficient 
justification for me. The rounding difference is just a bonus.

Would all those problems be solved, if the decimal! datatype actually 
was the money! datatype, and if we then had a real! datatype, that 
did it a fast way and giving results as we see in C and other languages?

As a practical example, if you are doing device-independent rendering 
you work in proportions (floating point ratios) and then convert 
to exact values (integer coordinates) on final rendering to the real 
device. Video games do this all the time - that is why GPUs need 
floating point hardware. Same with sub-pixel rendering. If you are 
working in proportions, your modulus functions will need to handle 
them. And modulus could be used for bounding box calculations on 
textured surfaces too.


In both those cases, the programmer will probably know enough about 
accumulated error to want to control it themselves. The non-rounding 
behavior of // would be a benefit to them then, so rounding can be 
minimized.

I feel, much confusion come from having a decimal! datatype, that 
isn't really that, decimal.

Also, think of the syntax. We have a sigil to denote the current 
money! type, which *was* added for financial calculations. If that 
type was the default, what would the floating-point sigil be?

I agree that float! would have been a better name than decimal! (not 
real! because they aren't). Too late now.

real! is not that bad either, actually, they are (subset of) real 
numbers, with "just a bit twiddled" arithmetic

That "subset of" is the kicker. Integers are also a subset of real 
numbers.

Reals surely is a much more appropriate name, than decimals

...but I bet, that I and Geomol would be OK with IEEE-754! or a similarly 
"ugly" name, which may really scare some people

A problem with "float" might be, that many will think 32-bit right 
away. And we have 64 bits to play with.

A 64bit float is still a float. There are 128bit IEEE754 floats too 
(and perhaps 256bit, I don't know).

there is a "slight" difference between "real" and "float" - both 
can be used, but "real" is more understandable for a layman than 
"float" - where does it float?

That is what  I like about the name. A programmer will understand 
the difference. REBOL is made for programmers, not laymen. We finally 
disabused ourselves of that delusion.

Ah, but "float" is a keyword for programmers that implies binary 
floating-point numbers (usually IEEE754), while "real" is a keyword 
for what floating point numbers (binary or decimal) *appproximate*. 
You know, the real world. The "real" pi doesn't have a finite binary 
representation. That distinction is why I like "float" instead. All 
moot now though - we are stuck with decimal!.

However, if we could summarize 2009, it has been a nice year for 
REBOL. Many things have evolved and I have not seen the development 
blocked for more than a week. I don't know how many people are still 
at RT but I suppose the number is quite low and I think we must congrat 
with Carl.

If we think about the needing for money and time a company and a 
family needs (talking about Carl's Family and RT) I am really suprised 
to see how much work has been spent over REBOL. Sometime I even ask 
myself  how it could be possible ? Has Carl some hidden treasure 
? Has he found a way to split himself so we have 2 Carl and not one 
? :-)

Is there a way that I can get the number of parameters of a function 
in R3? 
So I can do this:

>> num-of-parameters :print
== 1
>> num-of-parameters :now
== 2

Jerry - you can use words-of instead of spec-of. It doesn't return 
the comments.


>> a: func [b "comment" c "comment"  /local d] []                
        
 
>> b: func [c d e f /local z] []

 >> n-o-p: func [f] [length? copy/part spec: words-of :f find spec 
 /local]
 
>> n-o-p :a
 
== 2


>> n-o-p :b
 
== 4


Sory for the cryptic code. I had to keep it to a single line in the 
R3 console.

... and more importantly it doesn't handle refinements either.


What would you expect num-of-parameters to return for the following 
function:

a: func [b c /d e /f g /local x y z]

Here is a version using parse:


>> n-o-p: func [f] [ct: 0 parse words-of f [some [word! (++ ct) | 
refinement! thru end]] ct]
 >> n-o-p :now
 == 0


>> a: func [b c /local e] []
>> n-o-p :a
 == 2
>> x: func [b c /d e /f g /local x y z] [
 
>> n-o-p :x                                

== 2

A version without parse:

>> npars: func [f /local w] [
	w: words-of :f
	length? copy/part w any [find w refinement! tail w]
]
>> npars :print
== 1
>> npars :now
== 0
>> npars :insert
== 2

Some thought of naming. How should such a function be named the REBOL 
way?

number-of-parameters seems a bit long. I sometimes write functions, 
that return the number-of something. I come to think of # as being 
number-of, but # in the start mean an issue! datatype. What about 
allowing # in the end of words? Like:

parameters#: func [ ....

Or is that too ugly?

A bit like we have ? in the end of many words: length? tail? none? 
...

Remember that there is nothing special about the /local refinement 
or the words that follow it. All /local is is an option that you 
aren't using, and in that is no different than any other option you 
aren't using. In order to determine the number of args that a function 
takes, you need to specify which options you will be using in the 
call, perhaps by providing a path! instead of a function reference. 
Otherwise, just use WORDS-OF.

The type test in the argument list might be taking a little time. 
Try John's with the type spec. I'm curious to see what the difference 
is.

Yes Pekr and when you want to write Extension as generalDLL loader 
can you use a block! paramerer instead of struct, or better how to 
transform a block given as parameter of extension to struct needed 
as parameter of underlaying DLL.

The R2-style struct! and routine! types are not working in R3 and 
are likely to be removed. The struct! type might be replaced with 
a new, improved, incompatible struct! type. The routine! type has 
already been replaced with a new, improved, incompatible command! 
type.

You are right that documentation is an ongoing problem. The design 
has been changing a lot during the alpha phase, but the behavior 
of FUNC and FUNCT are unlikely to change, so they could be documented.

I added a ticket to curecode about the math performance issue: Ticket 
#0001338

Have you tested with prefix form math? The implementation of op! 
has changed, and the new implementation would probably be slower 
(at a guess) but is more flexible. Please test with prefix math so 
we can categorize the ticket properly.

If functions like ADD and SUBTRACT are slower, this is an issue. 
If it is just ops like + and - then it is a side effect of user-defined 
op!.

The new op! behavior has allowed us to speed up DO quite a bit overall. 
It won't be changed. If you want fast math, use prefix functions 
or better yet extensions.

If functions like ADD and SUBTRACT are slower

 - I'm not sure whether you mean are slower under Mac OS X  or slower 
 than + and -. ADD, SUBTRACT etc. are much slower than +.-.

Results on an old 1ghz ThinkPad:

 >> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:21.5

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17.25

>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]
== 0:00:20.625

>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]
== 0:00:17

The prefix forms in R3 are only about 20% slower than the inline 
forms in Mac OS X whereas they are over 50% slower in R2:

R2 results:
>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]

== 0:00:06.096334
>> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]              

== 0:00:03.679331

R3
>> a: 1. b: 2. dt [loop 10000000 [divide multiply add a b a b]]

== 0:00:06.72179

  >> a: 1. b: 2. dt [loop 10000000 [a + b * a / b]]                
    

== 0:00:05.521236

It's a big picture balance thing. The optimizations were rebalanced 
in the change from R2 to R3 in order to increase overall power and 
speed of REBOL. REBOL has never been a math engine (not its focus), 
but now it can be because of extensions. Everything is a tradeoff.

a nice parallel to R3 is python 3... just about every issue we have 
is also an issue in  P3 (unicode, R2 forward for example :-)... it 
took 3 years to build, and remember that python has NO graphics, 
only core release.   Also P3 has much less fundamental changes than 
R3 has, so in comparison, R3's implementation is at par with other 
interpreter updates.... except they are whole teams, where R3 is 
a very small team.


http://broadcast.oreilly.com/2009/01/the-evolution-of-python-3.html


P3 did require updating MANY modules, so most of the team probably 
worked on that instead of the language itself.

Most languages are going through the revamp nowadays, due to the 
Unicode and concurrency crisis, and the extent of the changes attempted 
varies from language to language.


Python 3 is on the more minimal end of the spectrum: Only Unicode 
changes, not paying attention to concurrency at all, focus on backwards 
compatibiity, no significant syntaxtic changes (the standards for 
syntax among Python devs is low), minor cleanups to its libraries. 
And it took them 3 years to do it :(


Perl 6 is on the more extreme end of the spectrum: Major changes 
in everything, including syntax, several complete system structure 
revamps going on at once, major semantics changes (not sure about 
the concurrency). Perl had an entire history of not being designed 
at all, so they had a lot of crap to get rid of. Which they replaced 
with much more new stuff (Perl doesn't know how to say No). 10+ years 
into the project, with no end in sight.


R3 started closer to the minimal end of the spectrum because we hadn't 
really been keeping track of how far behind we had gotten - not far 
behind the others, far behind our potential. As the scope of the 
changes needed became more apparent, the project rapidly went way 
towards the Perl 6 end of the spectrum. However, we had to do a couple 
restarts along the way. The current round has only been going for 
2 years, but gone way past the level of changes in Python 3, and 
has approached the level of change in Perl 6.

We had some advantages though:

- REBOL has been more designed than those others, over the years. 
That means that we are redesigining rather than designing.

- R3's primary designer is mainly into operating systems, so R3 is 
built like an OS, which makes more ambitious changes possible.

- We decided that R2 will be continue to be maintained as a separate 
project, so we don't need to stay backwards compatible.

- REBOL's design process knows how to say No, so we aren't falling 
into the Perl 6 trap.


All of these are why we have been able to accomplish so much in such 
a short time, with so little resources. It's taking a lot of time 
and effort to get the community to realize that R3 is a community 
project, so we've had to make the best use of the resources available, 
even when it meant taking some time off from developing to build 
the infrastruuctre for community development. This process work has 
paid off dramatically, so much so that comparing pace of development 
more than a year ago to that nowadays is completely irrelevant :)

Not everyone realizes that Carl has spent a long time building a 
very strong lever.... might not be pretty... but its damn straight 
;-)


now he's about to give us a chance at holding that lever as a group 
and leverage all the work.  He's been putting all the effort to putting 
the pivot of the lever (the fulcrum) as close to one end as possible... 
so R3 will be very strong and allow to do much more heavy lifting 
than R2 ever could.


now we just have to paint the lever and make it all shiny (gui) put 
a nice handle on it (the host) and even add a few more handles to 
it (threads).


most of that... we can do as as group with a few helping hands working 
together  :-)

Being able to say No was a really big deal. It is why we had to build 
our own VCS and developer communications infrastructure, with moderation 
and ranking built in. We didn't have the benefit of years or decades 
of established community development, like Perl or Python - we had 
to do this from scratch. The only way we have been able to make such 
ambitious changes so quickly and cleanly is through some group discipline 
and politeness, and that means we need to have a counter-pressure 
against flame wars and development fights. We would have never managed 
to get this far without DevBase (R3 chat) and CureCode :)

Other than "Glue" (which is "still" my choice for a name for REBOL), 
I have to admit that "Level" is another good name.

Question about R3 GUI. On this page http://www.rebol.net/wiki/GUI_Example_-_Move_a_window
 is an example for moving a window. After moving it with button "Move 
to 100x100" I move it manually to another spot. When I then push 
button "Move to 100x100" again, the window won't move anymore. Is 
that a bug or am I missing something?

if you put a probe inside the 'do block for the button, is it printed 
like it should?

Back to ROUND for a moment. It seems so long ago...


I think the goal was to have things make sense to normal people, 
while still allowing Ladislav and John to have their way. :-) Most 
programmers just want results that make sense to them as humans.

Most programmers just want results that make sense to them as humans.

I can agree with that. It would be a benefit, if it still make sense, 
when you think a little deeper about it.

I still find the equal operator with its trying to be clever about 
rounding errors in decimals a strange thing. Try this example:

for i 4.0 6.0 0.1 [print i if i = 6.0 [print [i "= 6.0"]]]

The last line output is:

5.99999999999999 = 6.0


So those two numbers are the same for the equal operator. Let's check 
it:

>> 5.99999999999999 = 6.0
== false

Now see what happens, if I let the loop run a little longer:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


Now the equal test within the loop doesn't become true. The last 
number output is 6.99999999999999, so this number doesn't equals 
7.0, like 5.99999999999999 equals 6.0. I know, we don't see all possible 
decimals, but that's not my point. My point is, that if equal can't 
cope with rounding errors always, then it shouldn't try to do it 
at all. (My opinion.) The current behaviour isn't a good thing for 
the language.

A side note: FOR doesn't allow money! as its start argument in R3. 
It does in R2.

after a slight modification I get:


for i 4.0 6.0 0.1 [print i if i = 6.0 [print [mold/all i "= 6.0"]]]
5.9999999999999929 = 6.0

I'm questioning the "nearness" in equal. Another example:

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 - 0.3 = 0.0
== false


STRICT-EQUAL returns false for both of these. Is the "nearness" a 
good thing to have from a language design point of view?

I got all the decimals after a while with this:

for a 4.0 5.9 0.1 [print a]

so I changed it to:

for ma $4.0 $5.9 0.1 [a: load next form ma print a]

I'm actually messing around with REBOL (actually R2) and been away 
from it so long I forgot a lot of stuff.  Anyway, was wondering how 
R3 is progressing.  I was just using parse and thought about rejoin. 
 For example, if we can parse something such as:

blk: parse "this, simple, csv, string" "," 


wouldn't it be cool to just come back along and rebuild it with something 
such as:

rejoin/csv blk ","

Geomol: "FOR doesn't allow money! as its start argument in R3. It 
does in R2." - Write it up as a wish in CureCode please :)

Paul, that function has been proposed as DELIMIT - not as REJOIN 
because that function needs to be low-level - but hasn't been added 
yet since there is no consensus about the feature set. No consensus 
means it goes in the library rather than the mezzanines. If you can 
make a version that is so awesome that everyone will agree with your 
feature set, we'll add it :)

I don't agree with such fundamental functionality of R2 to go into 
some optional library. Better to have some standard, than not. The 
same goes for easy read/lines equivalence. Dunno how current read/as 
turns out, if it will end-up as separate read-text or so, but we 
need easy way of having R2 analogy here. Those working with CSV data 
on a daily basis will greatly miss such features ....

hmm, there is a 'delimit function ... it seems to be renamed to 'split 
....

More like:

	dehex: use [hx ch][
		hx: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
		func [text][
			parse/all text: to-binary text [
				any [
					to #"%" remove [#"%" copy ch 2 hx] ; change <> remove insert
					(ch: debase/base ch 16) insert ch
				] to end
			]
			to-string text
		]
	]

I need a map! with 60'000'000 entries. But in R3, I cannot do that:

>> make map! 500'000
** Script error: maximum limit reached: 500000

Why the limit is so small?