From: John R. <jr...@ce...> - 2014-03-11 04:04:17
|
Jérôme, As you know, I've been working on the 7516 and 7238 encoding problem on Windows. I think I've got it figured out, but it's going to be a fairly significant change-set. I think I can get the work done by this weekend, but I'd like to get some others to test it before we release 4.0.4, so I'd appreciate the indulgence of holding off the release until late next week . Regards, John Ralls |
From: jerome <rom...@ya...> - 2014-03-11 19:51:29
|
John, I thought on making an annoncement for a '4.0.4' release on the end of the week (deadline). Agreed, by looking at some issues, we still need to wait. So, no problem. Note, running "$ python setup.py test" (other post on mailing list), there is maybe modules with minor issues (unit tests). If tests are correct, then it could be great to try to fix them before next release? I am also monitoring some issues (#7510), and some 'gi/gtk/glib/ubuntu' issues (#7501 #7502). https://lists.ubuntu.com/archives/ubuntu-gnome/2014-February/001503.html https://wiki.ubuntu.com/UbuntuGNOME/SubTeams We could release a '3.4.8', some days after '4.0.4'? Current changes and fixes since '4.0.3': https://www.gramps-project.org/wiki/index.php?title=Template:Releases/4.0.4 https://www.gramps-project.org/wiki/index.php?title=Template_talk:Releases/4.0.4 Regards, Jérôme -------------------------------------------- En date de : Mar 11.3.14, John Ralls <jr...@ce...> a écrit : Objet: 4.0.4 Release À: "Jerome" <rom...@ya...> Cc: "Gramps Development List" <gra...@li...> Date: Mardi 11 mars 2014, 5h04 Jérôme, As you know, I've been working on the 7516 and 7238 encoding problem on Windows. I think I've got it figured out, but it's going to be a fairly significant change-set. I think I can get the work done by this weekend, but I'd like to get some others to test it before we release 4.0.4, so I'd appreciate the indulgence of holding off the release until late next week . Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-03-17 19:08:01
|
Devs, I contacted translators for next releases. We may say that we are in the "string freeze"! Maybe we should release '4.0.4', first. Then '3.4.8' some days later. Looking at '4.0.4' roadmap[1], we should be able to quickly commit patch for: * 7501: Notes always say "no data exists for note" when saving * 7347: Pedigreeview problem with "on mouse over" event (with a solution included) after a review. Maybe some bug reports, need more investigations: * 7407: Search Bar ignores non-ASCII characters in lowercase on people views * 6742: Death date does not update in listview after change * 7093: Error after creating Pedigree Chart Report * 7464: Given Name Cloud Gramplet splits up given names into words (broken up by spaces) Some are related to dependencies or OS: * 7238: Media view does not show "Date"-column and no horizontal scroll bar (gtk > 3.6) * 7268: GUI freeze and 100% CPU load after adding multiple Children to a newly created family * 7024: view not refreshed upon deletion of Place record * 7502: Person Editor has black background * 7258: transcode os.path.join args from the fs enc to prevent a crash * 7161: Collation in Linux without ICU is broken I am monitoring: * 7539: Some gramps windows appear either too small or too big * 7532: Cannot drag & drop textual value via clipboard => issues on '3.4.8' roadmap[2]. * 7481: can't add existing citation via filter etc ... So, what about to release '4.0.4' on 24th march 2014? [1] https://gramps-project.org/bugs/roadmap_page.php?version_id=47 [2] https://gramps-project.org/bugs/roadmap_page.php?version_id=46 regards, Jérôme > -------------------------------------------- > En date de : Mar 11.3.14, John Ralls <jr...@ce...> a écrit : > > Objet: 4.0.4 Release > À: "Jerome" <rom...@ya...> > Cc: "Gramps Development List" <gra...@li...> > Date: Mardi 11 mars 2014, 5h04 > > Jérôme, > > As you know, I've been working on the 7516 and 7238 encoding > problem on Windows. I think I've got it figured out, but > it's going to be a fairly significant change-set. I think I > can get the work done by this weekend, but I'd like to get > some others to test it before we release 4.0.4, so I'd > appreciate the indulgence of holding off the release until > late next week . > > Regards, > John Ralls > |
From: John R. <jr...@ce...> - 2014-03-18 03:00:36
|
On Mar 17, 2014, at 12:06 PM, Jerome <rom...@ya...> wrote: > Devs, > > > I contacted translators for next releases. > We may say that we are in the "string freeze"! > > Maybe we should release '4.0.4', first. > Then '3.4.8' some days later. > > Looking at '4.0.4' roadmap[1], we should be able to quickly commit patch for: > > * 7501: Notes always say "no data exists for note" when saving > * 7347: Pedigreeview problem with "on mouse over" event (with a solution included) > > after a review. > > Maybe some bug reports, need more investigations: > > * 7407: Search Bar ignores non-ASCII characters in lowercase on people views > * 6742: Death date does not update in listview after change > * 7093: Error after creating Pedigree Chart Report > * 7464: Given Name Cloud Gramplet splits up given names into words (broken up by spaces) > > Some are related to dependencies or OS: > > * 7238: Media view does not show "Date"-column and no horizontal scroll bar (gtk > 3.6) > * 7268: GUI freeze and 100% CPU load after adding multiple Children to a newly created family > * 7024: view not refreshed upon deletion of Place record > * 7502: Person Editor has black background > * 7258: transcode os.path.join args from the fs enc to prevent a crash > * 7161: Collation in Linux without ICU is broken > > I am monitoring: > * 7539: Some gramps windows appear either too small or too big > * 7532: Cannot drag & drop textual value via clipboard > => issues on '3.4.8' roadmap[2]. > * 7481: can't add existing citation via filter > etc ... > > > So, what about to release '4.0.4' on 24th march 2014? > OK. I closed a couple of the collation bugs today, and I don't think the additional option on report menus for 6538 should go into 4.0.4, and maybe not into 4.0 at all, since they'd be something of a new feature. I had a bit of a breakthrough on 7258 today which fixes a big chunk of the DBEnv.open problem. If I can figure out the last bit tomorrow and it works for Helge and Josip, I can close that and its friends too and be ready for next monday. Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-03-25 18:02:45
|
Note, playing with undo.db, close.db on master, I found a minor bug on gramps34, gramps40 and master. Then going further on investigations, maybe got a more annoying one related to GUI/database (callback?). The problem looks important because it is around 'gen/db/write.py'! I think this also means that we should wait (once more) for '4.0.4' release. I suppose it was hidden before versions '3.4.6|4.0.2' and maybe enlighted after fixing a problem on EventRef, Attribute and Family? Now, the problem is that (maybe?) some actions can lead to a wrong backreference. It seems that we can edit an Event into Person Editor, and something (?) might store it as EventRef related to a Family, which could be right in theory. The problem seems not on database itself, rather on callback or GUI stuff. Maybe this could also explain some refresh issues? For the moment, I see one problem when we abort changes and quit the gramps session, but I do not understand all relations around this issue. Any expert is welcome! You can see bug report #7559. Regards, Jérôme Le mar. 18 mars 2014 at 4:00, John Ralls <jr...@ce...> a écrit : > > On Mar 17, 2014, at 12:06 PM, Jerome <rom...@ya...> wrote: > >> Devs, >> >> >> I contacted translators for next releases. >> We may say that we are in the "string freeze"! >> >> Maybe we should release '4.0.4', first. >> Then '3.4.8' some days later. >> >> Looking at '4.0.4' roadmap[1], we should be able to quickly commit >> patch for: >> >> * 7501: Notes always say "no data exists for note" when saving >> * 7347: Pedigreeview problem with "on mouse over" event (with a >> solution included) >> >> after a review. >> >> Maybe some bug reports, need more investigations: >> >> * 7407: Search Bar ignores non-ASCII characters in lowercase on >> people views >> * 6742: Death date does not update in listview after change >> * 7093: Error after creating Pedigree Chart Report >> * 7464: Given Name Cloud Gramplet splits up given names into words >> (broken up by spaces) >> >> Some are related to dependencies or OS: >> >> * 7238: Media view does not show "Date"-column and no horizontal >> scroll bar (gtk > 3.6) >> * 7268: GUI freeze and 100% CPU load after adding multiple Children >> to a newly created family >> * 7024: view not refreshed upon deletion of Place record >> * 7502: Person Editor has black background >> * 7258: transcode os.path.join args from the fs enc to prevent a >> crash >> * 7161: Collation in Linux without ICU is broken >> >> I am monitoring: >> * 7539: Some gramps windows appear either too small or too big >> * 7532: Cannot drag & drop textual value via clipboard >> => issues on '3.4.8' roadmap[2]. >> * 7481: can't add existing citation via filter >> etc ... >> >> >> So, what about to release '4.0.4' on 24th march 2014? >> >> > OK. I closed a couple of the collation bugs today, and I don't think > the additional option on report menus for 6538 should go into 4.0.4, > and maybe not into 4.0 at all, since they'd be something of a new > feature. > > I had a bit of a breakthrough on 7258 today which fixes a big chunk > of the DBEnv.open problem. If I can figure out the last bit tomorrow > and it works for Helge and Josip, I can close that and its friends > too and be ready for next monday. > > Regards, > John Ralls > |
From: Jerome <rom...@ya...> - 2014-03-28 09:00:04
|
John, What is the status of 7258? Should we keep some days for more testing? Maybe we should make at least a new test for 7519. I would like to also include a fix for get_reference_map_referenced_cursor() (7559), but currently I am still trying to provide a clear and proper testcase for reproducing it, and not only under my local repository. About the cursor issue, I suppose it is not new or a regression. It is specific to Person Editor (as far I can see). Something beween transaction, pickle, Person/Family/Event/Name object. I fear it was a "possible" known issue, see comment on 'gen/db/write.py': " while (ret is not None): (key, data) = ret # data values are of the form: # ((primary_object_class_name, primary_object_handle), # (referenced_object_class_name, referenced_object_handle)) # so we need the first tuple to give us the type to compare ### FIXME: this is a dirty hack that works without no ### sensible explanation. For some reason, for a readonly ### database, secondary index returns a primary table key ### corresponding to the data, not the data. if self.readonly: data = self.reference_map.get(data) else: data = pickle.loads(data) " As said, it looks like related to get_reference_map_referenced_cursor(), which sounds rather like a meta-data (tmp info). So, data are still secure (safe). The problem is maybe when we close the program, some tmp transactions around cursor are incomplete when some tables are not properly closed or when we abort actions (or something like that!). I am not familiar with such DB/GUI stuff, diagnostic might be wrong. Anyway, something goes wrong on cursor and to have a fix for '4.0.4' could be great too. Jérôme Le mar. 18 mars 2014 at 4:00, John Ralls <jr...@ce...> a écrit : > > OK. I closed a couple of the collation bugs today, and I don't think > the additional option on report menus for 6538 should go into 4.0.4, > and maybe not into 4.0 at all, since they'd be something of a new > feature. > > I had a bit of a breakthrough on 7258 today which fixes a big chunk > of the DBEnv.open problem. If I can figure out the last bit tomorrow > and it works for Helge and Josip, I can close that and its friends > too and be ready for next monday. > > Regards, > John Ralls > |
From: John R. <jr...@ce...> - 2014-03-28 14:09:51
|
On Mar 28, 2014, at 1:58 AM, Jerome <rom...@ya...> wrote: > John, > > What is the status of 7258? > Should we keep some days for more testing? > Maybe we should make at least a new test for 7519. > > I would like to also include a fix for get_reference_map_referenced_cursor() (7559), but currently I am still trying to provide a clear and proper testcase for reproducing it, and not only under my local repository. > > About the cursor issue, I suppose it is not new or a regression. > It is specific to Person Editor (as far I can see). Something beween transaction, pickle, Person/Family/Event/Name object. > > I fear it was a "possible" known issue, see comment on 'gen/db/write.py': > > " while (ret is not None): > (key, data) = ret > # data values are of the form: > # ((primary_object_class_name, primary_object_handle), > # (referenced_object_class_name, referenced_object_handle)) > # so we need the first tuple to give us the type to compare > > ### FIXME: this is a dirty hack that works without no > ### sensible explanation. For some reason, for a readonly > ### database, secondary index returns a primary table key > ### corresponding to the data, not the data. > if self.readonly: > data = self.reference_map.get(data) > else: > data = pickle.loads(data) " > > As said, it looks like related to get_reference_map_referenced_cursor(), which sounds rather like a meta-data (tmp info). So, data are still secure (safe). > The problem is maybe when we close the program, some tmp transactions around cursor are incomplete when some tables are not properly closed or when we abort actions (or something like that!). I am not familiar with such DB/GUI stuff, diagnostic might be wrong. Anyway, something goes wrong on cursor and to have a fix for '4.0.4' could be great too. Jérôme, I'm doing a GnuCash release over this weekend so I've had to set Gramps work aside for a few days. I'm afraid 7258 is as good as we can make it at this point, though we need Josip to test that the undodb crash at shutdown is fixed. AFAICT so far the problem of not being able to use arbitrary unicode codepoints, those which aren't on the active code page, passed correctly in to DBEnv is a bsddb/bsddb3 bug, but I haven't been able to nail it down well enough to write a bug report on it. I can add a unit test to check that clidbman can open a db in a non-ascii path, but it will have to be disabled in Windows. I'd have to spend some study time to help on 7559, and I don't have that time right now, sorry. Regards, John Ralls |
From: Jerome <rom...@ya...> - 2014-03-28 20:01:21
|
John, Does it mean that GnuCash will release two versions this month and Gramps none? No problem, Gramps has maybe less bugs !!! :/ https://www.gramps-project.org/wiki/index.php?title=Template:Releases/4.0.4 Seriously, sure we can still wait. ;) Maybe this mean that we need to wait for gramps-4.0.x as webapp (HTML apps)! If so, we might also look at bugs for 3.4.x? https://gramps-project.org/bugs/roadmap_page.php?version_id=46 I just fear that if bug reports do not have a patch - most of them were already reported some months ago and few have only a simple coding/syntax issues - then we will wait some weeks more! To disable an unit test in Windows! Does we load unit tests every time? I saw some print statements into 'test' codes, like: if __name__ == "__main__": eg, gramps/gen/db/bsddbtxn.py Does it make sense to move print() to logging (info, debug, etc ...) and/or move such tests into new modules (/test/...)? Vassilii, Maybe we should commit a simple fix for the Filter rules Editor? For information, think found the cause of 7559. Which is close to design! (see 6910) I could try to provide an experimental patch. eg, to also commit/update (TXNUPD = 1) Person or Family objects having the updated EventRef! It looks ugly on the method: call backlink reference for having a generator, then to force commit for Person too.. def commit_personal_event(self, event, transaction, change_time=None): if event.type.is_custom(): self.individual_event_names.add(str(event.type)) self.commit_event(event, transaction, change_time) + bck_ref = self.find_backlink_handles(event.handle) + for ref in bck_ref: + .... def commit_person(self, person, transaction, change_time=None): """ Commit the specified Person to the database, storing the changes as part of the transaction. """ but it is not the right or proper solution. Question: Does to update primary object's reference (also citation) within parent editor should also update this parent object? This is not secondary objects, and in theory, to update an event reference will also updates the Person itself (or Family). eg, role is always a EventRef field, even for only updating data on the unlinked fields (eg, date, place ... for the Event). Many related questions: how to be sure that we only update the ref too and not all related back references, does to cancel Person Edition after an EventRef (Event-Person) update should abort both transactions and commit? I guess that's why cursors are also designed. Regards, Jérôme R. Le ven. 28 mars 2014 at 15:09, John Ralls <jr...@ce...> a écrit : > > Jérôme, > > I'm doing a GnuCash release over this weekend so I've had to set > Gramps work aside for a few days. > > I'm afraid 7258 is as good as we can make it at this point, though we > need Josip to test that the undodb crash at shutdown is fixed. AFAICT > so far the problem of not being able to use arbitrary unicode > codepoints, those which aren't on the active code page, passed > correctly in to DBEnv is a bsddb/bsddb3 bug, but I haven't been able > to nail it down well enough to write a bug report on it. > > I can add a unit test to check that clidbman can open a db in a > non-ascii path, but it will have to be disabled in Windows. > > I'd have to spend some study time to help on 7559, and I don't have > that time right now, sorry. > > Regards, > John Ralls > > |
From: John R. <jr...@ce...> - 2014-03-28 21:26:31
|
On Mar 28, 2014, at 1:00 PM, Jerome <rom...@ya...> wrote: > John, > > > Does it mean that GnuCash will release two versions this month and Gramps none? > No problem, Gramps has maybe less bugs !!! :/ We release GnuCash on a schedule rather than to a roadmap. There’s *lots* of bugs. > > https://www.gramps-project.org/wiki/index.php?title=Template:Releases/4.0.4 > > Seriously, sure we can still wait. ;) > > Maybe this mean that we need to wait for gramps-4.0.x as webapp (HTML apps)! > > If so, we might also look at bugs for 3.4.x? > > https://gramps-project.org/bugs/roadmap_page.php?version_id=46 > > I just fear that if bug reports do not have a patch - most of them were already reported some months ago and few have only a simple coding/syntax issues - then we will wait some weeks more! > To disable an unit test in Windows! > Does we load unit tests every time? > > I saw some print statements into 'test' codes, like: > if __name__ == "__main__": > > eg, gramps/gen/db/bsddbtxn.py > > Does it make sense to move print() to logging (info, debug, etc ...) > and/or move such tests into new modules (/test/…)? I don’t think we run tests by default ever. Do you run them before making the release tarballs? The “if __name__ == “__main__” thing allows one to run the test as a standalone program instead of importing it into a test runner. Print statements make sense in that context, it’s not really necessary to set up a logger. Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2014-04-05 17:16:30
|
John Ralls-2 wrote > On Mar 28, 2014, at 1:00 PM, Jerome < > romjerome@ > > wrote: > >> John, >> >> >> Does it mean that GnuCash will release two versions this month and Gramps >> none? >> No problem, Gramps has maybe less bugs !!! :/ > > We release GnuCash on a schedule rather than to a roadmap. There’s *lots* > of bugs. I would very much like to have a schedule for Gramps releases. It isn't as if we carefully build a roadmap of fixes that are _really_ needed, and then wait till they have been completed before doing the release. It seems to me that we suddenly decide that we should do a new release of Gramps <tomorrow>, and then we look at the roadmap, and decide which reports can be moved to a later release, and maybe one or two that need to be urgently fixed before the release. I would find it much easier to work on fixes if I had a deadline. Also, having a release date would mean we had a good target for code and string freezes etc. Other people would find it much easier to plan their bug fixing work. Of course, this should not preclude urgent fixes where they are essential (e.g. if a new release has an unexpected and widespread unfortunate side effect). Could someone with the appropriate access please update the prospective release dates on the bug tracker? regards, Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/4-0-4-Release-tp4665146p4665418.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Nick H. <nic...@ho...> - 2014-04-05 17:50:20
|
On 05/04/14 18:15, Tim Lyons wrote: > I would very much like to have a schedule for Gramps releases. We have a schedule for major releases. It is yearly, around 21st May, but has varied in the past. The schedule for minor releases depends on the number of bugs reported and fixed. When we agree a date it should be posted to the list. The current maintenance release has slipped though. Hopefully we will be ready soon. Nick. |
From: John R. <jr...@ce...> - 2014-04-03 22:12:06
|
On Mar 28, 2014, at 7:09 AM, John Ralls <jr...@ce...> wrote: > > I can add a unit test to check that clidbman can open a db in a non-ascii path, but it will have to be disabled in Windows. Done, pushed to master and gramps40. Regards, John Ralls |
From: Vassilii K. <vas...@ta...> - 2014-03-29 11:12:51
|
You are way ahead of me on #7559 investigation! On 28.03.2014 23:00, Jerome wrote: > Many related questions: how to be sure that we only update the ref too > and not all related back references, does to cancel Person Edition > after an EventRef (Event-Person) update should abort both transactions > and commit? This sounds like a very complicated change, it needs to be covered by a lot of (initially failing) tests we write that specify what we expect, especially with partial failures --- like what happens if only some of the updates succeed, what happens if we run with an inconsistent back reference map, etc.! As for the implementation, maybe a good way to express the logic you want to implement, is to create a new transaction (sub)class that would aggregate these two transactions? First just for this editor scenario. Still complex work... V |
From: Jerome <rom...@ya...> - 2014-03-29 18:24:48
|
Vassilii, Maybe my method is not accademic, but at least I think there is two bugs or unwanted behavior(s) around this piece of code. True, I should not put all these comments and should look at one issue, which can be the most visible => 7559: 'Ignore changes and Quit' function does not ignore updated Event within Person Editor. Very close to 6910: Event Reference Editor dialog is non-modal to Person dialog 5977: Closing parent editor with a CitationEmbedList closes child CitationEditor windows without saving edits! 5595: DBError when rebuilding reference maps while Event view row is selected and maybe 6691: Family event edition via pedigree category does not update date on screen 6742: Death date does not update in listview after change * design on gramps' GtkWindow * update transaction is a specific behavior * KEY objects are often primary one, references are sometimes ignored * to edit/remove a linked primary object will also create/delete the reference, what about update only for this reference? Bug 1: #7559 1. Open Gramps 2. Open a Person editor 3. Edit an event from Events tab (update an existing one) 4. Go to Family Trees menu -> 'Ignore changes and Quit...' 5. re-open your family tree, look if changes were ignored. Bug 2: "To enable debug log (eg, ".citation" for 'gen/db/write.py'!) returns: 2014-03-25 17:55:16.384: DEBUG: write.py: line 1033: handle: cb14af55e3923588805, reflist: [] 2014-03-25 17:55:17.566: DEBUG: write.py: line 1033: handle: c43b3d096d1116eff50, reflist: [('Family', 'c43b3ce61e743945aea'), ('Event', 'cb14af55e3923588805')] Problem: I am editing Person's EventRef, not a Family ! # Once we have the list of rows that already have a reference # we need to compare it with the list of objects that are # still references from the primary object. reflist = obj.get_referenced_handles_recursively() LOG.debug("handle: {0}, reflist: {1}".format( handle, reflist))" Sure, I can guess what happen by looking at LOG or print statements, but when I saw on code, a comment like: " ### FIXME: this is a dirty hack that works without no ### sensible explanation. For some reason, for a readonly ### database, secondary index returns a primary table key ### corresponding to the data, not the data. if self.readonly: data = self.reference_map.get(data) else: data = pickle.loads(data) " I wonder what I can do! pickle module is too advanced for me. get_reference_map_referenced_cursor() or self.txn.commit(flags) seem powerful, but how to control data once we are on this stage? For resume, I suppose that a transaction (or commit and update) failed around Person, Name, EventRef. The problem is visible on few cases (transaction type is update and maybe delete). The corrupted back reference (Family) might be related to cursor (or pickle on data) or could be something different (unclosed table, code sequence, timing, typo on code, secondary reference (Family = Persons), etc ...). We can see when this could be a problem (undo, crash, abort into session, refresh data on screen, mapping, etc ...), but there is also a DB variable making the debug really uncomfortable. In fact, even with a new subclass, I did not know if this will fix the bug 2 : backreference which returns Family class name after editing Person's event... I do not know if any fix on this piece of code might cover at least one issue already reported, but if you can find the cause of: $ python Gramps.py -d ".citation" Open a Person editor, then Update an event from Events tab. 2014-03-25 17:55:16.384: DEBUG: write.py: line 1033: handle: cb14af55e3923588805, reflist: [] 2014-03-25 17:55:17.566: DEBUG: write.py: line 1033: handle: c43b3d096d1116eff50, reflist: [('Family', 'c43b3ce61e743945aea'), ('Event', 'cb14af55e3923588805')] then I suppose we could be into a more logical debug environment! Jérôme Le sam. 29 mars 2014 at 12:12, Vassilii Khachaturov <vas...@ta...> a écrit : > You are way ahead of me on #7559 investigation! > > On 28.03.2014 23:00, Jerome wrote: >> Many related questions: how to be sure that we only update the ref >> too and not all related back references, does to cancel Person >> Edition after an EventRef (Event-Person) update should abort both >> transactions and commit? >> > This sounds like a very complicated change, it needs to be covered by > a lot of (initially failing) tests we write that specify what we > expect, especially with partial failures --- like what happens if > only some of the updates succeed, what happens if we run with an > inconsistent back reference map, etc.! > > As for the implementation, maybe a good way to express the logic you > want to implement, is to create a new transaction (sub)class that > would aggregate these two transactions? First just for this editor > scenario. Still complex work... > > V |
From: Jerome <rom...@ya...> - 2014-04-01 08:57:32
|
Sorry, I added LOG statements during investigations. No one will see these back handle_references... I just commit one location, which should point out that something goes wrong. http://sourceforge.net/p/gramps/source/ci/3b23ab460258e2225b3a72616ac05329c21cf918/ Maybe run: $ python Gramps.py -d ".baseobj" then play with add/update/remove records (rather secondary and ref). ------------------------------- $ python Gramps.py -d ".citation" Open a Person editor, then Update an event from Events tab. 2014-03-25 17:55:16.384: DEBUG: write.py: line 1033: handle: cb14af55e3923588805, reflist: [] 2014-03-25 17:55:17.566: DEBUG: write.py: line 1033: handle: c43b3d096d1116eff50, reflist: [('Family', 'c43b3ce61e743945aea'), ('Event', 'cb14af55e3923588805')] > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Tim L. <guy...@gm...> - 2014-03-28 22:46:47
|
jerome wrote > > https://www.gramps-project.org/wiki/index.php?title=Template:Releases/4.0.4 The name "the machine that goes ping" might be taken to be a reference to MH370 and the (now notorious) Inmarsat pings or handshakes or polling. I don't know whether this choice might be regarded as bad taste. I am probably being too sensitive. But it might be worth keeping that name back to be used some other time. (What a strange coincidence). Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/4-0-4-Release-tp4665146p4665275.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Jerome <rom...@ya...> - 2014-03-29 08:29:50
|
Yes, you are right! The primary idea was rather Monty Python references! https://www.gramps-project.org/wiki/index.php?title=Previous_releases "The machine that goes ping In Monty Python's the Meaning of Life, the machine that goes "ping" is a device that doctors use to determine that the baby they're delivering is alive. It is also the most expensive machine in the whole hospital. "Aah! I see you have the machine that goes ping. This is my favourite. You see, we lease this back from the company we sold it to, and that way, it comes under the monthly current budget and not the capital account." http://www.urbandictionary.com/define.php?term=The%20machine%20that%20goes%20ping I did not think on airplane because I did not look at TV. I saw the news, '4.0.4' was planned before the '7. March' and did not remove it on wiki. Sorry! Benny can live without release names, and I think I can it too (especially now), but some users have send some new references. http://gramps.1791082.n4.nabble.com/Next-release-names-tp4660145p4660150.html So, we started to list and still use them! https://www.gramps-project.org/wiki/index.php?title=Talk:Previous_releases "Not the comfy chair" looks better? "MG whoring Call of Duty player. Derived from the Monty Python skit featuring the Spanish Inquisition. The Comfy Chair is the most feared torture device in which unbelievers are vigorously poke by soft cushions. Nobody expects this because Nobody Expects The Spanish Inquisition! Oh no! Not the Comfy Chair!" http://www.urbandictionary.com/define.php?term=The%20Comfy%20Chair Jérôme. Le ven. 28 mars 2014 at 23:46, Tim Lyons <guy...@gm...> a écrit : > jerome wrote >> >> >> https://www.gramps-project.org/wiki/index.php?title=Template:Releases/4.0.4 >> > The name "the machine that goes ping" might be taken to be a > reference to > MH370 and the (now notorious) Inmarsat pings or handshakes or polling. > > I don't know whether this choice might be regarded as bad taste. I am > probably being too sensitive. But it might be worth keeping that name > back > to be used some other time. > > (What a strange coincidence). > > Tim. > > > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/4-0-4-Release-tp4665146p4665275.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |