<JordanBrown>
the 2>&1 part only works if you're using a UNIX-style shell. For a program run from Python there are other mechanisms for collecting up standard error.
<lauraaa>
how can i use it
<JordanBrown>
What's the immediately-surrounding stuff? What Python mechanism are you using to run it?
<lauraaa>
subprocess
<JordanBrown>
I'm not enough of a Python guy to tell you the answer off the top of my head, but I can read docs with the best of them... hold...
<Friithian>
wait are we using python to call openscad?
<JordanBrown>
yes
<Friithian>
excuse me while I go bleach and ammonia my eyes
<Friithian>
(at the same time)
<JordanBrown>
why?
<JordanBrown>
It's a sensible way to automate how you call it, e.g. to process a directory full of files, or to automate running with different arguments.
<JordanBrown>
My automation uses a shell script, but Python is sensible if it's what you like.
<Friithian>
I would say bash it sensible… python… less so
<JordanBrown>
better Python than Perl :-)
<Friithian>
I've never gone near perl so *shrug*
<JordanBrown>
As languages for writing quick hacks in go, Python is not a bad choice.
<JordanBrown>
I'm not a fan of using it for major applications, but I know people who are.
<JordanBrown>
lauraaa: do you get any output at all in the terminal window?
<JordanBrown>
You need each element in the array to be a separate space-separated word. (Except for the unlikely cases where you want to include a space in an argument.)
<JordanBrown>
So the '--render -o' needs to be '--render', '-o'
<InPhase>
linext: Interesting. Is it disk time that's making the ascii stl take longer?
<InPhase>
The processing should be faster for the binary version, but I didn't imagine that being enough of a lag to make a runtime difference.
<InPhase>
How big are these output files?
<JordanBrown>
What's the whole Python call, subprocess.run(...)?
<JordanBrown>
And what are you doing with the value that it returns?
<InPhase>
lauraaa: Also, 2>&1 is a bash thing, not a general Linux command thing.
<JordanBrown>
Ah, OK.
<JordanBrown>
Now get rid of the 2>&1 part
<JordanBrown>
InPhase: it's there in all Bourne shell derivatives, which is almost all of them.
<JordanBrown>
But it's a shell thing, so direct execution won't process it.
<InPhase>
You can actually set that in some of the Popen commands I think.
<InPhase>
But it's a separate parameter to Popen.
<JordanBrown>
yes, you can say shell=True and it will feed the command to the shell.
<JordanBrown>
Very bad for security, if that matters to you.
<JordanBrown>
lauraaa: what OS are you on?
<lauraaa>
windows
<lauraaa>
it worked without the 2>&1
<JordanBrown>
Python directly on Windows, not inside MSYS2 or Cygwin?
<InPhase>
*thumbsup*
<lauraaa>
its weird that i can run it with it on my terminal
<lauraaa>
but not on the python code
<JordanBrown>
no, not really weird at all
<JordanBrown>
the 2>&1 part is understood by the program that you are typing commands to.
<JordanBrown>
It is *not* understood by the underlying OS or by OpenSCAD itself.
<JordanBrown>
and the Python invocation that you are doing is, more or less, talking directly to the underlying OS.
<JordanBrown>
So when you take away that 2>&1 argument, what happens?
<lauraaa>
it works
<lauraaa>
but rn is stuck
<JordanBrown>
rn?
<lauraaa>
right now
<lauraaa>
after converting it the terminal is stuck
<JordanBrown>
What is the bigger picture? Why are you trying to run OpenSCAD from a Python program?
<lauraaa>
im trying to figure out why
<lauraaa>
ohhhh
<lauraaa>
braille translator
<JordanBrown>
ah
<lauraaa>
and the new featured i added is basically being able to 3d print it
<JordanBrown>
Your program is the braille translator?
<lauraaa>
i generate the model using openscad
<lauraaa>
yes sir
<lauraaa>
you heard of it before?
<JordanBrown>
No, but I can imagine it.
<JordanBrown>
So you are going to want to capture the output from OpenSCAD to convert into braille, so that your user can read error messages, output from echo(), et cetera.
<JordanBrown>
Something like so (run interactively):
<JordanBrown>
unhappy face accidental
<JordanBrown>
Running it interactively, something like so:
<JordanBrown>
>>> x = subprocess.run(["echo", "foo"], capture_output=True)
<InPhase>
flite text to speech will let you capture stdout and stderr and audio report them.
<InPhase>
I just tested this on mine.
<JordanBrown>
So the example I gave will return an object in x that has an element "stdout" that has all of the output from the program.
<JordanBrown>
What InPhase did is similar using a slightly different mechanism.
<InPhase>
The difference with Popen is it returns before it finishes.
<InPhase>
You basically setup a background pipe of these.
<InPhase>
That can be good or bad. :)
<InPhase>
There is also p.wait if you decide to wait.
<InPhase>
And p.terminate if you are angry at it.
<JordanBrown>
Yeah, I know enough Python to just write most simple stuff, but for things like subprocess I need to be reading the manual in detail. It helps that I *do* fully understand UNIX argument and process semantics.
<JordanBrown>
Eh, let me back off on the "most" part. Maybe "some simple stuff".
<InPhase>
It's Python. With google and core competence you can work your way out of a hole real fast. ;)
<JordanBrown>
Oh, yeah, I've done real work in Python. I just don't do it on a daily basis and so only a small amount sticks.
<JordanBrown>
Mostly for quick hacks I use the shell, and for much more than that I use C. Sometimes JavaScript, but support for command-line JavaScript is not ubiquitous.
<InPhase>
I got a ton of practice with it at my current job. The posting said C++ and Python required, and I figured this would be a good way to spend my days.
<InPhase>
I just had to brush up enough for the interview. :)
LordOfBikes has quit [Ping timeout: 268 seconds]
<JordanBrown>
Anyhow... lauraaa: have we got you going?
<InPhase>
Right, OpenSCAD problem.
<lauraaa>
hahaha
<lauraaa>
dont worry about me
<lauraaa>
im still here trying to fix other problems
LordOfBikes has joined #openscad
<lauraaa>
CGAL cache size in bytes: 10890988 on my output
<lauraaa>
what does that mean?
<JordanBrown>
mostly you don't care
<JordanBrown>
CGAL is the component that does final render processing.
<JordanBrown>
It (or OpenSCAD around it, don't know) caches the results of that rendering so that if you go to render the exact same object again it can skip all of the work.
<JordanBrown>
That's how much memory it's spending on that cache.
<JordanBrown>
Or something a lot like that.
<lauraaa>
ohh
<lauraaa>
i get it
<lauraaa>
im reading what you were talking about x = subprocess.run(["echo", "foo"], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
<lauraaa>
but im not getting anything
<JordanBrown>
so when you do that you are getting the results in the variable x.
<JordanBrown>
try print(x) to see what you got.
<JordanBrown>
and of course my example is running "echo", not OpenSCAD.
<JordanBrown>
So, to be clear: is the Python program the Braille translator, or is it running *inside* the Braille translator?
<JordanBrown>
When you were getting the error output, was it getting translated to Braille?
<lauraaa>
that's a good question
<lauraaa>
it is the program
<lauraaa>
the translator works differently
<JordanBrown>
so that suggests that the error output was *not* getting translated to Braille, right?
<lauraaa>
the error was just popping out when i try to convert from scad to stl
<lauraaa>
it translates properly
<lauraaa>
the only problem is the conversion
<JordanBrown>
So I think we have worked our way through getting your OpenSCAD run to operate correctly. Right? Next is to make sure that it's usable for your users, that any errors that are encountered will be translated to Braille so that the users can read the errors.
<lauraaa>
right now it works properly, it converts to stl and translates too
<lauraaa>
you got rid of 2>&1
<lauraaa>
but im guessing it didnt really affect the perfomance
<JordanBrown>
Now deliberately put an error into your OpenSCAD program and make sure that the error message gets translated to Braille.
<lauraaa>
now im lost, how come
<JordanBrown>
OK, who is writing the OpenSCAD programs? Is it your blind user, or somebody else?
J1A8428 has joined #openscad
J1A84 has quit [Ping timeout: 252 seconds]
<lauraaa>
no one, is automated
<lauraaa>
you just insert what you want to translate and python do the rest
<lauraaa>
which is converting everything to .scad
<JordanBrown>
OK, sorry, I assumed that you were allowing blind users to write OpenSCAD programs.
<JordanBrown>
For that, you would need to ensure that any error messages were translated to Braille.
<JordanBrown>
But if the users are not writing the OpenSCAD programs, you don't need that.
<lauraaa>
yepyep
<lauraaa>
i just needed to optimize the time to convert it
<JordanBrown>
InPhase: I did a quick test, unioning a cube(10) with a sphere(10), and processing with openscad -o /tmp/a.stl --export-format=stl /tmp/a.scad.
<JordanBrown>
Generating ASCII STL is consistently about 1.3 seconds. Generating binary STL is consistently around 0.8 to 0.9 seconds.
<JordanBrown>
Even more dramatic: sphere(10, $fn=100) is about 5.6 seconds for ASCII STL, and 0.3 seconds for binary STL.
<lauraaa>
i think it takes that much also because i use a lot of spheres
<JordanBrown>
That doesn't make the least bit of sense. I wrote a Python program to emit something that looks like fake STL, converting numbers into ASCII, et cetera, and it emitted the same size file (close enough) in 0.4 seconds.
<JordanBrown>
It sure sounds like there is something badly wrong with ASCII STL export.
<JordanBrown>
I need to make some dinner; I'll look at it afterward. I wonder whether it's doing something stupid like unbuffered output.
<JordanBrown>
Yes, but I wrote a Python program that did the same number of conversions, and it took 1/10 as much time.
<Friithian>
exact same number conversions?
<JordanBrown>
Give or take.
<JordanBrown>
Real output:
<JordanBrown>
facet normal 0 0 1
<JordanBrown>
outer loop
<JordanBrown>
vertex 0.313488 0.019723 9.99507
<JordanBrown>
vertex 0.314108 0 9.99507
<JordanBrown>
vertex 0.313488 -0.019723 9.99507
<JordanBrown>
endloop
<JordanBrown>
endfacet
<JordanBrown>
fake output:
<Friithian>
it cannot be given and take, are you convering actual binary stl to ascii stl or just fakin git
<JordanBrown>
facet normal 1 1 1
<JordanBrown>
outer loop
<JordanBrown>
vertex 1.234567 1.234567 1.234567
<JordanBrown>
vertex 1.234567 1.234567 1.234567
<JordanBrown>
vertex 1.234567 1.234567 1.234567
<JordanBrown>
endloop
<JordanBrown>
endfacet
<Friithian>
and have you tried it for large files
<Friithian>
also use an online paste service
<JordanBrown>
$ wc -l /tmp/a.stl /tmp/a.fake
<JordanBrown>
70000 /tmp/a.fake
<JordanBrown>
69974 /tmp/a.stl
<JordanBrown>
139974 total
<JordanBrown>
yes, pastebin is better for a lot of things, but for a few lines that you're just going to read, not copy and paste...
<JordanBrown>
Oh, sorry, you meant "the exact same kind of conversions". I read "the exact same number *of* conversions".
<Friithian>
it's good etiquette to not paste >3 lines
<JordanBrown>
They're both in the vicinity of 90,000 floating point conversions plus, if they are different, 30,000 integer conversions.
<JordanBrown>
Assuming that Python isn't caching the results of floating point conversions, which would be a pretty weird thing for it to do.
lauraaa has quit [Quit: Client closed]
<JordanBrown>
I wrote a Python program to read an ASCII STL file into memory, parsing everything, then write it back out again in ASCII STL. For that sphere, it ran in 0.9 seconds. Again, that's versus 5.6 seconds for OpenSCAD.
<JordanBrown>
Now, that's including the OpenSCAD and Python startup times, which really shouldn't be included, but since OpenSCAD was able to emit binary STL in a total of 0.3 seconds, the startup times don't seem to be big contributors.
TheAssassin has quit [Remote host closed the connection]
fling has quit [Read error: Connection reset by peer]
GNUmoon2 has quit [Read error: Connection reset by peer]
TheAssassin has joined #openscad
GNUmoon2 has joined #openscad
<JordanBrown>
Here's my Python program, if you want to confirm that it does roughly the right number of conversions: https://pastebin.com/munrVdtQ
fling has joined #openscad
<JordanBrown>
Friithian
<JordanBrown>
ASCII STL export does convert the coordinates into strings, then back into numbers, but that doesn't explain it.
<JordanBrown>
(because that's approximately the same number of conversions as my Python program, and my Python program is still way faster than OpenSCAD.)
<JordanBrown>
OK, the actual I/O is nothing. I commented out all of the I/O, so that all it emitted was the "solid" and "endsolid" lines, and it ran in 6+ seconds.
<JordanBrown>
That is, I made that change to OpenSCAD.
<JordanBrown>
All of the time is in the three lines that look like
<JordanBrown>
Commenting those out (in addition to commenting out the output stuff that I already commented out) dropped the time to about 0.8 seconds.
<JordanBrown>
But it sounds like that's a very high overhead way to do it.
<Friithian>
… yes that's how reencoding data works
<JordanBrown>
But my Python program does the same thing, roughly, 10x faster.
<JordanBrown>
So all indications are that the istringstream, >>, and Vector3d take a very long time to convert 3 numbers in ASCII into doubles.
<JordanBrown>
Sure looks like binary mode produces a corrupt file if it has a triangle with all three points the same, because it does not emit a normal but *does* emit the three points. ASCII mode doesn't emit anything for such a triangle.
<JordanBrown>
I rewrote the ASCII processing so that it doesn't do the conversions to and from ASCII, so that it does the more obvious thing of just calculating the normal from the supplied values, and only converting to ASCII for output.
<JordanBrown>
The result is fast, ~0.6 seconds.
<JordanBrown>
The result is slightly different from the original; the coordinates for the normals differ in about the fourth significant figure.
<JordanBrown>
This is presumably because the round trip through ASCII is an information-losing process.
<JordanBrown>
Whether losing that information is critical I don't know. Somebody thought it was.
<JordanBrown>
Differing in the 4th significant figure seems to be the worst case; more typical is differing in the fifth or later.
<JordanBrown>
Just for fun, I tried changing it to do everything as doubles, instead of truncating to floats, and the results were very similar.
<JordanBrown>
Boy, I really got a different impression of what the project was trying to accomplish. I thought it was "provide a way for blind users to print an OpenSCAD model", but it's really "take ASCII input, produce Braille plastic".
<J1A8428>
yes
<JordanBrown>
Ah, well, the Python advice was still relevant.
<JordanBrown>
And researching the ASCII STL performance issues was interesting.
<InPhase>
JordanBrown: Well, that sounds ridiculous. I wrote the binary stl output, but left the ascii stl output untouched so as not to alter the existing part.
<InPhase>
But I didn't notice it was that underperformant.
<InPhase>
I guess now the binary version is well enough tested that it's safe to mess with the ascii part again.
<InPhase>
Not that I'm setting out to do that... I'm setting out to get some sleep.
<JordanBrown>
Yes, that's my plan too.
<JordanBrown>
What TZ are you in? I'm Pacific (Los Angeles).
<InPhase>
East coast.
<InPhase>
So a bit later. :)
<JordanBrown>
Yes, you should get sleep.
<J1A8428>
if i get up and InPhase is still there .. he needs sleep Ü
<JordanBrown>
Where are you?
<J1A8428>
UTC+1
<J1A8428>
(+2 summertime)
<JordanBrown>
Anyhow, as we were discussing, time for bed.
<J1A8428>
teepee regarding #4318 i have this with almost every design that Cura ( mesh tools) say my 3mf is not watertight - i assume that is a problem with mesh tools
<J1A8428>
however if i open those 3mf with other prog - no error is detected .. but if i save these with other software - Curas mesh tool is not reporting an error anymore
<teepee>
hmm, I have not seen that lately (using 5.0 beta)
<J1A8428>
do you have "mesh tools" enabled in cura ?
<teepee>
I think I installed that
<J1A8428>
well i assume it is some kind of detection error, not an real error within the geometry - so maybe they fixed it
<teepee>
yes, mesh tools 3.7.0
<J1A8428>
analyse of the two models show that some vertices got removed .. so these are probably redundant in the openSCAD export
<J1A8428>
Both still have the same number of faces
<J1A8428>
(there is also a checkbox in mesh tools for checking models when loaded Ü )
<teepee>
ah, they solved the appimage issue by providing 2 version, interesting
<J1A8428>
( mesh tools 3.7.0 also here)
<J1A8428>
3MF reader 1.0.1
<teepee>
check on load is enabled
<teepee>
and with 2nd hack, I can start the appimage :)
fling has quit [Remote host closed the connection]
fling has joined #openscad
TheAssassin has quit [Remote host closed the connection]
fling has quit [Write error: Connection reset by peer]
califax has quit [Write error: Broken pipe]
TheAssassin has joined #openscad
califax has joined #openscad
fling has joined #openscad
<J1A8428>
appimage for cura on linux?
<teepee>
yes
peepsalot has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
<J1A8428>
if you like try https://bpa.st/ZNQA export 3mf and import in cura .. really wonder if you didn't get the error as it is the same version of mesh tools
<JordanBrown>
Don't know beans about turning Python programs into .EXEs, sorry. I would probably just wrap it in a .BAT, or ensure that .PY is rigged to run Python. Details would depend on whether you want to click on a shortcut or type a command into a command prompt.
<JordanBrown>
Or, for that matter, wrap it in a shortcut.