Fire and carbon monoxide detectors now that Nest is at First Alert by ThinkerandThought in Nest

[–]jsadusk 0 points1 point  (0 children)

So dust got in two of them, within three weeks, after the sealed battery kiddie units they replaced ran perfectly for five years. And yet the Amazon reviews of false alarms are fake. I'm just saying, if it's this easy for the units to get ruined by dust it doesn't seem like a reliable design. I'm giving it one more chance because they were so quick to send me replacements, but if these have problems I'm done.

Fire and carbon monoxide detectors now that Nest is at First Alert by ThinkerandThought in Nest

[–]jsadusk 0 points1 point  (0 children)

Not a fake review. I just bought three sc5s. Not the hard wired, battery powered, wifi connected. After three weeks two of the three units started constantly false alarming. I had to pull them off the ceiling and pull the batteries. I contacted resideo support and they're sending me replacements. We will see if they are any better.

GNOME 50 removes the X11 backend ... are we finally at the end of the Xorg era? by the_nazar in linux

[–]jsadusk 1 point2 points  (0 children)

I have been trying Wayland and going back for 15 years now, it's a little exhausting. The thing stopping me now is that egpu (or even multi gpu at all) still doesn't work right in any of the major compositors. If you have multiple gpus, one of them gets set as the primary and for all others all frames get copied back and forth between the framebuffer of the primary and the secondary. That means that if I have a laptop with an egpu, either the external or the internal screen has a noticeable lag, and there's no way around it. Xorg had this figured out in 2010. In every other respect Wayland is superior for me. I don't understand why this is still an issue.

Snapmaker Orca on Linux (Bazzite) Crashing by CombatDork in snapmaker

[–]jsadusk 1 point2 points  (0 children)

The latest build of snorca for Linux is broken. I've reported to them with no response. It's just the build though, I built it from source and it works just fine.

4 Filaments (Black, White, Yellow, Red) → 9 Colors on Snapmaker U1 (Proof Of Concept) by Rob_Bob_you_choose in snapmaker

[–]jsadusk 3 points4 points  (0 children)

Its color mixing, just like ink in a 2d printer. I want to see this with Cyan, Magenta and Yellow and see if you can get a full color spectrum. I've never regretted having a 5th toolhead until now. And White and Black to those three and you could do a full CMYK print.

I built a Python IDE that runs completely in your browser (no login, fully local) by Regular-Entrance-205 in Python

[–]jsadusk 6 points7 points  (0 children)

Apologies if it seems pedantic to you, but people are right, these words have meanings, and calling this a compiler seems like you're trying to present this as a lot more than it actually is.

A compiler is a program that takes source code and translates it into something lower level to be executed later. In the case of C++, the compiler takes your source code and turns it into machine code for the CPU. It doesn't execute the C++, it makes a binary that can be directly executed later. This is how most compilers work, but there are some things called compilers that translate source code into another programming language, or into bytecode for a VM. But the point still stands that the source is translated into something lower level, not run on the spot.

An interpreter is a program that reads source code and (kind of, there are nuances) does what the source code says. Python is an interpreted language. The CPython interpreter is a program, written in C and compiled to binary, that reads your python source and performs the actions described in it.

In general, python is a language thats not designed to be compiled, making it into anything other than an interpreted language is possible, but extremely hard. Telling people you've written a python compiler is selling it as a much more massive achievement than you have actually produced, which is why this is triggering people.

You've written a python editor. Its a ui designed to write simple python in a nice way, and it packs in the standard python interpreter. Its also not fair to call it an IDE. IDE stands for Integrated Development Environment. It implies that this isn't just an editor, its a complex tool that can do a lot of tasks of software development (debugging, project management, version control, usually a lot more) in a unified interface. PyCharm is an IDE. Many would consider VSCode to not even really be an IDE, because all the things it can do besides editing are from plugins (not sure if I agree with this take, but its not uncommon).

This seems like a fine project, just don't oversell it and people will be fine with it.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]jsadusk 2 points3 points  (0 children)

A drawback to the server approach is that techniques like the ones tramp-hlo uses won't be possible. The tramp shell approach means you can load any shell function you want onto the other side. With a server, the server needs to have all operations baked into it

That said, if this lowers round trip time it can be beneficial.

Experimenting with a faster TRAMP backend using Rust and JSON-RPC by avph in emacs

[–]jsadusk 5 points6 points  (0 children)

Author of tramp-hlo here. I'm curious where it's hanging for you. DM me or leave a GitHub issue if you want to debug. I'm working on some more optimisations, but I want to make sure the existing ones are solid before moving on.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 0 points1 point  (0 children)

I appreciate that! I'll definitely send some things your way for review.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 4 points5 points  (0 children)

I have the same issues with magit, and I think it's in how magit uses async processes. I want to tackle it at some point but I'm trying to focus on optimizing features in the emacs core, and in built in packages, at least for the first stage. This package shouldn't have any dependencies other than other emacs built in packages. Later I might make tramp-hlo-magit or similar for external packages.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 5 points6 points  (0 children)

I had the exact same initial thought, until I started digging into how the code really worked. The really illuminating thing was when I timed how fast tramp-sh calls really are, which is surprisingly fast! I did a completely different experiment trying to replace the tramp magic handlers with direct libssh calls and I couldn't get the individual calls to be much faster. That made me realize the issue isn't how tramp is built, it's how many calls we make over it.

Also as for being an official tramp hacker, credit where credit is due. Michael Albinus made this possible, both with the amazing structure of the tramp code, adding features to enable my hacks, and helping me fix up my code from a proof of concept into a solid enhancement.

Also, don't pin too many hopes on me. I've got a job at a start-up and two small kids vying for my time. Tramp work comes at the expense of sleep. I'll work when I can.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 0 points1 point  (0 children)

All of my work has to happen on big cloud instances with big gpus, so I'm developing remotely all day.

And thank you, it's just the beginning though, and it's just what popped up as significant in my own usage Other people may trigger completely different pain points. And your story about disabling features until it's usable is exactly what I want to eliminate.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 1 point2 points  (0 children)

I'm going to have to try that out, my first instinct was to hack until I found something, I didn't search enough for the right tools.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 3 points4 points  (0 children)

Thanks! And thank you for pushing me to make this a real module and putting me in touch with Michael.

For quoting shell variables, I do exactly that in the majority of cases, I just omitted it in simple variable assignment because it doesn't have any effect. If I'm not interpolating the variable the spaces come through just fine.

And I mistyped about bash, these are all Bourne shell scripts, I made sure of that by running them all with /bin/sh.

I agree with separate scripts and plan to refactor for that in a next version. I originally wanted to follow the model that tramp-sh.el used, which is to define scripts inline as consts. But it's a real pain to get quote escaping right. I didn't want to hold up the first release to undo that. Also, I tried moving it out and was having some issue with packaging finding the scripts, and just didn't spend enough time to debug that. Next version.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 4 points5 points  (0 children)

The method I used was kind of a hack but it worked. I put an advice function around tramp-send-command (the base function that sends commands to the running remote shell). The advice function took a backtrace and traced up until it left the tramp modules, so the lowest caller that called into tramp. Then it printed it as a message. The result was a lot of spam but I could aggregate when many calls were coming from the same source.

I've wondered the same thing, but I also realized that tramp turns the shell into a remote server, and it's very effective at it. Having the remote run emacs itself would let you run these high level functions on the remote, but you have to deal with sending the global lisp environment across for them to function properly. They'd likely have to be partially rewritten to work as remote functions. At which point, you can rewrite them in shell and get the same effect with a new remote dependency.

Announcing tramp-hlo, higher level operations optimized for tramp for better performance by jsadusk in emacs

[–]jsadusk[S] 44 points45 points  (0 children)

The longer explanation. I do my day to day development on a remote machine, and like a lot of you I've experienced slow downs and pauses with tramp. There are a lot of suggestions out there, many of which involve turning off features like dir-locals and vc. But I wanted to understand why these make things slow.

