Posts by ssieler 23 publicly visible posts • joined 27 Feb 2014
What if, say, you go to open a file in C and if you don't say what happens when the file doesn't open, then that creates some kind of error condition that gets implicitly called?"
Gee, like in Burroughs ALGOL in 1970?
Their OPEN could be called 3 ways:
If open (....) then
... // your code to do some error handling
Open (...) [error_label]
// implied goto if open fails
Open (...)
// implied abort() if open fails
A least as of late 2022, the StarFive support and knowledge base was abysmal. I have one, and gave up trying to get it setup (in favor of using some other computers that were new and shiny :)
Perhaps that's improved since then?
I like the StarFive, in principal, because it has a decent amount of RAM (8 GB), as opposed to the Asus's 1 GB.
So....why the escape on the apostrophe in the second "WriteLine"?
I don't use C#, thankfully, but C, C++, Lua, ALGOL, Pascal, FORTRAN, APL, BASIC, COBOL, and some others ...
none require escaping an apostrophe *unless* the string is delimited by apostrophes, and this one isn't (it's delimited by double quote marks (")).
And, why the braces? Nothing like making the code harder to read :)
(Braces would be indicated if one is using a language requiring them...apologies if C# does, or (to me) they'd indicate the programmers intention to add more code within them later.)
@Pascal Monett ... nope, I didn't know that. So, now I'm wondering if I should support that in my date recognition code :)
BTW, https://site.uit.no/english/punctuation/dates/ agrees with you.
I've found Australian and German sites that say dash, slash (although incorrectly calling it forward slash), and dot ... no U.S. sites so far :(
Thanks!
There are two things to observe here (in naming updates with yymmdd####)...
1. changing the type from the equivalent of "int32_t" to "uint32_t" would solve the problem for several thousand years.
2. Does everyone understand that by reserving four digits for an update counter *within a day*, Microsoft effectively said "our software is sooooo bad, we might actually have to post a thousand or more updates *in a single day*"? Sheesh! :)
One aspect of "right to repair" is the fight against the FUD many manufacturers are spreading about "counterfeit parts". Their argument (particularly to the government, and banks) is something like "what if you got a counterfeit part from a third party maintenance company, and that part has firmware to report to China?". Their underlying motivation isn't patriotic: it's greed, pure and simple.
A major concern is that if they get a toehold into the government (e.g., a rule for government purchases: no used or third-party parts), that banks will scramble to fall in line, then other major companies, and then our freedom of choice is gone.
Re:
"If every OEM today did that as they did in the 1960s – published detailed service manuals, made replacement parts readily available, pasted schematics on the back of their products, etc. – nobody would be clamouring for a right to repair, because it wouldn't be necessary," says Paul Roberts, founder of SecuRepairs.org
While I strongly agree with the "right to repair" (and, my company was/is a member of the first industry organization to push this right in the U.S. Congress), I think I understand one aspect of the economics that got us to this point. In Paul's 1960s (above), manufacturers made a *MUCH HIGHER* profit margin, and didn't need to depend on repair/support costs as much. With increased competition and, yes, our eagerness to pay less and less for cheaper products, the profit margin has shrunk dramatically ... to the point where many companies feel the need (or the greed) to try to profit off being exclusively able to service their products.
When I started out programming, our mainframe's operating system was always released *with source code*, allowing us to fix problems (and make enhancements) (both of which we'd send to Burroughs to share with them and other users). The good old days :)
Not a new practice, I think. We got screwed out of a commission on a system sale many years ago.
HP was trying to get companies to buy the PA-RISC version of the HP 3000, and offered a 10% commission
on the total sale to any outside software vendor whose product was (a) purchased at the same time,
(b) cost $10,000 or more, and (c) the customer certified it was critical to the purchase.
So, we priced our compiler (the *ONLY* third-party compiler at the time, and still the only
one that compiles "SPL" to PA-RISC (or to C)) at $10,000. We had a software development company
purchase a 3000/930 (?) strictly for developing PA-RISC products, and they needed and bought
our compiler ... and wrote us the certification it was critical.
HP stiffed us.
(We were used to that ... got stiffed by DEC once, too, in a different manner :)
Re: " Probably MPE played a role, as I know at least a couple of companies that were still using it not too long ago.".
Thousands of HP 3000s are happily running today (PA-RISC, and probably under a dozen Classics).
One that I know of has one thousand users logon every day (i.e., at any give time during a normal work day, there are 1,000 logged in users) ... and that computer was probably made about 20 years ago!
IIRC, a very preliminary port of MPE/iX from PA-RISC to Itanium had been running in the lab,
and might even have been announced at the 2001 Interex conference, just before MPE was cancelled.
Stan
About 10 years ago, we were using a third-party (European) mail filter service ... a friend in Guatemala tried to send me a one line email, something like:
stan, see this statue of liberty replica in Colmar, France: <some url>
...and it got rejected.
We traced it down and found that the mail filter service rejected it because of the word 'replica' ... they'd been seeing tens of thousands of spam emails trying to sell "replica rolex" and other "replica" watches ... and they went way, way overboard.
We dropped them and started managing our own mail after that!
Yes, Burroughs ALGOL supported call-by-name (and call-by-value and call-by-reference).
The "thunks" weren't interpreted...they were real machine code ... but the accompanying cost of (effectively) a procedure call/procedure exit made such code relatively expensive, probably why the compiler writer(s) drew attention to it for you.
I learned Burroughs ALGOL in 1970, on a B6500 (which became a B6700 shortly thereafter) ...
absolutely wonderful language. It had features we still lack in "modern" languages ... much of what Burroughs invented (and, later, HP with the HP 3000) is now lost, sadly.
HP3000 APL was wonderful, it even had a keyword version (if you lacked an HP2641)
It was, however, the slowest APL I've ever seen.
Allegedly, HP kept it alive until a lawsuit over its unsuitability was closed, then they dropped it.
I'd love to get an HP2641 terminal!
If anyone is interested in getting HP3000 APL up and running on the Classic 3000 simulator, let me know. I'm easily findable.
Re: AS/400 "still kicking". I've always liked the AS/400, as well as the HP 3000.
Although not being made any more, the HP 3000 (er, "HP e3000") is still running in thousands of sites. Stromasys has an emulator for it, so it might outlast the original PA-RISC hardware :)
We have one customer who has over 2,000 sessions logged into their HP 3000 every day ...
not bad for 16 year old hardware!
It's a plausible weight-loss. Over the short term, water loss can account for a lot of that.
However, with a medically supervised [and mostly liquid] diet, it's not surprising to lose
1/2 lb per day for long periods of time (e.g., I've seen a friend go from 300+ to 150 in one year, just on the HMR medically supervised diet).
Back to watches ... the roundup sure missed a lot of smart watches, unfortunately.
I'd like to see info about Android-running watches (not merely watches that *talk to* Android systems) ... since I've had DOS and Palm watches, I'm a long-time believer in wearing a watch I can write code for :)
Also missing: Kreyos, and Buddy Bluetooth watch (I've tried both, not greatly impressed by either)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
