paul_manias's comments

Partially, but I think it's moreso the W3C spec being so thorough and the wealth of samples online. I found that during code review both Codex and Claude would refer back to the specs for certainty on expected outcomes. Their understanding of how to deal with unusual edge cases was also impressive, so it seems they have a lot of baked in knowledge & training of how XPath works and they draw from that.

In the last 7 days I implemented a complete XPath 1.0 parser & evaluation system from scratch in C++20. Right now I'm adding support for XPath 2.0.

Codex in the cloud has been leveraged to do 95% of the work and Claude 5%. We've output 10.5K LoC and 774 individual tests to ensure compliance to the spec.

Lately I've been feeling like we're living firmly in the future. This would easily be an 8+ month project on my own not including the tests, yet we're now on track for completion in 10 days. A min. 25x speed increase is a crazy level of productivity for me and it's hard to believe I'm still seeing articles claiming that AI coding isn't productive.

Same experience here. In the last week I've successfully managed to build a complete C++20 XPath 1.0 parser with Codex, and am now onto supporting XPath 2.0. Codex has been nailing it time and again - the only caveat is that I have to use their cloud version as local execution is buggy.

Sonnet on the other hand gets tripped up constantly due to the complexity. I'm not seeing the improvement I was hoping for with 4.5, and it's just given up on attempting to implement support for date-time functionality. Codex has nailed the same task, yet Anthropic claim OpenAI have the inferior product?

I'm pretty sad about this as I'm gunning for Anthropic and would have loved to see them at least match Codex with this new release. If OpenAI stays on this course then Claude Code is toast without an important breakthrough. It doesn't help that they're also the more expensive product and have service quality issues pushing people to quit the platform.

I've been using MinGW and MSYS for Windows development since the early 2000's, mainly to keep the build process consistent with Linux. A couple of years ago I gave Visual Studio / MSVC a second chance and have stuck with it ever since.

MSVC generates significantly faster & smaller code, doesn't require additional DLLs in the final build, and the C++ compiler behaves predictably. Critically it also works very well with CMake, so my build process is seamlessly aligned with Linux.

The VS debugger is a major help too - gdb can do the same stuff, and there are UIs for gdb, but debugging through VS is just more productive and convenient. Times change!

In the UK it is very easy to find scented roses from specialist growers. David Austin for instance has a 'Best for Fragrance' category on their website. They even go into some detail in describing the smells.

I find that scents don't last too long, but I think this is to be expected. On my property most of the scent from roses is produced in the first week's bloom before dissipating.

I work on a project that builds an SVG compliant vector scene graph and allows for detailed interaction via its API. Writing client code that can plug into the rendering pipeline or just altering the existing code is also fairly easy - comparatively at least.

It's at https://github.com/parasol-framework/parasol but fair warning though, it is in alpha right now and going through an overhaul.

It's right at the front near your knee. The level of discomfort would vary between people, but I find it to be very noticeable once the padding's worn out.

I've had my Aeron for 15 years (second hand, so it's probably 20 years old by now!). It's still as good as the day I bought it. The gas lift is going strong too, but I've had to replace the front pad every 5 years as they flatten over time.

Before I had the Aeron I'd replace my office chairs every 4 years or so. Not only have I saved money long term, their longevity makes them the better choice for the environment.

Enjoy your chair, you'll get a lifetime of use out of it.

It's only the size and age of them that makes one fly distinguishable from another. When they're all being born at the same time there's absolutely nothing that makes them distinct, and that's your clue that eggs have been laid somewhere in the vicinity.

This reminds me of the time I found two flies in my house despite the windows being closed. I vacuumed them up (more fun that way) and the next day there were two identical looking flies in the house. Did they get out of the vacuum cleaner? I vacuumed them up again.

The next day, same story. The flies were now appearing throughout the day. They all looked the same. Where the hell were they coming from? The windows were still closed. I kept vacuuming.

Eventually things were starting to get very irritating. I hunted for an entry point for days without finding anything and the flies just kept on appearing. I was pretty good at vacuuming flies by this point.

By day six I spotted a group of them hanging out near my Kentia palm. Aha! A fly had laid eggs in the soil of the plant. I had no idea that it was a suitable food source for larvae. Needless to say I quickly filled it with gravel and I guess that's the story of how I became a qualified Fly Detective.

Come on... make is a perfectly good choice (and for me, preferable) for any project that is small to medium sized. However if you get to a stage where you have to compile for 3 or more platforms and need to account for different compiler versions & systems that people may be using, 'make' quickly becomes hell to use. The possible build combinations just get out of hand, and you can't if-then-else your way out of every situation. Ultimately you get to a point where makefiles can't deal with the growing complexity of a big project.

That is where CMake really shines - it takes the headache out of managing complex, sprawling builds once you get it setup, and you won't have to keep tweaking the config to manage every other dev's system. I grant that the documentation is not perfect and there is a significant time investment in getting everything 'just so', but the long-term time savings make up for that completely in my experience.

I think that's reasonable, but is syntactic sugar really going to help you modify a path when the vector points will look more like this in reality:

  (path (M 368.296, 1.514) (c -0.908, 0 -1.818, 0.011 -2.716, 0.021) 
  (c 0.053, 0, 0.106, 0, 0.159,0) (c 147.196, 0.836, 265.306, 94.672, 267.029, 183.784)
  (c 0, 0.581, 0.065, 35.087, 0.065, 35.087) (h 49.415)
  (v -33.471) (h 37.094) (v -31.376)
  (C 719.342, 77.099, 575.826, 1.514, 368.296, 1.514)
  (z))

Let's imagine for a moment that path instructions could be mapped out with more verbose instructions. Would this really get enough practical use to be worthy of standardisation?

For the most part, SVG path outlines are almost always defined in software like Illustrator and Inkscape. Bezier curves are beyond the average person's ability to create or modify without visual aids. Simple path constructs aren't all that common in practice and the examples I see posted here aren't representative of real-world use.

SVG does provide transform capabilities to move, rotate and scale paths easily, and those features can be applied within a text editor. For anything else there are plenty of visual tools to aid path modification. Personally I've modified many an SVG file manually, but when it comes to the paths I can't say that seeing them laid bare would be of a help to my workflow.

> Oh. You can almost hear the designer saying "well fuck it, we'll just jam it all into a string.

I'll throw in my 2 cents here because the responses aren't addressing why the path descriptors are stylised in this way. Whether SVG's underlying document format was XML, JSON, SGML, CSS or whatever is irrelevant. However else you did it, any alternative would be more verbose because the 'd' tag already offers the most compact way of describing vector paths in text form.

And that's the point - it's small. Even in this compact form, it's not unusual for path strings to reach kilobytes in length when floating point numbers are catered for. Thus we need the path descriptions to be as small as possible for optimal parsing of the file and keeping the file size down.

As a side-note I disagree with the author's conjecture that SVG doesn't succeed as a machine-focused language or a human-focused language. I think it serves both sides of the coin quite well in practice (certainly more-so than HTML) and a pared back version already exists in the form of SVG Tiny.

You say that like someone that is yet to experience the absolute hell that is OpenSSL 'documentation'.