Access is currently forbidden.
Currently blocked in Brazil, 49/50 pings return 403/forbidden: https://globalping.io/?measurement=2acUvndlTojar3qy80001zLzv
Readit Newsjonasmalaco commented on Typechecking is undecideable when 'type' is a type (1989) [pdf] dspace.mit.edu/bitstream/... · Posted by u/birdculture
jonasmalaco commented on Can you remove ads from the documentation? github.com/dotnet/docs/is... · Posted by u/sensanaty
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.
The haxe people are the ones you need to discuss it further with. My pastebin expires in a week so you might want to clone it before you link to it.
Hm... No.
It's still reproducible just by substituting the top function for the stable alternative we use: http://pastebin.com/D3S6SYBM. Haxe 3.1.3 on OSX.
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.
It is not important we agree on this being a bug or not. If you have had a smooth experience you don't have to look further than the linked success story to find a counter-example.
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.
In our case on Android Array.sort throws exceptions. Pretend I nominated something the success story developer had to learn some OCaml to fix in the Haxe compiler instead, it is just an example and doesn't change the common narrative.
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.
Oh I definitely have nothing bad to say about Haxe. I was mostly just referring about some of the external libraries that never made the jump over from legacy, which could be indicative of developers jumping ship.
You make a great point; just because a project doesn't put out updates once a week doesn't mean it's stale. There are some other great projects like haproxy and redis that are clean enough and stable enough that regular updates aren't necessary.
I guess you sort of grow accustomed to that mentality when dealing with some other common OSS projects
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.