1. Using ChatGPT with a Business Premium seat (not personally paying for it).

2. Also have some API keys for some open weight models in Europe, but currently not using those.

3. I've personally used OpenCode, Claude Code and Codex and of those, I liked Codex the most, till bugs kept on accumulating and they started doing all kinds of shit like that daemon recently. I now switched to https://github.com/capocasa/3code which is a small, simple agent harness but with built-in sandbox, unlike so many other simple harnesses. I really like this one, plus the author is very responsive to feedback

4. No. And I don't think that stuff works in the long run with current quality of code output

5. No.

Tried nono.sh but it seemed cumbersome. I think it lets the whole agent run in the sandbox, so whenever you need to change something, you have to restart the whole thing, if I remember right.

Also tried Docker Sandboxes which worked fine during the try out but my trust in Docker products with regards to security is low in general, so I'd wanted to wait a bit whether problems show up.

Then used Codex for the built-in sandbox but it's buggy like hell, documented features just do not work properly. Nobody there every seemed to actually try using the stuff they are documenting as working.

Ended up with 3code right now, which also has built-in configurable sandboxing.

try https://www.droneship.run

It's not a zero-day if it's not the zeroth day anymore :-)

According to wikipedia[1]:

> A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it.

Apparently the meaning has evolved over the years.

[1] https://en.wikipedia.org/wiki/Zero-day_vulnerability

I think OP means that it will parse EDIFACT with the tree structure it actually has in its specification, instead of a simple list of messages like many people do.

EDIFACT normally has (possibly repeating, possibly nesting) segment groups and a lot of code trying to handle EDIFACT skips over that.

Surprisingly this problem of treating EDI files as lists instead of the tree structure it actually is, is widespread even among clearinghouses. In retail energy, clearinghouses would often support their own custom format, which typically was either CSV or Excel. If you used that, you would routinely run into data integrity issues.

At this point, I'm pretty convinced that if you're running into EDI (or its sister formats like HL7) processing issues, its because you've got the wrong data structure in place or you aren't keeping your rules up to date. Once you've got the right architecture in place, you can easily manage 100s of provider/partner-specific rules with one person at 20% time. If you don't your whole company is going to be dealing with data integrity issues forever

Care to share what "right architecture" could look like? There's surprisingly little public engineering reading about EDI...

> Care to share what "right architecture" could look like?

I can speak about ANSI X12 because I've used it (North America), haven't used EDIFACT (non-North America):

Each document type, like a PO or Invoice has a defined structure (by the standards group) which is conceptually nested/hierarchical but physically stored as a combination of tags at the line level combined with delimited elements within a line.

Traditionally the raw data would be pass through a translator tool that converted it into it's hierarchal structure and a person could define a mapping from that structure to their internal systems data structure.

With the internet and XML and JSON, many people/companies weren't aware of the standards and didn't have an EDI translator, so they just winged it and extracted what they needed from the raw data.

There is still a large volume of EDI based data movement and it will probably live for a long time due to cost to change plus having standard document definitions across companies reduces the level of effort to connect many partners to many other partners (it basically reduces the transformations down to a conversation about which things each company does uniquely in the document as opposed to starting from scratch with a completely custom document for every company).

Mentioned elsewhere in the thread, but it's possible to parse the (mostly) machine readable specs for EDIFACT messages to create schemas for reading massages.

A library that I wrote decades ago has some Perl which can do that to produce XML definitions from the UN/EDIFACT published directories. I hope that it can be useful to others: https://github.com/davidcoles/medici

Yes it was meant colloquially, like "the syntax tree describes the actual underlying structure of the flat list of EDIFACT segments".

Tried so many window manager addons or replacements for macOS. Ultimately, the only thing that stuck was https://github.com/FelixKratz/JankyBorders which does nothing more for me than painting a big colored border around the currently active window.

Everything else, including tiling managers never worked for me. I prefer to have my main window centered and all the others nearby, but nothing ever quite fit perfectly.

Been out of the SEO game for a while, but the industry has always been pretty hysterical and has been seeing broad patterns in what often are only minor fluctuations or tests.

Thanks for that. Looks like exactly the agent I might have been looking for.

All I'd want is a CLI with a few tools AND a built-in, properly configurable and working sandbox. Seems that's too much too ask.

Just be the 10th person to make one this week.

It's buggy like hell once you do not run the default settings. Whole permissions system is completely broken, for example.

It’s kinda vibe coding in a nutshell. Lots of cool and varied features, that often just don’t quite work right.

I didn't even consciously register the release of the many sequels back then. Always assumed it stopped after Lemmings 2.

Lemmings Revolution reminds me a little bit of good old Nebulus: https://en.wikipedia.org/wiki/Nebulus_(video_game)