AMF import on Windows doesn't work.

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

AMF import on Windows doesn't work.

nophead
All the test that import AMF fail for me on Windows.

Is this supposed to be working or is there an open issue for it?

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

kintel
Administrator
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

kintel
Administrator
It's entirely possible that we're ignoring a build error for the snapshot as well; we don't have an automated test pipeline set up for Windows as we do on the other platforms.
 
I'd wager that virtually nobody uses AMF at all - that standard doesn't seem to be going anywhere : /

 -Marius

On Thu, Aug 30, 2018 at 10:22 AM, nop head <[hidden email]> wrote:
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

doug.moen
Cura removed AMF support in 2016, at the same time that they added 3MF support.
Various reasons were given for removing AMF support:
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the standard, no sharing)


On 30 August 2018 at 10:31, Marius Kintel <[hidden email]> wrote:
It's entirely possible that we're ignoring a build error for the snapshot as well; we don't have an automated test pipeline set up for Windows as we do on the other platforms.
 
I'd wager that virtually nobody uses AMF at all - that standard doesn't seem to be going anywhere : /

 -Marius

On Thu, Aug 30, 2018 at 10:22 AM, nop head <[hidden email]> wrote:
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
The test suit seems to use it as a means to an end, rather than just testing AMF.

$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe --info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe "C:/msys64/home/ChrisP/openscad/tests/test_pretty_print.py" --builddir=C:/msys64/home/ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
      Start 132: dumptest_cube-tests
 1/14 Test #132: dumptest_cube-tests .................   Passed    0.29 sec
      Start 209: dumptest-examples_text_on_cube
 2/14 Test #209: dumptest-examples_text_on_cube ......   Passed    0.28 sec
      Start 303: cgalpngtest_cube-tests
 3/14 Test #303: cgalpngtest_cube-tests ..............   Passed    1.00 sec
      Start 339: cgalpngtest_cube-with-hole
 4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed    0.65 sec
      Start 466: opencsgtest_cube-tests
 5/14 Test #466: opencsgtest_cube-tests ..............   Passed    0.64 sec
      Start 516: opencsgtest_cube-with-hole
 6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed    0.70 sec
      Start 643: csgpngtest_cube-tests
 7/14 Test #643: csgpngtest_cube-tests ...............   Passed    1.04 sec
      Start 680: csgpngtest_cube-with-hole
 8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed    0.94 sec
      Start 807: throwntogethertest_cube-tests
 9/14 Test #807: throwntogethertest_cube-tests .......   Passed    0.69 sec
      Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed    0.64 sec
      Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 ..............   Passed    0.65 sec
      Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ...................   Passed    0.96 sec
      Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ...................   Passed    0.93 sec
      Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed    0.94 sec

64% tests passed, 5 tests failed out of 14

Total Test time (real) =  10.56 sec

The following tests FAILED:
 339 - cgalpngtest_cube-with-hole (Failed)
 516 - opencsgtest_cube-with-hole (Failed)
 680 - csgpngtest_cube-with-hole (Failed)
 855 - throwntogethertest_cube-with-hole (Failed)
 921 - amfpngtest_cube10 (Failed)
report saved:


On 30 August 2018 at 16:17, doug moen <[hidden email]> wrote:
Cura removed AMF support in 2016, at the same time that they added 3MF support.
Various reasons were given for removing AMF support:
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the standard, no sharing)


On 30 August 2018 at 10:31, Marius Kintel <[hidden email]> wrote:
It's entirely possible that we're ignoring a build error for the snapshot as well; we don't have an automated test pipeline set up for Windows as we do on the other platforms.
 
I'd wager that virtually nobody uses AMF at all - that standard doesn't seem to be going anywhere : /

 -Marius

On Thu, Aug 30, 2018 at 10:22 AM, nop head <[hidden email]> wrote:
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
Without libzip the AMF importer falls back to only being able to read non zipped AMF files.
cube-with-hole.amf is XML, so it should be able to read it without libzip. More investigation required.

On 30 August 2018 at 17:31, nop head <[hidden email]> wrote:
The test suit seems to use it as a means to an end, rather than just testing AMF.

