World: r3wp

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.

What is it that prevents this from working:

a: reduce [make object! [
        t: 3
        g: 5
    ] make object! [
        h: 12
        u: 15
    ]]

c: 2

a/:c/h
== 12 ; good

d: 'a/:c

d/h
== error!


It would be so wonderful to use only paths here instead of relying 
on GET IN GET IN GET IN...

Notice that I use a lit-path. I don't want evaluation to occur until 
the final moment.

>> p: 'a/b/c/d
== a/b/c/d
>> pick p 2
== b
>> p/2 
== b
>> p/c
== d
>> select p 'c
== d

Well, that's the inverse of what I would like to see: Path building 
using refinements only.

You can do it with file!:

a: %/c

a/somewhere
== %/c/somewhere

>> b: a/somewhere/else
== %/c/somewhere/else
>> b/subdir
== %/c/somewhere/else/subdir

etc...

When you write

d: 'a/:c


d become a path! datatype, and it's not connected to your block, 
a, in any way. If you wanna expand the path, you can do something 
like:

>> join d 'h
== a/:c/h

Is that what you wanna happen?

You can evaluate it with:

>> do join d 'h
== 12

It seems path! doesn't work like file! but more like block!, which 
is also what Gabriele pointed out, I think.

>> d/a
== :c


And that is also, why d/h fails. h is not found in the d path anywhere.