Re: Apologies for slow progress...

[Stelian Ionescu]

On Sat, 2020-08-01 at 15:00 -0500, Robert Goldman wrote:
> I'm afraid I have been very busy at work, but also the linux box I
> have 
> been using as my Jenkins platform had a disk failure, taking it out
> of 
> action.
> 
> No data was lost, but my employer has been supplying this, and I have
> to 
> wait in the queue, after business requirements, for the IT folks to
> get 
> me a new server configured for this purpose.
> 
> This has unavoidably hindered my work on ASDF.
> 
> I'm open to suggestions about alternative resources for running
> these 
> tests, but there are special challenges because I need to be able to
> put 
> commercial software (Allegro CL and LispWorks) on any test server,
> which 
> I think rules out using Travis.

What are the challenges ? Allegro works well on Travis, and the limitations
of Lispworks Personal are well known.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.



signature.asc
Description: This is a digitally signed message part

Apologies for slow progress...

[Robert Goldman]

I'm afraid I have been very busy at work, but also the linux box I have 
been using as my Jenkins platform had a disk failure, taking it out of 
action.


No data was lost, but my employer has been supplying this, and I have to 
wait in the queue, after business requirements, for the IT folks to get 
me a new server configured for this purpose.


This has unavoidably hindered my work on ASDF.

I'm open to suggestions about alternative resources for running these 
tests, but there are special challenges because I need to be able to put 
commercial software (Allegro CL and LispWorks) on any test server, which 
I think rules out using Travis.


If anyone has hosting suggestions, please let me know: otherwise I'm 
afraid we'll be limping along till September, which is unfortunate, 
since we have a bunch of fixes and bug reports, and I would very much 
like to be able to get these wrapped up into a bug fix release.


I hope you all are staying safe and healthy!

Re: A CFFI -ASDF integration bug

[Faré]

I'm not developing ASDF anymore (unless for hire) but I believe the
CFFI toolchain has a new maintainer, who might be willing to devote
cycles to that (or at least to merging a patch to CFFI).

Note that if the code that builds stuff and the code that tracks the
dependencies disagree, the right solution is to make the dependencies
match the actual build, not to make it lie better: make sure that
files are attributed as the output-files of the action that creates
it, and as the input-files of the other actions.

—♯ƒ • François-René ÐVB Rideau •Reflection• http://fare.tunes.org
Due to circumstances beyond your control, you are master of your fate
and captain of your soul.



On Fri, Jul 31, 2020 at 1:18 PM Ilya Perminov  wrote:
>
> Hi,
>
> I found a ASDF-related CFFI bug a couple of days ago. Can anyone think of a 
> good way of fixing it?
>
> A method in grovel/asdf.lisp adds output files of process-op to output files 
> of compile-op:
>
> ;;; Declare the .o and .so files as compilation outputs,
> ;;; so they get picked up by bundle operations.
> #.(when (version<= "3.1.6" (asdf-version))
> '(defmethod output-files ((op compile-op) (c wrapper-file))
>   (destructuring-bind (generated-lisp lib-file c-file o-file) 
> (output-files 'process-op c)
> (declare (ignore generated-lisp c-file))
> (multiple-value-bind (files translatedp) (call-next-method)
>   (values (append files (list lib-file o-file)) translatedp)
>
> As a result inputs and outputs of the ops look like this:
> process-op:
>   input: wrapper-file
>   output: bindings-file.lisp file.c FILE.O FILE.SO
>
> compile-op:
>   input: bindings-file.lisp
>   output: bindings-file.fasl FILE.O FILE.SO
>
> The problem is that process-op generates file.o and file.so before it 
> generates bindings-file.lisp. Thus compile-op gets re-executed all the time, 
> because its output files file.o and file.so are always older than its input 
> file bindings-file.lisp. And an execution of the compile-op does not change 
> anything, because it does not really generate .o and .so.
> One way to fix it would be to "touch" .o and .so to get the right order of 
> file modification times, but there may be a better way.
>
> CFFI bug report: https://bugs.launchpad.net/cffi/+bug/1889491
>
> Thanks,
> Ilya