ncurses: mouse works in terminal emulator but not tty(vt) - mouseevent

initscr();
cbreak();
noecho();
assert(OK==keypad(stdscr,TRUE));
mousemask(BUTTON1_PRESSED|BUTTON1_RELEASED,NULL));
assert(has_mouse());
assert(166==mouseinterval(1));
refresh();
for(;;){
int ch=wgetch(stdscr);
// Detect mouse event and print coordinates
}
endwin();
In terminal emulator (alacritty), mouse coordinates are reported normally after a click of the left button. However, if I systemctl start gpm then run it in tty(vt), there is no response at all wherever mouse is clicked.
How can I make it work in tty(vt) as well?

ncurses has to be configured (compile-time) to work with gpm. If you compiled it yourself, that may not be configured. If you are commenting on a prebuilt package, your question should include relevant information (system and package version).
A comment points to Arch Linux's package, which does not explicitly turn on gpm. The gpm feature is not enabled by default (hint: the INSTALL file shows the feature as --with-gpm), and lacking other clues, is unlikely to be part of the package, unless the development package for gpm happened to be installed on the build-server.
A further comment mentions midnight commander. Whether or not it actually uses ncurses midnight commander has not used ncurses' mouse support for quite a while. Some of that is discussed in comments on ncurses versus slang (S-Lang)
You could make this work (ncurses+gpm) either by compiling the package yourself (using --with-gpm, taking care to have the development headers and libraries installed), or possibly a bug report to Arch might get that changed.

Related

Could not find List::Util

I'm trying to compile some raku code I saw on https://replit.com/languages/raku. The code is from Why is Raku reporting "two terms in a row" when I define a new operator?.
It begins like this:
unit module Format;
use List::Util;
...
It fails to compile with:
 raku ./main.raku
