World: r3wp

Yes, parse can be used. My motivation was thoughts about switch. 
It seems, it could be improved.

REBOL3 is pretty consistently case-ignorant in this regard:

>> #"a" = #"A"
== true

And the SWITCH behaviour is just consistent with that.

(R2 is more inconsistent in this regard, as #"a" = #"A" is false, 
but SWITCH behaves case-insensitively, as you described.)

>> #"a" == #"A" 
 
== false

Perhaps SWITCH needs a /Strictly refinement?

SWITCH used to be a mezzanine, so you could easily patch it if you 
want. This is the old mezz source.

switch: func [
    [throw]
    value
    cases [block!]
    /default case
][
    either value: select cases value [do value] [
        either default [do case] [none]]
]

I use SWITCH very rarely, but I don't know about others.

/case would be more consistent with 'find, 'parse, and 'select than 
/strictly would

The char! datatype has many similarities to numbers. The following 
is from R3 and looks strange to me:

>> var - 32 = var
== true


What variable is equal to it's original value, even if you subtract 
32 from it?

>> var: #"a"
== #"a"
>> var - 32 = var
== true


A bit strange. I would prefer SWITCH to distinguish between #"a" 
and #"A".

>> (var - 32) = var
== false

This can be even more complicated when talking UTF encoding. Hm, 
who knows how R3 do this...

Rebolek, do it in R3.

I'm not sure what exactly [var - 32 = var

Ah, ok, this was R2.

Yes, in R3, it's true.

I agree with you, this is strange.

>> #"a" - 32
== #"A"

>> #"a" - 32 == #"a"
== false

>> #"a" - 32 = #"a"
== true

it's ok to my mind

Izkata: /strict could also striclty equal to numbers to give an alternative 
to :

>> number: 1

== 1
>> switch number [1 [print 1] 1.0 [print 1.0]]

1

>> number: 1.0

== 1.0

>> switch number [1 [print 1] 1.0 [print 1.0]]

1

I think the var - 32 scenario is fine as well. It's all about context, 
and by making it work the other way, you're just shifting the problem, 
not really solving it. That is, something becomes easier, but something 
else becomes harder.

Gregg, are you really sure, you mean this? As I see it, the life 
would be much easier, if "a" equals "A", but #"a" didn't equal #"A". 
As it is now, it's really problematic testing for different characters 
in a string using SWITCH. Cases where "a" and "A" should be handled 
as the same is ok, but cases where they should be different is the 
problem. If #"a" was made to not be the same as #"A", then both situations 
could be coped with easily.

At the moment Switch is consistent with Equal?. Surely, it would 
be better to retain that consistency and have a /strict refinement 
for switch which perfomed consistently with strict-equal? ?

Peter, the equal thing is correct for R3, not R2, which we still 
get updates for now and then.

In other words, SWITCH is not consistent with EQUAL in R2, when talking 
the char! datatype.

You are correct, I was mistaken about the R2 behaviour.

First, it should be consistent between R2 and R3 if at all possible. 
For SWITCH, I think the solution is to add a refinement if people 
think it's needed. If the new native SWITCH is still based on SELECT, 
adding a /CASE refinement shouldn't be hard.


For the more general case of char case-sensitivity, we have ==/strict-equal?

I agree with Geomol here.


many people see chars as a subsitute for string, even I once saw 
it like that, but I have come to realize that they shouldn't be.

#"A" should not be equal to #"a".

I'm getting an error with send that neever got before...

>> send [bebop-:-gmail-:-com] "hello"

** User Error: Server error: tcp 421 Cannot connect to SMTP server 
173.236.30.114 (173.236.30.114:25), connect error 10060
** Near: smtp-port: open [scheme: 'esmtp]
either only

I tried several different accounts but  get the same error

It seems to be working again...don't know what was going on

you know... it IS possible that Google has outages too  ;-)

I was using versizon google and another host...all the same prob...

verizon

amacleod: the IP address 173.236.30.114 resolve to cx02.justhost.com 
, which may be your provider. does that correspond to your smtp server?

yes...

actually it did not happen sending on gmail account as i can't (without 
Graham's fix anyway)

did you try an authenticated connection?

trace/net on

telnet 173.236.30.114 25
answers?

that error should be with your ISP's smtp server

ie:  [a ["one"] b ["two"] c ["three"]]

Q: best way to remove b and it's block ["two"] ?

remove/part find ie 'b 2

works for me, thanks

another question.. 


if i have a blk: [] and i want to add a 'word and and a block with 
a pair.. ie: [ word [1x2]] 

i typically would append the word, then append/only the pair, but 
that seems barbaric?

blk: copy [] append blk [word [1x2]]

At least one of the problems I had with one of my email accounts 
related to port number: 


I was changing my smtp port to 2626 with "system/schemes/smtp/port-id: 
2626"

when I should have been changing my esmtp port with : system/schemes/esmtp/port-id: 
2626

Dope!

Thanks for the help all

What is the advantage of using the "/only" refinement when sending 
multiple emails?


And is there a limit to the number of addresses yo can include in 
a bulk mailing?

afaik, the server usually applies a limit to bulk mail...  often 
~50 sometimes as low as 10 !

you will receive an error when you go past that threshold.

What about the "to:" in the header? 

When using /only is here a way to get the email to show the single 
address of the recipiant and not say a list of all address sent to?

I really don't know... its been a long while since i've done e-mailling 
in rebol... Graham can probably give you an answer, he's done a lot 
of email work.