$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe --info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe "C:/msys64/home/ChrisP/openscad/tests/test_pretty_print.py" --builddir=C:/msys64/home/ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
      Start 132: dumptest_cube-tests
 1/14 Test #132: dumptest_cube-tests .................   Passed    0.29 sec
      Start 209: dumptest-examples_text_on_cube
 2/14 Test #209: dumptest-examples_text_on_cube ......   Passed    0.28 sec
      Start 303: cgalpngtest_cube-tests
 3/14 Test #303: cgalpngtest_cube-tests ..............   Passed    1.00 sec
      Start 339: cgalpngtest_cube-with-hole
 4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed    0.65 sec
      Start 466: opencsgtest_cube-tests
 5/14 Test #466: opencsgtest_cube-tests ..............   Passed    0.64 sec
      Start 516: opencsgtest_cube-with-hole
 6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed    0.70 sec
      Start 643: csgpngtest_cube-tests
 7/14 Test #643: csgpngtest_cube-tests ...............   Passed    1.04 sec
      Start 680: csgpngtest_cube-with-hole
 8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed    0.94 sec
      Start 807: throwntogethertest_cube-tests
 9/14 Test #807: throwntogethertest_cube-tests .......   Passed    0.69 sec
      Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed    0.64 sec
      Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 ..............   Passed    0.65 sec
      Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ...................   Passed    0.96 sec
      Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ...................   Passed    0.93 sec
      Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed    0.94 sec

64% tests passed, 5 tests failed out of 14

Total Test time (real) =  10.56 sec

The following tests FAILED:
 339 - cgalpngtest_cube-with-hole (Failed)
 516 - opencsgtest_cube-with-hole (Failed)
 680 - csgpngtest_cube-with-hole (Failed)
 855 - throwntogethertest_cube-with-hole (Failed)
 921 - amfpngtest_cube10 (Failed)
report saved:


On 30 August 2018 at 16:17, doug moen <[hidden email]> wrote:
Cura removed AMF support in 2016, at the same time that they added 3MF support.
Various reasons were given for removing AMF support:
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the standard, no sharing)


On 30 August 2018 at 10:31, Marius Kintel <[hidden email]> wrote:
It's entirely possible that we're ignoring a build error for the snapshot as well; we don't have an automated test pipeline set up for Windows as we do on the other platforms.
 
I'd wager that virtually nobody uses AMF at all - that standard doesn't seem to be going anywhere : /

 -Marius

On Thu, Aug 30, 2018 at 10:22 AM, nop head <[hidden email]> wrote:
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
The reason it does not work on Windows is the AMF parser uses fs::path to represent element hierarchies in the XML file, for example /amf/object/mesh/volume/triangle.  On Windows fs:path uses \ instead of / so the paths don't match those in the maps of functions. So no functions are called and and empty polyset is returned.

On 30 August 2018 at 17:50, nop head <[hidden email]> wrote:
Without libzip the AMF importer falls back to only being able to read non zipped AMF files.
cube-with-hole.amf is XML, so it should be able to read it without libzip. More investigation required.

On 30 August 2018 at 17:31, nop head <[hidden email]> wrote:
The test suit seems to use it as a means to an end, rather than just testing AMF.

$ ctest -R cube
running 'C:/msys64/home/ChrisP/openscad/tests/../Release/openscad.exe --info' to generate sysinfo.txt
Post test:C:/msys64/mingw64/bin/python.exe "C:/msys64/home/ChrisP/openscad/tests/test_pretty_print.py" --builddir=C:/msys64/home/ChrisP/openscad/tests
Test project C:/msys64/home/ChrisP/openscad/tests
Enforcing Default test configuration. Use ctest -C <config> to override
      Start 132: dumptest_cube-tests
 1/14 Test #132: dumptest_cube-tests .................   Passed    0.29 sec
      Start 209: dumptest-examples_text_on_cube
 2/14 Test #209: dumptest-examples_text_on_cube ......   Passed    0.28 sec
      Start 303: cgalpngtest_cube-tests
 3/14 Test #303: cgalpngtest_cube-tests ..............   Passed    1.00 sec
      Start 339: cgalpngtest_cube-with-hole
 4/14 Test #339: cgalpngtest_cube-with-hole ..........***Failed    0.65 sec
      Start 466: opencsgtest_cube-tests
 5/14 Test #466: opencsgtest_cube-tests ..............   Passed    0.64 sec
      Start 516: opencsgtest_cube-with-hole
 6/14 Test #516: opencsgtest_cube-with-hole ..........***Failed    0.70 sec
      Start 643: csgpngtest_cube-tests
 7/14 Test #643: csgpngtest_cube-tests ...............   Passed    1.04 sec
      Start 680: csgpngtest_cube-with-hole
 8/14 Test #680: csgpngtest_cube-with-hole ...........***Failed    0.94 sec
      Start 807: throwntogethertest_cube-tests
 9/14 Test #807: throwntogethertest_cube-tests .......   Passed    0.69 sec
      Start 855: throwntogethertest_cube-with-hole
10/14 Test #855: throwntogethertest_cube-with-hole ...***Failed    0.64 sec
      Start 918: monotonepngtest_cube10
11/14 Test #918: monotonepngtest_cube10 ..............   Passed    0.65 sec
      Start 919: stlpngtest_cube10
12/14 Test #919: stlpngtest_cube10 ...................   Passed    0.96 sec
      Start 920: offpngtest_cube10
13/14 Test #920: offpngtest_cube10 ...................   Passed    0.93 sec
      Start 921: amfpngtest_cube10
14/14 Test #921: amfpngtest_cube10 ...................***Failed    0.94 sec

64% tests passed, 5 tests failed out of 14

Total Test time (real) =  10.56 sec

The following tests FAILED:
 339 - cgalpngtest_cube-with-hole (Failed)
 516 - opencsgtest_cube-with-hole (Failed)
 680 - csgpngtest_cube-with-hole (Failed)
 855 - throwntogethertest_cube-with-hole (Failed)
 921 - amfpngtest_cube10 (Failed)
report saved:


On 30 August 2018 at 16:17, doug moen <[hidden email]> wrote:
Cura removed AMF support in 2016, at the same time that they added 3MF support.
Various reasons were given for removing AMF support:
* nobody uses it
* the standard contradicts itself
* it is not an open standard (ie, devs need to pay money for a copy of the standard, no sharing)


On 30 August 2018 at 10:31, Marius Kintel <[hidden email]> wrote:
It's entirely possible that we're ignoring a build error for the snapshot as well; we don't have an automated test pipeline set up for Windows as we do on the other platforms.
 
I'd wager that virtually nobody uses AMF at all - that standard doesn't seem to be going anywhere : /

 -Marius

On Thu, Aug 30, 2018 at 10:22 AM, nop head <[hidden email]> wrote:
It does nothing silently. Under MSYS2 I think it is a build problem because qmake cant find libzip but I tested it with the Windows snapshot and that doesn't work either.
I will look into it.

So does nobody use AMF and Windows?

