World: r3wp
[Core] Discuss core issues
older newer | first last |
Henrik 7-Jul-2008 [10747] | has anyone worked on a method to convert a rebol block to a php array inside php? |
Dockimbel 8-Jul-2008 [10748x3] | For checking if a port! value is "opened", you can use this function : open?: func [port][zero? port/state/flags and 1024]. But that just checks for the "close" flag, it doesn't check the real TCP connection state. |
>> p: open http://rebol.com >> open? p == true >> close p >> open? p == false | |
In this example, it does report correctly the port state, but that doesn't inform you about the underlying TCP connection state (the TCP connection is closed once the first line is completed). | |
TimW 9-Jul-2008 [10751] | Is there a way to specify precision with rounding? My specific example has to do with money. Not only does it always chop it off to exact cents, but it rounds down. so .125 -> $0.12 This is horrible for accounting purposes. I just put everything in decimal and completely ignore the money! datatype, but this seems like a real shame. So is it possible to specify the decimal out to 4 or 5 places? |
Graham 9-Jul-2008 [10752] | help round |
TimW 9-Jul-2008 [10753] | 'round still doesn't work with money though >> round/to to-money .125 .001 --> $0.12 |
Henrik 9-Jul-2008 [10754] | Tim, it's probably better to not use money! when rounding. |
Sunanda 9-Jul-2008 [10755x2] | The rounding may not be to exact cents -- money type only *displays* 2 decimal points, though it *preserves* more: to-money .125 == $0.13 second to-money .125 0.125 |
Also, I am not seeing the always-down effect you report. round/to $.125 .001 == $0.13 ;; correctly rounded up Round did go through a couple of development stages. Perhaps your version of REBOL has an outdated one. This is the source from the version I am using: round: func [ {Returns the nearest integer. Halves round up (away from zero) by default .} [catch] n [number! money! time!] "The value to round" /even "Halves round toward even results" /down {Round toward zero, ignoring discarded digits. (truncate)} /half-down "Halves round toward zero" /floor "Round in negative direction" /ceiling "Round in positive direction" /half-ceiling "Halves round in positive direction" /to "Return the nearest multiple of the scale parameter" scale [number! money! time!] "Must be a non-zero value" /local m ][ throw-on-error [ scale: abs any [scale 1] any [number? n scale: make n scale] make scale either any [even half-ceiling] [ m: 0.5 * scale + n any [ all [ m = m: m - mod m scale even positive? m - n m - mod m scale + scale ] m ] ] [ any [ floor ceiling (ceiling: (found? half-down) xor negative? n down) n: add n scale * pick [-0.5 0.5] ceiling ] either ceiling [n + mod negate n scale] [n - mod n scale] ] ] ] | |
Henrik 9-Jul-2008 [10757] | As a note: In R3, money! is of much greater precision (infinite?) and should round properly using conventional ROUND/TO (once bug #492 is fixed, that is :-)). |
Pekr 9-Jul-2008 [10758] | infinite = 27 positions, IIRC ... |
Henrik 9-Jul-2008 [10759] | thanks, couldn't remember |
Chris 13-Jul-2008 [10760x2] | Uck, this is unsightly: >> to-path [ [ a [ b [ c [ ] == a/ b/ c |
Why does it not result in: == a/b/c | |
[unknown: 5] 13-Jul-2008 [10762x2] | The newline character is being detected so it is treating each as a separate statement. I would think that isn't a bug but rather a feature. |
Since the following works fine: >> to-path [a b c] == a/b/c | |
Chris 13-Jul-2008 [10764x4] | I think it's a bug in to-path. Why would you possibly want to retain that behaviour? |
I can understand silently storing newline settings between block sessions (I use 'new-line a little to control this behaviour), but what scenarios benefit from this when working with paths? | |
Consider this scenario: countries: [ us "United States" fr "France" au "Australia" uk "United Kingdom" ] foreach code extract countries 2 [ probe form to-path compose to-block 'users/(code) ] | |
I know how to work around it, just don't see the purpose. | |
Gabriele 14-Jul-2008 [10768] | chris, there is no purpose, it's just that internally path! = block!, so path! behaves exactly like block! does. it probably should strip newlines when converting though, or at least ignore them when molding... (that is, i'm saying this is a bug.) |
Henrik 14-Jul-2008 [10769] | perhaps it's a good idea to check on any char that does not belong in a path! R3 has a bug where it includes none! as part of a path. |
[unknown: 5] 14-Jul-2008 [10770] | Chris, you raised a good point when you said "Why would you possibly want to retain that behavior?". We wouldn't - add it to RAMBO please. |
Chris 14-Jul-2008 [10771] | Gab: just want to be sure, I know that one man's bug is another man's feature... |
eFishAnt 14-Jul-2008 [10772] | I'll RebIT to that! |
TimW 17-Jul-2008 [10773] | sorry I didn't reply sooner. The version of round I was using was on a linux box so it was the latest debian rebol release. It does round up correctly on the windows version I have. |
Henrik 21-Jul-2008 [10774x2] | >> build-tag [input type checkbox value test checked] == <input type="checkbox" value="test" checked> ; OK >> build-tag [input type checkbox value test checked /] == <input type="checkbox" value="test" checked="/"> ; Not OK, but required in all XHTM Lstandards. |
I'm not sure if it's the best way, but could it be solved by checking for /, "/" or #"/" as well as tail position in the block. | |
Geomol 21-Jul-2008 [10776] | What do you mean? |
Henrik 21-Jul-2008 [10777] | what I mean is that for single-standing tags, like <br>, XHTML 1.0 and upwards requires them to end with a slash. This creates a correct tag for this case: >> build-tag [input type checkbox value test /] == <input type="checkbox" value="test" /> But this is not correct: >> build-tag [input type checkbox value test checked /] == <input type="checkbox" value="test" checked="/"> |
[unknown: 5] 21-Jul-2008 [10778] | build-tag was probably adapted to support the earlier specification. |
Davide 21-Jul-2008 [10779] | The correct tag required by XHTML is: >> build-tag [input type checkbox value test checked checked /] == <input type="checkbox" value="test" checked="checked" /> |
Henrik 21-Jul-2008 [10780x2] | is checked="checked" really correct? |
interesting. it is correct. | |
Chris 21-Jul-2008 [10782] | Yep, xhtml requires paired attributes. |
Graham 23-Jul-2008 [10783] | >> f: %"test dir" == %test dir >> make-dir f == %test dir/ >> read f ** Access Error: Cannot open /d/rebol/test dir ** Near: read f |
Henrik 23-Jul-2008 [10784] | I'd say it's a bug |
Graham 23-Jul-2008 [10785] | a very old bug |
Henrik 23-Jul-2008 [10786] | but good it was found. that revealed 4 bugs in R3 there. :-) |
Graham 23-Jul-2008 [10787] | eeek! |
Henrik 23-Jul-2008 [10788] | I make a habit of testing R2 bugs in R3 as well. |
Graham 23-Jul-2008 [10789] | I think i've seen this bug before too .... |
Henrik 23-Jul-2008 [10790] | I have to work around it in my database system. |
Graham 23-Jul-2008 [10791x2] | I'm trying to rename a few 100 directories to conform to a naming scheme |
It's annoying having to work round this .. and also that rename doesn't work except in the current directory. | |
Henrik 23-Jul-2008 [10793] | yes, it's quite annoying |
Sunanda 23-Jul-2008 [10794] | I've been telling my clients for years not to install REBOL applications in folders that have a space in the name -- like "program files/rebol" It just creates too many problems. |
Chris 23-Jul-2008 [10795] | My virtual filesystem (in QM) simply doesn't allow them. Same reason -- too many problems... |
[unknown: 5] 23-Jul-2008 [10796] | what problems? |
older newer | first last |