[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is the time anyways?
- To: info-mcl
- Subject: Re: What is the time anyways?
- From: gersh@aplpy.jhuapl.edu (John R. Gersh)
- Date: 1 Dec 92 20:57:29 GMT
- Keywords: time
- Newsgroups: comp.lang.lisp.mcl
- Organization: Johns Hopkins University Applied Physics Lab
- References: <92Dec1.110128est.144049@explorer.dgp.toronto.edu>
- Sender: news@aplcen.apl.jhu.edu (USENET News System)
- Summary: Compiler Culprit?
In article <92Dec1.110128est.144049@explorer.dgp.toronto.edu>
Russell Owen writes:
>Hi,
> This may be a novice question but I am really stumped. I am trying to
>write a function that returns the current time read from the mac's
>real-time clock. It would seem to be a simple task.
>
[Provides code using Mac time traps that exhibits strange
behavior]
This problem raises some interesting questions:
The simple answer to the basic need, as has been mentioned, is to use Lisp
time functions rather than access the clock directly:
(defun get-current-hms ()
(multiple-value-bind (sec min hr) (get-decoded-time)
(format nil "~2,'0D:~2,'0D:~2,'0D" hr min sec)))
will provide the desired functionality of the initial code.
But here's the weird part: the original code works fine if the
definition is evaluated, rather than compiled!
Stripping things to essentials:
(defun time-test ()
(rlet ((time datetimerec))
(#_gettime time)
(rref time datetimerec.minute)))
works fine if the defun is evaluated with *compile-definitions* nil,
but does does not work correctly if *compile-definitions* is true.
This behavior shows up whether an rlet is used or the datetime record is
explicitly created and disposed in the function.
What's happening?
---------------------------------------------------------------------
John Gersh gersh@aplpy.jhuapl.edu
The Johns Hopkins University Applied Physics Laboratory
Johns Hopkins Rd., Laurel, MD 20723 (301) 953-5503