Package libzip was not found in the pkg-config search path.
Perhaps you should add the directory containing `libzip.pc'
to the PKG_CONFIG_PATH environment variable



On 30 August 2018 at 14:21, Marius Kintel <[hidden email]> wrote:
On Aug 30, 2018, at 8:42 AM, nop head <[hidden email]> wrote:
>
> All the test that import AMF fail for me on Windows.
>
> Is this supposed to be working or is there an open issue for it?

To my knowledge it’s supposed to work, but it’s not a very widely used feature, so I’m not sure where/when this last worked.
If you have any more context about how it fails, that may be revealing.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org





_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

tp3
On 08/31/2018 01:34 AM, nop head wrote:
> On Windows fs:path uses \ instead of / so the paths don't match those
> in the maps of functions. So no functions are called and and empty
> polyset is returned.
>
Oh, so instead of path.string() it should be path.generic_string()?

ciao,
   Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
Yes I will change it to a string as it isn't a file system path, so using fs::path also makes the code a bit confusing.

On 31 August 2018 at 01:12, Torsten Paul <[hidden email]> wrote:
On 08/31/2018 01:34 AM, nop head wrote:
On Windows fs:path uses \ instead of / so the paths don't match those
in the maps of functions. So no functions are called and and empty
polyset is returned.

Oh, so instead of path.string() it should be path.generic_string()?

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
Using a std::string works and now all the non-zipped AMF tests pass.

How does libzip get incorporated on Linux and why is it missing on Windows? Obviously I can download it manually but where should I put it and why isn't it done automatically?

On 31 August 2018 at 07:37, nop head <[hidden email]> wrote:
Yes I will change it to a string as it isn't a file system path, so using fs::path also makes the code a bit confusing.

On 31 August 2018 at 01:12, Torsten Paul <[hidden email]> wrote:
On 08/31/2018 01:34 AM, nop head wrote:
On Windows fs:path uses \ instead of / so the paths don't match those
in the maps of functions. So no functions are called and and empty
polyset is returned.

Oh, so instead of path.string() it should be path.generic_string()?

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

tp3
On 08/31/2018 10:52 AM, nop head wrote:
> How does libzip get incorporated on Linux and why is it missing on
> Windows? Obviously I can download it manually but where should I put
> it  and why isn't it done automatically?
>
It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.

ciao,
   Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use bzip2 instead of libzip or are both required?

pkg-config seems to expect the package to be already there rather than being responsible for downloading it. Is it already there on Linux?

The magic incantation on MSYS2 seems to be pacman -S mingw-w64-x86_64-libzip. That gets to this problem: https://github.com/openscad/openscad/issues/1919




On 31 August 2018 at 11:06, Torsten Paul <[hidden email]> wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it  and why isn't it done automatically?

It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.


ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
This seems to be another incorrect use of boost::filesystem::path for the filename. The filename is internal to the ZIP file, so presumably its format should be independent of the OS. It looks like filesystem::path is only used to separate the filename from the rest of the path but it has the unintended consequence of converting it to wide characters on Windows.

There is the wider problem of what happens if the path is utf8, but that depends on libxml2 and libzip in this case but is generally broken on Windows in other places anyway.

I am minded to use a std:string again and manually isolate the filename to locate the file in the archive.

On 31 August 2018 at 11:36, nop head <[hidden email]> wrote:
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use bzip2 instead of libzip or are both required?

pkg-config seems to expect the package to be already there rather than being responsible for downloading it. Is it already there on Linux?

The magic incantation on MSYS2 seems to be pacman -S mingw-w64-x86_64-libzip. That gets to this problem: https://github.com/openscad/openscad/issues/1919




On 31 August 2018 at 11:06, Torsten Paul <[hidden email]> wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it  and why isn't it done automatically?

It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.


ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

nophead
Did it the old fashioned way with char*s. All the AMF tests now pass on Windows with my two PRs https://github.com/openscad/openscad/pull/2467 and https://github.com/openscad/openscad/pull/2471.

Only four of the default tests fail on Windows now. Three are differences in Z fighting so I think that is just a difference in graphics cards, not actual errors.

The only real error is the test for non-ascii characters.

99% tests passed, 4 tests failed out of 1126

Total Test time (real) = 946.92 sec

The following tests FAILED:
 533 - opencsgtest_issue1165 (Failed)
 536 - opencsgtest_issue1215 (Failed)
 875 - throwntogethertest_issue1215 (Failed)
 1105 - openscad-nonascii_sfære (Failed)




On 31 August 2018 at 12:11, nop head <[hidden email]> wrote:
This seems to be another incorrect use of boost::filesystem::path for the filename. The filename is internal to the ZIP file, so presumably its format should be independent of the OS. It looks like filesystem::path is only used to separate the filename from the rest of the path but it has the unintended consequence of converting it to wide characters on Windows.

There is the wider problem of what happens if the path is utf8, but that depends on libxml2 and libzip in this case but is generally broken on Windows in other places anyway.

I am minded to use a std:string again and manually isolate the filename to locate the file in the archive.

On 31 August 2018 at 11:36, nop head <[hidden email]> wrote:
Yes I saw that but it is about bzip2 rather than libzip. Does MXE use bzip2 instead of libzip or are both required?

pkg-config seems to expect the package to be already there rather than being responsible for downloading it. Is it already there on Linux?

The magic incantation on MSYS2 seems to be pacman -S mingw-w64-x86_64-libzip. That gets to this problem: https://github.com/openscad/openscad/issues/1919




On 31 August 2018 at 11:06, Torsten Paul <[hidden email]> wrote:
On 08/31/2018 10:52 AM, nop head wrote:
How does libzip get incorporated on Linux and why is it missing on
Windows? Obviously I can download it manually but where should I put
it  and why isn't it done automatically?

It's supposed to be included via pkg-config, there was some discussion
in https://github.com/openscad/openscad/issues/2441 too. There were
quite some changes to the MXE build, thanks to Tony from the MXE team
who helped to bring the build to gcc7 (mxe-gcc7 branch).
I guess the answer to why it's broken is that multi-platform builds
are hard but the problem is only seen by people actually giving it
a try ;-). I would have expected libzip to work without too much
issues on MSYS2 though as it's much closer to Linux builds as MXE is.


ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: AMF import on Windows doesn't work.

tp3
In reply to this post by nophead
On 08/31/2018 12:36 PM, nop head wrote:
> Yes I saw that but it is about bzip2 rather than libzip.
> Does MXE use bzip2 instead of libzip or are both required?
>
No, the OP was about bzip2, but somewhere in the discussion
Tony mentioned that PKGCONFIG+=libzip did make it work.

> pkg-config seems to expect the package to be already there
> rather than being responsible for downloading it. Is it
> already there on Linux?
>
The (dev-)package needs to be installed, pkg-config will just
use the *.pc files that were installed along with the packages
to provide the various options.

 > There is the wider problem of what happens if the path is
 > utf8, but that depends on libxml2 and libzip in this case
 > but is generally broken on Windows in other places anyway.
 >
Thanks for diving into that issue, this helps a lot as most
of the time we seem to have no developer with Windows env
so this type of problems are detected quite late.

 > Only four of the default tests fail on Windows now. Three
 > are differences in Z fighting so I think that is just a
 > difference in graphics cards, not actual errors.
 >
 > The only real error is the test for non-ascii characters.
 >
 > 99% tests passed, 4 tests failed out of 1126
 >
Yes, those Z-fighting issues are disabled on Travis too.
I'm not sure why they are in the normal test list.

ciao,
   Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten