Re: [GNC-dev] Building Mac version using SDK 12

On 15 Sep 2022, at 13:54, john wrote: 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? Yes, it was a compiler version skew. It seems that Apple's frameworks won't compile with some

[GNC-dev] Building Mac version using SDK 12

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

Re: [GNC-dev] Removing "unused" code

On 12 Jun 2021, at 7:57, Christopher Lam wrote: This particular commit aimed to simplify and reduce old code. It can be reverted. Would you consider submitting them into the repository? Whether or not to delete code that may be unused is always a judgment call. I think we are sometimes

Re: [GNC-dev] Removing "unused" code

On 12 Jun 2021, at 8:59, D. wrote: I thought the eguile report was included in the distribution already. There is at least one EGuile report in the distribution (a balance sheet report, I think) but I don't think this one is included.. Mike ___

[GNC-dev] Removing "unused" code

I would like to request that we avoid removing code that is thought to be unused, but which may in fact be used, just for the sake of cleaning things up. I use a couple of reports that are not part of the standard GnuCash distribution and every now and then they stop working because something

Re: [GNC-dev] Auto reconcile from register window

Yes, but, Autoclear doesn't need an account any more than reconcile needs one. Both gnc_plugin_page_register_cmd_reconcile and gnc_plugin_page_register_cmd_autoclear call gnc_plugin_page_register_get_account to get the account to work on. This may return a null pointer if the register

[GNC-dev] Auto reconcile from register window

I noticed the recent checkins related to the auto reconcile feature. This intrigued me since I didn't know such a feature existed. After looking around for a while it appears that this is because it is only available for the account tree and I always start a reconcile from the register

Re: [GNC-dev] Crash during OFX import

On 30 Jun 2020, at 11:39, jean laroche wrote: I believe you're right. The bug was mine. But you had a difficult merge combining your changes with mine. Back when I was gainfully employed handling merges was one of my jobs and I know that it can be difficult. Mike

Re: [GNC-dev] Crash during OFX import

On 29 Jun 2020, at 12:58, John Ralls wrote: It's the right way. We're just in an unusual phase right now where master is the current stable. It's only on master because those struct _ofx_info members were introduced by

Re: [GNC-dev] gnucash master: Fix binreloc compile error with gcc.

On 27 May 2020, at 12:18, John Ralls wrote: It had nothing to do with mach-o/dyld.h: The build failures were on the TravisCI Linux dockers. Why did I not get an EMail from the Travis failure? On other projects I sometimes work on a Travis failure (or even a Travis success) produces an

Re: [GNC-dev] gnucash master: Fix binreloc compile error with gcc.

On 25 May 2020, at 11:01, John Ralls wrote: Updated via https://github.com/Gnucash/gnucash/commit/fde6be6e (commit) from https://github.com/Gnucash/gnucash/commit/159ceb64 (commit) commit fde6be6e018151c7884fd8754470c13924bbb683 Author: John Ralls Date: Mon May 25 08:01:47

Re: [GNC-dev] Resolving symlinks in _br_find_exe in binreloc.c

On 22 May 2020, at 13:32, John Ralls wrote: Even if you say GNC_UNINSTALLED=1 GNC_BUILDDIR=`pwd` bin/gnucash ? Not that I'm suggesting you shouldn't fix binreloc, I just wonder if the uninstalled bypass is broken. GNC_BUILDDIR works, but it has some other side effects which may not be

Re: [GNC-dev] Resolving symlinks in _br_find_exe in binreloc.c

On 21 May 2020, at 14:41, John Ralls wrote: The code that we have is gnomified from the original autopackage.org version. I agree it's pretty awful; the comparison of sizeof(ptr) to SSIZE_MAX particularly so; trying to allocate SSIZE_MAX-1 in the impossible case that sizeof(ptr) > SSIZE_MAX

[GNC-dev] Resolving symlinks in _br_find_exe in binreloc.c

