I'd given up on Skeinforge long ago, and been using Slic3r. Unfortunately, the version of Slic3r that comes bundled with Replicator-G doesn't appear to work with Replicator-G, so I'd downloaded the stable version for Linux, and had been using that, standalone (after preprocessing the .stl files through Replicator-G to get the orientation right).
Well, there were some peculiarities in a recent (more complex than usual) build, and the as-distributed Slic3r doesn't do a 3D view, so I decided to build from source and get that OpenGL support.
This involves getting the source from the git repository, which means the very latest experimental version. Anyway: I get that, then do the build, and... it works! And the anomaly is gone!
So then I try to process another, somewhat large part. Doesn't quite work; it needs a parameter or two fiddled. I fiddle the parameters, and:
Attempt to free unreferenced scalar: SV 0x7f983c8c9fc8, Perl interpreter: 0x7f983c019080 at /opt/Slic3r/lib/Slic3r.pm line 116.
Uh... howzat again?
Try again: same thing.
Unfiddle the parameters: same.
Try a smaller, simpler part: same.
It's happened to various people over the years. Related to .stl files that need repair? Process the .stl file through FreeCAD, so no more mesh errors: same crash.
Oh, and installing the new version made the old version (kept in its own directory) cease to function; apparently it updated a bunch of Perl modules into incompatibility or something.
Someone reports that rebooting cures the problem, temporarily. Don't remember what OS he was using. Maybe I'll try it. But what kind of sense does that make, anyway?
Not rebooting for a while yet; got too many things open.
Update: Well, I hadn't figured on rebooting, but...
I re-ran the build script for the older version. That got rid of the errors at startup, but when I tried to change a parameter it got a comprehensive wedgie and took X with it, requiring the old CTRL-ALT-F1 sudo reboot.
Then I re-ran the build script for the latest. Seems it installs its own Perl modules under Perl, rather than keeping to its own install directory, so There Can Be Only One.
Back to the unreferenced scalar. I look at the offending .pm file, and the line in question, and it's clearly an automatic deallocation. Apparently this sort of thing tends to be associated with threads not playing nice with shared data.
Changing all the config profiles back to default fails to solve the problem.
Well, maybe I just have to run it in a VM with some other, more up-to-date distro, like Ubuntu or Mint. Or... perhaps I should try renaming the ~/.Slicer directory, testing the program with a clean configuration, and then copying my tweaked config files back...?
Update 2: Just launched apt-get update; apt-get upgrade on the Mint-KDE VM. Got 480 packages to upgrade. Gonna take a while.
Aaaand... meanwhile, I renamed ~/.Slicer, created a clean one, copied my latest print/filament/printer configs over... and now 'tis working. Apparently something in slicer.ini causes the problem...?
Can't actually test the output just now, because the printer is in the lab, and the lab is closed for the night (what with it being past Tinga's bedtime).
Update 3: W. T. A. F????? Copying my latest fiddled configurations into the new directory causes the crash, even if I don't actually select them. Actual crash-inducer is print/Fiddled-3.ini, which doesn't appear to be doing anything particularly unusual. Delete that file, and all's well again.
And clicking on one of those dotini files in KDE (Debian-wheezy) takes a long time... because it's launching Notepad under WINE????? Maybe I should tell KDE that they're just plain text files.
Update 4: With the earlier version of Slic3r, setting the printer's X and Y offsets to zero gave centered prints. With the latest... Y needs to be set at ½, and X needs to be set to... wait for it... ¾?????
C'mon, guys. Reasonable offset factors are 0, 0.5, and 1, according to the coordinate system in use. In what kind of coordinate system does it make sense to have one axis offset by 75% of full scale?
(Also, the extruder-clearing lines it lays down at the beginning seem to start rather right of where they should, which suggests that an extraneous X-axis offset has crept in. Maybe something in the initial G-code?)
Update 5: On the other hand... when all's fiddled, I can print out a little dingus with a 0.095" (specified, not measured) hole running horizontally, and proceed to tap that hole #4-40, and it comes out feeling reasonably secure. Still have to test for actual durability, but having a tapped widget can save a bunch of assembly hassle. (No, I didn't try CADding the threads; it's a freakin' FDM printer, with nowhere the resolution to do 40 TPI.)
Every so often, I'll see a link to what seems an interesting thread (conversation, whatever) on Twitter, and click through.
If there are more'n a couple tweets involved, sorting them out gets impossible.
Because, y'see, they're presented in something approximating chronological order, but with no indication of "this tweet is a reply to that tweet specifically."
So, a few entries down, there'll be a message that's a reply of sorts, by @andy... that mentions @betty, @chuck, @doris, and @edward... but it's not clear to whose tweet it's a response, let alone which tweet. And, depending on which one it's a response to, @andy may have an important point, or he may just be a jackass.
As the thread is presented, ya just don't know.
Then, too, owing to the basic format, very often a standalone tweet will make sense only to someone who happened to be watching the same TV show at the time; the comment lacks any anchor to the outside world.
So, really brief comments, often without context, with the limited character count commonly chewed up by references to other users.
I guess this is the wave of the future, for people with the attention span of
I believe the term you're looking for is "fire-engine red".
Yer basic red-fire-engine siren is not so much red, more chrome-plated, innit?*
And I find no evidence that classical sirens were in any way red, despite being experts in luring men to their doom, which is after all the subject at hand**.
(Yeah, in today's usage a rotating red or red/blue light is called a "siren" on account of sitting atop a classic police car. But, back in the day, those who drove such cars knew the difference between "lights" and "siren", didn't they?)
* I'd post a link to an image, but Google's image search has had a makeover and now puts things in categories, and I haven't yet figured out how to break out of the categories and just rummage.
** And now that I've chased this curious bit of language, I won't bother examining the substance of the assertion, except to note that my reactions seem to be rather different. Chronotypes may be involved.
Yesterday's Big Outrage Story: a secret cabal of scientists whose work does not support Catatonic Anthropomorphic ManBearPig is secretly funded by Big Carbon!!!!
Well, we all know that Tobacco Science is not to be taken at face value, because the researchers know exactly what outcome the funders want, so there's a strong incentive to come up with a certain kind of result.
Those of us who are paying attention will realize that Government Science has exactly the same problem, only on a larger scale. (Seriously, if you spend a year examining all available evidence and conclude that the sky isn't falling, what do you expect to happen to next year's budget?)
Even without funding issues, ego-driven science, groupthink, and the bandwagon effect can draw many basically honest researchers along a false path for quite some time. N-Rays, anyone? Or everything we've known about nutrition and heart disease the past few decades?
So here's the thing.
If a politician is secretly on the payroll of someone with an agenda contrary to the public interest - a Prohibitionist parties with the bootleggers, say, or a bank regulator's high-flying lifestyle is supported by the megabanks, or the person responsible for creating Internet regulations is in bed with Big Cable - this is a big deal, because that person is in a position to influence public policy directly, significantly, and in secret, and motivations matter.
If, on the other hand, a scientist's motives are off-kilter, there's no need to examine his motives. If he's actually doing science, as opposed to politics, his work may be examined, and repeated; if it's wrong, it will be seen so.
Scientific research is supposed to be repeatable. Scientific theories are supposed to make testable predictions. If the results are repeatable and support the theory, what matter if the scientists are in the camp of an oil baron or of a divinity-school dropout?
And if the theory makes a hodgepodge of contradictory predictions, and the research requires fudging numbers without a coherent explanation? Maybe there's no science going on, at least at the level being publicized.
I just received a half-kilo spool of NinjaFlex (which is rubbery, but it's not 6800 miles long).
Some current & projected projects will call for custom shock mounts and/or other springy squishy tough bits, so this seemed worth a try. Tugging on the free end of the filament suggests that it has the right sort of properties.
It's the real name-brand stuff, not the half-price Russian knockoff, which might be worth checking out, someday, if I end up doing such things in volume. Or, once I have a design nailed down, I could just have someone else fabricate a bunch.
Update: The FlashForge's extruder doesn't like this squishy, hard-to-push stuff. I've downloaded a .stl of a purported fix; now I need to print it in ABS, disassemble the extruder, install the new part (assuming it actually fits), and then have another go at the rubbery goo, and fabricating some nanoNingis therefrom (the first planned rubbery object is actually somewhat triangular, but closer to 6800 microns along each side).
I don't think I'll have time for this today (this being Monday) nor tomorrow; got two consulting projects back in active mode, plus needing to get a provisional patent application together for that de-weaponized guidance system, and I didn't accomplish much over the weekend.
I did learn, in tugging on the filament, that the material is very tough indeed. Have to see how it comes out when printed at 90% infill.