Feed Aggregator Page 678

Rendered on Mon, 31 Jan 2022 13:02:33 GMT  newer latest older 

What's wrong with using Html.map?

via Elm - Latest posts by @Sebastian Sebastian on Wed, 26 Jan 2022 22:52:45 GMT

It is trying to discourage the use of the nested Elm architecture pattern Nested TEA - Elm Patterns. Commonly Html.map is used in this pattern. This pattern is useful but is best to leave it for when it is really needed. It brings a good amount of complexity and boilerplate, so it better to find alternative solutions first.

If Html.map is useful for you without the whole Nested TEA pattern then there is not reason not to use it.

Marco Antoniotti: CDR is Next...

via Planet Lisp by on Fri, 21 Jan 2022 21:44:00 GMT

 Hi

as many may know, I have been nursing (almost to death!) the Common Lisp Document Repository (CDR).  Pascal Costanza et al., started the project many years ago and then I sat on top of it for many more.

I finally found some time to work on it and the result is a revamped site (cdr.common-lisp.dev) with the addition of stashing documents in a Zenodo Community (CDR), which has the benefit of producing a DOI for each write-up.

Moreover, Pascal Bourguignon, Michał "phoe" Herda and Didier Verna have agreed to become CDR editors.  Many thanks to them.

So, if anyone wants to submit a "specification" for something of interests to the CL community, she/he is most welcome to do so.  Just remember that good specifications are not so easy to write.

(cheers)

Eitaro Fukamachi: Day 4: Roswell: How to make Roswell scripts faster

via Planet Lisp by on Tue, 18 Jan 2022 06:30:46 GMT

Hi, all Common Lispers.

In the previous post, I introduced "Roswell script", the powerful scripting integration of Roswell. Not only does it allow to provide a command-line interface, but it makes it easy to install via Roswell. In this point of view, Roswell can be regarded as a distribution system for Common Lisp applications.

Today's topic is related — the speed of scripts.

Why my simple Roswell script is so slow?

Let's begin with the following simple Roswell script. It's a pretty simple one that just prints "Hello" and quits.

#!/bin/sh
#|-*- mode:lisp -*-|#
#|
exec ros -Q -- $0 "$@"
|#
(progn ;;init forms
  (ros:ensure-asdf))

(defpackage :ros.script.hello.3850273748
  (:use :cl))
(in-package :ros.script.hello.3850273748)

(defun main (&rest argv)
  (declare (ignorable argv))
  (write-line "Hello"))
;;; vim: set ft=lisp lisp:

$ ./hello.ros
Hello

Though people expect this simple script to end instantly, it takes longer.

$ time ./hello.ros
Hello

real    0m0.432s
user    0m0.315s
sys    0m0.117s

0.4 seconds to print "Hello". It feels like an early scripting language.

An equivalent script with sbcl --script is much faster for the record.

$ time ./hello.lisp
Hello

real    0m0.006s
user    0m0.006s
sys    0m0.000s

Fortunately, there're several solutions to this problem.

Hacks to speedup

I have to admit that the Roswell script can't be faster than sbcl --script since it does many things, but it's possible to make it closer.

Stop loading Quicklisp

The first bottleneck is "Quicklisp".

Quicklisp is a de fact standard and available anywhere today, so we may not realize the cost of loading it. But, it can't be ignored in scripting.

Fortunately, it's easy to disable Quicklisp in the Roswell script. Just replace -Q with +Q in the exec line.

 #!/bin/sh
 #|-*- mode:lisp -*-|#
 #|
-exec ros -Q -- $0 "$@"
+exec ros +Q -- $0 "$@"
 |#
 (progn ;;init forms
   (ros:ensure-asdf))

Let's see the difference.

# No Quicklisp version
$ time ./hello.ros
Hello

real    0m0.142s
user    0m0.119s
sys    0m0.020s

It's approximately 0.3 seconds faster. Conversely, it takes this long to load Quicklisp. This is not little time for a program that starts many times, like scripts.

Additionally, omit ros:ensure-asdf since ASDF is unnecessary in this script.

 exec ros +Q -- $0 "$@"
 |#
 (progn ;;init forms
-  (ros:ensure-asdf))
+  )

 (defpackage :ros.script.hello.3850273748
   (:use :cl))

