00:18 <InPhase> JordanBrown: 999 is unexpected. I hadn't tried echoing the result.

00:20 <InPhase> JordanBrown: Looks like there's a warning if layer= is in the function assign form.

00:30 <InPhase> JordanBrown: I also don't spot anywhere in the code that the 999 should be coming from.

01:44 <JordanBrown> It's presumably coming from the JSON parser.

01:46 <JordanBrown> The OpenSCAD part of the import() function is quite simple; it's at https://github.com/openscad/openscad/blob/ef88e36a8e68b54a0080501126fa685a3517eeb7/src/core/builtin_functions.cc#L1051

01:46 <JordanBrown> Well, OK, import_json() is OpenSCAD stuff too I guess.

01:46 <JordanBrown> But the argument parsing is simple.

01:46 <JordanBrown> Do remember that functions and modules are very different things.

01:49 <JordanBrown> There's a 999 at the top of the DXF file. That might be a complete-and-correct JSON value, with the rest of the file ignored.

01:51 <JordanBrown> Yep. That 999 is a complete and correct JSON value.

01:51 <JordanBrown> https://www.json.org/json-en.html

01:51 <JordanBrown> json -> element -> ws value ws -> number

01:58 <InPhase> JordanBrown: lol, oh. That's why I couldn't find it in the source.

01:58 <InPhase> I had actually opened that file in a text editor and hex editor, but I didn't remember the 999.

02:04 <JordanBrown> Very first line.

02:04 <JordanBrown> 999 appears to be the code for "next line is a comment".

02:05 <JordanBrown> https://images.autodesk.com/adsk/files/autocad_2012_pdf_dxf-reference_enu.pdf

02:05 <JordanBrown> The 999 code is defined on page 4

02:05 <JordanBrown> and again on page 9

02:10 <JordanBrown> Filed an issue.

02:11 <gbruno> [github] jordanbrown0 opened issue #6030 (import(json_file) might want to be a bit pickier) https://github.com/openscad/openscad/issues/6030

02:23 <InPhase> JordanBrown: Based on the insight that 999 means "next line is a comment" I wrote a bash script line that I think will extract all the layer names. grep -A1 -E '^ 8$' "$FILE" | grep -Ev '^ 8$|^--$' | sort | uniq

02:24 <InPhase> That should save me from needing to open inkscape in the future. :)

02:28 <JordanBrown> Maybe we will some time implement import(dxf) as a function that can then return some or all of the data from the DXF.

02:29 <InPhase> A first run could return an object with .layers being a list of the layer names.

02:30 <JordanBrown> Perhaps, though since you later might want to return the *contents* of those layers, it might be better if layers[] is a vector of objects, with "name" being the name of that layer.

02:31 <JordanBrown> so that o.layers[i].somethingelse could be some other parameter of that layer.

02:31 <InPhase> Perhaps .layer_names then.

02:32 <JordanBrown> You're offending my sense of schema :-)

02:32 <InPhase> :)

02:32 <JordanBrown> I think that o.layers[i].name would be a perfectly usable start.

02:33 <JordanBrown> Though I'd want to analyze the format to find whether there should be anything above "layers".

02:33 <JordanBrown> (Like, maybe, if it had some kind of higher-level grouping.)

02:34 <JordanBrown> It is tempting to implement import("foo.txt") but we are treading perilously close to letting OpenSCAD have too much access to your system.

07:18 <gbruno> [github] bitbasher opened issue #6031 (import dxf fails as function with import-function enabled, while calling import() as a module works) https://github.com/openscad/openscad/issues/6031

07:46 <gbruno> [github] kintel closed issue #6031 (import dxf fails as function with import-function enabled, while calling import() as a module works) https://github.com/openscad/openscad/issues/6031

08:05 <bitbasher> this is my comment and question on Jordan's bug about import() function

08:05 <bitbasher> folks .. if there is a function called import() that only works on JSON files, and an import() module that uses the file's extension to know how to read the file shouldn't they have different names? either : define a function info = import_json( "filename.json" ) and rejects all other file types use existing module import( "filename.any" ) or: .. well, to me nothing else makes sense. i cannot even find the code for the function import

08:09 <bitbasher> ah .. i may have just found the import json code in io folder .. but i dont see how it is called by info = import() yet

08:20 <guso78k> there is an import_stl function, but it has been deprecated for a long time because openscad want to get rid of it in favor of import()

08:26 <guso78k> i think its in https://github.com/openscad/openscad/blob/master/src/core/builtin_functions.cc#L1057

08:28 <guso78k> but the two namespaces of openscad (functions and modules) are really confusing.  Depending on the  implicit context literal names  have completly different functions

08:29 <guso78k> and if()  returns a module/node ....

08:33 <bitbasher> yeah .. this is spaghetti code elevated to a meta level

08:35 <bitbasher> what sort of data can be imported from a json file .. like, an array of points for a polygon or polyhedron?

08:39 <guso78k> i think , anyhing which can be interpreted into strings, numbers, lists and dictionaries. therefor also coordinates and polygons ,....

08:39 <guso78k> its just about how you interprete it

16:06 <JordanBrown> Yes, that's all pretty much correct. Unlike many other languages (but like some), OpenSCAD has separate namespaces for variables, functions, and modules (which some might call subroutines).

16:06 <JordanBrown> And yes, that can be confusing for people who are used to unified-namespace languages.

16:06 <JordanBrown> import-the-module and import-the-function are two different components, with different capabilities.

16:08 <JordanBrown> And yes, the JSON that you import can be whatever you want it to be. That capability provides a way to have a workflow where one component generates some data, and an OpenSCAD program processes it into a 3D model.

16:16 <JordanBrown> There has never been an import_stl() *function*. There was an import_stl() *module*, that was deprecated and eventually removed in favor of the multi-format import() module.

19:07 <gbruno> [github] jordanbrown0 opened issue #6032 (Specifying a named argument not expected by the function/module should get a better message) https://github.com/openscad/openscad/issues/6032

20:36 <teepee> bitbasher: why not just ask and discuss here?

21:38 <bitbasher> for the most part i like to chat .. but when i am reporting info that may help diagnose or even solve a documented issue i update in the issue

21:42 <bitbasher> but my testing just now shows that evn with $fn cranked way up that an .obj exported from scad is not acceptable to Slicer .. unless it is first exported as an STL and then run through the STL Repair function in Slicer .. i dont know everything the repair does, but eyeballing the contents shows triangles and not quads

21:46 <teepee> posting on unrelated issues will potentially ping those people via email with unrelated discussions

21:46 <teepee> but I guess I'll just mind my own stuff for a bit...

22:17 <guso78k> Did OpenSCAD ever consider implementing this low hanging fruit: https://www.reddit.com/r/OpenPythonSCAD/comments/1m3e2hz/colorful_geodesic_sphere_in_pythonscad/

22:17 <guso78k> polyhedron with a color parameter

22:25 <bitbasher> i can sympathise teepee .. i am naturally opinionated and pedantic, but many come to love me despite these flaws .. i derive joy from being helpful and comforted by a tool doing what its docs say it should be doing.

22:27 <teepee> that part is great, but please don't invent features based on assumptions

22:27 <bitbasher> If anyone feel i am stepping on toes i apologize .. i do try to moderate my enthusiasm .. i appreaciate and welcome feedback when i go overboard with it all

22:29 <bitbasher> yeah .. that is hard to avoid when ignorant LOL that is why i try to test everything u can before wading in .. I know i get things wrong in places

22:30 <bitbasher> and why am happy to receive education and feedback .. really truly

22:30 <bitbasher> but now i need to get off to bed.. night all