razze

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.

We're also seeing symptoms of this in software support. Specifically with flatpak for example, as people start to recommend or wonder about flags (that have never existed) not working.

Some even end up writing (abusive) issues about that https://github.com/flatpak/flatpak/issues/6006

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.

Actually had some people that worked on XBMC go and start Plex, bad blood included.

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 is usually up to date. In my experience more then manjaro (but that's not arch), still usually fast enough.

Not sure you read the initial post the correct way :)

Just use Firefox then :)

There is a contingency plan for that. According to the core team.

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.

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.

Check https://package.elm-lang.org/packages/ChristophP/elm-i18next...

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.

https://builtwithelm.co/ lists some, but not sure what you consider large.

Not sure if you would categorize this as dev tool https://github.com/erkal/kite

And ellie certainly might be a dev-tool, but not a toy https://github.com/ellie-app/ellie

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?

Do you know if that somehow fixes https://github.com/microsoft/TypeScript/issues/8677 ? That's still the most annoying thing about typescript for me.

> 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.

You can just vendor those dependencies, that's what I did, but I only had one that didn't update. And that one was trivial to fix.

Banned from where the discourse?

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.

6. Name one language, that has no unmaintained libraries, please :)

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.

That's kind of the problem, unless you have more features to work on, there is little to maintain in the old sense. https://www.youtube.com/watch?v=RFrKffrKCeU

Your state can be a tree, if it needs to be, so you can nest.

A normal practice is to have a model per page. For e.g. https://github.com/rtfeldman/elm-spa-example/blob/master/src...

And you can have another item next to it for global state if you need to. https://github.com/ohanhi/elm-shared-state explains one way to do this

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...