World: r3wp

Henrik, yes, I agree. I do that all the time.

something like YYYYMMDDHHMMSS would do fine

That's what I do in most cases, but HH needs to be HHH (24-hour time). 
Sometimes I need to have sub-second or added extensions, but that's 
the basic idea.

HHH still mapping to two digits of course, just a format convention 
used elsewhere that I emulate in my FORMAT func.

it should be simple to do as a mezz

I would still like to see a general FORMAT func, though mine hasn't 
generated any excitement in the past.

I have my own date-time function, its pretty complete IMHO.

don't know if it works in R3 though....

	;------------------------------------------------------------
	;- DATE STUFF
	;------------------------------------------------------------
	; use this to prevent having to supply a spec all the time.
    ; the /default option of date-time sets this.
	default-date-time-spec: "YYYY/MM/DD-hh:mm:ss"
	                             
	
	;--------------------
	;-    date-time()
	;--------------------
	date-time: func [
		""
		/with spec ; specify

  /using thedate [string! date! time!] ; specify an explicit date instead 
  of now()
		/default
		/local str date-rules thetime
	][
		vin/tags ["date-time()"] [date-time]
		
		str: copy ""
		
		
		either spec [
			if default [
				default-date-time-spec: spec
			]
		][
			spec: default-date-time-spec
		]
		
		unless thedate [
			thedate: now/precise
		]
		
		
		if thedate/time [
			thetime: thedate/time
		]
		
		filler: complement charset "YMDHhmspP"
		;spec: "YYYY/MM/DD-H^^hmmP"
		;error: spec
		itime: true
		
		unless parse/case spec [
			some [
				here:
				(error: here)
				["YYYY" (append str thedate/year)] | 

    ["YY" (append str copy/part at to-string thedate/year 3 2)] | 
				["MM" (append str zfill thedate/month 2)] |
				["DD" (append str zfill thedate/day 2)] |
				["M" (append str thedate/month)] |
				["D" (append str thedate/day)] |

				["hh" (append str zfill thetime/hour 2)] |
				["mm" (append str zfill thetime/minute 2)] |
				["ss" (append str zfill to-integer thetime/second 2)] |

    ["rrrr" (append str fill/with/right/truncate (remainder thetime/second 
    1 4) "0" )] |
				
				["P" (append str "#@#@#@#")] | 
				["p" (append str "[--:--]@[--:--]")] | 
				["H" (
					itime: remainder thetime/hour 12
					if 0 = itime [ itime: 12]
					append str itime
					itime: either thetime/hour >= 12 ["PM"]["AM"]
					)
				] |
				["h" (append str thetime/hour)] |
				["m" (append str thetime/minute)] |
				["s" (append str to-integer thetime/second)] |
				["r" (append str remainder thetime/second 1)] |
				["^^" copy val skip (append str val)] |
				
				[copy val some filler (append str val)]
				
			]
			(replace str "#@#@#@#" any [to-string itime ""])
			(replace str "[--:--]@[--:--]" lowercase any [to-string itime ""])
		][
			print ["date-time() DATE FORMAT ERROR: " spec]
			print ["  starting at: "  error ]
			print ["  valid so far: " str ]
		]
		vout/tags [date-time]
		str
	]

just remove  vin and  vout functions before running the func.

Regarding lit-words compared to other datatypes:

