World: r3wp

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

deleted

Interesting memory-bug

filet!: context [filet: none]
spec: [filet: 1]
fil: make filet! spec
recycle probe stats
repeat i 10000[
 fil: make make filet! spec fil
]
recycle probe stats
repeat i 10000[
 fil: make make filet! spec third fil
]
recycle probe stats

make object! object! does not release.
make object third object! does.
(thats like make object! block!

linux 1.3.2

Is this repeatable, and clear enough for rambo?

Do you want me to test in OSX?

Good idea.

I don't understand the error. Do you want the output I am getting?

Yes.

Its three memory-stats (after recycle).

all should be same, or similar low.

the second is a lot higher, because the objects from the first loop 
are not relased.

Well after the make I get errors.

The data is:
run1: 1716394
run2: 3396726
run3: 1717126

Thanks. That confirms the bug.

Niow i need a good description..

I think the description is precise enough. make object! object! Not 
releaseing is bad. (Dangling pointers)

Good catch.

hmm, but memory is released at the next non object-object make, no?

Seems so. But i had a memory-leak by this. Seems making objects is 
not that common when the gui is set up. Then extend incomming objects 
with a default one, in that case it drove me mad.

Anyone had problems with 'switch and datatype! I've reduced the problem 
down to:

t: func [v] [
	select [
		#[datatype! integer!]	["A"]
		#[datatype! decimal!]	["B"]
		#[datatype! block!]	["C"]
	] type? v
]

>> t 1
== ["A"]
>> t 1.0
== ["B"]
>> t []
== decimal!

Unless there's an obvious explanation, I'll RAMBO it.

the explanation is this:

>> find [1 a []] block!
== [[]]
>> find [1 a []] word!
== [a []]
>> find [1 a []] integer!
== [1 a []]

so, use type?/word