freenode/#sicl - IRC Chatlog
Search
14:30:42
beach
So, instead of loading ASDF early, and instead of doing a small part of what ASDF is doing, I ought to be able to configure ASDF so that its load-op means loading a file into a first-class global environment according to how it is done during SICL bootstrapping.
14:32:08
scymtym
beach: this is not very developed, but you can either use the right-click menu to show more elements or click and drag (left and right) the part that says something like "showing 0 ... 100" at the top of the sequence presentation
14:54:54
beach
I think it will be possible if I can figure out how ASDF really works. Reading the manual may not be enough.
14:56:46
beach
I already did that, but I need to figure out how to propagate the operation to systems that the current one depends on.
15:06:53
beach
Brilliant. I defined my operation class, and I defined a method on PEFORM. Now that I try to use the new operation class, I get WARNING: DEPRECATED-FUNCTION-WARNING.
15:47:04
beach
All I (think I) need from ASDF is to call some function for all the :FILE components in the order that the DEFSYSTEM forms determine by the :DEPENDS-ON. So I defined my own operation class as a subclass of ASDF:OPERATION, and I defined a method on PERFORM that just does FORMAT.
15:47:06
beach
But I get WARNING: DEPRECATED-FUNCTION-WARNING: Using deprecated function (ASDF/ACTION:BACKWARD-COMPATIBLE-DEPENDS-ON ...) So I guess that's not the right way to accomplish what I need.
15:48:32
rpg
I'm not exactly sure what you are trying to accomplish -- did you say you are trying to replace what ASDF normally does when it loads something?
15:50:02
beach
But if you can just tell me how to call FORMAT for each :FILE in the right order, I think I can do the rest myself.
15:51:33
rpg
If that is the case, it's probably easier to make a new component class (call it :FILE-1 for now) and then make a PERFORM method for LOAD-OP and FILE-1 (possibly also with a new system-class that has FILE-1 as its DEFAULT-COMPONENT-CLASS, so that you get FILE-1 instead of CL-SOURCE-FILE when you write :file in your defsystem).
15:52:13
beach
But then I would have to duplicate all the system definitions. That is precisely what I want to avoid.
15:52:51
rpg
I thought this was only for the core system definitions that you are using to bootstrap SICL?
15:53:27
beach
No, it's mainly for all the external libraries that I also need to load, like Alexandria, and soon dozens more.
15:53:33
rpg
So is this an ADDITIONAL operation that will be done *in addition to* the conventional COMPILE-OP and LOAD-OP?
15:54:23
beach
For each :FILE component, it calls (sicl-boot:load-source-file <file-name> <environment>)
15:54:31
rpg
OK, and the hard part is that you need to use some arbitrary libraries during your bootstrapping process, and *in this context* you need to override COMPILE and LOAD.
15:56:46
rpg
I think what you do is add an :AROUND method on PERFORM LOAD-OP that uses SICL-BOOT:LOAD-SOURCE-FILE instead.
15:57:28
rpg
But then we need to find the right way to branch inside that :AROUND method. This is complicated because ASDF plans are linear, rather than hierarchical.
15:58:23
rpg
Can you make some kind of SICL-BOOT-OP that will be the main operation ? If so, we can control the context well enough to make this work.
15:58:23
beach
So that would break when I then try to use ASDF to build the code for the host, right?
15:59:08
rpg
If we have an identifiable phase (my SICL-BOOT-OP) that runs and then finishes, we can control the context, and make this work.
16:00:14
beach
Sure, I will start by doing (asdf:load-op "sicl-boot") and that's a normal host (SBCL) operation.
16:00:54
beach
As part of that code, I would like to say (asdf:....) which would then do the weird stuff.
16:01:26
beach
Once BOOT finishes, the next thing I will most likely do is a host (asdf:load-op ...) again.
16:02:09
rpg
I'm trying to think if we could have you do (asdf:operate-on-system 'sicl-boot-op "sicl-boot") -- but is that right?
16:02:55
rpg
And when you say after boot finishes you will probably do a host load-op again -- is "host" == vanilla SBCL or "host" == the SICL system.
16:03:51
beach
I don't need to configure (asdf:load-op "sicl-boot"). That's just compiling conforming Common Lisp code with SBCL.
16:04:28
beach
It is when I call (sicl-boo:boot) next, that I would like to call ASDF so that it loads things my way.
16:05:49
rpg
What I meant was you could have an ASDF system that describes the set of things that you would be loading as part of the boot process, and we could tailor this system's ASDF processing so that it sets up and tears down the context needed to modify the conventional load op.
16:06:55
beach
But I guess I don't understand why what I want to do is not precisely what ASDF says I should be able to do with a new operation and a method on PERFORM.
16:06:59
rpg
This world would have to interpret its dependencies as SICL boot dependencies, instead of conventional dependencies.
16:09:00
rpg
Yes, it might be that easy -- we define a SICL-BOOT-OP that requires SICL-LOAD-OP downwards and SICL-BOOT-OP sideways (as Fare uses those terms).
16:09:44
rpg
That would be cleaner, requiring no around methods, but requires thinking about ASDF dependencies.
16:10:12
rpg
"Downwards" == onto its components and "Sideways" is onto the components it depends on.
16:10:38
beach
I don't want to keep you from doing more important stuff. I can play with this a bit more myself.
16:11:45
rpg
1. Define a SICL-BOOT-OP, a SICL-LOAD-OP (I think that's the only operation. you need, right? You said no compilation...).
16:14:40
rpg
2. For SICL-LOAD-OP we need to tell ASDF that it depends on SICL-LOAD-OP being performed on its upstream members. Probably the easiest way to do this is to make SICL-LOAD-OP be a subclass of LOAD-OP, and make it *not* depend on COMPILE-OP on itself.
16:19:15
rpg
lisp-action.lisp has the definition of the operations for lisp files. So I think you make a subclass of load op (line 48 of lisp-action) that "selfward-depends" only on PREPARE-OP (standard LOAD-OP) depends on PREPARE-OP *and* COMPILE-OP
16:20:19
beach
Thanks for the hints. I'll work from here. If I need your help again, I'll let you know.
16:21:22
rpg
And... as I look at this, the PREPARE-OP (just a few lines up), requires LOAD-OP on its "sideways" depends. I guess you will need to replace that op, as well, with something that is like the built-in PREPARE-OP, but that requires SICL-LOAD-OP instead of LOAD-OP
16:22:15
rpg
That will be most of what you need -- you just need to make the PERFORM method for SICL-LOAD-OP, and I think (I hope!) you should be done.
16:23:11
rpg
There's a MAKE-PLAN (or some name like that) which will generate the plan structure for a system and an operation. building the plan and groveling over it will be easier for debugging that trying to apply the operation directly.
16:23:50
rpg
Getting the plan structure right is what you need to concentrate on, without being dragged into time consuming PERFORMs.
16:24:05
rpg
Once you get the plan built properly, you can add the PERFORM implementation and be done.
16:25:08
rpg
If you run into a dead end, you can reach me by email or on the asdf-devel mailing list. I'm not a regular on IRC any more, now that Slack is ruining my life.