Encountering numba current locale errors?

[vinayprabhu]

`raise NotImplementedError("cannot convert native %s to Python object" % (typ,))
LoweringError: cannot convert native const('\tnn descent iteration ') to Python object
File "../../../../home/.local/lib/python2.7/site-packages/umap/umap_.py", line 663
[1] During: lowering "print($515.5)" at /home/.local/lib/python2.7/site-packages/umap/umap_.py (663)

Failed at nopython (nopython mode backend)
cannot convert native const('\tnn descent iteration ') to Python object
File "../../../../home/.local/lib/python2.7/site-packages/umap/umap_.py", line 663
[1] During: lowering "print($515.5)" at /home/.local/lib/python2.7/site-packages/umap/umap_.py (663)
`
Related to 1.12.3.3 here: http://numba.pydata.org/numba-doc/dev/user/faq.html

[lmcinnes]

Wow, good catch! Thanks for the reference -- it saved me an evening of (probably very frustrating) googling. I think I have it fixed, but I would greatly appreciate it if you can test on your system (if you have time) to ensure that it does indeed resolve the issue for you. Thanks!

[MSiam]

I am encountering the same exact error even after your change.

[lmcinnes]

If that's the case then I must admit I am really not sure what the correct fix is -- this involves numba internals which I am not familiar with. I'll have to try and ask numba developers what the right solution to this is, which unfortunately may take a while. As an interim solution you can check out the code and simply remove or comment out code blocks

if verbose:
    print(...)

Ultimately I would prefer a more complete solution though, as the progress logging is really quite useful.

[sauln]

This is strange. I could try changing the prints to the logging module, but it looks like the problem comes during a string conversion, not the print function.

Does this happen always with python 2.7? Is there a formula for recreating the issue so I can play around with it?

[MSiam]

I am using python2.7 yes. I just ran the examples/digits/digits.py code nothing from my side and it gave this error:

raise NotImplementedError("cannot convert native %s to Python object" % (typ,))
LoweringError: cannot convert native const('\tnn descent iteration ') to Python object
File "build/bdist.linux-x86_64/egg/umap/umap_.py", line 455
[1] During: lowering "print($515.5)" at build/bdist.linux-x86_64/egg/umap/umap_.py (455)

Failed at nopython (nopython mode backend)
cannot convert native const('\tnn descent iteration ') to Python object
File "build/bdist.linux-x86_64/egg/umap/umap_.py", line 455
[1] During: lowering "print($515.5)" at build/bdist.linux-x86_64/egg/umap/umap_.py (455)

Thanks removing the if verbose, made it work.

[lmcinnes]

I suspect the logging module will not play nicely with numba; perhaps this is a python2/python3 compatability issue related to the print function? @sauln if you have some time to look into this I would greatly appreciate it as I don't have a lot of time for the next week or so.

[sauln]

I think it's some combination of print statements and string operations in python 2.

Multiple print arguments like

print("hello", "world")

cause the error and I haven't figured out any other way to format strings in numba.

This issue talks briefly about numba+print, but it was closed without explicit resolution.

I haven't found any way around this problem. There might be something in the numba documentation, but nothing has come up from google searches. I'll try to dig a bit more into this tomorrow.

[lmcinnes]

Thanks Nathaniel, at least we know what the likely issue is. One possibility is to use cffi and get the printf function from C to do the formatted printing, but that adds an extra dependency on cffi. Another option would be to explicitly write a very constrained function to do the limited format of printing we need and call that instead. I would welcome other ideas as neither of those seem optimal.

[sauln]

It might be hacky, but it should be possible to require cffi only for python2.7. That would force maintenance of two different logging systems though. As a first step, it's probably easiest to disable all logging on 2.7.

What do you think about having different behavior for 2.7 and 3? It's not ideal, but at least that way, 3+ could have complete and pretty logging.

[lmcinnes]

I'm good with just disabling logging for 2.7 for now -- if you want to make the PR I'll happily accept it.

…

On Wed, Nov 29, 2017 at 2:35 PM, Nathaniel Saul ***@***.***> wrote: It might be hacky, but it should be possible to require cffi only for python2.7. That would force maintenance of two different logging systems though. As a first step, it's probably easiest to disable all logging on 2.7. What do you think about having different behavior for 2.7 and 3? It's not ideal, but at least that way, 3+ could have complete and pretty logging. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALaKBbuwVw3gOKCSjG5sjRx3dECeLr0yks5s7bHzgaJpZM4QsgTs> .

[sauln]

I’ll look into it tonight.