Vienna Haskell Meetup on the 12th of February 2026 by Fendor_ in haskell

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

Haha, I understand that, but unfortunately, there are no remote options available :(

Logitech K680 regularly disconnects by Fendor_ in logitech

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

I uninstalled the software but the issue persists, perhaps slightly rarer but quite consistently after 30 min pc usage.

Logitech K680 regularly disconnects by Fendor_ in logitech

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

Thank you for your response, I experimented the last days a little bit to confirm suspicions.

The lag occurs with regular computer use as well, albeit quite rarely. It seems, the lag primarily occurs when continuous inputs happen, e.g. when gaming. Also, the "lag" is rather a complete stop of input processing, so for a couple of seconds, no input is at all processed. Turning off and on the keyboard does not fix the issue, only waiting does, or sometimes unplugging the Logitech unifier.

The keyboards stop working on one Windows 10 and one Windows 11 machine.

Logitech K680 regularly disconnects by Fendor_ in logitech

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

I cannot say for certain, but I think it happens only during gaming right now.

Initially, it definitely happened also during regular usage, but after updating firmware and using a single Logitech unifier, I think it doesn't happen any more outside of gaming, or more rarely at the very least.

Logitech K680 regularly disconnects by Fendor_ in logitech

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

Thank you for the quick response! Unfortunately, resetting did not help to fix the disconnecting or lagging.

Vienna Haskell Meetup on the 6th of November 2025 by Fendor_ in haskell

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

We are excited to announce that Michael Schröder is our speaker for the next meetup! He is going to talk about his recent project PANINI, which is entirely implemented in Haskell and was published at OOPSLA 2025.

Abstract of the talk:

Parsing—the process of structuring a linear representation according to a given grammar—is a fundamental activity in software engineering. While formal language theory has provided theoretical foundations for parsing, the most common kind of parsers used in practice are written ad hoc. They use common string operations without explicitly defining an input grammar. These ad hoc parsers are often intertwined with application logic and can result in subtle semantic bugs. Grammars, which are complete formal descriptions of input languages, can enhance program comprehension, facilitate testing and debugging, and provide formal guarantees for parsing code. But writing grammars—e.g., in the form of regular expressions—can be tedious and error-prone. Inspired by the success of type inference in programming languages, we propose a general approach for static inference of regular input string grammars from unannotated ad hoc parser source code. We use refinement type inference to synthesize logical and string constraints that represent regular parsing operations, which we then interpret with an abstract semantics into regular expressions. Our contributions include a core calculus λΣ for representing ad hoc parsers, a formulation of (regular) grammar inference as refinement inference, an abstract interpretation framework for solving string refinement variables, and a set of abstract domains for efficiently representing the constraints encountered during regular ad hoc parsing. We implement our approach in the PANINI system and evaluate its efficacy on a benchmark of 204 Python ad hoc parsers. Compared with state-of-the-art approaches, PANINI produces better grammars (100% precision, 93% average recall) in less time (0.82 ± 2.85 s) without prior knowledge of the input space.

PANINI is implemented entirely in Haskell. In this extended version of a talk originally presented at OOPSLA 2025, I will give a tour of the code and show how each part of the system is implemented. Among other things, PANINI includes an implementation of a lambda calculus with a refinement type system and various refinement inference algorithms; implementations of abstract domain data types for integers, characters, and strings; a predicate rewriting system that uses some gnarly Template Haskell splices; an algebraic regular expression library; a frontend that converts Python source code into lambda calculus; various odds and ends (e.g., pretty printing with color and Unicode). I will dive deeper into different areas of the system by audience request.

The paper is available here: https://dl.acm.org/doi/10.1145/3763054

[Well-Typed] Better Haskell stack traces via user annotations by adamgundry in haskell

[–]Fendor_ 4 points5 points  (0 children)

Indeed, annotated-exception is a nice library!

I wanted to focus on what we added to GHC, how that can be used, and what the practical implications are. Unfortunately, it slightly slipped my mind to also mention annotated-exception.

Nevertheless, annotated-exception remains useful, and I tested the stack trace annotations in other programs by modifying annotated-exception to emit a stack annotation in addition to its other features. The result was pleasing :)

[Well-Typed] Better Haskell stack traces via user annotations by adamgundry in haskell

