Cy @[email protected]

So uh, anyone here a #parent and doesn't give a fuck about it? All I ever see are Proud Moms and Cool Dads, all lucky enough to have some Awesome Kids. I think it's because parents who base their whole identity on parenthood will talk about it more than the people who just... happen to be parents, but is there more to it? There isn't a stigma, is there? Far as I can tell, people who are crazy about parenthood aren't the greatest parents, so I don't think there's a stigma?

That only happens if:
1) you use my insel hack
2) your primary key has keys in other tables constrained to it via foreign key
3) PRAGMA foreign_keys=1
4) you try to change its id, which would invalidate the id on those other tables
5) those other tables don't use ON UPDATE CASCADE (I think)
So that's probably why I'm the only one who ever ran into this before.

The reason being that the (integer) primary key in sqlite is auto-increment, so if the (bar) conflict happens to a row with id = 4, for instance, EXCLUDED.id will be 5 or higher, the potential new id that doesn't exist in the database yet. So if you have a foreign key constraint that requires foo.id to have a matching anothertable.id...

CREAT TABLE FOO (id PRIMARY KEY, bar INT UNIQUE);
INSERT INTO foo (bar) VALUES (?1) ON CONFLICT (bar) DO UPDATE SET id = EXCLUDED.id RETURNING id; -- FOREIGN KEY constraint failed
INSERT INTO foo (bar) VALUES (?1) ON CONFLICT (bar) DO UPDATE SET id = id RETURNING Id; -- OK
INSERT INTO foo (bar) VALUES (?1) ON CONFLICT (bar) DO UPDATE SET bar = bar RETURNING id; -- OK
INSERT INTO foo (bar) VALUES (?1) ON CONFLICT (bar) DO UPDATE SET bar = EXCLUDED.bar RETURNING id; -- OK

hokay, so when hacking #sqlite, since #SQL is stupid and there's plenty of support for upsert, with no one talking about insel, be sure not to use update excluded on the primary key when using my sqlite insel hack.

right, so when you do `MACRO(a, b + c)` make sure it becomes `allocate(a * (b+c))` not `allocate(a * b + c)`.

Sweet, now it works!
And... now I've got a double free error, freeing data right after calling a callback, set in a totally different thread...

OK I'll just set `child->has_any_position_at_all = FALSE` to force the update and... huh, it actually worked. Editing the profile updates the item in the grid view. Sweet!
Only possible improvement to that is to use a separate query entirely to update, depending on if the aspect ID is already known, to avoid doing the complex search query just to update that item.

OK so... auto-avatars are working, and don't look awful. Any bright ideas as to how to make a thing that lets you differentiate public key fingerprints at a glance are welcome. Still no client logic, so can't get posts from elsewhere, but at least it has... webfinger?
#programming #C

...the more I think on it, the less this sounds like a heartwarming tale, and the more it sounds like the plot of a horror film.

My mother got her first cat shortly before giving birth to me and giving up all her dreams. Sim-mah was a wild cat who just jumped right up into her camper van and went inside like she owned the place. She was never a very nice cat, but my mother still fell in love with her. My mom's always struggled with cat allergies, but she had already become such a fierce cat lover that she put up with a terrible sinus infection from Sim-mah, the first year. You know...

I'm half inclined to just toss that rotten view/model thing and do it myself, but making a grid of items is easy. The hard part is responding correctly to mouse clicks and drags to select items.

The GtkGridView has activated, and I can get the item for the model of that view, except models are required to be RAM allocated arrays of items, so my model doesn't store anything, since the items are populated via a dynamic database query. So I need to get the actual GtkListItem that was activated. To do that, I just uhhhhhhhhh
#gtk devs: uhhhhhhhhhhh

#triggering #boundaries Just got a message from @Ethancdavenport that I am not "welcome" to follow him anymore, because I replied when he "clearly" didn't want engagement. So if you follow him, please do not engage with him if he doesn't want it, and be aware that "do not read" is a requirement, not a warning. I think this is an exception, so in general please do lend your sympathy for people who are upset, unless they explicitly say they don't want it.

> A GtkListItemFactory is supposed to be final - that means its behavior should not change and the first widget created from it should behave the same way as the last widget created from it.
No, that means you're an idiot and you defined an interface as a *final* class just so you can swing your e-dick around and brag that only you privileged gtk devs get to inherit from it, and everyone else has to use your crude hack the GtkSignalListItemFactory, to do the same thing.

Hmm. Actually, that should be a closure around a pointer. Actually, that should be a pointer to a closure. Actually that should be a closure by value. Actually augggh I am so sick of switching -> and . frikkin everywhere every time
#define PROP(obj, field) obj.field
#fml