World: r3wp

Very, considering 0:0 defaults to hours:minutes -
>> 0:0
== 0:00
>> 0:0.1
== 0:00:00.1

hmm... you can have decimal only for seconds... so i guess rebol 
tries to make sense of 0:0.1 by assuming you meant 0:0:0.1

Maybe it should convert 0:0.1 into 0:0:6 ?  IIRC, Ti calculators 
do that when working with degrees/minutes/seconds...

0:0 is ambiguous. rebol normally takes that as hours:minutes because 
it's the most common case ("it's 10:07 am now"). but when you write 
1:0.7, rebol can see that you probably meant minutes:seconds, so 
it interprets it that way.

if the format was something like 10h12m3s, then you could write 0h0.1m 
and it could be taken as 0:0:6.

anyway, i guess Carl will change it to whatever is the most useful 
for people, so if most people think that 0:0.1 should mean 0:0:6 
he will probably change it.

I'm not sure I'd change the time... the above, as explained by Gabriele 
is what is happening, and its very logical... the dot is consistent. 
and fixes the inconsistency of  0:10:0 and  0:10 being the same thing.

this is a copy of a fresh REBOL interpreter console. Do you think 
it is covered by the documentation, or should I put it to RAMBO?

>> a: make string! 15
== ""
>> insert a "a"
== ""
>> a
== "a"
>> str: make struct! [s [string!]] reduce [a]
>> str/s
== "a"
>> insert/dup tail a "b" 14
== ""
>> a
== "abbbbbbbbbbbbbb"
>> str/s
== "a"
>> recycle
>> str/s
== "¸^D^G^A"

if we wanted to support decimal minutes and hours, I'd suggest that 
time then support using decimal values in all parts of a time like 
so:

0:.1:00
0.2:00
0:0.25:0.124


then we'd be forced to write 0:0:0.124 and the inconsistency would 
disapear.  a part from the above discrepancy in that you don't have 
to supply seconds

Regarding the decimal point in time value issue - my POV is, that 
if users find it natural, then there is no need to change the behaviour

I find the current time is adequate in all scripts I've done so far... 
it just has to be documented... if it currently isn't

I also find that all types should be described within a convertion 
matrix.

row/column of values with equivalent outputs in all other types.

Ladislav, why is the str/a corrupted after a recycle?

my interpretation: a is relocated to be able to grow and STR does 
not "protect" the old memory while still referencing it

I guess I should put it to RAMBO, because it is not covered by the 
STRUCT! documentation

ybut the size is within the 15 bytes you asked at a's outset no?

yes, that is another issue - due to an INSERT quirk you need to allocate 
17 places to make sure 15 elements fit in

(already in RAMBO)

and in any case, the reduced "a" is separate (copied) and in ram 
is probably equivalent to a: make string! 1...  so I guess the real 
bug is that structures do not properly identify regions of ram they 
point to.

<shudders> in my spine... if this is the case !

reduced "a" is not copied...

you can make sure by inserting less elements (say 2)

I have written 4 replies to the above, and everytime, I remember 
another detail about struct which is not obvious... and in all cases, 
I come back to this being a GC bug IMHO.

(replies I never sent... since they didn't identify another possibility 
when the sentence was finished)

aha :-)

(and you are right, the reduced "a" is not copied. if you change 
the first letter, then str/a is also changed)

I looked quickly at the code... and tought I'd seen rejoin somewhere 
;-)

i think it should be considered a bug, the old string should probably 
not be GCed or there should be some way to tell struct! what to do. 
(wasn't there a "save" attribute for structs?)

resize-image: func [
	dest [file!]
	size [pair!]
	file [file!]
	/local im
][	
	im:		load-image file
	save/png 	dest to-image layout [origin 0x0 image (im) (size)]
	im:		none
]

this leaks on 1.3.2.4.2  Is it a bug ?

the GC does not imediately recycle memory.

does this grow to hundreds of MB of RAM if you do this in a loop?

right, Gabriele, the save attribute is mentioned in http://www.rebol.com/docs/library.html#Garbage
, but it doesn't look like related to this situation

we may need a new attribute... i wonder what happens if you set the 
pointer manually though. either way you might get bugs. (though, 
your example is more common than setting the pointer manually, so 
i'd prefer to have that fixed.) we can also just state, that this 
is a documentation problem, and that the programmer should take care 
of keeping the string valid (it's for C interfacing after all, although 
we use structs for other things too)

We need an explicit malloc/free IMHO. maybe with copying the string. 
How  about  a little dll for such stuff?

(I added the [save] attribute note to RAMBO too)

Maxim, yes !

does replacing this:

dest to-image layout [origin 0x0 image (im) (size)]

by this:

dest to-image layout [origin 0x0 image im size]

do anything?

Yes, in the first case, the words IM and SIZE are sure to be evaluated 
outside the layout dialect, whereas in the second case, there is 
a fear that they might be interpreted as dialect words. They could 
be interpreted as dialect words if you added an IM style earlier 
and forgot about it, or the layout dialect was extended with an IM 
word and you didn't notice. In your little example, I see no difference, 
except that the first example could survive changes to the layout 
dialect better. I don't think the layout dialect will change much 
(in View 2.x  versions anyway).  I've been tending to write variables 
in parens, so I need to worry less about the possibility of misinterpretation.

Hmm. If I do this several times then memory is quickly exhausted:

view layout [area mold system]

I observe this slowing down and GROW-FACETS is slowly molding larger 
and larger.

repeat n 1000 [layout [area (s: mold get in svv 'grow-facets)] print 
[n length? s]]

Only now I noticed:
>> -2147483647  + -2147483648
** Math Error: Math or number overflow
** Near: -2147483647 + -2147483648
>> -2147483648  + -2147483648
== 0

I think the second one should also produce an overflow error, since 
a correct result is too large for an integer!

#3520 seems to work OK now (rebol/version == 1.3.2.3.1), so we should 
mark it as solved, shouldn't we?

aha, the add issue above is already in RAMBO as #3839 (by Jaime)

view layout [area mold system]

the text would include this  area the  next time, then include a 
text  which inlcudes the lastlast text and so on?