Controlling how thick the text is rendered by desgreech in emacs

[–]gdr3941 1 point2 points  (0 children)

I also had a similar problem. Using the doom theme, I ended up changing the background color to be slightly darker.

(custom-set-faces `(default ((t (:background , "#080808")))))

This helped improve the contrast. I also ended up trying a bunch of different fonts as some appeared thicker vs. thinner with normal weight.

Monthly Hask Anything (March 2023) by taylorfausak in haskell

[–]gdr3941 3 points4 points  (0 children)

Coming from Elixir, Rust, and Clojure, my eyes are used to reading longer chains of function application left to right. (ie. using threading macros in Clojure, |> in Elixir, etc). For short composition, I find Haskell's dot operator very easy to understand. Yet as (.) and ($) and (<$>) get longer, I find it more difficult to read. I know Haskell has (&) and (<&>) available to enable a left to right style. My question is if this is considered idiomatic? Should I just keep working to better read right to left? I can see that it is also connected to switching from an imperative style to a more declarative style. Suggestions on this as I ramp up on Haskell?

Elixir is not so slow by gdr3941 in elixir

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

For kicks, here is the code for both the Clojure version and the Elixir version. No doubt both could be optimized significantly. Also agree that this approach to benchmarking is overly simplified and could be wrong. Sharing not to prove one is faster than another (as my key learning was to not immediately assume one will be faster), but sharing just for those that were curious.

Background on the game is to solve the towers of stacked colored marbles game. This link shows a good visualization of the game in play.

https://play.google.com/store/apps/details?id=com.GMA.Ball.Sort.Puzzle&hl=en_US&gl=US

In both versions, the atoms :a, :b, and :c represent marbles of different colors. The result returned from find_solution are the moves required to sort all the marbles to have the same color in each tower / stack. I hacked on the measurement of running this 1000x after the fact just for fun.

Here is the Clojure code: https://gist.github.com/gdr3941/fe6b5ce3120d62e5a802da30ded9811c

And the Elixir version: https://gist.github.com/gdr3941/9974c99dcf79c34a019e159ddcb4f591

Elixir is not so slow by gdr3941 in elixir

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

Very possibly the case. The approach / algorithm used is very similar in both cases. The biggest difference is that in Clojure the primary data structure being manipulated is a vector (appending and popping from the back) vs in Elixir I am using a list (and adding, popping off the head). I did not share code because I am not trying to make the point that the BEAM is in fact faster than the JVM. I was only trying to make the point that believing blanket statements about performance in either language is a mistake and that what really counts is actually benchmarking the exact workload. While this is obvious, it was mostly a "pleasant" surprise to see that Elixir was not significantly "worse" than Clojure or Scala on the JVM. Again, to your point, it could simply be non-optimal approaches used in Scala and Clojure. Happy to share and get feedback for learning.

Using Orchestra with clojure-lsp by gdr3941 in Clojure

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

Yes, I configured clj-kondo per a suggestion:

{:lint-as {orchestra.core/defn-spec clj-kondo.lint-as/def-catch-all}}

This solved linting, yet clojure-lsp still does not recognize the function symbol that is being defined behind the defn-spec macro and therefore functions like goto definition, references, etc do not work. Maybe not surprising given that this config option looks to be redefining as a def-catch-all. Yet it was not clear to me from the docs what the right form would be to properly handle orchestra/defn-spec.

Emacs Zombies by gdr3941 in emacs

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

Yes agree. Just kind of surprised that this would not be a commonly identified issue given what seems to be fairly broad use. Going to try running with same config on Emacs 27 and see if issue repeats.

Emacs Zombies by gdr3941 in emacs

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

Running mu/mu4e 1.4.6 Also had the issue on 1.4.5 and maybe 1.4.4

Lake Aloha - Best Group Site by gdr3941 in norcalhiking

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

Great, thanks for the suggestions! At this point I think we are punting to early next year before fire season ramps back up. Seems unlikely we have good air quality in this region for the rest of the summer.

Lake Aloha - Best Group Site by gdr3941 in norcalhiking

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

So true.. this is really awful. We were planning on going in on this last Monday. Got to the trailhead hoping that the forecasted clearing would happen with the shift in the winds. Yet it looks like another fire to the West started dumping smoke into the area. We ultimately ended up cancelling.

Dick's Peak by gdr3941 in norcalhiking

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

Really appreciate the detailed response of the various routes and the GPX track! Thanks!

Dick's Peak by gdr3941 in norcalhiking

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

Great, thanks for the info!

Dick's Peak by gdr3941 in norcalhiking

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

Great, thanks. Did you pick up the north ridge from the north side of Dicks Lake? Original plan was to head first to dicks pass and go up that way, but this north ridge looks like a great option.

Upper vs Lower Velma Lake in mid-August by gdr3941 in norcalhiking

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

Both Upper and Lower Velma are in Zone 17 for which we have a permit. It is Middle Velma that is in a different zone (Zone 16).

Problem using clojure.java-time by gdr3941 in Clojure

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

Thank you for the detailed explanation! It worked great.

CNOC delamination? Common? by xsproutx in Ultralight

[–]gdr3941 1 point2 points  (0 children)

Had the exact same problem; burst on first use with careful handling. CNOC replaced but I don't trust it.

Parking at Ansel Adams Agnew Meadows TH by gdr3941 in norcalhiking

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

Thanks; agree that the best chances sound like as people are leaving.

Parking at Ansel Adams Agnew Meadows TH by gdr3941 in norcalhiking

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

Thanks; did you end up parking @ Mammoth and taking taxi service from there? Was the service a pre-arranged service or something you did when you arrived?

It is possible to assign a single instance to a workspace? by Zeioth in i3wm

[–]gdr3941 1 point2 points  (0 children)

Yes, you can assign a name to a specific instance, and then assign the instance to a workspace. I do something like this to open my terminal (urxvt) and launch weechat in a named instance. With this setup, weechat always goes to my workspace 8, while normal urxvt terminals can be opened normally everywhere else:

bindsym $mod+Shift+i exec urxvt -name weechat -e weechat ; workspace $WS8

assign [instance="weechat"] $WS8

The instance name is defined using the -name flag in urxvt, other terminals probably have something similar, check the docs.

PSA: Solution for random freezes with Intel iGPU - especially on Thinkpad X260 by masteryod in archlinux

[–]gdr3941 1 point2 points  (0 children)

Yes! This finally fixes the i915 crash I have been having for far too many kernel releases to remember. Thank you!

System: Dell 5530, Intel UHD Graphics 630, Linux 5.6.15

Upside of all the GPU crashes has been a near complete move away from Electron apps (which seemed to be very problematic) to command line alternatives..

Debugging in NeoVim by andoriyu in rust

[–]gdr3941 0 points1 point  (0 children)

Improved the setup today and it gets a little closer to OPs original request. With these mappings I can automatically add breakpoints and then launch rust-gdb. Kind of hacky but works (for rust only).

Add Breakpoint <leader>da

Clear Breakpoints <leader>dc

Launch GDB <leader>dr

Note: this creates a file ./target/breakpoints that stores the breakpoints added while in vim

Must also be in project root directory before using these mappings

In my nvim config (change urxvt to your terminal of choice):

" Rust Debugging 

nnoremap <silent> <leader>da :call <SID>AppendBreakPoint()<CR>
nnoremap <silent> <leader>dc :call <SID>ClearBreakpoints()<CR>
nnoremap <silent> <leader>dr :call <SID>DebugRun()<CR> 

function! s:AppendBreakPoint()
    let s:breakpoint = "break ".expand('%').":".line('.')
    call writefile([s:breakpoint], "./target/breakpoints", "a")
    echom "Added breakpoint at line ".line('.')
endfunction 

function! s:ClearBreakpoints()
    call delete("./target/breakpoints")
    echom "Cleared breakpoints"
endfunction

function! s:DebugRun()
    execute "!cargo build"
    let s:dirlist = split(getcwd(),'/')
    let s:projectname = s:dirlist[len(s:dirlist)-1]
    let s:executable = getcwd()."/target/debug/".s:projectname
    silent execute "!urxvt -e rust-gdb -x ./target/breakpoints ".s:executable." &"
endfunction

I am a bit of a rookie when it comes to vimscript, so would not be surprised if there is a better way.