lamperez

Asus Zenbook UX3402 speakers on Linux

Important

THIS IS NOW OBSOLETE WITH KERNEL VERSIONS ≥ 6.7.0

A recent announcement in the kernel mail list by Cirrus developers will solve the problem described here. Therefore, the proposed solutions will be soon obsolete. See this comment (thanks, @flukejones, for the tip).

I got the speakers working on my Asus Zenbook 14 OLED UX3402, the one with Intel CPU and the two CS35L41 audio amplifiers connected over SPI (not the UM3402YA, with AMD and I²C). The amplifiers are supported by the snd_hda_scodec_cs35l41 module in recent kernel versions, but they require some model-specific configuration paramaters, that should be provided by

selwynsimsek

;;;; Experimenting with 3D rendering in McCLIM

(ql:quickload '(mcclim 3d-matrices 3d-vectors 3d-quaternions))

(defpackage #:3d-test
  (:use #:clim #:clime #:clim-lisp #:org.shirakumo.flare.quaternion
        #:org.shirakumo.flare.matrix #:org.shirakumo.flare.vector))

(in-package :3d-test)

phoe

Forever Stable Branch

Stable branch, I can see you in the stable branch
See you again, I see you again
In my dreams, in my dreams, in my dreams, in my dreams

Morning light, I remember the morning li-i-i-i-ight
Outside my door (outside my door), I'll see you no more (see you no more)
In my dreams, in my dreams, in my dreams, in my dreams
>

jason-chandler

(in-package :lem-user)

;; beautiful monokai
(define-color-theme "monokai" ()
  (:foreground "#eeeeee")
  (:background "#262626")
  (cursor :foreground "#262626" :background "#eeeeee")
  (syntax-warning-attribute :foreground "#87005f" :background "#262626")
  (syntax-string-attribute :foreground "#d7d787" :background "#262626")
  (syntax-comment-attribute :foreground "#666666" :background "#262626")

bmaupin

Goal

Find a replacement for Llama (R.I.P. 😢)

Conclusion

🦙 Keep using Llama! 🦙

• Llama still works and no other application seems to match Llama in terms of ease of use and cell-tower location (Llama's killer feature)
• Cell-tower location UX seems to be unmatched by the alternatives (training new locations, ignoring towers, seeing location events)

lukego

CLIME

CLIME is an Emacs/SLIME backend for McCLIM. It lets you call CLIM drawing routines at the SLIME REPL and see rendered images inline in Emacs. It also supports Presentations so that you can (accept TYPE) and click in Emacs to choose an object.

Quick overview

Scroll down to see screenshots!

• Tweetstream: https://twitter.com/lukego/status/1387747747864973312
• Demo of ACCEPT: https://www.youtube.com/watch?v=ZTO4fwba4i0

tsjnachos117

I find the ability to get my android devices' battery info on my desktops via cli to be extremely convenient. I used to be able to this with KDE Connect easily, but things have just changed. Since I can't find any documentation on how to do this, and since I just stumbled on the answer myself, I though I might share what I know here. Please note that in the examples below, I will be using {device-id} as a placeholder for the string that KDE Connect uses to identify to my devices.

That said, I used to be able to get my various devices' battery status through gdbus through the following:

    gdbus call --session --dest org.kde.kdeconnect --object-path /modules/kdeconnect/devices/{device-id} --method org.kde.kdeconnect.device.battery.charge

However on Arch, I now get the following error: Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownInterface: No such interface 'org.kde.kdeconnect.device.battery' at object path '/modules/kdeconnect/devices/b04294f19e8767f5'. I don't get this message on Ubuntu 2

vindarel

Developer experience, libraries, performance… (2021/11)

I'll preface this with three things. 1. I prefer schemes over Common Lisps, and I prefer Racket of the Schemes. 2. There is more to it than the points I raise here. 3. I assume you have no previous experience with Lisp, and don't have a preference for Schemes over Common Lisp. With all that out of the way... I would say Common Lisp/SBCL. Let me explain

1. SBCL Is by far the most common of the CL implementations in 2021. It will be the easiest to find help for, easiest to find videos about, and many major open source CL projects are written using SBCL
2. Download a binary directly from the website http://www.sbcl.org/platform-table.html (even for M1 macs) to get up and running (easy to get started)
3. Great video for setting up Emacs + Slime + Quick Lisp https://www.youtube.com/watch?v=VnWVu8VVDbI

Now as to why Common Lisp over Scheme

raiph

Then mathematical neatness became a goal and led to pruning some features from the core of the language.

— John McCarthy, History of Lisp

If you prefer programming languages with a tidy and tiny core, you're in for a treat. This article drills down to the singleton primitive at the heart of Raku's metamodel ("model of a model") of a model of computation ("how units of computations, memories, and communications are organized")¹.

The reason I've written this article

It began with u/faiface's reddit post/thread "I'm impressed with Raku"². One of their sentences in particular stood out for me:

roge

An excerpt from "The Brain Makers" by HP Newquist (pg. 196):

Before long, Symbolics officials claimed that Stallman was actually taking the code that they were giving back to the lab, and that he was forwarding it to Greenblatt. Symbolics hackers even monitored Stallman's activities by using a little known feature that enabled networked LISP machines to watch what other LISP machines were doing. In essence, a hacker on LISP machine A could literally watch the screen activities of LISP machine B. After a few of these spying sessions, it became clear to Symbolics that Stallman was forwarding LISP code to LMI.

Several Symbolics executives approached MIT's administration and presented their evidence. Do something about Stallman, Symbolics' executives demanded. In order to keep its relationship with Symbolics on an even keel, MIT warned Stallman to stay away from the various LISP projects, but stopped short of denying him access to the lab's computing facilities. One more infraction, however, and Stallman m