$ time ./hello.ros
Hello

real    0m0.072s
user    0m0.052s
sys    0m0.020s

ASDF seems to require to load approximately 0.07 sec. Now, it's 6 times faster.

These changes are effective for small scripts which don't require Quicklisp or ASDF.

Even in the case of scripts that use Quicklisp and ASDF, this method can be applied partially by loading them conditionally.

For example, a script has several subcommands like run or help.

Let's suppose run requires Quicklisp to load the main application, and help doesn't.

If you use -Q option, Quicklisp will make help command slow though it doesn't require Quicklisp.

In this case, it is better to use the +Q option and load Quicklisp if necessary.

ros:quicklisp is a function to load Quicklisp manually, even when the ros started with +Q. By calling this function right before Quicklisp is needed, it's possible to make the other part faster.

Dump core with `-m'

What about in case of fairly complicated applications which must require Quicklisp to load external dependencies.

Building a binary is a prevailing solution.

I suppose it won't surprise you. It's a common technique even in no Roswell world. Also, I've mentioned ros build in the previous article, which makes a binary executable from a Roswell script.

However, we can't assume people always run ros build to speed up your application after installation.

Roswell takes care of it. Roswell has a feature to build the script dump implicitly to speed up its execution.

Add -m' option to theexec ros` line. Then, enable Quicklisp and ASDF to see how this feature is practical.

@@ -1,10 +1,10 @@
 #!/bin/sh
 #|-*- mode:lisp -*-|#
 #|
-exec ros +Q -- $0 "$@"
+exec ros -Q -m hello -- $0 "$@"
 |#
 (progn ;;init forms
-  )
+  (ros:ensure-asdf))

 (defpackage :ros.script.hello.3850273748
   (:use :cl))

And install the script.

$ ros install hello.ros
/home/fukamachi/.roswell/bin/hello

Let's try it. It'll take a little time for Roswell to dump a core named hello.core for the first time.

$ hello
Making core for Roswell...
building dump:/home/fukamachi/.roswell/impls/arm64/linux/sbcl-bin/2.2.0/dump/hello.core
WARNING: :SB-EVAL is no longer present in *FEATURES*
Hello

The second time, it's way faster.

$ time hello
Hello

real    0m0.032s
user    0m0.009s
sys    0m0.024s

It's approximately 13 times faster than the initial version. Of course, it includes the load time of Quicklisp and ASDF.

Remember that this requires the script to be installed at ~/.roswell/bin via ros install.

A living example is "lem", a text editor written in Common Lisp.

In the case of "lem", it requires lots of dependencies to run, and people expect a text editor to launch instantly. The dumping core works nicely for it.

# Installation
$ ros install lem-project/lem

# Takes a little time for the first time
$ lem
Making core for Roswell...
building dump:/home/fukamachi/.roswell/impls/arm64/linux/sbcl-bin/2.2.0/dump/lem-ncurses.core
WARNING: :SB-EVAL is no longer present in *FEATURES*

# === lem is opened in fullscreen ===
# Type C-x C-c to quit

It takes a little time to boot up the first time, but the second time is quicker. Also, it'll be dumped again when Roswell detects some file changes.

Note that the name of the core needs to be unique. If there is a conflict, Roswell will load a different core.

Actually, this behavior doesn't go with Qlot well. If there's an application installed in user local and another installed in project local, Roswell can't distinguish between their cores. So then, even if you think you have fixed the version of the library, it will be using a core with a different version loaded.

This is not a problem for independent software like lem, but you should be careful with applications that load other software while running. A bad example of this problem is "Lake".

Conclusion

In this article, I introduced a technique to speed up the startup of Roswell scripts.

• To startup faster
  • Add +Q to disable loading QuicklispF
  • Dump cores with -m option

Both have pros and cons.