>> w: first ['a/b]
== 'a/b
>> type? w
== lit-path!		; this returns path! in R2
>> type? :w
== lit-path!

>> w: first ['a]
== 'a
>> type? w
== word!		; Why?
>> type? :w
== lit-word!


There is this double evaluation of words holding lit-words. Why is 
that? As far I can see, only words holding lit-words and functions 
(incl. natives ...) have this difference in behaviour, when refering 
to them as words or get-words. I understand why with functions, but 
why also with lit-words?

Word-active values - another one is the #[unset!] value, which is 
also actively interpreted (triggering an error).

Regading the word-activity of lit-words - it has been quite some 
time when I suggested to Carl to make lit-words "normal" in this 
respect, but he did not accept my proposal, so I expect he found 
it uncomfortable for some reason.

Breaking some scripts maybe?

yes, aggressive evaluation of lit-word types is very annoying, it 
easily provokes molding/loading errors if you're not carefull.

yes, As in I agree with Lad

My func is very similar to yours Max.

>> x: [16#ffffff] 
== [#6#ffffff]

how can i specify an integer! in hex format?

debase/base "ffffff" 16  returns a binary! which i mostly can smear 
on my hair, since most operators just doesn't play nicely w it...

same problem again... i tried to use rebol for byte level processing 
and it's just not suitable for it.. :/

imean not logical neither easy to remember.

would it really be a pain to support the usual 0xff format?... it 
doesn't really clash w anything i think. only numbers can start w 
zero anyway...

R3 is much easier to use with binary than R2.

just use a binary string.

>> to-integer #{ffffffff}
== 4294967295

thx

0xff format
: it does clash with the pair! datatype.

true.. damn :)

on the other hand:
>> to-integer #ffffff              
== 16777215
>> to-integer #{ffffff}
== 16777215

the issues is sort of a syntax sugar, the binary string is the actual 
value in ram.   so you can do things like:

a: #{0f0f0f0f}
b: 3520188881     
>> a and b
== #{01010101}

but you can't with issues:

>> b: #d1d1d1d1
== #d1d1d1d1
>> a and b

** Script error: and does not allow issue! for its value2 argument

but if u have to turn it into integer anyway, then the issue is shorter

the only  real thing to be aware of is that to-binary of an integer 
will give you a 64 bit binary!

>> to-binary 22
== #{0000000000000016}

here is my ObjectID routine a'la mongodb.

wondering how much simpler could it be in r3?...  not that i could 
use r3 any time soon for production stuff, but i would love to, of 
course

  rejoin probe reduce [
    to-hex date-to-epoch now

    enbase/base copy/part checksum/method system/network/host 'md5 3 
    16
    skip to-hex access-os 'pid 4
    skip to-hex random/secure to-integer #ffffff 2
  ]

Geomol, the ticket for the lit-path problem you mentioned is here: 
http://issue.cc/r3/1434

Brian, the ticket you mentioned is not related to the problem Geomol 
mentioned.

Question: how many REBOL users prefer:

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == a/b

versus

a: make object! [b: does ["OK"]]
a/b ; == "OK"
do 'a/b ; == "OK"

?

I prefer the latter

(seeing it as more convenient)

latter

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!

versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

I prefer the latter again

The latters seems more logical to me in both cases.

The latters seems ok to me. But what if w is a word holding 'b or 
'a/b, as I was testing, in relation to the object a? This is what 
I get:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script Error: Invalid path value: b	; To me, that error is wrong 
worded, it should show 'b.
>> in a :w
== 'b		; Confused, as a doesn't hold any 'b
>> do in a :w
== 'b		; Why?
>> type? do in a :w
== lit-word!

Same in R3:
>> w: first ['b]
== 'b
>> type? :w
== lit-word!
>> a/:w

** Script error: cannot access :w in path a/:w		; Not sure about 
this error. Could be better, I think.
>> in a :w
== 'b			; ?
>> do in a :w
== b			; ??
>> type? do in a :w
== word!

And now the 'a/b:

In R2:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== "OK"
>> do :w
== 'a/b

In R3:
>> a: make object! [b: does ["OK"]]
>> w: first ['a/b]
== 'a/b
>> do w
== 'a/b
>> do :w
== 'a/b

wrt:

And, how many users prefer:

a: make object! [b: does ["OK"]]
type? do in a 'b ; == function!
versus

a: make object! [b: does ["OK"]]
type? do in a 'b ; == string!

============================

the first should be supported via the 'GET word, so I'd say the later 
is better, otherwise, there is no point with 'GET. 

basically, this was perfect in R2, why did it change in R3?

seems like a bug

It changed because functions were getting executed when you were 
doing a word referring to a function, rather than doing the function 
itself.

Ladislav, that ticket was related because it explained that lit-words 
were active values and that the behavior was intentional. This can 
be changed if we decide differently, but it isn't currently a bug, 
it's intentional.

I understand that the change was intended, but currently, all the 
respondents prefer the original behaviour.

And no wonder they do. If a user calls the DO function, then it is 
expectable that functions, etc. get evaluated.

Yes. But that is doing the *function*, not doing a word that refers 
to the function.

It's the difference between a: :print and a: 'print.

As said, all the respondents above prefer the function to be evaluated 
when doing a word that refers to the function. The only way how you 
can influence it would be if you said you preferred the current behaviour 
as implemented in R3. Do you?

For that, absolutely. For the lit-word/lit-path thing, no.

I hope we get more answers, since it is weekend now.