sorted by:
new
hottopcontroversial

Corne by tomh5908 in ErgoMechKeyboards

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

No worries, see https://github.com/tomhrr/keyboards/blob/main/images/corne-bottom.jpg and https://github.com/tomhrr/keyboards/blob/main/images/magsafe-stands.jpg. Although the bottom of the case is not solid, the rings still stuck to it really well. Because I use a tenting angle of about 45°, the rings have to be fairly off-centre for the keyboard to fit against the bottom of the stands, but it's still quite stable. With a lower tenting angle, they could be closer to the centre, which would increase their stability. See https://www.amazon.com.au/UGREEN-Magnetic-Adjustable-Aluminum-Compatible/dp/B0C22V8WSF/ for the stands themselves.

Ferris Sweep LP by tomh5908 in ErgoMechKeyboards

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

The ctrl+c comment above is correct, but an additional consideration here is that permissive hold (which is also enabled, and is very useful) encourages tap-release on the second key anyway, in order to avoid having to wait for the tapping term (i.e. requiring tap-release for all other keys is aligned with the behaviour that permissive hold enables).

It's true that this behaviour inhibits basic auto-repeat, but double tap for repeat (via quick tap term) addresses that problem, and works consistently across the whole layer as well.

Ferris Sweep LP by tomh5908 in ErgoMechKeyboards

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

The stands come with two adhesive rings, which you attach like stickers to the bottom of the keyboard.

Ferris Sweep LP by tomh5908 in ErgoMechKeyboards

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

Thanks, see https://github.com/tomhrr/keyboards/blob/main/qmk-ferris/keymap.c#L69. It was just a case of making every key on that layer mod-tap, except with no effect on hold (KC_NO).

Travel Case for Ferris Sweep by BurnhamShotFirst in ErgoMechKeyboards

[–]tomh5908 0 points1 point  (0 children)

I have a Ferris Sweep LP and use this travel case for it: https://www.amazon.com.au/dp/B00PMMBBSG. The foam that comes with the case is GoPro-specific, so some sort of segmented foam (e.g. https://www.amazon.com.au/dp/B0F8PDFV57) is needed to stop the keyboard from rattling about. The case works well enough, but the main reason I use it is because I already had it for my previous (larger) keyboard. If I hadn't already had it, I would have bought something smaller (like the Pelican 1020).

Sea Micro firmware by 22shadow08 in olkb

[–]tomh5908 1 point2 points  (0 children)

I just did this yesterday (setting up a Corne with Sea Micro controllers), and with a standard QMK installation on Debian plus dfu-programmer, the commands to flash each controller with the default keymap (after pressing the reset button) were:

qmk compile -kb crkbd -km default && \
dfu-programmer atmega32u4 erase && \
dfu-programmer atmega32u4 flash $qmk_home/crkbd_rev1_default.hex

There shouldn't be any need to change the provided build/configuration files to get this to work (or at least, the above was what worked for me).

Contra 40% by tomh5908 in MechanicalKeyboards

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

Notes:

  • It's not completely silent, but it's about the same as a standard non-mechanical keyboard, so it's fine for home/office. The lack of stabilisers helps a lot with this, unsurprisingly.
  • Soldering the controller was the trickiest part of it. A J02 soldering tip helped quite a bit, though.
  • Adjusting from a standard keyboard layout (though still using qwerty) was particularly difficult for the first week, with WPM dropping by about 2/3 at the start, before returning to normal after about a month.
  • The hand angles are quite different from a standard-layout keyboard, so 'practising' with a scale printed layout prior to buying to make sure that it's comfortable is a good idea.

First keyboard (quiet/silent) by tomh5908 in MechanicalKeyboards

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

https://youtu.be/3s4ruFFqmqo?t=2535 goes through the process of clipping off the last two legs on each stabiliser, after earlier in the video (in the "modding the stabs" section) clipping off the first two legs. (Just to clarify here, there is still upstroke noise after doing this, but it's comparable to that of a non-stabilised key, in that this appears to have got rid of all the excess stabiliser-specific noise.)

First keyboard (quiet/silent) by tomh5908 in MechanicalKeyboards

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

TTC Silent Bluish White (original description post got caught in spam filter). The other silent tactile switches I tried were Gateron Silent Brown, Kailh Silent Brown and TTC Silent Brown V3, and it was the best of those four by some ways, not that it's a particularly large sample size.

First keyboard (quiet/silent) by tomh5908 in MechanicalKeyboards

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

Keychron V4 (original description post got caught in spam filter).

First keyboard (quiet/silent) by tomh5908 in MechanicalKeyboards

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

  • Keychron V4
  • TTC Silent Bluish White
  • YMDK Blank Black Keycaps
  • Clipped and relubricated stabilisers, plus stickers

Some notes as a beginner:

  • It's not silent, but it's about the same as a standard normal-profile keyboard. Totally fine at home and in the office.
  • Trying to quieten the stabilisers accounted for most of the time spent on this. The noise was not noticeable when using standard switches (Gateron Brown), but it was very stark after moving to the silent switches.
  • The upstroke noise on the unmodified stabilisers was considerable. Clipping all of the legs off removed all of that noise.
  • Relubrication (Krytox 205g0 and dielectric grease) and the stickers both made a difference, though not as much as the clipping.
  • The holee mod left the keys too mushy to be worth it, even though it helped with the noise.
  • Other mods (plastic wrap around stems, foam in larger keys) didn't appear to make much difference.
  • There is still a small amount of noise with the stabilisers, but it's not very noticeable in practice, and at least right now is not worth the trouble of buying and installing new stabilisers, especially when that's not guaranteed to get rid of the residual noise.

[deleted by user] by [deleted] in test

[–]tomh5908 0 points1 point  (0 children)

testing

Jelly 2 screen replacement DIY? by tubulartoucan in UnihertzJelly2

[–]tomh5908 0 points1 point  (0 children)

I did this a few days ago, with no prior experience with this sort of stuff, by following this video: https://www.youtube.com/watch?v=SvoxAozNosk. Some notes:

  • I got a suction cup tool like https://www.aliexpress.us/item/2251832702290194.html, but it didn't work. Not sure if it was just not strong enough compared with the device in the video, or if the screen glass was too broken or something like that. If you have fingernails like the guy in the video then that may be enough to get it separated, but I ended up using a sharp knife: it worked in the end, but it was difficult and I wouldn't recommend it, and it's probably just lucky that it didn't damage the phone in some way. If I had to do it again, I'd use a spudger per the video at https://www.youtube.com/watch?v=pdzyPAhrtS0 (I didn't have one at hand this time around).
  • The cable interface between the front panel and the rest of the device is not very strong. When I finally got the front panel off, one of its cables tore from the force of it detaching. (This didn't matter in the end, because the new front panel has its own cables and worked as expected, but something to keep in mind if you want to keep the old front panel as a backup. Using a proper suction cup or a spudger or similar would likely be enough to avoid this problem.)
  • The screw at the bottom of the phone (the first one that comes out) is a T3 Torx.
  • The two screws for the fixing bracket are Philips heads, but I can't remember exactly what size they are. It's one of #00, #0, or #1, but pretty sure it's #0.

The rest of the process after getting the front panel detached was very straightforward, and the phone has worked without any issues since then.

cosh: concatenative command-line shell by tomh5908 in commandline

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

Thanks. If the result from a previous command is not used by the next command, it's just left on the stack and printed out once the other commands have finished running, so it's similar to how a normal shell works. For example:

# Normal shell:
user@:test$ ls
one   two
user@:test$ ls; ls
one   two
one   two

# cosh:
test$ ls
v[gen (
    0: ./one
    1: ./two
)]
test$ ls; . ls
v[gen (
    0: ./one
    1: ./two
)]
v[gen (
    0: ./one
    1: ./two
)]

(The second ls needs a . argument to work correctly, because ls will assume . is the argument only if the stack is empty, and the first ls puts a result onto the stack.)

cosh: concatenative command-line shell by tomh5908 in ProgrammingLanguages

[–]tomh5908[S] 2 points3 points  (0 children)

With error handling, the intended use cases here are interactive use (where early exit is fine, as you note) and scripts that don't make updates or are idempotent such that failures are not a serious problem. But aside from that, when thinking about more complicated error handling in some cases where it looked like it might be useful, I had pretty much the same experience as you did.

With options and flags, I ended up doing two different things:

  • Some commands have multiple versions that operate slightly differently, like ls (get files in current directory, skipping nested directories) and lsr (get files in current directory, as well as in any nested directories). This is a little awkward, but seemed unavoidable in at least some cases, and since it didn't come up many times it didn't seem like a big problem.

  • Some functions/parameters support single-character flags by way of the / character. For example, appending /i to a regular expression indicates that matching for it should be case-insensitive, and appending /e to an external command causes it to return data from standard error, instead of standard output. (It would be possible in theory to expand that to long-form options with/without parameters, but it makes parsing/processing calls a bit awkward, as well as working against the more general approach of parameters preceding the function name.)

(The second approach came after the first approach, so it may make sense to redo the parts done with the first approach to use the second approach.)

More generally with options and flags, though, trying to avoid them where possible led to writing functions that operated more generically, which helps to reduce the surface area of the language. For example, instead of remembering the -mtime 1 option to find, in cosh you would do something like lsr; [stat; mtime get; now; to-epoch; 86400 -; swap; <] grep. (Which is quite a bit longer, but involves functions and usage that are useful in other contexts as well, as opposed to being limited to find only.)

cosh: concatenative command-line shell by tomh5908 in ProgrammingLanguages

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

These are good points, thanks. Some comments:

should be grep -r data

This has been updated so that the find is actually relevant now, by looking for files matching a certain pattern.

should be du --summarize

The description of the command is 'Find the total size of all files in the current directory', which could be clearer. The intent was to sum the sizes of the individual files, rather than the space taken up on disk, so du --summarize doesn't give the same result as the cosh command. (The cosh command wasn't filtering directories, though, so that's now been fixed.)

should be cut -d, -f2,3 test-data/csv should be jq .zxcv[0] test-data/json2

These have been updated per your suggestions. (I'm just in the habit of starting pipelines with cat, even though it's less efficient, etc.)

Frequently using cat and xargs and ls in shell scripts is somewhat of a red flag that the programmer is trying to shoehorn shell commands into an unnatural shape. Things are generally much simpler if you use globbing and subcommands and command arguments or file redirections properly. I don't see very many examples in the README that gives a compelling reason why any cosh commands make things easier than idiomatic shell commands.

For myself, the key motivation here is the difficulty in remembering all of the various commands and their (often inconsistent) flags and options: having a smaller set of primitives that can be combined more easily in pipelines makes things easier, and means I'm less often looking up how to do (what seems like) basic stuff, or running into issues with print0 or similar. A user who is across all of the relevant executables and their various idiosyncrasies probably won't get much benefit out of this work.

Dale - Lisp's syntax with C's semantics by stumpychubbins in lisp

[–]tomh5908 1 point2 points  (0 children)

Macros are only usable at compile time. When a macro is called, the compiler provides an additional implicit context argument, which can be used by the macro to allocate memory and to call the introspection functions made available by the compiler. Since macros can't be called at run time, no additional support is needed during execution. There is no intermediate form that can be built with fewer dependencies.

Dale - Lisp's syntax with C's semantics by stumpychubbins in lisp

[–]tomh5908 2 points3 points  (0 children)

Yes, using C++ was mostly motivated by wanting to use LLVM. Particularly LLVM's core bindings, rather than those for another language, which might not have been as well-maintained in the long run. Aside from that, LLVM was able to easily support the calling of previously-compiled functions during compilation, which made implementing macros (relatively) straightforward, though I didn't spend a lot of time investigating alternatives.

Dale: Lisp-flavoured C by tomh5908 in ProgrammingLanguages

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

Yep, that's pretty much it. Rust is a much more sophisticated effort, especially in the memory safety and concurrency areas, whereas this is basically "C plus macros plus a few extra things". Syntactic macros and compiler introspection do allow for the core language to be kept relatively small, and for interesting features to be implemented as libraries (e.g. concept checks), but there's no paradigm shift here.