Due to issues I have had with CGAL generated shapes forming non-manifold STL files, making them difficult to import into other tools, I have been focusing on doing as much of my design as possible in userspace, generating 3D polyhedrons. This has been a lot of work due to limited support in the codebase, particularly as I am limited to running in the 2015 version. It would definitely be nice to have some 3d union, difference, and intersection functions for polyhedrons, but up until now I have been making do. I am having a couple of problems with this approach. One of these is that the internal code-base does not always seem to be able to handle userspace polygons properly. For example, I have a complex shape which is totally manifold, forms a single object, and renders perfectly, if I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is properly mirrored, but if I display both the original shape and the mirrored one, the show properly in the preview but either go non-manifold or vanish entirely when rendered. I also have issues when trying to union my shape with other shapes, it always works fine in preview, but when I render, it may work, or it may give an assertion failure and leave my shape out of the final rendering. Actually, in the example I am including a screenshot of, there was no error or warning at all when it rendered, it just removed my shape... Does anybody have any suggestions on what I can do to work around this? There are shapes that would be REALLY annoying for my to do in userspace, but if I can't find a workaround or solution for this, I am going to have to do so...

2015 is so long ago l don't remember what issues it had. In general though the way to avoid this type of issue is to make sure vertices are either exactly numerically the same, or different by a significant margin. Close vertices get merged and that breaks topology. Another tip is to clear the cache before F6. Preview can cache corrupted meshes. When objects disappear without an error it is usually because the error was generated earlier and an empty mesh was cached. On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> wrote: > Due to issues I have had with CGAL generated shapes forming > non-manifold STL files, making them difficult to import into other > tools, I have been focusing on doing as much of my design as possible > in userspace, generating 3D polyhedrons. This has been a lot of work > due to limited support in the codebase, particularly as I am limited > to running in the 2015 version. It would definitely be nice to have > some 3d union, difference, and intersection functions for polyhedrons, > but up until now I have been making do. > I am having a couple of problems with this approach. One of these is > that the internal code-base does not always seem to be able to handle > userspace polygons properly. For example, I have a complex shape which > is totally manifold, forms a single object, and renders perfectly, if > I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is > properly mirrored, but if I display both the original shape and the > mirrored one, the show properly in the preview but either go > non-manifold or vanish entirely when rendered. > I also have issues when trying to union my shape with other shapes, it > always works fine in preview, but when I render, it may work, or it > may give an assertion failure and leave my shape out of the final > rendering. Actually, in the example I am including a screenshot of, > there was no error or warning at all when it rendered, it just removed > my shape... > Does anybody have any suggestions on what I can do to work around > this? There are shapes that would be REALLY annoying for my to do in > userspace, but if I can't find a workaround or solution for this, I am > going to have to do so... > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

Oddly enough, even if the two shapes have no overlap at all, by even a significant margin, I can't get them to render properly. I have tried with a large visible gap between the two parts, and it still discard the polyhedron, which is definitely valid. On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: > > 2015 is so long ago l don't remember what issues it had. In general though the way to avoid this type of issue is to make sure vertices are either exactly numerically the same, or different by a significant margin. Close vertices get merged and that breaks topology. > > Another tip is to clear the cache before F6. Preview can cache corrupted meshes. > > When objects disappear without an error it is usually because the error was generated earlier and an empty mesh was cached. > > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> wrote: >> >> Due to issues I have had with CGAL generated shapes forming >> non-manifold STL files, making them difficult to import into other >> tools, I have been focusing on doing as much of my design as possible >> in userspace, generating 3D polyhedrons. This has been a lot of work >> due to limited support in the codebase, particularly as I am limited >> to running in the 2015 version. It would definitely be nice to have >> some 3d union, difference, and intersection functions for polyhedrons, >> but up until now I have been making do. >> I am having a couple of problems with this approach. One of these is >> that the internal code-base does not always seem to be able to handle >> userspace polygons properly. For example, I have a complex shape which >> is totally manifold, forms a single object, and renders perfectly, if >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >> properly mirrored, but if I display both the original shape and the >> mirrored one, the show properly in the preview but either go >> non-manifold or vanish entirely when rendered. >> I also have issues when trying to union my shape with other shapes, it >> always works fine in preview, but when I render, it may work, or it >> may give an assertion failure and leave my shape out of the final >> rendering. Actually, in the example I am including a screenshot of, >> there was no error or warning at all when it rendered, it just removed >> my shape... >> Does anybody have any suggestions on what I can do to work around >> this? There are shapes that would be REALLY annoying for my to do in >> userspace, but if I can't find a workaround or solution for this, I am >> going to have to do so... >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

