World: r3wp

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

Is this intended?
>> all [true true true]
== true
>> all [true true false]
== none
>> all [false false false]
== none

Why don't I get back FALSE in the 2nd and 3rd case?

hmm, strange, it should be false imo :-)

RAMBO it, please, they will dismiss it at max, if it is not a bug, 
but I think it is ...

Ok, submitted.

not sure if it can be said to be a bug, but i see the reasoning about 
wanting false there, so maybe it can be changed.

Thanks Gabriele, *so* obvious in hindsight (my workaround was to 
move the block! condition to the top of the list, but type?/word 
is a good refinement to remember!)

If all [true true false] should return false, all [true true none] 
should return false or none ?

same question for any : any [false false false]  should return false 
or none ?

any is more difficult to change it that case. any "returns the first 
value that is not none or false". there is no such value in that 
block - so what should it do?

should it return the last value anyway?

For me any and all should never return false. That's my opinion.

The problem I see is that I often use ANY and ALL as a condition 
and it it returns NONE I can't do anything with it. IMO this pattern 
should be possible:
	either ANY [...][yes][no]

DESCRIPTION:

     Shortcut AND. Evaluates and returns at the first FALSE or NONE.
     ALL is a native value.

How about returning than either FALSE or NONE which every was hit? 
That makes sense to me. So I can ensure that my app returns FALSE 
and that this value is returned. But now I return FALSE and get back 
NONE.

If you want to return FALSE instead of NONE, use FOUND?

>> found? any [true true false]
== true
>> found? all [true true false]
== false

:-)

I don't see the problem with either any [...][yes][no] :
>> either ANY [true false]["yes"]["no"]
== "yes"
>> either ANY [false false]["yes"]["no"]
== "no"

robert: either takes any value, false or none are "false", anything 
else is "true".

also, yes, found? is the default way to make a value into a logic! 
. not is also a nice way to do that, when you can/need to reverse 
the logic.

found? is the most elegant one so far. But the word's meaning isn't 
that good in such a case. I didn't searched anything...

Using EITHER and hence mapping the result on TRUE or FALSE is IMO 
a hack. It works (that's how I do it) but it's not logical. Maybe 
a refinment for ANY and ALL makes sense.
	ALL/logical and ANY/logical

I can see situations where it's very handy that ANY will return the 
result of some actions and not only TRUE and FALSE.

You can use TO LOGIC! directly, or write a mezz with a better name, 
that wraps it.

Something like RESULT? maybe, and it could also handle unset values 
if that's needed.

Robert: I think, ANY and ALL are meant for little bit 'wilder' things 
than returning TRUE or FALSE. Remember they return *AT* first false 
or none, it's not that they should return FALSE - which is important

simple example
>> a: 5
== 5
>> all [a < 3 a: a + 1]
== none
>> a
== 5
>> a: 1
== 1
>> all [a < 3 a: a + 1]
== 2
>> a
== 2