World: r3wp

Why?  If you create something you give it to users, and they start 
using it. They may push presure on the Echolons to favor your solution.

The biggest obstacle to making an encapped module in this environment 
is knowledge distribution

For example, if we rolled out an encapped file to 40,000 desktops 
and someone walked up and said who did this and they said Paul did 
- then they would say what happens if Paul leaves us.

You mean you are the only one with rebol knowledge?

They would never let them get themselves that vulnerable.  To much 
risk

I'm sure we have others in the company but not on this account - 
I'm it.

Well. You pointed them to network Rebol consultants that could support 
them. (Gabriele, Robert, Cyphre, Ladislav, Greg, DideC, Nenad and 
others...)

One time I created a nice program that would go out and check backups 
on the servers.  Because it was an executable file they got rid of 
the system - even though it was better than anything else we had.

That isn't good enough unfortunately

They need to be able to pick up a phone and get results.  We deliver 
Service Level Agreements that costs a lot of money when they are 
not met.

Also if you write document your script really well and show the code 
is easy to follow (cookbook tutorial) you may gain your boss trust 
and their request for other agents inside your company to learn Rebol.

You gotta remember when I say we have 40,000 desktops that isn't 
a typo.  We have teams dedicated to certain tasks including an application 
development team

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?