teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<Friithian> oh if it is big and you dont have a heated chamber ABS may be pain, but if you can print I would say do that, otherwise yeah PETG pretty darn good
<Friithian> tbh I like PETG better than PLA in general
<InPhase> I use PLA more mostly because I bought massive amounts of it before PETG became widely available.
<InPhase> But PETG has a lot of nice properties over PLA, such as just in general being more durable due to that little bit of flex.
<InPhase> PLA is my go-to choice though for something I want to be rigid like a brick.
<InPhase> e.g., when I needed a wall mount for a baby gate when my kid was young, and I didn't want it to be badly attached to drywall, I made a thick PLA unit to mount the baby gate to which spread out into a thick PLA wall mount, spreading the forces over 14cm of drywall, with one side extending just far enough to reach a stud. That thing wasn't going anywhere, and stood up to some heavy abuse.
califax has quit [Ping timeout: 258 seconds]
califax has joined #openscad
rawgreaze has quit [Quit: ZNC 1.8.2 - https://znc.in]
fling has quit [Ping timeout: 258 seconds]
fling has joined #openscad
rawgreaze has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
LordOfBikes has quit [Ping timeout: 248 seconds]
LordOfBikes has joined #openscad
epony has quit [Ping timeout: 252 seconds]
snaked has joined #openscad
Sauvin has quit [Read error: Connection reset by peer]
Colere has joined #openscad
peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #openscad
J1A8435 has joined #openscad
J1A84 has quit [Ping timeout: 244 seconds]
califax has quit [Quit: ZNC 1.8.2 - https://znc.in]
califax has joined #openscad
<gbruno> [github] ntfshard opened pull request #4380 (FreetypeRenderer::GlyphData destruction simplification) https://github.com/openscad/openscad/pull/4380
teepee has quit [Ping timeout: 258 seconds]
KimK has quit [Read error: Connection reset by peer]
teepee has joined #openscad
KimK has joined #openscad
epony has joined #openscad
drfff has quit [Read error: Connection reset by peer]
KimK_ has joined #openscad
KimK has quit [Ping timeout: 248 seconds]
RichardP_ has joined #openscad
RichardPotthoff has quit [Read error: Connection reset by peer]
<J1A8435> regarding temprature  PCTG is something you can try  it is the better copolyester of PETg
<J1A8435> PLA is also know for deformation under stress over time
ur5us has joined #openscad
ur5us has quit [Quit: Leaving]
ur5us has joined #openscad
KREYREN has quit [Write error: Connection reset by peer]
Killy has quit [Write error: Connection reset by peer]
Notkea has quit [Write error: Connection reset by peer]
JordanBrown[m] has quit [Remote host closed the connection]
Cadair has quit [Remote host closed the connection]
HansLoeblich[m] has quit [Remote host closed the connection]
DenKn[m] has quit [Write error: Connection reset by peer]
mikolajw has quit [Remote host closed the connection]
one-star-chef has quit [Write error: Connection reset by peer]
phas858[m] has quit [Remote host closed the connection]
Cadair has joined #openscad
mikolajw has joined #openscad
Notkea has joined #openscad
KREYREN has joined #openscad
Killy has joined #openscad
one-star-chef has joined #openscad
DenKn[m] has joined #openscad
phas858[m] has joined #openscad
JordanBrown[m] has joined #openscad
HansLoeblich[m] has joined #openscad
ur5us has quit [Ping timeout: 264 seconds]
<gbruno> [github] ntfshard opened pull request #4381 (Various minor text improvements) https://github.com/openscad/openscad/pull/4381
<Scopeuk> Those pulls feel like someone is running a tool. The fixes look valid and probably are an improvement but they don't look very human asside from if someone was prepping an area for further work. User is a public @intel email address too
<Scopeuk> I guess help is help and not to be declined especially when it is doing the thankless stuff
<Scopeuk> Although the font list dialog looks suspicious in the latest one
Guest16 has joined #openscad
Guest16 has quit [Client Quit]
<InPhase> Scopeuk: Well the commit is literally marked "Codespell fixes". https://github.com/codespell-project/codespell
<InPhase> The top repository on that user's github page is also a cppcheck fork, so apparently it is someone with an active interest in static analysis.
<Scopeuk> InPhase yeh the second one referenced a tool. I'm just wondering if we are being used as training for a static analysis tool. If it helps the code base there is no issue there, just feels a bit odd
<J1A8435> imagine AI starts github edits ..  the code is better after but nobody knows why
<buZz> J1A8435: github literally -has- 'AI edits' ;)
<buZz> over a year already
<J1A8435> so hope the ai knows what it is doing .. or someone write an ai to watch over it
<buZz> J1A8435: its not unvoluntary, see the link?
<J1A8435> i think it is just a process and matter of time to get used to it and trust it .. rely on it  -  and don't care that you can not control it in the end
<buZz> J1A8435: not sure if you're trolling
<J1A8435> it boggles my mind when i think about AlphaZero and when they found out how it won go  (years later)
<buZz> its funny that 'chess' gets so much focus, while Go is so much complexer :)
<buZz> and only recently won from a human
<J1A8435> tradition and historic reasons i assume ..    chess is something  people can grasp  - the strategies is go are on a different level
<buZz> hence why it was harder for a computer to beat a human ;)
<buZz> and thus a bigger feat that they did
<Scopeuk> Chess is superficially more complex, the rules are much more nuanced, go has simple rules but the complexity comes in from game state
<Scopeuk> Chess starts at it's most complex and simplifies as it is played, go works the other way arround
<J1A8435> and it took them a while to find out why it played that way - because no human plays GO that way ..
<Scopeuk> Just spotted the code cl warning (v1 to be deprecated) https://github.blog/changelog/2022-04-27-code-scanning-deprecation-of-codeql-action-v1/ it looks largely like switch over should be backwards compatible
<J1A8435> and it turned out that no human ever will be able to play GO that way α does
e2k has quit [Quit: leaving]
e2k has joined #openscad
<Scopeuk> Ok so the action thing affects basically every action we use, github are migrating the node.js version they use for the task runners, I should take a look at this later when I'm on a proper machine
<Scopeuk> Most/all of the actions we use have already been fixed just need to bump versions and double check none slipped in any arguement changes
castaway has joined #openscad
fluffytoebeans has joined #openscad
qeed has joined #openscad
qeed_ has quit [Ping timeout: 246 seconds]
fluffytoebeans has quit [Remote host closed the connection]
Colere is now known as Sauvin
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
Virindi has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Virindi has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
<peepsalot> I decided to do some work on https://github.com/openscad/openscad/issues/3932 and determine how much of test cases etc would change by switching to double-conversion's ToShortest
teepee has joined #openscad
<peepsalot> the main problem I have found in doing this is that it doesn't address the issue of cache precision, because most or all of those values are converted to double (as opposed to our Value type), through the course of outputting nodes to string
<peepsalot> so i need a way to override ostream operator<< on double, AND ostringstream operator<< on doubles
J1A843570 has joined #openscad
<peepsalot> i also asked this in #C++, with less exposition, but i was thinking to use example from this answer which replaces ostream: https://stackoverflow.com/a/17137990/251068
J1A84357013 has joined #openscad
<peepsalot> but then I'm not sure how to also make an ostringstream which works similarly and inherits the new class without re-implementing the whole interface
aiyion has quit [Remote host closed the connection]
J1A8435701347 has joined #openscad
J1A8435 has quit [Ping timeout: 244 seconds]
aiyion has joined #openscad
<peepsalot> in terms of naming, i was thinking to keep class names but use our own "scad" namespace: so scad::ostream and scad::ostringstream
J1A843570 has quit [Ping timeout: 244 seconds]
J1A84357013 has quit [Ping timeout: 244 seconds]
krazylink has joined #openscad
<Virindi> is it possible to somehow count the complexity of children to a module? I have an extremely large, complex model and I am trying to make it run at better than 1fps and it would really help to have some kind of debug that told me which parts were causing the most lag
<Virindi> right now it is entirely subjective, enable part, see how much slower the fps feels
<peepsalot> there's no direct feedback of any kind of complexity metric, aside from maybe number of faces when rendering a specific subtree.
<peepsalot> F6 render i mean
<krazylink> I have a quick question I was wondering if someone could help me with. Why does raising to a power of zero only keep the sign if using a direct value and not a variable. eg.
<krazylink> v=[.33,-.33,.33];
<krazylink> a = .33;
<krazylink> b = -.33;
<krazylink> c = .33;
<krazylink> echo("vector", [v[0]^0,v[1]^0,v[1]^0]);
<krazylink> echo("variable", [a^0,b^0,c^0]);
<krazylink> echo("direct",[.33^0,-.33^0,.33^0]);
<Virindi> I am concerned only with preview. I use very high $fn for render, I don't care how long parts take to render, but it is difficult to work on a project when the preview is 1fps
<peepsalot> Virindi: or you could use the disable modifier "*" on various parts until things speed up. and then those parts could explicitly call render() on them.
<Virindi> btw, VBO significantly increased the possible number of parts I can view at once :)
<Virindi> normally I have to disable half the parts during work.
<Virindi> I have a list where I choose which parts to show
<Virindi> but I am trying to find which parts are the most offending so I can further reduce the preview fn/fa/whatever
<peepsalot> calling render() module trades off some delay of initial preview render, for much more responsive panning and orbiting of camera
<Virindi> hmm
<Virindi> does that work with transparent parts?
<Virindi> and if I render() some part I am not working on, is the result cached if I change a different part?
<peepsalot> yes, as long as any color is applied outside of the render() call
<Virindi> ahhh
<Virindi> hmm
<Virindi> but if you call render() on something, $preview is still true right?
<Virindi> during preview, I mean.
<peepsalot> and yes the cache is why it puts less load on the preview renderer
<J1A8435701347> krazylink pow(-.33,0)
<Virindi> I use $preview to set $fn to 7, for example
<peepsalot> yes $preview is independent of usage of render() module
<Virindi> neat
<Virindi> thanks, I will try that
<J1A8435701347> krazylink i would assume there is an implementation error for ^ format  .. as  anything  to the power of 0 should be 1 and not -1 iirc
<krazylink> J1A8435701347 pow produces the same result. I was under the assumption that anything raised to zero is 1 preserving sign. Am I just fundamentally wrong on how raising to zero works?
<peepsalot> krazylink: it seems the precedence of negation and exponent operators may need to be tweaked. it works if you do this: (-0.33)^0
J1A8435701347 is now known as J1A84
<J1A84> krazylink  using version 22  pow(-.33,0) equals 1
<peepsalot> -.33^0 is apparently equivalent to -(.33^0)
<Virindi> peepsalot: does calling render() do anything for an imported stl?
<peepsalot> Virindi: no, only should help for complex interactions of various difference/intersection/unions
<Virindi> hmm, okay thanks
<peepsalot> Virindi: also see this FAQ about a specific configuration which is inherently slow to preview https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_is_the_preview_so_slow?
<peepsalot> if you are doing that ^, then render() on that portion would likely give the best gains
<krazylink> @J1A84 thanks for the link. It seems that most people agree that -x^0 == 1 but all the calculators and programming languages I have tried think -x^0==-1. Any suggestions on how to better detect the quadrant of a point?
<Virindi> I rarely use intersection. My standard pattern is to have a difference of a union and then a bunch of other simple objects
<Virindi> I just added render() before every color() and it is taking minutes to generate, heh
<Virindi> just finished, super high fps now though :)
<peepsalot> yes, it can be a bit of balancing act
<Virindi> since I am normally editing only one or two things at a time, most of the time I doubt it will be an issue....but there are some parameters which affect literally every object, those I'm sure will be painful to mess with
<peepsalot> if you have parts which are repeated numerous times in the model, and those are composed of a few boolean ops, then those are good targets for render()
<Virindi> mostly it is one of each part
<Virindi> but if I have an assembly of 100 parts and I am working on just one of them, this seems like a good way to actually be able to see the stuff I am not working on (at more than 1fps)
<Virindi> hmm
<J1A84> krazylink  if  you  say   2² : 2² =1   (which is 2⁰)   -4/-4 is 1
<peepsalot> i mean, for example, each part maybe uses a bolt hole, which could have a counterbore. if your object for that is union of two cylinders or something, then it would be good to cache that with render
<J1A84> so if your result is -1 than it is  - (x⁰) and not (-x)⁰
* krazylink headdesk
<peepsalot> Virindi: ... so if that same sized bolt is used all over the place, the render() of it should be quick and simple, but also significantly reduce the complexity of the CSG tree for the preview
<krazylink> of course there is a built in function. Thank you for letting me know to RTFM.
<J1A84> cheatcheet!
<J1A84> cheatsheet!
<othx> cheatsheet is https://www.openscad.org/cheatsheet/ for the release version and https://www.openscad.org/cheatsheet/snapshot.html for the development snapshot versions
<krazylink> oh, I looked at the cheat sheet. I'm just dumb and apparently like to make my life harder than it has to be.
<krazylink> Thanks all.
<gbruno> [github] Scopeuk opened pull request #4382 (Update to github ci to migrate to node 16 compatible versions) https://github.com/openscad/openscad/pull/4382
<gbruno> [github] t-paul closed pull request #4381 (Various minor text improvements) https://github.com/openscad/openscad/pull/4381
<gbruno> [github] t-paul pushed 11 modifications (Merge pull request #4381 from ntfshard/codespellfix Various minor text improvements.) https://github.com/openscad/openscad/commit/ac6e31233b36901e77a2d077809ec0435a0229b2
<Virindi> now if only the customizer had sliders, so I could put a list of joints in the customizer and slide a slider to move the joint :)
<InPhase> krazylink: The operation precedence order for -.33^0 in OpenSCAD complies with what -.33**0 yields in Python.
<Virindi> because this is actually fast enough for that to be worthwhile now
<JakeSays> so i'm becoming more interested in non-planar printing
<Virindi> ohh, it is supported?!
<Scopeuk> Virindi the customiser has sliders
<Virindi> darn, I have to try this now.
<InPhase> krazylink: And this is the way it needs to be, because "0-2^5" should yield the same result as "-2^5". And if "0-2^5" gave you "32" as an output, you would be wildly confused. ;)
<JakeSays> Virindi: was that directed at me?
<Virindi> no :)
<JakeSays> ah good:)
<krazylink> yeah, it seems what I was actually wanting was more like x=-n (x/abs(x))*(x^0)
<JakeSays> cuz it's not supported anywhere yet
<krazylink> or, you know, just use sign(x) and call it a day.
<Virindi> hmm, I guess I cannot set customizer limits to a variable, just a plain number? Like if I have a joint, and the joint angle limit is calculated somewhere, for example
<Scopeuk> unfortunately I believe it's only hard coded values
<InPhase> No features for related constraints in the customizer yet, although that could be an interesting feature.
<InPhase> Virindi: So did you resolve your display window frame rate issue?
<JakeSays> have you guys ever worked with TPU?
<Scopeuk> I guess the customizer stuff would all fall into the desired project driven syntax to replace/augment the thingiverse stuff
<Scopeuk> JakeSays yes
<Friithian> I've worked with TPC and it is pretty fun
<JakeSays> Scopeuk: how is it to work with?
<Scopeuk> my experience has been favorable
<Scopeuk> I'm not sure of the hardness of the stuff I have but it prints with my pla settings (my machine is fairly conservative so I guess that helps)
<JakeSays> it's very flexible, right?
<Friithian> yeah
<Virindi> inphase: yeah it is a lot faster now.....after generating :)
<peepsalot> some flexible filaments can be troublesome if your printer uses a bowden tube extruder
<Friithian> the TPC wants a bit more heat but it still good
<Virindi> I just search/replaced every color() with color() render() and bam
<peepsalot> or so I've heard anyways, i don't use a bowden tube
<JakeSays> peepsalot: what do you use?
<Friithian> with an ultimaker s5 which uses a bowden tube I had zero issues with the TPC
<peepsalot> extruder on x carriage
<JakeSays> peepsalot: ah ok.
<Scopeuk> I do use a bowden extruder and have had sucsess but I don't know how representative what I have done is
<JakeSays> i've been considering direct feed
<Virindi> take a look at designs like Orbiter for very light direct feed :)
<peepsalot> theoretically, the longer the path between drive gear and nozzle, the more chance for the filament to compress and stretch(during retraction), which would at the very least create inconsistencies or artifacts in the print
<Virindi> with bowden you generally have to retract more, and every retraction contains error because drivegears always slip, so you 'lose' filament the more you retract
<peepsalot> also not sure if binding/excess friction in the tube is an issue, which could jam up the extruder
<Scopeuk> the compression issue is definately a potential thing but is partially mitigated by reduced extrusion speed
<peepsalot> all that with caveat that I'm just theorizing with no direct experience :P
<Friithian> I've never run into those issues so far
<InPhase> Friithian: I don't think you'd see it with that TPC level's flexibility. But there are filaments which go more flexible.
<Scopeuk> I've not had any issues, I was pleasantly surprised on first try
<InPhase> I've not tried that TPC, but I'm guessing its properties based on the reported numbers there.
<Friithian> it's fairly similar to TPU
<InPhase> It seems like one that won't really compress too much when you press it through a tube, like TPU.
<Friithian> also it should be noted that this is with 2.85mm filament
<Friithian> which prob will compress even less
milza has joined #openscad
<InPhase> Ah, certainly.
<InPhase> I hadn't thought about it before, but the 3mm variants are probable much better for the Bowdens.
<InPhase> s/probable/probably/
<Friithian> maybe that's why ultimaker uses it
<InPhase> The only Bowden extruder I used was on the Monoprice Mini, but I haven't tried anything other than PLA in one of those.
<InPhase> They are a 1.75mm
<Scopeuk> my machine is based off the same machine as the mp select mini (Malayan m200?) it does have a slightly modified extruder to have less of a gap between the drive and the start of the Bowden, I've printed tpu on it
<Friithian> yeah ultimaker is weird still using 2.85mm but hey, it works
<Scopeuk> it's a legacy thing
<Scopeuk> 2.85/3mm is the strimmer cord diameter, ultimaker decided they want to retain backwards compatibility to the earliest of their machines
<InPhase> My string trimmers have all been 1.75mm. :)
<Friithian> wonder how expensive string trimmer lines are per kilo
<InPhase> About $100/kg at local prices I'm getting.
<Friithian> try to use the shittiest PLA you can get :D
<InPhase> Well, it's usually nylon, but even nylon filament has come down to about $33/kg now. (It used to be much more.)
<InPhase> There is a shape difference though, as trimmer line is usually edged or rippled in the outer shape. But I'm not convinced that actually makes much of a difference.
<peepsalot> or $10/lb if you don't mind square filament https://www.amazon.com/gp/product/B01E13CR1Q
<JakeSays> people use trimmer cord as filament?
<Friithian> that'd be heck of expensive
<InPhase> peepsalot: Oh, that's a much better bulk price than the local stores.
<InPhase> peepsalot: Although that would take me probably 20 years to use up. lol
<peepsalot> just print bigger things :P
<InPhase> Or more. I might die first, or have my string trimming replaced by robots.
<Scopeuk> JakeSays back when 3d printers were very home made and boot strapping you couldn't buy filament, so people started with strimmer cord
<JakeSays> Scopeuk: ah ok. that's pretty cool
<peepsalot> InPhase: but actually, i have a ton of unused filament spools at this point too.
<Scopeuk> the hotends back then were something else, potting a bolt in ceramic wrapping it with toaster filament and then wrapping it again, drill the bolt to mean a nozzle etc
<peepsalot> the string trimmer line I bought, but only actually for string trimmer
<Scopeuk> early reprap was mad
<InPhase> peepsalot: I meant for trimming, but printing also I am way on behind my purchases.
<InPhase> I only buy novelty filament these days.
<InPhase> Getting a 3mm printer would be like tossing away close to $300 worth of filament.
<InPhase> Every once in a while I buy a new white or black PLA. It's mostly colors that I have a lot of.
<Friithian> Im thinking of switch to 2.85mm but idk how annoying it'll be
<JakeSays> i've been using pla+ almost exclusively
<Scopeuk> InPhase seen the foaming tpu? you vary the temperature to control how big the boubles are in it at extrusion (correcting with extrusion multiplier) to modify the density and hardness
<InPhase> I just don't need that many red, blue, green, etc things.
<InPhase> Scopeuk: Uh, no. But I've printed with foaming nylon before.
<Friithian> every time I use at least makerbot's tough pla it just… I dont like it. I'd rather use PETG or ABS
<InPhase> Scopeuk: It wasn't sold as foaming nylon though, they wrote "string trimmer line" on the package, and you have to prepare it first by keeping it in your garage for a few years.
<JakeSays> i bought a spool of flexible pla+ but haven't tried it yet
<Friithian> LOL
<Friithian> I like the popping PVA
<Friithian> that you get with regular pla left out
<InPhase> Scopeuk: Which makes me wonder if foaming tpu was intentionally designed, or a crappy production run that someone figured out how to sell.
<Friithian> I'd say the latter
<Scopeuk> InPhase I'm informed it has baking soda added but I've not dug into it
<Scopeuk> its quite possible
<InPhase> baking powder, I presume.
<JakeSays> what is foaming tpu used for?
<peepsalot> i'm looking forward to the rest of the results from this guy's massive hotend benchmarking series https://www.youtube.com/watch?v=dAJlLWX0Few
<othx> peepsalot linked to YouTube video "How to find the best HotEnd? - Ultimate HotEnd Testing - Episode #1" => 1 IRC mentions
<InPhase> peepsalot: What I'd like next is a multi-filament all metal hotend.
<InPhase> Someone has to have made some good options for this.
<InPhase> You know, without paying $5000.
<Scopeuk> JakeSays I think that's a "problem for the reader" I saw it on https://www.youtube.com/watch?v=K7LDY7EJKFU
<othx> Scopeuk linked to YouTube video "There is MORE to this HOOK than you think! (Multi-Material 3D Printing)" => 1 IRC mentions
<InPhase> Scopeuk: Nice.
<InPhase> I had not seen one of those tool changer units before, but that has potential.
<Virindi> just noticed a problem: when I do render(), one of my imported stl files becomes "inside out". It works without render() and I am specifying a high convexity
<Scopeuk> I think thats the e3d one? they sold kits for a while hoping to turn it into an eco system, I don't really know the latest status
krazylink has quit [Ping timeout: 244 seconds]
<InPhase> Virindi: Is it purple in "Thrown Together" mode?
<peepsalot> InPhase: did you see my C++ question from earlier re: ostream, ostringstream? any ideas for that? i'm kind of confused about how to handle the inheritance
castaway has quit [Ping timeout: 268 seconds]
<Virindi> inphase: no.
clemens3 has joined #openscad
<gbruno> [github] t-paul pushed 1 modifications (Merge pull request #117 from lopezsolerluis/master Update documentation-books.html) https://github.com/openscad/openscad.github.com/commit/b6e7c772497b18b8b64f2637bb494bfe90994949
<gbruno> [github] t-paul pushed 6 modifications (Merge pull request #4382 from Scopeuk/github-action-updates Update to github ci to migrate to node 16 compatible versions.) https://github.com/openscad/openscad/commit/daef909c6b39996fc380d0ca2431b975eec2269d
<gbruno> [github] t-paul closed pull request #4382 (Update to github ci to migrate to node 16 compatible versions) https://github.com/openscad/openscad/pull/4382
milza has quit [Quit: milza]
<gbruno> [github] t-paul closed pull request #4380 (FreetypeRenderer::GlyphData destruction simplification) https://github.com/openscad/openscad/pull/4380
<gbruno> [github] t-paul pushed 2 modifications (Merge pull request #4380 from ntfshard/freetyperenderercleanup FreetypeRenderer::GlyphData destruction simplification.) https://github.com/openscad/openscad/commit/570b3a99f52639da54c89fa3c2cd30e50a816213
<InPhase> peepsalot: I didn't track the whole conversation, but saw pieces. What is the constraint that has you wanting to do it via ostream instead of a simpler use of function?
<InPhase> peepsalot: If you have a link to "I want to make a large bucket of these lines work" or something, that I can glance at (if it's something like that), then that would speed up my thinking about an elegant solution.
<peepsalot> i was trying to avoid having to rewrite every usage of ostream operator<<(double) , and so that it can less easily be forgotten to call some special function in future code
<InPhase> And we fundamentally cannot do that for that ostream operator with double, as it's already defined, so the best alternate solution has something to do with what the starting problem looks like. :)
<peepsalot> InPhase: here, the task is to pick out all the lines where doubles are being printed, and make them go through double-conversion library: https://github.com/openscad/openscad/blob/master/src/core/LinearExtrudeNode.cc#L154-L196
<peepsalot> InPhase: so I was thinking to write a "scad::ostream", and "scad::ostringstream" which would be dropins for std:: versions in places like that
<peepsalot> I'm just not sure how to do it in a way that works for both classes, and where scad::ostringstream inherits scad::ostream
<peepsalot> without more or less copying the whole std library header interface and making wrapper for every member function
<InPhase> Well, I'm not seeing a requirement to inherit here.
<InPhase> Only operator<< and .str() are used, so if you take it as a duck-typing problem you have two functions to write, where one is a template plus a case for double.
<InPhase> Then if someone tries to do something other than those two you get a compile error rather than an "oops I didn't account for that right" error.
<InPhase> Well don't do crap like that. lol
<InPhase> What even is that. An auto type from a conversion with a macro into a regex token iterator into an ostream iterator using std::copy as a hack to do non-copy things?
<InPhase> That could maybe have been a for loop. :)
<InPhase> The node.cc is easy. That's coming as a string out of AbstractNode, so it's AbstractNode's toString for doubles that needs the work.
<peepsalot> the regex code is stripping whitespace etc. in CSG tree for cache keys
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
<InPhase> The STR macro is a pre-C++11 approach. The modern C++ approach to that problem is a variadic macro.
<peepsalot> and I was actually basically wanting to get rid of toString and have the operator<< for AbstractNode send it directly to scad::ostream, without having to create instantiate temporary ostringstream so much.
<InPhase> I mean... a variadic function template.
<InPhase> One way or another STR needs updated, so it could be modernized into a function call. 88 lines of STR calls would need " << " replaced with ", "
<InPhase> Once you do that, it reduces to the same problem as the LinearExtrudeNode.cc case.
<InPhase> You could reuse the same code.
<peepsalot> btw i didn't originally write the weird std::copy usage, i only moved it to NodeDumper from elsewhere https://github.com/openscad/openscad/blame/7bea0bef37971035a8cfa0f6eecdd82276afe34e/src/Tree.cc#L51-L55
<InPhase> I hadn't checked the blame yet. :)
<InPhase> But I know peepsalot is not to blame for most of the things git blames peepsalot for.