World: r3wp

YES, it's working even in direct mode. But must use the file name 
as well

Yes, that's right, you would have got the "Cannot open a dir port 
in direct mode" error ?

Congratulations. You successfully used my patch. :-)

and I think, this should be enough: thru "tcp 550" to end

lines 81 and 107

Could be. Thanks for your report.

Thanks you for the patch:-))

Most welcome, Oldes.

What's your FTP server, by the way ?

(I mean, what's the name and version of the FTP server ?)

ProFTPD 1.2.10 Server (ProFTPD)

Thankyou.

Ok uploaded new version to the same location.

Hello;
  I'm getting an
   "Internal Error: No more global variable space
     Where: to-word
** Near: to word! :value"


 when i run a program that after reading a file into memory, it then 
 does a character by character parse of the file and writes any words 
 that it finds to a new file.  The code that seems to be causing a 
 problem is this:

    Write/Append OutFileNameFull reduce [to-word WordStr newline]   


It gets through about 1.5 MB before it "runs out of global variable 
space".


Why is it running out of global variable space when there is only 
the one variable (to-word WordStr)?

you reached Rebol's limit - you have declared too many global variables 
with the command to-word WordStr. Do you really need it?

Why you convert it to word anyway?

Write/Append OutFileNameFull join WordStr newline

Nut if I understand it well, you need content of variable which is 
stored in the wordStr

(nut = but)

>> w: "someWord"
== "someWord"
>> reduce [to-word w]
== [someWord]
>> find first system/words 'someWord
== [someWord]

but this is interesting:
>> length? first system/words
== 2600
>> newword
** Script Error: newword has no value
** Near: newword
>> length? first system/words
== 2601

Thanks but WordStr is a string and I need it to be a word type.

Actually, you are right.  Thanks Oldes.  I was able to write it all 
to the file then read it back in and parse it into 'words' without 
using 'to-word'.

This is a frequent stumbling block with beginners - using more words 
than necessary. Words are really good at expressing distinct concepts 
(ie. variables). If you have lots of similar data, then that really 
just calls for a series.

Anyone tried printf from the library?

>> do %printf.r
>> printf ["%d" .02 ]
** Access Error: Cannot open sprintf
** Where: routine-call
** Near: routine: make routine! spec library

note that r3 will make it easier to create non-bound words (i.e. 
symbols) for the cases when you want to use words as symbols (dialects, 
data, etc) and not variables. anyway, as anton says, i don't think 
anyone would ever really need more than 8k distinct words, so when 
you get that error it means that probably you are doing something 
wrong :) (ah, and given that contexts are extensible in r3, i expect 
the 8k word limit to go away)

Gabriele - as you mention dialects, will parse see any changes/enhancements 
in R3? Just curious :-)

maybe. we've been discussing a few things. nothing decided yet.

I wonder if beginners will take longer to realise the error of their 
ways...

anton, yes that could be an issue. maybe we could have a soft limit 
or something like that for contexts. but, i don't know if there's 
an hard limit, i'm just assuming there isn't, but i may be wrong.

They'll find the hard limit when they exhaust memory. :)

:-)

Graham, I bet printf is not finding the either the DLL or the function 
on the DLL.

Is this a standard windows dll?

Yes.

Humm. It seems that  WinXP' kernel32.dll doesn't includes the sprintf 
function. I will apreciate if anyone can point to the proper DLL.

msvcrt.dll

That is the C runtime. There are a few other (older) C runtimes on 
Windows, but that is generally the best one.

Thanks Brian.

New printf.r script with fix commited to the library.

Thanks.

Humm. I give up. Has somebody found a solution to the path capture 
problem?

#!/usr/local/bin/rebol -sq
REBOL []
print first system/options/args

What I need is to be able to capture the full path of the first arg 
passed to such script.

Not just the filename.

The reason is that the script is no of the same path of /usr/local/bin 
the script fails to find the file.

Which is passed as arg

Hopefully this is not too convoluted...

if you encap it, the CD will be the dir where the program was started 
from. when run with a shebang though... not sure if there's a way.

No SDK in OSX :-/