I would like to import csv files on stata. I do not understand why it does not work, I obtained : stacktrace not available
What should I do?
you cannot have non-ASCII characters in the STATA installation path. Up to now, Stata still requires ASCII.
Related
I have a problem with unzipping files. Usually I use a PowerShell script, that I run through SQL Server database (procedure) and it will unzip my files how I want them (database shouldn't be any issue).
Main part of script:
exec '"for %i in ("'+#path+'\*.zip") do "C:\Program Files\7-Zip\7z.exe" x "%i" -o"'+#to+'""'
But for once in a while there is a .zip file that if run through this script will extract files with names of files encoded badly and to prevent that I need to manually open every .zip file and click to extract in 7-zip GUI and that will returns names of files correctly.
This manual way of doing things very, very slow. Because it needs to be done on a server, God forbids if I am on VPN at home. So let's say I have 5 zip files (3 GB), it will take me hours to unzip. If I do it, through server it takes like 2 minutes.
So I just trying to find out how to unzip it with script, what is the difference between my script and manual extraction?
The root-cause is likely to be files that were created with a setup that doesn't match the codepage of your windows environment. Are any of the zip file publicly available? If so, can you provide a link?
To deal with these problem files, you need to know what encoding was used for the filenames. If the 7z gui can handle these files automatically there must be an option to tell it what encoding to use.
Once you know the encoding you can use the -scs option in 7z to decode the filenames correctly.
Modern zip files don't have this issue because they store filenames in UTF-8.
I need to convert a OWL ontology to OBO.
I've tried this tool https://github.com/ontodev/robot/ but the output format isn't correct at all, just some parts.
Also OBO-EDIT2 and Protegé but the weren't able to do a conversion.
Lastly I've tried this Perl module http://search.cpan.org/~easr/ however it gives this error
Undefined subroutine &XML::Parser called at /usr/local/share/perl/5.14.2/OBO/Parser/OWLParser.pm line 146.
And trying to install XML::Parser always ends with an error.
Could anyone help me to convert the Ontology?
Have you tried https://github.com/owlcollab/owltools/?
And trying to install XML::Parser always ends with an error.
What commands are you running to install XML::Parser? What is that error? Can you install other perl modules ok with the same commands? What about ones which require make?
If you're using OWL API, OBO is one of the supported output formats. It is sufficient to pass an OBODocumentFormat to the saveOntology() method.
I am trying to add a file with unicode name to my installer , when I copy and paste or insert the filename , it gives ??????.pdf as characters, so in compilation it couldn't recognise the file and failed to open it .
File: failed opening file "..\???? ????????.pdf"
Any idea will be appreciated
With NSIS 2 all filenames have to be encoded in the active codepage (CP_ACP) and it will generate an ANSI API installer so the codepage on the end-users machine comes into play as well.
The NSIS 3 compiler is Unicode but to generate a Unicode installer you need to add Unicode true to your .nsi script.
Do you use the standard NSIS version (2.46)?
Maybe you can try the Unicode NSIS or the new (alpha!) Version NSIS 3.0a2.
My code generates an excel 2007 file (.xlsx) from a data structure.
I am using Excel::Writer::XLSX module to create the excel file and to populate the workbook.
Although the code is working fine with 32bit active perl, while opening the excel, Excel 2007 is throwing error "An attribute value must not contain '<'."
Although the same code when executed using 64bit active perl produces excel without any issue.
Any pointer to what might be the reason will help?
Although the same code when executed using 64bit active perl produces excel without any issue.
Based on the error I'd guess that you aren't using the same version of Excel::Writer::XLSX with the 32 and 64 bit ActivePerls.
At the level the warning occurs at the code is pure Perl so there is no binary or 32/64bit issue that would cause this.
I would suggest ensuring that you have updated to the latest version of Excel::Writer::XLSX and testing again.
Also, it looks like the ActiveState repos for Excel::Writer::XLSX are significantly behind CPAN so make sure you upgrade the module from source and not via PPM.
If the issue still occurs then reduce the program down to the smallest amount of working code that demonstrates it and submit a bug report.
I want to generate a ER Diagram sort of, of my spatial database i created inside of Postgresql. As i am also new to Postgresql, i am not too sure if the diagramming functionality can be done using whats offered by the PgAdmin (not referring to the Graphical Query Builder). However, it seems to me there is none. I read around that there is a perl based tool called postgresql_autodoc that can run through PostgreSQL system tables and return HTML, Dot, Dia and DocBook XML which describes the database. Now this is not exactly what i wanted but its the closest option i have. So i have successfully installed, ActivePerl 5.8 and DBD-Pg 2.10.0 for Perl 5.8 (DBD PG is a Perl DBI driver for the PostgreSQL database) and i have also downloaded the postgresql_autodoc.pl file. I have also added the path for Perl. But when i try to run the postgresql_autodoc.pl via the command prompt, i was getting this error: Possible Unintended Interpolation of #TEMPLATE in string at C:/Perl/bin/postgresql_autodoc.pl line 1831. Global symbol "#TEMPLATE" requires explicit package name at C:/Perl/bin/postgresql_autodoc.pl line 1831. Execution of C:/Perl/bin/postgresql_autodoc.pl aborted due to compilation errors.
I tried to view the postgresql_autodoc.pl using notepad++ however i have no experience with the perl language and so i cant figure out what is really wrong. All i could do is locate line 1831 but i dont know what i should do to fix this problem.
The postgresql_autodoc.pl file was downloaded from: http://www.rbt.ca/autodoc/
I would appreciate if anyone can help me here!
Thanks in advance
Barbara
That thingy, ##TEMPLATE-DIR##, is a string that is replaced when you build and install the module -- meaning you're not supposed to run it directly from the unpacked archive.
Most Perl modules are installed with a more or less simple three-step installation process, something like perl Makefile.PL ; make ; make install. However, this package is slightly different, you seem only to need make install.
Note that I have no experience with installing Perl modules on Windows with ActiveState. So the above may not work (e.g. if there's no make utility which is usually not part of Perl -- though it might be part of the ActiveState Perl distribution).
But there's a workaround. You can simply do what the install script does and replace the ##TEMPLATE-DIR## string yourself. It can be done easily with any text editor by replacing the two occurrences of ##TEMPLATE-DIR## with the path to where the postgresql_autodoc.pl script has been unpacked to -- meaning it's the path the script will look for the *.tmpl files in.
Note that Windows path names can be written with forward slashes in Perl, meaning C:/Temp/postgresql_autodoc should be OK.