I got this error when converting a ipynb file to latex. Looks like there's a hardcoded upper bound on pandoc in nbconvert. Is there any reason why it would work with the latest version?
nbconvert/utils/pandoc.py:52: RuntimeWarning: You are using an unsupported version of pandoc (2.2.1). Your version must be at least (1.12.1) but less than (2.0.0).
Many command line options have changed between pandoc v1.* and pandoc v2, e.g. --smart is no longer recognized as pandoc uses a finer-grained mechanism now. In general, it seems like a good idea to limit the acceptable version.
That being said, nbconvert seems to only use options which have not changed; it is probably save to bump the upper version bound.
Related
I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.
I am trying to get the MNIST dataset in Julia using the MLDatasets package via the following commands in a .jl file:
using MLDatasets
dataset_train = MNIST(:train)
dataset_test = MNIST(:test)
This is what's indicated in the MLDatasets documentation. However, I am getting the following error:
ERROR: MethodError: objects of type Module are not callable
Stacktrace:
[1] top-level scope
# c:\my\julia\file\...
For some reason Julia is interpreting MNIST to be a module. It is worth noticing that this exact same code works without problem in a friend's computer, who has the same operating system, and the same Julia version (OS: Windows, x86_64-w64-mingw32; Julia version: 1.8.2).
The MLDatasets package is installed and does import correctly with the using command. What may be the problem?
The most likely reason is that you have an older version of MLDatasets installed on your computer. The current version is 0.7.5, while you probably have a 0.5.x version installed. This can happen if there are package conflicts that prevent the latest version of MLDatasets from being installed.
If you're using the default v1.8 environment to install all packages, conflicts like this are more likely to happen. It's recommended to instead create a separate environment for your project, and install only the packages you need for that particular project in that environment.
Older versions of MLDatasets had MNIST as a sub-module rather than as a type, which is the reason for this particular error message.
You can compare your environment's status (] status) and the one in your friend's setup. ] status --outdated can also help you see which particular package is causing the issue here. But I would suggest just keeping your base Julia environment (v1.8) minimal, uninstalling packages except the ones that you need to be available everywhere (eg. IJulia). See also the "Creating your own projects" section of the Pkg documentation.
I have built a small command line tool with an Xcode template.
The built works as it should, I can Archive it to obtain an executable quite fine.
What I cannot figure out is where I can set the version number of the binary. I do not have a Info.plist, but I can see several places containing the verb "Version"–none of which will attach a version number to my binary.
What am I missing here?
Command line tools don't have external info like a version number (eg something that would show up in the Finder). You should write internal code that returns a version number when someone calls SwiftyAppleMailCreator --version.
I'm trying to visualize a code base without explicit doxygen comments, I run into what seems like an error when viewing the dot graphs in the html generated by doxygen Generated Boxes
I'm running doxygen under a cygwin bash with GraphViz installed. Any Ideas?
OK, figured it out...the blank boxes should have been a dead give away that the problem was with a missing font dependency. I installed a different version of GraphViz that had the font dependency resolved under mingw.
I'm planning to use doxygen to document a project. It's an OSS project whose current documentation is of questionable quality. The reason I've decided to go with doxygen is because from version 1.8, doxygen has added support for Markdown (text formatter; think we use it on this site too).
A concern of mine is for the people who might end up using older versions of Doxygen (for example, it hasn't been updated in the current Ubuntu LTS release).
Is it possible to add some setting or marking in the Doxyfile (doxygen configuration file), such that it will issue an error/warning if someone tries to generate the documentation using an older version of doxygen?
(Ideally, explaining the cause of error as well)
Doxygen itself provides a sort-of warning for these circumstances. If your doxyfile includes things like MARKDOWN_SUPPORT = YES and the incumbent doxygen is not one that supports markdown, then you do get a warning that the option is unrecognised.
Warning: ignoring unsupported tag 'MARKDOWN_SUPPORT'...
Alternatively, you could implement some script that parses the return from doxygen -v which will either return a handy '1.8.5' or the usage help, including a line version 1.y.z - so something based around doxygen -v | grep "1\." would extract a suitable line.