I've had some fixes in binreloc.c for some time that I'm trying to clean up and commit. Part of the problem is that _br_find_exe doesn't work at all for non-Aqua Mac builds (i.e. using X11). I've fixed this by calling _NSGetExecutablePath if GNC_PLATFORM_OSX is set and MAC_INTEGRATION is not

Re: [GNC-dev] XCode build not building gnc-vcs-info

On 6 May 2020, at 13:27, John Ralls wrote: There should be a target for gnc-vcs-info. Maybe it's not getting into the build-all target, or isn't in the right place? There is. I discovered that everything works ok if you build using xcodebuild from the command line. In that case it makes

Re: [GNC-dev] XCode build not building gnc-vcs-info

Thanks, but the dependencies were already installed, and worked fine when I hand-built gnc-vcs-info.h so that's not the problem. I'm not using, and have never used jhbuild so it's not involved. I'm building using cmake and ninja. The result isn't packaged into an application bundle, but it

[GNC-dev] XCode build not building gnc-vcs-info

I tried the XCode project on the master branch this afternoon and the build failed because there was no rule to build libgnucash/core-utils/gnc-vcs-info.h. When I copied it from another recent build directory everything worked fine so this seems to be the only problem with using XCode with

Re: [GNC-dev] PDF Reports

On 25 Mar 2020, at 11:47, John Ralls wrote: OK. That's in MacPorts, right? Yes. It's the standard version of the webkit2-gtk port, version 2.26.2, I have no local mods. I didn't use their prebuilt binaries since I want the Aqua variant. It was built with the toolchain from XCode Version

Re: [GNC-dev] PDF Reports

FWIW I use WebKit2 (currently version 2.26.2) with the Quartz version of GnuCash and reports with charts seem to work fine. Even the tooltips work. You might want to give it a try again in case they've fixed something. Mike On 18 Mar 2020, at 12:14, John Ralls wrote: To

Re: [GNC-dev] A little hint for xcode usage (scheme)

I used to use XEmacs much like John describes, although I did use the debugging mode in XEmacs. That was long enough ago that lldb wasn't around, at least not for what I was working on. Now I use XCode for debugging and BBEdit for editing. They work together pretty well and XCode's

Re: [GNC-dev] A little hint for xcode usage (scheme)

On 8 Mar 2020, at 19:41, John Ralls wrote: For my part I seldom use Xcode at all. I use emacs for editing and do the builds in a terminal window (I use iTerm2 rather that Terminal). That works too. Back when I developed code for Windows and Unix as well as Mac I used XEmacs for everything,

Re: [GNC-dev] A little hint for xcode usage (scheme)

On 8 Mar 2020, at 17:59, jeanl wrote: The xcode project has tons of scheme. My question is: which scheme do I use to be able to build gnucash, place a break point in any given file and start debugging? The short answer is that you want the ALL_BUILD scheme. For more info look for the

Re: [GNC-dev] gnc:debug changes

On 7 Mar 2020, at 5:22, Christopher Lam wrote: Ok I think your changes are fine. I don't understand qof_log_check I'd hope it's not slow. I just pushed the change. qof_log_check is called a *lot* and I don't think it's a problem. It does a couple of hash table lookups and a couple of

Re: [GNC-dev] gnc:debug changes

On 7 Mar 2020, at 0:39, Christopher Lam wrote: I'd thought that the log level would be an invariant per session. If log levels could be amended mid-session I'd like to see how. Call qof-log-set-level. It works fine without the most recent change to gnc:debug. I put a few calls to it into

[GNC-dev] gnc:debug changes

I spent some time yesterday figuring out why gnc:debug never produced any output regardless of the gnc.scm log level. I tracked it down to commits 42b6fb9 and b3a4cd6 from last July. The actual bug is trivial (they test for the log level for "gnc" instead of "gnc.scm") but I wonder if

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

On 11 Feb 2020, at 8:14, Edward d'Auvergne wrote: Although most runs pass, I have noticed that some do not [4]. Have you seen that behaviour or know what might be happening? Sometimes AlphaVantage refuses to return a quote. Right now

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

