<J1A84>
why would more money for a forum make the software better? If people want to develop ideas i am sure they find a way of communication
<J1A84>
hmm not ideal that all the emails from replies are visible in the lists.openscad.org
GNUmoon has joined #openscad
kwikius has joined #openscad
<kwikius>
So where Does all the money go? wages?
kwikius has quit [Client Quit]
<J1A84>
Server Infrastructure and bounties for example
snaked has quit [Quit: Leaving]
<InPhase>
Well opencollective clearly states nothing has been disbursed yet from that site.
<InPhase>
$16k might be a lot in terms of web server costs, but it's puny in terms of labor costs. Actual operational expenses would require it to accumulate to higher I think. One option that is moving on to the table though is funding for a server for package/library management.
<InPhase>
At the rate donations are now coming in that becomes more conceivable.
<J1A84>
15% fees .. seems bit much
<J1A84>
(11.5% is the calculated fee sum)
<InPhase>
Hosted servers get a lot more pricey when hefty storage is in place and more computational resources become required, so it will take something like the current rate of donations, rather than the past rates.
<InPhase>
J1A84: Is that the opencollective fee?
<J1A84>
yes
<InPhase>
J1A84: There can be significant legitimate operational costs for financial services like that when you follow all the legal sorts of requirements.
<InPhase>
J1A84: At high volume that could maybe drop down to the 5% scale, but if they're doing small volume it's fair that it could require a bit more.
<J1A84>
sure also credit card/paypal/ whatever payment method is supported will all cost a fee .. still
<J1A84>
if people would use direct bank transfer .. it would be cheaper Ü
<InPhase>
Well, trust and transparency are important.
<InPhase>
Most of those donors probably have no idea who anyone involved with the project is. :)
<J1A84>
didn't steam / apple / g-play etc all take 30%
<J1A84>
hmm google seems to take 15%
<J1A84>
and apple cut them half to 15% for small dev
<InPhase>
Seems to not be 15% right now? Where did you get 15%?
<InPhase>
5% unless a little extra for bank transfer.
<InPhase>
That gives them an operational budget of $1.75 million/yr, which will cover a small team of 6-12 employees (depending on other outgoing expenses).
<InPhase>
teepee: Doesn't that qualify for that bounty?
<InPhase>
It's not a huge bounty, but it sounds like he should receive it.
<kwikius>
I would say spending money on a decent forum would pay off way more than a bounty. But I know that if a forum isnt well moderated then it quickly goes to shit!
kwikius has quit [Quit: Client closed]
<J1A84>
a forum is for people with problems .. a bounty for people that solve those
kwikius has joined #openscad
<kwikius>
So without a forum you will end up solving problems that don't need to be solved!
<teepee>
InPhase: yep, I totally agree
kwikius has quit [Quit: Client closed]
kwikius has joined #openscad
kwikius has quit [Client Quit]
tachoknight has joined #openscad
epony has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<JordanBrown[m]>
The only kind of forum that would be interesting would be one that has a near-seamless integration with the mailing list. The problem is not that there is no forum. There are several forum-style OpenSCAD communities - start with the Reddit community. The problem is that they are not nearly as active and, as far as I can tell, are not where the Cool Kids hang out. If there aren't a lot of people, if the people doing the development
<JordanBrown[m]>
and the people doing the big projects don't hang out there, then the forum is not nearly as good a resource for getting questions answered.
<JordanBrown[m]>
teepee, what's the current donation rate?
<JordanBrown[m]>
It's FOSS, so self-hosting is an option... if server capacity is available, if somebody was willing to set it up and keep it running...
TheAssassin has quit [Remote host closed the connection]
<JordanBrown[m]>
I am at least a little interested in Thunderbird, so I signed up for the Mozilla one and, I think, have turned on what I would need to pretend that it's a mailing list. We'll see. I'm not terribly optimistic - it looks like Discourse is a forum that sort of interoperates with e-mail, and those are hard to get right. (Just as it's hard to gateway a mailing list into a forum and get it right on the forum side - but since I prefer
<JordanBrown[m]>
mailing lists, I don't care as much about that direction.)
ur5us has quit [Ping timeout: 244 seconds]
<JordanBrown[m]>
I didn't look hard, but I didn't immediately see any options for gatewaying Discourse onto a standard mailing list. It looks like you have to adopt Discourse, and then can use it via e-mail. That means that there's a risk that the e-mail experience will not be as good as it is on a standard mailing list. That would be bad, since the majority of our users prefer the mailing list experience.
J1A844237 has quit [Ping timeout: 252 seconds]
J1A84 has joined #openscad
<JordanBrown[m]>
3D printing is like watching grass dry.
<J1A84>
if you have a nozzle cam it is more like a race
<juri_>
nozzle cams are a lot of fun.
<phryk>
i can't access variables from the main file in included files, can I?
<phryk>
the setup i'd like to have would be to have major modules/pieces in their own files being renderable as stand-alone but also in the main assembly.scad and have them configurable through the customizer in both cases – this currently isn't possible, is it?
mohnish has joined #openscad
<phryk>
i also have config variables that need to be shared between files, so my usual approach would be to have a config.scad, but as per the docs only variables from the main (i.e. directly opened) file are accessible through the customizer so that pattern also doesn't seem to be supported…
<JordanBrown[m]>
included, yes. used, no.
<JordanBrown[m]>
include is as if the text of the file was inserted at that point.
<JordanBrown[m]>
use is more complicated and has some isolation.
<JordanBrown[m]>
I don't know how the customizer interacts with include, but at best the include would have to be at the top of the file. I don't know if even that works.
<phryk>
JordanBrown[m]: can i check whether the evaluated file is the main file?
<JordanBrown[m]>
I don't think there is any direct way.
<phryk>
aw, that's a shame – because then i can just render the major modules in their own files if they're directly opened and have the file still be includable and (hopefully) work with the customizer….
<JordanBrown[m]>
You can do something kind of similar, because a variable assignment in the main file, after the include, wins.
<JordanBrown[m]>
So you could have the main say
<JordanBrown[m]>
include <sub.scad>
<JordanBrown[m]>
main = true;
<JordanBrown[m]>
and have sub.scad say
<JordanBrown[m]>
main = false;
<JordanBrown[m]>
if (main) { ... called from main ... }
<JordanBrown[m]>
But it sounds a bit like what you want is for the sub to have modules with appropriate parameters, and to invoke them from the main using configuration variables defined in the main.
<JordanBrown[m]>
and then use "use".
<phryk>
JordanBrown[m]: something like that, hence the approach of having a global file for all configuration variables…
<phryk>
oh, but can i "use" the main file from sub-files to import its variables?
<JordanBrown[m]>
When you use "use", the top-level module invocations in the sub are not executed, so you can have those do something interesting (demo, test) when the sub is executed on its own.
<JordanBrown[m]>
Variables don't cross the "use" boundary in either direction.
<JordanBrown[m]>
Modules and functions in the "used" file are visible to the "using" file.
<phryk>
also, with the main variable you described main will always be false in the sub files, even when directly loaded, no?
<JordanBrown[m]>
No, "main" will be true in the sub file if it's being included from the main file.
<JordanBrown[m]>
But I don't know if there is a pattern that will work well with both that behavior and the customizer.
<phryk>
guess i'll find out when i get to refactor this thing^^
ur5us has joined #openscad
TheAssassin has quit [Ping timeout: 258 seconds]
TheAssassin has joined #openscad
kwikius has joined #openscad
kwikius has quit [Client Quit]
aiyion has quit [Ping timeout: 258 seconds]
aiyion has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 258 seconds]
teepee_ is now known as teepee
<phryk>
weird, i'm getting major stutter when the windows size is… too small?
J1A8486 has joined #openscad
J1A84 has quit [Ping timeout: 252 seconds]
<phryk>
mhhh, if/when dictionaries drop, i could write a little function to easily define accessors for dictionary items, but that probably wouldn't work with the customizer @_@
<phryk>
mhh, i should probably work out a list of features i actually want from my scad design pattern and then see what's missing in openscad to actually implement it and see what could be easy-ish additions to openscad itself…
<teepee>
cool, discuss before here for maximum mergebility :)
<phryk>
teepee: i'm not sure how much i can actually implement. i do have *some* limited C experience, but i haven't really contributed to any complex codebase, much less one written by other people.^^
<teepee>
openscad has quite a number of things that are not hugely complicated. the geometry stuff is of course, but main headscratcher part is using CGAL
<phryk>
mostly i'm interested in making the case for a couple features that would enable a clean, extensible pattern in a well-founded and explained way. not a fan of demanding features without an explanation of why they'd even be a good idea to have.
<teepee>
so depending on what you need it might not be as complicated
<teepee>
but even if you don't end up with any coding, having a clear feature request with good description has a much higher chance of getting someone else to implement
<phryk>
teepee: i think one of the most important ones (apart from a ruler :P) would be a good pattern to be able to design modules separately with config variables shared between modules and the main assembly and have all that work well with the customizer.
<teepee>
that sounds like the big discussion going on anyway :)
<phryk>
yeah, first I'll have to work out a clean, workable pattern that would work with a few new features at most – ideally just one.
<JordanBrown[m]>
The biggest problem tends to be figuring out how to design new features so that they don't break anything existing, and so that they won't break a few years down the road when the next feature arrives.
<teepee>
I tend to think we still can get the object() function in already to maybe get some more direct feedback on the data handling part
<JordanBrown[m]>
I thought that object() should be fairly non-controversial, but so far it seems that I was wrong.
<teepee>
feature wise it is in my view. not sure about the name, and there's a couple of details we want to look at like the ordering discussion and so one
<teepee>
on*
<teepee>
in what part did you see the controversial stuff?
<phryk>
i think he might JordanBrown[m] might be referring to me saying that a dictionary would still be nice to have so you have a container type that's guaranteed not to hold any geometry.
<phryk>
a point i feel is probably even more valid now that i've read that the customizer apparently ignores everything defined after the first geometry.
<JordanBrown[m]>
My "biggest problem" comment was a response to phryk 's "interested in making the case for a couple features" comment.
<phryk>
tho i'm not sure how set in stone the customizer concept is. maybe there should just be some sort of config directive so the customizer can definitely tell what is intended for it…
<teepee>
the comment style customizer is set in stone by thingiverse
<teepee>
I do want an additional native syntax we can design freely
<teepee>
both will work with the customizer GUI integrated in openscad
<phryk>
nice. :)
<teepee>
thats the idea anyway
<JordanBrown[m]>
WRT controversial topics in object()... somebody said "we shouldn't need this, we should have object literals that should cover this need, why do we need to have a function to create this type", and somebody else said "how will echo produce valid OpenSCAD syntax if keys can be non-identifiers and object-literal syntax can't handle keys that are non-identifiers".
<phryk>
okay, I'mma continue designing my desk modules. hopefully i'll get to refactor in a couple days so i can test whether having a config.scad and including it from main assembly and module files will work with the customizer and then orient myself from there. :)
<teepee>
I could live with restricted objects and maybe having the any-key-possible dictionaries
<JordanBrown[m]>
I would go back to the question that I've asked InPhase a number of times: Why have two types? What's the difference between the two?
<teepee>
one is data only, with arbitrary keys maybe a way to have operation like + defined
<teepee>
the other one is more a representation of code / script where other rules apply
<teepee>
like no object + object but some form of customization to replace the "import config file" use case
<teepee>
"import config file but allow defaults in the main file" to be more specific
TheAssassin has quit [Ping timeout: 258 seconds]
TheAssassin has joined #openscad
<JordanBrown[m]>
As I define them, neither of them is a representation of *code*.
<JordanBrown[m]>
Somewhere in the picture, eventually, is a representation of *geometry*, but that's the *result* of executing code.
<JordanBrown[m]>
Somewhere in the picture, eventually, maybe, is module literals and module references, but those are independent.
ur5us has quit [Remote host closed the connection]
<JordanBrown[m]>
But an object literal, like the existing array literal, is executed immediately and yields a data value.
ur5us has joined #openscad
<JordanBrown[m]>
(That data value might include function or module references, just as an array today can include function references, but those would be part of its native ability to store arbitrary data values, not because they are part of its object-ness.)
<JordanBrown[m]>
Using my "hybrid" syntax, if you say
<JordanBrown[m]>
g = { cube(10); };
<JordanBrown[m]>
what is in g is not a program that says "call cube with 10 as an argument". Rather, it's a CSG tree that includes a 10-unit cube primitive, or perhaps a mesh with 8 vertexes and 12 triangles.
<JordanBrown[m]>
if you say
<JordanBrown[m]>
then the echo happens right then, whether or not you ever look at g again.
<JordanBrown[m]>
g = { echo("hello!"); };
<teepee>
yeah, I agree. what I meant was more that the content between those braces is basically an openscad script
<teepee>
e.g. g = import("cube.scad"); would do the same if that file contains "cube(10);"
<JordanBrown[m]>
Oh, yes, absolutely what is between the braces is basically a script. It is what I call "statement context" (as distinct from "expression context").
<JordanBrown[m]>
But, just to be painfully clear since we seem to have had some terminological problems in the discussion,
<JordanBrown[m]>
after you say
<JordanBrown[m]>
g = { cube(10); };
<JordanBrown[m]>
g does not have any code in it, any more than
<JordanBrown[m]>
after
<JordanBrown[m]>
a = [ b + 3, c*d ];
<JordanBrown[m]>
has expressions in it.
<JordanBrown[m]>
The block of code, or the expressions, are evaluated to produce data items, and it is those resulting data items that are stored in the object or array respectively.
<teepee>
I think that very much matches Dougs proposal too, which is good
lastrodamo has quit [Quit: Leaving]
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
<InPhase>
JordanBrown[m]: I still prefer the reduced mess of separate types. The problem is you have three types of things in a dict+object, geometry data, variables, and keys.
<InPhase>
JordanBrown[m]: That's a lot to mash together, and adding the keys does not add programming capability to object workflows.
<InPhase>
JordanBrown[m]: But perhaps try to find me a usecase where it is valuable to mash all three types of data together.
<InPhase>
JordanBrown[m]: And, I am justifying the statement that variables and keys are different types of data on the fact that they are constrained to different syntax rules. Variables are accessible inside the object at evaluation, and can be accessed with . syntax.
<InPhase>
At implementation they will probably end up stored separately as well.
<InPhase>
At echo time you would need to distinguish between them somehow.
<InPhase>
I suspect the usecase will be hard to think of, because my counter question will be, "Why not just a dict member?"
<JordanBrown[m]>
I understand that the geometric object and the name-value pairs are separate things, and indeed that's one of the aspects that I'm not totally happy about.
<JordanBrown[m]>
I don't understand drawing a distinction between the keys and the values. Yes, they have different rules, but they are inextricably bound together. You could not possibly have a data structure of the sort that we're talking about without having both.
<JordanBrown[m]>
(BTW, note that that part is already just about fully working in the development snapshot.)
<JordanBrown[m]>
I guess what I do not understand is, if we have that "hybrid" model for objects, what would a dictionary do that an object can't do?
<InPhase>
Other key types and dictionary comprehensions.
<JordanBrown[m]>
Why can't an object do that?
<InPhase>
One focuses on being a very abstract key/value data store. The other focuses on variables associated with objects in a shared scope.
<JordanBrown[m]>
Why are those different?
<InPhase>
For variables and objects to be naturally associated, they should be proper variables. Like, the sizes used to actually make a thing.
<InPhase>
But a dict is for storing more arbitrary data for lookup by string or integer.
<JordanBrown[m]>
Isn't that up to the program?
<InPhase>
Or as we established, keys that are coordinates could be an option.
<JordanBrown[m]>
Sure, you would expect that an object that contains a cube might contain its dimensions, but that doesn't mean that it can't also contain the author's phone number.
<InPhase>
I think we should be able to agree that a 3D coordinate is not a variable.
<JordanBrown[m]>
Huh?
<JordanBrown[m]>
Why not?
<JordanBrown[m]>
Or: what does "variable" mean?
<JordanBrown[m]>
point=[10,10,10]
<JordanBrown[m]>
looks like a 3D coordinate to me
<JordanBrown[m]>
looks like a variable containing a 3D coordinate to me.
<InPhase>
echo(d[[2.5, 3.7, 1.1]]) is very different from echo(o.x)
<JordanBrown[m]>
Not when you consider o.x to be shorthand for o["x"].
<InPhase>
If we take your point: d[point] is looking up that coordinate. o.point is a totally different thing. o.point is accessing a point WITHIN the object, while d[point] is grabbing the value associated with [10,10,10]
<JordanBrown[m]>
o.point is the same as o["point"].
<JordanBrown[m]>
Hypothetically, not yet implemented, you could also say o[[10,10,10]].
<JordanBrown[m]>
Generally, you could say o[keyexpr]. For the particular case where the key is a string that follows identifier rules, o.key is available as a shortcut.
<InPhase>
JordanBrown[m]: Well, I'm not seeing o.key as a shortcut.
<linext>
register and login now work, if anyone wants to be an early bird
<JordanBrown[m]>
(That aspect is not something that I'm making up - that's how JavaScript does it. But JS doesn't allow non-string keys.)
<JordanBrown[m]>
Why not?
<InPhase>
JordanBrown[m]: I'm seeing o.key as the primary accessor, because it is grabbing the thing in the way it's used when evaluating the object.
<InPhase>
o = { point = [10,10,10]; translate(point) cube(5); }
<InPhase>
We don't have any strings there.
<JordanBrown[m]>
o = {
<JordanBrown[m]>
scratch that
<InPhase>
Double-nose whisker frowning cyclops.
<JordanBrown[m]>
In the "hybrid" model, objects have two components: a name-value component, and a geometry component.
<JordanBrown[m]>
In the example you give, the geometry component is a translated cube.
<JordanBrown[m]>
The name-value component has one name-value pair, with a name of "point" and a value of [10,10,10].
<JordanBrown[m]>
You could equally well access that value using o.point or o["point"].
kwikius has joined #openscad
<InPhase>
JordanBrown[m]: But there's no real value I can see in having o["point"] as an additional accessor for object types on a variable like that.
<JordanBrown[m]>
In that particular case, maybe not.
<JordanBrown[m]>
But in the general case, sure.
<InPhase>
Well, find me some examples. :)
<InPhase>
I remain perpetually willing to be convinced by sufficialy compelling use-cases.
<InPhase>
sufficiantly
<JordanBrown[m]>
o = { losangeles= [34,-118]; newyork=[40,-74]; paris=[48,2]};
<JordanBrown[m]>
for (k = o) translate(o[k]) circle(1);
<InPhase>
Well, but that's just a dict.
<JordanBrown[m]>
Sure.
<InPhase>
We could write it in dict form.
<JordanBrown[m]>
Why have two forms?
<JordanBrown[m]>
Why should an object that doesn't happen to have any geometry in it be different from a dictionary?
<InPhase>
Because they are serving different roles.
<JordanBrown[m]>
Are they?
<InPhase>
Sure. Imagine if you tried to put some geometry in there, and a single variable got used that wasn't a city.
<InPhase>
Thus, if you inserted geometry, you would have to make the whole of your geometry without using a single variable, just to make sure the "for (k = o)" isn't broken.
<JordanBrown[m]>
Uh... don't build data structures that don't make sense for your program?
<JordanBrown[m]>
points = [ [5,5,5], [10,10,10], "aardvark" ]; doesn't make much sense either.
<JordanBrown[m]>
First, no, technically, you wouldn't. You could wrap all of your geometry in a union() and then its variables wouldn't be visible.
<InPhase>
o = { cities = {"losangeles":[34,-118], "newyork":[40,-74], "paris":[48,2]}; dotsize = 3; for (k=cities) translate(cities[k]) circle(dotsize); };
<InPhase>
This is an object.
<InPhase>
Want the cities outside? for (k = o.cities)
<JordanBrown[m]>
Indeed, it is an object.
<JordanBrown[m]>
And it's no less an object if you drop out the "for...circle()".)
<JordanBrown[m]>
It just doesn't happen to have any geometry.
<JordanBrown[m]>
Give or take that you used a different syntax for the city list.
<InPhase>
A syntax that stays clean if I do: d = {[1,2]:5, [3,4]:6, [5,7]:9};
<JordanBrown[m]>
That looks like Python dict syntax.
<JordanBrown[m]>
which is, I believe, { keyexpr: valexpr, ...}.
<InPhase>
It does. I happen to like that we can copy and paste vectors back and forth from Python. Might be nice to have for dicts as well. :)
<JordanBrown[m]>
That's a great syntax ... if the majority of your keys are computed.
<JordanBrown[m]>
I contend that the majority of keys are *not* computed.
<JordanBrown[m]>
That the majority of keys are identifiers.
<InPhase>
I'm confident I will be computing keys.
<InPhase>
I do it in Python all the time.
<JordanBrown[m]>
Sure.
<JordanBrown[m]>
I didn't say "all", I said "majority".
<InPhase>
It might be the majority for me for pure dicts.
<InPhase>
I very rarely manually type out a dictionary.
<InPhase>
If I know manual names, I usually make an object instead.
<JordanBrown[m]>
Seems like something of a circular argument.
<InPhase>
dicts I mostly use for computing associations between things as rearrangements of existing data.
<JordanBrown[m]>
In Python, yes, you must make that distinction, because objects are awkward to use for computed keys and dicts are awkward to use for identifier keys.
<JordanBrown[m]>
In JS objects are convenient to use for both purposes.
<JordanBrown[m]>
(Except that in JS keys are, at least kind of, always strings. But that's orthogonal.)
<InPhase>
Note that with what I'm proposing, copied and pasted json is also valid OpenSCAD code.
<InPhase>
Provided you assign it to something or pass it to something.
<InPhase>
In fact, the echo of a dictionary will also always be valid json if it contains only the types supported by json.
<InPhase>
This will have value.
<JordanBrown[m]>
Indeed that's an advantage. I'm not confident that you can come up with a ... pleasant ... syntax that allows both that and embedding OpenSCAD statement context in the middle of an expression.
<JordanBrown[m]>
They both kind of naturally want to be { ... }.
<InPhase>
This is why I like them separate. There's an asset to type/purpose distinction like this, because you can clean up and specialize the syntax that applies to each.
<InPhase>
Yet you can still mix and match them in combination by composition.
<JordanBrown[m]>
So, for discussion purposes, what might a syntax be that allows for both embedding OpenSCAD statements in an expression, and embedding a JS-style object in an expression?
<JordanBrown[m]>
BTW, JS form and Python form look kind of similar, but are not compatible.
<JordanBrown[m]>
In JS, the left side of the colon is an identifier or a constant string.
<JordanBrown[m]>
In Python, the left side of the colon is an expression.
<JordanBrown[m]>
So in Python { x: 3 } does not mean "make a dictionary with a key of 'x' with a value of 3".
<JordanBrown[m]>
It means "make a dictionary with a key taken from the variable x, with a value of 3".
<JordanBrown[m]>
In JSON the left side is always a constant string, so I guess that JSON form is a subset of Python form.
<kwikius>
/ module_ref arguments should be in scope!
<kwikius>
pt = obj1.point;
<kwikius>
/ and...
<kwikius>
pt2 = module obj([5,0,0]).point;
<kwikius>
///
<kwikius>
//
<kwikius>
// ah comment !
<JordanBrown[m]>
If you took the word "module" out of the obj1 and pt2 lines I'd be fine with that, and I think it is pretty much what falls out of combining my object proposal with a module literals proposal.
<JordanBrown[m]>
Well, maybe.
<JordanBrown[m]>
I hadn't really thought through what invoking a module in expression context would return. But having it return an object that contains all of the names and values, plus the geometry, makes sense.
<kwikius>
Don't know. I removed all the element access stuff so can't remember what passes bison! Putting modue in front of everything is smpler to remember and 0= {...} is still available for another purpose
<JordanBrown[m]>
If you say
<JordanBrown[m]>
o = module foo(bar);
<JordanBrown[m]>
is that defining a module with an empty body, or invoking an existing module?
<phryk>
does openscad have a container type i can add values to with a for loop?
<JordanBrown[m]>
lists (aka vectors, arrays)
<JordanBrown[m]>
sort of
<JordanBrown[m]>
You cannot *add values*.
<JordanBrown[m]>
OpenSCAD does not have variables. It has named constants.
<JordanBrown[m]>
But you can generate a list using a list comprehension.
<JordanBrown[m]>
squares = [ for (i=[0:10]) i*i ];
<JordanBrown[m]>
You cannot add a value to a list. But you can create a new list that starts with an old list and has a new value on the end.
<phryk>
my goal is writing a function that gives me a list of 2d vectors defining a regularly spaced grid – with number of rows and columns as well as offsets for both as parameters – so i can more easily have things that align with each other.