World: r3wp

James,
Create some nested objects:


 objects: context [objs: reduce [reduce [context [name: "hi"]] reduce 
 [context [name: "there"]]]]
	
Save them in a binary (should be just like saving to file):

	bin: make binary! ""
	
	save/all bin objects
	
Load back from the binary (should be like loading from file):
	
	objects2: do as-string load bin
	
Test to see if the nested objects were created properly:	
	
	>> type? objects2/objs/1/1
	== object!

	>> probe objects2/objs/1/1
	make object! [
		name: "hi"
	]

I need to be able to explicitly determine if something some functions 
return false as their value.  I wrote a quick function to do this 
but shouldn't we already have something that does this?

My function is:


false?: func [val][either all [logic? val not val][return yes][return 
no]]

That would be truefalse  :)   Sorry, couldn't resist.  But, yes, 
REBOL is very tri-state with the t f none thing. And zero being true, 
as a forther still rubs wrong, but that chaffing is almost over and 
done with.  Plus RebGUI now supports bi-state options, so life is 
good(er).  :)

no that function wouldn't tell you if something is true.

true? func [val][either all [logic? val val][yes][no]]

Sorry, I meant   a "true" false.

yes

I investigating the deets, but you might get away with strict-equal? 
   res == false; need to test.

what is the difference again between strict-equal? and equal?

strict-equal? compares value and type, and then there is identical 
testing with =?   where

a: "abc"  b: "abc"     a =? b  is false   c: a   a =? c  is true 
(pretty much has to occupy the same ram)

Oh just in case   1 = 1.0 is true   1 == 1.0 is not.

that is what I thought btiffin - when you mentioned using strict-equal? 
you have me confused.  How did you see it being used in a true false 
function?

Instead of    if false? expression [ ]   you might get away with 
 if strict-equal? false expression [ ]   and skip writing the false? 
 func.

All you should ever need is 
	= false

Good point.  Paul ... What Anton said.  ;)

Yeah I don't see a need for a true function only a false function.

Anyone know of a bug in REBOL where the word "end" shows up in a 
list! of values?  I have got this weird problem where the word "end" 
shows up in what should be a list! block of nothing but integers 
but instead I have integers and a few references of the word "end" 
without the string as it is not a string datatype.  If I do a foreach 
and attempt to step through each item it crashes on that entry.  
I can't determine what datatype it is.  I looked at my code and nothing 
in my code or the data it handles contains the word "end".

I did some more research and it appears that the "end" I seen is 
a datatype.  I didn't even know there was an end! datatype.

here is what the list block looks like for example:


== make list! [1 4 5 end unset 6 7 8 9 10 11 12 13 14 15 16 17 18 
19]

except it is a lot longer


I'm not sure why I'm getting the unset! or the end! datatypes at 
this point.  I only use insert to add to this list and all the values 
being inserted should be integer datatypes.

You could test, if what you're inserting actual is an integer. Something 
like:

if integer! <> type? value-to-insert [print ["Not an integer:" value-to-insert]]

I actually did that and it got no errors which really has me a bit 
stumped.

That's weird. Could you test, if the just inserted value in the block 
is not integer!? Like:
if integer! <> type? first blk [print "something"]

And do that for every insert.

Well that is actually how I did my test.  I had the following in 
the subject area of the problem:


if not integer? record-number: first to-block raw-record [print record-number]

Problem is that it never printed anything

Maybe someone can tell me what the end! datatype is used for and 
that might help find the problem

Gonna go see if the core manual refers to the end! datatype.

end! is the datatype used to specify ends of blocks, if I remember 
correctly.

I didn't even know there was one.  In what way would it be used?

Yes, "internal marker for end of block"

It's an internal datatype.

My guess is, that somehow your input is an empty block (or the end 
marker) in some situations.

Hmm... ok then that might explain something.   I recall a copy function 
I had that caused the interal code of REBOL to spill out so I assume 
it has something to do with my port handling as that copy function 
I had did similiar.

So it might be in the area where I have a copy/part on file data 
which would result in a block.

Geomol where did you get that information as it being an internal 
marker for end of block?

R3 datatypes: http://www.rebol.net/wiki/Datatypes

Many are the same in R2.

ok thanks.

I think, end! was hidden in R2 and will be exposed in R3.

I suppose so.  Maybe Gabriele will be lurking and can provide more 
info.

I suppose the end! datatype isn't really interal code as I understood 
internal code in REBOL.

It appears possibly to do with the sort function

You can see the problem here - as it only seems to appear when the 
sort function is introduced:

>> head dbrecs

== make list! [1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 
22 23 24 25 26 27 28 29 30
 31 32 33 34 35 36 37 38 39 40 41 42 43 ...
>> length? head dbrecs
== 10098
>> dbrecs
== make list! []
>> find head dbrecs end!
== none
>> sort head dbrecs

== make list! [1 4 5 end unset 6 7 8 9 10 11 12 13 14 15 16 17 18 
19 20 21 22 23 24 25 26 2
7 28 29 30 31 32 33 34 35 36 37 38 39 40...
>> find head dbrecs end!

== make list! [end unset 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 
21 22 23 24 25 26 27 28 2
9 30 31 32 33 34 35 36 37 38 39 40 41 42...

What do you see, if you do a
>> ? system/version

>> system/version
== 2.7.5.3.1

Have you checked the bug database, if it's a known issue?
http://www.rebol.net/cgi-bin/rambo.r

If it is the sort function then that would explain why putting the 
checks in my script didn't catch it because I was only using the 
sort in the console to test some other ideas.

(Just click the link, I gave, to run the bug database in your browser.)

I just searched it and didn't find mention of this problem.

This is related, I think: http://www.rebol.net/cgi-bin/rambo.r?id=3761&

Possibly.