On 11 Feb 2020, at 3:59, Edward d'Auvergne wrote: F::Q uses this URL for all queries: https://www.alphavantage.co/query?function=GLOBAL_QUOTE=json=IDRUSD=$MY_KEY The result I see is: { "Global Quote": { "01. symbol": "IDRUSD", "02. open": "0.0001", "03. high":

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

On 10 Feb 2020, at 6:27, Edward d'Auvergne wrote: I realise that F::Q is broken in some places. As I said, I reported an issue. However, as you have seen yourself, the F::Q developers are simply non-responsive. I believe that asking all GnuCash users to manually patch their own

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

On 9 Feb 2020, at 3:49, Edward d'Auvergne wrote: That sounds like it would work, however I see quite a different behaviour with the debugging (in my first post) and from the code (gnucash/price-quotes.scm and libgnucash/quotes/gnc-fq-helper.in). What I see in both is that for each iteration of

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

On 4 Feb 2020, at 6:21, Edward d'Auvergne wrote: That's a good point. In the future, F::Q might also be able to respect the API fetching limits across multiple calls, and then this would add an additional delay. That could be fixed by properly timing this while loop. As for sleeping for

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

I'm glad you're looking at this since it does need some work. However I think there are a couple of things you're not aware of. I, too, have quite a ffew currencies in my file (around 30) and by coincidence I was running a price fetch in the background when I first saw your message. It

Re: [GNC-dev] Robust error handling and respecting the Apha Vantage API limits in gnc-fq-helper.

I'm glad you're looking at this since it does need some work. However I think there are a couple of things you're not aware of. I, too, have quite a ffew currencies in my file (around 30) and by coincidence I was running a price fetch in the background when I first saw your message. It

Re: [GNC-dev] gnucash.xcodeproj obsolete ?

On 16 Jan 2020, at 16:40, Geert Janssens wrote: With this capability baked into cmake do we still want to keep the old xcode project in our repo ? Can it do something we wouldn't be able to do with the cmake generated xcode project (possibly after some tweaking of our current cmake scripts)

Re: [GNC-dev] Online ID matching for OFX import

On 5 Jan 2020, at 23:27, John Ralls wrote: I want you to code review and test the PR when I finish. ;-) The online_id comes from from the import source, AQBanking in this particular case--and we must be more careful because the code in question applies to all of the importers except QIF--and

Re: [GNC-dev] Online ID matching for OFX import

On 5 Jan 2020, at 19:46, John Ralls wrote: Complexity is not a valid reason to reject a solution to a complex problem unless there's a simpler solution that solves it *just as well*. Hackish solutions--and I'm just as guilty on that front as I wrote the strncmp hack--are far more likely to

Re: [GNC-dev] Online ID matching for OFX import

I agree that running the search twice is probably ok. However, John raises another point which seems relevant. What if there is more than one partial match? Right now it returns the first one. It would seem better to punt if there is no full match and more than one partial match.

Re: [GNC-dev] Online ID matching for OFX import

it will since the accounts commodity will be wrong. Mike On Sun, Jan 5, 2020, 10:01 AM John Ralls wrote: > > > > On Jan 5, 2020, at 12:40 AM, Mike Alexander wrote: > > > > When I tried to do my monthly import of an OFX file containing my > TIAA/CREF transactions it f

[GNC-dev] Online ID matching for OFX import

When I tried to do my monthly import of an OFX file containing my TIAA/CREF transactions it failed miserably. I tracked it down to commit 7853f5a2 which changed the matching of online IDs for accounts to only match an initial substring of the required ID. My accounts are structured with a

Re: [GNC-dev] gnucash maint: remove unnecesary 'home' level in path for US Income Tax book tax information

> On Jan 26, 2019, at 1:57 PM, Alex Aycinena wrote: > > Mike - Is your build working now? > Yes, it’s fine now. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: remove unnecesary 'home' level in path for US Income Tax book tax information

