AltME groups: search

So FIND cannot locate native! types by direct comparison.

Looks like a bug to me !  I confirm the above behaviour with my testing 
on View 2.7.6.4.2 on Linux.

A useful warning not to use current time as a unique key :-)


A wait of .001 is sufficient to get me different times -- but that 
may be processor and operating system dependent.

This code may help in exploring your limits:

n: 0
forever [
   n: n + 1
   k: enbase checksum/secure to-string now/precise
   wait .001
   k': enbase checksum/secure to-string now/precise
   if k = k' [print n halt]
]

better hint fo a unique key ? (meet rebol a week ago)

Never use current time as key generator. Win98 uses about 0.01 second 
timer resolution, which slapped me in the face a few years ago. Other 
OS'es may be similar.

As Henrik says, this code _probably_ returns unique ids:
n: 0
forever [
   n: n + 1
   k:  random/secure enbase checksum/secure to-string now/precise
   k': random/secure enbase checksum/secure to-string now/precise
   if k = k' [print n halt]
]


But for best results, add in something more:
-- a count?
-- user name / IP address?

a count would be useful

(opps -- my enter key got reset somehow)
1. hire me at a reasonable rate as your official scapegoat

2. make yourself potentially a billion times safer (so no need for 
a scapegoat) by adding something to the checksum string -- eg:

    k:  rejoin [random/secure enbase checksum/secure to-string now/precise 
    random/secure 100'000'000]
3. read up on UUID / GUID generation, eg:
    http://www.rebol.org/ml-display-thread.r?m=rmlCYYK

i usually use a random string generated on app startup, the time 
and a random value at each call.  

purists will tell you not to use the system time for the random seed 
.  it creates a time frame of attack which vastly reduces the number 
of hits required for brute force attacks.  


use two independent system data values like disk free size, & a measured 
I/O divided by each other.   a single digit off generates a completely 
different seed, so its much better and cannot be guestimaged easily 
by the attacker.

I just ask the user to think of a number

Of course, if you are running on a real operating system, you can 
get better "randomness" using:

>> p: open/binary/direct %/dev/urandom
>> enbase copy/part p 16
== "2Fm5zVhMBCgQkdQ3afEpYw=="
>> enbase copy/part p 32
== "Ymk3t6HyAgKNzpALcvGSXyV6poSDwRzk5pCR7IoDz68="
>> close p

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.

No, delete does not take a file spec

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.

Patch the scheme in memory, OK I'll give that a go. I'm on a steep 
learning curve here.

system is a REBOL object

prot-ftp.r is a file in my home folder. I hope that makes sense. 
Anyway, your code works :)

With a license.

Hopefully you have a Linux SDK license?

I do, and a windows one.

http://www.rebol.net/cgi-bin/rambo.r?id=-4777&

Delete does not take a port spec

( Gabriele are you still reviewing Rambo submissions? )

sorry if I will propose a nonsense, or if the solution already exists, 
but - when using REBOL for data extraction (using parse) and forming 
a block or CSV as a result, I often come to the need of append-only-if-the-item-does-not-exist-already, 
so using following idiom:

if not found? find target value [append target value]


What about adding /not refinement (or other name), so that I could 
append only unique values?

Also - is there any way of how to easily find out, if the block is 
unique? Should I apply 'unique, and compare the length before and 
after? Pity 'unique has /skip refinement, but does not have /compare 
one (as 'sort has), so that I can't set, when I have e.g. record 
of 5 items, I want to 1) set the record size (/skip) 2) select fields, 
upon which we want to define uniquess - could be an integer offset, 
or a block of positions [1 3] ... 'sort allows at least the offset 
via /compare

ALTER removes a value, if it's found.

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

Can I somehow get a difference of two blocks, with different sizes? 
Trying to avoid loops, but I will use loop most probably anyway ...

blk1 structure: [contract user tarif]
blk2 structure: [contract user street town tarif]


I know there are functions like intersect/difference, they even have 
/skip refinement, but those most probably can't treat different record 
sizes?

I really think, again, that  'append-or-insert-only-if-the-item-does-not-exist-already 
 should be a native in R3.


its a function MOST of us would use on a frequent basis.  it would 
be very usefull and its very powerfull with a /skip refinement

As opposed to that, my opinion is, that it should not be a native, 
since no significant speedup against a mezzanine would be observable

we can start with a mezz... but because of the find and then insert/tail 
and all the possible refinements its needs to handle... overall, 
it will be faster as a native.

I would like to see a version of REBOL where only the bare minimum 
natives are implemented and everything else is a mezz. It's possible 
that REBOL would run many months faster if not preamturely optimized. 
;-)

well, then you can say that you can fit your software on a floppy 
and wave a 5.25" floppy in people's faces :-)

I wonder if you can fit a script onto those square barcodes.

Does anybody has a script which would convert JS like expressions 
to REBOL expressions with correct precedency?
for example to convert this:
-( y1 - y0 ) / ( y2 - 2 * y1 + y0 )
to:
-( y1 - y0 ) / ( y2 - (2 * y1) + y0 )

A version of Gabriele's work is here:
    http://www.rebol.org/ml-display-message.r?m=rmlXHTS

