Lisplog

Blogging in Lisp

Search

Feed Aggregator

Rendered on Wed, 22 Nov 2017 14:32:29 GMT  newer latest older 
Next udpate: Wed, 22 Nov 2017 15:00:00 GMT feeds

Nicolas Hafner: Harmony - Confession 77

via Planet Lisp by on Wed, 15 Nov 2017 15:56:28 GMT

header
This is a blog entry about Shirakumo's sound system Harmony. While Harmony was released some months back, I spent the last few weeks rewriting large parts of it from the ground up, and I think it's worth it to write a short article describing how it's built and what you can do with it. So, if you're interested in doing sound processing and playback in Lisp, this is for you.

The need for Harmony arose out of me not finding any suitably powerful sound solution in Lisp. I tried doing a pure Lisp solution at first, but was not able to figure out how to make things go fast without sacrificing design. So, in the interest of performance, I first set out to write a C library that does the essential sound computations for me. This library is called libmixed.

I wanted to keep libmixed as simple and straight-forward as possible. As such, it does not do any sound file reading or writing, synthesising, or sound output to devices. Instead, it only concerns itself with the processing of sound samples. Another important factor for its design was that it should be easy to extend it with further capabilities, and to allow combining processing steps. This led to the segment pipeline model.

In libmixed, you assemble a set of segments - audio producers, consumers, or transforms - that perform the computations you need. You connect them together through buffers so that they can transparently exchange audio data. This produces a directed, acyclic graph where each vertex is a segment, and each edge is a buffer. This graph can then be serialised into a simple sequence that dictates the order in which the segments should be run.

Unfortunately, audio data comes in a variety of formats. Samples are frequently encoded as signed or unsigned integers of 8, 16, 24, or 32 bits, or in floats or doubles. The data might have multiple audio channels, and the samples can be either interleaved (LRLRLR..) or sequential (LLL..RRR..). The sample rate might be different as well. All of this can make it quite difficult to deal with the data between different audio components. Libmixed's solution to this problem is to force all the buffers to use the same sample rate, to encode samples in floats, and to only represent a single channel. Almost all segments present in a pipeline thus don't have to worry about any of these discrepancies anymore, reducing complexity tremendously. In order to allow interacting with foreign components easily, it does also include an unpacker and a packer segment.

The packer takes a set of buffers and information about the sample representation, and packs the buffer's data into a single C array, ensuring proper sample format, layout, and sample rate. The unpacker does the opposite. Thus, if for example you have a library that decodes an audio file, you most likely need to add an unpacker segment to the pipeline that decodes the audio data from the library into the proper internal format.

So, for a very simple example of taking two audio files, mixing them together, applying a reverb effect, and then playing them back, the pipeline would need to look something like this:

simple pipeline

We can get away with assigning the same two buffers for both of the unpackers here by using a special property of the basic-mixer segment. Instead of manually processing the two unpackers in our pipeline, we can set the segment property on the basic-mixer's inputs, which tells the basic-mixer to cause the processing on the segment on its own. This way, the mixer can process the segment that produces the input as it mixes it together, reducing the need to allocate individual buffers for each input to the mixer. This is one of the design decisions that still bother me a bit, but I found it necessary after discovering that I would otherwise need to allocate a huge amount of buffers if I wanted to allow playback of a lot of sources simultaneously.

As it currently stands, libmixed includes segments to mix audio by either just adding samples, or through 3D spatial positioning of the source. It also includes segments to change volume and pan, to fade in and out, to generate simple sawtooth, square, triangle, or sine waves, and to include LADSPA plugins in the pipeline. I'd like to add a bunch more effects segments to it to make it more useful for real-time sound processing, but I haven't felt the motivation to get into that yet. If you're interested in sound processing and would be willing to do this, let me know!

Basically the idea of libmixed boils down to this: there's segments that have properties, inputs, and outputs. You can write and read properties, and connect buffers to the inputs and outputs. You can then tell the segment to process a number of samples, and it will read its input buffers, and write to its output buffers. This all works over a struct that contains a bunch of function pointers to perform these actions. It is thus very easy to add further segments to libmixed, even as an outside library: simple produce a struct that holds the appropriate function pointers to the functions that do what you want. This is also how cl-mixed allows you to write segments from Lisp out.

Ascending from the C world to the C+L world then leads us to cl-mixed, which is the bindings and wrapper library for libmixed. It takes care of all the hairy low-level stuff of interacting with the C library, tracking and allocating foreign memory, and so forth. As mentioned, it also gives you a simple interface to write your own segments from Lisp. This can be really nice in order to prototype an effect.

While libmixed is a neat framework to base your sound processing around, it doesn't exactly make most of the common tasks very convenient. Usually you have some audio files that you would like to play back, and maybe apply some effects to them. This is where Harmony comes in.

Harmony takes libmixed's generic view of segments and extends it to include sources, drains, and mixers. Sources are segments with no inputs, drains are segments without outputs, and mixers take a run-time variable number of inputs. It also greatly simplifies the pipeline construction by handling the buffer allocation for you. It does this with the help of a graph library called Flow. More on that later. Harmony also gives you a sound server object that handles the mixing in the background, allowing you to focus on just adding, removing, and changing sources in your program. Finally, Harmony includes a number of pre-made sources and drains that either connect to other libraries, or present native implementations. Currently, it supports playing back MP3, WAV, FLAC, and raw buffers, and supports outputting to out123, OpenAL, WASAPI, CoreAudio, ALSA, PulseAudio, and to raw buffers.

The easiest way to get started is to use the harmony-simple system, which assembles a default pipeline for you, allowing you to just directly play some stuff.

 (ql:quickload :harmony-simple)
 (harmony-simple:initialize)
 (harmony-simple:play #p"my-cool-music.mp3" :music)
 (harmony-simple:play #p"kablammo.wav" :sfx)

Assembling your own pipeline isn't very difficult, though. It comes down to just telling Harmony how to connect the inputs and outputs between segments. An optimal buffer layout is automatically computed based on the segment's properties and the graph that you describe through the connections. To do this, Harmony uses the Flow library to describe segments in a graph. Unlike most graph libraries, Flow assigns distinct input and output ports to each vertex. These ports have properties like their arity, direction, and so on. For instance, the basic-mixer from the previously illustrated pipeline would be a vertex with an input port of arbitrary arity, and two output ports of single arity. Flow then employs a simple algorithm to assign colours to the edges in such a way that no input is connected to the same two colours, and no input and output on a vertex have the same colour unless the vertex is marked as in-place. This kind of allocation computation has cropped up in a couple of places, so I've been able to use Flow for it in other projects as well. I don't think it's important to know how the algorithm works, but in case you're interested, the source is commented and pretty short.

How to write new sources and segments, or how to assemble your own pipeline is already illustrated pretty succinctly in the documentation, so I suggest you check it out if you're interested in working on that kind of thing. Harmony is primarily geared towards use in games, where simple pipelines and immediate playback of a variety of audio sources is necessary. However, I can also see it being used in some kind of digital audio workstation, where a graphical user interface could allow you to put together segments and configure them, mapping to a libmixed pipeline underneath.

I feel like I've been rambling about tangents for a bit here, but I suppose the reason is that Harmony doesn't really do all that much. At best it just smooths over the last remaining corners that come from the libmixed C heritage and adds some useful segments to the library. All the concepts used and all the sound technology behind it lies more in libmixed's hands though, and I think I've already explained that all earlier.

So, to close off: if you're thinking of doing some kind of digital audio processing in Lisp, keep Harmony and cl-mixed in mind. I'm also more than open to feedback and suggestions, so if you have any ideas or things you'd like to add to the projects, head on over to GitHub's issues, or talk to us on Freenode/#shirakumo.

Remote work is here to stay. Be good at it.

via DockYard blog by Maria Matveeva on Wed, 08 Nov 2017 00:00:00 GMT

Here's what I learned in a year of full-remote.

Designing for PWAs without the Back Button

via DockYard blog by Maria Matveeva on Mon, 06 Nov 2017 00:00:00 GMT

Design Forward

Quicklisp news: October 2017 download stats

via Planet Lisp by on Mon, 06 Nov 2017 13:05:00 GMT

Here are the top 100 projects from Quicklisp for October, by "raw" download count.

16626  alexandria
15213 closer-mop
13436 anaphora
13420 split-sequence
12954 babel
12879 trivial-features
12719 iterate
12464 cl-ppcre
11798 bordeaux-threads
11724 let-plus
11693 trivial-gray-streams
11389 cffi
11281 trivial-garbage
10622 puri
9884 nibbles
9732 more-conditions
9611 flexi-streams
9026 usocket
8602 cl+ssl
8544 utilities.print-items
8153 cl-base64
8130 chunga
7889 chipz
7791 drakma
7691 esrap
7635 trivial-backtrace
6308 ironclad
5910 cl-yacc
5691 cl-fad
5302 parse-number
4996 named-readtables
4984 fiveam
4959 asdf-flv
4886 log4cl
4756 bt-semaphore
4736 local-time
4701 lparallel
4647 closure-common
4638 cxml
4594 architecture.hooks
4552 lift
3784 plexippus-xpath
3586 cl-json
3569 trivial-utf-8
3322 optima
3157 parser.common-rules
3144 cl-clon
2837 uuid
2819 cxml-stp
2705 xml.location
2700 metabang-bind
2624 cl-dot
2475 utilities.print-tree
2473 slime
2458 cl-unicode
2456 cl-interpol
2273 md5
2267 cl-store
2232 fare-utils
2204 fare-quasiquote
2108 inferior-shell
2105 fare-mop
1769 cl-utilities
1706 quri
1671 ieee-floats
1625 static-vectors
1605 fast-io
1547 trivial-types
1545 cl-annot
1536 cl-syntax
1437 utilities.binary-dump
1431 trivial-indent
1364 trivial-mimes
1335 asdf-system-connections
1334 array-utils
1329 symbol-munger
1320 cl-containers
1318 metatilities-base
1318 plump
1302 cl-slice
1296 hunchentoot
1280 access
1267 arnesi
1266 collectors
1258 gettext
1236 djula
1226 cl-parser-combinators
1221 cl-locale
1187 postmodern
1164 rfc2388
1159 yason
1121 simple-date-time
1050 command-line-arguments
956 cl-sqlite
951 cl-log
947 osicat
943 salza2
913 py-configparser
903 cl-markdown
903 asdf-finalizers

iPhone X Ad Swirling Colorful Sand

via Lisplog by on Sat, 04 Nov 2017 04:09:03 GMT

I finally found the artists responsible for the swirling colorful sand animation in the "iPhone X Is Here" ad.

It's WeAreColorful. There's a contact form at the bottom of that page. If enough of us ask them to package it as an app, for a dollar, maybe they'll do it.

https://youtu.be/wmEqgjT61FA

Feature Test with Headless Chrome and Capybara

via The Oozou Blog - Medium by Tino Thamjarat on Fri, 03 Nov 2017 05:03:26 GMT

Capybara is so cute ❤

Capybara is one of the most popular feature testing framework in the Ruby on Rails community. I’ve been pretty happy using it with headless browser like PhantomJS.

However, Google recently released Headless Chrome with their 59 version of it’s Chrome browser and it’s performance is really impressive. I decided switch to it on my current project and updated my Capybara configuration to supports it and have been really satisfied with the performance improvement.

ChromeDriver installation

Running your feature specs requires you to install Chrome (v59 and above) and ChromeDriver (v2.30 and above). For MacOs user, you can easily install/update your ChromeDriver via Homebrew by running one of these command in your Terminal:

# install the latest version
brew install chromedriver
# update existing chrome driver
brew upgrade chromedriver

You can validate your installation by running:

chromedriver -v
# It should display the latest/specify version like so
#=> ChromeDriver 2.33.506106 (8a06c39c4582fbfbab6966dbb1c38a9173bfb1a2)

Capybara Configuration

I normally put my spec configuration in spec/supports/ and import them in spec_helper so that the configuration file could be named properly and my Capybara configuration is not an exception.

This configuration sets Capybara to use headless_chrome as the default JavaScript driver and opens Chrome browser when the DEBUG is export to your ENV. This also enables you to write feature test for pages that is rendered by React.js which is slick!

CI configuration

If you have the right version of Chrome and ChromeDriver installed on your CI, you should be able to run your tests normally.

For CircleCI users, like me, the current CircleCI machine uses older version of Chrome and ChromeDriver which does not support Headless Chrome.

Has ChromeDriver been updated on the Ubuntu 14.04 (Trusty) image?

To fix this, you need to add a script to remove and reinstall newer Chrome and ChromeDriver. (At least until they update the version)

Wrapping Up

As I told you before, Headless Chrome performance is really satisfying and debugging it with this configuration is a breeze. I really recommend you to try it with your feature spec.

Thank you for reading

My name is Tino Thamjarat. Technical Lead at BASE and Software Engineer at Oozou . I love discussing everything. Business ideas, philosophy, physics, religion, tech, gaming, you name it. I also play League of Legend and a little bit of music once in a while. If you need a website, want to give some advice/comments or just need some guy to talk to, feel free to contact me on my Twitter or Instagram.


Feature Test with Headless Chrome and Capybara was originally published in The Oozou Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Safari just landed Cache Storage API support, another step closer to PWAs on iOS

via DockYard blog by Brian Cardarella on Wed, 01 Nov 2017 00:00:00 GMT

One of the primary underlying technologies necessary to support Service Workers just landed in WebKit Technology Preview 43

Didier Verna: Standard IO syntax and the Robustness Principle

via Planet Lisp by on Fri, 27 Oct 2017 00:00:00 GMT

Here is a flagrant illustration of the robustness principle, or rather, of a failure to honor it.

I was investigating a bug in Declt where some floating point numbers were printed with exponent markers (e.g. 0.5f0 instead of just 0.5) in the Texinfo file, which broke the parsing of the file by Perl.

Eventually, I found out a double infringement of the robustness principle. First of all, Declt failed to comply with part 1 of the robustness principle: be lenient with the others. The Texinfo file generation routine should have been wrapped into a call to WITH-STANDARD-IO-SYNTAX and it wasn't. Always do that to be on the safe side. Lesson learnt.

This failure on my part, however, had the interesting consequence of exhibiting what I consider a serious infringement of part 2 of the robustness principle: be strict with yourself. It would have remained unnocited otherwise. The culprit here is not Declt. This time, it's the common-lisp-stat library. Problem: the simple fact of loading this library globally changes the value of *READ-DEFAULT-FLOAT-FORMAT* from SINGLE-FLOAT (the default) to DOUBLE-FLOAT. This is bad, and it can break your code in all sorts of nasty ways.

Explanation

*READ-DEFAULT-FLOAT-FORMAT* tells the reader how to read floats when no exponent marker is provided. By default, 0.5 will be read as a SINGLE-FLOAT. But this variable also influences the printer (out of a concern for printing readably I guess): when printing a float of a different format than the current default, then the appropriate exponent marker is also printed. So here is precisely what happened. Declt had been compiled with some floats (e.g. 0.5) read as SINGLE-FLOATs. Later on, those floats were supposed to be printed aesthetically as such. But right after loading common-lisp-stat, the default format changed to DOUBLE-FLOAT and all of a sudden 0.5 started to be printed as 0.5f0.

Consequences

This is bad enough already, but consider that messing with the standard IO syntax globally like this can break your code in all other sorts of even nastier ways. Imagine for instance that common-lisp-stat had been loaded before Declt, and Declt needed to be recompiled. All of a sudden, Declt would be using double floats and the bug would be gone. That is, until the next start of the REPL, after which all floats would be printed like 0.5d0!

So granted, my code wasn't robust enough. But please, don't mess with standard IO syntax globally!

Zach Beane: UIOP, sly, and qlt

via Planet Lisp by on Wed, 25 Oct 2017 12:35:01 GMT

uiop

The problem I had with UIOP is due to using stock SBCL ASDF (3.1.5) with UIOP 3.3.0. UIOP changed a public function’s behavior in a way that affected older ASDFs (and seemingly only older ASDFs). This is considered a bug and will be fixed in a future UIOP release.

sly

September of Sly has turned into Season of Sly. I haven’t been hacking as much with Sly as I wanted in September, so I’m going to keep going with it for October and beyond, and write up a summary Very Soon. My current hangup is C-c M-q, which is slime-reindent-defun in slime, but does nothing in Sly, and there’s no sly-reindent-defun to try to bind instead. I try to use C-c M-q a thousand times a day.

qlt

You might know that Quicklisp dists are constructed after building every project that Quicklisp tracks, and projects that don’t build (due to compile-time problems) aren’t included. This is better than nothing, but it does nothing to catch runtime problems.

Last week Quicklisp got hit with a runtime problem that broke a lot of stuff, so it prompted me to create qlt.

qlt is for collecting small files of Common Lisp code to run before a Quicklisp dist is created. If any of the files signal an error, Quicklisp generates a report with the console output and the dist is no-go until the problem is tracked down.

The project is sparse right now, but it does include a test file that catches the runtime problem from last week. I hope to include many more things to test as time goes on. If there is something you want to check, patches welcome!

UIOP, sly, and qlt

via Zach Beane Common Lisp by on Wed, 25 Oct 2017 12:35:01 GMT

uiop

The problem I had with UIOP is due to using stock SBCL ASDF (3.1.5) with UIOP 3.3.0. UIOP changed a public function’s behavior in a way that affected older ASDFs (and seemingly only older ASDFs). This is considered a bug and will be fixed in a future UIOP release.

sly

September of Sly has turned into Season of Sly. I haven’t been hacking as much with Sly as I wanted in September, so I’m going to keep going with it for October and beyond, and write up a summary Very Soon. My current hangup is C-c M-q, which is slime-reindent-defun in slime, but does nothing in Sly, and there’s no sly-reindent-defun to try to bind instead. I try to use C-c M-q a thousand times a day.

qlt

You might know that Quicklisp dists are constructed after building every project that Quicklisp tracks, and projects that don’t build (due to compile-time problems) aren’t included. This is better than nothing, but it does nothing to catch runtime problems.

Last week Quicklisp got hit with a runtime problem that broke a lot of stuff, so it prompted me to create qlt.

qlt is for collecting small files of Common Lisp code to run before a Quicklisp dist is created. If any of the files signal an error, Quicklisp generates a report with the console output and the dist is no-go until the problem is tracked down.

The project is sparse right now, but it does include a test file that catches the runtime problem from last week. I hope to include many more things to test as time goes on. If there is something you want to check, patches welcome!

Work on Web App Manifest in WebKit has Begun

via DockYard blog by Jessica Krywosa on Wed, 25 Oct 2017 00:00:00 GMT

This means we’re that much closer to Safari supporting Progressive Web Applications.

Quicklisp news: October 2017 Quicklisp dist update now available

via Planet Lisp by on Mon, 23 Oct 2017 19:20:00 GMT

New projects:
  • also-alsa — Basic ALSA bindings for Common Lisp — LGPL
  • bitio — A wrapper for octet streams that enable bit level streams. — MIT License
  • cl-lzma — CFFI wrapper around LZMA (de)compressor foreign library — Public domain
  • cl-rules — Simple DSL for rules that can be configured without code — GPL-3.0
  • flac-metadata — A utility for reading metadata embedded in FLAC audio files. — MIT
  • html-entities — A module for encoding and decoding HTML/XML/SGML entities. — MIT License
  • mtif — An interface to the MacOS MultiTouch framework — MIT
  • parsley — A toolset for parsing binary data formats. — MIT
  • quicksearch — Quicksearch searches CL library, and outputs results at REPL. — MIT License
  • skippy-renderer — GIF renderer for SKIPPY — MIT
  • trivial-macroexpand-all — Call each implementation's macroexpand-all equivalent — Unlicense
  • zacl — A layer for loading and running some Allegro CL projects. — BSD
Updated projects3bgl-shader3bmdarchitecture.service-providerasd-generatorasdf-vizaws-sign4camblcavemanceplchirpcl+sslcl-anacl-ascii-artcl-autowrapcl-cache-tablescl-cognitocl-conllucl-enumerationcl-fluent-loggercl-forestcl-formscl-glfw3cl-hamcrestcl-html5-parsercl-i18ncl-ledgercl-mosscl-mysqlcl-ntp-clientcl-oclapicl-one-time-passwordscl-openglcl-pcgcl-projectcl-pslibcl-quickcheckcl-rabbitcl-sdl2cl-sdl2-ttfcl-smtpcl-strcl-yesqlclassimpclods-exportcloser-mopclsql-helperclssclunitclxcodata-recommended-valuesconfiguration.optionscroatoandecltdeedsdendritedeploydexadordirtdoubly-linked-listeasy-routeseazy-projectesrapfare-scriptsfast-iofiascoflac-parserfnfs-utilsfsetfxmlgamebox-dgengamebox-ecsgamebox-frame-managergamebox-gridsgamebox-mathgamebox-sprite-packergenieglophu.dwim.defhu.dwim.partial-evalhu.dwim.presentationhu.dwim.quasi-quotehu.dwim.reiteratehu.dwim.utilhu.dwim.web-serverinquisitorironcladjson-streamsjsonrpckenzolegitlet-pluslichat-serverliblisp-namespacelquerymaidenmcclimmedia-typesmitomito-authmodularize-hooksnew-opninevehoclclopticlopticl-coreorg-davep-dictosicatoverlordparse-floatparser.inipathname-utilsplumppngloadpostmodernpsychiqpzmqqlotqmyndqt-libsqtoolsreadablerestasretrospectiffroanrtg-mathscalplsdl2kitsecret-valuesserapeumshortysimple-inferiorssimple-loggersimple-rgbsnoozespinneretstaplestatic-vectorsstlstumpwmtemporal-functionsthe-cost-of-nothingtrivial-file-sizetrivial-irctype-runix-optsvarjowebsocket-driver.

Removed projects: cl-proj, magicffi, poiu.

Neither cl-proj nor magicffi build for me any more due to foreign library changes. POIU was removed by request of the author.

To get this update, use: (ql:update-dist "quicklisp")

Enjoy!

Software rot and the case for the PWA rewrite

via DockYard blog by Matt Ludwig on Mon, 23 Oct 2017 00:00:00 GMT

Companies that have legacy desktop apps should consider writing the next version of that app as a PWA.

DockYard Built PWA Showcased at Google's Chrome Developer Summit

via DockYard blog by Jessica Krywosa on Mon, 23 Oct 2017 00:00:00 GMT

High Tide was used as the example in 'The New Bar for Web Experiences'

McCLIM: Progress report #10

via Planet Lisp by on Sun, 22 Oct 2017 01:00:00 GMT

Dear Community,

We have many important improvements since the last iteration and even more work is pending. I want to apologise for this late progress report - it has been almost three months since the last update. I'll try to improve in this regard.

Some highlights for this iteration:

  • various utilities have been replaced with alexandria equivalents
  • distinct frames don't shadow *accelerator-gestures* of their children
  • accepting-values refinements - better handling of errors and return values
  • refactor and small fixes of the recording implementation code
  • refinements in class hierarchy for streams, medium and graphics state
  • slider from 30.4.5 spec section has been implemented
  • scrolling implementation refinements
  • tab-layout extension refactor
  • improvements related to drei text editing substrate
  • user manual refinements and improvements of its building scripts
  • improvements related to the PDF backend
  • MOP code has been ported to use closer-mop portability layer
  • numerous editorial fixes in bundled specification sources
  • improvements to format-graph-from-roots
  • better Unicode support in CLX for frame title
  • general code base cleanup to decrease number of warnings during compilation
  • transparency handling in CLX backend and alpha channel support in images
  • small Listener improvements (bug fixes and cleanups)

We want to thank everybody who has contributed to the project (by improving the code base, discussions, issue reporting, providing advice and suggestions, monetary contributions etc). We are especially grateful to the following people: Nisar Ahmad, Alastair Bridgewater, John Carroll, Cyrus Harmon, Philipp Marek, Elias Mårtenson, Piotr Mieszkowski, Jan Moringen, Nick Patrick, Alessandro Serra and last but not least Robert Strandh.

Bounties:

All McCLIM bounties (both active and already solved) may be found here. Default bounty expiration date is 6 months after publishing it (a bounty may be reissued after that time period).

Bounties solved this iteration:

  • [$300] Replace MOP things with closer-mop portability layer
  • [$100] Keystroke accelerators may shadow keys even if inactive

Active bounties ($1800):

  • [$100] drag-test demo: dragging square to the empty position invokes the debugger (new)
  • [$100] Text field pane height is too small, clipping the bottom off characters (new)
  • [$300] Listener: repl blocks when long process runs (new)
  • [$500] Windows Backend
  • [$400] Fix Beagle backend
  • [$150] When flowing text in a FORMATTING-TABLE, the pane size is used instead of the column size
  • [$150] clx: input: english layout
  • [$100] Add PDF file generation (PDF backend)

Our current financial status is $1089 for bounties and $264 recurring monthly contributions from the supporters (thank you!).

I have been asked a question about who decides which issues have bounties on them and how the reward amounts are decided. If anyone has been wondering about the same here goes the answer: issues and prices are based on my subjective opinion indicated by problems users encounter and what I consider being worth putting bounty on it. Note though, that I'm open to suggestions (see the next paragraph). I hope that despite some potential doubts the community is generally satisfied with the progress and decisions we make. If there is some lack of transparency, please let me know what you want to know and I'll do my best to help.

Suggestions as to which other issues should have a bounty on them are appreciated and welcome. Please note that Bountysource has a functionality "Suggest an Issue" which may be found on the bounties page. If you would like to work on an issue that is not covered by the existing bounties, feel free to suggest a new bounty.

If you have any questions, doubts or suggestions - please contact me either by email (daniel@turtleware.eu) or on IRC (my nick is jackdaniel). McCLIM developers and users hang out on #clim IRC channel on Freenode.

Sincerely yours,
Daniel Kochmański

Mind Your Ts and Qs

via DockYard blog by Sean Crickenberger on Thu, 19 Oct 2017 00:00:00 GMT

My decision to apply my talents as a Project Manager at DockYard came down to two simple, yet huge, reasons.

Zach Beane: UIOP 3.3.0 problems

via Planet Lisp by on Wed, 18 Oct 2017 12:59:06 GMT

Ok, here’s something that is causing problems when I build this month’s Quicklisp dist.

UIOP 3.3.0 was recently released, and it’s causing some stuff to apparently compile over and over again. Here’s a real simple thing to try:

$ cd ~/quicklisp/local-projects/
$ curl -O https://common-lisp.net/project/asdf/archives/uiop.tar.gz
$ tar xzvf uiop.tar.gz

Then:

CL-USER> (ql:quickload "circular-streams")

On my setup, I see cffi and babel stuff compiled twice:

To load "circular-streams":
  Load 1 ASDF system:
    circular-streams
; Loading "circular-streams"
[package uiop/package]............................
..................................................
..................................................
[package alexandria.0.dev]........................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package alexandria.0.dev]........................
..................................................
[package impl-specific-gray]......................
[package trivial-gray-streams]....................
[package uiop/package]............................
..................................................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package static-vectors]..........................
[package fast-io].................................
[package circular-streams]..

If I remove uiop-3.3.0/ from local-projects, the output looks like this:

To load "circular-streams":
  Load 1 ASDF system:
    circular-streams
; Loading "circular-streams"
[package alexandria.0.dev]........................
[package impl-specific-gray]......................
[package trivial-gray-streams]....................
[package uiop/package]............................
..................................................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package static-vectors]..........................
[package fast-io].................................
[package circular-streams]..

Any ideas?

update Commit 4ed76c32050753c8a4450c342a1592881e11d63d seems to reference this behavior, with the “fast-io” system given as an example. And indeed, when I try this with fast-io, I see similar recompilation.

UIOP 3.3.0 problems

via Zach Beane Common Lisp by on Wed, 18 Oct 2017 12:59:06 GMT

Ok, here’s something that is causing problems when I build this month’s Quicklisp dist.

UIOP 3.3.0 was recently released, and it’s causing some stuff to apparently compile over and over again. Here’s a real simple thing to try:

$ cd ~/quicklisp/local-projects/
$ curl -O https://common-lisp.net/project/asdf/archives/uiop.tar.gz
$ tar xzvf uiop.tar.gz

Then:

CL-USER> (ql:quickload "circular-streams")

On my setup, I see cffi and babel stuff compiled twice:

To load "circular-streams":
  Load 1 ASDF system:
    circular-streams
; Loading "circular-streams"
[package uiop/package]............................
..................................................
..................................................
[package alexandria.0.dev]........................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package alexandria.0.dev]........................
..................................................
[package impl-specific-gray]......................
[package trivial-gray-streams]....................
[package uiop/package]............................
..................................................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package static-vectors]..........................
[package fast-io].................................
[package circular-streams]..

If I remove uiop-3.3.0/ from local-projects, the output looks like this:

To load "circular-streams":
  Load 1 ASDF system:
    circular-streams
; Loading "circular-streams"
[package alexandria.0.dev]........................
[package impl-specific-gray]......................
[package trivial-gray-streams]....................
[package uiop/package]............................
..................................................
..................................................
[package babel-encodings].........................
[package babel]...................................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package static-vectors]..........................
[package fast-io].................................
[package circular-streams]..

Any ideas?

update Commit 4ed76c32050753c8a4450c342a1592881e11d63d seems to reference this behavior, with the “fast-io” system given as an example. And indeed, when I try this with fast-io, I see similar recompilation.

Animating Background Gradients to Make Your PWA More Native

via DockYard blog by James Steinbach on Tue, 17 Oct 2017 00:00:00 GMT

We can’t currently transition a CSS gradient, but by using an SVG mask, we can create a gradient and transition all its colors.

Archmage Is Done!

via Lisplog by on Mon, 09 Oct 2017 22:10:12 GMT

When I visited my son in Tennessee in late August, he taught me two new board games that he invented. I really like one of them, which he calls Archmage, so I've been working since then on building a webapp, in Elm, to play it. I just finished that today.

Check it out at https://gibgoygames.com/archmage/

Should it become wildly popular, I could be convinced to add score tracking and full game history, assuming I can come up with a business model to pay for the server, but I sorta doubt that's gonna happen.

Archmage

 newer latest older