coxmi · HackerTrans

I wonder what the dev/CI process looks like on this.

Will it ultimately be manually loading a build into specific hardware each time, or is there a level of automation that can be done here?

coxmi

11 天前discuss

Thanks for the detailed answer :)

All this does for me is raise the question of why they chose to use the `.` for so many different uses. I'd be fine if it was just to infer the type, but it seems very overloaded.

coxmi

11 天前discuss

Yeah, after looking it up, it looks like it is basically only used as either field access or an 'infer operator', is that right?

I thought it was used in four completely separate ways:

· normal struct field access

· anonymous struct definition

· field definition within structs (for reasons to do with the parser)

· an extra 'infer operator' for syntactic sugar

But there's no support for anonymous structs/fields, and all structs and fields require a type somewhere for it to be inferred. Which is why this is invalid zig:

  const test = .{ .x = 0, .y = 1 };

(It would need the type to be specified in the called function definition, or inline when assigning)

Correct me if I'm wrong here! (And thank you)

coxmi

11 天前discuss

The dot syntax used everywhere really confuses me. I get its use in struct fields, or for defining anonymous structs, but what is this one for? (Some kind of module-level enum space, where .sampler and .unknown are defined previously?)

  const Sampler = @SpirvType(.sampler);
                             ^

  const Image = @SpirvType(.{ .image = .{
    .usage = .{ .sampled = u32 },
    .format = .unknown,
              ^
  } });

Everything else about zig is quite readable, but this gets me every time. Maybe I'm being dumb though.

coxmi

26 天前discuss

Great stuff!

I can imagine the financial modelling side is a particularly difficult balance, yeah. Mod support sounds amazing though, I'll keep a look out. :)

coxmi

26 天前discuss

This looks great. I've had a quick look through the docs and can't see anything about bikes under transport, or, under housing, anything relating to modes of tenure that aren't private rentals (e.g. Vienna-style social housing, housing co-operatives, or private ownership). Would be lovely to play around with those variables.

Also, for finance, is there a particular reason why the finance sector calculations look quite simple (on the face of it, at least)? They seem only to be a percentage lift based on aura, rather than anything resembling any number of complex sectoral dynamics, from full rentier-financial domination to prudent support of industry/services.

coxmi

3 個月前discuss

Nice project!

I’ve been doing something very similar recently[0] with slightly different goals (still a tiny bundle size, but fully typed uniforms, deeper control over buffer bytes and layout, and less setup than raw gl).

Some in the comments seem to think GL is dead, but for me I think it’s just an easier shader language for beginners and that’s most important for dabbling and many small web use cases.

[0] https://github.com/coxmi/gleasy

coxmi

4 個月前discuss

The point of civilisation, however loose that idea may be, if it’s anything at all, is determined by people.

Technology exists today in a way that feels like it could be defining its own path in a sense, but much like oral tradition, neither are large enough concepts to describe civilisation.

coxmi

4 個月前discuss

This is an insane claim:

> The entire point of civilization and society is that we are all "addicted" to technology and progress.

Technology is like much of material reality, in that we can think whatever the hell we like about its various forms, especially so if we’re surrounded by it.

coxmi

4 個月前discuss

Is there a general preference for serifs, or a local style in Finland for this reason?

German certainly has typographic preferences that err toward taller x-heights and narrower forms due to heavy use of portmanteaus. It’d be interesting to know of other language-specific typographic styles too.

coxmi

5 個月前discuss

This sounds really interesting, do you have any more info or a repo to follow?

coxmi

10 個月前discuss

> Every Noise at Once was a long-running attempt at an algorithmically-generated, readability-adjusted scatter-plot of the musical genre-space, based on data tracked and analyzed for 6,291 genre-shaped distinctions at Spotify through 2023-11-19. The calibration is fuzzy, but in general down is more organic, up is more mechanical and electric; left is denser and more atmospheric, right is spikier and bouncier.

> Click anything to hear an example of what it sounds like.

> Click the » on a genre to see a map of its artists.

> Be calmly aware that this may periodically expand, contract or combust.

coxmi

10 個月前discuss

Nice to know i’m not alone, I’m sure there are dozens of us — dozens!

coxmi

10 個月前discuss

I’d go further than this and say globally-scoped CSS is fine as long as you’re using a decent naming pattern (e.g. BEM), or @layers.

For me, back in the JQuery days, the problem was always globally-scoped JS/DOM, rather than CSS. The big revolution was simply co-locating/importing styles in JS modules during the compile step, which works surprisingly well even outside of any framework.

Just using vanilla DOM or a small wrapper around web components for connectedCallback/disconnectedCallback logic is refreshingly simple. It’s quite sad that most SSR frameworks don’t allow this sort of approach, and lock you in to a specific front-end library.

coxmi

10 個月前discuss

rsync needs some love on this.

The most memorable args for me are `-mrchivas`, because together they sound somewhat like a name (“Mister Chivas”)

(I drop the -a depending on whether archive is needed, Mr. Chivs sounds fun too)

coxmi

10 個月前discuss

Ooo nice, I didn’t know about this. Thanks for posting, looks interesting, and framework agnostic to boot :)

(Edit: well, potentially at least)

I did try to make something like this a couple years back to deal with multiple renderers and a choose-your own set of various SSR techniques [0], but didn’t get very far with it in the end. I should have based it on Hono really, to get web standard Request objects.

[0] https://github.com/coxmi/ssr-tools

coxmi

10 個月前discuss

That’s a shame, I’ve also been through much the same process.

Astro is pretty good too, though. I’m not 100% sure on some of the decisions it’s made, and personally don’t enjoy the need for new file formats and domain specific languages, but it does a half decent job of being framework-agnostic despite a few pain points.

coxmi

10 個月前discuss

I don’t disagree on that front, the React ecosystem is huge, and rebuilding a load of complex components is often beyond the budgets of many greenfield projects.

I also don’t believe a React monoculture is good, so a growing Preact or Solid ecosystem would be really positive, alongside growing web/DOM standards to ultimately make these frameworks more of a light wrapper around some trivial updates.

React and Next.js, to me, have done the typical architecture astronaut thing, and it feels like they’ve both increased the barrier to entry and just made everything a little more complicated than it really needs to be for much of the web.

coxmi

10 個月前discuss

Deno Fresh seems like it has the right approach. It’s not complicated, the docs are refreshingly simple, and it handles both server and client logic without getting confused.

It’s just a shame it’s Deno-only (although I completely understand why)

Submissions

Every Noise at Once

comments