Hi,
I'm using ASDF on CCL running on a TI ARM Cortex A8 processor with Linux. I have a very simple hello world system written that I'm trying out.
When I try to load, I find that that find-system is called continuously and this never ends. I see the following on my slime window.
CL-USER> (asdf:oos 'asdf:load-op 'cl-syslink) ; Loading system definition from /home/root/ccl/tools/cl-syslink.asd into # <Package "ASDF0"> ; Registering #<SYSTEM "cl-syslink"> as cl-syslink ; Loading system definition from /home/root/ccl/tools/cl-syslink.asd into # <Package "ASDF1"> ; Loading system definition from /home/root/ccl/tools/cl-syslink.asd into # <Package "ASDF2"> ....
On investigation I found that the universal-time stored in *defined-systems* is just slightly behind the file-write-date. The dates I see are in-memory: 3499707641 and safe-file-write-date 3500387179.
I'm not sure why the time skew exists but I can always abort the recursive calls after a few times and then use the system.
Any thoughts on this? Is this seen on any other implementation/OS?
--Sid
I'm using ASDF on CCL running on a TI ARM Cortex A8 processor with Linux. I have a very simple hello world system written that I'm trying out.
We can't help you w/o access to the source code.
When I try to load, I find that that find-system is called continuously and this never ends. I see the following on my slime window.
Is your asd file trying to load itself?
On investigation I found that the universal-time stored in *defined-systems* is just slightly behind the file-write-date. The dates I see are in-memory: 3499707641 and safe-file-write-date 3500387179.
So you loaded a previous version of the file on Nov 25 and last modified the file on Dec 3. What else happened in the meantime?
I'm not sure why the time skew exists but I can always abort the recursive calls after a few times and then use the system.
Is the file loading itself *after* the defsystem? Or is it just using the result of a previous defsystem?
Any thoughts on this? Is this seen on any other implementation/OS?
Show your code first.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Death is only a state of mind.
Only it doesn't leave you much time to think about anything else.
On Sat, Dec 4, 2010 at 1:34 PM, Faré fahree@gmail.com wrote:
I'm using ASDF on CCL running on a TI ARM Cortex A8 processor with Linux. I have a very simple hello world system written that I'm trying out.
We can't help you w/o access to the source code.
Sorry about not attaching the code upfront. All I have is this -
;; cl-syslink.asd (asdf:defsystem "cl-syslink" :serial t :components ((:file "syslink")))
;; syslink.lisp (defpackage :syslink (:use :cl) (:export :hw))
(in-package :syslink)
(defun hw () (print "Hello Syslink World"))
When I try to load, I find that that find-system is called continuously and this never ends. I see the following on my slime window.
Is your asd file trying to load itself?
It shouldn't. I tried out the same files on CCL on Windows and it loads just fine.
On investigation I found that the universal-time stored in *defined-systems* is just slightly behind the file-write-date. The dates I see are in-memory: 3499707641 and safe-file-write-date 3500387179.
So you loaded a previous version of the file on Nov 25 and last modified the file on Dec 3. What else happened in the meantime?
I never bothered to look at the date until you mentioned it, but I just ran date on the board and that shows the following
root@dm816x-evm:~# date Fri Nov 26 05:01:45 UTC 2010
But obviously today is not Nov 26 :-) Looks like there isn't an RTC on the board or its not working correctly. get-universal-time reports the time that the board thinks it is but since the files are on NFS, the server (which most likely has the correct date) reports a date way ahead.
--Sid
Sorry about not attaching the code upfront. All I have is this -
;; cl-syslink.asd (asdf:defsystem "cl-syslink" :serial t :components ((:file "syslink")))
;; syslink.lisp (defpackage :syslink (:use :cl) (:export :hw))
(in-package :syslink)
(defun hw () (print "Hello Syslink World"))
On investigation I found that the universal-time stored in *defined-systems* is just slightly behind the file-write-date. The dates I see are in-memory: 3499707641 and safe-file-write-date 3500387179.
So you loaded a previous version of the file on Nov 25 and last modified the file on Dec 3. What else happened in the meantime?
I never bothered to look at the date until you mentioned it, but I just ran date on the board and that shows the following
root@dm816x-evm:~# date Fri Nov 26 05:01:45 UTC 2010
But obviously today is not Nov 26 :-) Looks like there isn't an RTC on the board or its not working correctly. get-universal-time reports the time that the board thinks it is but since the files are on NFS, the server (which most likely has the correct date) reports a date way ahead.
Bug reproduced. And fixed.
1- it should work with 2.011.3 2- you can test with your skewed clock (or skewing it again) 3- don't forget to unskew your clock in the end.
Thanks for the bug report!
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Life is made of commitment. Neutrality is a myth, unless towards the irrelevant. Don't hide your responsibilities under that carpet. — Faré
<snip> On Sun, Dec 5, 2010 at 1:37 AM, Faré fahree@gmail.com wrote:
But obviously today is not Nov 26 :-) Looks like there isn't an RTC on the board or its not working correctly. get-universal-time reports the time that the board thinks it is but since the files are on NFS, the server (which most likely has the correct date) reports a date way ahead.
Bug reproduced. And fixed.
1- it should work with 2.011.3 2- you can test with your skewed clock (or skewing it again) 3- don't forget to unskew your clock in the end.
Thanks for the bug report!
Thanks for the quick fix. I verified the fix and it works fine.
In Open Embedded linux, the hwclock program uses a timestamp file (/etc/timestamp) to keep track of date in case there is no RTC. When linux boots the date is set by reading from this file. I had untar'ed my filesystem on Nov 25 but started working on my code only a couple of days back. That's the reason for get-universal-time to report a date in Nov, but file-write-date reports the actual date, which is in Dec.
Thanks again! --Sid
-
Faré -
Sid H