On Mon, 16 Mar 2015 08:54:39 +0300
"Alexander S." wrote:
Hey Alexander,
> Wow, didn't ever seen ye that full of yerself, 20h. Making up
> challenges for random people at the same time you tell them to never
> come back, eh? Must make a ton of sense to you.
Christoph is totally right. These peop
On Mon, Mar 16, 2015 at 02:12:16PM +0800, Ivan Tham wrote:
> Sorry for that, but I didn't say that I am unwilling to read a C book.
Yes, you did, you are inventing reasons to justify your actions:
> I want to learn C, so now I am waiting for c.learncodethehardway.org
> to release as other book ma
On 16 March 2015 at 05:58, Ivan Tham wrote:
> I want to learn C, so now I am waiting for c.learncodethehardway.org
> to release as other book may seem a bit too long for me.
You should rather learn C from its inventors:
http://en.wikipedia.org/wiki/The_C_Programming_Language
BR,
Anselm
Thanks. I will.
On 3/16/15, Anselm R Garbe wrote:
> On 16 March 2015 at 05:58, Ivan Tham wrote:
>> I want to learn C, so now I am waiting for c.learncodethehardway.org
>> to release as other book may seem a bit too long for me.
>
> You should rather learn C from its inventors:
>
> http://en.wiki
Otherwise, pasting the X11 primary selection when empty results an
error and Xlib forcibly exits.
---
st.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/st.c b/st.c
index ac91d9f..cd470e7 100644
--- a/st.c
+++ b/st.c
@@ -1012,6 +1012,8 @@ selnotify(XEvent *e) {
ofs = 0;
x
Greetings.
On Mon, 16 Mar 2015 20:31:48 +0100 Alex Pilon wrote:
> Otherwise, pasting the X11 primary selection when empty results an
> error and Xlib forcibly exits.
Thanks for sending the patch. I was debuggint that crash myself already.
You were faster. It has been applied.
Sincerely,
Chris
On Sun, Mar 15, 2015, at 11:02 AM, Markus Teich wrote:
> read http://git-scm.com/book/en/v2 at least until chapter 3.
Thanks for this recommendation. I will read it. (I know it was
intended for someone else.) I have a pretty good basic understanding of
git and I've created, merged, and deleted
---
du.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/du.c b/du.c
index 6ecebc9..962e61c 100644
--- a/du.c
+++ b/du.c
@@ -29,7 +29,7 @@ printpath(size_t n, const char *path)
}
static size_t
-nblks(blkcnt_t blocks)
+nblks(size_t blocks)
{
return (512 * blocks + b
On Mon, Mar 16, 2015 at 03:47:21PM -0400, Steven Dee wrote:
> ---
> du.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/du.c b/du.c
> index 6ecebc9..962e61c 100644
> --- a/du.c
> +++ b/du.c
> @@ -29,7 +29,7 @@ printpath(size_t n, const char *path)
> }
>
> static size
On Mon, Mar 16, 2015 at 8:47 PM, Steven Dee wrote:
> ---
> du.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/du.c b/du.c
> index 6ecebc9..962e61c 100644
> --- a/du.c
> +++ b/du.c
> @@ -29,7 +29,7 @@ printpath(size_t n, const char *path)
> }
>
> static size_t
> -nblks
It's easy to forget things, like fixed with the following out of tree
patch.
commit ec6937b989a171e872c58bc60f8b21bd25880cd5
Author: M Farkas-Dyck
Date: Wed Dec 10 14:29:34 2014 -0500
dist arg.h; needed to build
diff --git a/Makefile b/Makefile
index 52af636..25719
Greetings.
On Mon, 16 Mar 2015 22:18:33 +0100 Alex Pilon wrote:
> commit ec6937b989a171e872c58bc60f8b21bd25880cd5
> Author: M Farkas-Dyck
> Date: Wed Dec 10 14:29:34 2014 -0500
>
> dist arg.h; needed to build
>
> diff --git a/Makefile b/Makefile
> index 52af636..2
> On Mon, 16 Mar 2015 22:18:33 +0100 Alex Pilon wrote:
> > Less code, and people notice when things aren't in the repo unlike a
> > little used target.
>
On Mon, Mar 16, 2015 at 10:18:33PM +0100, Christoph Lohmann wrote:
> That's too simple-minded. You are adding a dependency on git.
I considered
Is there a reason -lrt is missing from config.mk in sbase? I recall
seeing some messages saying that OpenBSD lacks -lrt support (or
something to that effect), but since its a POSIX library and is required
to compile find, it seems like it should be present by default.
Searching the list for "-lrt",
Hi,
> I considered that, but thought it the lesser evil. *Ideally*, build
> systems and version control systems shouldn't be tightly coupled, if at
> all. I have my own prejudices, and we can agree to cordially disagree on
> such a trivial and here insignificant matter.
Why do you suppose that
15 matches
Mail list logo