World: r3wp

Ladislav, does not POKE DATA parameter already accept argument of 
any type ?  ( I checked only Rebol3 alpha 76 (not most recent) and 
Rebol2.7.7).

Steeve, 

What might be interesting (and possibly even ... useful) is to generalise 
to be able to swap (rotate) any number of sub-series, eg.
for three sub-series in a series [... AAA ... BBBB ... CC ...]
AAA moves to where BBBB is currently,
BBBB moves to where CC is currently, and finally
CC moves to where AAA is currently.

(but not tonight, for me..)

Should not be that hard with a recursive approach

(I did not say that I will do it)

REBOL 3.0 A110 2-Nov-2010/3:56:20

>> source poke
poke: make action! [[

    {Returns value after changing its data at the given index. (Modifies)}
    value [series! port! map! gob! bitset!]
    index {Index offset, symbol, or other value to use as index}
    data "New value"
]]
>> poke [1] 1 #[unset!]
** Script error: poke does not allow unset! for its data argument

So, I was curious, what the user preferences are. Current poll state:


any-type! DATA : any DATA = 1:0 (counting just myself, no other response 
obtained)

Normally I would like to limit the occasions where an unset! can 
get through without errors triggered (those errors are the whole 
point to the unset! type), but in this case the other series manipulation 
functions accept any-type!, so consistency wins here. +1 any-type!.

anyone did anything with Rebol and JVM (Java) integr/cooper-ation. 
I need functionality of some big java lib ("server side") in rebol. 
What would you do or use?

add a port to communicate with the java app?

Ladislav, oh I see. Yep, +1 any-type!

Steeve, would need to convert to iterative to stay memory safe.

>> blk: copy [1]
== [1]
>> blk/1: #[unset!]
** Script error: blk/1: needs a value
>> poke blk 1 #[unset!]
** Script error: poke does not allow unset! for its data argument
>> head insert blk #[unset!]
== [unset! 1]

What other series funcs are you think of Brian?

If any-type! is allowed, should the behavior be like INSERT?

I'm not saying it's a useless requirement, but what is purpose to 
have #[unset!] in a serie, instead of anything else working, for 
instance, #[none!].
Just asking...

(#[none], not #[none!])

I was thinking of APPEND and CHANGE too - they both also allow any-type!.

what is purpose to have #[unset!] in a serie

 - well, it was not me who 'introduced' #[unset!] to Rebol series.

Steeve, triggering an error is the point of unset!. The none! type 
is for when non-values aren't an error.

nevertheless, since:


change at [1 2 3] 2 #[unset!] works, my opinion is, that poke [1 
2 3] 2 #[unset!] should work as well

In my opinion, there are certain simple and useful states, that we 
can choose from. One of the states might be, that #[unset!] is not 
a Rebol value at all. That approach was chosen for the #[end!] value 
as far as I can tell. Moreover, that approach was chosen even for 
#[unset!] for R1, but, for some reason, Carl declined from it, choosing 
a different approach.

So, instead of the R1 approach, Carl 'introduced' #[unset!] into:

*results of Rebol expressions
*values you can set Rebol words to using SET/ANY
*values you can "store" to and "retrieve" from Rebol series

, etc.

In my opinion, to 'allow' INSERT, APPEND and CHANGE handle #[unset!] 
makes 'disallowing' POKE to do the same uncomfortable.

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.