<peepsalot>
Scopeuk: since most modern CPUs have boost modes that change clock freq on demand, logging clock counts per task instead of wall time, user time etc. would be at least a step in the right direction
<peepsalot>
perf on linux can report clock cycles spent, e.g. "perf stat openscad [args]" for a basic usage
ur5us has joined #openscad
<peepsalot>
perf actually has an overwhelming number of metrics which can be analyzed, but that basic call gives: https://bpa.st/TIWA
<OlivierChafik[m]>
peepsalot: no grid in the hybrid đź‘Ś
<OlivierChafik[m]>
peepsalot: is the mimalloc lib only for Windows?
<peepsalot>
OlivierChafik[m]: mimalloc is cross platform. its actually least effective on windows at the moment, due to our funky cross compilation build environment for windows builds
<InPhase>
teepee: So you sent me that @opencax github invitation right in the middle of when I was laser-focused on a software release date at work, and it seems it expired by the time I found it again today.
<peepsalot>
OlivierChafik[m]: the problem that was identified is that CGAL + GMP based number types does an excessive number of malloc and free calls, basically everytime any operation is performed on any value, it requires a whole new allocation, which is far from ideal
<InPhase>
teepee: Can you re-send that?
<peepsalot>
OlivierChafik[m]: you can get some memory data by setting environment var MIMALLOC_SHOW_STATS=1 or MIMALLOC_VERBOSE=1 before an openscad-nightly call
<peepsalot>
upon exit it will print a summary
<peepsalot>
if you have a debug build, it prints a super detailed summary, where you can see the number of allocations of each size like 8bytes, 16bytes, 24bytes etc, and see that even though peak memory at any given time is maybe 100MB or so for some render, it will go through millions of tiny temporary allocations and frees, totalling in GBs or tens of GBs
<OlivierChafik[m]>
waaah, amazing!!
<OlivierChafik[m]>
haha you mean I could have benchmarked memory all that time???
<OlivierChafik[m]>
do the stats/verbose options come with much overhead?
<peepsalot>
displaying them no, but using a debug build for detailed stats is actually crazy amount of overhead. like 2-4x slower than without mimalloc
<peepsalot>
debug builds also have some added assertions / invariant checks which are unrelated to the stats record keeping as far as I understand
<peepsalot>
there is sort of a way to control the debug level more finely, which may have less impact in terms of overhead, but i didn't see a way without modifying mimalloc's own CMakeLists.txt directly.
califax- has joined #openscad
<teepee>
InPhase: sure, there's even a "resend" button :)
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
LordOfBikes has quit [Ping timeout: 256 seconds]
<OlivierChafik[m]>
hehe, I barely ever use debug with heavy files anyway so seems like a great thing to have
<OlivierChafik[m]>
it's cool to get the peak memory alloc for release builds too!
<zingos>
teepee, peepsalot, InPhase, everyone: Hello, how are you?
<OlivierChafik[m]>
> CGAL + GMP based number types does an excessive number of malloc and free calls,
<OlivierChafik[m]>
I anticipate this gets even worse with Epeck with all its laziness
LordOfBikes has joined #openscad
<teepee>
the article is great
<teepee>
as for lazy union, we may need to default to union the top level, or at least ask at export
<teepee>
unless the user defines multiple parts, which would be a very needed extension
<teepee>
zingos: fine, crazy times in germany, but otherwise good :)
<zingos>
teepee: crazy times globally...
<zingos>
teepee: how is openscad development going? it's been a while
<teepee>
yeah, crazy everywhere but with our new government it's extra fun, not bad, but consider we have one more party now in government than US has in total :D
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<OlivierChafik[m]>
teepee: thanks! Yes the default of lazy would only make sense for the 3d printers who give the output to a slicer but other users would probably be pissed. Which brings the question of non-experimental features.....
<teepee>
InPhase: I'm expecting quite some GUI work, so I'm not sure that fits in the shorter format
<teepee>
but I guess it would be a candidate allowing for both short and long
<InPhase>
teepee: The QFontDialog does most of that already though.
<teepee>
not really as you always only see 1
<teepee>
and one of the important parts would be the filter by glyph
<InPhase>
Ok. So more of a list like the current dialogue, but where each entry has example text along with it?
<InPhase>
And then with the extra value-addeds?
<teepee>
OlivierChafik[m] depends a lot on the slicer, cura handles this well I think, but others don't like overlapping geometry in STL files at least
<teepee>
InPhase: yes, convert to dockable window, extend the list, example render (maybe even openscad style?), filter to find font having specifc glyphs
<InPhase>
Okay. I suppose that can fit the full time then. I just didn't quite have that mental image of the task at first read. It sounded like QFontDialog with a few mods.
<InPhase>
teepee: I still think it would be awesome to have something like: import <git:github.com/rcolyer/threads-scad^threads.scad> where this gets cached in the libraries.
<teepee>
I see how that's cool for single file dependencies
<InPhase>
Well it would grab the whole repository.
<teepee>
but for anything else it gets annoying quite quickly
<InPhase>
And after the ^ is the entry file.
<teepee>
but then it could be more like the Arduino libraries
<InPhase>
So if you included multiple it would reuse the cached version.
<InPhase>
(I'm not sold on ^, I just went down my keyboard and looked for a non-url character.)
<InPhase>
| could be another option I guess.
<InPhase>
I think grabbing is easy, caching is easy, lookup is pretty easy. That's like a 175hr project. Maybe another 175hr could be a library manager window with update and delete buttons.
<teepee>
hmm, and combine for long project
<teepee>
I really have no feeling how it will go with short vs. long projects
<InPhase>
I think it would have to be one, since both are not very complete without the other.
<InPhase>
I don't like the idea of a library cacher with no manager. That's fine for the power users, and crap for the rest. :)
<teepee>
yes
<teepee>
same as I don't like the very much command line only vcpkg-ce solution
<teepee>
it seems quite functional on command line
<teepee>
but calling that from the UI seems like a bad idea
<teepee>
it would be great if we could use an existing solution, but I'm not so sure anymore that actually works
<teepee>
I guess there's a reason every language invents its own library manager
<InPhase>
Adding one yourself I would imagine as, for the above example, making a folder like github.com_rcolyer_threads-scad or something of that sort
<teepee>
I guess we want to keep the simple case too
<InPhase>
There are obvious future extensions, like right click on the editor at such an import step and select "manually add"
<teepee>
maybe a separate cache folder is clearer
<InPhase>
Although MVP is the right choice for a GSoC.
<teepee>
yeah, arduino does that with zip files, I've never check how that works on the file level :)
<InPhase>
I could type out a description of this idea on the GSoC page, but only if there's buy-in that this is a good idea.
<InPhase>
It opens a lot of doors to future file sharing, but it's a long term commitment feature as it's basically a language change.
<teepee>
for the arduino style library manager, there would not even be a language change needed
<InPhase>
I don't really know what that is.
<InPhase>
I have an arduino in a box somewhere that I didn't get around to playing with.
<teepee>
have a library manager window which lists available libraries based on a list of json files
<teepee>
installing a library just downloads that and makes it available similar to our library folder (which I believe is actually modeled after that idea)
<teepee>
now there's a possible extension to the language if we want to have something like "require <library> @ version" or so
<teepee>
but in the simplest case, it would just be some sort of assumption / documentation what the files to include are
<InPhase>
So it would only grab from a pre-canned list of libraries?
<teepee>
list of lists :)
<teepee>
let me grab one...
<InPhase>
We could of course pre-install every library on the library page, and it would barely even expand the distributable. But I think the killer-app for libraries is having availability for a very open set of them.
<InPhase>
I want each person to be able to break their projects down into design/library if they like, and encourage a ton of library development.
<teepee>
yes, I'm thinking about that for the docker images, but for a release that's not an option
<teepee>
we can't put out a release for every library change
<InPhase>
Naturally. They would just get a little stale.
<teepee>
that's the board manager part not libraries
<teepee>
actually I'm not sure if the library manager is fully fixed on a single json list
<teepee>
but you can add those board definition files via preferences, that page has a link to options at the bottom
<teepee>
e.g. ESP32 is not included by default, but you can just add their json file and it will then fetch that config
<teepee>
it's extemely basic and far from the elaborate stuff like pypi, cargo, npm whatever
<teepee>
it does work surprisingly well and I've seen people adding arduino libraries quite easily
<InPhase>
Workflow-wise that would consist of "download my json file and install the library using that" rather than "download my library".
<teepee>
well, the default could be a default json file which is handled via github actions
<teepee>
that's how the arduino flow works, you give them your repo address to include and they fetch, validate and include new versions automatically then
<InPhase>
I wouldn't mind if OpenSCAD prompted first before downloading a dependency specified in a file, because polite is good, but it seems a powerful feature to automate it somehow within the scad code so that distribution of designs with dependencies becomes transparent.
<teepee>
just like everyone else does, having some sort of dependency file
<teepee>
which could also play the role of a project file eventually
<InPhase>
I think version-locking a dependency is still possible with a git approach: include <git:github.com/openscad/openscad/tree/e886d88e0d5012733eda89faa6ef675964da06a7^examples/Advanced/animation.scad>
<InPhase>
Or I guess with tags, by whatever that url syntax is.
<teepee>
sure, or refs/heads/<branch> refs/tags/<version>
<InPhase>
Right.
<InPhase>
That probably makes more sense than the url version. :)
<teepee>
hm? that's the url part for those I think
<InPhase>
Oh, does it match?
\mSg has joined #openscad
<teepee>
not sure on github, might be a local folder thing
<teepee>
but it does work for getting files I think
<teepee>
yeah, that's git convention, the github web part is slightly different
<InPhase>
I suppose libgit as a dependency would be a little cleaner than a git executable.
<InPhase>
That would greatly increase the odds that it works across the platforms.
<InPhase>
Very few Windows users will have git, and about zero will have it in the path.
<teepee>
yes, I checked, it seems to be available everywhere, so that's good
<InPhase>
Well, I said I would brainstorm some GSoC ideas, and that's my first one. But I also recognize it's a bold-move GSoC idea, so maybe it's worth letting it mentally percolate for a day or so before any conclusive decisions about posting it.
<InPhase>
It's a "this is how we're going to do things now" sort of thing, which deserves a little careful thought and not a rush.
<InPhase>
Extra opinions solicited in the following blank space.
GNUmoon has quit [Ping timeout: 276 seconds]
<InPhase>
I think in general care is required in the GSoC project selections because it's only appropriate to solicit GSoC contributions that we at least intend to merge. Young programmers committing a summer would like to have something to show for it. :)
* teepee
is off to bed :)
<InPhase>
Night teepee.
<InPhase>
OlivierChafik[m]: I upvoted your corefinement reddit posts. :)
<InPhase>
I think it's exciting progress, and worthy of announcement.
<OlivierChafik[m]>
InPhase: thanks! so happy this is now properly out in the wild... can't wait to wake up with an avalanche of bug reports haha
<Zenmaster43>
The preferences "Editor" pane includes a "color syntax highlighting" option called "for dark background", but I don't see any setting to make the background dark. Where can I set that?
Zenmaster43 has quit [Quit: Ping timeout (120 seconds)]
<Scopeuk>
huge with loads of retract and travel moves I guess
<J22>
more a resin printer thingy ..  due to the amount of shells there is a huge surface area - bit like printing a menger sponge . Printing 225 cylinder - Ü
<J22>
it is like printing a 900mm cube from the surface
<J22>
(print wall length)
arebil has joined #openscad
bboett has joined #openscad
<bboett>
hello, is there maybe a matrix bridge somewhere? have a preference of that client :D
<bboett>
well seems i missed this years openscad presentation at fosdem :'( and i am available for next years if needed
<bboett[m]>
is there a link soemwhere for the actual fosdem presentation?
jonasbits has joined #openscad
<teepee>
bboett[m]: the topic has the link for the one kintel did 2020
<bboett[m]>
isn't there one for 2022?
<teepee>
not that I'm aware
<bboett[m]>
ok, so i didn't miss this years, one?
<teepee>
probably not, and due to pure virtual nature there was no other meeting either
<teepee>
in 2020 there was a BoF session, just a couple of people talking about experiences and wishes, which was interesting
<bboett[m]>
well even a virtual one would have been ok with me :D and as said, i am availale for that sort of stuff if needed
<teepee>
something like that would be possible virtual too, but someone would need to organize :)
<bboett[m]>
on the ml Torsten had some ideas for presentations?
<teepee>
that's me :)
<teepee>
hi!
<othx>
Welcome teepee!
<bboett[m]>
ok :D hello :D yoroshiku onegai shimasu ;)
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<bboett[m]>
well then ready when you are :D
<teepee>
yes, I have some ideas, but the question is what you would like. Best motivation is, if there's a good interest in the topic and it also is at least a little bit of fun
<teepee>
what I mentioned on the mailing list was something like short screen casts for features of OpenSCAD that are not easily visible for everyone
<teepee>
but there's lots of other possibilities for creating any kind of video presentation
<bboett[m]>
sure! well e.g. i did an intro to openscad on this years tuxtage.... but yeah highlighting new stuff would be nice too, and help me as well :D
<bboett[m]>
maybe you can set up a list with those "hidden" features, and i can try to set something up?
<bboett[m]>
(if i understand the feature..)
<teepee>
yep, we can put that into some wiki page
<teepee>
first one that comes to mind is the direct number editing
<teepee>
type a number, e.g. 10, place cursor between 1 and 0, press ALT+CURSORUP / DOWN
<bboett[m]>
:D allready in unkown land :D
<bboett[m]>
ahhhhh yes! like ctr-a ctrl-x in vi?
<teepee>
well, even better just "cube(10);" as it does automatic preview aswell
<bboett[m]>
BTW i don't use the inbuild editor....
<teepee>
that's already another topic, how to do that and use the auto-reload feature
<teepee>
I'm pretty sure there's quite a number of more features that most people don't easily find as they have no menu entries or are not obvious enough without actually knowing it's there
<J22>
is there a short hint why fast CSGÂ is fast ?
<InPhase>
bboett[m]: What's your general background? Programmer? Carpenter? Mathy person or printing hobbyist? It impacts what topics you could consider covering after such a long delay of one year.
<OlivierChafik[m]>
J22: fast-csg uses a different package from CGAL (its 3D CSG engine), which is faster.
<J22>
OlivierChafik[m]: ah thanks
ur5us has quit [Ping timeout: 240 seconds]
<InPhase>
bboett[m]: Well then you could conceivably end up pretty good at OpenSCAD by next FOSDEM. :)
myosotis has joined #openscad
<InPhase>
bboett[m]: Obviously right now people are excited about fast-csg. Although I think function literals, the structural changes this permits, and the rapidly growing library options are an area that would be really good for a presentation to other programmers.
<teepee>
ah, that's a great point
<teepee>
there's a surprising number of people trying to reinvent rounded boxes as it seems not obvious enough to just use one of the libraries
<teepee>
especially with rounded box even included in MCAD - which unfortunately is not well documented
<InPhase>
I'd probably start such a presentation by a few slides going over some major recent changes, and then maybe zero-in on one to cover. Growing library options is sure one that would have a lot of interesting stuff to show, and it can tap into a lot of the recent changes.
<InPhase>
If data = render() makes it in before FOSDEM, that will definitely be an important one to discuss as well, as it's a conceptual shift.
<InPhase>
The fast-csg change is basically one that says design complexity has just gone through the roof, which also means we need to start tapping libraries more to manage this rising complexity.
<InPhase>
So I think it is easy to make a cohesive narrative for a presentation around this concept.
<InPhase>
A good presentation structure tells a story, even if the story is a little contrived. :)
<teepee>
specifically for FOSDEM, my view is that it should not be too detailed and technical
<teepee>
I've seen a number of talk going deep dive into some projects and pretty much always nodded of half way
<teepee>
the ones I really liked did tell an overview story making one curious for looking up details while still staying interesting
<InPhase>
You generally want to pick a few soundbites you want the audience to remember that you want to hammer home. Something like: OpenSCAD is rapidly increasing what it can do. There are interesting new language features that are fun to play with. There are a lot of powerful libraries available building on this.
<InPhase>
Then you dazzle them with compeling examples, and bring them back to your take home messages.
<teepee>
yep, now the challenging part is actually doing that :)
<teepee>
but that's certainly the path to a very nice presentation
<InPhase>
bboett[m]: I'll be around for advice or feedback if you want any later. (It's a cause I believe in.) I've given, let's just say a very large number of presentations, and taught presenting, so please don't feel it's a burden to ask for advice if you want any.
<InPhase>
Basic can mean a variety of things. :) Did you go through the tutorial? As a programmer you might want to go through it at an accelerated pace, but it's a nice overview if there is anything you're missing.