When I try to "import simplejson" (or something that depends on it) in IronPython 2.0, I get "LookupError: unknown encoding: hex". How do I make this work?
The workaround for this is to import the hex codec manually before attempting to import the broken dependency:
from encodings import hex_codec
The issue is being tracked by IronPython, but so far, they claim it's a bug in the standard Python library.
Thanks, sblom. I think IronPython crew are right in saying its a bug in the standard library (or at least Freeze tool as of 2.7). Problem occurs with "frozen" programs iffrom encodings import hex_codec is not explicitly written in the script.
Sorry to 'necro-post', but this issue I feel was relevant, at least in regard to the Freeze tool.
Related
I am working on a fully cython compiled python package, using setuptools and some reStructured Text docstrings to generate the pdf documentation using sphinx-autodoc with good success.
The docstrings are not displayed when loading the package in Jupyter Notebooks (using Pylance language server in VSCode). I did not test but suspect that the issue exists in other IDEs or frontends either. Switching to e.g. Jedi as a language server in VSCode did not help.
Using the help(...) command on the routines/classes yields the expected docstring, so the issue does not seem to be with the cython compilation.
There are quite a few issues about formatting issues popping up when searching for Docstrings and Pylance, the issue never seems to be that they simply can not be retrieved.
Since sphinx (autodoc) does not throw any errors and generates a full-package encompassing documentation set fine, this seems a lot like a problem with the language servers to me.
However, I suspect that there may be any compiler directive or setuptools option that I am unaware of that could help - but I do not know about these.
I do have
compiler_directives={'embedsignature': True}
in the setup.py and since the docstrings do show up when using help(..), I do not think this is an issue.
I have also added
import Cython.Compiler.Options
Cython.Compiler.Options.docstrings = True
even though that is indicated as being the default, and it did not change the behavior at all.
Scavenging through the options of Pylance in VSCode was unfruitful, too - I did not expect much there anyways, since obviously the display of the docstrings does work for plenty (all?) other packages that I looked at. Everything is on defaults.
What's the difference between the Perl JSON modules below?
I have come across JSON::PP and JSON::XS. The documentation of JSON::PP says it is compatible with JSON::XS. What does that mean?
I am not sure what the difference between them are, let alone which of them to use. Can someone clarify?
Perl modules sometimes have different implementations. The ::PP suffix is for the Pure Perl implementation (i.e. for portability), the ::XS suffix is for the C-based implementation (i.e. for speed), and JSON is just the top-level module itself (i.e. the one you actually use).
As noted by #Quentin, this site has a good description of them. To quote:
JSON
JSON.pm is a wrapper around JSON::PP and JSON::XS - it also does a bunch of moderately crazy things for compatibility reasons, including extra shim code for very old perls [...]
JSON::PP
This is the standard pure perl implementation, and if you're not performance dependent, there's nothing wrong with using it directly [...]
JSON::XS
Ridiculously fast JSON implementation in C. Absolutely wonderful [...]
As you can see, just installing the top-level JSON module should do it for you. The part about compatibility just means that they both do the same thing, i.e. you should get the same output from both.
I installed the Perl JSON module a few years ago on a RHEL server I managed and it was a really straightforward process: just install (or build) the module from the CPAN site and you're done.
Installing should be a simple case of either using the OS package manager (if in GNU/Linux), using the cpan utility, or building from source. The OS package manager is recommended, as it helps keep things updated automatically.
To verify that it's installed, just try the following command from the terminal (assuming GNU/Linux):
$ perl -e 'use JSON;'
If it doesn't complain, then you should be good to go. If you get errors, then you should get ready to go in an adventure.
You can install JSON module, cpan install JSON
use JSON;
my $result = from_json($json);
if($result->{field})
{
# YOUR CODE
};
How to solve Scala Problem?
I have warning by JSON usage in my project:
Object JSON in package json is depricated. This object will be
removed.
import scala.util.parsing.json._
JSON.parseRaw("[{'a':'b'},{'c':'d'}]")
Usually, this means a piece of functionality has been superseded by another implementation the use of which is preferred over the old one and a question like this simply means the OP is too lazy to google the docs. This is especially true in case of libraries in the Java language, which treats backward compatibility very seriously (to the point it becomes a pain for some). The Scala ecosystem is not so strict in this regard and upgrading to a newer version of the language means you can get a different API or even binary incompabilities. See also Scala: binary incompatibility between releases. This is not a comment against Scala. There are good reasons these incompatibilities exist.
However, I must admit that the documentation for scala.util.parsing.json does not contain any information regarding the recommended replacement for this functionality whatsoever. It took me quite a while to dig up something that just barely resembles a clear statement of what the recommended replacement is.
There seems to have been a lot of discussion in the community about the point and repercussions of this deprecation. I recommend reading this thread in the scala-users group if you're interested.
The most quoted reasons for this deprecation seem to be around poor performance and thread safety.
The deprecation was done as part of this Jira issue and the use of different parsers is recommended in the closing comment of this related task that was not completed due to the deprecation.
Alternatives include:
play-json
spray-json
argonaut
jackson
rapture-json (which allows you to choose between different implementations)
To answer your question. This is a warning, your code should not break until this object is actually removed. However, if new bugs are found in this functionality, they most likely aren't going to be fixed. Your code can also break if you upgrade to a newer version of Scala that actually has those packages removed (Version 2.11.0 and above, according to the documentation)
The answer previously provided by #toniedzwiedz is very complete and describe the whole story around the question.
I just had the same issue using Scala 2.11 and I solved adding the dependencies which are in this repository.
In particular, for Scala 2.11 is:
<dependency>
<groupId>org.scala-lang.modules</groupId>
<artifactId>scala-parser-combinators_2.11</artifactId>
<version>1.1.0</version>
</dependency>
Then you will not have the warning.
Also considere using Lift JSON as an alternative
https://github.com/lift/lift/tree/master/framework/lift-base/lift-json/
The JSON parser in the Scala standard library is deprecated. You should pick one of more robust third-party libraries like Jackson, Play-Json, json4s, etc.
I'm starting using Bugzilla to manage some bugs. I spent hours to look for how to import bugs from CSV because this function is introduced. PLus, I cannot find where that function is, too.
Can anyone know this! Help me.
There isn't any way to directly import bugs into Bugzilla via CSV files. There are 2 options:
1) Convert your CSV file to Bugzilla XML and use the importxml.pl script
https://www.bugzilla.org/docs/4.4/en/html/api/importxml.html
2) Use your favorite programming language and the Bugzilla API to read the bugs from your CSV and insert them into Bugzilla.
https://www.bugzilla.org/docs/4.4/en/html/api/Bugzilla/WebService.html
importxml.pl will only be useful if he has shell access to the server. This may not always be the case.
Using his favourite programming language and the Bugzilla API to read the bugs from CSV and insert them into Bugzilla may be easier said than done. If perl is installed, I would suggest looking at https://github.com/c-alpha/bzimport for a start.
I'm trying to translating the MySql C connector 6.02 headers to D, but I get some weird crashes.
My guess is I've made some mistakes on translating the structs or function (I'm not very good at C).
I used implib /system on the libmysql.dll to create a lib file.
I couldn't get htod.exe to work. Using -hs (include system files) complained it couldn't find system files.
Coffimplib.exe didn't have an option to prepend _ to exported internal names.
I couldn't find a free version of coff2omf.
mysql.d is the wrapper. I've included the C definition before each wrapped definition to easier spot bugs. The file includes the mysql dll and converted libfile too.
When compiling mytest_fails.d it crashes. mytest_works.d only has an assert, and this makes it work.. Compiling mytest_works with -release makes it crash too.
I've been using dmd 2.051
Download mytest.zip from share1t.com
Update: I've also asked some question regarding this on the D.learn newsgroup, but I don't think anyone has gone through the code.
C Const
Compiler extensions
Connot get htod.exe to work
The weird crashes
stdcall is a Windows function calling convention (very different from the C calling convention). HTOD failed to mark several functions with extern(Windows). This is normal, since HTOD isn't equipped to handle macros (STDCALL is defined as a macro, I can see that from the leftover comments in msyql.d).
Here's an updated mysql.d file:
http://dl.dropbox.com/u/9218759/mysql.d
Now, you need the proper import library in OMF format. I'd generally advise that you do not use implib for this. I've had several problems with it and others have reported having problems using it. Using coffimplib is the way to go. But first, you will need a COFF import library.
If you need it, the Mysql release with the COFF import library can be downloaded from here: http://dev.mysql.com/downloads/mirror.php?id=377977#mirrors (Libraries in DLL form marked for Visual Studio usually come with a COFF import library).
But I'm providing you the translated COFF import library in OMF format here: http://dl.dropbox.com/u/9218759/libmysql.lib
I've tried both of your test cases and they both seem to work fine now. In case of problems, try to check the translated header file again (mysql.d), it's possible that I might have missed to specify all the calling conventions properly.