On Monday, 1 November 2021 at 23:49:35 UTC, H. S. Teoh wrote:
> :-) Which is awesome 'cos it can be tested on command-line without starting a webserver, *and* the same binary works inside CGI too.  cgi.d is total awesomeness.

And it has an embedded webserver if you do want one! can even serve on a unix domain socket though i've never found that terribly useful so far.

On Monday, 1 November 2021 at 23:24:18 UTC, H. S. Teoh wrote:
> Haha, the font wrapping was pretty easy, the freetype headers have the interesting property that error codes are defined with C macros that are defined externally; by suitably redefining these macros and #include'ing the header file twice, I managed to generate D code from the C header file.

oh that's interesting.

for me I just dynamic load as needed. though most of it i do through the xft library for display. My new magic feature is it can look up a font from the OS - most notably on Windows - and then load it in a custom library for opengl etc display. it is magical.




> 5) Upstream decides that they need to depend on libraries X, Y, Z, all of which potentially suffer from (1), (2), (3), or (4).  As the end user, you of course inherit all of the problems.  The worst of these problems is that any one of the 150 recursive dependencies

This here is why I have such a strict dependency policy for libraries. For applications, I sometimes go a bit crazy and use other things, but libraries I keep as thin as I can exactly because they are already someone else's dependency! So if I'm not a leaf, I'm viable to become a web.

If I do use something else, I adopt it myself, but even then I try to avoid.


Even though I have to say I kinda do want to add some new modules. A core util thing with better exceptions and maybe my buffer class etc, and perhaps my dynamic lib loader mixin, and most likely an eventloop2 which is mostly the simpledisplay loop just brought out. I kinda liked eventloop1 just it also sucked cuz I didn't know better when I made it.

Just adding a new module breaks my promise of "download this standalone file". So I avoid it. Just it would be kinda nice. Maybe I'll make it an optional thing again.

On Tue, Nov 02, 2021 at 01:40:46PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Monday, 1 November 2021 at 23:49:35 UTC, H. S. Teoh wrote:
> > :-) Which is awesome 'cos it can be tested on command-line without starting a webserver, *and* the same binary works inside CGI too. cgi.d is total awesomeness.
> 
> And it has an embedded webserver if you do want one! can even serve on a unix domain socket though i've never found that terribly useful so far.

A CGI app listening on a unix socket could potentially be useful in certain sandboxed webserver setups where the webserver talks to the CGI executable running in the background via the unix socket.  I've actually seen similar setups before (an external webserver linked to a localhost-only webserver running in a separate process), though these days this approach is kinda obsolete.  But I could see some niche use case where the CGI program is actually a daemon that's doing other things in the background, and occasionally services a request from the web-facing webserver via CGI.  A unix socket would be just the thing for something like that.  (Though equally common, if not more, these days is to just listen to a TCP socket bound to localhost.)


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.

On Tuesday, 2 November 2021 at 13:40:46 UTC, Adam D Ruppe wrote:
> On Monday, 1 November 2021 at 23:49:35 UTC, H. S. Teoh wrote:
>> :-) Which is awesome 'cos it can be tested on command-line without starting a webserver, *and* the same binary works inside CGI too.  cgi.d is total awesomeness.
>
> And it has an embedded webserver if you do want one! can even serve on a unix domain socket though i've never found that terribly useful so far.

When I wanted to run TiddlyWiki earlier this year, all the options were crap. Back in the old days, you could save directly from within Firefox without a server. Now you have a variety of methods to choose from but they're all bad. The best is running a Node server. 25 lines of D code + cgi.d delivered a stable option that did what I wanted.

