Re: [hackers] About swapfocus dwm patch
Thank you Daniel for your reply. One of the maintainers replied, and there
are indeed issues with the patch. I will try stacker instead.
Best regards,
Vinícius.
--
Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE
Long Key ID:
8E65EA37669D90BE
Short Key ID:
669D90BE
On Thu, Oct 1, 2020 at 10:42 AM Daniel Littlewood
wrote:
> Hi Vinicius,
>
> I think the "patch does not apply" error may be a red herring. The
> patch applies cleanly for me directly to dwm 6.2, but does not
> compile.
> dwm.c:2161:52: error: ‘Monitor’ {aka ‘struct Monitor’} has no
> member named ‘pertag’
> On the other hand, the patch conflicts you get if you apply pertag
> first are caused by the swapfocus patch including parts of pertag in
> its diff. I tried removing the parts of pertag that swapfocus
> includes, but could not get something compilable.
>
> I would probably check with the maintainer, but there could be a fix
> I'm not seeing.
>
> All the best,
> Daniel
>
> On Wed, Sep 30, 2020 at 6:54 AM vinícius mota wrote:
> >
> > Thank you very much Chris for your reply.
> >
> > I just tried again, from scratch, and failed again, with the same error.
> Early on today I successfully installed other suckless patches, this time
> for st, following the same procedure and everything worked flawlessly. In
> fact since I have two other patches for dwm in place, everytime dwm is
> reinstalled those two patches are reinstalled as well, and that happened
> several times today.
> >
> > It may be nonsense but I have looked up several patches' codes today and
> noticed that the beginning of the swapfocus patch is different, with a
> different "diff" command:
> >
> > diff -up a/config.def.h b/config.def.h
> > --- a/config.def.h 2020-01-29 00:06:12.415681126 +0100
> > +++ b/config.def.h 2020-01-29 13:25:14.167910093 +0100
> > @@ -66,6 +66,7
> >
> > while for all others that I have looked in such as hide vacant tags the
> diff command reads
> >
> > diff --git a/dwm.c b/dwm.c
> > index 4465af1..c4aa3de 100644
> > --- a/dwm.c
> > +++ b/dwm.c
> > @@ -416,7 +416,7 @@
> >
> > Other than that I have no idea of why it is failing the way it is.
> >
> > Anyway, thank you again very much for your reply.
> >
> > Vinícius.
> >
> >
> >
> >
> > --
> > Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE
> > Long Key ID:
> 8E65EA37669D90BE
> > Short Key ID:
>669D90BE
> >
> >
> > On Tue, Sep 29, 2020 at 10:29 PM Chris Down
> wrote:
> >>
> >> Hi Vinícius,
> >>
> >> The error message from patch is quite clear that it failed to apply, so
> >> compilation is premature. You need to either massage it in, or find a
> patch
> >> which roughly matches your version.
> >>
>
>
[hackers] [quark][PATCH] Fix docindex not being served
Previously, when a directory was requested, the index body was not sent,
and the MIME type defaulted to "application/octet-stream".
---
http.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/http.c b/http.c
index f1e15a4..2d3f17f 100644
--- a/http.c
+++ b/http.c
@@ -738,6 +738,12 @@ http_prepare_response(const struct request *req, struct
response *res,
S_FORBIDDEN : S_NOT_FOUND;
goto err;
}
+ } else {
+ if (esnprintf(res->path, sizeof(res->path), "%s%s",
+ vhost ? vhost->dir : "", RELPATH(tmpuri))) {
+ s = S_REQUEST_TOO_LARGE;
+ goto err;
+ }
}
}
@@ -778,7 +784,7 @@ http_prepare_response(const struct request *req, struct
response *res,
/* mime */
mime = "application/octet-stream";
- if ((p = strrchr(realuri, '.'))) {
+ if ((p = strrchr(res->path, '.'))) {
for (i = 0; i < LEN(mimes); i++) {
if (!strcmp(mimes[i].ext, p + 1)) {
mime = mimes[i].type;
--
2.28.0
Re: [hackers] sfakeroot (announce?)
Hi Richard Richard Ipsum wrote: > For a while I've been writing some tests which cover basic POSIX util > functionality, these tests have been quite useful in helping me find > bugs in sbase and other implementations. Recently though I wrote some Those tests sound interesting! Are they publicly available somewhere? Cheers, Silvan
Re: [hackers] About swapfocus dwm patch
Thank you Aaron for your kind reply. I will indeed try stacker instead. Best regards, Vinícius. -- Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE Long Key ID: 8E65EA37669D90BE Short Key ID: 669D90BE On Thu, Oct 1, 2020 at 11:53 AM Aaron Duxler wrote: > Hi Vinícius, > > sorry for the inconveniences. I have added a view features to the > swapfocus patch, because I did not like the default behavior of it. > > Though I'm not using this patch any more and for that reason I won't fix > the patch. > If it is really not working I will remove the recent swapfocus patch from > the wiki. > > I'm using now the stacker patch instead. It also provides the features > swapfocus provided as well as some other useful stuff. > Imho the stacker patch is also a lot cleaner. > I would recommend you to either try an older version of swapfocus or the > stacker patch instead. > > Sorry and kind regards, > Aaron > > > Am 30. September 2020 04:58:01 MESZ schrieb "vinícius mota" < > vcmot...@gmail.com>: > >Thank you very much Chris for your reply. > > > >I just tried again, from scratch, and failed again, with the same > >error. > >Early on today I successfully installed other suckless patches, this > >time > >for st, following the same procedure and everything worked flawlessly. > >In > >fact since I have two other patches for dwm in place, everytime dwm is > >reinstalled those two patches are reinstalled as well, and that > >happened > >several times today. > > > >It may be nonsense but I have looked up several patches' codes today > >and > >noticed that the beginning of the swapfocus patch is different, with a > >different "diff" command: > > > >diff -up a/config.def.h b/config.def.h > >--- a/config.def.h 2020-01-29 00:06:12.415681126 +0100 > >+++ b/config.def.h 2020-01-29 13:25:14.167910093 +0100 > >@@ -66,6 +66,7 > > > >while for all others that I have looked in such as hide vacant tags the > >diff command reads > > > >diff --git a/dwm.c b/dwm.c > >index 4465af1..c4aa3de 100644 > >--- a/dwm.c > >+++ b/dwm.c > >@@ -416,7 +416,7 @@ > > > >Other than that I have no idea of why it is failing the way it is. > > > >Anyway, thank you again very much for your reply. > > > >Vinícius. > > > > > > > > > >-- > >Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE > >Long Key ID: > >8E65EA37669D90BE > >Short Key ID: > > 669D90BE > > > > > >On Tue, Sep 29, 2020 at 10:29 PM Chris Down > >wrote: > > > >> Hi Vinícius, > >> > >> The error message from patch is quite clear that it failed to apply, > >so > >> compilation is premature. You need to either massage it in, or find a > >> patch > >> which roughly matches your version. > >> > >> >
Re: [hackers] About swapfocus dwm patch
Hi Vinícius, sorry for the inconveniences. I have added a view features to the swapfocus patch, because I did not like the default behavior of it. Though I'm not using this patch any more and for that reason I won't fix the patch. If it is really not working I will remove the recent swapfocus patch from the wiki. I'm using now the stacker patch instead. It also provides the features swapfocus provided as well as some other useful stuff. Imho the stacker patch is also a lot cleaner. I would recommend you to either try an older version of swapfocus or the stacker patch instead. Sorry and kind regards, Aaron Am 30. September 2020 04:58:01 MESZ schrieb "vinícius mota" : >Thank you very much Chris for your reply. > >I just tried again, from scratch, and failed again, with the same >error. >Early on today I successfully installed other suckless patches, this >time >for st, following the same procedure and everything worked flawlessly. >In >fact since I have two other patches for dwm in place, everytime dwm is >reinstalled those two patches are reinstalled as well, and that >happened >several times today. > >It may be nonsense but I have looked up several patches' codes today >and >noticed that the beginning of the swapfocus patch is different, with a >different "diff" command: > >diff -up a/config.def.h b/config.def.h >--- a/config.def.h 2020-01-29 00:06:12.415681126 +0100 >+++ b/config.def.h 2020-01-29 13:25:14.167910093 +0100 >@@ -66,6 +66,7 > >while for all others that I have looked in such as hide vacant tags the >diff command reads > >diff --git a/dwm.c b/dwm.c >index 4465af1..c4aa3de 100644 >--- a/dwm.c >+++ b/dwm.c >@@ -416,7 +416,7 @@ > >Other than that I have no idea of why it is failing the way it is. > >Anyway, thank you again very much for your reply. > >Vinícius. > > > > >-- >Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE >Long Key ID: >8E65EA37669D90BE >Short Key ID: > 669D90BE > > >On Tue, Sep 29, 2020 at 10:29 PM Chris Down >wrote: > >> Hi Vinícius, >> >> The error message from patch is quite clear that it failed to apply, >so >> compilation is premature. You need to either massage it in, or find a >> patch >> which roughly matches your version. >> >>
Re: [hackers] [sbase][PATCH 5/5] fold: fix handling of -s
On 2020-06-20, Richard Ipsum wrote:
> diff --git a/fold.c b/fold.c
> index 169064b..10a23cf 100644
> --- a/fold.c
> +++ b/fold.c
> @@ -29,12 +29,14 @@ foldline(struct line *l) {
> eprintf("fwrite :");
> if (l->data[i] != '\n')
> putchar('\n');
> - last = (sflag && spacesect) ? spacesect : i;
> + if (sflag && spacesect)
> + i = spacesect;
> + last = i;
> col = 0;
> spacesect = 0;
> }
> runelen = chartorune(, l->data + i);
> - if (sflag && isspace(l->data[i]))
> + if (sflag && isblankrune(r))
It seems like this hunk might belong better with patch 4/5? Or maybe
4/5 should use isspacerune, and change it to isblankrune here.
> spacesect = i + 1;
I think this should be `i + runelen` in case there is a multibyte blank.
> if (!bflag && iscntrl(l->data[i])) {
> switch(l->data[i]) {
Re: [hackers] About swapfocus dwm patch
Hi Vinicius,
I think the "patch does not apply" error may be a red herring. The
patch applies cleanly for me directly to dwm 6.2, but does not
compile.
dwm.c:2161:52: error: ‘Monitor’ {aka ‘struct Monitor’} has no
member named ‘pertag’
On the other hand, the patch conflicts you get if you apply pertag
first are caused by the swapfocus patch including parts of pertag in
its diff. I tried removing the parts of pertag that swapfocus
includes, but could not get something compilable.
I would probably check with the maintainer, but there could be a fix
I'm not seeing.
All the best,
Daniel
On Wed, Sep 30, 2020 at 6:54 AM vinícius mota wrote:
>
> Thank you very much Chris for your reply.
>
> I just tried again, from scratch, and failed again, with the same error.
> Early on today I successfully installed other suckless patches, this time for
> st, following the same procedure and everything worked flawlessly. In fact
> since I have two other patches for dwm in place, everytime dwm is reinstalled
> those two patches are reinstalled as well, and that happened several times
> today.
>
> It may be nonsense but I have looked up several patches' codes today and
> noticed that the beginning of the swapfocus patch is different, with a
> different "diff" command:
>
> diff -up a/config.def.h b/config.def.h
> --- a/config.def.h 2020-01-29 00:06:12.415681126 +0100
> +++ b/config.def.h 2020-01-29 13:25:14.167910093 +0100
> @@ -66,6 +66,7
>
> while for all others that I have looked in such as hide vacant tags the diff
> command reads
>
> diff --git a/dwm.c b/dwm.c
> index 4465af1..c4aa3de 100644
> --- a/dwm.c
> +++ b/dwm.c
> @@ -416,7 +416,7 @@
>
> Other than that I have no idea of why it is failing the way it is.
>
> Anyway, thank you again very much for your reply.
>
> Vinícius.
>
>
>
>
> --
> Fingerprint: 1224546E7D5435465E1777CB8E65EA37669D90BE
> Long Key ID:
> 8E65EA37669D90BE
> Short Key ID:
> 669D90BE
>
>
> On Tue, Sep 29, 2020 at 10:29 PM Chris Down wrote:
>>
>> Hi Vinícius,
>>
>> The error message from patch is quite clear that it failed to apply, so
>> compilation is premature. You need to either massage it in, or find a patch
>> which roughly matches your version.
>>
Re: [hackers] Licensing status of patches
On Thu, 1 Oct 2020 09:04:32 +0100 Daniel Littlewood wrote: Dear Daniel, > My argument that the GPL is simpler here is that in the "default case" > where changes are simply submitted without the contributor talking > about licensing, the project as a whole is not covered by the given > license (only those contributions which have explicitly agreed to it). > For small projects, or projects hosted on Github, this is no problem. > > But if, some time later, a user decides they want to fork the project, > simply seeing that the project is free is not enough to guarantee they > can use it. They need to see either something like a CLA (which may > cede the copyright to the maintainer, or simply agree that their > contributions inherit the parent license), or an explicit statement > from every contributor agreeing to license their changes under a free > license. > > So whether it's a "need" or a "simplification" is a matter of > perspective - I only think it would matter for projects above a > certain size. But the need to get access to downstream changes of your > own project is one of the motivating factors behind the GPL - I > believe Linus cites it as his motivation for choosing it for Linux. ah I see, yes, this is a big bonus of the GPL, as it mandates that for derivative works and modifications. Thanks for your elaboration! With best regards Laslo
Re: [hackers] Licensing status of patches
Dear Laslo, > as far as I know, there's no need for a CLA. CLAs are just a > simplification that contributors waive their rights to the code to the > legal entity behind the project so the license file is not littered > with 100s of people but only the legal entity. Which license you're > using doesn't matter here. Please correct me if I'm wrong. My argument that the GPL is simpler here is that in the "default case" where changes are simply submitted without the contributor talking about licensing, the project as a whole is not covered by the given license (only those contributions which have explicitly agreed to it). For small projects, or projects hosted on Github, this is no problem. But if, some time later, a user decides they want to fork the project, simply seeing that the project is free is not enough to guarantee they can use it. They need to see either something like a CLA (which may cede the copyright to the maintainer, or simply agree that their contributions inherit the parent license), or an explicit statement from every contributor agreeing to license their changes under a free license. So whether it's a "need" or a "simplification" is a matter of perspective - I only think it would matter for projects above a certain size. But the need to get access to downstream changes of your own project is one of the motivating factors behind the GPL - I believe Linus cites it as his motivation for choosing it for Linux. Hope that helps, Daniel On Thu, Oct 1, 2020 at 7:36 AM Laslo Hunhold wrote: > > On Wed, 30 Sep 2020 19:06:32 +0100 > Daniel Littlewood wrote: > > Dear Daniel, > > > I am wary of going too far off topic, but I think a convincing > > argument against the use of "permissive" licenses like MIT is that if > > your project grows above a certain size, it necessitates CLAs in > > addition to a license. If you do not use a platform like GitHub who > > guarantees that inbound=outbound, then you don't necessarily have a > > right to your contributors' changes, which I'm sure could be painful. > > Sure, it's an unlikely situation, but so are most pathological > > behaviours that necessitate a license. > > as far as I know, there's no need for a CLA. CLAs are just a > simplification that contributors waive their rights to the code to the > legal entity behind the project so the license file is not littered > with 100s of people but only the legal entity. Which license you're > using doesn't matter here. Please correct me if I'm wrong. > > With best regards > > Laslo >
Re: [hackers] [sbase][PATCH 4/5] fold: fix handling of multibyte characters
On Wed, 30 Sep 2020 22:41:47 -0700 Michael Forney wrote: Dear Michael, > POSIX says we should be counting column positions rather than > codepoints, but I think that might be rather difficult to get right > and this is probably an improvement already. > > I know Laslo has studied this area for libgrapheme, so maybe he has > suggestions. if you want to do it 100% right, there's no way around using libgrapheme (or another library handling grapheme clusters like icu, but I bet there's none nearly as lightweight as libgrapheme). Counting codepoints is only halfway there and there are trivial counterexamples which prove that this is not the complete solution and there are discrepancies. On the other hand, in the western world, most grapheme clusters are emojis and certain cases with more complex writing systems. It's a much different matter when you go to asia or africa, where you can't really properly implement many very popular writing systems (like Hangul) without using grapheme clusters. Most importantly in general though are if you're processing denormalized input (i.e. where everything is broken down as much as possible, for example the single codepoint (=1-codepoint-grapheme-cluster) "ä" is turned into the codepoint "a" with an umlaut modifier, making it a 2-codepoint-grapheme-cluster), leading to a lot of gotchas, inconsistencies and maybe even security problems. All in all though, codepoint-counting is a step in the right direction, but definitely not exhaustive, especially as time moves on and more and more people are using the higher unicode planes for data. If you really want to do it right, you must handle grapheme clusters, and libgrapheme is actually very fast and should even be faster than the Rune-solution using libutf.h, because it works on the byte-level rather than the Codepoint-level. With best regards Laslo
Re: [hackers] Licensing status of patches
On Wed, 30 Sep 2020 19:06:32 +0100 Daniel Littlewood wrote: Dear Daniel, > I am wary of going too far off topic, but I think a convincing > argument against the use of "permissive" licenses like MIT is that if > your project grows above a certain size, it necessitates CLAs in > addition to a license. If you do not use a platform like GitHub who > guarantees that inbound=outbound, then you don't necessarily have a > right to your contributors' changes, which I'm sure could be painful. > Sure, it's an unlikely situation, but so are most pathological > behaviours that necessitate a license. as far as I know, there's no need for a CLA. CLAs are just a simplification that contributors waive their rights to the code to the legal entity behind the project so the license file is not littered with 100s of people but only the legal entity. Which license you're using doesn't matter here. Please correct me if I'm wrong. With best regards Laslo
Re: [hackers] [sbase][PATCH 2/5] fold: fix handling of \b
On 2020-06-20, Richard Ipsum wrote:
> diff --git a/fold.c b/fold.c
> index 9c3c919..a54594b 100644
> --- a/fold.c
> +++ b/fold.c
> @@ -19,7 +19,7 @@ foldline(struct line *l) {
> for (i = 0, last = 0, col = 0, spacesect = 0; i < l->len; i++) {
> if (!UTF8_POINT(l->data[i]) && !bflag)
> continue;
> - if (col >= width) {
> + if (col >= width && (l->data[i] != '\b' || bflag)) {
I think '\r' might also need special handling here.
> len = ((sflag && spacesect) ? spacesect : i) - last;
> if (fwrite(l->data + last, 1, len, stdout) != len)
> eprintf("fwrite :");
Re: [hackers] Re: [sbase][PATCH 0/5] fold fixes
Hey Richard, Thanks for the reminder about the patches. On 2020-09-30, Richard Ipsum wrote: > Hi, looks like these patches got lost/forgotten, > is there any reason to not merge them? Sorry about that. I hadn't forgotten about them, I had just been putting off digging into the code to review them properly. But that's not fair to contributors like yourself (I really do appreciate all the fixes you've been sending), so I think I will set myself a deadline of one week to review patches so that this doesn't happen in the future. If you don't hear from me within a week, feel free to send a reminder. > It's been a while so I've almost forgotten how they work, > but I've got a fair bit of free time to bring them > up to scratch right now if they need more work. I've just gone through them now, and they look pretty good to me. I just have a few comments here and there. -Michael
