Re: [dev] Ada not Rust
Jeremy wrote: > What does Ada(or Rust for that matter) do better than C? > > Surely, you have all of the tools for static analysis, debugging, macros > for C that you would for any other language, no? > > I could understand generics, interfaces, iterators, OOP and all of that > from a masturbatory standpoint, but that aspect aside, what utility do > these provide over C? > > Jeremy Rationally, there is nothing better than C. I wish all the other things did not exist, so that people would stop piling crap on top of crap. It takes a solid engineering discipline, which is long forgotten. Kyryl.
Re: [dev] Ada not Rust
On 04/19/21 04:19PM, Greg Reagle wrote: > Okay, I did. Very interesting. I briefly studied Ada many years ago. Do > you think that Ada is a viable alternative to Rust? Do you think it is a > decent alternative to C for things like operating systems or utilities like > sbase or ubase? > > I made a Hello World program in Ada. Very fast and small. However, it > depends on libgnat-8.so.1. Is there a way to build it so that it does not? > Like statically linked? > What does Ada(or Rust for that matter) do better than C? Surely, you have all of the tools for static analysis, debugging, macros for C that you would for any other language, no? I could understand generics, interfaces, iterators, OOP and all of that from a masturbatory standpoint, but that aspect aside, what utility do these provide over C? Jeremy
Re: [dev] Ada not Rust
On Mon, Apr 19, 2021, at 16:36, Mattias Andrée wrote: > For me, libgnat is only dynamically linked if I run gnatbind > with -shared, but if you -static it should be statically linked. Thank you. [[ gnatmake hello.adb -bargs -static ]] does the trick, i.e. it makes the executable larger (of course) by statically linking libgnat. I am still an Ada beginner so I am not running the linker and binder etc. separately. > I cannot find how to statically link the C runtime. Yea, it still is dynamically linked to (depends on) several libraries: $ ldd hello linux-vdso.so.1 (0x7ffe57fde000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ffbb8a93000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7ffbb8a79000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ffbb88b8000) /lib64/ld-linux-x86-64.so.2 (0x7ffbb8af5000)
Re: [dev] Ada not Rust
On Mon, 19 Apr 2021 16:19:18 -0400 Greg Reagle wrote: > On Sat, Apr 17, 2021, at 11:57, Laslo Hunhold wrote: > > Anyway, I can't say it enough: Check out Ada 2012 (and the SPARK > > subset) if you care about "secure" languages. It's not as lean as C, but > > you end up solving so many problems with it, especially in regard to > > software engineering and safety. > > Okay, I did. Very interesting. I briefly studied Ada many years ago. Do > you think that Ada is a viable alternative to Rust? Do you think it is a > decent alternative to C for things like operating systems or utilities like > sbase or ubase? > > I made a Hello World program in Ada. Very fast and small. However, it > depends on libgnat-8.so.1. Is there a way to build it so that it does not? > Like statically linked? > For me, libgnat is only dynamically linked if I run gnatbind with -shared, but if you -static it should be statically linked. I cannot find how to statically link the C runtime.
[dev] Ada not Rust
On Sat, Apr 17, 2021, at 11:57, Laslo Hunhold wrote: > Anyway, I can't say it enough: Check out Ada 2012 (and the SPARK > subset) if you care about "secure" languages. It's not as lean as C, but > you end up solving so many problems with it, especially in regard to > software engineering and safety. Okay, I did. Very interesting. I briefly studied Ada many years ago. Do you think that Ada is a viable alternative to Rust? Do you think it is a decent alternative to C for things like operating systems or utilities like sbase or ubase? I made a Hello World program in Ada. Very fast and small. However, it depends on libgnat-8.so.1. Is there a way to build it so that it does not? Like statically linked?
[dev] Ada not Rust
On Sat, Apr 17, 2021, at 11:57, Laslo Hunhold wrote: > Anyway, I can't say it enough: Check out Ada 2012 (and the SPARK > subset) if you care about "secure" languages. It's not as lean as C, but > you end up solving so many problems with it, especially in regard to > software engineering and safety. Okay, I did. Very interesting. I briefly studied Ada many years ago. Do you think that Ada is a viable alternative to Rust? Do you think it is a decent alternative to C for things like operating systems or utilities like sbase or ubase? I made a Hello World program in Ada. Very fast and small. However, it depends on libgnat-8.so.1. Is there a way to build it so that it does not? Like statically linked?
Re: [dev] [st] libxft-bgra X Error
From: Страхиња Радић Sent:21/04/19 08:07pm Subject:Re: [dev] [st] libxft-bgra X Error > On 21/04/19 07:06, Страхиња Радић wrote: > > Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra > > 2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I > > regularly update from suckless repo[1]. Also ttf-nerd-fonts-symbols, *not* > > ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the > > uppercase > > "E".[2] (Maybe related?) > > After further testing, I can say that this bug does happen, but > inconsistently, > and with no obvious way to reproduce. When it does happen, I get the following > output: > > X Error of failed request: RenderBadPicture (invalid Picture parameter) > Major opcode of failed request: 139 (RENDER) > Minor opcode of failed request: 8 (RenderComposite) > Picture id in failed request: 0x1 > Serial number of failed request: 4871 > Current serial number in output stream: 5009 > > It also isn't tied to vim. I tried using joe -asis and less, with the same > result. Interestingly enough, cat iconlookup doesn't crash st, even when > scrolling back with tmux to the offending lines. > Yeah this is what I experienced as well. Seems to depend on what exactly is rendered on the screen but usually scrolling around line 160 in iconlookup seems to crash st. On my system with font size 16 and full screen (1920 x 1080, showing 47 lines) it crashes without fail when opening iconlookup and going to line 160 though.
Re: [dev] [st] libxft-bgra X Error
From: Страхиња Радић Sent:21/04/19 07:06pm Subject:Re: [dev] [st] libxft-bgra X Error > On 21/04/19 11:59, Luuk van Baal wrote: > > I was looking for pointers in regards to this error I'm receiving when > > using > > libxft-bgra(https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1). > > I explained the issue in > > (https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1#note_884325): > > > > "This patch (installed through this AUR package) leads to > > > > X Error of failed request: RenderBadPicture (invalid Picture parameter) > > Major opcode of failed request: 139 (RENDER) > > Minor opcode of failed request: 8 (RenderComposite) > > Picture id in failed request: 0x3b84 > > Serial number of failed request: 15315 > > Current serial number in output stream: 15327 > > > > when scrolling through this > > file(https://raw.githubusercontent.com/luukvbaal/iconlookup/master/iconlookup) > > in suckless' simple terminal using a patched nerd font. Very peculiar I > > know but this is the only way I've been able to reproduce this error. > > This sequence crashes the terminal every time: > > open st -> open iconlookup in vim -> press 160gg to go to line 160(full > > size terminal showing 47 lines centered around line 160). > > The same error does not happen when using different terminals but also does > > not happen in st when using the standard libxft from the arch repositories. > > I'm interested in figuring this out but I'm not sure how to debug the > > error. Would appreciate any pointers or thoughts regarding this." > > > > I'm curious to know your thoughts on this as like I said the problem > > does not occur with mainline libxft and st, does occur with libxft-bgra > > and st, but does not occur with libxft-bgra and other terminals(tried > > xterm/kitty/alacritty). Might this issue be fixed on st's side? > > Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra > 2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I > regularly update from suckless repo[1]. Also ttf-nerd-fonts-symbols, *not* > ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the > uppercase > "E".[2] (Maybe related?) > > Side note: I prefer :160 in vim to go to a particular line. > > [1]: https://git.sr.ht/~strahinja/st > [2]: https://github.com/ryanoasis/nerd-fonts/issues/581 > Taking a look at your st config led me to try to use the font2 patch and I can confirm that the error does not occor when using ttf-nerd-fonts-symbols in the font2 array and a regular font as the st font. Before this I was using a fontconfig setup like so: monospace FiraCode Nerd Font[1] Noto Color Emoji with the st font set to mono: static char *font = "mono:pixelsize=16:antialias=true:autohint=true"; It seems the error is caused by something only present when using a patched nerd font, not when using a seperate font containing the nerd font symbols. P.S. using the font2 patch with ttf-nerd-fonts-symbols leaves me with a misaligned shell prompt(powerlevel10k[2]) but I suppose this can be fixed. [1]: https://aur.archlinux.org/packages/nerd-fonts-fira-code/ [2]: https://github.com/romkatv/powerlevel10k
Re: [dev] [st] libxft-bgra X Error
On 21/04/19 07:06, Страхиња Радић wrote: > Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra > 2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I > regularly update from suckless repo[1]. Also ttf-nerd-fonts-symbols, *not* > ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the > uppercase > "E".[2] (Maybe related?) After further testing, I can say that this bug does happen, but inconsistently, and with no obvious way to reproduce. When it does happen, I get the following output: X Error of failed request: RenderBadPicture (invalid Picture parameter) Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 8 (RenderComposite) Picture id in failed request: 0x1 Serial number of failed request: 4871 Current serial number in output stream: 5009 It also isn't tied to vim. I tried using joe -asis and less, with the same result. Interestingly enough, cat iconlookup doesn't crash st, even when scrolling back with tmux to the offending lines. signature.asc Description: PGP signature
Re: [dev] [st] libxft-bgra X Error
On 21/04/19 11:59, Luuk van Baal wrote: > I was looking for pointers in regards to this error I'm receiving when > using > libxft-bgra(https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1). > I explained the issue in > (https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1#note_884325): > > "This patch (installed through this AUR package) leads to > > X Error of failed request: RenderBadPicture (invalid Picture parameter) > Major opcode of failed request: 139 (RENDER) > Minor opcode of failed request: 8 (RenderComposite) > Picture id in failed request: 0x3b84 > Serial number of failed request: 15315 > Current serial number in output stream: 15327 > > when scrolling through this > file(https://raw.githubusercontent.com/luukvbaal/iconlookup/master/iconlookup) > in suckless' simple terminal using a patched nerd font. Very peculiar I know > but this is the only way I've been able to reproduce this error. > This sequence crashes the terminal every time: > open st -> open iconlookup in vim -> press 160gg to go to line 160(full size > terminal showing 47 lines centered around line 160). > The same error does not happen when using different terminals but also does > not happen in st when using the standard libxft from the arch repositories. > I'm interested in figuring this out but I'm not sure how to debug the > error. Would appreciate any pointers or thoughts regarding this." > > I'm curious to know your thoughts on this as like I said the problem > does not occur with mainline libxft and st, does occur with libxft-bgra > and st, but does not occur with libxft-bgra and other terminals(tried > xterm/kitty/alacritty). Might this issue be fixed on st's side? Interesting, I'm not getting this error. I use Artix Linux, libxft-bgra 2.3.3.r7.7808631e-1 from AUR, vim 8.2.2653-1 and my modified st which I regularly update from suckless repo[1]. Also ttf-nerd-fonts-symbols, *not* ttf-nerd-fonts-symbols-mono, as the latter package has a bug with the uppercase "E".[2] (Maybe related?) Side note: I prefer :160 in vim to go to a particular line. [1]: https://git.sr.ht/~strahinja/st [2]: https://github.com/ryanoasis/nerd-fonts/issues/581 signature.asc Description: PGP signature
[dev] [st] libxft-bgra X Error
I was looking for pointers in regards to this error I'm receiving when using libxft-bgra(https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1). I explained the issue in (https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1#note_884325): "This patch (installed through this AUR package) leads to X Error of failed request: RenderBadPicture (invalid Picture parameter) Major opcode of failed request: 139 (RENDER) Minor opcode of failed request: 8 (RenderComposite) Picture id in failed request: 0x3b84 Serial number of failed request: 15315 Current serial number in output stream: 15327 when scrolling through this file(https://raw.githubusercontent.com/luukvbaal/iconlookup/master/iconlookup) in suckless' simple terminal using a patched nerd font. Very peculiar I know but this is the only way I've been able to reproduce this error. This sequence crashes the terminal every time: open st -> open iconlookup in vim -> press 160gg to go to line 160(full size terminal showing 47 lines centered around line 160). The same error does not happen when using different terminals but also does not happen in st when using the standard libxft from the arch repositories. I'm interested in figuring this out but I'm not sure how to debug the error. Would appreciate any pointers or thoughts regarding this." I'm curious to know your thoughts on this as like I said the problem does not occur with mainline libxft and st, does occur with libxft-bgra and st, but does not occur with libxft-bgra and other terminals(tried xterm/kitty/alacritty). Might this issue be fixed on st's side? Best regards, Luuk van Baal