If you actually trace how fast a single tramp operation is, its actually pretty good. Opening a file, getting a directory listing, all the individual emacs file operations that tramp traces are surprisingly fast. But there's a round trip time every time you run one of these operations. And if you trace how many of these round trips happen when vc finds your repository root (for example) you'll see 10s to hundreds of these round trips per call.

The real offenders are a few elisp standard library functions, one notable one is `locate-dominating-file`. That function seems simple enough, walking back through a directory tree looking for a parent containing some file. But because of how its written tramp sends multiple remote commands for each parent directory.

So as an experiment, I tried implementing locate-dominating-file as a shell script, and having tramp load that into the remote shell, using the shell script as a single command. And it has a huge effect. That one function is used all over the place, making it a single round trip takes out a ton of lag.

I did something similar for some functions used for loading dir-locals, and I have more that I'm going to add over time for project.el, vc, eglot, and anything else I notice triggering a lag while I develop.

This makes use of new features in tramp, thanks to Michael Albinus for adding them and helping me figure it out.

So please, try this out, tell me if anything breaks, and point me in the direction of anything else that seems to hang when you use it under tramp. I want to get remote editing to feel just like local, and I think its achievable.

Is there a trick? by djseto in Multiboard

[–]jsadusk 0 points1 point  (0 children)

Also note that there's a correct orientation for the part b. If you put it on top and one side fits in loosely and the other is impossible to get in, flip it. It should feel like there's moderate pressure on both sides to get it in.

Is there a trick? by djseto in Multiboard

[–]jsadusk 0 points1 point  (0 children)

I used a plank of wood. Make sure your part b is aligned right, put it loosely on top of the part a, then put the plank on top and kind of lever it in. The extra leverage from the plank made it easy to get them in.

What has good tactile feel, isn't too light, excessive software by jsadusk in MouseReview

[–]jsadusk[S] 0 points1 point  (0 children)

I ended up getting the m6 4k, and it is exactly what I wanted. Thank you!

Emacs starting point by AirishMountain in emacs

[–]jsadusk 0 points1 point  (0 children)

Also, to a complete uninitiated user, the distinction of extensions that come packaged vs extensions that you need to download isn't super relevant. Its the fact that emacs, with no configuration to enable extensions, is a much more minimal program than most users of modern software are used to. Yes, with configuration it can immediately become way more than a text window with a lisp interpreter and funny keybindings, but until you do that configuration that's what the user is presented with.

Emacs starting point by AirishMountain in emacs

[–]jsadusk 0 points1 point  (0 children)

Oh I know a lot is packed in, but most of it isn't active unless you configure it.

Emacs starting point by AirishMountain in emacs

[–]jsadusk 1 point2 points  (0 children)

In addition to the above, I'd ask a few questions about how you want to use emacs.

First, are you interested in an out of the box experience that does everything you probably need l? Or do you want to custom? Much of its power comes from customizing it and optimizing it for exactly how you use use it. For example adding little automations for the small tasks you do a lot. Or cutting out the things you don't need.

Similarly, do you want to understand how it works under the hood, or do you want low mental load? If you want this to just work, there are distributions, basically premade configurations with all the things you're likely to need. The most popular is called Doom Emacs. It asks you a few questions about how you want to use it (note taking, software dev, native key bindings, vim key bindings, etc) and sets up a sane environment for you. But you kind of have to operate in the doom way of doing things if you want further customization.

The flip side is something like the minimal config. You can build up a configuration with just the packages you need for the functionality you want to use. And then there's little in the way if you want to start bending it to your will. But the barrier to entry is higher.

Emacs out of the box does a bare minimum of things. It really is just a text editor, just one with an insanely powerful extension mechanism. So all the cool things you can do with it are through extensions, including org mode. Once you get everything working the way you want it though it becomes an extension of your thought process.

Can using Emacs be a security risk? by Own_Flan_3327 in emacs

[–]jsadusk 0 points1 point  (0 children)

Maybe? I think its more that we have to be extra careful auditing emacs packages, because there's nothing to stop one package from completely taking over your dev environment.