working with pymc3 in ipython4 I get some errors that concern the api of ipython:
ShimWarning: The `IPython.html` package has been deprecated. You should
import from `notebook` instead. `IPython.html.widgets` has moved to
`ipywidgets`. "`IPython.html.widgets` has moved to `ipywidgets`.", ShimWarning)
./lib/python3.4/site-packages/IPython/utils/traitlets.py:5: UserWarning: IPython.utils.traitlets
has moved to a top-level traitlets package.
warn("IPython.utils.traitlets has moved to a top-level traitlets package."
Is this part of the api sufficiently stable that I is worth to try to stabilize the code on it or is it still under heavy development ?
This is an issue with IPython's API. There is a pull request awaiting merge that eliminates this warning.
Related
NuGet.Protocol.Core.Types.FatalProtocolException: Unable to load the service index for source https://botbuilder.myget.org/F/experimental/api/v3/index.json. ---> System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).
I'm not 100% sure which package references that URL. Browsing to it manually does in fact prompt for log in. Navigating to the subdomain makes this seem like an 'official' Microsoft channel.
Attempting to update all nuget packages is a mess (x package needs y package at version 1, but z package needs y package at version 3). I'll spend some time updating them one-by-one, but knowing which package is relying on that URL would give me a place to start.
How can I tell which package is using this url? If someone from the BotBuilder team reads this, what should I be watching to make sure I stay on top of deployment breaking updates?
I am using the Virtual Assistant template. As Dana V pointed out in the comments, the Microsoft.Bot.Protocol.StreamingExtensions package was the problem. This package is needed for voice support in that template at the moment. Since I'm not using voice support I just needed to comment out the DefaultWebSocketAdapter class. Then I needed to comment out a line in Startup and change the initialization of MainDialog. There might have been some other minor errors, but nothing a // couldn't fix.
pysnmp-4.4.4.tar.gz is not available in the following path
https://pypi.python.org/packages/source/p/pysnmp/pysnmp-4.4.4.tar.gz
but I am able to get older releases.
Any idea why?
I guess this has something to do with the recent PyPI overhaul. But the package is available through both web UI and pip.
Where do you get this direct link? May be it is not stable and should not be hardcoded anywhere?
I am trying to figure out how to package an unchanged fork of VS Code.
My first steps were to follow the electron application distubution documentation, which has not been successful. I also found this post, where another user had the same question. However, the vscode-win32 gulp task seems to have been replaced by x64 and ia32 versions, and when I try running these tasks they generate an out-vscode folder as opposed to a full electron project.
This led me to believe that I can use this new out folder (as well as node modules, packages.json, etc.) with the electron release being used by VS Code to mimic the resources/app folder from the installed version of VS Code in Program Files, however when I try running electron.exe using this method I get:
The factory method of "vs/code/electron-main/main" has thrown an exception TypeError: Path must be a string. Received undefined
In short, I have been struggling with this for a couple of days, and I am out of ideas. If anyone has packaged the project and can offer a suggestion for how to do so, I would really appreciate it.
SOLVED
The issue seemed to be due to being branched off of master as opposed to release. I'd assume there are changes in main that aren't accounted for in the gulp task.
For anyone confused by my post, the expected behavior for a successful build is for a folder named VSCode-win32-x64 to be generated in the directory where your vscode clone is located.
In emacs, I am trying to get jedi:complete to work with theano. To do so, I have the following minimal bit of code.
from theano import shared
state = shared(0)
state.#
When I place my cursor at the # sign, and run m-x jedi:complete, I am met with the following error, and no autocompletion is offered.
deferred error : (error "\"TypeError(\\\"unhashable type: 'list'\\\",)\"")
I wonder if this is an incompatability with a source file in theano and jedi. But I am not sure, and I do not know what to do to further resolve the issue.
I get a similar error when I try to use company-jedi.
I have installed all of my packages through the packages-list-packages command, and they are updated with the latest versions.
I resolved this by looking through m-x packages-list-packages and seeing that there was (for some reason) an old deprecated version of jedi installed alongside another version of jedi. I deleted all the deprecated installations I had, and the error has gone away, but jedi doesnt seem to be able to autocomplete the above code still. It now just says No completion found.
I am wondering how can I ensure that my bower version configuration will be workable in the future?
E.g. I have already touched multiple projects, which either tell to use
">=1.0.0"
"~1.0.0"
Afaik the
">=" tells that all versions above 1.0.0 are fine
"~" tells all versions/minor updates on 1.0.x are fine
To be more specific:
"dependencies": {
"angular": ">=1.3.0",
"bootstrap": ">=3.2.0",
"jquery": "~2.1.0",
}
Of the day of writing this code following version configuration was included:
angular: 1.3.1
bootstrap: 3.2.0
jquery: 2.1.0
today you will get included:
angular: 1.4.0
bootstrap: 3.3.4
jquery: 2.1.4
From the point of the developers integration of the lib this features are fine on the beginning of the development. You have not to mess around with the painful dependency management of the libs and versions. But as soon as it gets tested the version should be fixed to defined versions.
I have already touched multiple projects which got broken after a very short period of 3 months, since the libs got updated to different versions, which either are incompatible to each other or some features got broken. So either the build was not working any more or even more bad, issues arise on client side.
What is the best practise to get rid of such version issues on the long term projects?
At the moment there is none, if your only option is bower. A lockfile a la composer or a shrinkwrap mechanism a la npm is in the works however it seems to have stalled as there are currently not enough contributors/maintainers to test the feature and maintain it in the long run.
UPDATE:
Since we now have yarn you can opt to use that, which uses a lockfile mechanism as the default behaviour. The only caveat is that it uses the npm registry which means that either some packages haven't been registered there yet, or have been namespaced like Google's Polymer which you might have to watch out for.
My get-t-go method is using exact versions,
don't let your dependency tool decide what version is best for you because they (and other people) are usually wrong.
What I mean by that is, and I have seen this plenty enough on bower. That one day you get version A.B.C and the next day you might get A.D.F and A.D.F conflicts with some other dependency you have. This can introduce all sort's of problems.
Best is to do handle all your upgrades yourself and test this yourself.
I have yet to see a project where UI and javascript testing was automated in such a way that this was done reliably.