Hi, the attached is supposed to be a Stata 12 file. (The data are not confidential.) Gretl on windows crashes when I try to import it. I haven't tried recent snapshots. I managed to open and convert the file with the "pandas" module under Python, result is also attached.

-----Original Message----- From: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel- bounces(a)lists.wfu.edu] On Behalf Of Sven Schreiber Sent: Friday, December 04, 2015 12:16 PM To: gretl-devel(a)lists.wfu.edu Subject: Re: [Gretl-devel] gretl 2015d crashes on opening attached stata file Am 04.12.2015 um 16:57 schrieb Riccardo (Jack) Lucchetti: > > With HEAD git here the file opens with no problems, although there is > a visualisation problem with variable 4 ("Bundesland") if you try > opening it (you get a blank window). If you try together with other > ones, you see it, but it's all misaligned. > > However, I suspect this is related to some work Allin is doing on > string variables and should be a transient hiccup. Now that you mention it, I also saw some misalignment there with 2015d, so perhaps not so transient. > > The important thing is that gretl doesn't crash here (Linux). Could > you see what happens with a recent snapshot? > Still crashes with the Nov 30th snapshot. This is Win 8.1 32bit. Can other Windows users test? (let me repeat: this likely crashes your gretl, save and close your data first) Maybe it has something to do with a) string-valued series, b) having hyphens and Umlauts in the values. BTW, I noticed that I cannot import a series/column with those strings from an xls file, gretl says "expected numerical data". This used to be obvious, but now that gretl also does such series, perhaps it is an oversight to not allow them in imports? thanks, sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Am 04.12.2015 um 16:57 schrieb Riccardo (Jack) Lucchetti: > > With HEAD git here the file opens with no problems, although there is a > visualisation problem with variable 4 ("Bundesland") if you try opening > it (you get a blank window). If you try together with other ones, you > see it, but it's all misaligned. > > However, I suspect this is related to some work Allin is doing on string > variables and should be a transient hiccup. Now that you mention it, I also saw some misalignment there with 2015d, so perhaps not so transient. Maybe it has something to do with a) string-valued series, b) having hyphens and Umlauts in the values.

BTW, I noticed that I cannot import a series/column with those strings from an xls file, gretl says "expected numerical data". This used to be obvious, but now that gretl also does such series, perhaps it is an oversight to not allow them in imports?

Although it's clear now where the wonky formatting was coming from I'm still not sure what provoked the crash on (only 32-bit?) Windows. This may be a word-length thing unrelated to the bad strings; it would be nice to track it down!

Am 05.12.2015 um 15:38 schrieb Allin Cottrell: > Although it's clear now where the wonky formatting was coming from I'm > still not sure what provoked the crash on (only 32-bit?) Windows. This > may be a word-length thing unrelated to the bad strings; it would be > nice to track it down! I have just tested today's snapshot with the same Stata file on another machine with 32bit Win 7 (before it was Win 8). Same immediate crash on trying to open it. And BTW on the previous Win8 machine when I launched it from the cmd with "gretl.exe --debug" I just saw something like "binary read error".

On Sun, 6 Dec 2015, Allin Cottrell wrote:

> > Thanks, Sven. I'll try to get to the bottom of this. IIRC, the Stata > 117 format is meant to support very big files and the binary > "signposts" telling you where to read within the file are 64-bit > integers. Handling these on 32-bit Windows requires some sort of > bodge, and apparently our current bodge is not successful. This is quite confusing. I've made some changes and put in more error-checking and debugging, so hopefully if it still crashes we can get a better idea of where the error is. I'm afraid I'm not able to test on 32-bit Windows myself.

On Sun, 6 Dec 2015, Allin Cottrell wrote:

> > Thanks, Sven. I'll try to get to the bottom of this. IIRC, the Stata > 117 format is meant to support very big files and the binary > "signposts" telling you where to read within the file are 64-bit > integers. Handling these on 32-bit Windows requires some sort of > bodge, and apparently our current bodge is not successful. This is quite confusing. I've made some changes and put in more error-checking and debugging, so hopefully if it still crashes we can get a better idea of where the error is. I'm afraid I'm not able to test on 32-bit Windows myself.