* Stage 1: Go to python 3 for OS X.
* Resolving prompt-toolkit conflict.
Somebody (not sure who) wants prompt-toolkit version to be between 1.04 and
2.00, but jupyter-console needs at least v2.00. First try - use a higher IPython
version.
* Try to force prompt-toolkit version on OS X.
Trying fix suggested in issue #370 (https://github.com/jupyter/jupyter/issues/370).
* Wrong operator for pip install prompt-toolkit.
* Play with IPython version, remove potentially redundant ipykernel install.
* Now we can't find jupyter on OS X.
The install looks good, though.
* Python 3.7.6 is still a release candidate. Sigh.
* Get serious about setting the PATH with pyenv.
* Is the shell set up for pyenv virtualenv?
* ELPA and emacs 25 are not getting along.
* Restarting the shell is a bad idea.
* I suspect the issue is with package gpg signatures.
* Try emacs 26.3 for OS X build.
* ein-ac: Fail silently for unexpected ein:completion-backend values.
Fixes#608, though we really need a test cases for completion in polymode.
* Only define ein ac-sources when the user explicitly sets the backend.
* Test case for issue #608.
* Only test jedi completion when testing polymode.
* Add epc dependency for emacs-jedi.
* Flanging up with travis is always a challenge.
* Forgot to update the scenario.
* Give jedi time to install.
* Add virtualenv to travis OS X build.
Also add some addition TOX environments for future testing cases.
* OS X travis is failing - is it a timeout issue?
Update help message in travis as well. Get rid of case-fold check for the
moment. It works fine locally, but travis can't seem to wrap its head around the
test.
Generally, ob-lang modules cannot require org, else it gets into
infinite require loop.
This begs the question whether ob-ein is really used by anyone.
* ob-ein: Bring back old functionality.
Bring back some old features to babel edit buffers while trying to respect
recent addition of polymode support.
* Override polymode if the user really wants.
Polymode is really for notebook buffers in any case, but this will override
whatever completion backmode a user has configured for python-mode.
* Install cask using python2.
For now python2 is the easiest option for testing on Windows since cask does
not properly support python3 when in Windows.
* Let's throw in the ert-runner, see what happens.
* Can I use my fork of cask?
Work around smartrep weirdness, try to live without command line wildcard
expansion.
* Get the url for the fork right.
* Experiment with python37, use test_script.
* Unstick appveyor, I hope.
* Fix parsing error.
* test_script is not executing. Why?
* Add ert testing.
But why are the test_script commands not executing?
* tasks: Automate building and testing using invoke.
Invoke leverages Python, which I hope will allow us to abstract out differences
in platforms when it comes to building and testing ein.
* Use invoke on appveyor.
* appveyor: Use the environment python.
So we can test versions other than python 2.7.
* Parsing error.
Is
https://packaging.python.org/guides/supporting-windows-using-appveyor/#setting-up
lying to me?
* Quote commands, just in case.
* Get python onto the path.
* Appveyor is catching up to travis.
* Parsing error.
* Update pip, try to get quoted syntax right.
* Still not liking my pip call.
Last try, next step we go to a requirements.txt file.
* Go to using a requirements file for pip.
* ecukes needs bash to work.
* Cleaning up and fiddling.
Seems like the emacs-jupyter guy has his act together - maybe we can take some
inspiration for our appveyor config.
* Syntax error in environment.
* More syntax errros.
* Maybe we need quoting.
* I give up.
* Formatting and cleanup.
* Add customization, yet another syntax error.
New customizable variable `ob-ein-babel-edit-polymode-ignore' to override
keybinding for \C-c\C-c in an org source code edit buffer.
* John learned some Powershell today.
* Fix the executable path.
Sometimes there is more than one curl installed on the system, make sure we can
account for that in testing.
* Handle updating the path inside invoke.
* Report which curl we are using before starting functional tests.
* Enable RDP so we can see error logs.
* Keep the build alive even when it finishes.
* Fix#568.
Apparently we need to specify the user agent when on windows, otherwise tornado
will start throwing 403 responses. Currently using Mozilla/4.0 as the agent, but
might be a good idea to make this value customizable.
* Clean up emacs config.
* Why is appveyor dropping the xsrf token?
* xsrf cookie found, what does the header look like?
* Try different user-agent header, reenable rdp.
* JSON encoding issues on Python side, it appears. Let's try an older Python.
Login works, contents query to get notebooklist works (i.e. GET on
/contents/api), but creating a notebook (i.e. POST on /contents/api) fails with
invalid JSON. ein and emacs-request appear to be generating the proper json, but
jupyter notebook does not see the same thing that is being written. Could be
bytes vs. text issue with modern v3.x python, so let us see how this all works
with Python 2.7.
* Python27 does not have pathlib out of the box.
* Make amends with Python27
* Back to python37.
Tornado/notebook still isn't reading the POST'ed json correctly.
* Do we need to specify content type?
* Must be selective in specifying application/json content.
* Re-enable rdp.
* Let's try a different curl.
* Ensure most recent curl is on path
* Try a different path.
* Try to warn user if suspicious curl detected.
* Remove debugging statements.
* EVM depends on trusty for 26.x
See issue #125 (https://github.com/rejeep/evm/issues/125). Let's hope I got the
travis.yml syntax right.
* Minimal support for ecukes from invoke.
* Cleaner server shutdowns, better ecukes support from invoke.
Use the /api/shutdown REST API call now to shutdown running server. Also support
more command line options for ecukes from invoke.
* Almost full support of ecukes using invoke.
But! Also disabling integration testing for the time being until I understand
why ecukes fails even though everything else is working.
* Just do integration and functional testing on appveyor.
Better than nothing while I work out what is breaking the integration tests.
* Documentation chasing the commit tail.
* This really belongs with the project.
No longer 100% up to date, but worth including if nothing more than for
historical purposes.
* Update ob-ein documentation.
* Fix testing for emacs 27.
Shouldn't setq a structure accessor.
* Add the changelog.
* Workaround for issue #559.
Force ein to use an earlier version (0.9) of websocket.
* Update to v0.16.1
* Add changelog.
One of these days I will remember.
* Get my links right.
* Revert now that websocket is working again.
* Doc updates, dependency updates, prepare for another release.
Make sure we point to a working version of websocket. Documenting some changes
so we can release v0.16.2.
* Make sure we get all the documentation changes in.
* Latest IPython version is 7.5.
Update travis accordingly.
* Testing for shared eval and connecting buffers.
* Forgot the feature.
* Need a small delay to make sure code is evaluated.
* Testing for shared eval and connecting buffers.
* Forgot the feature.
* Need a small delay to make sure code is evaluated.
* Add scenario for company completion in a connected buffer.
* Works better if we test completion first.
* Update ipython version tested in travis.
* Stab in the dark to fix travis erroring under ipython 6.x
* Revert "Stab in the dark to fix travis erroring under ipython 6.x"
This reverts commit 7255d31fdb.
Do not assume python... leverage ESS to improve R interaction.
Fix both undo and fontify in the presence of toggling cells (`C-c
C-t`)
Fix and test switching kernels
Merge the login and open commands (open aliased to login). Add login
tests described in #352.
Attempt to improve user experience by synchronously executing
`ein:jupyter-server-start`. `ein:dev-prefer-deferred` custom variable
allows easy switch to compare sychronous versus old asynchronous behavior.
For whatever reason, emacs-26.1-travis consistently fails to download an ess
dependency.
`Dependency ess failed to install:
https://melpa.org/packages/julia-mode-20180816.2117.el: Bad Request`
Remove emacs-26.1 from the build matrix until I figure this out.
```
"http://localhost:8888"
"http://localhost:8888/"
"http://127.0.0.1:8888"
"http://127.0.0.1:8888/"
"8888"
8888
```
Ideally these should converge to the same thing. Since many hash
tables are keyed off `url-or-port`, forgetting to
normalize `url-or-port` with `ein:url` leads to missed cache hits and
general malaise. So we try to do that.
Address a FIXME: apply callbacks to `ein:notebook-list-login-and-open`.
Removed py3.5 from travis build matrix to reduce developer strain.
Use deferred and callbacks instead of `:sync t` for tkf requests which
is known to have issues. Query server attributes once on
notebooklist-open to avoid sequencing issue #176 (but allow Resync).
Under curl backend, a second request for the same "key" as a pending
request will abort the latter, which has resulted in a clobbered
curl-cookie-jar file, so merely warn and don't abort.
Fix#176
1. no need to install git explicitly.
2. install emacs before `cask install`, otherwise the cask packages
are installed for system emacs.
3. pip installation as root, otherwise the debug session
travis_run_install hangs with 'Permission Denied'.
