> Another thing I noticed is the used file cache has way too many files. I think files used with both absolute and relative file paths get two cache entries. This again is my fault, or rather Bill Gate's. Under Windows paths are case insensitive. When I used a relative path it picked up the actual name of a directory that differed in case to the full paths I was using. When I corrected the directory name I also had to not open the file from the recent list as that was remembering the old name with the wrong case. Case insensitive paths are a mess, not sure how this should be fixed. I want my library to work on Linux as well as Windows so the paths have to be the correct case. It is only this bug / feature that made me realise I had some discrepancies left. I was previously alerted to some due to getting lots of new warnings about variables defined twice due to same file being reached by different case paths. I didn't report that as a bug because it was useful. One solution is to make all path comparisons case insensitive when running on Windows to match the file system. But then if you want a library to work on Linux you don't get any warnings when developing on Windows. On Fri, 30 Nov 2018 at 15:09, nop head <nop.head@gmail.com> wrote: > Actually it is my fault again. The undef is generated by false * 15. > Passing an actual true or false gives a correct error message assuming true > and false are not valid as numbers. > > > echo(version()); > echo(false * 5, true + 1); > translate([true, false, false * 15]); > > > ECHO: [2018, 11, 29] > > ECHO: undef, undef > > WARNING: Unable to convert translate([true, false, undef]) parameter to a > vec3 or vec2 of numbers, line 5 > > > > > > > > On Fri, 30 Nov 2018 at 13:49, Marius Kintel <marius@kintel.net> wrote: > >> >> > On Nov 30, 2018, at 6:52 AM, nop head <nop.head@gmail.com> wrote: >> > >> > Another issue is false is no longer converted to 0 when used in a >> vector parameter to translate. >> > >> > WARNING: Unable to convert translate([0, 0, undef]) parameter to a vec3 >> or vec2 of numbers, line 56 >> > >> > The undef is actually false. I thought true and false were converted to >> 1 , 0 when a number was required, as C. >> > >> This is worthy of a github ticket. >> >> -Marius >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >

On 29.11.18 17:06, Marius Kintel wrote: >> On Nov 29, 2018, at 10:32 AM, nop head <nop.head@gmail.com> wrote: >> Are all warnings supposed to show the file now, or is that still work in progress? >> > At least some of that is an open PR: https://github.com/openscad/openscad/pull/2593 Now replaced with https://github.com/openscad/openscad/pull/2615 >> Another thing I noticed is the used file cache has way too many files. I think files used with both absolute and relative file paths get two cache entries. > I had a similar concern last night, see my comment here: https://github.com/openscad/openscad/pull/2593#discussion_r237359938 > Not sure if we may need to backtrack through some of the warning stuff to figure this out.. It sound concerning to me that relatives paths are or might be used for cache entries. It is not unlikely that a user has an old copy of his project that uses a different version of library via relative paths and he uses both and old and new copy to debug something. On the bright side: Making all cache entire paths absolute would resolve both issues. With kind regards, Michael Frey

I think the cache entries probably are all absolute paths. The issue was in converting from no path to absolute the current directory is used. That had a different case to the absolute paths generated from OPENSCADLIBS, so got a different cache entry even though it was the same file due to Windows ignoring case. To debug it I generated a dependency file with the -d option. All the paths were absolute but the ones in the root directory of the project had a difference case for that directory. On Sat, 1 Dec 2018 at 12:40, Michael Frey <michael.frey@gmx.ch> wrote: > On 29.11.18 17:06, Marius Kintel wrote: > >> On Nov 29, 2018, at 10:32 AM, nop head <nop.head@gmail.com> wrote: > >> Are all warnings supposed to show the file now, or is that still work > in progress? > >> > > At least some of that is an open PR: > https://github.com/openscad/openscad/pull/2593 > Now replaced with https://github.com/openscad/openscad/pull/2615 > >> Another thing I noticed is the used file cache has way too many files. > I think files used with both absolute and relative file paths get two cache > entries. > > I had a similar concern last night, see my comment here: > https://github.com/openscad/openscad/pull/2593#discussion_r237359938 > > Not sure if we may need to backtrack through some of the warning stuff > to figure this out.. > > It sound concerning to me that relatives paths are or might be used for > cache entries. > > It is not unlikely that a user has an old copy of his project that uses > a different version of library via relative paths and he uses both and > old and new copy to debug something. > > On the bright side: Making all cache entire paths absolute would resolve > both issues. > > > With kind regards, > > Michael Frey > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >