Podcasts about Common Lisp

All Paul Graham essay's, brought to life in audio format. This is a third party project, independent from Paul Graham, and produced by Wondercraft AI.

All Paul Graham essay's, brought to life in audio format. This is a third party project, independent from Paul Graham, and produced by Wondercraft AI.

One of our oldest languages meets one of our newest sciences in this episode, as we talk with Professor Christian Schafmeister, an award-winning nanotech researcher who's been developing a language and a design suite to help research the future molecular machines.In this episode Christian gives us a quick chemistry lesson to explain what his research is trying to achieve, then we get into the software that's doing it: A new flavour of Common Lisp. But why Lisp? What advantages does a 60 year old language design offer? How does he strike a balance between high-level language features and the need for exceptional performance and parallelism? And what tricks does his development environment have that modern IDEs could still learn a thing or two from?--Clasp (the Lisp): https://github.com/clasp-developers/claspCando (the design language): https://github.com/cando-developers/candoThe Feynman Prize: https://en.wikipedia.org/wiki/Feynman_Prize_in_NanotechnologyAlphafold: https://alphafold.ebi.ac.uk/More on LEaP: https://ambermd.org/tutorials/pengfei/Interactive Development of Crash Bandicoot: https://all-things-andy-gavin.com/2011/03/12/making-crash-bandicoot-gool-part-9/ Christian's Research Group: https://www.schafmeistergroup.com/Kris on Twitter: https://twitter.com/krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/--#programming #software #lisplang #commonlisp #nanotech

On This Week in Google, Leo Laporte shows Paris Martineau and Jason Howell how he built a personalized Lisp programming assistant using GPT and a tailored corpus of Lisp books and websites. For the full episode, visit twit.tv/twig/742 Hosts: Leo Laporte, Paris Martineau, and Jason Howell You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

On This Week in Google, Leo Laporte shows Paris Martineau and Jason Howell how he built a personalized Lisp programming assistant using GPT and a tailored corpus of Lisp books and websites. For the full episode, visit twit.tv/twig/742 Hosts: Leo Laporte, Paris Martineau, and Jason Howell You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

On This Week in Google, Leo Laporte shows Paris Martineau and Jason Howell how he built a personalized Lisp programming assistant using GPT and a tailored corpus of Lisp books and websites. For the full episode, visit twit.tv/twig/742 Hosts: Leo Laporte, Paris Martineau, and Jason Howell You can find more about TWiT and subscribe to our podcasts at https://podcasts.twit.tv/ Sponsor: GO.ACILEARNING.COM/TWIT

Array Cast - October 13, 2023 Show Notes[01] 00:02:40 Minnowbrook conference https://aplwiki.com/wiki/APL_Implementer%27s_Workshop Combinators https://en.wikipedia.org/wiki/Combinatory_logic#Examples_of_combinators Tacit Programming https://mlochbaum.github.io/BQN/doc/tacit.html Function Composition https://aplwiki.com/wiki/Function_composition Tacit Episodes of the ArrayCast Tacit #4 The Dyadic Hook https://www.arraycast.com/episodes/episode17-tacit4-the-dyadic-hook Tacit #3 And Other Topics https://www.arraycast.com/episodes/episode15-tacit-3-and-other-topics Tacit #2 Why Tacit? https://www.arraycast.com/episodes/episode11-why-tacit Tacit #1 Tacit Programming https://www.arraycast.com/episodes/episode-09-tacit-programming[02] 00:03:35 Arrayground https://apps.apple.com/us/app/arrayground/id6453522556 Conor's Uiua videos Uiua - A New Array Language https://www.youtube.com/watch?v=iTC1EiX5bM0 BQN vs. Uiua https://www.youtube.com/watch?v=pq1k5USZZ9A BQN vs. Uiua #2 https://www.youtube.com/watch?v=SpZJxbOf_jM[03] 00:05:41 Stanley Jordan https://en.wikipedia.org/wiki/Stanley_Jordan April, an APL Compiler for Common Lisp https://www.youtube.com/watch?v=AUEIgfj9koc Andrew Sengul Episode of the ArrayCast https://www.arraycast.com/episodes/episode23-andrew-sengul Uiua Episode of the ArrayCast https://www.arraycast.com/episodes/episode63-uiua Game videos in BQN Snake2 in 8 Minutes https://youtu.be/tOZde7zrsLM?si=N2jTdTZBlPEleCr0 https://youtu.be/wTIlQ1Ib-zE Snake (longer version) https://youtu.be/wTIlQ1Ib-zE A Game implemented in APL Draculark in APL https://medium.com/@solarbreeze69/draculark-a-mudlarking-vampire-hunting-game-bbf40361bf1a[04] 00:09:06 Forks https://code.jsoftware.com/wiki/Vocabulary/fork Before and After in BQN https://mlochbaum.github.io/BQN/doc/hook.html Invisible Modifiers https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers Peter Mikkelsonhttps://pmikkelsen.comhttps://www.dyalog.com/blog/2022/11/welcome-peter-mikkelsen/[05] 00:14:52 Atop in J https://code.jsoftware.com/wiki/Vocabulary/at Compose (Over) in J https://code.jsoftware.com/wiki/Vocabulary/ampv Atop and Over BQN https://mlochbaum.github.io/BQN/doc/compose.html[06] 00:17:04 Henry Rich Episodes on the ArrayCast Fold in J https://www.arraycast.com/episodes/episode50-fold Henry Rich - Threads in J9.4 https://www.arraycast.com/episodes/episode48-henry-rich Henry Rich presents J903 https://www.arraycast.com/episodes/episode18-henry-rich-presents-j903 Henry Rich's Deep Dive into J https://www.arraycast.com/episodes/episode-06-henry-richs-deep-dive-into-j Invisible Modifiers Table https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers Seymour Papert https://en.wikipedia.org/wiki/Seymour_Papert[07] 00:20:10 NuVoc https://code.jsoftware.com/wiki/Vocabulary Forks https://code.jsoftware.com/wiki/Vocabulary/fork Modifier Trains https://code.jsoftware.com/wiki/Vocabulary/fork#invisiblemodifiers Modifier Train Exploration https://code.jsoftware.com/wiki/Vocabulary/ModifierTrains Modifier Train Exploration Discussion https://code.jsoftware.com/wiki/Talk:Vocabulary/ModifierTrains[08] 00:24:23 Atop APL Paw glyph https://aplwiki.com/wiki/Atop_(operator) https://aplwiki.com/wiki/Over Over APL Hoof glyph https://aplwiki.com/wiki/Over[09] 00:44:44 Arity of functions https://en.wikipedia.org/wiki/Arity Conjugate Monadic + https://code.jsoftware.com/wiki/Vocabulary/plus Plus Dyadic + https://code.jsoftware.com/wiki/Vocabulary/plus#dyadic[10] 00:54:55 Forks in the KAP Programming Language https://kapdemo.dhsdevelopments.com/kap-comparison.html#_fork Forks modelled in the dfns workspace http://dfns.dyalog.com/n_fork.htm[11] 01:00:35 Kadane's Algorithm https://en.wikipedia.org/wiki/Maximum_subarray_problem[12] 01:06:24 Pepe's Trains - Past, Present and ... https://www.jsoftware.com/pipermail/programming/2017-October/049263.html[13] 01:10:47 Dyadic Or BQN https://mlochbaum.github.io/BQN/doc/logic.html Monadic Sort BQN https://mlochbaum.github.io/BQN/doc/order.html[14] 01:15:23 Signum Monadic * https://code.jsoftware.com/wiki/Vocabulary/star Times Dyadic * https://code.jsoftware.com/wiki/Vocabulary/star#dyadic[15] 01:18:20 Jelly programming language https://github.com/DennisMitchell/jellylanguage https://aplwiki.com/wiki/Jelly[16] 01:25:14 Zilde Empty https://aplwiki.com/wiki/Zilde BQN's Nothing https://mlochbaum.github.io/BQN/help/nothing.html Monadic and Dyadic Meanings https://aplwiki.com/wiki/Mnemonics#Pairing_monadic_and_dyadic_meanings Overloading in BQN https://mlochbaum.github.io/BQN/commentary/overload.html q Programming Language https://code.kx.com/q/ Overloading in q https://code.kx.com/q/ref/overloads q Unary Forms https://code.kx.com/q/basics/exposed-infrastructure/#unary-forms[17] 01:30:56 Michael Higginson Episode of ArrayCast https://www.arraycast.com/episodes/episode46-michael-higginson Lynn Sutherland Nial Episode of ArrayCast https://www.arraycast.com/episodes/episode61-lynn-sutherland-and-nial NARS2000 Programming Language https://www.nars2000.org/ Hyperators in NARS2000 https://wiki.nars2000.org/index.php?title=Anonymous_Functions/Operators/Hyperators Hyperators in Dyalog https://dfns.dyalog.com/n_hyperators.htm[18] 01:41:46 Category Theory https://en.wikipedia.org/wiki/Category_theory[19] 01:45:25 Contact AT ArrayCast DOT Com

In this week's episode, host Anna Rose (https://twitter.com/annarrose) chats with Chhi'mèd Künzang (https://research.protocol.ai/authors/chhimed-kunzang/) and François Garillot (https://www.garillot.net/) from Lurk Labs (https://lurk-lab.com/) about all things Lurk, Lisp and zk languages. They discuss the history of the Lurk project, from its beginnings with Protocol Labs (the team that built Filecoin), to its emergence as a Turing-complete programming language for recursive zkSNARKs. They discuss Lurk's relationship with Lisp, what Lisp is, and how developers familiar with that family of languages would be able to interact with Lurk. They then discuss how Lurk compares to other zkDSLs and the new innovations this Lisp-based language brings to the table. Here's some additional links for this episode: Programming Languages * Circom (https://iden3.io/circom) * Arkworks GitHub (https://github.com/arkworks-rs) * Leo by Aleo (https://www.aleo.org/post/leo-programming-language) * SnarkyJS (http://snarkyjs.o1labs.org/) * Noir (https://noir-lang.org/) Lurk Links * LURK: Lambda, the Ultimate Recursive Knowledge by Amin, Burnham, Garillot, Gennaro, Künzang, Rogozin and Wong (https://eprint.iacr.org/2023/369) * Lurk Lab (https://lurk-lab.com/) * Lurk Lab Twitter (https://twitter.com/LurkLab) * Lurk Language (https://lurk-lang.org/) * Lurk GitHub (https://github.com/lurk-lab) Additional Reading/Listening * A Sloth-based Verifiable Delay Function (VDF) evaluator and SNARK prover GitHub (https://github.com/protocol/vdf) * Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I by John McCarthy, April 1960 (http://www-formal.stanford.edu/jmc/recursive.pdf) * Using ZK Proofs to Fight Disinformation By Trisha Datta and Dan Boneh (https://medium.com/@boneh/using-zk-proofs-to-fight-disinformation-17e7d57fe52f) * Common Lisp (https://lisp-lang.org/) * Episode 172: ZK languages with Alex Ozdemir (https://zeroknowledge.fm/172-2/) * zkSessions: The ZK Languages Rundown (https://www.youtube.com/watch?v=ABjSn_6m4Ac&list=PLj80z0cJm8QEz6BotG4SkGSCupwkPonCZ&index=12) * zkSummit4 Videos (https://www.youtube.com/watch?v=sj5yY3wguIo&list=PLj80z0cJm8QFnY6VLVa84nr-21DNvjWH7) - check the playlist (https://www.youtube.com/watch?v=C-C1fHzApEQ) for individual talks! Ever feel like developing zero-knowledge proofs is a daunting task? The team at RISC Zero (https://www.risczero.com/) is here to remind you that it doesn't have to be that way. Their out-of-the-box tooling allows developers to access the magic of ZK proofs from any chain without needing to learn custom languages or building custom zk circuits. Bonsai (https://r0.link/ZKpodcast), RISC Zero's most anticipated product, is a proving marketplace that enables any protocol or application to leverage fast ZKProofs in languages like Rust, Go, C++. Visit https://r0.link/ZKpodcast (https://r0.link/ZKpodcast) to learn more and sign up today for the Bonsai waitlist. If you like what we do: * Find all our links here! @ZeroKnowledge | Linktree (https://linktr.ee/zeroknowledge) * Subscribe to our podcast newsletter (https://zeroknowledge.substack.com) * Follow us on Twitter @zeroknowledgefm (https://twitter.com/zeroknowledgefm) * Join us on Telegram (https://zeroknowledge.fm/telegram) * Catch us on YouTube (https://zeroknowledge.fm/)

Source I was looking through while talking WIP: gopher://gopher.club/1/users/screwtape/car-game Compilers: sbcl https://sbcl.org/ ecl https://ecl.common-lisp.dev/ acl2 https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/ACL2____Common_02Lisp System definition: asdf https://common-lisp.net/project/asdf/ Books mentioned: Land of Lisp Advances in Formal methods (whatever by Kaufmann)

This episode is all about the Lisp family of programming languages! Ever looked at Lisp and wondered why so many programmers gush about such a weird looking programming language style? What's with all those parentheses? Surely there must be something you get out of them for so many programming nerds to gush about the language! We do a light dive into Lisp's history, talk about what makes Lisp so powerful, and nerd out about the many, many kinds of Lisps out there!Announcement: Christine is gonna give an intro-to-Scheme tutorial at our next Hack & Craft! Saturday July 2nd, 2022 at 20:00-22:00 ET! Come and learn some Scheme with us!Links:Various histories of Lisp:History of Lisp by John McCarthyThe Evolution of Lisp by Guy L. Steele and Richard P. GabrielHistory of LISP by Paul McJonesWilliam Byrd's The Most Beautiful Program Ever Written demonstrates just how easy it is to write lisp in lisp, showing off the kernel of evaluation living at every modern programming language!M-expressions (the original math-notation-vision for users to operate on) vs S-expressions (the structure Lisp evaluators actually operate at, in direct representational mirror of the typically, but not necessarily, parenthesized representation of the same).Lisp-1 vs Lisp-2... well, rather than give a simple link and analysis, have a thorough one.Lisp machinesMIT's CADR was the second iteration of the lisp machine, and the most influential on everything to come. Then everything split when two separate companies implemented it...Lisp Machines, Incorporated (LMI), founded by famous hacker Richard Greenblatt, who aimed to keep the MIT AI Lab hacker culture alive by only hiring programmers part-time.Symbolics was the other rival company. Took venture capital money, was a commercial success for quite a while.These systems were very interesting, there's more to them than just the rivalry. But regarding that, the book Hackers (despite its issues) captures quite a bit about the AI lab before this and then its split, including a ton of Lisp history.Some interesting things happening over at lisp-machine.orgThe GNU manifestio mentions Lisp quite a bit, including that the plan was for the system to be mostly C and Lisp.Worse is Better, including the original (but the first of those two links provides a lot of context)The AI winter. Bundle up, lispers!Symbolics' Mac IvoryRISC-V tagged architecture, plus this lowRISC tagged memory tutorial. (We haven't read these yet, but they're on the reading queue!)SchemeThere's a lot of these... we recommend Guile if you're interested in using Emacs (along with Geiser), and Racket if you're looking for a more gentle introduction (DrRacket, which ships with Racket, is a friendly introduction)The R5RS and R7RS-small specs are very short and easy to read especiallySee this section of the Guile manual for a bit of... historyCommon Lisp... which, yeah there are multiple implementations, but these days really means SBCL with Sly or SLIMEClojure introduced functional datastructures to the masses (okay, maybe not the masses). Neat stuff, though not a great license choice (even if technically FOSS) in our opinion and Rich Hickey kinda blew up his community so maybe use something else these days.Hy, always hy-lariousFennel, cutest lil' Lua Lisp you've ever seenWebassembly's text syntax isn't technically a Lisp, but let's be honest... is it technically not a Lisp either?!Typed Racket and HackettEmacs... Lisp?... well let's just give you the tutorial! The dreams of the 60s-80s are alive in Emacs.Actually, we just did an episode about Emacs, didn't we?Digital Humanities Workshops episodeWe guess if you wanted to use Racket and VS Code, you could use Magic Racket?! We dunno, we've never used VS Code! (Are we out of touch?!)What about for Guile?! Someone put some energy into Guile Studio!Hack & Craft!

Array Cast - April 1, 2022 Show NotesMany thanks to Adám Brudzewsky for collecting these links.00:00:50 [1] APL Seeds: https://apl.wiki/APL_Seeds00:02:31 [2] Gitte: https://apl.wiki/Gitte_Christensen00:03:42 [3] Common Lisp: https://en.wikipedia.org/wiki/Common_Lisp00:03:50 [4] April: https://apl.wiki/April00:04:00 [5] Bloxl: https://bloxl.co00:04:34 [6] Aaron: https://apl.wiki/Aaron_Hsu00:05:20 [7] Combinator: https://en.wikipedia.org/wiki/Combinatory_logic00:07:35 [8] Keyboards: https://apl.wiki/Typing_glyphs#Hardware00:08:52 [9] Mnemonics: https://apl.wiki/Mnemonics#Pairing_glyphs.2Ffunctionality_with_their_keyboard_locations00:09:13 [10] Model M: https://en.wikipedia.org/wiki/Model_M_keyboard00:09:13 [11] Model F: https://en.wikipedia.org/wiki/Model_F_keyboard00:09:34 [12] IME: https://en.wikipedia.org/wiki/Input_method00:11:00 [13] Typing methods: https://apl.wiki/Typing_glyphs#By_method00:14:25 [14] Layouts list: https://dfns.dyalog.com/n_keyboards.htm00:21:00 [15] Books: https://apl.wiki/Books00:21:08 [16] APL Quote Quad: https://apl.wiki/APL_Quote_Quad00:21:08 [17] Vector journal: https://apl.wiki/BAA#Vector_journal00:21:10 [18] APLcart: https://aplcart.info00:22:30 [19] Chat lessons: https://apl.wiki/APL_Cultivation00:22:42 [20] Weekly interactive sessions: https://apl.wiki/APL_Quest00:23:12 [21] Susan Bryson's Understanding APL: https://www.amazon.com/Understanding-Apl-Alfred-handy-guide/dp/088284220X00:24:50 [22] Bob on YouTube: https://youtube.com/bobtherriault00:24:55 [23] Rich on YouTube: https://youtube.com/rikedyp00:25:00 [24] Stephen's blog: https://5jt.com/tagged/software00:25:05 [25] Advent of Code: https://apl.wiki/Advent_of_Code00:25:15 [26] Aaron on YouTube: https://youtube.com/playlist?list=PLDU0iEj6f8duXzmgnlGX4hMHJUMYh4rJq00:25:20 [27] Hacker News thread: https://news.ycombinator.com/item?id=1379779700:25:23 [28] Adám on YouTube: https://youtube.com/abrudz00:25:26 [29] Rodrigo on YouTube: https://youtube.com/channel/UCd_24S_cYacw6zrvws43AWg00:25:40 [30] Conor on YouTube: https://youtube.com/codereport00:26:14 [31] Dyalog TV: https://dyalog.tv00:26:52 [32] Array Cast at Dyalog 21: https://arraycast.com/episodes/episode14-dyalog-21-live00:36:20 [33] AST: https://en.wikipedia.org/wiki/Abstract_syntax_tree00:38:10 [34] Co-dfns: https://apl.wiki/Co-dfns00:38:15 [35] Loop fusion: https://en.wikipedia.org/wiki/Loop_fission_and_fusion00:44:24 [36] Roger's list of special cases for Stencil: https://dyalog.com/blog/2020/06/towards-improvements-to-stencil00:44:45 [37] Co-dfns Performance manual: https://github.com/Co-dfns/Co-dfns/blob/master/docs/PERFORMANCE.md00:48:43 [38] New Kind of Paper: https://mlajtos.mu

Array Cast - March 19, 2022 Show NotesMany thanks to Adám Brudzewsky and Andrew Sengul for collecting these links.[1] 1:42 J Playground https://jsoftware.github.io/j-playground/bin/html/emj.html[2] 2:18 Bob's Pi video https://www.youtube.com/watch?v=vyILnD0e2IE[3] 2:50 ADSP the podcast https://adspthepodcast.com/[4] 3:50 LispNYC April presentation https://youtube.com/watch?v=AUEIgfj9koc[5] 5:00 April repo https://github.com/phantomics/april[6] 6:40 ELS paper - page 1, getting lexer output - page 2, adding a function to an April workspace - page 2, getting April's compiled output - page 3, adding a new lexical function to April - page 5, PNG palette extractor https://zenodo.org/record/6381963[7] 7:30 Lisp Creator John McCarthy http://jmc.stanford.edu/[8] 7:50 Steve Russel https://en.wikipedia.org/wiki/Steve_Russell_(computer_scientist)[9] 8:27 McCarthy's M-Expressions https://en.wikipedia.org/wiki/M-expression[10] 9:30 Common Lisp https://en.wikipedia.org/wiki/Common_Lisp[11] 10:20 Lisp Machine https://en.wikipedia.org/wiki/Lisp_machine[12] 13:43 Scenario Engine https://devpost.com/software/scenario-engine[13] 14:10 YAML https://yaml.org/[14] 18:15 LispNYC Seed presentation https://vimeo.com/269495385[15] 18:38 K and Kdb https://aplwiki.com/wiki/K[16] 23:50 Bloxl - Bloxl.co https://bloxl.co[17] 31:30 April's core specification - spec.lisp https://github.com/phantomics/april/blob/master/spec.lisp[18] 33:50 April's Vex framework - vex.lisp https://github.com/phantomics/april/blob/master/vex/vex.lisp[19] 40:43 CEPL GLSL compiler https://github.com/cbaggers/cepl YouTube Playlist https://www.youtube.com/playlist?list=PL2VAYZE_4wRKKr5pJzfYD1w4tKCXARs5y[20] 41:40 Racket - the most popular Scheme https://racket-lang.org/[21] 42:10 Scheme - https://en.wikipedia.org/wiki/Scheme_(programming_language)[22] 49:00 arctanh in Lisp and APL https://groups.google.com/g/comp.lang.apl/c/vRjMvZZUIiw/m/CxGL-FR-AAAJ[23] 49:42 Paul Penfield https://news.mit.edu/2021/professor-emeritus-paul-penfield-dies-0903[24] 53:10 kparc https://kparc.com/lisp.txt[25] 01:11:30 April's special code framework - patterns.lisp https://github.com/phantomics/april/blob/master/patterns.lisp[26] 01:18:30 APL Seeds https://www.dyalog.com/apl-seeds-user-meetings/aplseeds22.htm

We had fantastic chat with Joshua learning a thing or two about coffi the clojure FFI and farolero that is bringing Common LISP conditionals to to clojure. As far as we know, this is the first Clojure podcast to have Lojban in it! We would love it if you can join us for first ever defn call in show live with Joshua on 13th February 20:00 CET on our discord https://discord.gg/dDWd75xC

Common Lisp was written in the 80s as a kind of an amalgam of the existing Lisps at the time. To make sure the Common Lisp would stay relevant, it was made backward compatible so that existing legacy systems could run on it. One thing in common to these big old systems like Lisp is a lot more mutation, and the cool thing about this legacy is that it has a baked experience – it learns and it has learned. Today we talk to Eric Normand, an experienced functional programmer, trainer, speaker, and consultant on all things functional programming. He started writing Lisp in 2000 and is now a Clojure expert, producing the most comprehensive suite of Clojure training material at purelyfunctional.tv. He also consults with companies to use functional programming to better serve business objectives.  We talk about problems in legacy code basis utilizing functional programming, the abstract nature of programs, the wisdom of Lisp, and more.  When you’re done listening to the episode, make sure to check out Eric’s Clojure training and his podcast, as well as connect with him on LinkedIn. Mentioned in this episode: Eric Normand on LinkedIn: linkedin.com/in/eric-normand-61a70366/ Eric Normand’s podcast: Lispcast.com Eric Normand’s websites: https://lispcast.com and https://purelyfunctional.tv  Eric Normand’s Clojure training: Purelyfunctional.tv Eric Normand’s book Grokking Simplicity: https://www.manning.com/books/grokking-simplicity?utm_source=lispcast&utm_medium=affiliate&utm_campaign=book_normand_grokking_8_20_19&a_aid=lispcast&a_bid=72596968Use discount code TSSIMPLICITY for 50% off.

Sexta entrega de la travesía de descubrimiento por la programación funcional. En esta ocasión Andros invita a Diego Sevilla, profesor en la Universidad de Murcia para hablar de Lisp, uno de los lenguajes de programación más longevos y raíz de otros dialectos como Scheme, Clojure, Common Lisp o Emacs Lisp. Se puede asegurar que familia de Lisp tiene una larga historia que ha ayudado a modelar a otros lenguajes. Todo un pionero para lenguajes tan conocidos como Perl, Python, Javascript, Lua, Scala, Ruby, R, Elixir, Haskell… entre otros. Y que, a pesar de haber nacido en 1958 continúa gozando de salud juvenil. Lisp se puede utilizar en 10 dialectos diferentes, como por ejemplo Clojure, del que ya hablamos en el primer episodio de la serie programación funcional. Con Diego Sevilla hablamos mucho sobre GNU Emacs, la situación actual de Lisp, de Common Lisp, del invierno de la IA y su renacimiento, de la perenne habilidad de Lisp para continuar siendo un lenguaje valioso, altamente expresivo, con su particular sintaxis y con unas bases profundamente sólidas en conceptos matemáticos. Como en anteriores episodios de la serie, conversamos sobre los comienzos de Diego en la programación funcional, su uso actual, recursos de interés para conocer el lenguaje y su comunidad.

Sexta entrega de la travesía de descubrimiento por la programación funcional. En esta ocasión Andros invita a Diego Sevilla, profesor en la Universidad de Murcia para hablar de Lisp, uno de los lenguajes de programación más longevos y raíz de otros dialectos como Scheme, Clojure, Common Lisp o Emacs Lisp. Se puede asegurar que familia de Lisp tiene una larga historia que ha ayudado a modelar a otros lenguajes. Todo un pionero para lenguajes tan conocidos como Perl, Python, Javascript, Lua, Scala, Ruby, R, Elixir, Haskell… entre otros. Y que, a pesar de haber nacido en 1958 continúa gozando de salud juvenil. Lisp se puede utilizar en 10 dialectos diferentes, como por ejemplo Clojure, del que ya hablamos en el primer episodio de la serie programación funcional. Con Diego Sevilla hablamos mucho sobre GNU Emacs, la situación actual de Lisp, de Common Lisp, del invierno de la IA y su renacimiento, de la perenne habilidad de Lisp para continuar siendo un lenguaje valioso, altamente expresivo, con su particular sintaxis y con unas bases profundamente sólidas en conceptos matemáticos. Como en anteriores episodios de la serie, conversamos sobre los comienzos de Diego en la programación funcional, su uso actual, recursos de interés para conocer el lenguaje y su comunidad. Notas del episodio en https://republicaweb.es/podcast/descubriendo-la-programacion-funcional-lisp-con-diego-sevilla/

Alan on GitHub - https://github.com/alandipert Alan on Twitter - https://twitter.com/alandipert Alan's website - https://tailrecursion.com/~alan/Home.html Hoplon on GitHub - https://github.com/hoplon/hoplon Holpon's website - http://hoplon.io/ - Hoplon and Javelin, Micha Niskin - https://www.youtube.com/watch?v=UoZyyo2Bwr8 - High level UI toolkit built on Hoplon: https://github.com/jumblerg/ui - cljson: https://github.com/tailrecursion/cljson - Example app using shadow-cljs with Hoplon: https://github.com/rlander/conduit - Equality operator rationale in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Issues/iss143_w.htm - Hoplon and Bacwn (pre-Datomic Datalog): https://alandipert.github.io/hoplon-demos/bacwn-hoplon/ - FRP in ClojureScript with Javelin: https://tailrecursion.com/~alan/index.cgi/doc/tip/documents/Dipert-FRP_in_ClojureScript_with_Javelin.pdf, http://www.infoq.com/presentations/ClojureScript-Javelin, https://github.com/tailrecursion/javelin - Flapjax and ClojureScript: https://www.youtube.com/watch?v=xaxF5RDdVRE#t=22m21s, https://github.com/alandipert/flapjax-demo, http://alandipert.github.io/flapjax-demo/ - Flapjax Paper - https://cs.brown.edu/people/sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf - Micha on Hoplon vs React - https://tailrecursion.com/~alan/micha_on_hoplon_vs_react/ Video Courses: https://www.LearnReitit.com (new) https://www.LearnReFrame.com https://www.LearnReagent.com

Ivan Reese guest hosts. I've been intimidated by Jack Rusher from the first blush. I mean, he's wearing a high-collared fur coat and black sunglasses in his Twitter pic, and his bio includes "Bell Labs Researcher". So when tasked with choosing a subject for my first interview, I immediately reached out to him, leaning in to my nervousness. His reply included the detail that he's "generally hostile to the form" of podcasting. Terrifying. When we talked, it was about Lisp — several flavours of Scheme and Racket, Common Lisp, Lisp machines, Black, Clojure, parens of all stripes. It was also about aesthetics, and graphic design, the relative ignorance of typical programming tools to the capability of the visual cortex, and how to better tap it. This podcast's streak of discussions about Coq, miniKanren, TLA+, and Alloy continues, with the addition of QuickCheck and the like. Jack presents his work on a literate editor for Clojure called Maria.cloud, an environment that makes a number of unusual and interesting choices both in the design and implementation, reaching for an ideal blend of features that afford both instant beginner enthusiasm and unrestricted expert use. We pay our respects to the phenomenal red carpet that video games roll out to new players, inviting them in to the model and mechanics of the game with an apparent ease and apt ability that should be the envy of programming toolsmiths like us. The show ends with Jack sharing an excellent collection of plugs, ranging from academic papers by the relatively obscure Stéphane Conversy, to the aesthetically-lush programming tools pouring out of Hundredrabbits's Devine Lu Linvega. I am no longer terrified of Jack's persona. Rather, I am now humbled by his towering expertise and the wildly varied accomplishments of his career, and it was a thrill to get to tour them in this interview. Best quote of the show: "A kind of grotesque capitulation to sameness." Damn, Jack! Links Jack Rusher is our esteemed guest. He is on Twitter, Instagram, and SoundCloud. Applied Science is his consultancy, and Maria.cloud is their beautifully designed literate Clojure editor. Ivan Reese hosts. He's on Twitter, works on educational media, is making a visual programming tool, and plays 100 instruments — badly. He started life with HyperCard and now loves Max/MSP. Repl.it is our Sponsor. Email jobs@repl.it if you'd like to work on the future of coding. Complex Event Processing is a bit of technology Jack helped commercialize. ClojureVerse is where a discussion of Luna led to the Visual Programming Codex, based on the History of Lisp Parens by Shaun Lebron. QuickCheck, miniKanren, Datalog, Black Scheme, and Oleg Kiselyov are touched on. Out of the Tar Pit has its mandatory mention, and then Chez Scheme saves the day. I wanted to link to the Maru project but the author, Ian Piumata's website seems to be down and I could find no other canonical reference. There's some discussion on Hacker News and such. If you know of a good link, I'd love a PR. Scheme Bricks and Media Molecule's Dreams are interesting touchstones on the road to future visual programming languages. Ivan has an affinity for Pure Data and Max/MSP and vvvv. When talking about tools for beginners versus experts, Rich Hickey's Design, Composition, and Performance is invoked — and poor Shostakovich. Jack's main is Maria.cloud, named in honour of Maria Montessori. SICP gets a nod. Maria has proven useful at Clojure Bridge. Matt Hubert [Twitter] created the Cells abstraction that Maria was eventually built atop — it's similar to ObservableHQ. Video games like Steel Battalion, The Witness, and Dead Space have strong opinions about how much, or how little, visual interface to expose to the player. Complex 3D tools like Maya and 3D Studio Max are GUI inspirations for Ivan, where Jack and Matt prefer simplicity, so much so that Matt wrote When I Sit Down At My Editor, I Feel Relaxed. Dave Liepmann is the third leg of the stool in Applied Science, Jack's consultancy. Maria originally had a deployment feature like Glitch. There's a great talk about Maria by the Applied Science trio, containing a mini-talk called Maria for experts by Jack. Pharo is an inspiring modern Smalltalk. Fructure is a wildly cool new structured editor, and its designer Andrew Blinn is fantastic on Twitter. Extempore and Temporal Recursion by Andrew Sorensen offer some interesting foundations for future visual programming tools. Sonic Pi and Overtone are lovely audio tools by Sam Aaron, widely praised and deservedly so, and everyone should back Sam's Patreon. A visual perception account of programming languages: finding the natural science in the art and Unifying Textual and Visual: A Theoretical Account of the Visual Perception of Programming Languages are obscure but beautiful papers by Stéphane Conversy. Aesthetic Programming is one of Ivan's favourites, and the author Paul Fishwick just so happened to teach Jack's graphics programming class at Uni. Orca is a mind-bending textual-visual-musical hybrid programming tool by Hundredrabbits, who are Devine Lu Linvega and Rekka Bell. Notwithstanding that they live on a sailboat(!), they do an amazing job of presenting their work and everyone in our community should take stock of how they accomplish that. Ableton Push and Ableton Live are practically state-issued music tools in Berlin. (Not to mention — Ivan edited this podcast in Live, natch.) thi.ng and @thi.ng/umbrella are Jurassic-scale libraries by Karsten Schmidt, who wrote blog posts about Clojure's Reducers in TypeScript. Finally, Nextjournal are doing great work with their multi-lingual online scientific notebook environment. The transcript for this episode was sponsored by Repl.it and can be found at https://futureofcoding.org/episodes/041#full-transcript

Miuraさんと一緒にいろいろなスクリプト言語の実装や言語そのものなどについて話をしました。出演者: Miura Hideki (@miura1729)、Rui Ueyama (@rui314) https://turingcomplete.fm/6 ハッシュタグは#tcfmです。 TCFMはサポーターの投げ銭によって収益を上げています。このコンテンツに課金してもいいよという方はぜひクリエイター支援サイトPatreonから登録してご協力ください。 LuaとLuaJIT (0:00) 例外のABI (8:25) SQLiteとライセンス (12:45) ファイルシステムとデータベース (16:23) XLISPで言語の書き方を学んだ (19:15) C++の後方互換性とトライグラフ (21:55) Common Lispのメタオブジェクトプロトコル (26:18) Gauche Schemeのコンパイラのブートストラップ (35:40) 川合史郎さんの自作オーブンPC (40:02) ForthとOh! FM (43:00) Sun SPARCStation (50:27) PostScriptとHTML Canvas (53:16) SVGとXML (56:58) Lua SQLite パブリックドメイン XLISP トライグラフ The Art of the Metaobject Protocol Gauche Scheme COME FROM Reflections on Trusting Trust オーブンPC Forth Open Firmware PostScriptチュートリアル & クックブック

next_generation 7.0: SENSORIK | Symposium 14.06.2017 to 18.06.2017 With an exciting lecture program enriched the festival »next_generation 7.0 SENSORIK« Over five days and five nights, next_generation 7.0 offered an exciting and packed program on the latest positions on topics such as »Fixed Media«, »Spatial Music« and »Live-Electronics«, showing off the current creativity of the younger generation of producers in the context of technology and art. /// 14.06.2017 bis 18.06.2017 Mit einem spannenden Vortragsprogramm bereicherte das Festival »next_generation 7.0 SENSORIK« An fünf Tagen und fünf Nächten bot next_generation 7.0 ein spannendes und dichtes Programm über die neuesten Positionen zu den Themen »Fixed Media«, »Raummusik« und »Live-Elektronik«. Damit garantierte next_generation 7.0 eine repräsentative Übersicht über das aktuelle kreative Schaffen der kommenden Komponierendengeneration im Kontext von Technologie und Kunst.

I veckans avsnitt diskuterar grabbarna grus fler science fiction-filmer, bråkande spamfilter, filmer med AI, bluffare i retrovärlden, en oerhört usel icke-sevärd film med datorspelsanknytning, lite speltips, ilska över iOS 11 och hur man ringer med analoga modem över IP-telefoni. Länkar Mulled wine Christmas at ground zero Scrollout F1 Frontdoor Office space - skrivarscenen Her - tack för påminnelsen Mattias! Spike Jonze Inside man Moon Bloggen om Moon Mima och Aniara Ex machina Sunshine Doom, motorsågsscenen Gamedev tycoon Gemtillverkande AI Universal paperclips Artikeln Fredrik läste om spelet Google fixar sina katastrof-emoji Advent of code Kodsnacks Advent of code-repo på Github - skicka din mejladress om du vill vara med i Kodsnacks Slack också REXX Brainfuck Common lisp Erik Svedäng, skapare av else Heart.Break() Carp COBOL Iggy Drougge Rotinloggningsbuggen Datum/notisbuggen i IOS Forecast Phase 5 John “Chucky” Hertell felsöker Phase 5-korten Jockes kort repareras (kanske) Terriblefire på Youtube TF530 på Github Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-104-vi-ska-fa-fart-pa-rymden-igen.html.

In this episode, we clear up the myth about scrub of death, look at Wayland and Weston on FreeBSD, Intel QuickAssist is here, and we check out OpenSMTP on OpenBSD. This episode was brought to you by Headlines Matt Ahrens answers questions about the “Scrub of Death” In working on the breakdown of that ZFS article last week, Matt Ahrens contacted me and provided some answers he has given to questions in the past, allowing me to answer them using HIS exact words. “ZFS has an operation, called SCRUB, that is used to check all data in the pool and recover any data that is incorrect. However, if a bug which make errors on the pool persist (for example, a system with bad non-ecc RAM) then SCRUB can cause damage to a pool instead of recover it. I heard it called the “SCRUB of death” somewhere. Therefore, as far as I understand, using SCRUB without ECC memory is dangerous.” > I don't believe that is accurate. What is the proposed mechanism by which scrub can corrupt a lot of data, with non-ECC memory? > ZFS repairs bad data by writing known good data to the bad location on disk. The checksum of the data has to verify correctly for it to be considered "good". An undetected memory error could change the in-memory checksum or data, causing ZFS to incorrectly think that the data on disk doesn't match the checksum. In that case, ZFS would attempt to repair the data by first re-reading the same offset on disk, and then reading from any other available copies of the data (e.g. mirrors, ditto blocks, or RAIDZ reconstruction). If any of these attempts results in data that matches the checksum, then the data will be written on top of the (supposed) bad data. If the data was actually good, then overwriting it with the same good data doesn't hurt anything. > Let's look at what will happen with 3 types of errors with non-ECC memory: > 1. Rare, random errors (e.g. particle strikes - say, less than one error per GB per second). If ZFS finds data that matches the checksum, then we know that we have the correct data (at least at that point in time, with probability 1-1/2^256). If there are a lot of memory errors happening at a high rate, or if the in-memory checksum was corrupt, then ZFS won't be able to find a good copy of the data , so it won't do a repair write. It's possible that the correctly-checksummed data is later corrupted in memory, before the repair write. However, the window of vulnerability is very very small - on the order of milliseconds between when the checksum is verified, and when the write to disk completes. It is implausible that this tiny window of memory vulnerability would be hit repeatedly. > 2. Memory that pretty much never does the right thing. (e.g. huge rate of particle strikes, all memory always reads 0, etc). In this case, critical parts of kernel memory (e.g. instructions) will be immediately corrupted, causing the system to panic and not be able to boot again. > 3. One or a few memory locations have "stuck bits", which always read 0 (or always read 1). This is the scenario discussed in the message which (I believe) originally started the "Scrub of Death" myth: https://forums.freenas.org/index.php?threads/ecc-vs-non-ecc-ram-and-zfs.15449/ This assumes that we read in some data from disk to a memory location with a stuck bit, "correct" that same bad memory location by overwriting the memory with the correct data, and then we write the bad memory location to disk. However, ZFS doesn't do that. (It seems the author thinks that ZFS uses parity, which it only does when using RAID-Z. Even with RAID-Z, we also verify the checksum, and we don't overwrite the bad memory location.) > Here's what ZFS will actually do in this scenario: If ZFS reads data from disk into a memory location with a stuck bit, it will detect a checksum mismatch and try to find a good copy of the data to repair the "bad" disk. ZFS will allocate a new, different memory location to read a 2nd copy of the data, e.g. from the other side of a mirror (this happens near the end of dslscanscrub_cb()). If the new memory location also has a stuck bit, then its checksum will also fail, so we won't use it to repair the "bad" disk. If the checksum of the 2nd copy of the data is correct, then we will write it to the "bad" disk. This write is unnecessary, because the "bad" disk is not really bad, but it is overwriting the good data with the same good data. > I believe that this misunderstanding stems from the idea that ZFS fixes bad data by overwriting it in place with good data. In reality, ZFS overwrites the location on disk, using a different memory location for each read from disk. The "Scrub of Death" myth assumes that ZFS overwrites the location in memory, which it doesn't do. > In summary, there's no plausible scenario where ZFS would amplify a small number of memory errors, causing a "scrub of death". Additionally, compared to other filesystems, ZFS checksums provide some additional protection against bad memory. “Is it true that ZFS verifies the checksum of every block on every read from disk?” > Yes “And if that block is incorrect, that ZFS will repair it?” > Yes “If yes, is it possible set options or flag for change that behavior? For example, I would like for ZFS to verify checksums during any read, but not change anything and only report about issues if it appears. Is it possible?” > There isn't any built-in flag for doing that. It wouldn't be hard to add one though. If you just wanted to verify data, without attempting to correct it, you could read or scan the data with the pool was imported read-only “If using a mirror, when a file is read, is it fully read and verified from both sides of the mirror?” > No, for performance purposes, each block is read from only one side of the mirror (assuming there is no checksum error). “What is the difference between a scrub and copying every file to /dev/null?” > That won't check all copies of the file (e.g. it won't check both sides of the mirror). *** Wayland, and Weston, and FreeBSD - Oh My! (https://euroquis.nl/bobulate/?p=1617) KDE's CI system for FreeBSD (that is, what upstream runs to continuously test KDE git code on the FreeBSD platform) is missing some bits and failing some tests because of Wayland. Or rather, because FreeBSD now has Wayland, but not Qt5-Wayland, and no Weston either (the reference implementation of a Wayland compositor). Today I went hunting for the bits and pieces needed to make that happen. Fortunately, all the heavy lifting has already been done: there is a Weston port prepared and there was a Qt5-Wayland port well-hidden in the Area51 plasma5/ branch. I have taken the liberty of pulling them into the Area51 repository as branch qtwayland. That way we can nudge Weston forward, and/or push Qt5-Wayland in separately. Nicest from a testing perspective is probably doing both at the same time. I picked a random “Hello World” Wayland tutorial and also built a minimal Qt program (using QMessageBox::question, my favorite function to hate right now, because of its i18n characteristics). Then, setting XDGRUNTIMEDIR to /tmp/xdg, I could start Weston (as an X11 client), wayland-hello (as a Wayland client, displaying in Weston) and qt-hello (as either an X11 client, or as a Wayland client). So this gives users of Area51 (while shuffling branches, granted) a modern desktop and modern display capabilities. Oh my! It will take a few days for this to trickle up and/or down so that the CI can benefit and we can make sure that KWin's tests all work on FreeBSD, but it's another good step towards tight CI and another small step towards KDE Plasma 5 on the desktop on FreeBSD. pkgsrcCon 2017 report (https://blog.netbsd.org/tnf/entry/pkgsrccon_2017_report) This years pkgsrcCon returned to London once again. It was last held in London back in 2014. The 2014 con was the first pkgsrcCon I attended, I had been working on Darwin/PowerPC fixes for some months and presented on the progress I'd made with a 12" G4 PowerBook. I took away a G4 Mac Mini that day to help spare the PowerBook for use and dedicate a machine for build and testing. The offer of PowerPC hardware donations was repeated at this years con, thanks to jperkin@ who showed up with a backpack full of Mac Minis (more on that later). Since 2014 we have held cons in Berlin (2015) & Krakow (2016). In Krakow we had talks about a wide range of projects over 2 days, from Haiku Ports to Common Lisp to midipix (building native PE binaries for Windows) and back to the BSDs. I was very pleased to continue the theme of a diverse program this year. Aside from pkgsrc and NetBSD, we had talks about FreeBSD, OpenBSD, Slackware Linux, and Plan 9. Things began with a pub gathering on the Friday for the pre-con social, we hung out and chatted till almost midnight on a wide range of topics, such as supporting a system using NFS on MS-DOS, the origins of pdksh, corporate IT, culture and many other topics. On parting I was asked about the starting time on Saturday as there was some conflicting information. I learnt that the registration email had stated a later start than I had scheduled for & advertised on the website, by 30 minutes. Lesson learnt: register for your own event! Not a problem, I still needed to setup a webpage for the live video stream, I could do both when I got back. With some trimming here and there I had a new schedule, I posted that to the pkgsrcCon website and moved to trying to setup a basic web page which contained a snippet of javascript to play a live video stream from Scale Engine. 2+ hours later, it was pointed out that the XSS protection headers on pkgsrc.org breaks the functionality. Thanks to jmcneill@ for debugging and providing a working page. Saturday started off with Giovanni Bechis speaking about pledge in OpenBSD and adding support to various packages in their ports tree, alnsn@ then spoke about installing packages from a repo hosted on the Tor network. After a quick coffee break we were back to hear Charles Forsyth speak about how Plan 9 and Inferno dealt with portability, building software and the problem which are avoided by the environment there. This was followed by a very energetic rant by David Spencer from the Slackbuilds project on packaging 3rd party software. Slackbuilds is a packaging system for Slackware Linux, which was inspired by FreeBSD ports. For the first slot after lunch, agc@ gave a talk on the early history of pkgsrc followed by Thomas Merkel on using vagrant to test pkgsrc changes with ease, locally, using vagrant. khorben@ covered his work on adding security to pkgsrc and bsiegert@ covered the benefits of performing our bulk builds in the cloud and the challenges we currently face. My talk was about some topics and ideas which had inspired me or caught my attention, and how it could maybe apply to my work.The title of the talk was taken from the name of Andrew Weatherall's Saint Etienne remix, possibly referring to two different styles of track (dub & vocal) merged into one or something else. I meant it in terms of applicability of thoughts and ideas. After me, agc@ gave a second talk on the evolution of the Netflix Open Connect appliance which runs FreeBSD and Vsevolod Stakhov wrapped up the day with a talk about the technical implementation details of the successor to pkgtools in FreeBSD, called pkg, and how it could be of benefit for pkgsrc. For day 2 we gathered for a hack day at the London Hack Space. I had burn't some some CD of the most recent macppc builds of NetBSD 8.0BETA and -current to install and upgrade Mac Minis. I setup the donated G4 minis for everyone in a dual-boot configuration and moved on to taking apart my MacBook Air to inspect the wifi adapter as I wanted to replace it with something which works on FreeBSD. It was not clear from the ifixit teardown photos of cards size, it seemed like a normal mini-PCIe card but it turned out to be far smaller. Thomas had also had the same card in his and we are not alone. Thomas has started putting together a driver for the Broadcom card, the project is still in its early days and lacks support for encrypted networks but hopefully it will appear on review.freebsd.org in the future. weidi@ worked on fixing SunOS bugs in various packages and later in the night we setup a NetBSD/macppc bulk build environment together on his Mac Mini. Thomas setup an OpenGrock instance to index the source code of all the software available for packaging in pkgsrc. This helps make the evaluation of changes easier and the scope of impact a little quicker without having to run through a potentially lengthy bulk build with a change in mind to realise the impact. bsiegert@ cleared his ticket and email backlog for pkgsrc and alnsn@ got NetBSD/evbmips64-eb booting on his EdgeRouter Lite. On Monday we reconvened at the Hack Space again and worked some more. I started putting together the talks page with the details from Saturday and the the slides which I had received, in preparation for the videos which would come later in the week. By 3pm pkgsrcCon was over. I was pretty exhausted but really pleased to have had a few days of techie fun. Many thanks to The NetBSD Foundation for purchasing a camera to use for streaming the event and a speedy response all round by the board. The Open Source Specialist Group at BCS, The Chartered Institute for IT and the London Hack Space for hosting us. Scale Engine for providing streaming facility. weidi@ for hosting the recorded videos. Allan Jude for pointers, Jared McNeill for debugging, NYCBUG and Patrick McEvoy for tips on streaming, the attendees and speakers. This year we had speakers from USA, Italy, Germany and London E2. Looking forward to pkgsrcCon 2018! The videos and slides are available here (http://www.pkgsrc.org/pkgsrcCon/2017/talks.html) and the Internet Archive (http://archive.org/details/pkgsrcCon-2017). News Roundup QuickAssist Driver for FreeBSD is here and pfSense Support Coming (https://www.servethehome.com/quickassist-driver-freebsd-pfsupport-coming/) This week we have something that STH readers will be excited about. Before I started writing for STH, I was a reader and had been longing for QuickAssist support ever since STH's first Rangeley article over three and a half years ago. It was clear from the get-go that Rangeley was going to be the preeminent firewall appliance platform of its day. The scope of products that were impacted by the Intel Atom C2000 series bug showed us it was indeed. For my personal firewalls, I use pfSense on that Rangeley platform so I have been waiting to use QuickAssist with my hardware for almost an entire product generation. + New Hardware and QuickAssist Incoming to pfSense (Finally) pfSense (and a few other firewalls) are based on FreeBSD. FreeBSD tends to lag driver support behind mainstream Linux but it is popular for embedded security appliances. While STH is the only site to have done QuickAssist benchmarks for OpenSSL and IPSec VPNs pre-Skylake, we expect more platforms to use it now that the new Intel Xeon Scalable Processor Family is out. With the Xeon Scalable platforms, the “Lewisburg” PCH has QuickAssist options of up to 100Gbps, or 2.5x faster than the previous generation add-in cards we tested (40Gbps.) We now have more and better hardware for QAT, but we were still devoid of a viable FreeBSD QAT driver from Intel. That has changed. Our Intel Xeon Scalable Processor Family (Skylake-SP) Launch Coverage Central has been the focus of the STH team's attention this week. There was another important update from Intel that got buried, a publicly available Intel QuickAssist driver for FreeBSD. You can find the driver on 01.org here dated July 12, 2017. Drivers are great, but we still need support to be enabled in the OS and at the application layer. Patrick forwarded me this tweet from Jim Thompson (lead at Netgate the company behind pfSense): The Netgate team has been a key company pushing QuickAssist appliances in the market, usually based on Linux. To see that QAT is coming to FreeBSD and that they were working to integrate into “pfSense soon” is more than welcome. For STH readers, get ready. It appears to be actually and finally happening. QuickAssist on FreeBSD and pfSense OpenBSD on the Huawei MateBook X (https://jcs.org/2017/07/14/matebook) The Huawei MateBook X is a high-quality 13" ultra-thin laptop with a fanless Core i5 processor. It is obviously biting the design of the Apple 12" MacBook, but it does have some notable improvements such as a slightly larger screen, a more usable keyboard with adequate key travel, and 2 USB-C ports. It also uses more standard PC components than the MacBook, such as a PS/2-connected keyboard, removable m.2 WiFi card, etc., so its OpenBSD compatibility is quite good. In contrast to the Xiaomi Mi Air, the MateBook is actually sold (2) in the US and comes with a full warranty and much higher build quality (though at twice the price). It is offered in the US in a "space gray" color for the Core i5 model and a gold color for the Core i7. The fanless Core i5 processor feels snappy and doesn't get warm during normal usage on OpenBSD. Doing a make -j4 build at full CPU speed does cause the laptop to get warm, though the palmrest maintains a usable temperature. The chassis is all aluminum and has excellent rigidity in the keyboard area. The 13.0" 2160x1440 glossy IPS "Gorilla glass" screen has a very small bezel and its hinge is properly weighted to allow opening the lid with one hand. There is no wobble in the screen when open, even when jostling the desk that the laptop sits on. It has a reported brightness of 350 nits. I did not experience any of the UEFI boot variable problems that I did with the Xiaomi, and the MateBook booted quickly into OpenBSD after re-initializing the GPT table during installation. OpenSMTPD under OpenBSD with SSL/VirtualUsers/Dovecot (https://blog.cagedmonster.net/opensmtpd-under-openbsd-with-ssl-virtualusers-dovecot/) During the 2013 AsiaBSDCon, the team of OpenBSD presented its mail solution named OpenSMTPD. Developed by the OpenBSD team, we find the so much appreciated philosophy of its developers : security, simplicity / clarity and advanced features. Basic configuration : OpenSMTPD is installed by default, we can immediately start with a simple configuration. > We listen on our interfaces, we specify the path of our aliases file so we can manage redirections. > Mails will be delivered for the domain cagedmonster.net to mbox (the local users mailbox), same for the aliases. > Finally, we accept to relay local mails exclusively. > We can now enable smtpd at system startup and start the daemon. Advanced configuration including TLS : You can use SSL with : A self-signed certificate (which will not be trusted) or a certificate generated by a trusted authority. LetsEncrypt uses Certbot to generated your certificate. You can check this page for further informations. Let's focus on the first. Generation of the certificate : We fix the permissions : We edit the config file : > We have a mail server with SSL, it's time to configure our IMAP server, Dovecot, and manage the creation of virtual users. Dovecot setup, and creation of Virtual Users : We will use the package system of OpenBSD, so please check the configuration of your /etc/pkg.conf file. Enable the service at system startup : Setup the Virtual Users structure : Adding the passwd table for smtpd : Modification of the OpenSMTPD configuration : We declare the files used for our Virtual Accounts, we include SSL, and we configure mails delivery via the Dovecot lmtp socket. We'll create our user lina@cagedmonster.net and set its password. Configure SSL Configure dovecot.conf Configure mail.con Configure login.conf : Make sure that the value of openfiles-cur in /etc/login.conf is equal or superior of 1000 ! Starting Dovecot *** OpenSMTPD and Dovecot under OpenBSD with MySQL support and SPAMD (https://blog.cagedmonster.net/opensmtpd-and-dovecot-under-openbsd-with-mysql-support-and-spamd/) This article is the continuation of my previous tutorial OpenSMTPD under OpenBSD with SSL/VirtualUsers/Dovecot. We'll use the same configuration and add some features so we can : Use our domains, aliases, virtual users with a MySQL database (MariaDB under OpenBSD). Deploy SPAMD with OpenSMTPD for a strong antispam solution. + Setup of the MySQL support for OpenSMTPD & Dovecot + We create our SQL database named « smtpd » + We create our SQL user « opensmtpd » we give him the privileges on our SQL database and we set its password + We create the structure of our SQL database + We generate our password with Blowfish (remember it's OpenBSD !) for our users + We create our tables and we include our datas + We push everything to our database + Time to configure OpenSMTPD + We create our mysql.conf file and configure it + Configuration of Dovecot.conf + Configuration of auth-sql.conf.ext + Configuration of dovecot-sql.conf.ext + Restart our services OpenSMTPD & SPAMD : SPAMD is a service simulating a fake SMTP server and relying on strict compliance with RFC to determine whether the server delivering a mail is a spammer or not. + Configuration of SPAMD : + Enable SPAMD & SPAMLOGD at system startup : + Configuration of SPAMD flags + Configuration of PacketFilter + Configuration of SPAMD + Start SPAMD & SPAMLOGD Running a TOR relay on FreeBSD (https://networkingbsdblog.wordpress.com/2017/07/14/freebsd-tor-relay-using-priveledge-seperation/) There are 2 main steps to getting a TOR relay working on FreeBSD: Installing and configuring Tor Using an edge router to do port translation In my case I wanted TOR to run it's services on ports 80 and 443 but any port under 1024 requires root access in UNIX systems. +So I used port mapping on my router to map the ports. +Begin by installing TOR and ARM from: /usr/ports/security/tor/ /usr/ports/security/arm/ Arm is the Anonymizing Relay Monitor: https://www.torproject.org/projects/arm.html.en It provides useful monitoring graph and can be used to configure the torrc file. Next step edit the torrc file (see Blog article for the edit) It is handy to add the following lines to /etc/services so you can more easily modify your pf configuration. torproxy 9050/tcp #torsocks torOR 9090/tcp #torOR torDIR 9099/tcp #torDIR To allow TOR services my pf.conf has the following lines: # interfaces lan_if=”re0″ wifi_if=”wlan0″ interfaces=”{wlan0,re0}” tcp_services = “{ ssh torproxy torOR torDIR }” # options set block-policy drop set loginterface $lan_if # pass on lo set skip on lo scrub in on $lan_if all fragment reassemble # NAT nat on $lan_if from $wifi_if:network to !($lan_if) -> ($lan_if) block all antispoof for $interfaces #In NAT pass in log on $wifi_if inet pass out all keep state #ICMP pass out log inet proto icmp from any to any keep state pass in log quick inet proto icmp from any to any keep state #SSH pass in inet proto tcp to $lan_if port ssh pass in inet proto tcp to $wifi_if port ssh #TCP Services on Server pass in inet proto tcp to $interfaces port $tcp_services keep state The finally part is mapping the ports as follows: TOR directory port: LANIP:9099 —> WANIP:80 TOR router port: LANIP:9090 —-> WANIP:443 Now enable TOR: $ sudo echo “tor_enable=YES” >> /etc/rc.conf Start TOR: $ sudo service tor start *** Beastie Bits OpenBSD as a “Desktop” (Laptop) (http://unixseclab.com/index.php/2017/06/12/openbsd-as-a-desktop-laptop/) Sascha Wildner has updated ACPICA in DragonFly to Intel's version 20170629 (http://lists.dragonflybsd.org/pipermail/commits/2017-July/625997.html) Dport, Rust, and updates for DragonFlyBSD (https://www.dragonflydigest.com/2017/07/18/19991.html) OPNsense 17.7 RC1 released (https://opnsense.org/opnsense-17-7-rc1/) Unix's mysterious && and || (http://www.networkworld.com/article/3205148/linux/unix-s-mysterious-andand-and.html#tk.rss_unixasasecondlanguage) The Commute Deck : A Homebrew Unix terminal for tight places (http://boingboing.net/2017/06/16/cyberspace-is-everting.html) FreeBSD 11.1-RC3 now available (https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087407.html) Installing DragonFlyBSD with ORCA when you're totally blind (http://lists.dragonflybsd.org/pipermail/users/2017-July/313528.html) Who says FreeBSD can't look good (http://imgur.com/gallery/dc1pu) Pratik Vyas adds the ability to do paused VM migrations for VMM (http://undeadly.org/cgi?action=article&sid=20170716160129) Feedback/Questions Hrvoje - OpenBSD MP Networking (http://dpaste.com/0EXV173#wrap) Goran - debuggers (http://dpaste.com/1N853NG#wrap) Abhinav - man-k (http://dpaste.com/1JXQY5E#wrap) Liam - university setup (http://dpaste.com/01ERMEQ#wrap)

In this episode I talk with Baishampayan Ghose, better known as BG. We talk his entry into software development, exposure to Lisp, using Common Lisp, moving to Clojure, and much, much more.

Defn Episode #02 - The Reader [ a little news: spec ] The wonders of the Reader - Compare to the C pre-processor - How it underpins the language - Reader forms - EDN / Transit - Tagged literals - Reader Conditionals (1.7+) - clojure.tools.reader - Finally, why no user defined reader macros (as in Common Lisp and Scheme)? References The Data-Reader's Guide to the Galaxy (Clojure West, 2013) by Steve Miner Spyscope by David Greenberg More information and links at the DEFN website https://defn.audio/2016/05/30/episode-02-the-reader/ Our thanks to Ptzery for the intro and outro music (Melon Hamburger) https://soundcloud.com/ptzery/

Vi snackar lite mer om saker Apple presenterade på sin utvecklarkonferens WWDC: Swifts kommande källkodsöppning och vad den kan ha för betydelse, LZFSE - Apples nya komprimeringsalgoritm, att man kommer att kunna utveckla kompletta appar som körs på Apple watch och slutligen bitcode - att man kommer att kunna (och i klockans fall vara tvungen att) ladda upp sin app till App store som intermediärkod istället för färdigkompilerad binär. Vi får också med några av Tobias utvecklarriktade intryck av Apple watch. Vilken plats kan Swift få som generellt programmeringsspråk på många plattformar nu och i framtiden? Avsnittet sponsras av Jetbrains och Webstorm, Jetbrains IDE för webbutveckling. Ett stort tack till Cloudnet som sponsrar våra livesändningar och erbjuder finfina  VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @isallmaroon och @bjoreman på Twitter och epostas på info@kodsnack.seom du vill skriva längre. Vi läser allt som skickas. Länkar Swift 2 Nextstep LLVM Clang Vår intervju med Stefan Karpinski Julia Øredev Chris Lattner Skaparna av Go Clion - Jetbrains IDE för C-språken Protokoll i Swift Typsystemet i Rust Azure - Microsofts molnplattform Protokoll i Objective-C Protocol-oriented programming in Swift - presentation från WWDC 2015 Clojure Interface i Go Goroutines Block i Objecitve-C och Swift - där de kallas closures Jetbrains - veckans sponsor Webstorm - Jetbrains IDE för webbutveckling LZFSE Zlib LZMA LZ4 deflate och inflate 7zip XZ Tarboll Apple watch-SDK:t Buy me a pie IR Processorer som kör Java-bytekod Lispmaskiner App thinning - apples paraplynamn på lösningar för att dra ner på appars storlek Alla Apples videos från WWDC Clasp - Common Lisp implementerat på LLVM Common Lisp Jakrakning Christian Schafmeister Titlar Alltifrån en kernel till egentligen webbutveckling och allt däremellan Man ska kunna skriva allt i Swift Ett bättre C++ Swift talar till mig De vill ju också köra Swift på sina servrar Där Swift kommer att kunna hitta en nisch En jättemegastor klasshierarki Vad gör man då på Linux? Ett jättestort skrikande hål Semester betyder ju att du får koda på vad du vill En binär som innehåller alla tusen plattformar Den mest optimerade versionen av din app Hans jobb är att bygga molekyler

We chat with Stefan Karpinski, creator of the Julia programming language, live on stage during Øredev 2014. Topics include deciding to build a new language, the interesting unsolved problems of numerical computing, concurrency solutions, developing with and on LLVM, handling deprecation nicely, things (possibly) in the future for Julia and why Swift is exciting for Julia and other languages. This recording exists as good as it is thanks to Stephen Chin of nighthacking.com for providing and masterfully wrangling all the necessary technology. There is a minute and a half of worse audio quality just after the nine minute mark, where microphone problems forced us to fill in with audio from our backup microphone. Comments, thoughts or suggestions? Discuss this episode at Techworld! Links Stefan Karpinski Julia programming language Scientific computing Viral Shah Jeff Bezanson MATLAB R programming language Python C extension Goldilocks Goldilocks principle Dylan Garbage collection Unboxed data Complex number Julia Webstack Numerical computing Concurrency Distributed computing Threading Julia on Github Transactional memory Goroutine Coroutine Channel I/O LLVM IFDEF JIT - just-in-time (compilation, in this case) Shared library libclang - C Interface to Clang Template instantiation Quake2.jl Go Hacker school Matrix multiplication Vectorization Generational incremental garbage collection SNOBOL SPITBOL Icon Perl 4 C99 standard Immutable composite types Multiple dispatch Monkey patch radd-trick in Python Common Lisp CLOS - Common Lisp object system Polymorphism Self BLAS - Basic linear algebra subroutines Fast fourier transform Gofix Tracing Static compilation MIT - Massachusetts institute of technology Courses taught using Julia Function pointer Scipy Steven Johnson FFTW Pycall package for Julia Call stack GDB LLDB ABI - application binary interface Clang Rust programming language Swift Chris Lattner - creator of LLVM and Swift WebKit FTL JIT - compiles Javascript using LLVM Shadow stack ‎Dynamic stack frame deoptimization MATLAB matrix concatenation syntax Titles Some of the interesting tradeoffs Bridge that gap between high-level and low-level A huge pointer graph of some kind It’s good to have a focus, initially The point where we’re pushing things The classic tradition of a ton of IFDEFs This brings us back to garbage collection Specializing for numerical work Where numbers don’t have to be special anymore (The question is:) How useful is that generalization? You don’t necessarily know what code you’re going to need in advance Trading off memory for performance Really doing the deprecation process A situation where normally you’d JIT something You might end up in a slow case You can always just fall back on an interpreter A partially compiled interpreter Nobody needs to know that it was written in Julia A really capable C library As easy as walking a linked pointer list I’m really glad someone else implemented it

We chat with Stefan Karpinski, creator of the Julia programming language, live on stage during Øredev 2014. Topics include defiding to build a new language, the interesting unsolved problems of numerical computing, concurrency solutions, developing with and on LLVM, handling deprecation nicely, things (possibly) in the future for Julia and why Swift is exciting for Julia and other languages. This recording exists as good as it is thanks to Stephen Chin of nighthacking.com for providing and masterfully wrangling all the necessary technology. There is a minute and a half of worse audio quality just after the nine minute mark, where microphone problems forced us to fill in with audio from our backup microphone. Comments, thoughts or suggestions? Discuss this episode at Techworld! Links Stefan Karpinski Julia programming language Scientific computing Viral Shah Jeff Bezanson MATLAB R programming language Python C extension Goldilocks Goldilocks principle Dylan Garbage collection Unboxed data Complex number Julia Webstack Numerical computing Concurrency Distributed computing Threading Julia on Github Transactional memory Goroutine Coroutine Channel I/O LLVM IFDEF JIT - just-in-time (compilation, in this case) Shared library libclang - C Interface to Clang Template instantiation Quake2.jl Go Hacker school Matrix multiplication Vectorization Generational incremental garbage collection SNOBOL SPITBOL Icon Perl 4 C99 standard Immutable composite types Multiple dispatch Monkey patch radd-trick in Python Common Lisp CLOS - Common Lisp object system Polymorphism Self BLAS - Basic linear algebra subroutines Fast fourier transform Gofix Tracing Static compilation MIT - Massachusetts institute of technology Courses taught using Julia Function pointer Scipy Steven Johnson FFTW Pycall package for Julia Call stack GDB LLDB ABI - application binary interface Clang Rust programming language Swift Chris Lattner - creator of LLVM and Swift WebKit FTL JIT - compiles Javascript using LLVM Shadow stack ‎Dynamic stack frame deoptimization MATLAB matrix concatenation syntax Titles Some of the interesting tradeoffs Bridge that gap between high-level and low-level A huge pointer graph of some kind It’s good to have a focus, initially The point where we’re pushing things The classic tradition of a ton of IFDEFs This brings us back to garbage collection Specializing for numerical work Where numbers don’t have to be special anymore (The question is:) How useful is that generalization? You don’t necessarily know what code you’re going to need in advance Trading off memory for performance Really doing the deprecation process A situation where normally you’d JIT something You might end up in a slow case You can always just fall back on an interpreter A partially compiled interpreter Nobody needs to know that it was written in Julia A really capable C library As easy as walking a linked pointer list I’m really glad someone else implemented it

Спонсор выпуска — Vexor CI – облачный continuous integration сервис для ruby разработчиков с поминутной оплатой. С учетом поминутной оплаты, Vexor очень выгоден для маленьких проектов и эффективен для больших. Каждому новому пользователю предоставляется $10 на счет для экспериментов. Попробовать Vexor CI Расшифровки Коллекция рецептов для быстрого руби от Эрика. Интервью с Эриком Кир Первый раз в Москве? Эрик Ага, да. Кир И как тебе Москва, что думаешь о городе? Эрик Очень красивый город. Первый раз тут, и мне все очень нравится. Погода хорошая; вчера гуляли, были в музее космонавтики и в музее холодной войны — было здорово. Кир Круто. Эрик Ага. Кир Так вот. Ты работаешь в SoundCloud, в Берлине? Эрик Да! Кир Можешь рассказать об архитектуре SoundCloud? Эрик Так, в SoundCloud мы используем архитектуру микросервисов. Я работаю в команде, которая занимается платформой, проще говоря — серверным API. Публичный API — который используется, если использовать SoundCloud API — там запросы обрабатываются Rails приложением. Но вот как мы работаем.. Как только у нас появляются новые сервисы, и есть смысл их как-то отделить от основного, сделать их отдельным сервисом — мы так и делаем. В общем, мы используем Ruby, Rails, еще довольно много используем Scala, Clojure; все наши утилиты командной строки написаны на Go. Да, у нас даже сервисы на Julia есть. Все зависит от того, что лучше подойдет для задачи, которую мы пытаемся решить. Кир Интересно. То есть, как я понимаю, вы мигрировали с монолитного Rails приложения, да? Эрик Да! Думаю, многие компании, когда они развиваются и начинают масштабироваться, переходят с такой монолитной архитектуры приложения на архитектуру микросервисов. И да, мы довольно далеко в этом деле продвинулись. Кир Ясно. Давай поговорим про open source, над которым ты работал — какой проект твой любимый? Эрик Ох, их много — сложно выбрать. Не знаю, некоторые обертки над API, над которыми я работал — таких было несколько.. Я сделал octokit, обертку над API GitHub; еще обертку над API RubyGems.org, чтобы можно было доставать метаданные о gem'ах. Ну и, наверное, самая популярная обертка, которую я сделал — gem twitter. Да и gem soundcloud, я его сейчас поддерживаю, но автором был не я. Да, думаю, решать проблемы такого рода, причем несколько раз для разных сервисов, стало таким неплохим шаблоном, так что я горжусь теми gem'ами. Думаю, приемы работы над кодом, которые я использовал там, приводят к коду довольно чистому, хорошо покрытому тестами, и все такое. И, знаешь, наверное самый популярный мой gem — это rails_admin, там код и близко не такой чистый, так что для меня над ним не так приятно работать по этой причине. Каждый раз, когда с ним работаю, всегда нахожу какие-то вещи, которые стоит зарефакторить; но раз уж столько людей его используют, просто приятно было сделать что-то такое — люди постоянно ко мне подходят, благодарят. Так что им приятно заниматься по другой причине — не из-за красоты кода, а из-за пользы, которую он дает. Кир Понятно. А что вообще помогает тебе работать над новыми open source проектами? Эрик Ну, думаю, как и у всех — главная причина, наверное, в том, что когда я использую какой-то проект и нахожу баг, я вкладываюсь в проект просто чтобы пофиксить этот самый баг, или просто в какой-то степени этот проект улучшить. Иногда я начинаю проекты только затем, чтобы чему-то научиться — попробовать в деле новый фреймворк или новый язык; да, в общем, получается такое игрушечное приложение или игрушечная библиотека, и тогда нет причин не выпустить этот код как open source, чтобы другие люди могли учиться так же, как учился я, или научиться чему-то на моих ошибках. Да я и сам учусь на своих ошибках, потому что когда ты выпускаешь что-то как open source, другие люди видят твою работу, присылают пулл-реквесты, чтобы ее улучшить, и каждый раз, когда это происходит — это возможность мне чему-то научиться; другие же люди это увидят и тоже сделают какие-то выводы для себя. Кир Точняк. Ты упомянул, что в SoundCloud используется много разных языков, так вот, есть у тебя какой-то open source не на Ruby? Эрик Да, у нас есть. Кир Scala, Clojure? Эрик Да-да. Посмотри на https://github.com/soundcloud, думаю, у нас там больше сотни публичных репозиториев. И да, там есть проекты на Ruby, наш самый популярный — Large Hadron Migrator, LAM (https://github.com/soundcloud/lhm). Там идея в том, что если у тебя есть действительно здоровенная база данных (MySQL — прим. пер.), и тебе нужно сделать миграцию, с помощью этого проекта можно это сделать без даунтайма. Если на пальцах, он работает вот так: копирует таблицу, прогоняет миграцию на копии, потом на копию переносит все данные, которые скопились с момента начала миграции. Довольно эффективный способ делать миграции в БД. Нам этот проект был реально нужен, у нас были очень большие таблицы в MySQL, на которых нужно было делать миграции, а если мы делали обычные миграции, мы могли попасть на несколько часов даунтайма. Так что мы сделали такой вот инструмент. Другие компании, у которых тоже было много строк в таблицах их баз данных, большие таблицы, и нужно было делать миграции над ними, тоже оценили наше решение. Кир На каком это языке? Эрик На Ruby. Так что да, это в основном для миграций с Rails. Но у нас.. Если посмотреть на https://github.com/soundcloud, у нас есть репозитории почти на всех языках, что можно представить — Ruby, Clojure, Scala, Go.. Как я уже говорил, у нас есть код на Julia, думаю, мы его тоже выложили. Да, ну и на других языках. В SoundCloud мы гордимся тем, что всегда используем лучший инструмент для каждой конкретной задачи, а инженеры принимают решения основываясь на том, что по их мнению лучше всего использовать. Так что если давать инженерам автономию для принятия решений, последуют лучшие решения, чем если в компании просто есть правила — «использовать один язык для всего», или «использовать этот фреймворк для всего». И даже внутри нашей организации, мы иногда используем Rails, иногда Sinatra или другие фреймворки. Это действительно зависит только от характера проблемы, которую мы пытаемся решить. Кир Какое будущее у Ruby, по твоему мнению? Эрик Хм. Хороший вопрос. Надеюсь, что будущее будет таким же, как и прошлое — за последнее время каждый год выходит новая версия Ruby, и каждый раз она быстрее и лучше предыдущей. Так что да, надеюсь, такое продолжится в будущих версиях. Что я действительно хотел бы видеть (я упомянул об этом в своем докладе), так это JIT компилятор в MRI (CRuby). Кажется, над этим уже работают, так что я настроен оптимистично — думаю, скоро мы это увидим. Так же, как и AOT компилятор. Я еще работаю над парой интерфейсов для командной строки; Ruby не очень хорош для работы с командной строкой, потому что время запуска может быть большим, а вот если был бы компилятор, который бы предварительно парсил весь Ruby код в бинарник, было бы круто — особенно для штук вроде CLI (Command-Line Interface — прим. пер.). Так что вот, JIT и AOT компиляторы. И еще получше примитивы для параллелизма. Матц говорил, что он сожалеет о решении использовать Thread как главный примитив для параллелизма в Ruby, так что он вместе с Core Team думает над использованием actors, и может каких-то еще примитивов. Чтобы они появились в core библиотеках языка. Так что я этого очень жду, думаю, будет круто. Кир Да, я заметил тренд с переписыванием инструментов командной строки на Go. Эрик Да, точно. Кир Вот Heroku так делает. Эрик Да, это хороший пример. Их CLI для выполнения разных команд, раньше был на Ruby, но, вообще, думаю, он намного лучше стал на Go, по ряду причин. Во-первых, у Go весь runtime включен в бинарник, так что нет такой зависимости, как Ruby — не надо сначала устанавливать Ruby, а потом уже CLI. Можно просто установить бинарник, в котором все уже есть. Ну и то еще, что можно кросс-компилировать сразу на несколько разных платформ, делает разработку инструментов для командной строки намного проще. И вообще тот факт, что Go — язык компилируемый, означает, что никакой подготовки кода во время запуска нет, как в Ruby. Так что если есть, скажем, 30 библиотек, от которых зависит инструмент, то в Ruby даже для самой простой операции сначала нужно пропарсить все эти библиотеки, а это может занять много времени, особенно если нужно выполнить какую-то простую команду — такую, как help, version или что-то такое, и во многих CLI на Ruby это работает куда медленнее, чем должно бы. Так что AOT компилятор существенно этому поможет, Ruby сможет составить конкуренцию языкам вроде Go в борьбе за CLI. Кир Давай поговорим о Берлине. Эрик Ага. Кир Что ты думаешь о стартап-культуре, об атмосфере? Эрик Очень хорошая. Я переехал в Берлин из Сан-Франциско, где я до этого прожил 8 лет. И в Сан-Франциско чувствуется такое отношение, словно это единственное место в мире, где можно сделать стартап, и что если тебе нужно сделать стартап, то нужно переехать в Сан-Франциско, если хочешь добиться успеха. Это сработало для многих компаний, но в SoundCloud нам этого делать не пришлось. Есть много преимуществ работы в Берлине. Главное преимущество — мы можем нанимать талантливых людей со всей Европы, да и со всего мира, вообще говоря. У нас отличный офис, где есть разработчики из.. кажется, 35 разных стран, или вроде того. Думаю, эмиграционные законы США делают такое куда более сложным. У меня был такой скепсис, когда я переезжал из Сан-Франциско, но.. Мои коллеги — невероятно талантливые люди, я каждый день у них чему-то учусь. Да, Берлин — отличное место для работы. И стартап сцена — не только SoundCloud, у нас куча других стартапов! От самых маленьких, где пара человек работают над какой-то идеей, до людей, которые уже подняли венчурный капитал и теперь быстро растут. Да и просто классное сообщество и отношение. Митапы каждую неделю, наверное, даже каждый день — можно ходить на разные технарские митапы в Берлине. И вот что еще круто в Берлине: классное сообщество для тех, кто хочет учиться. То есть, если вы хотите научиться программированию, или если вы пока юниор, и вы ищете возможность подкачаться, Берлин — отличное для этого место. Вот Rails Girls начинались не в Берлине, но благодаря Travis CI, да, там много классных людей — Свен (Sven Fuchs — прим. пер.), Аника (Anika Lindtner — прим. пер.), да и вся команда — Джош (Josh Kalderimis — прим. пер.), Константин (Konstantin Haase — прим. пер.)… Такое комьюнити они создали! Меня пригласили выступить на Eurucamp пару лет назад — тогда я в первый раз оказался в Берлине, еще до того, как я туда переехал. Перед конференцией я побыл коучем на Rails Girls, и это был первый раз, когда я помогал на Rails Girls, и было круто. Но, думаю, Rails Girls проводятся в Берлине уже очень давно, теперь и Summer of Code проводится оттуда. Есть целые четыре разные команды Summer of Code, которые расположены в Берлине. Так что вот, это отличное место для того, чтобы научиться программированию и прокачаться. Кир Все, спасибо большое! Эрик Да, конечно. Спасибо за вопросы! Интервью с Божидаром Ярослав Привет, Божидар! Как тебе Москва? Божидар Все здорово. Фантастический город, счастлив, что я здесь и что меня пригласили. Это мой первый визит в Россию, для меня все в новинку и очень увлекательно. У вас прекрасный город, прекрасная страна. Ярослав Первый вопрос будет про Rubocop. Многие из наших ребят знают о gem parser нашей местной знаменитости, Петра (Зотова — прим. пер), который, кстати, выступал в прошлом году на этой самой конференции. Можешь рассказать немного о том, как parser и Rubocop работают вместе? Божидар Да, конечно. Когда я начал работать над Rubocop, я использовал Ripper, внутренний парсер MRI, у которого есть две фундаментальные проблемы: во-первых, он работает только с MRI, что сделало бы Rubocop несовместимым с JRuby и Rubinius. Во-вторых, он генерит ужасный AST. Я пытался отправить несколько багфиксов в Ripper, но стало понятно, что это ни к чему не приведет. В одном из сообщений об ошибке, которое я открыл на официальном багтрекере Ruby, кто-то упомянул, что мне лучше бы не использовать Ripper вообще, потому что есть новая библиотека под названием parser от Петра. Я ее посмотрел, она работала замечательно, выдавала отличный формат AST, в общем, делала ровно то, что нужно. Была переносимой, правда очень глючной, но я намеревался работать с ней, несмотря на это. В основном из-за Петра, отличного мейнтейнера. Я зарепортил, наверное, около 50 багов, или вроде того. И он обычно отвечал в течение пары часов. После того, как вышла первая версия Rubycop с использованием parser, обнаружилось еще больше багов — пользователи умудрялись писать такой Ruby код, что мы даже не знали о том, что так можно написать. Но в течение следующих релизов Петр все исправил, и я уверен, что это лучшая библиотека из тех, что существуют. Производительность отличная, почти так же быстро, как и с Ripper, но выдаются структуры данных намного проще, с этим намного приятнее работать. Если мне бы пришлось работать с Ripper, я бы, наверное, забросил Rubocop. Ярослав Мы говорим о Ripper, но ведь еще есть gem.. как его.. Божидар ruby_parser? Ярослав Да, ruby_parser. Божидар Да, проблема с ruby_parser была в том, что его не мейнтейнили особенно. Думаю, Петр изначально хотел улучшить ruby_parser (так и было — прим. пер.); он был совместим с Ruby 1.8, но не обновлялся для 1.9. Я видел от него несколько пулл-реквестов, но ребята, которые мейнтейнили ruby_parser, сказали, что изменения слишком сложные, или что-то в этом духе, и что они не будут их применять. Думаю, это и было мотивацией для Петра сделать новый gem. И еще дело было в том, что ruby_parser не был так производителен, как parser, так что при работе с огромными проектами это могло стать проблемой — можно было ждать целый час, пока идет анализ кода. Ярослав Ага. Следующий вопрос про твою самую известную работу — Ruby Guide. Можешь рассказать о процессе, о том как ты работаешь над ним? У тебя просто появился набор каких-то правил, ты сделал первый коммит и потом ты начал их обновлять? Как ты итерируешь, как обновляешь эти правила? Думаешь ли ты, что многие из них обязательные, или какие-то нет? В общем, твой Ruby Style Guide и Rails Style Guide не высечены в камне, они обновляются, так что хочется послушать про процесс. Например, как ты их валидируешь. Божидар Ну, обычно я делаю что-то, что называю проверкой толпой (Crowd Validation). Я добавляю правила иногда, когда натыкаюсь на хорошие идиомы в книгах, докладах; встречаю что-то, чего я раньше не замечал. Если я делаю правки и они не вызывают существенной негативной реакции в сообществе, значит, это и правда хорошая рекомендация. Если я что-то добавляю и все начинают на это жаловаться, значит, я сделал ошибку. Если мнения разделяются, мы начинаем вдаваться в детали. Например, мы делаем поиск по ruby-исходникам на GitHub, и если мы видим, что недавно добавленное или предложенное правило имеет смысл, если большинство отобранных проектов используют это правило, иначе мы его убираем, или правим существующее правило. Это уже много раз случалось. Но, в конце концов, кто-то должен проталкивать эти правила — обычно это не только я; можно видеть, что довольно много людей предлагают новые правила. Но я всегда стараюсь делать проверку, чтобы быть уверенным, что мы не предлагаем что-то, что нарушает сложившиеся практики. Так что если что-то звучит как хорошая идея, но никто ее не придерживается, мы не будем ее рекомендовать. Мы не хотим заставлять кого-то следовать стилю, который не принимается, не является естественным для Ruby сообщества. Ярослав Ясно. А ты начал с своего собственного набора правил, или ты использовал другие источники для вдохновления? Божидар Я начал с правил, которые я собрал из моих любимых книг по Ruby. В основном.. Моя любимая книга по Ruby — это, наверное, “The Ruby Programming Language”.. Ярослав Pickaxe? Божидар Не-не. Это “Programming Ruby”. Ярослав А, другая. Божидар Да. Так вот, я начал с советов из «Библии», то есть, единственной книжки, написанной самим Матцем, по крайней мере, частично. Я детально сверил стиль, который он использует, со стилем, который используется в Pickaxe. Были некоторые различия в верстке кода, например, Матц не использовал столько пустого места, отбивок, как использовал Дейв Томас, а я люблю читаемый код. Так что я взял у Дейва стиль для таких случаев. После этого, я начал добавлять вещи из “Eloquent Ruby”, “The Ruby Way” — книг, которые я считаю каноническими для сообщества. Так что начинал я оттуда, а после первого публичного релиза гайда, я получил массу отзывов — часто с приложенным анализом использования из поиска по GitHub, о котором я уже говорил. Например, все книги утверждали, что стоит избегать использования тернарного оператора, а использовать вместо него if/then/else в одну строку, но оказалось, что ни в одном Ruby проекте такого нет, наоборот, все используют тернарный оператор. Да, так что если люди хотят писать код так, кто я такой, чтобы им запрещать. Так что мы изменили это правило, да и другие правила тоже подверглись изменениям с изначальной версии. Мы обновляем правила все время. Например, когда все начиналось, еще не было Ruby 2.0 и 2.1, так что не было правил о аргументах-ключсловах (keyword arguments), использованию private на той же строке, что и определение метода, потому что это не имело смысла. Но гайд постоянно развивается, и, думаю, чем больше проходит времени, тем больше мы приближаемся к настоящей душе Ruby-стиля. Ярослав Я спрашивал, потому что еще до того, как я увидел твой гайд, был гайд от Кристиана, автора Rack (https://github.com/chneukirchen/styleguide — прим. пер.). Видел его? Божидар Да, видел. Ярослав Я его использовал неоднократно для обучения внутри команды, и только потом увидел твой гайд, который намного больше и подробнее. Божидар Да, я проводил поиски по гайдам. Я видел этот, видел веб-страницу, не помню URL, что-то от zenspider, наверное. Я видел три ресурса, но во всех отсутствовали примеры. Были правила, но без объяснений о том, почему это вообще хорошая идея. Некоторые правила были явно в противоречии с устоявшимися практиками. Это все были попытки, предпринятые одним человеком, больше похожие на личный набор правил. Вместо чего-то, что могло бы использоваться всеми, что и было моей целью. Потому что изначально я занимался документом по заказу компании. И мой проект случайно стал популярным. Ярослав Еще что хочу спросить о твоих гайдах. В каком-то смысле использование гайда по стилю — это как принятие методологии разработки ПО, методологии гибкой разработки ПО, например. Это много как можно сделать — кто-то делает все в точности по правилам, по книге, кто-то начинает использовать некоторые вещи и модифицирует их потом, и получается его собственная методология, и все такое. То есть, одни люди пишут книги, а другие люди просто используют их, как им заблагорассудится. Так как ты думаешь, как лучше всего применять твой гайд, или, может быть, как ты сам его применяешь на своих проектах, когда работаешь консультантом? Ты заставляешь людей ему следовать, или это процесс, шаг за шагом? Божидар Ну, обычно на моих проектах, Ruby Style Guide в его чистой форме дается как правило. Но это правило лишь до какой-то степени; некоторые правила абсолютны — например, не нужно мешать метод и его алиас в проекте, нужно выбрать одно название и использовать его везде. Правила про отступы тоже абсолютны, но, с другой стороны, у нас есть вещи вроде правил по метрикам: короткие методы, короткие классы, и вот они иногда довольно субъективны, нужно идти на нарушение правил: как ни старайся, иногда нельзя раздробить какую-то задачу на больше частей, чем ты уже сделал. Есть точка, после которой попытки упростить что-то просто вредны: больше это не оптимизация, ты уже делаешь код сложнее. Так что.. Есть другие такие правила, которые не следует применять вслепую.. Нужно думать. Я всегда говорю людям: это не десять заповедей, ниспосланные нам свыше. Многие из них — крайне разумные практики, и ничего плохого от их применения не случится, но нужно знать, когда их нарушать, и нужно знать, почему они были хорошей идеей изначально. Не нужно их нарушать, если нет четкой причины это делать. Ярослав Еще вопрос. Посмотрел на твой профиль на GitHub, и оказывается, что ты интересуешься Clojure. Божидар Да-а-а. Ярослав И у тебя даже гайд по стилю для Clojure есть. Не знал раньше. Так вот, в Ruby сообществе много разговоров идет.. В общем, на каждой Ruby конференции по крайней мере в России есть много людей, которым вообще не интересно разговаривать про Ruby, они хотят говорить про Clojure, Scala, функциональные языки, Elixir тоже популярная тема. Так вот, почему именно Clojure? Божидар Ну.. По той же причине, по которой я изначально выбрал Ruby. Я был очарован простотой и мощью языков из семейства Lisp. Когда я был начинающим программистом, я немного писал на Common Lisp. И потом я наткнулся на Ruby, и, хотя он не был Lisp'ом, очевидно, но в нем было много наследия Lisp. И это был язык, для работы на котором я хотя бы нашел людей, готовых мне заплатить. Rails был на волне, все хотели разрабатывать на Rails, веб. Это был хороший компромисс. Но сейчас есть Clojure, настоящий Lisp, со всей мощью, без ограничений Ruby. Все говорят о проблемах с производительностью Ruby, но, думаю, что есть ряд проблем, для которых объектно-ориентированный подход становится «бутылочным горлышком» в архитектуре. Ты сказал об Elixir, еще одном не-ООП языке, который недавно стал набирать популярность. Люди делают на нем классные вещи. Haskell становится популярным после того, как существовал уже 20 лет. Ярослав Да, но есть много людей, которые называют его академическим языком — в противовес Erlang и Clojure. Божидар Ну да, но нельзя отрицать и то, что количество open source проектов, использующих Haskell, выросло в 4 раза за последние пару лет. Не думаю, что люди занимаются на Haskell только исследованиями. Люди используют его для реальной, полезной работы. Есть известные веб-фреймворки для Haskell, его точно используют для решения реальных проблем, а не вычисления чисел Фибоначчи. Так что думаю, что с тем, как мультиядерность становятся нормой, языки, которые могут масштабироваться, языки, на которых можно строить распределенные системы, будут становиться все более и более популярными. А Ruby придется развиваться быстрее, или он потеряет в популярности. То, о чем ты говоришь — что люди на Ruby-конференциях здесь не хотят говорить о Ruby — это не случайность. Если посмотреть на Ruby-конференции в Штатах, например — всегда есть доклады об альтернативных языках. На последней конференции был доклад по Elixir, перед этим Рич Хики собственной персоной докладывался по Clojure на RubyConf (думаю, речь идет о RailsConf'2012 — прим. пер.), а это что-нибудь да значит. И еще нам нужно иметь в виду, что многие известные рубисты забросили Ruby и стали работать на других языках. Например, Аарон говорил о Хосе Валиме.. Ярослав С которого и начался Elixir, ага. Божидар Да. Я почти уверен, что ему Ruby уже не интересен — да, его компания известна среди рубистов, он все еще мейнтейнер Rails и сопутствующих проектов, что нужно для клиентов, но его настоящая страсть — Elixir. Он об этом сам несколько раз говорил. Был еще известный рубист, Фил Хагельберг (@technomancy — прим. пер.), сейчас он один из самых известных кложуристов. Ярослав Да, но он всегда был поклонником Emacs, и поклонником Lisp. Он был главным источником всего, что в Emacs было связано с Ruby. Все люди, которые начинали с Lisp в университете или школе, которые хакали на Emacs долгое время.. У них теперь время возмездия. Божидар Да, но думаю, что Ruby-программистов привлекает мощь всех этих новых альтернативных языков. Думаю, некоторые из хороших идей этих функциональных языков рано или поздно окажутся в Ruby. Я говорил об идее сделать строки иммутабельными, не уверен, как это можно сделать, учитывая что весь код, который зависит от строк, мутабелен, но люди говорят о персистентных структурах данных в Ruby. Матц говорил, что главная фича в Ruby 3.0 — фреймворк для параллелизма, видимо, похожий на actors. Весь мир ПО движется в этом направлении; нельзя отрицать и то, что нельзя бесконечно делать веб-приложения. Ландшафт рынка веб-приложений существенно изменился. Rails стал популярным, когда все веб-сайты были довольно стандартными. Была довольно статичная прослойка для представления, довольно простые модели. И сейчас все дошло до клиентских приложений, когда весь твой фронтенд — это отдельное приложение, а твое Rails-приложение — просто JSON-сервер. И ты начинаешь спрашивать себя — а нужен ли мне Rails только для JSON сервера? Почему бы мне не сделать приложение на чем-то высокопроизводительном — Java, Erlang? Потому что если избавиться от тесной интеграции представлений-моделей в Rails, его ценность резко уменьшается. Думаю, что мир ПО изменяется очень быстро, и сообщество Ruby и Rails должно реагировать мгновенно, или сгинет в геенне огненной. Как и много других классных технологий. Ярослав Депрессивно, но справедливо. Еще вопрос, чтобы не очень долго тебя задерживать. Очевидно, написание правильного Ruby — очень важная тема в эти дни. Ruby вырос, люди должны перестать делать отстойные приложения, чтобы их было проще поддерживать. Один из докладчиков на этой конференции — удаленный докладчик, правда — Сэнди Метц, она тоже рассказывает о способе писать на Ruby правильно, но она делает это с помощью книги. Вот. А у тебя есть гайд, с пятью тысячами вотчеров, кажется, на GitHub, огромное число, я точно не помню, но это все-таки open source проект, у него есть URL, надо ему поставить звездочку. Так вот, есть планы написать книгу? Божидар Да, я об этом говорил на докладе. Я запланировал написать книгу, но потом я стал мейнтейнером Cider, это IDE для Clojure, очень популярная. Пришлось много с этим работать, и это выкачало из меня все силы, которые я откладывал на Rubocop, Ruby Style Guide, Rails Style Guide, и вообще на все связанные с Ruby проекты, потому что очень уж я вдохновлен Clojure. Но моя работа с Cider сейчас в таком состоянии, что я ей более или менее доволен, так что я думаю, что продолжу там, где я остановился. И сделаю маленькую книгу, очень маленькую книгу. Но, думаю, будет здорово, если у всех правил будут описания побольше, примеры подлиннее. В Styleguide я этого сделать не могу — это как README длиной в 50 страниц, это было бы странно. Но, думаю, небольшая книга будет полезна многим. Ярослав Ну что же, удачи в написании книги. Спасибо, что зашел! Божидар Вам спасибо. Мы выражаем огромную благодарность Стасу Спиридонову за помощь с мастерингом этого выпуска.

本期由Terry Tai主持，邀请到了国内著名的 Common Lisp 程序员，实用 Common Lisp 编程 一书的译者田春(冰河)，和我们一起聊聊 Lisp 的方方面面, 揭开 Lisp 的神秘面纱。 实用Common Lisp编程 KnewOne Solaris Studio On Lisp ANSI Common Lisp Common Lisp the Language, 2nd Edition SICP S-表达式 Simple Network Management Protocol SourceForge cl-net-snmp Racket Scheme Common Lisp HyperSpec LispWorks SLIME Hunchentoot Quicklisp Clojure Paul Graham Arc Hacker News LALR parser Rich Hickey ABCL yacc FileMaker Pro FrameMaker InDesign DocBook LaTeX The Little Schemer Paul Graham Special Guests: 李路 and 田春(冰河).

Новости Rear admin Сканер уязвимсотей для RoR Прямой аплоад файла на nginx Ставим рельсы на убунту с нуля RubyMine со скидкой Gem отучался shound_not Обновление сайта _why-я Объяснение на пальцах фичи Ruby 2.0 Enumeration#lazy Пиши на Ruby правильно Passenger 4.0 RC6 Ruboto 0.11.0 Кеширование методов в Ruby и патч от Джеймса Голика Обсуждение Интервью с Андреем Руденко Твиттер Андрея Github нашего гостя Compojure Книга Land of Lisp Common Lisp в Wikipedia Официальный сайт языка Clojure Ring Редактор Emacs Редактор Light Table Текущая работа Андрея Clojure Core Статья с разной статистикой про Clojure Книга SICP Выступление Ричи Хики на QCon Выступление Ричи Хики