World: r3wp

I don't think the problem is about free features in free-rebol vs 
sdk. It is about education of the decision makers.

I'm not part of that team.  I'm part of the field services team which 
handles administrative functions.

Yeah Jaime your partially correct but if WSH can do it for free why 
REBOL - get my point?

I think you need to keep trying on viral approach, sneak some code 
there, and convince others to acept it.

I have made an application here and there that has been noticed but 
mine are all free - I don't charge and I'm bound that if I did make 
anything particularly useful they would own it anyway.

Why REBOL? (Thats a loaded question). Part of the answer is because 
it makes your life easier. So freeing your cycles and potentially 
the cycles of others, making the company more efficient.

Therefore, I see no way to penetrate the REBOL product into the environment 
unless I make a killer app or unless we can do the better work with 
REBOL at the same costs or better.

(Lets move to Chat)

ok

(Better lets create a new group)

Jaime - I noticed that the broadcast address that returns from that 
ipconfig function is not correct in cases where the netmask is different 
than 255.255.255.0.  Maybe a bug in get-modes when used on the interfaces.

Jaime, the port does not need to be ope. Just get-modes udp:// 'interfaces 
(or tcp://)

*open

Thanks Gabriel. Here is a shorter version, thanks to your hint.

ipconfig: has [interfaces] [
    foreach dev interfaces: get-modes udp:// 'interfaces  [
        print reform compose [
            join dev/name ":" "flags" mold dev/flags newline
            "^-inet" dev/addr "mask" dev/netmask 

            (either dev/broadcast [["broadcast" dev/broadcast]][""])

            (either dev/dest-addr [["dest-addr" dev/dest-addr]][""])
        ]
    ]
    interfaces
]

I know how to set the title of the window in REBOL/View, but how 
can I change the title of a REBOL core console?

with a system call

win-lib: make object! [	
	user-lib: load/library %user32.dll
	SetWindowText: make routine! [
		handle			[integer!]
		Title			[string!]
		return:			[integer!]
	] user-lib "SetWindowTextA"
	
	set 'WindowTitle func [
		Title [string!] 
	] [
		SetWindowText get-modes system/ports/system 'window Title
	]
]

WindowTitle "eFishAnt Ink"

can't remember who gave me that...

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.