<mechadense>
In OpenSCAD version 2023.05.04.ai15029 (git 7714032ac) it seems functions are not included via "use<>" or "include<>". I need that to make a reusable library. Any tipps?
<mechadense>
Specifically these get not carried over it seems: function test1(x) = 2*x;
<mechadense>
test2 = function(x) 2*x;
kintel has quit [Client Quit]
<mechadense>
I have a gear/screw library with profiles and geometries defined after the fact, but want to use one of some standard profile functions in another file.
<mechadense>
I can't pick profiled by just passing some strings describing the profiles (and using case of analysis) because I want to pass parameters too.
guso78 has joined #openscad
<InPhase>
mechadense: Functions are included. Function references are not with use, but only with include.
<InPhase>
mechadense: So test2 = function(x) 2*x; will only carry over with include. But function test2(x) = 2*x; would get carried over with both.
<InPhase>
mechadense: The defining characteristic of the differences is that use only picks up functions and modules and not variables, and those assignment statement versions make a variable that refers to a function.
escherial has quit [Remote host closed the connection]
<J23>
btw why is SCAD not recognizing if a library is used twice?
<InPhase>
J23: Do you have a problem with code reuse?
<J23>
I tried to split up so lib A is used by lib B but if i include A and B then A is executed twice (at least the echos)
<mechadense>
I had no luck with include either.
<J23>
mechadense include should work
<J23>
\me thinks .oO time to update for me
<mechadense>
Just re-checked, cleared console, it gives: function test1(x) = 2*x;
<mechadense>
test2 = function(x) 2*x; and same for test2
<mechadense>
oops incomplete
<mechadense>
WARNING: ignoring unknown function before both
<mechadense>
using include<...>
<J23>
that is in 2023.05.04 only?
<J23>
what does ```echo(test2);``` give
<mechadense>
2022.05.15 too
<J23>
maybe add an echo("libX"); in your library just to ensure it is really included
<mechadense>
WARNING: Ignoring unknown variable 'test2' in file
<J23>
maybe you including a library with the same name but from a different location without that function
<J23>
as libraries can be used from the acual folder, user and system
<mechadense>
Well all the geometry carries over so it's definitely included.
<J23>
i am (and other) using functions a lot and using all sort of versions .. so if it is not a bug in the most recent one - i think i would have noticed if such an elementary function stopped working
drfff has quit [Ping timeout: 240 seconds]
<mechadense>
RESOLVED classic i remaned the dependency but chaned only a bit there. Sorry to steal your time for that and THANKS!!
<J23>
no problem .. glad it could be solved
<J23>
(and glad you asked here and didn't open an issue Ü )
J23 has quit [Quit: Client closed]
J23 has joined #openscad
mechadense has quit [Quit: Client closed]
L29Ah has quit [Ping timeout: 268 seconds]
guso78 has quit [Quit: Client closed]
peeps[work] has joined #openscad
peeps[work] has quit [Quit: Leaving]
peeps[work] has joined #openscad
guso78 has joined #openscad
guso7842 has joined #openscad
guso78 has quit [Client Quit]
<joseph_>
teepee kintel: Supposedly the GSoC decisions have been released now. But there appear to be technical difficulties with Google's site because login attempts return "something went wrong." Perhaps it is from everyone trying to check the results simultaneously.
<teepee>
yep, #gsoc is a flurry of activity right now :)
<teepee>
I guess the easy option is waiting for the email
<joseph_>
teepee I didn't even know there was a different IRC channel for GSOC. I think I've set up all my clients to only show this channel
<teepee>
it's not that used anymore, the early group of google admins actively used it but that stopped when the team changed a couple of years ago
<teepee>
now and in addition due to the freenode->libera move it's just a small one kept alive by some of the regular mentors
<joseph_>
Thank you for clarifying. I believe I misunderstood the IRC topology. At first I thought the flurry of #gsoc activity was all for OpenSCAD applicants which didn't make sense. In Slack, which I am familiar with from my university courses, different "servers" are generally assigned for different purposes and there can be multiple channels per organization. But it seems like many OSS orgs share just one Libera server.
<joseph_>
And I now have an email saying that my GSoC proposal was accepted!
<teepee>
yep, there's hundreds of oss projects having chanels here
<guso7842>
InPhase, i just looked into the source code openscad use statment. it appears to accept far more but only scad files. there are also otf and ttf which seem to be fonts for text statement ...
<teepee>
yep it registers fonts as the normal font usage is always by name not by path
<guso7842>
i like to concept! is it possible to use serveral differwent l fonts in parallel ?
<teepee>
you can use all (vector fonts) that the built-in fontconfig knows about, on linux the list is shown via fc-list
<teepee>
all "installed" fonts are there anyway
<teepee>
use is only needed for fonts that are shipped with the project and are not necessarily installed
<guso7842>
did not know fc-list, but its output i huge
<guso7842>
and in text() command you select the font by e.g. script="Cantarell-ExtraBold" ) ?
<teepee>
font=""
<teepee>
that parameter basically is a fontconfig query so in theory you can put in a full query like fc-query uses
<teepee>
it's probably better to keep that limited, is a bit of an API leak
<guso7842>
I actually blindly thought, that use can use process scad files. if I know that option/idea before, i did not have to go the long way and coding an extra "texture" command in src/core/Expression.cc
<guso7842>
.. that use can process scad files only ....
L29Ah has joined #openscad
<guso7842>
teepee, apparently you are the very expert on text() command as you finally got it inserted into openscad. so many people use it :)
<teepee>
so it is written in the openscad history books ;-)
<guso7842>
at least its written in the github "history" but very likely the information got more popular
<guso7842>
background was, that inphase was brainstorming on how to best mix openscad with python lanaguage, so python could calculate subresults which openscad would assemble to the final result. now looking into the implementation of "use" keyword , this appears to be a very promising concept, when supporting "python" file type next to fft and otf.
Guest82 has joined #openscad
Guest82 has quit [Client Quit]
<guso7842>
question is just how to make the best link of python solids to module children and python numbers to openscad function results.
<teepee>
yeah, interesting question, at least some interaction between the languages would be great
<teepee>
but I'm not yet sure what the best strategy for that is
<guso7842>
i vote for including them by "use" ....
<teepee>
yes, that seems the natural way
<teepee>
but we still need some way of actually calling things and returning geometry or values
<teepee>
I don't have a good feeling how complex that is
<guso7842>
is openscad content included with "use" inserted into the openscad main script during "use" time or later when their functions are actually needed
<teepee>
it's parsed and stored as a separate module
<teepee>
so lookup for things will find it in the outer script
<guso7842>
i think: each python function included with "use" should be marked as "returns solid" or "returns other. it should have the same effect as defining a openscad function or defining an openscad module.
<teepee>
yeah, so we need to put some sort of wrapper into the parsed result
<guso7842>
the "lookup module name" function needs to be extended
<guso7842>
i presume such function exists
<teepee>
yes, for modules and functions
<teepee>
although that covers only the old style functions
<guso7842>
what is the difference between "old style functions" and more recent version ?
<Lagopus>
hmm, it still may be a bit too flat when stretched to the proper dimensions, but it's better than what I currently am facing
kintel has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<peepsalot>
Lagopus: not sure what you mean about "too flat", like too low poly? also there's no manipulation of an STL involved, just an cross section outline path
<Lagopus>
to be brief, looking to make an inner threading for a cap, extruding the circle doesn't give the threads enough substance but I have a few ideas to correct some things.
<peepsalot>
generating threads is a whole other problem, typically triangular profile an not circular
<peepsalot>
there are a number of libraries specifically for making threads already though
<InPhase>
That one is not the most flexible thread library for choosing different thread profiles other than triangular, but it gives very efficient results with the full thread as one polyhedron, it handles tolerances properly, and it gets improved fits by tapering the end of the outer threads in a bit so they insert smoothly.
<InPhase>
I have thought about writing a version that takes an arbitrary cross-section profile, but it is hard to merge that with the other design goal I had of perfectly aligning the triangulation with the edges to maximize smoothness of the turning.