World: r3wp

No really.....There is Puzzles and Puzzle Answers here, but they 
aren't very web-public.

There have been some nice puzzles on the mailing list:
   http://www.rebol.org/ml-topic-detail.r?l=p&topic=puzzle

The big problem with most code golf puzzles is they only ever play 
one one......It'd be better to have puzzles that are rolled out in 
stages: each stage being a modification to the previous puzzle spec. 
that way, generality and flexibility would be rewarded.

Yeah, usually the focus lies on code size (who writes the tiniest 
solution) which isn't always the best solution to a problem. Well, 
there aren't "best solutions" anyhow because it always depends on 
what you need (speed/stability/security/readability/etc.), often 
enough you need to make a tradeoff there so you can't really say 
one is best. But your idea would be a good start to improve code 
golfing. Now you just need to make a nice website that I can visit 
;)

...switching to [All] for the code golf discussion.....

Is there a simple way to convert a number to its binary representation?

This is what I want, but without the limit of 255 that char! types 
have:
>> enbase/base to-binary to-char 7 2
== "00000111"

This does it, though there may be faster native ways for the specific 
case of decimal-->binary@
   http://www.rebol.org/documentation.r?script=base-convert.r

found a bug in 'FOR when used in series... it becomes an endless 
loop..

>> s: "12345"
== "12345"
>> for c s tail s 1 [probe c]
12345
2345
345
45
5
; <----- it should stop here 




....

Izkata, it's a little tricky with R2, but this works for any integer:

>> enbase/base debase/base to-hex 546 16 2
== "00000000000000000000001000100010"

Thanks Sunanda, Steeve - I had a loop to generate it manually, but 
an enbase/debase-based solution is far faster  ;)

Izkata, there's a library of bit operations with several useful functions, 
also one that can do, what you need:

>> do http://www.fys.ku.dk/~niclasen/rebol/libs/bit.r
>> enbit 546
== "00000000000000000000001000100010"

It's BSD license, so you can use it in your work.

Max, I think that has been reported many times, eg. http://www.rebol.net/cgi-bin/rambo.r?id=4121&

Normal zero padding of decimals:

>> to-string .48
== "0.48"

Is it possible do to something like this:

>> magic-function .48
== ".48"


This would help in cases where you need to build a query string to 
search for plain text.

maybe something like:

magic-function: func [num [number!] /local result] [
    result: form num
    if #"0" = first result [remove result]
    result
]

you may want to handle cases like "0" specially, depending on what 
your exact needs are.

hmm... thanks. it seems that the problem is a little different than 
that, however.


I'm just loading a string: "this-column contains 001" which is loaded 
incorrectly to [this-column contains 1], so I have to do this differently 
in the loading phase.

Ah, the user should just use quotes.

I've forgotten .. is there a sort that sorts on the basis of the 
length of strings?

>> sort/compare ["1" "22" "333"] func [a b] [greater? length? :a 
length? :b]
== ["333" "22" "1"]

Actually, to make that a stable sort it should be greater-or-equal? 
instead.

cool ...

to make that a stable sort it needs to return -1, 0 or 1, not true 
or false. sign? on the difference would do the trick.

reboltutorial claims, that copying files larger than 1GB fails with 
R2? Anyone having similar experience? http://reboltutorial.com/blog/do-you-need-to-copy-big-files/

Perhaps he means 2GB, which is a known consequence of using 32bit 
signed integers for file indexes.

Fixed in R3, due to the switch to 64bit signed integers.

is it possible to cascade error throws through several functions?

never mind, I did something wrong. got it now.

Ubuntu 9.04; rebcore (2.7.6) can     devmem: open/read/binary %/dev/mem
rebview hangs.


Do I need to care?   I don't need View for this little informational 
gathering app, but ...


We are planning for an embedded system BIOS tweak so we can label 
an Asset Tag in the SMBIOS;  REBOL won the race getting the information 
decoded for everyone to see; beat Python development by a few minutes 
(in a highly uncompetitive sharing information back and forth development 
"race")

try /direct or /seek

/seek does not work

are you sure View didn't just pop up its security requestor behind 
the terminal so you couldn't see it?

Has anyone got a routine that calcuates the difference between two 
dates as an age in a format appropriate to that age.

So, age is displayed as a days for under a week, in weeks for under 
3 months, and as months upto 3 years, and then as years/months after 
that.

I've used 'case for that in the past, rough example:

	age: case [
		1 > diff: d2 - d1 ["less than a day"]
		7 > diff [reform [diff "days"]]
		... etc ...
	]

That way, you can tune it as fine as you need it.

I ended up using case .. and just straight subtraction of years etc 
instead of using 'difference which can sometimes lead to numeric 
overflow.

Something similar I've used:
   DayConv: func [Days /local Ret Tip][
      Ret: copy {}
      Tip: false
      foreach Val [[365 y] [31 m] [7 w] [1 d]] [
         if Days >= Val/1 [
            append Ret join to-integer divide Days Val/1 Val/2
            Days: mod Days Val/1
            if Tip [return Ret]
            Tip: true
         ]
      ]
      return Ret
   ]


'Tip was to make it stop at just two time-indicators (So 2 months, 
1 week, and 3 days would display just as 2m1w, omitting the days, 
for example)

(Messy looking implementation is due to being reeaally tired at the 
time, just never felt like fixing it up...)

Interesting.

I thought R3 has not support task! yet. Why does the following code 
work?

do make task! [ forever [ print now wait 1 ] ]

It has support for tasks, but the method for tasking on a low level 
is supposedly not the correct one, given that R3 could be running 
on an OS kernel without threads.

I repost here: task is a discovery for me. I am interested to know 
if  it will be developed. It might be an important feature for R3.

oops, now I posted the response in the wrong group. :-)

ok, saw it, thanks

oops, I did it again:


The problem is that OS kernels do it differently, depending on their 
capabilities, so the current threading model used to create tasks 
may have to go.

yes, its a real challenge ...

Fortunately Carl has a little bit of experience with multitasking, 
so I'm sure a good model will come up. :-)

Of course ! He certainly will find a clever approach !

Graham, is it important to take into account leap years in your solution?

No, just accurate within a couple of days.