===SORRY!=== Error while compiling /home/runner/l4gp3hvdnhd/./main.raku
Could not find List::Util in:
inst#/home/runner/.raku
inst#/opt/rakudo-pkg/share/perl6/site
inst#/opt/rakudo-pkg/share/perl6/vendor
inst#/opt/rakudo-pkg/share/perl6/core
ap#
nqp#
perl5#
at /home/runner/l4gp3hvdnhd/./main.raku:3
exit status 1
On the other hand I see this is a valid module - https://raku.land/zef:lizmat/List::Util.
Why is it failing?
TL;DR Run zef install --/test List::Util in the console, put use lib '.'; at the top of your Raku main.raku, and run, don't walk, with your program, before gremlins gleefully render your efforts in vain. Or maybe just listen to Liz and Rawley.
As Liz and Rawley have noted, you need List::Util installed.
But while I largely agree with them in practice (it may be a pain to use replit to do what you're trying to do) I think a different response to complement theirs might be helpful.
One of the ways replit is trying to distinguish itself from other online evaluators, is that it is trying to be akin to a full dev environment.
In reality it's early days in their ambitious project, and beggars can't be choosers (if you're not paying, it's hard to complain if things don't work out as you might want), but of particular relevance for this SO it is worth noting that it does have console/shell facilities and they've installed Rakudo Star, or perhaps just something like it, including the Raku package manager pretty much everyone uses (zef).
Thus this command, which I just ran in replit's console of a new raku session, worked:
zef install --/test List::Util;
(The --/test tells zef not to run tests. I've only got a free account and it looked like replit killed zef's process when I ran just zef install List::Util during its running of tests. Presumably they take too long, but I don't know.)
And then this main.raku also worked:
use lib '.'; # Tell Raku(do) libs are in current directory.
use List::Util <notall>; # Load and import `notall` from module.
say notall { 42 }, 99; # Try it.
But now the rub. As I was composing this answer, the expected happened. My internet connection momentarily flaked out, the replit rebooted the session, and while my main.raku code was rescued, both List::Util and my console history had disappeared, so I had to paste the install command again and rerun it to get the module installed again.
It's all just throwaway container magic, and there's only so much replit has done thus far to make the simulation of a real full local dev environment really work.
Maybe if your Internet connection is rock solid and/or you're using a paid replit account and/or it's the full moon, it'll all work out. Or maybe you're best off following Rawley's advice.
Speaking of which (I mean Rawley's advice to set up your Raku dev environment locally), if you do install locally you can also install the awesome free version of CommaIDE.
You do not have List::Util installed. Since you're using an online interpreter you will most likely have a lot of trouble doing this. Instead I recommend installing Raku on your local machine with rakubrew.
Then run the following commands:
rakubrew build # Make sure to follow the instructions at the end
rakubrew build-zef
zef install List::Util
Now you should be able to run your code on your local machine, and you'll have access to the List::Util library.

Parcel watch doesn't detect changes, but safe-write is off

Symptoms:
Starting parcel watch completes the initial build, the command continues running but doesn't detect any further changes
Context:
Parcel is being run from an IntelliJ IDEA platform IDE (Rider)
Safe-write functionality is disabled, so I am completely sure that the file is actually being changed on disk
Problem is reproducible when I edit referenced CSS or JS using a different editor (vim)
OS is Ubuntu Linux
Why aren't subsequent changes to files detected by Parcel, triggering a re-build?
FWIW, you can set up a file watcher inside intellij that runs touch on the file. Just make sure it doesn't trigger on external file changes, or you'll loop forever. This way, you can leave safe write on and still trigger parcel and other external watchers.
IntelliJ-based IDEs have a habit of completely burning through the inotify limit. In my case, setting fs.inotify.max_user_watches in /etc/sysctl.conf to a higher value (524288 in my case, in accordance with the instructions given by JetBrains) and then running sudo sysctl -p --system before restarting parcel watch solved the problem conclusively.

How to run a script from startup on Raspbian 10 (buster)?

I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.

Having trouble with Osmocom source in gnuradio

I'm having trouble running a simple flowgraph with an osmocom source and a qt gui sink. If I run the file with a waveform generator instead of the osmocom source, all is well, the plots appear as they should, no problem.
When the osmocom source is hooked up, everything runs and there is no immediate error message... the gui window just never opens. If I run it from the terminal with verbose output, the output ends with and that's where it hangs.
import 'osmosdr._osmosdr_swig' # <_frozen_importlib_external.ExtensionFileLoader object at 0x7f5e0cae23c8>
import 'osmosdr.osmosdr_swig' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5e0cdda978>
import 'osmosdr' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5e0cdc9dd8>
Not sure what those errors mean but it just hangs there. Eventually it ends up using 100% of CPU and I have to CTRL + \ it to get it to stop. Is it a library maybe in the wrong place that it's not finding?
OS : Ubuntu 18.04
Gnuradio-config-info -version : 3.8.0.0-rc2
gr-osmosdr was installed from the git repo and the gr3.8 branch (which worked for me previously) so as to be ok with gnuradio 3.8. I had initially installed gr-osmosdr from the master branch and instead of doing make uninstall, I deleted the directory. I think installed from the gr3.8 branch, did a make uninstall to see if that maybe might have helped (?) and then reinstalled. No dice.
If there's any more info I can supply, let me know - any and all help is greatly appreciated, thanks!

What text editors does --dev reload with work

I'm following Odoo's documentation to use the --dev all parameter when I run odoo-bin, in order to have Python models get updated when I change the source code without me having to restart the server. According to the documentation, the reload flag (which is part of all) doesn't work with some text editors. I've been using Sublime Text, and that doesn't seem to work because my model changes don't take effect until I restart the server. Is there a good, commonly used text editor which does work with the reload parameter, or is there a list of text editors which work with it?
If you're running Odoo from the command line via a standard ./odoo-bin --dev reload command then you should not have any issues as long as you have the lib dependencies setup.
Make sure to monitor your log for errors. It requires the watchdog library to be installed via pip install watchdog. Take a look at (currently line 943) of the core files https://github.com/odoo/odoo/blob/10.0/odoo/service/server.py to see how dev reload works:
def start(preload=None, stop=False):
...
watcher = None
if 'reload' in config['dev_mode']:
if watchdog:
watcher = FSWatcher()
watcher.start()
else:
_logger.warning("'watchdog' module not installed. Code autoreload feature is disabled")
if 'werkzeug' in config['dev_mode']:
server.app = DebuggedApplication(server.app, evalex=True)
I am not completely sure, but after doing a quick search on the text editor that I have been primarily using (Atom developed by GitHub), I believe it may have what you're looking for.
Have fun with your future endeavors. I hope my answer helps.
Since odoo uses werkzeug server,you can just use the command line argument to start the server, and everything will be taken care by the server.
./openerp-server --auto-reload
this will restart the server whenever .py file is modified.