AltME groups: search

Ah, but that is assuming that the code is run at the top level. Judging 
by that particular code snippet, it looks like something from inside 
a function, and one that is likely in a context has 'email? already 
defined. Still, the fact that INTERN is already run on normal scripts 
(and the module equivalent run on modules) means that he likely wouldn't 
need to do this with the main contexts, just inner contexts.

Has to do with implementation of this function: http://github.com/hostilefork/Rebmu/blob/master/rebmu.r#L448

this is something curious I just noticed.

If you pass a file as a parameter to a rebol program on the dos command 
line it works
but if you do the same in a dos batch file, it does not

eg:. script.exe %/c/rebol/myfile.dat

works from the dos command line

but to get it to work in a batch file you have to do this

script.exe %%/c/rebol/myfile.dat

I presume it's because the command processor tries to do a substitution 
using the %

is there a way to get access to the main script's header within code 
you execute using 'DO

when I 
do %source.r

and source.r defined as:

 print system/script/header/title

I get the title of the source.r file... not the main script.

Well, I know, but I just mean that if functions can detect what types 
they get then making [add (something) (percent)] do the same thing 
as [add (something) to-decimal percent] seems a little less exciting 
than if it "knew what you meant".  There's sort of a dimensional 
analysis thing... adding integers and percents doesn't make a lot 
of semantic sense unless you're speaking about adding a number to 
a percentage of itself.

Well, you are assuming that 10 is what the 50% was supposed to apply 
to. REBOL can't make that assumption - it has to do whatyou tell 
it to do, not what you want it to do.

Well it doesn't matter all that much, easy enough to work around. 
 I just wish Rebol showcased a bit more of its ability to have the 
cross product of behavior across types in examples where people would 
go "whoa, how'd it do that?" then... "oh, I see..."

In R3 they stay consistent, and there is an action PAST? to tell 
whether an index is past the end.
>> b: next a: "a"
== ""
>> remove a
== ""
>> index? b
== 2  ; not adjusted
>> past? b
== true


In R2 I don't even see how to write this in mezzanine without temporarily 
appending something on the end of the series (a single element will 
do) and seeing if the index adjusts, then removing what you appended. 
Like this:
>> b: next next next a: "abc"
== ""
>> clear a
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b
== true  ; past end
>> b: ""
== ""
>> also (index? b) < (append b "1" index? b) clear back tail b

== false  ; not past end, but Henrik's method, and EMPTY? will both 
return true.

OK, nevermind, I do not want the text to be longer, a "series is 
past its tail" looks better to me, than any reference to series index

REBOL []

do %../library-dialect/lib-dialect.r

make-routines [
    lib %kernel32.dll
    def-rtn-type long
    ; returns available drive flags as a bitset (in a long)
    get-logical-drives "GetLogicalDrives"
    get-logical-drive-strings "GetLogicalDriveStringsA" [
        buff-len [integer!]
        buffer   [string!]
    ]
    get-drive-type [drive [string!]] "GetDriveTypeA"
]


drive-types: [
    Unknown     ; 0 We don't know what kind of drive it is
    NoRootDir   ; 1 Probably not a valid drive if there's no
                ;   root directory
    Removable   ; 2 It's a removable drive
    Fixed       ; 3 It's a fixed disk
    Remote      ; 4 It's out there on the network somewhere
    CDROM       ; 5 It's a CD ROM drive
    RAMDisk     ; 6 It's not a real drive, but a RAM drive.
]

drive-type?: func [drive /word /local res] [
    res: get-drive-type join first trim/with form drive "/" ":"
    either word [pick drive-types add res 1] [res]
]

get-drive-strings: func [
    /trim "Return only the drive letters, no extra chars"
    /local len buff res
][

    ; Call it once, with 0, to find out how much space we need in our 
    buffer
    len: get-logical-drive-strings 0 "^@"
    ; Init our buffer to the required length
    buff: head insert/dup copy "" #"^@" len
    ; Make the call for real, to get the data
    len: get-logical-drive-strings length? buff buff
    res: parse/all copy/part buff len "^@"
    if trim [foreach item res [clear at item 2]]
    res
]