This commit is causing build failures for me. I get a number of errors of the form /tools/gnucash-git/gnucash/libgnucash/app-utils/gnc-ui-util.c:264:73: error: expression which evaluates to zero treated as a null pointer constant of type 'const char *' [-Werror,-Wnon-literal-null-conversion]

Re: [GNC-dev] Currencies in Price Database UI gone weird in 3.4

> On Jan 13, 2019, at 7:44 AM, Wm via gnucash-devel > wrote: > > I tried to get new exchange rates today for the first time since updating to > 3.4. Tools / Price Database / Currencies was largely unpopulated. I looked > in the file and the prices are there. I reverted to 3.3 and all

Re: [GNC-dev] Compiling Gnucash on MacOS - not for the faint of heart...

> On Jul 1, 2018, at 11:23 PM, John Ralls wrote: > > Last question first, bash and emacs. ISTR Mike Alexander uses vim and emacs. Sorry for the delay, I’m a bit behind on EMail My GnuCash environment is probably unique, or at least was until recently. I’ve been too busy to upda

Re: Moving .gnucash and friends from $HOME to XDG_DATA_HOME (and impact on other applications like KMyMoney)

> On Aug 23, 2017, at 1:09 PM, Geert Janssens > wrote: > > Linking has its drawbacks as well though. If I link the directory, the files > and subdirectories will be essentially the same. However if the user > misinterprets the message and removes file by file from

Re: Python bindings and Gtk3

> On Aug 10, 2017, at 3:22 AM, John Ralls wrote: > > 3.22.what? I pushed the change to gtk that caused the pango breakage between > 3.22.11 and 3.22.12 so 3.22.11 wouldn't have had the problem... and of course > if pango is using the fontconfig backend it

Re: Python bindings and Gtk3

> On Aug 9, 2017, at 1:49 PM, John Ralls wrote: > > Hmm, looks like both whitespace and font are larger. What version of Gtk+-3? > It’s version 3.22. > Hmm, looks like both whitespace and font are larger. What version of Gtk+-3? > > You can try fiddling with

Re: Python bindings and Gtk3

> On Aug 9, 2017, at 12:21 AM, Mike Alexander <m...@umich.edu> wrote: > >> On Aug 8, 2017, at 10:23 AM, John Ralls <jra...@ceridwen.fremont.ca.us> >> wrote: >> >> I don't know if the MacPorts X-build uses the CoreText or FontConfig backend >> for

Re: Python bindings and Gtk3

> On Aug 8, 2017, at 10:23 AM, John Ralls wrote: > > I don't know if the MacPorts X-build uses the CoreText or FontConfig backend > for Pango, but if it uses CoreText it might be your problem. I don’t know either. I see that Pango’s configure looks for (and

Re: Python bindings and Gtk3

> On Aug 7, 2017, at 8:51 PM, Sumit Bhardwaj wrote: > > For the tab issue, can you share a screenshot or something to that effect? I > am on master build and have tabs on right-hand side as well, but it's > perfectly usable. > It’s certainly usable, I didn’t mean to

Python bindings and Gtk3

You may already know this, but the Python bindings done’t work in the current master branch (they still use Gtk2). I made a brief attempt to fix this, but I don’t know either Python or Gtk3 well enough. I also noticed a cosmetic issue that you may not be aware of because I use a non-default

Re: xaccTransSetCurrency and Bug 763146

> On Mar 16, 2016, at 10:54 PM, John Ralls wrote: > > In the course of working on and testing bug 763146 [1] the reporter > discovered an interesting auto-completion bug: If the transaction that's > being copied is multi-currency and was created in the other register (so

Re: xaccTransSetCurrency and Bug 763146

> On Mar 17, 2016, at 6:55 PM, John Ralls wrote: > > Neither. I'm used to finding bugs like that because the early authors weren't > thinking about multi-currency transactions and by the time you started to the > codebase had become far too bloated and convoluted to track

