Passing data from camera to OpenGL broke my mind. The code is still far from what I'd call nice, but feel free to steal anything you want!
Once I verify that debayering still works (I originally tested it years ago), GPU progress will mean calculating various statistics - the color balance, brightness, contrast for focusing, histograms, etc. Then feed them to control algorithms to adjust the camera controls.
First, libobscura doesn't yet fully support even UVC webcams,
and second, related to the quote, is that you will not run into segfault with libobscura no matter how hard you try.
When using libcamera, the task of memory management is on you, with the usual consequences.
There are more smaller differences. Image processing in libobscura is on the GPU from day 1. Contributing to the project is through codeberg, not a mailing list. The internal architecture differs, although that's not too visible.
Future goals may end up diverging, too. I'm thinking of a completely different approach to configuring devices and a different governance structure.
> Similarly, how do you create an on-screen keyboard that can inject keypresses for characters not available in the current layout?
I switched the keyboard layout on the fly, on key press, if needed. That works... mostly. Chromium and Chromium-based apps know better what layout I am using, so they will misinterpret some inputs despite having a key map already.
And then you realize that you can't use a physical keyboard at the same time, because key maps go out of sync while keys are pressed on both. I talked to a Wayland dev about having separate keyboards with separate layouts, but the answer was basically "it's an incompatible change, and it's too late to fix this" (it was in an issue tracker, but no link). So the only way to have a non-input-method on-screen keyboard is to limit yourself artificially to the current layout. Which, of course, is an oft requested feature I will never implement.
> A better idea would be to allow to send arbitrary Unicode strings and maybe integrate regular input and IME input (input system for typing Asian characters).
Isn't Mac OS do something like that? I agree this is the way to go. But the stumbling block is - again - that applications like Chromium won't implement this. I created the text-input-v3 protocol some 4 years ago, and it's still basically only used in GNOME.
But with new funding from NLNet I'm gathering a special ops team to push input methods again this year :)
> most developers use only ASCII and do not have experience using multiple layouts.
I'm getting that impression as well after discussing the topic of internationalization on Mastodon: using languages other than English is undervalued by open source devs. I mean, how often do you find variables named in Spanish or Russian in open source software? It's a very anglocentric bubble.
> I'm getting that impression as well after discussing the topic of internationalization on Mastodon: using languages other than English is undervalued by open source devs. I mean, how often do you find variables named in Spanish or Russian in open source software? It's a very anglocentric bubble.
Why is that a good thing? I get the idea that a common language is beneficial, but the flip side is the knowledge and effort of the people who know another language. That's lost due to never being opened (I guess that's more of an indictment of the open source community being not interlinguistic).
So, let's look at this group of people knowledgeable in programming et al, but not english. Sure, this group exists. It's relatively tiny though. English is the language in any (modern, IOW except where it didn't replace latin yet) science, including CS. The vast majority of other on-topic literature is english. It's hard to learn a decent amount of stuff concerning programming without knowing english.
You can't randomly mix languages in source code, and any other choice of common language than english would exclude a LOT more people from the project.
All of this isn't related to i18n/l10n of your application at all. People not knowing english is a much more relevant factor when talking about user interfaces. I actually plan to localize my Xmoji tool eventually, it's just postponed until more important stuff is done (I mean, I assume most people would get together enough english to be able to use an emoji keyboard after all, but of course, especially seaching would benefit from l10n).
I guess my initial reaction was wrong: not having code in non-English languages doesn't accurately represent developer sentiments. There's a lot of translation efforts in open source, but again, this is not a good proxy for the sentiment because we don't know how many translators (who care about non-English) set project direction and design protocols.
Still, an anglocentric bubble diminishes internationalization, and I disagree that it's a good thing.
A bicycle computer. Hackable. Open source software. Off the shelf hardware.
ARM microcontroller, 100% Rust, Bluetooth (not yet).
I have had a bike computer nearly 3 decades ago, but the dream to have the distance counter reset automatically has remained unfulfilled. I could either get a fixed-function calculator or 100% closed overpowered gadget. Why can't I have some fun myself?!?
Thankfully, now we have cheap, reverse-engineered smart watches. I found a pretty decent, sunlight-readable one, and now I'm hacking away!
The big TODO is speeding up development by switching from TockOS to RTIC, and implementing a minimal Bluetooth Low Enegy stack.
Currently on hiatus because it's bike season and I'd rather spend my time outside :)
You can view the data structures opaquely even though the functions are written not in Rust, but in Python.
One of the difficulties is that the Rust compiler will emit different debugging info depending on the compiler version. Perhaps I should look into how gdb deals with that (if at all).
Don't know about the long lines, everything wraps well to me, but on mobile (firefox) the zero padding on the left side is brutal. The gigantic comment section at the end is a small hindrance, while the right sidebar kills 30-40% of the page width (on mobile), which is annoying on longer articles.
And thanks for the content :-)
> Start in the middle. It's the most interesting part, too. After all, that's the core of your idea.
For a programming language? Maybe if you are designing your language by feature list.
What if you are designing a programming language for ergonomics instead?
Let's be real - the differentiating factor in any modern language design is the syntax, not the features. They all mostly support a similar cross-section of features, in terms of "getting things done".
What you are really designing is a competitor to the existing languages, in which case it is beyond the scope and effort of a lone developer to match feature-for-feature of modern languages.
My experience of lone-wolf programming languages is all the same ... namely ...
Even if you do have one, single, differentiating feature, people aren't going to adopt unless you have all the other features they want. Doesn't matter how good your feature is if your language is missing some feature that people like in current mainstream languages.
You should also be careful of thinking that a single good feature will cause a little adoption; if it's any good the existing languages will simply adopt it!
Another path into darkness is thinking that the batteries included is so different to current offerings that people will adopt it, such as that recent post on HN about a language developed for cloud by the author of CDK. There's nothing in that language that can't be implemented as a library for existing languages.
For programming languages alone, going feature-first is a good way to produce an obscure language that no one is interested in. Without even a small community, the original dev themselves won't use it.
Where a new language makes sense is in ergonomics, not in features.
Can you make the syntax such that people onboard quickly? Can your syntax support something complicated in a manner that the most simple-minded developer can understand? Is your syntax amenable to collaboration? Can it be easily parsed in pieces for IDEs? Will the output be package-distributable or module-distributable? Can you ensure easy GDB integration? What build mechanism can be used (for reading the sources and figuring out dependencies).
Syntax is the major difference between writing in Kotlin and writing in Java.
My new language project, I'm still trying to nail down what the syntax should look like. I have no problem documenting the tree to support features I want, but I find that settling on what good syntax looks like to the majority of corporate developers is really really difficult.
Compare with, from an AST, emitting code for some advanced language constructs. That's almost a mechanical effort that I think I can delegate a lot of to ChatGPT.
Designing universally acceptable syntax, on the other hand, is a lot more complex and requires actual human decision-making.
As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours.
> As far as I can tell, this author is writing a language just for the experience of writing a language, without much regard to getting it used, so it sounds like their success criteria may be a fair bit different than yours.
Actually, his criteria was exactly the same as mine when I first started writing my own languages - learning experience, bragging rights, whatever.[1]
At some point, though, even I didn't use my own languages, because without a community of users, it soon became pointless.
That's the thing about some projects - they take off even when the objective is not to build something that takes off. It's why I admire (and maybe slightly jealous of, as well) Andreas Kling's SerenityOS.
It's the only project I can think of in recent years that was totally superflous and unnecessary (any solo OS or PL project is, at this point in time), and yet its gathering steam and shaping up to be a real contender.
But that type of thing is like winning the lottery - the odds are against it.
[1] One of my comments on HN last week mentioned that I want to write a Forth type language, and telling one of the responders to my comment that it isn't because there doesn't exist a quality Forth implementation.
Some places do require an app and while there are alternatives, there may not be another choice in the future. But not today, most of my elderly neighbours also don't own a smartphone and yet they survive in this city (Antwerp).
Life without a smartphone is possible, and imho calmer and more relaxed.
Once I verify that debayering still works (I originally tested it years ago), GPU progress will mean calculating various statistics - the color balance, brightness, contrast for focusing, histograms, etc. Then feed them to control algorithms to adjust the camera controls.