Re: Gnucash c++
On Wed, 13 Aug 2014 17:20:51 -0700 John Ralls jra...@ceridwen.us wrote: Then I can make a C++ class and move the functionality into it one function at a time, converting the C function to a wrapper with C linkage. I can test that against the existing C tests, add C++ tests, and move on to the next function. The rest of GnuCash can't tell anything's changed; new work now has two versions of the API to use depending on whether it's completely new or a modification of existing. If it comes time to start the release cycle and the conversion isn't complete, we can ship it as-is because nothing's broken. It sounds good *in theory*, but I'm not so sure you're going to rewrite engine and get rid of cruft this way. Still, as a happy GC user, I wish you all success. For the sake of experiment I briefly tried KMyMoney anticipating that (maybe) KDE could fill the need, but *very* quickly I was back to xfce/i3/Gnucash. :-) Sincerely, Gour -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Tue, 5 Aug 2014 11:04:00 -0700
John Ralls jra...@ceridwen.us wrote:
Hello all,
What is the motivation for compiling everything as C++ if it's still
really C and you have to wrap everything in extern C {} to get it
to link, especially in gnome and register directories, which can't be
converted to C++?
when I visited #gnucash the other day I heard about the plan to (slowly) move
to C++.
Although I'm aware that I do not have 'currency' to influence the switch, I'd
just like to give my 0.02hrk (1$ ~ 5.8hrk) and propose to (just) consider using
Go language instead.
Here is nice article http://talks.golang.org/2012/splash.article explaining
about the reason to conceive the language which is solving some of the
performance problems encounted when building large C++ apps.
Moreover, it is meant to be easily approachable for the developers being
familiar with C (which is not really the case with C++) and we could say that
Go is kind of 'modern C'.
Not wanting to go deeper into any sort of argumentation being more than happy
that Gnucash is givne to me for free this is just attempt to my side in order
to provide some feedback to make GC even better developer-wise.
Sincerely,
Gour
--
The work of a man who is unattached to the modes of material
nature and who is fully situated in transcendental knowledge
merges entirely into transcendence.
http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins warl...@mit.edu wrote: Ummm.. No. OK. The benefit of C - C++ is that except for a few minor issues with keywords you can *generally* compile C code using the C++ compiler and it will *just work*. That's clear. The same cannot be said for Go or any other language. Btw, Go team converts Go compiler from C to Go. ;) Please read the FAQ entry on Why don't you (re)write GnuCash in your favorite language at http://wiki.gnucash.org/wiki/FAQ Well, being in #gnucash I got the feeling that there is plan to abandon glib, rewrite the engine and possibly even to consider Qt 'cause without glib, one is not tied so much to GTK any longer. Considering that C -- C++ (and taking advantage of it) might be more strange than C -- Go which is created to be picked easily by C devs, I did throw my suggestion. Otoh, I believe that C -- C++ is not to be done in order to just increase build time.* :-) * Rob Bike from the Go team says that long build times (~45mins) for C++ * projects was the time when Go was conceived. ;) I'm aware of FAQ entry, but was thinking that GC is on the verge of possible (partial) rewrite. All the best! Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposed feature requests on uservoice: Do we want them, or decline them?
On Mon, 06 May 2013 23:47:32 +0200 Christian Stimming christ...@cstimming.de wrote: But my point is that the uservoice feedback gives us a strong hint about the things that are really important to the users. Those are most likely different from what us developers considered important. I would love to see us taking the user's priorities seriously here. And by taking the user's needs seriously, we might also find that the implementation to meet this very needs can be chosen differently and maybe simpler than what we initially thought. I certainly agree with it...but, not being GC coder myself cannot complain much if something is not implemented. In those cases where the real user needs can be fulfilled by relatively simple implementations, I'd like to see those implementations be added to gnucash. For this reason I think all 10 of the above are valid feature requests. We should try to get them implemented. Maybe not in the full-blown glory that some of the comments there were hoping for, but some parts of the features can be done and should be done. I didn't put my votes on that list, but having needs for some more business- related features which could help freelancers, let me mention two items which *might* be helpful and not too hard to implement: 1) Proforma (quotation) invoices http://gnucash.uservoice.com/suggestions/1758239 This could be very useful addition eliminating the need to use 3rd party (mostly web-based) PHP apps to do it 'cause GC is already doing the major part. 2) user-generated custom reports http://gnucash.uservoice.com/suggestions/2381349 Ability to make it easier for end-user to tweak/customize reports, mostly for invoices has been a topic discussed quite often. I know there is e-guile, but it seems it never expanded much. Otoh, there are some attempts to solve it (it via Python bindings), and I must say that, yes, I consider python more user-friendly for end-user... The two possible solutions which may need some more work are: a) https://github.com/n1ywb/jeffs-gnucash-utils b) https://github.com/loftx/gnucash-rest so I wonder if there is some interest to take those ideas and develop them further to bring some more report customization capabilities to GC for 2.6? Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GSoC 2012 final evaluation passed
On Thu, 30 Aug 2012 13:55:47 +0200 Ngewi Fet nge...@gmail.com wrote: Hello everyone, The final evaluation for GSoC 2012 is out and I glad to say that I passed it. Thanks for all the support I received. Congrats!! I would like to continue to maintain Gnucash for Android going forward. Is there anything I need to know or do (like processes to be adhered to etc)? Excuse me for jumping late into the train, but being user of Droid phone myself, I'm aware there are several apps available which can import/export QIF data, so I wonder what was the primary rationale for your project? 1. Up till now, I have just used the GitHub tracker for issues. Do I have to migrate it somewhere else? No need. 2. Secondly, code hosting. The code is currently hosted on Github and I am ok with it. But from following the other (Git migration) mails on the list, it seems there is not much love for GitHub. I tried to avoid Git for long time, but using it now happily. Github is also OK and do not believe that for public hosting bitbucket, gitorious or something has any advantage. Sincerely, Gour -- Abandoning all attachment to the results of his activities, ever satisfied and independent, he performs no fruitive action, although engaged in all kinds of undertakings. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GSoC 2012 final evaluation passed
On Thu, 30 Aug 2012 15:05:25 +0200 Ngewi Fet nge...@gmail.com wrote: Well Gnucash for Android is not about importing and exporting QIF data. In fact, Gnucash for Android does not support QIF at all, it uses OFX. I know. It is more of an expense tracker for now (humble beginnings) and will grow in functionality with time. The question is why the expense tracker for Android was done as GSoC project in the Gnucash slot or what is its specific importance for Gnucash over. e.g. Expense Register? Just curious... Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
python bindings py3k
Hello! I'd like to try Jeff's (https://github.com/n1ywb/jeffs-gnucash-utils) utility which enables one to tweak GC invoice reports by changing invoice template based on HTML/CSS and Mako language which is, in my case, definitely much easier than fiddling with Scheme. However, on my distro (Archlinux) GC is built without python bindings enabled, but I've problem building it 'cause Archlinux uses python3 as default one. Changing it to python2 as default, would make package manager utilities broken. Otoh, Jeff's invoice.py script requires just using one print() instead of print (based on the output from 2to3), but bindings are not python-3 ready. Considering that GC's configure does not have something like: --with-python=/path/ option, I wonder if you can suggest what would be the least intrusive way to pass path to python2 as default python to be used while building? Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: python bindings py3k
On Thu, 23 Aug 2012 11:14:38 +0200
Gour g...@atmarama.net wrote:
Considering that GC's configure does not have something like:
--with-python=/path/
option, I wonder if you can suggest what would be the least intrusive
way to pass path to python2 as default python to be used while
building?
Huh...I passed PYTHON=/path-to-2.7 in a build's wrong function. :-(
Now I was able to build GC wiht python bindings against python-2.7, but
here is what I get:
gour@atmarama ~ $ python2
Python 2.7.3 (default, Apr 24 2012, 00:00:54)
[GCC 4.7.0 20120414 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
import gnucash
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/site-packages/gnucash/__init__.py, line 6, in
module
from gnucash_core import *
File /usr/lib/python2.7/site-packages/gnucash/gnucash_core.py, line 31, in
module
import gnucash_core_c
File /usr/lib/python2.7/site-packages/gnucash/gnucash_core_c.py, line 25,
in module
_gnucash_core_c = swig_import_helper()
File /usr/lib/python2.7/site-packages/gnucash/gnucash_core_c.py, line 21,
in swig_import_helper
_mod = imp.load_module('_gnucash_core_c', fp, pathname, description)
ImportError: /usr/lib/python2.7/site-packages/gnucash/_gnucash_core_c.so:
undefined symbol: _Py_FalseStruct
Any hint?
Sincerely,
Gour
--
One who restrains the senses of action but whose mind dwells on
sense objects certainly deludes himself and is called a pretender.
http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash 2.4.10 released
On Mon, 06 Feb 2012 22:16:44 +0100 Christian Stimming christ...@cstimming.de wrote: GnuCash 2.4.10 released Congratulations to all devs for another release! We also wonder if this is last one in 2.4.x series before going to more substantional changes? Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash reports using php and mysql
On Fri, 30 Dec 2011 03:00:01 + (UTC) Hendrik Boom hend...@topoi.pooq.com wrote: I still intend to get back to this. I still thiink that the primary problem with the report-writing tools is not that they are unusable, but that no one knows how to use them. Thank you very much. It would be, imho, great ROI allowing (potential) GC users to fully embrace GC. At least, to me it seems much nicer to use GC for everything than to have to fiddle with PHP Web invoicing apps just to easily tweak/create decent invoice. Sincerely, Gour -- In the material world, one who is unaffected by whatever good or evil he may obtain, neither praising it nor despising it, is firmly fixed in perfect knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release -- SCheme
On Sat, 31 Dec 2011 18:17:13 -0500 Derek Atkins de...@ihtfp.com wrote: Is it really worth our time to find another scheme implementation and swap everything over to it? I would think that it would be better to write a report infrastructure in a language that would seem more popular (python), build in the infrastructure, and then send out a call for report writers to convert the existing scheme reports over to the new language. +1 Very well put together. ;) btw, wishing happy prosperous New Year to everybody to make GC even better in 2012! Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release -- SCheme
On Sat, 31 Dec 2011 18:31:34 -0500
Donald Allen donaldcal...@gmail.com wrote:
If there is agreement among the developers that this is an attractive
alternative to Guile, I would advise doing some prototyping to
evaluate the performance of Python for report generation.
I believe you ('cause I did not dive into GC yet) that performance might
be problem, but in my case customizability is much bigger one, so we're
ready to trade it for performance.
Otoh, it's not we would not believe with Python, but just wonder if you
thought about Lua which shoould go nicely along with C and it is very
simple language to learn for end user wanting to customize reports?
Sincerely,
Gour
--
A person who has given up all desires for sense gratification,
who lives free from desires, who has given up all sense of
proprietorship and is devoid of false ego — he alone can
attain real peace.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release -- SCheme
On Sat, 31 Dec 2011 18:36:28 -0500 Mike Alexander m...@umich.edu wrote: Python is popular now, but will it be in 10 years? I've seen lots of languages come and go. That's true, but I bet it will be more popular than Scheme for sure. Moreover, we can speculate what will happen with GTK+ in 10 years, but let's make GC more approachable *today*. ;) Sincerely, Gour -- A self-realized man has no purpose to fulfill in the discharge of his prescribed duties, nor has he any reason not to perform such work. Nor has he any need to depend on any other living being. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash reports using php and mysql
On Wed, 21 Dec 2011 10:10:39 -0500 Donald Allen donaldcal...@gmail.com wrote: My motivation was the same as yours -- I could not get what I wanted from the built-in reports and I felt that the cost of trying to learn to work within gnucash (in spite of the fact that I am a *very* experienced Scheme programmer) was higher than the approach I took. Huh...this does not sound optimistic for potential GC users wanting to customize their invoices/reports... Is there any plan to improve reporting system in 2.6 or we cannot expect anything before 3.0? I'd suggest having a look at an interesting thread, Scripting API, on gnucash-devel started by Hendrik Boom in November. It discusses similar issues and the subject of the fairly new python bindings capability comes up, something I have not investigated myself (only because I already have something that serves my purpose, developed before the python bindings capability became available) but is probably worth looking at if you are actively developing reports for yourself. Is it now possible to use those Python bindings to more easily create/tweak reports/invocies? Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.4 and sqlite...
On Sun, 2 Jan 2011 11:47:23 -0800 J. == J. Alex Aycinena wrote: J. Also as a constructive comment, please realize that it is impossible J. for the developers to test every possible combination of environments J. and libraries that is represented in the user base. Well, here we are not talking about many 'possible combinations'... libdbi-0.8.2 which works is almost 4 yrs old, while the 'newer' 0.8.3 which is broken is almost 3yrs old, so it's not hard to anticipate that not all Linux distros are shipping with 'epic' 0.8.2. /me is running x86_64 Arch with 0.8.3 Moreover, as John Ralls wrote: The bug affects only 32-bit x86 builds with gcc 4.3 or later. It was detected during 2.3 testing on Fedora and resolved with the Fedora maintainers..., my question is why it was not tested more at that time? Finally, even, today, there is no warning on web site saying that using sqlite3 back-end with libdbi-0.8.3 is broken?? J. interested parties that are not developers can certainly help with the J. development efforts is to participate in testing by downloading and J. exercising pre-release builds and reporting problems they find. For J. the project as a whole, there is probably too little of this. I agree...I did compile one of the 3.x series to check whether it works with sqlite, but couldn't test extensively not being familiar with Gnucash since I was/am evaluating some invoicing-only apps. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.4 and sqlite...
On Sat, 01 Jan 2011 14:48:20 -0500 John == John Gray g...@agora-net.com wrote: John Same here, rebuilding libdbd-sqlite3 didn't fix the problem, and John libdbi isn't building. I just wonder how it could be that after so many 2.3.x releases, sqlite back-end was so poorly tested that there is now release with such bug? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.4 and sqlite...
On Sat, 1 Jan 2011 16:17:06 -0500 Derek == wrote: Derek Because it's not *our* bug, it's a bug in libdbi, I'm aware it's not Gnucash bug... Derek and it's a bug Derek that only affects certain builds of libdbi, but I didn't know about the latter. Derek I don't know enough about the bug to tell you whether it's Derek something that we can easily detect at runtime. But it's Derek certainly the case that you can build GnuCash against the Derek working version and then upgrade the library to the broken Derek version and GnuCash will stop working. Similarly, if you build Derek GnuCash against the broken version of libdbi and then replace it Derek with a working version then it should start working again. This is something I do not understand fully...Based on what I see at libdbi site, it looks that it's not in such a rapid development producing new releases so often, iow the site says: libdbi-0.8.4 2010-09-01 libdbi-0.8.3 2008-02-06 which means there are two releases in last (almost) three years. Now, which version of the libdbi is broken? Derek Again, this is *not* a bug in GnuCash, but a bug where libdbi Derek does not return valid data when compiled with fast math. That's clear. otoh, based on the links in this thread, it seems that the bug is present in 0.8.3 version which is not the newest one. I'll try to build gnucash on my Archlinux system, but for now I can only say that libdbi is built with: ./configure --prefix=/usr so I do not know what does it mean in regard to '-fast-math' option. Still (although I very much admire Gnucash and its devs), I believe that it could be that not-too-many devs were testing with Sqlite back-end which is important considering that SQL storage is some of the 'hot stuff' proudly announced as 'major changes' in 2.4.0. Please, take my post just as constructive criticism meant to help improve Gnucash. (Finally, I'm the one wanting to use it.) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
customizing reports in Python (was Re: [PATCH] invoice creation with python-bindings and value of stability patch)
On Fri, 18 Jun 2010 12:31:53 -0500 Mark == Mark Jenkins m...@parit.ca wrote: Mark Hi to all again, Hello Mark, Mark Attached is patch, Mark python_bindings_business_invoice_support_and_examples.patch that Mark enhances the python bindings to include support for creating, Mark posting, and paying invoices. I've just posted question to gnucash-user list about the possibility to use python-bindings for tweaking/creating Gnucash invoices/reports led by Derek's statement that: You could, however, write a standalone python report. Or indeed you could write any standalone python app to read or manipulate gnucash data. Considering there was a longish thread recently on gnucash-users (Report customization nightmare) it seems that not everybody is utterly happy to hack in Guile in order to customize reprots/invoices. Otoh, I believe that using Python and some of its templating languages might provide more comfortable solution for end-users/non-programmers/designers to tweak Gnucash reports *externally* . The question is how much infrastructure is provided by python-bindings and what is missing so that Gnucash can have nice customization features via python some templating language? Sincerely, Gour p.s. Maybe there could be interest for some bounty or to fund this development which would certainly make Gnucashe much more appealing to wider audience? -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: We need to prevent multi-user access to the SQL backend
On Thu, 20 May 2010 12:55:01 -0400 Derek == Derek Atkins warl...@mit.edu wrote: Derek IMNSHO, adding MySQL and PG support was a mistake; we should Derek have stuck with just SQLite. +1 Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
