World: r3wp

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.

Chris, url::%23 and url::# should not be the same. The purpose of 
percent encoding is to allow you to specify character values without 
them being treated as syntax. If you specify a # directly in an http 
url, for instance, it should be taken as the start of the anchor 
portion of the url. If you percent encode it, it shouldn't be an 
anchor.

Yep, hence the so far insurmountable problem I have.

Even tried the equivalent of - read decode-url  "uri::%23" - but 
somewhere it gets encoded again to %2523, not sure if that's specific 
to the http scheme implementation? I haven't dug enough.

Is there a reason why it should decode any percent encoded character 
on loading?

Here's the offender - how to make this work? -- http://search.twitter.com/search?q=%23REBOL

Chris: I have pointed out this flaw to Carl before R3 was started, 
and provided the correct code to handle URI according to the standards...