Hacker Newsnew | past | comments | ask | show | jobs | submit | JonChesterfield's commentslogin

Bastard thing corrupted some of my source code that was "on a shelf". Just gone, no path to retrieving, reimplement it. About a decade ago now and I'm still angry about it. Don't lose the work is table stakes for source control.


I really like the json schemas around the tool calls. Much stricter validation than in codex.

Git might be worth adding to the top level. Currently you've got LSP, grep, glob nicely structured for non-mutating queries across a codebase, but git is behind bash and that means hope or sandboxing.

Thank you for uploading it. Gives a lot of insight into how the deepseek models might expect tool calls to be structured.


This is an AI response


I don’t like it. Structures responses really do not work well with LLMs at all. They are one of the biggest causes of issues with tool calling right now.


Agree with sibling. If you're getting severely deteriorated results with structured output, you're probably doing something wrong. There's been some research on the impact of structured outputs on results distribution, and there are tradeoffs, but "do not work well at all" doesn't match the experience at large.


Then you're doing it wrong :)


You prefer having the harness execute any markdown that looks like it might be a tool call? I had a bad time getting that to work reliably whereas a grammar in the sampler gets it right every time.


Libxml2 segv when the input is large and the transform complicated was something of a surprise to me. Parsing xml is easy enough but I think implementing xslt is going to be a nuisance.


That's the any type and the moving logic into json loaded at runtime features


Not really, the `any` type doesn't let you perform any operation on it with runtime dispatch like dynamic typing does. Moving logic into json isn't a language feature.


This only holds if society manages to hang together, which in the age of military strategy written by AI is looking borderline.


It won't last. You need a good grade to find work after so handing out lower grades decreases applications next year.

On the plus side, high grade + long ago remains a signal.


I doubt that's the bottleneck. UCB's acceptance rate is not high (<5% for CS). They have way more people who want to get in -- qualified kids, too! -- than they can fit. They'd need to burn through that backlog before it started showing up as a signal.


> high grade + long ago remains a signal

Does it? I didn't think people looked at GPAs once you're 5 or so years into a career.


Scale is a cuda implementation running on nvidia or amdgpu. Think nvcc semantics with template diagnostics by clang.

Nvidia including Spectral in their inception programs seems a big deal to me. It bodes well for the future of the cuda ecosystem.

If you'd like to run it, docs and download at https://scale-lang.com/. It's a clang fork with a bunch of libraries packaged. I'm on the dev team and always happy to hear from people.


Not imaginary. Eliding checks on nullptr and integer overflow were both implemented, shipped, miscompiled the linux kernel and grew flags to disable them. I expect there are more if one goes looking.


Well yeah that just means some aspects of the imaginary compiler were in some configurations approximated by some historical compiler versions and were in some cases rejected by the community (which cares about sane semantics even for behavior left undefined by ANSI/ISO) and in some cases left in as defaults but made trivially configurable for anyone who wants to define the undefined behavior.


Well, you can't write malloc in conforming C, which hurts rather more than remembering to write bitcast as memcpy on char pointers.

Doesn't matter though because you aren't writing standards conforming C. You're writing whatever dialect your compilers support, and that's probably (module bugs) much better behaved than the spec suggests.

Or you're writing C++ and way more exposed to the adversarial-and-benevolent compiler experience.

The type aliasing rules are the only ones that routinely cause me much annoyance in C and there's always a workaround, whether if it's the launder intrinsic used to implement C++, the may_alias attribute or in extremis dropping into asm. So they're a nuisance not a blocker.


You too can solve maths problems by:

1. Generating enormous amounts of text

2. Persuading a mathematician to look closely at it

3. Announcing success if they conclude it is a proof

This is deeply disappointing relative to "chatgpt found a proof that isabelle verifies" or similar, especially the part where a mathematician spends (presumably hours) reading through the llm output.


I think large proofs done by humans also require hours of verification by other mathematicians, checking for "bugs" in a sense. I don't think they're obviously correct, I think it's like more like doing a code review.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: