GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
qeed has quit [Quit: qeed]
la1yv_b has joined #openscad
snakedGT has joined #openscad
linext_ has joined #openscad
peeps[zen] has quit [Read error: Connection reset by peer]
la1yv_a has quit [Read error: Connection reset by peer]
snaked has quit [Read error: Connection reset by peer]
stefanct has quit [Excess Flood]
peepsalot has joined #openscad
stefanct has joined #openscad
clemens3 has quit [Ping timeout: 268 seconds]
clemens3 has joined #openscad
linext has quit [Ping timeout: 272 seconds]
qeed has joined #openscad
J22921 has joined #openscad
J229 has quit [Ping timeout: 256 seconds]
snakedGT is now known as snaked
ferdna has joined #openscad
TheAssass1n has joined #openscad
TheAssassin has quit [Remote host closed the connection]
LordOfBikes has quit [Ping timeout: 240 seconds]
LordOfBikes has joined #openscad
J22921 has quit [Quit: Client closed]
J22921 has joined #openscad
J22921 has quit [Quit: Client closed]
J22921 has joined #openscad
Junxter has joined #openscad
J2292154 has joined #openscad
J22921 has quit [Ping timeout: 256 seconds]
Guest54 has joined #openscad
Guest54 has quit [Client Quit]
ferdna has quit [Quit: Leaving]
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #openscad
J229215495 has joined #openscad
J229215495 is now known as J22
J2292154 has quit [Ping timeout: 256 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
arebil has joined #openscad
zauberfisch_ has joined #openscad
zauberfisch_ has quit [Read error: Connection reset by peer]
TheAssass1n has quit [Remote host closed the connection]
TheAssassin has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
zauberfisch_ has joined #openscad
fling has quit [Ping timeout: 240 seconds]
foul_owl has quit [Ping timeout: 272 seconds]
foul_owl has joined #openscad
zauberfisch_ has quit []
zauberfisch_ has joined #openscad
zauberfisch_ is now known as zauberfisch
<InPhase>
teepee: Excellent. :) I just noticed the git emails about the OpenSCAD on wasm efforts. :)
<teepee>
yep, that is very cool
<teepee>
needs some fixes to get latest version running, but hopefully that's not a big deal
<teepee>
would be so cool to have some interactive playground available on a webpage
<teepee>
time to learn how to interact with it :)
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<InPhase>
We noted perhaps two years ago that development efforts were accelerating from preceding years. I think it's fair to say development efforts are accelerating yet again. I suppose in combination with rising 3D printer access, interest in the project is feeding back into itself as growth.
<InPhase>
I don't know exactly what will come from it all, but I bet fun times are ahead.
<teepee>
yeah, seems like it. that would be cool. there's so much stuff that would make it easier to create models
<InPhase>
The strategy of faster releases was an important thing that fed into that, so we should probably think of the right timepoint for an early 2022 release.
arebil has joined #openscad
<InPhase>
fast-csg would be a massive milestone to have stable enough for a release if this works out.
<InPhase>
It seems like it's actually not far away from being a sensible default-on.
TheCoffeMaker has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]>
InPhase: I think with remeshing (in good progress) and mesh repairs (being prototyped) to avoid most of the known issues it's not unconceivable to think of calling fast-csg stable in the next couple of months.
<OlivierChafik[m]>
(remeshing keeps the size of the corefined solids in check, while repairs make more solids eligible for corefinement by duplicating non-manifold edges and possibly patching holes - although CGAL's routines have trouble doing this without introducing self-intersections: testing my own)
<teepee>
InPhase: I agree very much, but that has some so called nophead issue still unsolved ;-)
<Virindi>
Would it be possible to avoid invisible objects interacting with the camera in preview? What is the deal with that? Like, if you have a difference and the camera is inside the subtracted part, and it screws up the preview
<teepee>
yes, use orthogonal view
<Virindi>
ewwwwwwwwwwwwww no!
<Virindi>
:)
<Virindi>
I guess that is why it was never considered a big deal, all the cool people use ortho
<Virindi>
makes sense
<teepee>
no, it's just a limitation that's probably not easy to remove
<Virindi>
I figured it would be
<Virindi>
why does it not happen in ortho?
<teepee>
one option might be using intersection instead of difference
<teepee>
because in ortho the eye is basically at infinite point
<Virindi>
ahh, right.
<Virindi>
I tend to end up writing complex formulae for things like the outside edge of a cutting box, rather than just making the coordinate +1000, to avoid it. Just seemed like something that if it were solved, would be a little improvement in friction for making models
<teepee>
I usually have something like h = ... for height and use cylinder(3 * h, center = true) for punching holes
<Virindi>
sometimes I do that
<teepee>
would be nice to have a convenient way, but it gets complicated soon when trying to catch all cases
<Virindi>
I have also encountered cases where, when making a model, I used something which was a 'very large value' but hopefully not big enough to intersect the camera, for example, 2*h. Then later I come back and change something else and not thinking about it, now that size is not big enough. Of course what I really meant originally was 'infinity' but I couldn't use that.
<J22>
you can use more distance and zoom in via field of view
<J22>
$vpf
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<Virindi>
doesn't that defeat the purpose of perspective view :P
<Virindi>
for me personally, the purpose of perspective view is that the objects look the same in the preview as they would with my eye sitting near the objects at a reasonable distance
<Virindi>
that is what I want
<Virindi>
I don't look at my assemblies using a telescope :)
<J22>
just don't use extreme values .. you can also use render()
<J22>
i calculate the size of the differencing from the viewports variables .. which works well
<J22>
and when not in preview it gets large to make sure
<J22>
perspective view is nice in animations though
<ecraven>
how do I set $fn=100 *only* for $preview==0, but *not* set it at all for $preview (which should use $fs=0.1
<ecraven>
if I put the $fn=.. inside an if, that is a syntax error :-/
<teepee>
$fs = $preview ? 0.4 : 0.6;
<teepee>
ideally never set $fn at all :)
<teepee>
use $fa and $fs
<ecraven>
I can't get it finer than 0.1 ;)
<Virindi>
redefinition overwrites, right? I know it generates a warning but I thought it overwrites. So wouldn't it technically work to do
<Virindi>
$fn=($preview==0)?100:$fn;
<Virindi>
maybe not even a warning I guess, I don't know how $ interacts with that warning
<Virindi>
surely it just plain old evaluates the RHS then assigns
<teepee>
I think that works because the default $fn is coming for an built-in context, so it's assigned to a new one in the file
<Virindi>
I am picturing the parser just stepping through line by line, if it is an assignment statement eval the RHS, assign the new variable, and if the variable was already assigned display warning
<Virindi>
so uh, that means some sequential programming is possible
arebil has joined #openscad
<teepee>
no, it's not
<teepee>
there's some special cases to not beeing too annoying with warnings
<teepee>
plus like I said it like:
<teepee>
a = 3; if (true) { a = a + 4; echo(a); }
<teepee>
with the { ... } representing the file content
<InPhase>
teepee: I know there are still things nophead wants to be different in the next release, but I don't think they are possible in that manner without semantic chaos in the language, which I consider the much more important long term impact. There exist clean ways to do everything he wants to do with his code. I think the only logical solution is to keep moving on with progress, and remain open to other
<InPhase>
ways to do dynamic configuration or potentially downstream other semantic methods of handling modules.
<teepee>
I would not want to change back the fixed behavior
<teepee>
having some backward compatibility flag would be useful though
<InPhase>
teepee: And I haven't seen a good method proposed yet for another approach other than using functions where dynamic behavior is desired. I happen to think the notion of using functions for calculating values dynamically is very semantically clean though, and is the dominant approach used out there from what I see.
<Virindi>
hmm, it seems that when it sets the warning it also sets the variable to undef. That seems unnecessarily harsh. Almost retaliatory for the user attempting to use the wrong paradigm
<teepee>
when?
<Virindi>
if you attempt something like
<Virindi>
a=a+1
<Virindi>
a=1
<Virindi>
it doesn't give you either 1 or 2
<Virindi>
it gives you undef
<InPhase>
teepee: Have we ever identified another codebase that made use of that particular behavior? I remember searching hard for it, and all I could find was BOSL using the same repeated-reprocessing behavior as the reason to abandon "use" and shove everything into include.
<InPhase>
teepee: I mostly regard it as an edge-case bug that seems to have been discovered and used in one codebase.
<teepee>
Virindi: yes, because it's trying to access the variable a from the outer context where it does not exists, so it's undef
<teepee>
same logic as I showed above
<Virindi>
:(
<InPhase>
teepee: Any attempts to support that sort of thing long term would exceed the efforts to swap in functions for dynamic behavior in that codebase.
<teepee>
ideally it just should be an error, but simply doing that would break a couple of things where there's no replacement at this point
<teepee>
InPhase: I don't think it's clear where it's coming from. there was discussion it might be related to the re-evaluation happening
<teepee>
InPhase: maybe not long term, but having a deprecation phase would be better if possible
<teepee>
on the plus side, there's not a huge risk of breaking Thingiverse designs :)
<teepee>
well, considering they are not updating anyway, that's a moot point too
<Virindi>
forcing people to go back and change old designs is unacceptable though, you don't want a python3 disaster on your hands where there is a decade of work that is thrown away never to be repaired, just lost
<Virindi>
no language fix is worth that
<teepee>
there is literally no way to give a 100% guaranty for that
<teepee>
at this point most 10 year old scripts still work fine, maybe with lots of warnings
<InPhase>
Virindi: Every bug fix changes behavior. We have done it very very frequently. This just happens to be one of the few that had someone using it. But it is actually pretty hard to trigger, as you have to be attempting a very specific type of thing making use of dynamic reprocessing of use variables prior to every function and module entry.
<InPhase>
Virindi: The manual actually describes the behavior as not like this, and has for a very long time, which is why it is not something out there in other codebases.
<Virindi>
I see
<InPhase>
We also recently made a ton of changes to how undef's are processed and propagated, which can similarly change behavior in code. But the goal there was also consistency, and a recognition that the behavior was pretty chaotic.
<teepee>
true, also the change for ranges can potentially change designs
<InPhase>
Every such decision that's delayed as the language grows in popularity ends up becoming technical debt that is much harder to fix up later. :)
<teepee>
but in most cases the change is actually fixing issues :)
<Virindi>
yeah there definitely seems like a line there, when people start relying on clearly unintended and crazy behaviors, and the number of models doing that likely few
tachoknight has joined #openscad
myosotis has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<Junxter>
are there any pastebin that supports openscad syntax ?
<J22>
cadhub Ü
<Junxter>
very cool
<J22>
it is not a true pastebin as the code is in the url .. however with a url shortener this .. is more work
<teepee>
something *like* that yes, a dedicated code call to export no
<Junxter>
i mean a debugging aid would be nice, that lists all the evaluated named quantities, including lists
<Junxter>
would be helpful for designs with large number of calculated dimensions
<InPhase>
Junxter: We should probably submit a syntax update to bpa.st to support OpenSCAD syntax. That site has its source open on git, and supakeen who runs it hangs out here in the Python channels.
<teepee>
sounds like all that would be a topic for the annotations I want to have for years :)
<myosotis>
Junxter, have you thought about managing the project in another language, and just using openscad for the final preview / rendering?
<Junxter>
the code i posted above are actual production code . i mostly machine parts, so there's extra CAM step, where exact dimensions need documented
<Junxter>
myosotis, yes. i use a postprocessor to process SCAD files to automatically generate mesh files and the accompanying modules that use the mesh files and look for relevant transforms in a global table, so A knows how to fit onto B, etc.
<Junxter>
and not slow down when geometries get complex
<Junxter>
it helps to tame complexity and not having openscad slow down to a crawl, both in design preview and also render export
<myosotis>
this might be off topic, but your php code makes me miss perl. the regexp and string manipulation features were so nice
<Junxter>
sure ... lol
J22 has quit [Quit: Client closed]
J22 has joined #openscad
<Scopeuk>
I mean regex and string manipulation is perls speciality, was designed by a linguist after all
<Scopeuk>
php on the other hand was "designed" by 12 angry people on different continents that didn't like to talk to each other and had vastly different programming backgrounds
<Scopeuk>
also still the only backed web dev language I ever learned
<Junxter>
i think regex and dictionary are best parts of perl's . php / javascript really quite similar under the hood, e.g. everything is a "dictionary", really inherited from perl
<myosotis>
started web dev with perl. I'm a HUGE fan but I'm pragmatic. since nobody else uses it, neither do I. Nothing is worse than code that *only you* can maintain
<Scopeuk>
granted I haven't done anything "heavy" with php since the early 5. somethings I guess its moved on a lot, but back then it was the easiest way to connect a command line application a database and a remote user interface to chose what game was available over the air for loading onto my Nintendo DS
<myosotis>
php seems to migrate slowly to a c++ like state more each year. It's still not fun to use, but it gets the job done sort of.
<InPhase>
Junxter: Congrats, I spot no security holes. :)
<InPhase>
Junxter: It's risky business that php execution processing, but you seem to have sanitized everything properly.
<Junxter>
InPhase, plenty of "holes" though, it being all geometry ... lol :)
* InPhase
chuckles.
<myosotis>
if you trust the source then there's no security issue
<InPhase>
Well, if it's php, I don't trust the source.
<myosotis>
haha i meant for junxter
<Junxter>
haha
<myosotis>
I assume that script isn't just sitting on the web processing random users's input and doing things on his systems
<Junxter>
myosotis, it's a command line script, used on the console, part of openscad design workflow.
<InPhase>
myosotis: Well I meant that the rationale for using php is that it could be made public facing.
<Junxter>
it's actually a suite of post-processors, for parting, remeshing, auto-labelling
<InPhase>
Or at least, that's the usual rationale for php.
<myosotis>
I have plenty of php code that will never see another set of eyes on my machine. sometimes the language you're currently most familiar with is the best one
<Junxter>
myosotis, yes. php is very convenient glue, a nicer "shell" language
<InPhase>
I guess I can see that, if you spend too long on webdev and get it deeply ingrained into the brain. :)
<InPhase>
I would have pythoned that script.
<myosotis>
I know I should learn python, I just can't bring myself to do it for some reason. I think the syntax angers me
<Junxter>
python 2.7 -> 3 really broke my heart ...
pah is now known as pa
<Junxter>
and python really not even suitable for web dev nowadays. pretty every security problem attributed to php would be extant if not made worse, if python were used in place.
<Junxter>
personally python feels like scripted Java, and PHP more like interpretd C, with memory safety. And personally I was raised on C, and never got into Java. so PHP feels more ... "natural" ... ?
<Scopeuk>
familiarity counts for a lot
<Scopeuk>
Perl might be "perfect" as a DSL for what you are doing but if you've never worked with it you'll probably get the problem solved quicker in python or c++. obviously there is a crossover based on the scale of the project
<Junxter>
Scopeuk: I always enjoyed learning and reading about perl. During the height of its popularity, I was on the other camp doing cgi in C, but was always curious about Perl.. . And then PHP happened ...
<Junxter>
i guess making parts in openscad compensates for not having the chance to make web sites in perl, lisp, or haskell ... lol
<Scopeuk>
its on I never really learned and I'm very much the other side of the fence generally embedded stuff so its all ada c and c++
<Junxter>
i vaguely remember doing projects in forth , a.k.a. poorman's ada ...
<myosotis>
I don't hate on any languages. I use c and asm for microcontroller projects. Everything has it's place
<Junxter>
Hate leads to the dark side, according to Yoda. But I sometime wonder if Javascript were made in malice by the Sith, or just incompetence by a Jedi academy dropout ...
<myosotis>
yeah I don't understand how html/css/js is THE frontend language stack. and somehow js seems to be creeping into the backend
<myosotis>
maybe the robots will take over before it gets too bad
Guest4847 has joined #openscad
Guest4847 has quit [Client Quit]
<Junxter>
Yo mama's computer is so slow it can't even mo zilla
<OlivierChafik[m]>
teepee: what's the WASM story? I've been thinking very hard about OpenSCAD.js today... (with both WASM and node.js native modes, and a JS/TS API)
<OlivierChafik[m]>
(also, hope you slept well the other time haha, how are you?)
<teepee>
yep, that was all good. also no hurricane problem here, just very very windy :)
<teepee>
well, WASM, exciting news, latest version actually running in web browser
<OlivierChafik[m]>
🤯
<teepee>
no OpenGL and no interfaces at this point, but still very cool result
<OlivierChafik[m]>
Like, what how what what?
<teepee>
it can output STL but no images at this point
<OlivierChafik[m]>
wow
<teepee>
but that's cool, we have fast-csg :)
<OlivierChafik[m]>
what kind of interface is there?
<OlivierChafik[m]>
amazing!!
<OlivierChafik[m]>
I'd love to experiment with that, is it ready for testing?
<teepee>
that repo works, although that's still the 2019 version
<OlivierChafik[m]>
fabulous!
<teepee>
I'm just about to create a PR for updating to latest master, but that also needs the NULLGL fix merged
<teepee>
I did generate fine for: roof() difference() { square(15, center = true); square(8, center = true); }
<teepee>
proof it's actually the latest dev version :)
<OlivierChafik[m]>
hahaha
<teepee>
with experimental featuers
<OlivierChafik[m]>
I was wondering if we'd have to use some double kernel for speed or something
<OlivierChafik[m]>
glad it all works
<teepee>
no idea about speed, it gives a warning about being slow with some sort of grow-memory flag
<OlivierChafik[m]>
well, all works until proven otherwise ;-)
<OlivierChafik[m]>
so exciting!!
<teepee>
also no malloc improvements, those did not build at first run, so I just disabled that for now
<OlivierChafik[m]>
wow
<OlivierChafik[m]>
we can start a new optimization game with memory I guess :-D
<OlivierChafik[m]>
(I did try using nef operations with a double kernel and it wasn't pretty, but maybe corefinement is happier with that, to be experimented with)
<OlivierChafik[m]>
also wondering if gmp & al could benefit from the WASM simd extensions, etc