Re: [dev] [sbase] diff

2016-01-28 Thread Mattias Andrée
I have trimmed down the memory usable a little but, but not reduce the space complexity. (Reduced by 80 % on 32-bit machines, and 88.(8) % on 64-bit machines, as the supreium.) If I understood that algorithm correct, I do not think it will produce the optimal result (I have not look in to it tough

Re: [dev] [sbase] diff

2016-01-28 Thread Mattias Andrée
On Thu, 28 Jan 2016 16:48:22 +0100 Markus Wichmann wrote: > On Wed, Jan 27, 2016 at 11:22:55PM +0100, Mattias Andrée > wrote: > > Perhaps I should describe how the program works > > (although it is very simple.) The documents are > > compared just like of they were words, but with > > lines rathe

Re: [dev] [sbase] diff

2016-01-28 Thread Markus Wichmann
On Wed, Jan 27, 2016 at 11:22:55PM +0100, Mattias Andrée wrote: > Perhaps I should describe how the program works > (although it is very simple.) The documents are > compared just like of they were words, but with > lines rather than characters, and only add and > remove are valid changes, not subs

[dev] [sbase] diff3 and beyond?

2016-01-28 Thread Mattias Andrée
Is there any interest in having diff3 and beyond (why limit it to anything less than 64, or at all, if implementing it for 3 files) in sbase? pgp4ZEpSZsLiP.pgp Description: OpenPGP digital signature

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread FRIGN
On Thu, 28 Jan 2016 15:49:54 +0100 FRIGN wrote: > key, until you have not lifted your finger again the screen will stay blue. I mean "black" of course. -- FRIGN

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread FRIGN
On Thu, 28 Jan 2016 15:48:55 +0100 Markus Teich wrote: Hey Markus, > another even more annoying example is: I actually type my password so fast, > the > key release events are sometimes in the wrong order. You can test it with xev, > just type some text as fast as you can and you will find some

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread FRIGN
On Thu, 28 Jan 2016 12:42:37 -0200 Brad Luther wrote: Hey Brad, > Say somebody manages to "clamp" any letter or number key without you > noticing, and you for the better of it cannot type in your password > (not because it's all-caps, but because it's spamming lots of chars). > > So we want the

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread Markus Teich
Brad Luther wrote: > Say somebody manages to "clamp" any letter or number key without you noticing, > and you for the better of it cannot type in your password (not because it's > all-caps, but because it's spamming lots of chars). > > So we want the screen to turn red on key down? Any key? Why ju

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread Markus Teich
FRIGN wrote: > So we want the screen to turn red on key down. Heyho, another even more annoying example is: I actually type my password so fast, the key release events are sometimes in the wrong order. You can test it with xev, just type some text as fast as you can and you will find something li

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread Brad Luther
Say somebody manages to "clamp" any letter or number key without you noticing, and you for the better of it cannot type in your password (not because it's all-caps, but because it's spamming lots of chars). So we want the screen to turn red on key down? Any key? Why just shift? Not that I care to

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread FRIGN
On Thu, 28 Jan 2016 21:02:27 +1300 David Phillips wrote: Hey David, > This patch does not change this. With this patch applied, for someone to > tamper with the shift key and *not* make a change on the screen, their only > option is to press and never release it. This is still quite suitable for

[dev] Quick and dirty statistics tool for the UNIX pipeline

2016-01-28 Thread Marc Collin
Who ever had to deal with R and other complex tools to do some statistical work? I found an interesting alternative that appears to be 'suckless' to me. qstats. I'm sending this email to the author too so we can discuss his project with the suckless community. What I miss the most are confidence in

Re: [dev] [slock] chown to root:root on install?

2016-01-28 Thread Nick
Hi folks, Quoth Markus Teich: > Nick wrote: > > Ideally slock should always be owned by the root user, so that it can > > disable > > the oom lock. I wonder what the right solution is here, as obviously one > > can't > > chown a file to be owned by root if one isn't root oneself. > > > > One op

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread David Phillips
> Heyho David, Hi Markus > I don't think we should change the current behaviour. As already explained > there > are two different ways of operation: > > - The paranoid option / failonclear = true: > Here you will leave your screen green and will notice ANY fiddling with the > keyboard. Let'

Re: [dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread Markus Teich
David Phillips wrote: > Previously, if failonclear was set to True and a modifier key (especially > shift) was pressed and held in order to modify the next keypress, slock would > detect that a keypress had been made, observe that the buffer was clear and > set the screen to the failure colour. >

[dev] [PATCH] [slock] React to key release rather than key press events

2016-01-28 Thread David Phillips
Previously, if failonclear was set to True and a modifier key (especially shift) was pressed and held in order to modify the next keypress, slock would detect that a keypress had been made, observe that the buffer was clear and set the screen to the failure colour. That behaviour is unwanted if th