WTF Bites
-
@BernieTheBernie said in WTF Bites:
By the way, how did you guess we are using Lua 5.2… oh, right, the other versions have shifts done differently. Because
. Lua is one huge pile of .
-
… when Python broke compatibility from 2 to 3, it took over 10 years to port most of the world and some wounds are still not healed. When Perl tried to break compatibility with 6, nobody bothered, but that might have been because they let the dog and the cat cook it. But Lua is breaking compatibility with every damn minor version.
Filed under:
-
how did you guess we are using Lua 5.2
Just asked Google. I do not know Lua. Are there newer versions? Like Python 2 still used more often than Python3, despite the latter being more than 10 years old already?
-
@BernieTheBernie doesn't matter with what they're planning for Python 10 next year.
-
@BernieTheBernie said in WTF Bites:
Just asked Google. I do not know Lua. Are there newer versions?
Yes, 5.3 and 5.4.
@BernieTheBernie said in WTF Bites:
Like Python 2 still used more often than Python3, despite the latter being more than 10 years old already?
Not any more. It's already removed from a lot of systems now that it is officially out of support. A bunch of no longer maintained libraries was kicked out of Debian archives with it too.
-
To be fair, by “normalize” they “only” mean to make it look normal by comparing it to leaks from other companies, not make sure it happens regularly.
And there I was hoping it was to calculate a mean level of catastrophic data breaches per user per day. Oh well…
-
@Gribnit Neither, of course. Lua is a
.Specifically, it appears to be Lua-ese for
!=in many other languages.
-
@dkf those sick monsters. is at at least actually a bitwise xor?
-
@BernieTheBernie said in WTF Bites:
Like Python 2 still used more often than Python3
That's changed a lot over the past couple of years due to the rug being pulled out from under the Py2 package ecosystem.
If you don't use division, it's pretty easy to use
sixto bridge things over. If you do use/for integer division, you're going to be fucked up the ass and good luck hunting down all the places where trouble lurks.
-
-
@dkf why would I leave my ITE?
-
@dkf those sick monsters. is at at least actually a bitwise xor?
A bitwise xor of floating point numbers in unspecified format (Lua does not distinguish integers and floats; it's just numbers)? No, fortunately it isn't.
In Lua 5.2, bitwise operations are only available via the
bit32built-in module. In other versions…… in Lua 5.3 the
~actually becomes unary bitwise not and binary bitwise xor… but of course~=continues to be just inequality.
-
@dkf those sick monsters. is at at least actually a bitwise xor?
A bitwise xor of floating point numbers in unspecified format (Lua does not distinguish integers and floats; it's just numbers)? No, fortunately it isn't.
In Lua 5.2, bitwise operations are only available via the
bit32built-in module. In other versions…… in Lua 5.3 the
~actually becomes unary bitwise not and binary bitwise xor… but of course~=continues to be just inequality.phew!
-
@Bulb what's exception handling? We don't have that in lua!
-
@Zerosquare To be fair, by “normalize” they “only” mean to make it look normal by comparing it to leaks from other companies, not make sure it happens regularly.
My first thought was they meant standardizing the format of leaked databases across all hacked companies.
-
@sloosecannon Yes, we do. It's as good as in Perl.
-
@sloosecannon Yes, we do. It's as good as in Perl.
Well, personally I don't count pcall as exception handling because it's.. like exception handling minus all the useful bits and supporting syntax....
-
@sloosecannon Our Lua code is sort of intermediate representation for … this thing called OTX that is canonically represented with XML¹. So support syntax does not matter too much, and we have some support functions that pcall closures and report the error in standardish way.
¹ It's one of those failed attempts at letting people code logic without knowing how to program. Well, some tooling implementers apparently do have some syntax for it, but we have just a flowchart editor².
² Which is why we, and the people at customer also, often end up tweaking the Lua scripts anyway. It's still easier than fiddling with the boxes.
-
It's as good as in Perl.
"As good as Perl" is not exactly a resounding endorsement. (And that's coming from someone who actually likes Perl.)
-
@HardwareGeek That's the point. “Exception” handling in Perl sucks as much as in Lua.
-
I've been watching a talk about sandboxing
https://youtu.be/vYirbKQ90IY?t=510
and this point surprised me: he says that on Linux and MacOS processes are cheap (so you don't have to think twice about starting a helper for isolation), they are rather expensive on Windows and even more on Android. Now Android uses Linux kernel, so how the hell did they fuck it up that badly?
-
² Which is why we, and the people at customer also, often end up tweaking the Lua scripts anyway. It's still easier than fiddling with the boxes.
QFFT. (It doesn't change for almost any other combination of GUI programming tool and programming language either.)
-
QFFT
There was a classic article about it (~15 years ago, when articles were still classic).
I'm sure you can find exceptions to this rule
No. This is an exception to the rule that every rule has exceptions.
-
This is an exception to the rule that every rule has exceptions.
Depends on how obscure and unpleasant the language is. Some are really quite nasty.
-
Now Android uses Linux kernel, so how the hell did they fuck it up that badly?
Linux doesn't keep track of much state in a process -- pid, ppid, euid, egid, iopl, maybe 2 or 3 other things -- and everything's copy-on-write. Linux also exists in a world where devices are usually wall-powered and usually provisioned with enough memory for their workload that no process need ever die.
Android doesn't have that copy-on-write functionality as far as I know, tracks a lot more information about processes -- manifested privileges, role privileges, digital signatures, etc -- and often has to boot a separate Davlik VM for each process. Android devices frequently operate on battery power so keeping components (such as RAM) powered on is a concern, and processes are aggressively dehydrated or killed, especially when running on Samsung's latest bloatware festival that can barely boot.
Android's IPC mechanisms also provide much finer grained control of lifetime management, which ironically means it's a lot more likely to have your helper ripped out from under you while you're not looking at it, and much of the operating system pushes for explicitly bundling everything into the same process -- automatic merging of all Activities and Services related to one application into one process and thread, regardless of how many instances exist, unless special steps are taken to opt out, for example.
-
@TwelveBaud so they didn't have the balls to specify wall power, is the problem.
-
@TwelveBaud said in WTF Bites:
Android doesn't have that copy-on-write functionality as far as I know
Where did it lose it? The thing is that it is still Linux!
@TwelveBaud said in WTF Bites:
tracks a lot more information about processes -- manifested privileges, role privileges, digital signatures, etc
That's basically per-user-id, not per process. Android assigns each application a user-id and SELinux context and that handles most of it. And the manifested privileges should be checked by the system daemon when the service is requested. If they are doing it ahead of time, they are holding it wrong.
@TwelveBaud said in WTF Bites:
and often has to boot a separate Davlik VM for each process
… which I suspect is where the Chrome people are
. The renderer processes shouldn't touch Dalvik with a 10-foot pole. The code is C++, so it does not need it, and it only interacts with the browser, network, storage and GPU processes, not the rest of the system, so it shouldn't need to have Dalvik running at all.I also thought Android switched to ahead-of-time compilation (during package installation or first start or something) exactly to make the VM come up quickly and go straight to full speed.
@TwelveBaud said in WTF Bites:
Android devices frequently operate on battery power so keeping components (such as RAM) powered on is a concern, and processes are aggressively dehydrated or killed
… using the standard Linux mechanism made configurable.
@TwelveBaud said in WTF Bites:
especially when running on Samsung's latest bloatware festival that can barely boot.
That shouldn't create overhead for the other processes though. Eat up some resources, yes, but the other processes don't actually reference it (or only explicitly when they request some service, not during their own startup).
@TwelveBaud said in WTF Bites:
Android's IPC mechanisms also provide much finer grained control of lifetime management, which ironically means it's a lot more likely to have your helper ripped out from under you while you're not looking at it,
But that, again, should have nothing to do with how much work it is to start a process.
@TwelveBaud said in WTF Bites:
and much of the operating system pushes for explicitly bundling everything into the same process -- automatic merging of all Activities and Services related to one application into one process and thread, regardless of how many instances exist, unless special steps are taken to opt out, for example.
The Java framework does this. But the Chrome renderers are portable C++, and on that level nothing of this exists. On that level there are just the normal Linux system calls, and the
bindsyscall that was rejected upstream as horrible kludge, ugly as butt, purple, with yellow polka dots, that you can't use manually without all the Dalvik-generated data structures anyway. And you don't want to touch Dalvik with a 10-foot pole. But you can use plain old anonymous pipes and sockets between your own processes, because it's still Linux.
-
But that, again, should have nothing to do with how much work it is to start a process.
In desktop-land once you start a process it's running for a while; the cost is amortized over a long lifetime. In Android-land, the OS "knows" you're not using it at a given moment and kills it out from under you, meaning you pay startup costs again. They don't have as much time to get amortized away.
That shouldn't create overhead for the other processes though. Eat up some resources, yes, but the other processes don't actually reference it (or only explicitly when they request some service, not during their own startup).
The devices have far less memory than the workload they're running expects, so processes die even faster. And stuff at the OEM level restarts Bixby, Samsung Pay, etc, etc, far more aggressively than anything Android One would, so things that create helper processes have to breed them harder to stop them from being outcompeted.
The renderer processes shouldn't touch Dalvik with a 10-foot pole.
Maybe my knowledge of Android is waaay out of date, but didn't they make it so that every process gets its own Dalvik "for free", whether they use it or not, a la
LD_PRELOAD?
-
@TwelveBaud said in WTF Bites:
In desktop-land once you start a process it's running for a while; the cost is amortized over a long lifetime.
We are talking about Linux. It quite often spawns hundreds of processes a second that all die within tenth of a second.
@TwelveBaud said in WTF Bites:
In Android-land, the OS "knows" you're not using it at a given moment and kills it out from under you, meaning you pay startup costs again. They don't have as much time to get amortized away.
Au contraire. It suspends the processes and only kills them when it needs the memory for something else. But …
… actually this might be the reason why the Chrome renderer tasks need to touch the damned Dalvik even though they'd really strongly prefer not to—because the way to mark a process as doing something useful in the background is to create a Service in it and bind it from the process hosting the foreground Activity. Which you can't do without the Belgiuming Dalvik, because they are defined in Java and use the forty two times cursed “bind” IPC.
@TwelveBaud said in WTF Bites:
The devices have far less memory than the workload they're running expects, so processes die even faster. And stuff at the OEM level restarts Bixby, Samsung Pay, etc, etc, far more aggressively than anything Android One would, so things that create helper processes have to breed them harder to stop them from being outcompeted.
Java was an exceptionally poor choice of language. Though the real memory hog is all those high-res images for the xxxxxxxxdpi displays the OEMs like to show off with.
@TwelveBaud said in WTF Bites:
Maybe my knowledge of Android is waaay out of date, but didn't they make it so that every process gets its own Dalvik "for free", whether they use it or not, a la LD_PRELOAD?
My too, but I've never heard of a hack this bad. You'll probably end up linking with it for zillions of reasons though. And as I mentioned above, it might be because you actually need to mark your processes as services in active use and you can't do that without that ensanguined atrocity.
-
I was wondering where to put my activities of the day until I saw this snippet upthread, so it'll be here!
@BernieTheBernie said in WTF Bites:
Python 2 still used more often than Python3
Dear diary, today I've been looking at Fable, a tool for automatic conversion of Fortran code into C++ code. No, that's not the
, or rather not the only one.You can (probably) build it from source, but I used the easy way and downloaded a pre-built version for Windows. You can grab daily (or so) builds, the latest one being from February (yeah, that's another
as it's slightly more (!) than a day ago... what happened since then? who knows?), so it's not old stuff.The package is 650 MB, contains a full Python and countless accessories (such as Qt!), all for the part that really interests me that is maybe a couple of MB of Python, at most. Apparently I can only get a full toolbox of a bazillions things even if I just want one of them, which is annoying (even more so as the zip file contains tens of thousands of files and takes ages to extract) but not really a
.As you can guess from the bit I quoted though, it's Python 2. Here is the
.Oh, and bonus
s: to call their stuff you have to run a setenv.batfile first. Which only works withcmd.exe, not in PowerShell. Then you start this thing and it fails on some code that is valid in Fortran 77, in addition to failing on code that is Fortran 90 (I can understand it failing on F90, after all that's also the case forf2cand the reason I went looking for something else, but on F77, really?). So you "fix" the Fortran code, it runs, and it generates wrong C++. Like, not "ugly C++" (that's a given forauto-generatedC++), but "C++ that does not even compile becausef(a,)is not a valid syntax, how could you even generate that and not notice it?" Also, all strings are set to a length of 1 because one character, many characters, meh, who cares? Oh, and there are a few functions that it just decided "
, do it yourself, I've written an empty placeholder and let you fill it in."All that, of course, on top of the huge
that is requiring to convert Fortran to C/C++, but that's another issue (in short: no free compiler that interoperates nicely with msvc).
-
The package is 650 MB, contains a full Python and countless accessories (such as Qt!), all for the part that really interests me that is maybe a couple of MB of Python
I am used to that on Windows wither their lack of anything resembling package management.
When Microsoft does it in an otherwise properly looking Debian package, well, that's a
.
-
in short: no free compiler that interoperates nicely with
msvcWhat does that mean?
These days, Clang should understand code written for MSVC, so maybe it would be usable instead, and LLVM 11 gained Flang so it should work with it. Or maybe it would work as a glue.
-
@Bulb psht.
Plang
-
Also, all strings are set to a length of 1 because one character, many characters, meh, who cares?
Considering that compared to Fortran strings even C's null-terminated
garbagestrings are a shining beacon of good design, this seems par for the course.
-
in short: no free compiler that interoperates nicely with
msvcWhat does that mean?
These days, Clang should understand code written for MSVC, so maybe it would be usable instead, and LLVM 11 gained Flang so it should work with it. Or maybe it would work as a glue.
You'd think so, would you?
llvm-project/flang at main · llvm/llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. - llvm/llvm-project
The code does not compile with Windows
Oh.
Hang on, I can hear you say, what about PGI Community Edition, that used to be one of the standard(ish) Fortan compiler for Windows, and easy to get? It's been taken over by Nvidia so it now has the backing of a large company, that should make things easy.
Nvfortran for Windows
I have been using the pgi fortran compiler (community edition), but now my license expired. My impression is that now I have to move to nvfortran, but it seems to me that the Windows version is not available yet. Can you please give me some information about when I can expect the release or what...
We are in the process of developing a Windows release of the HPC SDK but it wont be available for a few more months.
Oh.
-
You'd think so, would you?
llvm-project/flang at main · llvm/llvm-project
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. - llvm/llvm-project
The code does not compile with Windows
Nobody cares whether it compiles with windows, what matters is whether it compiles for them </
>Oh.
How the hell did they even manage. It's a bloody compiler. It reads some files, does some crunching, and writes files out. It shouldn't need anything more than the standard C and C++ libraries, and those behave on Windows exactly as they do on Unices.
… can it target Windows though? If it could, you could run the compiler on WSL…
Yeah, keep on piling thes…
-
can it target Windows though? If it could, you could run the compiler on WSL
Surely LLVM can cross-compile to Windows, so the front-end language shouldn't matter? Yeah, maybe not.
-
can it target Windows though? If it could, you could run the compiler on WSL
Surely LLVM can cross-compile to Windows, so the front-end language shouldn't matter? Yeah, maybe not.
LLVM can cross-compile to Windows all right, but every language has a library of compiler intrinsics, and needs to link the system libraries that may have their quirks. If those don't work, then it can't cross-compile that particular language. And the statement about not compiling “with” Windows is unfortunately not clear what it means.
-
Yeah, keep on piling thes…And once you reach the top of that pyramid and have spent a couple of days building the most Rube-Goldberg-ish build process, you suddenly realise that the Fortran code is actually about 500 lines and just reading a (fairly simple, mostly serialised arrays of values) binary file format.
-
@remi A well documented format to top it off?
-
And once you reach the top of that pyramid and have spent a couple of days building the most Rube-Goldberg-ish build process, you suddenly realise that the Fortran code is actually about 500 lines and just reading a (fairly simple, mostly serialised arrays of values) binary file format.
Good opportunity to throw not just the fortran code but also
f2cinto the trash were they belong and just rewrite it.As 3 lines of perl.
-
@Bulb Uh, no, unfortunately. The
here is that the documentation is the code .Well I guess that means it doesn't matter if I add a bug when rewriting it in C++, since by definition the code will do what the doc says it does.
-
And once you reach the top of that pyramid and have spent a couple of days building the most Rube-Goldberg-ish build process, you suddenly realise that the Fortran code is actually about 500 lines and just reading a (fairly simple, mostly serialised arrays of values) binary file format.
Good opportunity to throw not just the fortran code but also
f2cinto the trash were they belong and just rewrite it.As 3 lines of perl.
Psht. Take the time to get it down to 1.
-
@remi I fear you'll need to read the same files the old one was reading though, won't you?
-
@Bulb stop trying to put logic in this madness.
(yes, the actual test will be being able to correctly read existing files)
-
@remi what about the line at the end that invokes a massive crystallography calculation?
ed. you asked explicitly that this post be made.
-
I've been watching a talk about sandboxing
https://youtu.be/vYirbKQ90IY?t=510
and this point surprised me: he says that on Linux and MacOS processes are cheap (so you don't have to think twice about starting a helper for isolation), they are rather expensive on Windows and even more on Android. Now Android uses Linux kernel, so how the hell did they fuck it up that badly?
Adding Google Analytics to every process launched isn’t free
-
@remi Well, if you don't need to read the same files, you can just define a new format and call it a fortnight, so…?
-
@Bulb ... and miss an opportunity to post here? Nah, too easy.
Though I could make it a XML file where arrays are stored with one node per element, and at least one attribute per element storing the type, position in the array etc.
-
@remi dunno, seems to miss the self-describing property of XML still. you'll want to be able to full express array semantics in a system-independent fashion in some sort of prologue element, or perhaps included resource. some of this, for sure, is taken care of by XSD, but for interoperability you need a fully specified declaration and at least some assertions about implementation (0 vs 1 based addressing, for instance).
