jvanveen

It already uses a harness (lightweight viewer) to generate screenshots with. The agent already sometimes compares it with the aerial layer, but I didn't gave it much thought. Currently, the most difficult things to get right are tunnels and bridges. Comparing it to real location imagery would probably help. I'll give it a try. Thanks for the suggestion!

Yes, it is all still very experimental. I think the data pipeline (gathering and constructing the tiles mostly) is still a bit problematic. I mostly test from the Android build at the moment, but I'll see if I can give the wasm build a bit more focus.

It is basically an openstreetmap viewer plus a simulator layer that turns the data (https://versatiles.org/) into 3d at a certain level of detail. The Netherlands have very detailed geo data-sets (https://www.pdok.nl/), which are used to augment the 3d representation with stuff like point-cloud rendered buildings (3DBAG), crop-rendering, benches, etc.. Basically, it tries to combine as much public data as possible, to represent a city. The simulator is then used to be able to navigate through it with an avatar and to build basic stuff (Secondlife prim-style + Lua scripting engine).

Install Forgejo and move on...

I have been working in the past with Secondlife and OpenSimulator, and since then I aspired to build a map/virtual world mashup that would be suitable for augmented reality. Lack of time and experience with 3d coding always got in the way. Recently I gave it a try with Claude Opus, Rust, Bevy and Openstreetmap data (overpass/nominatim so far) and was suprised that a google earth style tile map system, 3d buildings and global poi's in the form of layers was not that hard at all with the help of AI. So now I want to build something useful out of it, which also should include social features like avatars, gps rtk, mobile clients, chat & video. Useful feedback is welcome. The project: https://github.com/garage44/viberfox/

I'm working on a set of open-source applications to help collaborate on building software. Basic principles are better online communication between people(Pyrite - Galene SFU, channel-based chat), automating i18n and project management where feasible. Mostly experimental: https://github.com/garage44/garage44/

Expressio simplifies i18n workflows with tooling that works for both human translators and AI. Type-safe translations, AI translation support (DeepL, Claude), and code sync.

Instead of magic strings like `$t('menu.settings')`, you use typed references: `$t(i18n.menu.settings)`. TypeScript knows about all translations, IDE autocomplete works, and refactoring is safe. The type-safe approach also makes it easy for AI tools to understand and work with translations.

Features:

- AI translation via DeepL/Claude

- Type-safe translations (no magic strings)

- CLI + web UI

- Real-time WebSocket sync

- Lint to find missing translations in code

Works with i18next format. Uses a workspace file (`.expressio.json`) to track source text and translations. Built partly with AI assistance to speed up development.

Live demo: https://garage44.org/

Puppeteer (Pdfium => https://github.com/chromium/pdfium)

I can't believe people still buy the Purism scam after all these years...I ordered a Librem 5 and a Pinephone back in the days of the other supply chain story(Covid). The Pinephone flew in from China in less than 2 months; the Librem 5 took more than 4 years to arrive. All Purism offered during that time were "opportunities" to invest and exhausting delay stories about failing supply chains, while keeping their customers completely in the dark about their order state. Instead of preying on the goodwill of FOSS enthousiasts, they now try to tap into a new market (nationalism) to sell the same useless overpriced brick to.

Recently used Cursor/Claude sonnet to port ~30k lines of EOL Livescript/Hyperscript to Typescript/JSX in less than 2 weeks. That would have took at least several months otherwise. Definitively a force multiplier, for this kind of repetitional work.

I hate to manually keep track of development time. Wakatime and Wakapi (https://github.com/muety/wakapi) are super useful to generate monthly stats from its api. Made an open-source tool to generate monthly hour reports with: https://codeberg.org/garage44/garage44/src/branch/main/packa...

Not hours; but days instead of months: porting around 30k lines of legacy livescript project to typescript. Most of the work is in tweaking a prompt for Claude (using Aider) so the porting process is done correctly.

Interesting approach! I like the idea of using an ast to find translation strings and to generate source strings by an llm from the context. My experience is the same. Having to deal with 6 languages and a fast changing application is impossible for small teams, so I ended up with asimilar approach where developers only edit the source text, and target translations are automatically kept in sync using Deepl. This solves the whole i18n dilemma of outdated/missing translations, by just focussing on the source texts. It would be great to be able to even generate the source texts from the $t tag. I'm slowly turning this into an open source developer tool: https://garage44.org/posts/expressio/expressio-machine-trans...

I just switched to Bun for typescript support, a free bundler and better performance. Iojs flashback all over :)

"you have 3 items in your cart" would in that case create a translation for each time the amount changes, instead of having "you have {{count}} items in your cart. A backend proxy sounds like an interesting idea, but working with an i18n formatted string from the start seems like a more sustainable approach.

Cool, nice product. Interesting to see that you've managed to get translations working on top of chatGPT, even for languages like Arabic! I decided not to support target language edits, because I felt it would make it much more difficult to keep languages in sync, when the source string is not always leading. How do you deal with this properly? Would love to have an automatic workflow that updates the json source file, as i18n tags are being added/removed from frontend files. For versioning; maybe just take advantage of the project's (git) versioning?

Interesting! How about using Deepl as a translation backend? I got some good results for translation strings with {{placeholders}} that needed to be ignored in the translations. Its api also has some neat features like formality, glossaries and context(experimental).

Ps. I'm working on a similar opensource tool to speed up the i18n process ( https://codeberg.org/garage44/expressio)

Just updated my Librem 5, to see where it's at after catching dust in a drawer for a year. No bluetooth audio, sluggish browsing, no maps, no suspend, nice terminal, sweaty hands from the heat exhaust. So... still no battery life, and charging takes a couple of hours. I didn't even bother to try calls. Been there, done that with the PP & PPP. Great idea, nice proof of concept, but this is not a usable phone at all. Back to Fairphone + CalyxOS for me...

Wakapi is great! I'm using it for a couple of months now on a simple VPS. I like that it is written in Golang (quite fast) and feels polished. There is a recent instruction video about Wakatime & Wakapi which is a nice way to get a quick overview: https://www.youtube.com/watch?v=iEb71_kaluc

Because I couldn't find any similar solution, I've come up with a small script (Wakamonth) on top of Wakapi/Wakatime, that allows me to get an overview of worked hours at the end of the month, without me having to write down this manually. Any thoughts about it or similar solutions?

I tried to log hours with Wakapi and Wakatime plugins for Vscode and Firefox. Heartbeats are still collected when offline, but i'm not sure how precise the time tracking itself is. The collected data can be summarized on a project/branch level, which makes it suitable for hour reports. A first attempt: https://github.com/bitstillery/wakamonth

Perhaps try something like this? https://github.com/ggerganov/whisper.cpp/tree/master/example...

Some more background: https://www.curbed.com/2020/12/venices-usd6-billion-mose-flo...

https://www.lastampa.it/esteri/la-stampa-in-english/2017/10/...

I got mine a month ago; ordered oktober 2019. Since than tried the Pinephone and PPP as a daily driver. The Librem5...it's slower and clunkier than the Pinephone pro. Both last less than 24 hours on a charge(suspend and calls seem to be a difficult problem tot fix). In the end, these may be nice tinkering devices, but nowhere near anything that you can reliably use as a phone. I now use a Fairphone 4 + Calyxos, and am quite happy with it. Spotify instead of Ncspot, Bluetooth that works, calls that work, no more buggy mobile Firefox config, reliable maps, messaging clients that work in the background. Most importantly; a battery that last at least 2 days, with reliable fast-charging. Purism, Pine and the Opensource community around it are just too small; either they run out of cash and/or people burn out trying to make it happen. A whole different case, but Valve's steamdeck is IMO a good example that Linux-based products with a good value proposition are possible, under the right circumstances.

CSS sourcemaps, being a basic assets in frontend tooling for many years, are still unsupported in Vite(https://github.com/vitejs/vite/issues/2830). Being an open issue for that long, while sourcemaps are supplied for free with tools like ESBuild & SCSS, are perhaps an indication of too much complexity in Vite? About build performance; ESBuild(and SWC as well) happily build large projects within reasonable time(<200ms). I doubt that skipping bundling all-together, by using ES-Modules during development, is worth the extra hassle in tooling. It made sense during the Webpack/Vuepack/Parcel 1 era, but not that much anymore since ESBuild happened. Spending some extra time in writing a custom buildscript (ESBuild + SCSS + simple async task manager + Chokidar + Tinylr or something similar) pays itself back really quick when a project gets larger.

Response from Pine64: https://www.pine64.org/2022/08/18/a-response-to-martijns-blo...

Thanks for your hard work on the Pinephone Martijn! I really enjoyed reading your posts about the Pinephone, Megapixels and Tow Boot.

HMR is nice, but the added complexity seems to make basic stuff like sourcemaps support difficult. Would be nice to have something that adds HMR with the flexibility of a custom build stack(esbuild + a better livereload)

For more interesting related projects, you may also want to checkout https://github.com/pion/awesome-pion

I'm fiddling now and then on an alternative conferencing frontend(Pyrite - https://github.com/garage44/pyrite) for Galene(https://galene.org), which is a SFU that uses Pion.