|
I remember thinking of Python as this promised land when I was dealing with Perl 5 scripts around ASIC collaterals. They're never the product that you're actually shipping, just some shim garbage to make one tool's output fit into another tool's schema. I forwarded a script we used to make sense of this giant tree of muxes and the engineer sent back this giant screed blasting our entire team about how they'd never ship something that emitted so many warnings on success and welp ¯\_(ツ)_/¯ I wouldn't write it that way either, but I'm not itching to re-solve this problem for the sake of my terminal. It didn't even print a bell character. Now I'm writing a BLE test suite. In bash
|
# ? Feb 4, 2016 19:12 |
|
|
# ? Apr 23, 2024 08:02 |
TCL is also used in X-ray astronomy!
|
|
# ? Feb 4, 2016 19:35 |
|
VikingofRock posted:TCL is also used in X-ray astronomy! my job in 1995 they had just released the trading floor software for the Irish Stock Exchange - Written in TCL/TK with DBase Backend
|
# ? Feb 4, 2016 20:23 |
|
Around here, most projects using tcl/tk for their gui have been replaced with Qt implementations, but all systems still need the packages installed because it occasionally shows up in a dependency of the software they're developing (ironically, a dozen or so .tcl files show up in Qt's source distribution). Back in the day though? Man, tk was THE thing to be using. "You mean I can make a gui with something that looks sort of like a shell script? And I can call actual shell scripts inside it? Well of course I want to use that! In fact we'll build an entire infrastructure around it, it'll be the perfect frontend for the tens of millions of dollars worth of scientific equipment we manage!"
|
# ? Feb 4, 2016 20:51 |
|
ExcessBLarg! posted:Die? Not really sure how that works. None of the "plangs" are actually dead, Perl 5, Python, Ruby, and PHP are all very much around. As much as I would probably like to see PHP go away, it's so widely used it probably never will. Tcl might be dead. Programming languages never die, they just run in/on javascript.
|
# ? Feb 5, 2016 00:14 |
|
Ender.uNF posted:Programming languages never die, they just run in/on javascript. And it's not even the only one: quote:There are several other implementations of Tcl in Javascript ...
|
# ? Feb 5, 2016 01:03 |
|
I have a colleague down the hall that daily works with FORTRAN, it's still has a good niche in HPC-land. An ex-colleague moved to work on a startup doing COBOL code analysis. And I still love to work in Lisp languages. Yep, languages that had seen some use will keep sticking around long after we're not.
|
# ? Feb 5, 2016 13:29 |
|
Clojure exists. Lisp is far from dead.
|
# ? Feb 5, 2016 14:48 |
|
Beef posted:I have a colleague down the hall that daily works with FORTRAN, it's still has a good niche in HPC-land. The German Meteorological Service 's main weather models are written in FORTRAN with a nice sprinkling of ksh, running on a CRAY XC40. Pollyanna posted:Clojure exists. Lisp is far from dead. Racket seems to be a semi-popular learning language as well.
|
# ? Feb 5, 2016 15:41 |
|
There are people in other departments at work that work primarily in PL/X
|
# ? Feb 5, 2016 16:12 |
|
code:
|
# ? Feb 5, 2016 17:48 |
|
Hollow Talk posted:
It's not a bad scripting language either.
|
# ? Feb 5, 2016 18:10 |
|
carry on then posted:There are people in other departments at work that work primarily in PL/X I used to be one of them! It's honestly a pretty good alternative to C
|
# ? Feb 5, 2016 21:01 |
|
Dessert Rose posted:It's not a bad scripting language either. I technically agree. However, the problem with command-line arguments (which is probably more in line with this thread) is that all parameters are always strings. Cue atrocities like this: code:
edit: This didn't need to be a macro, but I didn't know whether I'd need some syntax modifiers, hence the superfluous syntax-rules. Hollow Talk fucked around with this message at 21:59 on Feb 5, 2016 |
# ? Feb 5, 2016 21:55 |
|
carry on then posted:There are people in other departments at work that work primarily in PL/X Most of current zOS, IMS, DB2 and other IBM Mainframe stuff is written in PL/X. Actually, the PL/X source is THE definite documentation for some obscure control blocks in Mainframeland. Gul Banana posted:I used to be one of them! It's honestly a pretty good alternative to C In an alternate Universe, people writes systems stuff in BLISS and PL/S, and the curly-brace based languages are a joke among drunken old farts talking about ye olde times. Amberskin fucked around with this message at 23:04 on Feb 5, 2016 |
# ? Feb 5, 2016 23:02 |
|
This hasn't become code yet, but...Slide 1 posted:- Two asynchronous CPUs Slide 2 posted:- Proprietary extension to ABP bus allows hardware peripherals to behave differently depending on CPU/DMA/debug
|
# ? Feb 8, 2016 12:22 |
|
C code:
|
# ? Feb 8, 2016 12:35 |
|
qntm posted:
So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators)
|
# ? Feb 8, 2016 19:45 |
|
code:
|
# ? Feb 8, 2016 20:40 |
|
code:
|
# ? Feb 8, 2016 20:43 |
|
Xarn posted:So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators) Yeah, can you give an example of a call site? It's baffling.
|
# ? Feb 8, 2016 20:49 |
|
Xarn posted:So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators) I thought for initialising the elements in an array, rather than a function call maybe? Horrid, in any case.
|
# ? Feb 8, 2016 20:50 |
|
Xarn posted:So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators) My guess would be something like: C code:
|
# ? Feb 8, 2016 21:42 |
|
Cuntpunch posted:
I keep thinking I should write a code analysis rule to find unit tests with no asserts, or asserts that are like Assert.IsTrue(true)
|
# ? Feb 8, 2016 22:03 |
|
eth0.n posted:My guess would be something like: That doesn't work with the parens though.
|
# ? Feb 8, 2016 23:30 |
|
I'm working with a 3D modeling plugin API that has a hook called BeginSaveDocument and another called EndSaveDocument. There's no detailed documentation, but that seems pretty straightforward, right? One fires right before a document is saved, and one fires right after. But something wasn't working. In my EndSaveDocument handler code, if the document had never been saved before, it wasn't present at the place it should be. It wasn't a race condition; I could hang my handler execution forever with the debugger, and the file would only appear after it had completed. EndSaveDocument seemed to be firing before the save. So I post on the developer forums, saying I think I found a bug. I included a little test case. "Nope," was the official response. "It works correctly, I just checked the code. It fires after the save. I don't know why you think otherwise." I figured it out several months later, browsing another thread on their forums. You see, when the program saves, it saves to a temporary file first, and then moves the file to the requested save location, presumably to avoid clobbering old data if there's a problem. This is all well and good. And it turns out EndSaveDocument does fire after the save! But it fires before the file is moved to the correct location. And there's no way to get the temp file location. The officially-recommended workaround is to watch the filesystem on a separate thread.
|
# ? Feb 8, 2016 23:34 |
|
Subjunctive posted:That doesn't work with the parens though. There aren't parens around the commas.
|
# ? Feb 8, 2016 23:38 |
|
Plorkyeran posted:There aren't parens around the commas. Oh, quite right!
|
# ? Feb 8, 2016 23:42 |
|
Cuntpunch posted:
We have a rule that every bug fix must include a unit test for a regression on the fix. If someone committed something that caused the default constructor to throw an exception, this would be a reasonable test (not great, but reasonable) test for such a regression. I would worry, though, about a smart compiler skipping the unused constructor call though. Most assertions would look pretty stupid though: target is not null, target.tostring returns a string, etc. and don't make it clear what you're actually testing.
|
# ? Feb 9, 2016 04:29 |
|
KernelSlanders posted:We have a rule that every bug fix must include a unit test for a regression on the fix. If someone committed something that caused the default constructor to throw an exception, this would be a reasonable test (not great, but reasonable) test for such a regression. I would worry, though, about a smart compiler skipping the unused constructor call though. Most assertions would look pretty stupid though: target is not null, target.tostring returns a string, etc. and don't make it clear what you're actually testing. Yeah, but that's what comments are for. Tests like that are spurious when its purpose isn't documented, but you're right that they can be justified. One nice thing is that some testing frameworks have blackbox(T) functions that are meant to trick the compiler into not ignoring a value for reasons like the optimization concern you mentioned.
|
# ? Feb 9, 2016 04:33 |
|
Ithaqua posted:I keep thinking I should write a code analysis rule to find unit tests with no asserts, or asserts that are like Assert.IsTrue(true)
|
# ? Feb 9, 2016 10:55 |
|
KernelSlanders posted:We have a rule that every bug fix must include a unit test for a regression on the fix. If someone committed something that caused the default constructor to throw an exception, this would be a reasonable test (not great, but reasonable) test for such a regression. I would worry, though, about a smart compiler skipping the unused constructor call though. Most assertions would look pretty stupid though: target is not null, target.tostring returns a string, etc. and don't make it clear what you're actually testing. Am I missing something obvious? Because let's say you do have a default ctor that blows up loudly. Doesn't that tend to result in an exception being thrown. And since the test isn't try/catching, even if you did: code:
|
# ? Feb 9, 2016 14:03 |
|
Xarn posted:So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators) The real horror is a missing set of parens around a.
|
# ? Feb 9, 2016 15:50 |
|
I like writing custom assertion helpers, then unit testing those, because I get to write:code:
|
# ? Feb 9, 2016 16:03 |
|
Cuntpunch posted:Am I missing something obvious? Because let's say you do have a default ctor that blows up loudly. Doesn't that tend to result in an exception being thrown. And since the test isn't try/catching, even if you did: A failure because of an uncaught exception is still a failure. Having the assert there is not needed, true, but having it there makes the intention of the test clearer.
|
# ? Feb 9, 2016 16:16 |
|
KaneTW posted:The real horror is a missing set of parens around a. Also, a gets computed 3 or 4 times. Fun with macros.
|
# ? Feb 9, 2016 16:19 |
|
My favorite test I've seen was called AlwaysPassesTest()
|
# ? Feb 9, 2016 16:24 |
|
Xarn posted:So, what is the function call this was made to simplify? (I refuse to believe they mean for it to expand so that the commas are operators) C code:
|
# ? Feb 9, 2016 16:43 |
|
HardDisk posted:Having the assert there is not needed, true, but having it there makes the intention of the test clearer. Really? That just makes me think that the writer thinks constructors can return null.
|
# ? Feb 9, 2016 16:48 |
|
|
# ? Apr 23, 2024 08:02 |
|
HardDisk posted:A failure because of an uncaught exception is still a failure. Having the assert there is not needed, true, but having it there makes the intention of the test clearer. Isn't that better served by naming the test appropriately and/or leaving a comment saying "make sure we don't throw an exception"?
|
# ? Feb 9, 2016 17:09 |