Quoth Galos, David:
> P.S. As a matter of list etiquette, I'm not sure whether this
> announcement is considered appropriate. I want to give
> folks a chance to comment on my changes, but perhaps
> I am supposed to count on people being subscribed to
> [hackers].
I like reading the code here :)
T
The types array stood out to me as a bit of a code smell.
After pondering over it for a couple of minutes, I realized
that you could just do this:
type = argv[1][0] == 'b' ? S_IFBLK : S_IFCHR;
-Truls
On 7/3/13, Galos, David wrote:
>> Added LICENSE.lpl as well and updated the license and copyright details
>> for
>> the md5 code.
>
> I am considering applying this patch. The license is why I have to take
> time to think. I'm worried about setting a precedent which allows external
> differently-l
* Robert Ransom [2013-07-03 10:26:03 +]:
> On 7/3/13, Galos, David wrote:
> >> Added LICENSE.lpl as well and updated the license and copyright details
> >> for
> >> the md5 code.
> >
> > I am considering applying this patch. The license is why I have to take
> > time to think. I'm worried abo
On Wed, Jul 03, 2013 at 01:16:35PM +0200, Szabolcs Nagy wrote:
> * Robert Ransom [2013-07-03 10:26:03 +]:
> > On 7/3/13, Galos, David wrote:
> > >> Added LICENSE.lpl as well and updated the license and copyright details
> > >> for
> > >> the md5 code.
> > >
> > > I am considering applying thi
won't this increase cache misses for everything else?
On 7/2/13, Calvin Morrison wrote:
> On 2 July 2013 15:50, Galos, David wrote:
>>> I'm failing to see the problem with loading everything into memory.
>>
>> If the next step is "write that to a temp file" there is a big
>> problem. There's not
* sin [2013-07-03 14:43:24 +0300]:
> That's cool. I will spend some time today or tomorrow to re-write the
> code and send in patch v4.
>
> If that's fine then I can also proceed with sha1sum(1).
>
i have cleaned up sha1 as well, but that was not audited for musl
http://port70.net/~nsz/crypt/
How?
On 3 July 2013 08:13, hiro <23h...@gmail.com> wrote:
> won't this increase cache misses for everything else?
>
> On 7/2/13, Calvin Morrison wrote:
>> On 2 July 2013 15:50, Galos, David wrote:
I'm failing to see the problem with loading everything into memory.
>>>
>>> If the next step i
On 2 July 2013 20:41, Galos, David wrote:
>> and also depends on having a non-read only filesystem
>> to write too.
> You understand that in order to change the target file, the
> filesystem needs to be writable, right?
What if I had extremely limited filespace though, or only write
permissions t
* Martin Kopta [28.06.2013 14:26]:
> If I create new window, it gets placed on the primary monitor no matter what
>
> monitor is currently focused and no matter where mouse cursor is. It is
>
> annoying, but (for most apps) I can just move the window to the prefered
>
>
> The types array stood out to me as a bit of a code smell.
> After pondering over it for a couple of minutes, I realized
> that you could just do this:
>
> type = argv[1][0] == 'b' ? S_IFBLK : S_IFCHR;
After some thought, I am inclined to agree. This has been
changed.
> Oh, and you should add tar
> i have cleaned up sha1 as well, but that was not audited for musl
>
> http://port70.net/~nsz/crypt/
They cleaned up very nicely! I would nix the OpenSSL compat
layer in the sbase patches, but still, very nice.
> That's cool. I will spend some time today or tomorrow to re-write the
> code and s
Oh, and you should add tar using sltar as a base.
I actually worked on sltar, adding create support. At the
same time, I wrote a cleaner struct-based version, which
I am thinking about adding.
Why not just post your work to the list, so it can be reviewed, instead
of just thinking about adding
> Why not just post your work to the list, so it can be reviewed, instead of
> just thinking about adding it?
> You probably will learn better this way. ;)
I need to find my work first ;) It's in a hard drive somewhere.
For now, I will add sltar into sbase, submitting my changes as a patch
later.
On 28 June 2013 14:25, Martin Kopta wrote:
> If I create new window, it gets placed on the primary monitor no matter what
> monitor is currently focused and no matter where mouse cursor is. It is
> annoying, but (for most apps) I can just move the window to the prefered
> (nonprimary) monitor. But
On 07/02/2013 07:54 PM, Calvin Morrison wrote:
>If on any system other than linux, I would consider loading into ram,
>but because of memory overcommit, malloc never fails, the whole system
>crawls to a halt, and the oom killer takes 20 minutes to put
>everything back together. No thanks.
Okay s
just give it up, this thread sucks.
On 7/3/13, Bjartur Thorlacius wrote:
> On 07/02/2013 07:54 PM, Calvin Morrison wrote:
>>> >If on any system other than linux, I would consider loading into ram,
>>> >but because of memory overcommit, malloc never fails, the whole system
>>> >crawls to a halt, a
>From 309ffdb318e67014b8565335cc1d95e4ff5d506c Mon Sep 17 00:00:00 2001
From: Strake
Date: Wed, 3 Jul 2013 07:26:16 -0500
Subject: [PATCH 1/2] bin/handlers: roll up repeated code
---
bin/handlers.rc | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/bin/ha
On 03/07/2013, Strake wrote:
> ...
Sorry, I thought that I tested both, but actually only tested the
first. Second needs work yet.
Tested now.
>From 309ffdb318e67014b8565335cc1d95e4ff5d506c Mon Sep 17 00:00:00 2001
From: Strake
Date: Wed, 3 Jul 2013 07:26:16 -0500
Subject: [PATCH 1/2] bin/handlers: roll up repeated code
---
bin/handlers.rc | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff
20 matches
Mail list logo
