in reply to Re: "Magic tools" that take the fun away (Releng/DevOps/Cloud/Virtualization/Container/Server References)
in thread "Magic tools" that take the fun away

I regret that I don't agree with you about make. I've made modest contributions to EUMM, so I know a bit about generating Makefiles. But make isn't really about macros etc; it's about dependencies, and only building what you need to (and concurrently at that where the dependencies permit). I think it's really, really good.

Before you mention it, so-called recursive make is indeed bad, but when I finish updating it, Make will treat cd $DIR; make as an oddly-spelled include, so it will have the whole dependency graph available to it, allowing full proper parallel builds. Until then, when developing PDL (with its literally 99 Makefiles in its tree) I rely on the parallel-build coretest job I constructed, ironically avoiding recursive make using recursive functional code.

And system configuration isn't, in my mind, supposed to be fun, but incredibly solid and reliable. My feeling about the described Ansible setup is that it needs a bit of refactoring, since Ansible is supposed to be possible to scale.

  • Comment on Re^2: "Magic tools" that take the fun away (Releng/DevOps/Cloud/Virtualization/Container/Server References)
  • Select or Download Code

Replies are listed 'Best First'.
Re^3: "Magic tools" that take the fun away (Releng/DevOps/Cloud/Virtualization/Container/Server References)
by NERDVANA (Priest) on Jun 18, 2024 at 01:51 UTC
    Make is a good build algorithm, but a clunky scripting language. I'd much rather have a Make library for perl and then let a perl script assemble all the dependencies into some object and then execute it with a method call. I repeated this experience with OpenSCAD. I loved it at first, but then gradually got annoyed about the way it implements conditional statements (i.e. functional programming) and lacks macros or named anchors on the model, and now I really wish that I had a CAD library for Perl where I could just code up the missing bits myself right in the 3D model.

    Domain-specific languages are great at solving domain-specific problems... until you want to do something that the author didn't plan for.

[reply]
      ...now I really wish that I had a CAD library for Perl where I could just code up the missing bits myself right in the 3D model.
      Can I interest you in PDL::Graphics::TriD and PDL::IO::STL? Only one careful owner :-)

      Also I gather haj is doing some CAD-like stuff at the moment.

[reply]
        My grand plan was to finish Alien::OpenCASCADE and then build a companion module for Math::3Space that makes it easy to specify triangle meshes and uses OpenCASCADE to perform solid modeling operations on them (union/difference/intersection) in the style of OpenSCAD, but procedural with objects. Then, combine those two with OpenGL::Sandbox to view it. (I considered using OpenSCAD's underlying C libraries, but read that they were quite a bit less performant than OpenCASCADE)

        I haven't finished reading your PDL version of Math::3Space, but my first impression so far is that I'd like to make my modules PDL-aware so that they can read and write to ndarrays (like created by your trigrid3d or loaded from STL), and then for parallel processing just make new modules in the PDL namespace that perform these same operations the PDL-way.

[reply]
Re^3: "Magic tools" that take the fun away (Releng/DevOps/Cloud/Virtualization/Container/Server References)
by jeffenstein (Hermit) on Jun 17, 2024 at 17:30 UTC
    ... since Ansible is supposed to be possible to scale.

    In my experience, this isn't the case. Ansible isn't agent-based, so a process is always blocked until the remote system completes its work.

    Ansible is easy to use for a lot of cases, and easy to implement, but not scalable to tens or hundreds of systems. :(

[reply]

In Section Meditations