On Jul 17, 2013 7:39 PM, "Calvin Morrison" wrote:
>
> What was the last time you used the reverse polish notation calculator
> that precedes the invention of C?
It is the calculator I always use.
Dmitrij D. Czarkoff
Sorry, I typed that by head. it's ;2; instead of ;5;
Here's a test case
printf "\x1b[38;2;255;100;0mTRUECOLORBITCHES\x1b[0m\n"
According to Wikipedia[1], this is only supported by xterm and konsole.
It's a common confusion about terminal colors... Actually we have this:
* plain ascii
* ansi e
Bjartur Thorlacius writes:
> On 07/17/2013 09:02 PM, Calvin Morrison wrote:
>> So it seems a good deal of that time is ls
>>
> Wait, sbase ls doesn't seem to implement -f. Are you sorting the
> directory entries?
Using -f improves performance a bit, but no matter what, an 'ls
-whatever|wc -l' pi
On 7/17/13, Calvin Morrison wrote:
> On 17 July 2013 16:32, Christian Neukirchen wrote:
>> What's the bottle neck here?
>
> Looking up the filenames and reading them, printing them to standard
> out and then wc parsing for all the \n characters.
Most ls implementations also sort the list of fil
Hi. I've noticed some odd screen clearing problems with TUI aptitude
(which switches to alternate screen when invoking dpkg, and instead of
clearing it just prints "0" and overwrites whatever text it has) and
transmission-remote-cli, which does the same upon exiting. This is
most likely due to mis-
> * plain ascii
> * ansi escape codes (16 color codes with bold/italic and background)
> * 256 color palette (216 colors+16gray + ansi) (colors are 24bit)
> * 24bit true color (8*8*8 colors (aka 16 milion)
>
Ok, I think we could add it to st without too much problems. But we should think
if it ha
On Thu, Jul 18, 2013 at 04:00:13PM +0400, Alexander Sedov wrote:
> Hi. I've noticed some odd screen clearing problems with TUI aptitude
> (which switches to alternate screen when invoking dpkg, and instead of
> clearing it just prints "0" and overwrites whatever text it has) and
> transmission-remo
* Calvin Morrison [2013-07-17 16:43:00 -0400]:
> On 17 July 2013 16:32, Christian Neukirchen wrote:
> >> calvin@ecoli:~/big_folder> time ls file2v1dir/ | wc -l
> >> 687560
> >>
> >> real0m7.798s
> >> user0m7.317s
> >> sys 0m0.700s
> >>
> >> calvin@ecoli:~/big_folder> time ~/bin/dc fil
>Added mdprint().
> Update $(HDR) in Makefile to avoid build errors
> with sbase-box target.
I have decided to apply this; the net change in code went from
+83 in the first version to a completely bearable +15. If sha512sum,
et c. show up, this is definitely be net win.
On Thu, Jul 18, 2013 at 09:59:30AM -0400, Galos, David wrote:
> >Added mdprint().
>
> > Update $(HDR) in Makefile to avoid build errors
> > with sbase-box target.
>
> I have decided to apply this; the net change in code went from
> +83 in the first version to a completely bearable +15. If sha512s
Have you found time to look at my patch David?
2013/7/18 sin
> On Thu, Jul 18, 2013 at 09:59:30AM -0400, Galos, David wrote:
> > >Added mdprint().
> >
> > > Update $(HDR) in Makefile to avoid build errors
> > > with sbase-box target.
> >
> > I have decided to apply this; the net change in code
> Have you found time to look at my patch David?
I glimpsed at it; I've been busy this week, so I'm taking
some time now to catch up.
I don't think your most recent patch will apply given the
changes to the function arguments in sha1/md5 introduced
with this patch. It should be trivial for you to
With Truls' modifications, I have applied the patch. Sbase now
has tar.
Test away,
Dave
> It doesn't, as far as I can tell. That implementation comes from OpenBSD's
> who.
Is the utmp file guaranteed to be machine endian? This patch seems to imply
that.
> *environ = NULL;
The linux manpage suggests 'environ = NULL'. Is BSD different in that regard?
I would like to see sbase compile
On Wed, Jul 17, 2013 at 01:23:33PM -0400, Calvin Morrison wrote:
> Hi guys,
>
> I came up with a utility[0] that i think could be useful, and I sent
> it to the moreutils page, but maybe it might fit better here. All it
> does is give a count of files in a directory.
>
> I was sick of ls | wc -l
I'm the author of radare and I did this code. So yep :) i know how r2 uses it.
I have added a config var to enable truecolor support. You can run this command
to test. (Using r2 from git)
r2 -e scr.truecolor=true -cecr /bin/ls
"ecr" will create a random color palette
You can run r2 -cecs - to
On 17/07/2013, Calvin Morrison wrote:
> I came up with a utility[0] that i think could be useful, and I sent
> it to the moreutils page, but maybe it might fit better here. All it
> does is give a count of files in a directory.
$ ls | wc -l
> I was sick of ls | wc -l being so damned slow on larg
On Thu, Jul 18, 2013 at 11:31 AM, Galos, David
wrote:
>> It doesn't, as far as I can tell. That implementation comes from OpenBSD's
>> who.
> Is the utmp file guaranteed to be machine endian?
OpenBSD assumes it is. And on Linux, man 5 utmp claims: "The file
format is machine-dependent, so it is r
On 18 July 2013 11:33, Markus Wichmann wrote:
> On Wed, Jul 17, 2013 at 01:23:33PM -0400, Calvin Morrison wrote:
>> Hi guys,
>>
>> I came up with a utility[0] that i think could be useful, and I sent
>> it to the moreutils page, but maybe it might fit better here. All it
>> does is give a count of
Am 2013-07-18 17:33, schrieb Markus Wichmann:
Also, there already is a constant for the maximum
path length of a file. It's called PATH_MAX and already includes the
NUL
byte.
isn't PATH_MAX a GNU extension?
--Markus
* Markus Teich [2013-07-18 18:37:57 +0200]:
>
> isn't PATH_MAX a GNU extension?
>
no, actually gnu hurd was a proponent of unlimited paths
(so any file operation has unbounded latency on hurd only limited by
the address space)
PATH_MAX is posix and should be defined in limits.h
FILENAME_MAX is
* Szabolcs Nagy [2013-07-18 18:51:09 +0200]:
> PATH_MAX is posix and should be defined in limits.h
> FILENAME_MAX is iso c and is defined in stdio.h (usually PATH_MAX-1)
sorry i was wrong about the -1
FILENAME_MAX is buffer size, not string length
> > What's the bottle neck here?
>
> Looking up the filenames and reading them, printing them to standard
> out and then wc parsing for all the \n characters.
None of the time comes from wc. Changing from ' | wc -l' to
'> /dev/null' creates no speedup at all.
ls's bottlenecks come almost entirely
On 07/17/2013 06:13 PM, Calvin Morrison wrote:
I rely heavily on unioned directories (go plan9!) so mine tend to get
large when working with many large datasets.
Does anyone use large directories often?
Unices avoid large directories to scalability problems like the one
you're trying to solve.
Based on the discussion in 'coreutils / moreutils - DC a directory counter'
I have optimized sbase ls to easily handle large directories. The major
change is that ls no longer calls 'lstat' on files if it does not have to.
This patch also add '-U' which keeps the list from being sorted. When using
On 18 July 2013 15:00, Galos, David wrote:
> Based on the discussion in 'coreutils / moreutils - DC a directory counter'
> I have optimized sbase ls to easily handle large directories. The major
> change is that ls no longer calls 'lstat' on files if it does not have to.
>
> This patch also add '-
I have applied this patch. OpenBSD users rejoice, you
too can finally experience sbase!
From: "Roberto E. Vargas Caballero"
OpenBSD defines strlcpy function, and the declaration is a bit different
of the static declartion found in tar.c. The duplication of symbol name
with different type (one extern and other static, one returning int and
the other returning size_t) caused tar could
Hi.
I made a patch that improves the performance of font caching mechanism.
This is based on a funny behaviour of FontConfig: it was handling
FcCharSet in a somewhat unexpected way.
So, we are currently adding "a character" to a new FcCharSet, and then
add it to a FcPattern. However, if we toss t
> I've been testing this patch for some time, but not really sure if this
> is stable enough. Also, this patch is base on 40e4d76 (the current HEAD)
It seems good for me, and I think we could add it to HEAD and it could
help others could test it to. If nobody says something about it, I
will add it
30 matches
Mail list logo
