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

World: r3wp

[Core] Discuss core issues

Geomol
27-Feb-2006
[3582]
This is from the REBOL command prompt under Mac OS X. Does REBOL 
behave the same under other OSs?
>> 31-12-16383
== 31-Dec-16383
>> 1-1-16384  
** Syntax Error: Invalid date -- 1-1-16384
** Near: (line 1) 1-1-16384
>> d: 1-1-0000
== 1-Jan-0000
>> d - 1
== 31-Dec-65535
Henrik
27-Feb-2006
[3583]
Windows:

>> 31-12-16383
== 31-Dec-16383
>> 1-1-16384
** Syntax Error: Invalid date -- 1-1-16384
** Near: (line 1) 1-1-16384
>> d: 1-1-0000
== 1-Jan-0000
>> d - 1
== 31-Dec-65535
Geomol
27-Feb-2006
[3584x2]
The Gregorian Reformation occured in September 1752. This is output 
from the UNIX 'cal' command:
$ cal 9 1752
   September 1752
 S  M Tu  W Th  F  S
       1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Notice the jump from 2. to 14. Sep.!
And then some REBOL:
>> d: 2-9-1752
== 2-Sep-1752
>> d + 1
== 3-Sep-1752


Seems like the reformation didn't occur in REBOL-land. Maybe that 
should be noticed in the wikibook, Henrik?
Henrik
27-Feb-2006
[3586]
it probably should. could you put it in? I'm a little strained for 
time
Geomol
27-Feb-2006
[3587x2]
Also there is no year 0. So this is not absolutely correct:
>> 1-1-0000
== 1-Jan-0000
The year before year 1 is year -1 (or 1 BC).
I'm wondering, how REBOL handle leap year...
Henrik
27-Feb-2006
[3589]
strange that this year was picked, since the gregorian reformation 
didn't happen everywhere at once
Geomol
27-Feb-2006
[3590x2]
yeah, this is from UNIX 'man cal':

The Gregorian Reformation is assumed to have occurred in 1752 on 
the 3rd

     of September.  By this time, most countries had recognized the reforma-

     tion (although a few did not recognize it until the early 1900's.)
So most countries did.
Henrik
27-Feb-2006
[3592]
but would it be good/bad for rebol to support it? what if you are 
calculating astronomical data or similar
Geomol
27-Feb-2006
[3593x2]
It seems, REBOL handle leap years correctly. The rule is, that every 
4. year is a leap year. Every 100 year isn't a leap year though, 
unless it's divided by 400. So 2000 was a leap year, 1900 wasn't, 
but 1600 was. And so on.
Henrik, good question!
Rebolek
27-Feb-2006
[3595x2]
Also, REBOL does not support negative years at all
>> 1-1--1
== 1-Jan-1999
Henrik
27-Feb-2006
[3597x2]
well, that's pretty bad if you want to calculate astronomy stuff... 
maybe support for the julian calendar would be more appropriate for 
calculating extreme time periods?
I've always thought that consideration for science in REBOL was a 
little low
Sunanda
27-Feb-2006
[3599]
REBOL broadly follows the ISO-8601 date format (though not with the 
strict yyyymmdd format): years are 4 digit, positive numbers only. 
ISO 8601 is not designed for acheology or astronomy.

True astronomocal julian dates of course change day at midday not 
midnight -- so be really sure you want to use them.
Brock
28-Feb-2006
[3600x3]
Can anyone help me understand what is wrong below?  I am essentially 
trying to get Rebol to execute a ping or traceroute and record the 
result in a text file....
>> print read dns://www.google.ca
72.14.207.104
>> fp: open/new/lines %google.txt
>> call/console/output "tracert 72.14.207.104" fp
== 0
>> close fp
>> data: read/lines %google.txt

== ["close fp" "close fp" "close fp" "close fp" "close fp" "close 
fp" "close fp" "close fp" "close fp" "close fp" "
close fp" "close...
I have also tried using /wait...
	call/console/wait/output "tracert 72.14.207.104" fp
with the essentially the same result.
sqlab
28-Feb-2006
[3603x4]
use this 
call/console/output "tracert 72.14.207.104" fp: ""

probe fp
or this
call/console/output "tracert 72.14.207.104" f %google.txt
sorry, it's wrong above.
Should be;
call/console/output "tracert 72.14.207.104"  %google.txt
Gabriele
28-Feb-2006
[3607x2]
don't use /console! /console means redirecting i/o to the rebol console, 
which conflicts with the other redirection you are asking for.
just call/output "tracert www.google.ca" out: ""
Brock
28-Feb-2006
[3609]
so close... thanks guys.
Pekr
1-Mar-2006
[3610x2]
why this does not work?

  ff: func [a] [str: "a + 1" do str]
>> ff 2
** Script Error: a has no value
** Where: ff
** Near: a + 1
while following does?

>> ff: func [a] [b: a  str: "b + 1" do str]
>> ff 1
== 2
Volker
1-Mar-2006
[3612]
string is bound global. 'b too.
Anton
1-Mar-2006
[3613x2]
'b is global, as is not.
Yes, Volker is right, (and I made a spelling mistake.)
Pekr
1-Mar-2006
[3615x2]
ok, before I read your replies I found it out too :-) can we somehow 
influence how 'do or 'load behave in that regard?
simply to bind 'do to the context of the function?
Volker
1-Mar-2006
[3617x2]
ff: func [a] [str: "a + 1" blk: bind load str 'a do blk]
bind the argument, not the 'do
Anton
1-Mar-2006
[3619]
just   do bind load str 'a
Pekr
1-Mar-2006
[3620x4]
I thought bind is involved somehow :-)
I have one other question to bindology :-)
following works:

 >> kontext: context [a: 1 b: 2 c: 3]
 >> do bind [a + b + c] in kontext 'a
== 6
but I first tried:

do bind [a + b + c] 'kontext 


and it did not work. So is 'kontext itself a different context than 
in kontext 'a? :-)
JaimeVargas
1-Mar-2006
[3624x4]
do bind [a + b + c] kontext ;; works.
Or you can use this mezz.
with: func [object [object!] block [block!]] [
    do bind/copy block object
]


>> kontext: context [a: 1 b: 2 c: 3]
>> with kontext [a + b + c]
== 6
The WITH mezz was proposed by greg his implementation is backward 
compatilble, while the above is for 2.6 core. For completeness here 
is his implementation:

with: func [object block] [
    if object [do bind/copy block in object 'self]
]
Pekr
1-Mar-2006
[3628x2]
uh, that is cute ....
will it be accepted to Core?
JaimeVargas
1-Mar-2006
[3630]
It is being considered.
Volker
1-Mar-2006
[3631]
do bind [a + b + c] 'kontext
In which context is 'kcontext bound? ;)