Wrong, most of these radars are 24Ghz and specifically designed to detect body micro movements. They specifically give both human 'occupancy' and dynamic ranging information.
I wrote low level drivers for the ESP32 for all the ones I could buy and have tested all of them. The only one that does not try to give a human occupancy position is the car speed sensor.
I'm increasingly building entire functional prototypes from start to finish using Claude 3.5 Sonnet. It's an amazing productivity boost. Here are a few recent examples:
datasette-checkbox is a Datasette plugin adding toggle checkboxes to any table with is_ or has_ columns. Animated demo and prompts showing how I built the initial prototype here: https://simonwillison.net/2024/Aug/16/datasette-checkbox/
I still see some people arguing that LLM-assisted development like this is a waste of time, and they spend more effort correcting mistakes in the code than if they had written it from scratch themselves.
I couldn't disagree more. My development process has always started with prototypes, and the speed at which I can get a proof-of-concept prototype up and running with these tools is quite frankly absurd.
SAW2 is maybe one of the most important collections of ambient electronic music ever made. It's an astonishing exploration of the genre.
I've thought it to be compared in some ways to Bach's "The Art of Fugue" which pushed its own genre so hard that its often considered to be pinnacle work on Fugues and sort of forced later musicians to move along to newer forms.
While I personally prefer SAW85-92, I have to recognize the ways in which SAW2 pushes ambient and electronic music, even today, to areas that force it to be defined and to redefine itself. SAW85-92 sounds very much like a product of the time, but SAW2 sounds absolutely contemporary even today. It somewhat closed the book on Ambient electronica and then shoved that book firmly into the avantgarde. The individual pieces range from unsettling to mind-alteringly beautiful.
"...I Care Because You Do" just sort of continues the leap forward. "Start As You Mean to Go On" feels to me like plugging yourself into a power outlet in a hurricane. IMHO, RDJ is at his best when he combines a kind of odd, almost apathetic, idle but tuneful, framework to a song, then ignites it into a frenetic mind blending fire with absolutely bonkers rhythmic lines, or sometimes just leaves it to chill like with "Aberto Balsalm".
It's wild to think we're talking about music older than people who have graduated college and are considered almost mid-career in some fields. And yet he's still making mindblowing stuff https://youtu.be/e_Ue_P7vcRE
>Caffeine integrates SqueakJS, a JavaScript implementation of the Squeak Smalltalk virtual machine, with several JavaScript runtime environments, including web frontends (web browsers, with DOM, DevTools, and Observable integration), backends (Node]S), and Web Workers.
>Caffeine ( caffeine.js.org ) is a livecoded integration of the SqueakJS Smalltalk virtual machine with the Web platform and its many frameworks. Craig Latta will show the current state of Caffeine development through live manipulation and combination of those frameworks. The primary vehicle is a Caffeine app called Worldly, combining the A-Frame VR framework, screen-sharing, and the Chrome Debugging Protocol into an immersive virtual-reality workspace.
>Craig Latta ( blackpagedigital.com ) is a livecoding composer from California. He studied music at Berkeley, where he learned Smalltalk as an improvisation practice. He has worked as a research computer scientist at Atari Games, IBM's Watson lab, and Lam Research. In 2016 he began combining Smalltalk technologies with the Web platform, with an emphasis on spatial computing. He is currently exploring spatial audio for immersive workspaces.
SqueakJS – A Squeak VM in JavaScript (squeak.js.org)
115 points by gjvc on Oct 27, 2021 | hide | past | favorite | 24 comments
One thing that's amazing about SqueakJS (and one reason this VM inside another VM runs so fast) is the way Vanessa Freudenberg elegantly and efficiently created a hybrid Smalltalk garbage collector that works with the JavaScript garbage collector.
SqueakJS: A Modern and Practical Smalltalk That Runs in Any Browser
>The fact that SqueakJS represents Squeak objects as plain JavaScript objects and integrates with the JavaScript garbage collection (GC) allows existing JavaScript code to interact with Squeak objects. This has proven useful during development as we could re-use existing JavaScript tools to inspect and manipulate Squeak objects as they appear in the VM. This means that SqueakJS is not only a “Squeak in the browser”, but also that it provides practical support for using Smalltalk in a JavaScript environment.
>[...] a hybrid garbage collection scheme to allow Squeak object enumeration without a dedicated object table, while delegating as much work as possible to the JavaScript GC, [...]
>2.3 Cleaning up Garbage
>Many core functions in Squeak depend on the ability to enumerate objects of a specific class using the firstInstance and nextInstance primitive methods. In Squeak, this is easily implemented since all objects are contiguous in memory, so one can simply scan from the beginning and return the next available instance. This is not possible in a hosted implementation where the host does not provide enumeration, as is the case for Java and JavaScript. Potato used a weak-key object table to keep track of objects to enumerate them. Other implementations, like the R/SqueakVM, use the host garbage collector to trigger a full GC and yield all objects of a certain type. These are then temporarily kept in a list for enumeration. In JavaScript, neither weak references, nor access to the GC is generally available, so neither option was possible for SqueakJS. Instead, we designed a hybrid GC scheme that provides enumeration while not requiring weak pointer support, and still retaining the benefit of the native host GC.
>SqueakJS manages objects in an old and new space, akin to a semi-space GC. When an image is loaded, all objects are created in the old space. Because an image is just a snapshot of the object memory when it was saved, all objects are consecutive in the image. When we convert them into JavaScript objects, we create a linked list of all objects. This means, that as long as an object is in the SqueakJS old-space, it cannot be garbage collected by the JavaScript VM. New objects are created in a virtual new space. However, this space does not really exist for the SqueakJS VM, because it simply consists of Squeak objects that are not part of the old-space linked list. New objects that are dereferenced are simply collected by the JavaScript GC.
>When full GC is triggered in SqueakJS (for example because the nextInstance primitive has been called on an object that does not have a next link) a two-phase collection is started. In the first pass, any new objects that are referenced from surviving objects are added to the end of the linked list, and thus become part of the old space. In a second pass, any objects that are already in the linked list, but were not referenced from surviving objects are removed from the list, and thus become eligible for ordinary JavaScript GC. Note also, that we append objects to the old list in the order of their creation, simply by ordering them by their object identifiers (IDs). In Squeak, these are the memory offsets of the object. To be able to save images that can again be opened with the standard Squeak VM, we generate object IDs that correspond to the offset the object would have in an image. This way, we can serialize our old object space and thus save binary compatible Squeak images from SqueakJS.
>To implement Squeak’s weak references, a similar scheme can be employed: any weak container is simply added to a special list of root objects that do not let their references survive. If, during a full GC, a Squeak object is found to be only referenced from one of those weak roots, that reference is removed, and the Squeak object is again garbage collected by the JavaScript GC.
DonHopkins on Oct 27, 2021 | parent | next [–]
Also:
The Evolution of Smalltalk: From Smalltalk-72 through Squeak. DANIEL INGALLS, Independent Consultant, USA
>Although Squeak is still available for most computers, SqueakJS has become the easiest way to run Squeak for most users. It runs in just about any web browser, which helps in schools that do not allow the installation of non-standard software.
>The germ of the SqueakJS project began not long after I was hired at Sun Microsystems. I felt I should learn Java; casting about for a suitable project, I naturally chose to implement a Squeak VM. This I did; the result still appears to run at http://weather-dimensions.com/Dan/SqueakOnJava.jar .
>This VM is known in the Squeak community as "Potato" because of some difficulty clearing names with the trademark people at Sun. Much later, when I got the Smalltalk-72 interpreter running in JavaScript, Bert and I were both surprised at how fast it ran. Bert said, "Hmm, I wonder if it’s time to consider trying to run Squeak in JavaScript." I responded with "Hey, JavaScript is pretty similar to Java; you could just start with my Potato code and have something running in no time."
>"No time" turned into a bit more than a week, but the result was enough to get Bert excited. The main weakness in Potato had been the memory model, and Bert came up with a beautiful scheme to leverage the native JavaScript storage management while providing the kind of control that was needed in the Squeak VM. Anyone interested in hosting a managed-memory language system in JavaScript should read his paper on SqueakJS, presented at the Dynamic Languages Symposium [Freudenberg et al. 2014].
>From there on Bert has continued to put more attention on performance and reliability, and SqueakJS now boasts the ability to run every Squeak image since the first release in 1996. To run the system live, visit this url: https://smalltalkzoo.thechm.org/HOPL-Squeak.html?launch
codefrau on Nov 5, 2021 | root | parent | next [–]
Dan published an updated version of that paper here:
It's just a hodgepodge of prototype scripts, but one that I actually used on a few occasions already. Most of the work is manual, but does seem easily run as "fire and forget" with maybe some ways to correct afterwards.
First, I'm using the pyannote for speech recognition: it converts audio to text, while being able to discern speakers: SPEAKER_01, _02, etc. The diarization provides nice timestamps, with resolution down to parts of words, which I later use in the minimal UI to quickly skip around, when a text is selected.
Next, I'm running a LLM prompt to identify speakers; so if SPEAKER_02 said to SPEAKER_05 "Hey Greg", it will identify SPEAKER_05 = Greg. I think it was my first time using the mistral 7b and I went "wow" out loud, once it got correct.
After that, I fill in the holes manually in speaker names and move on to grouping a bunch of text - in order to summarize. That doesn't seem interesting at a glance, but removing the filler words, which there are a ton of in any presentation or meeting, is a huge help. I do it chunk by chunk. I'm leaning here for the best LLM available and often pick the dolphin finetune of mixtral.
Last, I summarize those summarizations and slap that on the front of the google doc.
I also insert some relevant screenshots in between chunks (might go with some ffmpeg automatic scene change detection in the future).
aaand that's it. A doc, that is searchable easily. So, previously I had a bunch of 30 min. to 90 min. meeting recordings and any attempt at searching required a linear scan of files. Now, with a lot of additional prompt messaging I was able to:
- create meeting notes, with especially worthwile "what did I promise to send later" points
- this is huge: TALK with the transcript. I paste the whole transcript into the mistral 7b with 32k context and simply ask questions and follow-ups. No more watching or skimming an hour long video, just ask the transcript, if there was another round of lay-offs or if parking spaces rules changed.
- draw a mermaid sequence diagram, of a request flowing across services. It wasn't perfect, but it got me super excited about future possibilities to create or update service documentation based on ad-hoc meetings.
I guess everybody is actually trying to build the same, seems like a no-brainer based on current tool's capabilities.
Kragen is right that PostScript is a lot more like Lisp or Smalltalk than Forth, especially when you use Owen Densmore's object oriented PostScript programming system (which NeWS was based on). PostScript is semantically very different and much higher level that Forth, and syntactically similar to Forth but uses totally different names (exch instead of swap, pop instead of drop, etc).
But its most obvious similarities with Forth are based on generic Computer Science concepts like stacks, which is not something particularly unique to Forth itself, so saying PostScript was influenced by Forth ignores other much more influential languages like Interpress, JaM, and Design System, which directly influenced PostScript and were designed by the same people. Also, PostScript is not threaded like Forth. But it's homoiconic, unlike Forth and Lisp.
PostScript was a direct descendent of and heavily influenced by Xerox PARC's Interpress, by John Warnock and Charles Geschke, which itself was a direct descendent of JaM, which stands for "John and Martin", by John Warnock and Martin Newall. And JaM was a descendent of Evans and Sutherland's Design System, by John Warnock and John Gaffney.
Brian Reid (whose brother is Glenn Reid, author of several books on PostScript from Adobe) wrote up an excellent historical summary in 1985 on the laser-lovers mailing list of the influences and evolution of PostScript.
>Brian Reid wrote about page independence, comparing Interpress' and PostScript's different approaches. Adobe's later voluntary Document Structuring Conventions actually used PostScript comments to make declarations and delimit different parts of the file -- it wasn't actually a part of the PostScript language, while Interpress defined pages as independent so they couldn't possibly affect each other:
>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.
There's more interesting discussion about the relationship between PostScript and Forth on c2:
I have several 'home-cooked' apps. One is our shopping list. I have a Pi with a touchscreen in the kitchen running it, and it's easy for us both to add to from there. I also built in functionality so that if we're using a recipe from the web, we can share it to the screen, which is neat.
We can also access the shopping list on our phones while shopping. I built a feature that sorts the products by aisle (specific to our local supermarket), making it easier to do the shop easily/quickly.
I'm sure there are commercial (not even paid neccessarily) apps that do all this, but this one is used only by us and it's built to perfectly interact with our lives and circumstances:
* Things are hard-coded that would make no sense in a publicly available app, or would be very difficult to build customisation for. Hardcoding things is easy, building UI is hard. We're so used to building things in the commercial space for scale we forget how easy it is to build small things that will never need to scale beyond a userbase of 1-2.
* It has remained almost entirely unchanged in UI and features for ~10 years now. Can you say that of any other piece of software you use on a daily basis?
I've been using Pharo professionally for about 1.5 months now, and I'm beginning to getting the hang of the language, and the culture surrounding it.
I'll share a couple of thoughts.
__General Development/Hacking__
0. From Pharo 9 and onwards, it runs smooth on an M1 Mac.
1. If you're interested in developing in Pharo professionally, we're hiring [1]!
1b. Other ways to learn about Pharo is to come to Smalltalk/Pharo conferences. I've been to the Pharo Days in Lille recently and I've learned a lot in those 3 days! Other than the Pharo Days there is ESUG.
1c. Check out the Discord channel. People have been really helpful [0].
2. A big part of the documentation can be found inside the image. For example, press SHIFT + enter and type "tutorial" or "exercise" and a few will come up. Moreover, when you click on any class, there's a "class comment" tab. Some class comments actually have comments and they're written out in a quite understandable fashion when they do.
3. You can make the following clicks and they do something different:
- Click: shows a context menu to showcase a particular window / tool
- Right click: shows "World Contents", aka objects about your GUI (I haven't used this one yet)
- Shift + Option + click: this shows a "halo" around a GUI
- Shift + Control + Click: the coolest meta click there is, it shows all objects that are directly related to the pixel you clicked on. If you clicked on a table cell item in a GUI window, you can figure it out via this click. I've used this trick to figure out where to go in order to alter my IDE to my own taste.
4. Pharo is one of the few languages I know where you can create like a game or application for which it's possible to immediately see the source code and interact with it. The use-case this allows for is highly hackable open-source applications. For example, here's a game that allows you to design chips [2]. It's easy to see how you could alter levels yourself quite easily, just start editing the code! IMO, that's next level open-source.
5. If you want to, it's relatively easy-ish to inspect the AST and see how it's mapped to the VM. Be careful of setting breakpoints here, you'll crash your image :P
6. A Smalltalker told me that Pharo's VM enforces everything to be an object but technically not everything is an object, as far as VM implementation goes. If you're not hacking on the VM, then you can assume everything is an object.
7. Overwriting the #doesNotUnderstand: message can lead to all kinds of fun! I wrote my custom If/Elif/Else DSL. Smalltalkers will hate me but I found it awesome because it showcases how one could hack a DSL quickly. You can see about it here [3]. Here's some example code:
As you can see, I've hacked the _: to be a separator of some sorts, but what it actually is, is an argument of a message. You can do all kinds of fun stuff with this. See [8].
8. When you overwrite #doesNotUnderstand then you can inspect the message and its arguments. So whether you send Object1 a:arg1 veryImportant:arg2 message:arg3, then you can inspect those arguments. In the case above, this means you can also inspect _:arg1 _:arg2 or _:arg1 _:arg2 _:arg3 ... _;argN. In other words, you can deal with variable arguments and it doesn't matter what they're called. Because of this, it's easy to create a simple DSL, if you need another separator, then simply add one. You have a lot of characters at your disposal that are quite unique [4]. I figured that out by using by using point (2) and just looking around in the environment.
__Web Development__
9. Seaside is capable of live and dynamic updating. MOOCs won't tell you this because it requires using Seaside quite differently. In short, the pattern that I see used at my work is by having server-side rendered HTML that has designated blocks as callbacks. So when you send your server-side rendered HTML, those callback blocks will transform itself into a jQuery GET/POST request. Pharo writes the jQuery for you. We also use React, but I haven't gotten around to it how it's used, I'm fairly sure we don't use anything like Redux.
10. In terms of testing, it's relatively easy to write tests. As with Go, it's all included and you're ready to test! Also note: if you want to use Selenium tests, you can use Parasol [5], it's quite easy to use.
11. The following concepts are not explained well, so I'll do it: Seaside heavily uses what we'd call middleware in NodeJS (filters in Seaside). In NodeJS/Express we also have a request object that exists during the lifetime of a request. In Seaside this is called a dynamic variable (WADynamicVariable is the class).
__Stuff I wrote out in the open__
12. I've been working on refactoring i18n in Seaside [6]. I currently find the approach Pharo uses the nicest approach, which is something along the lines of:
'You have some string that needs translation in your web app' SeasideTranslated
When you want to export a catalog file of all the strings you want to translate, then you send exportCatalog new exportCatalog and it will look through the whole image and find every tagged string and export it into a catalog (.pot) file that you can edit with POEdit (a free Mac app [7]).
13. I wrote a simple animation that shows the definition of sin and cos [8]. Most of the code is shown in that video, IMO it gives a good enough sense how to use it.
__Bottom Line Thoughts__
14. I think Pharo is a production-ready language for SaaS apps where you can easily scale by adding instances. I am not sure if it'd be production-ready for consumer facing web apps with many concurrent users.
15. It's an amazing language to create desktop applications for.
16. The debugger capabilities are awesome and there's active research on it. Time travel debugging is currently in its PoC phase (source: Pharo Days).
17. It's also a good language for live music making (source: Pharo Days where someone demo-ed some live coded acid music).
[1] We're hiring developers able to work in Europe and based in a European time zone. The way we use Pharo is IMO the real deal, it goes far beyond what any MOOC can teach you.
The three most recent HN discussions on CRDTs are all worth perusing.
[1] is an excellent tutorial that assumes no initial familiarity with CRDTs or the math that underpins them. It walks you through both the formalisms and the implementation, which is pretty key to understanding why making real-world CRDTs flexible enough to handle things like rich text editing is hard.
[2] is a talk that goes more in-depth on the hard parts
[3] goes deeper on OT vs. CRDT
It's worth noting that many of the CRDT discussions focus on collaborative text editing. That's a really hard problem. CRDTs are (and have been for some time) a useful primitive for building distributed systems.
I wrote low level drivers for the ESP32 for all the ones I could buy and have tested all of them. The only one that does not try to give a human occupancy position is the car speed sensor.
The ld2450 can track three people at once.
https://github.com/mianos/hk-heltec-radar/tree/main/src