AltME groups: search

the alternatives are .. 1. I learn to do it properly each time 2. 
I change the language to do it the way I expect :)

Question: <Unix Time>..   I found several functions on the web that 
show you how to create a unix-timestamp from a rebol time (now). 
 However, I am looking for the ability to convert a unix-timestamp 
back into rebol-time.  I started writing my own function but I think 
that leap-years might mess me up.  Anyone have any thought on the 
matter?

!> now + to-time 1e6
== 23-Oct-2005/13:26:16+2:00

The unix-timestamp could be any date/time.. so I think I have to 
work top down.. first find the year then month, day, hour, min, sec. 
    Kind of like building a binary number from a decimal.. top-down.

Yeah.  the date -> unixTime function from someone else (maybe Gabrielle) 
is..
to-unix-time: func [date] [
  date/date - 1-1-1970 * 86400 + to-integer date/time
]

Little casio watches know all of this info (Year/month/day/time). 
 I suspect it is in a static table inside the watch.  I have been 
looking for something like this on the web.

1-1-1970 + to-time unix-seconds

You might be on to something.. I did unix time (now) and it returned 
24-Dec-13007.  However, maybe I need to subtract not add.  I will 
play with this SIMPLE solution.  (I always try to look at it harder 
than it probably needs to be).  Thanks.

>> 1-Jan-1970/0:0:0 + to-time to-unix-time 15-Apr-2006/15:41:0
== 15-Apr-2006/15:41

Looks like the time just needs to be inlcuded...

O.K.
Thanks to everyone for their help.

I offer my final (not that it's the best) rendition of these conversion 
functions.


to-unix-time: func [
  "Create unix-timestamp.  Author: Gabriele_3-Aug-2002."
  date [date!] "Rebol-format date. (non-Milisecond type)."
][
  date/date - 1-1-1970 * 86400 + to-integer date/time
]

from-unix-time: func [

  "Create rebol-timestamp from unix-timestamp.  Author: Rebolers-Altme_2005."
  utime [integer!] "Unix timestamp."
][
  unixTimestampConstant + to-time utime
]  

-- OR an all-in-one --

unixTimestamp: func [

  "Rebol date to/from unix timestamp conversion.  Authors: Many rebolers.."

  varIn "Enter either a Date!type or Integer!type to convert to/from 
  unix/rebol."
][

   unixTimestampConstant: 1970-01-01/00:00:00           ;Reference.
   varOut: "ERR"

   if ((type? varIn) = date!) [                         ;from rebol, 
   to unix.

     varOut: varIn/date - 1-1-1970 * 86400 + to-integer varIn/time
   ]

   if ((type? varIn) = integer!) [                      ;from unix to 
   rebol.

     if (varIn >= 0) [                                  ;B.U.  (before 
     Unix.)
       varOut: unixTimestampConstant + to-time utime
     ]
   ]
   return varOut
]

John.

BIG TYPO on the last post.. 

unixTimestamp: func [

  "Rebol date to/from unix timestamp conversion.  Authors: Many rebolers.."

  varIn "Enter either a Date!type or Integer!type to convert to/from 
  unix/rebol."
][

   unixTimestampConstant: 1970-01-01/00:00:00           ;Reference.
   varOut: "ERR"

   if ((type? varIn) = date!) [                         ;from rebol, 
   to unix.

     varOut: varIn/date - 1-1-1970 * 86400 + to-integer varIn/time
   ]

   if ((type? varIn) = integer!) [                      ;from unix to 
   rebol.

     if (varIn >= 0) [                                  ;B.U.  (before 
     Unix.)
       varOut: unixTimestampConstant + to-time varIn
     ]
   ]
   return varOut
]

John.
BIG TYPO on the last post.. 

unixTimestamp: func [

  "Rebol date to/from unix timestamp conversion.  Authors: Many rebolers.."

  varIn "Enter either a Date!type or Integer!type to convert to/from 
  unix/rebol."
][

   unixTimestampConstant: 1970-01-01/00:00:00           ;Reference.
   varOut: "ERR"

   if ((type? varIn) = date!) [                         ;from rebol, 
   to unix.

     varOut: varIn/date - 1-1-1970 * 86400 + to-integer varIn/time
   ]

   if ((type? varIn) = integer!) [                      ;from unix to 
   rebol.

     if (varIn >= 0) [                                  ;B.U.  (before 
     Unix.)
       varOut: unixTimestampConstant + to-time varIn
     ]
   ]
   return varOut
]

John.

Louis, multi-user friendly!? What do you mean? That one user can 
lock a file for some time, so others can't access it? Or what?

Yes, I did play around with Rugby a while back, but could think of 
any way to use it at the time. Now I have a use.

pekr, it calculates date, not time difference that way. you need 
to:

start: now/time/precise wait 5 print (now/time/precise - start)

it would be nice if it calculated the complete time and date difference

Be careful of using the BCC feature with emails.  I sent mails at 
one time were the BCC recipients were viewable in the header information 
from within Outlook.  A disgruntled recepient then SPAMMED all who 
were BCC'd using my companies email address as the from Address.... 
Corporate Security didn't like me very much.

Dates have natural ranges depending on their domain.

An expected due date of an unborn baby is (in theory) no more than 
9 months away.

The expected due date assigned to my mother before I was born is, 
now, a long time ago.


I don't'see how you can get around applying all due diligence to 
*any* input field. That may include asking for 4-digit dates on some 
occassions or disambiguating 24/oct/05 to ensure you know which part 
is the year.


Validation is one of the hardest parts of any real-world application, 
and one of the parts that most languages -- REBOL included -- offer 
only token support for.
Ideally, we'd have a range of to-xxx? words, like:
to-date? "29-feb-03"
== [false  "no such date"]
to-date?/strict "29-feb-04"    
== [false "ambiguous year/day]
to-date?/window "29-feb-04" [1975 2074]
== [true 29-feb-2004]

Ladislav, Petr: It is all right to use ME for puzzles though, time 
permitting :)

No, REBOL is the runtime. A dialect processor only counts as a translator 
by my standards if the translation is only performed once rather 
than every time the operation is performed. Other languages can have 
tons of syntax because they are compiled.

Some dialects are one time use only others are not for example DRAW

A lot of the time I do my dialect processing with functors, functions 
that create functions. Sometimes these functors run in pre-rebol, 
some at runtime function creation time. Then the actual work is done 
by the generated functions. This gives me the advantages of dialects 
without the drawbacks. On the other hand, dialects like draw are 
examples of my principle of low overhead in proportion to the that 
of the work performed - the dialect overhead isn't that much different 
to that of a series of function calls in the do dialect.

>> help foreach
USAGE:
    FOREACH 'word data body

DESCRIPTION:
     Evaluates a block for each value(s) in a series.
     FOREACH is a native value.

ARGUMENTS:

     word -- Word or block of words to set each time (will be local) (Type: 
     get-word word block
)
     data -- The series to traverse (Type: series)
     body -- Block to evaluate each time (Type: block)

I want to use two block arguments.  One for word (value that gets 
set each time) and of course the 'data' block.

It's a long time since I did any high school math :(

Does now/time give military time?

Almost, no leading zero. Try: now/time + 12:00

I got it, it is a hard book. I haven't gotten the time to get through 
it with my job and kids, but what I have done was well worth it. 
EopL and the "book with the dragons" by Aho et al about complier 
design are books that change your view on programming.

>> o: make object! [time: does [now]]
>> third o
== [time: func [][now]]
>> reduce third o
== [7-Dec-2005/3:23:23+1:00]
>> third o
== [time: 7-Dec-2005/3:23:23+1:00]

>> o: make object! [time: does [now]]
>> third o
== [time: func [][now]]
>> reduce copy/deep third o
== [7-Dec-2005/3:25+1:00]
>> third o
== [time: 7-Dec-2005/3:25+1:00]

Why is the block not copied?

Henrik: what happens there is that the word TIME is set to the result 
of the function.

volker: it's just that TIME is bound to the object, and he's changing 
its value to that date...

I remember that insert func is syncronous when used in a port opened 
without no-wait refinement. Time to read again the core manual :-) 
. Thanks anyway

forall: func [
    "Evaluates a block for every value in a series." 
    [catch throw] 

    'word [word!] {Word set to each position in series and changed as 
    a result} 
    body [block!] "Block to evaluate each time"
][
    throw-on-error [forskip :word 1 body]
]

my Series article: http://en.wikibooks.org/wiki/REBOL_Programming/Language_Features/Series
mentions this for quite some time

Yeah, IN can speed things up a bit when repeatedly accessing the 
same member of a object, saving on lookup time. It can be used to 
provide object field access in rebcode by calling it with apply too. 
Useful function.

Jaime, that's a pretty neat trick with the classes. Actually it's 
an extension of the language with some feature, that is not initially 
possible. I'll use some time this week-end to make a deeper inspection 
of the code. Are you the author?

Server 0.3 was meant to enable that and 0.4 was meant to mature that 
functionality. We did improve security during that time, and improvements 
such as those were rolled into 0.4

Ruud is watching from a distance. Like most people, he was surpsised 
by the time and effort it takes to develop a project like this. When 
he didn't get the contributions he had hoped for his newsletters, 
he decided to take a step back

David, we had a nice conference. Everything was filmed, but it always 
takes the organiser a long time to edit the videos, so I don't know 
when they will be published

why use other languages?  My personnal observation is that software 
running REBOL is much more stable than other scripted languages. 
 cause you have more time to debug and less bugs to begin with.

Ah, Hamachi is LogMein. They're advertising on our sites all the 
time :-)

I actually switched to AltME at the time because Groove didn't come 
through with their Linux (and Mac) versions

I don't know, it said "flush_block ... failed" several time (20-30 
times may be) I thought that it doesn't work but then desktop appeared 
and it works fine.

I looked into it at the time. I don't remember the details, but some 
hacking would probably be needed in the boot process and such

My OS of choice is however BlueBottle (bluebottle.ethz.ch) so I'd 
prefer to devote time to it. So that's a matter of time investments. 
E.g. I would not try hacking sources of Syllable...

no stack traces this time, and no relevant messages found.

Ahh. "3.9 Building the Syllable base system" at http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/README
: "At the time of writing, it is not possible to give a definitive
instruction for building the entire Syllable base system." :(((

At the time of writing, it is not possible to give a definitive
instruction 
for building the entire Syllable base system.
 :(((

I'll be away for a short time to check if we have any notes in our 
Syllable AltME space

but microkernels are unavoidable. everything will have them with 
time.

People leave volunteer projects all the time, and it's very easy 
for a troll to make it seem like it has something to do with the 
people remaining. Suffice it to say that this is motivated by their 
own feelings of inferiority, and far beside the truth

If Red/System takes a long time to be rewritten in Red, it might 
be an option to get it to run on R3, so it would run on Syllable 
Desktop

Not sure I want to spend time on it, because Red is next in the planning. 
But if you're looking to help... :-)

You might want to wait for some more information about modules to 
be revealed before asking that question yet. As it is now, components 
are compile-time features of REBOL 2 that can be included or excluded, 
enabled or disabled, in one chunk when building a version of REBOL. 
Only RT and SDK licensees have any control over that.


Plugins and modules are features of REBOL 3 that haven't been documented 
yet (maybe not finalized either). It is unknown whether REBOL 3 will 
even have components at all, or whether they will be replaced by 
modules or plugins.

Ladislav, I don't have time to think it all to the end, but an advise: 
Keep it simple!


I know, it's a very hard goal to reach, because we don't want to 
cut off possibilities. If it's possible for someone new to the language 
to use a feature like "function-local return" right away with expected 
result, and still the advanced programmer can use the feature in 
a way maybe not obvious at first, but that makes good sense, then 
it might be perfect.


But don't make the advanced programmer happy, if it'll make things 
difficult for the newbie.


recursive usage of the function that may request a return from different 
instances of the recursion

 sounds complicated at first. I think, you're right. We probably don't 
 need such a feature. If the code (C source) become simpler by including 
 the feature in recursion, then you might consider it though.

Is rebol3 going to support file locking? I think that is the correct 
term. I need for several users to be entering data into the same 
file at the same time. Is there a way to do this right now?

Alright, off to Rambo then. (I recall discussions all about equality 
and strict-equal a long time ago.)

REBOL has saved me from doom quite a few times. Last time was yesterday 
when I lost a database of people signed up to a town party race (a 
system written in REBOL), when the power cord to all the PCs was 
pulled. The database was partially wrecked, but (believe it or not) 
by creating a LIST-VIEW and querying the database, it was possible 
to view and print out the contents. REBOL is so damn wonderful, it's 
almost hard to believe.

I don't use rebol for making money, but saving me a time by doing 
very small utils, which save time .... and so maybe money? :-)

Something to consider for REBOL 3: The current implementation strategy 
for symbols in REBOL has significant limits to the possible number 
of symbols available at one time. It might be a good idea to try 
a red-black tree for symbols instead - newLISP uses that strategy 
and can handle millions of unique symbols efficiently.

As for red-black trees, I'm not sure they had been invented yet the 
last time I was in school for computer science. My studies were more 
focused on programming language design than data structures, so again 
I am not the one to ask.

Well, you could always try seeing how hard it is to implement from 
the available souce snippets. I think by the time you've finished 
doing that you'd be an expert.

Takiing into account the first made estimate (alpha in April IIRC?) 
and the time lag we now have, I think we won't see R3 final before 
September-2008. Other bets?

Yes, I know, nevertheless doing it "mostly" alone limits the pace 
we can move... it's still the same problem. Within production optimization 
I would say: We have a capacity, lot size (the different tasks) and 
setup time problem to solve.

I strongly doubt that RT would be wasting time. It's just that there 
is so much to do and R3 is one component in a large amount of software. 
Had this been some single-purpose program (like LIST-VIEW), we would 
see more rapid fire releases. :-)

Well, if community is a bit tight, then I would expect a more tighter 
relationship ... the thing is, that even blogging slowed down, and 
sometimes we can see blog posts, just buying Carl a bit more time 
imo :-)

Ladislav mentioned on ml, that he invited RT to discuss portability 
issues, maybe ppl would welcome some status update too ... we don't 
fear missing the schedules, as it happens with sw project, but imo 
ppl would deserve to know some status from time to time ...

I wonder with portability, when it will be time to discuss how to 
port r3? I remember hearing that it would be possible for 3rd party 
developers to do their own port

Humm. I don't like it. It violates  the contract for REPEAT.

USAGE:
   
	 REPEAT 'word value body

 

DESCRIPTION:
     
	Evaluates a block a number of times or over a series.
	REPEAT is a native value

.

ARGUMENTS:
	word -- Word to set each time (Type: word)
     

 value -- Maximum number or series to traverse (Type: integer series)
 
  ;;;;; This part of the contract is being broken by the example. 
  
	body -- Block to evaluate each time (Type: block)

If we make the right decisions about which functions are important 
enough to have their own word, we free ourselves with clearer code 
etc. Imagine if there was no DO function, but that functionality 
was a refinement of LOAD or REDUCE   --->    We would write REDUCE/DO 
 all the time.

Also, your implementation is slower than DELIMIT, by an order of 
magnitude.

>> time-block [conjoin "," []] 0.05  ;
== 4.953515625E-5

>> time-block [delimit/with [] ","] 0.05  ;
== 2.453125E-6

We have also the issue if  the joins should return a string all the 
time. We could use old 'join for typed joins, by gibing the type 
as the first argument, and 'rejoin always returns a string. then 
it would be called 'join and join something with type in the name, 
join-as or something.

Volker, joins don't return strings all of the time, they return series. 
If the first value is a series, the result will be a series of the 
same type. Since your urls there are series types, join will join 
them as-is.

Anton, i think that conjion will be used often, but will the argument 
be an inline-block, or a block in a variable? 'rejoin is used as 
an template, 
rejoin["Its" now/time "o'clock"]

In that case the block should be last. 'append is used with block 
in a var, 
'append this-block something

With conjoin i  expect it less like a template and more like 'append.

>> time-it: func [iterations code /local t0 t1][t0: now/precise loop 
iterations code t1: now/precise print difference t1 t0]
>> time-it 4000000 [pick [[a][b]] none? true]
0:00:04.306
>> time-it 4000000 [either true [[a]][[b]]]
0:00:03.555
>> time-it 4000000 [pick [[a][b]] none? none]
0:00:04.266
>> time-it 4000000 [either none [[a]][[b]]]
0:00:03.525

