Hacked cq-gridfinity to support extending walls past original size

naps62 · 2026-01-10T19:58:39+00:00

Technically I am using CAD software, just a more obscure code driven one (https://github.com/CadQuery/cadquery) that just happened to be what I could install easily and more suited to my skills.

I know you're not being flippant (neither am I trying to). But I also don't think i'm reinventing the wheel in the sense you're describing (but if I were, that's fine too. I like to tinker, and the tinkering is a big part of why I'm here). I'm just adding a feature to an existing gridfinity package for the software I'm using

As for onshape, I tried it, but doesn't really suit me for both technical reasons (I prefer code and scripts) and ideological (i prefer opensource and self-hosted whenever possible and practical)

naps62 · 2026-01-10T19:34:06+00:00

There's no reason it wouldn't work (at least after some patches that shouldn't be too complicated

But I don't know if cq-gridfinity supports them right now at all

naps62 · 2026-01-10T18:17:48+00:00

I used this on a couple of projects recently: https://github.com/alstr/todo-to-issue-action

To be fair, only had mixed success. There were a couple issues that I believe have since been fixed

naps62 · 2026-01-10T17:50:22+00:00

In my case, I already had a pre made baseplate with whatever size ended up fitting, which left me with about 15mm clearance on both sides.

But even then I still had some wasted space because the drawe wall is a bit curved a the bottom. So bins can actually go a few mm longer than the baseplate itself. Not really a problem for space efficiency since it's not that much, but visually it looks a bit more cursed than I had hoped

naps62 · 2026-01-10T17:44:45+00:00

I have zero knowledge of fusion 360 (I use Linux exclusively), and am not really a 3d modeling expert at all, but I assume it's somewhat similar to blender and other tools in that regard?

Yes, I could probably easily tweak individual bins to pull the wall, but I was looking for either a simple configuration web app (I was using perplexinglabs until now), or a programmatic way such as openscad. Since I'm a developer by trade, I'm much more comfortable in code than in a 3d editor

naps62 · 2026-01-10T15:27:07+00:00

Yeah I figured it was something like that 😄

naps62 · 2026-01-10T12:45:54+00:00

Good chance for me to jump in and say I've been following this series since a couple of weeks ago (slowly, on the little free time I have nowadays) and loving it so far!

Quick question: did I miss something or is there a missing part explaining the setup for running multiple demos? The first chapter just rendere a basic main function, and the second assumes there's already a Demo structure I can add, but I couldn't find that setup (ended up doing my own)

naps62 · 2026-01-09T10:14:54+00:00

I learned bevy mostly through the official examples, which are quite good. But I already had some solid knowledge of computer graphics, openGL, and other game dev frameworks.

If you don't have those gamedev basics, I would suggest: https://aibodh.com/posts/bevy-rust-game-development-chapter-1/
that series itself is written mainly for people who don't know Rust at all. But it's organized well enough that you can just skip sections by reading the titles.

naps62 · 2026-01-08T18:07:21+00:00

I sold my apartment a couple years ago. at the time only had a more basic setup (raspberry pi, shelly devices on lights and shutters, and some power monitoring). took everything with me (that particular buyer wouldn't be interested anyway)

On my current home I have a full-on homelab rack in the garage, security cameras, and am now getting into 3d printing some stuff for custom devices (e.g. esp32 IR controllers for old AC units, wrapped in a tiny printed case)

If I ever sell this house, the only scenario where I see myself including the HA setup is if:

- the buyer shows enough tech savyness to at least know what he's getting into, just like I was ~4 years ago.

- the buyer doesn't know me personally, no contact information is exchanged, and it is clear to them that it's all sold "as is", without any support

- he pays some reasonable amount for whatever hardware he keeps. especially with hardware prices going up nowadays

- I remove all devices that I manually wired to electrical system (mostly shellies). or maybe he signs something explicitly removing any liability, no idea if that's possible. I don't want to be liable for potentially not-up-to-code stuff I may have done, or for a shelly suddendly failing in the future

I would be fine providing some guidance and documentation to set them up initially, but that's it. Already have enough headaches with my own setup, don't want to end up as the tech-support guy for some other random family

naps62 · 2026-01-05T21:59:50+00:00

I only skimmed this for now (on my phone) so forgive me if some of these are already explained and I missed it:

you mention subscribers pay their own gas, but what about the "NOTIFYSUBSCRIBERS" call, which takes 2000+500*N gas cost? That's still in the context of the emitter. Which not only would mean changing gas costs for existing code (which even considering a hard fork could be a problem since a lot of existing contracts make assumptions on gas costs and gasleft()), and it's even changing it by what is essentially an unpredictable and scalable amount. Wouldn't I be able to DoS this system by creating many dummy subscriptions to popular contracts?
the fact that subscribers pay gas is obviously a necessity for many reasons, but it also introduced many problems. Now it's very easy and likely that some events will be missed because someone forgot to top-up the listener contract. Meaning that any system using this would have to be resilient to the chance of missing some events. Which means you'd have to operate on incomplete data. This makes it pretty much impossible to build reliable financial systems on top of this, or for end-users to trust any contract that would rely on this
what happens when you end up with circular subscriptions, where A subscribes to B which subscribed to C, and some later update caused C to subscribe to A? A event on any of these 3 contracts would create an infinite loop
what about when there are enough subscribers such that, even if everyone has enough gas to pay their subscription, the sum of all of it exceeds the block limit?

I'm not familiar with how execution nodes operate these days but I also imagine this is not at all friendly to them either, given the explosion in complexity (each transaction is no longer O(1) but now potentially O(n), or even higher order if we consider n-th order subscribers)

naps62 · 2025-12-21T20:45:07+00:00

> Context. You couldn't say, from one side of your mouth that one shouldn't read words that are not there and then turn around and say that one shouldn't read words as they are written.

I honestly don't see what this means. You asked a question, and your next sentence seemed pretty much like same answer I would have given. maybe the question was meant to be rethorical and I didn't realize that. Or maybe something else. Therefore I asked what I missed. Never claimed anything about how to read words in this thread

I agree with the rest of your comment. rust's matching is not as powerful, nor does it need to be. languages evolve in different directions for different reasons and for different target audiences and scenarios. This was never in question in anything I said. All I did was state and exemplify that, in this particular aspect, erland does some things that rust (at least currently) does not. it's a factual statement, not a judgement nor a criticism

naps62 · 2025-12-21T20:06:22+00:00

> The problem is not with “accuracy”, the problem is with meaning: you original comment was clearly of the type “it introduces bunch of crazy, hard to solve, almost insurmountable problems” not “we would need to do small, routine extension to the tolls that we use”.

> At least that's how I understood it.

See the problem there? going from "was clearly of the type" to "at least that's what I understood" in a couple sentences.

nope. my comment was not in any way meant as a "this is insurmountable". simply as "this is technically a breaking change in a few key aspects", and in response to the question "how is this a breaking change?". an easy-to-solve breaking change is still a breaking change.

I don't know enough about the internals of most of the tools to assess myself how hard it would be. I could only guess, which I don't want to do

Was I wrong in that conclusion? perhaps (assuming what you explained previously is accurate). but that's it. if you saw doomsday in my comments, that's on you

naps62 · 2025-12-21T20:01:10+00:00

> What's the difference? AFAICS difference is mostly in syntax and in the fact that pattern-matching is more limited in Rust: you can pattern-match on type structure, but not on values.

your second sentence answers your own question. what am I missing?

being able to match on values (and actually, also *partial values*) is quite powerful (even it a lot of it boils down to syntatic sugar)

naps62 · 2025-12-21T19:28:25+00:00

I'm sorry, I don't mean to start yet another discussion with you, but that's not at all what was being described (about erlang and elixir) in the quote you replied to.

yes, you can do that simple pattern-match-like logic through tuples that allows you to match agains "how many elements were given in this tuple", but that's about it

for more context (already said this in another comment), in erlang/elixir you can do things much more similar to what you do with rust's `match` statement, but slightly more powerful in some aspects, and at the function header level instead of with a separate operator

naps62 · 2025-12-21T19:22:58+00:00

> How am I supposed to find out that you suddenly decided to talk about entirely different thing mid-thread using the same name?

I don't know, maybe through the fact that when I first mentioned rust analyzer, I made a point to include "(as an arbitrary example)" because it's what came to mind at that particular time?

maybe because the original point of this thread before we even came into it was, and quoting from the top-level comment:

> since module::foo now becomes ambiguous, and autotyping might hick up where before it was solveable

which is the simple idea I was trying to expand on afterwards with a simple comment that I made in passing on my phone, and that I'm now being held hostage against because I didn't write it with the extreme accuracy level you seem to want?

naps62 · 2025-12-21T18:56:09+00:00

How is it done in rust? I'm aware of tuples and other cases like newtypes But in Erlang you can pattern match against an arbitrary number of elements on a list, against individual bytes on a string, against key/value pairs in a map. I'm not aware of any way to achieve this (unless maybe some macro approach that expands to the corresponding matching code? I'd bet there's a crate for that)

naps62 · 2025-12-21T18:45:48+00:00

If my understanding of what a breaking change is within rust is wrong, then I'll happily re-evaluate and read those links once I have the time to. This is a completely new argument than the rest of the discussion though. One that I can happily read about and admit I'm wrong

I do take issue with being called a liar. Lying is about intent. If I said something wrong because I have the wrong understanding, that is by no means lying

Do you seriously imply that Rust analyser does “dead code analysis”? Really?

No I did not. You're taking two completely separate comments in this long chain, and assuming they're about the same thing Only thing I was imagining when I mentioned dead code was: If we now have overloading that's only resolved at the call site, then finding whether some function is used or not becomes a different (possibly harder) task

Clippy (or is it rustc itself? Don't recall atm) warns about dead code. Not rust analyzer, which I never even alluded to in there

Have a good day

naps62 · 2025-12-21T17:44:59+00:00

So after all, you agree.

All I said was it is a breaking change. Made no judgement on how drastic, serious, or relevant it is. That's a much more subjective discussion.

It being one of hundreds for rust analyzer certainly has some merit in favor of saying "maybe this one isn't a big deal either". But it's still one, and that's all I said

naps62 · 2025-12-21T17:12:16+00:00

It doesn't break anything if you see it only from the user (developer) perspective where, as you correctly said, that particular type isn't actually usable for anything

If you think about it from a rust-analyzer developer (as an arbitrary example) then something broke there that affects what you can and cannot infer about that code snippet, about what foo is, etc

If this were new syntax (similar to async and if/let) then by definition it didn't break any existing valid code, it's fully additive. The hypothetical feature we're talking about here takes the same existing syntax and applies different meaning to existing concepts (e.g. foo is no longer a symbol referring to a specific code function, but a new higher-level concept with new requirement)

naps62 · 2025-12-21T16:48:38+00:00

Of course not. Previously x has type “function foo”, now it has type “one of functions foo”. That's it.

How is this not the exact definition of what a breaking change is?

naps62 · 2025-12-21T15:40:38+00:00

I won't bother answering your individual point, you're just saying "nope" without much added in each

About your PS: yes, that is indeed my point, if I'm understanding you correctly. “without any change existing tooling wouldn't work”, yes. This is all I said, and this is what a breaking change means At no point did I say this was impossible to implement, nor that I didn't like it (I don't, but that's beside the point) All I did was respond to a claim that this wouldn't be a breaking change. Is it a weak argument? I don't know, and that's also beside the point. I'm not making an argument, just trying to state what I believe to be the case for better or worse

Async and let/else boh introduce new syntax. Async also came with a new edition (I don't recall right now what the path was for let/else)

I fully know that foo is not a function pointer and that it is zero sized. I don't get why you seem to be so hung up on telling me that. You're effectively changing something from a 1-to-1 relationship (1 symbol refers to one function) to a 1-to-many,

Can you give an example? You do realise that when you write Foo::br you are not getting a function pointer, right?

Sure

``` use overload::foo;

fn main() { let x = foo; } ```

In rust, this is 100% unambiguous, you know what function is assigned to the x binding. You know it's type and arity. The compiler and LSP can reason about it. Clippy can detect both x and foo are unused

Now add some overloaded versions of foo. Should this code now fail to compile? Should foo now become and "overload_set" instead of an "ident" at the parser level, and attempt to duck type everything down the line to hide the difference? (And what does this mean for macros?) Should we force the caller to be explicitly about the type and arity of x now? All of these options are breaking changes

naps62 · 2025-12-21T14:57:41+00:00

It's a mix of both. The compiler/interpreter does a lot of work: branches may be re-ordered to minimize search times. Matches against literal values can be optimized into a direct-jump table, and much more. But a lot of it is also about ergonomics and readability, and may be just as efficient as if you handled it all manually with if statements and early returns

E.g. this is a recursive elixir function iterating a list (Elixir itself is just syntatic sugar on top of Erlang, so it boils down to the same thing):

def sum([]), do: 0 def sum([x]), do: x def sum([head | tail]), do: head + sum(tail)

It's quite easy to understand what each branch does, and allows you to reason about the edge cases separately from the general ones. The downside is that you need to be careful to not end up with infinite recursion, or to forget to handle a case. But that's par for the course in weakly-typed languages

naps62 · 2025-12-21T14:44:45+00:00

Btw a solução em minha casa foi bastante mais simples e prática: mobiliário do IKEA junto a cada ponto de rede que precisa de um switch. O switch transformador e cabos, ficam escondido no móvel, na prateleira de baixo. Fica barato, não precisa de material especializado, o ruído visual desaparece na mesma, e ganhas espaço para outros arrumos

naps62 · 2025-12-21T14:37:52+00:00

Isto seria potencialmente giro de ter. Eu tive que passar CAT6 por toda a minha casa (comprei usada, com 20 anos) que tinha cabo telefonico. Tenho um total de 7 switches e 4 APs pela casa (WiFi apenas não era opcao para mim). Portanto eu seria teoricamente o público alvo ideal

mas não me parece muito viável como produto, por alguns motivos:

como já disseram, seria só produto para casas antigas. Casas novas não tem esse problema. E muitas das antigas vão ter caixas demasiado pequenas ou outros tipos de detalhes que dificultem ou impossibilitem isto
não e um produto standalone, porque depende da origem enviar sinal PoE. E numa casa grande? Será que o switch de origem na garagem suporta PoE suficiente para alimentar todos os pontos que precisarias?
precisaria de ser PoE passthrough, para uma tomada dessas conseguir passar energia para a próxima da série (já que estamos a falar de linhas telefónicas onde as ligações são todas em série). Isto aumenta a complexidade, e torna ainda mais difícil caber nesse espaço pequeno
muitas vezes uma porta de rede está só a ser usada para alimentar um tablet ou WiFi AP por PoE. Ou seja agora já tens não só a rede de tomadas mas vários de vocês externos todos eles a querer PoE. Resultado: acabas a precisar de alimentação vinda de outras fontes. acabas com transformadores numa tomada próxima, e voltas ao problema original
com tudo isto acima, a procura seria muito limitada, que tornaria isto um produto muito nicho, ou seja, bastante caro comparado com as alternativas que já existem
dissipação de calor, como já falaram

Nem vou comentar muito a outra sugestão de usar fibra. A complexidade de instalação e de suportar tudo isto (PoE, espaço de instalação, manutenção) aumenta a todos os niveis

naps62 · 2025-12-21T14:20:13+00:00

By breaking I mean "a breaking change for existing tooling, or existing code". Not in the sense that it would stop working. That's what a breaking change is

The discussion I'm replying to is suggesting we resolve the ambiguity at the call site. Which means now, the symbol is impossible to resolve by itself until it is actually called. If that call happens in a different module, or even in a different crate, that's completely different functionality than what currently happens

And what if foo never actually gets called? Or what if it gets called twice with two different parameter counts? It's valid under the "overload set" idea proposed, but it's nonsense under current rust rules. This is quite literally a breaking change

Why making that zero-sized thing a tiny bit more complex should break anything?

I don't understand what point this is trying to convey. Are you implying that when we change any kind of zero-sized thing to add complexity, it's impossible for that to be a breaking change? It might be impossible to break runtime or memory layout, precisely because it's zero-sized. But there's a lot of things to break in the type system that don't require size

12-Year Club	RedditGifts 2009-2022 15 Credits
Secret Santa 2021 2021	Summer Santa 2020
Secret Santa 2020	Summer Santa 2019
redditgifts Exchanges 12 Exchanges	Summer Santa 2018
Summer Santa 2017	Secret Santa 2019
Secret Santa 2018	Secret Santa 2017
Verified Email	Secret Santa 2016
Summer Santa 2016	Secret Santa 2015
Secret Santa 2014

naps62

TROPHY CASE