martinvuyk

I'm sorry I'll be more concise: Easy and intuitive interoperability between the UIntX types would be nice ``` var n0 = UInt8(0) var n1 = UInt8(0xFF) var n3 = UInt8(3)...

I also tried executing the MatMul example with 500 matrices and it only uses 4 threads. Output of `lscpu` for more info: ``` Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Address...

Used the matmul example to compile and `objdump -d` but I definitely can't read pthread assembly. Here is the code and how I removed vectorization and attached is the output...

Hi, a bit late to the party but won't doing something like adding a conditional conformance overload to eq work ? i.e. `fn __eq__(self: Scalar[type], rhs: Scalar[type]) -> Bool:`

> i was confusing it with having condition `__bool__()` conformance like that, hah.. Well I guess it could be used for that too ? But you wouldn't have the nice...

> This is still WIP internally, running into some compiler issues. ok, just to clarify since I'm practically new to OSS should I keep merging to nightly when it changes...

> self.find(key) has already unit tests. But get(self, key: K, default: V) -> V doesn't have unit tests yet. Maybe you can add a few unit tests for this function...

Added a short and simple unit test, `Dict.find()` didn't have one. Bunched both (find & get) in the same test since they are aliases for each other

>I don't think file should really have a bidirectional iterator. deleted it >I think we should implement a iterator object like [_Listiter](https://github.com/modularml/mojo/blob/00528f4c44f799966b3da0a866a00e24370c4b59/stdlib/src/collections/list.mojo#L44) instead of using List. I'm trying to get...

Currently this is what's in `/stdlib/src/builtin/_stubs.mojo` ```mojo trait _IntNext(Copyable): fn __next__(inout self) -> Int: ... trait _IntIter(_IntNext): fn __len__(self) -> Int: ... trait _IntIterable(_IntIter): fn __iter__(self) -> Self: ... trait...