r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Gabriele
8-Feb-2006
[1566x2]
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.
Carl
8-Feb-2006
[1568]
Yes, I agree that the difference in behavior makes it more painful.
Graham
8-Feb-2006
[1569]
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.
[unknown: 9]
8-Feb-2006
[1570]
Agreed.
Anton
9-Feb-2006
[1571x2]
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 ?
Ammon
13-Feb-2006
[1573x2]
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...)
BrianH
14-Feb-2006
[1575]
clipboard:// just works with View. Did you try /Command/View ?
François
20-Feb-2006
[1576]
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
Graham
20-Feb-2006
[1577]
>> type? request-file
== none!
François
20-Feb-2006
[1578x4]
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
Gabriele
20-Feb-2006
[1582]
deleted
Volker
7-Mar-2006
[1583x5]
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?
JaimeVargas
7-Mar-2006
[1588]
Do you want me to test in OSX?
Volker
7-Mar-2006
[1589]
Good idea.
JaimeVargas
7-Mar-2006
[1590]
I don't understand the error. Do you want the output I am getting?
Volker
7-Mar-2006
[1591x4]
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.
JaimeVargas
7-Mar-2006
[1595x2]
Well after the make I get errors.
The data is:
run1: 1716394
run2: 3396726
run3: 1717126
Volker
7-Mar-2006
[1597x2]
Thanks. That confirms the bug.
Niow i need a good description..
JaimeVargas
7-Mar-2006
[1599x2]
I think the description is precise enough. make object! object! Not 
releaseing is bad. (Dangling pointers)
Good catch.
Gabriele
8-Mar-2006
[1601]
hmm, but memory is released at the next non object-object make, no?
Volker
8-Mar-2006
[1602]
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.
Ashley
13-Mar-2006
[1603]
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.
Gabriele
14-Mar-2006
[1604x3]
the explanation is this:
>> find [1 a []] block!
== [[]]
>> find [1 a []] word!
== [a []]
>> find [1 a []] integer!
== [1 a []]
so, use type?/word
Robert
14-Mar-2006
[1607x2]
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?
Pekr
14-Mar-2006
[1609x2]
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 ...
Robert
14-Mar-2006
[1611]
Ok, submitted.
Gabriele
14-Mar-2006
[1612]
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.
Ashley
14-Mar-2006
[1613]
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!)
Coccinelle
15-Mar-2006
[1614x2]
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 ?