<J23>
linext i would use sin/cos hull()for (i=[0:5:180])translate([0,0,sin(i)*10])scale(cos(i)*[0.7,.8]+[0.3,.2])cube([20,15,.01],true);
ur5us has joined #openscad
fedorafan has quit [Ping timeout: 252 seconds]
ur5us has quit [Ping timeout: 265 seconds]
fedorafan has joined #openscad
LordOfBikes has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
J2350 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
kintel has joined #openscad
<kintel>
lf94 In terms of node; you probably don't want node, just pure JavaScript ..which should be relatively straight-forward since we can sandbox a VM pretty easily. Still opens up for a lot of potential vulnerabilities, especially if it's given internet access, but I think it would require a bug in OpenSCAD to pull that off, so it's probably acceptable since bugs can be fixed.
<kintel>
..and there are some very constrained JS VMs out there, like quickjs
<kintel>
I've always felt like scheme or guile is more in the spirit of OpenSCAD. ..but then again, I'm probably not the target audience for this functionality ;)
<kintel>
^ See above for my current attempt at writing a CMake find module wrapper. Lesson learned: This isn't completely trivial, and I haven't figured out how to respect things like the REQUIRED argument.
<kintel>
I'm starting to think fork & modify may actually be cleaner :/
<InPhase>
linext: I liked J2350's starting base, so I tweaked it. :) hull()for(i=[0:2:60])translate([0,0,sin(i)*5])scale(cos(i)*[0.7,.8]+[0.3,.2])linear_extrude(0.01)offset(2, $fs=0.2, $fa=1)offset(-2)square([20,8],true);
ur5us has quit [Ping timeout: 250 seconds]
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
ur5us has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
la1yv has joined #openscad
guso787 has quit [Ping timeout: 260 seconds]
<J2350>
InPhase seeing that - i think using offset instead of scale would be much better hull()for(i=[0:2:60])translate([0,0,sin(i)*5])linear_extrude(0.01)offset(2-(1-cos(i))*2.5, $fs=0.2, $fa=1)offset(-2)square([20,8],true);
<J2350>
and if hull would work more like a skin or minimal surface you could do concave too for(i=[0:2:80])translate([0,0,sin(i)*2])linear_extrude(0.1)offset(1-(1-cos(i))*1, $fs=0.2, $fa=1)offset(-1)difference(){square([20,8],true);square(5);}
<J2350>
at least it doesn't matter about the center distance
<J2350>
JakeSays looks great - did you make the flange on top with the chamfer option?
<JakeSays>
J2350: lol no. that didn't even occur to me. i already had that part done before i added your lib
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
<JakeSays>
any suggestions on a good paint to use to weatherproof it? the inside of the tube will be exposed to the elements.
<J2350>
if you print in ASA, TPU or PETg there is no need .. else a PU paint or epoxy
<JakeSays>
this is PLA+
<JakeSays>
whats PU?
<J2350>
for most conditions a simple acrylic paint will do the job
<J2350>
PU Polyurethan
<JakeSays>
ah ok
<J2350>
but also PLA should be weather resistant
<J2350>
only ABS get problems with UV .. (and after years also other plastic)
<JakeSays>
PLA is biodegradable
<JakeSays>
although it's probably not worth worrying about.
<JakeSays>
if it degrades, i'll just print another one :)
<J2350>
haha yeah but only if heated in a bio reactor
<J2350>
biodegradable means "it is possible" not that it is compostable
<JakeSays>
ah good point
<J2350>
I burried BDP (biodegradableplastic) 5 years ago .. and they still look the same .. sunlight can make them brittle but with color black there should also be a better resistance but they might get hot which can deform PLA
<JakeSays>
7 years ago someone gave me a huge portable air conditioner, but it didn't have the exhaust hose or mounting kit. i'm finally getting around to making the parts for it
fedorafan has quit [Ping timeout: 248 seconds]
<JakeSays>
J2350: ah fortunately the location of where this will be doesn't get direct sunlight
<J2350>
I have one put it outside (monoblock) and made a casing from XPS and a cooking tube so air from inside is cooled and delivered via the tube into my home office room.
fedorafan has joined #openscad
<JakeSays>
J2350: that's cool
<J2350>
so i could remove all the exhaust piping as it circulates outside and doesn't use the inside air which need to be replenished with hot air
<JakeSays>
right
<J2350>
and it is much quieter if it is outside and you are 10m tubing away in a different room
<JakeSays>
yeah definitely
<JakeSays>
that's a huge advantage
castaway has joined #openscad
L29Ah has left #openscad [#openscad]
fedorafan has quit [Ping timeout: 248 seconds]
fedorafan has joined #openscad
fedorafan has quit [Ping timeout: 255 seconds]
fedorafansuper has joined #openscad
fedorafansuper has quit [Read error: Connection reset by peer]
fedorafan has joined #openscad
J2350 has quit [Quit: Client closed]
J2350 has joined #openscad
fedorafan has quit [Ping timeout: 255 seconds]
fedorafan has joined #openscad
pah has joined #openscad
pa has quit [Ping timeout: 255 seconds]
L29Ah has joined #openscad
<InPhase>
J2350: Yeah, putting the varying scale into the offset certainly gives a more interesting edge effect there.
<J2350>
why "offset extrude" would be such a good idea .. is there some progress?
<buZz>
J2350: whats BDP if not PLA?
<buZz>
and what plastic is XPS ment to be?
<buZz>
XPS?
<buZz>
PLA decomposts at 90C btw, only decent compostpiles reach that in the center
<buZz>
i've had PLA prints in direct sunlight for ~5 years, PLA itself was fine, the dye removed itself quickly :)
<J2350>
No that is EPS expanded polysterene XPS is much denser and rigid
<buZz>
funny @ that Greentec btw, the Chemical Resistance Information Sheet has the properties of that material and PLA being 1:1
<buZz>
J2350: yeah like when you melt stryrofoam and it become a puddle
<buZz>
let it harden, boom, xps
<buZz>
grossest material :D
<J2350>
all plant based are similar .. someone made plastic from avocado seeds which is probably not much different
<buZz>
that greentec suggests its copolyesters though
<buZz>
from MSDS
<J2350>
Greentec uses lignin (from wood) iirc
<J2350>
and you can sand/saw/mill/ it much better than PLA - also it has much higher temp resistance ( cooking water )
<buZz>
it bends though
<buZz>
not as rigid as PLA
<J2350>
not the ones i had - quite the opposite
<buZz>
also, 2-3x the price so not really considerable :D
<buZz>
then they lie on the specs?
<J2350>
from what spec
<buZz>
the one you linked
<buZz>
oh duh, thought this was #reprap
* buZz
moves
<J2350>
the net diagram shows similar to PLA NX2
<buZz>
that reads like normal PLA+
<buZz>
also known as IMPLA
<J2350>
E-module for PLA1 is given with 500 while GreenTec has 4300MPa
<J2350>
so where did you read about "bending" and concluded "not as rigid as PLA"
<J2350>
bit strange is that "stress at break" is lower than tensile strength - not sure how that works
<InPhase>
buZz: I read all about how PLA is a biodegradable plastic which breaks down in 1-2 years in environmental conditions, and therefore it's unsuitable for outdoor applications. I printed some PLA stakes to use for some solar lights in frequently damp soil near a creek bed subject to lots of water runoff and that overflows routinely, and a few years later I inspected those and found... they had not
<InPhase>
changed the slightest bit.
<buZz>
InPhase: indeed
<buZz>
J2350: because it bends, its 'bruising'
<InPhase>
In fact the only reason I had to get rid of those solar lights is because almost all of the OTHER plastic they were made out of, from the factory, had fallen apart in that time frame. Only the PLA stakes held up. lol
<buZz>
InPhase: hahaha :)
<buZz>
could replace the case with a design of your own ;)
<InPhase>
I sure thought about it!
<InPhase>
But then I realized I wanted to double the solar panel size and the battery capacity, and then I didn't get around to it.
<InPhase>
Nearly all solar lights promise 8 hours of light. Nights are not 8 hours long.
<InPhase>
To get to 16 you just need to double the input power without changing the light output.
<buZz>
hmhm, plus their chargers are rarely any smart, so they tend to just murder batteries over time
<InPhase>
I'd rather just buy some with a longer specification, but those don't seem to be sold. Maybe they're all designed in a part of the world where the Earth rotates every 16 hours.
<InPhase>
The nimh ones do fine with the batteries.
<buZz>
for ~2 years yeah
<buZz>
about 5x faster death
<InPhase>
I've bought eneloops for a little over 15 years, and over about a hundred of them I've only had to throw out a small handful for no longer working right.
<buZz>
nice
<InPhase>
Those are REALLY good nimh batteries that just keep working on a decade-plus scale.
<buZz>
i honestly havent seen any 'solar light' for garden usage that survives >2 years, most often just by murdering its cells
<InPhase>
Also there's an Amazon generic version of the eneloop that is reputed to be made in the same factory, and works the same, but just costs a little less. I buy some of those.
<buZz>
i dont use amazon
<buZz>
i use stores
<InPhase>
But I know of no solar light that can last more than 2-3 years. :) It seems like it should be possible, but they're all made pretty low quality it seems.
<buZz>
nkon.nl <- best dutch store for batteries
<InPhase>
If no one steps up to the plate, I'll probably make my own someday, the next time I want solar lights.
<InPhase>
I don't have any right now because the township has a bright lamp near my driveway that would be charging the solar lights all night long.
<guso78[m]>
Today i have added the Alert Dialog to warn the User about Potential harmful Python Files
<guso78[m]>
There IS even a Blacklist and a whitelist.
<guso78[m]>
Self written Files are Not considered harmful
<guso78[m]>
How IS IT Händler If openscad gets New Messages to translate IT to all the languages ? Obviously this cannot BE all deine by the Same Person.
<guso78[m]>
Deine=done
kintel has joined #openscad
<teepee>
guso78[m]: current strategy is only updating the translation files and hope for the best
<InPhase>
guso78[m]: How are you defining "self-written" from a procedural standpoint?
<InPhase>
guso78[m]: Does it whitelist it at the save operation? Or at the new file operation?
<InPhase>
guso78[m]: And did you whitelist by path or by hash of the contents?
<InPhase>
guso78[m]: There can be a functional difference for example with repositories that are updated externally.
<InPhase>
It might be nice to require reapproval if a python script has changed. I for one would want to validate the contents of files if they have changed.
fedorafan has quit [Ping timeout: 265 seconds]
<guso78[m]>
Self written implies that File ist empty initially and get whitelisted Then. When User continues to Code Python , they are already White. If the File is Opened in a New openscad, the Warning Dialog will appear once
<InPhase>
guso78[m]: Also, that's great progress that you have gotten the dialogue going. I'm only being careful with these nuanced details because security is a serious business, and we have mostly users that don't understand it. So we want to avoid getting any CVE entries or bad reputations from these issues. And I think we can achieve both usability and safety here with threading the needle properly.
<InPhase>
Does the whitelist get cached in memory, or is it stored on disk?
<InPhase>
I think storing it on disk is actually the better strategy for usability as long as we use hashing of contents.
<guso78[m]>
I whitelist File pathes. Else the User IS Always reasked the question when He continues programming
<InPhase>
If a file is whitelisted at load, it could be kept as such at each subsequent run, updating the hash during editing.
fedorafan has joined #openscad
<InPhase>
Hmm. I will need to think a bit about the user flow for using an external editor.
<InPhase>
At least for "Automatic Reload and Preview" of the active file, that can follow the same logic, once whitelisted, keep it whitelisted with changes.
<InPhase>
External files imported other than the primary file can then pop up for approval.
<InPhase>
Although do you actually have visibility of those?
<guso78[m]>
Hmm i am Not very good with hashes and Auto updating Them in certain conditions. Need to make my Idea about that First
<InPhase>
I figure there are two modes to import. One is the include a python file into a scad file, which I'm not sure if you actually implemented yet, but if you haven't, that will be rapidly asked for as a feature. The other would be "import" within Python, which could either be installed libraries OR local files, and if those local files aren't checked, we'd have an invisible place where changes can be made
<InPhase>
if this is not tracked.
<guso78[m]>
Inphase would you assist me there ?
<InPhase>
With hashes?
<InPhase>
It'll be pretty simple really, but I can advise.
<InPhase>
We'll just need the simplest sha256 or sha512 code to integrate into the codebase.
<guso78[m]>
Yes May BE give detailled instructions on where to are which Algorithm, which functions to use
<guso78[m]>
I believe even a simple xor checksum yields Same purppse
<InPhase>
That would definitely not work. :)
<InPhase>
Sha256, sha512, or whirlpool would provide the needed difficulty of a malicious actor creating a false hash match result.
<InPhase>
And I have code for these, but it's from a decade ago, so I should first check to see if there are easier codebases to work with out there.
<guso78[m]>
And If hashes need to BE Stores beyond openscad Lifestyle i need to know where to store
<InPhase>
That'll be in a file in the config directory, unless teepee has a different idea. I think a separate file is probably best though, so people could do simple things like delete it to clear it all out.
<InPhase>
Then we don't have to implement a saved hash manager.
<guso78[m]>
Where IS config directory in Linux ?
<InPhase>
~/.local/share/OpenSCAD/, the terribly named official place for such things.
<InPhase>
Or wait. That's the libraries.
<InPhase>
~/.config/OpenSCAD/
<guso78[m]>
Yes but a very good choixez. Support also the enabled Features are Stored there
<InPhase>
You'll see in there for example shortcuts.json which was added recently.
<guso78[m]>
Choice
<InPhase>
There could be a python_files.csv or something simple.
<InPhase>
Or maybe even just a list of hashes, one per line.
<InPhase>
They could then be loaded into a std::set for a .count() check to see if it's in there.
<InPhase>
That'll keep it logarithmic complexity to check for them.
<guso78[m]>
Are there functions available to read and write from config dir which Work in all platforms?
<InPhase>
A million entries would be something like 48MB of memory storage, so this will never get out of control.
<InPhase>
Yes, there are.
<InPhase>
There's an abstraction for that in the code somewhere, which we can track down.
<InPhase>
I'm thinking this looks like a great library choice. I haven't tried using it, but the documentation at first glance appears great: https://github.com/weidai11/cryptopp
<InPhase>
And it has supposedly undergone some great security audits, so everything should be solid.
<InPhase>
This apparently uses the recommended Crypto++ "pipelining" technique where "new" is used but it manages the deletion of the allocated objects internally.
<InPhase>
So it hashes a std::string into a base64 string in one sequence, which is precisely what we're looking to do.
<InPhase>
Then those base64 hashes can just be dumped out to file like text. Nice and simple.
<InPhase>
We could also choose to store and work with them as binary, or as hex hashes, but base64 is pretty good and more user friendly as a file format.
<guso78[m]>
OK let me try to calculate the hashes First
<InPhase>
It stays pretty compact in memory too.
<InPhase>
The license is boost, so no issues there, and this is popularly used, so we should be able to integrate it trivially.
<kintel>
Manifold: Any opinions on whether it's fine to disable ENABLE_MANIFOLD and ENABLE_TBB by default, or gate those behind EXPERIMENTAL?
<InPhase>
kintel: Well it should stay disabled by default because it crashed up until very recently. :)
<kintel>
ok, I'll make the switch :)
<InPhase>
I'd also regard it as experimental unless the recent updates have wildly improved it.
<teepee>
why the effort as it has it's own switch anyway?
<InPhase>
I don't quite understand the question structure though regarding what's proposed to change.
<kintel>
I guess it was good for early experiments to build with EXPERIMENTAL=ON and MANIFOLD=OFF
<kintel>
..but now we can probably just use the EXPERIMENTAL to implicitly turn on Manifold support
<InPhase>
I don't think it needs separate build settings, if that's what you meant.
<InPhase>
Only defaulting to off for users, and blocked behind experimental for now.
<kintel>
I just noticed that the default build fails now
<teepee>
yeah, good point just EXPERIMENTAL and maybe even soon-ish have it default to yes :)
<InPhase>
I would love default on, but we need to hammer the crap out of it before then.
<teepee>
and that will only happen with default on
<InPhase>
lol
<teepee>
all the open issues seem fixed currently
<InPhase>
Well, we can sell it to the inner circle people. :)
<kintel>
yeah, and practically disable CGAL for all cases where manifold works. It's a rather large switch
<teepee>
true, but some of the examples are fairly complex objects
<InPhase>
teepee: I will have to run more tests. It seems unthinkable to go from that level of bugs to fully working in such a short time. But, maybe!
<teepee>
I've seen only one from you :P
<InPhase>
That was my representative case.
<InPhase>
I didn't want to overwhelm
<teepee>
2 other github issues are confirmed fixed
<teepee>
the one I've seen is fixed too
<InPhase>
Sounds good. I had a bunch failing, but I thought it possible they were all different flavors of the same issue, so I posted only one.
<teepee>
the only unclear candidate is the potential multithread issue and that had 2 fixes in manifold
<teepee>
(tbb update + fix with iterators)
<InPhase>
I will find a time to run a bunch of my heavier old designs that made CGAL sweat. And then I'll try some pathological stuff.
<teepee>
that would be cool. considering the number of CGAL fails we don't even need to get to 100% to be better than the old state
<teepee>
plus 50 times faster is not bad either
<InPhase>
I do a lot of weird things that are on the edge of broken, which is rarely useful except in cases like this. :)
<InPhase>
Yeah. We just want to avoid any serious regressions really. And we want to avoid crashes, as those are worse than CGAL assertion failures.
<teepee>
considering at least 2 Manifold devs read our github issues lately, it's the perfect time to shake this a much as possible :)
<InPhase>
I need to run out for some shopping, but perhaps I'll hammer this some more in the evening while Germany slumbers.
<teepee>
yep, that will be soon for me
<teepee>
had some fun visiting BMW fab in real world :D
<teepee>
so day started way earlier than normal
<kintel>
In terms of Manifold: Does anyone know if it's realistic for Manifold to one day get support for tagging subtracted surfaces?
<teepee>
like at german times ;-)
<teepee>
I don't *know*, but it seems elalish is quite interested in adding features and that sounds like a very useful thing
<peepsalot>
rapha: yes the way to make it work is to fix your STL file. the mesh has to be "water-tight" for one thing
<rapha>
thanks, peepsalot ... not viable then (stl files downloaded from thingiverse)
<rapha>
thankfully got a buddy to do it in a different program
<peepsalot>
there are various utilities that can repair STL files
<peepsalot>
to varying degrees of success
<peepsalot>
rapha: the reason F5 preview works but F6 doesn't is because F6 requires computing the mesh, which uses CGAL library, which has very strict constraints on what is valid input geometry or not. F5 on the other hand, only simulates roughly what it would look like without really computing the new mesh geometry
<rapha>
that's good to know
<rapha>
pretty sure this will come along again
<peepsalot>
but the message "not closed" would indicate that there is likely a hole in that STL model