Re: Tag for 2.6.9

--On November 18, 2015 at 6:37:06 AM -0800 John Ralls wrote: The “missing” tags along with all of the branches that you don’t use are in .git/packed-refs. Might be a config issue. You can force retrieval of the tags with `git fetch -t`. "git fetch -t" more or less fixed

Re: Problems building with guile2

--On November 18, 2015 at 6:38:51 AM -0800 John Ralls wrote: Have you upgraded to ElCap? If so, see https://bugzilla.gnome.org/show_bug.cgi?id=757616. No, I'm still on Yosemite. This isn't the problem. Anyway, by adjusting the value of DYLD_LIBRARY_PATH I was able to

Re: Tag for 2.6.9

--On November 17, 2015 at 9:41:49 AM +0100 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: On Tuesday 17 November 2015 02:33:08 Mike Alexander wrote: Is there a reason that there's no 2.6.9 tag in the Git repository? It seems like it should go on 4241505.

Re: Tag for 2.6.9

--On November 17, 2015 at 8:09:55 PM -0800 John Ralls <jra...@ceridwen.us> wrote: On Nov 17, 2015, at 4:38 PM, Mike Alexander <m...@umich.edu> wrote: --On November 17, 2015 at 9:41:49 AM +0100 Geert Janssens <geert.gnuc...@kobaltwit.be> wrote: On Tuesday 17 November

Problems building with guile2

I tried to merge maint into master tonight. Although the merge seemed to be fairly easy, the result wouldn't build. I tried to figure out why, but eventually gave up. The problem exists in maint too, it won't build with guile2. There were a lot of changes to various Scheme files recently

Re: understanding currency exchange...

--On November 14, 2015 at 12:37:04 PM -0800 John Ralls wrote: Let’s at least make the non-trading account view look like the trading account view with each split amount. That will help some with the confusion. You mean always show the amount instead of the value? I

Tag for 2.6.9

Is there a reason that there's no 2.6.9 tag in the Git repository? It seems like it should go on 4241505. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: understanding currency exchange...

> On Nov 14, 2015, at 10:22 AM, John Ralls <jra...@ceridwen.us> wrote: > > >> On Nov 13, 2015, at 8:49 PM, Mike Alexander <m...@umich.edu> wrote: >> >> --On November 11, 2015 at 5:12:38 PM -0800 John Ralls <jra...@ceridwen.us> >> wrote:

Re: Rounding in the price db.

On Aug 17, 2015, at 5:36 AM, John Ralls jra...@ceridwen.us wrote: On Aug 12, 2015, at 2:13 PM, John Ralls jra...@ceridwen.us wrote: It might help to consider what the price db is used for: Aside from providing a default rate in the transfer dialog, it’s used for pricing assets in the

Re: Rounding in the price db.

--On August 13, 2015 at 10:06:09 AM +0100 John Ralls jra...@ceridwen.us wrote: Another related thought: Answering a dialog box every time one enters a two-currency transaction is going to annoy anyone who has to enter a bunch of such transactions. I can think of several ways of dealing with

Re: Rounding in the price db.

--On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens geert.gnuc...@kobaltwit.be wrote: I'm not really sure about the price entered vs F::Q price. I would imagine that if you are tracking stock, you would be interested in the exact real price you bought/sold it, which is not necessarily

Re: Rounding in the price db.

--On August 11, 2015 at 9:20:43 AM +0100 John Ralls jra...@ceridwen.us wrote: Hmm. That’s doable in master with careful rounding control. I’m pretty sure it would produce overflows in maint because the old int128 math is really int128-int64 and it barfs if any intermediate result won’t fit in

Re: Rounding in the price db.

--On August 10, 2015 at 4:27:40 PM +0100 John Ralls jra...@ceridwen.us wrote: I seem to remember that banks here use 6 significant digits in exchange rates, which is not quite the same as 6 places after the decimal point. Your USD-Sao Tomean Dobra illustrates this: due to the extreme value

