[dev] user interfaces on top of ii
On Thu, Feb 20, 2020, at 15:33, Greg Reagle wrote: > I am not very familiar with IRC or with ii (I've used IRC very very > little). Could you recommend and IRC client that works on top of ii > that is fairly easy to use, not requiring a lot of scripting and setup > and so forth? Maybe something on the level of mutt? So that I can get > an idea of how to make a friendly UI on top of the FIFOs. I have figured out how to use pcw with multiple st windows running lchat. I understand the general idea now. I have this in pcw_win.sh: exec st -t "$CPATH" -e lchat -n30 -p "$(basename "$CPATH")> " -t "$(basename "$CPATH")>" "$CPATH"
Re: [dev] startup time of some interpreters
Hi, Out of the blue: I recently did switch from the "compiled" version of youtube-dl to the use of it's raw code straight from the git repository, because it felt starting significantly faster. (nobody should have to use youtube-dl to get the video/dash url) -- Sylvain
Re: [dev] an approach to Matrix client that sucks less
Thank you Laslo Hunhold for your feedback. On Thu, Feb 20, 2020, at 14:54, Laslo Hunhold wrote: > yes, we haven't looked into Matrix much here. I have to admit that it's > the most promising protocol out there, in my opinion. What matters for > a suckless client is the interface. Based on your other comments, I assume that when you stress the importance of the "interface", you are not referring to end-user interface (like command line, or curses, or GTK, etc.) but more of a lower level interface, like the way that ii works with files and directories and FIFOs? > A few years ago, Dimitris, Hiltjo, > I and a few others wrote a client for toxcore, and we kept it similar > to ii with a file based hierarchy. The client itself was event-driven > and had a pretty sophisticated state machine to handle the different > states. We even supported calls and file transfers, but sadly, tox died > due to internal conflicts and an inconsistent API. Are you referring to https://git.2f30.org/ratox/file/README.html. Are you suggesting that I use it as a template for the interface (along with ii). > Investigating Matrix is definitely a nice thing! I am not a big fan of > Lua though, I am certainly open to suggestions to other languages. If using a different language can get me more contribution from others, that would be very valuable to me indeed. But I do want something higher level than C. > but what matters is the interface. From that point on, it > shouldn't matter which language you use to implement it. I understand. I am not very familiar with IRC or with ii (I've used IRC very very little). Could you recommend and IRC client that works on top of ii that is fairly easy to use, not requiring a lot of scripting and setup and so forth? Maybe something on the level of mutt? So that I can get an idea of how to make a friendly UI on top of the FIFOs.
Re: [dev] an approach to Matrix client that sucks less
On Thu, 20 Feb 2020 11:44:19 -0500 "Greg Reagle" wrote: Dear Greg, > Hi y'all. I don't see any Matrix client at > https://suckless.org/rocks/ or https://suckless.org/other_projects/ > and I am thinking of making one. I use the Riot.im web app client > which has a lot of features, but is bloated. > > Do any of you know of a Matrix client that is not bloated? I have > looked at many of the clients at https://matrix.org/clients. I have > tried several. Some of them are either too bloated, use a language > I'm not crazy about, or lack some basic features (too immature). > > I have never used Weechat and am feeling too lazy to learn. I expect > there would be a lot to learn just to use it as an IRC client, then > as a Matrix client I don't know how well it works. I am reluctant to > invest the time and effort (but maybe I should, I don't know). > > I might write my own Matrix client. I would probably use Lua. C is > too low level for my taste. Would any of you be interested in > contributing? I expect I would start by writing command line > interface. CLI would be good to have, and I could learn a lot about > implementing Matrix without being bothered by UI issues. After the > CLI was done, then I would consider what to do next, maybe a GUI, > maybe a TUI, etc. yes, we haven't looked into Matrix much here. I have to admit that it's the most promising protocol out there, in my opinion. What matters for a suckless client is the interface. A few years ago, Dimitris, Hiltjo, I and a few others wrote a client for toxcore, and we kept it similar to ii with a file based hierarchy. The client itself was event-driven and had a pretty sophisticated state machine to handle the different states. We even supported calls and file transfers, but sadly, tox died due to internal conflicts and an inconsistent API. Investigating Matrix is definitely a nice thing! I am not a big fan of Lua though, but what matters is the interface. From that point on, it shouldn't matter which language you use to implement it. With best regards Laslo
Re: [dev] startup time of some interpreters
On Thu, Feb 20, 2020 at 02:24:22PM -0500, Greg Reagle wrote: > On Thu, Feb 20, 2020, at 13:07, Hadrien Lacour wrote: > > A much more accurate mesure of disgust is the number of syscall made for > > such a > > simple task: > > That's very interesting, thank you. Do you know how to write a similar test > for memory usage? > Your GNU time usage already include this, no? busybox time -v is also quite good.
Re: [dev] startup time of some interpreters
On Thu, Feb 20, 2020, at 12:48, Eric Pruitt wrote: > One problem I see with these benchmarks is that it's not an entirely > fair comparison. For example, in Python, you're only printing some text, > but you aren't importing any modules. That's true, but I was just comparing the overhead of the interpreter itself.
Re: [dev] startup time of some interpreters
On Thu, Feb 20, 2020, at 13:07, Hadrien Lacour wrote: > Why would it be "defective" other than sh or I/O adding time noise? Because I am a flawed and imperfect person who makes mistakes, and while I consider myself a competent programmer, I know that there are people here on suckless who are experts and consider things that I overlook. > lua is a very simple language with a light reference interpreter. Yes, that is my point. > A much more accurate mesure of disgust is the number of syscall made for such > a > simple task: That's very interesting, thank you. Do you know how to write a similar test for memory usage?
Re: [dev] startup time of some interpreters
On Thu, Feb 20, 2020 at 12:22:53PM -0500, Greg Reagle wrote:
> Hello. I am amazed at how fast Lua is to start up and shut down. Is my
> benchmark defective in any way? Lua seems to start up and exit faster than
> bash, python, rc, and ksh. Dash and mksh are faster. These interpreters are
> all packages from Debian Stable 10 "Buster".
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do dash -c "echo \"hello\"";
> done' > /dev/null
> 0.12user 0.04system 0:00.17elapsed 97%CPU (0avgtext+0avgdata 1728maxresident)k
> 0inputs+0outputs (0major+16728minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do mksh -c "echo \"hello\"";
> done' >
> /dev/null
> 0.16user 0.05system 0:00.23elapsed 96%CPU (0avgtext+0avgdata 1904maxresident)k
> 0inputs+0outputs (0major+18472minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do lua -e "print \"hello\"";
> done' >
> /dev/null
> 0.22user 0.07system 0:00.31elapsed 97%CPU (0avgtext+0avgdata 2496maxresident)k
> 0inputs+0outputs (0major+25334minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do bash -c "echo \"hello\"";
> done' > /dev/null
> 0.26user 0.09system 0:00.36elapsed 96%CPU (0avgtext+0avgdata 3240maxresident)k
> 0inputs+0outputs (0major+30253minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do ksh -c "echo \"hello\""; done'
> > /dev/null
> 0.28user 0.14system 0:00.44elapsed 95%CPU (0avgtext+0avgdata 3888maxresident)k
> 0inputs+0outputs (0major+37146minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do /usr/lib/plan9/bin/rc -c "echo
> \"hello\""; done' > /dev/null
> 0.43user 0.14system 0:00.60elapsed 96%CPU (0avgtext+0avgdata 2008maxresident)k
> 0inputs+0outputs (0major+43700minor)pagefaults 0swaps
>
> /usr/bin/time sh -c 'for i in $(seq 1 200); do python -c "print \"hello\"";
> done' > /dev/null
> 2.32user 0.88system 0:03.32elapsed 96%CPU (0avgtext+0avgdata 7220maxresident)k
> 0inputs+0outputs (0major+174760minor)pagefaults 0swaps
>
Why would it be "defective" other than sh or I/O adding time noise? lua is a
very simple language with a light reference interpreter. You should consider
tcl (through jimsh) too, I find this language way more elegant than these.
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do busybox ash -c
"echo \"hello\""; done' > /dev/null
0.05s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do bash -c "echo
\"hello\""; done' > /dev/null
0.13s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do python2 -c
"print \"hello\""; done' > /dev/null
1.55s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do python3 -c
"print(\"hello\")"; done' > /dev/null
2.72s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do perl -e "print
\"hello\n\""; done' > /dev/null
0.17s
hadrien@gentoo-zen2700x> printf '%s\n' '#!/usr/bin/tclsh' 'puts hello'
>hello.tcl
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do ./hello.tcl;
done' > /dev/null
0.39s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do jimsh -e "puts
hello"; done' > /dev/null
0.18s
hadrien@gentoo-zen2700x> time sh -c 'for i in $(seq 1 200); do lua -e "print
\"hello\""; done' > /dev/null
0.11s
What it shows is that python is slower than a dead rat and the reference tcl
could be better. Apart from that, they're all quite fast.
A much more accurate mesure of disgust is the number of syscall made for such a
simple task:
hadrien@gentoo-zen2700x> strace -fc busybox ash -c 'echo hello' 2>&1 >/dev/null
| tail -n1 | awk '{print $3}'
26
hadrien@gentoo-zen2700x> strace -fc bash -c 'echo hello' 2>&1 >/dev/null | tail
-n1 | awk '{print $3}'
132
hadrien@gentoo-zen2700x> strace -fc python2 -c 'print "hello"' 2>&1 >/dev/null
| tail -n1 | awk '{print $3}'
683
hadrien@gentoo-zen2700x> strace -fc python3 -c 'print("hello")' 2>&1 >/dev/null
| tail -n1 | awk '{print $3}'
517
hadrien@gentoo-zen2700x> strace -fc perl -e 'print("hello\n");' 2>&1 >/dev/null
| tail -n1 | awk '{print $3}'
173
hadrien@gentoo-zen2700x> strace -fc ./hello.tcl 2>&1 >/dev/null | tail -n1 |
awk '{print $3}'
190
hadrien@gentoo-zen2700x> strace -fc jimsh -e 'puts hello' 2>&1 >/dev/null |
tail -n1 | awk '{print $3}'
78
hadrien@gentoo-zen2700x> strace -fc lua -e 'print "hello"' 2>&1 >/dev/null |
tail -n1 | awk '{print $3}'
90
Speaks for itself.
Re: [dev] startup time of some interpreters
On Thu, Feb 20, 2020 at 12:22:53PM -0500, Greg Reagle wrote:
> Hello. I am amazed at how fast Lua is to start up and shut down. Is my
> benchmark defective in any way? Lua seems to start up and exit faster
> than bash, python, rc, and ksh. Dash and mksh are faster. These
> interpreters are all packages from Debian Stable 10 "Buster".
One problem I see with these benchmarks is that it's not an entirely
fair comparison. For example, in Python, you're only printing some text,
but you aren't importing any modules. Just about every non-trivial
Python script will import at least one module which will in turn import
others, and imports affect how long it takes before the core of your
script runs:
$ time for _ in {1..10}; do python -c 'print("Hello world")'; done
...
[0.376s (98.63% CPU; User: 0.322, Sys: 0.049)]
$ time for _ in {1..10}; do python -c 'import subprocess; import os;
print("Hello world")'; done
...
[0.502s (99.91% CPU; User: 0.402, Sys: 0.099)]
I've used "os" and "subprocess" in my examples since those are among the
most likely to be used if you're replacing a shell script with a Python
script.
Also, you didn't include AWK interpreters. On my system MAWK and the
typically slower GAWK take around the same time to print "Hello world"
as dash does on my machines:
$ time for _ in {1..10}; do mawk 'BEGIN { print "Hello world" }'; done >
/dev/null
[0.112s (100.60% CPU; User: 0.107, Sys: 0.005)]
$ time for _ in {1..10}; do gawk 'BEGIN { print "Hello world" }'; done >
/dev/null
[0.152s (99.90% CPU; User: 0.150, Sys: 0.002)]
$ time for _ in {1..10}; do sh -c 'echo Hello world'; done > /dev/null
[0.115s (100.53% CPU; User: 0.104, Sys: 0.012)]
Eric
Re: [dev] [no js web]
On Wed, Feb 19, 2020 at 09:56:50PM +, sylvain.bertr...@gmail.com wrote: > Hi, > > As some may already know I am sueing the french administration which recently > (a couple of years) broke the support of no js web browsers. > > The follow up would be to deal with this issue at the EU administration level > and the local W3C representatives. > > I am currently trying to get a lawyer allocated for this, and if there are any > french citizens among suckless aware people who would like to join the party, > do not hesitate to get in touch with me. > > regards, > > -- > Sylvain > Well, good luck with it, even if you're right on the issue. Pretty sure that Microsoft usage in schools is the same problem: mandatory proprietary shitware paid by the taxpayers. Personally, I was much more scared of the DSP2 directive that basically made Google/Apple powered smartphones mandatory for online banking/shopping. Some banks made some completely offline OTP+QRcode devices available (for a price, "of course"), fortunately.
Re: [dev] [surf] can't follow a link for download
On Thu, Feb 20, 2020 at 02:05:01PM -0300, Renato A. Galvão wrote: > >>> surf: execvp x-terminal-emulator failed: Permission denied > > There is an apparmor file, > > /etc/apparmor.d/usr.bin.surf > [...] > /usr/bin/stterm ix, In the past st was shipped in the stterm package with only an stterm binary. Nowaways the stterm package includes the st binary again (and a symlink from stterm to st). But AppArmor doesn't seem to follow symlinks. I will update the surf profile in the next upload. Thanks for the hint. Regards, Reiner signature.asc Description: PGP signature
[dev] startup time of some interpreters
Hello. I am amazed at how fast Lua is to start up and shut down. Is my benchmark defective in any way? Lua seems to start up and exit faster than bash, python, rc, and ksh. Dash and mksh are faster. These interpreters are all packages from Debian Stable 10 "Buster". /usr/bin/time sh -c 'for i in $(seq 1 200); do dash -c "echo \"hello\""; done' > /dev/null 0.12user 0.04system 0:00.17elapsed 97%CPU (0avgtext+0avgdata 1728maxresident)k 0inputs+0outputs (0major+16728minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do mksh -c "echo \"hello\""; done' > /dev/null 0.16user 0.05system 0:00.23elapsed 96%CPU (0avgtext+0avgdata 1904maxresident)k 0inputs+0outputs (0major+18472minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do lua -e "print \"hello\""; done' > /dev/null 0.22user 0.07system 0:00.31elapsed 97%CPU (0avgtext+0avgdata 2496maxresident)k 0inputs+0outputs (0major+25334minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do bash -c "echo \"hello\""; done' > /dev/null 0.26user 0.09system 0:00.36elapsed 96%CPU (0avgtext+0avgdata 3240maxresident)k 0inputs+0outputs (0major+30253minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do ksh -c "echo \"hello\""; done' > /dev/null 0.28user 0.14system 0:00.44elapsed 95%CPU (0avgtext+0avgdata 3888maxresident)k 0inputs+0outputs (0major+37146minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do /usr/lib/plan9/bin/rc -c "echo \"hello\""; done' > /dev/null 0.43user 0.14system 0:00.60elapsed 96%CPU (0avgtext+0avgdata 2008maxresident)k 0inputs+0outputs (0major+43700minor)pagefaults 0swaps /usr/bin/time sh -c 'for i in $(seq 1 200); do python -c "print \"hello\""; done' > /dev/null 2.32user 0.88system 0:03.32elapsed 96%CPU (0avgtext+0avgdata 7220maxresident)k 0inputs+0outputs (0major+174760minor)pagefaults 0swaps
[dev] an approach to Matrix client that sucks less
Hi y'all. I don't see any Matrix client at https://suckless.org/rocks/ or https://suckless.org/other_projects/ and I am thinking of making one. I use the Riot.im web app client which has a lot of features, but is bloated. Do any of you know of a Matrix client that is not bloated? I have looked at many of the clients at https://matrix.org/clients. I have tried several. Some of them are either too bloated, use a language I'm not crazy about, or lack some basic features (too immature). I have never used Weechat and am feeling too lazy to learn. I expect there would be a lot to learn just to use it as an IRC client, then as a Matrix client I don't know how well it works. I am reluctant to invest the time and effort (but maybe I should, I don't know). I might write my own Matrix client. I would probably use Lua. C is too low level for my taste. Would any of you be interested in contributing? I expect I would start by writing command line interface. CLI would be good to have, and I could learn a lot about implementing Matrix without being bothered by UI issues. After the CLI was done, then I would consider what to do next, maybe a GUI, maybe a TUI, etc.
Re: [dev] [surf] can't follow a link for download
2020-02-20 11:33 GMT-03:00, Renato A. Galvão : > 2020-02-20 10:35 GMT-03:00, Greg Reagle : >> On Thu, Feb 20, 2020, at 08:26, Renato A. Galvão wrote: >>> I use the packaged version buster (stable) of surf in Debian. >>> >>> While trying to make any download I'm receiving this: >>> >>> surf: execvp x-terminal-emulator failed: Permission denied >> >> Run the command x-terminal-emulator from a shell prompt. What happens? >> >> Also, try these commands: >> ls -l $(which x-terminal-emulator) >> ls -l /etc/alternatives/x-terminal-emulator >> >> > > It opens st, which is my default terminal emulator. > > ls -l $(which x-terminal-emulator) > lrwxrwxrwx 1 root root 37 jun 17 2016 /usr/bin/x-terminal-emulator -> > /etc/alternatives/x-terminal-emulator > > ls -l /etc/alternatives/x-terminal-emulator > lrwxrwxrwx 1 root root 11 jul 14 2019 > /etc/alternatives/x-terminal-emulator -> /usr/bin/st > There is an apparmor file, /etc/apparmor.d/usr.bin.surf where the following directives is found: # for downloading files /dev/ptmx rw, /dev/pts/* rw, /usr/bin/stterm ix, # unconfined because it is called in (and downloading to) the cwd /usr/bin/curl Ux,
Re: [dev] [surf] can't follow a link for download
2020-02-20 10:35 GMT-03:00, Greg Reagle : > On Thu, Feb 20, 2020, at 08:26, Renato A. Galvão wrote: >> I use the packaged version buster (stable) of surf in Debian. >> >> While trying to make any download I'm receiving this: >> >> surf: execvp x-terminal-emulator failed: Permission denied > > Run the command x-terminal-emulator from a shell prompt. What happens? > > Also, try these commands: > ls -l $(which x-terminal-emulator) > ls -l /etc/alternatives/x-terminal-emulator > > It opens st, which is my default terminal emulator. ls -l $(which x-terminal-emulator) lrwxrwxrwx 1 root root 37 jun 17 2016 /usr/bin/x-terminal-emulator -> /etc/alternatives/x-terminal-emulator ls -l /etc/alternatives/x-terminal-emulator lrwxrwxrwx 1 root root 11 jul 14 2019 /etc/alternatives/x-terminal-emulator -> /usr/bin/st
Re: [dev] [surf] can't follow a link for download
On Thu, Feb 20, 2020, at 08:26, Renato A. Galvão wrote: > I use the packaged version buster (stable) of surf in Debian. > > While trying to make any download I'm receiving this: > > surf: execvp x-terminal-emulator failed: Permission denied Run the command x-terminal-emulator from a shell prompt. What happens? Also, try these commands: ls -l $(which x-terminal-emulator) ls -l /etc/alternatives/x-terminal-emulator
Re: [dev] [surf] can't follow a link for download
> Dear developers, Hi Renato, > I use the packaged version buster (stable) of surf in Debian. > > While trying to make any download I'm receiving this: > > surf: execvp x-terminal-emulator failed: Permission denied This seems to be a Debian issue, surf uses "st" terminal emulator by default, it seems that Debian packager(s) decided to replace that with "x-terminal-emulator" which seems to be problematic on your system. I suggest enquiring about that over-there!
[dev] [surf] can't follow a link for download
Dear developers, I use the packaged version buster (stable) of surf in Debian. While trying to make any download I'm receiving this: surf: execvp x-terminal-emulator failed: Permission denied
