64 entries in 0.059s
phf: asciilifeform: clim fwiw predates micro exodus. was, like common lisp, an attempt by the three vendors to make a unified gui foundation. you can still see scarring in genera where they started transitioning to clim apps from their flavors
phf: like https://common-lisp.net/project/climacs/images/screenshots/old/swine-ss.png
phf: (speaking of common lisp. asdf the system dependency tool turned from 30k in version 1 into a asdf/uiop 900k monster in version 2. in a systemd move took over most of the compatability packages and is now present ~in every single lisp distribution~. with the did accomplished, Fare posts the following http://fare.livejournal.com/188429.html )
phf: fwiw ada is a harsh mistress is an illusion. if it were to become fashionable to write ada among the hacker news crowd, there will be rapid attempts at modernization. common lisp went through that process
phf: in related http://www.method-combination.net/blog/archives/2017/03/07/nibbles-and-ironclad-releases.html " I will no longer be maintaining nibbles, ironclad, nor any of my other Common Lisp packages"
phf: huh, you're right, 2009-12 is 3 clojure to 4 common lisp
phf: these days when you say "lisp" you usually either mean an equivalent of "algol" or "common lisp" specifically
phf: there's a lineage of lisp, which is significantly mutually compatible. LISP, maclisp, interlisp, zetalisp. common lisp is a standardization attempt on top of those. for example if you take eliza code (written for LISP 1.5) you can make it run on common lisp without any transformations (need to provide some missing forms though)
phf: there's was a wip fork of making linux-unix.lisp talk directly using syscalls without libc. that's probably lowest common denominator
phf: it opens with enough of common lisp to be useful, and then goes into actual programming problems. i think it's one of the best programming books in general.
phf: http://www.nhplace.com/kent/Papers/Condition-Handling-2001.html this is the canonical document on error handling in common lisp. it's long and dense, because powerful machinery
phf: i'm not here to ~defend~ common lisp, i made an analogy that didn't stick
phf: another take on this might be common lisp vs scheme. cl was standardized after the fact, existed and evolved on lisp machines. i'm looking at mit's cadr at the moment, and at a certain point you have maclisp, interlisp, zetalisp and "common lisp" all coexisting on the same machine, 10 years before the standard was written. scheme on the other hand was esparantoed for a purpose. the result is that as you move closer to speaking common
phf: but so that it's not just noise, here's one thing that i used as a jumping point, http://foldr.org/~michaelw/log/programming/lisp/diff-sexp there's also a cmu archive of differs, including a working common lisp diff implementation (with a different output though) http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/tools/src_cmp/0.html
phf: http://btcbase.org/log/2016-12-07#1578953 << just fyi, while you can diff an intermediate ~state~ of an image as a sexp, common lisp's input is a ~character stream~. builtin dispatch ~mostly~ operates on forms (like #p #. (concatenate 'string "foo" "bar")), but not always, like #\; comment reads till end of line.☝︎
phf: ben_vulpes: if you were to use bind everywhere you can use it (e.g. as a replacement for let, destructuring-bind) your code is going to look sufficiently different that it's not clear if you're even programming in common lisp at that point. makes the result less readable for other cl programmers, and code becomes harder to future proof. the tradeoff is generally seen as not worth it (too intrusive for little payoff)
phf: trinque: that's a nifty wot explorer. are you spitting html from common lisp or some other tech?
phf: presumably he doesn't have a key, because there's no openpgp implementation in common lisp...
phf: gabriel_laddel: https://common-lisp.net/project/closure/
phf: it's like halfway between common lisp and elisp
phf: well, then you have a hitler diddled copy, ironclad's tagline always has been "entirely in common lisp"
phf: http://paste.lisp.org/display/327488 lamport parachute PoC in common lisp (it has soft dependency on ironclad for sha256, but otherwise follows the design in that own function can be substituted)
phf: (an example is https://gitlab.common-lisp.net/cmucl/cmucl/blob/master/src/compiler/x86/float-sse2.lisp#L1426 x87-set-floating-point-modes prelude with keywords says some handy things about what's being emitted to put it in context, but then (:generator 6 ...) is your regular asm, mov xor ...)
phf: movitz and mezzano are common lisp compilers, they are just shitty ones. they are good enough to boot an os on x86, but they are missing bits (large chunks of standard) because nobody's written those
phf: the linux approach actually's been done twice, i.e. write something shitty, but it boots and then improve it until it's somewhat ok. there's https://common-lisp.net/project/movitz/ and https://github.com/froggey/Mezzano
phf: i probably wrote most code for tbr/shiva, and it was an exercise in rewriting common lisp from scratch
phf: trinque: you're on a book cover blurb ;) https://common-lisp.net/project/mcclim/excite.html
phf: gabriel_laddel wrote a mcclim tutorial https://common-lisp.net/project/mcclim/posts/CLIM-the-galaxys-most-advanced-graphics-toolkit.html
phf: or common lisp music which is a subset of common lisp to describe a wavelength generation/transformation/composition (i'm pretty sure it was used to do first computer FM synthesis)
phf: they had a bunch of appel books there, mead's introduction to vlsi, a bunch of old common lisp books, 80s expert system books, etc.
phf: Framedragger: despite the rhetoric people here are extremely pragmatic. but when you think about these things there's no reason to allow sloppy thinking. the question is "how much of a dick up your ass is too much dick", and the healthy answer is "none at all". llvm is good technology (it gives you same kind of layering that a decent common lisp compiler does, but for languages that are not used to that kind of richness, so everyone's excited abou
phf: http://btcbase.org/log/2016-06-07#1477855 << actually research done by ECL people claims that mocl is derivative of this project http://www.informatik.uni-kiel.de/~wg/clicc.html (via https://common-lisp.net/project/ecl/static/quarterly/img/vol4/all-hierarchy.png)☝︎
phf: http://btcbase.org/log/2016-06-03#1475432 << i've used it, and the wukix people are responsive to feature requests. i think the source is a fork of one of kyoto common lisp derivatives, probably akcl. fwiw it's the same lineage as gcl and ecl, so ascii's "why not compile ecl" is entirely reasonable☝︎
phf: ben_vulpes: to be fair common lisp tumor is mainly perceptible only to a special kind of basket cases. it is still one of the healthier ecosystems.
phf: fwiw my first exposure to clojure was a clojure job in finance industry, i did a couple of talks on common lisp within airshot of the hiring person from the team, that was way before 1.0, and we must've been one of the first corporations to use clojure, because hicky made a point of coming to a local tech conference and speaking, i've had beer with him a few times
phf: well, i think anything short of common lisp is not really a lisp :P (i.e. reader macros, restarts, pervasive defvar/defparameter clarity, well thought out function library, and such)
phf: jurov: i've not seen where asdf is deprecated, you looking at this guy https://common-lisp.net/project/asdf/?
phf: from the world of lisp rot, asdf, the `make' of common lisp, has been gaining features for a while now to the point that it contains all kinds of crazy shit, like a fullblown cross-lisp compatibility layer for various file operations, etc. so i pulled version 1.369, last one before faré took over the operations, it is 75kb vs current 560k (which is itself packed from a large repo). not surprisingly it works, but when it doesn't it exposes cockroa
phf: 12 step bot, you could buy PAIP and learn to write one yourself, a cleaned up eliza version for common lisp is somewhere there in the later chapters
phf: common lisp doesn't let you redefine +, it does have somewhat sane numeric tower
phf: trinque: yes! that would be handy. i just audited that postgresql common lisp driver (not the popular one, but the pure network pg one)
phf: re standartization, issue i'm personally running into is that we can drag tinyscheme in the direction of common lisp or stick to scheme conventions. both have downsides
phf: a curio for the lisp aficionados http://mumble.net/~jar/pseudoscheme/ an implementation of scheme in common lisp forward ported from lisp machines. a precursor to scheme48, so gets a lot of things right
phf: gabriel_laddel: anything that https://common-lisp.net/project/cmucl/doc/clx/ doesn't answer?
phf: oh, man, another fukamachi project (re quickutil). guy works for a tokyo ad startup, generates massive amounts of web dev style common lisp code. he's behind http://log.bitcoin-assets.com/?date=19-11-2015#1327538☝︎
phf: sucks that he ended up writing book on sgml, but not on common lisp
phf: asciilifeform, ben_vulpes, adlai: edi weitz (cl-ppcre, hunchentoot, flexi-streams rest of ediware) published a book of common lisp recipes http://www.amazon.com/o/asin/1484211774
phf: asciilifeform: you were right re gossip prototype in common lisp. it was a needless distraction, i spent a long time getting lisp gpgme bindings working, and the end result was still pos. i'll just send the patches to gnupg ml, and maybe they'll update upstream, but that's not gotten me anywhere closer. i learned that cffi is mostly a mess. (someone worked some improvements on cffi recently, which resulted in cffi documentation being
phf: it's just impressions. i've been looking at a lot of high traction common lisp code (top quicklisp packages) and there's a lot of senseless turd polishing in the past few years. broken interfaces for the sake of "cleanliness", half baked code, needless macros, dependency hell etc. and then you look at the code and it's the same set of aggressive, google employed queergenders.
phf: punkman: mcclim itself has a handful of examples, but https://common-lisp.net/project/climacs/ and https://common-lisp.net/project/gsharp/
phf: can use http://shinmera.github.io/qtools/ for Qt work from common lisp. adds a thin protective layer
phf: named loops in common lisp? i don't actually know the feature
phf: i have some code for gossipd, i'm going to by the spec that's published on trilema, rather then follow up conversation about udp and first packet validation. i wrote enough in c to be able to prime gpg machinery and send packets over the wire (which basically coveres things that i wasn't sure how to do before i started), then i switched to common lisp to get a prototype up. what came out of that so far is updated bindings for lisp
phf: ben_vulpes: libgpg-error, and share/common-lisp is installed with brew version, but
phf: huh, libgpg-error and gpgme come with common lisp bindings (and only cl) in the standard distribution..
phf: i did technical review for it, which was pretty stressful. barsky is a poliglot and writes with a lot of grahamisms, so i rewrote a lot of bits to make them more "common lisp", though i don't think i fully reached that goal
phf: trinque: re lisp rps, you might want to look at cmucl's WIRE and REMOTE packages, https://common-lisp.net/project/cmucl/doc/cmu-user/ipc.html. while you can send sexps over the wire and slime/swank do it by sending readable forms in netstring format, you start running into issues when you need to ipc opaque blobs, like lambdas, hashtables or clos instances. cmucl's ipc solves all those issues, unfortunately married to cmucl. i think it woul
phf: common lisp specification is written in a such a way that you don't need to know anything about the outside world to fully replicate a ~useful~ computation
phf: https://common-lisp.net/project/closure/ for the curious
phf: BingoBoingo: i use that ibook for mac os 9 now, with kaleidoscope, hypercard, mcl (macintosh common lisp). i boot it up from time to time and it feels like the cyberpunk future that never was
phf: a good common lisp book to have in addition to keene's clos book is AMOP http://www.amazon.com/The-Metaobject-Protocol-Gregor-Kiczales/dp/0262610744
phf: in practical terms, common lisp quirks are direct result of underlying machine level architecture
phf: i think "minimal set of common lisp primitives" is a common theme on #lisp, not surprisingly with different answers every time
phf: i'm not one of those people you're arguing against, i like cl standard just fine. i did paid common lisp consulting on and off for the past 10 years.