[GNC-dev] How to contribute to GnuCash?
Hello, I am the founder of a mobile app startup and a big fan of GnuCash. My team has some free time now. I wonder if we can contribute to develop an iOS companion app like current Android one. Can you let me know if you think that's a good idea? and if yes, how to start? Thanks, John -- Thanks for choosing our apps, Vicinno, www.vicinno.com Like us on Facebook <http://www.facebook.com/vicinno> or Follow us on Twitter <http://www.twitter.com/vicinno> ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] How to get Report Development Environment Working in Windows
I wasn't sure about Guile's understanding of MSDOS-style paths. Try converting
them to Cygwin style, e.g. set GUILE_LOAD_PATH="/c/Program Files
(x86)/gnucash/share/guile/2.2:/c/Program Files
(x86)/gnucash/share/guile/site/2.2". You might need to escape the spaces as
well, e.g. Program\ Files\ \(x86\).
Regards,
John Ralls
> On Sep 3, 2021, at 6:32 PM, flywire wrote:
>
> John, presumably you mentioned a guile instance because it's more efficient
> than the technique I asked about to reload reports without restarting
> GnuCash. That doesn't bring up a Win10 guile instance:
>
> C:\Users\User\AppData\Roaming\GnuCash>type guile-env.bat
> @ echo off
> REM
> https://lists.gnucash.org/pipermail/gnucash-devel/2021-September/045942.html
> <https://lists.gnucash.org/pipermail/gnucash-devel/2021-September/045942.html>
> set GUILE_LOAD_PATH="c:\Program Files
> (x86)\gnucash\share\guile\2.2;c:\Program Files
> (x86)\gnucash\share\guile\site\2.2"
> set GUILE__COMPILED_LOAD_PATH="c:\Program Files
> (x86)\gnucash\lib\guile\2.2\ccache;c:\Program Files
> (x86)\gnucash\lib\guile\2.2\site-ccache"
> path = "c:\Program Files (x86)\gnucash\bin";%PATH%
> C:\Users\User\AppData\Roaming\GnuCash>guile-env
>
> C:\Users\User\AppData\Roaming\GnuCash>guile
> Uncaught exception:
> Throw to key misc-error with args ("primitive-load-path" "Unable to find file
> ~S in load path" ("ice-9/boot-9") #f)Cannot exit gracefully when init is in
> progress; aborting.
>
> C:\Users\User\AppData\Roaming\GnuCash>dir /b
> accelerator-map
> books
> checks
> config-user.scm
> custom_import.scm
> custom_import_renderer.scm
> document-renderer.scm
> expressions-2.0
> gnucash-4.6
> gnucash-4.6.tar
> guile-env.bat
> my-world.scm
> prototype-loader.scm
> prototype-renderer.scm
> prototype.scm
> prototype_loader.scm
> saved-reports-2.8
> saved-reports-2.8-backup
> stylesheets-2.0
> test00.scm
> transaction.scm
> translog
> trep-engine.scm
>
>
> On Fri, Sep 3, 2021 at 10:48 AM John Ralls <mailto:jra...@ceridwen.us>> wrote:
>
> > On Sep 2, 2021, at 4:55 PM, flywire > <mailto:flywi...@gmail.com>> wrote:
> >
> > I'd like to use
> > https://wiki.gnucash.org/wiki/Custom_Reports#Development_Environment
> > <https://wiki.gnucash.org/wiki/Custom_Reports#Development_Environment> in
> > Win10. The Technique to reload reports without restarting GnuCash is not
> > working and I think the main problem is not following:
> >
> >> Finally, you should also extract a GnuCash source tar ball in
> > ~/GnuCash/CustomReport/ to have access to the Scheme files referenced in
> > this page.
> >
> > Does this mean extract the contents of gnucash-4.6.setup.exe
> > under %USERPROFILE%/GnuCash/CustomReport? Which files are actually needed
> > where (required path of one file as an example would be good)?
>
> Not exactly. A source tarball is an archive of the sources made with the Unix
> `tar` program; we distribute two variants, gnucash-4.6.tar.bz2 and
> gnucash-4.6.tar.gz; the trailing extensions indicate the compression method
> used.
>
> It looks like much of that page dates from GnuCash 2.6 that used an earlier
> version of Guile than we use now. You don't really need that though. What you
> need is to set up two environment variables, $Env:GUILE_LOAD_PATH and
> $Env:GUILE_COMPILED_LOAD_PATH:
>
> (Assuming Powershell)
> $Env:GUILE_LOAD_PATH="c:\Program Files
> (x86)\gnucash\share\guile\2.2;c:\Program Files
> (x86)\gnucash\share\guile\site\2.2"
> $Env:GUILE__COMPILED_LOAD_PATH="c:\Program Files
> (x86)\gnucash\lib\guile\2.2\ccache;c:\Program Files
> (x86)\gnucash\lib\guile\2.2\site-ccache"
>
> Also adjust your path to include "c:\Program Files (x86)\gnucash\bin"
>
> With that setup a guile instance run from that shell should be able to find
> all of the modules it needs. Note that none of this is needed for GnuCash to
> execute your config-user.scm as it sets up the paths for itself.
>
> Regards,
> John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Report with Fiscal Year
> On Sep 5, 2021, at 12:50 AM, flywire wrote: > > Any chance of a bit of a hand working through the add-option to get Fiscal > Year working in the code? I've tested everything else and it works. It'd be > a nice fix for Australians. > > gnc:make-date-option needs an optional parameter for year-start-month - > https://github.com/flywire/gnucash/blob/Fiscal-year/libgnucash/app-utils/options.scm#L683-L761 > > Typical code ( > https://github.com/flywire/gnucash/blob/Fiscal-year/libgnucash/app-utils/date-utilities.scm > ): > > (define* (gnc:get-end-cur-year #:key (start-month-fy 0)) > (let ((now (gnc-localtime (current-time >(set-tm:sec now 59) >(set-tm:min now 59) >(set-tm:hour now 23) >(set-tm:mday now 31) >(set-tm:mon now 11) >(if (< (tm:mon now) start-month-fy) > (set-tm:year now (tm:year now)) > (set-tm:year now (+ (tm:year now) 1))) >(set-tm:isdst now -1) >(gnc-mktime now))) Let's back up a bit. What do you mean by "fiscal year" and what exactly are you trying to do? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Report with Fiscal Year
OK. I know what the general definition of a fiscal year is. I used to be a US Navy supply officer and had to keep books "the Navy way" (as in "the right way, the wrong way, and the Navy way"). The US Government operates on a fiscal year running from 1 Oct to 30 Sept. (It used to be 1 July to 30 June but in 1974 Congress tried to give itself 3 extra months to get a budget and appropriations passed. The extra time didn't help, but there was a special 3-month fiscal year in 1976 called the T-year... funded under continuing resolution authority, of course). Flywire's bug reports and request here suggested to me that that wasn't what they meant so I asked. GnuCash uses the term Accounting Period for non-calendar fiscal years. There are two problems with this: First, it's in Preferences instead of File properties so a user can't have different books with different fiscal years and two users of the same book have to set their preferences to the same Accounting Period. Second and maybe worse it sets specific dates that don't roll over. Unfortunately Chris's PR attempts to address this in Scheme. While the options (but not preferences) including the file properties are partly implemented in Scheme (I have a substantial feature branch for the next major release that fixes that) for the most part Scheme code isn't visible to the C parts of the program and some of those (the summary bar and some Accounts page columns come immediately to mind) will also need to be adjusted to accommodate the change and of course the date stuff has to be somewhere that's visible to the C code. date-utilities.scm isn't that place. Moreover Chris's PR leaves the accounting period preference in place because as I said preferences are in C and Chris hadn't learned C when he wrote that PR. He's since--to his very great credit indeed--learned C and done some really good work fixing some long-standing memory leaks. Aside from the options code change that will be mostly invisible to users changing the Accounting Period from preferences to book options will be a breaking change for those who make use of it and will have to be guarded with a feature-flag: If you set a non-calendar-year repeating accounting period in GnuCash 5 it won't be loadable in GnuCash earlier than the last 4.x release. Until we can get all of that implemented I'm afraid that the best option is to continue to change the accounting period every year. Since this is the developer list it's worthwhile to discuss how a good rolling accounting period UI would look. If we assume that short years are exceptional and can be accommodated with absolute dates like the 1 July 1976 - 30 September 1976 T-year then we can also assume accounting periods are otherwise a full year, they just don't start 1 January. I see a lot of websites that use two combo boxes for this, the first with 1-31 for the day of the month and the other with the 12 months. Does that seem reasonable for GnuCash? The current Accounting Period UI allows for less than a year accounting periods with what to my eye are a bit weird alternatives: One can select independently an accounting period that e.g. begins at the beginning of last quarter and ends at the end of this month. IIUC that will create an accounting period that will vary in length from 3 to 6 months depending on the current month, which seems a good way to drive oneself nuts. I propose to remove that. Does anyone find it useful and if so how? Regards, John Ralls > On Sep 5, 2021, at 7:23 PM, flywire wrote: > > I see Chris has pushed a PR through which appears to provide this > functionality. I'd like to work on other reports too and this was a > learning exercise as much as anything. What it doesn't do is help me as a > community member develop skills with reports so I can work on those parts > of the software I see as a priority that others aren't interested in. > >> > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Report with Fiscal Year
Re C++, you and your professor are at least 10 years out of date. Since the publication of the C++11 standard C++ has become easily the most modern and versatile language available with the possible exception of Rust. Unlike Rust it is an ISO standard language with one of the largest and most active standards committees in the world and is consistently near the top of languages both in projects using it and programmers skilled in it. C on the other hand is 1970s technology and while they do have their own standards committee they're publishing new versions only every 10 years (to C++'s 3 year cycle) and most of the changes in the last cycle came from C++. As for "back into C++", you have that backwards too. Much of GnuCash was originally written in Scheme, but the early developers realized that Scheme isn't a very good language for serious programming. There's a section of the Guile manual titled "Why Scheme is a better language for hacking". Well, hacking is fine for quick-and-dirty-use-once-or-twice code but as you no doubt know it's a terrible idea for code that will be distributed to ordinary users or maintained over decades. The options rewrite is the next step in our long-term goal of completely removing Scheme from GnuCash. Modularity is good, yes. Unfortunately not everyone writing GnuCash code has understood that and Linas's careful design has become a rather large bowl of spaghetti code. Fixing that is another long term goal. Regards, John Ralls > On Sep 6, 2021, at 1:54 AM, flywire wrote: > > I recall recent discussion about separating the main app and reporting. > App, database and reporting modules seem to offer a lot of scope for > non-traditional integrations I've raised before. One of my repos uses ocr > to load bank statements, and there's an ever-expanding range of smart > analysis tools. > > I'm concerned John's described pulling report functionality back into c++. > > It's a while since I worked as a programmer but I've been involved in a > broad range of system development. I was after a c++ developer a couple of > years ago and a university lecturer told me they'd stopped teaching it a > few years earlier. He said to concentrate on the functionality and let the > implementation move with the technology. M a y b e GnuCash is. The > application doesn't need to run on 1990 technology anymore. > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Report with Fiscal Year
https://wiki.gnucash.org/wiki/Roadmap#Reports <https://wiki.gnucash.org/wiki/Roadmap#Reports> Christian Stimming wrote the last paragraph about replacing Scheme in 2011. Regards, John Ralls > On Sep 6, 2021, at 4:41 AM, Christopher Lam wrote: > > Where is it mentioned that reports are being converted to c++? > > There is currently a separation between libgnucash (eg the engine and > backend database) and gnucash (eg the UI, reports, import/export). There is > a drive to remove guile from libgnucash. This may allow libgnucash to be > used in iOS for example. > > On Mon, 6 Sept 2021 at 08:55, flywire wrote: > >> I recall recent discussion about separating the main app and reporting. >> App, database and reporting modules seem to offer a lot of scope for >> non-traditional integrations I've raised before. One of my repos uses ocr >> to load bank statements, and there's an ever-expanding range of smart >> analysis tools. >> >> I'm concerned John's described pulling report functionality back into c++. >> >> It's a while since I worked as a programmer but I've been involved in a >> broad range of system development. I was after a c++ developer a couple of >> years ago and a university lecturer told me they'd stopped teaching it a >> few years earlier. He said to concentrate on the functionality and let the >> implementation move with the technology. M a y b e GnuCash is. The >> application doesn't need to run on 1990 technology anymore. >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash-devel Digest, Vol 222, Issue 6
> On Sep 6, 2021, at 12:22 PM, Borden via gnucash-devel > wrote: > > > >> I see references/comments in the PR referring to ?Fiscal? year. Just my >> view but ?Fiscal? seems to be one of those terms that are rarely used by >> anyone except federal treasurers and finance reporters. Perhaps more >> understandable to use FinYear / FinancialYear or similar. >> > Well, "Fiscal Year" is the proper terminology in IFRS and US GAAP in the same > way that "Assets", "Liabilities", "Equity", "Debits" and "Credits" are. So, > unless you want to confuse and irritate people who've been raised to use the > official terminology, I'd avoid using the "layman's terminology." > > And fiscal year support is something that transcends the Australian tax > system. Entities are free to pick their own fiscal year and, in fact, are > encouraged to pick one _after_ their busy season so there are fewer > distractions when they do their closing procedures. > > So every GNUCash file really should track the entity's year-end (defaulting > to the calendar) and adjust reports accordingly by default. That how I learnt > accounting, at least. Yeah, me too. I agree with the premise, it's the practical issues of making it happen that are in the way. It's not as trivial a change as it might seem. Formal vs. layman terminology--or behavior for that matter--is a constant tension in GnuCash. AFAIK none of the developers has formal accounting training past one or two college courses; most rather less. Even fewer of the user base have any formal accounting training at all and so we try to be very gentle about using formal accounting jargon: For example one must override a default preference to see Debit and Credit column headings instead of Deposit and Withdrawal. I guess Fiscal Year vs. Accounting Period falls in the same bucket except that nobody's ever added Fiscal Year to the formal accounting labels in GnuCash. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Generic Import Transaction Matcher separation of front end and backend
> On Sep 8, 2021, at 2:26 AM, Chris Good wrote: > > I'm adding an "Append" checkbox to the bottom of the matcher which the user > can set to enable the > > imported Description to be appended to the Description on the matched > transaction, rather than overriding it. > > > > I've added a pointer (append_text) to the checkbox widget to the > _main_matcher_info struct defined in import-main-matcher.c. > > > > GNCImportMainMatcher is defined in import-main-matcher.h: > >typedef struct _main_matcher_info GNCImportMainMatcher; > > > > What's the right way to enable gnc_import_process_trans_item() in > import-backend.c to use > > gtk_toggle_button_get_active (_main_matcher_info->append_text) and still > keep the existing separation between the > > front and back ends? You're thinking in the wrong direction: You need to go in the other direction: Add a gboolean member to GNCTransInfo and set it in import-main-matcher before calling gnc_import_process_trans_item, which will test your new member and append or replace according to its value. > > > > I guess it is wrong to move the definition of _main_matcher_info to > import-main-matcher.h > > and then include import-main-matcher.h in import-backend.c? It sure would. That would create a circular dependency. We have enough spaghetti already. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Runtime issue with gwenhywfar and aqbanking libraries
> On Sep 12, 2021, at 7:04 AM, Lothar Paltins via gnucash-devel > wrote: > > Hi, > > I'm compiling gnucash 4.6 with the following commands: > > export > PKG_CONFIG_PATH=/opt/gwenhywfar/lib64/pkgconfig:/opt/aqbanking/lib64/pkgconfig > mkdir build > cd build > cmake -DCMAKE_INSTALL_PREFIX=/opt/gnucash .. > make > sudo make install > > It succeeds, /opt/gnucash/bin/gnucash is installed and it works, but there > are no online banking functions available. I found out, that gnucash can't > find the gwenhywfar and aqbanking libraries. It seems, that setting > PKG_CONFIG_PATH isn't sufficient. If I copy all shared libraries from > /opt/aqbanking/lib64 and /opt/gwenhywfar/lib64 to /opt/gnucash/lib64/gnucash, > then everything works as expected. Is there a way to specify the aqbanking > and gwenhywfar library paths and to avoid the copying of the libraries? Did you forget to add /opt/gwenhywfar/lib64 and /opt/aqbanking/lib64 to LD_LIBRARY_PATH so that the dynamic linker can find the libraries at runtime? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Runtime issue with gwenhywfar and aqbanking libraries
> On Sep 13, 2021, at 5:45 AM, Lothar Paltins via gnucash-devel > wrote: > > John, > > thanks for your answer. > >> Did you forget to add /opt/gwenhywfar/lib64 and /opt/aqbanking/lib64 to >> LD_LIBRARY_PATH so that the dynamic linker can find the libraries at runtime? > > No, I didn't 'forget' it. Specifying the paths in LD_LIBRARY_PATH makes it > work, as well as adding them to the run-time linker cache with ldconfig. But > I was looking for a way to add these directories to the runtime library > search path of the executable. I think, it's more convenient, if an > executable finds its libraries without any special runtime configuration as > long as these libraries are in the same directory as at compile time. OK. To learn about that you need to read up on rpath. CMake's wiki article https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling <https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling> is a good place to start. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GUI SQL Reports
> On Sep 24, 2021, at 9:58 PM, flywire wrote: > > I've looked around at free GUI SQL report writers and haven't come up with an > alternative to Base. It's barely acknowledged as part of the suite, had > little development, fugly, with suspect reliability, eg formatting on view > columns isn't saved. SQL dialects vary a bit but the GnuCash accounts tree in > SQL moves it out of basic SQL. > > 1. Any comments about storing foreign keys in the database? > 2. Any guidance on how to use dates stored as text fields? By default, Base > only recognises the characters. > > E:\BOOKS>\sqlite\sqlite3 empty.gnucash > SQLite version 3.36.0 2021-06-18 18:36:39 > Enter ".help" for usage hints. > sqlite> .tables > accounts customers lots splits > billterms employees orderstaxtable_entries > books entries pricestaxtables > budget_amountsgnclock recurrences transactions > budgets invoices schedxactions vendors > commodities jobs slots versions > sqlite> .schema transactions > CREATE TABLE transactions(guid text(32) PRIMARY KEY NOT NULL, currency_guid > text(32) NOT NULL, num text(2048) NOT NULL, post_date text(19), enter_date > text(19), description text(2048)); > CREATE INDEX tx_post_date_index ON transactions(post_date); > > > On Thu, Jun 3, 2021 at 10:47 AM John Ralls <mailto:jra...@ceridwen.us>> wrote: > For playing around: It's a bit of a lash-up but you can use Microsoft Access > or Open/LibreOffice Base with SQLite3 via an ODBC driver. Both have QBE, > though Microsofts is (as usual) a lot more polished. What about storing foreign keys? There are lots of them, they're just not marked as such in the table definitions because we don't yet use the database that way. It's probably that SQLite3 doesn't have a date type, it stores them as a sort of ISO8601 strings with no punctuation. MySQL/MariaDB and Postgresql have proper date types. If Base doesn't have a built-in parser you'll have to write one. ISTR that there are Python and Java bindings for LibreOffice. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash 4.7 Released
David, The problem is that schemes.compiled doesn't have the new org.gnucash.GnuCash paths. Or rather didn't, because running glib-compile-schemas again should have added that and you should now be able to run GnuCash. Can you check that? Geert and I were working with another user on IRC this afternoon (well, my afternoon). That user used make and I just tested and found that make produced the result you get while ninja produced the result I get. But you say you're using ninja so so much for that hypothesis. Regards, John Ralls > On Sep 27, 2021, at 6:39 PM, davidcousen...@gmail.com wrote: > > Hi John, > > $strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep > dialogs.import.hbci > (b)org.gnucash.dialogs.import.hbci > /org/gnucash/dialogs/import/hbci/ > org.gnucash.dialogs.import.hbci.connection-dialog > org.gnucash.dialogs.import.hbci.connection-dialog > /org/gnucash/dialogs/import/hbci/connection-dialog/ > > > $ sudo glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/ > returns no erors > > The build directory was cleaned with rm -rf before rebuilding and then a rerun > of the cmake, ninja and sudo ninja install. > > Cheers > > David > > On Mon, 2021-09-27 at 18:05 -0700, John Ralls wrote: >> David, >> >> Does >> strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep >> dialogs.import.hbci >> return >> (i)org.gnucash.dialogs.import.hbci >> /org/gnucash/dialogs/import/hbci/ >> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >> /org/gnucash/GnuCash/dialogs/import/hbci/connection-dialog/ >> org.gnucash.dialogs.import.hbci.connection-dialog >> /org/gnucash/dialogs/import/hbci/connection-dialog/ >> org.gnucash.GnuCash.dialogs.import.hbci >> /org/gnucash/GnuCash/dialogs/import/hbci/ >> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >> >> If you run >> glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/ >> do you get an error? >> >> By "cleaned the build directory" do you mean "rm -rf *" or "ninja clean"? >> >> Regards, >> John Ralls >> >> >> >>> On Sep 27, 2021, at 2:25 PM, David Cousens wrote: >>> >>> Hi Geert, >>> I hadn't tried to run gnucash from the build directory, only the installed >>> directories under /usr/local. >>> Applied the patch, uninstalled the previous install, cleaned the build >>> directory and rebuilt 4.7. Again no problems with cmake or ninja or the >>> install itself but the same problem when running gnucash. I've attached the >>> trace file and the patched gschema file. >>> $ gnucash --debug >>> Trace/breakpoint trap (core dumped) >>> >>> On Mon, 27 Sept 2021 at 17:21, Geert Janssens >>> wrote: >>> >>>> Hi David, >>>> >>>> This is definitely a crasher bug that unfortunately managed to slip passed >>>> our >>>> testing. I am surprised the warning only happens when installing gnucash, >>>> not >>>> while building it. Likewise you can run GnuCash just fine from the build >>>> directory but not from the install path. >>>> >>>> I'll push a fix but unfortunately this probably means we need to do a >>>> hotfix >>>> release (4.7.1). I'll let John decide. >>>> >>>> I have attached a patch. Can you try to apply this to your tarball and see >>>> if >>>> t hat fixes the problem ? It does for me. >>>> >>>> Regards, >>>> >>>> Geert >>>> >>>> Op maandag 27 september 2021 03:27:02 CEST schreef >>>> davidcousen...@gmail.com: >>>>> Hi John >>>>> >>>>> Encountered a runtime problem with GC 4.7 on Linux MInt 20.2 built from >>>> the >>>>> downloaded tarball. There were no obvious problems with the cmake and >>>> ninja >>>>> runs and only the following warning running sudo ninja install ( to >>>>> /usr/local). >>>>> >>>>> Compiling gschema files in /usr/local/share/glib-2.0/schemas >>>>> Warning: undefined reference to >>>> id='org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog'/> >>>>> >>>>> the program bombs out when I try to run it with the following in the >>>>> gnucash.trace file:
Re: [GNC-dev] GnuCash 4.7 Released
David, Thanks for the followup, but *please* copy the list! This is information of general interest. Regards, John Ralls > On Sep 28, 2021, at 4:35 AM, davidcousen...@gmail.com wrote: > > > Hi John, > > Yes the glib compile command fixed the problem and 4.7 is now running without > any errors and appears to be OK. Thanks for the help. > Regards > David > > On Mon, 2021-09-27 at 20:04 -0700, john wrote: >> David, >> >> The problem is that schemes.compiled doesn't have the new org.gnucash.GnuCash >> paths. Or rather didn't, because running glib-compile-schemas again should >> have added that and you should now be able to run GnuCash. Can you check >> that? >> >> Geert and I were working with another user on IRC this afternoon (well, my >> afternoon). That user used make and I just tested and found that make >> produced >> the result you get while ninja produced the result I get. But you say you're >> using ninja so so much for that hypothesis. >> >> Regards, >> John Ralls >> >> >>> On Sep 27, 2021, at 6:39 PM, davidcousen...@gmail.com wrote: >>> >>> Hi John, >>> >>> $strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep >>> dialogs.import.hbci >>> (b)org.gnucash.dialogs.import.hbci >>> /org/gnucash/dialogs/import/hbci/ >>> org.gnucash.dialogs.import.hbci.connection-dialog >>> org.gnucash.dialogs.import.hbci.connection-dialog >>> /org/gnucash/dialogs/import/hbci/connection-dialog/ >>> >>> >>> $ sudo glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/ >>> returns no erors >>> >>> The build directory was cleaned with rm -rf before rebuilding and then a >>> rerun >>> of the cmake, ninja and sudo ninja install. >>> >>> Cheers >>> >>> David >>> >>> On Mon, 2021-09-27 at 18:05 -0700, John Ralls wrote: >>>> David, >>>> >>>> Does >>>> strings /usr/local/share/glib-2.0/schemas/gschemas.compiled | grep >>>> dialogs.import.hbci >>>> return >>>> (i)org.gnucash.dialogs.import.hbci >>>> /org/gnucash/dialogs/import/hbci/ >>>> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >>>> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >>>> /org/gnucash/GnuCash/dialogs/import/hbci/connection-dialog/ >>>> org.gnucash.dialogs.import.hbci.connection-dialog >>>> /org/gnucash/dialogs/import/hbci/connection-dialog/ >>>> org.gnucash.GnuCash.dialogs.import.hbci >>>> /org/gnucash/GnuCash/dialogs/import/hbci/ >>>> org.gnucash.GnuCash.dialogs.import.hbci.connection-dialog >>>> >>>> If you run >>>> glib-compile-schemas --strict /usr/local/share/glib-2.0/schemas/ >>>> do you get an error? >>>> >>>> By "cleaned the build directory" do you mean "rm -rf *" or "ninja clean"? >>>> >>>> Regards, >>>> John Ralls >>>> >>>> >>>> >>>>> On Sep 27, 2021, at 2:25 PM, David Cousens >>>>> wrote: >>>>> >>>>> Hi Geert, >>>>> I hadn't tried to run gnucash from the build directory, only the >>>>> installed >>>>> directories under /usr/local. >>>>> Applied the patch, uninstalled the previous install, cleaned the build >>>>> directory and rebuilt 4.7. Again no problems with cmake or ninja or the >>>>> install itself but the same problem when running gnucash. I've attached >>>>> the >>>>> trace file and the patched gschema file. >>>>> $ gnucash --debug >>>>> Trace/breakpoint trap (core dumped) >>>>> >>>>> On Mon, 27 Sept 2021 at 17:21, Geert Janssens < >>>>> geert.gnuc...@kobaltwit.be> >>>>> wrote: >>>>> >>>>>> Hi David, >>>>>> >>>>>> This is definitely a crasher bug that unfortunately managed to slip >>>>>> passed >>>>>> our >>>>>> testing. I am surprised the warning only happens when installing >>>>>> gnucash, >>>>>> not >>>>>> while building it. Likewise you can run GnuCash just fine from the >>>>>> build >>>>>> directory but not from the install path. >>>
Re: [GNC-dev] GnuCash 4.7 Released
> On Sep 28, 2021, at 5:55 PM, Chris Good wrote: > > > Message: 1 > Date: Tue, 28 Sep 2021 12:20:57 +0200 > From: Geert Janssens > To: davidcousen...@gmail.com, gnucash-devel@gnucash.org > Cc: GnuCash Developers , john > > Subject: Re: [GNC-dev] GnuCash 4.7 Released > Message-ID: <4683663.31r3eyu...@legolas.kobaltwit.lan> > Content-Type: text/plain; charset="iso-8859-1" > > What I thought to be the problem yesterday turned out to only be an indirect > indication of the problem. I now blame a subtle change in the build order to > be the actual source of the issue. > > I have applied a fix to maint, which seems to work well in all my tests > (both building with ninja or make). It would be helpful if others can build > our current maint branch report their results here as well. > > Regards, > > Geert > > Hi Geert, > > I've just recreated my main maint repo (head is now d561cc6) and build in > eclipse fails: > ... > 369/956] Generating > org.gnucash.GnuCash.window.pages.account.tree.gschema.valid > [370/956] Generating ../../share/gnucash/migratable-prefs.xml > FAILED: share/gnucash/migratable-prefs.xml > cd /home/cgood/gnucash-maint/build/gnucash/gschemas && /usr/bin/cmake -E cat > /home/cgood/gnucash-maint/src/gnucash/import-export/aqb/gschemas/migratable- > prefs.xml > /home/cgood/gnucash-maint/src/gnucash/import-export/ofx/gschemas/migratable- > prefs.xml > /home/cgood/gnucash-maint/src/gnucash/gschemas/migratable-prefs.xml > > /home/cgood/gnucash-maint/build/share/gnucash/migratable-prefs.xml > CMake Error: cmake version 3.16.3 > Usage: /usr/bin/cmake -E [arguments...] > Available commands: > capabilities - Report capabilities built into cmake in JSON > format > chdir dir cmd [args...] - run command in a given directory > compare_files [--ignore-eol] file1 file2 > - check if file1 is same as file2 > copy ... destination - copy files to destination (either file or > directory) > copy_directory ... destination - copy content of ... > directories to 'destination' directory > copy_if_different ... destination - copy files if it has changed > echo [...]- displays arguments as text > echo_append [...] - displays arguments as text but no new line > env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]... >- run command in a modified environment > environment - display the current environment > make_directory ... - create parent and directories > md5sum ... - create MD5 checksum of files > sha1sum ... - create SHA1 checksum of files > sha224sum ... - create SHA224 checksum of files > sha256sum ... - create SHA256 checksum of files > sha384sum ... - create SHA384 checksum of files > sha512sum ... - create SHA512 checksum of files > remove [-f] ... - remove the file(s), use -f to force it > remove_directory ... - remove directories and their contents > rename oldname newname- rename a file or directory (on one volume) > server- start cmake in server mode > sleep ... - sleep for given number of seconds > tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2 ...] >- create or extract a tar or zip archive > time command [args...]- run command and display elapsed time > touch ... - touch a . > touch_nocreate ... - touch a but do not create it. > create_symlink old new- create a symbolic link new -> old > true - do nothing with an exit code of 0 > false - do nothing with an exit code of 1 > > [371/956] Generating org.gnucash.GnuCash.window.pages.gschema.valid > [372/956] Generating > ../../share/guile/site/2.0/gnucash/engine/commodity-table.scm > [373/956] Generating swig-core-utils-guile.c > [374/956] Linking CXX shared library lib/libgnc-engine.so > [375/956] Generating gnucash.desktop.in > ninja: build stopped: subcommand failed. > "/usr/bin/ninja all" terminated with exit code 1. Build might be incomplete. > > 10:31:36 Build Finished. 0 errors, 0 warnings. (took 41s.326ms) > > Full log attached. > I see immediately afterwards, John pushed 29e7b07 Remove superfluous > schema_source left over from pasting, so I pulled that too but same error. > Chris, Please read the GnuCash 4.8 Released thread with David Cousens for the workaround. Re ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] warning: 'gtk_action_set_sensitive' is deprecated [-Wdeprecated-declarations] And gtk4
> On Oct 5, 2021, at 9:54 PM, Chris Good wrote: > > Hi John Ralls, > > > > I'm following up on the your suggestion that it should not be possible to > start another import while another is already running. > > > > When I added gtk_action_set_sensitive() the compiler says: > > /home/cgood/gnucash-maint/src/gnucash/import-export/ofx/gnc-plugin-ofx.c:121 > :5: warning: 'gtk_action_set_sensitive' is > > deprecated [-Wdeprecated-declarations] > > > > but I see in maint, that function is used in many places but with > > -Wno-deprecated-declarations > > in the CMakeLists.txts to ignore this warning. > > > > https://docs.gtk.org/gtk3/class.Action.html : > > In GTK+ 3.10, GtkAction has been deprecated. Use GAction > instead, and associate actions with GtkActionable widgets. > > Use GMenuModel for creating menus with > gtk_menu_new_from_model(). > > > > There are NO mentions of GMenuModel in current maint or master. > > > > Should I just continue with gtk_action_set_sensitive and add > -Wno-deprecated-declarations to CMakeLists.txt? > > > > Is there a plan to migrate to GAction? Is that going to be a huge task? > > > > I haven't seen any discussion about going to gtk4. Is that not a huge task > like gtk2 to gtk3? Nobody's told me of undertaking the effort to rework the GUI for Gtk4, and I think Geert is somewhat opposed to it because we want to consider converting to another graphics framework at some point. There's no need to rush, Gtk3 will continue in maintenance mode for several more years. Consider that The GIMP (which is the "G" in Gtk) is still working on their Gtk3 conversion. IMO it would be far more useful to work on MVC separation in the GUI directories than on modernizing GtkActionGroup and GtkMenu usage. We don't want no-deprecated-declarations, that might silence something from another library that we'd need to know about. I think there's a Gtk or Glib macro to silence those particular deprecation warnings. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] bug 798366 - cross-currency capital gains
nges; the code that > decides to mark capital gains as "dirty" needs to be made > currency-aware, and the code that changes the capital gains split > should reset the income account of the capital gains > transaction. Haven't looked into that yet. TOOD. Sorry I didn't intervene sooner. You need to read through https://bugs.gnucash.org/show_bug.cgi?id=797796 <https://bugs.gnucash.org/show_bug.cgi?id=797796> before doing any more work because your approach doesn't support the GAAP/IAS requirements. Much of the rest of GnuCash doesn't either, but there's no point in doing a lot of work that doesn't move us in the direction of being legal. To your specific questions: 1. assert vs. g_assert: Doesn't really matter, they do the same thing. Neither is particularly useful in production code because they're macros that are disabled in release builds. They're useful for catching programming errors with unit tests. Your patch doesn't have any of those so there's no point in asserting anything. If you need to do things like null-checks to prevent crashes use g_return_if_fail or g_return_value_if_fail, which log a critical error and return, preventing the crash. 2. We make no stability guarantees for libgnucash at present. We have a long-term goal to do so, but the current API is rather haphazard and needs substantial clean up before we'd be willing to do so. It also has serious memory-management issues when used outside of the application so part of the required work is to rewrite the whole thing in C++, replacing the already incorrect GObject implementation. This has been discussed at great length over the last 10-12 years. If you're interested you can look through the mailing list archives. 3. There's already a struct combining commodity with gnc_numeric amount called gnc_monetary, declared in libgnucash/engine/gnc-commodity.h. 4a. The GAAP/IAS requirement is that all transactions get valued in the book's home currency on the day of the transaction using either an actual exchange rate if funds were converted that day or an average rate for the day if they weren't. One of the participants in bug 797796, CDB-Man, is a licensed accountant. The discussion on that bug is quite comprehensive and I won't attempt to summarize it. It's actually a pretty substantial simplification over what you've planned. 4b. Yes, GnuCash has a backward compatibility policy and a GncFeature component (libgnucash/engine/gnc-feature.[hc]) to test whether an older version of GnuCash can safely work with a book. 4c. Apropos the book property proposal, do you know about and understand Trading Accounts? Enabling use of trading accounts changes the behavior of the register in multi-commodity transactions. Neither cap-gains.c nor dialog-lot-viewer.c check for using trading accounts; perhaps they should. 5. I'm not sure what you mean here. If the code doesn't mark the splits dirty then they won't get saved in the SQL backends and all of your changes are for naught. If you mean that nothing marks the capital gain needing to be recomputed if the user edits the sell transaction that's OK, re-running the lot scrub from the dialog will find the imbalance and create an additional split. Some general observations: First, it will be far more productive for both of us if you'll resubmit your patch as a Github pull request. Code reviewing patch files in bug reports and keeping track of the changes is quite painful, and the larger the patch is the more painful managing the reviews and review comment corrections gets. No patch containing commented code is acceptable. Remove it instead. It makes the diff more understandable and prevents the accumulation of cruft. As evidenced by bug 797796 and the bugs you've created and commented on in the last few days this problem is quite a bit bigger than just the lot scrubber. Addressing it piecemeal, particularly with piecemeal design goals, will just add to the huge amount of technical debt we have already. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] SEPA internal transfer
> On Nov 19, 2021, at 1:02 AM, Stefan Bayer > wrote: > > Hi all, > > I recently implemented the SEPA internal transfer (SEPA Übertrag) in > aqbanking and now took the liberty to also amend the aqbanking functionality > in gnucash to support this. > > In case of a SEPA internal transfer the information of possible target > accounts is provided by aqbanking, so in this case the transfer form does not > allow to enter the bank information directly but the template list is reused > as a list of possible target accounts for the internal transfer. I hope I > have tested it well enough, I am already been using the functionality here > for a few weeks without problems. > > I followed your guidelines and set up a Github clone for my changes, is it ok > to just issue the pull request for this? Or do I need to do something else? Just make a pull request. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Investment position from OFX files
So I guess you could use it to trigger the "There's balance information in the import, do you want to use it?" dialog and feed the units into the reconcile information dialog. I wouldn't think it worth the effort, but I'm not the sort to spend hours automating something that takes a few seconds once a month to do manually. Regards, John Ralls > On Nov 30, 2021, at 4:07 PM, Jean Laroche wrote: > > Yes, both of the brokers I use export to OFX and include position data with > units, unit price, and market value (of which only the units is really > relevant to GC). > > > On 11/30/21 3:22 PM, John Ralls wrote: >> >>> On Nov 30, 2021, at 2:19 PM, Jean L wrote: >>> >>> Devs, >>> >>> I was looking inside *libofx *and saw that a new callback has been added >>> *ofx_set_position_cb *which can be use to gain information about security >>> positions. >>> (2021-01-03, LibOFX 0.10.0) >>> >>> I think it'd be really useful to add this to gnc-ofx-import.c as currently, >>> reconciling security positions can only be done manually even when >>> importing transactions from an OFX file. >>> Do you guys think it's a waste of time? Useful? >> Very few of the elements in a struct OfxPositionData >> (https://github.com/libofx/libofx/blob/56e12a3016072204b771d0c4b0d2f4e5a4568a0e/inc/libofx.h.in#L1161) >> seem relevant to GnuCash. >> >> Does your broker export OFX files with INVPOS elements? If not it will be >> hard for you to test and harder still to make much use of it. FWIW mine >> (Charles Schwab) exports only CSV. >> >> Regards, >> John Ralls >> ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h
Geert, This is hilarious. In that post Mr. Braam says that he maintains his Megapixels project on SourceHut. Follow the link. Right at the top it says "The development and maintainership of Megapixels has been moved to gitlab.com/postmarketos/megapixels <http://gitlab.com/postmarketos/megapixels>"! That aside, the workflow promoted there depends on hosting at SourceHut; it's (not Free or even open source AFAICT) software is what provides the patch tracker. I do agree with him about the merge button, though, and don't use it even on those projects where the Github/Gitlab repo is the canonical one and it would work. I nearly always want to do a local check before I make a merge public, especially since both the author and CI built and tested the *unmerged* commits. I'm a little puzzled by your complaint about git am saving you context switches. Have you tried `git pull --no-ff https://github.com/user/gnucash/ <https://github.com/user/gnucash/> pr-branch`? You can copy and paste the line (minus the --no-ff) directly from the Github Conversation tab after clicking the "command line instructions" link (don't follow the instructions, most of the steps are unnecessary). If you prefer to do that in a local branch then be sure to change the merge commit message to say "into maint" so that you can ff-merge the local branch into maint. While searching for software to track mailing list patch submissions I found this: https://lwn.net/Articles/860607/ <https://lwn.net/Articles/860607/>, "Pulling GitHub into the kernel process". It's an interesting discussion of lots of alternatives that the kernel teams are considering. https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html <https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html> is another interesting post that mentions https://github.com/getpatchwork/patchwork <https://github.com/getpatchwork/patchwork> for tracking patch status from a mailing list. I found only one other, https://github.com/lu-zero/plaid <https://github.com/lu-zero/plaid>, which says it's a patchwork derivative. Regards, John Ralls > On Dec 6, 2021, at 8:20 AM, Geert Janssens wrote: > > Well, it wasn't just Kevin's patch submission by mail that triggered my > reaction. > > I recently also read this blog post > https://blog.brixit.nl/git-email-flow-versus-github-flow/ > <https://blog.brixit.nl/git-email-flow-versus-github-flow/> > Though as it didn't really apply to gnucash directly I only read it > superficially back then. Rereading it more closely I gather the git mail > process can be made more attractive by adding a web-based tool that displays > mailing list messages in a way optimized for typical git mail conversations. > I'll also note the author apparently is allergic to merge commits which we > are not so his heavy focus on that argument is a little weak. > > I'm not really interested in promoting such an approach. It did trigger an > academic curiosity towards it though as it seems to have it's own distinct > advantages and drawbacks. > > I'll elaborate on what I perceive just for the sake of provoking thoughts. > > For example, the author refers to github's merge facility (which is in his > opinion subpar as it generates merge commits). We can't actually use that as > we have declared our repos on code to be the master repos. Yet as I'm usually > working on the command line to steer git, using git am to apply mail patches > would save me a number of context switches. > From a user point of view that same command line efficiency is possible with > git mail. In addition not everyone wants to have an account on github for > various reasons, but I presume those same people are willing to send mails > directly to the project. > > Specifically to your first objection (large complex patches needing much > discussion). I didn't suggest to make it the only or even the primary channel > to submit patches. We could still request a formal PR on github if the patch > becomes too complex or rely on the suggested web-based tool to make that > process easier for us. > > Clearly there are also downsides. Firstly there is the maintenance of yet > another website. Additionally much of the benefit of direct mail workflow is > gone if you still have to visit a website to be able to follow the review > conversation... > > And with that I'll step down from my soapbox :) > I do not plan to pursue this further myself as I don't think there's enough > net benefit for gnucash. > > Regards, > > Geert > > Op zondag 5 december 2021 23:17:41 CET schreef John Ralls: > > Geert, > > >
Re: [GNC-dev] Small changes to comment text, mostly in gnucash/import-export/import-main-matcher.h
> On Dec 6, 2021, at 11:02 AM, Frank H. Ellenberger > wrote: > > …and the bug report is? https://bugs.gnucash.org/show_bug.cgi?id=798382 <https://bugs.gnucash.org/show_bug.cgi?id=798382> Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Just curious, images to file or MySQL
> On Dec 7, 2021, at 1:40 AM, Jeff wrote: > > Since GNC is based on XML and MySQL, how hard would it be to upgrade to link > the code to a MySQL database format for document saving (i.e.check images) > instead of just an XML hard link to a file? > > Even though there seems to be a limit on the number of transactions that you > can convert from XML to MySQL. 3 years works, 30 doesn't. I have 30+ in my > ledger and cannot get it to convert from XML to MySQL. My dad's only has less > than 4 years and converts fine to MySQL. > > Saving to an image file currently limits you to one drive and a specific > file. MySQL would allow saving to wherever the database of images exists as > a list of blobs. Hard drive upgrades would be much simpler. > > Again just curious. There is no programmatic limit in GnuCash on the number of transactions that GnuCash can store using the MySQL backend, so you're most likely hitting some limitation on the server side. You can run GnuCash with --log gnc.backend.sql=debug to get details of the insert queries and server error responses; combined with your MySQL logs you should be able to pretty quickly diagnose the problem. If you find that GnuCash's backend is doing something dumb please file a bug. As for document image links they're URIs so you can put them anywhere that you can access with a URI. A web server on your LAN is an easy to implement option. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Just curious, images to file or MySQL
> On Dec 7, 2021, at 10:27 PM, Jeff wrote: > > On 12/7/21 11:38 AM, john wrote: >> >>> On Dec 7, 2021, at 1:40 AM, Jeff wrote: >>> >>> Since GNC is based on XML and MySQL, how hard would it be to upgrade to >>> link the code to a MySQL database format for document saving (i.e.check >>> images) instead of just an XML hard link to a file? >>> >>> Even though there seems to be a limit on the number of transactions that >>> you can convert from XML to MySQL. 3 years works, 30 doesn't. I have 30+ >>> in my ledger and cannot get it to convert from XML to MySQL. My dad's only >>> has less than 4 years and converts fine to MySQL. >>> >>> Saving to an image file currently limits you to one drive and a specific >>> file. MySQL would allow saving to wherever the database of images exists >>> as a list of blobs. Hard drive upgrades would be much simpler. >>> >>> Again just curious. >> There is no programmatic limit in GnuCash on the number of transactions that >> GnuCash can store using the MySQL backend, so you're most likely hitting >> some limitation on the server side. You can run GnuCash with --log >> gnc.backend.sql=debug to get details of the insert queries and server error >> responses; combined with your MySQL logs you should be able to pretty >> quickly diagnose the problem. If you find that GnuCash's backend is doing >> something dumb please file a bug. >> >> As for document image links they're URIs so you can put them anywhere that >> you can access with a URI. A web server on your LAN is an easy to implement >> option. >> >> Regards, >> John Ralls >> >> . > > I understand the direct link to a file or URL but; how does one specify a URI? URI means Uniform Resource Identifier, see https://en.wikipedia.org/wiki/Uniform_Resource_Identifier <https://en.wikipedia.org/wiki/Uniform_Resource_Identifier>. It's a more general term than URL, or Uniform Resource Locator. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Trouble with gsettings in GC 4.9
Christian, Try uninstalling 4.7 again, then make sure that /opt/share/glib-2.0/schemas and /usr/share/glib-2.0/schemas contain no files whose names begin with `org.gnucash', then reinstall 4.9. Regards, John Ralls > On Dec 28, 2021, at 7:50 AM, Christian Wehling wrote: > > Hi, > I have tried all this: > I started with a working version 4.7, did a 'sudo make uninstall' and > then installed versions 4.8 and 4.9 with 'sudo make install' and 'sudo > ninja install'. Unfortunately, both versions were unsuccessful. > > The Output from 4.8 and 4.9: > * 16:29:33 INFO [gnc_load_app_icons] Path 19: > /usr/share/pixmaps > * 16:29:33 INFO [gnc_load_app_icons] Path 20: > /opt/gnucash/share/gnucash/icons > * 16:29:33 INFO [gnc_load_app_icons] Path 21: > /opt/gnucash/share/icons > * 16:29:33 ERROR g_settings_new_full: assertion > 'schema != NULL' failed > * 16:29:33 WARN > [gnc_gsettings_get_settings_ptr()] Ignoring attempt to access unknown > gsettings schema org.gnucash.GnuCash.general > * 16:29:33 ERROR GVariant* > gnc_gsettings_get_user_value(const gchar*, const gchar*): assertion > 'G_IS_SETTINGS (settings_ptr)' failed > * 16:29:33 ERROR g_settings_new_full: assertion > 'schema != NULL' failed > * 16:29:33 WARN > [gnc_gsettings_get_settings_ptr()] Ignoring attempt to access unknown > gsettings schema org.gnucash.general > * 16:29:33 ERROR GVariant* > gnc_gsettings_get_user_value(const gchar*, const gchar*): assertion > 'G_IS_SETTINGS (settings_ptr)' failed > * 16:29:33 ERROR g_settings_new_full: assertion > 'schema != NULL' failed > > I've also checked the dependencies and the version numbers of > gsettings. > > Fortunately, I was able to get version 4.7 to work again with 'sudo > make install'. I have been doing this in the same way since 4.5 and it > has always worked until now. > > Christian > > > > Am Dienstag, dem 28.12.2021 um 09:10 +1000 schrieb > davidcousen...@gmail.com: >> Christian, >> >> Not sure what the problem is but you could try using David Whitings >> script for >> installation on Ubuntu 20.04 which is now in the wiki at >> https://wiki.gnucash.org/wiki/Building_On_Linux#Focal_Fossa_20.04_LTS >> . It works >> well with the only disadvantage it downloads a copy of the whole git >> repository >> and not just the specific source files for a single version, OK if >> you don't >> have any serious space issues. >> >> The following commands from the script will do the setup for builing >> and install >> the dependencies: >> >> sudo apt -y update >> sudo apt -y upgrade >> sudo apt -y install git >> sudo apt -y build-dep gnucash >> >> ## To build series 4 of gnucash on Ubuntu 20.04 >> sudo apt -y install libboost-program-options1.71-dev >> >> If you still want to work from the downloaded zip file of the sources >> just run >> these first to make sure all the dependencies are loaded. I would try >> a fresh >> download of the zipped file from Sourceforge as well. There was a >> patch to the >> 4.8 sources that affected the gsettings schemas from memory but AFAIK >> it was >> incorporated in the 4.9 sources. >> >> If you run the following command ( I have also listed the output from >> it on >> Linux MInt 20.2 which should be the same as Ubuntu 20.04) you will >> list the >> packages affecting gsettings. >> >> dpkg -l | grep gsettings >> >> ii dconf-gsettings- >> backend:amd64 0.36.0- >> 1amd64simple >> configuration storage >> system - GSettings back-end >> ii gsettings-desktop- >> schemas 3.36.0- >> 1ubuntu1 all GSettings desktop- >> wide schemas >> ii libproxy1-plugin- >> gsettings:amd640.4.15- >> 10ubuntu1.2 amd64automatic proxy >> configuration >> management library (GSettings plugin). >> >> It is ususlly a good idea on Linux to unistall the previous version >> befor >> installing a new version. On Linux Mint (not sure Ubuntu is exactly >> the same but >> I think it should be) if you right click on the icon in the menu you >> should get >> a dropdown menu with uninstall as one of the options. It may require >> you to keep >> the build directory which has the install_manifest.text used to do >> the >> uninstall
Re: [GNC-dev] Trouble with gsettings in GC 4.9
You're building in a clean build directory, right? Regards, John Ralls > On Dec 29, 2021, at 5:48 AM, Christian Wehling wrote: > > Hi, > unfortunately, neither deleting the schema files after uninstalling nor > installing them according to David's instructions helped. > Fortunately, version 4.7 is still executable. > > Are there other possibilities I can try? > > Regards > Christian > > > > > Am Dienstag, dem 28.12.2021 um 08:10 -0800 schrieb john: >> Christian, >> >> Try uninstalling 4.7 again, then make sure that /opt/share/glib- >> 2.0/schemas and /usr/share/glib-2.0/schemas contain no files whose >> names begin with `org.gnucash', then reinstall 4.9. >> >> Regards, >> John Ralls >> >>> On Dec 28, 2021, at 7:50 AM, Christian Wehling >>> wrote: >>> >>> Hi, >>> I have tried all this: >>> I started with a working version 4.7, did a 'sudo make uninstall' >>> and >>> then installed versions 4.8 and 4.9 with 'sudo make install' and >>> 'sudo >>> ninja install'. Unfortunately, both versions were unsuccessful. >>> >>> The Output from 4.8 and 4.9: >>> * 16:29:33 INFO [gnc_load_app_icons] Path >>> 19: >>> /usr/share/pixmaps >>> * 16:29:33 INFO [gnc_load_app_icons] Path >>> 20: >>> /opt/gnucash/share/gnucash/icons >>> * 16:29:33 INFO [gnc_load_app_icons] Path >>> 21: >>> /opt/gnucash/share/icons >>> * 16:29:33 ERROR g_settings_new_full: >>> assertion >>> 'schema != NULL' failed >>> * 16:29:33 WARN >>> [gnc_gsettings_get_settings_ptr()] Ignoring attempt to access >>> unknown >>> gsettings schema org.gnucash.GnuCash.general >>> * 16:29:33 ERROR GVariant* >>> gnc_gsettings_get_user_value(const gchar*, const gchar*): assertion >>> 'G_IS_SETTINGS (settings_ptr)' failed >>> * 16:29:33 ERROR g_settings_new_full: >>> assertion >>> 'schema != NULL' failed >>> * 16:29:33 WARN >>> [gnc_gsettings_get_settings_ptr()] Ignoring attempt to access >>> unknown >>> gsettings schema org.gnucash.general >>> * 16:29:33 ERROR GVariant* >>> gnc_gsettings_get_user_value(const gchar*, const gchar*): assertion >>> 'G_IS_SETTINGS (settings_ptr)' failed >>> * 16:29:33 ERROR g_settings_new_full: >>> assertion >>> 'schema != NULL' failed >>> >>> I've also checked the dependencies and the version numbers of >>> gsettings. >>> >>> Fortunately, I was able to get version 4.7 to work again with 'sudo >>> make install'. I have been doing this in the same way since 4.5 and >>> it >>> has always worked until now. >>> >>> Christian >>> >>> >>> >>> Am Dienstag, dem 28.12.2021 um 09:10 +1000 schrieb >>> davidcousen...@gmail.com: >>>> Christian, >>>> >>>> Not sure what the problem is but you could try using David >>>> Whitings >>>> script for >>>> installation on Ubuntu 20.04 which is now in the wiki at >>>> https://wiki.gnucash.org/wiki/Building_On_Linux#Focal_Fossa_20.04_LTS >>>> . It works >>>> well with the only disadvantage it downloads a copy of the whole >>>> git >>>> repository >>>> and not just the specific source files for a single version, OK >>>> if >>>> you don't >>>> have any serious space issues. >>>> >>>> The following commands from the script will do the setup for >>>> builing >>>> and install >>>> the dependencies: >>>> >>>> sudo apt -y update >>>> sudo apt -y upgrade >>>> sudo apt -y install git >>>> sudo apt -y build-dep gnucash >>>> >>>> ## To build series 4 of gnucash on Ubuntu 20.04 >>>> sudo apt -y install libboost-program-options1.71-dev >>>> >>>> If you still want to work from the downloaded zip file of the >>>> sources >>>> just run >>>> these first to make sure all the dependencies are loaded. I would >>>> try >>>> a fresh >>>> download of the zipped file from Sourceforge as well. There was a >>>> patch to the >>>> 4.8 sources that affected the gsettings schemas from memory but >>>> AFAIK &g
Re: [GNC-dev] Preferences for Accounting Period start-date and end-date lost on 4.9 Install
> On Jan 2, 2022, at 4:25 PM, Chris Good wrote: > > Hi All, > > > > I installed Gnucash 4.9 on my Windows 10 machine (was 4.4) and the > Preferences for Accounting Period start-date and end-date were lost. > > They have gone back to the default 1/1/1970. > > > > Looking in the registry I can see they have been migrated (moved) from > > > HKCU\Software\GSettings\org\gnucash\window\pages\account-tree\summary\[start > -date etc] > > To > > > HKCU\Software\GSettings\org\gnucash\GnuCash\window\pages\account-tree\summar > y > > > > but the Preference dialog and the Accounts page still seem to be looking at > the old keys. > > > > I set them again using the preferences dialog and now they are in both the > old and new locations. > > After View, Refresh the Accounts page is showing the correct Total(Period) > figures again. > > > > If it makes any difference, the first time I opened 4.9 it was with the > --nofile arg. > > > > Should the old or new schema location be used? > > > > HKCU\Software\GSettings\org\gnucash\general\prefs-version = 404 > > HKCU\Software\GSettings\org\gnucash\GnuCash\general\prefs-version = 4009 The new schema is correct for GnuCash 4.7 and later. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] alpha-testing budgets in 5.x
> On Jan 4, 2022, at 8:40 AM, Christopher Lam wrote: > > Experienced Users, > > The upcoming 5.x series (master branch) currently has a one-time fix for > budgets to ensure they're internally stored as unreversed numbers. > Currently (up to 4.x) budgeting $1000 income into $600 expense and $400 > liability repayment are stored as +1000, +600, +400. They should be stored > internally as -1000, +600, +400 amounts, as per usual accounting equation. > The internal numbers assume the reversal pref is "Credit Accounts". This > means the budgets are currently functioning well *only* if reversal > preference is set to credit-accounts > > A obligatory one-time fix is suggested and applied on the master branch, > applying some heuristics and negating the numbers, and will render the > datafile unreadable on GnuCash prior to 3.7. It is *not* an option to make > the one-time fix optional, because this will mean maintaining two code > paths in perpetuity. However I'm not sure if it is debugged enough. > > I'd like to ask experienced users to test from the master branch, either as > win32 nightlies https://code.gnucash.org/builds/win32/master/ (4-jan-2022 > onwards) or building on linux, and report back of the new budget is *less* > buggy than in 4.x maint series. Please do NOT test master on your > production datafile. > > If there are unsolvable bugs, then I'll suggest that the one-time fix > change must be undone, and someone else may decide to try again. Linux users can also get a flatpak nightly from https://code.gnucash.org/builds/flatpak/master <https://code.gnucash.org/builds/flatpak/master>. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Preferences for Accounting Period start-date and end-date lost on 4.9 Install
Chris, Geert is right, at least for now, both because of the OpenSP failure and because the latest MSYS2 updates require a new webkit build and I haven't yet done the 64-bit one. You can't just run the 32-bit build, though, because you've installed the 64-bit dependencies. You could reinstall them by hand but it's much easier to re-run setup-mingw64.ps1 and leave off the -x86_64 $true argument. Note that I haven't tried doing this on an already-built environment. It might not work. The TARGET environment variable is read by jhbuildrc to decide which branch to build. The default is master, generally not what you want. Regards, John Ralls > On Jan 14, 2022, at 1:11 AM, Geert Janssens > wrote: > > Hi Chris, > > I don't think we support building a 64bit version on Windows. > > Can you run your commands in the 32bit mingw64 shell (MSys2 64bit/MSys2 MinGW > 32-bit) > to at least avoid any additional bugs due to the different environment ? > > Note the name is confusing. MingW64 is the name of the project (to > differentiate from an > older MingW32 project), but it provides both a 32bit and a 64bit environment > for > development. So far gnucash has only used the 32bit environment. > > Regards, > > Geert > > Op vrijdag 14 januari 2022 08:01:09 CET schreef Chris Good: >> Hi Devs, >> >> I'm trying to build gnucash-on-windows so I can find where the "subscribe" >> error above is coming from. >> I ran setup-mingw64.ps1 like: >> E: >> cd \Data\GnuCash\gcdev64 >> .\setup-mingw64.ps1 -target_dir "e:\\Data\\GnuCash\\gcdev64" -download_dir >> "e:\\Data\\GnuCash\\gcdev64\\downloads" -x86_64 >> >> The setup seems to have worked with the exception of HtmlHelp but I don't >> need to build the documentation so I've ignored that. >> >> The build is failing when I run in a MSYS2 64Bit / MSYS2 MinGW x64 window >> (not as admin): >> (As suggested by >> https://wiki.gnucash.org/wiki/Building_on_Windows#Running_a_build) >> >> cd /e/Data/GnuCash/gcdev64/src/gnucash-on-windows.git >> TARGET=gnucash-maint jhbuild -f jhbuildrc build >> >> Please see attached full log. >> >> Note the output from the setup says: >> >> Your build environment is now ready to use. Open an MSys2/mingw64 shell from >> the start menu, cd to /e/Data/GnuCash/gcdev64, and run >> jhbuild -f src/gnucash-on-windows.git/jhbuildrc build >> >> Should I be doing that before the above "TARGET=... command or instead of? >> >> Regards, Chris Good > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] How to specify args to setup-mingw64.ps1
> On Jan 15, 2022, at 5:58 PM, Chris Good wrote: > > Ignoring for the moment the fact that John Ralls says the Windows 64 bit > build is currently broken because the latest MSYS2 updates require a new > webkit build and he hasn't yet done the 64-bit one. > > > > How would I specify a non default target_dir and a 64-bit build? > > > > I tried many things but had to resort to editing the script to plug the > values I want in the CmdLetBinding section. > > > > For example: > > > > .\setup-mingw64.ps1 -target_dir "e:\Data\GnuCash\gcdev64" -download_dir > "e:\Data\GnuCash\gcdev64\downloads" -x86_64 "$true" > > fails with > > "Failed to install MSys2, aborting." > > because $bash_path = True\\usr\\bin\\bash.exe > > > > I added after line 76: $bash_path = "$msys2_root\\usr\\bin\\bash.exe" > > > > write-host "target_dir=$target_dir" > > write-host "download_dir=$download_dir" > > write-host "msys2_root=$msys2_root" > > write-host "x86_64=$x86_64" > > write-host "preferred_mirror=$preferred_mirror" > > > > .\setup-mingw64.ps1 -target_dir "e:\Data\GnuCash\gcdev64" -download_dir > "e:\Data\GnuCash\gcdev64\downloads" -x86_64 "$true" > > target_dir=e:\Data\GnuCash\gcdev64 > > download_dir=e:\Data\GnuCash\gcdev64\downloads > > msys2_root=True ??? > > x86_64=True > > preferred_mirror=http://repo.msys2.org > > > .\setup-mingw64.ps1 -target_dir "e:\Data\GnuCash\gcdev64" -x86_64 "$true" > > target_dir=e:\Data\GnuCash\gcdev64 > > download_dir=True ??? > > msys2_root=e:\Data\GnuCash\gcdev64\\msys2 > > x86_64=True > > preferred_mirror=http://repo.msys2.org Don't quote $true, it's a PowerShell constant. If you quote it it turns into a string and doesn't work. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] EPC QR code
> On Jan 16, 2022, at 8:37 AM, Rainer Dorsch via gnucash-devel > wrote: > > Hello, > > many thanks for all the effort you put in gnucash. It is a really useful and > very stable tool and that for many years (even decades!) > > I recent times I often see QR codes on invoices. I quick search revealed that > they are standardized by the European Payments Council > > https://en.wikipedia.org/wiki/EPC_QR_code > > Is there any plan to support reading these QR codes with e.g. the laptop > camera and extract the data required for the SEPA credit transfer? > There isn't, and adding the ability to access the camera would involve adding GStreamer as a dependency, not an easy task. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Extending GnuCash: CSV-import/lookup commodity by cusip
It seems unlikely to me that there's much demand for this field at all, never mind demand for keeping both an ISIN and a national number, so I don't think we need to separate it. The search function could use namespace as a disambiguator for numbers, or users who encounter more than one flavor could use a prefix to separate them if the formats happen to collide, eg cusip-123456789 and wkn-123456789. As it happens cusip is 9 characters, sedol is 7, wkn is 6, and ISIN is 12 so there's no collisions among those 4. Regards, John Ralls > On Jan 22, 2022, at 9:35 AM, Frank H. Ellenberger > wrote: > > Hi Thomas, > > Am 21.01.22 um 21:39 schrieb Thomas: >> And because of that, I am struggling to do a matching based on that >> field. As my bank, denotes the WKN (a unique identifier), > > The WKN is only unique inside the german markets. If you also have a > french bank, they might send the SEDOL instead. > > But ISIN would be unique. It is "DE". > > I wonder if we should at some point separate ISIN as gloal unique > identifier from the catch-all field "ISIN, CUSIP or other identifier". > > Namespace+Symbol is the current unique identifier. > ISIN would be unique while NSINs like WKN have the implicit assumption > all securities are emitted in the same country. > > Regards > Frank > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Missing G_END_DECLS macro in gnucash/import-export/aqb/gnc-ab-kvp.h
> On Feb 18, 2022, at 8:24 PM, Kevin Buckley wrote: > > I actually noticed this in a source file from back in the 2.6 days, > although have just pull-ed the maint branch, at commit 1ed85c9b6, > and still can't see one? > > FWIW, I was looking to wrap all of the > > G_BEGIN_DECLS > G_END_DECLS > > pairs in GNU indent "Ignore" comments > > /* *INDENT-OFF* */ > > /* *INDENT-ON* */ > > (indent not being overly happy dealing with them nor with G_GNUC_CONST > come to that), > > and noticed this file had a BEGIN-ing but no END. > > Was wondering if that was "correct" or merely just "OK"? > > > Just out of interest though, and leaving aside the "it's a free-for-all" notes > in the Coding Style Conventions stanza of the HACKING file, what are the > pretty-printers of choice for the various source code languages within > the GnuCash codebase? A G_BEGIN_DECLS without a corresponding G_END_DECLS should fail to compile if it's presented to a c++ compiler. Seems those macros are used mostly in files that aren't likely to ever be presented to a c++ compiler so they should probably be removed; in the few exceptions where a c++ compiler might see them I think it would be better to replace them with their expansions for clarity. On those occasions where we want to bulk reformat we've generally used artistic style, http://astyle.sourceforge.net/, as astyle -xd -k1 -m0 -M60 -xL -xC79 -OHpUcZns4 --brackets=break or more commonly just astyle --indent=spaces=4 --brackets=break --suffix=none Please refer to https://wiki.gnucash.org/wiki/CodingStandard rather than the ancient instructions in HACKING--which I just replaced with a pointer to the wiki page. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Missing G_END_DECLS macro in gnucash/import-export/aqb/gnc-ab-kvp.h
> On Feb 25, 2022, at 8:59 PM, Kevin Buckley wrote: > > On Sun, 20 Feb 2022 at 02:05, john wrote: >> >> On those occasions where we want to bulk reformat we've generally used >> artistic style, http://astyle.sourceforge.net/, as >> astyle -xd -k1 -m0 -M60 -xL -xC79 -OHpUcZns4 --brackets=break >> or more commonly just >> astyle --indent=spaces=4 --brackets=break --suffix=none > > For anyone coming to this thread, I wanted to point out that the > > --brackets=break > > argument in the above should possibly be > > --style=break > > at least for Artistic Style version 3.1. That looks right and shows that we haven't used astyle in a long time: The --brackets option was last mentioned in the release notes in 2.02, though it's in the 2.04 docs that I have installed on my main dev machine. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash/gnome-utils/gnc-plugin-page.h missing a documentation parameter
> On Feb 28, 2022, at 9:26 PM, Frank H. Ellenberger > wrote: > > Hi Kevin, > > Am 27.02.22 um 08:47 schrieb Kevin Buckley: >> appears to be missing the parameter name color >> >> Line 408 should presumably be >> >> * @param color The color for this page. This string is owned by the page >> and > > np, it is the return value. Because a function can have multiple > parameeters you have to name them. But there is only one return value. Frank, Before being so dismissive you should look at https://code.gnucash.org/docs/MAINT/group__ContentPluginBase.html#ga7408d75bdf2e64264cb9386ac860052c: <https://code.gnucash.org/docs/MAINT/group__ContentPluginBase.html#ga7408d75bdf2e64264cb9386ac860052c:> BTW > void gnc_plugin_page_set_page_color (GncPluginPage *page, const char *color); clearly has no return value. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] ANNOUNCE: GnuCash 4.10 Released
> On Mar 28, 2022, at 8:20 AM, Chris Graves wrote: > > Thanks devs for your time and effort! > > I'm running 4.10 on macOS and have a repeatable crash. > > In a register, say a checking account, entering a transaction, Gnucash will > crash when entering text in the Description field. > > Excerpt of crash dump follows: > Translated Report (Full Report Below) > - > > Process: Gnucash [59898] > Path: /Applications/Gnucash 4.10.app/Contents/MacOS/Gnucash > Identifier:org.gnucash.Gnucash > Version: 4.10-1 (4.10-1) > Code Type: X86-64 (Native) > Parent Process:launchd [1] > User ID: 501 > > Date/Time: 2022-03-28 08:04:53.7747 -0700 > OS Version:macOS 12.3 (21E230) > Report Version:12 > Bridge OS Version: 6.4 (19P4242) > Anonymous UUID:858FE7A6-31A3-2D36-6F92-0A5CE1E86B47 > > Sleep/Wake UUID: AC40E359-EF77-45DA-90C6-01002E09B655 > > Time Awake Since Boot: 25 seconds > Time Since Wake: 4463 seconds > > System Integrity Protection: enabled > > Crashed Thread:0 Dispatch queue: com.apple.main-thread > > Exception Type:EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0x > Exception Codes: 0x0001, 0x > Exception Note:EXC_CORPSE_NOTIFY > > Termination Reason:Namespace SIGNAL, Code 11 Segmentation fault: 11 > Terminating Process: exc handler [59898] > > VM Region Info: 0 is not in any region. Bytes before following region: > 4483457024 > REGION TYPESTART - END [ VSIZE] PRT/MAX > SHRMOD REGION DETAIL > UNUSED SPACE AT START > ---> > __TEXT 10b3c2000-10b3ea000[ 160K] r-x/r-x > SM=COW ...MacOS/Gnucash > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libglib-2.0.0.dylib 0x10bbdee83 _g_utf8_normalize_wc > + 83 > 1 libglib-2.0.0.dylib 0x10bbdf73c g_utf8_normalize + 12 > 2 libgnc-register-gnome.dylib 0x10b8817ce > gnc_combo_cell_modify_verify + 350 > 3 libgnc-register-core.dylib 0x10b7f0e58 > gnc_table_modify_update + 424 > 4 libgnc-register-gnome.dylib 0x10b88f9aa > gnucash_sheet_insert_cb + 778 > 5 libgobject-2.0.0.dylib 0x10c14e766 g_closure_invoke + > 278 > Thanks. One of the Davids already reported this at https://bugs.gnucash.org/show_bug.cgi?id=798490 <https://bugs.gnucash.org/show_bug.cgi?id=798490>. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Typo in gnucash/gnome-utils/gnc-date-edit.c or incorrect string altogether?
> On Apr 6, 2022, at 9:39 PM, Kevin Buckley wrote:
>
> Spotted this one recently
>
> gnucash/gnome-utils/gnc-date-edit.c:658:
>"Date/time represented in
> seconds since Januari 31st, 1970",
>
> and assumed it was just a mis-typing of "January"
>
> However, as I can't find another instance of "January 31st" in the codebase,
> was wondering if it should be "January 1st"
>
> For context, it's in this function
>
> gnc_date_edit_class_init
>
> in this call
>
>g_object_class_install_property(object_class,
>PROP_TIME,
>g_param_spec_int64("time",
>"Date/time (seconds)",
>"Date/time represented in
> seconds since Januari 31st, 1970",
>G_MININT64,
>G_MAXINT64,
>0,
>G_PARAM_READWRITE));
>
Yes to both: It should be 1 January 1970. I've clarified further by specifying
that it's "since midnight UTC, 1 January 1970". Thanks for noticing.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python-Bindings: issue when C expects GList argument
> On May 10, 2022, at 1:53 AM, Matteo Lasagni wrote:
>
> Thank you, John!
>
> I fixed it by adding the following into base-typemaps.i:
>
> %typemap(in) GList * {
> $1 = NULL;
> /* Check if is a list */
> if (PyList_Check($input)) {
> int i;
> int size = PyList_Size($input);
> for (i = size-1; i >= 0; i--) {
> PyObject *o = PyList_GetItem($input, i);
> $1 = g_list_prepend($1, o);
> }
> } else {
> PyErr_SetString(PyExc_TypeError, "not a list");
> return NULL;
> }
> }
>
> I had overlooked the swig definition in engine.i, where there is a typemap
> (in) for GList, but then it is cleared right afterwards...
> I am not (yet) very familiar with swig :-)
>
> I have also noticed that CreatePaymentLotSecs does not work out of the box,
> as it expects **Transaction while only *Transaction is type mapped.
>
> I will test these changes then I will figure out how to share them with the
> developers.
>
>
> Matteo
>
>
> On Tue, 10 May 2022 at 02:32, John Ralls <mailto:jra...@ceridwen.us>> wrote:
>
>
> > On May 9, 2022, at 2:17 PM, Matteo Lasagni > <mailto:laser...@gmail.com>> wrote:
> >
> > Hi,
> > I am writing a python script to automatically associate a set of
> > invoices to a single transaction.
> > To this end, I am trying to use the function AutoApplyPaymentsWithLots
> > with no success:
> >
> >
> > lots = [lot1, lot2, lotn, ..]
> > owner.AutoApplyPaymentsWithLots(lots)
> >
> > This causes the following error:
> >
> > TypeError: in method 'gncOwnerAutoApplyPaymentsWithLots', argument 2 of
> > type 'GList *'
> >
> > I have tried different solutions from passing different types of python
> > objects, to updating the swig typemap and also to modifying the
> > auto-generated gnucash_core.c...nothing worked out so far.
> > I could write an additional c-wrapper, but I am sure there is a more
> > general solution.
>
> The fundamental problem is that there's only a Python out typemap for GList,
> that is one that converts from a GList* to a python list. Lacking an in
> typemap the gncOwner.AutoApplyPaymentsWithLots python wrapper expects an
> already constructed and Swig-wrapped GList*.
>
> Regards,
> John Ralls
>
>
Nice. Would you put that in a pull request?
There are two typemap(in) GList* in engine.i, but they're both for Guile
(Scheme), not Python. 'scm' is the giveaway.
If there's a way to implement an output pointer parameter in Python I don't
know about it. You can pass in a container object and put the output
Transaction* in the container, but that's both a bit of a hack and doesn't have
the same meaning as Transaction** nor is it very pythonic. Nor, for that
matter, is gncOwnerCreatePaymentLotSecs a very good design as it mixes
responsibilities. Unfortunately there's a lot of that in GnuCash because most
of it is written with a very narrow focus, in this case providing for the
payments dialog.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python-Bindings: issue when C expects GList argument
gncOwnerCreatePaymentLotSecs is a bad design because it tries to fit two use
cases.
One, in gncInvoiceApplyPayment, has a transaction already and passes it to
gncOwnerCreatePaymentLotSecs. That's OK.
The other, in gnc_payment_ok_cb via gncOwnerApplyPayemtSecs, asks it to create
a transaction and apply the payment to it, and passes in a Transaction** so
that it can get the new transaction. That's bad. The fix is to remove the
transaction-creation code from gncOwnerCreatePaymentLotSecs and change the
Transaction** parameter to Transaction* in both gncOwnerCreatePaymentLotSecs
and gncOwnerApplyPaymentSecs. gnc_payment_ok_cb (actually gnc_payment_ok_cb's
controller function, but that's for a different rant) should create the
transaction itself and pass it to gncOwnerApplyPayemtSecs.
While that will make gncOwnerCreatePaymentLotSecs wrappable, I think it's
debatable that it should be wrapped: It's pretty clearly an implementation
detail of applying a payment. Implementation details shouldn't be part of the
public API.
Regards,
John Ralls
> On May 10, 2022, at 2:59 PM, Matteo Lasagni wrote:
>
> Thank you Derek, I understand what you mean.
> The point here is that I was not interested in the value returned through the
> pointer,
> but only in making that function callable from Python.
> I was looking for a solution to automatically associate multiple invoices to
> the same transaction,
> as it is possible with the GUI; this seemed to be the right way.
> Maybe there is a better solution for this specific goal.
>
> However, I try to follow your suggestion to unref the return value or return
> it in a tuple.
> Since I kept receiving always the following error, no matter how I change the
> swig interface,
> I was only focusing on the input value (i.e., c input direction) quite
> convinced the first step was
> to fix the conversion of a double pointer.
>
> TypeError: in method 'gncOwnerCreatePaymentLotSecs', argument 2 of type
> 'Transaction **'
>
>
> Best,
> Matteo
>
>
>
> On Tue, 10 May 2022 at 23:37, Derek Atkins <mailto:de...@ihtfp.com>> wrote:
> More specifically...
>
> The issue here is that there are multiple return values.
> gncOwnerCreatePaymentLotSecs() is *RETURNING* both a GNCLot* and a
> Transaction*. However, C doesn't allow you to do that, so the function
> returns the GNCLot* and assigns the Transaction* to the Transaction**
> argument as a second return value.
>
> Your proposed wrapper here is wrong.
>
> You can either write a wrapper that obtains the transaction and then
> unrefs it (returning only the Lot), or you can write a wrapper that
> obtains both values and returns the tuple (Lot, Txn) in Python -- assuming
> Python, like Scheme, allows that.
>
> Most likely this is why the function wasn't wrapped before -- due to the
> complexities of the double return values.
>
> -derek
>
> On Tue, May 10, 2022 5:23 pm, Matteo Lasagni wrote:
> > If I can find a good solution, yes, I will put it in a pull request.
> >
> > I have tried to encapsulate Transaction* in a list, but of course it
> > doesn't work without touching swig definitions.
> > I am now trying to create a specific typemap for handling the double
> > pointer. I think this would be the cleanest solution.
> >
> > Alternatively, a quick and dirty workaround is to add a C wrapper in
> > gncOwner.c that expects Transaction* and passes Transaction** to
> > gncOwnerCreatePaymentLotSecs:
> >
> >
> > GNCLot *
> > gncOwnerCreatePaymentLotSecsPyHelper (const GncOwner *owner, Transaction
> > *txn, Account *posted_acc, Account *xfer_acc, gnc_numeric amount,
> > gnc_numeric exch, time64 date, const char *memo, const char *num)
> > {
> > return gncOwnerCreatePaymentLotSecs(owner, &txn, posted_acc, xfer_acc,
> > amount, exch, date, memo, num);
> > }
> >
> >
> > regards,
> > Matteo
> >
> > On Tue, 10 May 2022 at 17:25, john > <mailto:jra...@ceridwen.us>> wrote:
> >
> >>
> >>
> >> On May 10, 2022, at 1:53 AM, Matteo Lasagni >> <mailto:laser...@gmail.com>> wrote:
> >>
> >> Thank you, John!
> >>
> >> I fixed it by adding the following into base-typemaps.i:
> >>
> >> %typemap(in) GList * {
> >> $1 = NULL;
> >> /* Check if is a list */
> >> if (PyList_Check($input)) {
> >> int i;
> >> int size = PyList_Size($input);
> >> for (i = size-1; i >= 0; i--) {
> >> PyObject *o = PyList_GetItem($input, i);
> >&
Re: [GNC-dev] Co-Owner
> On Jun 10, 2022, at 1:40 AM, Ralf Zerres wrote:
>
> Hello mailinglist,
>
> i do appologize for not coming up with this issue on this list before
> hacking and submitting a PR.
>
> In any case (thanks John for your prompt answer on github) i do need to
> find a solution for my personal needs.
> And no, I do not want to buy a commercial solution (like Karthago,
> et.al).
>
> Your decline message was short and without any further argumentation. I
> was a bit surprised on this.
> So i try to pick up the issue, since i do think this isn't out of topic
> at all. At least, if stock and customer/employee handling are welcome
> as first class citizens.
>
> However, i hope we can at least discuss the idea before declining any
> action in the public.
>
> If i have to go on myself, I'd like to get some help on how to debug
> the scm parts. Currently my code is compiling the .c and .cpp comits.
> As soon as the guile stuff need to create the wrapper libraries i do
> get errors and have no idea, on how to debug.
> Any help here is much appreciated
>
> Ralf
>
> Shell output:
>
> $ cd $gnucash-root; mkdir ../gnucash-coowner
> $ # ../gnucash-coowner is $gnucash-coowner
> $ cd ../gnucash-coowner
> $ cmake -DCMAKE_INSTALL_PREFIX=./gnucash-install -G Ninja ../gnucash-
> root
>
> $ cd ninja
>
> ...
>
> $gnucash-coowner/lib/guile/2.2/site-ccache/tests/unittest-support.go
> /data/development/gnucash/gnucash/common/test-core/unittest-
> support.scmunittest-support.scm
> Backtrace:
> In ice-9/boot-9.scm:
>705:2 19 (call-with-prompt _ _ #)
> In ice-9/eval.scm:
>619:8 18 (_ #(#(#)))
> In /usr/bin/guild:
>72:17 17 (main _)
> In srfi/srfi-1.scm:
>640:9 16 (for-each #
> ?)
> In scripts/compile.scm:
> 264:26 15 (_ _)
> In system/base/target.scm:
> 57:6 14 (with-target _ _)
> In system/base/compile.scm:
>152:6 13 (compile-file _ #:output-file _ #:from _ #:to _ #:env _ ?)
> 43:4 12 (call-once _)
> In ice-9/boot-9.scm:
>841:4 11 (with-throw-handler _ _ _)
> In system/base/compile.scm:
>59:11 10 (_)
> 155:11 9 (_ #)
> 235:18 8 (read-and-compile # # _ ?)
> 183:32 7 (compile-fold (#) ?)
> In ice-9/boot-9.scm:
> 2312:4 6 (save-module-excursion #)
> In language/scheme/compile-tree-il.scm:
>31:15 5 (_)
> In ice-9/psyntax.scm:
> 1262:36 4 (expand-top-sequence ((eval-when (compile load # #) #)) ?)
> 1209:24 3 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
> 285:10 2 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
> In unknown file:
> 1 (load-extension "libtest-core-guile" "scm_init_unittest?")
> In ice-9/boot-9.scm:
> 752:25 0 (dispatch-exception _ _ _)
To amplify the rejection of your pull request: GnuCash has a scope that's
limited by its basic design and what the core development team are able to
maintain. That scope is basic accounting for personal and very small business
use, where very small means sole proprietors with no employees (GnuCash has no
payroll module). The multiple ownership model of this change falls outside that
scope. Furthermore it caters to a very narrow single-nation use case that would
be very difficult for the current core team to maintain.
Nevertheless the whole point of Free software is your freedom to adapt it to
your needs and this is the right place to ask for help with that.
As for the scheme problem, it looks like your C changes managed to break
compiling unitest-support.scm, but you chopped off a bit too much to be sure.
There should be two more lines at the bottom saying what was the actual error
and a few more lines leading up to the stack trace would be helpful to be sure
of the source of the error. Turn on GitHub actions for your personal repository
(see
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository)
and Github will run builds for you using the CI actions already in GnuCash.
Then you can just post a link to a failed one for us to help you diagnose it.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Co-Owner
> On Jun 11, 2022, at 12:58 PM, Ralf Zerres wrote: > > One open question: > > I defined a new submenu gnc-plugin-business-ui.xml > > ... > > > > action="CoOwnerOverviewPageAction"/> > action="CoOwnerNewCoOwnerOpenAction"/> > action="CoOwnerFindCoOwnerOpenAction"/> > action="CoOwnerNewInvoiceOpenAction"/> > action="CoOwnerFindInvoiceOpenAction"/> > action="CoOwnerNewJobOpenAction"/> > action="CoOwnerFindJobOpenAction"/> > action="CoOwnerProcessPaymentAction"/> > action="InvoicesDueReminderOpenAction"/> > > ... > > Stupid me: Where do i activate this menu? > Seems that osx_acel_map isn't used for submenu entries that any more > ... > accelmap is a user customization point for changing menu accelerator keys, it doesn't load ui files. You have to do that in code with GtkUIManager, see https://docs.gtk.org/gtk3/class.UIManager.html. There are actually several ways to pull in a ui.xml file besides direct calls to GtkUIManager. Just grep the GnuCash sources for "ui.xml" and you'll find several. Note that GtkUIManager and ui.xml files are for the old GtkMenu design and is deprecated as of 3.10 and removed in Gtk4, replaced with Glib's GMenu and related classes. GnuCash will have to follow that redesign at some point fairly soon (PRs very welcome if somebody wants to take it on!) and we don't regard that as public API meaning that it will just happen with no deprecation and no warning. BTW osx-accelmap is just a template for making a few menu accelerators more Mac-like. It's only loaded on macOS, but the accelmap mechanism in Gtk is turned on so users on any platform can use it to customize their menu accelerators. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Co-Owner (v0.3.0)
> On Jun 29, 2022, at 10:32 AM, Ralf Zerres wrote: > > Hey all, > > I'm still active on hacking the coowner branch. > It's quite a stony path, but I do my best and got into the code > structure quite well. The active, rebases branch is now called > `cooowner`. No i do get stuck on two nasty problems. Appreciate your > advice: > > * seems there is the need of a specific GTK environment > Which one is needed to use glade and code integration (seems plaind > 3.x version isn't enough) > > * given situation: compiles, but i introduced a regression > > 11:23:34 ERROR gboolean > qof_choice_add_class(const char*, char*, char*): assertion > 'qof_object_is_choice(select)' failed > > * debug gnucash > build path: > cd ~/build-coowner; >cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=./install - > G Ninja ..) > >no i'm strugglin within gdb. Since the app is multi-threaded, i > like to simplify the debug session and wonder if it would be possible > to just run with a singel thread? > > * does gnucash have a chat for active development (mattermost, discord, > et al?) > We're severely behind in cleaning out deprecated Gtk code so anything from around 3.10 should work OK. Glade is another matter, Bob Fewell keeps regenerating the Glade files with new versions. I avoid the problem by using emacs on glade files, but otherwise you need to keep up to date. Maybe Bob can jump in with some more advice. The part of GnuCash that you're interested in is single-threaded. Guile and WebKit fire off some threads for their own nefarious purposes but you can ignore them. CMAKE_BUILD_TYPE=Debug doesn't turn off optimization, you need to add -O0 or -O1 to CMAKE_CPP_FLAGS if you need to have all of your locals and args populated and your code to step linearly. We have an IRC channel, see https://wiki.gnucash.org/wiki/IRC, with some of the core team usually present. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Co-Owner (v0.3.4)
> On Jul 1, 2022, at 8:11 AM, Ralf Zerres wrote: > > Do i have to test in an isolated environment/container? Yes, otherwise the linker will find the installed libraries instead of your newly-built ones. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Questions about Import Map Data
> On Jul 4, 2022, at 11:07 PM, Lincoln A Baxter wrote: > > Hi, > > It's been a very long time since I asked a question on this list serve, > and a very long time since I last did a "cleanup" of my GC file (with > perl scripts back then). > > I started keeping my accounting data in GC back in March of 2005. Now > I'm looking to reorganize my chart of expense accounts (again) to > simplify things... when I do that, I'll want to remove the obsolete > Bayes data (again). > > I have a general idea of how the Bayesian import mapper works... Years > ago I wrote some perl scripts to prune it out of the uncompressed XML > file, so I could start it over. But, I'm now looking at the Tools -> > Import Map Editor which I will (belatedly say) is a huge improvement > over mucking about with the xml slot data -- which now looks to be > simplified), especially if all one wants to do, is zero it out. But, > this has lead me to some questions: > > Most of the Bayes data is space tokenized transaction description data. > I get that part. My understanding is that it is scores in this data > that the matcher uses to map transactions to a balancing account. But > I see data, that could not of come from transaction descriptions. Why > are days of the week (Monday, Tuesday, etc) in the Bayes data? Where > does this data come from? How does this help the transaction mapper? > > It looks like the Non-Bayesian data consist of a full (non-tokenized) > transaction descriptions... at least a few of them (nowhere near all of > them... not even close). Given how few I've got (and how old they > appear to be), I don't under stand why this data is here. It is almost > like this was an early attempt to create transaction matching data, > that might have existed since before the bayesian matcher "matured." > So: > > Why does gnucash have these records (and how did they get created)? > Are these records used in transaction mapping? (anymore)... or does > this display exist simply for the purpose of allowing one to nuke them? The day of the week of the transaction posted date is one of the tokens, as are the "words" of the description and of each split's memo. The logic is coded in TransactionGetTokens, https://github.com/Gnucash/gnucash/blob/e9df8d41d2fc838046bc02aed0b05bde53ca9dcd/gnucash/import-export/import-backend.c#L442 and isn't significantly changed from the original contribution in GnuCash 1.9.1, see https://github.com/Gnucash/gnucash/commit/b2ccbf62cf04adddbf3464875c6521582b353964. You're correct that the non-Bayesian matching is just the transaction description. You might have those in your book because at some point you disabled Bayes matching in Preferences, but more likely you imported a QIF file or a CSV file before Geert re-wrote the CSV importer for GnuCash 3.0. The QIF importer doesn't support Bayesian matching so if you import a QIF file those match records are what the importer will use. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] building gnucash
> On Jul 8, 2022, at 7:36 AM, Kevin T wrote: > > On Thu, 2022-07-07 at 17:21 -0700, John Ralls wrote: >>> On Jul 7, 2022, at 4:34 PM, Kevin T via gnucash-devel >>> wrote: >>> >>> >>> Hi All, >>> >>> yan. yet another newbie >>> >>> New installation of centos stream 8 >>> >>> [kt@localhost gnucash-build]$ cat /etc/redhat-release >>> CentOS Stream release 8 >>> [kt@localhost gnucash-build]$ cmake --version >>> cmake version 3.20.2 >>> >>> i had to install these packages to get to the starting point for >>> gnucash. >>> >>> drwxrwxr-x. 13 kt kt 4096 Jul 6 14:43 gc-8.0.6 >>> drwxrwxr-x. 16 kt kt 4096 Jul 5 21:27 gmp-6.2.1 >>> drwxr-xr-x. 15 kt kt 4096 Jul 6 19:04 gnucash-4.11 >>> drwxr-xr-x. 21 kt kt 4096 Jul 6 14:45 guile-3.0.8 >>> drwxrwxr-x. 11 kt kt 4096 Jul 6 14:20 libffi-3.4.2 >>> drwxrwxr-x. 10 kt kt 4096 Jul 5 21:32 libunistring-1.0 >>> >>> >>> I had to create the /glib-2.0 dir and other sub dirs. >>> >>> [kt@localhost gnucash-build]$ echo $SRCROOT >>> /home/kt/Sources/gnucash-4.11 >>> >>> [kt@localhost gnucash-build]$ ls $SRCROOT >>> AUTHORS ChangeLog.2001 ChangeLog.2007 ChangeLog.2013 ChangeL >>> og.2019 CMakeLists.txt gnucash README >>> bindingsChangeLog.2002 ChangeLog.2008 ChangeLog.2014 ChangeL >>> og.2020 common HACKING README.dependencies >>> borrowedChangeLog.2003 ChangeLog.2009 ChangeLog.2015 ChangeL >>> og.2021 datalibgnucash test-templates >>> ChangeLog ChangeLog.2004 ChangeLog.2010 ChangeLog.2016 cmake >>>doc LICENSE util >>> ChangeLog.1999 ChangeLog.2005 ChangeLog.2011 ChangeLog.2017 CMakeCa >>> che.txt DOCUMENTERS NEWS >>> ChangeLog.2000 ChangeLog.2006 ChangeLog.2012 ChangeLog.2018 CMakeFi >>> les gnome po >>> >>> >>> The error @ line 66, I dont know what to do with. The equal signs >>> demarcate the output of the screen. >>> >>> === >>> [kt@localhost gnucash-build]$ pwd >>> /home/kt/gnucash-build >>> [kt@localhost gnucash-build]$ cmake $SRCROOT/gnucash >>> CMake Warning (dev) in CMakeLists.txt: >>> No project() command is present. The top-level CMakeLists.txt file >>> must >>> contain a literal, direct call to the project() command. Add a line >>> of >>> code such as >>> >>> project(ProjectName) >>> >>> near the top of the file, but after cmake_minimum_required(). >>> >>> CMake is pretending there is a "project(Project)" command on the >>> first >>> line. >>> This warning is for project developers. Use -Wno-dev to suppress it. >>> >>> CMake Error at gnome/CMakeLists.txt:66 (gnc_add_swig_guile_command): >>> Unknown CMake command "gnc_add_swig_guile_command". >>> >>> >>> CMake Warning (dev) in CMakeLists.txt: >>> No cmake_minimum_required command is present. A line of code such as >>> >>> cmake_minimum_required(VERSION 3.20) >>> >>> should be added at the top of the file. The version specified may be >>> lower >>> if you wish to support older CMake versions for this project. For >>> more >>> information run "cmake --help-policy CMP". >>> This warning is for project developers. Use -Wno-dev to suppress it. >>> >>> -- Configuring incomplete, errors occurred! >>> >>> >>> this error line is in the file: $SRCROOT/gnucash/gnome/CMakeLists.txt >>> >>> Untar'd and I have changed NOTHING in the source code. >>> I have also tried the following (results from web search). Both >>> resulted in the same error. >>> >>> cmake $SRCROOT -DCMAKE_INSTALL_PREFIX=/usr/local >>> cmake $SRCROOT -DCMAKE_INSTALL_PREFIX=$HOME/.local >>> >>> what is the solution to this stumbling block? >> >> Follow the instructions more carefully: The cmake command should be `cmake >> $SRCROOT` not `cmake $SRCROOT/gnucash`. > > The build directory is not the same as the src directory. > > I tried that as well. Same result. The CMakeOutput.log has n
Re: [GNC-dev] util/gnc-vcs-info fails if building from a Git worktree (with possible solution)
> On Jul 10, 2022, at 4:38 AM, Kevin Buckley wrote:
>
> I have recently discovered that
>
> util/gnc-vcs-info
>
> fails if building from a Git worktree.
>
> Within gnc-vcs-info is this test
>
> # Maybe it's git?
> real_gitdir="${real_srcdir}"/.git
> if test -d "${real_gitdir}"
> then
> ...
>
> however, if you have checked out a Git branch into a worktree,
> then .git will be a file containing the string
>
> gitdir: /path/to/main/working/tree/.git/worktrees/branchname
>
> In order to allow gnc-vcs-info to "do the right thing" from
> within a Git worktree, I'd suggest adding the following stanza
> to gnc-vcs-info, which basically replicates the code from the
> existing "Maybe it's git?" block, but allows for the fact that
> you know it's a worktree
>
> fi
> fi
>
> +# Maybe it's a git worktree?
> +real_gitdir="${real_srcdir}"/.git
> +if test -f "${real_gitdir}"
> +then
> + worktrees=`grep worktrees ${real_gitdir}`
> + if test $? = 0 ; then
> +
> +if [ "$request" = "type" ]
> +then
> + echo "git"
> + exit 0
> +fi
> +
> +# The windows build uses environment variable $GIT_CMD to invoke
> git (adding git
> +# to the PATH in Windows results in a build failure).
> +# So for platform independence, use GIT_CMD for all
> +[ -n "$GIT_CMD" ] || GIT_CMD=git
> +if [ "$request" = "date" ]
> +then
> + exec "$GIT_CMD" log -1 --format=%cd --date=short
> + exit 0
> +fi
> +
> +githead=`"$GIT_CMD" log -1 --pretty=format:"%h" HEAD 2>/dev/null`
> # short hash only
> +if test $? = 0 ; then
> + /bin/echo -n $githead
> + # Add a "+" to the hash if there deleted or modified files (not
> excluded by .gitignore and friends)
> + # "Ignores" untracked files
> + # [ $("$GIT_CMD" ls-files -dkm 2>/dev/null | wc -l) -gt 0 ] &&
> /bin/echo -n "+"
> + # Includes untracked files
> + [ $("$GIT_CMD" ls-files -dkmo --exclude-standard 2>/dev/null |
> wc -l) -gt 0 ] && /bin/echo -n "+"
> + echo
> + exit 0
> +else
> exit 1
> +fi
> +
> + fi
> +fi
> +
> if test -d "${real_srcdir}"/.bzr ;
> then
> # If we're only interested in the vcs type, then we're done here
>
>
> or you might want to come up with something else to handle building
> from a Git Worktree, in which case feel free to (ab)use the above as
> you see fir.
Nice. Please submit that as a Github pull request, see
https://wiki.gnucash.org/wiki/Simple_Pull_Request
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Simple Start to Contributing
Paul, Sounds like you'll fit right in. ;-) Git is an amazing improvement over CVS and subversion. I highly recommend at least skimming Pro Git (https://git-scm.com/book/en/v2, free to read online) to get an idea of how it can help you keep your coding work organized. Regards, John Ralls > On Jul 16, 2022, at 5:44 AM, Paul Kroitor wrote: > > Thanks for your kind welcome, John. > > Well, my first real language was Fortran in the early 70s, but my first love > was 360/ASM. I knew (at least some of) 14 languages when I graduated in 1976 > but you won't have heard of many of them. My first job was > maintaining/extending the (assembly-language, on punch card) mainframe > operating system at a big pharma firm, although everyone else there was > strictly COBOL. I still recall one of my peers trying to persuade the rest > of us that you could write programs without Go-Tos with a new-fangled thing > called Structured Programming. Of course, this wasn't any of my business as > 360/ASM doesn't have the instructions for it. Then, as a young IT department > manager in the early 80s, I can still vividly recall two young > whippersnappers (they were 20; I was 25) in my office trying to persuade me > that COBOL was out of date, and we would all be using C soon. > > In later years I spent most of my time in C, Pascal, and C++, but as Project > Manager or Director of Development. That said, I was always the type to get > my hands dirty, and whenever there was a requirement for low-level stuff > (like x86 Assembler), I always wound up assigning it to myself (it's still > my favourite part). I've written hundreds of things in C++ and other > object-oriented languages. These days the first thing I reach for -- given > the simple things that come my way -- is Python, Powershell, or Javascript. > > The source control I've used is almost exclusively CVS and Subversion, but I > do understand what git is and why it's better. My question about making a > feature branch was a response to an instruction in the Wiki about when to do > so -- this little project seemed to be just on the borderline. Based on your > comments, I'll play it safe and do so. > > I have no trouble following the Guile/Scheme -- Lisp was one of the original > 14 languages I studied in college -- and many reports date back 20 years or > more anyway. The difficulties come more with the layers of approaches / > authors you get in such mature systems. For example, the balance sheet and > income statement use common support modules that enable certain standard > optional behaviours, but the cash flow wasn't written to use said modules, > so one has to duplicate the functionality but really should toss half the > cash-flow and use the (better) common support modules. > > I've built a Rocky 9 (just released, and I want to start testing it anyway) > VM for this and will set up the GnuCash build environment on it next (I did > a similar thing a couple of years ago, it went fine). Then I will move on to > integrating the changes. > > You should know that although I'm retired, I'm very overcommitted, and I > only get to a small percentage of what I hope to achieve. But I will do what > I have time for, with your valuable help. > > Paul > > > -Original Message- > From: John Ralls > Sent: July 15, 2022 7:04 PM > To: Paul Kroitor > Cc: gnucash-devel@gnucash.org > Subject: Re: [GNC-dev] Simple Start to Contributing > > > >> On Jul 15, 2022, at 10:58 AM, Paul Kroitor wrote: >> >> Hi, my apologies for asking such basic questions, but I'm new to >> GnuCash contributions - although not to coding - and want to try a >> simple (useful) change to get my feet wet. So I've "fixed" the >> cash-flow.scm module (the Cash Flow report) locally to adjust a minor >> annoyance (I added a "Show Accounts as Hyperlinks" checkbox so it can >> match the other two standard financial statements). It works the way >> it should now, but needs testing against a broader set of inputs, and the > localizations must get queued. >> >> > > Welcome to GnuCash! > > What languages and programming styles (I mean what are sometimes rather > grandly called paradigms, like object-oriented or functional) do you like? > > Your question about feature branches suggests that you may not be familiar > with git. What source control systems have you used? > >> >> Some questions arise: >> >> 1. Do I have to post anywhere / get agreement before embarking on such >> a contribution (I have 30+ years of experience managing programmers >> and do know I must keep the changes hom
Re: [GNC-dev] [GNC] Unit Tests
> On Aug 11, 2022, at 4:56 AM, Robert Simmons wrote: > > Looking at the code repo I see a directory of unit tests, but it doesn't > look like it has actual unit tests. Do you all do continuous integration > somewhere and have unit tests? When a software defect is identified and > fixed, do you create a unit test based on the fix? If you found only one directory of tests you didn't look very hard: $ find * -name "*test*" -type d | wc -l 25 The tests are mixture of unit tests, fuzzers, and integration tests. You'll notice that there are a lot more in the libgnucash/ core than in the UI-centric gnucash/; that's in large part because the MVC violations we discussed a couple of days ago make it difficult to write tests. That's actually part of a broader problem, that the code isn't well separated for responsibilities so meaningful unit tests aren't always possible. There's a build target "check" to build and run all of the tests. We try to keep the dependencies lined up so that building all isn't a prerequisite but that occasionally gets out of whack so I generally use `ninja && ninja check` to make sure. CI is performed via Github actions, see https://github.com/Gnucash/gnucash/tree/maint/.github/workflows. Contrary to Derek's claim I'm afraid that none of us are sufficiently self-disciplined enough to reliably add a test when we fix a bug. It does happen from time to time, but tests are more often added when refactoring or rewriting than when bug fixing. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Stuck: Creating a distribution list
> On Aug 15, 2022, at 3:27 AM, Ralf Zerres wrote: > > Hey list > > I got stucked while hacking the new distribution list feature in > gnucash > may someone can give me a light, please? > > my latest repro with the code in question is accessible on github > (https://github.com/rzerres/gnucash/tree/coowner) > > I did summerize the intention of the routines in > https://github.com/rzerres/gnucash/blob/coowner/doc/property-management.md > And distribution lists are one peace in the puzzle to predefine > apportionable shares/percentage values to property units. > You may see the analogy to billing terms. > > My problem: > When creating a distribution list assigned to a book > (GncDistributionList * gncDistribListCreate (QofBook *book) line 284: > the attributes of the struct are presetted as expected. > > Then in line 289 i need to add an object (addObj (distriblist). > The fuction call should initialize a pointer to a _book_info structure > (line 105). Analog code is present in gncBillTerm.c and does work as > expected. > Now calling line 107: > > book_info = qof_book_get_data (qof_instance_get_book(distriblist), > _GNC_MOD_NAME); > > will not update as expected. It stays NULL. And i have no clue to > that. > > Is anybody able to explain why? Again, compairing this to gncBillTerm > where the book_info (there: bi) is filled in correctly. Looks like you forgot to call gncDistribListRegister. You probably want to add it to the list in business_core_init() in cashobjects.c. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Database abstraction
> On Aug 16, 2022, at 4:54 AM, Thomas wrote: > > Hello everybody, > > for quite some time I am interested in doing some simple queries against the > data I have in my GnuCash books that I found hard to specify in custom > reports or the like. > As I have some technical background, I was thinking whether there is some DB > abstraction that allows easier queries than the core database model behind > GnuCash. At least for me, it would be easier to write some Python code or SQL > queries rather than writing a custom GnuCash report tbh. > > So a representation closer to the visual representation in GnuCash where it > is easier (without countless JOINs for example) to make queries (e.g., get > all transactions in a specific account that are higher than a certain amount). > > I'd appreciate any kinds of hints on what you would use for such purposes! > > Thanks a lot in advance! For that specific example you could use the Python bindings to call xaccAccountGetSplitList() and filter the result by amount in a list comprehension. The API docs at https://code.gnucash.org/docs/MAINT are a good place to discover more functions like that. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Data Model Schema
The SQL Schema is laid out in https://wiki.gnucash.org/wiki/SQL. There's an attached ERD, but note that it shows secondary keys and auxiliary tables that indicate how GnuCash treats the data once it's loaded. The actual schema defines only a few secondary keys and the data represented in the auxiliary tables is actually stored in the slots table. Also keep in mind that we're still using the both backends as an object store. What enriched metadata are you looking for? How will having it benefit GnuCash? It seems rather presumptuous of you to unilaterally declare your intended derivative project a sibling. Regards, John Ralls IOn Aug 17, 2022, at 9:06 AM, Scott Morgan wrote: > > Hi All, > > Is the Data Model, / DB Schema stored somewhere with enriched metadata? > If not I would like to volunteer to do this work, in part because I'm > probably going to create a sibling Java project at some point to share the > schema / data model. > > Cheers, > Scott > > On Wed, Aug 17, 2022 at 11:00 AM wrote: > >> Send gnucash-devel mailing list submissions to >>gnucash-devel@gnucash.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >>https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> or, via email, send a message with subject or body 'help' to >>gnucash-devel-requ...@gnucash.org >> >> You can reach the person managing the list at >>gnucash-devel-ow...@gnucash.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of gnucash-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: Database abstraction (john) >> >> >> -- >> >> Message: 1 >> Date: Tue, 16 Aug 2022 09:15:46 -0700 >> From: john >> To: Thomas >> Cc: gnucash-devel@gnucash.org >> Subject: Re: [GNC-dev] Database abstraction >> Message-ID: >> Content-Type: text/plain; charset=us-ascii >> >> >> >>> On Aug 16, 2022, at 4:54 AM, Thomas >> wrote: >>> >>> Hello everybody, >>> >>> for quite some time I am interested in doing some simple queries against >> the data I have in my GnuCash books that I found hard to specify in custom >> reports or the like. >>> As I have some technical background, I was thinking whether there is >> some DB abstraction that allows easier queries than the core database model >> behind GnuCash. At least for me, it would be easier to write some Python >> code or SQL queries rather than writing a custom GnuCash report tbh. >>> >>> So a representation closer to the visual representation in GnuCash where >> it is easier (without countless JOINs for example) to make queries (e.g., >> get all transactions in a specific account that are higher than a certain >> amount). >>> >>> I'd appreciate any kinds of hints on what you would use for such >> purposes! >>> >>> Thanks a lot in advance! >> >> For that specific example you could use the Python bindings to call >> xaccAccountGetSplitList() and filter the result by amount in a list >> comprehension. The API docs at https://code.gnucash.org/docs/MAINT are a >> good place to discover more functions like that. >> >> Regards, >> John Ralls >> >> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> >> -- >> >> End of gnucash-devel Digest, Vol 233, Issue 6 >> * >> > > > -- > Regards, > Scott Morgan > President & CEO > Adligo Inc > http://www.adligo.com > https://www.linkedin.com/in/scott-morgan-21739415 > A+ Better Business Bureau Rating > <https://www.bbb.org/chicago/business-reviews/computer-software-publishers-and-developers/adligo-inc-in-chicago-il-88381256> > https://github.com/adligo > > By Appointment Only: > 1-866-968-1893 Ex 101 > sc...@adligo.com > skype:adligo1?call > Send Me Files Securely: > *https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI > <https://www.sendthisfile.com/f.jsp?id=ewOnyeFQM18IDRf7MMIdolfI>* > https://discord.com/ > Adligo#3066 > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Data Model Schema
Scott, No, accounting software isn't a fancy spreadsheet. The math part is a lot simpler, but accounting is all about rules. The rules part is harder. That's not to say that you can't use a spreadsheet to do your accounting, lots of people do, but a relational database approach is a much better fit. There's no need to invent yet another financial data interchange format, there are plenty already: Intuit's proprietary QIF and QBO formats, the public OFX one (which Intuit calls QFX), and the banking industry's SWIFT and ISO-20022 are all widely used. You still haven't said what "enriched metadata" means or why we'd be interested in having it. Regards, John Ralls > On Aug 20, 2022, at 12:06 PM, Scott Morgan wrote: > > Hi John, > > Well, I did some work building an open source Java Accounting Model > (adligo.org <http://adligo.org/>) a few times of the past two decades. Now I > find my self using QuickBooks online, so I have been looking for some > collaborators and gnucash seems like the most successful project out there. > The enriched metadata would allow me to build ETL tools to go back and forth > between QuickBooks, my system and gnucash. > In my opinion accounting systems are basically the evolution of / fancy > spreadsheets. The main difference is the way transactions are linked in > double-sided accounting. Longer term I'm hoping for some sort of > import-export standardization of accounting data.The current standard > seems to still be CSV files, which have problems binding the accounts > together. You can do this by tracking source systems and source Ids. But > it's still fairly painful. > So I figured I would start looking at the model you all were using inside > of GnuCash. > > On Sat, Aug 20, 2022 at 11:51 AM john <mailto:jra...@ceridwen.us>> wrote: >> The SQL Schema is laid out in https://wiki.gnucash.org/wiki/SQL. There's an >> attached ERD, but note that it shows secondary keys and auxiliary tables >> that indicate how GnuCash treats the data once it's loaded. The actual >> schema defines only a few secondary keys and the data represented in the >> auxiliary tables is actually stored in the slots table. Also keep in mind >> that we're still using the both backends as an object store. >> >> What enriched metadata are you looking for? How will having it benefit >> GnuCash? >> >> It seems rather presumptuous of you to unilaterally declare your intended >> derivative project a sibling. >> >> Regards, >> John Ralls >> >> IOn Aug 17, 2022, at 9:06 AM, Scott Morgan > <mailto:sc...@adligo.com>> wrote: >>> >>> Hi All, >>> >>> Is the Data Model, / DB Schema stored somewhere with enriched metadata? >>> If not I would like to volunteer to do this work, in part because I'm >>> probably going to create a sibling Java project at some point to share the >>> schema / data model. >>> >>> Cheers, >>> Scott >>> >>> On Wed, Aug 17, 2022 at 11:00 AM >> <mailto:gnucash-devel-requ...@gnucash.org>> wrote: >>> >>>> Send gnucash-devel mailing list submissions to >>>>gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org> >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>>> or, via email, send a message with subject or body 'help' to >>>>gnucash-devel-requ...@gnucash.org >>>> <mailto:gnucash-devel-requ...@gnucash.org> >>>> >>>> You can reach the person managing the list at >>>>gnucash-devel-ow...@gnucash.org >>>> <mailto:gnucash-devel-ow...@gnucash.org> >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of gnucash-devel digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Database abstraction (john) >>>> >>>> >>>> -- >>>> >>>> Message: 1 >>>> Date: Tue, 16 Aug 2022 09:15:46 -0700 >>>> From: john mailto:jra...@ceridwen.us>> >>>> To: Thomas >>> <mailto:tduellmann%2bgnucashde...@gmail.com>> >>>> Cc: gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org> >>>> Subject: Re
Re: [GNC-dev] Data Model Schema
> On Aug 21, 2022, at 7:51 AM, Michael or Penny Novack > wrote: > > I do not understand what you could mean by going back and forth from > Quickbools to gnucash (or any other double entry bookkeeping software) as > Quickbooks is not double entry. Michael, you're confusing Quicken that isn't double-entry with QuickBooks that is. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building Mac version using SDK 12
> On Sep 14, 2022, at 9:41 PM, Mike Alexander wrote: > > When I try to build either current maint or master using MacOSX12.1.sdk or > MacOSX12.3.sdk for SDKROOT I get compile errors in gnc-filepath-utils.cpp. > The first error is > > In file included from > /System/Volumes/Data/tools/gnucash-maint/gnucash/libgnucash/core-utils/gnc-filepath-utils.cpp:64: > In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:12: > /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSBundle.h:91:143: > error: function does not return NSString > - (NSAttributedString *)localizedAttributedStringForKey:(NSString *)key > value:(nullable NSString *)value table:(nullable NSString *)tableName > NS_FORMAT_ARGUMENT(1) NS_REFINED_FOR_SWIFT API_AVAILABLE(macos(12.0), > ios(15.0), watchos(8.0), tvos(15.0)); > /Library/Developer/CommandLineTools/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:103:48: > note: expanded from macro 'NS_FORMAT_ARGUMENT' >#define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A))) > > This is probably because there is something wrong with my build environment, > but I was wondering if anyone else had seen this? Mike, I haven't had any errors like that. I don't understand the error but it seems to be an SDK error rather than anything we're doing. Might the compiler have gotten out of sync with the SDK? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building Mac version using SDK 12
> On Sep 15, 2022, at 12:47 PM, Rob Gowin wrote: > > There are suggestions on the interweb that adding -DNS_FORMAT_ARGUMENT(A)= to > compiler options will work around this problem. > That seems unwise. https://stackoverflow.com/questions/18449176/objective-c-format-string-is-not-a-string-literal-potentially-insecure-warn Objective-C: "format string is not a string literal (potentially insecure)" warning with macro stackoverflow.com provides a detailed explanation of what that NS_FORMAT_ARGUMENTS is for. I don't see anything in gnc-filepath-utils.cpp that would incite that warning. https://discuss.tvm.apache.org/t/macos-latest-command-line-tools-clt-crashes-build-for-metal/12413 advocates editing NSBundle.h to change the return type of localizedAttributedStringForKey: from NSAttributedString* to NSString*. That also seems unwise. https://forum.arduino.cc/t/build-question-about-old-node-module-requested-by-package-json/936228reports that the user was able to make the error go away by upgrading his OS to macOS12. I didn't see the host macOS version mentioned on any of the other reports of this failure, but it wouldn't be the first time that I've encountered problems with building using a newer MacOSX SDK than the running macOS version. One can get older versions of Xcode and the command line tools at https://developer.apple.com/downloads; you have to sign in with your Apple ID. I don't know if you have to be an enrolled developer too. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Conditions to move revamped GnuCash Mobile App to GnuCash org
> On Sep 28, 2022, at 5:09 PM, Daniel Brown wrote: > > Hello GnuCash devs, > > does someone here have (had) a relation to the gnucash-android project? > I couldn't find a way to contact the mainter "codinguser" and the project is > abandoned: https://wiki.gnucash.org/wiki/GnuCash_and_Mobile_Devices > > Recently there have been a couple of people (including me) who would like to > contribute/maintain/fork/rewrite the project to keep it alive: > https://github.com/codinguser/gnucash-android/issues/913 > > I have started a couple of steps to revive the project and will try to > establish a new leading fork so that all the open contributions can find its > way into the app. And as part of this revamp I would consider aligning the > project to gnucash.org > > What would be necessary, to move and continue the project under the gnucash > org in the future? > > I mean not only GitHub organization, but it would would be great to see the > project as an official part of the community, with vendor "GnuCash" in the > app store, mailing-list for support and so on. Ngewi created Gnucash for Android as a Google Summer of Code project. The previous year's GSoC student, Muslim Choclov, acted as Ngewi's mentor, and since we were denied direct participation I arranged for the Gnome Foundation to get us a slot. Several of us provided Ngewi with technical advice while he was working on the original implementation, particularly with details about which import format would work best. Ngewi requested that we allow him to piggyback onto our (really Christian Stimming's) legacy free UserVoice account; 2013 was about the time that Uservoice stopped allowing new free accounts. Christian duly created a sub-account for him and he used it for a bug tracker until he bailed We haven't heard from Ngewi for more than 4 years and we removed the reference to GnuCash for Android 2 years ago because it was clear at that time that Ngewi wasn't coming back. The short version of all that is that GfA has never been a part of GnuCash: Once he'd completed the GSoC project he didn't interact much with us at all, nor we with him or the GfA project. Every once in a while someone will pop in and ask something about GfA on gnucash-users or the #gnucash IRC channel. We tell them we don't really know anything about GfA and they go away. AFAIK--and I encourage somebody to contradict me here--nobody who uses the mailing lists or IRC channel regularly uses GfA. Add to that that while https://github.com/codinguser/gnucash-android/issues/913 has been going on for more than 9 months you're the first person to come here to discuss it and it's pretty easy to conclude that the GfA community, such as it is, isn't all that interested in GnuCash. So for GfA to "join the GnuCash community", GfA users and developers have to join the GnuCash community. A good way to start would be to hang out in gnucash-user and on the IRC channel. When somebody comes along with a GfA question, answer it. Encourage users in the other GfA channels to ask their questions and offer their help in gnucash-user too. For the developers, engage here in gnucash-devel and in gnucash-user. Do market research: Why don't GnuCash more users with Android phones use GfA? Can/should GfA integrate better with GnuCash? How? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Conditions to move revamped GnuCash Mobile App to GnuCash org
> On Sep 28, 2022, at 5:37 PM, Camille Rizko via gnucash-devel > wrote: > > Hello, I also wrote a Gnucash viewer for the iphone. It does not have all > the functionality, but it is a good start. Not sure if it is worth starting a > gnucash-iphone project with it. I can make the source code available. See my answer to Daniel, but in addition: Making your source code available isn't good enough. GnuCash is a Free (as in Freedom) software project and community. If you want your project to be part of that then you must also embrace the principles of Free Software, which means not just making your sources available but allowing others to modify it and freely publish their modifications. IMO the best way to do that is to license your code with the GPL because it ensures that those others also must allow others to modify their modifications, but for the less doctrinaire there are a bunch of other licenses, see https://opensource.org/licenses. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Flatpak GnuCash and Finance::Quote
> On Oct 2, 2022, at 3:38 PM, Bruce Schuck wrote: > > Hello all, > > Noticing that the most recent Flatpak version of GnuCash (4.12+ (Flathub > 4.12)) has v1.49 of Finance::Quote, I wanted to update to the recent release > candidate I pushed to CPAN. I believe there are issues running gnc-fq-update > or cpan within the flatpak container because some of the modules required by > F::Q v1.52 and later require the gcc compiler to make and install. As far as > I can see, gcc is not in the flatpak GnuCash distribution. > > While copying the ./lib/Finance tree from GitHub or a downloaded tarball may > seem to work, some of the lesser used methods for data retrieval may not work. Bruce, Correct. IIUC there are a lot of things not normally included in a flatpak installation required to run cpan, so it's not really a practical option. We build Finance::Quote and all of its dependencies from source tarballs, see https://github.com/Gnucash/gnucash-on-flatpak/blob/master/modules/finance-quote-sources.json. Unfortunately F::Q has a lot of dependencies and the list isn't stable, so keeping up with the latest often falls in the "too much effort" category and doesn't get done. If there's a better way, please share. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Flatpak GnuCash and Finance::Quote
> On Oct 3, 2022, at 7:56 PM, Frank H. Ellenberger > wrote: > > Hi, > > comments inline > > Am 03.10.22 um 18:23 schrieb Bruce Schuck: >>> Date: Sun, 2 Oct 2022 21:09:31 -0700 From: john >>> Correct. IIUC there are a lot of things not normally included in a >>> flatpak installation required to run cpan, so it's not really a >>> practical option. We build Finance::Quote and all of its dependencies >>> from source tarballs, see >>> https://github.com/Gnucash/gnucash-on-flatpak/blob/master/modules/finance-quote-sources.json. >>> Unfortunately F::Q has a lot of dependencies and the list isn't >>> stable, so keeping up with the latest often falls in the "too much >>> effort" category and doesn't get done. >>> If there's a better way, please share. >> John, >> Trust me, if I knew a better way I would share. But you answered my unasked >> question as to whether or not including GCC is feasible or may be included >> in the future. > > From > https://docs.flatpak.org/en/latest/building-introduction.html#software-development-kits-sdks > etc. I would suspect, our users have to install org.gnome.sdk to have the > compiler inside the flatpaks available. > >> My concern is that the copy from GitHub ./lib/Finance to , >> while working for the AlphaVantage currency fix, may not necessarily work >> for other modules that require those modules that need compiling to install >> not included in the flatpak. >> Being a somewhat recent addition to the F::Q maintainer team (and lately the >> sole active member), I am unsure why there is a huge number of additional >> module requirements between 1.49 and 1.52. > > It seems cpan generates on each run a different order of building the > required modules. That makes it not really easy to find the diffs. Bruce, Frank is the one who's actually done the work of getting the Finance::Quote build into the Flatpak, so he's the best one to answer the question. Adding to his response, keep in mind that the F::Q build starts from whatever Flatpak's perl has and building a full dependency stack, so if something halfway down changes one of its dependencies it can require substantial changes even if F::Q didn't change anything. On the other hand, the latest F::Q might work perfectly with the older version of that dependency. Like most package managers cpan is quite aggressive in pushing the latest of everything, so using it as a guide might be making extra work... but then not using it as a guide is also extra work. :-/ Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash for Android -> GnuCash Pocket?
> On Oct 7, 2022, at 5:52 AM, Daniel Brown wrote: > > Hello GnuCash devs, > > thank you for your recent feedback on the history and possible future of > GnuCash for Android. > I used it in my outline post: > https://github.com/codinguser/gnucash-android/issues/913#issuecomment-1263624322 > > What do you think about the name proposal: *GnuCash Pocket* > /small, mobile, wallet, complementary, compatible/ > Do you agree, that it's a suitable name? I think that it creates the impression that you have a mobile implementation of GnuCash rather than a companion app. You could overcome that to some extent with a tagline like "The Android companion for GnuCash" or you could go for a longer name like "The GnuCash Pocket Companion". In the latter case you could still use the shorter form for things like your web domain (e.g. gnucashpocket.org <http://gnucashpocket.org/>) and git repository. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] gnucash maint: Compatibility with XCode's "new build system"
> On Oct 9, 2022, at 12:00 PM, gnucash-patches-requ...@gnucash.org wrote: > Updatedvia https://github.com/Gnucash/gnucash/commit/2d3e80ea > (commit) > from https://github.com/Gnucash/gnucash/commit/5ed45e08 (commit) > > > > commit 2d3e80ea086c1014ca73fb04576721ed43c48cd2 > Author: Mike Alexander > Date: Sun Oct 9 00:47:12 2022 -0400 > >Compatibility with XCode's "new build system" > >With XCode 14 or newer CMake tries to use the "new build system" which has > a >requirement that if two targets depend on the same generated file one of > them >must depend on the other. This commit adds reduntant dependencies to > satisfy >this requirement. > > > > Summary of changes: > bindings/guile/CMakeLists.txt | 4 +++- > common/test-core/CMakeLists.txt | 1 + > gnucash/gnome-utils/CMakeLists.txt | 1 + > gnucash/gnome/CMakeLists.txt| 3 ++- > gnucash/html/CMakeLists.txt | 1 + > gnucash/report/CMakeLists.txt | 2 ++ > libgnucash/app-utils/CMakeLists.txt | 2 +- > po/CMakeLists.txt | 4 > 8 files changed, 15 insertions(+), 3 deletions(-) Mike, Xcode doesn't have cmake and I've been using Xcode 14 beta for months without problems. Is this really MacPorts recent update to 3.23.4? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Dependencies policy for major releases
We're getting close to starting the beta testing cycle for GnuCash 5.0. Part of the preparations is deciding the minimum versions to set for dependencies; those minimum versions influence what features we can support and code complexity. For example, we merged a patch last year to enable SEPA internal transfers using AQBanking. It requires a feature introduced in AQBanking 6.4.0, so of GnuCash to be buildable with older versions of AQBanking the build has to detect the AQBanking version and either compile or not compile the code that implements the feature. When I started working on GnuCash 13 years ago the policy was that minimum dependency versions were what was provided by the current RHEL release. Some time around 10 years ago we noticed that RHEL had stopped including not just GnuCash but several of our dependencies and was falling behind on significant updates. Within a couple of years Red Hat created Fedora with a 6-month release cycle and Canonical started up and began releasing Ubuntu with a similar 6-month release cycle. Gtk had a major release, Gtk3, with some pretty substantial API changes. WebKitGtk, which we use to render reports, stopped supporting Gtk2. We ignored all of that until 2017 when an OpenSuSE packager informed us--6 months before we were to release GnuCash 2.8--that they weren't going to package WebKitGtk 2.10, the last version that supported Gtk2, and that if we didn't update our dependency we wouldn't be in the next distribution. Red Hat soon warned us that would be true for the next release of Fedora too. Geert started a crash Gtk3 migration and I migrated WebKitGtk. The current RHEL still didn't support Gtk3, so we clearly needed a new dependency version benchmark. We settled on the 1 version old Ubuntu LTS release, 14.04. We did the same for 4.0, basing our dependency minimum versions on Ubuntu 18.04. What about Windows and macOS? On Windows we use MSYS2/MinGW-w64 and they, like Arch Linux, always have the latest stable releases of everything they supply and we build the rest. On macOS we build the entire stack from source and can similarly use recent stable releases. Minimum dependency versions are of concern only on Linux. Our Ubuntu policy would have us set the dependencies based on Ubuntu 20.04 LTS, but that has only AQBanking 6.0.1 and we'd like to make the minimum 6.4 so that we can remove the conditional compilation mentioned in the first paragraph. There's been another major change in the Linux ecosystem: Flatpak. It's always reasonably up to date, it's distribution agnostic, and it enables us to package GnuCash for immediate consumption: We even have nightly builds of both the stable and development branches. For those who prefer to build their own versions of GnuCash flatpak also affords an up to date build environment regardless of what's provided by the installed distribution. The most extreme policy would be that the minimum dependency level for any release, even a minor one, is that we code to the dependency's current stable release without any conditional compilation and set the minimum requirement to whatever we use from that dependency. Sticking with AQBanking, the current stable release is 6.5, but we don't use any 6.5 API; we do use functions introduced in 6.4 so that would be the minimum version. If the AQBanking developers add new API that we want or need (thinking of the FinTS change in 2020) in say, summer 2024, then the minimum version for the subsequent release (5.13 if we get 5.0 out next March) would be the stable release providing that new API. A more conservative position would freeze the minimum version at 6.4 for the duration of the 5.x series so that the new code would have to be conditionally compiled in the maintenance branch until it gets replaced with the release of GnuCash 6.0. What really makes sense? How many users are building for themselves and on what? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Building MacOS/Quartz from source: environment PREFIX, CXXFLAGS, etc?
> On Oct 31, 2022, at 12:53 AM, Jim DeLaHunt wrote: > > Hi, > > I am trying to build GnuCash 4.11 from source on macOS 12.6 (M1 CPU), > following the instructions at https://wiki.gnucash.org/wiki/MacOS/Quartz . > > I have finished the preliminaries, so I appear to have jhbuild running. I > encounter difficulty with the command: > > jhbuild bootstrap-gtk-osx > > It throws a succession of Python KeyErrors, looking for environment variables > PREFIX, CXXFLAGS, and I assume CC and CFLAGS as well. For instance > > % jhbuild bootstrap-gtk-osx > Loading .env environment variables... > Traceback (most recent call last): > File "/Users/gtkdeveloper/Source/jhbuild/jhbuild/config.py", line 194, in > load > execfile(filename, config) > File "/Users/gtkdeveloper/Source/jhbuild/jhbuild/utils/compat.py", line 67, > in execfile > exec(code, globals, locals) > File "/Users/gtkdeveloper/.config/jhbuildrc", line 474, in > exec(compile(open(_user_rc, "rb").read(), _user_rc, 'exec')) > File "/Users/gtkdeveloper/.config/jhbuildrc-custom", line 3, in > prefix = os.environ['PREFIX'] > File > "/Users/gtkdeveloper/.new_local/share/pyenv/versions/3.10.2/lib/python3.10/os.py", > line 679, in __getitem__ > raise KeyError(key) from None > KeyError: 'PREFIX' > jhbuild: could not load config file > % > > The wiki page MacOS/Quartz does not mention these environment variables. > > Where are they described? What values should I assign for them? I would > appreciate a link to whatever page I should read next. Jim, Sorry. There were a couple of mistakes in gnucash-on-osx/jhbuild-custom. I just pushed a commit to fix them. With that in place, the build will default to $HOME/gnucash with subdirectories src, build, and inst, the latter being short for install. You can override that by setting PREFIX in the environment, e.g. PREFIX=$HOME/mygnucashbuild/ and jhbuild will create the subdirectories. I've updated the wiki page to reflect the current layout. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Various failures while building MacOS/Quartz from source
> On Nov 3, 2022, at 1:56 AM, Jim DeLaHunt wrote: > > On 2022-11-01 12:58, John Ralls wrote: > >> >>> On Oct 31, 2022, at 9:46 PM, Jim DeLaHunt wrote: >>> >>> I am continuing my attempt to build GnuCash 4.11 from source on macOS 12.6 >>> (M1 CPU), following the instructions at >>> https://wiki.gnucash.org/wiki/MacOS/Quartz >>> >>> In the next 46,000 lines of output, there were about six failures: >>> >>> 1. during phase build of >>> >>> freetype:/Users/gtkdeveloper/gnucash/src/freetype-2.11.1/src/autofit/afshaper.h:30:10: >>> fatal error: 'hb-ft.h' file not found >>> ...[2 through 6 elided]... >>> >> Jim, >> >> I just did a test build and it worked. There are a couple of minor fixups >> required in makefiles for xml-sec (your #4) and libdbi (#6), and >> libdbidrivers is broken and requires a manual step as a workaround. >> >> Failures 2 and 3 are because you didn't fix #1. #1's error indicates that >> it failed because harfbuzz-no-cairo built without freetype; that's probably >> because freetype-no-harfbuzz failed and you tried to keep going > > Interesting. Thank you for the insights. > > I searched the stdout from my build attempt. I did not find any diagnostic > line about installing a file 'hb-ft.h'. I did see diagnostics which seemed to > say that freetype-no-harfbuzz and harfbuzz-no-cairo installed without error. > > Which module should install file 'hb-ft.h'? harfbuzz-no-cairo, perhaps? Yes. [SNIP] > Run-time dependency freetype2 found: NO (tried pkgconfig, framework and cmake) [SNIP] > Font callbacks (the more the merrier) > FreeType : NO Which is why it didn't install hb-ft.h, nor, presumably, build the corresponding objects. [SNIP] > There is a file 'hb-ft.h' as part of harfbuzz 4.1.0[1]. > > [1] <https://github.com/harfbuzz/harfbuzz/blob/4.1.0/src/> > > I see "installing" messages for 33 files in > /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0/src/hb-*.h. I count 39 such > filenames in harfbuzz [1]. > > The hb-*.h files not installed seem to be: hb-ft.h, hb-directwrite.h, > hb-gdi.h, hb-graphite2.h, hb-uniscribe.h, hb-version.h. > I recognise directwrite, gid, and uniscribe as Windows subsystems, and > graphite2 as another text renderer, all reasonably not installed on Harfbuzz > for macOS. I don't understand why hb-ft.h or hb-version.h would not be > installed. But I have not investigated that yet. > > Any further insights you might be able to share? So the question is now why didn't pkg-config find Freetype? Does /Users/gtkdeveloper/gnucash/lib/pkgconfig/freetype2.pc exist? (It should, the installation is right after your elision note.) If so, does starting a shell (`jhbuild shell`) and running `pkg-config --modversion freetype2` return a version string? If not, what is the result of `echo $PKG_CONFIG_PATH`? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Various failures while building MacOS/Quartz from source
Jim, > % ls -lF /Users/gtkdeveloper/gnucash/lib/pkgconfig/* > zsh: no matches found: /Users/gtkdeveloper/gnucash/lib/pkgconfig/* > > But that file does exist elsewhere on the path: > Sorry, forgot the 'inst/' when typing the path. /Users/gtkdeveloper/gnucash/inst/lib/pkgconfig/* is where it belongs. > On Nov 4, 2022, at 12:27 AM, Jim DeLaHunt wrote: > > % pkg-config --print-errors --exists freetype2 > Package libbrotlidec was not found in the pkg-config search path. > Perhaps you should add the directory containing `libbrotlidec.pc' > to the PKG_CONFIG_PATH environment variable > Package 'libbrotlidec', required by 'freetype2', not found > Aha! Another gtk-osx user experienced that failure a couple of weeks ago [1]. You have libbrotli installed somewhere outside of /Users/gtkdeveloper/gnucash that Cmake can find it and pkg-config can't. That makes meson decide that it can't use that freetype to build harfbuzz so it ignores it and builds harfbuzz without freetype. Add module_cmakeargs['freetype']="-DFT_DISABLE_BROTLI=YES" module_cmakeargs['freetype-no-harfbuzz']="-DFT_DISABLE_BROTLI=YES" to /Users/gtkdeveloper/.config/jhbuildrc-custom and run jhbuild buildone -fc freetype-no-harfbuzz jhbuild build I just pushed a commit to gtk-osx to make Harfbuzz fail immediately if it's unhappy with Freetype for some reason. That should make troubleshooting this kind of problem a little quicker. Regards, John Ralls [1] https://gitlab.gnome.org/GNOME/gtk-osx/-/issues/62 <https://gitlab.gnome.org/GNOME/gtk-osx/-/issues/62> ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Various failures while building MacOS/Quartz from source
> On Nov 5, 2022, at 2:21 AM, Jim DeLaHunt wrote: > > On 2022-11-04 13:44, john wrote: > >> On Nov 4, 2022, at 12:27 AM, Jim DeLaHunt wrote: >>> % pkg-config --print-errors --exists freetype2 >>> Package libbrotlidec was not found in the pkg-config search path. >>> Perhaps you should add the directory containing `libbrotlidec.pc' >>> to the PKG_CONFIG_PATH environment variable >>> Package 'libbrotlidec', required by 'freetype2', not found >>> >> Aha! Another gtk-osx user experienced that failure a couple of weeks ago >> [1]. You have libbrotli installed somewhere outside of >> /Users/gtkdeveloper/gnucash that Cmake can find it and pkg-config can't. >> That makes meson decide that it can't use that freetype to build harfbuzz so >> it ignores it and builds harfbuzz without freetype. >> >> Add >> module_cmakeargs['freetype']="-DFT_DISABLE_BROTLI=YES" >> module_cmakeargs['freetype-no-harfbuzz']="-DFT_DISABLE_BROTLI=YES" >> >> to /Users/gtkdeveloper/.config/jhbuildrc-custom and run >> jhbuild buildone -fc freetype-no-harfbuzz >> jhbuild build >> >> I just pushed a commit to gtk-osx to make Harfbuzz fail immediately if it's >> unhappy with Freetype for some reason. That should make troubleshooting this >> kind of problem a little quicker. > > Thank you. That got me a step further. > > freetype-no-harfbuzz now compiles happily, but harfbuzz-no-cairo seems to be > unhappy about freetype's lack of libbrotlidec in the same way: > > = > > *** Configuring harfbuzz-no-cairo *** [2/2] > The Meson build system > Version: 0.63.3 > Source dir: /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0 > Build dir: /Users/gtkdeveloper/gnucash/build/harfbuzz-4.1.0 > Build type: native build > Project name: harfbuzz > Project version: 4.1.0 > C compiler for the host machine: > /Library/Developer/CommandLineTools/usr/bin/gcc (clang 14.0.0 "Apple clang > version 14.0.0 (clang-1400.0.29.202)") > C linker for the host machine: > /Library/Developer/CommandLineTools/usr/bin/gcc ld64 820.1 > C++ compiler for the host machine: > /Library/Developer/CommandLineTools/usr/bin/g++ (clang 14.0.0 "Apple clang > version 14.0.0 (clang-1400.0.29.202)") > C++ linker for the host machine: > /Library/Developer/CommandLineTools/usr/bin/g++ ld64 820.1 > Host machine cpu family: aarch64 > Host machine cpu: arm64 > Compiler for C++ supports link arguments -Bsymbolic-functions: YES > Compiler for C++ supports arguments -fno-exceptions: YES > Compiler for C++ supports arguments -fno-rtti: YES > Compiler for C++ supports arguments -fno-threadsafe-statics: YES > Compiler for C++ supports arguments -fvisibility-inlines-hidden: YES > Library m found: YES > Found pkg-config: /Users/gtkdeveloper/gnucash/inst/bin/pkg-config (0.29.2) > Found CMake: /Users/gtkdeveloper/gnucash/inst/bin/cmake (3.20.0) > Run-time dependency freetype2 found: NO (tried pkgconfig, framework and cmake) > Not looking for a fallback subproject for the dependency freetype2 because: > Use of fallback dependencies is disabled. > > ../../src/harfbuzz-4.1.0/meson.build:87:0: ERROR: Dependency 'freetype2' is > required but not found. > > A full log can be found at > /Users/gtkdeveloper/gnucash/build/harfbuzz-4.1.0/meson-logs/meson-log.txt > meson --prefix /Users/gtkdeveloper/gnucash/inst --libdir lib > -Dcoretext=enabled -Dfreetype=enabled -Ddocs=disabled -Dbenchmark=disabled > -Dintrospection=disabled --wrap-mode=nofallback > /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0 > *** Error during phase configure of harfbuzz-no-cairo: ## Error > running meson --prefix /Users/gtkdeveloper/gnucash/inst --libdir lib > -Dcoretext=enabled -Dfreetype=enabled -Ddocs=disabled -Dbenchmark=disabled > -Dintrospection=disabled --wrap-mode=nofallback > /Users/gtkdeveloper/gnucash/src/harfbuzz-4.1.0 *** [2/2] > > = > > The relevant part of meson-log.txt seems to say: > > = > > Pkg-config binary for 1 is not cached. > Pkg-config binary missing from cross or native file, or env var undefined. > Trying a default Pkg-config fallback at pkg-config > Found pkg-config: /Users/gtkdeveloper/gnucash/inst/bin/pkg-config (0.29.2) > Determining dependency 'freetype2' with pkg-config executable > '/Users/gtkdeveloper/gnucash/inst/bin/pkg-config' > env[PKG_CONFIG_PATH]: > /Users/gtkdeveloper/gnucash/inst/lib/pkgconfig:/Users/gtkdeveloper/gnucash/inst/share/pkgconfig:/usr/lib/pkgconfig > Called `/Users/gtkdeveloper/gnucash/inst/bin/pkg-config --modversion
Re: [GNC-dev] Easy and Tax Invoice Reports
> On Nov 7, 2022, at 12:28 AM, Vesna Micajkova > wrote: > > > > Hello everyone! > > > > First of all, thank you for this great program. I am an accounting professor > and I am using GnuCash for educational purposes and I am very satisfied with > its features. I am exploring the opportunities for this program usage by > enterprises in my country since there is no translation in Macedonian > language yet. So, I was looking for possibility of completely translation of > invoice and find out that there is no opportunity for translating the > following strings: Invoice Date and Due Date. If those strings can be added > to Easy and Tax Invoice Reports options the invoices can be completely > translated in any language. > > If you can make this addition, I think it will make a great deal for users. > If, I have missed the possibility for these strings translation in the > program, I will be very grateful if you can inform me where to find it. > > I hope I am addressing on right place, if not, I am sorry for the > disturbance. > You're in the right place. But both those strings are in gnucash.pot and translatable. Is there somewhere in the UI where you find them to be untranslated? If so, where? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Easy and Tax Invoice Reports
Dr. Micajkova, Please remember to copy the list on all replies. "Reply-all" does the job on most mail clients; some have a "Reply-list" function as well. The screen shot shows an untranslated UI, so it doesn't illustrate your claim that there are untranslated strings. Please set your locale to one of the 100% translated languages (the ones with a check-mark) on this page: https://hosted.weblate.org/projects/gnucash/gnucash/ and see if the strings you think are untranslated really are. You'll see on that page that Frank has added Macedonian, so you can create a Weblate userid and start translating. You'll find instructions at https://wiki.gnucash.org/wiki/Translation. Regards, John Ralls > On Nov 7, 2022, at 11:27 PM, Vesna Micajkova > wrote: > > Hello John! > > Thank you very much for your reply. Attached I am sending you PrtSc of the > UI where I am making this translation. > > Best regards, > > > > Vesna Micajkova, PhD > > Institute Praktikum > St. Ohridska 39/1, Skopje > Tel: ++389 70 766 463. > www.casoviposmetkovodstvo.mk > > > > > > > > -Original Message- > From: john [mailto:jra...@ceridwen.us] > Sent: Monday, November 7, 2022 6:32 PM > To: Vesna Micajkova > Cc: gnucash-devel@gnucash.org > Subject: Re: [GNC-dev] Easy and Tax Invoice Reports > > > >> On Nov 7, 2022, at 12:28 AM, Vesna Micajkova > wrote: >> >> >> >> Hello everyone! >> >> >> >> First of all, thank you for this great program. I am an accounting > professor >> and I am using GnuCash for educational purposes and I am very satisfied > with >> its features. I am exploring the opportunities for this program usage by >> enterprises in my country since there is no translation in Macedonian >> language yet. So, I was looking for possibility of completely translation > of >> invoice and find out that there is no opportunity for translating the >> following strings: Invoice Date and Due Date. If those strings can be > added >> to Easy and Tax Invoice Reports options the invoices can be completely >> translated in any language. >> >> If you can make this addition, I think it will make a great deal for > users. >> If, I have missed the possibility for these strings translation in the >> program, I will be very grateful if you can inform me where to find it. >> >> I hope I am addressing on right place, if not, I am sorry for the >> disturbance. >> > > You're in the right place. > > But both those strings are in gnucash.pot and translatable. Is there > somewhere in the UI where you find them to be untranslated? If so, where? > > Regards, > John Ralls > > > -- > This email has been checked for viruses by AVG antivirus software. > www.avg.com > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Various failures while building MacOS/Quartz from source
> On Nov 8, 2022, at 1:03 AM, Jim DeLaHunt wrote: > > On 2022-11-06 16:17, John Ralls wrote: > >> >>> On Nov 6, 2022, at 1:33 PM, Jim DeLaHunt wrote: >>> >>> Yes, you did, and I appreciate it. As you will have read above, >>>> freetype-no-harfbuzz now compiles happily... >>>> Rebuilding Harfbuzz isn't going to get rid of Freetype's dependency on >>>> brotli. Harfbuz doesn't know anything about broil. >>> Agreed. Adding the cmakeargs of "-DFT_DISABLE_BROTLI=YES" appeared to get >>> rid of Freetype's dependency on brotli, _for the purpose of compiling >>> freetype-no-harfbuzz_. >>> >>> I am moving on to the next problem, which is that harfbuzz-no-cairo fails >>> to build, despite the successful fix which enabled Freetype to build in a >>> way acceptable freetype-no-harfbuzz. And the symptoms of the next problem >>> are interestingly similar to the symptoms of the previous problem. >> No, harfbuzz-no-cairo fails to build because the rebuild of >> freetype-no-harfbuzz *didn't* succeed in removing its dependency on brotli. >> That's what >> >>> pkg-config error with 'freetype2': Could not generate cargs for freetype2: >>> Package libbrotlidec was not found in the pkg-config search path. >>> Perhaps you should add the directory containing `libbrotlidec.pc' >>> to the PKG_CONFIG_PATH environment variable >>> Package 'libbrotlidec', required by 'freetype2', not found >>> >> is telling you. One possibility is that the install step didn't replace >> /Users/gtkdeveloper/gnucash/inst/lib/pkgconfig/freetype2.pc, the other is >> that cmake ignored FT_DISABLE_BROTLI perhaps because >> BROTLIDEC_INCLUDE_DIRS:PATH and BROTLIDEC_LIBRARIES:FILEPATH are already set >> in CMakeCache.txt. >> >>> I read that sentence and took it to heart. You will see a mention of >>> /Users/gtkdeveloper in my logs. gtkdeveloper is a macOS user account I >>> created specifically to build GnuCash. It does not have any of my primary >>> account's path or environment changes. I have not told it about MacPorts. >>> >>> As far I as know, MacPorts installs many files to /opt/local/*, and acts >>> like it owns that directory subtree. It installs apps to >>> /Applications/MacPorts . Users are responsible for adding /opt/local/bin to >>> their own paths. As far as I know from monitoring the project's user and >>> developer lists, MacPorts tries to avoid installing anything anywhere else. >>> >>> If there is software on macOS which consults /opt/local/*, then IMHO it >>> should be aware it might well find MacPorts-installed software there. If it >>> doesn't want to be contaminated by MacPorts, it should have a way to >>> refrain from consulting /opt/local/* . >>> >>> Of course, the difference of opinion between cmake and pkg-config might not >>> stem from consulting /opt/local/* . >> Sigh. Here's the problem: >> https://github.com/Kitware/CMake/blob/890d44792307134b41274b52cd972e4944af7d36/Modules/Platform/Darwin.cmake#L265 >> >> It might be possible to disable that with >> https://cmake.org/cmake/help/latest/variable/CMAKE_IGNORE_PREFIX_PATH.html#variable:CMAKE_IGNORE_PREFIX_PATH >> to '/opt/local' or >> https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_USE_CMAKE_SYSTEM_PATH.html#variable:CMAKE_FIND_USE_CMAKE_SYSTEM_PATH >> too 'NO'. E.g., add to jhbuildrc-custom >> cmakeargs = "-DCMAKE_IGNORE_PREFIX_PATH=/opt/local", but meson also uses >> cmake to find stuff and it's not clear from the meson docs whether one can >> add the same thing to its cmake_args; I guess that would look like >> mesonargs = "-Dcmake_args=-DCMAKE_IGNORE_PREFIX_PATH=/opt/local". >> >>> Yes, I have seen this report. It might be worse: I tried building gnucash >>> 4.11 via the MacPorts `gnucash` port, and a) there is an unexpected >>> interaction with gtkosxapplication.h, and b) after hiding >>> gtkosxapplication.h, the resulting GnuCash application crashes after >>> setting up a new book. I wasn't going to start the thread here about those >>> issues until I had got as far as I could with building GnuCash the GnuCash >>> way. But there is more on these MacPorts problems at >>> <https://trac.macports.org/ticket/66119>. >>> >> gtkosxapplication is what puts the menus on the menu
Re: [GNC-dev] Easy and Tax Invoice Reports
Dr. Micajkova, Ah, I see where you're going. You can file an enhancement request, see https://wiki.gnucash.org/wiki/Enhancement_Requests, to add those rows to the options of the Tax Invoice Report. You probably also want the Date and Description columns. Neither the Easy Invoice nor the Fancy Invoice has any headings modifications options, so you'd be asking for the Tax Invoice Reports options to be copied over and adjusted as necessary to match the fields displayed in those reports. Whether anyone will act on the request is another matter, so if you can program you might consider doing the work yourself. https://wiki.gnucash.org/wiki/Custom_Reports has a lot of information about the structure of reports, including how to copy one and make your own modifications to it. Regards, John Ralls > On Nov 8, 2022, at 11:24 PM, Vesna Micajkova > wrote: > > Hello John! > > Thank you for your reply. > I guess I haven’t explained well. Every word and string from the invoice can > be translated through the program to any language except the strings: Invoice > Date and Due Date. In the PrintScreen I have send, you can see that I have > translated Report Title and Units in Macedonian language. So, I can create > and print invoice in Macedonian language, only Invoice Date and Due Date will > stay on the language that I am using GnuCash on. I am very glad that Frank > has added Macedonian language so we can work on translating the whole > program, but my initial question was if Invoice Date and Due Date can be > added as additional strings so they can be translated the same way I am > translating the rest of the invoice content. > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
> On Nov 13, 2022, at 6:28 AM, Geert Janssens > wrote: > > How recent then can "more recent" be ? In my mind anything that's in the most > recent LTS, should be fine in all cases. For anything more recent than that, > we should consider how hard it would be to self-build the dependency. > For clarity, I think you mean Ubuntu's latest LTS, currently 22.04. > The other approach, where we freeze minimum dependencies on the stable > branch, sounds like a nice compromise, but has the drawback that it makes the > stable code more complicated in order to accommodate support for multiple > versions of a dependency. So we trade the stability of an older dependency > for complexity in our own code. I don't know if that's really a good > trade-off for a small development team. I think that means that we'd bump a dependency's minimum version only in the case where there's an API change that would otherwise require that we have to #ifdef on the dependency version--or rather that bumping the minimum version lets us remove ifdefs introduced to keep building on both the current Ubuntu LTS and bleeding-edge distros like Arch Linux and Debian Unstable. Then there's Gnome and macOS which have very nice versioning macros and deprecation policies that let you tune what the compiler will warn about. See e.g. https://docs.gtk.org/glib/const.VERSION_MIN_REQUIRED.html. There's a corresponding GLIB_VERSION_MAX_ALLOWED that somehow eluded gi-doc, see glib/versionmacros.h.in. There are corresponding macros for Gtk and Gdk. The idea is that MIN_REQUIRED will emit deprecation warnings for API deprecated in that version or earlier while MAX_ALLOWED will warn if you use API that was introduced after that version. Should we start using these to try to keep our code more current? (I think so.) If so how should we set them? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash and Github
My number one use of GitHub, and IIRC the reason we mirrored it there in the first place, is to refer to and reference code when communicating on these lists, bug reports, and IRC. That's replaceable too by serving the repo ourselves or moving the mirror back to Sourceforge. The fear is that Github's copilot will violate our author's copyrights by copying sufficiently substantial sections of code into a non-GPL project, stripping off the copyright and license in the process. I've seen claims that this has already happened. In my completely non-legal opinion that makes every project that uses CoPilot GPL and the FSF should be suing all of them to publish their source code. But I think that's also true of any project whose developers read Stack Overflow or search on the web for solutions to their coding problems. The world has changed since the GPL was conceived and sharing source code meant sending me a blank DECTape and a paid mailer or downloading a tarball by anonymous FTP and code on the web--regardless of where--is findable by web-searching for a function name, and even if we don't provide web access someone else will. The GPL encourages that. Plus the bird has flown. Sure, we could take down our Github repo. That won't affect the 673 forks, and some of those folks will get our code from somewhere and keep their repos up to date. In fact it seems to me that the Software Freedom Conservancy is missing the point: The problem with Copilot isn't that it's encouraging proprietary-software developers to use open-source code in their projects. Although the GPL requires that using GPL code turns the project into a GPL one, most other FLOSS licenses don't. They require only that copyright statements are preserved and Copilots failure to do so is the real problem. That's a matter for the courts; in order to get the matter before the courts somebody has to sue Github. Filing those suits on behalf of their client projects is the Software Freedom Conservancy's job, see https://sfconservancy.org/copyleft-compliance/. Since they have a history of suing over GPL compliance the boycott call suggests to me that they think they'd lose, either on merit or just because Microsoft has a bigger badder legal team. It's interesting that the FSF has nothing to say on their own, just a few links to articles: https://www.fsf.org/licensi ng/copilot. Regards, John Ralls > On Nov 13, 2022, at 6:59 AM, Derek Atkins wrote: > > Hi, > > What are the features of github that we use/depend on? > > - We don't use github's git repo except as a read-only version -- we COULD > open up code for RO access. > > - We don't use github issues; we have our own bugzilla. > > - We DO use github pull requests; we could theoretically migrate to gerrit > for review/management. > > - We DO use github actions; we could theoretically migrate to Jenkins > (with gerrit) for build/test/CI work. > > Am I missing anything? > > Having said that, and admitting I did not follow the link and read the > complaints, what is the fear with their "use" of GnuCash? > > -derek > > On Sun, November 13, 2022 9:48 am, Geert Janssens wrote: >> Some may have heard the rumblings around github semi-recently. The >> software >> conservancy is calling free software projects to seek alternatives. They >> motivate this in much >> more detail over here: >> https://sfconservancy.org/GiveUpGitHub/[1] >> >> In short, they claim github is a proprietary tool that's leveraging the >> hosted free software for >> their commercial purposes. In itself that would be acceptable as long as >> it's done according >> to the licenses of these free software projects. There have been several >> situations where >> that's not the case, "copilot" being the latest and most worry-some. >> >> Is this something we as a free software project should think about and >> possibly act on ? >> >> Personally I don't like it at all that I chose to write code under a free >> software license to >> ensure my effort helps and benefits the free software ecosystem. Yet that >> a commercial >> company then decides to use my code to train an AI that's meant to help >> build proprietary >> software. The legal status of that is still very unclear and certainly not >> what I intended my >> code to be used for. >> >> That is obviously only my personal opinion, but I wanted to express it as >> starting point for a >> wider discussion on this topic. >> >> Is the golden cage that is github to developers really becoming >> detrimental to real free >> software
[GNC-dev] Git branches
Since Geert brought up our relationship with Github I thought it timely to start a discussion about a related trend: The name of the git repository's primary branches. There's an ongoing effort in the software development community for the last 25-30 years or so to remove the terms master and slave; originally when used together (as in processes) but more recently when used alone. This recently includes the name of the primary branch in a git repository. The Gitlab folks have a nice summary at https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/. 'Master' was the standard when we started using git 10 years ago and so we adopted it and still use it. Aside from the cultural sensitivity issues (primarily in the United States because of our unfortunate history with forced importation and enslavement of Africans) it has proved to be a bit confusing to new contributors. The new standard default is 'main'. I think that would be fine for htdocs where we have master and beta: Main would better express that that's the branch that you see when you visit https://www.gnucash.org <https://www.gnucash.org/>. The gnucash-on-foo repositories for the build processes have only master branches so it doesn't really matter what the branch is called. I don't think 'main' is the right name for gnucash or gnucash-docs because it does nothing about the confusion factor. Note that the default branch on those two is maint but we still use master for the next major release's branch. The most expressive titles would be current-major-release and next-major-release but they're a bit wordy; OTOH just current (or curr) and next leave a new contributor to ask current and next what? maint is concise and not terrible for a branch that gets only bug fixes and small features. Lots of generic names for the next-major-release branch (future, devel or development, major-change) come to mind but I'm not sure that any of them clearly express the intent of the branch. Comments? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
David, Unfortunately that's ambiguous without explaining that in that particular context release means major release series. In ordinary usage the current release is 4.12; it can't get any more commits. The next release is 4.13 and will release off what we now call the maint branch. Regards, John Ralls > On Nov 14, 2022, at 10:05 AM, David T. via gnucash-devel > wrote: > > Not that my opinion carries much weight on this, but "current-release" and > "next-release" might be a reasonable set of options that are less wordy but > still clear? > > David T. > > On Nov 14, 2022, 19:17, at 19:17, Geert Janssens > wrote: >> This had been brewing in my mind as well, so thanks for bringing this >> up. >> >> When I considered alternative branch names I initially thought of >> "stable" vs "development" >> or "devel" with an optional "unstable" at times of pre-releases. >> >> However when thinking this through some more I started wondering >> whether we really >> should limit ourselves to just two (or three) branch names. >> >> We could also name our branches "4.x", "5.x" and so on to indicate the >> release series this >> branch is for. At some point we just stop using the older branches. We >> can choose to drop >> them or just leave them in the git history as it suits is best. >> >> Both naming schemes have advantages and drawbacks. I like the direct >> relationship >> between branch name and releases that will be on it for the latter >> scheme. Although I admit >> this relationship doesn't hold for the pre-releases, unless we make >> that a separate branch for >> those like eg "4.9xx". >> >> Regards, >> >> Geert >> >> Op zondag 13 november 2022 21:40:14 CET schreef john: >>> Since Geert brought up our relationship with Github I thought it >> timely to >>> start a discussion about a related trend: The name of the git >> repository's >>> primary branches. There's an ongoing effort in the software >> development >>> community for the last 25-30 years or so to remove the terms master >> and >>> slave; originally when used together (as in processes) but more >> recently >>> when used alone. This recently includes the name of the primary >> branch in a >>> git repository. The Gitlab folks have a nice summary at >>> >> https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/. >>> >>> 'Master' was the standard when we started using git 10 years ago and >> so we >>> adopted it and still use it. Aside from the cultural sensitivity >> issues >>> (primarily in the United States because of our unfortunate history >> with >>> forced importation and enslavement of Africans) it has proved to be a >> bit >>> confusing to new contributors. >>> >>> The new standard default is 'main'. I think that would be fine for >> htdocs >>> where we have master and beta: Main would better express that that's >> the >>> branch that you see when you visit https://www.gnucash.org >>> <https://www.gnucash.org/>. The gnucash-on-foo repositories for the >> build >>> processes have only master branches so it doesn't really matter what >> the >>> branch is called. >>> >>> I don't think 'main' is the right name for gnucash or gnucash-docs >> because >>> it does nothing about the confusion factor. Note that the default >> branch on >>> those two is maint but we still use master for the next major >> release's >>> branch. The most expressive titles would be current-major-release and >>> next-major-release but they're a bit wordy; OTOH just current (or >> curr) and >>> next leave a new contributor to ask current and next what? maint is >> concise >>> and not terrible for a branch that gets only bug fixes and small >> features. >>> Lots of generic names for the next-major-release branch (future, >> devel or >>> development, major-change) come to mind but I'm not sure that any of >> them >>> clearly express the intent of the branch. >>> >>> Comments? >>> >>> Regards, >>> John Ralls >>> >>> ___ >>> gnucash-devel mailing list >>> gnucash-devel@gnucash.org >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
Wow, I'm elevated to a whole department! ;-) I wish I had the clones to make it true! If the scripts are in git on code then Geert or I can update them as needed when we shift branches. Regards, John Ralls > On Nov 14, 2022, at 8:26 AM, Derek Atkins wrote: > > I have no objection to changing branch names. > > Just keep in mind that several build scripts depend on the branch names, > so if they change once, that's fine, but if they are constantly changing > (e.g. 4.x, 5.x, 4.99, 6.x, etc) then we may need to rework the scripts so > I don't have to coordinate with release-engineering when a new branch gets > created. (This dev-docs, etc). > > -derek > > On Mon, November 14, 2022 11:17 am, Geert Janssens wrote: >> This had been brewing in my mind as well, so thanks for bringing this up. >> >> When I considered alternative branch names I initially thought of "stable" >> vs "development" >> or "devel" with an optional "unstable" at times of pre-releases. >> >> However when thinking this through some more I started wondering whether >> we really >> should limit ourselves to just two (or three) branch names. >> >> We could also name our branches "4.x", "5.x" and so on to indicate the >> release series this >> branch is for. At some point we just stop using the older branches. We can >> choose to drop >> them or just leave them in the git history as it suits is best. >> >> Both naming schemes have advantages and drawbacks. I like the direct >> relationship >> between branch name and releases that will be on it for the latter scheme. >> Although I admit >> this relationship doesn't hold for the pre-releases, unless we make that a >> separate branch for >> those like eg "4.9xx". >> >> Regards, >> >> Geert >> >> Op zondag 13 november 2022 21:40:14 CET schreef john: >>> Since Geert brought up our relationship with Github I thought it timely >>> to >>> start a discussion about a related trend: The name of the git >>> repository's >>> primary branches. There's an ongoing effort in the software development >>> community for the last 25-30 years or so to remove the terms master and >>> slave; originally when used together (as in processes) but more recently >>> when used alone. This recently includes the name of the primary branch >>> in a >>> git repository. The Gitlab folks have a nice summary at >>> https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/. >>> >>> 'Master' was the standard when we started using git 10 years ago and so >>> we >>> adopted it and still use it. Aside from the cultural sensitivity issues >>> (primarily in the United States because of our unfortunate history with >>> forced importation and enslavement of Africans) it has proved to be a >>> bit >>> confusing to new contributors. >>> >>> The new standard default is 'main'. I think that would be fine for >>> htdocs >>> where we have master and beta: Main would better express that that's the >>> branch that you see when you visit https://www.gnucash.org >>> <https://www.gnucash.org/>. The gnucash-on-foo repositories for the >>> build >>> processes have only master branches so it doesn't really matter what the >>> branch is called. >>> >>> I don't think 'main' is the right name for gnucash or gnucash-docs >>> because >>> it does nothing about the confusion factor. Note that the default branch >>> on >>> those two is maint but we still use master for the next major release's >>> branch. The most expressive titles would be current-major-release and >>> next-major-release but they're a bit wordy; OTOH just current (or curr) >>> and >>> next leave a new contributor to ask current and next what? maint is >>> concise >>> and not terrible for a branch that gets only bug fixes and small >>> features. >>> Lots of generic names for the next-major-release branch (future, devel >>> or >>> development, major-change) come to mind but I'm not sure that any of >>> them >>> clearly express the intent of the branch. >>> >>> Comments? >>> >>> Regards, >>> John Ralls >>> >>> ___ >>> gnucash-devel mailing list >>> gnucash-devel@gnucash.org >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > > > -- > Derek Atkins 617-623-3745 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
I guess we could do that as long as we continue the no-backports policy, but it's something you argued against when we started using git-flow a few years ago. But what about the opposite approach, having only one permanent branch and no major releases? Instead of 5.0 next spring we'll release 2023.1 and the spring after that 2024.1, with .2 in June, .3 in September, and .4 in December every year? Major changes, like c++options, get merged when ready; we might do a beta release (e.g. 2023.2beta) a month before a release with a major change to get better user testing. We'd have to work out policies for API and schema changes because it would blow up the file upgrade path for users who've skipped some releases. There's a very dense exposition on this pattern at http://dymitruk.com/blog/2012/02/05/branch-per-feature/. Regards, John Ralls > On Nov 14, 2022, at 8:17 AM, Geert Janssens > wrote: > > This had been brewing in my mind as well, so thanks for bringing this up. > > When I considered alternative branch names I initially thought of "stable" vs > "development" or "devel" with an optional "unstable" at times of pre-releases. > > However when thinking this through some more I started wondering whether we > really should limit ourselves to just two (or three) branch names. > > We could also name our branches "4.x", "5.x" and so on to indicate the > release series this branch is for. At some point we just stop using the older > branches. We can choose to drop them or just leave them in the git history as > it suits is best. > > Both naming schemes have advantages and drawbacks. I like the direct > relationship between branch name and releases that will be on it for the > latter scheme. Although I admit this relationship doesn't hold for the > pre-releases, unless we make that a separate branch for those like eg "4.9xx". > > Regards, > > Geert > > Op zondag 13 november 2022 21:40:14 CET schreef john: > > Since Geert brought up our relationship with Github I thought it timely to > > start a discussion about a related trend: The name of the git repository's > > primary branches. There's an ongoing effort in the software development > > community for the last 25-30 years or so to remove the terms master and > > slave; originally when used together (as in processes) but more recently > > when used alone. This recently includes the name of the primary branch in a > > git repository. The Gitlab folks have a nice summary at > > https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/. > > > > 'Master' was the standard when we started using git 10 years ago and so we > > adopted it and still use it. Aside from the cultural sensitivity issues > > (primarily in the United States because of our unfortunate history with > > forced importation and enslavement of Africans) it has proved to be a bit > > confusing to new contributors. > > > > The new standard default is 'main'. I think that would be fine for htdocs > > where we have master and beta: Main would better express that that's the > > branch that you see when you visit https://www.gnucash.org > > <https://www.gnucash.org/>. The gnucash-on-foo repositories for the build > > processes have only master branches so it doesn't really matter what the > > branch is called. > > > > I don't think 'main' is the right name for gnucash or gnucash-docs because > > it does nothing about the confusion factor. Note that the default branch on > > those two is maint but we still use master for the next major release's > > branch. The most expressive titles would be current-major-release and > > next-major-release but they're a bit wordy; OTOH just current (or curr) and > > next leave a new contributor to ask current and next what? maint is concise > > and not terrible for a branch that gets only bug fixes and small features. > > Lots of generic names for the next-major-release branch (future, devel or > > development, major-change) come to mind but I'm not sure that any of them > > clearly express the intent of the branch. > > > > Comments? > > > > Regards, > > John Ralls > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
> On Nov 14, 2022, at 10:41 AM, Derek Atkins wrote: > > But no, the scripts are not in git. That's easily changed. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
> On Nov 14, 2022, at 11:11 AM, Alex Aycinena wrote: > > how about a simple change, like calling it 'main' rather than > 'master' and keeping the existing pattern for branches. That would be OK as long as long as the two names aren't similar. main and stable would be OK; with main and maint one is far too likely to do something to the wrong branch. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
I didn't follow completely all of dymitruk's essay either, but it seems clear to me that he's working in a much larger team than we are. His suggestion for handling merge conflicts was a shared git rerere cache; I understand the principle but I'm not completely clear about the implementation. I had the impression that release branches were like feature branches: Used once by the release team and discarded, and that his team uses Atlassian's Jira to keep track of what branches are merged into each release. He didn't go into a lot of detail about how to do it, and absent us adopting Jira I don't think that would matter much. Anyway I didn't mean to suggest that we should take up that whole rather complicated process; I just thought it a useful outline of the single-branch strategy. Not only do we not do semantic versioning, I don't think we even know how. https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning has a brief description that says that you bump the major number if you remove or change some existing API, the minor number if you add API, and the patch number (which we got rid of with 3.0) for all other changes. That doesn't make any sense at all for GnuCash the application, it's for libraries. For GnuCash right now it would really just for bindings and maybe only the Guile bindings. Glib has some nice macros, based somewhat on Apple's Availability Macros, in https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gversionmacros.h.in that can be used in functions declarations to emit or suppress deprecation warnings based on a target version of any Glib-based library. We *could* use those directly or we could pinch them and adapt them to however we want to manage deprecations. Glib and several other GNOME libraries also have deprecated directories, e.g. https://gitlab.gnome.org/GNOME/glib/-/tree/main/glib/deprecated that they use when they deprecate whole classes. The SQL backend has that per-table version check and built in update queries to update a database when the version changes, but since it doesn't write out a new DB on every save it has a much greater need for that feature than does the XML backend. There's also GNUCASH_RESAVE_VERSION that's available to indicate that the database needs to be purged and rewritten from memory. Fortunately we haven't needed to change it. The XML backend does have versions on each top-level element. They're all 2.0.0 suggesting that either we haven't been very good about updating them when we change something or that the schema is a lot more stable than we think it is. From a design standpoint I'm not sure that versioning every entry is all that useful considering that everything is written out fresh with every save. Regards, John Ralls > On Nov 15, 2022, at 9:25 AM, Geert Janssens > wrote: > > Op maandag 14 november 2022 19:59:24 CET schreef john: > > I guess we could do that as long as we continue the no-backports policy, but > > it's something you argued against when we started using git-flow a few > > years ago. > > > > I don't have a clear memory of what I argued against way back then. It > doesn't matter much. In reality we have continued to avoid backporting > anyway, which is just fine for the small team that we are. > > > But what about the opposite approach, having only one permanent branch and > > no major releases? Instead of 5.0 next spring we'll release 2023.1 and the > > spring after that 2024.1, with .2 in June, .3 in September, and .4 in > > December every year? Major changes, like c++options, get merged when ready; > > we might do a beta release (e.g. 2023.2beta) a month before a release with > > a major change to get better user testing. We'd have to work out policies > > for API and schema changes because it would blow up the file upgrade path > > for users who've skipped some releases. There's a very dense exposition on > > this pattern at http://dymitruk.com/blog/2012/02/05/branch-per-feature/. > > It's actually a branch and release pattern I had been considering but was > hesitant to bring up as perhaps to radical. Since you now bring it up for > consideration, let's evaluate it after all. > > 1. I like the idea of only a single release branch and all development > happening on feature or bugfix branches that get merged into this release > branch when ready. > > 2. I also like the idea of dropping distinction between a stable and > development series. It would bring improvements to users much faster in > general - it will be released when ready, not queued for the next major > release (which could be only in 2 years worst case). > It's a bit what fast moving projects such as webbro
Re: [GNC-dev] Git branches
We could pinch from Debian and use stable, testing, and unstable, where testing
is the alpha/beta pre-major-release weeklies.
Regards,
John Ralls
> On Nov 18, 2022, at 7:55 AM, Geert Janssens
> wrote:
>
> I'm fine with just doing the simple name change for our two primary branches
> as it's the option of least effort.
>
> I'd rather have a different name than "main" though. It's a bit ambiguous and
> like "master" suggesting this branch is somehow more important than the other
> long-term branch "maint". I'd rather have names that help guide contributors
> to the right branch to work from. I don't think there's a silver bullet here
> though, but some names may give more of a hint than others. Some suggestions:
>
> * "current" vs "future" as shorthands for "current-release-series" or
> "future-release-series"
> * "maintenance" ("maint") vs "development" ("devel")
> * "stable" vs "development"
>
> That said, I'm also very interested in the single branch model as
> alternative. Discussion on that is for another message.
>
> Regards,
>
> Geert
>
> Op maandag 14 november 2022 20:59:26 CET schreef john:
> > > On Nov 14, 2022, at 11:11 AM, Alex Aycinena
> > > wrote:
> > >
> > > how about a simple change, like calling it 'main' rather than
> > > 'master' and keeping the existing pattern for branches.
> >
> > That would be OK as long as long as the two names aren't similar. main and
> > stable would be OK; with main and maint one is far too likely to do
> > something to the wrong branch.
> >
> > Regards,
> > John Ralls
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] GnuCash and Github
I don't think the silo effect is a big deal. The main impact is on transferring bugs and we gave that up when Gnome shut down its Bugzilla instance. Cross-project pull/merge requests make no sense, so I guess your complaint is that you can't use your Github account to submit a PR to e.g. Gtk because while there's a Gtk mirror on Github it doesn't take PRs, you have to get a Gnome LDAP account and make your MR (merge request, gitlab's name for pull request). Based on what I see over at Gnome running a gitlab instance is a lot of work. Plus even with the Gnome Foundation's compute resources it frequently bogs down. I don't think we'd want to do that. I'd never even heard of gitea or codeberg and I've encountered only one project on sourcehut. I wasn't terribly impressed. We could switch the git mirror to Sourceforge, which would get us the code-browsing, though not as nice as GitHub's, and the merge requests. I don't know how the edit/discussion flow works there, but I bet it's not as nice as Github's either. That leaves CI. Sourceforge doesn't provide it, so we'd have to set up our own instance of something; Jenkins used to be popular but I don't know if it's still considered the best. Regardless that's more time spent setting it up, securing, and maintaining it. Regards, John Ralls > On Nov 18, 2022, at 9:15 AM, Geert Janssens > wrote: > > That's a good analysis of the situation. > > I agree this is largely a legal issue to be solved by organisations like the > SFC. > > At a deeper level though I agree this could only have happened because OSS > has allowed github to become such a golden cage for our projects in the first > place. And this seems to happen over and over again. > > It has become very hard to leave github because of the network effect. And I > agree we can't make others not have a clone of the gnucash repo on github. > That doesn't mean we can't make a statement by not hosting our own > forks/clones there ourselves if we care enough. > > I don't know if *I* care enough. I am concerned about these developments, > but at the same time I wouldn't want to add more infrastructure maintenance > to our already limited time. > > SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or > self-hosted (gitea, gitlab CE, sourcehut). > > Codeberg is very similar to github, except for CI (which is currently in > closed beta). So it offers much of what our users/contributors are already > used to. > I don't know about the others. > > As a last semi-OT remark/rant, I think all the alternatives are missing a key > piece - federation. > > You either have a centrally hosted platform(codeberg.org,...), or you have > completely isolated islands that happen to use the same software (think > gitlab.gnome.org, gitlab.kitware.com,...) > > The centrally hosted platforms will invariably lead to similar silo effects > as github.com or gitlab.com if they become more successful. The islands on > the other hand currently have no means of interaction or integration (like > tracking an issue issue on another 'island's' tracker, forking to another > 'island', creating pull requests across 'islands',...). So in both cases the > very distributed nature of git is not brought up to the level of the web > interfaces. > > The social media landscape is in the same boat in fact, though federation may > very slowly be getting a foot in the door with the recent twitter debacle and > a fair number of users now start to experiment with Mastodon. > > Regards, > > Geert > > Op zondag 13 november 2022 20:50:53 CET schreef john: > > My number one use of GitHub, and IIRC the reason we mirrored it there in the > > first place, is to refer to and reference code when communicating on these > > lists, bug reports, and IRC. That's replaceable too by serving the repo > > ourselves or moving the mirror back to Sourceforge. > > > > The fear is that Github's copilot will violate our author's copyrights by > > copying sufficiently substantial sections of code into a non-GPL project, > > stripping off the copyright and license in the process. I've seen claims > > that this has already happened. > > > > In my completely non-legal opinion that makes every project that uses > > CoPilot GPL and the FSF should be suing all of them to publish their source > > code. But I think that's also true of any project whose developers read > > Stack Overflow or search on the web for solutions to their coding problems. > > The world has changed since the GPL
[GNC-dev] String Freeze
Devs, the 4.13 release is in two weeks so that means that there's a string freeze on maint until then. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Missing column header labels after resizing columns (Windows 10, GC version 4.12)
Dear Mr. Taurig,
No, it's a user list item because you are asking about how to use GnuCash, not
how to write GnuCash code.
Regards,
John Ralls
> On Dec 4, 2022, at 4:10 PM, Scott Traurig wrote:
>
> Hi John,
>
> Respectfully, this is beyond the user-list. That list has come up dry, and
> the conventional FAQ answer is not working.
>
> The relevant FAQ entry:
>
> <https://wiki.gnucash.org/wiki/FAQ#Q:_How_do_I_resize_my_register_columns.3F_Why_can_I_not_shrink_the_description_column.3F>
>
> That FAQ entry looked promising, but it did not solve the problem. There are
> no entries in the .gcm file showing zero width to edit.
>
> Worse, uninstalling GnuCash and deleting the entire C:\Users\my user
> name\AppData\Roaming\GnuCash directory, including all .gcm files such that
> they would be reconstituted from scratch, does not work either.
>
> Interestingly, somewhere in the system it remembers what book I had open even
> through an uninstall/reinstall cycle. I suspect it has something to do with
> that.
>
> And whatever/wherever that data is, it also transcends books. If I create an
> entirely new book, it also immediately has the exact same missing column
> label problem
>
> It's also worth noting that the columns themselves are visible with normal
> appearing widths. Only the labels are missing. I've attached a screen shot.
>
> Is there another directory somewhere, or a set of registry entries, that also
> need to be deleted?
>
> Thank you,
>
> Scott
>
>
> On Sun, Dec 4, 2022 at 6:11 PM john <mailto:jra...@ceridwen.us>> wrote:
>> That's a user-list question. I've changed the CC for your convenience.
>>
>> The file you're looking for is the book's metadata file, see
>> https://wiki.gnucash.org/wiki/Metadata_File. It stores among other things
>> window sizes and column widths for registers.
>>
>> Regards,
>> John Ralls
>>
>>
>>> On Dec 4, 2022, at 1:56 PM, Scott Traurig >> <mailto:scott.trau...@gmail.com>> wrote:
>>>
>>> Dev's,
>>>
>>> After resizing some column headers in an account, the labels for the
>>> Transfer and Reconciled ("R") columns have disappeared. The header blocks
>>> for both are now combined into a single blank field.
>>>
>>> I tried un-installing, including manually removing the folders in %appdata%
>>> and Program Files (x86), but the problem persists after re-installing
>>> GnuCash.
>>>
>>> I grabbed another Windows 10 machine, installed on it, and opened the
>>> .gnucash file that I normally use from it's normal directory on my NAS
>>> without the same problem appearing--all column headers are fine. So the
>>> .gnucash file is OK.
>>>
>>> Thus it would appear that there is a file that is not removed during a
>>> Windows uninstall (or the manual files I deleted), or a registry setting
>>> that persists and continues to cause this behavior on my main PC.
>>>
>>> If someone could identify the offending file or registry setting for me so
>>> that I can kill it it would be most appreciated.
>>>
>>> Thanks,
>>>
>>> Scott
>>> ___
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] GnuCash 4.900 Released
> On Jan 10, 2023, at 12:28 AM, Jeff wrote: > > And how do I find it under Ubuntu 22.04.1 LTS? Flathub is your best option, see the beta instructions at https://wiki.gnucash.org/wiki/Flatpak#Regular_releases_at_flathub.org. ***But note that this is an unstable release! Don't use it on your production book, make a copy for testing.*** Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] GnuCash 4.900 Released
In the case of the Fedora 26 system it won't even let him connect, probably because it doesn't have TLS 1.3 and Flathub (rightly) refuses to connect. Fred, there's not enough info on the other failure. AFAIK Flatpak does indeed work only on Linux, but doesn't care about the desktop environment. It installs its own Gnome runtime and all the other needed dependencies. Regards, John Ralls > On Jan 10, 2023, at 6:40 PM, Adrien Monteleone > wrote: > > I thought one of the points of Flatpaks were that they didn't require the > base system to match the software being installed. If the software needs it, > Flatpak will bring it in just for that app. (it won't change the base system > to a different DE or WM) > > I could be mistaken of course. > > Regards, > Adrien > > On 1/10/23 7:28 PM, Fred Tydeman wrote: >> On Mon, Jan 9, 2023 at 9:02 PM John Ralls wrote: >>> The GnuCash development team announces GnuCash 4.900, the first unstable >>> release leading to GnuCash 5.0. >>> >>> This is an unstable release for testing purposes. Do not use it with >>> production data! Make a copy of your book to test this release. >>> ... >>> GnuCash is also available as a flatpak from Flathub.org. Instructions for >>> installing and running may be found at >>> https://wiki.gnucash.org/wiki/Flatpak. >>> >> I followed those instructions. It failed because it appears to require >> Gnome on Linux. Correct? >> I am running a different window manager. >> On another computer, running Fedora 26 (very old) Linux, I get: >> Unacceptable TLS certificate. >> Reinstalling ca-certificates did not help. I assume it is just too old. >> Correct? > > ___ > gnucash-user mailing list > gnucash-u...@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Sample Report with Examples
You can't possibly be serious. Regards, John Ralls > On Jan 13, 2023, at 12:11 AM, flywire wrote: > > https://lists.gnucash.org/pipermail/gnucash-devel/2021-September/045939.html >> The code would be easier to follow if different strings other than Hello, > World! were used, making it clearer what they relate to. While this report > might have developed from a Hello World example, a minimal program to > generate output, it's much more than that now. Can it be renamed? Maybe > just hello.scm or move it to welcome-to-gnucash.scm with a related document > title. >> >> If there are no concerns I'll put up a PR. > > I made minimal changes for the strings and pushed > https://github.com/Gnucash/gnucash/pull/1501 > > Other changes would need a bit of discussion as would affect the docs. > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Sample Report with Examples
> On Jan 13, 2023, at 6:46 PM, flywire wrote: > > The point is not about the changes options make to reports, it's about how > the report source code changes the report and report options. Why wouldn't > unique string values help people unfamiliar with reports see the relationship > more clearly? While it's possible in Scheme to take that quoted option value and convert it to code I don't know of any report code in GnuCash that does so. That's a very good thing, we have enough Scheme-induced vulnerabilities without that. With that in mind, no, the quoted-string default values do not in any way have anything to do with illustrating how the report source code changes the report and report options. Nor, for that matter, does hello-world.scm illustrate anything of the sort. hello-world.scm simply provides examples of the different types of options and very simply displays the values in the report. There's not a single line of code that changes the behavior of the report based on an option value--unlike many of the real options in most of the real reports. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Sample Report with Examples
Geert, Roger. The problem with that argument is that someone with that little programming experience isn't going to be able to write a custom report anyway. Even someone with enough programming experience to agree that default option values aren't significant to the structure of the code isn't going to be able to write a custom report unless at least some of that experience is in one of the Lispish languages. The Lispish paradigms of car, cdr, lambda, map, and so on are utterly foreign to most procedural language programmers, but required for writing GnuCash reports. Yes, the use of Hello, World is a bit flippant, and yes, hello-world.scm isn't a minimal Scheme program. It's also not a sample report because it doesn't demonstrate querying the GnuCash data performing analysis, or presenting results. So if someone feels motivated to make it less flippant and better described then I suggest: * Change the filename to options-example.scm, and the menu-name to "Options Example". * Add a report title option. Most of the real reports have one. Set its default to "Example Title". * Fix the comment describing the value of `name from "This will be used, among other things for making its menu item in the main menu.". It doesn't do that, it sets the name on the options dialog's title bar and the default value for the General section's Report Name option. "menu-name", which is part of the report-registration block at the bottom, sets the menu name. The comment should also explain that changing the report name option will change the value of the report's window or tab title but not its options dialog title. * Change the name value to "Options Example Report". * Change the two Hello… section names to something like Tab A and Tab B to make clear that "Sections" in the option block map to tabs on the dialog box. * Change the string option default to "String Option Default". * Speaking of the General section, there should be a comment explaining that a skeleton General section gets added by gnc:report-template-new-options that provides the name (but not the title, reports must add that themselves) and stylesheet options. Regards, John Ralls > On Jan 14, 2023, at 2:02 AM, Geert Janssens > wrote: > > Ok, I tend to agree partially with flywire on this one. > > John, you and I have years of programming experience and to us the default > value of an option is a minor detail. > > However I can imagine someone with hardly any development experience at all > will have a much harder time to map the same string used multiple times in > the report code to the output visible on screen. And I sympathize with those > that try to create their own custom reports. So yes, using different sample > strings in code (even for default values) makes it easier to relate output on > the report with what's written in the code - before - any option is changed. > > To us this may look like bikeshedding, I think for someone trying to wrap > their head around the gnucash code this may actually help. > > And while bikeshedding was mentioned, I'd rather use values like > "Sample string", "Sample Document Title" and "Sample Report" than the > half-baked "Hello String" and "Hello Example". > > As with these changes "Hello, World" is never used, the file name is probably > better changed as well. > > Regards, > > Geert > > Op zaterdag 14 januari 2023 05:47:29 CET schreef john: > > > On Jan 13, 2023, at 6:46 PM, flywire wrote: > > > > > > The point is not about the changes options make to reports, it's about how > > > the report source code changes the report and report options. Why > > > wouldn't unique string values help people unfamiliar with reports see the > > > relationship more clearly? > > While it's possible in Scheme to take that quoted option value and convert > > it to code I don't know of any report code in GnuCash that does so. That's > > a very good thing, we have enough Scheme-induced vulnerabilities without > > that. > > > > With that in mind, no, the quoted-string default values do not in any way > > have anything to do with illustrating how the report source code changes > > the report and report options. Nor, for that matter, does hello-world.scm > > illustrate anything of the sort. hello-world.scm simply provides examples > > of the different types of options and very simply displays the values in > > the report. There's not a single line of code that changes the behavior of > > the report based on an option value--unlike many of the real options in > > most of the real reports. > > > > Regards, > > John Ralls > > > > ___ > > gnucash-devel mailing list > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Missing FreeType2 for Mac OS Development
While you're getting familiar enough with GnuCash ask questions here. Once you've got a PR written we can move the discussion to that PR. Regards, John Ralls > On Jan 14, 2023, at 4:21 PM, Vincent Lucarelli > wrote: > > It looks like freetype2 picked up a dependency on > /opt/homebrew/lib/libbrotlidec.dylib even though I started with a new user > account and insulated the build with >> >> cmakeargs = >> '-DCMAKE_SYSTEM_IGNORE_PATH="/opt/homebrew:/opt/macports:/sw:/usr/local"' > as suggested at > https://wiki.gnome.org/action/show/Projects/GTK/OSX/Building#Prerequisites > > > So when harfbuzz-no-cairo tried to configure against freetype2, it was > looking for libbrotlidec.pc, but that wasn’t built by jhbuild. > > I’ll try again tomorrow to see if I can track down exactly how homebrew is > poisoning the build environment. > > Provided I can actual build gnucash, should development questions about > integrating FQ get_features() take place on this mailing list in a new thread > or on GitHub under and issue? > > Best, > > Vince > > >> On Jan 14, 2023, at 4:44 PM, John Ralls wrote: >> >> >> >>> On Jan 14, 2023, at 10:22 AM, Vincent Lucarelli >>> wrote: >>> >>> Hi, >>> >>> I am attempting to setup a new Mac OS X user account on Ventura 13.0.1 to >>> build gnucash so I can attempt to help integrate a new Finance::Quote >>> feature into GnuCash. Ran into 2 problems following the instructions at >>> https://wiki.gnucash.org/wiki/MacOS/Quartz >>> >>> First issue - was able to solve - copying /bin/bash to $HOME/.new_local/bin >>> doesn’t seem to work on Ventura. The process is immediately killed when >>> the alternate copy of bash is run. Some googling suggests it might have >>> something to do with quarantine or code signing, but a few of the suggested >>> solutions didn’t work. I have homebrew installed (but not in the path for >>> the account I’m using to try and build gnucash), so I just installed bash >>> with brew and then copied that executable into .new_local/bin. >>> >>> Second issue - not sure how to proceed. The bootstrap run successfully, >>> but the jhbuild step failed to find freetype2 >>> >>>> PREFIX=$HOME/opt/gnucash jhbuild build >>> >>>> ../../src/harfbuzz-4.1.0/meson.build:87:0: ERROR: Dependency 'freetype2' >>>> is required but not found. >>>> >>>> A full log can be found at >>>> /Users/gnucash/opt/gnucash/build/harfbuzz-4.1.0/meson-logs/meson-log.txt >>>> WARNING: Running the setup command as `meson [options]` instead of `meson >>>> setup [options]` is ambiguous and deprecated. >>>> *** Error during phase configure of harfbuzz-no-cairo: ## Error >>>> running meson --prefix /Users/gnucash/opt/gnucash/inst --libdir lib >>>> -Dcoretext=enabled -Dfreetype=enabled -Ddocs=disabled -Dbenchmark=disabled >>>> -Dintrospection=disabled --wrap-mode=nofallback >>>> /Users/gnucash/opt/gnucash/src/harfbuzz-4.1.0 *** [20/76] >>>> >>>> [1] Rerun phase configure >>>> [2] Ignore error and continue to build >>>> [3] Give up on module >>>> [4] Start shell >>>> [5] Reload configuration >>>> [6] Go to phase "wipe directory and start over" >>>> choice: >>> >>> Any advice how how to proceed is appreciated. >> >> harfbuzz-no-cairo depends on freetype-no-harfbuzz. If >> $PREFIX/lib/pkgconfig/freetype2.pc isn't installed then something went wrong >> with the latter. Scroll back in your terminal session to see what. >> >> Regards, >> John Ralls > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Finance::Quote get_features() and GnuCash
Vincent, You're looking in the wrong places. The list of F::Q sources displayed in the Security Editor dialog is partially hard-coded in libgnucash/engine/gnc-commodity.c beginning at line 171. Every entry in those two lists represents an F::Q method. At startup GC calls F::Q's `$quoter->sources()` and compares the returned list against the hard-coded lists, enabling the matching entries. Any F::Q methods not in either hard-coded list is added to a new dynamic list that's displayed as the "unknown" list--unknown because at present GnuCash has no way of knowing whether it's a single or a multi-source method--in F::Q terminology whether it has fallbacks. Maintaining that list is a pain in the rear and its existence creates a coupling between GC and F::Q versions. The same applies to modules and API keys and to which module provides which methods. The perl interface is in libgnucash/quotes/finance-quotes-wrapper.in that's turned into bin/finance-quotes-wrapper.pl at configuration. Any additions or changes there should be limited to converting a JSON stream on stdin to function arguments, calling the F::Q function, and converting the return data into a JSON stream on stdout and errors on stderr. The wrapper is driven by gnucash/price-quotes.cpp that's responsible for presenting an API to the rest of the program. API callsl set arguments and marshal them into the JSON stream sent to finance-quoter-wapper's stdin, invoking the appropriate finance-quote-wrapper function, parsing the returned JSON string into whatever C++ struct the API promises to the rest of GnuCash, and parsing and interpreting the stderr JSON. finance-quote-wrapper functions should be kept as thin as possible because it's perl running in a separate process and must interact purely through the JSON streams. The pair of finance-quote-wrapper and price-quotes.cpp should abstract away as much implementation detail as possible so that coupling between F::Q and the rest of GnuCash is minimal. I think that the user interface, both for the source selection in the GUI and for retrieving specified quotes from the command line, should continue to focus on methods and treat the methods behind them as much as an implementation detail as possible. To accomplish that GnuCash needs to know when a method is implemented by a module that needs an API key and which key that is. If GC doesn't already have that key stored it needs to prompt for it using a dialog box with a "remember" checkbox in the GUI; there are several ways one could go with a terminal command of which erroring out (`method foo requires a bar API key and you haven't provided one`). I'd also like to get rid of the hard-coded method lists. That requires being able to query which methods are single-source and which have fallbacks. For the latter it would be nice to have a tooltip listing what single-source methods in what order will be tried to obtain the quote. It would also be nice to flag on the list which sources need which API keys. GC also needs to scan the configured securities for sources to identify any sources that aren't provided by the installed F::Q and present that as an error to the user. Currency sources are interesting in a different way. Last I looked F::Q had four available sources for looking up currencies defaulting on alphavantage. Using anything other than the F::Q default will require substantially changing the way GC requests currency rates. There are probably users who would like to configure sources per pair of currencies, e.g ECB for EUR<->USD and Alphavantage for USD<->INR. Others might be content with a preference setting for the currency method. Most may not care at all as long as they can get the rates that they want without much fiddling. That's a mid-size project. I don't think it will be possible to have it ready for GnuCash 5.0, whose release is only 10 weeks from now with feature freeze in only two weeks. It might be possible to get it into 5.1 at the end of June but I think 5.2 at the end of September is a more realistic goal. See https://wiki.gnucash.org/wiki/CodingStandard and https://wiki.gnucash.org/wiki/C++ for style guidance. Regards, John Ralls > On Jan 21, 2023, at 8:43 AM, Vincent Lucarelli > wrote: > > Hi, > > We have an experimental function in Finance::Quote called get_features() that > returns a perl hash that provides information on > quote_modules - list of sources for stock quotes + a list of any required > parameters (such as an API key) the module requires > quote_methods - a single module or list of modules to try in a specific order > currency_modules - list of sources for currency information if FQ is required > to convert quotes from one currency to another > > The current version of FQ just uses AlphaVantage for curr
Re: [GNC-dev] gnucash-devel Digest, Vol 238, Issue 15
> On Jan 22, 2023, at 9:21 AM, Bruce Schuck wrote: > > On Sat, 21 Jan 2023 11:09:02 -0800 Joh Ralls wrote: > >> Vincent, > >> The list of F::Q sources displayed in the Security Editor dialog is >> partially hard-coded in libgnucash/engine/gnc-commodity.c beginning >> at line 171. Every entry in those two lists represents an F::Q >> method. At startup GC calls F::Q's `$quoter->sources()` and compares >> the returned list against the hard-coded lists, enabling the matching >> entries. Any F::Q methods not in either hard-coded list is added to a >> new dynamic list that's displayed as the "unknown" list--unknown >> because at present GnuCash has no way of knowing whether it's a >> single or a multi-source method--in F::Q terminology whether it has >> fallbacks. Maintaining that list is a pain in the rear and its >> existence creates a coupling between GC and F::Q versions. The same >> applies to modules and API keys and to which module provides which >> methods. > > . > . > . > >> That's a mid-size project. I don't think it will be possible to have >> it ready for GnuCash 5.0, whose release is only 10 weeks from now >> with feature freeze in only two weeks. It might be possible to get it >> into 5.1 at the end of June but I think 5.2 at the end of September >> is a more realistic goal. > >> See https://wiki.gnucash.org/wiki/CodingStandard and >> https://wiki.gnucash.org/wiki/C++ for style guidance. > > Gentlemen, > > May I suggest this discussion get moved or copied to the discussion list on > https://github.com/finance-quote/finance-quote, possibly > https://github.com/finance-quote/finance-quote/discussions/255 or perhaps a > new one (In addition I think adding > reply+achs6j2atlmjqpwojzhnsvwbydzitevbmxhaar2...@reply.github.com to the Cc > list may copy that discussion). In my opinion the GitHub discussion feature > is maybe a better fit for discussing what possible changes may be made to > F::Q and underlying modules than the Gnucash-devel mailing list. I think > following a discussion may be easier than email list thread/subject archives. > > Thank you John for giving a more detailed description of the GnuCash to > Finance::Quote interface and explaining how more thought and planning would > benefit both GnuCash and F::Q. Bruce, This thread is about GnuCash code and belongs here, at least until Vincent is ready to open a GnuCash PR, at which point the discussion will move to the PR. I fully expect that as Vincent works on developing the GnuCash side of the code he'll realize that he needs to change the Finance::Quote PR, and those changes will properly be discussed on the Finance::Quote PR. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python bindings: How to expose additional engine functions
You might need to precede your gncOwnerGetOwnerFromTxn declaration with
%ignore gncOwnerGetOwnerFromTxn
outside of any %{…%} block. If you don't SWIG will create a default decl from
the #include and ignore yours.
If gnc_get_current_session is returning nullptr in what you think is a running
instance of GnuCash I'd guess that it has to do with connecting the python
interpreter. You might try it in the python console; that did work the last time
I tried it.
Regards,
John Ralls
> On Jan 25, 2023, at 12:13 PM, Steve Brown wrote:
>
> Hi John,
>
> Thanks for the swig link. That's exactly what I need.
>
> I added the typemaps.i include and the following to gnucash_core.i
>
> gboolean gncOwnerGetOwnerFromTxn(Transaction *INPUT, GncOwner *OUTPUT);
>
> The *OUTPUT was ignored and arg2 is processed according the
> GncOwner(in) typemap.
>
> OTOH:
>
> gboolean gncOwnerGetOwnerFromTxn(Transaction *INPUT, int *OUTPUT);
>
> The value of arg2 after the call is appended to the return as a tuple.
> That seems correct.
>
> Any idea?
>
> ===
>
> The issue with gnc_get_current_session() is very minor.
>
> I do use a context manager like the example. However, if I call
> gnc_get_current_session(), it doesn't know that a session already
> exists and creates a new one. That wasn't the behavior I expected.
>
> On the surface, it seems unnecessary to call that function at all.
> However, my environment is a plugin with an embedded Python
> interpreter. Calls to gnc_get_current_session() are useful and work
> just fine. The Python scripts are easier to debug standalone. As this
> is unlikely to be an issue for anybody, but me, I can work around it.
>
> Thanks,
> Steve
>
> On Tue, 2023-01-24 at 14:37 -0800, John Ralls wrote:
>>
>>
>>> On Jan 24, 2023, at 2:03 PM, Steve Brown
>>> wrote:
>>>
>>> My use case is accessing owner name and address from a transaction.
>>> The transaction is found by guid.
>>>
>>> Exposing guid_from_string() was pretty straightforward as was
>>> GetLot()
>>> and GetFirstAPARAcctSplit().
>>>
>>> I also need GetOwnerFromTxn or GetOwnerFromLot. However, this and
>>> many
>>> similar functions return the result through an argument and
>>> indicate
>>> success or failure by returning a boolean. It's not clear whether
>>> there
>>> is an general way with swig to deal with this other than adding a
>>> wrapper to return the result and indicate failure by returning
>>> NULL.
>>
>> Yes, but SWIG makes it pretty simple, see
>> https://www.swig.org/Doc3.0/Python.html#Python_nn46.
>> Note that you can still have the bool rv to test success.
>>
>>> I also noticed that there is a problem with gnc-
>>> session.c:gnc_get_current_session() using the bindings. In the
>>> executable, gnc_set_current_session() is called in gnc_file.c after
>>> each qof_session_new(). But with the Python bindings, the swig-
>>> generated code calls qof_session_new(). So, current_session isn't
>>> initialized and the first call subtly creates a new session. I
>>> added a
>>> gnc_set_current_session() call to qof_session_new() and that fixed
>>> things for me . I don't think that's the best solution.
>>
>> Neither set_ nor get_current_session are wrapped. You should be
>> creating a Python Session object,
>> bindings/python/examples/simple_book.py.
>>
>> Regards,
>> John Ralls
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Python bindings: How to expose additional engine functions
You forgot to copy the list.
If you can't get the direct type maps to work then writing a wrapper seems a
reasonable thing to do.
Regards,
John Ralls
> On Jan 27, 2023, at 2:46 AM, Steve Brown wrote:
>
> Hi John,
>
> On Wed, 2023-01-25 at 20:58 -0800, john wrote:
>> You might need to precede your gncOwnerGetOwnerFromTxn declaration
>> with
>> %ignore gncOwnerGetOwnerFromTxn
>> outside of any %{…%} block. If you don't SWIG will create a default
>> decl from
>> the #include and ignore yours.
>
> That's what I thought too. So, I commented out the declaration in
> gncOwner.h. Didn't make any difference. I tested with this.
>
> swig -python -I.. -I../../libgnucash/engine -I../../common
> -I/usr/include/glib-2.0 -v gnucash_core.i
>
> 1. After reading chapter 10.3, only one typemap gets chosen for an
> argument or return. I don't totally understand the precedence rules,
> but you only get one and *OUTPUT has a typemap. So, does GncOwner.
>
> 2. It also appears you have to write their own OUTPUT typemap for any
> user-defined type, even a type with no conflicting typemap. The
> INOUT/OUTPUT/INOUT typemaps are in inoutlist.swg. I don't see where
> that restriction is implemented, but empirically, it's there.
>
> I'm inclined o just write some swig-friendly C functions that call the
> current ones that return results through an argument.
>
>> If qofsession.cp is returning nullptr in what you think is a running
>> instance of GnuCash I'd guess that it has to do with connecting the
>> python
>> interpreter. You might try it in the python console; that did work
>> the last time
>> I tried it.
>
> I think my explanation was lacking. The get_current_session works as
> expected in the embedded Python. I need it to get the current session.
> It's in my standalone test environment where I'm testing a script that
> will ultimately run under the embedded interpreter that the problem
> appeared. It's unlikely to trouble anybody but me.
>
> In case anybody else runs into this, attached is a patch to simple_book
> that illustrates the problem. Also, attached is the patch to
> qofsession.cpp that fixed it for me.
>
> Thanks again for your help,
>
> Steve
>
>>
>> Regards,
>> John Ralls
>>
>>> On Jan 25, 2023, at 12:13 PM, Steve Brown
>>> wrote:
>>>
>>> Hi John,
>>>
>>> Thanks for the swig link. That's exactly what I need.
>>>
>>> I added the typemaps.i include and the following to gnucash_core.i
>>>
>>> gboolean gncOwnerGetOwnerFromTxn(Transaction *INPUT, GncOwner
>>> *OUTPUT);
>>>
>>> The *OUTPUT was ignored and arg2 is processed according the
>>> GncOwner(in) typemap.
>>>
>>> OTOH:
>>>
>>> gboolean gncOwnerGetOwnerFromTxn(Transaction *INPUT, int *OUTPUT);
>>>
>>> The value of arg2 after the call is appended to the return as a
>>> tuple.
>>> That seems correct.
>>>
>>> Any idea?
>>>
>>> ===
>>>
>>> The issue with gnc_get_current_session() is very minor.
>>>
>>> I do use a context manager like the example. However, if I call
>>> gnc_get_current_session(), it doesn't know that a session already
>>> exists and creates a new one. That wasn't the behavior I expected.
>>>
>>> On the surface, it seems unnecessary to call that function at all.
>>> However, my environment is a plugin with an embedded Python
>>> interpreter. Calls to gnc_get_current_session() are useful and work
>>> just fine. The Python scripts are easier to debug standalone. As
>>> this
>>> is unlikely to be an issue for anybody, but me, I can work around
>>> it.
>>>
>>> Thanks,
>>> Steve
>>>
>>> On Tue, 2023-01-24 at 14:37 -0800, John Ralls wrote:
>>>>
>>>>
>>>>> On Jan 24, 2023, at 2:03 PM, Steve Brown
>>>>> wrote:
>>>>>
>>>>> My use case is accessing owner name and address from a
>>>>> transaction.
>>>>> The transaction is found by guid.
>>>>>
>>>>> Exposing guid_from_string() was pretty straightforward as was
>>>>> GetLot()
>>>>> and GetFirstAPARAcctSplit().
>>>>>
>>>>> I also need GetOwnerFromTxn or GetOwnerFromLot. However, this
>>>>> and
>>>>> many
>>>>> similar functions return the resu
Re: [GNC-dev] Python Binding: GncOwner fails to convert from C->Python->C
Yes, it does look like the in type map ignores the out typemap's tuple and
tries to convert it into a pointer. That won't work. It should be something like
if (! PyTuple_Ceck($input))
return NULL;
GncOwnerType type = (GncOwnerType)PyLong_asLong(PyTuple_GetItem($input, 0));
PyObject* py_instance = PyTuple_GetItem($input, 1);
void* instance = NULL;
GncOwner* owner = gncOwnerNew()
switch (type)
{
case GNC_OWNER_CUSTOMER:
if (SWIG_ConvertPtr(py_instance, &instance,
$descriptor(GncCustomer *),
SWIG_POINTER_EXCEPTION)) == 0)
{
gncOwnerInitCustomer(owner, (GncCustomer *)instance);
$1 = owner;
}
/* ... */
}
/* Something failed */
gnc_owner_free(owner);
PyErr_SetString( PyExc_ValueError,
"Python object passed to function with GncOwner *
argument "
"couldn't be converted back to pointer of that type");
$1 = NULL;
That's untested off the top of my head, obvs you need to fill in the other
types. It should correctly make a GncOwner* to pass back to functions that take
one.
Now if you actually need the instance pointer you'll want to write a
typemap(in) for each one that you need. It will probably be cleanest to extract
the tuple item in python and pass that, letting the new %typemap(in) convert it
to a C pointer.
Geert, those typemaps are yours, written 11 years ago. Any comments?
Regards,
John Ralls
> On Jan 29, 2023, at 5:38 AM, Steve Brown wrote:
>
> I get a Python GncOwner object returned to Python. It appears well
> formed.
>
> owner:
>
> owner_instance: (4, 0x7f214b5a9500>)
>
> It's not clear how to easily inspect the Swig object.
>
> However, the object doesn't convert back to C. It's not recognized as
> GncVendor.
>
> I get:
>
> ValueError: Python object passed to function with GncOwner * argument
> couldn't be converted back to pointer of that type
>
> The out typemap for GncOwner looks correct. However, I can't see how
> the in typemap gets the swig wrapper object from the tuple created by
> the out typemap.
>
> I can recreate the problem in simple_business_create.py with the
> attached patch.
>
> If there is nothing obviously wrong with the typemaps, how should I go
> about debugging this?
>
> Thanks,
> Steve
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] GnuCash 4.901 Released
Neither of which seem to be in the bug tracker. Regards, John Ralls > On Feb 5, 2023, at 7:54 PM, Glenn Fowler wrote: > > Thank you to the team for the continued development! > > I just installed 4.901 on W10 and just pointing out two bugs still persist > from 4.900: > > 1. Tip of the day cannot be suppressed > 2. Keyboard shortcut for "Manage Document Link" is still missing > > Thank you > > On Sun, Feb 5, 2023 at 2:51 PM John Ralls <mailto:jra...@ceridwen.us>> wrote: > >> The GnuCash development team announces GnuCash 4.901, the second unstable >> release leading to GnuCash 5.0. >> >> This is an unstable release for testing purposes. Do not use it with >> production data! Make a copy of your book to test this release. >> >> New Features >> >>• A new Stock Transaction Assistant to guide you through entering >> most investment transactions for stocks, bonds, and mutual funds. You can >> access it from Actions>Stock Assistant when you have the Accounts page ora >> Stock or Fund account register open. >>• A new Investment Lots report showing a graph of capital gains >> and losses in a period by investment lot. Note that if you don't use the >> View Lots dialog to manage capital gains and losses this report won't have >> anything to show you. Use Reports>Assets & Liabilities>Investment Lots to >> see the report. >>• A new tab on the New/Edit Account dialog called More Properties >> includes entries to set a high and low limit on an account. That's coupled >> to a new column that's available on the Accounts Page, Balance Limit. If >> you set a high or low limit and the account balance falls above or below >> the respective limit an indicator will be shown in the Balance Limit column. >>• The description field quickfill in the register now displays a >> drop-down list of possible completions instead of just one inline >> completion. >>• File import menu items for the MT940, MT942, and DTAUS formats >> is replaced with a single Import from AQBanking that supports importing any >> file format supported by AQBanking, including the frequently requested CAMT. >>• The report generated by the Print Invoice button on the Edit >> Invoice tab can now be configured as a book option at teh bottom of the >> Business tab; this permits selecting a saved configuration of one of the >> standard invoice reports. Another option enables a delay, during which a >> dialog box will appear enabling the user to select a different report. >> >> Note: When saving a configuration make sure that the invoice number is not >> set or you'll get that particular invoice instead of the one that you >> pressed the button for. >> >> Between 4.900 and 4.901, the following bugfixes were accomplished: >> >> The following fixes will also appear in GnuCash 4.14: >>• Bug 797477 - Manual foreign transaction from APAR to another >> doesn't trigger price input >>• Bug 797725 - Untranslatable string "For Period Covering ~a to ~a" >>• Bug 798734 - Aging Reports don't handle mixed currency payments >> and invoices without Trading Accounts >>• Bug 798737 - Minor grammatical error - 'for' missing in 'You >> will be asked a conversion rate for each.' >>• Bug 798740 - Build fails with gcc 13 >>• Bug 798747 - Crash in Investment Portfolio report >> >> The following additional bug fixes are in unstable only: >> >>• Bug 753307 - Custom Report be selectable as default Report for >> Printing >> Change the preference in Business->'Report for Printing' to be saved as a >> book property and allow the selection of any Invoice Report to be used as >> the default. >> >>• Bug 794028 - CSV import, default to matching full account name >> If the account map doesn't yield a result, try to map the import string >> against existing accounts' full names >> >>• Bug 796955 - Import CSV - Single-line two-currency transactions >> can't be imported >>• Use a provided price if the transfer account uses a >> different commodity from the base account's; apply it as transfer amount = >> base amount * price. >>• Add a transfer amount column option to avoid the >> rounding that might arise from having an inexact price. >>• Bug 797756 - Currency format setting is ignored >>• Bug 798292 - csv Imp
Re: [GNC-dev] donation problem
> On Feb 10, 2023, at 8:04 AM, Michael or Penny Novack > wrote: > > Would love to donate, but ... > > Unfortunately your donation process assumes we can either ... > > a) Do an international bank transfer (would be a great deal of trouble/red > tape getting this set up as would need a one time override of fraud controls) > > b) Receive a confirmation code by text to a cell phone number. Cannot do that > from HERE. While we do have an emergency cell phone my wife caries in case > she breaks down on the road somewhere (at a location where there IS cell > phone service) we do not have cell phones to RECEIVE cell phone calls. That's > because there is no cell service where we live. If I am here at the computer > in the house, cannot receive a text. > > This is not an infrequent problem, a site ASSUMING can use a cell phone for > this. Thus we are limited in with whom we can have accounts and have to do > things like choose banking institutions based on whether they provide an > alternative authentication method (like automated voice call to our land line > number to send the code) > Really? You can't use a credit card through PayPal without SMS authentication? Fraud controls? How much are you thinking of donating? (If you want to take that part offline feel free, but please include at least Christian Stimming, Derek, Frank, and Geert in the conversation.) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] problem with importing CSV file
That's https://bugs.gnucash.org/show_bug.cgi?id=798703 Regards, John Ralls > On Mar 1, 2023, at 1:25 PM, Camille Rizko via gnucash-devel > wrote: > > Hello, I am getting an intermittent crash when importing a CSV file. I > attached a report. file.rtf>___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Test failure on current master branch
Geert, Aha! That would certainly explain why I couldn't reproduce it. That change is from https://github.com/Gnucash/gnucash/commit/408b5ec2165fb43bef18b80ff44ba4d2f1b67f5f. Yes, no doubt string->number expects the number to be represented in the current locale, so it wants "42,0" and getting "42.0" returns #f (https://www.gnu.org/software/guile/manual/html_node/Conversion.html). I'll have to find another way to make that conversion. Regards, John Ralls > On Mar 2, 2023, at 5:39 AM, Geert Janssens wrote: > > I still haven't figured out exactly where it goes wrong, but I did discover > it's a locale related issue. For some reason this particular test has become > locale sensitive. > > If I run the test as follows: > LC_ALL=C ctest -V -R test-gnc-option-scheme-output > it passes. If however I do this: > LC_ALL=fr_FR.utf8 ctest -V -R test-gnc-option-scheme-output > it fails. I have also tried nl_BE.utf8 (my native locale), which fails as > well. > I suspect the call to (string->number (GncOption-serialize option)) on line > 459 is failing. Perhaps GncOption-serialize spits out numbers in C locale > while string->number uses local locale or vice versa ? > > Regards, > > Geert > > Op woensdag 1 maart 2023 04:41:14 CET schreef John Ralls: > > Geert, > > > > I can't replicate that, tried on Debian 10, Debian Unstable, and Arch. I'm > > installing a Fedora 37 VM but I'm out of time for today and won't get to > > the point of a test build of GnuCash. > > > > Regards, > > John Ralls > > > > > On Feb 28, 2023, at 2:07 PM, Geert Janssens > > > wrote: > > > > > > Hi, > > > > > > With the current master branch I get the following test failure: > > > > > > ctest --rerun-failed --output-on-failure > > > Test project /home/janssege/Development/gnucash/master/build > > > > > > Start 120: test-gnc-option-scheme-output > > > > > > 1/1 Test #120: test-gnc-option-scheme-output ***Failed0.22 sec > > > gnc:make-string-option is deprecated. Make and register the option in one > > > command with gnc-register-string-option. > > > gnc:register-option is deprecated. Use gnc-register-foo-option instead. > > > gnc:option-set-value and indeed all direct option access is deprecated. > > > Use gnc-set-option instead. > > > gnc:make-font-option is deprecated. Make and register the option in one > > > command with gnc-register-font-option. > > > gnc:make-currency-option is deprecated. Make and register the option in > > > one command with gnc-register-currency-option. > > > gnc:make-budget-option is deprecated. Make and register the option in one > > > command with gnc-register-color-option. > > > gnc:option-set-default-value and indeed all direct option access is > > > deprecated. Use gnc-set- option instead. > > > gnc:make-commodity-option is deprecated. Make and register the option in > > > one command with gnc-register-commodity-option. > > > gnc:make-simple-boolean-option is deprecated. Make and register the option > > > in one command with gnc-register-simple-boolean-option. > > > gnc:make-pixmap-option is deprecated. Make and register the option in one > > > command with gnc-register-pixmap-option. > > > gnc:make-account-list-option is deprecated. Make and register the option > > > in one command with gnc-register-account-list-option. > > > gnc:make-multichoice-option is deprecated. Make and register the option in > > > one command with gnc-register-multichoice-option. > > > gnc:make-list-option is deprecated. Make and register the option in one > > > command with gnc- register-list-option. > > > gnc:make-number-range-option is deprecated. Make and register the option > > > in one command with gnc-register-number-range-option. > > > > > > FORMAT: error with call: (format #f "'~f<===" ===>#f ) > > > > > > argument is not a number or a number string > > > > > > Backtrace: > > > In ice-9/boot-9.scm: > > > 1752:10 14 (with-exception-handler _ _ #:unwind? _ # _) > > > > > > In unknown file: > > > 13 (apply-smob/0 #) > > > > > > In ice-9/boot-9.scm: > > > 724:2 12 (call-with-prompt _ _ #) > > > > > > In ice-9/eval.scm: > > > 619:8 11 (_ #(#(#))) > > > > > > In ice-9/command-line.scm: > > > 185:18 10 (_ #) > > > > > > In unknown file: &g
Re: [GNC-dev] [GNC] GnuCash 4.902 Released
If you mean the download links on https://www.gnucash.org/, that's because it's still not accepting updates. Use https://code.gnucash.org/website/. Regards, John Ralls > On Mar 6, 2023, at 3:17 AM, David H wrote: > > John, > > Ta for that. 1 question - download links seem to be pointing to 4.900 / > 4.901 not 4.902 ? > > Thanks David H. > > > On Mon, 6 Mar 2023 at 14:20, John Ralls <mailto:jra...@ceridwen.us>> wrote: > >> The GnuCash development team announces GnuCash 4.902, the second unstable >> release leading to GnuCash 5.0. >> >> This is an unstable release for testing purposes. Do not use it with >> production data! Make a copy of your book to test this release. >> >> New Features >> >>• A new Stock Transaction Assistant to guide you through entering >> most investment transactions for stocks, bonds, and mutual funds. You can >> access it from Actions>Stock Assistant when you have the Accounts page ora >> Stock or Fund account register open. >>• A new Investment Lots report showing a graph of capital gains >> and losses in a period by investment lot. Note that if you don't use the >> View Lots dialog to manage capital gains and losses this report won't have >> anything to show you. Use Reports>Assets & Liabilities>Investment Lots to >> see the report. >>• A new tab on the New/Edit Account dialog called More Properties >> includes entries to set a high and low limit on an account. That's coupled >> to a new column that's available on the Accounts Page, Balance Limit. If >> you set a high or low limit and the account balance falls above or below >> the respective limit an indicator will be shown in the Balance Limit column. >>• The description field quickfill in the register now displays a >> drop-down list of possible completions instead of just one inline >> completion. >>• File import menu items for the MT940, MT942, and DTAUS formats >> is replaced with a single Import from AQBanking that supports importing any >> file format supported by AQBanking, including the frequently requested CAMT. >>• The report generated by the Print Invoice button on the Edit >> Invoice tab can now be configured as a book option at teh bottom of the >> Business tab; this permits selecting a saved configuration of one of the >> standard invoice reports. Another option enables a delay, during which a >> dialog box will appear enabling the user to select a different report. >> >> Note: When saving a configuration make sure that the invoice number is not >> set or you'll get that particular invoice instead of the one that you >> pressed the button for. >> >> Between 4.901 and 4.902, the following bugfixes were accomplished: >> >> The following fixes will also appear in GnuCash 4.14: >> >>• Bug 798748 - Transaction Notes field's value does not appear in >> reverse transaction. >>• Bug 798754 - Build fails with gcc 13 and glib > 2.76 >>• Bug 798759 - Register widths for 'with sub-account' not saved >>• Bug 798600 - CSV import of multi-split security transactions >> fails to load capital gain >> Transactions with capital gains processing can have splits in transaction >> currency with a zero amount and a non-zero value. To properly import those, >> prefer the value column even if transaction currency equals account >> commodity. Previous (wrong) assumption was that in case of a same-currency >> split, the amount would always be the value. >> >> Update csv transaction export format to include split values. In the csv >> importer the 'GnuCash Export Format' option will now include values. For >> compatibility with filex exported from older gnucash versions the previous >> preset is still available under the name 'GnuCash Export Format (4.x and >> older)'. >> >> The following additional bug fixes are in unstable only: >> >>• Bug 782141 - Import CSV - Multi-currency support can cause >> rounding errors >> Replace the column types 'Deposit' and 'Withdrawal' with 'Amount' and >> 'Amount (Negated)' that are conceptually applicable more widely. Also >> introduce column types 'Value' and 'Value (Negated)' to allow construction >> of splits in commodities different from the transaction currency. While >> Value is the number in the transaction currency, always use 'Amount' in >> single-currency transactions. >&
Re: [GNC-dev] Performance regression loading account
> On Mar 12, 2023, at 1:28 PM, Maarten Bosmans wrote: > > Hi all, > > When testing the 4.902 flatpak, I noticed that loading an account > takes several (~4.5) seconds. This account has about 24k transactions > and loads in less than half a second on the GnuCash 4.8 from my > distribution. Is this a regression because of a code change, or > perhaps simply the result of a debug build in the flatpak? > > From the attached flamegraph you can see that a lot of time is spent > in `g_utf8_collate` for the quickfill insert. That function does not > appear below `gnc_quickfill_insert` for the 4.8 run. I did a quick > search in the git history to see that may be some caller was changed > to the `QUICKFILL_ALPHA` sort method, but could not easily find such a > thing. > > Another difference with 4.8 is stat `gnc_table_realize_gui` (which > takes 0.85s) does not appear below > `gnc_plugin_page_register_create_widget` and that function only takes > 0.03s in total. This time seems to be spent in Gtk. > > I don't think this is a release blocking bug, but GnuCash feels quite > sluggish to me, so it would be nice to fix this papercut before 5.0. > Any pointers on how to proceed? My first guess is that it's from creating a cache of quickfill entries to populate a drop-down list of possible entries similar to the way the transfer account field has worked for a couple of years. An obvious optimization is to get a collation key with g_utf8_collate_key for each string and use that for doing the actual sorting/ordered inserting. It's still a char-by-char comparison but it saves having to validate and normalize the strings on every compare. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Preferred way of writing object oriented code
> On Mar 14, 2023, at 12:24 PM, Maarten Bosmans wrote: > > Hi, > > In preparation for making some changes to QuickFill.c, I thought it > would be a good idea to get familiar with the GnuCash code by doing > some easy fixes or code improvements. > So I turned on the AddressSanitizer of GCC and ran the test suite. The > first issue I looked at was a delete of a GncGuid that was allocated > with g_malloc(). Trying to untangle that led me through several > parallel implementations of objects and containers: GLib, Qof, and > C++. Let's just say that the codebase has a rich and varied history. > > Of course this is not new to any current developers of GnuCash. On C++ > page on the wiki it is mentioned that C++ should be preferred over > GLib and Qof. I think that makes sense. > I have a couple of questions for further clarification, as I want to > avoid spending time on preparing patches that you don't want to > accept. > - I see that GncGuid is implemented using boost::uuid now. But the > implementation still interfaces with glib and qof. Is eliminating that > seen as a worthwhile further improvement? (even if it is just > replacing `gconstpointer` with `const *void`) > - Could in general any GList instance that is not needed for > interfacing with Gtk potentially be converted to the appropriate C++ > container? > - Does this also mean that any .c file can be converted to .cpp if we > need to make use of a C++ feature? (e.g. std::vector, or templated > functions) Rich and varied indeed! As for GUID: It still has Glib and QOF interfaces because it's pervasive throughout the code-base. The way towards changing that is getting rid of Glib and QOF, not fixing them to use GUID instead of GncGUID. Spelling changes like gconstpointer -> const void* (or void const* if you're an east-const person) isn't really useful on their own, but if you're doing something serious and that happens to be there then it's OK. Good refactorings of 400-line functions is a lot more useful if you want to clean up code. Writing unit tests is even better. Changing a GList to std::vector is always a nice improvement, but if it's an rv or out-variable of a public function then you have to make sure that all of the consumers are also compiled with C++, *including SWIG bindings*. That's a general statement for c -> c++ conversion of any file: You have to make sure that either all of the consumers of what that file exports in its public header are also compiled with C++ (in which case you should rename the header to .hpp to make it clear that it's a C++-only header) or that the exported functions are marked extern "C" and will compile in C. Does that help? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Performance regression loading account
Bob, Please open a bug report and attach your sample test file. Regards, John Ralls > On Mar 15, 2023, at 4:02 AM, Robert Fewell <14ubo...@gmail.com> wrote: > > I wanted to get some numbers on this as my test file seemed OK. > I used Calc to create a CSV transaction import file with 8402 rows and some > description columns with 16, 64 and 128 character random strings. > Used this to import several times to a new empty gnucash xml file and added > some timing for the account open command in 4.903 and 4.13 with results > below... > > With 4.903 > Description 16 Characters and 16804 unique transactions / descriptions, 0.93, > second time 0.73 > Description 64 Characters and 16804 unique transactions / descriptions, 2.39, > second time 1.67 > Description 128 Characters and 16804 unique transactions / descriptions, > 4.08, second time 2.90 > > With 4.13 > Description 16 Characters and 16804 unique transactions / descriptions, 0.49, > second time 0.35 > Description 16 Characters and 16804 unique transactions / descriptions, 1.22, > second time 0.61 > Description 16 Characters and 16804 unique transactions / descriptions, 1.91, > second time 0.93 > > Regards, > Bob > > On Tue, 14 Mar 2023 at 18:54, Maarten Bosmans <mailto:mkbosm...@gmail.com>> wrote: >> Op ma 13 mrt 2023 om 04:44 schreef john > <mailto:jra...@ceridwen.us>>: >> > My first guess is that it's from creating a cache of quickfill entries to >> > populate a drop-down list of possible entries similar to the way the >> > transfer account field has worked for a couple of years. >> >> Yes, I've isolated it to the commit "Change the Register description >> layout cell type", Bob in CC. >> That branch adds the combobox and quickfill to the description field >> of the register. In my case those are fairly long (~100 chars) and all >> unique strings, as they come frome downloaded bank statements and >> include a timestamp, account holder, actual description, etc. So for >> my use case having a combo box to easy filling out new items is not >> that useful anyway. May be we can think of a way to adapt the >> behaviour to be useful in Bob's case (I suppose manual entry of a >> short and often reused description text), but not slow down my case? >> >> > An obvious optimization is to get a collation key with g_utf8_collate_key >> > for each string and use that for doing the actual sorting/ordered >> > inserting. It's still a char-by-char comparison but it saves having to >> > validate and normalize the strings on every compare. >> I will have a look into storing the collated string in the QuickFill. >> That probably doubles the memory usage, but should not be too bad. >> >> Maarten ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
