World: r3wp

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 not sure, why it isn't allowed to write this in R2:

to decimal! $4.0

Maybe just missed. It's fixed in R3.

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 ","

or have any deliminater you specify.

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

'dehex does not work as I'd anticpated:

	dehex "em%E2%80%94dash" ; s/b "em--dash" (where -- is em-dash)

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?

CC it, please ...

I think that some things are settable, via enchant or so function, 
e.g. stack size, but not sure ...

Ok, I will CC it.

Thanks Brian, I'll try to look up the discussions regarding DELMIT 
tonight if I have some time.

This:

parse "this, simple, csv, string" ","


I believe was meant to be removed, because it's too obscure. I think 
the intended function for this is SPLIT.

I didn't know that.

I don't know if it has been removed yet or if that will be a 3.1 
feature.

Back to my question (a long time ago :-) May I assume that the behaviour 
I wrote about in my question is a bug? A probe works, but anyhow 
the window won't move anymore.

what happens if you change show-later to show?

seems host code work is now continuing. Something with a MinGW C 
target.

how can I remove an entry from a map! in R3? BTW, I use string! (not 
word!) as index here, so I cannot just say:  my-map/my-word: none

Geomol; I have to go with Gregg on this one.  I'd much rather have 
to deal with grenade close on output than NOT seeing your for example 
fire true on the if i = 6.0.  Is that attitude good for REBOL or 
rocket science?  Perhaps not.  Small business owner/hobbyist?  Yep. 
 In my humble, liable to blow up rockets, opinion.

oops, didn't notice how far back the scroll bar was...  "this one" 
being the post re decimal! with base 2 conversion precision.   this 
line in particular.    for i 4.0 6.0 0.1 [print i if i = 6.0 [print 
[i "= 6.0"]]]f

Jerry: try my-map/( my-string ): none

thanks Izkata

btiffin, did you notice, that the i = 7.0 test in my other example 
fails? Try:

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


The problem is, that you can make examples, where the "nearness" 
works. So the small business owner/hobbyist will come to think, the 
language actually handle those base-2 precision problems, but it 
doesn't. The only way, as I see it, to really handle this problem 
is by using true decimal arithmetic (e.g. some kind of binary-coded 
decimal as in money!). I believe, the current behaviour will only 
lead to more confusion.

How will you explain this behaviour to someone learning how to program?

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 > 0.3
== true


I can explain this next behaviour, even it seems illogical at first:

>> 0.1 + 0.1 + 0.1 == 0.3
== false
>> 0.1 + 0.1 + 0.1 > 0.3
== true

even *if* it seems ...

Do or do not... there is no try.

REBOL try to solve the base-2 precision problem.

Henrik: the behaviour is the same when I use show instead of show-later.

For the record; I am using: Windows XP Pro SP3
Rebol3 2.100.94.3.1
GUI 0.2.1

arie, ok. I don't have a solution, but this needs to be looked into 
once GUI work continues. While the Core of R3 has moved forward a 
lot, GUI has not moved in the past year. it could be that a feature 
is broken in the GUI now because of this.

>> 0.1 + 0.1 + 0.1 > 0.3
 - this differs from the behaviour in R2, maybe an error?

If you change it, then you'll have problem with < > and ==, because 
you can have situations, where all those 3 return false.

Then you can add strict-lesser? and strict-greater?, but I wouldn't 
recommend it. :-)

R2 difference:

	R2
	>> join url:: "%23"
	== url::%23

	R3
	>> join url:: "%23"
	== url::%2523

The "%" is encoded as "%25" for urls in R3, which is correct, I think.

>> to char! #"^(25)"
== #"%"

See e.g. http://en.wikipedia.org/wiki/Percent-encoding#Percent-encoding_reserved_characters

This isn't helpful either:

	>> load join "url::" "%23"
	== url::#

I know, but my string is already percent encoded...

ah

but your string is not a url, its a string.

the string should be the decoded value of the url.

If it did a full url-encode, that'd be good, but it doesn't.

Just percent encoding, of the percent symbol.

Is this is a bug? - url::%23 and url::# are not the same:

	>> url::%23
	== url::#

Blocked either way:

	>> qs: to-webform [q "&=#"]        
	== "q=%26%3D%23"

	>> join url:: qs
	== url::q=%2526%253D%2523

	>> load join "url::" qs
	== url::q=&=#

Henrik: OK.  Thanks!

I've been looking over R3's url handling and decoding and it needs 
more work, some of which needs to be in the native syntax.