;print enbase/base to binary! get-logical-drives 2
foreach id [a b "C" 'c "D" d: %E %F %/F] [
    print [mold :id tab drive-type? :id tab drive-type?/word :id]
]
print mold get-drive-strings
print mold get-drive-strings/trim
print read %/

I put an init function in the class, and do any stuff there, then 
its much easier to manage.

a: make class [init]

if you keep the prototype as a block you don't need to do so
>> context proto

thing is load isn't the counterpart to mold.  'DO is.   and even 
then, even MOLD/ALL isn't a real serialization because shared objects, 
or series aren't shared anymore.


although they go a long way, and I have been using them extensively 
in many tools, MOLD & MOLD/ALL are just helpers, destined for advanced 
users who have very special requirements.

I have done some work on this to support reloading of shared & nested 
objects specifically and its easy enough to do (for me ;-), but it 
requires some deeper understanding of REBOL.


I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language. 


IMHO, The current implementation isn't a "bug" but rather an annoying 
limitation which has been known and put off as a "to do" for years, 
by everyone which is capable of solving it.

(cause its a very tedious and "not fun" thing to do)

also, there are nasty binding issues on serialization...  things 
like:

---------------------------------
a: "data"
f: does [print a]
o: context [
	a: "other data"
	f: does [print a]
]
set in o 'f :f
---------------------------------


how is this treated in MOLDing ?  these are hard cases to choose 
from a variety of paths, if we serialize only the o  object, then 
its f method is pretty much broken in current REBOLs.   

how would we handle this?  there are a lot of ways to play with the 
above, but no single method will ever cover all possibilites.  


so in the end, the serialization will never be "perfect", unless 
all data items are signed with a unique key which is retrievable 
at run-time and reusable at each interpretation (pretty much impossible).


IMHO all we can do is properly document  what can and cannot be serialized 
without risk of data corruption.  Currently, official & explicit 
documentation on this is vague at best.

{I agree with Ladislav, though, that serialization should be addressed 
more "completely" at some point, directly within the language.} - 
I do not need that, especially not in this case; but I do want to 
help people to not get caught by the bad design decision making SAVE 
inadequate for the task it is supposed to perform.

aahhh yes... loading doesn't convert the word tokens to their values, 
so they do not get converted to #[none]... they are still words... 


though all the comments disapear... which is understandable in this 
case.

if you had a pre-processor which converted all none to #[none]... 
first thing I'd do is stop using your tool   ;-p

mechanical

? - it is the only syntax allowing me to write a logic! type value 
in using the Data exchange dialect. There is no other way how to 
do it.

Generallly, "preprocessing REBOL scripts" means to work with the 
DED, not with the DD (Do dialect)

but one must understand that when you LOAD data, no evaluation occurs, 
which is why serialization into litterals does not occur. 

this is a big detail, which most REBOLers do not grasp.


the litteral notation allows you to load items AS data, not as DO 
dialect source code.


I guess what could be done is to remove the /ALL refinement and add 
a new refinement which forces the non /serialized format.  but that 
makes SAVE work opposite of other serialization handling ... which 
is why I'm not sure that is such a good thing.

This has nothing to do with any bindology, no rocket science involved

Ladislav, if you try to DO a script saved with SAVE/all or MOLD/all, 
it will fail if it contains functions or objects. And it definitely 
*won't* be "as close to original as possible". So /all can't be the 
default for SAVE.

The primary purpose of SAVE is to save scripts that are to later 
be processed by DO.

When SAVE is being used to generate source that is meant to be run 
by DO, that source should be semantically equivalent to DO code (active 
values in an evaluation context won't be preserved without QUOTE, 
nor will constructed values in a non-evaluating context). When the 
generated source is intended to be LOADed, it should stick to the 
semantics that can be directly LOADed without DO (no multi-level 
"nested scopes" or other binding tricks, no inline modules, no natives). 
And when you are going to combine them, stick to string source.

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

Maxim, we can't extend the existing serialized form to represent 
everything in memory, because binding, cycles and DAGs aren't representable 
without some kind of reference index. So even rebin wouldn't do, 
we'd need something like RIF.

Ladislav, it was just an example to illustrate that the abstract 
REBOL that is accepted by LOAD doesn't exactly represent the real 
REBOL in memory. But it does represent enough to do source processing 
by a preprocessor.

As a matter of fact, LOAD and SAVE/all form a far better duality 
as far as REBOL source is concerned. So Ladislav and I argued that 
making /all the default for SAVE would be a sensible thing to do.

Sure, that's why we are discussing it at all. Besides getting mightily 
side-tracked in semantic debates that do mostly not pertain to this 
issue, to only argument against this suggestion I heard was that 
SAVE should behave symmetrically to MOLD, not dually to LOAD.

SAVE and MOLD are explicitly designed to be newbie-friendly - that 
includes being able to have MOLD generate the value 0.1, which is 
not representable by the (misnamed) decimal! type in memory. And 
#[] syntax has been judged to not be newbie-friendly, or at least 
an ugly thing that only power users do. If you want to reverse that 
decision, fine, but it's unlikely.

Fair enough. So your take is that LOAD/SAVE forms no duality because 
of MOLD is supposed to do "developer pretty printing" but for absolute 
newbie developers, not for developers familiar with e.g. #[] syntax.

the problem is, that Microsoft does not allow me to do what I want 
in Windows

Brian: do you in fact read what I write? Or just single our words 
to pick on?

Andreas, I am not qualified to do so. I haven't read the standard, 
don't know the code involved, and don't run Linux.

if you try to DO a script saved with SAVE/all or MOLD/all, it will 
fail if it contains functions or objects.
 - show me an example.

The primary purpose of SAVE is to save scripts that are to later 
be processed by DO.

 - weird, i always use save and load to save and load data. but, even 
 if that was the case, save/all would work just as well, so this is 
 a silly argument.

Brian: your #[function! ] example is something I have ALWAYS pointed 
out as a bug and you ALWAYS countered by saying it is a "security 
feature" which i still thing is a very stupid thing to do (doing 
that as a "security feature")

SAVE and MOLD are explicitly designed to be newbie-friendly

 - I though Carl had realized, that "newbie-friendly" is the worst 
 thing you can do to a language. I hope others realize this as well, 
 as soon as possible...

Try newbies

: unless I find out you are right, I do not have any reason to believe 
you (I remember, that I was a newbie once too)

Regarding all the above discussion regarding MOLD... there is an 
assumption, once that I do not believe.


The assumption is this: that any function of REBOL could ever produce 
the perfect output storage format for all data.


Or, stated another way: part of the design of building all applications 
that store persistent data is to build the storage formatters (savers) 
and storage loaders.


I don't think there's any way around this, because storage formats 
have specific requirements, such as speed of loading, indexing keys, 
resolution of references (words or other), construction of contexts, 
etc.

Yes, I do agree with you, that is why I restricted my notes (or at 
least tried to) to just script preprocessing.

aha, it is compatible, since your proposed spec is variadic. OK, 
then it is a different problem: you are out of luck with variadic 
functions, not to mention that it is ugly (at least I do not like 
it)

Gregg, the issue becomes, do you want all of them to advance at the 
same time, or nested, and if nested, in which order?

Agreed that the code is "Javaish"... still, hard crashes are always 
worth fixing, you'll never know when they're going to bite you! (Maybe 
Carl should do a blog post explaining why that approach is bad and 
what is the alternative, most people get thaught that stuff in school 
and don't know better.)

Oh ok, I see. In that case, I'd like to see suggestions for how to 
do it more rebolishly. It doesn't immediately occur to me, not knowing 
the context for the code, how it should be better.

Another explanation could be that Carl is suggesting that such code 
(manipulating millions of vectors) makes more sense implemented in 
C (for higher performance), with rebol calling out to it.

Yes, that is a valid interpretation as well (things like that are 
not a good thing to do in REBOL). I do think that you can't give 
a more "rebolish" implementation without the context (that's the 
whole point of REBOL).

hello: func [word][do bind [f/text: copy "hello" show f] word]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [hello 'f] ;  Pass to HELLO any one of the words in 
  this context (here 'f).
		button "Clear" [clear-face f]
	]
]

open-window
do-events

window-functions: [
	hello: does [f/text: copy "hello" show f]
]

open-window: has [ctx] [
	view/new center-face layout bind vid-context/to [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
		button "New window" [open-window]
	] 'ctx context bind window-functions ctx
]

open-window
do-events

Well... what do you need to do again?

What I want to do is the working example I posted above.

hello: does [f/text: copy "hello" show f]

bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [bind-funcs 'f hello] ;  Pass to BIND-FUNCS any one 
  of the words in this context (here 'f).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

You no longer have to do:
bind [a] in ctx 'self
or
bind [a] in ctx 'a

hello: func [ctx] [do bind [f/text: copy "hello" show f] ctx]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [hello self] ;  Pass to HELLO this context (created 
  by VID-CONTEXT).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

hello: does [f/text: copy "hello" show f]

bind-funcs: func [ctx] [

 foreach window-function [hello][bind second get window-function ctx]
]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [bind-funcs self hello] ;  Pass to HELLO this context 
  (created by VID-CONTEXT).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

svv/vid-styles/button/multi/block: func [face blk][ ; <- This only 
does BUTTON for now.
	if pick blk 1 [
		;face/action: func [face value] pick blk 1

  face/action: func [face value /local window word] compose/only [

   window: face/parent-face ; Find the window face <-- (simplistic for 
   now)

   word: window/pane/1/var ; Find a word which references a field in 
   the window. <-- (simplistic for now)
			print "Remake action function."

   face/action: func [face value] probe append append copy [bind-funcs] 
   to-lit-word word (pick blk 1)
			do-face face value
		]

  if pick blk 2 [face/alt-action: func [face value] pick blk 2] ; <- 
  Also need to remake alt-action similarly to action, above.
	]
]
bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

hello: does [f/text: copy "hello" show f]

open-window: does [
	view/new center-face layout ctx: vid-context [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

svv/vid-styles/button/multi/block: func [face blk][ ; <- This only 
does BUTTON for now.
	if pick blk 1 [
		;face/action: func [face value] pick blk 1

  face/action: func [face value /local window word] compose/only [

   window: face/parent-face ; Find the window face <-- (simplistic for 
   now)

   word: window/pane/1/var ; Find a word which references a field in 
   the window. <-- (simplistic for now)
			print "Remake action function."

   face/action: func [face value] probe append append copy [bind-funcs] 
   to-lit-word word (pick blk 1)
			do-face face value
		]

  if pick blk 2 [face/alt-action: func [face value] pick blk 2] ; <- 
  Also need to remake alt-action similarly to action, above.
	]
]
bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

hello: does [f/text: copy "hello" show f]

open-window: has [window ctx] [
	window: view/new center-face layout vid-context/to [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
		button "Clear window2's field" [clear-face window2/user-data/f]
	] 'ctx
	window/user-data: ctx
	window
]

window1: open-window
window2: open-window
do-events

No, Gregg's first example suffered because it only did a BIND once, 
when the window was created. It needs to do the bind every time the 
button is pressed.

A hash doens't allow me to do a wild card search

http://www.rebol.org/view-script.r?script=like.rlets you do more 
than find/any, but you're still going to have the overhead of checking 
each string. Depending on your needs that may work, or you could 
make one big string out of them and just PARSE that.

looks like I should try and get a hash for each first letter, first 
and second letter etc so I can at least narrow it down to the first 
3 letters and then do search on everyone after that.

It's also mentally uncomfortable - it feels like there should be 
a way to do use/only [a][a: 1]

parse "this" use/only [mk][opt "t" mk: to end (probe mk)]

The current USE does:
1. Create context of specified words.
2. Bind body.
3. Evaluate.
Chris wants to be able to remove the evaluation.

In a perfect world with no legacy issues to worry about, I would 
prefer USE to do only steps 1 & 2, and USE/DO to do all three steps.

Or, a new function could be introduced (which I might name ENCLOSE 
or COOP) which does only steps 1 & 2.


Alternatively, if there was a function which returned a context created 
from a block of words, eg:


 CONTEXTUALIZE: func [words [block!]] [ ... ]  ; Returns a new context 
 containing words without evaluation.


then you could imagine using an idiom to get steps 1 & 2, or all 
three steps. eg:

	bind body contextualize words  ; Steps 1 & 2.
	do bind body contextualize words   ; All three steps.

So Chris' example would be:


 parse "this" bind [opt "t" mk: to end (probe mk)] contextualize [mk]

(<sigh> If only BIND had its argument order reversed...)

I have a question about 'unique that could become a feature request.

Somebody ask (on the french Rebol forum) how he could remove the 
duplicate records from this dataset :
database: [
	a "b" "c 1" "d"
	a "b" "c 2" "d" 
	a "b" "c 3" "d"
	a "b" "c 2" "d" ;ligne 4 to delete
	a "b" "c 5" "d" 
	a "b" "c 6" "d" 
	a "b" "c 7" "d" 
	a "b" "c 2" "d" ;ligne 8 to delete
]

My first though was "use 'unique func". But it turns out that it 
can't do what I though.

As usual, the doc tells nothing about that (in fact it ells pretty 
nothing on the func), but with the /skip refinment, it seems it only 
checks the first value at each skip position (so the 'a in this dataset), 
not all the values of the record.

Gabriele, it would certainly be good to have your nice MAKE-CONTEXT 
built in. I had a strong feeling you had something like that already 
done. I just wish for a shorter function name. You're probably right 
about the higher frequency usage of USE, but I was just trying to 
find a way to minimize the characters typed.

In my proposed alternative reality, where  USE and DO USE  replace 
 MAKE-CONTEXT and USE, there would be a saving in typing only if 
DO USE was used less than 3 times as often as USE (ie. < 75% of the 
time).

If I could show that, then my alternative reality would at least 
have some typing advantage.
I don't have much hope of that, so I withdraw.
I'd be very happy with your MAKE-CONTEXT built in, anyway.

I'm a newbie to Rebol. I need to know how to delete a file on my 
website. I tried uploading a file using:

write ftp://user:[pass-:-website-:-com]/myfile.enc myfile.enc


which does not work because of the ['-:-'] in the user name. I tried 
replacing the ['-:-'] with '%40', still did not work. So I tried the 
following which works:

ftp-port: [
	scheme: 'ftp
	host: "ftp.mysite.org"
	port-id: 21
	user: "[user-:-mysite-:-org]"
	pass: "xxxxxxxxxxxxx"
	target: %myfile.enc
]
file: read %myfile.enc
write/binary ftp-port file


So now my file is on my server. My question is - How do I delete 
this file? I see no way to tell the Delete command the name of the 
file on my server so it can delete it. And:

delete ftp://user:[pass-:-website-:-com]/myfile.enc


does not work for the same reason the standard velsion of write does 
not work, because of the ['-:-'] in the user name. Any help much appreciated.

I had to type that all out very slowly and carefully, long password, 
and I don't use the shell much these days (I'm an old Amigan). YES 
it worked! Thanks Graham. I'll add the guimauve, they do look delicious. 
Help me out much more and end up delivering a feast.


So I imagine I need to include prot-ftp.r in my Rebol programs and 
I'll be able to use the standard way of accessing files on my server? 
Am I right?

Thanks for all the help, this will get me going now.

I don't want to add new refinements for such a easy to do solutions 
as they would slow every APPEND a little bit.

The code below seems to do what you want......Just lacks the clever 
optimisation that'll turn it into a one-liner :)

inc-counter: func [process path /local p] [
    p: select values process
    path: parse mold path "/"
    p: select p to-word path/1
    p: find p to-word path/2
    p/2: p/2 + 1
]

If you are happy to use issues instead of integers for your process 
ids, then maybe this would be ok:

values: [

 #1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 #2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [process path /local p] [

 do reduce [to-set-path p: join 'values/(to-issue process) path p 
 '+ 1] 
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

I was thinking along the same lines as Anton. 

values: [

 1 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]

 2 [dos [new 0 modified 0 deleted 0] fic [new 0 modified 0 deleted 
 0]]
]

inc-counter: func [key path /local rec] [
	rec: select values key
	path: head insert copy path 'rec
	do reduce [to set-path! path  1 + do path]
]

inc-counter 1 'dos/new
inc-counter 1 'dos/new
inc-counter 2 'dos/deleted
inc-counter 2 'fic/modified

Nevertheless, I do not like the header of the FORALL function, since 
the WORD argument is actually used to supply two values to the function, 
which is not a KISS strategy

Not using FORALL, I actually do not mind, I just wanted to point 
out what is wrong about it

I am pretty sure, that *if* FORALL was defined properly from the 
start, everybody would perceive a change to the "two in one argument 
passing method" inappropriate. But, since it is a backward compatibility 
issue, you do not see what is wrong about it. Nevertheless: the WORD 
argument is an independent word, which is used to "define" a local 
in the BODY argument, that is why it actually does not make sense 
to use it as a "series container" on entry

In my opinion, different functions are defined not because we like 
to have different functions, but because they do different things 
for us

I do not dispute, that there a faster methods for removal.
But removal is not the only way to deal with series.

:) Well, we can also today do something like:

>> blk: reduce [1 'a to lit-word! "2" 'b]
== [1 a '2 b]
>> blk/(to lit-word! "2")
== b

But I will consider such for rubbish.

>> p: to path! [blk [a b]]
== blk/[a b]
>> do p
== 0

you guys didn't solve the "how do we use an integer as a key instead 
of an index" - you *can* use integer as a key without using it as 
an index, if you like. Nevertheless, the path-access does not work 
like that. You should either get used to it, or use a different access 
method, that is all. Anyway, you have got no right to call it a "GAPING 
hole in the path evaluation", taking into account, that it is by 
design. The fact, that your design preferences differ is irrelevant.

not being able to use paths to access these datasets is quite annoying 
since we can practically do all the rest.

And, your "integer problem" is easy to solve. I guess, that you are 
so experienced, that you actually *are* able to do it.

anyway.. why you simply do add a wish to CC and see what Carl thinks 
about it.

I'm not interested in all the possible cases where using temporary 
variables isn't so bad (or even where it's better). I'm interested 
in those cases, which do come up from time to time, where using temporary 
variables is uncomfortable, and using a path directly to get to what 
I want would be much better (indeed, smoother).

I don't think the Ruby ! sigil is particularly meaningful, so I wouldn't 
vote for that.


While having complete consistency might make for a more pure and 
mathematically beautiful language, I don't think that is REBOL's 
goal. REBOL's design has elements that exist to make things simpler 
and more obvious. You could argue that complete consistency would 
do that, but if you look at history, that's not the case. 


the argument that sort modifies because you can always copy first 
is met by the retort that you can always assign afterwards

 - You can always assign, but if you have other references to that 
 series, they wouldn't see the change. This can also cause unintended 
 side effects of course, which is the risk of modifying, but that's 
 part of REBOL too. :-\


We'll never please everyone. I'm OK with the current SORT and set-operation 
behavior.

(((( I know you don't agree with me, but I want a VM level way to 
define pure functions (that are guaranteed they can't change anything 
outside itself). 

Big future deal in rebol to me is in runtime code generation to express 
things and *code mobility* and there can't be any real mobility if 
the code I get can "get over the wire" can do anything to my system 
))))

It comes to my mind that reduce/into should not behave like inserting 
data but changing them.

Changing data if it's it's at the end of the container will simply 
add them.

But if it's at the head of the container, it will remplace them intead.
Probably more usefull, than the current behavior.

so that 
>> reduce/into data data

would simply do the job we all expecting. To reuse the same block. 
A reduce in place (rest in a peace)

It doesn't make sense to reduce/into the same series, but that's 
not the intended purpose. Or am I missing something? Of course, people 
might still do it, thinking they're optimizing. :-\

sforpath: func ["Evaluate a path similar to the builtin path evaluation, 
except number elements SELECT (rather than PICK)."
	path [path!] action [function! block!] /local e v c
][

 v: get path/1 ; The path is assumed to begin with a word, so get 
 its value.

 while [not tail? path: next path][ ; Step through the path to inspect 
 each of its elements.
		c: v ; Store the current value before SELECTing into it.
		e: pick path 1 ; The current element.
		;print [mold :e mold type? :e]
		if get-word? :e [e: get e]
		case [

   number? e [v: select v e] ; SELECT this number element. (Paths normally 
   PICK number elements.)

   word? e [v: select v e] ; SELECT this word element (as paths normally 
   do).
		]
	]
	;?? e ?? v ?? c
	; Process the last element.
	if block? :action [action: func [c e] action]
	action c e
]
; Test
values: [1 [dos [new 0]]]

sforpath 'values/1/dos/new [c/:e: c/:e + 1]  ; <- DideC's INC-COUNTER 
function could be implemented simply using this.

The main reason that UNIQUE isn't used is because it is not very 
useful: It is easier to make sure that the series is unique in the 
first place. The other "set" functions like INTERSECT, DIFFERENCE 
and EXCLUDE are used more often, even though they do the same copies 
as UNIQUE, using the same hashing method.

about reduce/into b b

It allows to keep several references of the same block without the 
need to reassign them when the block is reconstructed.

But currently, we can't avoid the block expansion because the data 
are inserted instead of beeing replaced (which would be more useful 
to my mind).

Then, if internaly it's faster to do a copy, I don't care while it's 
not recycled by the GC (for the reasons I mentioned previously).

how to remove the last character from a file in R3?


I don't know, if it will be done differently in R3, but using R2 
I would do something like:

sz: length? p: open/binary %file
write/binary %newfile copy/part p sz - 1
close p

Here (under windows) a unix format text file is changed to dos format, 
if I do, what you just suggested. So it become longer.

*do do = to do

The only problem I am having with it is, that it creates the given 
FILE, if it does not exist, while I would prefer the function to 
do nothing in that case

I do not consider it a bug, but I do want a different behaviour, 
which I have to simulate somehow

So, I need to send seme emails and need to login into my SMTP server. 
And this mostly fails out-of-the box in Rebol 2 and I can't remember 
what to do to make it work:

>> send [robert-:-muench-:-googlemail-:-com] "Test"
Net-log: ["Opening" "tcp" "for" "esmtp"]
connecting to: mail.saphirion.com
Net-log: [none "220"]

Net-log: {220 mail.saphirion.com ESMTP Exim 4.63 Sat, 09 Oct 2010 
12:12:46 +0200}
Net-log: [["EHLO" system/network/host] "250"]

Net-log: {250-mail.saphirion.com Hello mail.saphirion.com [10.0.0.3]}
Net-log: "250-SIZE 52428800"
Net-log: "250-AUTH LOGIN CRAM-MD5 DIGEST-MD5"
Net-log: "250 HELP"
Net-log: ["Supported auth methods:" [login cram]]
Net-log: ["MAIL FROM: <[robert-:-muench-:-saphirion-:-com]>" "250"]
Net-log: "250 OK"
Net-log: ["RCPT TO: <[robert-:-muench-:-googlemail-:-com]>" "250"]
** User Error: Server error: tcp 530 Relaying not allowed
** Near: insert smtp-port reduce [from reduce [addr] tmp]


I think the probem is that Rebol isn't logging in correctly. Either 
it doesn't understand the supported methods or something else is 
different. Any ideas how I can fix it or track it down?

Gabriele, thanks, I trust your memory better than mine about this. 
This is definitely a good reason why Carl is trying to do Rebin before 
he releases the host code - reducing direct access to internal data 
structures.