@galdor@emacs.ch
@galdor@emacs.ch avatar

galdor

@galdor@emacs.ch

Contrarian software engineer. Hire me to solve your technical problems.

$argon2id$v=19$m=64,t=512,p=2$0rwNagYG9nw58bd3D5HBfw$ZDMVWlX+adPhtQKcnrqI5A

This profile is from a federated server and may be incomplete. Browse more on the original instance.

galdor, to random
@galdor@emacs.ch avatar

In , you cannot call the String method on a literal URL struct ("cannot call pointer method String on url.URL") because the String method has a pointer receiver. String does not modify the object, but it uses a pointer receiver to avoid copying the object for each call.

This is what you get when 1/ you design a language with pointers (why would you do that in 2009?) and 2/ you do not have "const".

Just bad design.

galdor,
@galdor@emacs.ch avatar

@holgerschurig And yet I use C libraries just fine in Common Lisp, a language which does not use pointers as a language mechanism. No intermediate C. A pointer is just an address, as long as your language has integers and the necessary primitives to call C code, you can use C libraries directly. Ruby FFI does the same thing.

galdor, (edited )
@galdor@emacs.ch avatar

@holgerschurig You do realize that pointers are memory addresses, which are simply integers no matter what the language is, right?

galdor,
@galdor@emacs.ch avatar

@holgerschurig

Modern Common Lisp implementations also have typed foreign types, this is not the wild west ;) Pointers are not "emulated", I honestly have no idea what you imagine. There are a lot of issues with Common Lisp, and I'm the first one to complain about them, but working with C libraries has always been very comfortable compared to what it is in Ruby, Erlang, or even Go (well, CGo).

I do not frown on pointers in general (I wrote way too much C professionally for that), but they do not make sense in Go: there is a GC and pointer arithmetic is not available! There is nothing useful you can do with them, and they cause so many headaches.

galdor, to emacs
@galdor@emacs.ch avatar

While the LSP protocol is useful for completion or access to symbol definitions, some of its features are less appealing. In , you can instruct Eglot to ignore any feature you dislike.

E.g. (setq eglot-ignored-server-capabilities '(:inlayHintProvider)) to remove annoying hints mixed with the code in c-mode with clangd.

louis, (edited ) to stackoverflow
@louis@emacs.ch avatar

Because I deleted (not edited) some of my answers on Stack Overflow (7 in total) during the last two days, my account is now locked because I "defaced" the community.

They seem to be really desperate. But with their decision to sell their data to OpenAI, they sealed their own fate.

galdor,
@galdor@emacs.ch avatar

@louis Everyone knew what would happen after Stack Exchange was sold to a private equity conglomerate. Founders made their money (good for them!) and are out. At the end of day it is yet another company exploiting users for data. Nothing new and no real future.

galdor, (edited )
@galdor@emacs.ch avatar

@louis

> Can't quite get it why anyone would still volunteer their time as a moderator to this company, err, "community".

It's funny because reading the beginning of your message, this is what I immediately thought. Same thing with Reddit moderators. Companies have been doing a very good job at convincing people that they were providing free services out of the goodness of their heart. Hopefully users will learn from this.

louis, to random
@louis@emacs.ch avatar

Exciting news for SBCL users. A coroutine proof-of-concept was created during ELS after-hours in a pub :-) I for once hope, what happened in Vienna, doesn't stay in Vienna.

galdor,
@galdor@emacs.ch avatar

@louis I hope it means green threads (let me dream).

galdor, (edited )
@galdor@emacs.ch avatar

@louis From a quick check in CCL documentation, it used to have cooperative userland multithreading and switched to OS threads in 0.14.

The thing is, naïve cooperative multithreading (i.e. Stackless Python or what some Scheme implementations do with continuations) is pretty much useless without a runtime able to deal with IO (global IO handler with epoll/kqueue, yield on all IO ops and resume on IO events), which is tricky because none of this is defined in the Common Lisp standard.

Also this is 2024, if your green threads cannot be dispatched on multiple cores (as in Go or Erlang), the benefits are more than limited.

Doing all of this really efficiently is a very hard problem, especially if you are a native compiler (now you have potentially millions of green threads, each with a tiny stack, then suddenly you make FFI calls and the C code is convinced you have your 4+MiB of stack…).

amoroso, to Lisp
@amoroso@fosstodon.org avatar

Are you going to European Lisp Symposium 2024?

I have a favor to ask you. Please tell the Lispers there if any of them writes a Common Lisp book I'll be more than happy to buy it, back a kickstarter, spread the voice, and support the author any way I can.

This is just one data point but my hunch is many Lispers are like me.

galdor,
@galdor@emacs.ch avatar

@amoroso What would you like to see in a new Common Lisp book?

galdor, to random
@galdor@emacs.ch avatar

I had some fun: went through chapter 2 (Syntax) of the standard and bootstrapped a reader. I learned a few things:

  • Pure C99 is (still) easy to read and to write.
  • The standard is very well written: just do what is described and it works.
  • If you did not read the standard, there are a lot of things you do not know about Common Lisp.

Now I need minimal support for arbitrary-precision arithmetic, and I do not want any dependency.

galdor, to random
@galdor@emacs.ch avatar

I was playing again with my HTTP implementation and I've made my peace with its blocking nature. It is irrelevant with a buffering reverse proxy (HAProxy or NGINX), performances are excellent and the code of the server stays simple.

Here, 210k+ req/s on 64 connection handling threads with 390µs P90 latency and sub-ms P99 (Linux amd64, SBCL 2.4.1).

Of course I can't use the same approach for my SMTP server (too many parallel connections that stay alive and no buffering proxy possible), but not all software have to use the same language.

galdor, (edited )
@galdor@emacs.ch avatar

@louis No, there are 64 threads handling connections, i.e. reading requests and writing responses. However these read and write operations are blocking, meaning that they only return once data have been read/written. Without buffering, if a client opens 64 connections and does not send anything, the server will lose the ability to process requests.

With a buffering reverse proxy, e.g. NGINX, the proxy manages connections in a non-blocking way (usually with epoll or kueue), without requiring one thread per connection, and accumulates requests until they are complete, then only forward them to the real server. No risk of blocking. Of course in theory I could write the HTTP server in a non-blocking way in Common Lisp, but then we're back to the lack of green threads, callback hell, etc.

louis, to random
@louis@emacs.ch avatar

Or, we could just build our own Mastodon client with Common Lisp.

Took me less time to build this with than desparately trying to fetch that data in the Web UI.

Who knows what this will morph into. :p

galdor,
@galdor@emacs.ch avatar

@louis I remember reading that the problem with Mastodon was the protocol that makes it impossible to be efficient. Do you concur?

galdor,
@galdor@emacs.ch avatar

@louis @screwtape Curious to see the result indeed, thanks for the explanations.

galdor, to random
@galdor@emacs.ch avatar

I love SQLite, but everytime I see someone claiming you do not need PostgreSQL, I feel the need to remind them that SQLite has very limited type handling and that you'll seriously miss row locking as soon as you want HA. And it's just the tip of the iceberg.

galdor,
@galdor@emacs.ch avatar

@loke My point is that every debate on the subject is focused on performances, which is mostly irrelevant unless you have a ton of concurrent writes.

What people do not realize is how many features SQLite is missing compared to PostgreSQL. And do not get me started on the brain dead idea of allowing NULL primary keys…

galdor, to random
@galdor@emacs.ch avatar

Some say you must start with a simple programming language and learn your way up. Others tell you to learn a low level language such as C to understand how everything works.

I've seen plenty of developers who started with Python or JS, and some who started with C. Comparing them, there is no doubt about which method yields the best developers.

The good news is that it's never too late to go back to the fundamentals.

louis, to openSUSE
@louis@emacs.ch avatar

Two full months into Pop_OS now. While genereally happy, I struggle a bit with the system getting slower and slower over time, I need to reboot every 2-3 days to get back to normal. Resource monitors shows no havoc procresses and no excessive memory usage.

For some other reasons I installed openSUSE Tumbleweed in a VM with KDE 6 and now find it very tempting to switch. It was super fast and KDE seems just so much better at this point.

Switching distro is a huge PITA, so if you have any arguments against it, I would appreciate that before I go down that road 🙂

galdor,
@galdor@emacs.ch avatar

