Is "let-over-lambda" (variable capture / closure) not possible in F#? Is that not a form of implicit dependency injection?

Closures are possible, yeah. But F# also has partial application(and currying). So you don't need to use a closure to do this.

Yes it’s possible.

This seems fine within a file, but isn't this problematic across files? Now the file order is significant, so not only is the Visual Studio XML project file is an essential part of the language semantics, you also can't organize your files in subdirectories freely? Or did they fix that at some point? How does that scale to larger projects?

More expressive nature of F# means you don't have that many files. C# is luckily and finally moving into that direction too. There was no reason for "one file per class" policy anyway, but it was still widely adopted historically.

Here's an example of a worst-case scenario (GUI frameworks and the extensions have notoriously huge amount of code): https://github.com/fsprojects/Avalonia.FuncUI/blob/master/sr...

But realistically an average project would look closer to this instead: https://github.com/DiffSharp/DiffSharp/blob/dev/src/DiffShar...

Once you have enough files, it might be a good idea to factor out separate concerns into different projects.

You can organize the files however you like, but you must specify list them in the correct order.

The XML is not part of the language. You could invoke FSC manually (again, with the files listed in the correct order).

It scales very well IME.

Would C# be better with circular library dependencies?

Is there a specific reason why Windows is not supported?

Presumably because the Google cloud doesn't run on Windows. Well, nothin HPC related runs Windows.

Life science industry uses plenty of Windows, including HPC workloads.

We ship Windows CPU only at the moment.

We don't support Windows GPU because we haven't had the engineer bandwidth to support it well.

We recommend WSL2 for GPU on Windows at the moment because that is a compromise: it allows CUDA support, without us having to support another release variant.

But we welcome community contributions!

Because no one has done the work to add it... Could be you!

I don't think Microsoft invented it:

> On the CDC CYBER, an interlock register is available ... Operation of this interlock register is similar to TEST AND SET

Concurrency in Operating Systems, October 1976 https://www.computer.org/csdl/magazine/co/1976/10/01647182/1...

OBS is very good software, thanks for working on it!

Recording the screen works much better than any other screen recording software I tried. For this use case the preview can be a bit confusing. If the resolution does not match (because of OS 200% scaling for example) going to the settings each time to adjust it is a bit cumbersome; the interactive resizing handles in the preview somehow never helped me. Sometimes one of the reset zoom context menus helps.

Also the "Window source" would be awesome, but is a bit cumbersome to set up every time, and doesn't capture things like menus unfortunately.

It's probably really difficult to improve these things, so they work automagically for dummies like me that know very little about OBS and use only a tiny feature set, without taking making things worse for power users, which are probably happy with things as they are.

Even drawing front-to-back you don't need the y-buffer, if you switch the loops: for x ... for y ...

Another trick I now remember was to interpolate the color values on such a y-segment, to reduce the pixelated look.

Indeed, switching the loops is valid and might or might not give you an additional speedup. I had hoped, that someone figures this out :-). However I think in order to understand the basic algorithm the way in the readme is the better one.

Do you know of referenceable pseudocode (or real code) for that somewhere? I've tried modifying your code to switch the loops, but it always comes out garbled; clearly I'm messing up somewhere in the refactoring process, but I don't have enough experience with this algorithm to figure out where!

A render routine with exchanged for loops looks like this.

https://www.pastiebin.com/5e10d48ac6595

Just exchange the Render() method in my VoxelSpace.html file with the pastie.

Such good points and so obvious (now that you said them) that first I really want to retract my comment and second now I feel like coding up a terrain generator today. Duh, Doom did (famously) switch the loops for similar reasons!

There were also tricks to extend this simple rendering algorithm to allow limited rotations around the other two axes, to look up / down slightly (just move everything up / down; also implemented in the demo here) and to "lean" when steering left / right (just move everything up / down proportional to the distance from the center of the screen; not implemented in the demo here, but visible in the 1992 NovaLogic Comanche example GIF).

There were Turbo Pascal versions of this on websites in the 90s I think, but it seems they were lost.

Indeed, look up / down is very simple implemented. Just alter the horizon line position. This works for the human eye for small deviations such as ±20°, but will lead to perspective distortions for higher angles.

Same with leaning. Add one more line of code and tweak the draw call:

    var ylean = (input.leftright*(i/screenwidth-0.5) + 0.5) * screendata.canvas.height / 4;
    DrawVerticalLine(i, heightonscreen+ylean, hiddeny[i]+ylean, map.color[mapoffset]);

It adds a lot to the "feeling" IMO :)

Cool, that works!

> There were Turbo Pascal versions of this on websites in the 90s I think, but it seems they were lost.

You can still find a lot of this old code if you dig for it; lot's of it can be found on various SIMTEL MS-DOS ftp archive sites, for instance. I also think the textfiles site has some of it. Also archive.org might have some of it.

Take a look around using google and such: "ftp msdos source code" etc - you'll find plenty to be sure (and even if you don't find what you're looking for, you're sure to find stuff you weren't expecting!)

The one I remember was "voxel.pas by Steven H Don". A Delphi port survived here: http://tothpaul.free.fr/sources.php?dprgrp.voxel

Searching for "voxel" in https://github.com/nickelsworth/swag/ also finds some very similar tiny Turbo Pascal programs.

A short article titled "Voxel Landscapes 2D and 3D By Scout/C-Lous" described most of the tricks, but I can't find the text anywhere. A similar article by the same author on another topic I found here https://github.com/ggnkua/Atari_ST_Sources/blob/master/Docs/...

purge is a third-party extension; it removes untracked files as you wrote.

But ~purge~ prune is also a command of the evolve extension, that is conceptually similar to strip, as GP wrote.

evolve doesn't have a purge command. It has a prune command.

purge is not a third party extension. It is distributed along with Mercurial.

You are correct, thanks.

Fortunately "transplant" is just an old extension, so you can just forget entirely about it.

"Graft" copies; "Rebase" moves.

Alternatively just forget about graft also, and use "rebase --keep" to copy.

"Rebase with evolve" is conceptually still rebase.

Mercurial has strip (removes changesets from repository, by default stores a backup). Mercurial does not have purge.

Evolve has ~purge~ prune (marks changesets as obsolete).

Evolve is similar to a git reflog.

Evolve stores more contextual information than the reflog, so Mercurial+Evolve it is safer and easier to undo things than in Git+reflog. Mercurial also pushes some of this contextual information, so even collaborative history rewriting is possible in a safe and easy way, unlike git.

I don't understand the reasons. What is the actual problem in this "even-odd problem"?

How do all the other languages that have an equivalent function (Perl quotemeta, PHP preg_quote, Python re.escape, Ruby: Regexp.escape, Java Pattern.quote, C# Regex.Escape, Go QuoteMeta, Rust regex::escape) avoid or deal with this problem?

They don't. The reasons are frankly idiotic.

The first couple of comments as well as the very last one from April in that thread all sum it up quite well.