From dridi at varni.sh Mon Feb 4 19:26:08 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 4 Feb 2019 20:26:08 +0100 Subject: VMOD havoc generating patch In-Reply-To: <84471.1548680044@critter.freebsd.dk> References: <84471.1548680044@critter.freebsd.dk> Message-ID: On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp wrote: > > Ticket 2810 is about the names generated by vmodtool and vcc, and > while there is a good intellectual argument for getting it right, > I am a little bit worried about how much havoc that causes. > > This is a WIP patch headed in that direction, and I would like to > hear input from VMOD writers. > > Ideally with this stuff finished, VMOD writers can version their > vmods using $Prefix and you will then be able to import multiple > different versions of the same VMOD in the same VCL. Not sure that > is a good thing to do, but it proves that the name-space issue is > solved. > > See the changes to the in-tree vmods for how this will look for you. I waited until my weekly CI against master would choke on this change, and it's very easy to support both before and after if your baseline is 6.0, which is more than fine since 4.1 only has a couple months to live: #include "vcc_$VMOD_if.h" /* Varnish < 6.2 compat */ #ifndef VPFX #define VPFX(a) vmod_ ## a #define VARGS(a) vmod_ ## a ## _arg #define VENUM(a) vmod_enum_ ## a #endif I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be helped if that snippet is not enough. Dridi From phk at phk.freebsd.dk Mon Feb 4 19:30:18 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 04 Feb 2019 19:30:18 +0000 Subject: VMOD havoc generating patch In-Reply-To: References: <84471.1548680044@critter.freebsd.dk> Message-ID: <92757.1549308618@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp wrote: >I waited until my weekly CI against master would choke on this change, >and it's very easy to support both before and after if your baseline >is 6.0, which is more than fine since 4.1 only has a couple months to >live: > > #include "vcc_$VMOD_if.h" > > /* Varnish < 6.2 compat */ > #ifndef VPFX > #define VPFX(a) vmod_ ## a > #define VARGS(a) vmod_ ## a ## _arg > #define VENUM(a) vmod_enum_ ## a > #endif > >I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be >helped if that snippet is not enough. Yes, that would go a long way towards compatibility. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Mon Feb 4 21:25:19 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 4 Feb 2019 22:25:19 +0100 Subject: VMOD havoc generating patch In-Reply-To: <92757.1549308618@critter.freebsd.dk> References: <84471.1548680044@critter.freebsd.dk> <92757.1549308618@critter.freebsd.dk> Message-ID: On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp wrote: > > -------- > In message , Dridi Boukelmoune writes: > >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp wrote: > > >I waited until my weekly CI against master would choke on this change, > >and it's very easy to support both before and after if your baseline > >is 6.0, which is more than fine since 4.1 only has a couple months to > >live: > > > > #include "vcc_$VMOD_if.h" > > > > /* Varnish < 6.2 compat */ > > #ifndef VPFX > > #define VPFX(a) vmod_ ## a > > #define VARGS(a) vmod_ ## a ## _arg > > #define VENUM(a) vmod_enum_ ## a > > #endif > > > >I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be > >helped if that snippet is not enough. > > Yes, that would go a long way towards compatibility. It seems incomplete though, currently the $Prefix is applied all over the place and the VPFX macro isn't used for function names. Is that still work in progress? Dridi From phk at phk.freebsd.dk Mon Feb 4 21:29:02 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 04 Feb 2019 21:29:02 +0000 Subject: VMOD havoc generating patch In-Reply-To: References: <84471.1548680044@critter.freebsd.dk> <92757.1549308618@critter.freebsd.dk> Message-ID: <93429.1549315742@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp wrote: >It seems incomplete though, currently the $Prefix is applied all over >the place and the VPFX macro isn't used for function names. Is that >still work in progress? You mean the in-tree vmods ? Yes, I only applied the necessary macros to make things work again, in order to highlight that you dont *have* to use the macros to write/port a VMOD to the new world order. After the dust has settled and march release is out, I think we should fully macro-ize the in-tree VMODS, but if you guys think it is a better idea to go the full step now, I'm fine with that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Tue Feb 5 07:16:35 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 5 Feb 2019 08:16:35 +0100 Subject: VMOD havoc generating patch In-Reply-To: <93429.1549315742@critter.freebsd.dk> References: <84471.1548680044@critter.freebsd.dk> <92757.1549308618@critter.freebsd.dk> <93429.1549315742@critter.freebsd.dk> Message-ID: On Mon, Feb 4, 2019 at 10:29 PM Poul-Henning Kamp wrote: > > -------- > In message , Dridi Boukelmoune writes: > >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp wrote: > > >It seems incomplete though, currently the $Prefix is applied all over > >the place and the VPFX macro isn't used for function names. Is that > >still work in progress? > > You mean the in-tree vmods ? No, I mean when I look at the generated vcc_$VMOD_if.h, I see many occurrences of the $Prefix that are not guarded by VPFX() macros. > Yes, I only applied the necessary macros to make things work again, > in order to highlight that you dont *have* to use the macros to > write/port a VMOD to the new world order. Right, but it's very convenient to maintain 6.0 source compatibility :3 > After the dust has settled and march release is out, I think we > should fully macro-ize the in-tree VMODS, but if you guys think > it is a better idea to go the full step now, I'm fine with that. The in-tree C files don't need to be macro-ized, I was mostly concerned by the if.h file generated by vmodtool. But even that shouldn't matter too much. Taking my snippet and applying s/vmod/$Prefix/ to it is probably enough. Dridi From phk at phk.freebsd.dk Tue Feb 5 09:17:05 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 05 Feb 2019 09:17:05 +0000 Subject: VMOD havoc generating patch In-Reply-To: References: <84471.1548680044@critter.freebsd.dk> <92757.1549308618@critter.freebsd.dk> <93429.1549315742@critter.freebsd.dk> Message-ID: <85020.1549358225@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >No, I mean when I look at the generated vcc_$VMOD_if.h, I see many >occurrences of the $Prefix that are not guarded by VPFX() macros. The VPFX/VARGS/VENUM macros are mostly intended as convenience for the files the vmod-author writes. I didn't VPFX the prototypes to not _force_ people to use the VPFX in their code if they dont want to, but if the consensus is that we should be pushing VPFX() usage, changing it is just stylistic. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Tue Feb 5 09:54:03 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 5 Feb 2019 10:54:03 +0100 Subject: VMOD havoc generating patch In-Reply-To: <85020.1549358225@critter.freebsd.dk> References: <84471.1548680044@critter.freebsd.dk> <92757.1549308618@critter.freebsd.dk> <93429.1549315742@critter.freebsd.dk> <85020.1549358225@critter.freebsd.dk> Message-ID: > >No, I mean when I look at the generated vcc_$VMOD_if.h, I see many > >occurrences of the $Prefix that are not guarded by VPFX() macros. > > The VPFX/VARGS/VENUM macros are mostly intended as convenience for the > files the vmod-author writes. Ack. > I didn't VPFX the prototypes to not _force_ people to use the VPFX > in their code if they dont want to, but if the consensus is that > we should be pushing VPFX() usage, changing it is just stylistic. I will leave it to $Prefix users that need to support both 6.0 and the new 6.2 vmodtool to leave an opinion here. I don't use the $Prefix stanza. Thanks, Dridi From phk at phk.freebsd.dk Mon Feb 11 22:59:23 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 11 Feb 2019 22:59:23 +0000 Subject: tabular CLI output proof of concept hack Message-ID: <84707.1549925963@critter.freebsd.dk> While looking at #2896 it bothered me how much code we spend on text-processing the CLI output. Since we now have -j for machine-readable output, it would make sense to make the non-j output more human-friendly, and avoid some of all that text-processing at the same time. I threw together the attached proof-of-concept hack, which adds a central function to figure out how wide the columns of tabular output should be, and to reformat it thusly. The idea is that the CLI code, in this case vcl.list sticks some ASCII control-chars in the vsb to mark the columns, which then autosize once all the output is ready, rather than have all the "lets set this column width to 28 ? 45 ? 51?" guesswork. In the hack I have also added column headers for nicer output so that it looks like this: Status Readiness Ref Name ====== ========= === ==== active auto/warm 1 vcl1 (Ignore the amount of space/padding etc, that's for later) I kind of like it. But I am also seriously wondering if we should go even further and have varnishd *only* produce JSON output, and leave the render-for-humans aspect to varnishapi or even varnishadm. Comments welcome... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. -------------- next part -------------- A non-text attachment was scrubbed... Name: _.patch Type: text/x-diff Size: 4522 bytes Desc: _.patch URL: From dridi at varni.sh Tue Feb 12 08:59:14 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 12 Feb 2019 09:59:14 +0100 Subject: tabular CLI output proof of concept hack In-Reply-To: <84707.1549925963@critter.freebsd.dk> References: <84707.1549925963@critter.freebsd.dk> Message-ID: > But I am also seriously wondering if we should go even further and > have varnishd *only* produce JSON output, and leave the render-for-humans > aspect to varnishapi or even varnishadm. Ideally implement it in libvarnish.a and expose it in libvarnishapi, with a way for varnishadm to specify a window size in interactive mode. This way varnishd -d will be able to produce the plain text output. Dridi From phk at phk.freebsd.dk Tue Feb 12 11:22:40 2019 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 12 Feb 2019 11:22:40 +0000 Subject: tabular CLI output proof of concept hack In-Reply-To: References: <84707.1549925963@critter.freebsd.dk> Message-ID: <66327.1549970560@critter.freebsd.dk> -------- In message , Dridi Boukelmoune writes: >> But I am also seriously wondering if we should go even further and >> have varnishd *only* produce JSON output, and leave the render-for-humans >> aspect to varnishapi or even varnishadm. > >Ideally implement it in libvarnish.a and expose it in libvarnishapi, >with a way for varnishadm to specify a window size in interactive >mode. This way varnishd -d will be able to produce the plain text >output. I think you need to unpack that a bit before I follow ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dridi at varni.sh Tue Feb 12 13:12:24 2019 From: dridi at varni.sh (Dridi Boukelmoune) Date: Tue, 12 Feb 2019 14:12:24 +0100 Subject: tabular CLI output proof of concept hack In-Reply-To: <66327.1549970560@critter.freebsd.dk> References: <84707.1549925963@critter.freebsd.dk> <66327.1549970560@critter.freebsd.dk> Message-ID: On Tue, Feb 12, 2019 at 12:22 PM Poul-Henning Kamp wrote: > > -------- > In message , Dridi Boukelmoune writes: > >> But I am also seriously wondering if we should go even further and > >> have varnishd *only* produce JSON output, and leave the render-for-humans > >> aspect to varnishapi or even varnishadm. > > > >Ideally implement it in libvarnish.a and expose it in libvarnishapi, > >with a way for varnishadm to specify a window size in interactive > >mode. This way varnishd -d will be able to produce the plain text > >output. > > I think you need to unpack that a bit before I follow ? My bad! When you run varnishd -d from a terminal you may send CLI commands from stdin and read responses from stdout. So whether it's in a VTC log or run interactively, I think it would be harder to read the JSON output (parsing with eyeballs=). So my thought was that varnishd -d should stay human-friendly and stick to plain text. Dridi From varnishmodules at gmail.com Wed Feb 27 06:23:03 2019 From: varnishmodules at gmail.com (Varnish Modules) Date: Wed, 27 Feb 2019 14:23:03 +0800 Subject: [Wanted] Varnish Module Freelance Developer Message-ID: Hi, Our company is looking for a project-based freelancer to develop a Varnish Module. The current Varnish Module is only supporting up to version 4. Our project requirement is to support the latest version of Varnish Cache. If you are interested, please email me to request for further information. - Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: