World: r3wp

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

Is it in curecode?

Don't seem to be able to register for curecode - get this message: 
"Sorry, this page cannot be displayed. Try again or contact the web 
site administrator"

ok, mention it in the curecode group, so dockimbel can look at it.

Gabriele, be sure to post the correct url parsing code here or in 
R3 chat. We will be sure to get it integrated into R3. Or you could 
integrate it yourself if you like. If there need to be specific changes 
to the url syntax as accepted by TRANSCODE, please note them here 
or in CureCode. Proper url handling is important, and now is the 
time to fix it.

I have been thinking that urls should stay percent-encoded until 
they are decoded by DECODE-URL, so that percent-encoded characters 
won't be mistaken for syntax characters. (I don't claim this is my 
idea - I think you said it earlier, and I remember that.)


Is this approach a good one? Have you thought of any gotchas or downsides 
to this? Will this require that urls have an associated decoded version 
that would be stored as well as the character version? Do you think 
we could get away with TRANSCODE enforcing the initial rules, then 
not checking again until it comes time for DECODE-URL to be called 
(on OPEN, for instance)?

Your code in Qtask for this was somewhat complex, but could be simplified 
with the new PARSE. Clarity is key here :)