Mastodon Feed: Posts

Boosted by soatok@furry.engineer ("Soatok Dreamseeker"):
nightdragon0@fursuits.online ("Hyshaji Nightdragon") wrote:

Always fun looking back at good times!
#fursuit #fursuiting #fursuitfriday

📷: Gryphonfluff

Boosted by soatok@furry.engineer ("Soatok Dreamseeker"):
GameFromScratch@mastodon.gamedev.place wrote:

Looking for a long weekend activity? How about learning Godot #Gamedev with this just launched Humble Bundle from @gamedevtv. It also includes a few made in #GodotEngine games including Buckshot Roulette.

GFS supporting link - https://humblebundleinc.sjv.io/GodotGameDevTV2026

ireneista@irenes.space ("Irenes (many)") wrote:

we would go so far as to say that our strategy for making code maintainable is to make it aesthetically pleasing. it's easier to remember its details, and to feel a sense of investment in it, when it is.

this may not be the only possible strategy, but it's ours...

ireneista@irenes.space ("Irenes (many)") wrote:

please notice how we really, really mean it when we say this is artistic expression to us. like, this is a challenging technical problem, but these are aesthetic judgements we're making.

ireneista@irenes.space ("Irenes (many)") wrote:

yeah okay, we've chewed on all of those enough. we're going to go ahead and do some minimal state-tracking that we think we need no matter what, and generate the output that's most directly doable with that tracking, and see how we feel about what's still missing after doing that

Boosted by NfNitLoop ("Cody Casterline 🏳️‍🌈"):
zwol@masto.hackers.town ("Zack Weinberg") wrote:

"LLMs are a safe tool for code generation as long as you always carefully review the output" is the same flavor of programmer hubris as "C is a safe language as long as you always carefully check for all the mistakes the compiler won't catch."

jwz wrote:

Dear Lazyweb,

1. Can someone please look at xscreensaver/configure.ac and explain to me what I need to do to get past "AM_GNU_GETTEXT not found in library" on e.g. Debian 13.5.

2. Can someone please rewrite xscreensaver/po/Makefile.* to not be complete garbage, because it's 20 years old, pure evil, and I have never understood it.

Boosted by isagalaev ("Ivan Sagalaev :flag_wbw:"):
yangmusa@pixelfed.social ("Fair Fowl") wrote:

Sunrise on California Street. It was cloudy all week, so I wasn't sure if I'd go - but it turned out clear so I'm glad I did! #photography #streetphotography #sanfrancisco #sunrise #city #darktable #olympus #em5ii #microfourthirds #m43

Boosted by aredridel@kolektiva.social ("Mx. Aria Stewart"):
Catvalente@wandering.shop ("Catherynne M. Valente") wrote:

Every once in awhile, in the midst of my nights, I’m struck dumb with awe and a strange, refracted grief:

It’s legitimately fucking *crazy* how good the internet used to be

Boosted by cstanhope@social.coop ("Your weary 'net denizen"):
guilhernunes_@mastodon.art ("guilherme nunes") wrote:

The cat didn't want to go to work and is jealous of the cat that was abducted.

ireneista@irenes.space ("Irenes (many)") wrote:

several of these approaches would work, we want to be clear, what we're trying to decide is which one we like

ireneista@irenes.space ("Irenes (many)") wrote:

do we need a tagged-annotations concept? weird to do that in a language with no AST

ireneista@irenes.space ("Irenes (many)") wrote:

a notion we had a while ago, which was attractive in the abstract, was that it would be sufficient to just output all the ordinary comments from each output-producing word, each time they run. we've now gone and actually looked at what that would mean, and no, that's not appropriate, there's a lot of comments concerned with internal flow-control details which are definitely needed when maintaining those words, but won't be relevant to the hex dump.

aredridel@kolektiva.social ("Mx. Aria Stewart") wrote:

RE: https://hci.social/@amyjko/117191734905239704

Interesting approach!

glyph ("Glyph") wrote:

I really missed an opportunity to give the bot a more specific instruction, like a comment to leave

Boosted by glyph ("Glyph"):
donni ("donni saphire") wrote:

Are you depressed or are you simply aware of various situations

glyph ("Glyph") wrote:

welp, "amasen02 closed this 13 minutes ago"

ireneista@irenes.space ("Irenes (many)") wrote:

... or maybe we want a syntax used from within the assembly words, which describes the appropriate annotations there, but does nothing unless it's under the transform? that might be the most maintainable way...

Boosted by glyph ("Glyph"):
glyph ("Glyph") wrote:

@farah @donni I’m at paralysis, I’m at the overwhelm. I’m at the combination overwhelm paralysis

Boosted by jwz:
jef ("Jef Poskanzer") wrote:

Yesterday's Daily Cal was almost 100% about the use of generative AI in campus and city writing. One article mentioned they fired some staffers for using AI.

You will never guess what full page ad is on the back.

Boosted by jwz:
AnarchistArt ("Anarchist Art Ⓐ") wrote:

ireneista@irenes.space ("Irenes (many)") wrote:

though... we have a lot of unused flag bits in the word entry header. we could allocate a few of them to this. hm.

ireneista@irenes.space ("Irenes (many)") wrote:

our real goal here is to not have to list off every single word that is used in encoding assembly language. we could do that, but it would make it a lot more painful to refactor our Forth-assembly language. we would very much like to find a way to programmatically determine which role each word serves, from some small taxonomy of roles.

ireneista@irenes.space ("Irenes (many)") wrote:

.... no, no, we don't need to worry about that, because the point at which we want to insert the annotations is actually when the lowest-level output-producing word is called, and there's an extremely small set of those. what the tracing logic should be doing is gathering information that can inform what the annotations say, when they're inserted. hm. okay.

glyph ("Glyph") wrote:

@jwz still not quite there yet but “individual patches over email” is looking better every day

ireneista@irenes.space ("Irenes (many)") wrote:

ah. right. we have an additional problem: we need to peek at some internal state of label-loop to figure out where the current output point is. hmmm.

jwz wrote:

@glyph

Boosted by aredridel@kolektiva.social ("Mx. Aria Stewart"):
geekysteven@beige.party wrote:

ireneista@irenes.space ("Irenes (many)") wrote:

we're doing this to get some intuition for how we can identify the ones we care about as they happen

it's looking like we might find it useful to have some sort of "already handled" flag that suppresses processing of annotations for the inner calls when an outer one has logic that should override it?

ireneista@irenes.space ("Irenes (many)") wrote:

okay, we had to tweak our stack-walking code a bit because of the layering stuff, but now we're looking at a trace of all the calls that occur inside the transformed code, trimmed to only the portions of the stack that are within it.