jonasmalaco's comments

Wouldn't the sender be the better judge of the accuracy of what they wanted to communicate? If they feel the LLM version more closely matches their intent, then we should accept it.

There are good arguments to get to know someone "mistakes and all", I just don't think this is a particularly good one. No matter how much you (think) you know someone, they probably know them(selves) better.

Currently blocked in Brazil, 49/50 pings return 403/forbidden: https://globalping.io/?measurement=2acUvndlTojar3qy80001zLzv

The intent behind these mentions was to "promote the use of Copilot" and "showcase Copilot usage scenarios in a variety of different ways".

These are quotes from resolved comments in the review to a similar but slightly earlier PR[1], from the same author, to the one that introduced the specific mention referred to in the issue[2].

And that's why these suggestions to use Copilot probably don't belong in the docs: their intent was to promote a product.

(To be fair, in the first comment quoted above the reviewer asks that the Copilot section be moved to the end of the document, prioritizing teaching the user about the actual feature the article was about).

One additional problem, already pointed out by others, is that Copilot seems to be the only AI tool showcased in the docs. Besides suggesting the intent of these suggestions is purely promotional, this reflects poorly on an organization that should be independent from Microsoft.

[1] https://github.com/dotnet/docs/pull/42357 [2] https://github.com/dotnet/docs/pull/42625

That information could come in handy, cool.

A complementary method is to attach a writable NFC sticker tag to the phone. Though it has to be placed far enough from the phone's NFC antenna in order for both/either to work.

The upside is that you get a second tag of your choice (physically) on your phone. There are even UID-writable sticker tags out there (even if they can be a tiny bit harder to find).

You also don't need to replace your default transit card, which could be inconvenient depending on where you live.

Hm... No.

Do you have the same problem with a deterministic comparison function?

I'm not dismissing the existence of a bug just because of this (although the issue may be related to it), but non-deterministic comparison functions are problematic with many sort _algorithms_. You might experience (other) problems when using implementation independent "sort" APIs, since many algorithms need to rerun the comparison function several times and expect consistent behaviour; I would expect certain algorithms to, for instance, never complete.

Respectfully, it is important to understand whether sort stability is as bug or not. Particularly since you seem to have experienced exceptions on Android, and assuming that the problem was in the sort stability may have mislead you.

Please report that bug. The core team (or other devs familiar with Haxe like myself) will be happy to fix it.

Also, consider that 65% of the code in the haxe git repository is written in Haxe, not OCaml. There's a lot you can change, extend or fix without knowing OCaml at all.

Development has been quite stable: https://github.com/HaxeFoundation/haxe/graphs/contributors

You should try the nightly builds or compiling straight from Git. They are stable enough for many purposes (and if you report a bug chances are that its fix will soon be available) and you can take advantage of new features.

By the way, there's a new release planned for the next weeks.

Well, it simply isn't a bug. Most sort algorithms aren't stable, and the only thing a generic _sort_ algorithm is supposed to guarantee is a sorted output according to the comparison function you supply it with. If however the method was called "stableSort", the situation would be very different...

The default Array.sort stability is inconsistent across targets _because_ guaranteeing it would prevent reusing implementations already available in the targets. And differently than what you claimed, many languages (and most Haxe targets) don't guarantee sort stability in their default "sort" APIs: C, C++, C#, JS, PHP and Neko.

Also, any remark placed in the official api docs for "Array" or in that very module, just next to sort method, can't be said to be "buried" in the docs.

If you have a client and a server, you'll most likely need to handle input or state twice. You shouldn't trust the client but you also don't your user to depend exclusively on the server (you want less latency and/or more informative errors).

I don't do that many UIs at all, so I wouldn't know about that. Even so...

These languages are certainly more mature than Haxe, but I do still expect to find some bugs in their standard libraries (in performance or security).

And when you factor in third-party libraries, the answer is always "yes you do expect to encounter bugs" independent of the language. For me, programming is in great part reading and fixing other people's code, and I still think most of them are much more skilled than me.

I've known Haxe for almost 7 years and have been using it extensively in the past 4.

In my experience, inconsistencies between targets and undefined behaviour were common, but most cases have since been removed or documented.

Also, I find it's usually trivial to see how a given Haxe API (be it one in the standard Haxe library or from a third-party lib) maps to native calls.

Personally, the fact everything in the Haxe ecosystem is open-source and has reasonable scale (for instance, the std API by design isn't as big as Java's) is one of the reasons I like it so much. Even though I can't code in Ocaml and modify the compiler itself, I feel that can I solve most time-sensitive issues that might arise (bugs, unexpected behaviour, extending APIs, etc.).

Other reasons I code a lot in Haxe are: code reuse; powerful type system (ADTs, abstracts...); macros; reasonably pleasant syntax (although a bit verbose for my taste).

I found the Bim editor interesting; particularity for the simplicity of its implementation.