Empathy List Archives

RW

Roger Whiteley

Wed, Apr 13, 2022 7:28 AM

I'm trying to pull files into a separate Openscad design which are
located on a pathname which is failing with WARNING: Can't open library
'../g1-dot-5/filename.scad'. I'm using OpenSCAD 2019.05.

The use or include looks like [doesn't matter which].

use <../g1-dot-5/testfilename.scad>

I've got this horrible feeling that the dash in front of the number 5 is
being interpreted as a subtract, because the number 5 is maroon, so the
use or include fails.

I copied a standard library, in the libraries folder,
corner-tools.scad, to corner-tools-2.scad and included that as an
experiment, the 2.scad turned maroon, e.g.

include <corner-tools-2.scad>

I've tried escaping the 5, I've tried a symbolic link [Ubuntu 20.04.4
LTS]. So regrettably I resort to the collective great minds of the
developers.

Bug or feature?, if I have to I'll move the file [except its one of
about 50 design files in the same folder] or rename the folder, but
renaming the folder is a last resort, because of dependencies outside
OpenSCAD.

TIA

Roger

I'm trying to pull files into a separate Openscad design which are located on a pathname which is failing with WARNING: Can't open library '../g1-dot-5/filename.scad'. I'm using OpenSCAD 2019.05. The use or include looks like [doesn't matter which]. use <../g1-dot-5/testfilename.scad> I've got this horrible feeling that the dash in front of the number 5 is being interpreted as a subtract, because the number 5 is maroon, so the use or include fails. I copied a standard library, in the libraries folder, corner-tools.scad, to corner-tools-2.scad and included that as an experiment, the 2.scad turned maroon, e.g. include <corner-tools-2.scad> I've tried escaping the 5, I've tried a symbolic link [Ubuntu 20.04.4 LTS]. So regrettably I resort to the collective great minds of the developers. Bug or feature?, if I have to I'll move the file [except its one of about 50 design files in the same folder] or rename the folder, but renaming the folder is a last resort, because of dependencies outside OpenSCAD. TIA Roger

DM

Douglas Miller

Wed, Apr 13, 2022 12:06 PM

Bug or feature?

I think I'm gonna go with "bug" here. I am also using OpenSCAD 2019.05,
but on a Windows platform (Win10 Pro, specifically). For me, also, the
number turns maroon, but no warnings are emitted and the design renders
as expected.

For what it's worth, the color change is independent of whether the -#
occurs at the end of the path, or in the middle.

On 4/13/2022 3:28 AM, Roger Whiteley wrote:

I'm trying to pull files into a separate Openscad design which are
located on a pathname which is failing with WARNING: Can't open
library '../g1-dot-5/filename.scad'. I'm using OpenSCAD 2019.05.

The use or include looks like [doesn't matter which].

use <../g1-dot-5/testfilename.scad>

I've got this horrible feeling that the dash in front of the number 5
is being interpreted as a subtract, because the number 5 is maroon, so
the use or include fails.

I copied a standard library, in the libraries folder,
corner-tools.scad, to corner-tools-2.scad and included that as an
experiment, the 2.scad turned maroon, e.g.

include <corner-tools-2.scad>

I've tried escaping the 5, I've tried a symbolic link [Ubuntu 20.04.4
LTS]. So regrettably I resort to the collective great minds of the
developers.

Bug or feature?, if I have to I'll move the file [except its one of
about 50 design files in the same folder] or rename the folder, but
renaming the folder is a last resort, because of dependencies outside
OpenSCAD.

TIA

Roger

> Bug or feature? I think I'm gonna go with "bug" here. I am also using OpenSCAD 2019.05, but on a Windows platform (Win10 Pro, specifically). For me, also, the number turns maroon, but no warnings are emitted and the design renders as expected. For what it's worth, the color change is independent of whether the -# occurs at the end of the path, or in the middle. On 4/13/2022 3:28 AM, Roger Whiteley wrote: > I'm trying to pull files into a separate Openscad design which are > located on a pathname which is failing with WARNING: Can't open > library '../g1-dot-5/filename.scad'. I'm using OpenSCAD 2019.05. > > The use or include looks like [doesn't matter which]. > > use <../g1-dot-5/testfilename.scad> > > I've got this horrible feeling that the dash in front of the number 5 > is being interpreted as a subtract, because the number 5 is maroon, so > the use or include fails. > > I copied a standard library, in the libraries folder, > corner-tools.scad, to corner-tools-2.scad and included that as an > experiment, the 2.scad turned maroon, e.g. > > include <corner-tools-2.scad> > > I've tried escaping the 5, I've tried a symbolic link [Ubuntu 20.04.4 > LTS]. So regrettably I resort to the collective great minds of the > developers. > > Bug or feature?, if I have to I'll move the file [except its one of > about 50 design files in the same folder] or rename the folder, but > renaming the folder is a last resort, because of dependencies outside > OpenSCAD. > > > TIA > > Roger >

MF

Michael Frey

Wed, Apr 13, 2022 6:34 PM

On 13.04.22 14:06, Douglas Miller wrote:

Bug or feature?

I think I'm gonna go with "bug" here. I am also using OpenSCAD
2019.05, but on a Windows platform (Win10 Pro, specifically). For me,
also, the number turns maroon, but no warnings are emitted and the
design renders as expected.

Note: the bug is only with the syntax highlighting.

It is fixed with https://github.com/openscad/openscad/pull/4205 which
was merged 5 days ago.

There is currently no windows development snapshot with that fix.

Note: the fix is only for the syntax highlighting.

The lexer for running scad files is different from the lexer for syntax
highlighting.

The bug is just cosmetic.

With Kind regards,

Michael Frey

On 13.04.22 14:06, Douglas Miller wrote: >> Bug or feature? > I think I'm gonna go with "bug" here. I am also using OpenSCAD > 2019.05, but on a Windows platform (Win10 Pro, specifically). For me, > also, the number turns maroon, but no warnings are emitted and the > design renders as expected. Note: the bug is only with the syntax highlighting. It is fixed with https://github.com/openscad/openscad/pull/4205 which was merged 5 days ago. There is currently no windows development snapshot with that fix. Note: the fix is only for the syntax highlighting. The lexer for running scad files is different from the lexer for syntax highlighting. The bug is just cosmetic. With Kind regards, Michael Frey

TP

Torsten Paul

Wed, Apr 13, 2022 7:22 PM

On 13.04.22 20:34, Michael Frey wrote:

There is currently no windows development snapshot with that fix.

Oh? Why, it should be included in all the snapshots except
the Arm64/Raspi build which is not automated.

ciao,
Torsten.

On 13.04.22 20:34, Michael Frey wrote: > There is currently no windows development snapshot with that fix. Oh? Why, it should be included in all the snapshots except the Arm64/Raspi build which is not automated. ciao, Torsten.

MF

Michael Frey

Thu, Apr 14, 2022 4:24 AM

On 13.04.22 21:22, Torsten Paul wrote:

On 13.04.22 20:34, Michael Frey wrote:

There is currently no windows development snapshot with that fix.

Oh? Why, it should be included in all the snapshots except
the Arm64/Raspi build which is not automated.

ciao,
Torsten.

My bad. I miss calculated the dates when looking at

http://openscad.org/downloads.html#snapshots

and misread the date code.

Also the path

http://files.openscad.org/snapshots/

with slightly newer builds is not trivial to find.

With Kind regards,

Michael

On 13.04.22 21:22, Torsten Paul wrote: > On 13.04.22 20:34, Michael Frey wrote: >> There is currently no windows development snapshot with that fix. > > Oh? Why, it should be included in all the snapshots except > the Arm64/Raspi build which is not automated. > > ciao, > Torsten. My bad. I miss calculated the dates when looking at http://openscad.org/downloads.html#snapshots and misread the date code. Also the path http://files.openscad.org/snapshots/ with slightly newer builds is not trivial to find. With Kind regards, Michael

TP

Torsten Paul

Thu, Apr 14, 2022 8:03 AM

On 14.04.22 06:24, Michael Frey wrote:

Also the path

http://files.openscad.org/snapshots/

with slightly newer builds is not trivial to find.

Yeah, it's all the way down on the huge download page.

But there shouldn't actually be newer builds. I have to
check why those don't show up on the download page. The
automatic update is supposed to fetch the new files from
the build server and make them available on the download
page. Looks like on 2022-04-12 only the first part
happened.

ciao,
Torsten.

On 14.04.22 06:24, Michael Frey wrote: > Also the path > > http://files.openscad.org/snapshots/ > > with slightly newer builds is not trivial to find. Yeah, it's all the way down on the huge download page. But there shouldn't actually be newer builds. I have to check why those don't show up on the download page. The automatic update is supposed to fetch the new files from the build server and make them available on the download page. Looks like on 2022-04-12 only the first part happened. ciao, Torsten.

discuss@lists.openscad.org

File Paths in use and include