Reading the source code, i see that tdefcolor contains the following
case to handle 24-bit color codes. [1]
case 2: /* direct color in RGB space */
[ ... ]
idx = TRUECOLOR(r, g, b);
break;
The TRUECOLOR macro returns an integer with
On Sun, May 31, 2015 at 12:01:20PM -0400, s j wrote:
> printf "\e[38;2;255;255;255mTRUECOLOR"
Should it be a 16 bits value per component in order to accomodate cleanly 10
bits displays?
regards,
--
Sylvain
On Mon, Jun 1, 2015 at 3:23 PM, Aditya Goturu wrote:
> Why do we need to "appear busy". If people want to use better
> software, they will. We don't need to "appear busy"
>
It was a joke. This entire thread is a joke.
On Mon, Jun 01, 2015 at 10:28:40AM -0600, Anthony J. Bentley wrote:
> Suckless has settled on the wrong solutions for years. Case in point:
> customizing software by compiling it.
Seriously? Compiling dwm or st takes less than a second, sucks a lot
less (in of itself, without regard for context) t
On Mon, Jun 01, 2015 at 08:40:40PM +0200, Dmitrij D. Czarkoff wrote:
> Greg Reagle said:
> > I don't know git well, just the basics, but why don't you use a git
> > commit id as the target for patching and packaging? As far as I
> > understand, a tag is just a "friendly" name for a commit id anywa
On Mon, Jun 01, 2015 at 10:28:40AM -0600, Anthony J. Bentley wrote:
> 7heo writes:
> > Suckless comes from suck less. We're not here to settle down on wrong
> > solutions.
>
> Suckless has settled on the wrong solutions for years. Case in point:
> customizing software by compiling it. How often do
On Mon, Jun 1, 2015, at 03:31 PM, Jack L. Frost wrote:
> 1) How do I know if a certain tag is stable enough to use? Do I just take
> the
> current HEAD? Do I spend my time extensively testing a few latest tags to
> figure out if they are stable or not?
I assume by tag you mean commit because we ar
Greg Reagle wrote:
> To follow up on my suggestion to use a git commit as a version, the
> following command in fish automatically produces a version number:
> date --date (git log -1 --pretty=format:%aD) -u +%Y.%m.%d.%H.%M.%S
>
> In bash, it would be:
> date --date "$(git log -1 --pretty=format:%
Greg Reagle said:
> In bash, it would be:
> date --date "$(git log -1 --pretty=format:%aD)" -u +%Y.%m.%d.%H.%M.%S
date: unknown option -- -
usage: date [-aju] [-d dst] [-r seconds] [-t minutes_west] [-z output_zone]
[+format] [[cc]yy]mm]dd]HH]MM[.SS]]
But you have a point - this i
To follow up on my suggestion to use a git commit as a version, the
following command in fish automatically produces a version number:
date --date (git log -1 --pretty=format:%aD) -u +%Y.%m.%d.%H.%M.%S
In bash, it would be:
date --date "$(git log -1 --pretty=format:%aD)" -u +%Y.%m.%d.%H.%M.%S
--
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote:
> I don't know git well, just the basics, but why don't you use a git
> commit id as the target for patching and packaging? As far as I
> understand, a tag is just a "friendly" name for a commit id anyway.
1) How do I know if a certain
Why do we need to "appear busy". If people want to use better
software, they will. We don't need to "appear busy"
On Tue, Jun 2, 2015 at 12:42 AM, Greg Reagle wrote:
> On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote:
>> On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote:
>> > I don't
I agree. Thats probably why the software sucks less in the first place.
On Mon, Jun 1, 2015 at 8:55 PM, Martti Kühne wrote:
> On Mon, Jun 1, 2015 at 5:16 PM, Ivan Tham wrote:
>> Be confident for apps that suck less. Drop confident for apps that suck
>> more. More importantly, **The Author Should
On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote:
> On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote:
> > I don't know git well, just the basics, but why don't you use a git
> > commit id as the target for patching and packaging? As far as I
> > understand, a tag is just a "friendly"
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote:
> On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote:
> > As a packager, I'd very much appreciate tagging once in a while so that
> > we have
> > static targets for patching and packaging.
>
> I don't know git well, just the basics, b
Greg Reagle said:
> I don't know git well, just the basics, but why don't you use a git
> commit id as the target for patching and packaging? As far as I
> understand, a tag is just a "friendly" name for a commit id anyway.
1. In some packaging software that will fuck up package versioning and
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote:
> On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote:
> > As a packager, I'd very much appreciate tagging once in a while so that
> > we have
> > static targets for patching and packaging.
>
> I don't know git well, just the basics, bu
On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote:
> As a packager, I'd very much appreciate tagging once in a while so that
> we have
> static targets for patching and packaging.
I don't know git well, just the basics, but why don't you use a git
commit id as the target for patching and packa
On Mon, Jun 01, 2015 at 11:16:52AM +0200, Dmitrij D. Czarkoff wrote:
> Hi!
>
> There have been more then 2 years since 0.6 surf release (2013-02-10).
> Maybe it is time for 0.7?
As a packager, I'd very much appreciate tagging once in a while so that we have
static targets for patching and packagi
Martti Kühne said:
> Did you release your "big" patch to the public?
It is a set of patches. Some are from wiki; some are mine; some are
published.
> Is it that hard to port it to HEAD?
Trivial in my case. The point still stands though.
Also, I am planning to add gtk3 patch to the mix - gtk2
On Mon, Jun 1, 2015 at 7:08 PM, Dmitrij D. Czarkoff wrote:
> Martti Kühne said:
>> However upstream is not everyone's taste either, in that configuration
>> changes require recompiling of the respective binary.
>
> Exactly! I have a big patch for surf 0.6; it takes time to adopt these
> changes t
Martti Kühne said:
> However upstream is not everyone's taste either, in that configuration
> changes require recompiling of the respective binary.
Exactly! I have a big patch for surf 0.6; it takes time to adopt these
changes to current snapshot, and there are better ways to waste that
time then
Hi Ivan,
How are you determining the memory use of multiple processes? Is it accounting
for shared mappings? For example, I have a database application that has
mappings shared across processes for each core. When I look at top(1), my
memory usage would appear to be 200% when 4 processes are re
7heo writes:
> Suckless comes from suck less. We're not here to settle down on wrong
> solutions.
Suckless has settled on the wrong solutions for years. Case in point:
customizing software by compiling it. How often do you recompile mv, cp
and rm? Even compiling your kernel is something that shoul
Hey Frign.
> I'd be happy to see this annoying discussion resolved in the short term.
> More and more Arch hipsters found their way on this ML
You're doing it wrong then. It's not by calling people names that you're going
to make the discussion any shorter. ;)
Else, why the big fuss; because i
On Mon, Jun 01, 2015 at 05:34:28PM +0200, 7heo wrote:
> I personally understand your problem (I shortly contributed to alpine and had
> to report problems upstream, and I was more than glad when they accepted to
> merge my patches upstream, so I hear you), but I still think that arbitrary
> vers
On Mon, 01 Jun 2015 17:34:28 +0200
7heo <7...@mail.com> wrote:
Hey Theo,
> So yeah, it would solve your problem in the short term, but it would
> also encourage bad practices, which is a real problem on the long run.
I'd be happy to see this annoying discussion resolved in the short term.
Regula
We should seriously discuss this and settle down to a consistent guideline,
agreed.
On June 1, 2015 5:33:03 PM CEST, Joerg Jung wrote:
>On Mon, Jun 01, 2015 at 05:14:17PM +0200, Martti Kühne wrote:
>> On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote:
>>
>> From the average suckless user's view
I personally understand your problem (I shortly contributed to alpine and had
to report problems upstream, and I was more than glad when they accepted to
merge my patches upstream, so I hear you), but I still think that arbitrary
versions are the wrong approach. Arbitrary versions exist only so
On Mon, Jun 01, 2015 at 05:14:17PM +0200, Martti Kühne wrote:
> On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote:
>
> From the average suckless user's view, knowing what source is compiled
> and what config included is always wanted and preferred over other
> people's builds.
>
Average suckless
On Mon, Jun 1, 2015 at 5:16 PM, Ivan Tham wrote:
> Be confident for apps that suck less. Drop confident for apps that suck
> more. More importantly, **The Author Should Suck Less**
>
> I don't mean any insults. And if I did it, sorry.
I don't see suckless software shipped to people who wouldn't
> There are package managers which allow very easy re-compiling of
> packages with own patch-sets, especially due to projects like suckless.
> Several people, still prefer re-compiling of packages based on the given
> releases. Because from sysadmin point of view, packages are always
> wanted and p
On Mon, Jun 01, 2015 at 04:14:36PM +0100, Raphaël Proust wrote:
Hi, I use 2 windows of surf uses more memory then using firefox with 6 tabs
opened. Is there some memory leaks?
Open the six exact tabs of your FF in surf and compare that.
Open the two pages from your surf into your FF and compare
On Mon, Jun 01, 2015 at 05:09:43PM +0200, Martti Kühne wrote:
...everywhere...
that should obviously git.suckless.org there. :-)
It is just in case that there are 10,000 downloads per minute,
git.suckless.org will be seeding and those other downloader will help in
the progress.
How by Dennis R
On 1 June 2015 at 16:10, Ivan Tham wrote:
> Hi, I use 2 windows of surf uses more memory then using firefox with 6 tabs
> opened. Is there some memory leaks?
Open the six exact tabs of your FF in surf and compare that.
Open the two pages from your surf into your FF and compare that.
Some pages o
On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote:
>> >You're right in that package maintainers can't tell where the fixes
>> >and new features are coming in, they'll not introduce their own
>> >releases.
>
> Right, you disproved your own sentence above.
>
No need to get nitpicking, I saw and stil
http://www.catb.org/esr/writings/taoup/html/ch04s02.html#compactness
Hi, look at it and find man. Do you think we should put it in the wiki?
--
_
< Do what you like, like what you do. >
-
\ ^__^
\ (oo)\
Hi, I use 2 windows of surf uses more memory then using firefox with 6 tabs
opened. Is there some memory leaks?
--
_
< Do what you like, like what you do. >
-
\ ^__^
\ (oo)\___
(__)\ )\/
On Mon, Jun 1, 2015 at 5:06 PM, Ivan Tham wrote:
> On Sun, May 31, 2015 at 05:01:46PM +0200, Martti Kühne wrote:
>>>
>>> ...everywhere...
>>
>> that should obviously git.suckless.org there. :-)
>
>
> It is just in case that there are 10,000 downloads per minute,
> git.suckless.org will be seeding
Hi,
you are both wrong.
On Mon, Jun 01, 2015 at 04:39:39PM +0200, 7heo wrote:
> My point exactly. Plus, it does not even solve an actual problem.
It does, it makes life for downstream package maintainers (like me)
easier, as no cherry-picking of patches or own releases are required.
> On June
On Sun, May 31, 2015 at 05:01:46PM +0200, Martti Kühne wrote:
...everywhere...
that should obviously git.suckless.org there. :-)
It is just in case that there are 10,000 downloads per minute,
git.suckless.org will be seeding and those other downloader will help in
the progress.
--
___
On 1 June 2015 at 15:33, Martti Kühne wrote:
> However upstream is not everyone's taste either, in that configuration
> changes require recompiling of the respective binary.
I'm quite happy using the default configuration for most tools though,
as are a lot of people. And since it's the default i
My point exactly. Plus, it does not even solve an actual problem.
On June 1, 2015 4:33:55 PM CEST, "Martti Kühne" wrote:
>No it wouldn't help downstream package maintainers.
>You're right in that package maintainers can't tell where the fixes
>and new features are coming in, they'll not introduce
No it wouldn't help downstream package maintainers.
You're right in that package maintainers can't tell where the fixes
and new features are coming in, they'll not introduce their own
releases.
However upstream is not everyone's taste either, in that configuration
changes require recompiling of the
> Am 01.06.2015 um 11:16 schrieb Dmitrij D. Czarkoff :
>
> There have been more then 2 years since 0.6 surf release (2013-02-10).
> Maybe it is time for 0.7?
Yes, please.
Tagging a new release would help downstream
package maintainers.
Thanks,
Regards,
Joerg
7heo said:
> Package management is none of suckless's concern.
Not in case of package that has a metric fucktone of dependencies.
--
Dmitrij D. Czarkoff
Which brings us back to the question: what problem does it solve?
Package management is none of suckless's concern. I would go for removing
versions rather. We don't need those capitalist lies.
On June 1, 2015 2:38:27 PM CEST, "Dmitrij D. Czarkoff"
wrote:
>7heo said:
>> I don't get how that is
7heo said:
> I don't get how that is a problem. Versions don't have a 1:1 mapping
> to any mathematical function taking SLOCs as input, do they?
If you are done with pretending to be clueless, can we just assume that
versions have something to do with package management?
--
Dmitrij D. Czarkoff
On Mon, Jun 1, 2015 at 8:26 AM, 7heo <7...@mail.com> wrote:
> I don't get how that is a problem. Versions don't have a 1:1 mapping to any
> mathematical function taking SLOCs as input, do they?
No, but some software has a 1:1 mapping with a date and its version.
I propose a new suckless version
I don't get how that is a problem. Versions don't have a 1:1 mapping to any
mathematical function taking SLOCs as input, do they?
On June 1, 2015 1:47:19 PM CEST, Martin Kopta wrote:
>On Mon, Jun 01, 2015 at 01:15:36PM +0200, 7heo wrote:
>> On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff"
On Mon, Jun 01, 2015 at 01:15:36PM +0200, 7heo wrote:
> On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff"
> wrote:
> >Hi!
> >
> >There have been more then 2 years since 0.6 surf release (2013-02-10).
> >Maybe it is time for 0.7?
>
> What problem does it solve?
# Archlinux
$ pacman -Si surf
What problem does it solve?
On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff"
wrote:
>Hi!
>
>There have been more then 2 years since 0.6 surf release (2013-02-10).
>Maybe it is time for 0.7?
Hi!
There have been more then 2 years since 0.6 surf release (2013-02-10).
Maybe it is time for 0.7?
--
Dmitrij D. Czarkoff
you could switch to hg.
On 31 May 2015 at 14:09, Ivan Tham wrote:
> http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/
> […]
> Comments and insults are welcome.
Have you heard of IPFS? http://ipfs.io/
Might interest you.
Cheers,
--
__
Raphaël Proust
On 1 June 2015 at 02:02, Lee Fallat wrote:
> Git (and other CVSs) are inherently decentralized. Don't use a service
> like Github if you want a decentralized repository. Like someone else
> was saying, torrenting involves people to seed, and when they don't
> the torrent dies (in our case, a repos
56 matches
Mail list logo
