World: r3wp

The first load/all seems to wrap in brackets once too often !

The difference is in whether there is a single item or multiple items 
being loaded.

Mmm, don't see it in RAMBO already. Anybody can confirm ?  By the 
way, SAVE or SAVE/ALL doesn't make a difference, but it must be LOAD/ALL 
to show the inconsistency.

I'm sure we've been over this one before, actually.
Similar behaviour:
>> save %afile [1]
>> load/all %afile
== [[1]
]
>> save %afile [1 2]
>> load/all %afile
== [1 2
]
>> save %afile [1 2 3]
>> load/all %afile
== [1 2 3
]

that's because save is like mold/only, except when the block only 
has one item.

i'm not sure we can classify it as a bug.

It's difficult to know what was saved after the fact.  Or at least, 
I am finding it difficult to see the logic clearly, in order to produce 
a nice loading function that handles all cases consistently.

either use write mold/only, or don't use load/all.

though, i guess this deserves some more thinking. add it as an issue 
ticket? or as note...

Ahh.. Of course ! Excellent suggestion.

Last time I remember Carl talking about it, he seemed to like the 
idea of being able to save/load a single value easily, so it is perhaps 
difficult to convince him.

.. to change it.

My solution: I used SAVE and SAVE/ALL, and LOAD.

The reason I wanted to use SAVE/ALL is to save none! in a serialised 
way. So I used SAVE/ALL in one place for that, and in another place 
I used SAVE and just made sure I wasn't saving none values, so it 
wasn't a problem.

(I will keep a note to use write mold/only, in case any problems 
crop up.)

Hang on a minute. There is an issue there, surely:

>> save %afile [1]
>> print read %afile
[1]
>> load %afile
== [1]
>> load/all %afile
== [[1]
]

>> save %afile [1 2]
>> print read %afile
1 2
>> load %afile
== [1 2
]
>> load/all %afile
== [1 2
]

LOAD and LOAD/ALL are the same when there are multiple values in 
the block, but different when there is only one value.

(I think I will post a ticket for this...)

LOAD and LOAD/ALL are the same when there are multiple values in 
the block, but different when there is only one value.


Exactly, and I think that is intentional, although weird and probably 
deserving some discussion.

Deserving discussion, yes. Do you have any idea what this difference 
of LOAD/ALL could be used for ? Anyone ?

I suppose that's why I should post a ticket.  :)

I first thought that mold and mold/all would be the mirrored functions 
of load and load/all, but that's not the case?

Umm...

I would say SAVE should mirror WRITE MOLD, and LOAD should be orthogonal 
to that.

(Or at least, that's what you kind of expect.) (and same for SAVE/ALL, 
MOLD/ALL, LOAD/ALL.)

hmm...

load/all is very useful if you are loading a block of values from 
a file, eg.

	1 2 3 "Bob"


and you don't want to code for the case where the file only has one 
value in it. For example, with a file containing a single value in 
it I get:

>> load %a.txt
== 1
>> load/all %a.txt
== [1]


but in all other cases (zero or more than one value), I always get 
a block. I asked about this ages ago and the answer at the time was 
that beginners expected to be able to "load" a value without worrying 
about unwanted block creation (and those who wanted it would use 
load/all).

Yes, it all seemed to make sense at the time SAVE/ALL and LOAD/ALL 
were implemented. I remember the discussions about it. But trying 
to get a consistent method for saving/loading my data the other night 
proved very confusing. I spent a couple of hours testing different 
cases and I still haven't finished thinking about the issue.

I would probably have said that if you are to return something, use 
as few different types as possible, even at the cost of an additional 
function. then a block would be returned regardless of contents

Yes, that's what I had in mind. One way of saving and loading, where 
I can always expect the data in a particular format.

In RebDB I ended up with the following to handle this:

	switch/default length? tables/:table/data [
		0	[write tables/:table/dat-file ""]
		1	[save/all tables/:table/dat-file first tables/:table/data]
	][
		save/all tables/:table/dat-file tables/:table/data
	]

I think, as per Gabriele's suggestion, that can be simplified to:
	write  tables/:table/dat-file  mold/all tables/:table/data
(though it's not exactly the same for the 0 case.)

(The only reason I would want to use SAVE or SAVE/ALL is to avoid 
the slightly longer expression: WRITE MOLD or WRITE MOLD/ALL)

If I have to make a custom function to get consistent behaviour then 
I might as well just use WRITE. :-)

note: save/all and load/all are unrelated, and they were added at 
different times.

also, if you are using load/all, you will need mold/only/all on the 
example above. the /all in mold is unrelated to the /all in load 
and means that all values are serialized.

Yes, I agree that the difference in behavior makes it more painful.

From the Orca channel .. it would be good to set up a way of "voting" 
or other way of determining of what are the priorities for *developers* 
that RT should focus on.

Agreed.

Ah that's very interesting !  I had the strong impression load/all 
and save/all were supposed to be orthogonal, even though I had read 
the function help for each one.

Maybe it is my failing ? Am I so stubborn to continue to try to make 
something work the way I imagined it, instead of considering that 
  maybe it just won't work that way, and to look around for the (what 
should have been) obvious alternatives ?

REBOL/Command 2.5.125.3.1
Copyright 1997-2005 REBOL Technologies

>> write clipboard:// "test"
** Access Error: Invalid port spec: clipboard://
** Near: write clipboard:// "test"
>> read clipboard://
** Access Error: Invalid port spec: clipboard://
** Near: read clipboard://

(That's running on Windows XP Media Center...)

clipboard:// just works with View. Did you try /Command/View ?

Hi, i just posted a new bug on rambo: When calling 'request-file 
and clicking on Cancel, the value returned is %none instead of none 
--> makes more complicated to test the returned value. I tested under 
Windows XP

>> type? request-file
== none!

Well, you are right, from the console, it is ok, but try from a script... 
I have %none and file! as as result

My mistake!!! Sorry!

It works, indeed...

Just send a feedback to RT to ask them to disregard the rambo ticket