On Tuesday, 2 November 2021 at 16:48:21 UTC, H. S. Teoh wrote:
> On Tue, Nov 02, 2021 at 01:40:46PM +0000, Adam D Ruppe via Digitalmars-d wrote:
>> On Monday, 1 November 2021 at 23:49:35 UTC, H. S. Teoh wrote:
>> > [...]
>> 
>> And it has an embedded webserver if you do want one! can even serve on a unix domain socket though i've never found that terribly useful so far.
>
> A CGI app listening on a unix socket could potentially be useful in certain sandboxed webserver setups where the webserver talks to the CGI executable running in the background via the unix socket.  I've actually seen similar setups before (an external webserver linked to a localhost-only webserver running in a separate process), though these days this approach is kinda obsolete.  But I could see some niche use case where the CGI program is actually a daemon that's doing other things in the background, and occasionally services a request from the web-facing webserver via CGI.  A unix socket would be just the thing for something like that.  (Though equally common, if not more, these days is to just listen to a TCP socket bound to localhost.)
>
The performance difference between TCP sockets and Unix sockets is far from beieng negligeable. On our setup at work a memcached server on Unix sockets has twice the thtroughput of a localhost socket (Linux on 15 core intel server).

On Tue, Nov 02, 2021 at 05:54:09PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Tuesday, 2 November 2021 at 16:48:21 UTC, H. S. Teoh wrote:
[...]
> > A CGI app listening on a unix socket could potentially be useful in certain sandboxed webserver setups where the webserver talks to the CGI executable running in the background via the unix socket.  I've actually seen similar setups before (an external webserver linked to a localhost-only webserver running in a separate process), though these days this approach is kinda obsolete.  But I could see some niche use case where the CGI program is actually a daemon that's doing other things in the background, and occasionally services a request from the web-facing webserver via CGI.  A unix socket would be just the thing for something like that.  (Though equally common, if not more, these days is to just listen to a TCP socket bound to localhost.)
> > 
> The performance difference between TCP sockets and Unix sockets is far from beieng negligeable. On our setup at work a memcached server on Unix sockets has twice the thtroughput of a localhost socket (Linux on 15 core intel server).

I'm not surprised, since the TCP stack is a non-trivial subsystem in the kernel that does a LOT of things beyond just passing data from one place to another.  At the very bare minimum, you need to add TCP headers and wrap that in an IP packet on the sending end, and on the receiving end unwrap the IP packet and process the TCP headers.  Whereas a write to a unix socket could be as simple as a kernel memcpy from source process to destination process and sending a notification to the destination process. (Well, OK, IIRC there may be two memcpy's, one to transfer the data to the kernel buffer, then another from kernel buffer to receiver address space when the receiver calls read(). But still, that's a lot less work than traversing the TCP stack.)

But I've seen a lot of "lazy" code that just uses a TCP socket on localhost, because then they could just reuse existing network-based code without change except for setting the source/destination IP addresses to 127.0.0.1.


T

-- 
The best way to destroy a cause is to defend it poorly.

On Tuesday, 2 November 2021 at 16:48:21 UTC, H. S. Teoh wrote:
> But I could see some niche use case where the CGI program is actually a daemon that's doing other things in the background, and occasionally services a request from the web-facing webserver via CGI.

That's actually why I added it: a user wanted unix domain for scgi. And since so much of the code for scgi and http are shared, it just automatically applied to both.

There's a lxd program that does listen for http on a unix socket, so my http2.d client also supports it from that end.

I actually kinda prefer using a unix socket than a tcp thing just because the name is less likely to collide than ports...

On Monday, 1 November 2021 at 19:12:49 UTC, rikki cattermole wrote:
>
> On 02/11/2021 8:10 AM, MGW wrote:
>> The biggest GUI application on QtE5 is ek87.exe - working in dozens of cities, testing nondestructive testing for oil and gas specialists.
>
> Oh wow!
>
> Has your company been added to the list that use D?
>
> And would you be willing to do an article for the D blog about what you are doing?

Yes please! Or DConf video?

— Bastiaan.

On Tue, Nov 02, 2021 at 07:35:15PM +0000, Adam D Ruppe via Digitalmars-d wrote: [...]
> I actually kinda prefer using a unix socket than a tcp thing just because the name is less likely to collide than ports...

Yeah, and TCP ports on Linux have that annoying tendency to stick around for a while after the listening process has exited.  (Yes I know there's a syscall / socket option to get around that. But it's annoying because it's one extra thing to have to do.)

And also the performance hit that Patrick mentioned.


T

-- 
If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell