Fred

We're a couple months later, I ended up doing a second small project, this time I used half tung oil half orang oil, and adjusted my technique: wiped with a clean rag after application, and I think the room was warmer them last time.

Got better results, more even and it didn't take 2+ weeks for the first coat to cure (more like a few days).

Thanks for the advice 🙂

There was a discussion of pathlib a few days ago: https://programming.dev/post/21864360

You clearly have more experience than I do; the only explanation for why my (one) attempt is not going so well is that I had less than ideal conditions. Both temperature and user technique, probably the latter is most to blame!...

It is pure oil, maybe I'm being too impatient then, a month is a long time though!

/u/NataliePortland@lemmy.ca suggested a wipe with solvent, is that the role of orange oil? I think ill try that when I have time in few days

It's inside the house, but this being winter, is not super warm.

I disn't do the two steps apply liberally, wipe the excess a few minutes later. Of well, top late to go back and do that :)

I think I'll try your suggestion when I have time in a few days

Well I'm not missing the point then, that's good to know :)

Maybe I'm wildly misunderstanding something, not helped by the fact that I work very little with Web technologies, but...

So, in a RESTful system, you should be able to enter the system through a single URL and, from that point on, all navigation and actions taken within the system should be entirely provided through self-describing hypermedia: through links and forms in HTML, for example. Beyond the entry point, in a proper RESTful system, the API client shouldn’t need any additional information about your API.

This is the source of the incredible flexibility of RESTful systems: since all responses are self describing and encode all the currently available actions available there is no need to worry about, for example, versioning your API! In fact, you don’t even need to document it!

If things change, the hypermedia responses change, and that’s it.

It’s an incredibly flexible and innovative concept for building distributed systems.

Does that mean only humans can interact with a REST system? But then it doesn't really deserve the qualifier of "application programming interface".

Scapy is another library where they redefined / to layer packets, such that you can write:

IP(dst="172.23.34.45") / UDP() / DNS(…)

Then Scapy has magic so that on serialisation, the UDP layer knows defaults to dport=53 if the upper layer is DNS, and it can access the lower layer to compute its checksum.

And don't forget that strings have a custom % (as in modulo) operator for formatting:

"Hello %s" %(username)

Of course in modern Python, f-strings will almost always be more convenient

I can’t remember if threads are core bound or not.

On Linux, by default they're not. getcpu(2) says:

   The getcpu() system call identifies the processor and node on which the
   calling thread or process is currently running and writes them into the
   integers pointed to by the cpu and node arguments.  ...

   The  information  placed in cpu is guaranteed to be current only at the
   time of the  call:  unless  the  CPU  affinity  has  been  fixed  using
   sched_setaffinity(2),  the  kernel  might  change  the CPU at any time.
   (Normally this does not happen because the scheduler tries to  minimize
   movements  between  CPUs  to keep caches hot, but it is possible.)  The
   caller must allow for the possibility that the information returned  in
   cpu and node is no longer current by the time the call returns.

There's been a few of those in the UK; this article quotes "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD and ; DROP TABLE “COMPANIES”;-- LTD.

That seems like a weird dichotomy between ruff and Jedi. One does linting & formatting, the other code completion, goto-definition, refactoring. With pylsp you can have both: it uses Jedi (in the default config), and has a plugin to call ruff for linting and formatting (according to the doc; I don't actually use ruff).

I'm using pylsp (python-language-server). My reason being a process of elimination. I also use mypy for type-checking, so even without considering the danger of allowing MS to entrench itself into my tooling, it didn't make much sense to use a tool built around pyright.

The ruff-lsp seems to only do the things that ruff is good at: linting, code formatting, auto-fix of certain issues, and I wanted more.

Since I saw that pylsp uses Jedi under the hood, and offered a mypy plugin, I felt that pylsp offer a superset of the features that the Jedi LSP has. In the end I'm happy with pylsp, and never tried Jedi LSP.

However: with the mypy plugin for pylsp, the memory usage kept growing to ridiculous amounts and getting killed, so I ended up disabling it. I had a look in their bug tracker Instead, I'm using flymake that triggers mypy on save, and that seems to work well. (I have a few changes on top of com4/flymake-mypy.el, because it leaves behind plenty of temporary files.)

That offers me:

• jump to definition (using Jedi under the hood)
• rename symbol (and then Jedi goes and rename uses of that symbol)
• smart completion (eg. offers only variables in scope, or after a . only the instance members, etc.)
• short documentation on hover
• squiggly lines for errors found by flake8 or mypy
• and a few more that I don't really notice

One thing I struggled with: where do you install the LSP? Using pipx for a user installation, or in a per-project venv? I did the latter, which works for me because I work on a small number of projects. That also means that mypy finds all the relevant third-party libraries in that venv. I wrote a bit of elisp that allow emacs to find the right mypy binary to check code.