probonopd

Are we XLibre yet?

X11 has been, and still is, a vital piece of technology at the core of professional Unix-like workstations since decades. It has a proven track record of supporting enterprise-grade applications with long-term protocol stability and platform compatibility. It has matured over decades. XLibre is an actively developed fork of the X.Org X11 server, initiated by the most active X.Org developer and supported by the open source community.

An incompatible alternative, Wayland, is being aggressively pushed by IBM = Red Hat = Gnome = Fedora = freedesktop.org. However, it is not ready to succeed X11 as it its governance model leads to never-ending discussions and prevents even the most essential functionality from existing. Think twice before abandoning Xorg. Wayland breaks everything!

It is time that the open source community reclaims what was ours to begin with. This page lists distrib

rexim

#include <stdio.h>
#include <stdlib.h>

#define da_append(xs, x)                                                             \
    do {                                                                             \
        if ((xs)->count >= (xs)->capacity) {                                         \
            if ((xs)->capacity == 0) (xs)->capacity = 256;                           \
            else (xs)->capacity *= 2;                                                \
            (xs)->items = realloc((xs)->items, (xs)->capacity*sizeof(*(xs)->items)); \
        }                                                                            \

digikar99

Coalton: Why is the interop not easier, and why might it be necessary for Coalton to be an entire language in itself?

If you came here searching for the context in which some reddit comments were written, you might want to check out this previous version of the article.

Several blog posts have been written about Coalton, about how it can be useful and what it brings to the table. However, to me, it hasn’t been clear why Coalton is the way to solve the problems that it does solve. Isn’t a simpler solution possible without making a full embedded language, and giving users the cognitive overhead of thinking about interop between normal lisp and coalton?

I have been thinking about this for a while as one of my pasttimes, and below I’ll summarize the better reasons why coalton might be the way it is. Perhaps, I couldn’t se

x0nu11byt3

ELF Format Cheatsheet

Introduction

Executable and Linkable Format (ELF), is the default binary format on Linux-based systems.

Compilation

probonopd

Think twice before abandoning X11. Wayland breaks everything!

Wayland breaks everything! It is binary incompatible, provides no clear transition path with 1:1 replacements for everything in X11, and is even philosophically incompatible with X11. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.

Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.

Feature comparison

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

vindarel

Testimonies

CL's compiler

The thing in CL I miss most doing Clojure as my day job? CL's compiler. I like having a compiler tell me at compile time about the mistakes I've made. Bogus arguments. Unreachable code because of unhandled exceptions, and so on. CL saves me round after round of bugs that in clojure aren't found until you run the code. If you test well, it's found when testing, if you don't it's found in production. "Clojure compiler" almost demands air quotes.

CL's optional but oh-so-useful model of type declarations is also infinitely more useful (to me) than Clojure's use of "spec", and instrumentation that happens only at test time because of the cost. Depending on the OPTIMIZE declarations, other type defs are a floor wax and dessert topping. Want checks for argument types? Lower optimizations. Want most efficient machine code? High optimizations.

/u/Decweb, March 2023 https://www.reddit.com/r/lisp/comments/11ttnxk/the_rise_fall_of_lisp_too_good_for_the_rest_of/jczpysp/

unclechu

type
  MaybeKind = enum Just, Nothing
  Maybe[T]  = object
    case kind: MaybeKind
      of Just: value: T
      of Nothing: discard

  EitherKind   = enum Left, Right
  Either[L, R] = object
    case kind: EitherKind

horus

import Foreign.Java

main :: IO ()
main = do
    initJava ["-Djava.class.path=/home/horus/test"]
    runJava $ do
        Just testClass        <- getClass "Test"
        Just systemClass      <- getClass "java.lang.System"
        Just printStreamClass <- getClass "java.io.PrintStream"
        Just outField         <- getStaticField systemClass "out" (object "java.io.PrintStream")