World: r3wp

For POP3 and email fans:


   http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=do-pop-scheme.r


Gives you easy access to LIST, TOP, UIDL, etc. for your spam delete 
scripts or whatever.

My main purpose of making this script was investigate coding design 
choices. So I would appreciate comments on the design choice of the 
scheme and the helper function, and of course let me know if there 
are bugs!

A lot of people will appreciate this Brett.  I haven't looked at 
the code yet, but just read the docs.  Do you want to add support 
for the "CAPA" command ?

If I was to add CAPA support, I would not do anything special with 
it, I'd just send it and get the response expecting the user script 
to know what to do with CAPA. But, I don't know if that is enough 
flexibility to be useful to a user script.  The other change that 
CAPA would bring is, that I should not issue a STAT automatically 
after authorisation.  Might need to look at this more. Have you used 
it and what for?

I only needed to know about it as some mail clients would query Cerebrus 
with the "CAPA" command and I had to know how to respond.

Security question: LOAD no longer evaluates values when loading. 
 But can it still load destructive values?

>> args: load/all {#[function! []['value]]}
== [func []['value]
]
>> args/1
== value

I'm not sure as values such as functions aren't bound:

>> args: load/all {#[function! [][print "Don't Print Me"]]}
== [func [][print "Don't Print Me"]
]
>> args/1
** Script Error: print word has no context
** Where: 1
** Near: print "Don't Print Me"


So, how dangerous can args/1 be?  I wouldn't be so careless as to 
-- do args -- or -- context args -- but I don't want to have to worry 
about, say:

if args/1 = 6 [...] ; or
if args/1 = 'value [...]

Though -- first args -- appears to be safe:

>> first args
>>

Rule #1: if you don't trust the source of the string, don't trust 
the results of LOAD. always check the type of the data you get. instead 
of args/1 use pick args 1, instead of var use :var and so on.

hah.. nice.. I just logged on and was about to ask the same thing.. 
(since 'load is the only way I could figure out to make something 
work)


Quick Q:  "pick args 1" and "first args" would -both- be safe, right? 
 Or at least have the same amount of safety?

What do you think about this?
>> 97.0 = #"a"
== false
>> #"a" = 97.0
== true
Is it per design? Is it a good design?

>>97.0 = to-decimal #"a"
== true

If  a = b implies converting the second value to the same type as 
the first then it would appear to be an implementation bug.

I looked up = in the Rebol Dictionary and, whilst it is not explicit, 
it implies different value types can be equal.

But this looks like a bug:

>> #"a" == 97.0
== true

From the dictionary:


== - Returns TRUE if the values are equal and of the same datatype.

I say to rambo with that.

I have submitted both the = & == behaviour to Rambo

Izkata: yup, they're both safe, as long as args is not empty (first 
throws an error in that case, while pick just returns none)

Thank you ^.^

The whole thing is in an error? try [] in case someone throws it 
bad data.. heh

Rule #1 - is that true today? AFAIK the only thing which can be executed 
is functions, and one can't inject working functions? The old way 
one can only inject words. The new with mold/all, functions can be 
injected, but the words are not bound to global context, so they 
can not trigger usefull actions. only triggering an error in an unexpected 
place?

I've got a question. I don't know how to describe it, so here is 
the code

>> a: context [b: 1 c: does [b: b + 1]]
>> f: func [fn][loop 100 [fn]]
>> a/c
== 2
>> f a/c
== 3
>> f get in a 'c
== 103

Why there's difference between f a/c and f get in a 'c

I think they should behave same, shouldn't they?

I don't see why they should be the same. 

One is using path evaluation to execute c, the other is asking for 
the value of c.

> type? get in a 'c
== function!

OK thanks, I'll do it another way

volker: i think that rule always applies if you want to be safe. 
you never know what someone could be doing to work around your safety; 
more checks means safer.

anyone know what the 'run function does?  I always get a message 
that its not available in this version of rebol but I am using sdk 
so not sure why.

In Command:
>> help run
USAGE:
    RUN file /as suffix
DESCRIPTION:
     Runs the system application associated with a file.
     RUN is a native value.
ARGUMENTS:

     file -- The file to open (file, URL) or command to run (string). 
     (Type: file url string)
REFINEMENTS:
     /as
         suffix -- (Type: string file)

Though having just tried it......it didn't work either.
Looks like an older name for call

it's not.

run will call a native application to open the file in question eg. 
acrobat reader for pdf files.

It is only enabled on IOS .. I have asked RT why it can't be enabled 
for the sdk as well.

Yes Graham that is what it looks like to me as well - looks similiar 
to a winshellexecute function.  Would be good for them to activate 
it as that would be a very good function to have.

And, perhaps even REBOL View too eh?

Ahhh not complaint here Carl.

Is this OK? And if yes, then why?

>> x: context [d: does [print e]]
>> y: make x [e: 1]
>> y/e
== 1
>> y/d
** Script Error: e has no value
** Where: d
** Near: print e

yes, this is OK

and why?

because you refer to word 'e with global context

>>  x: context [d: does [print self/e]]
>>  y: make x [e: 1]
>> y/d
1

ok I see

In this case it would work:
>> x: context [e: 5 d: does [print e]]
>> y: make x [e: 1]
>> y/d
1

because the 'e in function d would be bound to the context of the 
object (self)

yes I know, I needed it when extending objects

so I'll use 'self or define everything in advance

If you use 'self you are safe rearding contexts IMO.

if you want to extend context, you might want to try associative 
array instead

or a "dynamic" object like o: make object! [data: make object! [x: 
1]]

usage:

>> o/data/x
== 1
>> o/data: make o/data [y: 5]
>> o/data/x
== 1
>> o/data/y
== 5