hansihe

But you don't really have to retrain the whole model to modify it's writing style, fine tuning would probably be enough

This is not true.

Rivers are often dammed to create an artificial body of water that can be used for power generation. You are storing water from the river when it has a high flow rate, in order to be able to generate power when needed.

There is nothing that requires the area downstream from the dam to have been previously underwater.

If I where to guess it would be to act as a spring to push the sensor against the ball

As I understand it, Matter uses Thread to communicate with low power devices.

Thread uses the IEEE 802.15.4 PHY and MAC.

Zigbee also uses the IEEE 802.15.4 PHY and MAC, using the same frequency bands as Thread as far as I understand it.

Maybe a new radio is needed if you want BLE commissioning (is this required?), but for operation any chip with a IEEE 802.15.4 PHY should support both Thread and Zigbee.

Not necessarily, other render passes could need the depth data later.

Note that this is just the kernel modules, not the actual graphics driver.

IIRC these sources were already released under a permissive license along with their driver distribution. This just seems to be them putting those sources on GitHub and being more open to contributions.

I would probably make the connection if we are talking about very commonly used words, or if I knew what to look out for. In this case, I am not terribly familiar with that mountain range, so I probably wouldn't make the connection by myself.

We have 3 different "special" letters in Norwegian, all of which have their own "latinifications", so it can sometimes be difficult to see when it has been done. (ø to o, æ to ae/a/e, å to a/aa)

Incidentally, Kjolen and Kjølen are both nouns of their own. (kjolen means "the dress" as in what a woman could wear. kjølen can mean "the fridge" as in "put something in the fridge"/"put something in a cool place")

Isn't the main thing missing pointer support in shaders? As I understand it the VK_KHR_buffer_device_address is mandatory in 1.3 and should fix most of the blockers

This actually works somewhat today, but it's all a little hit and miss.

For Wayland I believe the currently accepted way if doing screen sharing is through xdg-desktop-portal which has a backend for wlroots and a bunch of other common compositors. I have gotten this to work fairly decently with Firefox at least, but some things are a bit hacky.

https://github.com/emersion/xdg-desktop-portal-wlr

Yeah, this would pull out a bunch of other alkaloids as well as I understand it. I guess it depends on what the specific plant contains.

I just flew in to Minneapolis from Europe last night and they handed these out for free at the airport. Was really surprised to see the Bluetooth sign on the box.

Fun to see you around here as well!

Because as codebases in dynamic languages grow and age the developers start seeing the advantages having a static type system to lean on would give them.

Jellyfin user with a relatively large library here. I am not having any crashing or hanging issues, did you use the Docker image when you tried it? Can't really speak about the plugin support since I haven't used Emby.

In Rust a slice `&[T]` is a fixed length sequence of `T`s laid out linearly in memory. Every `T` is required to be of the same size.

Strings in Rust are (normally) represented as UTF-8. Both `String` and `str` represent data that is guaranteed to be valid UTF-8.

This means that if Rusts UTF-8 strings were represented as normal slices, they would have to be slices of UTF-8 code-units.

Rust wants to provide a safe and correct String data type, and therefore, indexing a string on a byte (code-unit) level would be incorrect behavior.

Having a custom type `String` and `str` instead of just a `Vec<u8>` enables you to have more correct behavior implemented on top of the data type that doesn't implement normal slice indexing and such.

---

As a note, even though you probably don't want to normally, you can quite easily access the backing data of your string using `String::as_bytes`

A regular Raspberry Pi with a cheap POE USB-C splitter from Aliexpress works very well.

https://a.aliexpress.com/_mMpvxGV

Right, but even a phased array will give you sidelobes, it's only a question about reducing them, right? Your claim that there are no sidelobes at all seems a bit dubious to me.

Or is there some metamaterial "magic" going on even at the transmitter that I'm not accounting for?

Thanks for clearing that up!

As far as I understand it near-field effects stop being relevant at a couple of wavelengths away from the transmitter. For 2.4ghz that would give you what, a meter of distance?

Can you link me to reading material explaining how an antenna can have no sidelobes?

In my mind this is a multifaceted issue.

One major factor is the special semantics of execution in Erlang VM compared to most other languages. Of note are:

* Guaranteed tail calls. There is no other way of doing a loop in Erlang other than recursing, so this point is really important. Although I can certainly imagine making this work with a JS target, we would have to perform certain code transformations that would most likely make the JS JIT a lot less effective.

* Preemption of Processes. Processes are the name of the lightweight actors used in the Erlang execution model. Each process is only allowed to run for a certain timeslice before execution has to be preempted. Although, again, I could imagine implementing this in a similar way as I would implement guaranteed tail calls, this would fully break up the control flow of a function, further disadvantaging the JS JIT.

* The semantics of the language term system. While this is probably one of the smallest issues for a JS target, it would still require us to implement and frequently call into relatively complex term operations that are implemented on top of the JS object model. I can't imagine this interacting well with the above two points in terms of performance.

* Concurrency/message passing model. One of our goals is exploring writing more fully featured applications in Erlang and then running it in the browser. As such, having the same concurrency model as the BEAM is critical. Using webworkers and utilizing shared memory through SharedMemoryBuffer (reenabled in chrome, let's hope firefox gets somewhere with this soon too), we believe makes it possible to implement things in a way that behaves very similar to the BEAM.

We want to invest heavily in the compiler in order to generate the best possible WASM code, which, given we play our cards right in codegen, should be further optimizable by the WASM engine. This involves inferring types and generating specialized code. Since most of Erlangs BIFs (built in functions) accept a much narrower array of types than what a lot of other dynamic languages do, we can draw relatively good type information from that.

This above is all an answer specific to the WASM/JS question, but doesn't even touch on the further goals of the project. While WASM is our primary focus at the moment, we also support native targets.

As for compilation to JS, ElixirScript (https://github.com/elixirscript/elixirscript) is prior art here. I am not involved in this project, so I can't really answer to what design decisions they made, but it is interesting to compare with regardless.

Again, time will obviously tell how well all of this will work out, but from what we have seen thus far, our approach is fairly solid.

I am working on something similar but from a slightly different direction. The project is mainly focusing on compiler infrastructure for now, but I have a reference interpreter I use for validation. The short term goal is to make it able to run the erlang `compile` module. https://github.com/hansihe/core_erlang

I have worked with Elixir quite a lot, and I think I have a fair idea of how the language works in general, and how OTP apps are structured.

Even so, I find myself having the exact same issue as you are having when using Phoenix and Ecto. The way I like learning something new is by looking at something someone else has made. This gives me a much better view of how things are done than just reading getting-started guides and docs. I have looked, but I haven't found a lot of examples that actually applies to the latest versions of Phoenix and Ecto.

That's very true.

Do you think I should have written it differently? I might want to add a clause in the caveats section at the very least.

Thanks! I'll see if I can get something more written soon. Is there anything in particular you think I should prioritize?

Funny, the microcode assembler for my toy-cpu which is written in newbie-haskell is called the same thing. https://github.com/hansihe/ttl_cpu/blob/master/haskell/McAsm...

This is an example of the syntax it has. https://github.com/hansihe/ttl_cpu/blob/master/microcode/mic...

It, along with the assembler is configured through a yaml file. https://github.com/hansihe/ttl_cpu/blob/master/microcode/map...

If anyone is interested, there is an unfinished article about the project located here. http://hansihe.com/2016/11/25/i-built-a-computer-from-scratc...

Being a consumer magazine, a large part of the readership are probably gamers. It makes perfect sense to include a test of what users should expect if they buy the hardware for playing games.

Like it or not, game performance is a useful real-life metric for many consumers.

I did basically the same thing a couple of years ago.

https://cdn.rawgit.com/hansihe/CanvasEvolve/master/index.htm...

How does it detect renamed files in the filesystem?

Thank you for open sourcing by the way, I can definitely see how some features (binary file handling, submodule handling) could be useful for large-scale projects like games.

I have been working on a project for writing safe NIFs in Rust. I feel like I have the rough details of the API sketched out, but there is still work to do. https://github.com/hansihe/Rustler

There are still some rough edges on it, and if you see any obvious improvements, I would be more than happy to take suggestions or push requests :)

But there is no reason not to point it out. He made an observation about the drug dealers in his area, and mentioned it. I don't see why there would be anything more to it than that.