HN user

razze

34 karma
Posts1
Comments32
View on HN

Working on a freedesktop (linux) api, that allows apps/app developers to call local models, without having to ship them for each app. Currently with vision, speech and language use cases, all sandboxed and able to run in sandboxed apps.

You can't go too crazy with the requests, but with a decent PC it can be very handy, especially for accessibility.

Did you create an issue for this?

My last info was, that we don't process anything in parallel, as the old xml scrapers were not optimized for that. As we're moving to python scrapers now, we should be able to optimize the interface to handle more in parallel. That was the plan at least, but XML scrapers first need to be removed, as they hold back the API.

That more sounds like a you problem. No reason to play around with your setup, if you don't want to. Just hook it up to a NAS and play your files, has been working fine here for +7 years

Fedora 35 5 years ago

Fedora is usually up to date. In my experience more then manjaro (but that's not arch), still usually fast enough.

Elm at Rakuten 5 years ago

Having worked with "the main dev" I can't say I share this view. It has been very nice to be able to pick his brain and hear his thoughts. It can be exhausting, when you want to improve things now, but come up with a better long term plan. I guess that's a language designer thing.

Elm at Rakuten 5 years ago

I don't think that's fair. If elm ever wants to replace js it only needs to rewrite the kernel modules, they govern. Otherwise the whole ecosystem would break in that case and yes, that would be a harmful feature.

Honestly, it's nothing alike. Refactoring in Elm is different, as the compiler will tell you if you did the correct thing when refactoring. The typescript compiler can only do a fraction of that, even if you type your stuff correctly.

Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.

Interesting, why are compilers special in your POV? Why do they need regular maintenance and why don't they allow extension via some kind interfaces, thus allowing for less maintenance?

Unless the benevolent dictator pushes out a new Elm version that is not backward compatible.

That wouldn't break your build/deploy out of the blue, as you don't get force updated to the latest version.

And having worked on the 0.19 transition, it was in public preview for about 3/4 of a year and regularly discussed in the elm slack. When 0.19.1 came about, there were some more pre-release versions, where evan asked people to test and give feedback in slack. Can't speak for versions before that.

I've been doing a bit more elm (some at work) and I've tried to get into Reason from time. I always aborted on the first day. Last time I tried to learn ReactReason in december, I think their VSCode tooling wasn't working at all.

I'm pretty sure if your honest all you projects end up having this bus factor (check all your dependencies). If you really care to look, most projects are run by a small group of people.

where people are allowed to make suggestions, where all feedback is considered valuable, where people can experiment and explore the design space without artificial limits?

Can you put your finger on each of those and why you think they exist? The only one that makes sense to me is the last one if that means, that people can use hacks and use private apis they were never supposed to use?

That's not correct, you can just inline any package into your vendor folder in your project.

And the package website is just an index, the sources need to be on github in the first place (this has some problems too), but if the website is down, you can still grab them from github.

Elm 0.19.1 7 years ago

You can get these infos from the json the compiler provides you on errors, that's also what all editors will use to show you errors, so they are aware where the error acually is.

While it seems like a bus factor of one, my understanding is that there is a plan in place (probably from the people at noredink). Even if not, the code is open source and can be forked, which should only be the very very last option.

I'm using elm 0.19 for an internal company wide tool, backed up by elixir with a graphQL api.

You have to see the implementation of libraries like https://package.elm-lang.org/packages/dillonkearns/elm-graph... to really appreciate what elm is trying to do. Maybe even read this https://package.elm-lang.org/help/design-guidelines

So every package is documented and quiet easily understandable. So whenever I need to go back into angular land - most times dependencies don't even have any docs maybe a readme if your lucky...