I use it similarly, but I add spots for side x side as well as left, center, right. I only use Hammerspoon for this and a couple tiny things, but it's completely worth it for this alone. Use math to specify window sizes & location. Insanity.
local mode = hs.screen.primaryScreen():currentMode()
local mods = {"ctrl", "alt", "cmd"} -- mash those keys
-- regular app windows
do
local w = 1094 -- no clip on GitHub, HN
local h = 1122 -- tallish
local x_1 = 0 -- left edge
local x_2 = math.max(0, (mode.w - w - w) / 2) -- left middle
local x_3 = (mode.w - w) / 2 -- middle
local x_4 = math.min(mode.w - w, x_2 + w + 1) -- right middle
local x_5 = mode.w - w -- right edge
local y = 23 -- top of screen below menu bar
hs.hotkey.bind(mods, "2", function() move_win( 0, y, mode.w, mode.h) end) -- max
hs.hotkey.bind(mods, "3", function() move_win(x_1, y, w, h) end)
hs.hotkey.bind(mods, "4", function() move_win(x_2, y, w, h) end)
hs.hotkey.bind(mods, "5", function() move_win(x_3, y, w, h) end)
hs.hotkey.bind(mods, "6", function() move_win(x_4, y, w, h) end)
hs.hotkey.bind(mods, "7", function() move_win(x_5, y, w, h) end)
end
function move_win(x, y, w, h)
hs.window.focusedWindow():setFrame(hs.geometry.rect(x, y, w, h))
end
No. Being well typed is not a semantic property of of a program - in a language where it makes sense to talk about running badly typed code, a piece of code that starts with an infinite loop may be well or badly typed after that point with no observable difference in program behaviour.
There are decidable type systems for Turing complete languages (many try to have this property), and there are languages in which all well typed programs terminate for which type checking is undecidable (System F without all type annotations).
That's the basis for my critique of CSS. There were plenty of other layout systems extant at the time CSS was cooked up. How CSS could have delivered such an incomplete and broken scheme is beyond me. To this day, it sucks harder than GridBagLayout from AWT of the 90s (and that one sucks a quite bit).
> If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier.
I would look to the UCSD p-System as a precedent to the JVM. Both are byte-code interpreted VMs. Gosling used the p-system earlier in his career, prior to joining Sun.
mod_php was distributed w/ Apache httpd, so it was "already installed". mod_perl needed to be installed manually, so it posed immediate friction, if not a complete freeze-out, depending on the situ. I believe that was why PHP became popular.
Systems with mod_perl (or just Perl allowing normal CGI) installed, especially shared hosting was so common as to be the norm in the late 90s and early 00s.
I think instead the biggest reason PHP took off was it had far less deployment friction and better aesthetics than Perl did on machines where you didn't have admin access, basically ever shared web hosting ever.
Typically CGI scripts on shared hosting were limited to explicit cgi-bin directories that had +ExecCGI. At the same time hosts would often not enable mod_rewrite because it could get computationally expensive on hardware of the era.
This all meant that all your dynamic content had to live at some "/cgi-bin/" path. It could be difficult to have a main landing page be dynamic without an empty index HTML just having an HTTP-Refresh meta tag to your "/cgi-bin/" path.
Contrast with PHP which would be processed from any directory path and was its own built-in templating language. It was also usually included in the DirectoryIndex list so an index.php would act as a directory index leading to cleaner URLs.
In the era when deployment mean MPUT in an FTP client those small differences made a difference for people trying to make their first dynamic website and look "professional".
Perl CGI scripts were ubiquitously supported by shared hosts, but IIRC mod_perl was not unless you had some custom setup on a dedicated server. Also IIRC, mod_perl was just a lot more complicated to set up and use, while mod_php was dead simple.
Not sure what you mean by "primitive support". Java 22 added FFM (Foreign Function & Memory). It works w/ both on-heap & off-heap memory. It has an Arena interface.
That brings back some memories...when Frank Yellin and Sheng Liang (from Javasoft) visited our team at UW I think in 1996 or 1997, we mentioned that our bytecode verifier/failure injector was really fast because we were using arena allocation, which was only possible (at the time) because we did the project in C. If you are using non-pointer offsets, you totally can do arena allocation with a byte buffer. I still don't get how you can do it safely with high level objects even with the mechanism described above, but there are definitely lots of unsafe ways to do it.
