World: r3wp

tuple aren't immutable in R2 OR R3

 - it is discussed in http://www.rebol.net/wiki/Identity#Expressions_modifying_their_values

Tuples are exactly as mutable as integers in R2 as well as in R3

BrainH asked: Didn't know you could put the /compare index in a block. 
Can you specify more than one index?

Sunanda says: Yes you can:
sort/skip/compare s 4 [1 2 4 3]
== [1 2 8 a 1 2 6 b 1 2 7 c]


That's great but can you do that with a block of blocks of  data....

example: 
s: [
	[1 2 8 a]
	[1 2 6 b] 
	[1 2 7 c]]
]

remove extra ]

use a compare function for that

So nothing as easy as Sunanda's example built into rebol?

To turn Maxim's comment into an example:

   sort/compare s func [a b] [
== [
    [1 2 6 b]
    [1 2 7 c]
    [1 2 8 a]
]
s

Oops that SORT line should be
   sort/compare s func [a b] [return a/3 < b/3]

thanks... I was a bit lazy there  ;-)

so something like this will give me a sort on multi indexes?
sort/compare s func [a b] [return a/4 < b/4 return a2 < b/2]

btw return is never required at the end of a func .. and slows down 
rebol A LOT in tight loops.

amacleod... your example would stop at first compare (you're returning 
right away)

try this instead:

sort/compare s func [a b] [
	either  a/4 = b/4  [
		a2 < b/2
	][
		a/4 < b/4
	]
]

but not exactly sure of results...

For safe stable, sorting return -1, 0, +1 rather than true or false:
   http://www.rebol.com/docs/changes-2-5.html#section-72

I do not know if that is what I want...i'm looking to prioritize 
each compare giving each a "weight"

example" 


sorting a list of first and last names first on last then on first 
in case of same last names

The basic compare function then (assuming you are sorting a block 
of objects) is:

   func [a b] [if a/surname = b/surname [return a/firstname < b/firstname] 
   return a/surname < b/surname]]

so if I'm comparing 5 or 6 fields I would nest to if statements 5 
deep?

Basically, yes.....You may find a neat way of refactoring....Or JOINing 
keyfields so you can do a single compare....but that is the basic 
principle.

thanks all

late but here is an equivalent working example:

names: [
	["zz" "bb"] ["cc" "zz"] ["aa" "aa"]["bb" "ee"]
	["zz" "tt"] ["cc" "aa"] ["aa" "yy"]["bb" "aa"]
]
sort/compare names func [a b][
	either a/1 = b/1 [a/2 < b/2][a/1 < b/1]
]
probe names

== [ ["aa" "aa"] ["aa" "yy"] ["bb" "aa"] ["bb" "ee"] ["cc" "aa"] 
["cc" "zz"]  ["zz" "bb"] ["zz" "tt"] ]

that limits it to comparisons on two fields...right?

yep... as sunanda said, you need to chain the compares.


there might be a way of using ANY/ALL functions too, but it can be 
tricky ... though usually yields less code.

yields = requires

Something like this will sort on all fields
 

sort/compare s func [a b] [for n 1 length? a 1 [if a/:n < b/:n [return 
-1] if a/:n > b/:n [return +1]] return 0]

refining sunanda's example, sorting on selected fields

sort/compare s func [a b] [
	repeat n [2 4] [
		if a/:n < b/:n [return -1] if a/:n > b/:n [return +1]
	] 
	return 0
]


I just indented it to make it a bit easier to break up

note, the order of the fields given is the order in which they are 
weighted

Thanks, Maxim -- that's nice.

I wouldn't have thought of your idea, so I thought *yours* was really 
nifty  :-)

That awsome...thanks guys

I've used 'case statements for multiple levels of sorting, like that

...although I can't seem to find where right now

can you use get-modes over ftp?

try it ..

i get errors

>> nodes: get-modes port 'file-modes
** Script Error: Invalid argument: file-modes
** Where: halt-view
** Near: system/words/get-modes port/sub-port modes

You might not be able to get file-modes. Try some of the other modes.

You might be able to modify my ftp protocol for R3 to add the SITE 
command so that you can do CHMOD if that's the aim

modify my ftp protocol

 for R2. R3 doesn't have anything like GET-MODES yet, though something 
 is planned.

or you could modify the ftp protocol for r2 to display all the file 
modes sent back by the LIST commands

I think my r3 protocol does currently display all the file attributes

That might be tricky though, because different FTP servers format 
that information differently. A large portion of the source for FileZilla 
or other FTP clients that have GUIs for file listings is different 
parsers for the file listings of different FTP server software.

But we have PARSE, so it doesn't have to be that bad :)

IIRC mozilla's ftp server code is like 1MB of source code.

practically speaking though if you only have the one ftp server .. 
you only have to do it once

ftp server.... should read   ftp server specific

the r2 formatting code is a page of parse rules

Practically speaking, there are probably over a hundred different 
FTP server platforms, and the R2 parsing code only supports (hopefully) 
most of them.

So, if you're not looking for a generalized solution.. then it's 
quite doable.

I've had issues where paths misaligned between list, read and write 
ops !