I have two ASDF systems, call them foo and bar. foo depends on bar.
In general, I'll say something like
(asdf:operate 'asdf:load-op :foo)
The system loads. Now I make a change in bar. I again load foo with
the above command. bar recompiles, but foo does not recompile, even
though it depends on bar. This is problematic, since foo uses macros
(for instance) which are defined in bar.
Is there something obvious that I'm missing? What's the right way to
deal with this?
rif
rif <···@mit.edu> writes:
> I have two ASDF systems, call them foo and bar. foo depends on bar.
> In general, I'll say something like
>
> (asdf:operate 'asdf:load-op :foo)
>
> The system loads. Now I make a change in bar. I again load foo with
> the above command. bar recompiles, but foo does not recompile, even
> though it depends on bar. This is problematic, since foo uses macros
> (for instance) which are defined in bar.
>
> Is there something obvious that I'm missing? What's the right way to
> deal with this?
That's an interesting question. When I'm developing, I edit and
compile various definitions in my running image. I do this by editing
the source and using SLIME's C-c C-c (and on occasion C-c C-k). So
reloading the system definition is actually not something I ever do.
What I do do is from time to time rebuild my system from scratch with
a fresh image. I delete the fasl files, do the ASDF load, and then
save a new image. The reason I do this is to ensure that my source
code is not depending on any state changes I made to the image that
are not in the source files anymore.
So for me, ASDF is not about reloading or redefining anything.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David Steuber <·····@david-steuber.com> wrote:
+---------------
| rif <···@mit.edu> writes:
| > I have two ASDF systems, call them foo and bar. foo depends on bar.
| > In general, I'll say something like
| > (asdf:operate 'asdf:load-op :foo)
| > The system loads. Now I make a change in bar. I again load foo with
| > the above command. bar recompiles, but foo does not recompile, even
| > though it depends on bar. This is problematic, since foo uses macros
| > (for instance) which are defined in bar.
| >
| > Is there something obvious that I'm missing? What's the right way to
| > deal with this?
+---------------
I'm not sure about *between* ASDF systems, but within a single one I
find myself using something like this:
(:file "foo" :depends-on (...whatever...)
:in-order-to ((compile-op (load-op "bar"))))
+---------------
| That's an interesting question. When I'm developing, I edit and
| compile various definitions in my running image. I do this by editing
| the source and using SLIME's C-c C-c (and on occasion C-c C-k). So
| reloading the system definition is actually not something I ever do.
...
| So for me, ASDF is not about reloading or redefining anything.
+---------------
Interesting. When developing web-based apps, I do exactly the opposite!! ;-}
During periods of active development, I make the "foo.lhp" (Lisp-Handled
Pages) file look like this:
;;; Boilerplate for using ASDF from LHP page.
(let ((system :foo)
(package :org.rpw3.foo)
(function :foo-main))
(flet ((this-page (request)
;; Ensure up-to-date each time.
(asdf:operate 'asdf:load-op system)
;; Hack to avoid a package read error the very first time.
(funcall (intern (symbol-name function) package) request)))
(lhp-set-page-function #'this-page)))
That way, ASDF verifies that everything's up to date and (re)compiled
on *every* web hit. That makes the development cycle *very* tight:
edit a bit, do a "save" in the editor, hit "Reload" in the browser,
and *boom*! Everything gets recompiled and the browser pops up the
new version of the page. [Or doesn't, and I look at the application
server's REPL and/or the Apache error log to figure out why.]
Yes, it costs a few extra cycles per page-hit, but IMHO it's well
worth it. [...and you did notice that "during periods of active
development" qualifier, yes?]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> David Steuber <·····@david-steuber.com> wrote:
> +---------------
> | That's an interesting question. When I'm developing, I edit and
> | compile various definitions in my running image. I do this by editing
> | the source and using SLIME's C-c C-c (and on occasion C-c C-k). So
> | reloading the system definition is actually not something I ever do.
> ...
> | So for me, ASDF is not about reloading or redefining anything.
> +---------------
>
> Interesting. When developing web-based apps, I do exactly the opposite!! ;-}
> During periods of active development, I make the "foo.lhp" (Lisp-Handled
> Pages) file look like this:
>
> ;;; Boilerplate for using ASDF from LHP page.
> (let ((system :foo)
> (package :org.rpw3.foo)
> (function :foo-main))
> (flet ((this-page (request)
> ;; Ensure up-to-date each time.
> (asdf:operate 'asdf:load-op system)
> ;; Hack to avoid a package read error the very first time.
> (funcall (intern (symbol-name function) package) request)))
> (lhp-set-page-function #'this-page)))
>
> That way, ASDF verifies that everything's up to date and (re)compiled
> on *every* web hit. That makes the development cycle *very* tight:
> edit a bit, do a "save" in the editor, hit "Reload" in the browser,
> and *boom*! Everything gets recompiled and the browser pops up the
> new version of the page. [Or doesn't, and I look at the application
> server's REPL and/or the Apache error log to figure out why.]
>
> Yes, it costs a few extra cycles per page-hit, but IMHO it's well
> worth it. [...and you did notice that "during periods of active
> development" qualifier, yes?]
:-)
Do you ever get bitten by dependencies that exist in your image but
have been elided from the source? I'm always paranoid about that
which is why I go back and rebuild my whole image from scratch from
time to time. I have actually had that issue. I've also had weird
order dependencies (a result of me not fully understanding the package
system) where I had an image that just wouldn't build from the
existing source.
I also tend to "doodle" in the editor and sometimes forget to clean
things up when I've figured out the right way (or at least a way) do
do something. I think this is one reason why Lisp appeals to me so.
Lisp is much friendlier towards the style of interactive development
that I like to do than C++ or even Perl ever was.
In school I had a Fortran class where I had to use a terminal to an
IBM 360 or some such. The printer was in a room that students weren't
allowed in so I had to wait for the lackey to get my print out and put
it in my box (a physical box). You might be able to imagine just how
much that sucked for interactive development! The process was
controlled by JCL to compile, run, and print. I could only fix a few
compiler errors at a time and there was often a 15 minute wait for my
printout. Needless to say, Emacs + SLIME feels like heaven to me now.
I'll have to get more into ASDF. Since SLIME can load a system, it
seems like another way to check things when I've touched a bunch of
files.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
No excuses. No apologies. Just do it.
--- Erik Naggum
David Steuber <·····@david-steuber.com> writes:
> [...]
> In school I had a Fortran class where I had to use a terminal to an
> IBM 360 or some such. The printer was in a room that students weren't
> allowed in so I had to wait for the lackey to get my print out and put
> it in my box (a physical box). You might be able to imagine just how
> much that sucked for interactive development! The process was
> controlled by JCL to compile, run, and print. I could only fix a few
> compiler errors at a time and there was often a 15 minute wait for my
> printout. Needless to say, Emacs + SLIME feels like heaven to me now.
That's the problem with newcomers, they don't get to use a card
puncher and go fetch listing from their box...
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
__Pascal Bourguignon__ http://www.informatimago.com/
> David Steuber <·····@david-steuber.com> writes:
>> [...]
>> In school I had a Fortran class where I had to use a terminal to an
>> IBM 360 or some such. The printer was in a room that students weren't
>> allowed in so I had to wait for the lackey to get my print out and put
>> it in my box (a physical box). You might be able to imagine just how
>> much that sucked for interactive development! The process was
>> controlled by JCL to compile, run, and print. I could only fix a few
>> compiler errors at a time and there was often a 15 minute wait for my
>> printout. Needless to say, Emacs + SLIME feels like heaven to me now.
I had the same fun, after I had spent 2 years on 9600 baud color
graphics terminals. I did incremental development with 'FORMAT'
statements due to the time lag you mention. Previously I had learned
how to hack the Job Control to get my prints into the high-speed
printer queue. Anything feels like heaven now!
--
Everyman has three hearts;
one to show the world, one to show friends, and one only he knows.
David Steuber <·····@david-steuber.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > ;;; Boilerplate for using ASDF from LHP page.
...[trimmed]...
| > That way, ASDF verifies that everything's up to date and (re)compiled
| > on *every* web hit. That makes the development cycle *very* tight:
| > edit a bit, do a "save" in the editor, hit "Reload" in the browser,
| > and *boom*! Everything gets recompiled and the browser pops up the
| > new version of the page. [Or doesn't, and I look at the application
| > server's REPL and/or the Apache error log to figure out why.]
...
| Do you ever get bitten by dependencies that exist in your image but
| have been elided from the source?
+---------------
Yes, but it's fairly rare. And anyway, I do my development on a laptop
[yes, that's running Apache & PostgreSQL as well as CMUCL and a browser],
so it gets rebooted anyway whenever I shut it down. Only when the new code
works as desired is it copied to the production site. [And tested again,
at least briefly...]
+---------------
| I'm always paranoid about that which is why I go back and rebuild
| my whole image from scratch from time to time. I have actually
| had that issue. I've also had weird order dependencies (a result
| of me not fully understanding the package system) where I had an
| image that just wouldn't build from the existing source.
+---------------
Yes, all that happens, rarely, but not often enough to get "paranoid"
about.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607