Idea/rfc: planner / bug tool / code map
application should somehow be aware of those annotations for some useful purpose. Ever goof with Visio hyperlinking? An almost WikiLike link-and-click-ability between the views is what I'm looking for--- perhaps it should be free-form and even user-extensible, though some structure should be available embodied in the organization of the tickets, their attachments, and meta-data... Mechanism, not Policy... offer a few policies? Find patterns, groupings, and other features that emerge from the information using some sort of advanced AI or employee-written annotations and Dublin core? But not just textual annotations, perhaps, but relationships between objects in different applications... I want it to be as natural as drawing a diagram in Dia or what have you, and to link things like you can link the bars in the gantt chart of Planner. When I make a transaction in GnuCash (QOF), I want it to be able to trigger work-flow events in other components of the system. To select and draw the objects together using GUI gestures then explain what they are via a diagramming / text editor with WikiLinks would be amazingly nifty. To be able to program inter-application collaborations like that... I mean, link them visually and then describe the work-flow to it in some way, to create arbitrary constellations of intercommunicating applications. WiKid --- sort of the LabView of Gnome ERP, POS, BTS. All of the meta info about documents and annotations made on files from within Anjuta, messages, events, person records in Evolution, or transactions, lots, or accounts and what have you in GnuCash... -- enough information is available to restore relevant state-environment for sub-session after click of WikiLink to some object's view... beagle sniffing a Dublin Core? (annotation stored off-to-the-side, overlaying the real file contents, perhaps; n-way merge of annotations made by any of several developers or sales people?)... should be able to contain ClickLinks from code to BTS ticket view (in Evolution) and back again. Wow, this is insane! It will need a hyper-visor! We're consing now. What if we all pulled our WikiPedia through the same proxy, and it had annotation overlay capability plus a rating and referral system so that we can rate page views to see what students are reading about (only on specific URL sub-trees; WikiMedia etc) and to make it so you can easily direct someone to a Wiki page... Ok, so WikiMedia, or this Anjuta / Evolution / GnuCash / GnomeAnything+X can all click-link and hook up like WikiWare, then we document it, GPL it, and sell it. GMTA/YTMAWBK -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnc-backend-file.c: ERR_BACKEND_PERM too unspecific
On Mon, 2005-12-05 at 17:11 -0500, Derek Atkins wrote: Quoting Tim Wunder [EMAIL PROTECTED]: As I understand the process, gnucash renames the existing file, then creates a new file of the same name, then chowns it to whatever the permissions of the original file was. This seems really odd to me. chowns it to whatever owner and group, and chmod to set the permission mode. It's not odd at all. LOTS of programs do this. Emacs does this, for example. It will rename() the old file to the tilde-file, and then create the new file and write your new data to it. Then it reverts the file permissions to the original version. Emacs has a setting for 'backup by copying'. This is useful if you need to edit files that have more than one directory entry, or hard link, and you _do_ _not_ want the hard-link broken by edit/save. On the Linux file system, the files data location, size, ownership and permissions are specified by it's inode (See: http://en.wikipedia.org/wiki/Inode). The directory entries specify the file name and which inode contains the file information. More than one directory entry can point to a particular inode, and the inode contains a link count which tells how many directory entries point to that file. The unlink() (man unlink) system call removes a directory entry and decrements the link count in the inode. When it reaches zero, the blocks consumed by that file are freed for reuse by the file system. When a file is opened (man open) the link count is incremented, and when it's closed (man close) the link count is decremented. That is why you can open a file, unlink it, and keep using it, even though there is no longer a directory entry referring to it. When the invisible file is closed, its blocks will be released. If you use the rename() (man rename, and man mv) system call, it changes the file name in the directory entry. If you then open a new file using the original file's old name, the operating system creates a brand new inode for that file. Thus, the old name no longer points to the same file that other directory entries still point to, aka, hard links to that file are broken. (Symbolic links to that file are not broken, since they point to the file by _name_, rather than by _inode_.) In my experience, hard links are not used very often, except in cases where you actually do want to break the link if you change the file in one location. Perhaps you have a tree of source code, and you then make a tree of hard links to it. The new tree won't take up more space, since the directory entries point to the same inodes as the ones in the original tree. If you want to edit a file in the new tree without affecting the original file, you must rename the file, then make a copy of it under the original name, and edit that. If you want the edit to show up in both places, you must ensure that Emacs is set to 'backup by copying' mode. (What does 'vim' do here?) Since the ownership, permissions and POSIX ACL attributes (man acl) are all associated with the inode rather than the directory entry, when you rename the old file to a new name then open a new file under the old name, you must then set the ownership and permissions of the newly created inode. In the POSIX API, that is done with separate system calls --- it is not part of open(). Since the only system call guaranteed to be atomic over NFS is rename(), if there are concurrent file access issues, it may be that special care must be taken to ensure that two processes on separate computers do not race for access to the file. You can read about that by researching Debian Policy regarding mail spool file locking on NFS. ;-) If there are security issues, like a race to access and open this new file before it's permissions are set, then the file should be kept in a secure sub-directory where only the appropriate users may access any files created there. Also see: man ln, man 2 stat Why is a new data file created at all? Why isn't the original data file simply copied (like a cp -a) to the backup file. cp is a command-line utility. There is no cp API function. You may like to get a copy of the GNU Shellutils source, and have a look at what 'cp' actually does. Another one to look at is the 'cp' in Busybox; it's a little simpler, but does basically the same thing. Derek's suggestion to not chown at all and forego the group setting completely and assume the user has a proper setgid setting on the directory seems reasonable to me. There may be cases where that assumption is not correct, I think. For the general case, and to err on the side of caution, it's probably best to set all of owner, group, mode, and ACL attributes. If ACL is not being dealt with by the application, and the administrator wants to use them, then I suppose they can be set for the directory...? -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org
Re: [PATCH] Fixes sentinel warnings on GCC4
On Tue, 2005-12-06 at 00:55 -0500, Chris Shoemaker wrote: In the gcc ML thread where the -Wstrict-null-sentinel warning was added, it was claimed that at least some versions of HPUX and Solaris 2.8 on 64-bit machines #define NULL 0. Then those system headers are wrong, not the code that uses NULL as a (void *)0. I wonder if there's a way to use 'typeof()' to get a readout as to whether it needs to be redefined properly? I don't get how C++ can get away with calling NULL == 0 rather than == (void *)0. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] Policy change for ChangeLog
I was taught to maintain ChangeLog as I edit. In Emacs, you type: C-x 4 a ... to add a ChangeLog entry. (Will a vim user please explain the process used? Does it automatically insert a ChangeLog entry template with the ISO-8601 date, file name, and function?) So for each change you make, you make a note of it, as you go, so that later on, when you review the diff prior to commit, you have less work to do, and you won't have forgotten why you did something. It takes a certain amount of discipline to do this, but make it easier not to forget to make an entry. With pcl-cvs, it would take the ChangeLog and pull out the pieces pertaining to a set of files you are committing, to use for the commit log entry. The psvn interface should do that also, if it doesn't already. Again, I'm not a vim user, so someone familiar with that would have to explain the process. Do you use an external tool for working with svn? A Perl script could pull the ChangeLog parts out into a commit log you can edit prior to commit... Earlier, someone mentioned using ChangeLog for listing things like what's changed in the API, new features, deprecations, etc., but that's not what ChangeLog is for. That's what NEWS is for. IMO, trying to make an automatically generated ChangeLog from svn commit log entries is inviting laziness wrt writing readable and meaningful log entries that mention every significant modification. You are not supposed to commit after every little change as you go. You are supposed to get it all squared away, then commit a related set of changes as a unit. Sometimes it takes several days of work to get that all together, and so logging as you go becomes more important. It prevents you from forgetting to log a change. Reviewing a pile of diffs to see what you changed so you can write a log entry is tedious. If the changes are already logged, then the review of the diff is just a quick scan --- you don't have to totally parse every modification then. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Fixes sentinel warnings on GCC4
On Tue, 2005-12-06 at 16:07 -0500, Chris Shoemaker wrote: Yes, this *works*! IFF NULL expands to 0. But, it's not portable because NULL *may* expand to (void*)0. This is *exactly* why using NULL (or even 0) as a sentinel is not portable. Portable code *must* explicitly cast sentinels. Don't blame me - blame Ritchie. Remember: arguments to variadic functions are NOT in a pointer context. After reading what Stuart D. Gathman wrote in this thread, I'm thinking that it's not Ritchie's fault either. It's a matter of mapping the C language to the hardware and it's assembly language. I was going to respond that I think it's BS to have to cast the NULL pointer, but now I see why it is necessary. It does have to do with context. If it's a pointer to a type where the pointer is 8 bits, and the stdarg code expects a (void *)0 that turns out to be 32 bits... the input argument is not automatically extended to 32 bits because the compiler cannot see the need for it unless you tell it with the cast or an assignment to a variable with a larger sized pointer type. We probably should not even assume that (equalp NULL 0). Maybe it's 0xff? In either case, the explicit cast to (void *) will port, right? Q: Why can't the stdarg.h code perform that typecast internally so that client code does not have to? And... from info libc, on variadic functions: 88 Since the prototype doesn't specify types for optional arguments, in a call to a variadic function the default argument promotions are performed on the optional argument values. This means the objects of type char or short int (whether signed or not) are promoted to either int or unsigned int, as appropriate; and that objects of type float are promoted to type double. So, if the caller passes a char as an optional argument, it is promoted to an int, and the function can access it with va_arg (ap, int). Conversion of the required arguments is controlled by the function prototype in the usual way: the argument expression is converted to the declared argument type as if it were being assigned to a variable of that type. 88 It says that this default argument promotions feature is required by ISO C. So shouldn't a small pointer type be promoted automatically to a larger pointer type, by the compiler? (Of course it cannot happen at run-time in C.) What settles it once and for all is this, from info libc, The NULL Pointer Constant: 88 If you use the null pointer constant as a function argument, then for complete portability you should make sure that the function has a prototype declaration. Otherwise, if the target machine has two different pointer representations, the compiler won't know which representation to use for that argument. You can avoid the problem by explicitly casting the constant to the proper pointer type, but we recommend instead adding a prototype for the function you are calling. 88 -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
64-bit issues, login accounts on an Athlon-64 available.
On Sat, 2005-12-03 at 11:55 -0500, Josh Sled wrote: Thanks to the efforts of Neil and Derek, the goffice-update branch is pretty robust at this point, except for issues on 64-bit platforms. However, since I understand those issues already appear on HEAD, I'm going to merge the branch back in this weekend sometime ... later today or tomorrow. Shout if that's a problem. What exactly are the 64-bit issues? I have an Athlon-64 running Ubuntu Breezy Badger. I'd like to help. Would anyone like an account on it? I'm on a fast connection, at Portland State University. If you tell me who you are, and send your login ID and SSH public key, I'll create an account you can use to work on GnuCash 64-bit issues. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: MediaWiki instead of Trac Wiki?
On Tue, 2005-11-29 at 09:55 -0500, Josh Sled wrote: It sounds like the Trac-provided wiki isn't really working out, and MediaWiki is (relateively) easy to setup, full-featured and well-known. I say we try it out, and dereference gnomesupport.org. If you search on the Firefox extension download site, you'll find two really cool tools for working with Wiki pages. One is the Wikipedia tool bar, and the other is 'save text area' which lets you save a text edit area to a file, and load it's contents from a file. I'm thinking of a hack where a daemon or an emacs sub processes watches for a file to appear, and when it does, calls on 'gnuclient' to open it for editting. When the file is saved back, somehow the browser should notice and load it again. :-) I don't know how to do the second part. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Trac ?
I wonder if this would be useful now that the GnuCash project is using Subversion? http://projects.edgewall.com/trac/ -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [patch] Fix compiler warnings on 64 bit processor.
In reading the message that came back from the list, I'm seeing some things I missed and also that maybe not all of the things I changed are in the diff for some reason. Please discard that, unless you've already applied it, and I'll resubmit. If you already applied it, don't sweat it, obviously it is a minor change and I can re-sync and fix the rest. Thank you for switching to Subversion. I like it better than CVS mainly due to the speed improvements due to it not needing a network connection for everything. It's much nicer on a laptop. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[patch] Fix compiler warnings on 64 bit processor.
Here's a ChangeLog entry and diff against today's CVS that suppresses
the compiler warnings wrt casting from gpointer to int when a pointer is
64 bits and an int is only 32. See the Glib manual, under type
conversion macros for documentation of the macros used in this patch.
--
Karl Hegbloom [EMAIL PROTECTED]
2005-11-01 Karl Hegbloom [EMAIL PROTECTED]
* src/backend/postgres/upgrade.c (get_iguid_cb): Use glib macros
for type conversions to suppress compiler warnings on amd64.
(put_iguid_in_tables): ditto
* src/backend/postgres/price.c (commodity_mark_cb): Use glib
macros for type conversions to suppress compiler warnings on
amd64.
* src/backend/postgres/base-autogen.c (pgendAccountCompareVersion):
Use glib macros for type conversions to suppress compiler
warnings on amd64.
(pgendTransactionCompareVersion): ditto
(pgendPriceCompareVersion): ditto
(pgendAccountGetDeletedVersion): ditto
(pgendBookGetDeletedVersion): ditto
(pgendTransactionGetDeletedVersion): ditto
(pgendPriceGetDeletedVersion): ditto
* src/backend/postgres/kvp-sql.c (ival_cb): Use glib macros for
type conversions to suppress compiler warnings on amd64.
* src/backend/postgres/putil.h (COMP_INT64): Cast fun to long long
int to suppress compiler warning on amd64.
Index: src/backend/postgres/kvp-sql.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/backend/postgres/kvp-sql.c,v
retrieving revision 1.13.2.5
diff -u -r1.13.2.5 kvp-sql.c
--- src/backend/postgres/kvp-sql.c 13 Oct 2005 12:28:06 - 1.13.2.5
+++ src/backend/postgres/kvp-sql.c 1 Nov 2005 20:43:34 -
@@ -121,7 +121,7 @@
ival_cb (PGBackend *be, PGresult *result, int j, gpointer data)
{
int ival = atoi (DB_GET_VAL (ipath, 0));
- return (gpointer) ival;
+ return GINT_TO_POINTER(ival);
}
@@ -143,7 +143,7 @@
p = stpcpy (p, ';);
SEND_QUERY (be,be-buff, 0);
- ival = (int) pgendGetResults (be, ival_cb, (gpointer) 0);
+ ival = GPOINTER_TO_INT(pgendGetResults (be, ival_cb, (gpointer) 0));
if (ival) return ival;
/* Else, this guid has never been stored before.
Index: src/backend/postgres/price.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/backend/postgres/price.c,v
retrieving revision 1.17.4.8
diff -u -r1.17.4.8 price.c
--- src/backend/postgres/price.c 20 Oct 2005 14:48:11 - 1.17.4.8
+++ src/backend/postgres/price.c 1 Nov 2005 20:43:34 -
@@ -197,7 +197,7 @@
static gboolean
commodity_mark_cb (gnc_commodity *cm, gpointer user_data)
{
- gint32 v = ((gint32) user_data) 0x;
+ gint32 v = ((gint32) GPOINTER_TO_INT(user_data)) 0x;
gnc_commodity_set_mark (cm, (gint16) v);
return TRUE;
}
Index: src/backend/postgres/putil.h
===
RCS file: /home/cvs/cvsroot/gnucash/src/backend/postgres/putil.h,v
retrieving revision 1.10.4.6
diff -u -r1.10.4.6 putil.h
--- src/backend/postgres/putil.h 20 Oct 2005 14:48:11 - 1.10.4.6
+++ src/backend/postgres/putil.h 1 Nov 2005 20:43:34 -
@@ -318,7 +318,7 @@
#define COMP_INT64(sqlname,fun,ndiffs) { \
if (strtoll (DB_GET_VAL(sqlname,0), NULL, 0) != fun) { \
PINFO(mis-match: %s sql='%s', eng='%lld', sqlname, \
- DB_GET_VAL (sqlname,0), fun); \
+ DB_GET_VAL (sqlname,0), (long long int) fun); \
ndiffs++; \
}\
}
Index: src/backend/postgres/upgrade.c
===
RCS file: /home/cvs/cvsroot/gnucash/src/backend/postgres/upgrade.c,v
retrieving revision 1.12.4.3
diff -u -r1.12.4.3 upgrade.c
--- src/backend/postgres/upgrade.c 1 Oct 2005 22:42:52 - 1.12.4.3
+++ src/backend/postgres/upgrade.c 1 Nov 2005 20:43:35 -
@@ -126,7 +126,7 @@
get_iguid_cb (PGBackend *be, PGresult *result, int j, gpointer data)
{
int fin = atoi(DB_GET_VAL (iguid, j));
- return (gpointer) fin;
+ return GINT_TO_POINTER(fin);
}
@@ -150,7 +150,7 @@
p = SELECT iguid FROM gncGUIDCache ORDER BY iguid DESC LIMIT 1;;
SEND_QUERY (be,p, );
- iguid = (guint32) pgendGetResults (be, get_iguid_cb, 0);
+ iguid = (guint32) GPOINTER_TO_UINT(pgendGetResults (be, get_iguid_cb, 0));
iguid ++;
sprintf(buff, CREATE SEQUENCE gnc_iguid_seq START %d;, iguid);
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS, Oct 30, Build errors on x86_64
On Mon, 2005-10-31 at 09:00 -0500, Josh Sled wrote: On Sun, 2005-10-30 at 23:36 -0800, Karl Hegbloom wrote: I won't have time to try and fix these; I'm way behind on my Mathematics homework and should really be working on that instead... Hope this helps. Do yous have an AMD64 to test compile on? Only vicariously through souls like yourself... :) ...but the issue here isn't x86_64 specific: the GSF_CLASS_FULL macro errors in the lib/goffice/ code are due to a macro signature difference in =libgsf-1.12.1 and =libgsf-1.12.2. Neil Williams had put in a check re: libgoffice / libgsf to work around this on his Debian Unstable box. What system-installed versions of libgsf and libgoffice do you have? libgsf-1-dev 1.12.3-3ubuntu3 libgsf-gnome-1-dev 1.12.3-3ubuntu3 libgoffice-1-dev was not installed at all. I just installed version 0.0.4-1, also from Ubuntu. I don't know how it was able to finish 'configure' and compile as much as it did if it requires libgoffice. Perhaps a 'configure.in' check for that is not present? It probably would fail to link without it. -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
CVS, Oct 30, Build errors on x86_64
I won't have time to try and fix these; I'm way behind on my Mathematics homework and should really be working on that instead... Hope this helps. Do yous have an AMD64 to test compile on? -- Karl Hegbloom [EMAIL PROTECTED] error.txt.gz Description: GNU Zip compressed data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature Request: triggers or variable auto-transactions
On Fri, 2005-08-19 at 16:24 -0400, Josh Sled wrote: On Fri, 2005-08-19 at 12:48 -0700, Karl Hegbloom wrote: Perhaps a special feature for posting a DDA could schedule the repayment just as the bank does, to have it happen right after posting the paycheck? A dialog could take the initial information, like the amount Could you simply create both transactions when you post the DDA? Since the paychecks probably come on a set schedule, you can always figure out when the next one would be, and you can post-date the repayment transaction to that date. But if I enter the transaction now, even if it is post-dated, won't that affect the displayed account balance? That would make it difficult to monitor the present balance, and thus greatly increase the chances of an overdraft, the very thing the DDA is meant to avoid. It's a lot cheaper to pay the service charge on the DDA than for an overdraft. transaction. Q: Can this be done using scheme and current GC features? Certainly, anything can be done if you're willing to write it. :) It would probably be a bit more involved than simply re-combining existing features with scheme, but not too much. I will need to spend a lot of time learning about the internals of GnuCash then. It cannot be possible otherwise, that's just the way it is. The question then is, should I begin with CVS GnuCash for GTK2, or with presently released GnuCash? I think it will take some time for me to learn it since I've limited time available for that. When will the GTK2 version be releaseable? In thinking about this, it seems to me that a generalized mechanism for creating this sort of dialog would be very useful. If the widgets could Also useful is the idea of a palette of template transactions -- divorced from the scheduled transactions -- which can be instantiated by the user. They would be slightly different from the whole-transaction-autocomplete that we currently have, mostly by being first-class participants, and being available for explicit creation. E.g., here, you could have a Take DDAdvance template that contained both the advance and repayment transactions, and you could create them as a unit. Maybe I could simply create the scheduled transaction, and schedule it to happen only once. That seems easiest and now that it has occured to me, almost obvious. [...] I've been musing about writing that for a while, but there are many other higher-priority things for me right now. If this is your itch, then scratch away! Well, it's summer vacation, one month to go before fall term begins. Right now my itch has more to do with my social life and recreation. ;-) -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: payroll
On Tue, 2005-05-24 at 06:50 -0700, Brian wrote: For Canada: # of pay periods/yr. ---Incomes Hours Rate basic wage several extras, such as bonuses for extra trade tickets. [ ... ] Reminds me of scheduled transactions. Could it be implemented in terms of those, with a template transaction and function calls to retrieve the correct values? -- Karl Hegbloom [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
