<peepsalot>
InPhase: like, i would ideally forward both t and args, right? (and oss?)
LordOfBikes has joined #openscad
<InPhase>
Well at the args... as std::forward<Args>(args)...
<InPhase>
I hadn't thought about the << call. I suppose you can probably do: oss << std::forward<T>(t)
<InPhase>
I never tried this, but it's just a cast.
<InPhase>
Should work.
<peepsalot>
InPhase: well I just got to the point where the project compiles, but doesn't link. not sure why yet, but its complaining about multiple STR defintions
<peepsalot>
have I done it wrong in the paste I showed?
<InPhase>
peepsalot: Yep, you need to drop the word "inline" in front of the "std::string STR(scad::ostringstream& oss)" one.
<InPhase>
peepsalot: The templates are inline by default, and thus immune to the ODR. The other one is a plain function that you left in the header where the macro was most likely.
<InPhase>
Given the nature of the function, declaring it inline is also a very reasonable choice.
<InPhase>
The alternative would be the standard declaration/definition division for the one non-template, but I would not choose that here for this case of "return oss.str();"
EkpyroticFrood has quit [Quit: So long, and thanks for all the fish.]
EkpyroticFrood has joined #openscad
Sauvin has quit [Quit: Leaving]
grymzu has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
fling has quit [Remote host closed the connection]
fling has joined #openscad
J1A84 has joined #openscad
pah is now known as pa
<peepsalot>
well i got it to build and broke about 500 tests. i think i see what I did wrong, but its going to take some refactoring to fix, which will have to wait til tomorrow
ur5us has joined #openscad
lastrodamo has joined #openscad
ccox has quit [Remote host closed the connection]
ccox has joined #openscad
ccox has quit [Ping timeout: 268 seconds]
ur5us has quit [Ping timeout: 250 seconds]
little_blossom has quit [Ping timeout: 264 seconds]
gbruno has quit [Ping timeout: 252 seconds]
gbruno has joined #openscad
GNUmoon has quit [Remote host closed the connection]
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
GNUmoon has joined #openscad
little_blossom has joined #openscad
KimK_ has quit [Remote host closed the connection]
<phryk>
currently getting some sewing done, but in an hour i could use some pointers on how to refactor my top plates to accomodate the module grid while also strengthening it so it won't break with heavy modules hanging from it.
<J1A84>
infill and thickness?
<phryk>
infill means what kinda material i use?
<phryk>
thickness configurable, currently at 25mm, haven't settled on a final value.
<phryk>
my approach would be to break it up into a thinner plate and have a frame/grid on the bottom for structural integrity and mounts.
<phryk>
J1A84: https://paste.xinu.at/3EY/ screenshot of the latest version without strenghtening. the pink pins show where the mounting grid is supposed to be.
<phryk>
i.e. every pink pin there would become a pin in the surface, so i'll also need to recess the main plate a bit so there can be a rubber mat or something on top to have a straight surface without a bump every 5cm
<phryk>
err, become a *hole* in the surface.
<J1A84>
you can add an aluminum or steel grid beneath the pins.. or as a sandwich plate
<phryk>
sandwhich plate?
<phryk>
also i was thinking wood grid because I'm cheap ^^
<phryk>
you mean using that as a material for a frame/grid below the main plate?
<J1A84>
or you use two outside plates with 5 and 10 mm on top and some metal grid in the middle which is glued in with epoxy (but i assume that would be overkill) .. there are also composite plates with carbon and foam but these are expensive and only used for lightweight constructions
<Scopeuk>
Infiil is a slicer setting that defines how well filled the part is. It's what generates the patterns inside 3d printed parts
<phryk>
ah, nothing here will be 3d printed.
<phryk>
everything here is supposed to be wood and steel. tho there will be some plastic components involved in the final assembly. mainly those rack brush things as dust covers for the cable management openings.
<J1A84>
the grid pins will weaken the load capacity so it all depends on the grid distance
<J1A84>
or you use a sub structure
<phryk>
J1A84: you mean no holes in the top plate at all? i think that'll take away too much available depth
<J1A84>
maybe add a center cross with steel quad tubes to take some load
<phryk>
err height^^
<phryk>
that but with wood was my first idea, but now I'm thinking if i want wood for the strengthening, it might be more sensible to have one straight beam from left to right every grid unit.
<J1A84>
if your holes are 2cm and 10cm apart it should be fine .. bigger holes or closer will take away a lot of material
GNUmoon has quit [Remote host closed the connection]
<phryk>
holes are currently 5cm apart (on both axes). hole size is 8mm (or rather they should fit M8 screws, so maybe 9-10mm diameter)
<J1A84>
also a beam under the front edge connecting the legs will increase strength drastically
<phryk>
yeah, that would be part of the outer frame. then the frame would have cutouts on its top to accomodate smaller beams that would strengthen the construction everywhere a grid hole would be placed.
<J1A84>
so your holes are 3× smaller but you have 4× the amount so this will weaken more
<phryk>
yeah, but as i don't have any data *how much* any of this would weaken anything, i don't really have much to base my decision on…
<phryk>
fem solver integration when? :P
<J1A84>
you don't have a number how much load it should hold Ü
<phryk>
i don't have a number how much load it *can* hold.
<J1A84>
the plate have specifications for that
<phryk>
it *should* holy ~300kg, 200 of those in modules hanging underneath.
<phryk>
nowehere i've seen, also not with holes in it, even less so with some custom-made frame beneath it…
<phryk>
this desk will be held together pretty much only by steel pins, i can exchange any component…
ccox has joined #openscad
<phryk>
being able to dis- and reassemble everything without weakening the material was one of the central design decisions.
<J1A84>
so your desk surface is not a static element? .. so you can remove it and everything would still be working (the modules .. legs etc)
<phryk>
so no screws that are just screwed directly into wood and the like, pretty much nothing that'll get glued (module rails will be, but that's the only thing)
<phryk>
kinda-sorta. with the design as it is right now, it would fall over. :P
<phryk>
with the frame/grid thing i'm planning on adding you would have to remove the module rails but things would remain standing.
<phryk>
pretty sure with that clearing the desk surface itself would still be the majority of time it'd take me to exchange the top plate :P
<J1A84>
as your modules will make ⅔ of the load - i would but the rails on the back and front frame that is connected to the legs to get the load/force into the ground
<J1A84>
put/but
<J1A84>
and have look at the festotool system as with bigger holes you can put clamps through the holes
<phryk>
not really possible. the rails are supposed to be removable.
<phryk>
not my use-case… i don't need clamps. this is more of an IT thing. integrated cable management. modules for things like 19" racks…
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
<JordanBrown[m]>
teepee you there?
<teepee>
yep
<JordanBrown[m]>
(Sorry, got distracted and looked away.)
<JordanBrown[m]>
What are your thoughts on alternatives to $ variables for programmatically controlling the camera and the lights?
<teepee>
no worries, that's why it's chat not a phone call :)
<JordanBrown[m]>
I understand the CLI alternative for some purposes, but programmatic control seems useful too.
<teepee>
I have no good idea for writing yet, for reading I think it should be a function call returning a data structure now
<teepee>
like for animation we have $t but we probably want some more info, basically going into the direction of what shadertoy has as parameters as that seems to give quite good control
<teepee>
having $ variables for that is just confusing both from grabbing the namespace and also it's a static value, so if some code overwrites the $variable it's just bad
<JordanBrown[m]>
There's a namespace problem no matter what, absent new syntax. (And I would go there only as a last resort.)
<JordanBrown[m]>
I'm not sure why you say that if something overwrites the $ value it's bad.
<JordanBrown[m]>
It seems like it's fine if exactly one place overrides the $ value. The problem is if two places do, since the camera can only be in one plage.
<JordanBrown[m]>
place.
<teepee>
if you pass a module via children() into a library and use the $variable in that module, the library can overwrite that $variable and you never see the original value
<JordanBrown[m]>
That sounds like the problem I described of two places setting the variable... right?
<JordanBrown[m]>
The camera position is a global, and OpenSCAD doesn't have globals.
<teepee>
yes, for one render the camera can be only at a single place (well, or 2 if we get the stereo stuff merged :)
<JordanBrown[m]>
I suppose we could have a new builtin module setCamera(), that errors if it's called more than once.
<JordanBrown[m]>
Stupid C++ question: is the declaration of a class required to declare all of the methods of the class, including ones that are totally internal?
<teepee>
I don't think we should ever have any "action" command, it's just too misleading
<teepee>
declare methods, yes, I think so, but C++ allows more things like free functions to extend behavior
<teepee>
e.g. streams << can be declared as free function taking the stream and the object
<JordanBrown[m]>
I don't mean extending behavior, exactly. I mean that if I have some public method M, and I want to refactor it so that M calls internal implementation methods M1 and M2, I have to put M1 and M2 into the declaration in the header?
<JordanBrown[m]>
I know I can mark them private, but having to rebuild the world when their declaration changes is a pain in the neck.
<teepee>
that's what c++20 modules intend to solve
<JordanBrown[m]>
:-( but thanks for the confirmation.
<JordanBrown[m]>
As for "action" commands... yeah, but... we don't really have anything that is a good match, so either we come up with a new concept or we abuse an existing one.
<teepee>
question is if annotations would work ok. I'd say some sort of meta data will be needed anyway
<JordanBrown[m]>
What exactly do you mean by an annotation?
<JordanBrown[m]>
Kind of like a C pragma?
<JordanBrown[m]>
But: you want to be able to set camera and lights based on calculations made by the program, and so the mechanism for setting them needs to logically execute as part of the program, not as some kind of external metadata.
<JordanBrown[m]>
New syntax certainly gives new options. I'm not sure whether what I see there in a very brief look lines up with the need, because the need for this case is *not* a decoration. Or at least I don't see it as a decoration.
<JordanBrown[m]>
Will check back in a couple of hours.
fluffytoebeans has joined #openscad
fluffytoebeans has quit [Remote host closed the connection]
fluffytoebeans has joined #openscad
fluffyto_ has joined #openscad
fluffytoebeans has quit [Read error: Connection reset by peer]