Brian, I think you might have misunderstood how I reworked the /only 
and /pad-only refinements, or I've misunderstood what you're trying 
to say about it. Let's consider /ONLY:

The first value in DATA is a block, so the result is a block. The 
second value 2 is inserted as is. The third value [3] is a block, 
but the contents are INSERTed, so the block is unwrapped:
	>> conjoin '| [["one"] 2 [3]]
	== ["one" | 2 | 3]


Same result except this time the /ONLY refinement causes the third 
value [3] to be inserted as is, so it remains a block:
	>> conjoin/only '| [["one"] 2 [3]]
	== ["one" | 2 | [3]]


This seems to me to be a necessary option in the treatment of the 
input data.

Just wanted to remind, that Rebcode was here for a short time:-) 
Hope it will come back:-)

I confess I had not read thru what you have been working on (time) 
I just wanted to be sure it was considered

we typed the same conclusion at the same time :)

(need to check that, didn't use rebcode for quite some time)

Also if I understand correctly, Maxim has now full time job, non 
AGG related. I wonder what the future of AGG is for us, and if we 
should not look into something else ....

That would shave off a lot of development time for an app, I'm developing. 
Just this one feature. Thanks.

rebol [
	purpose: "Demonstrate how to use the findany function."
	note:  {This is a function I would like included in Rebol3.
		One of you experts (I don't remember who) made this function 

                for me, and I use it all the time. Do you see any ways it can
		be improved before I submit it? --- Louis
	}
]

s: "findany will return true if it finds in this sentence any of 
the strings you enter in the request box."
print [s newline]

forever [

 bs: copy parse (request-text/title "Enter the strings you want to 
 find separated by a space.") none

	findany: func [ 
	     "Searches string x for any substring found in block ys."
	     x [string!] "string"
	     ys [block!] "block of substrings"
	    /local pos
	] [
	    foreach y ys [
	         if pos: find x y [return pos]
	     ]
	]

either findany s bs [print true][print false]

]
halt

Functions like these are very useful to have. I could have used them 
recently while doing file searching.
However, I wouldn't like to see these functions included as is.

- Not very efficient. That's ok  for searching small strings or the 
contents of short files, but bad when searching large files for many 
strings. 

- Not generic. The name suggests many datatypes are supported. Better 
names might be find-any-string, find-all-strings
- The above FINDALL does not keep FINDIT as a local.

- The argument names are too short, so they are not distinct or descriptive 
enough.

- The return values are not defined clearly in the function doc strings. 
The above issues are fixable, but it will take some time.

(Actually, the efficiency issue will take the most time to resolve.)

I plan to look disgusted every time somoene does not speak English...this 
seems like a good attack plan while in France..... : )

for my part, the first time I landed in Charles de Gaule airport, 
I saw a lost traveler (french) asking for bus schedules, get screamed 
at by the stewardess at the help desk... cause he asked twice!  :-)


I got cut off in a line (as I was going to be served) waiting for 
a train ticket in paris... twice in a row... I was soooo surprised 
I didn't know how to react!  I was then told a lot of people expected 
you to start arguing or else they are right ! 

its just funny really.  :-)


but my guess is that the more alien you are, the better people react 
.

yes obviously, actually calling reduce all the time.

First I thought R3 alpha will be released before the end of the year, 
now I wish we could at least see long time promissed diagrams of 
R3 architecture as a Christmas gift :-))

Any time I am on AltMe is break time for me. Most of what I do with 
REBOL nowadays is parse and file manipulation, and neither of those 
have changed much in years. I don't need View - most of my code is 
non-interactive or web-based.

so visit here from time to time and please if you have something 
to say to the topic, feel free to. I believe Ladislav and Carl listen 
to various opinions ...

...but even then everybody is going to have a hard time trying to 
supply a variable as argument

The operator
*
works with Type: number pair char money time tuple

We have to check for all those, when defining a mult2 function today. 
(Or catch the error.)

as opposed to that, I guess that these cannot save much time anyway

Okay, what then if INC/DEC are introduced in the language in a way, 
so they work more like we're used to with e.g. NEGATE, but at the 
same time allow, that variables can be changed? We have to use call-by-word 
(the REBOL way of call-by-reference) to have the variables changed. 
Like this:

>> a: 4
>> inc a
== 5
>> a
== 4
>> inc 'a
== 5
>> a
== 5


