New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opening .sav file, graphics output #1695

Closed
baltzis opened this Issue Mar 22, 2017 · 15 comments

Comments

Projects
None yet
5 participants
@baltzis

baltzis commented Mar 22, 2017

Environment (for bugs)

  • JASP version: 0.8.1.1

  • OS name and version: Windows 10 (64bit)

  • Analysis: When I try to open a .sav file in a directory other than route, I get the message:
    "Unable to open file. No header found in .SAV file".
    I suspect that this is because my system is in Greek and several directories have Greek names. The same file, however, can be opened from the route directory of "My Documents".

  • Second problem: While labels in Greek appear OK in tables (e.g. frequencies), in plots they appear in gibberish (see attached image).
    test-jasp

@jdittrich

This comment has been minimized.

Show comment
Hide comment
@jdittrich

jdittrich Mar 22, 2017

It seems that this issue should be split in two issues, so that both issues could be investigated and solved independently

e.g. in these:

  • "Unable to open file. No header found in .SAV file when in folder with Greek characters"
  • "Greek characters are correct in tables but wrongly encoded in graphs"

jdittrich commented Mar 22, 2017

It seems that this issue should be split in two issues, so that both issues could be investigated and solved independently

e.g. in these:

  • "Unable to open file. No header found in .SAV file when in folder with Greek characters"
  • "Greek characters are correct in tables but wrongly encoded in graphs"
@AlexanderLyNL

This comment has been minimized.

Show comment
Hide comment
@AlexanderLyNL

AlexanderLyNL Mar 22, 2017

Contributor

The plot problem is indeed an R problem. At the moment, we cannot have foreign languages in the plots.

Contributor

AlexanderLyNL commented Mar 22, 2017

The plot problem is indeed an R problem. At the moment, we cannot have foreign languages in the plots.

@aknight1-uva

This comment has been minimized.

Show comment
Hide comment
@aknight1-uva

aknight1-uva Mar 22, 2017

Collaborator

The "No Header issue" strikes me as odd. - It seems like a file has been found (and opened) but the contents of the file are not recognisable as an .SAV file - Which suggests to me the file is damaged in some way. Could you please attach a copy of an SAV file that shows this problem?

Collaborator

aknight1-uva commented Mar 22, 2017

The "No Header issue" strikes me as odd. - It seems like a file has been found (and opened) but the contents of the file are not recognisable as an .SAV file - Which suggests to me the file is damaged in some way. Could you please attach a copy of an SAV file that shows this problem?

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Mar 22, 2017

baltzis commented Mar 22, 2017

@aknight1-uva

This comment has been minimized.

Show comment
Hide comment
@aknight1-uva

aknight1-uva Mar 22, 2017

Collaborator

Sorry Alexandros, I can't see your attachment. Did you attach it to an comment on typed-in on github.com?

Collaborator

aknight1-uva commented Mar 22, 2017

Sorry Alexandros, I can't see your attachment. Did you attach it to an comment on typed-in on github.com?

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Mar 22, 2017

Sorry, I've sent it through an email. Here is the file.
Flexibility scale1.zip

baltzis commented Mar 22, 2017

Sorry, I've sent it through an email. Here is the file.
Flexibility scale1.zip

@aknight1-uva

This comment has been minimized.

Show comment
Hide comment
@aknight1-uva

aknight1-uva Mar 27, 2017

Collaborator

@baltzis : Thanks for the file. There doesn't appear to be any damage to it at all.
@boutinb, @FransMeerhoff Further investigation has produced a possible cause of this issue: The importers (without exception) use a std::ifstream object to read files. With underlying files-systems that support UTF-8 filenames (e.g. Linux or ?OS/X?) this works really well in the presence of Unicode chars in the path/file name. Windows doesn't do this: On Windows, the file system for MBCS (8 bit char) file names reverts to the OEM/code page character set (or did up to Win XP: Vista and latter is anyone's guess, Microsoft seems very reticent on the issue).
In short, the chances of JASP on Windows importing any file with one or more non ASCII character(s) in the path or file name is at best small, at worst vanishingly remote.
The fix would be to replace std::ifstream with the Qt equivalent, assuming it is working properly on Windows builds. Given the age of the Qt libraries used with Windows builds, I would have my doubts about this.

Collaborator

aknight1-uva commented Mar 27, 2017

