are doomed and should be banned.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Sat, 25 Jul 2015 19:07:08 +0200
Quentin Rameau quinq+dev@fifth.space wrote:
Did you have any time to do that?
Sorry, not then. I finished my exams today,
will do it end of next week. Sorry for the
delay.
Cheers
FRIGN
--
FRIGN d...@frign.de
with this.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Cheers
FRIGN
--
FRIGN d...@frign.de
on st was a lot of fun and I'm planning to do some more work on it
at the end of the month.
This has been a good time to tag, many people will be happy about this! ;)
Thank you guys for working on st!
Cheers
FRIGN
--
FRIGN d...@frign.de
security
matter should be fixable in finite time (unlike some GNU projects).
Cheers
FRIGN
--
FRIGN d...@frign.de
. ;)
Cheers
FRIGN
--
FRIGN d...@frign.de
on a professional basis?
Like, have you been paid by Google Inc. to work on st?
Cheers
FRIGN
--
FRIGN d...@frign.de
That's it!
If you have a large set of input modifications, you
could also hack the config.h-part a bit and include
another header with shared defines, and so on and
so on ...
Btw, I'd love to see a woman use suckless software.
Anybody know someone? ^^
Cheers
FRIGN
--
FRIGN d...@frign.de
for this program.
So TL;DR: it's not hard, it's just wrong.
That's what she said.
Cheers
FRIGN
--
FRIGN d...@frign.de
have numerous git-repos which just
are not that popular to begin with.
The big problem I see is authentication, which has already been
discussed in the article. Using and developing blockchains is not
easy and this leads to errors which I'm personally not keen on handling.
Cheers
FRIGN
--
FRIGN d
next time. I hate it when branch
merges infest the log-history. Just take the patches and apply them with
git am on the master branch, no magic please.
Cheers
FRIGN
--
FRIGN d...@frign.de
the stdin/stdout fd's are
for, fix the FILE*-handling instead of stacking on
top of it.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
And next time, please write some text to accomodate your
patches, so people know what you changed.
Additionally, this is common E-Mail etiquette, which I
value highly.
Cheers
FRIGN
--
FRIGN d...@frign.de
if
somebody tried to access your computer while you were out with friends
or fetching some food from the local pub.
Come to think of this sentence, who seriously eats at a pub?
Cheers
FRIGN
--
FRIGN d...@frign.de
the for loops out into their own function
too? Or all the if statements? After all, they are duplicated code.
This is near that level of retardedness.
Check out GNU coreutils if you like that.
You've also not propagated errors correctly... so it is a FAIL!
Where?
Cheers
FRIGN
--
FRIGN d
fixed this in the latest commit, thanks for reporting! Stay tuned for it
to be pushed to the suckless repositories, it's still in staging.
Please let me know if git am works now. :)
Cheers
FRIGN
--
FRIGN d...@frign.de
section if I were you.
Cheers
FRIGN
--
FRIGN d...@frign.de
to make them compatible
with latest Git.
Cheers
FRIGN
--
FRIGN d...@frign.de
the possibility
to columnize ls -l output.
I would do it, there's literally no reason not to allow columnizing ls -l,
and implementing output-format-stuff into ls just adds a lot to the cruft
for no practical reason.
Cheers
FRIGN
--
FRIGN d...@frign.de
the time to test it, but
codewise it's already very good. :)
Cheers
FRIGN
--
FRIGN d...@frign.de
and clear.
I'd remove the if, memmove is equivalent to a non-op when the offset
is 0.
Cheers
FRIGN
--
FRIGN d...@frign.de
this
bugtracker solves a problem that all other bugtrackers
leave unsolved.
If it is yet another NiH-timewaster, I can hardly
find the motivation to take a closer look at it.
Cheers
FRIGN
--
FRIGN d...@frign.de
).
Please again tell me what it does better than
bugseverywhere than only being less bug-ridden.
Cheers
FRIGN
--
FRIGN d...@frign.de
by POSIX, but are very well aware
this is a difficult matter of discussion.
Cheers
FRIGN
--
FRIGN d...@frign.de
guys we decided to drop -- parsing
for the sake of not breaking scripts. Commit should come in soon.
Nevertheless, please follow common E-Mail etiquette next time. This is not
WhatsApp.
Cheers
FRIGN
--
FRIGN d...@frign.de
have decided to
implement our own locale (LC_COLLATE) handler and supersede *libc strcoll().
FRIGN has proposed himself to act as the main developer on that, with any help
appreciated, many thanks to him!
The global project will be called “scollate” for now, but any better
suggestion
to support only this date format.
I second this!
--
FRIGN d...@frign.de
about the security and sanity of the results, and this is
the reason why I have a problem with that.
I propose UTF-8 everywhere, everything else sucks. Until then, I could live
with these preliminary locale-sets.
Cheers
FRIGN
--
FRIGN d...@frign.de
beyond that is mostly insane.
We assume a UTF-8-locale and that's it. setlocale is just ugly and imho
not the solution to this issue.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Maybe I now need to Internationalize the sound of my surname, because it
sounds
too ASCII?
Are you a troll?
Cheers
FRIGN
--
FRIGN d...@frign.de
is the future, there's no way around
it.
You need multiples of 8 bit to store non-ASCII-codepoints, but UTF-8 is doing a
great job.
Keep in mind: For most text streams, you are dealing with ASCII-characters. This
is one argument against UTF-16, which has a bottleneck in this regard.
Cheers
FRIGN
, ereallocarray, ...).
Cheers
FRIGN
--
FRIGN d...@frign.de
system.
The suckless core will be handled as a list any maybe later be also
an installable collection for, let's say, Alpine Linux.
I'm looking forward to your contributions, as this list is not complete,
and your feedback.
Cheers
FRIGN
--
FRIGN d...@frign.de
sortno -m, -o, -d, -f, -i
= xargs no -I, -L, -p, -s, -t, -x
Choose what you like.
Cheers
FRIGN
--
FRIGN d...@frign.de
become cool in the Arch-community, the number of
spam-threads on this list has grown beyond control.
Cheers
FRIGN
--
FRIGN d...@frign.de
to
actually see what the hell is in your struct.
I vote against applying it, and there's no reason to convolute
your code in this way.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Cheers
FRIGN
--
FRIGN d...@frign.de
the chance to refactor it early enough and you could use the
refactored version. ^^
This is a very creative idea and I bet it will keep your teacher wondering
what the hell you meant by that. :P
Keep up the great work!
Cheers
FRIGN
--
FRIGN d...@frign.de
far fontconfig is away from all
Pando-dependencies.
If we switch to libsl in the long run, I could live
with Pango being linked in libsl and all suckless-
programs below that touching it only with rubber gloves.
Cheers
FRIGN
--
FRIGN d...@frign.de
this.
Cheers
FRIGN
--
FRIGN d...@frign.de
, you'll be
able to answer most questions up there by yourself, and in any case, even
though I also like to write manuals, I see more use in writing, auditing
and testing code than writing long paragraphs and speeches about why this
and that utility is implemented or not.
Cheers
FRIGN
--
FRIGN d
, every movement
scrutinized.
--
FRIGN d...@frign.de
LIKE HELL.
CHEERS
FRIGN
--
FRIGN d...@frign.de
without fontconfig are not having trouble while the majority
of users will have an easier time setting up dwm and dmenu
harmoniously with st.
Let me know what you think.
Cheers
FRIGN
--
FRIGN d...@frign.de
to be effective in the very near future to adress these problems,
though a libsl with drw.c is the holy grail. ^^
Cheers
FRIGN
--
FRIGN d...@frign.de
On Tue, 3 Mar 2015 13:40:04 +
Dimitris Papastamos s...@2f30.org wrote:
This reminds me, we should really find another name for cols(1) now that
we have col(1).
Any ideas?
Maybe bw(1) as opposed to col(1) (black/white - color).
Or gcc(1), generate cool columns.
Cheers
FRIGN
--
FRIGN
pick the best from the ones written in a sucky
interface language.
Interfaces generally are an issue. If the interface is inherently non-
suckless, it's all about choosing the least trade-off.
Cheers
FRIGN
[0]: http://tronche.com/gui/x/icccm/
[1]: http://suckless.org/sucks
--
FRIGN d...@frign.de
On Sun, 1 Mar 2015 14:44:12 -0800
Michael Forney mfor...@mforney.org wrote:
That looks good to me.
Thanks! Applied:
http://git.2f30.org/sbase/commit/?id=48696d8c955db9d0621812aca7ef5caac727da31
--
FRIGN d...@frign.de
this
should work.
But please guys, don't flood this ml with these strange discussions and write
some
code instead. If you want to nag and want to masturbate to something, go to
reddit
or the Arch Forums.
Cheers
FRIGN
--
FRIGN d...@frign.de
to handle it.
This just pushes the problem onward to people who actually are not responsible
for it.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Tue, 24 Feb 2015 13:21:08 -0800
Sam Dodrill shadow.h...@gmail.com wrote:
Hey Sam,
I was wondering what you all use for a suckless style unit testing
framework in C.
I use {} for all my unit testing needs.
Cheers
FRIGN
--
FRIGN d...@frign.de
(that is, with nouveau). A byte-for-byte identical copy of st
under the same dwm but an Intel graphics chip seems to work fine.
I have to agree with the others here: This really looks like an issue
with you graphics-driver.
Nothing can be done here from our side.
Cheers
FRIGN
--
FRIGN d...@frign.de
.
Cheers
FRIGN
[0] http://en.wikipedia.org/wiki/Test_Anything_Protocol
[1] https://github.com/clibs/clib/wiki/Packages#testingquality-assurance
[2] https://github.com/kazuho/picogc/blob/master/t/test.h
[3] https://github.com/lpsantil/picotap/blob/master/t/test.c
--
FRIGN d...@frign.de
want to use.
The strictness of compile-time-configuration would be kept if we only
loaded fonts specified in the array. This would also bring a performance
gain for Unicode characters (The performance is horrible atm).
Cheers
FRIGN
--
FRIGN d...@frign.de
is not in
the current font dropped a lot of code in my case.
In config.def.h, the fallback font fontfb[] could already be set to some
sane default font everybody has and which has a big range of
Unicode-characters.
What do the others think?
Cheers
FRIGN
--
FRIGN d...@frign.de
is exactly when
ints and chars are mixed, given they both need 4 bytes of memory at the
end of the day.
Cheers
FRIGN
--
FRIGN d...@frign.de
to issue
a new version of the patch? Also, I think such a patch should be
considered for inclusion at http://st.suckless.org/patches/. Thank you!
There you go!
Please let me know if it works. Apply with git am.
Cheers
FRIGN
--
FRIGN d...@frign.de
From 56556405a10f3a677d50854e2f5aca353258e6ea Mon
through each filename _rune by rune_ and check if
isprintrune() is false, replacing the rune with '?'.
You probably need to implement a runestrtoutf()-function. I could do it
for you in case you need it.
Cheers
FRIGN
--
FRIGN d...@frign.de
works (it needs
cleaning though).
thanks for reporting this!
I remember writing this part of mkrunetype.awk at 2am in the morning.
In the end, the most trivial things are wrong. :P
I changed the underlying awk-script as well, so we're good to go now.
Cheers
FRIGN
--
FRIGN d...@frign.de
in Version 7 ATT UNIX.
The ioctl() can be assumed to be present on all systems, but in case
TIOCGWINSZ doesn't exist, we fall back to the fixed value. This is the
best of both worlds.
Cheers
FRIGN
--
FRIGN d...@frign.de
this way.
What's the problem? k0ga imho said pretty clearly why the usage() has developed
as
we know it.
The normal use is with eprintf() across the suckless-projects, but the non-zero
exit-status is a common approach and unimportant if you use it in an interactive
environment.
Cheers
FRIGN
interface to the web.
There are other areas where you can make a change. It's not looking like
the web is going to improve in the next couple of years.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Sun, 15 Feb 2015 19:35:51 +0100
k...@shike2.com wrote:
I like your solution, but I think COLUMNS should have a bigger
priority, because in this case user can define a different value of
the current width.
Okay, then do 3 fallbacks
ioctl - getenv - fixed width
--
FRIGN d...@frign.de
thoroughly test it without issues?
Cheers
FRIGN
--
FRIGN d...@frign.de
is to keep a slightly modified version of libutf
internally, but push all additions to the main repo on suckless,
after they have been discussed on the ml.
Cheers
FRIGN
[0]: http://git.2f30.org/sbase/tree/libutf
[1]: http://git.2f30.org/sbase/tree/libutf/fgetrune.c
--
FRIGN d...@frign.de
() into a new file called
runeio.c.
The name doesn't really matter, because on the outside, only the utf.h-
header will be exported.
Let me know what you think.
Cheers
FRIGN
[0]: http://git.2f30.org/sbase/tree/libutf/chartorunearr.c
[1]: http://plan9.bell-labs.com/sys/doc/utf.html
[2]: http://git.2f30.org
exist yet but may as well; see runestrcat(3).
That would also be very consistent. What do the others think?
Cheers
FRIGN
--
FRIGN d...@frign.de
about it.
Apparently, compilers are not as smart as I had in mind previously.
Going the separate approach is a good thing, so I welcome this
suggestion!
Cheers
FRIGN
--
FRIGN d...@frign.de
/tree/runetype.c
http://git.suckless.org/libutf/tree/runetypebody.h
Maybe we should remove libutf for the sake of political correctness.
--
FRIGN d...@frign.de
-sided polygon,
however, this does not mean 20h is a nazi or is using his name to
celebrate German history in some way.
Get over it!
Cheers
FRIGN
--
FRIGN d...@frign.de
both in lightness
and color is given according to WCAG 2.
I hope you like it and looking forward to your responses.
Cheers
FRIGN
[0]: http://suckless.org/logo.svg
[1]: http://frign.de/static/sl_30.svg
--
FRIGN d...@frign.de
become a link to the homepage, like the suckless.org header text is.
you are absolutely right! I fixed it now.
Cheers
FRIGN
--
FRIGN d...@frign.de
much and these are just minor details,
but it opens the way up to print the logo on caps or stickers
and looking at the suckless assembly at the 31C3, we are in dire
need of some simple icon to identify us.
Let me know what you think.
Cheers
FRIGN
[0]: http://frign.de/static
be rendered to static html. So don't bikeshed too
much until this is fixed.
Yes, this is a good point! If I wasn't occupied with sbase and exams currently,
I'd look at the issue.
Cheers
FRIGN
--
FRIGN d...@frign.de
the evil use of 0-days and government
backdoors in sbase.
I like your idea with MIN(LLONG_MAX, SIZE_MAX) which
is very smart. ;)
Keep up the great work! Patch should be pushed soon.
Cheers
FRIGN
--
FRIGN d...@frign.de
be added.
Cheers
FRIGN
--
FRIGN d...@frign.de
FRIGN
--
FRIGN d...@frign.de
implementation[0]
of it a while ago which makes a backup of a given xdg-open-script
and places itself on top of it.
It's cool to test out. If you don't like it, you can just make
uninstall and it will put everything in place again.
Cheers
FRIGN
[0]: http://git.2f30.org/soap
--
FRIGN d...@frign.de
is to allow these ideas.
In 99% of the cases, A-Z is sufficient though. But for a better experience,
I'll augment it as soon as I have put together some of my ideas.
Thanks for your feedback!
Cheers
FRIGN
--
FRIGN d...@frign.de
example of what POSIX requires. Cut is
another notable command with the same problem.
No wonder why it's behind .. They can't even maintain their codebases
properly.
Cheers
FRIGN
--
FRIGN d...@frign.de
for the C locale. What do
you mean by hugely misrepresenting? They are just fragments to build the
classes later on.
--
FRIGN d...@frign.de
above my head. ;)
At the end of the day, you want software to work as expected:
GNU tr:
$ echo ελληνική | tr [α-ω] [Α-Ω]
®
our tr:
$ echo ελληνικη | ./tr [α-ω] [Α-Ω]
ΕΛΛΗΝΙΚΗ
Cheers
FRIGN
--
FRIGN d...@frign.de
just fine!
Please test it and let me know what you think!
Cheers
FRIGN
--
FRIGN d...@frign.de
From 2ff2c365fac5a0c0c0b6ee88cbbb4502a2dcf0a6 Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Fri, 9 Jan 2015 20:36:27 +0100
Subject: [PATCH] Rewrite tr(1) in a sane way
tr(1) always used
On Fri, 09 Jan 2015 17:41:19 -0500
random...@fastmail.us wrote:
Or, is it possible that FRIGN misinterpreted the prohibition on
multi-character collating elements ?
Did you read what I said? I explicitly went away from POSIX in this regard,
because no human would write tr '\303\266o' 'o\303
with this information.
I stated that I did not implement collating elements into this tr(1) at
the beginning and that it's a POSIX-nightmare to do so, bringing harm
to anybody who is interested in a consistent, usable tool.
Cheers
FRIGN
--
FRIGN d...@frign.de
this is to pull it in from vis.c via extern.
Attached is a patch which does just that.
Cheers
FRIGN
--
FRIGN d...@frign.de
From 3cc548817bf61c71c7744e43da3b0d083b95b8e4 Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Sun, 4 Jan 2015 17:50:41 +0100
Subject: [PATCH] Set tabwidth and expandtab
even know
how the CPP works?
--
FRIGN d...@frign.de
On Sat, 3 Jan 2015 22:41:19 +0100
Matthias Rabault matthias.raba...@mailoo.org wrote:
The two values were previously supplied as magic constants.
Well, apart from this idea, what's the reason for the vis.h-header
and why is it not a separate patch?
--
FRIGN d...@frign.de
window)?
Cheers
FRIGN
--
FRIGN d...@frign.de
single big monolith you need ctags for to navigate.
It's no wonder the initial developer of ctags, Ken Arnold, is a die-hard
Java-proponent, a language we all know is designed to bloat problems up
unnecessarily.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Fri, 26 Dec 2014 10:24:27 +0100
FRIGN d...@frign.de wrote:
(...)
Modularity in general is what C is about and there's no reason NOT to have
a very complex problem separated into several smaller problems instead
of writing one single big monolith you need ctags for to navigate.
sorry
, they are not needed. Same applies
to special formatting of indents.
Argumentum ad personam. Great! I'd rather discuss the meritts of ctags
based on the program, please.
Chill out, this is suckless! We all know everyone who voluntarily develops
in Java is a crazy disillusioned zealot.
Cheers
FRIGN
--
FRIGN
I know is using ^fun for function definitions
void
fun(int a, char *b, size_t c)
{
}
Everything else is just plain crazy!
Cheers
FRIGN
--
FRIGN d...@frign.de
big number of patches for a given program.
Cheers
FRIGN
--
FRIGN d...@frign.de
On Tue, 23 Dec 2014 10:28:36 +0100
Anselm R Garbe garb...@gmail.com wrote:
Hey Anselm,
@FRIGN: I'm considering to apply your patches, with the exception
outlined of patch 4 line 41-70.
I'm okay with that. ;)
Do you want me to send you an updated patch 4 or are you able to
manually merge them
LICENSE file for copyright and license details.
See LICENSE file for copyright and license details.
See LICENSE file for copyright and license details.
See LICENSE file for copyright and license details.
See LICENSE file for copyright and license details.
--
FRIGN d...@frign.de
of the above
patches is merged.
Please let me know what you think.
Cheers
FRIGN
--
FRIGN d...@frign.de
From 1034776002946a5aea403e31ecf3d14deeae7742 Mon Sep 17 00:00:00 2001
From: FRIGN d...@frign.de
Date: Mon, 22 Dec 2014 14:17:21 +0100
Subject: [PATCH 1/5] Convert atoi - estrtol
Basically
+22,9 @@
#include bsd_auth.h
#endif
+#define COLOR1 black
+#define COLOR2 #005577
This is just wrong. Or do you expect people to dig
in the code to change the colours?
Better yet, if you want to make the separation, create
a config.h and put the option in there.
Cheers
FRIGN
--
FRIGN d
with the program properties
So just for the sake of consistency, given the two colours are a
program property, it should be in config.h (even if it is only 2
lines, who cares? There's not going to be a binary change and especially
no difference after the CPP-vomit).
Cheers
FRIGN
--
FRIGN d
201 - 300 of 695 matches
Mail list logo