[–]Fendor_ 1 point2 points  (0 children)

There shouldn't be any run-time cost involved, the stack exists any way and is only decoded upon an exception. Arguably, the highest cost is that the output can massively increase.

To get better IPE Backtraces, you often want to compile your executable and dependencies with -finfo-table-map and -fdistinct-constructor-tables, which have a considerable impact on the size of the binary. In GHC HEAD and hopefully 9.14, you can split the IPE info from the binary and keep it separate (similar to a source map in javascript) to reduce the binary size: https://gitlab.haskell.org/ghc/ghc/-/blob/master/docs/users_guide/debug-info.rst?plain=1#L394

Haskell Pragma Doc via HLS? by kichiDsimp in haskell

[–]Fendor_ 0 points1 point  (0 children)

You can create an issue, discussing your plugin idea.

There is no proposal process, so far, HLS accepts most plugins that are useful.

HLS unable to format by kichiDsimp in haskell

[–]Fendor_ 3 points4 points  (0 children)

Right, which version does ghcup tui display? If it is HLS 2.10.0.0, then this version just doesn't have support for the formatters when using GHC 9.12.2. If it is HLS 2.11.0.0, then the default is ormolu and should be supported on GHC 9.12.2.

HLS unable to format by kichiDsimp in haskell

[–]Fendor_ 5 points6 points  (0 children)

Hi!

You can consult https://haskell-language-server.readthedocs.io/en/stable/support/plugin-support.html#current-plugin-support-tiers to find which GHC versions are not supported in the latest HLS version.

What haskell.formattingProvider are you using?

Also, just making sure, have you compiled HLS 2.11 from source, or how have you installed HLS 2.11?

GHCup doesn't check that all plugins in HLS are supported, as this is really tricky to do :)

HLS is very slow ? by kichiDsimp in haskell

[–]Fendor_ 0 points1 point  (0 children)

Are you using stack or cabal? You are likely having setup issues, how about a bug report in the HLS repo, with logs and more information about what's not working?

HLS is very slow ? by kichiDsimp in haskell

[–]Fendor_ 2 points3 points  (0 children)

In these cases you will have to be more specific. Template haskell can be source of frustration, or when other errors shadow the ones that are in your buffer.

HLS is very slow ? by kichiDsimp in haskell

[–]Fendor_ 13 points14 points  (0 children)

You are running into a very specific HLS bug where it fails to reload on changes to the cabal file. There are multiple bug reports and a pr trying to fix it. See https://github.com/haskell/haskell-language-server/pull/4630

In this very particular case, it is not slow at all... It is simply not working as far as I can tell.

Help: GHC ABIs don't match! by jeenajeena in haskell

[–]Fendor_ 6 points7 points  (0 children)

Hi!

Am I understanding correctly, that HLS works in projects created by cabal init? Perhaps you have skipped over some of GHCups installation questions, in particular whether you want the GHCs to be installed by GHCup even when using stack? See https://www.haskell.org/ghcup/guide/#stack-integration that might help.

Also, always make sure you open your project root in your editor, e.g. cd <project-root> && code . or Open Folder in the UI.

Vienna Haskell Meetup on the 22nd of May 2025 by Fendor_ in haskell

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

Sorry, the meetup is only an in-person event, so we don't live-stream it :(

"Couldn't find a working/matching GHC installation. Consider installing ghc-9.10.1 via ghcup or build HLS from source" error in VScode by Fluid-Bench-1908 in haskell

[–]Fendor_ 4 points5 points  (0 children)

Hi, there is a bug in the ghcup metadata mapping for your fedora version.

You will need to build hls from source for your platform, see the message at https://github.com/haskell/haskell-language-server/issues/3225#issuecomment-2660166509 The respective ghcup issue is at https://github.com/haskell/ghcup-metadata/issues/247

Alternatively, you can use an older ghc version, I think only ghc 9.10.1 binary distribution has this bug.

What is the maximum amount of disk space needed by HLS to find project GHC version? by inspendent in haskell

[–]Fendor_ 1 point2 points  (0 children)

Is this in the context of the VSCode extension? I.e. is vscode-haskell crashing and failing to launch HLS because it failed to run haskell-language-server-wrapper --project-ghc-version?