paulclinger

Roundabouts are great (we just had two complex intersections with traffic lights replaced by roundabouts and the traffic flow is much better), but they take significantly more space than a 4-way stop.

Many of these topics (and more) are explored in Ted Chiang's "The Lifecycle of Software Objects" (https://en.wikipedia.org/wiki/The_Lifecycle_of_Software_Obje...).

I have updated the Lua binding to support the session extension (http://lua.sqlite.org/home/timeline?r=session) and it's been integrated into the current version of cosmopolitan/redbean. This was partially done to support application-level sync of SQLite DBs, however this is still a work in progress.

It's an IDE, but it allows building full GUI apps. It's itself written in Lua using wxlua/wxwidgets toolkit, so has access to the majority of the modules availables in wxwidgets. The binaries are also bundled with the IDE for all supported platforms, so you can develop and package your own application in the same way.

FWIW there is ongoing work with good progress to add websocket support to redbean (https://github.com/jart/cosmopolitan/pull/967)

True, but I take loading a dishwasher as a puzzle to do it in the most compact/efficient way, which helps with adding enjoyment to the process.

Look great! I've done something similar with exactly the same approach of fully reevaluating Love functions, which allows changing the app behavior on the fly: http://notebook.kulchenko.com/zerobrane/live-coding-with-lov.... This is only running on a desktop (as it's controlled from the ZeroBrane Studio IDE running on the same machine) and allows both changing the source code and using virtual sliders on any numbers in the script to drag left/right to affect the behavior.

It was very interesting to work on that and to see the behavior of the script changing in real time. I've seen some of the users creating simple applications in a matter of minutes using this approach; here is one that was done at about the same time as the Love demo (although it's using Gideros SDK): https://notebook.kulchenko.com/zerobrane/gideros-live-coding...

I find it easier to read if it's something like "22% with $5 minimum per month".

No, to my knowledge cosmopolitan doesn't provide any special provisions to support this, so you'd have to build it yourself.

FWIW, there is ongoing work on dlopen; it was introduced 2 weeks ago (https://github.com/jart/cosmopolitan/commit/5e8c928f1a37349a...) and continued after that.

It will complicate the control of the truck and add more components (increasing the cost).

Obituary. necrolog is coming from French and is used in some languages, Russian for example.

There is a similar sign next exit 17 on 405N prohibiting existing and re-entering back.

Don't worry, it will be paused for your convenience and resumed when you come back.

There is no support for dynamic libraries in Cosmopolitan right now, so the libraries would either need to be compiled in (statically) or included in the archive as Python-only libraries. With the later ones, it should be a matter of adding them to the zip archive within the cosmo python executable, which should make them available to your scripts. See the discussion elsewhere in this thread (https://news.ycombinator.com/item?id=38102629) for some additional details.

Yes and yes.

It does indeed look interesting and looks to be similar to Lua in several aspects (although, there are some noticeable differences too). FWIW, there has been work done in eLua to keep some of the data (transparently) in ROM: https://eluaproject.net/doc/v0.9/en_arch_ltr.html (see rotables).

I don't think it's really that wrong-headed. What are the choices: (1) march ahead trying to salvage the current design with no clear path forward (other than waiting for the SSR solution), (2) quit right now, or (3) quit in 6-8 weeks if the proposed solution doesn't work (or is not delivered fast enough). The last option is not that bad if the author is hoping to figure it out, especially that the timeline is short and with a quick prototype (which the author did) it's going to be clear much sooner if the new approach is workable or not.

I mostly use arclite, Brackets matching, Netbox (for FTP access), Process list, FarColorer and Temporary panel. I suspect most of them come bundled with Far.

I've been using FAR for the last 20+ years on a daily basis and it hasn't crashed a single time for me. I like its minimalist UI, but a quite complex functions are only a click or two away and various plugins extend its functionality in useful ways (for example, Netbox for ftp access). I think it's a fantastically useful and robust tool.

You are being facetious. Libraries used to be able to do this and this is exactly how it was working until relatively recently (I received a notification earlier this year as someone who submitted requests for digital books in the past).

> If its not in the catalog requesting it from the library isn't really doing anything for you but give you false hope of it appearing.

That's precisely the point. If it's not in the catalog, there has to be a way to request it to be added (assuming the publisher allows that), but right now there is no even a mechanism to do this, as there is no competition and the full control is on the Libby side to include or not include an item (without libraries having any say in it).

> What the author is missing is the comparison with physical books, which never had this feature. You want to recommend the library get a book? You fill out the form they have. That process still works regardless of the format.

It doesn't. I used to be able to submit a request for printed and digital books, but my library stopped accepting those requests for digital books and (just as I commented elsewhere in this thread) now refers me to the Notify Me feature and Overdrive catalog (and if it's not in the catalog, I can't request it do be added).

> it's a long rant against a feature change which is really just "I don't like this change in behavior". The search box likely changed to show results from only your library, instead of worldwide results, because it was confusing a lot of library patrons

> But this is just a UX change that the author doesn't like.

That's not the case. This removed the ability for me, a library patron, to request a digital title that I had before. I can still request a printed book to be added to the catalog, but for digital title our library FAQ states (which I presume is copied from OverDrive): If you’re looking for a specific digital title that we do not have, you can use a Notify Me tag in Libby. Notify Me will alert you if the library buys the title. However, not all publishers sell their content to libraries in digital format. If you cannot find a title in Libby’s catalog, then we cannot buy the item.

This looks like the control for digital purchases was removed from the libraries and moved to OverDrive/Libby, which is definitely not a simple UX change.

This doesn't serve my interests at all and, according to the article, doesn't serve the library interests either, as they don't have the information they had before about who requests what books and can't control the purchase process. It's also (according to the author) a sign of the (coming) platform changes for the worse, which I tend to agree with.

The article (and the local-first software) has nothing to do with cloud vs. on-prem. It's about the priorities in developing and running/using your applications: "The word “local” in the name refers to your personal computer. “First” means your computer is prioritized over “someone else’s.”". Local-first apps can still use cloud resources for synchronization or for simplifying their initial configuration, but it's not a focal and critical point of the design and only serves as one of the nodes and can be made optional. You can still get all the benefits of being cloud-enabled, but you're also getting all the benefits of working without any cloud involvement at the cost of adding synchronization and conflict-resolution mechanisms.

Agree; it also helps to write documentation supporting the example. On several occasions I ended up reworking APIs I'd been working on after writing documentation for them, as some of the elements were too complex, looked inconsistent, or just didn't feel right.

Speaking about fat binaries; @jart posted this a day ago in the #ape channel on project discord:

Just created my first ever fat ape executable. I ran `apelink.com -o fat-ape-binary.com o/tiny/examples/hello2.com.dbg o/aarch64-tiny/examples/hello2.com.dbg` to create an executable that runs on Linux+OpenBSD+NetBSD+FreeBSD on x86_64+aarch64.

> Consider offering APE for x64 but then still producing ARM binaries the old fashioned way.

The recent version of cosmopolitan generates ARM binaries for Linux and MacOS (https://github.com/jart/cosmopolitan#arm; mode aarch64). There is also blink that provides the x86-64 emulation layer for (APE and other) binaries on a variety of platforms (https://github.com/jart/blink).

> But it is one thing to say that those people you wrote about in your comment were banned for spamming and it is a totally different thing to say that they were banned for sockpuppetting (when they were not).

How can I be legitimately banned for spamming when I made zero comments or posts? I rarely post or comment, so did not get a chance, but I was glad to join the community.

I recently came across CadZinho (https://github.com/zecruel/CadZinho), which is MIT-licensed, cross-platform (also works in a browser) and uses Lua as its extension language.

To me that's precisely the point: since vehicle itself is not defined and is a subject to interpretation, excluding emergency services is less of a problem than carving out an accurate boundary around what is or is not a vehicle.