Flow seems stuck parsing files on startup - flowtype

I use flow for a large JS project of mine. It used to work fine, showing errors in vim. But something happened in the last few months where it stopped reporting any errors (but still compiling fine using babel). When I started investigating, the issue seems to be that the flow server never finishes starting, for whatever reason. I have updated my flow-bin and flow-typed (sudo npm install -g flow-bin && sudo npm install -f flow-typed). When I attempt to start flow, I see the following message indefinitely (as number of parsed files keeps climbing to ridiculously high numbers):
Please wait. Server is initializing (parsed files 132568): /
It seems that both vim and atom editors I tried keep running into the same exact issue (vim silently, and atom actually shows a spinner claiming that flow is initializing. This is what my .flowconfig looks like:
[ignore]
.*\.git/.*
.*/public/*
.*/scripts/*
.*/dist/*
.*/cypress/*
.*/uploads/*
[untyped]
.*/node_modules/*
.*/lib/*
[libs]
flow-typed
[lints]
sketchy-null=warn
[options]
suppress_comment= \\(.\\|\n\\)*\\#flow-ignore
Currently installed versions:
❯❯❯ flow --version
Flow, a static type checker for JavaScript, version 0.116.1
❯❯❯ flow-typed --version
3.2.1

Try to update [options] section in .flowconfig with:
sharedmemory.hash_table_pow=21

Related

Fedora 30: GTK fails to load appmenu-gtk-module

I am learning to program in Python and Rust. On different versions of Ubuntu these programs compiled and ran perfectly. Now that I have a dedicated Fedora 30 KDE system, every time I try and build a program, I get a warning: Failed to load module "appmenu-gtk-module"
I have tried looking this up and have re/installed anything GTK on my system. The programs otherwise function well, but no menus are drawn. I was also trying things in GNOME and hit the same thing.
I am also using QT. Those programs also build and run fine, but again, no menu.
I'm going bonkers with this. Any help is appreciated.
The appmenu-gtk module is not packaged on Fedora. (GNOME doesn't support them anyway.)
The real questions are:
Why is it configured to load? Did you copy or share GTK config files from an Ubuntu system? You should remove this module from your settings.
Even with improper configs I don't believe this should result in menus not appearing. It should just fail to load and work as normal. How is your application using menus?
I finally got so fed up with getting this error that I went full nerd-diagnosis, and ran this command to find out which file contained the errant reference to the appmenu-gtk (the package that would provide this is not installable on my system either).
(Replace "dolphin" with the command that is giving you the error.)
strace -e openat,access dolphin 2>&1 |grep -v ENOENT |awk '/appmenu-gtk/ {exit} !/appmenu-gtk/ {print}'|cut -d '"' -f2 |sort|uniq|xargs grep appmenu-gtk 2>/dev/null
This will then give you a list of files which contain the line appmenu-gtk, and in my case it was ~/.config/gtk-3.0/settings.ini. From there I just commented it out, and that gets rid of the error message (not sure if this will fix your problem of not having any menus, but you might just be able to edit that line to fix it in another way if commenting it out doesn't work).

Executing opkg post install script after image installation

We are creating a filesystem image in BitBake and one of the packages requires that its post install script be executed on the device, after the image itself has been installed on the device, and not while the rootfs image is being generated by the build server.
Looking at the package with "opkg status ", it says that the package has been successfully installed -- "install ok installed". However, none of the side effects have been performed, and simply running the .postinst file from /var/lib/opkg/info/.postinst works and reports no errors.
How do I get this to work? It seems that the package is being "installed" in the rootfs image with the incorrect status.
Please see Dev manual section Post-Installation Scripts: With recent Yocto (>=2.7) you can use pkg_postinst_ontarget_${PN}() when you know your script should always run on target during first boot, and never during rootfs generation.
On older Yocto version you can just do what pkg_postinst_ontarget_${PN} does manually in your function pkg_postinst_${PN}():
if [ -n "$D" ]; then
echo "Delaying until first boot"
exit 1
fi
# actual post install script here
$D will be defined during rootfs generation so the postinstall script will fail. This means the script will be run again during first boot on target.
The best option is still fixing the postinstall script so that it works during rootfs generation -- sometimes this isn't possible of course.

Odd ld warning from rstudio

while i tried to install packages on Rstudio,I kept encountering the ld warning like this:
ld: warning: text-based stub file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation.tbd and library file /System/Library/Frameworks//CoreFoundation.framework/CoreFoundation are out of sync. Falling back to library file for linking.
Does someone know how to fix this?
Reinstalling CommandLineTools doesn't work for me.
These warnings were caused by the frameworks in /System/Library/Frameworks/.
The solution
Links the recent frameworks from MacOSX.sdk to /Library/Frameworks/.
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework /Library/Frameworks/
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Security.framework /Library/Frameworks/
First, you can safely ignore those messages. This is a known condition after the installation of Mojave (macOS 10.14) or the macOS 10.13.6+ updates.
You can try to remove them by having the OS regenerate the compatibility files (Apple uses a different library format for macOS app development but has a compatibility layer for "normal" development). To do that, set aside abt 8 minutes on a fast internet connection, open a command-line prompt (Terminal/iTerm) and do:
sudo mv /Library/Developer/CommandLineTools /Library/Developer/CommandLineTools.old
then do:
xcode-select --install
and follow the instructions and wait.
Re-try your package/source compilations and if the messages go away, you should be able to safely do:
sudo rm -rf /Library/Developer/CommandLineTools.old
but leaving that directory tree there should not do any harm (provided you have the free space to spare).

After restart ZSH cannot find NPM, Gulp or Bower

Context
Earlier this week, while my computer was starting Ubuntu 17.10 it shutoff due to low battery.
The Problem
Upon plugging in and rebooting I noticed some unusual behavior. One of the key things was that Oh My ZSH appears to be broken. Meaning, when I opened Terminal, pressed the up arrow to cycle through my history, and hit enter to execute the command: it reported it could not find my ZSH history log and failed to execute the command.
What I've Tried
So I assumed that ZSH was corrupted as a consequence of the improper shut down. So I reinstalled and the history error disappeared. But then it couldn't find NPM, Gulp or Bower. Meaning, when I executed something like gulp watch it reports zsh: command not found: gulp.
So I attempted to reinstall gulp with NPM and it reported the same error but for NPM.
I concluded that they were still installed and not corrupted but that ZSH simply can't find them.
So I tried a random command to export "paths" from a bash file to my ZSH file (I think they're called .rc files but I don't remember).
Then it seems to work.
Then I closed Terminal and it stopped working.
So I reinstalled ZSH again, this time using apt-get and it worked without having to export my paths.
Then I restarted (properly) and discovered it's broken again.
The Question
Can anyone explain why this is happening and how to resolve it?
short answer: add path in your ~/.zshrc
tl;dr
find executable path for your libraries or programs and add them
nano ~/.zshrc
export PATH=/path/to/lib/or/bin:$PATH
then save the file (ctl+o)
after this restart your zsh or reload the rc file (source ~/.zshrc)

Unix CouchDB installation + KERL

I am attempting to install CouchDB on my planetlab Unix machines from the source packages.
I installed Erlang r16b01 using Kerl: http://docs.basho.com/riak/1.3.0/tutorials/installation/Installing-Erlang/#Install-using-kerl
I installed openssl from the source package.
So, I ran "./configure --with-erlang=path/to/erlang/using/kerl" and I get the error
"configure: error: Could not find the Erlang crypto library"
This error indicates that Erlang was not compiled with OpenSSL support.
So, I tried using
"KERL_CONFIGURE_OPTIONS=--with-ssl=path/to/openssl/lib"
(Not sure if I'm using the above command correctly)
Then, reinstalled and reactivated Erlang.
This still brings up the same error.
I checked if Erlang if it could execute "crypto.start()", and it let me type the command, but it doesn't have a reply "ok" like in the documention: http://dennisreimann.de/blog/installing-couchdb-and-erlang-on-ubuntu-hardy/
Please help!
1) Did you first create a user couchdb and then do everything as that user? Including erlang build and install? That might be easier.
2) There is an error in your test, you need to terminate your command in the erl shell with a dot, otherwise you get no responce, like you already noticed. crypto:start(). is correct:
$ erl
Eshell V6.1 (abort with ^G)
1> crypto:start().
** exception error: undefined function crypto:start/0
After a successful build and installation it will respond ok:
$ erl
Eshell V6.1 (abort with ^G)
1> crypto:start().
ok
And you can also stop it afterwards:
2> crypto:stop().
ok
3>
=INFO REPORT==== 10-Aug-2014::20:22:06 ===
application: crypto
exited: stopped
type: temporary
3) You need the development package of OpenSSL including the header files as well as the binary command program openssl. At least version 0.9.8 of OpenSSL is required. As a sidenote for people who are on debian and ubuntu, it is usually enough to run:
sudo apt-get install openssl libssl-dev
In your case, you should somehow make sure that your openssl source install includes all the above (openssl binaries, header files).
4) Most probably it could be an issue with finding the libraries. I recommend reading this answer, which deals with a unix based system, and it could point you to the right direction:
https://stackoverflow.com/a/14776521/362951
Depending on the error message after the crypto:start(). you could try to somehow add the path and logout of the shell and relogin and then activate kerl and try again. No need to rebuild if it was present and found at compile time.
5) Your kerl configuration looks good. Again using debian/ubuntu paths a ~/.kerlrc could look like
KERL_CONFIGURE_OPTIONS="--with-ssl=/usr/lib/ssl"
And hopefully the ssl path you are inserting is the correct one.
You could also try and omit the path, maybe it finds the correct one by itself. On http://www.erlang.org/doc/installation_guide/INSTALL.html it looks like it is valid to do so:
KERL_CONFIGURE_OPTIONS="--with-ssl"
Currently kerl silently produces a build without crypto if it fails to find the headers https://github.com/yrashk/kerl/issues/31
6) I see you are giving the --with-erlang parameter to couchdb, does it point to the right directory? Or maybe it needs to go one level deeper or one level up.
Otherwise possibly an older, system. wide erlang could be used, if found.
Also I am not sure if the combination of a kerl environment and passing the erlang location using the --with-erlang parameter to couchdb works. I did not try the --with-erlang parameter with kerl, because I activate the kerl environment before compiling couchdb and then again before the couchdb start script.

Resources