World: r3wp

That is why allowing it for POKE is a good idea.

This came up in a CC ticket for another series function once, and 
the reasons for the choice made there apply here as well. There are 
two main reasons that you would want series functions to be able 
to handle unset!:

- This gives the error context, so when it is triggered you can get 
an idea of what the conditions were that caused it.

- Your code might be structured to handle errors on output from the 
series instead of input to it.

Does R2/Forward contain fixes to TO-LOCAL-FILE? There are some rather 
significant differences in functionality between the R2 and R3 version.

As a rule, R2/Forward hasn't had any changes to native functions 
in R2, mostly for performance and compatibility reasons. It is intended 
to have an extended version later that attempts to backport as many 
native changes as possible, but that won't be the default because 
it would break a lot of the same R2 code that R3 breaks.

However, TO-LOCAL-FILE? and TO-REBOL-FILE? aren't really that fundamental, 
and were originally written in REBOL, so it might be OK to change 
them if it can be done without breaking code. What are the specific 
differences you have found between the R3 and R2 versions?

Got it: the /full option.

R2:

>> to-local-file to-file "/test"
== "t:\st"

R3:

>> to-local-file to-file "/test"
== "\\test"

Oh, nice. Yes, that's worth doing, and fits within the rules. For 
that matter, it's worth adding to the R2 bug list.

I agree on POKE supporting unset! to match CHANGE and INSERT.

Henrik, that fix is scheduled for 2.7.8, but not the /full option.

yay... the fact that we couldn't support writing out UNC paths easily 
has bitten me at a high-profile client in the past :-)

nice to have that fixed.

It was scheduled for 2.7.8 but didn't make the deadline. So now it's 
still pending.

I'm able to consistently produce this in 2.7.7:

---------------------------
REBOL Error
---------------------------
REBOL Internal Error: Invalid series width 1 was 16 (type 39)

Program terminated abnormally.
This should never happen.
Contact www.REBOL.com with details.
---------------------------
OK   
---------------------------


Will need to dig a little. Not sure if it's an encryption part, debase 
part or what it is yet, but it occurs, when loading enbased, encrypted 
data.

ok.... it apparently happens when LOADing certain DECLOAKed data, 
but only under specific circumstances.

Does it happen in 2.7.8?

I am unable to test this, as 2.7.7 is heavily integrated into RM 
Asset's build system for the NLPP program

one factor that makes me think this is deep, is because it doesn't 
occur until the main window has been opened.

That's deep even by native bug standards.

I saved the offending data to disk, but am not sure how helpful that 
is.

You can go through the steps with the data manually, and with different 
R2 versions. Anything unexpected will be a clue.

true, however at this time, it's going to be very time consuming.

It shouldn't be to hard to use 2.7.8 in our setup and switch back 
and forth between both. We can take a look at it tomorrow.

I'm still stuck by binding thing sometimes !

Given the following code, how can I load the object and get back 
the correct binding ?

Rebol []

make-obj: func [
	"Créé un objet en sauvant son nom dedans."
	'name "Nom de l'objet à créer."
	obj "Objet de base à instancier."
	spec "extension de l'objet de base."
] [

 set name make obj append reduce [to-set-word 'obj-name to-string 
 name] spec
]


save-obj: func [
	"Sauvegarde un objet selon son propre nom."
	'obj "Objet à sauvegarder."
	/local name
] [

 name: any [all [word? obj  object? get obj  get in get obj 'obj-name] 
 join "objet" random 10000]
	save/all to-file join name ".r" get obj
]

load-obj: func [

 "Recharge un objet et l'intancie selon son propre nom s'il en a un."
	file "Nom du fichier à charger."
	/local obj
] [
	if exists? file [
		obj: load file
		probe bind next first obj obj
		probe get in obj 'list
		all [in obj 'obj-name  set to-word get in obj 'obj-name obj]
	]
	obj
]

task: make object! [
  list: copy []
  add: funct [t [block!]] [
    append list t
  ]
  save: does [
    save-obj self
  ]
  run: does [
    do list
  ]  
]

make-obj task1 task []
task1/add [a: 0 a: a + 1]
task1/add [print a]
task1/run
task1/save

task1: none

load-obj %task1.r
task1/run

Try by replacing SAVE/ALL by SAVE and LOAD FILE by DO LOAD FILE.

OK, thanks : it works.
Now : why does save/all not work ?

In other words, how to get back a functionnal object from a serialized 
form (save/all) ?

I'm not sure it's possible because the literal form for object's 
functions (#[function! ...]) make them evaluated before the object, 
so the binding process might fail in that case.

Using SAVE ensures that you have a list of symbols in unevaluated 
form more suitable for object reconstruction and proper binding.

Anyway, binding information is lost during serialization (MOLD or 
MOLD/ALL), so if you want to get back bindings from serialized code, 
you need to manually ensure that the binding will be reconstructed 
as expected. That's achieved easily in your simple example using 
the SAVE / DO combination, but it can get much more complex in other 
cases and could require a lot of additional code.

So to resume, serialized form is not suitable for object!.

do load
 does not work with the serialized form (I tried it)?

sorryn o "?" but DOT

Last question, why can't the binding of the save/all form be restored 
by the manual 'bind ?

do load

 does not work with the serialized form (I tried it)?" I'm not sure 
 to understand what you mean there. SAVE/ALL uses MOLD/ALL to serialize 
 values, so binding information is not preserved. If you want to restore 
 correct binding in a object! serialized using /ALL format, you need 
 to write some code to walk through object's functions body blocks 
 and bind object's words explicitely using BIND.

This would be similar to what MAKE does on an object's spec block! 
but a bit smarter as you need to dive into function! values (MAKE 
doesn't do that AFAICT). You need to see the distinction between 
"unevaluated code" (source form) and "evaluated code" (reduced form) 
to get a clear picture on this issue.

Nested bindings are faked using a procedural process in REBOL. Serialized 
syntax is declarative, and there isn't a reference to the bindings 
in that syntax. It would be possible to make a serialized syntax 
that includes binding references, and the proposal to do that is 
called Rebin.

Is there sort function (comparator) for no sorting, so this will 
be TRUE ?

block = sort/compare copy block :comparator

The only one I can think of only works if the entries in _block_ 
are unique:

     sort/compare copy block func [a b][return (index? find block a) < 
     index? find block b]

This may work too:
  sort/compare/skip block func [a b][return true] length? block

sort/compare [t r y t h 1 s] func [a b] [0]

If you want SORT to be stable, return -1, 0, 1 instead of just TRUE 
and FALSE.

Doesn't seem to work in R3.

>> sort/compare [t r y t h 1 s] func [a b] [0]
== [r y t h 1 s t]

It's not supposed to work in R3.

R3 currently has no stable sort. At least not on all platforms.

Ah, ok.

(Which is http://issue.cc/r3/1152.)

This does a null sort in R2 and R3.....but it requires the func to 
know the name of the block being sorted:

    sort/compare block func [a b /local c] [c: [] if 0 = length? c [append 
    c block]  block: copy c 0]

sort is mostly useless anyway - it will not work with unicoded alphabets 
anyway, no?