IRC channel logs
2014-10-29.log
back to list of logs
<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 <gjanssens>However I'm running into some "Wrong type to apply : #<syntax-transformer N_>" errors again <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>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 <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>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>GnuCash git works when I allow it to autocompile <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? <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 <wingo>we should have begin-for-syntax in guile <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... <wingo>the question to ask is "what defines N_" and then "how am I importing the definition of N_ in this module" <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 <wingo>is the error happening before the gnc:module-load is called? <gjanssens>No. If I comment that line out, the file builds fine <wingo>comment out the gnc:module-load line or the line that uses N_ ? <gjanssens>To reduce possible causes I have stripped the file report-collectors.scm to a bare minimum <wingo>so what is the current error? :) <wingo>when you try to compile that file, what error do you get? <gjanssens>Which file is that ? The report-collectors file ? <wingo>ok so it's in the "prefs" file somehow <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>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>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 <gjanssens>I have no idea why that would make a difference <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>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>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>git-merge-changelog! <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>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!