While I have been limiting myself to the most recent release version (2015???), I decided to try the most recent RC4 version, so see if things are improved. Unfortunately, it is totally unusable for me, as the code generated thousands of warnings for: WARNING: len() parameter could not be converted, in file ../util/util.scad, line 21 The length checks it is warning about are part of my type checking functions. Is there any way to reduce the warning level? I understand the reason for the warnings, but it makes it VERY difficult to work with the same code in multiple versions of the software, and I will have to rewrite significant parts of my library to use functionality that doesn't exist in the older version of openSCAD On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: > > 2015 is so long ago l don't remember what issues it had. In general though the way to avoid this type of issue is to make sure vertices are either exactly numerically the same, or different by a significant margin. Close vertices get merged and that breaks topology. > > Another tip is to clear the cache before F6. Preview can cache corrupted meshes. > > When objects disappear without an error it is usually because the error was generated earlier and an empty mesh was cached. > > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> wrote: >> >> Due to issues I have had with CGAL generated shapes forming >> non-manifold STL files, making them difficult to import into other >> tools, I have been focusing on doing as much of my design as possible >> in userspace, generating 3D polyhedrons. This has been a lot of work >> due to limited support in the codebase, particularly as I am limited >> to running in the 2015 version. It would definitely be nice to have >> some 3d union, difference, and intersection functions for polyhedrons, >> but up until now I have been making do. >> I am having a couple of problems with this approach. One of these is >> that the internal code-base does not always seem to be able to handle >> userspace polygons properly. For example, I have a complex shape which >> is totally manifold, forms a single object, and renders perfectly, if >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >> properly mirrored, but if I display both the original shape and the >> mirrored one, the show properly in the preview but either go >> non-manifold or vanish entirely when rendered. >> I also have issues when trying to union my shape with other shapes, it >> always works fine in preview, but when I render, it may work, or it >> may give an assertion failure and leave my shape out of the final >> rendering. Actually, in the example I am including a screenshot of, >> there was no error or warning at all when it rendered, it just removed >> my shape... >> Does anybody have any suggestions on what I can do to work around >> this? There are shapes that would be REALLY annoying for my to do in >> userspace, but if I can't find a workaround or solution for this, I am >> going to have to do so... >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Yes len should never have been changed. It is a total pain. You have to use is_list to check it is a list first even though it is documented to return undef for a scalar. Unless this is reverted it will lead to a wall of complaints and slow adoption of the new release. On Wed, 17 Apr 2019, 12:25 A. Craig West, <acraigwest@gmail.com> wrote: > While I have been limiting myself to the most recent release version > (2015???), I decided to try the most recent RC4 version, so see if > things are improved. Unfortunately, it is totally unusable for me, as > the code generated thousands of warnings for: > WARNING: len() parameter could not be converted, in file > ../util/util.scad, line 21 > The length checks it is warning about are part of my type checking > functions. Is there any way to reduce the warning level? I understand > the reason for the warnings, but it makes it VERY difficult to work > with the same code in multiple versions of the software, and I will > have to rewrite significant parts of my library to use functionality > that doesn't exist in the older version of openSCAD > > On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: > > > > 2015 is so long ago l don't remember what issues it had. In general > though the way to avoid this type of issue is to make sure vertices are > either exactly numerically the same, or different by a significant margin. > Close vertices get merged and that breaks topology. > > > > Another tip is to clear the cache before F6. Preview can cache corrupted > meshes. > > > > When objects disappear without an error it is usually because the error > was generated earlier and an empty mesh was cached. > > > > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> wrote: > >> > >> Due to issues I have had with CGAL generated shapes forming > >> non-manifold STL files, making them difficult to import into other > >> tools, I have been focusing on doing as much of my design as possible > >> in userspace, generating 3D polyhedrons. This has been a lot of work > >> due to limited support in the codebase, particularly as I am limited > >> to running in the 2015 version. It would definitely be nice to have > >> some 3d union, difference, and intersection functions for polyhedrons, > >> but up until now I have been making do. > >> I am having a couple of problems with this approach. One of these is > >> that the internal code-base does not always seem to be able to handle > >> userspace polygons properly. For example, I have a complex shape which > >> is totally manifold, forms a single object, and renders perfectly, if > >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is > >> properly mirrored, but if I display both the original shape and the > >> mirrored one, the show properly in the preview but either go > >> non-manifold or vanish entirely when rendered. > >> I also have issues when trying to union my shape with other shapes, it > >> always works fine in preview, but when I render, it may work, or it > >> may give an assertion failure and leave my shape out of the final > >> rendering. Actually, in the example I am including a screenshot of, > >> there was no error or warning at all when it rendered, it just removed > >> my shape... > >> Does anybody have any suggestions on what I can do to work around > >> this? There are shapes that would be REALLY annoying for my to do in > >> userspace, but if I can't find a workaround or solution for this, I am > >> going to have to do so... > >> _______________________________________________ > >> OpenSCAD mailing list > >> Discuss@lists.openscad.org > >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > > > _______________________________________________ > > OpenSCAD mailing list > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

In my case I am using it as part of an isArray function definition, so it shouldn't be too painful. It's a VERY common idiom, and warni. Gs seem to cause a lot of overhead in the ui. My hode, which normally renders in around a minute, was well running for much longer than that with no sign of completion due to all of the warnings On Wed, 17 Apr 2019, 07:43 nop head, <nop.head@gmail.com> wrote: > Yes len should never have been changed. It is a total pain. You have to > use is_list to check it is a list first even though it is documented to > return undef for a scalar. > > > Unless this is reverted it will lead to a wall of complaints and slow > adoption of the new release. > > On Wed, 17 Apr 2019, 12:25 A. Craig West, <acraigwest@gmail.com> wrote: > >> While I have been limiting myself to the most recent release version >> (2015???), I decided to try the most recent RC4 version, so see if >> things are improved. Unfortunately, it is totally unusable for me, as >> the code generated thousands of warnings for: >> WARNING: len() parameter could not be converted, in file >> ../util/util.scad, line 21 >> The length checks it is warning about are part of my type checking >> functions. Is there any way to reduce the warning level? I understand >> the reason for the warnings, but it makes it VERY difficult to work >> with the same code in multiple versions of the software, and I will >> have to rewrite significant parts of my library to use functionality >> that doesn't exist in the older version of openSCAD >> >> On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: >> > >> > 2015 is so long ago l don't remember what issues it had. In general >> though the way to avoid this type of issue is to make sure vertices are >> either exactly numerically the same, or different by a significant margin. >> Close vertices get merged and that breaks topology. >> > >> > Another tip is to clear the cache before F6. Preview can cache >> corrupted meshes. >> > >> > When objects disappear without an error it is usually because the error >> was generated earlier and an empty mesh was cached. >> > >> > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> wrote: >> >> >> >> Due to issues I have had with CGAL generated shapes forming >> >> non-manifold STL files, making them difficult to import into other >> >> tools, I have been focusing on doing as much of my design as possible >> >> in userspace, generating 3D polyhedrons. This has been a lot of work >> >> due to limited support in the codebase, particularly as I am limited >> >> to running in the 2015 version. It would definitely be nice to have >> >> some 3d union, difference, and intersection functions for polyhedrons, >> >> but up until now I have been making do. >> >> I am having a couple of problems with this approach. One of these is >> >> that the internal code-base does not always seem to be able to handle >> >> userspace polygons properly. For example, I have a complex shape which >> >> is totally manifold, forms a single object, and renders perfectly, if >> >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >> >> properly mirrored, but if I display both the original shape and the >> >> mirrored one, the show properly in the preview but either go >> >> non-manifold or vanish entirely when rendered. >> >> I also have issues when trying to union my shape with other shapes, it >> >> always works fine in preview, but when I render, it may work, or it >> >> may give an assertion failure and leave my shape out of the final >> >> rendering. Actually, in the example I am including a screenshot of, >> >> there was no error or warning at all when it rendered, it just removed >> >> my shape... >> >> Does anybody have any suggestions on what I can do to work around >> >> this? There are shapes that would be REALLY annoying for my to do in >> >> userspace, but if I can't find a workaround or solution for this, I am >> >> going to have to do so... >> >> _______________________________________________ >> >> OpenSCAD mailing list >> >> Discuss@lists.openscad.org >> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > >> > _______________________________________________ >> > OpenSCAD mailing list >> > Discuss@lists.openscad.org >> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

@kintel please can we have len reverted to match it's long documented spec On Wed, 17 Apr 2019, 13:25 A. Craig West, <acraigwest@gmail.com> wrote: > In my case I am using it as part of an isArray function definition, so it > shouldn't be too painful. It's a VERY common idiom, and warni. Gs seem to > cause a lot of overhead in the ui. My hode, which normally renders in > around a minute, was well running for much longer than that with no sign of > completion due to all of the warnings > > On Wed, 17 Apr 2019, 07:43 nop head, <nop.head@gmail.com> wrote: > >> Yes len should never have been changed. It is a total pain. You have to >> use is_list to check it is a list first even though it is documented to >> return undef for a scalar. >> >> >> Unless this is reverted it will lead to a wall of complaints and slow >> adoption of the new release. >> >> On Wed, 17 Apr 2019, 12:25 A. Craig West, <acraigwest@gmail.com> wrote: >> >>> While I have been limiting myself to the most recent release version >>> (2015???), I decided to try the most recent RC4 version, so see if >>> things are improved. Unfortunately, it is totally unusable for me, as >>> the code generated thousands of warnings for: >>> WARNING: len() parameter could not be converted, in file >>> ../util/util.scad, line 21 >>> The length checks it is warning about are part of my type checking >>> functions. Is there any way to reduce the warning level? I understand >>> the reason for the warnings, but it makes it VERY difficult to work >>> with the same code in multiple versions of the software, and I will >>> have to rewrite significant parts of my library to use functionality >>> that doesn't exist in the older version of openSCAD >>> >>> On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: >>> > >>> > 2015 is so long ago l don't remember what issues it had. In general >>> though the way to avoid this type of issue is to make sure vertices are >>> either exactly numerically the same, or different by a significant margin. >>> Close vertices get merged and that breaks topology. >>> > >>> > Another tip is to clear the cache before F6. Preview can cache >>> corrupted meshes. >>> > >>> > When objects disappear without an error it is usually because the >>> error was generated earlier and an empty mesh was cached. >>> > >>> > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> >>> wrote: >>> >> >>> >> Due to issues I have had with CGAL generated shapes forming >>> >> non-manifold STL files, making them difficult to import into other >>> >> tools, I have been focusing on doing as much of my design as possible >>> >> in userspace, generating 3D polyhedrons. This has been a lot of work >>> >> due to limited support in the codebase, particularly as I am limited >>> >> to running in the 2015 version. It would definitely be nice to have >>> >> some 3d union, difference, and intersection functions for polyhedrons, >>> >> but up until now I have been making do. >>> >> I am having a couple of problems with this approach. One of these is >>> >> that the internal code-base does not always seem to be able to handle >>> >> userspace polygons properly. For example, I have a complex shape which >>> >> is totally manifold, forms a single object, and renders perfectly, if >>> >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >>> >> properly mirrored, but if I display both the original shape and the >>> >> mirrored one, the show properly in the preview but either go >>> >> non-manifold or vanish entirely when rendered. >>> >> I also have issues when trying to union my shape with other shapes, it >>> >> always works fine in preview, but when I render, it may work, or it >>> >> may give an assertion failure and leave my shape out of the final >>> >> rendering. Actually, in the example I am including a screenshot of, >>> >> there was no error or warning at all when it rendered, it just removed >>> >> my shape... >>> >> Does anybody have any suggestions on what I can do to work around >>> >> this? There are shapes that would be REALLY annoying for my to do in >>> >> userspace, but if I can't find a workaround or solution for this, I am >>> >> going to have to do so... >>> >> _______________________________________________ >>> >> OpenSCAD mailing list >>> >> Discuss@lists.openscad.org >>> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> > >>> > _______________________________________________ >>> > OpenSCAD mailing list >>> > Discuss@lists.openscad.org >>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

The discussion of this in the archives is rather extensive, I really don't see what is gained by the check. If the user wasn't expecting the documented behaviour, they will get an undef warning in any case On Wed, 17 Apr 2019, 08:37 nop head, <nop.head@gmail.com> wrote: > @kintel please can we have len reverted to match it's long documented spec > > On Wed, 17 Apr 2019, 13:25 A. Craig West, <acraigwest@gmail.com> wrote: > >> In my case I am using it as part of an isArray function definition, so it >> shouldn't be too painful. It's a VERY common idiom, and warni. Gs seem to >> cause a lot of overhead in the ui. My hode, which normally renders in >> around a minute, was well running for much longer than that with no sign of >> completion due to all of the warnings >> >> On Wed, 17 Apr 2019, 07:43 nop head, <nop.head@gmail.com> wrote: >> >>> Yes len should never have been changed. It is a total pain. You have to >>> use is_list to check it is a list first even though it is documented to >>> return undef for a scalar. >>> >>> >>> Unless this is reverted it will lead to a wall of complaints and slow >>> adoption of the new release. >>> >>> On Wed, 17 Apr 2019, 12:25 A. Craig West, <acraigwest@gmail.com> wrote: >>> >>>> While I have been limiting myself to the most recent release version >>>> (2015???), I decided to try the most recent RC4 version, so see if >>>> things are improved. Unfortunately, it is totally unusable for me, as >>>> the code generated thousands of warnings for: >>>> WARNING: len() parameter could not be converted, in file >>>> ../util/util.scad, line 21 >>>> The length checks it is warning about are part of my type checking >>>> functions. Is there any way to reduce the warning level? I understand >>>> the reason for the warnings, but it makes it VERY difficult to work >>>> with the same code in multiple versions of the software, and I will >>>> have to rewrite significant parts of my library to use functionality >>>> that doesn't exist in the older version of openSCAD >>>> >>>> On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: >>>> > >>>> > 2015 is so long ago l don't remember what issues it had. In general >>>> though the way to avoid this type of issue is to make sure vertices are >>>> either exactly numerically the same, or different by a significant margin. >>>> Close vertices get merged and that breaks topology. >>>> > >>>> > Another tip is to clear the cache before F6. Preview can cache >>>> corrupted meshes. >>>> > >>>> > When objects disappear without an error it is usually because the >>>> error was generated earlier and an empty mesh was cached. >>>> > >>>> > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> >>>> wrote: >>>> >> >>>> >> Due to issues I have had with CGAL generated shapes forming >>>> >> non-manifold STL files, making them difficult to import into other >>>> >> tools, I have been focusing on doing as much of my design as possible >>>> >> in userspace, generating 3D polyhedrons. This has been a lot of work >>>> >> due to limited support in the codebase, particularly as I am limited >>>> >> to running in the 2015 version. It would definitely be nice to have >>>> >> some 3d union, difference, and intersection functions for >>>> polyhedrons, >>>> >> but up until now I have been making do. >>>> >> I am having a couple of problems with this approach. One of these is >>>> >> that the internal code-base does not always seem to be able to handle >>>> >> userspace polygons properly. For example, I have a complex shape >>>> which >>>> >> is totally manifold, forms a single object, and renders perfectly, if >>>> >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >>>> >> properly mirrored, but if I display both the original shape and the >>>> >> mirrored one, the show properly in the preview but either go >>>> >> non-manifold or vanish entirely when rendered. >>>> >> I also have issues when trying to union my shape with other shapes, >>>> it >>>> >> always works fine in preview, but when I render, it may work, or it >>>> >> may give an assertion failure and leave my shape out of the final >>>> >> rendering. Actually, in the example I am including a screenshot of, >>>> >> there was no error or warning at all when it rendered, it just >>>> removed >>>> >> my shape... >>>> >> Does anybody have any suggestions on what I can do to work around >>>> >> this? There are shapes that would be REALLY annoying for my to do in >>>> >> userspace, but if I can't find a workaround or solution for this, I >>>> am >>>> >> going to have to do so... >>>> >> _______________________________________________ >>>> >> OpenSCAD mailing list >>>> >> Discuss@lists.openscad.org >>>> >> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> > >>>> > _______________________________________________ >>>> > OpenSCAD mailing list >>>> > Discuss@lists.openscad.org >>>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

