#commonlisp — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #commonlisp, aggregated by home.social.
-
@screwlisp @jackdaniel also available on yt: https://www.youtube.com/watch?v=c4pM9cjpeLc #clim #commonlisp #ecl #els #gui #mcclim #lisp
-
@screwlisp @jackdaniel also available on yt: https://www.youtube.com/watch?v=c4pM9cjpeLc #clim #commonlisp #ecl #els #gui #mcclim #lisp
-
@screwlisp @jackdaniel also available on yt: https://www.youtube.com/watch?v=c4pM9cjpeLc #clim #commonlisp #ecl #els #gui #mcclim #lisp
-
@screwlisp @jackdaniel also available on yt: https://www.youtube.com/watch?v=c4pM9cjpeLc #clim #commonlisp #ecl #els #gui #mcclim #lisp
-
@screwlisp @jackdaniel also available on yt: https://www.youtube.com/watch?v=c4pM9cjpeLc #clim #commonlisp #ecl #els #gui #mcclim #lisp
-
ELS (European Lisp Symposium) talks day 1 have been uploaded by someone:
https://www.youtube.com/playlist?list=PLpHdy7ydcZKf17kvGFPafbfxyA1cXWDAu
-
This article by @masinter Larry Masinter and Bill VanMelle, published in December of 1981, reported on the state of Common Lisp from the angle of the Interlisp community. It's interesting as it covers the early stage of standardization, when the specification and design work was under way but no implementations were available yet.
-
@sigue wrote:
«BTW, I don't want you to get the feeling that I'm making this a competition between CL and Dylan here. I actually really enjoy that you're making me think about how I might do some of this stuff in Dylan.»
Oh, I did not and do not view this as a competition, not at all.
And I am glad to learn a little bit about Dylan.«This specific example is pretty straight-forward in Dylan:
let t = make(<table>);
t[#"foo"] := 1 + element(t, #"foo", default: 0);
// => 1»Thank you.
Yes, that is how I do it in Python, too, when I need it (there are some minor syntactic differences, of course):
t['foo'] = 1 + t.get('foo', 0)«In theory we could add `#key default` to the element-setter generic function and then this would work:
inc!(element(t, #"foo", default: 0));
One could also imagine syntax to supply a default value to t[k] such as t[k; d], and then this would work:
inc!(t[#"foo"; 0])»
Thank you; at the very least this is an interesting little exercise.
«A while ago I wrote up a proposal for an extension to Dylan that would provide similar functionality in https://opendylan.org/proposals/dep-0013-multi-assignment.html I think it needs work but it gets the idea across.»
I'm sure this is fun to work on.
Otherwise, I am just a side observer here, of course (regarding justification, acceptance, etc.).«One might point out that the awesome thing about CL is that this can be done in-language instead of needing to modify the compiler. :)»
Oh, yes, oh, yes!
-
@sigue wrote:
«BTW, I don't want you to get the feeling that I'm making this a competition between CL and Dylan here. I actually really enjoy that you're making me think about how I might do some of this stuff in Dylan.»
Oh, I did not and do not view this as a competition, not at all.
And I am glad to learn a little bit about Dylan.«This specific example is pretty straight-forward in Dylan:
let t = make(<table>);
t[#"foo"] := 1 + element(t, #"foo", default: 0);
// => 1»Thank you.
Yes, that is how I do it in Python, too, when I need it (there are some minor syntactic differences, of course):
t['foo'] = 1 + t.get('foo', 0)«In theory we could add `#key default` to the element-setter generic function and then this would work:
inc!(element(t, #"foo", default: 0));
One could also imagine syntax to supply a default value to t[k] such as t[k; d], and then this would work:
inc!(t[#"foo"; 0])»
Thank you; at the very least this is an interesting little exercise.
«A while ago I wrote up a proposal for an extension to Dylan that would provide similar functionality in https://opendylan.org/proposals/dep-0013-multi-assignment.html I think it needs work but it gets the idea across.»
I'm sure this is fun to work on.
Otherwise, I am just a side observer here, of course (regarding justification, acceptance, etc.).«One might point out that the awesome thing about CL is that this can be done in-language instead of needing to modify the compiler. :)»
Oh, yes, oh, yes!
-
@sigue wrote:
«BTW, I don't want you to get the feeling that I'm making this a competition between CL and Dylan here. I actually really enjoy that you're making me think about how I might do some of this stuff in Dylan.»
Oh, I did not and do not view this as a competition, not at all.
And I am glad to learn a little bit about Dylan.«This specific example is pretty straight-forward in Dylan:
let t = make(<table>);
t[#"foo"] := 1 + element(t, #"foo", default: 0);
// => 1»Thank you.
Yes, that is how I do it in Python, too, when I need it (there are some minor syntactic differences, of course):
t['foo'] = 1 + t.get('foo', 0)«In theory we could add `#key default` to the element-setter generic function and then this would work:
inc!(element(t, #"foo", default: 0));
One could also imagine syntax to supply a default value to t[k] such as t[k; d], and then this would work:
inc!(t[#"foo"; 0])»
Thank you; at the very least this is an interesting little exercise.
«A while ago I wrote up a proposal for an extension to Dylan that would provide similar functionality in https://opendylan.org/proposals/dep-0013-multi-assignment.html I think it needs work but it gets the idea across.»
I'm sure this is fun to work on.
Otherwise, I am just a side observer here, of course (regarding justification, acceptance, etc.).«One might point out that the awesome thing about CL is that this can be done in-language instead of needing to modify the compiler. :)»
Oh, yes, oh, yes!
-
@sigue wrote:
«BTW, I don't want you to get the feeling that I'm making this a competition between CL and Dylan here. I actually really enjoy that you're making me think about how I might do some of this stuff in Dylan.»
Oh, I did not and do not view this as a competition, not at all.
And I am glad to learn a little bit about Dylan.«This specific example is pretty straight-forward in Dylan:
let t = make(<table>);
t[#"foo"] := 1 + element(t, #"foo", default: 0);
// => 1»Thank you.
Yes, that is how I do it in Python, too, when I need it (there are some minor syntactic differences, of course):
t['foo'] = 1 + t.get('foo', 0)«In theory we could add `#key default` to the element-setter generic function and then this would work:
inc!(element(t, #"foo", default: 0));
One could also imagine syntax to supply a default value to t[k] such as t[k; d], and then this would work:
inc!(t[#"foo"; 0])»
Thank you; at the very least this is an interesting little exercise.
«A while ago I wrote up a proposal for an extension to Dylan that would provide similar functionality in https://opendylan.org/proposals/dep-0013-multi-assignment.html I think it needs work but it gets the idea across.»
I'm sure this is fun to work on.
Otherwise, I am just a side observer here, of course (regarding justification, acceptance, etc.).«One might point out that the awesome thing about CL is that this can be done in-language instead of needing to modify the compiler. :)»
Oh, yes, oh, yes!
-
I was being facetious, but seriously, avoiding double evaluation is a lesser benefit of a modify macro.
A greater benefit is that it allows modification of a non-existent place, but one for which a default value can be supplied.
The usual example is with a hash table:(let ((h (make-hash-table)))
(incf (gethash 'foo h 0))
(gethash 'foo h))
=> 1I need this kind of thing every so often.
Otherwise, it is true that `define-modify-macro' itself is rarely needed, because the usual things are already provided.
I think I have used it once, maybe twice, perhaps to write `appendf' or something like that.***
«The only thing Dylan provides that is similar to SETF is a simple rule:
f(...) := expression
is exactly equivalent to
f-setter(expression, ...)»
Thank you.
-
A primary source is a beautiful thing.
*
In my not so humble opinion, the finest uses of the Loop facility are those without `do' clauses.
Once I realized those are best viewed as if expressed in declarative style, I was no longer bothered by the "lack of parentheses".Note that three years later Common Lisp specified `loop' while reserving forms with atoms in them, so it did specify enough for a REPL "in four".
(In REverse PoLish, of course;
WHOIS says that re.pl was created on 2000-03-14.)#Alchemy
#CommonLisp
#DeclarativeProgramming
#DeclarativeProgrammingStyle
#Lisp
#Loop
#LoopFacility -
I couldn't find a copy of the memo named "Loop Iteration Macro" by Glenn Burke and David Moon, January 1981 (MIT/LCS/TM-169) at MIT's dSpace site, or anywhere else. So I scanned in my copy and have uploaded it to my web site.
NOTE WELL: This document was written prior to CLTL and describes a facility that was available in MACLISP and the Lisp Machine's Zetalisp. Common Lisp drew design ideas from this, but the syntax, semantics, and associated functions/macros described in this are NOT the same as what Common Lisp offers.
For example, my recollection from long ago (which I did not re-check before making this post) is that there are other differences in syntax because this earlier version of Loop was underconstrained in the ordering of the keywords in a way that let you write some expressions that the committee felt might confuse people with their results.
But also, for reasons that slip my mind, Common Lisp did not adopt the define-loop-path macro that is described starting on page 19.
http://nhplace.com/kent/History/maclisp/MIT-LCS-TM-169-Loop-Iteration-Macro.pdf
#lisp #maclisp #loop #iteration #ComputerHistory #KentsHistoryProject #lisp #LispM #Zetalisp #CommonLisp
cc @screwlisp
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).
My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.
But I still think there could be things the Scheme community would want to glean from this snapshot of history.
I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.
[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdfcc @sigue @ramin_hal9001 @screwlisp
#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject
-
Mine, a Coalton and Common Lisp IDE
https://coalton-lang.github.io/20260424-mine/
#HackerNews #Mine #Coalton #CommonLisp #IDE #Programming #Tools #DeveloperCommunity
-
Mine, an IDE for Coalton and Common Lisp
-
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
You can pick up the document 'Signalling and Handling Conditions' from this index page:
It was longer than I thought it would be, but I think you'll find it interesting to see what the Zetalisp condition system (which inspired the Common Lisp condition system) looked like.
In spirit, it was much the same. The biggest differences are:
* The CL system has 'active' restarts, where the ZL system had a passive thing where you returned a value to the case context and hoped that it would do the thing you wanted. It felt quite a bit more error-prone (if you'll pardon the reuse of 'error' here, maybe I should say 'mistake-prone').
* The ZL condition system offers a lot of really low-level stuff that did not seem proper for CL.
* The set of operations offered in ZL was richer, but also a lot more complicated, I thought, and I worried people would not really see what it was trying to do.
* Obviously, the ZL system was based on Flavors, not CLOS, and made reference to a lot of LispM-specific packages.
* The document was published in January, 1983 and identifies itself as part of Symbolics Release 4.0.
There are other differences as well.
#Zetalisp #LispMachine #LispMachines #Symbolics #LispM
#ConditionHandling #ConditionSystem #ErrorSystem #ErrorHandling #CommonLisp #CL #Flavors #CLOS #History #ComputerHistory
#InternetArchive #Bitsavers -
Is anyone using ocicl as a systems manager in Common Lisp? Have a look at https://github.com/ocicl/ocicl - I only discovered it now, but it seems to be slightly more modern than quicklisp and it is actively maintained.
-
SystemLisp - an HDL simulator written in Common Lisp
#lisp #commonlisp #hdl #rtl #verilog #design #verification #vhdl #systemverilog #vlsi #programming #fpga
-
SystemLisp - an HDL simulator written in Common Lisp
#lisp #commonlisp #hdl #rtl #verilog #design #verification #vhdl #systemverilog #vlsi #programming #fpga
-
SystemLisp - an HDL simulator written in Common Lisp
#lisp #commonlisp #hdl #rtl #verilog #design #verification #vhdl #systemverilog #vlsi #programming #fpga
-
SystemLisp - an HDL simulator written in Common Lisp
#lisp #commonlisp #hdl #rtl #verilog #design #verification #vhdl #systemverilog #vlsi #programming #fpga
-
SystemLisp - an HDL simulator written in Common Lisp
#lisp #commonlisp #hdl #rtl #verilog #design #verification #vhdl #systemverilog #vlsi #programming #fpga
-
So, someone decided to mix Common Lisp with #eBPF, creating a Frankenstein monster they call #Whistler. 🎩 Apparently, it optimizes better than clang and has all the charm of a 90s hacker movie. 🤖 But hey, who doesn’t want to debug a network packet filter in a dialect older than the internet? 🙃
https://atgreen.github.io/repl-yell/posts/whistler/ #CommonLisp #90sHackerMovie #NetworkDebugging #HackerNews #ngated -
Whistler: Live eBPF Programming from the Common Lisp REPL
https://atgreen.github.io/repl-yell/posts/whistler/
#HackerNews #Whistler #eBPF #CommonLisp #REPL #Programming #LiveCoding
-
Whistler: Live eBPF Programming from the Common Lisp REPL
https://atgreen.github.io/repl-yell/posts/whistler/
#HackerNews #Whistler #eBPF #CommonLisp #REPL #Programming #LiveCoding
-
Whistler: Live eBPF Programming from the Common Lisp REPL
https://atgreen.github.io/repl-yell/posts/whistler/
#HackerNews #Whistler #eBPF #CommonLisp #REPL #Programming #LiveCoding
-
Whistler: Live eBPF Programming from the Common Lisp REPL
https://atgreen.github.io/repl-yell/posts/whistler/
#HackerNews #Whistler #eBPF #CommonLisp #REPL #Programming #LiveCoding
-
The #Nimble type inferencer required about 30 seconds to type the #TAK function given above on a 4 Megabyte #MacintoshPlus with a 16MHz 68020 accelerator running Coral #CommonLisp. (h g b)
-
The #Nimble type inferencer required about 30 seconds to type the #TAK function given above on a 4 Megabyte #MacintoshPlus with a 16MHz 68020 accelerator running Coral #CommonLisp. (h g b)
-
Need help from Lisp wizards — looks like I'm missing something simple and obvious (but not so obvious for beginner). I'm trying to build (with ECL) the simple program, which uses ql:quickload to load parse-number, then prints "Hello world". It builds without errors, but resulting binary could not be executed — it prints error message about unknown "ql:quickload" function.
QuickLisp was installed like described in the official documentation. It works in SBCL, it works in ECL REPL and it has the necessary lines in the ~/.eclrc:
;;; The following lines added by ql:add-to-init-file:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
(ql:quickload '(:slite) :silent t)The program, itself, runs successfully if I just evaluate the next code in the REPL:
(ql:quickload '(:parse-number) :silent t)
(defpackage :test
(:use :cl))(in-package :test)
(defun toplevel ()
(print "Hello world"))(progn
(toplevel)
(ext:quit))And it compiles:
ecl --eval '(progn (compile-file "test.lisp" :system-p t) (c:build-program "test" :lisp-files '"'"'("test.o")) (quit))'
;;; Loading #P"/home/drag0n/quicklisp/setup.lisp"
;;; Loading #P"/usr/local/lib/ecl-24.5.10/asdf.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Finished compiling test.lisp.
;;;But doesn't print "Hello world":
./test
Condition of type: UNDEFINED-FUNCTION
The function QUICKLISP-CLIENT::QUICKLOAD is undefined.
No restarts available.Top level in: #<process TOP-LEVEL 0x8295a3f80>.
> -
SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]
https://research.gold.ac.uk/id/eprint/2336/1/sbcl.pdf
#HackerNews #SBCL #CommonLisp #Bootstrapping #LispProgramming #PDF
-
SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]
https://research.gold.ac.uk/id/eprint/2336/1/sbcl.pdf
#HackerNews #SBCL #CommonLisp #Bootstrapping #LispProgramming #PDF
-
SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]
https://research.gold.ac.uk/id/eprint/2336/1/sbcl.pdf
#HackerNews #SBCL #CommonLisp #Bootstrapping #LispProgramming #PDF
-
SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]
https://research.gold.ac.uk/id/eprint/2336/1/sbcl.pdf
#HackerNews #SBCL #CommonLisp #Bootstrapping #LispProgramming #PDF
-
SBCL: A Sanely-Bootstrappable Common Lisp (2008) [pdf]
https://research.gold.ac.uk/id/eprint/2336/1/sbcl.pdf
#HackerNews #SBCL #CommonLisp #Bootstrapping #LispProgramming #PDF
-
An idea to defeat #GenerativeAI in #FreeSoftware:Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.
You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.
LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.
#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use
dfinstead ofdefine, rename types of things likestring?toutf8str?, use generic functions with mulitple dispatch soappendwill work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS
-
Colors are not mine, this is just how #wgpu-native has it :blobcat_thisisfine:
I finally looked up the story about Lemonodor, so yeah, I am way late to that party... I don't even understand why I am doing #commonlisp, but for some reason, I find it addictive.
And so, after 3 months of pretty intense work, I proudly present this beauty—THE TRIANGLE!!! :blobcat_dundundun:
It’s the wgpu-native triangle example implemented in CL with the #wgpu bindings lib I’ve been working on. I hope I can now exhale, relax, and take a small break. And then jump into it again. Refreshed. A bit, at least.
There’s going to be a lot of work to clean up the mess I made while zerg rushing things with my brain cells in these past 3 months before I start expanding the API. I hope wgpu-native will continue to bless me with smooth rendering and zero crashes. 🤞
-
Colors are not mine, this is just how #wgpu-native has it :blobcat_thisisfine:
I finally looked up the story about Lemonodor, so yeah, I am way late to that party... I don't even understand why I am doing #commonlisp, but for some reason, I find it addictive.
And so, after 3 months of pretty intense work, I proudly present this beauty—THE TRIANGLE!!! :blobcat_dundundun:
It’s the wgpu-native triangle example implemented in CL with the #wgpu bindings lib I’ve been working on. I hope I can now exhale, relax, and take a small break. And then jump into it again. Refreshed. A bit, at least.
There’s going to be a lot of work to clean up the mess I made while zerg rushing things with my brain cells in these past 3 months before I start expanding the API. I hope wgpu-native will continue to bless me with smooth rendering and zero crashes. 🤞
-
Colors are not mine, this is just how #wgpu-native has it :blobcat_thisisfine:
I finally looked up the story about Lemonodor, so yeah, I am way late to that party... I don't even understand why I am doing #commonlisp, but for some reason, I find it addictive.
And so, after 3 months of pretty intense work, I proudly present this beauty—THE TRIANGLE!!! :blobcat_dundundun:
It’s the wgpu-native triangle example implemented in CL with the #wgpu bindings lib I’ve been working on. I hope I can now exhale, relax, and take a small break. And then jump into it again. Refreshed. A bit, at least.
There’s going to be a lot of work to clean up the mess I made while zerg rushing things with my brain cells in these past 3 months before I start expanding the API. I hope wgpu-native will continue to bless me with smooth rendering and zero crashes. 🤞
-
Colors are not mine, this is just how #wgpu-native has it :blobcat_thisisfine:
I finally looked up the story about Lemonodor, so yeah, I am way late to that party... I don't even understand why I am doing #commonlisp, but for some reason, I find it addictive.
And so, after 3 months of pretty intense work, I proudly present this beauty—THE TRIANGLE!!! :blobcat_dundundun:
It’s the wgpu-native triangle example implemented in CL with the #wgpu bindings lib I’ve been working on. I hope I can now exhale, relax, and take a small break. And then jump into it again. Refreshed. A bit, at least.
There’s going to be a lot of work to clean up the mess I made while zerg rushing things with my brain cells in these past 3 months before I start expanding the API. I hope wgpu-native will continue to bless me with smooth rendering and zero crashes. 🤞
-
Colors are not mine, this is just how #wgpu-native has it :blobcat_thisisfine:
I finally looked up the story about Lemonodor, so yeah, I am way late to that party... I don't even understand why I am doing #commonlisp, but for some reason, I find it addictive.
And so, after 3 months of pretty intense work, I proudly present this beauty—THE TRIANGLE!!! :blobcat_dundundun:
It’s the wgpu-native triangle example implemented in CL with the #wgpu bindings lib I’ve been working on. I hope I can now exhale, relax, and take a small break. And then jump into it again. Refreshed. A bit, at least.
There’s going to be a lot of work to clean up the mess I made while zerg rushing things with my brain cells in these past 3 months before I start expanding the API. I hope wgpu-native will continue to bless me with smooth rendering and zero crashes. 🤞
-
I'm trying out #CommonLisp plugins for various #IDEs and striking out each time. Am I really stuck with Emacs or Lem? I haven't done much lisp in the last 10 years, and I can hardly remember what I used before. I'm not certain, but I think I just used Vim and ran a REPL in a shell and would just run a command from the REPL to reload a file. I think I used Slimv for awhile, too, but I remember it being very buggy. Any Common Lispers out there that use something other than Emacs/Lem?
-
I'm trying out #CommonLisp plugins for various #IDEs and striking out each time. Am I really stuck with Emacs or Lem? I haven't done much lisp in the last 10 years, and I can hardly remember what I used before. I'm not certain, but I think I just used Vim and ran a REPL in a shell and would just run a command from the REPL to reload a file. I think I used Slimv for awhile, too, but I remember it being very buggy. Any Common Lispers out there that use something other than Emacs/Lem?
-
I'm trying out #CommonLisp plugins for various #IDEs and striking out each time. Am I really stuck with Emacs or Lem? I haven't done much lisp in the last 10 years, and I can hardly remember what I used before. I'm not certain, but I think I just used Vim and ran a REPL in a shell and would just run a command from the REPL to reload a file. I think I used Slimv for awhile, too, but I remember it being very buggy. Any Common Lispers out there that use something other than Emacs/Lem?