<J1A8486245143>
and with thrust corefinement #23 this is so not helpfull
<J1A8486245143>
great the reason was a rotate([90])cylinder(150,d=2.0001,$fn=24); // i seen this now several times that certain sizes cause problems like 2 while 2.0001 works fine. This need to be fixed as this numbers may be a problem for float but are very regular used sizes.
J1A8486245143 is now known as J1A84
kwikius has quit [Quit: Client closed]
kwikius has joined #openscad
<InPhase>
J1A84: Do you have some very simple test cases that demonstrate it?
<InPhase>
J1A84: It will be important to check for failure to follow the overlap rule, which will be easier in simple cases.
<InPhase>
Or do you mean that one-liner does it?
<InPhase>
I am currently not getting any rendering issues from this on the master branch with d=2
<J1A84>
probably this happens when points in differnces coincident like cutting a d=10 cylinder from a cube(10,center);
<InPhase>
Yeah, that remains invalid as before, but it can be expected that the errors from it will differ between the two approaches.
<InPhase>
I have seen a large number of cases where fast-csg handles overlap failures in the desired way where the traditional approach fails on them, but there are also cases the other way around. This is just because the internal math is different so the failures will manifest in slightly different cases. We'll need to still keep that as undefined behavior for a design.
<J1A84>
in case of the cylinder it was indeed scratching the surface, but i had this also on other occasions with other modules - it is always solvable but the problem is you never know where the error is
<J1A84>
so difference #23 or whatever number is impossible to find - the error msg need to have a line number
<InPhase>
It would be helpful if we could get better diagnostic information out of CGAL, but the authors of it do not value this as a principle. They view such inputs as pathological inputs and programmer errors. We appear to be one of the few applications of their library where non-specialists are providing the positioning of inputs, and they have been resistant to making the error handling appropriate to this
<InPhase>
use case.
<J1A84>
damn
<J1A84>
so you need to run a analysis (render) every few lines so you know what code part causes the error
<J1A84>
also getting a lot error if $fs<.5
<J1A84>
but those are roof related (iirc)
<J1A84>
.. or just change all values by random e-12 values .. probably fixes these too (and may cause a bunch new errors)
<J1A84>
echo (str(undef)); ↦ "undef" wouldn't be "" better ?
<JordanBrown[m]>
No
<JordanBrown[m]>
I keep wondering whether there is a way to get from CSG and our polyhedral to and from Nef polyhedral, because Nef polyhedral allow touching edges and we already do a lot of our work with them.
<JordanBrown[m]>
DYAC all of those “polyhedral” should be polyhedra.
<JordanBrown[m]>
(The “no” was with respect to str(undef).)
<J1A84>
yeah but "undef" is also a defined string
kwikius has quit [Quit: Client closed]
teepee has quit [Ping timeout: 258 seconds]
teepee has joined #openscad
<JakeSays>
hey who is the person who was writing a super slicer in haskell?
<InPhase>
JakeSays: juri_
<JakeSays>
InPhase: ah thanks
<JakeSays>
juri_: hey how's your slicer progressing?
<JakeSays>
so what's new with openscad these days?
kwikius has joined #openscad
<teepee>
well, the newest is just one line above your question :D
<kwikius>
ModuleLiteral PR : So on the subject of context/scope , I think I need to store a ref to the scope where the ModuleLiteral is defined with the moduleLiteral to be used for evaluating default arguments https://github.com/kwikius/openscad/issues/3
<kwikius>
Yeah congrats to nickzoic for that one!
<kwikius>
ModueLiteral PR. Presumable this is a solved problem with FunctionLiteral though ?
<kwikius>
(meaning defining context for default args)
<JakeSays>
teepee: lol
<teepee>
kwikius: yeah, first check looks good in relation to capture. I think I found an issue, but that's pretty likely not specific to the module literal changes
<teepee>
it probably should capture also default values in the definition
<teepee>
I think I had some issue when calling a function literal that returns a module literal
<teepee>
not sure, I did not have time to have a very close look, first trying to check out the user facing side
<kwikius>
Hokeydokey check that but will press on anyway So firstly I should grab Localscope off the top of the scope_stack, but not evaluate default args there since thing like $fn may be modified at the place the module literal is instantiated?
<teepee>
so this works: ff = function (x) function (y) x + y; echo(ff(3)(5));
<teepee>
now the question is, should that work too: fm = function (x) module (y) cube([x, y, 2]); fm(3)(5);
<InPhase>
teepee: Yes, for a module literal with that syntax.
<InPhase>
teepee: However did you see our discussion the other night about how function literals are already module literals with some very minimal changes if we just have object literals working right? :)
<InPhase>
function could become the "both" syntax.
<teepee>
no, but that sounds promising, as that unification was also one of the goal in the openscad2 proposal
<InPhase>
And in a non-breaking manner with some simple rules like "call old-school modules instead of function literals if they exist in the same scope at a module context."
<teepee>
I *really* would like that as it seems a good path forward instead of solidifying the distinction originally introduced even with the different name spaces
<InPhase>
We didn't write it out other than in the chat here, but we hammered it out and it seemed to work out okay as a concept.
<kwikius>
In the expression, is module (y) cube([x, y, 2]); fm(3)(5); all one module literal ?
<teepee>
yeah, we have that fallback for the function literals already I think, so maybe not perfect, but I guess a reasonable compromise for compatibility
<teepee>
kwikius: no it ends at the ;
<teepee>
fm(3)(5); would be the part that probably should yield the cube([3, 5, 2]);
<teepee>
that could turn out to be tricky on the parser side though
pbsds has quit [Ping timeout: 265 seconds]
<kwikius>
f0 = function (s) module cube(s); // WARNING: Ignoring unknown variable 's' in file test.scad, line 1
<kwikius>
m0 = f0(10);
<kwikius>
m0();
<kwikius>
f1 = function () module cube([5,10,20]);
<kwikius>
m1 = f1();
<kwikius>
m1(); // graphical output of the cube from m1();
<kwikius>
I reckon that is baecause modules don't do lookup in function parameter scope, presumably because they never had to
<kwikius>
Also you cant instantiate an r-value module reference
<kwikius>
ar = [ module cube(10)];
<kwikius>
m(); /// ok
<kwikius>
ar[0](); /// syntax error
<kwikius>
should be an m = ar[0]; in there
<teepee>
yes, at this point there's no expression on the left side or statement
<kwikius>
For this fm = function (x) module (y) cube([x, y, 2]); fm(3)(5);
<kwikius>
I think is same as
<kwikius>
cube([10,20,30])(5); // syntax error
<teepee>
it should be a function returning a module reference
<teepee>
and that seems to be the case
<teepee>
minus the non-working passing of x it does work when assigning the function result to another variable
<teepee>
so the returned values are fine, it's just that the parser only understands a single lookup on the statement part
<kwikius>
I think it is a question of examining scope lookup for modules. I had a look and felt it could be loosened from what it is.. some abstract base class somewhere
<J1A84>
great(y) is displayed as emoticon thumbsUP .. and i was wondering if now emoticons can be names Ü
<teepee>
there's a big chance we need to use a different lexer for unicode support or maybe there's an official flex version doing that at some point
<teepee>
also, actual emoji, no, never :P
<teepee>
if we would start supporting more than boring ascii, that should be the codepoints classified as ID by the unicode spec
<J1A84>
so as printing round edges will create bad overhangs at bottom .. but chamfer is so edgy so here the limited rounding https://imgur.com/a/nD7vH0I
<teepee>
looks nicely printable
<J1A84>
the intention was to create nice elongated holes ..
<InPhase>
Oops, that's right. You do not all have my one-true color scheme yet. This has the color fully specified: https://bpa.st/ZEYQ
<teepee>
InPhase: looks quite cool in my tomorrow color scheme already :)
<teepee>
which had a dark blue cabin
<InPhase>
:)
<InPhase>
Perhaps someday I will be able to specify a glass canopy shader.
<InPhase>
Looks like I can hit 50fps in animation with this.
<InPhase>
(Timing to make sure it completes the full circuit in the specified time, since there is no "real" fps marker other than that.)
<J1A84>
print and put on a ceiling fan
<InPhase>
:)
<InPhase>
I'm trying a printed copy at the moment. Although it will be needing supports, since the original F-15 design was not really planned as a printable shape.
<InPhase>
I will need to submit a complaint to McDonnell Douglas later about this.
<J1A84>
do you know the pip F14 with spreadable wings
<InPhase>
I had not seen it. Perhaps I will try printing that one later.
<InPhase>
I was wondering how you would do that and not fail horribly.
<InPhase>
I'm not sure if my printer is still in good enough shape to handle it though. It is in desperate need of a recalibration, which I've been putting off because it's also about time to replace it with a better model.
<kwikius>
Guy Fawkes night coming up in UK... if you need a motor for that
<kwikius>
Wings in on the way up and pop out on the way down... would be nice!