IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<dsmith-work>Morning Greetings, Guilers
<ArneBab>moin dsmith-work
<nalaginrut>I'm glad there's cond-expand, then I would never afraid of portability for my code
<gjanssens>Hi, I'm making some progress with pre-compiling the gnucash scm code
<dsmith-work>gjanssens: Cool
<gjanssens>However I'm running into some "Wrong type to apply : #<syntax-transformer N_>" errors again
<gjanssens>I had those before in a different context, see to refresh the memory...
<gjanssens>I am trying to use the same technique to get around it, propose by wingo, but this time it doesn't seem to work
<gjanssens>And I think that's because this time the errors happen inside a guile module, where before it were just simple guile files
<wingo>gjanssens: is the definition for N_ loaded by "load" or by "use-modules" ?
<gjanssens>Meaning, the files I'm working with now start with (define-module ...). Last time that was not the case
<wingo>is "load" still used in gnucash?
<wingo>it used to be that code would be imported via something like "load", if i remember right
<gjanssens>There are still some files like that yes
<gjanssens>Let me give you some pointers at the files, so you can look over my shoulder:
<gjanssens>That's the central file in wich the define-syntax for N_ is found
<gjanssens>In line 307 is uses "load-from-path" to load prefs.scm
<gjanssens>Compiling app-utils.scm as wells as prefs.scm work fine
<gjanssens>It goes wrong when these files are indirectly included, like in
<wingo>i think you need to export N_ from that module
<wingo>just (export N_) should be sufficient for 1.8 and 2.0
<wingo>line 301 is pretty sketch, but i might have written that :P
<gjanssens>I think you did :)
<gjanssens>Should I replace this with (export N_) ?
<wingo>gjanssens: so, which module is actually exhibiting the error?
<wingo>i.e. which file does the "wrong type to apply" error originate in
<gjanssens>category-barchart.scm is one file that triggers this
<gjanssens>Here's the full error log:
<gjanssens>Not that this error has been produces with a skinned category barchart and report-collectors (use-module'd from category barchart)
<wingo>does this error exist in gnucash git? where are you working there?
<gjanssens>Stripped category barchart:
<gjanssens>Stripped report-collectors:
<gjanssens>wingo: what do you mean "in gnucash git" ?
<gjanssens>GnuCash git works when I allow it to autocompile
<gjanssens>However I'm now trying to pre-compile
<wingo>ah cool.
<wingo>heya civodul :)
<dsmith-work>civodul: Hey hey
<gjanssens>And for that I'm systematically going throught all the directories, adding the necessary entries in each makefile
<dsmith-work>gjanssens: Just curious: is gnucash currently a C app that links with libguile and expoeses some interfaces to guile, or is it a collection of modules with guile loadign them and being the main loop?
<gjanssens>The former - a c app linking with libguile
<wingo>gjanssens: it could be that (gnc:module-load "gnucash/report/report-system" 0) needs to run at expansion time
<gjanssens>wingo: that was indeed the solution last year
<gjanssens>You showed me a neat trick using a begin-for-syntax construct
<gjanssens>Like in this file:
<wingo>yes exactly
<wingo>we should have begin-for-syntax in guile
<wingo>sorry we don't yet :)
<gjanssens>That's ok, I can copy ;)
<gjanssens>However, the trick doesn't work here
<wingo>too bad :)
<gjanssens>report-collectors currently looks like this:
<gjanssens>I suppose it fails because begin-for-syntax is not defined top-level ?
<wingo>cond-expand preserves the "top-level" aspect
<gjanssens>Ok, then I'm clueless as to how I can fix this...
<gjanssens>Or should (export N_) be the way to go ?
<gjanssens>Nope, it doesn't
<wingo>the question to ask is "what defines N_" and then "how am I importing the definition of N_ in this module"
<gjanssens>"what defines N_" is 'app-utils.scm'
<gjanssens>It's being imported as part of the gnc:module-load of 'gnucash/report/report-system'
<gjanssens>gnc:module-load searches for a shared libary based on the name passed and then calls it's init routine
<gjanssens>The source of the shared module is here:
<wingo>is the error happening before the gnc:module-load is called?
<gjanssens>No. If I comment that line out, the file builds fine
<gjanssens>(guild compiles fine)
<wingo>comment out the gnc:module-load line or the line that uses N_ ?
<gjanssens>comment out gnc:module-load
<gjanssens>To reduce possible causes I have stripped the file report-collectors.scm to a bare minimum
<wingo>so what is the current error? :)
<gjanssens>The error is unchanged
<wingo>when you try to compile that file, what error do you get?
<gjanssens>Which file is that ? The report-collectors file ?
<wingo>the file from
<gjanssens>wingo ^
<wingo>ok so it's in the "prefs" file somehow
<gjanssens>wingo: prefs is here:
<gjanssens>It is loaded with load-from-path in app-utils.scm
<wingo>yes i see, and the error comes from there it seems
<gjanssens>If I remove prefs from the files being loaded the error shifts to business-prefs.scm which is loaded at the end of app-utils.scm
<gjanssens>New error:
<gjanssens>wingo: I wonder why the build didn't fail on date-utilities.scm which also makes use of the N_ macro and is loaded before business-prefs.scm ?
<gjanssens>What's different ?
<gjanssens>The difference seems to be in the inclusion of (use-modules (gnucash core-utils))
<gjanssens>If I add this in prefs.scm report-collectors continues to build successfully
*wingo has to go, ttyl
<gjanssens>Here's core-utils:
<gjanssens>I have no idea why that would make a difference
<gjanssens>ok ttly
<gjanssens>eh ttyl
<lloda>so I'd like to have the branch lloda-array-support merged in master. Any obstacles? I remember the scm_words thing when allocating the descriptor. Should I fix that? Also mark_weaver didn't like how I forced the test in the first patch but I don't remember why that was.
<gjanssens>hey wingo
<gjanssens>I got it fixed
<gjanssens>It was indeed a case of using load
<gjanssens>In particular:
<gjanssens>I compiled prefs.scm, so there was a prefs.go in the load-compiled path
*wingo looks at lloda-array-support
<gjanssens>However prefs.scm as an independent file didn't load the N_ syntax definition, so it probably had an unresolved symbol
<gjanssens>Later when app-utils.scm got evaluated, it did know the N_ syntax definition, but it somehow also tried to include the prefs.go that doesn't know about it
<gjanssens>I got a clue when I removed the prefs.go file as then it suddenly worked
<gjanssens>I have now rewritten the code slightly so that prefs.scm always knows about the N_ syntax definition
<gjanssens>Whether compiled independently or as part of app-utils.scm
<gjanssens>Thanks for sharing your brain. I'm progressing again :)
<wingo>lloda: to me it looks good in general. please check with mark_weaver what he thinks
<wingo>i think that last sentence was a spanglishism
<wingo>anyway :)
<wingo>gjanssens: complicated. sorry about that! anyways i'm glad it's working for you :)
<lloda>wingo: thanks, I'll do that.
<mark_weaver>lloda: my objection was moving all of the internal lexical variables to the top-level in order to cope with limitations of c&e.
<gjanssens>Heh, in a way self-compiling is a great help to clean up the code
<mark_weaver>I'd rather change the way c&e is implemented to be less restrictive. apologies for the delay on doing that.
<gjanssens>It forces us to be a little more disciplined
*rlb had no idea
<rlb>(for projects that still keep ChangeLogs...)
<mark_weaver>lloda: having looked again, I don't think the issue with c&e tests should block your patches. I'm okay with you pushing them.
<mark_weaver>lloda: thanks for your work on this!
<wingo>+1 :)
<mark_weaver>sneek: later tell lloda: having looked again, I don't think the issue with c&e tests should block your patches. I'm okay with you pushing them. thanks for your work on this!
<sneek>Will do.
<mark_weaver>sneek: botsnack