Science/Engineering/Technical forums

It's a classic book in comp sci. O'Reilly tended to pick interesting and somehow peripherally relevant animal pictures for covers. Figuring out the relevance was an interesting pursuit back then.
It's been said that a camel is a horse designed by a committee, a slur on committees. But it's also said that a camel is a highly efficient machine for its function and not merely a misshapen horse.

The author of the prior statement was simply not aware of the conditions a camel is best suited for - a desert.

Which was the state of a certain class of "just get it done without wasting programmer time" software support was - there was shell (later bash)...and hard to put together C (fortran and JCL/Cobol in one world), which is not that great for "just get me the answer" kinds of work - scripting, so there was a desert in the programming space. Either bash or C can do most of what perl can, with extra libraries in either case, and a lot more work and complexity on the part of the coder. Some people think newer scripting languages are in some way better or at least prettier, things like Python being the current fad.

All of them are simply incomplete copies of perl's basic design...Things that offended the author(s) of the newer languages were left out. There is legitimate controversy over per'ls TMTOWTDI (there's more than one way to do it) and other philosophies expressed in the design, and many find perl code hard to read when they are brought in to modify it.

This is in part because perl was the first general purpose language to support regular expressions as a built in - and those can give anyone a headache. They are now built in to almost all scripting languages, and available to compiled ones - but hmmm...no one points that out. There being more than one way to do it does allow overly-clever people to write tricksy code no one else can understand - there was even a perl poetry contest at one time - and perl would do what the poem was about (sort of). But those people are just bad programmers seeking sinecure job security, and that more than one way to do it feature can be used to make code very clear and easy to understand as well - rather than barring the entrance, and holding a shotgun on you, perl just expects you'll stay out of the place unless asked in. (hopefully my perl, often uploaded here and on my github, makes this obvious) Other languages try to enforce tight rules their authors and fans say eliminate programming errors. History has shown this is baloney - bad programmers can be bad in any language, and there is simply no way a tool can be created that's powerful and idiot proof simultaneously, and convenience tends to go out the window faster than steel rusts in salt spray. (Some will see what I did there).

It is of course, possible to take that idea too far and fail to have a big picture and plan - I give you PHP, a fractal of bad design, which is often misused to do big things, even code big websites with bulletin boards (like this one. The link above is a hilarious read for those into the topic). Of course, holy wars in software are more or less the norm, often partly justified, more damaging than needed, and unfair, just like any other holy war. On the other hand, they can be entertaining especially if one "was there", knows the context, and realizes the kids fighting just don't really have a clue about the shape of the landscape, or a realization of how little there was to work with then - we were still writing text editors and report generators! No one knew what this was all going to evolve into. A few early language designs made it to success and wide use, most didn't, and hindsight is a lot easier to get right.

An unobstructed view of the original mangy animal for those who haven't seen it. At one time it was hard to find anyone in the biz that hadn't read it, and most owned a copy.

Perl is still my favorite language to beat out something quick and dirty that gets the job done. Such as add leading zeros to a traffic log, because the new version of the radio automation system demands it, even though it did not care before.

Yeah, it's my go-to default when I don't need C these days. Coming from assembly and then C, the text munging facilities in perl just blew me away. I admit that the first time I added a textual 1 to a numeric 1999 and got a float 2000 I wanted to go wash my hands...but I got used to it. For tweaky math stuff it's not as great, but there's always C..

I've probably pushed it further than most do. I use it for the P in LEMP stack, even on raspberrry pies, pretty much all glue stuff, daemons that tie my LAN of things together with CGIs and a database, and even some small gui programs, like the one I use to control fusor1 and collect data. I use a LEMP stack here - the E stands for the pronunciation of NGINX, which I prefer over Apache for small local things.

FWIW, initially setting it up to do GUIs in linux was a major pain, which I have a salve for up on github. There are some odd and hard to put in dependencies (of dependencies of...loop) - so I did a script to put them in, and created some boilerplate to get you to hello world with no work...and the rest is easy. Humans are slower than perl on a pi model A anyway...I use Glade to lay them out.
This is finally as good or better than MS DevStudio 6 was for such things - fast and efficient for the programmer and the machine both.

My "4d" plotting program lets you type little perl programs into edit boxes to map from the database data to the axes any way you want. Can't do that with python without full blown multiline edit boxes and complex handling...or of course, any compiled language, really. These mapping routines are placed in hashes and saved as named presets for later runs.
All pretty painless to implement using Storable from CPAN.

I frankly couldn't think of any other reasonable way to do that and have the utter flexibility of being able to eval code from the user point by point.
Obviously this isn't something you'd let the world type arbitrary code into, but that's not the use-case.
It's not blindingly fast, but it's quick enough,taking perhaps a whole second to generate a plot from a 10 minute fusor run - or keep up in real time. All plotting here is from the database, so in real time it acts as a check of whether I'm putting in the new stuff at all and correctly. As an aside, the database server (MySQL), for EMI-safety, is running elsewhere on the network, on an Odroid HC2 arm machine that has a big disk on it. I'm using a pretty old 4th gen intel i5 NUC and a raspberry pi b for the other things, along with some arduino unos controlled by the pi to do realtime data aq and control. Nothing that super slick is needed, and it's all loafing load-wise.

I've found that if you are careful with variable scoping, you can avoid invoking the memory garbage collection at inconvenient times and satisfy many real time requirements for the lower speeds, unlike other languages (Java...) that just go off on demented errands of their own and break things.

I use the Inline:: modules from CPAN in reuse things like python code from Adafruit to deal with oddball hardware sensors. While both python and perl do "duck typing" - they vary in the details and if you want some odd bittness or endian calibration math for a sensor to work right - you can choose the immense pain of going from scratch or...just grab up some python and put it inline.
The only downside I've run into (other than confusing the syntax highlighting in editors) is that most of this kiddie python is badly written and will often do a microsleep rather than check for ready.
It runs FASTER in perl (as it's compiled by Inline::Python) and will sometimes have errors due to that.
There is also Inline::C for when you need to crunch a lot of math, but with any inline, it's slow doing it for one number at a time. There's still pure C needed here and there - but less and less.

I do C++ but eschew some of the fancier later stuff, like template libraries, too much bloat and too much finicky syntax for me. Damian Conway demonstrated in a talk that the C++ templating system is Turing-complete and can do sorting during a compilation that generates no code! That's just too out there for my taste.
Here's Damian's demo, part of a talk about perl 6 - which is a great talk, hilarious, Damian is our mad scientist (Larry is the nutty professor) - but perl6 isn't my favorite either.
https://youtu.be/Nq2HkAYbG5o?t=833 Epic.

The glueness is hard to beat - between your stuff, other big chunks like databases, plot programs, opsys or servers, networking ... it's a long list of things it seems to excel at.
The stability (we're talking perl 5.x here) is a great feature - stuff I wrote many years ago - no breakage. And CPAN...it's probably already been written. I like the approach there compared to
these enormous namespace killing libraries I see for other languages - I like the ala carte. It's easier to find what I need, maybe that's just me, but I like it.


/////
Sigh, it's always something. Fusor2's forepump doesn't like to restart after sitting all night - it runs but it doesn't pump. So that system outgasses/leaks up to around 1 mbar overnight, but then to get it to pump down again, you need to let gas in to make the little flapper valve "aquarium" forepump get going so the turbo can spin up. I've rebuilt it once, and can probably do it again, but where it is now (and the pump station is holding the rest up from beneath the table) - it makes putting a new 8 track in an old corvette with good speakers look like a fun job (I actually did this as a young guy when I could contort up inside the dash of such things...). I'm hoping this time if I run it in the day (when there's solar) it will run back in...I don't need super purity for starters just now, but gheesh.
I think if I take it that far apart again I'll add a valve to let air leak into the foreline, which already has a solenoid valve I added long ago to block it from the turbo outlet. That's my system to control gas removal in my batch runs - I just leave that valve closed until some gas needs to come out, then pulse it open. This is a nice trick to prevent back leakage when in standby or shutdown too.
I have the forepump controlled by the turbo power use, so most of the time it doesn't run, saving money, power, lifetime. When it's running, I automatically open that valve. That's working great on both setups. I find this is a lot easier to control than trying to balance an inlet leak with a pumping out leak - integrators always drift...I just pulse one valve to let gas in, another to let it back out.

Interesting. Now, is noticing this some kind of cognitive bias, and they were always around, or some sort of resonance in the universe made these happen, since a lot of people have a picture in their head? No opinion, but this is pretty odd. I saw this while weeding out some poison ivy...the oak trees are infected with something that looks like Covid...(some insect cocoon?). I suppose some of the more panicky among humans would mount up and run off in all directions?

Shop coming back online as weather permits. We're getting leak tested by the planet just now - a tropical storm is dumping a few inches a day of rain on us. At least there's plenty of clean water. This stainless steel cabinet was sitting at the dumpster (the redneck recycling center). I picked it up, didn't have a use for it right away, tried to give it away, failed, and well, now it's about to be in use. I have a stock of some fairly nasty chemicals, and some of those would be better off stored outside...and well as perhaps a couple of maintenance items for the generators and so on. So...reducing entropy a little bit seems a good thing. It doesn't leak when rained on, but would leak things like strong acids out onto the ground if there was a containment problem. That's nicer than eating my shop or even starting a fire.

Doug, did you cut one of the alien growths open to find out if it's a cocoon or a gall of some sort? I surely haven't seen anything like that except in sci-fi flicks...

Nope, it's rained hard and almost continuously since that first pic.
But I just went out (it's 8:30pm here) and took another look.
Something is killing what was a really fast growing oak tree, I took more pix but it's getting dark, still raining, I should be able to do better tomorrow as the storm is ending.
Here's one though. Note the droopy leaves (no other tree here is doing that), the other dark brown growths higher up, and the suddenly bare top - you might have pegged it with that alien remark...
Something odd is happening there. I think if I do cut it up - note the things haven't noticeably changed at all - I'll wear some protective gear!

More tomorrow, till then, here's a pic from just now, cropped a little so it shows the part of interest larger. Worked all day blueprinting a Mauser action for the benchrest swede version. Made some cool tools to get it all flat and straight down to a few atoms. The Czechs do this well (it's a postwar action, better metallurgy and workmanship than the war ones), but they don't have time to make it perfect. More on that when there's more. This one gets one of the high dollar barrels.

I have a buddy that lives a bit north of you, but his knowledge of plants and their problems might help some. I'll ask him.

Some searching turns up:
this
Wow...that leads here: https://www.seashoretoforestfloor.com/wool-sower-gall/
And here: http://webiocosm.net/webiocosm_zoo/wool ... llwasp.htm
Which don't quite get to the brown (older?) growths in this picture but may all be the same cause. We've also had a crazy infestation of some kind of white feathery fungus that is trying to eat my buildings from beneath, and I'm still fighting that after a couple years.
I may need to rent one of those expensive foggers and some expensive chemicals to kill it off - it's everywhere, anywhere there's a bit of moisture, outdoors too - if a couple boards
are leaned on a wall under a porch roof - it's growing between them even though they never get actually wet - humidity is enough. At first I thought this might be another manifestation
of that, but apparently not. It eats treated wood just as easily as the regular stuff.

The upside of the more rain we've been getting for a couple of years now is that I have plenty of water... Which likely means someone else now has less.
At least now that I know what this is, I don't think I have to worry about it attacking me, or likely my huge beautiful oaks.
##########//////////////////////////////////////////////
Without getting into nearly all of the arguments around "climate change" - an issue that's mostly ignored is one I think is important - and cause doesn't matter at all.

We've built a world where everything that isn't a farm is a city or town. The remainder is considered worthless, more or less, which is for example, why I was able to afford this place in the mountains - it's hard to farm too steep for cropping, only a few cattle are raised - and it's impossible to "develop" in the normal city-suburb way - it's insanely expensive to just have some roads in this terrain.
I like this place myself, but obviously if the world were like this, there'd be a lot fewer people on it. I made it work for me by creating and shipping out "intellectual property" and having things like food and fuel brought to me in exchange - which is difficult and expensive due to the mountains, but possible. All we have is abundant natural beauty, but it's hard to get to, and not showy like
a Hawaii or other tourist destination.


Now, as climate changes (again, cause immaterial - we could do a thread where the ridiculous arguments on all sides are taken out back and shot - but not this one.) - let's look at what happens if the good places to grow food MOVE. Uh oh - our setup doesn't let you just move the farm to the new good place, not hardly - the farmer owns this land, not some other, and now there's a city and/or public works where the crops want to be.

Similar is if things get bad for cities - water, heat - they're a little better off if they don't starve, as all that happens is the costs go up (A/C, water, food may cost more due to the above) - you only kill the poor in that case (yes, I'm being sarcastic).

My beautiful climax forest...when where the pests live best moves to here - as I'm seeing - it cannot migrate, trees are kind of slow on their feet. We'e already lost most all of our locust trees due to a pest that kills them moving north.

Our socio-political setup has utter normalcy bias - and almost no flexibility short of violence to adapt to things that were assumed implicitly to never change...like what would be good land use patterns. Just sayin. If deserts flower and once-verdant garden spots die - we have a problem and not just in Houston. Cause again does not matter here, and nope, I don't really have an answer, socio-politics is something I stink at and avoid mostly - I got into sci/tech/computers because as people have said of me "You don't get humans, do you?". That's about the size of it.

The canary chirps...
Super busy here, as my health is coming back - strict regimen but it's paying off - I've been doing a heck of a lot of yard work while the weather is friendly for that, and the exercise is part of the regimen. It appears that spending a large part of each day totally out of breath and feeling like I'm going to collapse is good for me, whoda thunk. Maybe I'll live to fight another day.

Today's tale of woe is about another intel Nuc - the newest one - shitting the bed totally. Out of 5 I've bought, all have failed, this will be the second unrecoverable one - the others have been rejuvenated, and I think I'm done with Intel for good now. I don't really have a spare month+ pay laying around to build another, I'll have to do some scrounging, but it looks like me and AMD are going to get acquainted real soon now...
Something along the lines of a Ryzen 7-3700 with 16 gb of 3200 ddr4 on a b550 mobo with an nvidia RTX 2060 ought to do perhaps. A big leap in power consumption, hopefully manageable when at idle, but a huge leap in performance too, if what I see is how it really is.
The sad thing is - the NVME drive in the NUC is probably fine, and it has a ton of stuff I'd like to recover...but it turns out that my little SSD to USB adapter doesn't do NVME, it only goes up to m.2 sata, so...buy another adapter, or wait for the AMD setup to materialize.

Ah, but in the meantime, timeshift will save my day - I'd put a 2 tb spinning rust drive in that nuc just for that...and I bet it'll have what I want on it, as I set it up to make images pretty often. We'll see, this is a fresh disaster.
I'm now surfing on a raspberry pi 4 (at least it's a 4) as my main squeeze non-specialized box. It's missing quite a lot of functionality, for example, it seems to not be able to see this camera, it can't really power all the usb peripherals I have...I have basic browsing and remote VNC viewing going at least. But it's set me back a good bit, and there are a few holes in what software you can get for arm machines.

I'm posting this on a backup of the backup hardware machine in the "wrong building"...it's not really set up either, but it's a "real" computer, which can see the camera so I can even do this. If it looks like a long time to a new main squeeze system coming up, then, well, I guess I can move this one and fly without a net for a bit. Or maybe a lot of bits if I can recover the coding projects from the dead one (likely, it's just a lot of work).

Of course, I found this out when I came to post some progress on a little bit of a side fun project. I'm building a really nice data aq and control setup for the new ion trap/fusor2, and it's going to have a ton of BNC connectors on its front panel. Of course, the ones I could get are those screw in ones that really want a flatted hole, else they unscrew on the first use, no matter what thread locker you use, it's just not up to that.
So, I tried making a flat out punch - not so good, and it won't be shown here - the real issue is the matching die - same problem as making those holes in the first place, but in hard steel!

Based on clickspring's little square hole project, I decided to try making a broach instead. Ok, my first go is ugly, I wasn't paying attention to making all the teeth even length, I was dealing with a grooving tool that broke, and then another that broke, then...new tools from China, then...hey, it works. And I've learned a couple of things that will let me make the next one a lot closer to perfect. For one thing, get some good steel stock, not
some mystery iron that seems like it's 1018. Too gummy to cut well, grabs and breaks grooving tools, and too soft to make the number of holes I want in the expensive brushed and anodized aluminum panel I have.
So, going down the rabbit hole and also somewhat inspired by Clickspring and Elemental Maker - I built a little heat treat oven - mostly making a burner, and a stand for a pile of really nice silica foam bricks Bill brought over one day. And it works. I put the broach in a little SS pipe, with charcoal, Casenit, and borax...and now it's file-hard on the surface. Yes, it's ugly, laugh all you want, but it is enough to do the job, and I learned how to do it right for next time - and I will, this is an issue that comes up around here, and this is glorious compared to getting out a file - I have around 20 to do on this one panel...that's a lot of voopa-voopa dwarf tink-tink role playing.

So here are a few shots of that stuff - I'll make a real post somewhere in machining when I have my computer infra back online - that's higher priority just now, but I'm not dead, in fact I'm becoming less dead, and
there's fun happening - my mantra. More after I recover my trick script that shrinks jpeg file sizes without ruining the picture quality too horribly. This is good. I found out I don't need to make the teeth anywhere near this long, and in fact, a too long broach is harder to use with my short stroke hydraulic press.


This deserves another post by me - EM's works great, but I wanted something a bit smaller and of course, built out of my scrap box. I used a .035" MIG tip (brazed into a bit of gas-supply pipe) for the propane orifice instead of his 60 mil hole, and some SS pipe I made air holes in etc. I'll detail it later on, it's the same idea as his, just lower output - my need is less and those good firebricks make the required input less as well. It's still pretty brutal.

Tweet.
Why guess? You know the rest...
Happy birthday mill and lathe. Can't really justify getting and learning CNC stuff, but this helps the human get it right.