Lisplog

Blogging in Lisp

Search

Feed Aggregator

Rendered on Thu, 22 Oct 2020 20:34:09 GMT  newer latest older 
Next udpate: Thu, 22 Oct 2020 21:00:00 GMT feeds

Micha Herda: The Common Lisp Condition System is out now

via Planet Lisp by on Thu, 22 Oct 2020 16:21:07 GMT

tclcs-cover-s.png

After just a bit more than six months, my first programming book is out and generally available. I hope that it works well for everyone who wants to explore the condition system, how it differs from standard exception-throwing systems in other programming languages, how to implement it and how to leverage it in real-world scenarios.

Links:

  • Apress - for buying and general information
  • Amazon - for buying and general information
  • GitHub - includes the full source code from the book and the online-only Appendix E ("Discussing the Common Lisp Condition System")

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!

Micha Herda: The Common Lisp Condition System is out now

via Planet Lisp by on Thu, 22 Oct 2020 16:02:02 GMT

After just a bit more than six months, my first programming book is out and generally available. I hope that it works well for everyone who wants to explore the condition system, how it differs from standard exception-throwing systems in other programming languages, how to implement it and how to leverage it in real-world scenarios.

Links:

  • Apress - for buying and general information
  • Amazon - for buying and general information
  • GitHub - includes the full source code from the book and the online-only Appendix E ("Discussing the Common Lisp Condition System")

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:

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 @antew Antew on Thu, 22 Oct 2020 13:52:08 GMT

That is so cool, I played with the table demo for a lot longer than I had planned to, great work!

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.

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.

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.

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.

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!

Custom Scroll Bar Logic

via Elm - Latest posts by @turboMaCk Marek Fajkus on Wed, 21 Oct 2020 20:27:00 GMT

I think @Janiczek and @kraklin have something similar in app the’re working on at work. just in that case it’s not a text but a table and it also performs network requests per cells with scrolling both on x and y axis.

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.

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

via Elm - Latest posts by @dkodaj Daniel Kodaj on Wed, 21 Oct 2020 14:38:56 GMT

Could you elaborate on that? What is the main advantage of React here? One of the more obvious advantages of Elm seems to be the ability to create reusable elements with extreme flexibility. Is the problem that you need to use Html.map and Cmd.map and hook up everything to the app’s main update function?

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.

Efficient Text Editing Buffer

via Elm - Latest posts by @rupert Rupert Smith on Wed, 21 Oct 2020 13:39:52 GMT

I pushed a demo up here:

This is using my gap buffer implementation to hold the text. When the cursor is moved with up/down arrows or page up/down, the zipper focus is shifted to the line where the cursor is - so the underlying arrays are sliced and appended as you move around.

The demo is running 10K lines, locally I tried 100K and it was just as fast. At 1M it becomes very unresponsive - there is still some efficiency could be squeezed out of the buffer algorithms, since my zipper refocussing is not optimal. I am also wondering, where do I draw the line? I would very rarely edit a 100K line file, let alone 1M.

Next is to implement some basic editing and better cursor behaviour.

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.

Set default values while decoding JSON

via Elm - Latest posts by @system system on Wed, 21 Oct 2020 11:53:30 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 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.

Is my install of elm-app broken?

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

Since yesterday my Elm app (created with create-elm-app) refuses to compile, with an unusually unhelpful message:

Failed to compile

./src/Main.elmError: Compiler process exited with error Compilation failed

This error occurred during the build time and cannot be dismissed.

It worked fine the last time I worked on it. (I had a cyclic dependency issue on one of my branches. Now, all of my branches won’t compile, with the same generic error message.

The same error occurs using either elm-app start or elm-app build. What happened?

It doesn’t seem to have anything to do with the code itself, but just in case: https://gitlab.com/NiavlysB/where-s-my-char (also it’s a few commits behind my local repo)

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.

Service Worker FFI

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

I will check if monkeypatching ellie I can have a working example.

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.

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

via Elm - Latest posts by @hexedhash Giorgio on Wed, 21 Oct 2020 02:53:25 GMT

why would you release a new version of the compiler if the old one is still working fine? Much of the action is in the libraries.

Perhaps for optics. To help sway management and ease concern of skeptical colleagues. And to signal to people that “this compiler is indeed quite stable and has been used in production by several folks”.

 newer latest older