"Defenestrate" was not in my list, but it's a word I would have gotten, as I know it from: (1) An A.C. Clarke short story ("The Defenestration of Ermintrude Inch", in "Tales from the White Hart", if I remember correctly); and (2) The Defenstration of Prague (I have visited Prague Castle - there were apparently multiple defenestrations there). It's an interestingly (amusingly?) macabre word. (It also helps that I know high-school French and German plus understand Swedish as being very close to Norwegian.)
Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.
Kawa predates Clojure by a decade. (Kawa work started 1996; Clojure's initial release was 2007.) Also, Clojure isn't really focused on high performance, while that has always been a priority for Kawa, which generates bytecode similar to Java, especially if you include suitable type annotations. (It is likely Clojure have have improved in this respect - they have a lot more people working on it.)
What a blast from the past! I too remember with pleasure the days working with Anthony Green (and others) at Cygnus. I like to boast that (apart from Java) Kawa Scheme is the oldest compiler-based language implementation still available for the JVM.
"COBOL uses a fixed width character format for all data (yes even for COMP). If you want a four digit number, then you have to use 4 character positions."
That is incorrect. USAGE COMP will use binary, with the number number of bytes depending on the number of digits in the PIC. COMP-1 specifically takes 4 bytes. COMP-3 uses packed decimal (4 bits per digits).
For me Tauri/Wry starts up pretty instantaneous. This is using Wry as the renderer for the DomTerm terminal emulator (https://domterm.org), invoked with 'domterm -Bwry'. This is on Fedora Linux 41 x64. Admittedly using a rather old version of Wry (0.43.1) with webkitgtk 2.46.5 - I haven't had time to update.
The libwebsockets server (https://libwebsockets.org) supports serving directly from zip archives. Furthermore, if a URL is mapped to a compressed archive member, and assuming the browser can accept gzip-compressed files (as most can), then the compressed data is copied from archive over http to the browser, without de-compressing or conversion by the server. The server does a little bit of header fiddling but otherwise sends the raw bytes to the browser, which automatically decompresses it.
Completion for program P should be written and maintained by the "owner" of program P - and installed with program P. This is of course difficult when there are many different "shells" that each have their own "language" for specifying completions. A multi-shell completion library can help with this problem.
To me it make sense that completion for program P should be handled by program P itself. That way, completions are unlikely to get out of sync with the application, and the completion handler can use the same option parser as the application. A way to do this is to use a special "hidden" switch to request completion.
Specifically the DomTerm terminal emulator (https://domterm.org) handles its own completions. Bash allows you to register a command that handles completions for some other command. The following tells bash that to handle completions for the domterm command it should call domterm with the magic "#complete-for-bash" option followed by the existing line and position.
When domterm is run with "#complete-for-bash" as the first argument (chosen to avoids accidental use) it processes the remaining arguments, and prints out the completion suggestions to bash.
I don't know how to do something similar for other shells; suggestions welcome. Some other shells (such as Fish) include help text as part of the suggested completions. Handling that would require a more complex protocol. Perhaps one that returs a result in JSON format?
If a such a protocol were standardized (perhaps invoked by a "#completions-as-json" option?), we just need to solve a final piece of the puzzle: How does a shell know if a command understands the "#completions-as-json" option? My suggestion is that we define a new keyword-value pair in the "desktop" file specification; the shell would search for a P.desktop file,
On Gnome, the Super (Windows) key does an Expose (show windows reduced-size and non-overlapping) and lets you launch applications (and more).
On KDE 5, the Super key brings up the Application Launcher, which is nice. And Super+W (which isn't too painful to type) does an Expose. But it would be nice if there was an option for Super to do an Expose and bring up Application Launcher.
And people may judge you if you don't react in the way people think "normal people" react. People have been convicted of murder because police or juries though they didn't react the way they were "supposed to".
I am working on a re-write (https://github.com/xtermjs/xterm.js/issues/4800) of the xterm.js "BufferLine" data structures that (among other benefits) could potentially support variable-width fonts in the terminal. Instead of a 2-dimensional grid of character cells, the primary data structure will be a list of logical lines, each consisting of characters and attributes.
A rather modest enhancement to the vt100/xterm escape sequences would be a mode where screen addressing would be in terms of logical characters and logical lines. The application should not need to know the width of characters or how lines are broken into screen rows. This makes use of variable-width fonts practical - which is necessary for decent rendering of many scripts.
DomTerm's display engine (https://domterm.org) does support lines containing a mix of monospace and variable width characters, and know how to wrap such lines. I'm working on long-term replacing DomTerm's native display engine with xterm.js (for speed and other reasons) which requires making xterm.js more versatile.
The master branch of xterm.js (which will become version 5.4) has a new experimental support for grapheme clusters, combining characters, and partial support for variation selectors, based on Unicode 15. (Contributed by Your Truly.) For now it needs to be explicitly enabled (see https://github.com/xtermjs/xterm.js/tree/master/addons/addon...) but in a later release we hope to make it the default. Most of the work is handled by the browser and the font, but xterm.js does need to detect cluster boundaries - which is what the addon does.
To be pedantic: You're conflating the syntax of regular exprssions, with the (computer science) concept. Glob patterns are a kind of very resticted regular pexressions. Ksh extended the glob syntax so it has the full power of regular expressions in the computer science sense - though without all the extensions of modern regular expressions.
Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt.
But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt.
Some REPLs have nicer interactive features (such a completion than others).
Some REPLs have nicer or more powerful syntax or different data types.
But as longs as you have a Read-Eval-Print-Loop it's a REPL.
One of the issues R7RS-large ran into was in how to handle datatypes, such as collection types. Initially, Lisp-style languages had linked lists as the primary data type, but vectors were early added. So you had a "map" function (that worked on linked lists) and "vector-map" (that worked on vectors). Similarly, "length" vs "vector-length". What happens if you want to add more collection types - for example "bytevector"? Do you add "bytevector-map" and "bytevector-length"? Or do you generalize "map" and "length" so they also work on bytevectors (and also vectors)? The former is most compatible with Scheme history and tradition. The latter is IMO preferable going forward as new collection types are added - but it needs some way to talk about frameworks of types that are all sequences (linear collections). I.e. you need at least the concept of inheritance or "interfaces" as used in various languages, including Java and TypeScript.
Many languages in the Lisp/Scheme family have some kind of inheritance or interfaces, including Common Lisp, Dylan, Racket, Kawa, and many more. However, this hasn't been standardized for Scheme. R7RS-small has a mechanism to define new data types (records), but they were limited in functionality to C-like structs.
I (and others in the community) felt (and feel) that it is premature and unwise to add a bunch of new libraries for new data types until or unless we have some kind of framework for inheritance or interfaces. Others in the community (including the former chair) felt this was unnecessary and perhaps inappropriate for a language with the goals and history of Scheme.
There is no clear right answer or consensus for how to go forward, which is part of what caused things to bog down.
This succeeds if obj matches the pattern p::Point, declaring p to be the value of obj coerced to a Point.
This is integrated with Kawa's static type-checking/inference.