From: Samium G. <_de...@fe...> - 2007-11-30 01:33:09
|
Good day folks, This patch makes using *break-on-signals* a little less painful, where ASDF is concerned. regards, Samium Gromoff diff --git a/contrib/asdf/asdf.lisp b/contrib/asdf/asdf.lisp --- a/contrib/asdf/asdf.lisp +++ b/contrib/asdf/asdf.lisp @@ -366,8 +366,9 @@ and NIL NAME and TYPE components" (defun make-temporary-package () (flet ((try (counter) (ignore-errors - (make-package (format nil "ASDF~D" counter) - :use '(:cl :asdf))))) + (let ((*break-on-signals* nil)) + (make-package (format nil "ASDF~D" counter) + :use '(:cl :asdf)))))) (do* ((counter 0 (+ counter 1)) (package (try counter) (try counter))) (package package)))) |
From: Christophe R. <cs...@ca...> - 2007-11-30 08:11:32
|
Samium Gromoff <_de...@fe...> writes: > This patch makes using *break-on-signals* a little less painful, > where ASDF is concerned. My feeling is that rebinding *break-on-signals* in application code is unlikely ever to be a good idea. (If you get hit by that signal too often, you could run ASDF:FIND-SYSTEM on systems you care about before setting *BREAK-ON-SIGNALS*). Cheers, Christophe |
From: Samium G. <_de...@fe...> - 2007-11-30 12:41:57
|
At Fri, 30 Nov 2007 08:11:17 +0000, Christophe Rhodes wrote: > > My feeling is that rebinding *break-on-signals* in application code is > unlikely ever to be a good idea. I can see that. Actually I've had another solution, introducing a monotonically increasing counter for the purposes of temporary package generation inside ASDF, but then I've remembered somebody handholding me into the rebind-*b-o-s* solution, and the reasons which determined that choice -- concurrent package loading might still trigger *b-o-s*, in the absence of multithreading synchronisation being dealt with. However, I can see your point about rebinding *break-on-signals* in application code, so, perhaps we can reformulate the aim to be reduction, instead of elimination, of package collisions. So, will the other[1] patch be acceptable instead? > (If you get hit by that signal too > often, you could run ASDF:FIND-SYSTEM on systems you care about before > setting *BREAK-ON-SIGNALS*). Either I'm misunderstanding what you imply here, or I'm in need to make a clarification of the actual source of the problem. One of the issues this patch fixes was an actual annoyance I encountered on the wild -- namely a constituent source file of an ASDF system calling REQUIRE, which triggered a detached ASDF package loading pass, with the temp package counter set to zero, resulting in a collision and a signal. That, I think, illustrates why ASDF:FIND-SYSTEM won't help much. > Cheers, > > Christophe regards, Samium Gromoff [1]: diff --git a/contrib/asdf/asdf.lisp b/contrib/asdf/asdf.lisp --- a/contrib/asdf/asdf.lisp +++ b/contrib/asdf/asdf.lisp @@ -351,6 +351,8 @@ and NIL NAME and TYPE components" #+nil "/home/dan/src/sourceforge/cclan/asdf/systems/" #+nil "telent:asdf;systems;")) +(defvar *package-generation-counter* 0) + (defun sysdef-central-registry-search (system) (let ((name (coerce-name system))) (block nil @@ -368,8 +370,9 @@ and NIL NAME and TYPE components" (ignore-errors (make-package (format nil "ASDF~D" counter) :use '(:cl :asdf))))) - (do* ((counter 0 (+ counter 1)) - (package (try counter) (try counter))) + (declare (special *package-generation-counter*)) + (do* ((*package-generation-counter* (incf *package-generation-counter*)) + (package (try *package-generation-counter*) (try *package-generation-counter*))) (package package)))) (defun find-system (name &optional (error-p t)) |
From: Christophe R. <cs...@ca...> - 2007-11-30 13:11:19
|
Samium Gromoff <_de...@fe...> writes: >> (If you get hit by that signal too >> often, you could run ASDF:FIND-SYSTEM on systems you care about before >> setting *BREAK-ON-SIGNALS*). > > Either I'm misunderstanding what you imply here, or I'm in need to > make a clarification of the actual source of the problem. I think the former: if you run asdf:find-system on every system your asdf knows about, then my understanding is that asdf will load into memory the system descriptions. Then if you set *break-on-signals* to whatever you want, and issue your operate / require call, asdf will not attempt to reload .asd files into any package, because the in-memory version will be up-to-date. So no more package creation will ensue. I accept that this is nontrivial, and maybe your patch should be applied anyway, but I think it does solve your problems. Cheers, Christophe |
From: Samium G. <_de...@fe...> - 2007-11-30 13:24:58
|
At Fri, 30 Nov 2007 13:11:00 +0000, Christophe Rhodes wrote: > > Samium Gromoff <_de...@fe...> writes: > > >> (If you get hit by that signal too > >> often, you could run ASDF:FIND-SYSTEM on systems you care about before > >> setting *BREAK-ON-SIGNALS*). > > > > Either I'm misunderstanding what you imply here, or I'm in need to > > make a clarification of the actual source of the problem. > > I think the former: if you run asdf:find-system on every system your > asdf knows about, then my understanding is that asdf will load into > memory the system descriptions. Then if you set *break-on-signals* to > whatever you want, and issue your operate / require call, asdf will > not attempt to reload .asd files into any package, because the > in-memory version will be up-to-date. So no more package creation > will ensue. That's a neat trick, indeed! > I accept that this is nontrivial, and maybe your patch should be > applied anyway, but I think it does solve your problems. Yes, the particular problem is solved, and I, personally, can live with that solution. The crave, though, is for less flow disruptions in the long term, so that's the real reason of why I'm posting this.. That said, I'm not hell-bent on any particular way of achieving this, for as long as the "end user[1] needs to care about one thing less" constraint is satisfied. regards, Samium Gromoff [1] Somebody using *b-o-s* to debug their programs. |