josevalim.bsky.social
Creator of Elixir. Working at Dashbit and Livebook.
90 posts
5,521 followers
17 following
Regular Contributor
Active Commenter
comment in response to
post
FWIW, I almost never ask it to correct itself. Usually I start again, giving more information (or by updating my rules file), and then if it doesn't work, I just do it myself.
It feels like once it goes in the wrong path, it is very hard to "right" it.
comment in response to
post
Just to confirm, it is all working as expected. It compiles on Erlang/OTP 27, but not on Erlang/OTP 28. It can't really work on Erlang/OTP 28 so I appreciate you going ahead and submitting PRs for those projects.
comment in response to
post
Both algebra and reflection. For example, every binary has to be traversed twice, one to figure out to print it as a binary/string and another for the algebra document. Similar for maps deciding between keywords or => and so on.
comment in response to
post
That code will always fail on Erlang/OTP 28, so we added an earlier warning, but we should probably have gated it around a OTP_RELEASE check. I will do it now.
Btw, don't expect me to check bsky/twitter, this would have been seen earlier on official language channels. :)
comment in response to
post
I can confirm it is expensive, it traverses data structures, reflecting on them, then it builds an algebra document, and then it figures out the best way to format them. Although there may be some low hanging fruits somewhere.
comment in response to
post
I had to double check 😂
comment in response to
post
Thank you! I wanted to post it here but unfortunately there is a 2 minutes limit on videos (and I didn't want to go through the hassle of uploading it somewhere else either).
comment in response to
post
That one is on me, sorry. It was very outdated. mix xref docs is the way to go and is always up to date on latest best practices: hexdocs.pm/mix/Mix.Task...
comment in response to
post
Cool <3 We also have a Discord server on the website in case you want to join us and chat. There is a #rails channel!
comment in response to
post
After discussing it for a bit, I am thinking a "get_package_location" should be enough, as it can then use the regular shell commands to interact with that directory. Can you try that instead?
comment in response to
post
Sweet! Would you be willing to send some PRs? I have to discuss with the team but I can say for sure the built-in get_source_location should be able to deal with gems Then next we need to find out a way to read them (it works in Elixir because packages are installed within the project root)
comment in response to
post
It is .ai for "AI CARAMBA"
comment in response to
post
Thank you, I was also annoyed by this!
comment in response to
post
In that case you can fallback to the less efficient version which is first only compute the indexes (using Regex.run / :binary.matches) but then build the strings afterwards after collapsing the indexes?
comment in response to
post
I wonder if we could add it as "parts: -2", which means splitting the parts from the end?
comment in response to
post
Fwiw, the "scaffold" generators (phx.gen.html/phx.gen.live/etc) are not using daisyUI, only the CoreComponents, so you can use them regardless if you keep or yank daisyUI from your app.
comment in response to
post
You can find my email on GitHub! But ElixirKit should work as a dep today if you point to the repo with the sparse flag!
comment in response to
post
I am wearing the Dashbit hat in this post! Official LSP updates will come from the Expert team!
comment in response to
post
I'd say Agent and GenServer sit at the same abstraction level though. The Agent may have a more concise API but the abstraction level - the concepts you need to know and understand - are roughly the same. It is mostly a style preference although agents unfortunately cannot handle info.
comment in response to
post
Or spawn a process in test_helper.exs:
spawn(fn ->
ref = Process.monitor(MyRepo)
receive do
{:DOWN, ^ref, _, _, reason} -> IO.inspect(reason)
end
end)
to tell you if it's crashing. If reason is shutdown, it's supervisor restart. Then use handle_sasl_reports to find which child causes it.
comment in response to
post
The process is most likely dead. Either a bug in Ecto or because another process in your supervision is crashing, causing it to restart the whole tree. You could enable handle_sasl_reports to print something when your supervisors act: hexdocs.pm/logger/Logge...
comment in response to
post
The challenge is to prove that your existing APIs will remain narrow for old types, and only widen for new types, which is what the article introduces: a type safe mechanism to emit such proofs.
comment in response to
post
If it escapes, you will by definition get a typing violation, because you will pass a %Schema{name: string() or nil} to a place does not accept nils. That's the easy part and it works with the existing theory today.
comment in response to
post
The cool thing about the article (note: I'm biased!) is that it shows "type widening is only permissible in a contravariant context" can be augmented with "We can also widen the output as long as it is widened for input types not previously handled", and that's also safe! :D
comment in response to
post
Yes, that's exactly what I hope to start changing with this discussion. Why are we ok with forcing libraries to release breaking changes as the only way to evolve types? Maybe this is not the answer but it certainly shouldn't be grit your teeth. :)