afrisch

There are still subscriptions that give access to both ChatGPT and Codex, but with a much smaller usage quota than before the change (which came at the same time as the end of the 2x promo). I couldn't find the equivalent in terms of credit for the usage included with these $20/25 seats...

But -10 is smaller than -2, right?

Giving AI agents permission to do things on your behalf in your computer is obviously dangerous. Installing a compromised MCP server is really the same as installing any compromised software. The fact that this software is triggered by the user or an agent doesn't really change anything. I don't think that humans are more able to decide not to use a tool that could potentially be compromised, but that they have chosen to install already.

How is this different from a backdoor in, say, a Thunderbird extension? I've maintained an extension for Thunderbird and, when I was no longer interested in it, a guy pushed hard to take over the project after sending a few legitimate contributions. I declined because it seemed crazy to give the keys to tens of thousands mailbox to a guy I didn't really know. I also found it crazy that people would trust me initially, but well, I know I'm a good guy :-)

> Having worked with OCaml at Jane Street is not, I think most of us would agree, going to be, going to be a serious barrier to getting hired to work with another language somewhere else.

The retention factor is *not* that other companies wouldn't want to hire them, but rather that these employees are likely to dislike being forced to use something other than OCaml.

No doubt excessive nesting is bizarre, although the end user might not notice (nested panels that fit in their parent are not visible). That's not a reason to have your entire OS break :-(

It has been fixed but a similar problem (with the same repro case) reappeared with a recent Windows update, only now when closing the popup.

So at least they should really work hard to not let a BSOD happen in case of excessive nesting of widgets. The repro case is actually the same than the one for a bug which was fixed 6 years ago, and it is straightforward (just nest enough panels in a modal popup, and close it). It's hard to understand how this could not be caught by a non regression test.

It's crazy a such a simple script, which is actually the same as 6 years ago, can produce a BSOD in a deterministic way with the latest update of Windows. And nobody at MS seems to care about it.

CDuce was the result of my PhD thesis (about 20 years ago); mostly just a research prototype with enough engineering efforts to make it usable for small enough projects. It came after XDuce, which introduced the idea of building a functional language around regular expression types (used to XML schema languages, DTD, XSD, Relax). My work focused on distilling the theory from XDuce into more primitive constructs from type theory (products, unions, recursion), and embedding them into a more expressive type system and language (with set-theoretic intersection and negation, function types, extensible records -- used to model XML attributes, etc), also with a powerful XML pattern matching engine and an efficient implementation of type-checking (just deciding subtyping is in theory exponential in the size of schema, but works well in practice). The theory could probably be used to serve as the basis of statically-typed languages working, on, say, "typed" JSON structures. The work was/is continued by my PhD advisor and other colleagues to include parametric polymorphism (original CDuce supported ad hoc overloading polymorphism only).

The idea was just that if your language could directly express constraints on your document types in its native type system, the compiler could directly type-check statically complex transformations and make sure they produce documents from the expected output schema (assuming the input complies with the announced input schema). This is more direct than having to rely on mapping between XML and "native" data types, which (usually) don't fully preserve constraints imposed by XML schema languages, and are themselves tedious and fragile to write. This works well for XML->XML transformations. Of course, in most applications, XML parsing and/or generation is just a tiny part, which shouldn't affect the choice of an implementation language. With OCamlDuce, I explored the idea of extending OCaml to include XML types. The combination felt a bit ad hoc, but was ok. Today, it could be rebuilt indeed about PPX extension points + some type-checking hooks in the OCaml compiler.

The best part is that tree trade is not contradictory with setting standards!

> For the first time, the trade agreement includes countries' Paris climate deal commitments.

> The text also addresses sustainable development and sets standards for labor, safety, environmental and consumer protection.

Of course. As a matter of fact, UK was never part of the Schengen Area.

> and lose at least 2 points from any speeding

(Nitpicking: actually only one point if driving less then 20 km/h above the limit.)

According to Wikipedia[1], SQLightning -- a port of Sqlite using LMDB -- was 20x faster than original sqllight. It could thus be interesting to compare LiteTree with SQLightning.

[1] https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Databa...

Shameless plug: ocaml-vdom[1] is another implementation of TEA in OCaml (with js_of_ocaml)

[1]: https://github.com/LexiFi/ocaml-vdom

I could have added reasonml to the list indeed, but reasonml really is (a different syntax for) ocaml.

Yes sorry, Elm is indeed implemented in Haskell.

Well, OCaml is indeed rather popular for implementing compilers for new languages (sometimes later bootstrapped), including ones which became rather popular. I can think of F#, Rust, Elm, Haxe, FlowType for instance.

Yes, well, I can imagine that under the assumption that people loose "faith" in Bitcoin, it's still possible to assign a "value" to the Bitcoin network, e.g. the hardware that makes it (miners and nodes) -- I wouldn't count the electricity usage as part of its value, though. But the point is that holding units of Bitcoin, i.e. knowing the secrets that allow spending them, does not give any rights on those hardware assets, so the value of the network cannot provide a lower bound to the value of Bitcoin units, in the same way that industrial or jewelry usages of gold does give it a lower valuation bound.

What's the value of the bitcoin network itself (its computing power?), and how does the holding of bitcoins give any right on this value?

Many files are taken from the OCaml compiler and then adapted, but changes seems a bit deeper than just a different syntax. It would indeed seem fair for the authors to at least make it clear in the toplevel README that the front-end (parsetree representation and type-checking) is indeed / started as a fork of the OCaml code base.

Considering ongoing efforts to create a WebAssembly backend for OCaml (and thus Reason), I wonder what would be the selling point of Grain.

Of course it feels less native than with F#, but we have created and used CSML (https://github.com/LexiFi/csml) specifically to allow our OCaml code base to interact with .NET.

I don't think so. Both bytecode and native evaluate right-to-left.

Here is an obviously incomplete list: http://ocaml.org/learn/companies.html

OCaml now uses Github as its official repo and accepts PRs.

I guess Bucklescript aims at a smoother integration with the JS ecosystem, which means binding to existing frameworks rather than creating new ones (such as tyxml or Eliom). These are different approaches which make sense for different target audiences.

That said, it is also quite easy to bind to the JS world with js_of_ocaml and nothing forces you to rely on tyxml or Eliom. You can use either the FFI which comes with js_of_ocaml, or gen_js_api ( https://github.com/LexiFi/gen_js_api ) which we have created to abstract OCaml/JS bindings from the underlying OCaml->JS compilation technology (we hope that Buckescript will support gen_js_api). The web client-side frontend of my company is using exclusively gen_js_api + the js_of_ocaml compiler (but not its FFI nor its standard library), which should make it straightforward to port to Buckescript at some point if the need arise.