From: Benny M. <ben...@gm...> - 2012-06-23 09:47:38
|
Tim, I soon leave for conferences (Thursday), so will be of the radar for quite some time, depending on wifi and bandwith capacities. Would it not be best to do a 3.4.1 beginning of July? The conversion problem of citations is solved, some other issues might be resolved if we indicate a bug release start of July. Also translations that did not make it in 3.4.0. Can you handle a 3.4.1 release? What do others think, should something definitely go in? Benny |
From: Peter L. <pet...@te...> - 2012-06-23 11:05:21
|
Hi, 1. I have noticed that parish and county are not exported to GEDCOM. Is this a limitation in the GEDCOM standard? 2. I see also that street address is exported twice, both as ADDR and ADR1. This causes a number of errors in the following import and creation of a number of new notes. /Peter |
From: Nick H. <nic...@ho...> - 2012-06-23 11:37:40
|
On 23/06/12 12:05, Peter Landgren wrote: > Hi, > > 1. I have noticed that parish and county are not exported to GEDCOM. > Is this a limitation in the GEDCOM standard? Yes. > > 2. I see also that street address is exported twice, both as ADDR and ADR1. > This causes a number of errors in the following import and > creation of a number of new notes. The GEDCOM standard says: "The address structure should be formed as it would appear on a mailing label using the ADDR and the CONT lines to form the address structure. The ADDR and CONT lines are required for any address. The additional subordinate address tags such as STAE and CTRY are provided to be used by systems that have structured their addresses for indexing and sorting. For backward compatibility these lines are not to be used in lieu of the required ADDR.and CONT line structure." Gramps maps the following fields for structured addresses: ADR1 = Street ADR2 = Locality ADR3 = Not Used CITY = City STAE = State CTRY = Country POST = Zip/Postal Code There are no GEDCOM fields for Parish or County. The ADDR and CONT lines are required and should hold a full mailing address. In Gramps, we just populate it with the street for export. For import, the structured fields are used. It is not used for the place title - this is imported from the PLAC structure. An alternative to using the structured address fields, would be to define a place hierarchy in the PLAC structure. We could possibly include County and Parish fields in this structure - it might be worth investigating. Nick. > > /Peter > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Tim L. <guy...@gm...> - 2012-06-24 22:18:11
|
Nick Hall-6 wrote > > The ADDR and CONT lines are required and should hold a full mailing > address. In Gramps, we just populate it with the street for export. > For import, the structured fields are used. It is not used for the > place title - this is imported from the PLAC structure. > (Without looking at the code, I recall that) on import, both the ADDR/CONT and the structured fields are used. I made a fix so that if the ADDR/CONT lines were overwritten by the structured fields, you got a warning message. -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655496.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: John R. <jr...@ce...> - 2012-06-23 21:02:02
|
On Jun 23, 2012, at 10:47 AM, Benny Malengier <ben...@gm...> wrote: > Tim, > > I soon leave for conferences (Thursday), so will be of the radar for quite some time, depending on wifi and bandwith capacities. > > Would it not be best to do a 3.4.1 beginning of July? The conversion problem of citations is solved, some other issues might be resolved if we indicate a bug release start of July. Also translations that did not make it in 3.4.0. > > Can you handle a 3.4.1 release? What do others think, should something definitely go in? It would be better to hold off two weeks until I get back from holiday on 11 July. Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2012-06-25 13:59:28
|
John Ralls-2 wrote > > On Jun 23, 2012, at 10:47 AM, Benny Malengier <benny.malengier@> > wrote: >> Would it not be best to do a 3.4.1 beginning of July? The conversion >> problem of citations is solved, some other issues might be resolved if we >> indicate a bug release start of July. Also translations that did not make >> it in 3.4.0. > > It would be better to hold off two weeks until I get back from holiday on > 11 July. > The 11th July would be better. 0005785: print statements in Check.py causing a crash in Windows (pythonw.exe) after outputting 4096 characters is still not resolved - I am discussing it offlist with Josip. By the way, I suspect that 0003428: When running with pythonw.exe, Windows may crash if you write to stdout (the exact same fault) was not really resolved when it was closed fixed in 3.2 in Feb 2010. LOG.warn() as recommended in 3428 still results in output to stdout. I think this will be fixed RSN. -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655505.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Benny M. <ben...@gm...> - 2012-06-25 16:17:30
|
2012/6/25 Tim Lyons <guy...@gm...> > > John Ralls-2 wrote > > > > On Jun 23, 2012, at 10:47 AM, Benny Malengier <benny.malengier@> > > wrote: > >> Would it not be best to do a 3.4.1 beginning of July? The conversion > >> problem of citations is solved, some other issues might be resolved if > we > >> indicate a bug release start of July. Also translations that did not > make > >> it in 3.4.0. > > > > It would be better to hold off two weeks until I get back from holiday on > > 11 July. > > > > The 11th July would be better. > Ok, I'll leave it in your hands. Benny > > 0005785: print statements in Check.py causing a crash in Windows > (pythonw.exe) after outputting 4096 characters is still not resolved - I am > discussing it offlist with Josip. By the way, I suspect that 0003428: When > running with pythonw.exe, Windows may crash if you write to stdout (the > exact same fault) was not really resolved when it was closed fixed in 3.2 > in > Feb 2010. LOG.warn() as recommended in 3428 still results in output to > stdout. I think this will be fixed RSN. > > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655505.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: John R. <jr...@ce...> - 2012-07-10 16:21:14
|
On Jun 25, 2012, at 5:17 PM, Benny Malengier wrote: > > > 2012/6/25 Tim Lyons <guy...@gm...> > > John Ralls-2 wrote > > > > On Jun 23, 2012, at 10:47 AM, Benny Malengier <benny.malengier@> > > wrote: > >> Would it not be best to do a 3.4.1 beginning of July? The conversion > >> problem of citations is solved, some other issues might be resolved if we > >> indicate a bug release start of July. Also translations that did not make > >> it in 3.4.0. > > > > It would be better to hold off two weeks until I get back from holiday on > > 11 July. > > > > The 11th July would be better. > > Ok, I'll leave it in your hands. > Tim, Are you planning to do the release tarballs tomorrow, or to wait until the weekend? I'm flying back from London tomorrow, so if the tarballs are ready and on SF I'll start the OSX build Thursday morning (Z+8). Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2012-07-11 15:49:34
|
On Tue, Jul 10, 2012 at 5:21 PM, John Ralls <jr...@ce...> wrote: > Tim, > > Are you planning to do the release tarballs tomorrow, or to wait until the > weekend? I'm flying back from London tomorrow, so if the tarballs are ready > and on SF I'll start the OSX build Thursday morning (Z+8). > > Regards, > John Ralls > > Sorry, I had it in my mind that the date I was working towards was 21st, not 11th. (and naturally was procrastinating!) I have committed a fix for Citation filters, and need to commit a fix for the problem that was causing a crash in MS Windows. I was working on that with Josip, but haven't heard from him lately. I have some changes made to Check and elsewhere that will reduce the likelihood of problems, but need to make the change that will prevent them altogether. Also, I can't actually make the tarball. Regards, Tim. |
From: John R. <jr...@ce...> - 2012-07-12 03:58:11
|
On Jul 11, 2012, at 8:49 AM, Tim Lyons wrote: > > > On Tue, Jul 10, 2012 at 5:21 PM, John Ralls <jr...@ce...> wrote: > Tim, > > Are you planning to do the release tarballs tomorrow, or to wait until the weekend? I'm flying back from London tomorrow, so if the tarballs are ready and on SF I'll start the OSX build Thursday morning (Z+8). > > Regards, > John Ralls > > > Sorry, I had it in my mind that the date I was working towards was 21st, not 11th. (and naturally was procrastinating!) > > I have committed a fix for Citation filters, and need to commit a fix for the problem that was causing a crash in MS Windows. I was working on that with Josip, but haven't heard from him lately. I have some changes made to Check and elsewhere that will reduce the likelihood of problems, but need to make the change that will prevent them altogether. Oh, OK, if you've got commits to go in then we should certainly wait. > Also, I can't actually make the tarball. Now I'm confused. Why was Benny asking you to do the release if you can't make the tarball? Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2012-07-16 23:23:47
|
I have now committed the changes for bug 5785. Although I have forced it down the Windows path to do some basic testing, it does need to be tested in both the Windows and Mac gramps.app environment. So I would be grateful if Josip and John (respectively) could do so. There are changes to the main gramps.py module, so it does need to be established that it works in the different environments. Otherwise, as far as I am concerned, it is now ready for the 3.4.1 release. I think the tarball is normally made by Stephane, once the release is said to be ready. -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655696.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Tim L. <guy...@gm...> - 2012-07-16 23:34:16
|
Sorry, I should have said that I have tested the gramps34 branch, but not trunk at all though I have applied the patches to trunk - with some difficulty because of all the file moves and renames :-( -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655697.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: John R. <jr...@ce...> - 2012-07-17 21:20:45
|
On Jul 16, 2012, at 4:23 PM, Tim Lyons [via GRAMPS] wrote: > I have now committed the changes for bug 5785. Although I have forced it down the Windows path to do some basic testing, it does need to be tested in both the Windows and Mac gramps.app environment. So I would be grateful if Josip and John (respectively) could do so. There are changes to the main gramps.py module, so it does need to be established that it works in the different environments. Otherwise, as far as I am concerned, it is now ready for the 3.4.1 release. > > I think the tarball is normally made by Stephane, once the release is said to be ready. I've tested the current maintenance/3.4 head on Mac and found that the logging behaves itself just fine, at least on Snow Leopard. Regards, John Ralls |
From: John R. <jr...@ce...> - 2012-07-17 21:26:07
|
On Jul 16, 2012, at 4:23 PM, Tim Lyons [via GRAMPS] wrote: > I have now committed the changes for bug 5785. Although I have forced it down the Windows path to do some basic testing, it does need to be tested in both the Windows and Mac gramps.app environment. So I would be grateful if Josip and John (respectively) could do so. There are changes to the main gramps.py module, so it does need to be established that it works in the different environments. Otherwise, as far as I am concerned, it is now ready for the 3.4.1 release. > > I think the tarball is normally made by Stephane, once the release is said to be ready. I've tested the current maintenance/3.4 head on Mac and found that the logging behaves itself just fine, at least on Snow Leopard. Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2012-07-18 00:10:22
|
John Ralls-2 wrote > > I've tested the current maintenance/3.4 head on Mac and found that the > logging behaves itself just fine, at least on Snow Leopard. > Thanks John. If someone (Josip?) could do a test on Windows, then we are ready to release 3.4.1. -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655707.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Jérôme <rom...@ya...> - 2012-07-18 03:59:30
|
> then we are ready to release 3.4.1. Should we move some items/entries from 3.4.1[1] to 3.4.2[2] on roadmap? [1] http://www.gramps-project.org/bugs/roadmap_page.php?version_id=31 [2] http://www.gramps-project.org/bugs/roadmap_page.php?version_id=32 Tim Lyons a écrit : > John Ralls-2 wrote >> I've tested the current maintenance/3.4 head on Mac and found that the >> logging behaves itself just fine, at least on Snow Leopard. >> > > Thanks John. If someone (Josip?) could do a test on Windows, then we are > ready to release 3.4.1. > > -- > View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655707.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Tim L. <guy...@gm...> - 2012-07-18 21:50:01
|
On 18 Jul 2012, at 04:59, Jérôme wrote: >> then we are ready to release 3.4.1. > > Should we move some items/entries from 3.4.1[1] to 3.4.2[2] on > roadmap? Yes please. |
From: Tim L. <guy...@gm...> - 2012-06-25 09:42:19
|
On 25 Jun 2012, at 07:01, Peter Landgren wrote: > The reason is that both ADDR and ADR1 contains the same information. > See: > self.__writeln(level, "ADDR", location.get_street()) > if location.get_street(): > self.__writeln(level + 1, 'ADR1', > location.get_street()) Well, yes and no. That is the reason you get a warning when you re- import something that has been exported from Gramps. But of course, the Gramps import has to cater for data from any source, not just from Gramps. The GEDCOM specification does not specify what should happen if both ADDR and ADR! are populated. All it says is "The address structure should be formed as it would appear on a mailing label using the ADDR and ADDR.CONT lines. These lines are required if an ADDRess is present. Optionally, additional structure is provided for systems that have structured their addresses for indexing and sorting.". So we have to assume that when both ADDR and ADR1 are present, it is possible that ADDR and ADR1 contain different (non-overlapping) information. Hence we warn the user when information may be lost. |
From: Peter L. <pet...@te...> - 2012-06-25 11:09:46
|
Tim Lyons skrev 2012-06-25 11:42: > On 25 Jun 2012, at 07:01, Peter Landgren wrote: >> The reason is that both ADDR and ADR1 contains the same information. >> See: >> self.__writeln(level, "ADDR", location.get_street()) >> if location.get_street(): >> self.__writeln(level + 1, 'ADR1', location.get_street()) > > > Well, yes and no. That is the reason you get a warning when you > re-import something that has been exported from Gramps. > > But of course, the Gramps import has to cater for data from any > source, not just from Gramps. The GEDCOM specification does not > specify what should happen if both ADDR and ADR! are populated. All it > says is "The address structure should be formed as it would appear on > a mailing label using the ADDR and ADDR.CONT lines. These lines are > required if an ADDRess is present. Optionally, additional structure is > provided for systems that have structured their addresses for indexing > and sorting.". > > So we have to assume that when both ADDR and ADR1 are present, it is > possible that ADDR and ADR1 contain different (non-overlapping) > information. Hence we warn the user when information may be lost. > > Yes, I'm aware of this definition, but is it neccesary to export the same information in both ADDR and ADR1? I can't see why. /Peter |
From: Nick H. <nic...@ho...> - 2012-06-25 13:30:24
|
On 25/06/12 12:09, Peter Landgren wrote: > Tim Lyons skrev 2012-06-25 11:42: >> On 25 Jun 2012, at 07:01, Peter Landgren wrote: >>> The reason is that both ADDR and ADR1 contains the same information. >>> See: >>> self.__writeln(level, "ADDR", location.get_street()) >>> if location.get_street(): >>> self.__writeln(level + 1, 'ADR1', location.get_street()) >> >> Well, yes and no. That is the reason you get a warning when you >> re-import something that has been exported from Gramps. >> >> But of course, the Gramps import has to cater for data from any >> source, not just from Gramps. The GEDCOM specification does not >> specify what should happen if both ADDR and ADR! are populated. All it >> says is "The address structure should be formed as it would appear on >> a mailing label using the ADDR and ADDR.CONT lines. These lines are >> required if an ADDRess is present. Optionally, additional structure is >> provided for systems that have structured their addresses for indexing >> and sorting.". >> >> So we have to assume that when both ADDR and ADR1 are present, it is >> possible that ADDR and ADR1 contain different (non-overlapping) >> information. Hence we warn the user when information may be lost. >> >> > Yes, I'm aware of this definition, but is it neccesary to export the > same information in both ADDR and ADR1? I can't see why. We should really export the full mailing address in the ADDR rather than just the street, so that systems that do not read the structured format still get a full address. Newer systems that use the structured format should still export the older format. When reading a newer structured format the older format will still be present. It is likely that this will be a duplicate and no data will be lost, but this is not definite. I would suggest that we could suppress the errors in this case. Tim - what do you think? Nick. > /Peter > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Tim L. <guy...@gm...> - 2012-06-25 13:49:28
|
Nick Hall-6 wrote > > When reading a newer structured format the older format will still be > present. It is likely that this will be a duplicate and no data will be > lost, but this is not definite. > > I would suggest that we could suppress the errors in this case. Tim - > what do you think? > Well, yes. When I was writing my original response, I did think that really the correct thing to do was to check whether the ADDR/CONT field was actually duplicating the structured fields and if so not to produce the warning. But you would need to deal with the fact that the ADDR/CONT might only contain some of the structured information (in the case of the code quoted, it would only be the ADR1 component). And you would probably want to ignore trailing spaces, and differences in newlines, and possibly other white space differences. I decided that I was not that bothered to do it carefully enough. My excuse is that I am more concerned with improving GEDCOM import. By the way, the same problem arises for the PERSONAL_NAME_STRUCTURE, where the NAME_PERSONAL may duplicate the name pieces. In the classic GEDCOM torture test data I think one of the PERSONAL_NAME_STRUCTUREs has NAME_PERSONAL and name pieces that are NOT duplicates, and from memory, I think I tried to ensure that the two parts were both imported. -- View this message in context: http://gramps.1791082.n4.nabble.com/3-4-1-tp4655461p4655504.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Paul F. <pf....@gm...> - 2012-07-17 12:06:25
|
On 7/16/12, Tim Lyons <guy...@gm...> wrote: > I think the tarball is normally made by Stephane, once the release is said > to be ready. Just curious, but can somebody say if it is as simple as: 1) navigate to gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps34/ 2) click on "Download GNU tarball" at the bottom (which is: gramps.svn.sourceforge.net/viewvc/gramps/branches/maintenance/gramps34/?view=tar ) 3) renaming the "gramps-gramps34.tar.gz" which results (to have the correct version number, etc.) 4) uploading that renamed tarfile to the correct SourceForge directory (which I am guessing only some developers have write permission for, thus can do, but that's just my guess) Thanks. |
From: Stéphane C. <ste...@gm...> - 2012-07-17 13:11:34
|
On Tue, Jul 17, 2012 at 5:06 AM, Paul Franklin <pf....@gm...> wrote: > On 7/16/12, Tim Lyons <guy...@gm...> wrote: > > I think the tarball is normally made by Stephane, once the release is > said > > to be ready. > > Just curious, but can somebody say if it is as simple as: > Not quite. I wrote a wiki page a few years ago when I started doing the releases. The instructions are up-to-date: http://www.gramps-project.org/wiki/index.php?title=What_to_do_for_a_release Stéphane |