@baltzis : Thanks for the file. There doesn't appear to be any damage to it at all.
@boutinb, @FransMeerhoff Further investigation has produced a possible cause of this issue: The importers (without exception) use a std::ifstream object to read files. With underlying files-systems that support UTF-8 filenames (e.g. Linux or ?OS/X?) this works really well in the presence of Unicode chars in the path/file name. Windows doesn't do this: On Windows, the file system for MBCS (8 bit char) file names reverts to the OEM/code page character set (or did up to Win XP: Vista and latter is anyone's guess, Microsoft seems very reticent on the issue).
In short, the chances of JASP on Windows importing any file with one or more non ASCII character(s) in the path or file name is at best small, at worst vanishingly remote.
The fix would be to replace std::ifstream with the Qt equivalent, assuming it is working properly on Windows builds. Given the age of the Qt libraries used with Windows builds, I would have my doubts about this.

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Mar 27, 2017

Should I understand this as a final result, saying that there is no solution for Windows in languages other than English?

baltzis commented Mar 27, 2017

Should I understand this as a final result, saying that there is no solution for Windows in languages other than English?

@boutinb

This comment has been minimized.

Show comment
Hide comment
@boutinb

boutinb Mar 27, 2017

Collaborator

@baltzis No, there should be a solution. But first of all, we have to reproduce your problem. I have just tried to make folder with a greek's name on a Windows 7 machine, and I can load a JASP file without problem. We will try on a Windowns 10 machine.

Collaborator

boutinb commented Mar 27, 2017

@baltzis No, there should be a solution. But first of all, we have to reproduce your problem. I have just tried to make folder with a greek's name on a Windows 7 machine, and I can load a JASP file without problem. We will try on a Windowns 10 machine.

@aknight1-uva

This comment has been minimized.

Show comment
Hide comment
@aknight1-uva

aknight1-uva Mar 27, 2017

Collaborator

All we can say at present, is that we cannot reproduce the issue on Windows 7 (English).
For now, it seems the only work around we can offer is one you already have: Keep all your SAV files you wish to read with JASP in a folder whose path contains only ASCII characters (i.e. only those used by a US keyboard). This is an issue that will require some careful thought - In other words will take some time to fix.

Collaborator

aknight1-uva commented Mar 27, 2017

All we can say at present, is that we cannot reproduce the issue on Windows 7 (English).
For now, it seems the only work around we can offer is one you already have: Keep all your SAV files you wish to read with JASP in a folder whose path contains only ASCII characters (i.e. only those used by a US keyboard). This is an issue that will require some careful thought - In other words will take some time to fix.

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Mar 27, 2017

Thank you.

baltzis commented Mar 27, 2017

Thank you.

@aknight1-uva

This comment has been minimized.

Show comment
Hide comment
@aknight1-uva

aknight1-uva Apr 7, 2017

Collaborator

I can reproduce this in Windows 10 (Enterprise, English) using Greek letters in file name.
However the QT Creator required for Windows builds won't run in Win 10 (it GPF's on start-up), even after running qtbinpatcher,exe.

Collaborator

aknight1-uva commented Apr 7, 2017

I can reproduce this in Windows 10 (Enterprise, English) using Greek letters in file name.
However the QT Creator required for Windows builds won't run in Win 10 (it GPF's on start-up), even after running qtbinpatcher,exe.

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Jun 5, 2017

The new version 8.1.2 keeps having the same trouble, but not only with non-ASCII characters in the path name. For some reason, even in a path with only ASCII characters in the path name, I get the following message:
Unable to open file
No header found in .SAV file.

Very annoying, because I would like to use JASP for teaching.

baltzis commented Jun 5, 2017

The new version 8.1.2 keeps having the same trouble, but not only with non-ASCII characters in the path name. For some reason, even in a path with only ASCII characters in the path name, I get the following message:
Unable to open file
No header found in .SAV file.

Very annoying, because I would like to use JASP for teaching.

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Jun 5, 2017

Interestingly enough, when this problem appears with one file once, JASP seems to have problem with any file in the same directory. While at first it opened for e.g. file A, after encountering problem with file B, it does no longer open file A, not any other file in the same directory.

baltzis commented Jun 5, 2017

Interestingly enough, when this problem appears with one file once, JASP seems to have problem with any file in the same directory. While at first it opened for e.g. file A, after encountering problem with file B, it does no longer open file A, not any other file in the same directory.

@baltzis

This comment has been minimized.

Show comment
Hide comment
@baltzis

baltzis Jun 5, 2017

Another interesting detail: the same file can be opened on my 64bit desktop, but on my 32bit laptop. The two computers are connected on a home network. The desktop 64bit computer cannot open the same file from the 32bit laptop when read through the network. The same message appears:
Unable to open file
No header found in .SAV file.

I am not sure whether this additional information helps. I hope it does.

baltzis commented Jun 5, 2017

Another interesting detail: the same file can be opened on my 64bit desktop, but on my 32bit laptop. The two computers are connected on a home network. The desktop 64bit computer cannot open the same file from the 32bit laptop when read through the network. The same message appears:
Unable to open file
No header found in .SAV file.

I am not sure whether this additional information helps. I hope it does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment