The Common Lisp Condition System Book

via Lisp, the Universe and Everything by Vsevolod Dyomkin on Mon, 23 Nov 2020 12:41:00 GMT

Several months ago I had a pleasure to be one of the reviewers of the book The Common Lisp Condition System (Beyond Exception Handling with Control Flow Mechanisms) by Michał Herda. I doubt that I have contributed much to the book, but, at least, I can express my appreciation in the form of a reader review here.

My overall impression is that the book is very well-written and definitely worth reading. I always considered special variables, the condition system, and multiple returns values to be the most underappreciated features of Common Lisp, although I have never imagined that a whole book may be written on these topics (and even just two of them). So, I was pleasantly flabbergasted.

The book has a lot of things I value in good technical writing: a structured and logical exposition, detailed discussions of various nuances, a subtle sense of humor, and lots of Lisp. I should say that reading the stories of Tom, Kate, and Mark was so entertaining that I wished to learn more about their lives. I even daydreamt (to use the term often seen throughout the book) about a new semi-fiction genre: stories about people who behave like computer programs. I guess a book of short stories containing the two from this book and the story of Mac from "Practical Common Lisp" can already be initialized. "Anthropomorphic Lisp Tales"...

So, I can definitely recommend reading CLCS to anyone interested in expanding their Lisp knowledge and general understanding of programming concepts. And although I can call myself quite well versed with the CL condition system, I was also able to learn several new tricks and enrich my understanding. Actually, that is quite valuable as you never know when one of its features could become handy to save your programming day. In my own Lisp career, I had several such a-ha moments and continue appreciating them.

This book should also be relevant to those, who have a general understanding of Lisp, but are compelled to spend their careers programming in inferior languages: you can learn more about one of the foundations of interactive programming and appreciate its value. Perhaps, one day you'll have access to programming environments that focus on this dimension or you'll be able to add elements of interactivity to your own workflow.

As for those who are not familiar with Lisp, I'd first start with the classic Practical Common Lisp.

So, thanks to Michał for another great addition to my virtual Lisp books collection. The spice mush flow, as they say...

Understanding Combinators

via Elm - Latest posts by @evancz Evan on Thu, 22 Oct 2020 17:52:35 GMT

My understanding is that the term “combinators” is not a topic on its own. It generally see it as a modifier term for existing things. So “X combinators” is generally like saying “X where I have thought about how to combine one X with another X pretty carefully.”

For example, a person who uses this term might say elm/parser is a library of “parser combinators”. Their meaning is “these are parsers that can be combined” and they may be using the term (1) just because other people say it or (2) to draw a contrast with parsing libraries that may not have as clear rules for how parsers fit together. So parsers like regex or lex/yacc would be distinct from “parser combinators” when talking about parsing techniques in a more formal setting. (In my experience!)

I think things that get this modifier added to them might often have map or map2 or andThen functions, but I do not think “combinator” has a consistently used technical meaning with regards to which of these functions are available (or if there is some other mechanism for combination!)

For example, the Arrowized FRP work here refers to “AFRP combinators” that are pretty different from the typical map2 or andThen approaches. In this case the meaning is roughly “AFRP functions for combining things”.

I think the term “combinators” is generally (always?) used for things embedded within an existing language, so perhaps it is distinguishing between “a language for X” vs “a set of functions for X”. I’m not thinking of counter-examples for this definition right now! Maybe that’s the best definition!

Anyway, that’s just my perspective on this. Hope that helps!

Understanding Combinators

via Elm - Latest posts by @hexedhash Giorgio on Thu, 22 Oct 2020 15:19:32 GMT

Hey friends,

Recently I’ve come across two great libraries that use combinators to build great abstractions:

• https://package.elm-lang.org/packages/hecrj/composable-form/latest/
• https://package.elm-lang.org/packages/astynax/tea-combine/latest/

As someone who isn’t very familiar with the concept of combinators, I’d like to gather and read resources on combinators to gain a deep understanding.

There’s a Medium post that specifically talks about tea-combine (link), but I’d like to see if there is a more general post / tutorial on using combinators that will help me grok this concept.

3D Physics Engine Pt. 5

via Elm - Latest posts by @unsoundscapes Andrey Kuzmin on Wed, 21 Oct 2020 23:17:57 GMT

Hey folks! I’ve just published the new version of elm-physics and realized that it has been almost a year since the last update. I am going to take this as an oportunity to write another progress report. You can find all the posts here.

falling ducklings demo800×400 389 KB

This blogpost is going to focus on the following things:

1. Performance improvements
2. Better inertia support
3. New shape types
4. What’s next

Performance Improvements

Since the last performance improvements I have identified more hot places in the code using Chrome Development Tools. I then inlined some code blcoks and reduced object allocations. I also removed more List.foldl and List.map occurences in favor of tail optimized recursions. A tail optimized recursion in Elm is compiled to a while loop in JavaScript with function arguments becoming a bunch of local variables. This makes it pretty fast! Besides these simple improvements, I have made three rather complex ones.

One of them was improving the collision algorithm between two convex polyhedrons. In the last part of collision, two faces from colliding shapes are being clipped against each other. The former implementation used adjacent faces for clipping, the new implementation does not need this, it uses planes, that are perpendicular to the clipping face. Now it is following the else part in the original Cannon.js code. My understanding is that this was transpiled from the bullet engine code where the BLA1 was replaced with true. Maybe there is more to this, because the maintainers of cannon-es, the continuation of Cannon.js, have deleted the else part as dead code. However this has been working fine so far in elm-physics and haven’t noticed any issues.

Another improvement was to further reduce slow Array.insert operations in the solver. Basically the solver iterates over a list of equations of pairs of bodies. When an equation is processed, both bodies need to be updated and thus written to an immutable array. I had already done an improvement in this part of the solver before. I grouped the equations for each pair of bodies, this way I could update two bodies in the recursion, and then finally write them to the array after I looped through the whole group. In this case I took this a little further. I noticed a pattern of how contacts between pairs of bodies are generated for all combinations of bodies. If a single body collided with two other, it would be likely for it to be present in subsequent equation groups. I decided to keep this body on the recursion and write to the array only when the next equation group doesn’t include this body.

The last improvement was to cache the shape definitions (faces, vertices, edges, etc.) in the world coordinates, to avoid having to transform them from the body local coordinates in all other places in the code multiple times.

The result of this work — 125 boxes are now simulated at 60fps! This is quite fast for an engine where each simulation cycle creates a new immutable copy of the world.

Better Inertia Support

The moment of inertia tensor is what affects the rotational movement of a body. It basically defines how the mass is distributed. This is one of the things that elm-physics takes care of, so that you don’t have to worry about it! The original implementation had an oversimplified calculation of the moment of inertia tensor. It basically took a bounding box and assumed it was a solid body. The new implementation uses the right formula for each primitive shape, and also properly aggregates inertia for a compound body made of multiple shapes.

I didn’t simply decide to work on this myself, but was encouraged by Ian Mackenzie, and the work of folks from McMaster Outreach who used elm-physics to build a programming playground for students, in which they could assemble a space ship and then control the thrusters. I wasn’t asked to improve inertia, but thought that it would make simulations more realistic.

table-flip demo800×400 57.4 KB

It took a lot of time to learn the physics and get this right, including solving the bug, that took about a month to figure out. I had to write pretty interesting tests too. The result is very rewarding and noticeable even in some of the existing demos. For example, try flipping the table with a mouse — it is more likely for it to land upside down now than it was before!

New Shape Types

The previous version of elm-physics only supported blocks and spheres. Even though it was possible to build demos with just these shapes, that was pretty limiting. The new version has two new additions.

The first new addition is the cylinder shape, that was contributed by Martin Stewart! It is tremendously hard to implement collisions for a proper mathematical representation of a cylinder, so this implementation simplifies it as a convex polyhedron. It also lets you choose how much you would like to subdivide the sides.

The second kind of shape — unsafe convex — is something that I am very excited about. This opens up the internal API for folks who want to use their own convex shapes. The input for the constructor is the same TriangularMesh type, that is used in elm-3d-scene too. The reason why it is called “unsafe”, is because there are a few gotchas: it has to be convex, it has to be watertight, and the faces should have the correct winding order of vertices.

But don’t worry, there are existing tools that let you create proper shapes — like Blender, where you can select vertices and enclose them in a convex polyhedron. And if the result mesh has too many faces, you can also apply the decimate modifier, that would simplify the collider shape and make the physics simulation more performant.

Up until recently, there was no easy way to import things from Blender into elm-3d-scene. Thankfully to the elm-obj-file package, we can now export 3D meshes from Blender, and then render and simulate them with Elm. It is even possible to store both visual and physical representations in the same OBJ file, and then write a decoder for both, like it is done in the Duckling demo from above.

duck mesh and collider shape914×319 70.9 KB

The source code for this demo is just 256 lines of Elm. I am excited what folks can build using these tools!

What’s next

Ian Mackenzie gave a pretty nice overview of what’s next in 3D in Elm at London Elm Meetup. As you can see, most of elm-physics items have been implemented.

Continuous collision detection, a mechanism to prevent bodies moving at high velocities to pass right through each other, is something that is still pending. It would be nice to implement this at least for spheres. If you would like to collaborate with me on this functionality, please get in touch!

Something that is almost complete is the raycast car demo, that implements manipulations on top of elm-physics to simulate a car. It shoots rays and applies impulses where they hit the ground. This way it is possible to simulate suspension, that results in a more smooth than the current rigid version that uses hinge constraints.

raycast car demo800×400 447 KB

You might have seen a variation of this demo in Evan’s ICFP keynote, that was built by Luca Mugnaini. This example used the demo rendering code from elm-physics examples. I plan to make a package that implements the pluggable raycast car behavior, and then build concise examples that render with elm-3d-scene.

Last but not least, the topic of the next Elm Game Jam is going to be “3D”. We will be organizing this together with Ian. Stay tuned for the official announcement!

Webpack 5 updated example

via Elm - Latest posts by @system system on Wed, 21 Oct 2020 15:18:59 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Is my install of elm-app broken?

via Elm - Latest posts by @NiavlysB Sylvain Brunerie on Wed, 21 Oct 2020 14:20:42 GMT

Oh sorry, the repo is private actually, I completely forgot about that!

Anyway, problem fixed now! I just ran yarn global upgrade create-elm-app, and all is well now. create-elm-app was apparently broken in my environment since it was also unable to create new projects.

Is my install of elm-app broken?

via Elm - Latest posts by @pdamoc Peter Damoc on Wed, 21 Oct 2020 12:12:29 GMT

This link is broken. It throws a 404 error.

I’ve been using this plugin since May without any issues. Maybe it is the interaction with some other plugins that you have.

Is my install of elm-app broken?

via Elm - Latest posts by @NiavlysB Sylvain Brunerie on Wed, 21 Oct 2020 09:30:23 GMT

PS: At the same time, Sublime’s “Elm format on save” plugin seemed to be broken in a dangerous way, completely emptying any Elm file I would try to save… I disabled the plugin and it fixed the problem. I would think there’s no relation with the main issue I mentioned here, but just in case, I thought I should mention it as well.

Reasons that people were forced to move from Elm to something else?

via Elm - Latest posts by @francescortiz Francesc Ortiz on Wed, 21 Oct 2020 08:52:47 GMT

React was already widely adopted on version 0.14. Then, they decided to strip the 0 and the next version became 15, but in fact it should have been 0.15, and the current one should be 0.17. Or maybe it should have been called 1.0.0, but being on 1.0.0 also feels immature, so they skipped 14 numbers. Browsers used to release new major versions every few years. Then, chrome decided that everything should be a major version. Now, i f you are in version 1.0.0 you look in early stages compared to chrome. Instead of playing around numbers, check the ecosystem. JavaScript has been there since last century and still has a messy ecosystem pushed forward by hypes that last after a few months.

Also, nowadays, with continuous integration, it is common to promote releases, not create new ones. So 1.2.0-alpha becomes 1.2.0-beta and, afterwards, 1.2.0-stable, but they are exactly the same thing only with different tagging.

So, Chrome could be at version 3.7, React could be at version 1.2, and Elm could be 2.1. The number is irrelevant, the important thing is what they offer.

Do you put tests outside the `tests/` folder?

via Elm - Latest posts by @lydell Simon Lydell on Wed, 21 Oct 2020 06:40:15 GMT

Thanks! Though I’m not sure we want to be bring the “old” behavior back.

In all test runners I’ve ever used, running cool-test-runner path/to/some.file only runs the tests in that file, which is nice when debugging a failing tests for a certain module. If we also run tests in files that are imported that command could run a lot more tests than one would expect.

I have just looked at this quickly, but the impression I got from the PRs/issues leading up to the revision3 release was that 0.19.1 and 0.19.1-revision2 were regressions from 0.18 – the run tests via imports (if that’s even how it works, I haven’t dug into it) was an accident and never how it was supposed to work.

I need to dig deeper to know for sure, though.