Exactly. And the only workarounds make code longer, which cannot be progress. On Wed, 17 Apr 2019, 14:29 A. Craig West, <acraigwest@gmail.com> wrote: > The discussion of this in the archives is rather extensive, I really don't > see what is gained by the check. If the user wasn't expecting the > documented behaviour, they will get an undef warning in any case > > On Wed, 17 Apr 2019, 08:37 nop head, <nop.head@gmail.com> wrote: > >> @kintel please can we have len reverted to match it's long documented spec >> >> On Wed, 17 Apr 2019, 13:25 A. Craig West, <acraigwest@gmail.com> wrote: >> >>> In my case I am using it as part of an isArray function definition, so >>> it shouldn't be too painful. It's a VERY common idiom, and warni. Gs seem >>> to cause a lot of overhead in the ui. My hode, which normally renders in >>> around a minute, was well running for much longer than that with no sign of >>> completion due to all of the warnings >>> >>> On Wed, 17 Apr 2019, 07:43 nop head, <nop.head@gmail.com> wrote: >>> >>>> Yes len should never have been changed. It is a total pain. You have to >>>> use is_list to check it is a list first even though it is documented to >>>> return undef for a scalar. >>>> >>>> >>>> Unless this is reverted it will lead to a wall of complaints and slow >>>> adoption of the new release. >>>> >>>> On Wed, 17 Apr 2019, 12:25 A. Craig West, <acraigwest@gmail.com> wrote: >>>> >>>>> While I have been limiting myself to the most recent release version >>>>> (2015???), I decided to try the most recent RC4 version, so see if >>>>> things are improved. Unfortunately, it is totally unusable for me, as >>>>> the code generated thousands of warnings for: >>>>> WARNING: len() parameter could not be converted, in file >>>>> ../util/util.scad, line 21 >>>>> The length checks it is warning about are part of my type checking >>>>> functions. Is there any way to reduce the warning level? I understand >>>>> the reason for the warnings, but it makes it VERY difficult to work >>>>> with the same code in multiple versions of the software, and I will >>>>> have to rewrite significant parts of my library to use functionality >>>>> that doesn't exist in the older version of openSCAD >>>>> >>>>> On Wed, Apr 17, 2019 at 4:44 AM nop head <nop.head@gmail.com> wrote: >>>>> > >>>>> > 2015 is so long ago l don't remember what issues it had. In general >>>>> though the way to avoid this type of issue is to make sure vertices are >>>>> either exactly numerically the same, or different by a significant margin. >>>>> Close vertices get merged and that breaks topology. >>>>> > >>>>> > Another tip is to clear the cache before F6. Preview can cache >>>>> corrupted meshes. >>>>> > >>>>> > When objects disappear without an error it is usually because the >>>>> error was generated earlier and an empty mesh was cached. >>>>> > >>>>> > On Wed, 17 Apr 2019, 02:24 A. Craig West, <acraigwest@gmail.com> >>>>> wrote: >>>>> >> >>>>> >> Due to issues I have had with CGAL generated shapes forming >>>>> >> non-manifold STL files, making them difficult to import into other >>>>> >> tools, I have been focusing on doing as much of my design as >>>>> possible >>>>> >> in userspace, generating 3D polyhedrons. This has been a lot of work >>>>> >> due to limited support in the codebase, particularly as I am limited >>>>> >> to running in the 2015 version. It would definitely be nice to have >>>>> >> some 3d union, difference, and intersection functions for >>>>> polyhedrons, >>>>> >> but up until now I have been making do. >>>>> >> I am having a couple of problems with this approach. One of these is >>>>> >> that the internal code-base does not always seem to be able to >>>>> handle >>>>> >> userspace polygons properly. For example, I have a complex shape >>>>> which >>>>> >> is totally manifold, forms a single object, and renders perfectly, >>>>> if >>>>> >> I put it in a scale([-1, 1, 1]) or mirror([1, 0, 0]) module, it is >>>>> >> properly mirrored, but if I display both the original shape and the >>>>> >> mirrored one, the show properly in the preview but either go >>>>> >> non-manifold or vanish entirely when rendered. >>>>> >> I also have issues when trying to union my shape with other shapes, >>>>> it >>>>> >> always works fine in preview, but when I render, it may work, or it >>>>> >> may give an assertion failure and leave my shape out of the final >>>>> >> rendering. Actually, in the example I am including a screenshot of, >>>>> >> there was no error or warning at all when it rendered, it just >>>>> removed >>>>> >> my shape... >>>>> >> Does anybody have any suggestions on what I can do to work around >>>>> >> this? There are shapes that would be REALLY annoying for my to do in >>>>> >> userspace, but if I can't find a workaround or solution for this, I >>>>> am >>>>> >> going to have to do so... >>>>> >> _______________________________________________ >>>>> >> OpenSCAD mailing list >>>>> >> Discuss@lists.openscad.org >>>>> >> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> > >>>>> > _______________________________________________ >>>>> > OpenSCAD mailing list >>>>> > Discuss@lists.openscad.org >>>>> > >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

Since is_list() is not available in older OpenSCAD versions I ve changed my codebase to use mylist = 1; mylist = [1]; echo(mylist[0] != undef); This expression works down to 2015. -- Sent from: http://forum.openscad.org/