add a reduce.

I give up. I have a routine that creates CSV files but I am stuck 
with how change what is an 0D 0A  to just an 0A  when it comes to 
setting up the actual CSV text file.  Anyone know?

Maybe I did at one time but at my age it's easy to forget! Real easy. 
I just took a look at the reb dictionary and aha! , there it is in 
black and white.

I need some help dealing with paths.

I have a block of sublocks and values refered by words.

I want to make a function that increment a value in a subblock based 
on a process number and a path. But adding subpath to a path seems 
to work only with file! type.

I hope that the code bellow obviously show what I want :

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] [
	p: select values process
	p/(path): 1 + p/(path)
]

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

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
]

Hmm, I see such expressions as

    parse mold path ...

as a very bad habit

Thanks Sunanda. I need any length paths, but its a proposal I can 
work  based on.

Thanks Ladislav and sqlab -- I was having a blindspot about being 
able to directly access the parts of a path.


DideC -- if you need to go to any depth, this version may help (subject 
to optimisation by the gurus):

inc-counter: func [process path /local p] [
    p: select values process
    foreach pp copy/part path -1 + length? path [
        p: select p pp
        ]
    p: find p to-word last path
    p/2: p/2 + 1
]

It's a pity we can't select integer series members using path notation 
directly.

My first thought was to introduce a new datatype (like a "lit-integer!" 
(eg. '1) or an "index-integer!" (eg. @1), but it still means there 
will exist a datatype which, in a path, does not SELECT like other 
types, but is interpreted as a direct index PICKer.

So now I think there could be some "escape" path notation which changes 
the PICK-type functionality of integer path members into the SELECT 
type (which all the other datatypes have by default).

eg.  values/^1/dos/new   <-- The ^ causes the path to consider the 
following integer 1 as a series member to be SELECTed like other 
datatypes, instead of the PICK special treatment.

not a bad idea for path notation.

Except that ^1 is a valid word. :-)

Maybe, a lit-integer! could do the job.
'1

I don't know if we need a change. While having "one path notation 
to rule them all" is a nice goal, the cure might be worse than the 
disease.

but I think too, that SELECT and FIND should be able to process paths 
to look for nested structures.
via a refinement maybe.
Like select/path and find/path

My reasoning is that the effort to implement a lit-integer! type 
is not worth the value the notation provides, at least not right 
now. Once R3 is out, stable, and complete, ask me again. ;-)

In any case, write up a proposal, and RT will make the call. It's 
always good to write things down so we don't forget.

Is this a bug ?

>> a: make object! [ b: [ 1 2 3 4 5 ]]
>> probe a
make object! [
    b: [1 2 3 4 5]
]
>> forall a/b [ print a/b/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall a/b [print a/b/1]
>> forall word: a/b [ print word/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall word: a/b [print word/1]
>> word: a/b
== [1 2 3 4 5]
>> forall word [ print word/1 ]
1
2
3
4
5

yes, you need to specify a word ... not a set-word.

How can it be a bug, when it is documented?

>> forall (in a 'b) [print a/b/1]
1
2
3
4
5

Looks more than sufficient for me.

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

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

Assuming (hypothetically), that FORALL did not use the "two in one" 
method, the Graham's example would look as follows:

forall b a/b [print a/b/1]


, which is preferable, since it clearly suggests, that the word 'b 
in the BODY is actually not the same word as in a 'b

Aha, it seems, that I noticed one more strangeness in this. Why actually 
the expression:

forall (in a 'b) [print a/b/1]

prints what it does in R3?

the reason I use 'forall is so I can remove elements of a series 
as I traverse it.

so

forall series [ if series/1 = something [ remove series ]]


which 'foreach doesn't allow because you don't have a reference to 
where you are in the series

remove-each is indeed much faster and it's a native.

what I have been explained is that it makes a new series and only 
copies when remove is false.  then replaces the pointer within the 
series to the new one.

Steeve, removal of one object from a block is an O(n) operation, 
where n is the length of the series. That would make a naive implementation 
O(n ** 2), while REMOVE-EACH is just O(n)

does CLEAR only set the soft size of a series or does it actually 
truncate the internal buffer of a series?

although,maybe, that in some cases, the GC is able to reassign a 
smaller part of memory to the series, but I doubt it

seems to work
>> a: [ 1 2 3 4]
== [1 2 3 4]

>> forall a [if a/1 = 3 [a/1 / 0] print a]
1 2 3 4
2 3 4
** Math error: attempt to divide by zero
** Where: / if forall
** Near: / 0

>> a
== [3 4]

Using 'forall with 'remove will skip the element after a removed 
one (in R2 at least, don't know if it changed in R3)

>> X: [1 1 2 2 3 3 4 4 5 5 6 6 7 7]
== [1 1 2 2 3 3 4 4 5 5 6 6 7 7]
>> forall X [if odd? X/1 [remove X]]
== [7]
>> X
== [1 2 2 3 4 4 5 6 6 7]

Gregg, I should make it clear that my alternate suggestion was *not* 
to add a new datatype, but to extend the path syntax with an escape 
char (which, if it would be ^, would also unfortunately reduce the 
syntax of words a little bit).


Perhaps ' is a better path escape char, because '1 is currently not 
any valid rebol datatype, so adding it would not require reducing 
the syntax of any existing datatype, as using ^ would. So,  values/'1/dos/new 
 would not contain any new datatype, it would simply extend the path 
syntax with an escape char which must be followed by an integer.


This escape mechanism should also work when followed by a paren, 
allowing evaluation of any expression (as long as the evaluation 
of the paren results in an integer). eg.
	n: 3
	values/'(n - 2)/dos/new

and as you say, its a simple added case in the run-time evaluation 
of paths, as well as an additional variation to add in the lexical 
parsing of paths.

overall, not such a big deal to implement.

there should be a note in the 'FORALL help ...   

** do not use this function  **  all the alternatives are better 

;-D

Actually, if you want to remove more elements from a block, then 
you either need to know what you are doing, or you should use the 
REMOVE-EACH function, eitherwise you quite likely get O(n ** 2) time, 
which is sloooow

I disagree. Alternatives are not always better.

If I traverse a series and depending of the data, I change an element 
or remove it, then I regard forall as appropriate.

You can do whatever you like, but removal of N elements from a block 
of length N is O(N * N) usually, if not done cleverly.

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

Gabriele, having a look at

http://www.rebol.org/ml-display-message.r?m=rmlXHTS


, I wonder, whether it can handle equivalents of such expressions 
as [3 ** 3 ** 3], which my

http://www.fm.tul.cz/~ladislav/rebol/evaluate.r

handles as follows:

>> std [3 ** 3 ** 3] translate
== [power 3 power 3 3]

Ladislav: I don't remember, I guess Anton is right. I wrote that 
rather quickly, mostly as a PARSE example. I haven't really used 
that script after that, so I've never had a good reason to improve 
/ complete it.

:-) it would be nice to write a proper, complete compiler (including 
optimization etc.). your script may be already be close enough?

nevertheless, it was originally meant as a "teaching code", so I 
do not claim completeness, or fitness for other purposes

Something to consider:

blk/'a/b
is a valid path today:

>> blk: ['a [b 0]]
>> blk/'a/b
== 0


If ' is made to be an escape, when followed by an integer, then it 
might be a bit confusing. On the other hand, I see lit-paren! as 
an usable new datatype, and in that case, it's kinda like an escape, 
when used in path notation. Something like:

>> blk [(a b) 0]
>> blk/'(a b)

which isn't valid today.

It should have been with a colon:
>> blk: [(a b) 0]

Remember you can always do:

>> blk: [1 a 2 b]
== [1 a 2 b]
>> second find blk 2
== b

But of course that's way more than just writing: blk/'2

It can be a bit confusing, because blk/'a mean: search for lit-word 
'a in blk. So I would guess, blk/'1 mean: search for lit-integer 
'1 in blk. That would be my initial though, when I saw this the first 
time.

Or not lit-integer, but lit-word '1 (assuming '1 would be a valid 
lit-word).

When reconsidering all this again, I would like to question, how 
blk/'a works today. Why not evaluate 'a to a? Parens are evaluated 
in paths:

>> blk: [1 a 2 b]
== [1 a 2 b]
>> blk/(1 + 1)
== a

The reason, I would expect  'a to be evaluated in a path, is because 
it is when standing alone:

>> type? 'a
== word!

Like parens are:

>> (1 + 1)
== 2


It can be argued, that different behaviour, when used in a path, 
is a bad thing.

Geomol:

>> blk: [(a b) 0]
== [(a b) 0]

>> blk/(quote (a b))
== 0

There has to be a limit somewhere

:) 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.

Not to mention, that it is illogical to have lit-parens, since we 
already have them. They are named blocks

Hm, then I would expect this path notation to work:

>> blk: [[a b] 0]
== [[a b] 0]
>> blk/[a b]
** Syntax Error: Invalid path -- blk/

Same in R3.

Yes, it simply does not work, the funny thing about it is, that this 
does:

>> blk: [[a b] 0]
== [[a b] 0]

>> blk/([a b])
== 0

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

So, it is a problem of the language parser, which does not accept 
some data, that the interpreter can process

you guys didn't solve the "how do we use an integer as a key instead 
of an index"


this is a GAPING hole in path evaluation.  using integers isn't some 
fancy side datatype.


we are not adding a new datatype, its not a complex system like using 
parens (which is also very slow) and it doesn't require advanced 
binding tricks.

I wouldn't call it a gaping hole, I would call it "the intended design". 
:-)

well...  can I not agree with the design, cause "there's a GAPING 
hole in the design"  ;-)

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.

no not irrelevent.  we are all users, and some of us agree that this 
is a hole in the design.

we are all users, and some of us agree that this is a hole in the 
design.
 - so what? some don't, which proves my point

It does in this case, your point is irrelevant, since it you are 
trying to call "a hole in the design" something, that provably *is 
the design*

Not being able to use my radio frequency tuner for TV broadcasting 
may be disliked by me, but I have no right to call such a property 
"a hole in the design" regardless how many other people would want 
to agree with me