Am 08.09.2010 06:07, schrieb Victor Lowther:
> Blame my ongoing Emacs education. I learned about
> (custom-set-variables '(indent-tabs-mode nil)) after doing most of the
> work, and dropped the whitespace cleanup patches due to size.
>
> Otherwise, I ignored the vim modelines -- 2 characters per i
On Tue, Sep 7, 2010 at 10:47 PM, Dave Reisner wrote:
> On Tue, Sep 07, 2010 at 10:32:28PM +0200, Thomas Bächler wrote:
>> Am 30.06.2010 23:47, schrieb Victor Lowther:
>> > Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
>> >
>> > Bashifying this framework should result in
On Tue, Sep 07, 2010 at 10:32:28PM +0200, Thomas Bächler wrote:
> Am 30.06.2010 23:47, schrieb Victor Lowther:
> > Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
> >
> > Bashifying this framework should result in about a 30% speedup, assuming no
> > IO latency and that al
On Tue, Sep 07, 2010 at 09:51:59PM -0500, Victor Lowther wrote:
> On Tue, Sep 7, 2010 at 3:32 PM, Thomas Bächler wrote:
> > Am 30.06.2010 23:47, schrieb Victor Lowther:
> >> Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
> >>
> >> Bashifying this framework should result i
On Tue, Sep 7, 2010 at 3:32 PM, Thomas Bächler wrote:
> Am 30.06.2010 23:47, schrieb Victor Lowther:
>> Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
>>
>> Bashifying this framework should result in about a 30% speedup, assuming no
>> IO latency and that all programs we
Am 30.06.2010 23:47, schrieb Victor Lowther:
> Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
>
> Bashifying this framework should result in about a 30% speedup, assuming no
> IO latency and that all programs we call also take zero time. :)
I just pushed the patches - I
On Sat, Jul 31, 2010 at 11:54 AM, Thomas Bächler wrote:
> Am 31.07.2010 18:44, schrieb Victor Lowther:
>> On Fri, Jul 23, 2010 at 5:51 PM, Thomas Bächler wrote:
>>> Am 23.07.2010 22:58, schrieb Victor Lowther:
After looking over it again, you are correct -- split into array does
not do
Am 31.07.2010 18:44, schrieb Victor Lowther:
> On Fri, Jul 23, 2010 at 5:51 PM, Thomas Bächler wrote:
>> Am 23.07.2010 22:58, schrieb Victor Lowther:
>>> After looking over it again, you are correct -- split into array does
>>> not do The Right Thing here. It will be easy to fix -- by the time
>>
On Fri, Jul 23, 2010 at 5:51 PM, Thomas Bächler wrote:
> Am 23.07.2010 22:58, schrieb Victor Lowther:
>> After looking over it again, you are correct -- split into array does
>> not do The Right Thing here. It will be easy to fix -- by the time
>> you read this it will have been fixed and rebased
Am 23.07.2010 22:58, schrieb Victor Lowther:
> After looking over it again, you are correct -- split into array does
> not do The Right Thing here. It will be easy to fix -- by the time
> you read this it will have been fixed and rebased back into
> bashification-redux.
It is, thanks. I'll have t
On Fri, Jul 23, 2010 at 7:29 AM, Thomas Bächler wrote:
> Am 17.07.2010 16:24, schrieb Victor Lowther:
>>> Sorry for taking so long. Apart from squashing the trivial
>>> bashifications, all patches I didn't comment on are ACKed.
>>
>> That is cool. I went ahead and reworked/squashed everthing I co
Am 17.07.2010 16:24, schrieb Victor Lowther:
>> Sorry for taking so long. Apart from squashing the trivial
>> bashifications, all patches I didn't comment on are ACKed.
>
> That is cool. I went ahead and reworked/squashed everthing I considered
> a "trivial bashification" into 6 or 7 patches afte
On Sun, Jul 11, 2010 at 1:11 PM, Thomas Bächler wrote:
> Am 11.07.2010 15:12, schrieb Victor Lowther:
>> On Sun, 2010-07-11 at 14:26 +0200, Thomas Bächler wrote:
>>> Am 11.07.2010 14:20, schrieb Victor Lowther:
Going back through and rewriting the patch series to do that will be
jsut abo
On Sun, Jul 11, 2010 at 2:11 PM, Thomas Bächler wrote:
> No no, that wouldn't make sense. It should be this way: First all
> patches that actually change logic, then one big commit that just
> converts the _remaining_ [ to [[ with no additional logic changes involved.
>
wouldn't it be better to do
Am 11.07.2010 15:12, schrieb Victor Lowther:
> On Sun, 2010-07-11 at 14:26 +0200, Thomas Bächler wrote:
>> Am 11.07.2010 14:20, schrieb Victor Lowther:
>>> Going back through and rewriting the patch series to do that will be
>>> jsut about as much effort as creating the original one was. If I had
On Sun, 2010-07-11 at 14:26 +0200, Thomas Bächler wrote:
> Am 11.07.2010 14:20, schrieb Victor Lowther:
> > Going back through and rewriting the patch series to do that will be
> > jsut about as much effort as creating the original one was. If I had
> > know that was what your preference was, I wo
Am 11.07.2010 14:20, schrieb Victor Lowther:
> Going back through and rewriting the patch series to do that will be
> jsut about as much effort as creating the original one was. If I had
> know that was what your preference was, I would have written it that
> way to begin with. Since the end resu
On Sun, Jul 11, 2010 at 4:45 AM, Thomas Bächler wrote:
> First of all: Sorry that I haven't finished the review, I have been busy
> with work and the heat kept me from thinking clearly.
>
> Am 07.07.2010 06:25, schrieb Dan McGee:
>> On Tue, Jul 6, 2010 at 11:03 PM, Allan McRae wrote:
>>> Here is
First of all: Sorry that I haven't finished the review, I have been busy
with work and the heat kept me from thinking clearly.
Am 07.07.2010 06:25, schrieb Dan McGee:
> On Tue, Jul 6, 2010 at 11:03 PM, Allan McRae wrote:
>> Here is a quick review on all these patches. I recommend that the lvm a
On Jul 6, 2010, at 11:25 PM, Dan McGee wrote:
If there was one thing I wasn't so fond of in these patches, it seemed
like there were too many.
Some people like larger patches, some like smaller ones. It is easier
to merge smaller ones together than it is to split larger ones apart.
The be
On Wed, 2010-07-07 at 14:03 +1000, Allan McRae wrote:
> Here is a quick review on all these patches. I recommend that the lvm
> and crypttab changes get a decent amount of testing before these go live
> as they are the biggest changes being done.
>
>
> Tighten up the console size finding code
On Tue, Jul 6, 2010 at 11:03 PM, Allan McRae wrote:
> Here is a quick review on all these patches. I recommend that the lvm and
> crypttab changes get a decent amount of testing before these go live as they
> are the biggest changes being done.
>
> Why has this been removed:
> -if [ -x /etc/
Here is a quick review on all these patches. I recommend that the lvm
and crypttab changes get a decent amount of testing before these go live
as they are the biggest changes being done.
Tighten up the console size finding code a bit.
Add some white space in test construct:
if ((STAT_C
On Thu, 2010-07-01 at 22:58 -0400, Caleb Cushing wrote:
> On Wed, Jun 30, 2010 at 6:07 PM, Victor Lowther
> wrote:
> >> I don't see the need for this patch. functions is not supposed to be
> >> executed standalone, it is only source'd from bash scripts.
> >
> > It is a habit I have -- including th
On Wed, Jun 30, 2010 at 6:07 PM, Victor Lowther
wrote:
>> I don't see the need for this patch. functions is not supposed to be
>> executed standalone, it is only source'd from bash scripts.
>
> It is a habit I have -- including the shebang line at the top makes sure
> my text editors automatically
Am 01.07.2010 00:07, schrieb Victor Lowther:
> On Wed, 2010-06-30 at 23:55 +0200, Thomas Bächler wrote:
>> Am 30.06.2010 23:47, schrieb Victor Lowther:
>>> Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
>>>
>>> Bashifying this framework should result in about a 30% speedup
On Wed, 2010-06-30 at 23:55 +0200, Thomas Bächler wrote:
> Am 30.06.2010 23:47, schrieb Victor Lowther:
> > Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
> >
> > Bashifying this framework should result in about a 30% speedup, assuming no
> > IO latency and that all progr
Am 30.06.2010 23:47, schrieb Victor Lowther:
> Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
>
> Bashifying this framework should result in about a 30% speedup, assuming no
> IO latency and that all programs we call also take zero time. :)
> ---
> functions |2 +-
>
Despite efforts to make the initscripts POSIX, we use bash 4.0 features.
Bashifying this framework should result in about a 30% speedup, assuming no
IO latency and that all programs we call also take zero time. :)
---
functions |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --g
29 matches
Mail list logo
