World: r3wp

the issue probably is that if you did

date/hours: 50


its a logic error.  so how is it resolved? ... an error... add two 
days, two hours?

You can alter the day, month, year and zone ... just not the time

there is a bug in any case!!!  

>> t: 50:00
== 50:00

>> d: now
== 23-Oct-2009/2:40:09-4:00

>> d/time: t
== 50:00

>> d
== 25-Oct-2009/2:00-4:00

here it seems it added two days ... but didn't add the 2 extra hours 
!!

so, I guess the handling wasn't speicifically designed by the date 
object, and is simply a side effect of its internals.

(thats in R2 A90)

actually all i wanted to do was to round the time off to remove all 
the seconds

*R3*

but I have to extract the time, round it off and then set the date 
time value back :(

put it into curecode and add the above bug within the report... it 
will add to its relevance (and priority) within the post.

I don't hve the link close to hand ...

google rebol curecode... first link

Not for me .. I get vid extension kit!

nope .. not in google on those parameters

Let me try google.ca

I get the rebol doc base page for R3

Hmm... perhaps I need to remove "google" from the search!!

hahahahha

I pass ...

hum... that can take different meanings... hehe

  http://curecode.org/rebol3/

I don't wish to create an account ...

Then you'll only ever see other people's bugs fixed :)

I'm not using R3 at present

I'm creating a ticket... I also found a rebol crash!  (even in A92)

>> d: now
>> d/6: 5
>> print d

**CRASH**

curecode is also for wishes... so if you want R3 to be what you want 
it to, you have to speak... and curecode is that place... many blog 
posts where originated from good curecode reports/suggestions.

ticket 1292

Actually some bugs are fixed the same day as they are posted.

The entire date handling system in R3 was rewritten a while ago, 
AFAIK.

And I have had one date related issue fixed.

(going to R3)

Graham, the explanation is that dates are not really mutable (or 
more precisely, are always passed by value and not reference). the 
date/anything: is a hack. (I sometimes think that, no matter how 
useful they are, those hacks only hurt a language in the end...)

That makes sense.

But pragmatism usually outweighs purity in the real world :)

how about:

to-object now
= make object! [
	year: 2009
	month: 10
	etc...
]

I'm going to write it up as a wish to be implemented after the crash 
is fixed :-)

REDUCE can be used to reduce blocks, and by that evaluate parens 
within blocks:

>> reduce [(1 + 2)]
== [3]

But REDUCE won't evaluate parens themselves:

>> reduce first [(1 + 2)]
== (1 + 2)

Is that a bug? (Same in R3.)

I also find this a bit strange:

>> do first [(1 + 2)]
== 3
>> do to paren! "1 + 2"
** Script Error: + word has no context
** Near: 1 + 2

I see no bugs.

REDUCE,  acts on blocks, nothing else.


TO-PAREN and TO-BLOCK on strings, act like LOAD, but don't bound 
the result in any context.


Both of them have well known behavior. It's perhaps a lack of good 
documentation but no bugs.

I'm probably wondering, because parens works in many ways the same 
as blocks, but not when reduced. The same can be said about paths.

and

Parens and paths are default being evaluated (by the scanner/lexical 
analysis), blocks are not. And when you reduce blocks, parens and 
paths within the block are being evaluated. On the other hand reducing 
parens and paths won't evaluate them. I tend to agree, it's not bugs 
but lack of documentation.

What's a quick method to find duplicates in a series?

kind of the opposite of UNIQUE

given 'a' is a block of numbers:
b: unique a foreach c b [remove a c] probe a

not pretty but works

>> a: [a a a b b c d e e] foreach x b: unique a [remove find a x] 
unique a
== [a b e]

It only removes the first of each from a - any additional ones are 
left behind. The last unique gets rid of the remaining dups.

Your version won't work since REMOVE only takes one parameter, not 
two.

I was going to add that additional unique at the end also but it 
helps for me to not only know which are duplicated but how many times...

Thanks Brian

>> a: [a a a b b c d e e] remove-each x b: unique a [not find find/tail 
a x x] b
== [a b e]
Doesn't modify a :)

that's handy

Should be faster too.

If a is sorted: