epony has quit [Remote host closed the connection]
epony has joined #openscad
FluxLalonde has joined #openscad
<FluxLalonde>
Hello. New here. I see in the WIP section of the manual that module literals/references are (possible?) thing. How do I test/work with these?
teepee_ has quit [Remote host closed the connection]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
guso78k60 has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
<guso78k60>
kintel, when i use sphere() to create a mesh with vertices indexes and they are received in another function such union e.g. the mesh of the sphere is looking equally but the vertices and indices have another order. its even different in each openscad run. what can be the reason ?
<guso78>
Basic sphere r=2 with Manifold, but suppose that does Not matter
fling has quit [Remote host closed the connection]
<gbruno>
[github] kintel pushed 44 modifications (PolySet Refactor: Remove Polygon2d features from PolySet (#4933) * Render polygon outlines directly from Polygon2d instead of retaining polygon2d in a PolySet * Remove polygon2d from PolySet * Safer memory management of OpenCSGPrim * Removed some unused code) https://github.com/openscad/openscad/commit/f5d1bfa3a9955e062a3144a3bd88ed1081673204
<gbruno>
[github] kintel ready_for_review pull request #4937 (Optimize some PolySet creations to avoid using the PolySetBuilder reindexer) https://github.com/openscad/openscad/pull/4937
<kintel>
Are you still planning to look into the couple of items you assigned yourself?
califax has quit [Remote host closed the connection]
<kintel>
guso78 spheres are created using your PolySetBuilder, which reorders everything
<kintel>
My latest PR above rewrites that so that PolySets are generated directly
califax has joined #openscad
<kintel>
Also, we may tessellate PolySets into triangles. I'm uncertain if that would change the vertex order
<kintel>
*The PolySetBuilder _potentially_ reorders stuff. I guess for a single PolySet it will use the order in which vertices are added
<kintel>
Anyway, give my PR a spin and let me know if you still see surprising behavior. We still have interesting ways in which geometry is processed, and more cleanup can be done, but I'm a bit tired of that work so I need a break :)
califax has quit [Remote host closed the connection]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<guso78>
Kintel yes, but the data which IS already created with polyset Bilder IS different, when sent in sphere() or Received in Translate ().
<guso78>
IT does Not matter when using openscad but IT makes Debugging very hard. I could Open a Ticket for that.
<guso78>
This could bei the reason for the flaky Tests. If we Turn Off this randomization. Bugs will either appear Always or never.
kintel has joined #openscad
<kintel>
guso78 I'm not sure what you're trying to achieve, but since you're relatively familiar with the low-level mechanisms I would suggest tracing the lifetime of a sphere and look into what happens.
<kintel>
I'm not sure if maintaining internal vertex order is something we'd aim for, but if it helps debugging and doesn't complicate the codebase too much, it could make sense to do it
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
teepee_ is now known as teepee
fling has quit [Ping timeout: 240 seconds]
fling has joined #openscad
FluxLalonde has joined #openscad
RoyK has quit [Ping timeout: 276 seconds]
RoyK has joined #openscad
ferdna_ has quit [Quit: Leaving]
<teepee>
kintel what's the view on GSoC this year? I suppose if we want to join again we want to review the topics keeping only really clearly defined ones
<FluxLalonde>
I've started poking module-litteral and I've come to my first surprise. Expect "module bar(foo) {...}" to be just sugar for "bar = module(foo){};". But passing bar as a module parameter only works with the anonymous declaration, not with the old-style syntax. Is this intentional?
Pringle has quit [Ping timeout: 250 seconds]
<peepsalot>
that's also how function literals work, so probably
<teepee>
FluxLalonde: I'm not sure it's easily possible, the main problem is that old style functions and modules have separate namespaces, so you can have a module, a function and a variable all with the same name
<peepsalot>
FluxLalonde: its sort of a namespace / backwards compatibilty issue.
<teepee>
seen JordanBrown
<othx>
JordanBrown was last seen in #openscad 5 days, 12 hours, 40 minutes, 48 seconds ago saying 'bye'.
<othx>
JordanBrown1 was last seen in #openscad 30 days, 12 hours, 44 minutes, 2 seconds ago saying 'myFancyEcho(), maybe.'.
<othx>
JordanBrown2 was last seen in #openscad 40 days, 19 hours, 12 minutes, 40 seconds ago saying 'teepee WRT '*'. Indeed. Sigh. I hate it when my mental model is wrong.'.
<teepee>
JordanBrown probably has the best memory regarding the very deep details as he did this PR based on a number of earlier work
J24k3 has joined #openscad
<FluxLalonde>
The namespace collision/backwards compatibility story makes sense. I've perhaps redundantly added a bit to the github PR conversation.
<guso78k60>
kintel, i found my data altering problem. It happened only in my offset branch where CGALUtils::applyUnion3D was called even when offset has only one child. applyUnion3D creates different union result each time. luckily i don't need it for my single child this fixed my issue.
<InPhase>
FluxLalonde: JordanBrown and I discussed the following look-up order as backwards compatible: Variables (including module and function references established by assignment), then conventionally defined functions and modules which then act as a reference. The only change this makes in terms of backwards compatibility is turning some cases of undef that already throw a warning, into well defined code
<InPhase>
grabbing a reference. But because this was already "invalid" code giving a warning, this is not a problem.
<InPhase>
FluxLalonde: In the event of a conventional variable and conventional module sharing a name, the prior behavior is still preserved where the variable wins in variable contexts.
<InPhase>
I don't think this was worked into the PR, but we thought about it for a while and as best I can remember from all the discussions, it seems to not cause issues.
<InPhase>
What we were mostly still debating on that PR was the syntax.
mmu_man has quit [Ping timeout: 268 seconds]
<FluxLalonde>
InPhase It would be good to be able to bridge the namespaces. Being able to say "foo = module (...) {bar(...);};" or somesuch to bridge from one to other *without* having to know the parameters of bar seems like the critical bridge. Or does it already exist and I haven't seen it?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
mmu_man has joined #openscad
<peepsalot>
hmm, I wonder if it would help to have "resolve" as a special function or keyword? something like: foo = resolve(module bar); where you still provide the namespace, but it puts it into an actual Value
<peepsalot>
or maybe thats a bit of a kludge
<FluxLalonde>
peepsalot: The "..." proposed would help some other cases as well. Being able to pass and call functions without binding all the variable by hand would be useful. Or even just reduce it to existing syntax: baz = module bar; I haven't examined the grammar to see how invasive this would be.
<InPhase>
peepsalot: I'd rather just have a complicated lookup order and "We recommend not reusing labels for variables, functions, and modules", or even declaring that deprecated, but still continuing to support it without warning.
<InPhase>
peepsalot: I think we widely regard this as a historical mistake that made language updates more challenging. Although we've avoided an issue with it so far, it might be a good idea to set in place a deprecation in case it becomes a more serious issue in the future.
<InPhase>
We don't have to break anything to make this work well now, because we have that lookup order loophole. But someday, this might be a more serious issue, and there might not be enough loopholes left. :)
<teepee>
but kudos for nice description and organization with cc-by license
FluxLalonde has quit [Quit: Client closed]
<J24k3>
those 100+ files models are quite successful - we have to accept smart people that can use a script are just 20% .. the other are used to search and download the model they want.
<teepee>
that would be something Printables could solve
<J24k3>
i wouldn't wonder if these people are overchallenged with more than one dropdown .. I just found an scad that is only a selector/viewer to import one of 7 different stl files
<teepee>
maybe that made sense on thingiverse with their customizer?
<teepee>
can't really see how though
<teepee>
talking of gsoc, I made a small project proposal list viewer as it seems the workshop session a couple of days ago did a bit dislike using a bugtracker directly
<kintel>
teepee re. gsoc - yeah, I feel we should significantly scale down the ambition level of projects. It's very easy for inexperienced students to grossly overestimate their abilities to contribute to a real-world, not uni toy project, codebase
<kintel>
..and we should, ideally, have someone internal who are committed/motivate to finish the work that was started
<kintel>
In that sense, the OpenGL project from last year was fine. ..despite me ending up replacing all the code during refactoring : /
<teepee>
looking at the current list, I would say we can keep 2 and maybe need one or 2 more
teepee has quit [Ping timeout: 240 seconds]
teepee has joined #openscad
teepee has quit [Remote host closed the connection]