Re: [dev] [st] System freeze when killing X after using st-git
Greetings. On Sat, 30 Nov 2013 09:38:32 +0100 Vidya Singh apei...@gmx.us wrote: On Wed, Nov 27, 2013 at 09:08:43AM +0100, Silvan Jegen wrote: On Wed, Nov 27, 2013 at 6:20 AM, Ryan O’Hara rni...@gmail.com wrote: On Tue, Nov 26, 2013 at 8:00 PM, Szilágyi Szilveszter szilvesz...@gmx.co.uk wrote: Hello, I use the same environment for 6 months and there were no problem at all. Szilveszter Okay, dwm-git, st-git, Arch Linux, MacBook Pro 2012 seems to be what most people reproduce it on. I have used dwm-git and st-git on Arch Linux amd64 (Intel desktop system with a Geforce 570 and proprietary Nvidia drivers) for more than 6 months without any problems. That might indicate that the problem lies with the MacBook Pro hardware. I can confirm this bug with 64 bit Arch Linux with DWM on a Dell inspiron 1545. I can only reproduce this when launching st from the CTRL-ALT-ENTER shortcut. Launching ST from dmenu causes no issue. Launching other terminals from CTRL-ALT-ENTER causes no issue. The kernel does not hang. The display does not work. I cannot shift tty's, but SYSRQ works just fine. I won’t add a »I‐am‐so‐stupid‐to‐buy‐Apple‐hardware« or »I‐am‐a‐retard‐ using‐Arch‐Linux‐after‐the‐systemd‐disaster« flag. The bug is outside of st. Sincerely, Christoph Lohmann
Re: [dev] [st] System freeze when killing X after using st-git
On Sat, Nov 30, 2013 at 09:38:32AM +0100, Christoph Lohmann wrote: Greetings. On Sat, 30 Nov 2013 09:38:32 +0100 Vidya Singh apei...@gmx.us wrote: On Wed, Nov 27, 2013 at 09:08:43AM +0100, Silvan Jegen wrote: On Wed, Nov 27, 2013 at 6:20 AM, Ryan O’Hara rni...@gmail.com wrote: On Tue, Nov 26, 2013 at 8:00 PM, Szilágyi Szilveszter szilvesz...@gmx.co.uk wrote: Hello, I use the same environment for 6 months and there were no problem at all. Szilveszter Okay, dwm-git, st-git, Arch Linux, MacBook Pro 2012 seems to be what most people reproduce it on. I have used dwm-git and st-git on Arch Linux amd64 (Intel desktop system with a Geforce 570 and proprietary Nvidia drivers) for more than 6 months without any problems. That might indicate that the problem lies with the MacBook Pro hardware. I can confirm this bug with 64 bit Arch Linux with DWM on a Dell inspiron 1545. I can only reproduce this when launching st from the CTRL-ALT-ENTER shortcut. Launching ST from dmenu causes no issue. Launching other terminals from CTRL-ALT-ENTER causes no issue. The kernel does not hang. The display does not work. I cannot shift tty's, but SYSRQ works just fine. I won’t add a »I‐am‐so‐stupid‐to‐buy‐Apple‐hardware« or »I‐am‐a‐retard‐ using‐Arch‐Linux‐after‐the‐systemd‐disaster« flag. The bug is outside of st. Sincerely, Christoph Lohmann Yes, very mature. The first statement I would agree on but in what way is Arch Linux with systemd a disaster? It runs very smoothely and fast over here. Or is it just the usual wannabe elitist bull...? Sincerely, Andreas Marschall
Re: [dev] [st] System freeze when killing X after using st-git
Andreas Marschall wrote: Yes, very mature. The first statement I would agree on but in what way is Arch Linux with systemd a disaster? It runs very smoothely and fast over here. Or is it just the usual wannabe elitist bull...? You know, the systemd (and friends) actually does a great job of ruining my day with Arch boxes - by now I have one permanently hanging on boot, another booting up twice as slowly as it did before the switch and a third one, which gets misconfigured by the boot-time voodoo. Sure, at least some of these problems are solvable, but I have to invest quite some time into it - and all of it goes into compensating the improvements in boot process. And I still can't see any benefit from the switch. -- Dmitrij D. Czarkoff
Re: [dev] [st] System freeze when killing X after using st-git
On Sat, 30 Nov 2013 10:12:35 +0100 Dmitrij D. Czarkoff czark...@gmail.com wrote: Andreas Marschall wrote: Yes, very mature. The first statement I would agree on but in what way is Arch Linux with systemd a disaster? It runs very smoothely and fast over here. Or is it just the usual wannabe elitist bull...? You know, the systemd (and friends) actually does a great job of ruining my day with Arch boxes - by now I have one permanently hanging on boot, another booting up twice as slowly as it did before the switch and a third one, which gets misconfigured by the boot-time voodoo. Sure, at least some of these problems are solvable, but I have to invest quite some time into it - and all of it goes into compensating the improvements in boot process. And I still can't see any benefit from the switch. -- Dmitrij D. Czarkoff The problem I see here is that the big GNU+Linux-distributors tend to add more and more abstractation layers on top of the base-system to automate it. A good example is the Gnome NetworkManager, which actually writes a ton of Mac Addresses into /etc/conf.d/net, making it impossible to hand-maintain these things afterwards. I could go on with PAM, ConsoleKit, Gnome KeyringManager and the like, but I'm sure you know (better) of the metastases of this cancerous disease so many man-hours were wasted for and which is the reason why we need multi-million dollar companies behind the big, automated distributions to fix software which breaks due to that, in the interest of providing a consistent user experience. If you ever dare to dig deeper or if a problem surfaces, you're screwed. That's why I'm using Gentoo (On my Mac mini :P). Cheers FRIGN -- FRIGN d...@frign.de
Re: [dev] [sbase][RFC] Add a simplistic version of tr
On Thu, Nov 28, 2013 at 07:01:17PM +, Thorsten Glaser wrote: Silvan Jegen dixit: If I understand correctly you would use mmap to allocate a sparse memory area into which we could then directly index (either using UTF-8 or UTF-32 indices), right? Since mmap needs a file descriptor I think that wouldn’t help much. Intuitively I would say it should help quite a lot because we usually do not map more than a few characters using tr (well, at least I do) and thus have a very sparsely populated memory area. Implementing a mmap and a non-mmap version of the code and comparing the memory usage should not be too hard to do, however. Sadly, I do not follow. I recognize that the lengths of those arrays multiplied correspond to the maximum number of Unicode code points (1,114,112) but I am not sure how the mapping (from UTF-8 or UTF-32 encoding) should be done. Care to enlighten me? Eh, 0xFF and 8? Bear with me for a moment, I am not used to bit twiddling :-) So your suggestion is to convert the UTF-8 to the Unicode code point (aka UTF-32) and use its value 8-shifted as an index into an array of pointers to 255-member arrays of wchar_t's (or uint32_t's). The least significant byte of the UTF-32 encoded code point can then be extracted by using the bitwise AND operation with 0xFF and used as an index into the uint32_t/wchar_t array itself. That sounds reasonable but requires that we convert UTF-8 to UTF-32 which should not be strictly necessary when we only map one UTF-8 value to another. I wonder whether there's an easy solution that would not necessitate that conversion, but this may just be a premature optimization...
Re: [dev] [sbase][RFC] Add a simplistic version of tr
On Thu, Nov 28, 2013 at 01:24:40PM -0500, Strake wrote: [..] UTF-32 is an encoding that is identical to the unicode point as far as I know. So what I am thinking is that one would either use the UTF-8 representation of the Unicode point as an index, or the unicode point itself. Since using UTF-8 would not require any conversion (on UTF-8 locales) I think it would be preferrable. UTF-8 has variable width, so one must find the length of the sequence anyhow and shift it bytewise into an integer, so one may as well just use fgetwc or the like and work with codepoints. You are right about the variable width. According to the standard, UTF-8 has a maximum length of 4 bytes which would fit into a int on most (all?) platforms so shifting would not be necessary, I think. I am not too familiar with C but wouldn't it theoretically be possible to figure out the length of a UTF-8 sequence, cast only the sequence to an int and use it to map into a sparse array of wchar_t/uint32_t's? Obviously having a sparse array that is backed by only a fraction of the actually requested memory would be crucial because UTF-8 allows 4 byte sequences with almost all the most significant bits set.
Re: [dev] [sbase][RFC] Add a simplistic version of tr
On Thu, Nov 28, 2013 at 12:45:40PM +0200, sin wrote:
On Tue, Nov 26, 2013 at 12:01:01PM -0800, Silvan Jegen wrote:
Hi
This is a braindead and incomplete implementation of tr that only
works for one-byte encodings. Do you think it makes sense to use this
implementation as some kind of stopgap-measure until we have a more
robust version of tr?
This particular version of the patch does not introduce a manpage
which would be necessary to document the limited behaviour of the
current program.
I can add a man page as soon as we have decided whether we want Unicode
support or not.
I am starting to wonder, do you guys think it would make sense to
have a staging branch that we can use for incomplete tools? Currently
some of the tools implement a subset of the total behaviour but I'd
like to believe that they implement that subset correctly. As long as
we document that they can go in master with possible eprintf(not
implemented);
calls for the options that we care about.
Programs that are obviously buggy can go in the staging branch.
I don't mind either way. Having a staging area could allow the project
to grow faster since not every contribution has to be complete to be
included.
If you you would rather not take this version, what approach would
you take for the character set mapping when using UTF-8? A hashmap-,
or B-tree-based solution or something else entirely?
I am not knowledgeable enough about UTF-8 so I can't answer this.
A B-tree is I think an overkill for sbase. We do not have a nice
implementation of a hash table in sbase as we did not need it but
if we go down that path it makes sense to put this in util/ so other
programs can benefit. Currently we don't have an implementation of
a singly linked list that we can reuse, but that is trivial enough and
we've re-implemented it wherever needed (with the minimum set of
operations needed for each tool). I can send an implementation of
a hash table that I've used for my own programs, MIT/X licensed and it is
simple enough.
Regarding UTF-8, some other programs in sbase also lack proper handling
of UTF-8. Do you think we could embed libutf8 from suckless.org and
use it?
I think having Unicode support is necessary at least in the long run
and UTF-8 is the way to go. libutf provides the most basic handling of
UTF-8 but should be sufficient as long as you do not want to go into
text normalization too much [1] [2]. BTW, the most recently updated version of
the library seems to be at https://github.com/cls/libutf/commits/master
and not at http://git.suckless.org/libutf/ for some reason.
[1] http://blog.golang.org/normalization
[2] http://mortoray.com/2013/11/27/the-string-type-is-broken/
+usage(void)
+{
+ eprintf(usage: tr set1 [set2]\n);
+}
Use %s and argv0.
I changed it in the new version of the patch that I will send out when
we have decided the Unicode issue.
+void
+handle_escapes(char *s)
+{
+switch(*s) {
+ case 'n':
+ *s = '\x0A';
+ break;
+ case 't':
+ *s = '\x09';
+ break;
+ case '\\':
+ *s = '\x5c';
+ break;
+}
+}
I have not yet applied this patch but I suspect you have
mixed whitespace + tabs here. Use tabs only.
You were right. I changed the whitespace to be tabs only.
+ if (ferror(stdin)) {
+ eprintf(stdin: read error:);
+ return EXIT_FAILURE;
+ }
Indentation issues.
Corrected.
Cheers,
Silvan
[dev] Re: [st] System freeze when killing X after using st-git
Dmitrij D. Czarkoff czark...@gmail.com writes: Andreas Marschall wrote: Yes, very mature. The first statement I would agree on but in what way is Arch Linux with systemd a disaster? It runs very smoothely and fast over here. Or is it just the usual wannabe elitist bull...? You know, the systemd (and friends) actually does a great job of ruining my day with Arch boxes - by now I have one permanently hanging on boot, another booting up twice as slowly as it did before the switch and a third one, which gets misconfigured by the boot-time voodoo. Sure, at least some of these problems are solvable, but I have to invest quite some time into it - and all of it goes into compensating the improvements in boot process. And I still can't see any benefit from the switch. The solution is easy: https://github.com/chneukirchen/ignite -- Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org
Re: [dev] [sbase][RFC] Add a simplistic version of tr
Silvan Jegen dixit: That sounds reasonable but requires that we convert UTF-8 to UTF-32 which should not be strictly necessary when we only map one UTF-8 value to another. Arrgh, no. UTF-8 and UTF-32/UCS-4 are encodings of numerical Unicode codepoints. When working with text documents, you always operate on those codepoints. This was true for single-byte encodings as well, except there, the codepoints always fit into bytes. bye, //mirabilos -- 08:05⎜XTaran:#grml mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ft:#grml yeah. /bin/rm. ;) 08:09⎜mrud:#grml hexdump -C 08:31⎜XTaran:#grml ft, mrud: *g*
Re: [dev] [sbase][RFC] Add a simplistic version of tr
On Sat, Nov 30, 2013 at 12:38:21PM +0100, Silvan Jegen wrote: BTW, the most recently updated version of the library seems to be at https://github.com/cls/libutf/commits/master and not at http://git.suckless.org/libutf/ for some reason. I'll rebase the github repo and push it at some point soon-ish. bye, sin
Re: [dev] Re: [st] System freeze when killing X after using st-git
Christoph Lohmann 2...@r-36.net, 2013-11-30T08:08:43Z I won’t add a »I‐am‐so‐stupid‐to‐buy‐Apple‐ hardware« or »I‐am‐a‐retard‐ using‐Arch‐Linux‐after‐the‐systemd‐disaster« flag. The bug is outside of st. Shall we change it to dwm then? It works fine with literally any other combination. Ryan O’Hara
Re: [dev] Re: [st] System freeze when killing X after using st-git
Hello, On Sat, Nov 30, 2013 at 07:29:47AM -0800, Ryan O’Hara wrote: Christoph Lohmann 2...@r-36.net, 2013-11-30T08:08:43Z I won’t add a »I‐am‐so‐stupid‐to‐buy‐Apple‐ hardware« or »I‐am‐a‐retard‐ using‐Arch‐Linux‐after‐the‐systemd‐disaster« flag. The bug is outside of st. Shall we change it to dwm then? It works fine with literally any other combination. It sounds like this is reproducible, and it also sounds like a debugger might not help so... Why not instrument the code around the so called troubling commit and look to see if that reveals proof of a problem?. if you think its a dwm issue, hunt it down with instrumentation. (i.e. carefully thought out print statements.) surely there are other ways to gather more information too... --Carlos
Re: [dev] [st] Very strange font problem
Nick suckless-...@njw.me.uk wrote: Quoth FRIGN: On Thu, 28 Nov 2013 23:37:59 +0200 Dimitris Zervas dzer...@dzervas.gr wrote: I attach a screenshot of xterm that I now use and the st that I'm configuring. I want to make st look the same with xterm. Any help apprecieted. I have had this problem before. It has definitely something to do with the font. You might try playing around with the font-parameters (esp. autohinting). It isn't any of the font parameters. A few fonts just didn't work with st. I don't know why (and can't remember any examples). Which version of st are you using? Font handling is done differently to how it used to be, so you may find using the latest tip it all just works for you. It happens whenever you try to use a proportional font, though I can only specifically remember it happening with Xft fonts. - Samuel Holland sam...@sholland.net