Re: gnucash master: Multiple changes pushed

On Aug 10, 2015, at 3:05 AM, John Ralls jra...@ceridwen.us wrote: I pushed the change Alex suggested to maint and that got my other change synced to Github so everything should be OK now. I pushed changes to maint and master that I think fix things up. They replace my change to

Re: Rounding in the price db.

--On August 9, 2015 at 8:35:04 PM +0100 John Ralls jra...@ceridwen.us wrote: A recent IRC conversation and a discussion (face to face!) with a user got me thinking about the prices entered from the transfer dialog into the price db. The current situation is that when the user creates a

Re: gnucash master: Multiple changes pushed

--On August 9, 2015 at 10:36:52 AM +0100 John Ralls jra...@ceridwen.us wrote: m On Aug 8, 2015, at 5:00 PM, gnucash-patches-requ...@gnucash.org wrote: commit 1e16ba6c14ccec6222a8fe798e7824285fd49cac Author: Mike Alexander m...@umich.edu Date: Fri Aug 7 19:43:12 2015 -0400 Quote the date

Re: io-gncxml-v1.c

On Jun 14, 2015, at 3:17 AM, John Ralls jra...@ceridwen.us wrote: Mike, I’m working on extracting the KVP operations and this file has a bunch. From history it looks like you’ve been maintaining it recently. Do you have a test file? I recall vaguely doing some work on it a few years

Re: Difficulty building on MacOSX

--On May 5, 2015 at 6:18:09 PM -0700 John Ralls jra...@ceridwen.us wrote: I obviously haven’t encountered that problem, and ISTM our environments for this purpose should be pretty much identical, at least when you’re using the Xcode compiler. The one possibility that comes to mind is

Re: Difficulty building on MacOSX

--On May 7, 2015 at 7:19:49 AM -0700 John Ralls jra...@ceridwen.us wrote: Surely you didn’t rebuild libc just to get a 64-bit time_t. What motivated you? Since you went to the work of replacing libc and the headers in your SDK (and have to redo it every time Apple pushes an Xcode upgrade), why

Re: Difficulty building on MacOSX

--On May 5, 2015 at 6:18:09 PM -0700 John Ralls jra...@ceridwen.us wrote: I obviously haven’t encountered that problem, and ISTM our environments for this purpose should be pretty much identical, at least when you’re using the Xcode compiler. The one possibility that comes to mind is

Difficulty building on MacOSX

I'm having trouble building the X window version of Gnucash with the recent changes to use Boost for data and time on MacOSX 10.10.3 with XCode 6.3.1. I've tried using both clang as provided by XCode and GCC 4.8 as provided by MacPorts and get similar failures. In each case either the first

Re: gnucash master: Book-Currency Feature step 1

--On February 9, 2015 at 10:48:30 PM -0800 Alex Aycinena alex.aycin...@gmail.com wrote: That's exactly the approach planned. The book options dialogue will be a choice of three currency accounting approaches: trading accounts, book-currency, neither. If trading accounts is selected, it should

Re: gnucash master: Book-Currency Feature step 1

On Feb 9, 2015, at 4:18 PM, J. Alex Aycinena alex.aycin...@code.gnucash.org wrote: Updatedvia https://github.com/Gnucash/gnucash/commit/b22c6b6e (commit) from https://github.com/Gnucash/gnucash/commit/9c8405da (commit) commit b22c6b6eb9ab86273bfc7225cc50504f28158bc8

Re: Byte order mark always make some files modified

--On December 28, 2014 at 7:19:42 PM +0800 Chenxiong Qi qcxh...@gmail.com wrote: And what sort of machine is this on? Windows, Mac, or Linux? I have core.autocrlf set to input and it seems to work ok for me on my Mac. You might want to reread the section on End-of-line conversion in the git

Re: Byte order mark always make some files modified

the globs in .gitattributes 2 Dec., and Mike Alexander removed the line endings from the repo on the 8th. This worked correctly for me just now, with no core.autocrlf setting. Did you experience the problem with a fresh checkout or an older one? README.win32-bin.txt and downloaded.mt940 don't have

Re: git always make some files modified

--On December 27, 2014 at 9:16:56 PM +0100 Christian Stimming christ...@cstimming.de wrote: My solution is as follows: - Remove the .gitattributes file - Commit this removal into git (which makes the modified-message go away), - And reset the master branch back to the original master.

Re: python-bindings: coredump whil executing gnucash.Session

--On December 14, 2014 at 7:02:15 AM -0800 John Ralls jra...@ceridwen.us wrote: Did you regenerate the swig files? You'll need to do that often on master. If you build in a separate directory you'll need to `git clean -fdx` in your source directory then re-run autogen.sh and configure. If you

Re: commit 78fea12afc5f0db5a137d0766e92994232f60a78

--On December 13, 2014 at 12:13:23 PM -0800 John Ralls jra...@ceridwen.us wrote: I do use MacPorts and I see that it has a really weird patch to Glib's configure file which affects this area. I need to figure out what they think they are doing and what effect it may be having on this problem.

Re: commit 78fea12afc5f0db5a137d0766e92994232f60a78

--On December 11, 2014 at 8:31:03 PM -0800 John Ralls jra...@ceridwen.us wrote: Thanks for reverting. No problem, I shouldn't have committed it in the first place. You may well be the only one who's building 64-bit on a mac. I think pretty much everyone does on Linux, but Linux seems to

Re: commit 78fea12afc5f0db5a137d0766e92994232f60a78

--On December 11, 2014 at 11:37:19 AM -0800 John Ralls jra...@ceridwen.us wrote: Please ask on the list or file a bug before making changes to the new code. Bear in mind that I’m developing in OS X too and using Xcode tools daily though not the IDE, so problems you’re encountering are perhaps

Re: C++ work

--On September 9, 2014 at 3:12:33 PM -0400 Aaron Laws dartm...@gmail.com wrote: Currently, c++ work is starting at the deepest point (the part of the code that is relied on by everything), qof, so that a C api has to be maintained until everything that relies on QOF has a way of accessing the

Re: Namespaces, file names,...

On Sep 5, 2014, at 11:26 AM, Buddha Buck blaisepas...@gmail.com wrote: When every method name has to be Hungarian-notated to work with pseudonamespaces, short namespace abbreviations make sense. But with true namespaces, using directives, and namespace aliasing available in C++, I see

Re: Gnucash c++

On Aug 11, 2014, at 4:52 PM, Christian Stimming christ...@cstimming.de wrote: thanks for investing time in Gnucash and also in its development towards more future-proof programming technologies. I was a bit puzzled about the benefit of switching the normal compiling from C to C++, just by

Re: -Wno-deprecated-register with Clang

--On July 2, 2014 at 3:39:07 PM -0400 Mike Alexander m...@umich.edu wrote: I found my stupid mistake and GnuCash now builds ok with clang for me (a lot faster too). I do both an optimized and a debug build. The optimized build works ok, but the debug build crashes trying to produce a vendor

Re: -Wno-deprecated-register with Clang

--On July 2, 2014 at 9:58:28 AM +0200 John Ralls jra...@ceridwen.us wrote: Yeah, I build all the time with Clang, otherwise I wouldn't have needed to make that change. I'm using Xcode 5.0 because of a problem with 5.1, though I don't remember exactly what. I think it might even have been

Re: gnucash master: Multiple changes pushed

--On July 2, 2014 at 5:01:10 PM -0400 John Ralls jra...@code.gnucash.org wrote: Updated via https://github.com/Gnucash/gnucash/commit/29923b1f (commit) via https://github.com/Gnucash/gnucash/commit/773326b7 (commit)from https://github.com/Gnucash/gnucash/commit/d3389828

-Wno-deprecated-register with Clang

I just tried to compile GnuCash with clang and it failed because of the change in 4aed8b3 to not set -Wno-deprecated-register with clang. The version of clang in Mavericks (MacOSX 10.9) certainly recognizes this parameter and won't compile GnuCash without it. Which version of clang were you

Re: Rethinking Numeric

--On May 31, 2014 11:19:23 PM +0200 Christian Stimming christ...@cstimming.de wrote: But back to your initial question: You said we occasionally encounter overflow errors. I don't understand (yet) what the actual problem is. With our current rational numbers and int64_t numerator we have

Re: gnucash master: A truly ancient bug, discovered with an Xcode-5.1 compiler warning.

--On May 19, 2014 7:07:46 PM -0400 John Ralls jra...@code.gnucash.org wrote: Updated via https://github.com/Gnucash/gnucash/commit/eabaee8e (commit)from https://github.com/Gnucash/gnucash/commit/6e62ce99 (commit) commit eabaee8eb58c557743b8b1b476b4145b97eb9836 Author: John Ralls

Re: private-kvp merge reverted other changes since November.

On May 13, 2014, at 11:47 AM, John Ralls jra...@ceridwen.us wrote: Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development

Re: private-kvp merge reverted other changes since November.

--On May 13, 2014 9:17:58 PM +0100 Colin Law clan...@gmail.com wrote: It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There

Re: private-kvp merge reverted other changes since November.

--On May 13, 2014 9:35:58 PM -0700 John Ralls jra...@ceridwen.us wrote: That's the SVN way. We discussed this back in March [1] and decided that we're not going to do that anymore. If you want to revisit that you need a better argument than that's the way I've always done it, considering that

Re: private-kvp merge reverted other changes since November.

--On May 6, 2014 10:41:17 PM -0400 John Ralls jra...@ceridwen.us wrote: That's unfortunate. It means that our strategy of merging instead of rebasing isn't going to work. I can't address the details until I get back from travel next week -- and it may take a few more days of catch up after

Re: private-kvp merge reverted other changes since November.

--On May 7, 2014 6:41:03 PM +0200 Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 06 May 2014 18:16:51 Mike Alexander wrote: Just to pick another random example, the merge also removed a call to qof_instance_set_dirty in gnc_template_register_save_xfrm_cell which is in register

private-kvp merge reverted other changes since November.

I get this error when I quit GnuCash (master branch) with a report open: Backtrace: In ice-9/boot-9.scm: 157: 7 [catch #t #catch-closure 116f3a2c0 ...] In unknown file: ?: 6 [apply-smob/1 #catch-closure 116f3a2c0] ?: 5 [call-with-input-string gnc:report-generate-restore-forms ...] In

Re: Crash paying invoice

--On May 5, 2014 12:11:32 AM -0400 John Ralls jra...@ceridwen.us wrote: Turned out not to be so hard after all, there's just an extra level of indirection required. Fixed in edd85fa. Thanks for fixing it. It seems to work fine for me now. Mike

Crash paying invoice

Something in private-kvp branch that was merged in a day or two ago seems to have broken part of the business features. If I try to pay an invoice for a customer I get a crash in the code that creates the payment window. The top of the stack is * thread #1: tid = 0x81af3a,

Re: gnucash maint: Multiple changes pushed

On May 2, 2014, at 10:01 AM, Geert Janssens janssens-ge...@telenet.be wrote: I have pushed a commit that only adds _FORTIFY_SOURCE if compilation with optimization is detected. Feel free to improve it if you have a cleaner solution. Geert Thanks for fixing it. Just out of curiosity,

Re: gnucash maint: Add _FORTIFY_SOURCE directive only when compiling with optimization enabled

On May 2, 2014, at 9:58 AM, Geert Janssens gjanss...@code.gnucash.org wrote: Updatedvia https://github.com/Gnucash/gnucash/commit/ca480862 (commit) from https://github.com/Gnucash/gnucash/commit/08c59b58 (commit) commit ca48086287045c0af08b0dde62ce121e00a8e0c0 Author:

  1   2   3   4   >