groue - Network

C'est vrai que ça a l'air taloché avec les pieds...

C'est vrai que ça a l'air taloché avec les pieds 😬

#KerningCrime

https://www.reddit.com/r/typography/comments/1k90zg7/kerning_on_the_popes_tombstone/#lightbox

It is sensible indeed to respect the time spent on genuine, effective, plain work. I admire my friends who work more than I do. Not...

It is sensible indeed to respect the time spent on genuine, effective, plain work. I admire my friends who work more than I do. Not "work" as in "make some random person more wealthy", but as in "suck less at great stuff".
https://dindon.one/@henry/114392095581209241

On an app that I'm working on, the diff is +60/-105. The main benefit is that I coud remove a lot of verbose extensions on...

On an app that I'm working on, the diff is +60/-105. The main benefit is that I coud remove a lot of verbose extensions on DerivableRequest<MyRecord>. Now they are only needed when a scope would be needed in a Rails app (i.e. when the logic becomes complex, or when you want to encapsulate and hide database details). That's super cool :-)

> In order to avoid the breaking change, I'll have to choose a name that is not `Columns`.Ah this is difficult. I could ask users to...

> In order to avoid the breaking change, I'll have to choose a name that is not `Columns`.

Ah this is difficult. I could ask users to opt in for the new feature by renaming their existing `Columns` to, say, `TableComponents`. But there are still places where this type is used with its full name:

struct Player: FetchableRecord, PersistableRecord {
var id: String
var name: String

enum Columns { ... }

// Columns is used here
static var databaseSelection: [any SQLSelectable] {
[Columns.id, Columns.name]
}

// Columns is used here
init(row: Row) {
self.id = row[Columns.id]
self.name = row[Columns. name]
}

// etc
}

I need a name that is not `Columns`, and that could be used in the above sample code without seeming out of place. 🤯

I have a nice #GRDB branch that simplifies the definition of SQLite requests from Swift code: // 🙄 String-based (current state of the...

I have a nice #GRDB branch that simplifies the definition of SQLite requests from Swift code:

// 🙄 String-based (current state of the lib)
Player.filter(Column("score") > 1000)

// 😐 Enum-based (current state of the lib)
Player.filter(Player.Columns.score > 1000)

// 🤩 NEW
Player.filter { $0.score > 1000 }

It comes for free for record types that follow the recommended practices (i.e. define a nested `Columns` enum). 🎁

The commit that updates the demo app shows a nice win, at +9/-44 https://github.com/groue/GRDB.swift/commit/261c0ccf866029c0f65a88b881aabf46effc4f9e

The problem is that it breaks apps that define their records in packages/frameworks. The `Columns` enum must become `public` when the record type is, or the compiler won't compile it (even if its members are not public). 😖

In order to avoid the breaking change, I'll have to choose a name that is not `Columns`.

TableColumns? RecordColumns? Cols? Col? C?

In my own practice, this type sometimes contains expressions that are not columns, as below. Maybe the name should not refer to "columns", after all. TableLayout? TableComponents? SQLElements?

enum Columns {
// The date column
static let start = Column(CodingKeys.start)

// An expression derived from the date column
static let startDateUTC = SQL("date(\(Columns.start))").sqlExpression
}

🚀 GRDB 7.4.0, the Swift toolkit for SQLite database, is out.It is a recommended upgrade, because it solves unexpected database...

🚀 GRDB 7.4.0, the Swift toolkit for SQLite database, is out.

It is a recommended upgrade, because it solves unexpected database observation errors in applications that `await` the database from tasks that get cancelled. And we all prefer when database observation has no known bugs whatsoever! 🐞

Check out the link for the most recent releases:

https://github.com/groue/GRDB.swift/releases

@mattiem To address the needs of @layoutSubviews (and peers) expressed in https://mastodon.social/@layoutSubviews/114032891799577133, I...

@mattiem To address the needs of @layoutSubviews (and peers) expressed in https://mastodon.social/@layoutSubviews/114032891799577133, I could declare both "sending" and @‍Sendable variants of the async methods, depending on the compiler(>=6.1) directive.

But this is VERY MESSY. And I'm not talking about online documentation that does not match the actual declaration, the unstable DocC hashes, and all the nasty consequences of bugs.

So I'd better be sure of the kind of bug I'm looking at: a fixed one, or a future one. The only one I'll eventually forget is the fixed one.

@mattiem Minimum reproducing code: https://gist.github.com/groue/ab4dc13ae4b05f679008454169ea921b (fails with Xcode 16.2, compiles with...

@mattiem Minimum reproducing code: https://gist.github.com/groue/ab4dc13ae4b05f679008454169ea921b (fails with Xcode 16.2, compiles with Xcode 16.3)

@mattiem Hello Matt! If you have a few minutes, would you play a concurrency game?I was working on turning Sendable closures into plain...

@mattiem Hello Matt! If you have a few minutes, would you play a concurrency game?

I was working on turning Sendable closures into plain "sending" ones. The context is https://hachyderm.io/@groue/114029639111178668

I met a problem: this change breaks user code. The snippet in the screenshot stops compiling with Xcode 16.2. And it compiles with Xcode 16.3 beta.

It's difficult to untangle. I'm sure the code was correct with Sendable closures. Switching to "sending" closures should not change its correctness. But there is a bad interaction with isolation inference (I do intend the closure to be nonisolated regardless of the isolation of the caller, but the compiler says otherwise with "sending" closures). This bad interaction may be a bug that has been fixed in Swift 6.1. But I'm not sure if I’m describing the reality, or if I'm making things up.

Do you have an idea about the exact cause of the problem with "sending" closures?

cc @layoutSubviews @holly

More and more people are asking for SQLCipher support in GRDB + SPM.Unfortunately, this is beyond my skills. I'm not a build...

More and more people are asking for SQLCipher support in GRDB + SPM.

Unfortunately, this is beyond my skills. I'm not a build expert.

There is a PR in progress at https://github.com/groue/GRDB.swift/pull/1708 that seems like it is going in the right direction. But it is still not the pull request I'm hoping for:

🤩 Provides built-in SQLCipher support that works for 80+% of people.

🤩 No extra dependency (we must control the SQLCipher compilation options).

🤩 No binaries (they rot).

🤩 A clear documentation that tells users what to do to get GRDB+SQLCipher with SPM, written for people who are not build experts.

🤩 Testable in GitHub CI.

🤩 Runs the full GRDB test suite with unencrypted databases, AND with encrypted databases (we already do that for SQLCipher with CocoaPods).

🤩 Requires minimum efforts for debugging (one can debug tests from Xcode).

🤩 Requires minimum efforts for maintenance (i.e. bumping SQLCipher version and adjusting compile options when needed)

🤩 A technique thats enables SQLCipher support in companion packages as well (GRDBQuery, GRDBSnapshotTesting, RxGRDB).

That would achieve the level of quality I would expect from my favorites libraries (simply the best 🎵)

If you use GRDB and SQLCipher with SPM, and your solution checks some of the above items, please consider contributing your solution for all GRDB users!

cc @marcprux

I stopped trying with Java, because my Java is so rusty I can't write "Hello World", and I can't find it behind the cookie...

I stopped trying with Java, because my Java is so rusty I can't write "Hello World", and I can't find it behind the cookie banners.

It's even easier with Swift:1. Edit myprogram.swift in any text editor2. Run `swift myprogram.swift` in any terminal3. There’s no step...

It's even easier with Swift:

1. Edit myprogram.swift in any text editor
2. Run `swift myprogram.swift` in any terminal
3. There’s no step 3

I'm not sure what I was supposed to mean in my previous message 😅

Very rarely, I write a small C program. My C is very rusty. That's how I can tell that C can have great ergonomics:1. Edit myprogram.c...

Very rarely, I write a small C program. My C is very rusty. That's how I can tell that C can have great ergonomics:

1. Edit myprogram.c in any text editor
2. Run `cc myprogram.c && ./a.out` in any terminal
3. There's no step 3

https://sqlite.org/forum/forumpost/d1eebbd331

Trump reminds me of The Mule in Asimov's Foundation.

Trump reminds me of The Mule in Asimov's Foundation.

I complain about the compiler as if it were a technical issue, but all I want is that some people apply a strong pressure, from within the...

I complain about the compiler as if it were a technical issue, but all I want is that some people apply a strong pressure, from within the design team, and reorient the sea monster.

Since I'm a better citizen than the compiler, I created an issue: https://github.com/swiftlang/swift/issues/79083

Since I'm a better citizen than the compiler, I created an issue: https://github.com/swiftlang/swift/issues/79083

One more example of how hostile Swift 6 can be? I wanted to update RxGRDB (the RxSwift interface to GRDB) to GRDB 7. The RxGRDB package is...

One more example of how hostile Swift 6 can be? I wanted to update RxGRDB (the RxSwift interface to GRDB) to GRDB 7. The RxGRDB package is `swift-tools-version: 5.7`. The RxSwift package is `swift-tools-version: 5.5`. How could they state more explicitly that they don't even know about Swift 6? Well, compiler farts warnings nobody asked for, and nobody cares about: https://github.com/RxSwiftCommunity/RxGRDB/issues/72

FFS, I did not upgrade GRDB to Swift 6 and spent MONTHS sweating my concurrency annotations to be rewarded with such a stupid punishment. RxGRDB should be able to stay at Swift 5 without a f***ing single warning.

I don't have time for this shit work.

🚀 GRDB 7 is out, a joint effort by ten contributors! The new version blends as well with Swift 6 concurrency as you need it, and is ready...

🚀 GRDB 7 is out, a joint effort by ten contributors! The new version blends as well with Swift 6 concurrency as you need it, and is ready to follow you for the years to come.

Did you know 2025 marks GRDB's tenth anniversary? First commit was done on June 30.

#sqlite #swift

https://forums.swift.org/t/grdb-7-is-out/77465

@pointfreeco focuses on SQLite 🤩 They intend to teach a lot, from the low-level access to the C library from Swift, to the high-level...

@pointfreeco focuses on SQLite 🤩 They intend to teach a lot, from the low-level access to the C library from Swift, to the high-level conveniences of GRDB (woot!). It's great, because one can trust SQLite to take care of the precious users’ data more than everyone else, and database knowledge is just as suitable for front-end developers as it is for those developing back-ends. Finally… special thanks to @mbrandonw for saying my name _just right_ :-)

https://podcasts.apple.com/fr/podcast/point-free-videos/id1438330035?i=1000675545654

@ivory Hello! Quick issue report: I get this error message when I navigate to the Explore tab, enter a search string in the top field, hit...

@ivory Hello! Quick issue report: I get this error message when I navigate to the Explore tab, enter a search string in the top field, hit Search, push the results page (so far so good), and start performing pull-to-refreshes this these results. Not 100% reproducible on each pull-to-refresh, but quite frequent. It does not look like it depends on the search string.