I'm trying to follow the tutorial Mike Bostock did for Command Line Cartography (which is a great help). Right after installing shapefile and running the shp2json step [shp2json cb_2014_06_tract_500k.shp -o ca.json] I get this error message:
“error: Decoder not present. Did you forget to include encoding-indexes.js first?” an error message which originates from the text-encoding package from NPM.
In trying to diagnoise the problem, I figured I should manually install text-encoding as it's in the shp2json dependency list but, didn't appear to be loading. I also reinstalled node to downgrade from 7.3.0 to 6.9.2 and a number of other things (my hacking around looking for a solution for a few hours) but, am stuck. Is this just a matter of updating a package.json?
I’m using Windows7, the env variables is set I believe correctly to \Users\myAccount\AppData\Roaming\npm. I’ve installed all packages globally as well. Thanks for any insight.
I had the same problem when running the "#prepublish" script here. Then I noticed that Mike's shapefile repo has this information in the README:
# shp2json --encoding *encoding*
Specify the dBASE table file character encoding. Defaults to “windows-1252”.
So I experimented and changed that script to:
shp2json --encoding utf-8 cb_${YEAR}_${STATE}_tract_500k.shp
Note that in this line above my state and year variables had been defined higher in the script (I was using Texas[48], not California[06]).
Also, I was getting another error asking for d3-array. So I installed that, too.
Problem solved (at least in terms of processing the data and getting it to render in the browser). Others issues, like projection, remain. Obviously.
Related
Using a stock install of Chapel (via Homebrew) on a Mac running Big Sur. Tried to compile one of the example programs:
chpl /usr/local/Cellar/chapel/1.27.0/libexec/examples/hello.chpl
followed with
mv: rename /var/folders/81/9s9zv6450td9kgh_znllq52000037c/T//chpl-username.deleteme-nJkMMc/hello.tmp to hello: No such file or directory
error: mv /var/folders/81/9s9zv6450td9kgh_znllq52000037c/T//chpl-username.deleteme-nJkMMc/hello.tmp hello
error: Make Binary - Linking
Looks like a simple fix, but would appreciate suggestions. (And annoyingly, am trying to (eventually!) do a local compile of a package I contributed to)
R.
As noted and verified in the comments above, this seems to have been a recently discovered issue in our code base that can be worked around in homebrew for the time being by doing a brew update. It ought to be fixed in a more principled manner in Chapel 1.28.0 and onwards. If others see this failure mode going forward, please consider opening a GitHub issue on the Chapel repository so that we can help you work through it.
I have a little problem while I want to update my package. I'll explain this: I published my package. After that, I waited for 2-3 hours for my packages be in the microsoft/winget-pkgs in GitHub. My branch merged successfully, It works on any Windows devices but, I created a new version of my application: v3.6.2. The version that I released it was v3.5.7. So now, I can't publish that version because this error is showing when I execute this cmd command: wingetcreate update <packageIdentifier> -u https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe --version 3.6.2 -t ghp_YourGithubPersonalAccessTokenWith_public_repo_setting.
If you want an image, i'll show you the image (My Windows is French btw): Here the image. But as you can see, the red is the error and I tried everything, I searched on Google and didn't find anything that fixed my problem, I tried the examples showed above when you only execute this command: wingetcreate.exe update but still the same error message that you can see on the image.
So I decided to take the third example but same, without success. Is there a way that could update my WinGet package? Thanks!
I don't know if this could help but I can give you some info: it's inno, the achitecture is Neutral.
IMPORTANT NOTE:
FIX HERE
The last answer works but if you type the command winget search <YourApp>, it will keep the previous version and if you install, it would install the previous one... How to fix that because it is litteraly NOT updating but doing nothing.
It's hard for me to know exactly what the issue is without knowing the contents of the manifest or the metadata of the installer. My gut feeling is that there is an architecture mismatch when trying to match the installer you provided with the existing installer that is currently specified in the existing manifest. To override the detected architecture you can use the '|' symbol followed by the desired architecture. Here is an example:
wingetcreate update <packageIdentifier> -u "https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe|x64" --version 3.6.2 -t <githubToken>
If that doesn't work for you, I would encourage you to post an issue on the GitHub repository so we can help you further.
Okay, I found the way: You take the code that the previous answer contains, and add -s:
wingetcreate update -s <packageIdentifier> -u "https://github.com/YourUsername/yourrepository/releases/download/3.6.2/yourapp.exe|x64" --version 3.6.2 -t <githubToken>
It will publish the application on GitHub for verification, in the command prompt you put (replace the sentence in the quotes with your current manifest file):
winget validate --manifest "PathToYourManifestShowedInGreenAfterPublishing"
When the validation on GitHub is done, it's done and normally it should work.
NOTE: Verification on GitHub can take 2 to 3 hours or even 4 hours. Be patient! (I hope)
I am trying to install ezbounce on an SSH Shell. (Host has OK'ed use of the bouncer)
(I do NOT have sudo, however, my host is lenient and I can get things ran. If possible, I prefer a solution that does NOT require sudo or equivalent.)
I have finished ./configure , and am on the make step.
when I go to make the file, it errors with the following:
https://pastebin.com/YetM6nGN
I found a possible solution to the problem here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219298
The solution seems to be centered on the fact that GCC++/GNU make calls its latest version as opposed to the newer one.
They have an included patch, but I am honestly clueless how this gets applied.
Any help fixing the error via here or directly editing the makefile is greatly appreciated.
My makefile: https://www.dropbox.com/s/u75toiigd4v5wgl/Makefile?dl=0
So I had some help from an external source (Thank you discord communities!)
The patch listed above is for FreeBSD ONLY! (As I was made aware)
For Non-FreeBSD Ports, the fix (if your makefile looks like mine) is to edit line 32 to the following: CXX_OPTIMIZATIONS = -std=gnu++98 -O2
There is some error looking items in console that follows, but the build is successful, so I'm gonna assume they are moot.
It honestly was a confusing little puzzle for your average user, but there ya go :)
IntelliJ will not detect installed PHP even though it does exist and can be used from the command line. I have installed php via brew install php54. Below is a screenshot of my issue along with evidence that it does exist. I've tried clicking the refresh button many times, but it will not pick up the binary.
I just had the same problem. Through some hackery, I discovered it was due to some ansi escape sequences in my prompt. From your screenshot it looks like you might have the same or a similar issue.
Essentially, IntelliJ uses a php script to create an XML string out of some PHP configuration items, including $_SERVER. The $_SERVER superglobal contains environment variables and therefore picked up the escape character (0x1b) in the sequence. Since the escape character is invalid in XML, IntelliJ rejected the output and concluded the PHP interpreter was bad.
Once I removed the ansi sequences from my prompt, IntelliJ recognized the PHP interpreter right away.
Hope this helps.
I had the same issue, and it turned out my Homebrew install was severely out of date when I installed PHP. To fix it, I ran:
brew update && brew upgrade
With some quick help from jetbrains support, the latest EAP version fixed it for me: http://confluence.jetbrains.com/display/IDEADEV/IDEA+14+EAP
http://youtrack.jetbrains.com/issue/WI-23045
If you prefer to keep investigating the issue, see Chris' answer and search the idea.log for something like:
INFO - s.impl.stores.FileBasedStorage - Document was not loaded for $APP_CONFIG$/php.xml file is null
idea.log locations
I've just now come back to this after some time and it looks like the latest version IntelliJ works with PHP installed via Homebrew. So I'm going to mark this as resolved.
I'm trying to create my docs with Sphinx, and now on two machines I have the exact same problem: the program-output directive does not work.
I installed Sphinx, then the programoutput extension:
$ sudo pip install sphinxcontrib-programoutput
The installation went fine, documents compile beautifully to nice looking html, but the command-output just doesn't work.
I created a super-simple test case with a file called test.rst containing a single line:
.. program-output:: python -V
Now when trying to compile this, I get the following output (path abbreviated):
/path/to/test.rst:1: ERROR: Unknown directive type "program-output".
Changing program-output to it's alias command-output doesn't work either (not surprising). I really wonder what I'm doing wrong here. I followed the installation instructions, tried it again and again, reinstalled with an --upgrade flag, nothing works.
Thanks to bmu I found the problem, indeed I had to add it to the conf.py.
Now the next question: "why is this not in the installation/usage documentation of this extension?" It's not mentioned in http://packages.python.org/sphinxcontrib-programoutput/ which is the first link I get when googling for this extension.
Anyway the complete answer, hope it's useful for other people too:
Go to the document root of your documentation (e.g. ~/Projects/project-name/doc) where the rest of your documents are.
Edit file conf.py
Look for the line that says extensions = [] (an empty list in my case)
Change this to: extensions = ['sphinxcontrib.programoutput']
And miraculously it suddenly starts to work.