So INC has to check, if it's called with a word, and then get it's 
value before adding one, and in the end do a set-word. We could have 
the same with NEGATE and other functions (actions) of the same kind:

>> negate a
== -5
>> a
== 5
>> negate 'a
== -5
>> a
== -5

Does that make sense? And is it REBOLish?

Sorry, I just realized that was a confusing answer (to anyone other 
than Ladislav :). To clarify:


By call-by-name, I meant passing a word or path value to the function, 
rather than passing the value it refers to. If you have 'a formal 
arguments then call-by-name is implicit - if you have regular formal 
arguments then you must explicitly express call-by-name by writing 
the 'a as the actual argument, at the time of the call.


When I was talking about having to put function calls in parens, 
I meant any function calls or expressions that return the values 
that would then be passed to the INC/DEC function in their first 
argument. The first version of the functions, with the 'a argument, 
would need to put any word or path generating expression in parentheses 
for it to work properly. The second version of the functions would 
not require such a hack - you could use normal REBOL evaluation patterns.


One of the normal REBOL evaluation patterns is that call-by-name 
is explicit for all functions, except interactive functions used 
for documentation like HELP and SOURCE. This is why I prefer the 
latter functions above, the ones with normal formal arguments: Their 
behavior is more REBOL-like.

geomol and others...  INC with lit-words is seriously flawed in actual 
use ... a: inc a  ?? what's the point of it...


lit-words are not word values they are labels, they are not usable 
unless the word exists "somewhere else"  its not THE a you are evaluating 
but AN a somewhere... which is why this is as alien to rebol as anywhere 
else.


if all series can change values "in-place" like append... why not 
allow this for scalars (and others) too?  its already an integral 
part of REBOL ... I don't see the "confusion" in   INC a   changing 
THE a... its exactly like  append a, but for another type... hell, 
I've wanted in-place editing for many things which aren't series 
and it would speed up code, just like not having to copy series all 
the time like python. 

ADD-TO a 10


when you do INC 'a  you HAVE to declare 'A somewhere else... which 
is not in rebol's philosphy.  this is completely different thinking 
to rebol... its much closer to C style... where you expect a to exist 
somewhere...    the lit word syntax, just cause a big confusion within 
the normal chain of rebol coding IMHO its not simple, and certainly 
not obvious... most newbies don't even get what a lit-word is.  just 
like SET which is used only (usually) to implement other tricks in 
the language... we shouldn't be using SET in normal code.  INC is 
not a trick word... its something I'd be using in many scripts, unlike 
SET which I seldom need to.  

just giving my view on this topic.  ;-)

I know many of you are very technical and scientific, but this is 
a kind of detail, which is IMHO not in REBOL's mindset and don't 
mind a little bit of extra "precision" or "correctness".  but REBOL 
is not about being correct and strict... its about being simple and 
productive... so even if you are probably correct in your analysis... 
I do think its not a simple detail to understand for the vast majority 
of REBOLers.


The interpreter should addapt to use, not the opposite.  INC a means 
increment a, who cares what this means within the interpreter, words 
already are pointers internally, so its not such a big deal to implement 
anyways AFAICT.  in the end, we will be typing an extra ' all the 
time and really will be adding complexity elsewhere in the code, 
cause we have to "remember what a means, somewhere"


or end up doing a: INC a  which is sort of pointless.  Also, its 
an op, not a function.  just like + - = ... its not supposed to follow 
a function's tought pattern.

maybe its time REBOL had a better support for ops.

is it just me or is it obvious R3 is about giving us what we always 
asked for and need? so far, all I read is user requests coming to 
life.


If people think 100% open source is the universal panacea...  I think 
its time people looked at how REBOL is evolving.


I think R3 might be the middle ground which allows much of the "open" 
discussion to be irrelevant.  user types,  open  linking and compilation, 
 lexical allowance for unrecognised tokens, somehow, this seems like 
we will be able to mold (sorry for the pun) REBOL into what we need, 
finally, rather than molding what we do to what REBOL (the interpreter) 
wants  :-)

Make sure you comment on the relaxed lexical parsing.  I've been 
working around this one for a long time...but it may hold traps my 
giddy little mind is missing today.