The nice thing about the `-m' option is that the end-user doesn't need to be aware of it, which is a good part of Roswell as a distribution system for Common Lisp applications.

Eric Timmons: CL Community(?) Norms

via Planet Lisp by on Mon, 17 Jan 2022 09:00:00 GMT

In case you haven't seen it, the ASDF maintainer is considering resigning. The reason is pretty straightforward: continued antagonization toward the ASDF team from a prominent CL developer (and maintainer of a number of widely used libraries) and the seeming acceptance of this by the CL community.

The only other forum I'm aware of that's discussing this is this Reddit thread. However, I found most of the conversation in that thread simultaneously depressing and wildly missing the point. So I decided to take advantage of this space to speak my thoughts clearly, plainly, and without interruption or other noise surrounding them.

Side note: if you know of some other place this is being discussed, I'd love to know. Bonus points if it's not a SOS's pool.

Full disclosure: I am an ASDF developer, but I was not a developer when most of the relevant events happened. I am u/daewok on the Reddit thread. Last, I think Robert has done a great job shepherding ASDF and don't want to see him resign, especially over this.

The Issue

The current flash point is this flexi-streams GitHub issue. However, the tensions have been building for quite a while.

Basically, ASDF 3.mumble improved upon an under-specified area of defining multiple systems per .asd file. The new method improved reliability, improved safety, and reduced user surprise. The cost is that a certain system naming convention needs to be followed. The naming convention is even backward compatible (if you adopt the new convention, it'll still work exactly as expected on older ASDF versions).

But even then, ASDF didn't even break extant naming schemes: all it does is signal a warning telling the user about the updated naming scheme. I personally would love it if, at some point, ASDF stops supporting anything other than the new scheme. But we are years away from considering that (ideally after everyone has adopted the new (and I can't emphasize this enough: backward compatible) naming scheme).

A mixture of ASDF and non-ASDF developers have submitted patches to projects to use the updated naming scheme. The fact that non-ASDF developers have gotten involved shows that the warning works. Most projects have accepted these patches. However, there was a notable holdout in the edicl-verse. Not only did this maintainer refuse to apply the trivial patches, they openly expressed their hope that as many people as possible would complain to the ASDF devs. This latter behavior is what Robert is unspeakably frustrated by and is what prompted his resignation consideration.

The Existing Discussion

Let me get this out of the way first: could Robert's initial interaction on the flexi-streams issue been better? Almost certainly. But I'm willing to cut him a little slack given that his previous interactions in other threads were collegial, I know he's been antagonized a lot over this issue and similar ones throughout the years, and were are (still) in the middle of a pandemic that's affecting everyone in different ways.

I think this antagonization of the volunteer team maintaining a widely used piece of CL infrastructure is something that very much needs to be discussed. Like I said in the intro, the Reddit thread is the only place I've really seen it discussed in any depth. And that's a shame, because the discussion there missed the point in two major ways.

First, there was a group of people that focused on the technical issues at hand. Basically things like: "should ASDF have made this change?", "the warning being signaled is unnecessary in this specific case!", "why is ASDF signaling warnings at all!?" Which, in addition to missing the point of Robert's email entirely, also managed to demonstrate that people have shockingly strong opinions on what they want the world to look like, but have made little to no effort to make it happen in a positive way. I can definitely say that the ASDF team would love it if more people were involved in developing and testing the shared resource that is ASDF!

Second, there was the group that believed that the maintainer had the absolute right to ignore/reject the patches and that ends the discussion. I give this group credit for at least discussing a non-technical aspect of this. And while they are correct that he could ignore the patches, it misses the more interesting questions of should he have rejected the patches and was his behavior in calling for as many complaints as possible to the ASDF team reasonable.

My thoughts

Frankly, I think the call to brigade the ASDF team was out of line and I definitely expect better from a prominent CL developer. Additionally, while I agree that he had the right to not merge the patches, I still think he should have and am upset that he didn't.

There were at least three ways to remove the warning. All three were offered at one point or another. All three were backward compatible (one maybe needed a bit of reader macro magic to be so). Two did not require changing the names of the systems.

I know this developer is competent enough to understand the improvements the new naming scheme brought, so why was he a stick in the mud about it? The technical arguments for the change were strong and a PR was waiting for approval, so the two most obvious explanations are that it was some personal vendetta or he wanted to punish the ASDF developers for not getting the issue correct on the first try and wanted to force us to continue to support a horribly broken feature.

Maybe it was something else, but in any case, it makes me upset that he would prioritize whatever that reason was over supporting another CL project that is attempting to make things easier and more reliable for nearly every CL developer.

That being said, there is one place where I think I disagree with Robert. He said that the CL community tacitly accepts this behavior. But I'm really starting to think that this can't be true because there really is no CL community to speak of.

fe[nl]ix's blog post on IDEs is probably what planted this idea in my head. I didn't believe (or want to believe) it at the time, but the more I've thought about it the more sense it makes. There is no big, happy CL community. Instead there's this diaspora of small communities that only tangentially interact with each other. So it's true that the edicl community tacitly (or explicitly) accepted this behavior. But there are other communities that find the behavior abhorrent. But because they're not the same community, and each community's resources (especially manpower) are finite, there's not much they could do about it. Heck, they may not have known the issue existed until Robert's email!

To be fair, one person in the Reddit thread pointed out there is no CL community. I down voted him at the time, but it was done out of anger and I have since turned it into an up vote. That broke my spirit a bit, but it needed to be done.

This realization is very sobering and distressing. One thing I've learned about myself is that I work the best when part of a supportive community and I am willing to make some personal sacrifices to help my community. I'm lucky enough to have such a community at the moment -- my research group. I've done a lot of work in CL that I didn't need to do for my own personal goals, but I found enjoyable because I was invested in helping others and improving our shared situation and ability to make progress.

However, I won't be a part of this research group forever. So what happens when I look to find a new community? Will I be forced to reside in multiple small, fractured communities? Or is it more likely that I'll drift away from CL forever?

So far, I have found the ASDF community, Robert in particular, to be supportive. But there's a decent chance he's going to resign. I've also found the Common Lisp Foundation folks to be extremely supportive and, like me, willing to take on small personal costs for the greater good. But their reach is somewhat limited (again, mostly due to the low manpower inherent in having many small communities).

But I want more. I want a broader CL community that supports one another, gives constructive feedback, uses each others' projects, and contributes code and issues. I want a community that is willing to make small individual sacrifices in order to improve everyone's situation. I want a community that realizes that because our language is frozen in time, we can devote more efforts to continuously improving our software, even if it means there are breaking changes (so long as those changes are communicated in advance :D). That last one is particularly important to me because, let's face it, most CL projects don't have a brilliant committee designing them and didn't get their interfaces perfect the first time.

So, how do we move forward? For the immediate issue, the edicl community has grown a little bit with the addition of new maintainers. At least some of those new maintainers care about this issue and are working to improve their system definitions.

But how to build a bigger, better CL community escapes me. I personally think the CLF has the best chance at being the seed crystal of such a community. They have a nonprofit set up, they are already providing shared infrastructure (such as Gitlab, project web site hosting (side note: there's some exciting news coming down the pipe soon on that front), mailing lists, and fundraising), and it seems to be run by level-headed folks that truly want to see CL succeed and a community grow. So I highly recommend that more people join that community by taking advantage of what they offer and floating any community building ideas you have on their fora or at their monthly meetings.

Beyond that, I think the best advice may be to try and broaden out any community you find yourself a part of. Give more people commit rights (after making sure they're trustworthy, of course). File issues and PRs instead of forking a project (and be responsive when you receive them!). Plan for project succession by hosting projects in a shared org instead of in your personal namespace. If you've got a single person project, consider hosting it on CLF's Gitlab so that if you drop off the face of the Earth an admin can step in and make sure someone else is able to continue working on it.

If we all grow our communities enough maybe they'll merge and we'll get our one big happy community. Then again, maybe not, but I think it's the best idea I've got at the moment.

OTP 24.2 Release

via Erlang/OTP | News by Kenneth Lundin on Wed, 15 Dec 2021 00:00:00 GMT

Analysis of Elm core issues and patches

via Elm - Latest posts by @miniBill Leonardo Taglialegne on Tue, 30 Nov 2021 18:27:21 GMT

I think line 32 and 14 are basically the same thing?

Excellent work with the analysis!

Lazy evaluated map

via Elm - Latest posts by @gampleman Jakub Hampl on Tue, 30 Nov 2021 15:56:32 GMT

Fundamentally there seems to be more than one way to skin a cat.

In the broader view you’re gonna go somewhere between the simplicity of the for loop and the efficiency of SQL depending on your needs in terms of optimisation, composition and predictability.

I think the cool thing about transducers is that they provide a very cool interface for the fromList/toList stuff that is entirely abstracted from the datastrucutre (as long as it has some neccesary operations).

A process for core library fixes and improvements

via Elm - Latest posts by @rupert Rupert Smith on Tue, 30 Nov 2021 11:27:50 GMT

You could kind of say that all Linux distros are releases of the upstream Linux kernel - I know its stretching the analogy with Elm a bit, but …

Each Linux distro has its own name, logo and identity. They all feed from a huge number of upstream projects and try to bring them together into a stable curated system. They all create opportunities to feedback patches to those upstream projects. Some have their own private repos and kernel patches (but must make those available as per the GPL) - RedHat Enterprise Linux being the obvious example.

Would put a different name and logo on it, but be completely open about the fact that it is actually Elm with a few modifications.

Lazy evaluated map

via Elm - Latest posts by @jfmengels Jeroen Engels on Tue, 30 Nov 2021 09:20:18 GMT

It’s not part of elm-review-simplify because this is not a simplification 100% of the time in terms of readability.

a
  |> List.map toX
  |> List.map toY

may be more readable than

a
  |> List.map (toX >> toY)

especially for people who dislike or have trouble reading >>. Also, in some cases, things get pretty

a
    |> List.map toX
    |> List.map
        (if condition then
            toY

         else
            identity
        )

would become

a
    |> List.map
        (toX
            >> (if condition then
                    toY

                else
                    identity
               )
        )

which I believe is worse (not that the former was that much better though).

The Elm compiler actually does very little work transforming the code. As far as I can tell, it transforms things like +into real additions (instead of function calls) and |> into regular function calls, and that’s the extent to which the compiler optimizes things (and it’s already really fast ).

I am currently looking into merging map functions and the sorts together through elm-optimize-level-2. If it works out well, then hopefully it will make it into the compiler at one point. From preliminary benchmarks, it does look like it improves performance.

That said, there is a problem with optimizing Elm core code like this, which is that custom code won’t receive the same optimizations. Say you wrote a thin wrapper around List named MyList to enforce some constraints. If the compiler were to optimize a |> List.map f |> List.map g, it wouldn’t do the same thing for a |> MyList.map f |> MyList.map g, because the compiler doesn’t know how this map function works.

And the same thing applies for other kinds of optimizations. If you want to benefit from the same optimizations because MyList is used in performance-critical code, you’d need to remove the wrapper and start using List, which is not an incentive for good and maintainable code.

It’s like having regular-speed car lanes on a highway for almost everything in Elm, and then a fast lane for core custom types. Once you have a fast lane, the other lanes become slow lanes.

Does this mean we shouldn’t apply this transformation? Not necessarily, but it’s something to keep in mind. I believe we should try and find ways to make all lanes fast, but that will probably be hard.

Serving a simple static html file from inside elm-spa

via Elm - Latest posts by @RyanNHG Ryan Haskell Glatz on Tue, 30 Nov 2021 03:13:51 GMT

Hey @madsh,

How you serve static pages in elm-spa will depend on what hosting looks like for you.

For single page apps, there is a requirement to redirect all requests to the single index.html file. For example, when I was making https://elm-spa.dev, I chose to host the app with Netlify.

Here’s what my netlify.toml file looked like to handle single-page redirects:

The last [[redirects]] section takes all page requests and points them to index.html (which serves the elm-spa application). This is what makes URL requests to /posts or /about-me always hit the elm-spa application.

If you were using Netlify, and wanted requests to /innerspa/* to go to a different entrypoint- you would specify a section like this before the final index.html redirect:

[[redirects]]
  from = "/innerspa/*"
  to = "/innerspa.html"
  status = 200

As long as your innerspa.html file is alongside index.html in the public folder, you should be all set.

If you are using a different server than Netlify, you’ll need to look into the docs for that hosting solution. The good news is this is a general frontend web app problem, so what you learn there will apply to elm-spa and any other frontend project you use.

Hope this context helps!
Ryan

 newer latest older