I don't think it is an experiment, AFAIK it is used in a widely used application by the author.

Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated). I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema). What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.

> Marketing I suppose.

Nope. And not sure where you get that idea. This release even involved a rename away from including "GRDB."

When 0.1 of the library was released, it was a simple adapter between our Sharing library and GRDB, thus the name SharingGRDB. As our needs grew, the tool evolved significantly, and both the Sharing component and GRDB have become more of an implementation detail. In the future we will consider supporting any SQLite adapter, even your libraries ;)

If you think that this library is "basically Swift/Core Data", you have to learn more about "Swift/Core Data" and what it does, and why and how.

It persists data to disk in a manner that is easy to query. It allows observing changes to the data so that features update when necessary. It handles graphs of objects just fine thanks to recursive CTE's in SQLite. With a little bit of work it can handle historical edits with undo/redo. It seems to quack like Swift/Core Data to me, but bringing SQLite to the forefront instead of putting needless abstraction layers on top of it.

There’s the cheap personal attack

No, both Rust and Swift can be seen as better C++'s. And both do not provide the Smalltalk like OO Objective-C has. Swift (only) on Apple platforms integrate w/ ObjC, but the core language is more like C++ and very little like Smalltalk.

I once built one in Swift 4, in part to see how multithreading via SwiftNIO and using copy-on-write datastructures would compare. It held up well against the C implementation, would be worth trying again against Swift 5.x. https://github.com/NozeIO/redi-s

The demo version now actually supports multiple rooms (I think the 4 or 5 last you clicked). The bigger issue usually is the lack of XOXC support (as the general API gateway lacks a lot of API features).

BTW: You can also get a refund. This is more to make sure that people actually try the thing before blindly buying something. Shrugs _does_ have limitations, so it's important to first test whether it fits the needs.

If you have them archived as iChat files on a Mac (Library/Messages/Archive), you could try Past: https://zeezide.de/en/products/past/

Thanks a lot! It is still lacking quite some functionality (check the FAQ for details), but we'll get there.

My primary goal for Shrugs wasn't better memory efficiency but a better user experience (i.e. using native controls, having multiple windows, quicklook, etc). It uses quite some memory because it does (too) aggressive caching and prefetching of messages (I have enough RAM, fast access was more important to me).

It is worth noting that the official Slack app has gotten massively more memory efficient about a 1.5y ago, its bad reputation comes from the time before that (when it easily used more than 1GB of RAM). (I think it still has other performance issues, but they aren't as big anymore, it is doing quite well IMO)

Having said that I'm working on improving memory consumption in Shrugs.app - it is a tentpole feature planned for v1.1 (it'll take some time until this will be ready though).

Oh, the original comment was about the WebKit wrapper. Well, that this is using as much memory isn't very surprising. Why would Slack use less memory in a WKWebView than in an Electron frame? It is essentially the same app (with the Electron app providing a set of extra platform integration benefits).

Any performance differences between the two approaches should essentially boil down to the Chrome vs Safari differences.

Safari happens to not be an absolute RAM hog ;)

Just looked up your app. Love the idea but still too many features missing, especially editing messages.

I'll keep an eye on it. I have no problems buying after it gets good enough. Thanks for your work.

Thanks! Yes, it is very 1.0 and lacks quite some features. Message editing falls in the same batch of work like the RAM improvements and will very likely be part of 1.1.

In the current state it draws into a pixel buffer array which you can then display on for example an epaper display connected to a Raspi or other embedded device.

1. No. Neither. It does all the drawing on its own. Right now even fonts.

2. I think he would like to make it platform agnostic that way (i.e. provide reusable parts), but no, not right now.

3. His primary goal is/was driving UIs on embedded devices and AFAIK wants to complete it at least for this task.

Disclaimer: In contact with @cosmo in some Slack, due to my SwiftWebUI project (which offloads a load of things to the browser, so his stuff is quite different / more complex in many ways).

I will be watching this. We can always use more better tools for making GUI on embedded. Especially ones that do their own rendering.

One of my plans is to play around with using and/or creating a custom flutter engine embedder like flutter-pi.

Interesting! I'm curious about this because I didn't see anything rendering to the pixel buffer array. Do you know where that code is? I tried looking for it.