r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Izkata
30-Oct-2009
[14956]
Thanks Sunanda, Steeve - I had a loop to generate it manually, but 
an enbase/debase-based solution is far faster  ;)
Geomol
30-Oct-2009
[14957]
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.
Gabriele
31-Oct-2009
[14958]
Max, I think that has been reported many times, eg. http://www.rebol.net/cgi-bin/rambo.r?id=4121&
Henrik
2-Nov-2009
[14959]
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.
Gabriele
2-Nov-2009
[14960x2]
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.
Henrik
2-Nov-2009
[14962x2]
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.
Graham
3-Nov-2009
[14964]
I've forgotten .. is there a sort that sorts on the basis of the 
length of strings?
BrianH
4-Nov-2009
[14965x2]
>> 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.
Graham
4-Nov-2009
[14967]
cool ...
Gabriele
4-Nov-2009
[14968]
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.
Pekr
8-Nov-2009
[14969]
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/
BrianH
8-Nov-2009
[14970x2]
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.
Henrik
12-Nov-2009
[14972x2]
is it possible to cascade error throws through several functions?
never mind, I did something wrong. got it now.
btiffin
12-Nov-2009
[14974]
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")
Gabriele
13-Nov-2009
[14975x3]
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?
Graham
13-Nov-2009
[14978x2]
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.
Chris
13-Nov-2009
[14980x2]
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.
Graham
13-Nov-2009
[14982]
I ended up using case .. and just straight subtraction of years etc 
instead of using 'difference which can sometimes lead to numeric 
overflow.
Izkata
14-Nov-2009
[14983]
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...)
Graham
14-Nov-2009
[14984]
Interesting.
Jerry
14-Nov-2009
[14985x2]
I thought R3 has not support task! yet. Why does the following code 
work?
do make task! [ forever [ print now wait 1 ] ]
Henrik
14-Nov-2009
[14987]
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.
jocko
14-Nov-2009
[14988]
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.
Henrik
14-Nov-2009
[14989]
oops, now I posted the response in the wrong group. :-)
jocko
14-Nov-2009
[14990]
ok, saw it, thanks
Henrik
14-Nov-2009
[14991]
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.
jocko
14-Nov-2009
[14992]
yes, its a real challenge ...
Henrik
14-Nov-2009
[14993]
Fortunately Carl has a little bit of experience with multitasking, 
so I'm sure a good model will come up. :-)
jocko
14-Nov-2009
[14994]
Of course ! He certainly will find a clever approach !
Brock
15-Nov-2009
[14995]
Graham, is it important to take into account leap years in your solution?
Graham
15-Nov-2009
[14996]
No, just accurate within a couple of days.
Henrik
16-Nov-2009
[14997x2]
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.
Gabriele
16-Nov-2009
[14999]
>> p: 'a/b/c/d
== a/b/c/d
>> pick p 2
== b
>> p/2 
== b
>> p/c
== d
>> select p 'c
== d
Henrik
16-Nov-2009
[15000x3]
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...
Geomol
16-Nov-2009
[15003x3]
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.