Re: Help Packaging Incudine (Common Lisp)
That's interesting. I was also suspicious about this function and mentioned it upstream but they said it is normal to do it like this so I just ignored it. Also I remember having tried out a dummy package, so I really believed it was ok. Thanks for your help! On October 23, 2023 10:44:57 AM GMT+02:00, Guillaume Le Vaillant wrote: >Hi. > >It looks like there's a bug in "contrib/cl-sndfile/cffi-sndfile.lisp". >The 'make-sndinfo' function definition tries to get the size of the >'info' foreign structure before this foreign structure is defined. > >After moving the definition of 'make-sndinfo' at the end of the file, >compilation works. > >I think you can report this issue upstream.
Re: Help Packaging Incudine (Common Lisp)
Hi, sure. Note that here the installation is narrowed to the asd system
"cl-sndfile". But you could add or replace it by "incudine".
> (define-public sbcl-incudine
> (let ((commit "21c99e4fe1b152c125a1bc6df915759b46cdab78")
> (revision "1"))
> (package
> (name "sbcl-incudine")
> (version (git-version "0.0.0" revision commit))
> (source
> (origin
>(method git-fetch)
>(uri (git-reference
> (url "https://git.code.sf.net/p/incudine/incudine;)
> (commit commit)))
>(file-name (git-file-name "incudine" version))
>(sha256
> (base32 "1zh17ifb6l8cpj5lzjz218h02c7rhf9khnh0lra3qmxd8dlwhqpa"
> (build-system asdf-build-system/sbcl)
>(arguments
> `(#:asd-systems '("cl-sndfile")
> #:phases
> (modify-phases
>%standard-phases
>(add-after 'unpack 'fix-paths
> (lambda* (#:key inputs
> #:allow-other-keys)
> ;; contrib
> (map (lambda (system-name)
>(substitute*
> (string-append "contrib/cl-"
>
> system-name
>
> "/cffi-"
>
> system-name
>
> ".lisp")
>
> (((string-append "lib" system-name "\\.so"))
>
>(search-input-file inputs
>
> (string-append "/lib/lib"
>
>
> system-name
>
>
> ".so")
> '("sndfile" "portmidi"))
> ;; foreign
> (map (lambda (system-name)
>(substitute*
> (string-append "src/foreign.lisp")
>
> (((string-append "lib" system-name "\\.so"))
>
>(search-input-file inputs
>
> (string-append "/lib/lib"
>
>
> system-name
>
>
> ".so")
> '("fftw3" "gslcblas" "gsl"
> ""))
> )
> (inputs
> (list sbcl-alexandria sbcl-bordeaux-threads sbcl-cffi sbcl-swap-bytes
> sbcl-trivial-garbage
> ;; pthread
> ;; jack
> portmidi
> libsndfile
> ;; fftw
> gsl
> ;; fluidsynth
> ;; lilv
> ))
> (home-page "https://incudine.sourceforge.net;)
> (synopsis "Music/DSP programming environment for Common Lisp")
> (description
> "Incudine is useful to design software synthesizers or sound plugins
> from scratch, exploiting the expressive power of Common Lisp, without the
> constraint to use pre-built unit generators. It is also a compositional tool
> that allows to produce high quality sounds controllable at the sample level,
> defining and redefining the digital signal processors and the musical
> structures on-the-fly. ")
> (license license:bsd-2
Guillaume Le Vaillant writes:
> [[PGP Signed Part:Undecided]]
> Hi.
> Could you send the package definition you made for Incudine?
> I could take a look at it and try to find where the issue comes from.
>
> [[End of PGP Signed Part]]
Re: Help Packaging Incudine (Common Lisp)
Liliana Marie Prikler writes:
> Am Donnerstag, dem 28.09.2023 um 12:23 + schrieb Théo Tyburn:
>> Oh, it seems I took the WARNING message for an ERROR message.
>>
>> The error message seems to just be:
>> > Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread #> > THREAD:THREAD tid=21 "main thread" RUNNING
>> >
>> > {100AFE8113}>:
>> > COMPILE-FILE-ERROR while
>> > compiling #
>>
>> No sure what can be done with this.
> Note that this error doesn't tell you where CL would have written the
> compiled file to.
>
> Am Donnerstag, dem 28.09.2023 um 14:21 + schrieb Théo Tyburn:
>> Not sure in what retrying a compilation on the interactive debugger
>> is different from compiling normally. But I need to understand why
>> the retrying of compilation does in order to replicate it without the
>> need of an interactive session.
> I'd hazard a guess that your $HOME is writable in the interactive case
> and not so much during guix build :)
> Well, that still doesn't explain why the compilation fails normally in
> the interactive case, does it? I think for that you'd have to look up
> uiop/lisp-build:compile-file and see when it raises errors. Enter
> rubber ducky.
Yes, that's probably the right place to look for hints. Need to find out
where and how compiled files are written.
Thanks
Re: Guix related things in Germany at the end of October/start of November
Christopher Baines writes: > [[PGP Signed Part:Undecided]] > Hey, > > PackagingCon [1] is happening in Berlin on the 26th to the 28th of > October, and the Reproducible Builds summit is happening in Hamburg on > the 31st of October to the 2nd of November. > > 1: https://packaging-con.org/ > 2: https://reproducible-builds.org/events/hamburg2023/ > > I've had a talk proposal on QA and Guix accepted for PackagingCon, and > I'm planning to attend the Reproducible Builds summit as well. Plus I'll > try to make some time to do some tourist stuff while I'm in Germany as > well. > > Is anyone else planning to attend these events, or otherwise interested > in meeting up in Germany around these dates? > > Chris > > [[End of PGP Signed Part]] I live in Berlin and never met someone using Guix IRL. Would be nice to organize something before/after/during the conf. Not sure if I can attend as I don't know my schedule yet. Cheers, Théo
Re: Help Packaging Incudine (Common Lisp)
For some weird reasons I manage to compile this reluctant file in an interactive session by accepting the error in the debugger and retrying compilation later on when the compiled file is required. Not sure in what retrying a compilation on the interactive debugger is different from compiling normally. But I need to understand why the retrying of compilation does in order to replicate it without the need of an interactive session. Here are the logs: This is the first error where where I accept: > ASDF could not load incudine because > COMPILE-FILE-ERROR while > compiling # "cffi-sndfile">. > While evaluating the form starting at line 3, column 0 > of #P"/home/teddd/src/music/incudine/require.lisp": > debugger invoked on a UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread > #: > COMPILE-FILE-ERROR while > compiling # "cffi-sndfile"> > Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. > restarts (invokable by number or by possibly-abbreviated name): > 0: [RETRY] Retry > compiling # "incudine" "contrib/cl-sndfile" "cffi-sndfile">. > 1: [ACCEPT ] Continue, treating > compiling # "incudine" "contrib/cl-sndfile" "cffi-sndfile"> > as having been successful. > 2: Retry ASDF operation. > 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the > configuration. > 4: Retry ASDF operation. > 5: Retry ASDF operation after resetting the > configuration. > 6: [RETRY] Retry EVAL of current toplevel form. > 7: [CONTINUE ] Ignore error and continue loading file > "/home/teddd/src/music/incudine/require.lisp". > 8: [ABORT] Abort loading file > "/home/teddd/src/music/incudine/require.lisp". > 9: Ignore runtime option --load > "require.lisp". > 10: Skip rest of --eval and --load options. > 11: Skip to toplevel READ/EVAL/PRINT loop. > 12: [EXIT ] Exit SBCL (calling #'EXIT, killing the > process). > (UIOP/LISP-BUILD:CHECK-LISP-COMPILE-RESULTS NIL T T > "~/asdf-action::format-action/" ((# . > # "cffi-sndfile">))) > ; File has been modified since compilation: > ; SYS:CONTRIB;ASDF;ASDF.LISP.NEWEST > ; Using form offset instead of character position. >source: (ERROR 'COMPILE-FILE-ERROR :CONTEXT-FORMAT CONTEXT-FORMAT > :CONTEXT-ARGUMENTS CONTEXT-ARGUMENTS) > 0] 1 Then comes the second error where I retry compilation: > ASDF could not load incudine because > Couldn't load > #P"/home/teddd/.cache/common-lisp/sbcl-2.3.5-linux-x64/home/teddd/src/music/incudine/contrib/cl-sndfile/cffi-sndfile.fasl": > file does not exist.. > While evaluating the form starting at line 3, column 0 > of #P"/home/teddd/src/music/incudine/require.lisp": > debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread > #: > Couldn't load > > #P"/home/teddd/.cache/common-lisp/sbcl-2.3.5-linux-x64/home/teddd/src/music/incudine/contrib/cl-sndfile/cffi-sndfile.fasl": > file does not exist. > Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. > restarts (invokable by number or by possibly-abbreviated name): > 0: [TRY-RECOMPILING ] Recompile cffi-sndfile and try loading > it again > 1: [RETRY] Retry loading FASL for >#. > 2: [ACCEPT ] Continue, treating loading FASL for ># > as having been successful. > 3: Retry ASDF operation. > 4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the > configuration. > 5: Retry ASDF operation. > 6: Retry ASDF operation after resetting the > configuration. > 7: [RETRY] Retry EVAL of current toplevel form. > 8: [CONTINUE ] Ignore error and continue loading file > "/home/teddd/src/music/incudine/require.lisp". > 9: [ABORT] Abort loading file > "/home/teddd/src/music/incudine/require.lisp". > 10: Ignore runtime option --load > "require.lisp". > 11: Skip rest of --eval and --load options. > 12: Skip to toplevel READ/EVAL/PRINT loop. > 13: [EXIT ] Exit SBCL (calling #'EXIT, killing the > process). > (LOAD >
Re: Help Packaging Incudine (Common Lisp)
Oh, it seems I took the WARNING message for an ERROR message.
The error message seems to just be:
> Unhandled UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread # tid=21 "main thread" RUNNING
> {100AFE8113}>:
> COMPILE-FILE-ERROR while
> compiling #
No sure what can be done with this.
I include the whole backlog, maybe this helps:
> Invoking sbcl:
> "/gnu/store/pp8pa2gl73gdn7vazjih16px7r28hqv0-sbcl-2.3.5/bin/sbcl"
> "--non-interactive" "--eval" "(require :asdf)" "--eval"
> "(asdf:initialize-source-registry (list :source-registry (list :tree
> (uiop:ensure-pathname
> \"/gnu/store/g8g7v4dvdylv2n6kjixgyxxsmgaqa5ka-sbcl-incudine-0.0.0-1.21c99e4/share/common-lisp/sbcl/incudine\"
> :truenamize t :ensure-directory t)) :inherit-configuration))"
> "--eval" "(asdf:load-system \"cl-sndfile\")"
> This is SBCL 2.3.5, an implementation of ANSI Common Lisp.
> More information about SBCL is available at
Help Packaging Incudine (Common Lisp)
Hi there,
I'm trying to package Incudine, a Music/DSP programming environment for
Common Lisp. I'm stuck with the binding of libsndfile. First
libsndfile.so could not be found, but I fixed the paths like it is
commonly done in other CL packages. Next problem is that somehow the
bindings are not working. The error I get:
> file:
> /gnu/store/s2657snmavhsnqyr0hf6f8a2v1lvrln2-sbcl-incudine-0.0.0-1.21c99e4/share/common-lisp/sbcl/incudine/contrib/cl-sndfile/cffi-sndfile.lisp
> in: DEFUN MAKE-SNDINFO
> (CFFI:FOREIGN-TYPE-SIZE '(:STRUCT SNDFILE:INFO))
>
> caught WARNING:
> Error during compiler-macroexpansion of
> (CFFI:FOREIGN-TYPE-SIZE '(:STRUCT INFO)). Use *BREAK-ON-SIGNALS* to
> intercept.
>
>Unknown CFFI type (:STRUCT INFO)
Now in the source file `cffi-sndfile.lisp`, there is:
> (declaim (inline make-sndinfo))
> (defun make-sndinfo ( pointer)
> (%make-sndinfo
> :pointer (or pointer
> (cffi:foreign-alloc :int8
>:count (cffi:foreign-type-size '(:struct info))
>:initial-element 0
>
> [...]
>
> (cffi:defcstruct info
> (frames sf-count)
> (sample-rate :int)
> (channels :int)
> (format :int)
> (sections :int)
> (seekable :int))
If I look at the source `sndfile.h` (which is present in source/.cl-union)
there is:
> struct SF_INFO
> { sf_count_t frames ;/* Used to be called samples.
> Changed to avoid confusion. */
> int samplerate ;
> int channels ;
> int format ;
> int sections ;
> int seekable ;
> } ;
So things look like they should match. Is there something I'm missing
here? I have 0 experience with CFFI bindings, so there might be
something obvious I'm missing.
Cheers
Théo
Re: Imagemagick with OpenEXR support
On Sun, Apr 16, 2023, 01:37 Csepp wrote: > > Théo Maxime Tyburn writes: > > > Csepp writes: > > > >> Théo Maxime Tyburn writes: > >> > >>> ``` > >>> checking for OpenEXR >= 1.0.6... no > >>> [...] > >>> Delegate library configuration: > >>> OpenEXR --with-openexr=yes no > >>> ``` > >> > >> If we are going by semver, then 1.0.6 is incompatible with 3.x. Maybe > >> it expects an older version? > > > > Hum. But it seems to look for a version that is greater or equal > > 1.0.6. Shouldn't 3.x be matched ? Maybe I misunderstand semver. > > You mean 3.x could have incompatibilities so that is what is is not > > matched ? > > A major version bump is supposed to mean a backwards incompatible > change, so depending on how the greater-than operator works, 1.x might > not be "smaller" than 3.x. It's not a total ordering, I think it's a... > semilattice? Or something along those lines. > Ah I see. That would make sense. Though semver.org says: ``` Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. ``` But maybe the imagemagick config also specifies a maximum version and doesn't say it out loud in the printed output. I'll have a look >
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
Hey all of you, I'm still interested. I go by teddd on IRC. I'll write you there Ludo. Cheers, Théo On Thu, Oct 6, 2022, 16:01 Ludovic Courtès wrote: > Hi Simon, Théo, Kaelyn, > > Simon Streit skribis: > > > Théo Maxime Tyburn writes: > >> It is here https://github.com/theottm/emacs-guix-clone. There is only > >> one branch. > >> > >>> if you succeed in building the new merged branch please notify me and > >>> I'll try to upstream it to > >>> https://git.savannah.gnu.org/cgit/guix/emacs-guix.git > >> > >> I just sucessfuly built it. You can probably use > > > > I could successfully build your branch. Unfortunately with geiser's > > recent upgrade from 0.23.2 to 0.26 emacs-geiser broke on my side. > > > > Geiser has since [1] removed all references to company. The end result > > is, that emacs-geiser will fail to load a REPL while it tries to > > initiate geiser-company. > > > > Here is my modification that fixes the REPL again: [2]. > > > > It'd be nice to see this pushed too and merge all the branches that now > > exist with emacs-guix. > > [...] > > > [1] > https://gitlab.com/emacs-geiser/geiser/-/commit/18faa0ba32c9ce751c16960b2a39b3880b523272 > > [2] https://git.steel-is-real.com/emacs-guix-clone/log/?h=simons-hack > > I’ve now merged your ‘simons-hack’ branch on Savannah. > > I’m sorry for dropping the ball here. I had told Kaelyn that they could > get an account on Savannah and become responsible for the Emacs-Guix > repo. The offer still holds, and it can even be extended to you Simon > and to Théo! > > As you can see I sometimes fail to follow up on issues, so I’d suggest > that you ping me on IRC (where I go by civodul) so we can proceed. > > Thank you! > > Ludo’. >
