Re: Guidance requested for debugging import problem.
On Mon, 2021-11-29 at 21:16 +0100, felix.winkelm...@bevuta.com wrote: > > Hi! > > The problem here is that read-syntax extensions are not seen by csm, > which > tries to load and parse all source files. This was a blatant > oversight on my part, > I just committed a few changes to the csm trunk that adds a "-csm- > extend FILENAME" > option. You should be able to pass this directly to csm or via an > options file - > it works like csc's "-extend" and loads a file (source or compiled) > into the > processor so read-syntax extensions in the loaded file are installed. > > Could you give it a try? I have not tagged a new release yet, you can > check it > out via svn: > svn co > https://anonym...@code.call-cc.org/svn/chicken-eggs/release/5/csm > > I'd be very grateful for feedback. I think csm is quite useful, but > it hasn't been > tested enough yet and it needs serious usage to clarify whether the > approach is > worth it and robust enough. > It worked! Very nice. I'll keep using it and feedback any other issues I run into. Thanks. > felix > >
Re: Guidance requested for debugging import problem.
> Hi Felix, > > I did not know about csm (or perhaps forgot it's existence?). Anyhow it > seems like a potentially much better solution than a > hand-maintained Makefile. I've tried it on a couple code bases and I'm > running into a few issues, some are just cruft in the code but two cases > I'm running into invalid sharp syntax errors: > === > csm -program logpro -ignore tests/run.scm > while reading file /home/mrwellan/data/logpro/logprocessor.scm: > > Error: invalid sharp-sign read syntax: #\/ > === > For logpro I wanted to expose the #/ ... / syntax to users. Since > regex-literals is not ported in chicken 5 I just injected the code into > logpro for now but it seems that csm doesn't understand the situation. > Hi! The problem here is that read-syntax extensions are not seen by csm, which tries to load and parse all source files. This was a blatant oversight on my part, I just committed a few changes to the csm trunk that adds a "-csm-extend FILENAME" option. You should be able to pass this directly to csm or via an options file - it works like csc's "-extend" and loads a file (source or compiled) into the processor so read-syntax extensions in the loaded file are installed. Could you give it a try? I have not tagged a new release yet, you can check it out via svn: svn co https://anonym...@code.call-cc.org/svn/chicken-eggs/release/5/csm I'd be very grateful for feedback. I think csm is quite useful, but it hasn't been tested enough yet and it needs serious usage to clarify whether the approach is worth it and robust enough. felix
Re: Guidance requested for debugging import problem.
Hi Felix, I did not know about csm (or perhaps forgot it's existence?). Anyhow it seems like a potentially much better solution than a hand-maintained Makefile. I've tried it on a couple code bases and I'm running into a few issues, some are just cruft in the code but two cases I'm running into invalid sharp syntax errors: === csm -program logpro -ignore tests/run.scm while reading file /home/mrwellan/data/logpro/logprocessor.scm: Error: invalid sharp-sign read syntax: #\/ === For logpro I wanted to expose the #/ ... / syntax to users. Since regex-literals is not ported in chicken 5 I just injected the code into logpro for now but it seems that csm doesn't understand the situation. Thanks. On Mon, Nov 15, 2021 at 5:01 AM wrote: > > Wow, that seems to have fixed it. Thanks!! > > Also, I will not tire to point out that "csm" is always a viable > alternative! :-) > > > felix > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Re: Guidance requested for debugging import problem.
> Wow, that seems to have fixed it. Thanks!! Also, I will not tire to point out that "csm" is always a viable alternative! :-) felix
Re: Guidance requested for debugging import problem.
Wow, that seems to have fixed it. Thanks!! On Sun, Nov 14, 2021 at 3:54 PM wrote: > > I went ahead and completed the minimal example build including the use of > > .import.o files to enable using modules in evals. See attached tar. It > > works fine which implies that, as you suggested, I have something wrong > in > > my build system. > > Thanks for the example code, this is really helpful understanding the > problem. > I have added -M to the compilation rules for the modules and removed the > "uses" declaration of m1.import and the example still seems to work. > -M includes the registration code in the binary, so that the module is > visible > at runtime. Perhaps this would help getting rid of the seprate *.import > units. > > > felix > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Re: Guidance requested for debugging import problem.
> I went ahead and completed the minimal example build including the use of > .import.o files to enable using modules in evals. See attached tar. It > works fine which implies that, as you suggested, I have something wrong in > my build system. Thanks for the example code, this is really helpful understanding the problem. I have added -M to the compilation rules for the modules and removed the "uses" declaration of m1.import and the example still seems to work. -M includes the registration code in the binary, so that the module is visible at runtime. Perhaps this would help getting rid of the seprate *.import units. felix
Re: Guidance requested for debugging import problem.
I went ahead and completed the minimal example build including the use of .import.o files to enable using modules in evals. See attached tar. It works fine which implies that, as you suggested, I have something wrong in my build system. I do think this little sample build might be helpful for others ramping up on creating a chicken application. I could not find a sample app on the wiki, after getting input on best known methods I can add it. On Sat, Nov 13, 2021 at 11:25 PM Matt Welland wrote: > The .import.o files are there to support access to modules in evals (there > is a past email thread on this). Those files are compiled like this: > > csc -unit apimod.import -c apimod.import.scm -o apimod.import.o > > I've attached a basic testcase that models the build without the import.o > stuff. Please confirm it is correct and then I'll add an example of the > .import.o files. > > Thanks again. > > On Sat, Nov 13, 2021 at 4:58 AM wrote: > >> > Thanks Felix for looking. Both run with -:d and attached. >> > >> > I only see the following loading calls in dashboard.log: >> > >> > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ >> > chicken.time.import.so ... >> > [debug] loading compiled library >> > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so >> > (0x555a9a701260) >> > [debug] entering toplevel... >> > ; loading ./debugprint.import.scm ... >> > ; loading ./mtargs.import.scm ... >> > ; loading ./commonmod.import.scm ... >> > ; loading ./configfmod.import.scm ... >> >> I'm not sure I fully understand the problem here, but these look strange: >> >> [debug] entering apimod.import... >> [debug] entering debugprint.import... >> [debug] entering mtargs.import... >> [debug] entering commonmod.import... >> [debug] entering configfmod.import... >> [debug] entering bigmod.import... >> >> Are import-libraries compiled as modules? I think there might be a problem >> with your build system - these messages indicate the modules of the names >> given are compiled as library units / toplevel proceduresm which >> shouldn't be. >> Import libraries are auxiliary files that are loaded or included, but do >> not >> represent separate toplevel procedures. The latter are only created for >> library units >> and modules. Please check how the shown files (apimod, etc.) are compiled >> and with what options. >> >> >> felix >> >> > > -- > -- > Complexity is your enemy. Any fool can make something complicated. > It is hard to keep things simple. - Richard Branson. > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson. testbuild.tar.gz Description: application/gzip
Re: Guidance requested for debugging import problem.
The .import.o files are there to support access to modules in evals (there is a past email thread on this). Those files are compiled like this: csc -unit apimod.import -c apimod.import.scm -o apimod.import.o I've attached a basic testcase that models the build without the import.o stuff. Please confirm it is correct and then I'll add an example of the .import.o files. Thanks again. On Sat, Nov 13, 2021 at 4:58 AM wrote: > > Thanks Felix for looking. Both run with -:d and attached. > > > > I only see the following loading calls in dashboard.log: > > > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > > chicken.time.import.so ... > > [debug] loading compiled library > > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > > (0x555a9a701260) > > [debug] entering toplevel... > > ; loading ./debugprint.import.scm ... > > ; loading ./mtargs.import.scm ... > > ; loading ./commonmod.import.scm ... > > ; loading ./configfmod.import.scm ... > > I'm not sure I fully understand the problem here, but these look strange: > > [debug] entering apimod.import... > [debug] entering debugprint.import... > [debug] entering mtargs.import... > [debug] entering commonmod.import... > [debug] entering configfmod.import... > [debug] entering bigmod.import... > > Are import-libraries compiled as modules? I think there might be a problem > with your build system - these messages indicate the modules of the names > given are compiled as library units / toplevel proceduresm which shouldn't > be. > Import libraries are auxiliary files that are loaded or included, but do > not > represent separate toplevel procedures. The latter are only created for > library units > and modules. Please check how the shown files (apimod, etc.) are compiled > and with what options. > > > felix > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson. testbuild.tar.gz Description: application/gzip
Re: Guidance requested for debugging import problem.
> Thanks Felix for looking. Both run with -:d and attached. > > I only see the following loading calls in dashboard.log: > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > chicken.time.import.so ... > [debug] loading compiled library > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > (0x555a9a701260) > [debug] entering toplevel... > ; loading ./debugprint.import.scm ... > ; loading ./mtargs.import.scm ... > ; loading ./commonmod.import.scm ... > ; loading ./configfmod.import.scm ... I'm not sure I fully understand the problem here, but these look strange: [debug] entering apimod.import... [debug] entering debugprint.import... [debug] entering mtargs.import... [debug] entering commonmod.import... [debug] entering configfmod.import... [debug] entering bigmod.import... Are import-libraries compiled as modules? I think there might be a problem with your build system - these messages indicate the modules of the names given are compiled as library units / toplevel proceduresm which shouldn't be. Import libraries are auxiliary files that are loaded or included, but do not represent separate toplevel procedures. The latter are only created for library units and modules. Please check how the shown files (apimod, etc.) are compiled and with what options. felix
Re: Guidance requested for debugging import problem.
Thanks Felix for looking. Both run with -:d and attached. I only see the following loading calls in dashboard.log: ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ chicken.time.import.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so (0x555a9a701260) [debug] entering toplevel... ; loading ./debugprint.import.scm ... ; loading ./mtargs.import.scm ... ; loading ./commonmod.import.scm ... ; loading ./configfmod.import.scm ... On Fri, Nov 12, 2021 at 3:31 PM wrote: > > On Fri, Nov 12, 2021 at 3:47 AM wrote: > > > > > > Update. I found that removing the *.import.scm files causes the > problem > > > to > > > > also occur when running the executable in the directory where > compiled. > > > > However the non-gui executable still works fine. Why would a compiled > > > > Chicken program be reading the import.scm files at run time? > > > > > > This can depend on compiler options: the import files contain code to > > > register modules and imports, depending on compilation type > > > (static/dynamic) > > > and certain compiler options, this code is compiled into the executable > > > or is loaded from a separate file. > > > > > > If you run the binaries with "-:d" and/or "-:d" do you get any > information > > > regarding the loaded files? > > > > > > > I see the *.import.scm files being loaded in the output only in this one > > place after chicken.time.import.so: > > > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > > chicken.time.import.so ... > > [debug] loading compiled library > > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > > (0x555a9a701260) > > [debug] entering toplevel... > > ; loading ./debugprint.import.scm ... > > ; loading ./mtargs.import.scm ... > > ; loading ./commonmod.import.scm ... > > ; loading ./configfmod.import.scm ... > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/base64.import.so > ... > > > > Can you run both apps with the debug flags and show their output? > > > felix > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson. Script started on 2021-11-12 18:47:36-0500 [debug] application startup... [debug] heap resized to 1048576 bytes [debug] stack bottom is 0x7fffd3cf5780. [debug] entering toplevel... [debug] entering library... [debug] entering build-version... [debug] entering eval... [debug] entering modules... [debug] entering chicken-syntax... [debug] entering expand... [debug] entering internal... [debug] entering ducttape-lib... [debug] entering file... [debug] entering extras... [debug] entering data-structures... [debug] entering irregex... [debug] entering pathname... [debug] entering posix... [debug] entering scheduler... [debug] entering port... [debug] entering lolevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/regex.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/regex.so (0x55aa95624c00) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ansi-escape-sequences.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/ansi-escape-sequences.so (0x55aa95625800) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-1.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-1.so (0x55aa95626e60) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/test.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/test.so (0x55aa95628910) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/slice.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/slice.so (0x55aa9562a240) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-13.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-13.so (0x55aa9562a890) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-14.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/srfi-14.so (0x55aa9562cc10) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/rfc3339.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/rfc3339.so (0x55aa9562e610) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/matchable.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/matchable.so (0x55aa9562f5b0) [debug] entering toplevel... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/directory-utils.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/directory-utils.so (0x55aa9562fcb0) [debug] entering toplevel... ;
Re: Guidance requested for debugging import problem.
> On Fri, Nov 12, 2021 at 3:47 AM wrote: > > > > Update. I found that removing the *.import.scm files causes the problem > > to > > > also occur when running the executable in the directory where compiled. > > > However the non-gui executable still works fine. Why would a compiled > > > Chicken program be reading the import.scm files at run time? > > > > This can depend on compiler options: the import files contain code to > > register modules and imports, depending on compilation type > > (static/dynamic) > > and certain compiler options, this code is compiled into the executable > > or is loaded from a separate file. > > > > If you run the binaries with "-:d" and/or "-:d" do you get any information > > regarding the loaded files? > > > > I see the *.import.scm files being loaded in the output only in this one > place after chicken.time.import.so: > > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ > chicken.time.import.so ... > [debug] loading compiled library > /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so > (0x555a9a701260) > [debug] entering toplevel... > ; loading ./debugprint.import.scm ... > ; loading ./mtargs.import.scm ... > ; loading ./commonmod.import.scm ... > ; loading ./configfmod.import.scm ... > ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/base64.import.so ... > Can you run both apps with the debug flags and show their output? felix
Re: Guidance requested for debugging import problem.
On Fri, Nov 12, 2021 at 3:47 AM wrote: > > Update. I found that removing the *.import.scm files causes the problem > to > > also occur when running the executable in the directory where compiled. > > However the non-gui executable still works fine. Why would a compiled > > Chicken program be reading the import.scm files at run time? > > This can depend on compiler options: the import files contain code to > register modules and imports, depending on compilation type > (static/dynamic) > and certain compiler options, this code is compiled into the executable > or is loaded from a separate file. > > If you run the binaries with "-:d" and/or "-:d" do you get any information > regarding the loaded files? > I see the *.import.scm files being loaded in the output only in this one place after chicken.time.import.so: ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/ chicken.time.import.so ... [debug] loading compiled library /home/matt/data/buildall/ck5.2/lib/chicken/11/chicken.time.import.so (0x555a9a701260) [debug] entering toplevel... ; loading ./debugprint.import.scm ... ; loading ./mtargs.import.scm ... ; loading ./commonmod.import.scm ... ; loading ./configfmod.import.scm ... ; loading /home/matt/data/buildall/ck5.2/lib/chicken/11/base64.import.so ... > > felix > > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Re: Guidance requested for debugging import problem.
> Update. I found that removing the *.import.scm files causes the problem to > also occur when running the executable in the directory where compiled. > However the non-gui executable still works fine. Why would a compiled > Chicken program be reading the import.scm files at run time? This can depend on compiler options: the import files contain code to register modules and imports, depending on compilation type (static/dynamic) and certain compiler options, this code is compiled into the executable or is loaded from a separate file. If you run the binaries with "-:d" and/or "-:d" do you get any information regarding the loaded files? felix
Re: Guidance requested for debugging import problem.
Update. I found that removing the *.import.scm files causes the problem to also occur when running the executable in the directory where compiled. However the non-gui executable still works fine. Why would a compiled Chicken program be reading the import.scm files at run time? On Thu, Nov 11, 2021 at 8:17 PM Matt Welland wrote: > Background: I've converted a flat (compilation units but not modules) > chicken program to modules and from chicken 4.12 to chicken 5.2. There are > two executables, a command-line only and a gui using iup. > > The problem: The command-line program runs fine from any directory however > the IUP gui program only works from the directory where it was compiled. > When run from a different directory I get an error "Error: (import-syntax) > during expansion of (import-syntax ...) - cannot import from undefined > module > debugprint". > > I'm looking for suggestions on how to debug this further. > > Thanks. > -- > Complexity is your enemy. Any fool can make something complicated. > It is hard to keep things simple. - Richard Branson. > -- -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
Guidance requested for debugging import problem.
Background: I've converted a flat (compilation units but not modules) chicken program to modules and from chicken 4.12 to chicken 5.2. There are two executables, a command-line only and a gui using iup. The problem: The command-line program runs fine from any directory however the IUP gui program only works from the directory where it was compiled. When run from a different directory I get an error "Error: (import-syntax) during expansion of (import-syntax ...) - cannot import from undefined module debugprint". I'm looking for suggestions on how to debug this further. Thanks. -- Complexity is your enemy. Any fool can make something complicated. It is hard to keep things simple. - Richard Branson.
