World: r3wp

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 :)

The main gotcha so far to the keep-encoded approach is whether INSERT 
and APPEND should do some magic percent encoding or not. It seems 
that it may be a better approach to just assume that the programmer 
knows what they are doing and just insert what they say to insert 
as is, as long as the url character set restrictions are met. This 
would mean that the programmer would need to handle their own percent 
encoding where needed, and that INSERT or APPEND would not do any 
encoding or decoding. Or perhaps some non-syntax characters, such 
as space, could be encoded by MOLD instead of rejected and DECODE-URL 
just adjusted to not freak out when it seees them. What do you think?

I vote for NO automatic encoding.

it just makes everything totally confused and leads to very hard 
to fix bugs.

and breaks inter type linearity... if source is one type... something 
happens, when source is another type, something else happens... aaaarrrrggghhh 
 :-(

We have to do percent decoding to read urls. The question is when.

Intertype linearity is more of a guideline anyways. If types behaved 
identically, there wouldn't be point to more than one :)

its a question of taste, in R2 a lot of the series handling stuff 
in some types alienate me more than anything.

for urls, I'll let you guys assess it... I'm the kind of guy that 
will do all with the string and just convert it to url at the end, 
 its just much more useable that way... you have a better control 
over stuff like "/" in the path anyways.