@louis I have been using Archlinux for so long I do not remember using anything else for my workstation or my laptop (still use FreeBSD for my servers and Ubuntu LTS for production professional work because it’s the path of least resistance despite being a shitty distribution).

I have neither the time nor the interest in tinkering with my OS (I had my Gentoo phase a long time ago thank you very much), so a distribution with up-to-date packages and very little opinions (I’m looking at you Debian) suits me perfectly.

Also, yes, Gnome and KDE are self inflicted pains, using i3 or equivalent is a game changer.

galdor, to random
@galdor@emacs.ch avatar

Firefox tip of the day: create/update "userChrome.css" in the "chrome" subdirectory of your profile directory and add:

moz-input-box.urlbar-input-box {
font-family: monospace !important;
}

Do not forget to set "toolkit.legacyUserProfileCustomizations.stylesheets" to "true" in "about:config" (blame Mozilla for this BS).

Because yes, URIs should be readable in your browser.

louis, to random
@louis@emacs.ch avatar

While most programming languages pride themselves in how they limit the programmer, there is one that does quite the opposite. One, that rewards you with every day you spend, every struggle you overcome with a new box of undiscovered tools. And when there are no more, you have all the tools you need to build your own.

You all know which one I'm talking about.

galdor,
@galdor@emacs.ch avatar

@louis I am starting to wonder which one of us is going to go crazy and start writing an implementation ;)

galdor, to emacs
@galdor@emacs.ch avatar

The value of is not in the packages that are available (Gnus, org-mode, Magit, etc.). It is the fact that these packages live in the same application, manipulate text the same way, and can interact with each other to do exactly what you want them to do.

galdor,
@galdor@emacs.ch avatar

@holgerschurig @dougbeney

> How would one discover that, except by doing programming language archeology?

Like everyone, by reading the documentation: https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html

There is a lot of problems with Emacs Lisp, but at least it has documentation. And taking Python as an example is hilarious given how shitty the language and its ecosystem are.

galdor, to random
@galdor@emacs.ch avatar

There is a fundamental misconception about how software licenses and copyright work. Since Redis Labs relicensed Redis, I've read multiple times that it would not have happened if Redis had been GPL-licensed. This is incorrect. The entity (or entities if they all agree when there are multiple copyright holders) owning the software, company or individual, can relicense it at any time, and no license can change that.

Using the GPL license would also not have prevented Amazon from making money by hosting Redis (nothing wrong with that btw). Making it AGPL would have forced them to release any modification, but then again if it was AGPL, lots of companies would not have touch it (for good reasons).

There is absolutely nothing stopping anyone from forking the last BSD-licensed release of Redis and continuing the work with another name ("Redis" is a trademark that belongs to Redis Labs).

louis, to random
@louis@emacs.ch avatar

Call me old school (or just old) but I hate to see that more and more corporations switch to the informal German "Du" ("thou") and dismiss the more respectful "Sie".

I know in English "thou" is no longer common, but in German the distinction between Du and Sie is pretty much alive and we use it all the time between adults that don't know each other, especially in a business relationship. Usually the older or higher-ranked person is in the position to offer switching to "Du".

In Switzerland it is a bit more relaxed (within most companies all are using "Du" no matter which rank), but the rules still apply to people unknown to each other.

How is that working in your country?

galdor,
@galdor@emacs.ch avatar

@louis Same problem in France, lots of companies abandoned the respectful "vous" and abuse the casual/informal "tu" both internally and in their communication with clients/users.

In the past, I have been in multiple job interviews where a manager I've never met before started immediately using "tu" in a very casual way. Of course when that happens, I immediately do the same; always fun to observe their reaction.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • normalnudes
  • rosin
  • ngwrru68w68
  • tacticalgear
  • DreamBathrooms
  • mdbf
  • magazineikmin
  • thenastyranch
  • Youngstown
  • Durango
  • slotface
  • everett
  • vwfavf
  • kavyap
  • megavids
  • khanakhh
  • Leos
  • cisconetworking
  • cubers
  • InstantRegret
  • ethstaker
  • osvaldo12
  • modclub
  • anitta
  • provamag3
  • GTA5RPClips
  • tester
  • JUstTest
  • All magazines
    •