fling has quit [Remote host closed the connection]
fling has joined #openscad
ccox_ has joined #openscad
ccox has quit [Read error: Connection reset by peer]
abff has quit [Ping timeout: 265 seconds]
abff has joined #openscad
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Colere has quit [Ping timeout: 264 seconds]
Colere has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
<JordanBrown[m]>
teepee We have something like 31 states with towns named Springfield. Wisconsin appears to have five of them. Pasadena, Texas was named after the much-better-known Pasadena, California, but now has a larger population.
<JordanBrown[m]>
We seem to have 4±1 copies of St Petersburg, depending on whether you count the one in Alaska that doesn't officially have the "Saint" part in its name and the one in Missouri that's fictional.
snaked has quit [Read error: Connection reset by peer]
snaked has joined #openscad
ur5us has quit [Ping timeout: 244 seconds]
snaked has quit [Read error: Connection reset by peer]
snaked has joined #openscad
snakedGT has joined #openscad
snaked has quit [Ping timeout: 244 seconds]
snakedLX has joined #openscad
snakedGT has quit [Ping timeout: 244 seconds]
arebil_ has joined #openscad
arebil_ has quit [Changing host]
arebil_ has joined #openscad
smudge-the-cat has joined #openscad
smudge-the-cat has left #openscad [#openscad]
epony has quit [Remote host closed the connection]
ur5us has joined #openscad
snakedLX has quit [Read error: Connection reset by peer]
snakedLX has joined #openscad
epony has joined #openscad
ur5us has quit [Ping timeout: 244 seconds]
snakedLX has quit [Read error: Connection reset by peer]
snakedLX has joined #openscad
ndnihil is now known as nihil
nihil is now known as ndnihil
othx has quit [Ping timeout: 265 seconds]
othx has joined #openscad
smudge-the-cat has joined #openscad
smudge-the-cat has left #openscad [#openscad]
snakedLX has quit [Read error: Connection reset by peer]
snakedLX has joined #openscad
ur5us has joined #openscad
extor has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
snakedLX has quit [Read error: Connection reset by peer]
snakedLX has joined #openscad
snakedLX has quit [Remote host closed the connection]
snakedLX has joined #openscad
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
ur5us has quit [Ping timeout: 244 seconds]
califax has quit [Ping timeout: 258 seconds]
califax has joined #openscad
snakedLX has quit [Read error: Connection reset by peer]
epony has quit [Ping timeout: 252 seconds]
epony has joined #openscad
arebil_ has quit [Quit: arebil_]
J1A84497031 has joined #openscad
J1A844970 has quit [Ping timeout: 252 seconds]
J1A8449703162 has joined #openscad
J1A8449703162 is now known as J1A84
J1A84497031 has quit [Ping timeout: 252 seconds]
J1A84 has quit [Ping timeout: 252 seconds]
tachoknight has joined #openscad
qeed has quit [Ping timeout: 265 seconds]
J1A84 has joined #openscad
qeed has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
Trieste has quit [Ping timeout: 260 seconds]
Trieste has joined #openscad
fancsali[m] has quit [Quit: You have been kicked for being idle]
<linext>
i figured out how to load mcad and fonts into the openscad wasm
<linext>
not really a fan of the ArrayBuffer format though
<linext>
code can be pasted/typed into the OpenSCAD Code textarea
ran has joined #openscad
<teepee>
it would be cool if we could use that on the website for examples / howtos
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<linext>
yea, it's almost like jsfiddle or codepen
<InPhase>
linext: "Reset view" is broken.
<linext>
it just deletes all 3d models in the viwer
<linext>
sometimes i'm getting double renders of the same object
<linext>
clicking 3. Generate... will redraw the STL
<InPhase>
Oh, yeah, I had a double render one time, but cannot reproduce it.
<linext>
i think there's either a race condition from something being called twice
<InPhase>
linext: For UX, the first time I saw this interface I was super confused by "Generate OpenSCAD Params" because it doesn't do what it says. That's the button to render the model.
<linext>
it used to be that you had to click 4 buttons to get a STL download
<linext>
button 1 now clicks button 2, button 3 now clicks button 4
<InPhase>
Although it seems to also auto-render from adjusting the parameters. And "Parse" generates a model. So most of the buttons are kind of a little mislabeled.
<linext>
yea, they're from the old version, as i've been working through adding features
<linext>
my goal is to get something decent on the level of makerbot customizer by the end of the month
<InPhase>
Please don't interpret any negativity. I point these things out because I like it, and now see it as valuable to clean up to something great, rather than not liking it. :)
<InPhase>
Probably should have led with that.
<linext>
i'm going to try and see if i can import SVG images into the filesystem and get OpenSCAD wasm to find them
<InPhase>
linext: Also, download image would be a wonderful wishlist item next to Download STL.
<linext>
yea, that's easy i think
<linext>
https://ochafik.com/openscad/ downloads resources like fonts and libraries as .ZIP files and unzips them from within web assembly
<InPhase>
Maybe also on the wishlist list, share code? This could be either storage of the input files on the server if you have the capacity, or one of those "pack it into the url" approaches.
<linext>
yea, i intend to reproduce the user-based system on thingiverse with most features like each customizer having it's ownURL
<InPhase>
Although perhaps you have broader plans in mind for that of integrating it.
<InPhase>
Cool, that sounds good.
<linext>
originally i was trying to talk prusa into adding a customizer to printables.com
<linext>
they said they were too busy and would rather work on other more important things
<InPhase>
Yeah, prusa has gone a prusa-centric direction a long time ago with their sharing of gcode and such.
<InPhase>
They even veered away from open source designs for their printers toward commercial-focused stuff.
<InPhase>
I'm not sure what their overall vision is, or how open they are to ... open, still.
<J1A84>
Prusa slicer (afaik) uses negative geometries to alter designs .. the resulting 3mf files are just crap or damaged so nobody except prusa can load them
<J1A84>
and even the printables 3mf viewer can't display this shit correctly - Ü
<DenKn[m]>
I already read this source behaviuor. I hoped, this is such a big problem, that it could change in future. for example with a special for-loop wich would be expanded first. it would be possible to write an own for-loop-module: module myfor(ls) { for (i=ls) { children(0,i) } }
<DenKn[m]>
what do you do, if you have something like that? or do you naver had it?
<peepsalot>
can't really do it as a module but you can try: for(i=[0:100]) hull() { translate([0,i,0]) cube([i,0.1,i]); translate([0,i+1,0]) cube([i+1,0.1,i+1]); }
<InPhase>
DenKn[m]: Module literals and/or geometry literals, which are being discussed heavily, are tools which will facilitate these sorts of options. Geometry literals in particular would be good for your use case.
<InPhase>
DenKn[m]: So will it be possible in the future? Yes, I think so. We seem to have a broad agreement that we need these sorts of features in the language, and we're mostly only discussing how to setup the syntax and functionality.
<InPhase>
DenKn[m]: Then I suppose there's a secondary question of how to special-case your one problem of the moment. :)
<DenKn[m]>
Nice to hear. I would be glad to use it.
<DenKn[m]>
at the moment i use peepsalot's solution.
<InPhase>
And most likely it will just need to be a little uglier and less generalized, like peepsalot suggested.
<DenKn[m]>
this seems to be the most suitable solution at the moment without a iterating hull-module
<InPhase>
An alternative option is to make m() take only 2 children, and move m() inside your for loop, and give it two steps in the for loop at once.
<peepsalot>
InPhase: that's basically what my first suggestion did, except then m is just the same as hull, so i omitted the definiton
<DenKn[m]>
this was only an example. My current problem is more complex. it generates a hull of a half-cutted cylinder and a thin cube.
<InPhase>
Yeah, I was assuming this was a simplified testcase.
<InPhase>
But something of that sort.
<InPhase>
And if you don't want to repeat the parts inside the m() { ... }, then one more module.
<peepsalot>
it would definitely be a useful operation, and its something I've referred to before as "consecutive hull" or "chain hull"
<InPhase>
peepsalot: Formalizing that as an internal would probably simplify many things. But I think if we go that route what people really want is a loft like operation to connect points.
<InPhase>
DenKn[m]: Rather than "cube" you would make a list of the 4 points of the cube, and then assemble a list of those, and then call the ClosePoints on it.
<InPhase>
4 points of the square, that is.
<InPhase>
DenKn[m]: It is basically just a polyhedron call, but it handles the messy parts internally, and all you need to provide it with is the outline of points for each layer along the trajectory.
<InPhase>
(And follow the rules for the points in the trajectory, such as the ordering, and making sure they don't cause any self-intersections.)
<InPhase>
That's all in the comments there.
<DenKn[m]>
wow. I do not understand anything, yet. It is more complex. I have to have some experience with it.
Guest43 has joined #openscad
<Guest43>
I am new here and would appreciate some help. Can I use OpenSCAD python script to create 3D models independently from OpenSCAD program? meaning can I run my python code from the cloud?
<peepsalot>
openscad and python are completely independent languages
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
tachoknight_ has joined #openscad
<J1A84>
DenKn[m] have you read about polyhedron(); ?
<peepsalot>
teepee: i know that fast-csg doesn't have the greenish shading on cgal "cut" faces. so did the expected results all get replaced, or are there two separate sets now?
<Guest43>
peepsalot thank you
<Guest43>
Is there a way to convert shape file (geojson) to openscad ?
<Scopeuk>
Guest43 perhaps we can go a step back, what are you trying to achieve?
<Scopeuk>
also if you wish you can change your name by typing /nick yourNewName
<J1A84>
Guest43 there is a polygon(); that can be used
Guest43 is now known as Not_Guest
<DenKn[m]>
<J1A84> "DenKn have you read about..." <- not yet. for a cylinder there were many points/surfaces
<Not_Guest>
I wrote a python script spitting out shape file and I want to integrate that into other 3D models in automated script
<Not_Guest>
J1A84 yes my shape file is a polygon
<J1A84>
Not_Guest export and import as svg would work too or json import
la1yv_j has quit [Read error: Connection reset by peer]
la1yv_j has joined #openscad
<peepsalot>
InPhase: would geometry literals help solve the problem though? last time it was discussed I was told geometry should be a black box. so how would you iterate over them?
aiyion has quit [Remote host closed the connection]
<peepsalot>
InPhase: there are too many competing/overlapping proposals regarding object/module/geometry values for me to keep track of
aiyion has joined #openscad
e2k_ is now known as e2k
fling has quit [Remote host closed the connection]
fling has joined #openscad
qeed_ has joined #openscad
qeed has quit [Ping timeout: 264 seconds]
rawgreaze has quit [Read error: Connection reset by peer]
rawgreaze has joined #openscad
<linext>
strange, when i send a input=file to OpenSCAD FS and try to download it, it comes back slightly different
<linext>
i send cube.stl in stlbin and get back something different
<InPhase>
peepsalot: Completely unbiased opinion by me as I was the last person to edit it... But it reflects my perception of all the discussions and conclusions in here about them. (And I have yet to find the time to review JordanBrown[m]'s comments about my edits.)
<InPhase>
peepsalot: DenKn[m]'s problem would be solved with that using: module m(objs) { for (i=[0:len(objs)-1]) hull() { objs[i]; objs[i+1]; } } m([for (i=[0:100]) {translate([0,i,0])cube([i,0.1,i]); }]);
<InPhase>
So really, almost exactly what DenKn[m] wanted to do, just passed in instead of children.
<InPhase>
Oops, len(objs)-2 in there.
<InPhase>
Clearly I did not test it, since it's not implemented...
<InPhase>
peepsalot: I really want to distinguish object literals from dictionaries. I think they fundamentally represent different things.
<InPhase>
peepsalot: I'm actually okay with adding a dictionary type with string keys.
<peepsalot>
unfortunately I'm just not sure if there's any way it could be compatible with object's holding geometry as jordanbrown wants
<InPhase>
Well the geometry problems are 100% sorted out in the wiki post.
<InPhase>
That all works fine under that. I "think" we considered all the edge cases, and got it all correct.
<InPhase>
What I think turns into more chaos is trying to mix it up with string keys and pretending it's a dictionary. I want an "object" to represent an encapsulation of related variables and already computed geometry, or optionally just one of these.
rawgreaze has quit [Ping timeout: 250 seconds]
<InPhase>
If we want something to do string keys, then let us do a dict type, which focuses on dict syntaxes, and does not contain any geometry but is just a pure data store. This is a fine idea.
<InPhase>
Then we can do nice things like dict comprehensions and such to construct dicts.
<peepsalot>
InPhase: but no object comprehension then?
<InPhase>
peepsalot: Rather than object comprehensions, there are other ways in the wiki proposal to dynamically construct them by merging. Specifically, "each" applies to objects.
<InPhase>
Comprehensions only make sense with string keys, but string keys don't make sense with geometries. But "each" can be taken to mean merge all the things in.
<InPhase>
So these are two fundamentally different things unless we stretch into absurdities. So let's keep them separate.
tachoknight_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
I evaluated a few options for object comprehensions and realized I was trying to glue a dictionary into part of an object. If we want a dict, let us put one in the object as a variable, or put the object into a dict. This will be cleaner.
<peepsalot>
i guess I just have a hard time conceptualizing the difference between dict and object, especially for a language with immutable values.
<peepsalot>
they seem 90% redundant
<InPhase>
Well, object: Contains variables and geometries. dict: key/value lookup constructed by a comprehension.
othx has quit [Ping timeout: 265 seconds]
<InPhase>
The purpose of an object is to prepare geometries with variables annotating them with useful information. Think about geometries carrying along their own sizing or positioning information, or parts carrying along part information.
othx has joined #openscad
<InPhase>
A dictionary is a pure data structure for people who want to do string lookups of data.
<InPhase>
Also, a dictionary should be able to do integer key lookups of data.
<InPhase>
We do not do integer variable names.
<peepsalot>
so, does "each obj;" include geometries or no?
<InPhase>
Yes, geometries and data.
<peepsalot>
can you each obj in a dict comprehension?
<InPhase>
A dict comprehension would contain a value. "each obj;" expands to multiple variables, like how each in a list would.
<InPhase>
So you can only do it in a context type scope.
<InPhase>
i.e., in an object definition (the important one), or in a module, or at the top-level.
<InPhase>
So any place you could both define a variable and make a cube(1)
<InPhase>
So you could do one inside a dictionary by setting a dictionary value to an object which has an each inside of it. The dictionary contains no geometry, but it has a value under some key which has a geometry in it.
<peepsalot>
i have a feeling that dict comprehension + { ... } object as expression syntax would conflict. should dict use some other character than curly braces?
<InPhase>
So for this I defer to peepsalot's wisdom. A dict can be made with something like dict(...)
<InPhase>
You used similar reasoning on render.
<InPhase>
But yes, definitely not {} syntax for a dict.
<InPhase>
Although strictly speaking like Python with set and dict it COULD be done because k:v is discernible, I think that's probably a confusing mess, and I don't recommend it.
ur5us has joined #openscad
<InPhase>
{ } makes sense for objects, because it is essentially a special literal-like case of what we're already doing with other scopes designated by braces.
Guest47 has joined #openscad
<InPhase>
It is very helpful then if objects essentially behave just like these other scopes, which is what the wiki proposal does. It just has a literal-like definition that the geometries are calculated at the definition point, and that the variables are later accessible with the obj.val syntax.
<peepsalot>
InPhase: is this valid for a sort of "import as"? mylib = { include <foo.scad> };
<peepsalot>
also, are you saying that dict comprehension would only be valid syntax within the parens of a special keyword dict() ?
<linext>
so here's how OpenSCAD.wasm.js reads and writes files
<linext>
first screenshot is inputfile, and second is outputfile
<linext>
it's like i need to read the multi-byte per char array UTF-8, and convert it back into single byte char
<peepsalot>
no, its like you NEED TO STOP TREATING BINARY DATA AS TEXT. i'm done talking if you're going to continually ignore any help I try to provide.
Not_Guest has quit [Ping timeout: 252 seconds]
<dalias>
:-p
<dalias>
seconded. don't try to read binary data as text
<dalias>
probably what's happening is that the text reader rightly assumes the encoding is utf-8, but then does something like fallback on invalid utf-8 to guessing it's latin1. then the text writer rightly writes text as utf-8 (because this is 2022 and text is utf-8)
<dalias>
and the problem is that your data is not text and you should not be trying to read it as text
<JordanBrown[m]>
peepsalot, InReach: I think that one of the biggest things that needs to be understood is what the difference is, if there is a difference at all, between "objects" and "dictionaries".
<JordanBrown[m]>
My take is that there is no difference.
<JordanBrown[m]>
The question is how geometry connects in.
<JordanBrown[m]>
I'd like to avoid having several almost-the-same syntaxes.
<JordanBrown[m]>
So what I'm currently pushing is the notion that we have these things that are sets of key-value pairs, optionally plus a geometric object.
<JordanBrown[m]>
(And one of the cleanest options in some ways is to say that the geometric object is just a data item stored under a reserved key.)
<JordanBrown[m]>
If you have a "object" that is a collection of key-value pairs, I don't understand what a "dictionary" would be that would be different.
<JordanBrown[m]>
I know that Python has both concepts, and it always confuses me. JavaScript only has one.
<JordanBrown[m]>
As for the syntax of object literals, I have two thoughts:
<JordanBrown[m]>
1) it would be nice not to have two different { ... } syntaxes. That's something that I thought was cool about the proposal that InPhase mentioned, that { ... } is just top-level OpenSCAD statement context, not a special syntax.
<JordanBrown[m]>
2) Python syntax is expr=expr, allowing easily for calculated keys. But that also makes it nasty for constant keys, because you have to put the key in quotes.
<JordanBrown[m]>
And I would think that constant keys would be the more common case.
<JordanBrown[m]>
I think that the dict() that InPhase talks about is exactly the same as the object() that's been proposed.
<JordanBrown[m]>
Well, once you add the functionality that you would want dict() to have around making modified copies of dictionaries.
<ndnihil>
lol python
<JordanBrown[m]>
ndnihil: for what reason?
<ndnihil>
well, there are many reasons, but my favorite reason python is garbage is the use of whitespace as a syntactical delimiter
<ndnihil>
My First Programming Language - By Fisher Price
<InPhase>
peepsalot: Yes, that would be a valid "import as"
* ndnihil
throws up the perl4lyf gang sign
<InPhase>
peepsalot: I do not object to dict having a . accessor, with the understanding that it would only be allowed for keys that comply with variable rules. This would be sort of like swizzling for vectors, where it provides some special case conveniences, if you want. I don't think it's necessary, but we could do it.
<InPhase>
peepsalot: Oh, on render (I think it was you) you advocated that render should exist in a function context to return data, and therefore data = render( {cube(5);} ); receives an object value and returns its rendered geometry data. dict is also then functioning like a special sort of function that takes key/value pairs and returns a dict entity.
<InPhase>
dict is then not a normal function, but one with a little bit of special parsing so we can do the string values.
<peepsalot>
idk sounds bizarre. dict comprehensions only work inside dict(...) ?
<InPhase>
I haven't thought about dict comprehension syntax yet.
<InPhase>
I've been mentally deferring thought about dicts because I don't think they're too hard to figure out in comparison to objects. It just is "different", and I think doesn't mix too well.
<InPhase>
I did have one syntax in mind for an object plus dict comprehension, but I don't like it too much. It looks like: obj = { cube(5); for (i=[0:5]) [str("sqr_", i)] = i*i; };
<InPhase>
In this, obj.sqr_2 == 4, and so on.
<InPhase>
Of course that wouldn't need to be special to object scope, and could be done at the top level as well.
<InPhase>
But it's only useful in object scope for accessing like echo(obj["sqr_2"]); which would then also support strings that are not allowed to be variables.
<InPhase>
To really do a comprehension syntax with objects plus dicts you need to allow multiple comprehensions within each object like that.
<InPhase>
I just worry that's a little ... complicated?
<InPhase>
And I fear it mixes things up. But, it's possible as an option if people are really adamant these should be merged.
<peepsalot>
so string keys would require square brackets around them?
<InPhase>
A dictionary of squares with no geometry under that syntax would look like: squares = { for (i=[0:5]) } [i] = i*i; }; Then squares[3] == 9
<InPhase>
Or integer.
<InPhase>
But yes.
<InPhase>
Essentially, foreshadowing how they will be accessed later.
<InPhase>
It's required to distinguish them because you need a way to say "interpret this variable as a key" when it's not just a constant. Otherwise this is pretty useless.
<InPhase>
You cannot do a comprehension over a constant. :)
<peepsalot>
can dictionary keys be any type, or they are coerced to string?
<InPhase>
ascii_map = { for (c=[ord(a):ord(z)]) [chr(c)] = c; }; And then ascii_map.c == 99 == ascii_map["c"]
<InPhase>
Well, strings and numbers are important. I have made no decisions about other types.
<InPhase>
I would say defer consideration of other types to avoid drowning in questions over sensible hashing.
<InPhase>
File that under "could be added later".
<peepsalot>
so squares[3] != squares["3"] ?
<InPhase>
Correct, those are different values.
<InPhase>
That's how a dict typically works anyway. So if you want to mash it with objects, it comes along for the ride. :)
<InPhase>
There would be no obj.3 anyway.
<peepsalot>
hmm, until now I thought everyone wanted only strings. I feel like it should be either all strings, or all types, but no in between.
<peepsalot>
"strings only, or any type" i mean
<InPhase>
Well no dict in any language with many types supports "any type".
<peepsalot>
i thought that's how python worked
<InPhase>
Nope.
<InPhase>
d = {[1]:'a'}
<InPhase>
TypeError: unhashable type: 'list'
<InPhase>
Now their rationale is that the list is mutable, so it will get lost. But also if you try to do a custom class, it will only work if you give it a __hash__ dunder.
<InPhase>
Likewise if you tried to feed an object in OpenSCAD as a key, the question is, what data do you hash?
<InPhase>
You could probably sort it out, since we have a more confined type space, but that sounds complicated as a stage-1 implementation.
<peepsalot>
hmm, how many builtin python types are hashable?
<peepsalot>
tuples are... because those are immutable, like our lists, so then list should be if we follow their lead
<peepsalot>
also None
<InPhase>
Sets are also not.
<InPhase>
But again because they are mutable.
<InPhase>
So all built-in types are hashable if they are immutable, if we restrict "built-in types" to mean only the primitive ones.
<InPhase>
(dicts also cannot be dict keys, again because of mutability.)
<InPhase>
You could in theory do lists as well. I think I might prefer skipping objects as keys though..
<InPhase>
(In OpenSCAD.)
<InPhase>
Doing an equality check on a geometry sounds more expensive than what a user expects on a dictionary lookup.
<InPhase>
If someone really wants to write it later, fine, I suppose I wouldn't object. But that wouldn't need to be up front.
<InPhase>
list for a key could have some value, like for coordinates.
<InPhase>
Vertices to faces map? :)
<peepsalot>
so maybe all but the last 2 (or 3)? undef, bool, double, string, list, range, function, object
<peepsalot>
i think range would be trivial to support, just not sure if there's any utility to it
<linext>
anyone know the mime-type of binary STL?
teepee_ has joined #openscad
<Friithian>
I dont think there is a specific one that is different
<JordanBrown[m]>
(Sorry, switching back and forth between this and real work.)
<Friithian>
this *is* real work :D
<JordanBrown[m]>
InPhase: I think your dict() is (or easily can be) a totally normal function, just as object() is. The only thing special is that, like echo(), you can have arbitrary key= parameters.
<JordanBrown[m]>
I mean the not-fun kind of real work :-)
<Friithian>
aaah
<JordanBrown[m]>
I believe that Java will let you make HashMaps of anything with a hash method and a comparison method (the name of which escapes me at the moment). And your hash function could be "return 0" or something like that, if you didn't mind O(n) lookup times.
<JordanBrown[m]>
But again I don't see any reason to have two different "map" types, two different types that are collections of key-value pairs.
<JordanBrown[m]>
I would (and did!) start with only allowing strings as keys, but there's no reason that other types couldn't be allowed.