Alex Kirchhoff Comments - Answer Overflow

Topics

Alex Kirchhoff

•Created by Shaun Kulesa on 12/16/2023 in #questions

How to build the mojo packages for my hardware?

What kind of hardware are you talking about? We have not yet open sourced Mojo (though per the FAQ, this is expected to change in time), so it's not currently possible to build Mojo yourself, but the packages we release, while specific to a particular OS and instruction set, should be generic to different kinds of processors implementing that instruction set.

3 replies

•Created by Naroxar on 12/16/2023 in #questions

simd_load of Tensor with StaticIntTuple

simd_load will always load a contiguous range of values from the input tensor. The StaticIntTuple overload is intended to reference different dimensions of a multidimensional tensor, not different elements of a gather. For example, if you had an NxHxWxC tensor representing an image (e.g., 1x448x448x4), you could index it with a StaticIntTuple[4](0, 100, 100, 0) and simd_load[4] to get the 4 channels at batch=0, x=100, y=100 location in the image. The documentation could probably be clearer about this.

2 replies

•Created by Moosems / Three chickens on 12/16/2023 in #questions

c++ interop in executables

The Mojo compiler driver currently does not support linking in any other native code. There is nothing fundamental blocking this, and this is likely to change in the future, but for now, this is not possible.

6 replies

•Created by HybridRobotix on 12/5/2023 in #questions

Mojo on ARM?

It is too early to say, but I don't think there's anything special about Ampere that would prevent a general AArch64 release from running on it.

17 replies

•Created by HybridRobotix on 12/5/2023 in #questions

Mojo on ARM?

We'd love to be able to target it too, and in time, I think we will -- it's a matter of timing. We can only focus on so many things at a time, and right now our focus is on other platforms. As our release process becomes more mature, I think an ARM Linux Mojo SDK will be likely, but I can't provide a timeline.

17 replies

•Created by DisappointingSalad on 12/12/2023 in #questions

Is StringLiteral intended for handling c strings?

StringLiteral is the type of Mojo string literals, and does not have a stable ABI representation. It should not be used for FFI. Pointer[Int8] is probably the right type for FFI. But after you've got the pointer, there are easier ways to interact with it that don't require copying. If you have a Pointer[Int8] named p, you can easily convert it to a StringRef with StringRef(p). StringRef is easy to interact with and works with many APIs. If you do want to copy it into a String, that becomes trivial as well: String(StringRef(p)).

2 replies

•Created by alvinjrush on 12/10/2023 in #questions

Unable to implement matrix multiplication on a large matrix

free(): corrupted unsorted chunks usually indicates some sort of memory corruption. This could either be a bug in your code or a bug in Mojo. Double check your code, and if you think it is a Mojo issue, please file an issue on GitHub at the link provided in the error message.

2 replies

•Created by Henk-Jan Lebbink on 12/8/2023 in #questions

What would be the target-triple to cross-compile for Graviton.

I believe Graviton's usual target triple is aarch64-linux-gnu. But I expect this to be of little use, since last time I checked, our LLVM builds only include the native architecture -- we do not formally support cross compilation yet. Our ARM benchmarks are through compiling and running Mojo natively on ARM. These packages are not publicly available at this time, though I expect they will eventually become available (though I have no timeline).

3 replies

•Created by HybridRobotix on 12/5/2023 in #questions

Mojo on ARM?

W.r.t. "hefty", I am mostly thinking of memory -- I know we had reports that the language server was running out of memory when people had less than 16 GB of memory available to them. Mojo runs great on Graviton (although we have not released the packages for it yet), so I expect it would also run great on e.g. a Jetson device with 16 GB, as you mention. In time, I expect packages to be available for ARM. But we want to make sure we are adequately resourcing QA and documentation etc. to ensure people have clear expectations of requirements and a good experience using it. We will probably get to that eventually, but our focus is currently elsewhere.

17 replies

•Created by gryznar on 12/3/2023 in #questions

Error handling like in Rust

Yes, this is how exceptions are currently implemented.

11 replies

•Created by Henk-Jan Lebbink on 12/5/2023 in #questions

Compilation does not terminate for recursive function

I believe @parameter if in Mojo is quite similar to if constexpr in C++ -- does that work?

3 replies

•Created by HybridRobotix on 12/5/2023 in #questions

Mojo on ARM?

To my knowledge, we have not released any ARM Linux Mojo SDK packages at this time. It is likely we may release some in the future, though I do not have a timeline. They are pretty hefty as well -- at present, they are best suited to larger ARM systems like Graviton. It is possible they could work on smaller systems too but we have not tested it and we are focused on other deployment targets at the moment.

17 replies

•Created by gryznar on 12/3/2023 in #questions

Error handling like in Rust

Maybe. I am not involved with the planning here.

11 replies

•Created by JIMC on 12/4/2023 in #questions

Trying to do compile time checking with 'const' type arguments.

I responded in the issue, but the direct cause of the error on the get line is because Secret is not register-passable, but Tuple only works on register-passable types at the moment. And given the purpose of Secret, you wouldn't want it to be register-passable, so your best shot is to avoid Tuple for now and make your own similar type.

11 replies

•Created by JIMC on 12/4/2023 in #questions

Trying to do compile time checking with 'const' type arguments.

For clarity, which Mojo version are you running this under?

11 replies

•Created by gryznar on 12/3/2023 in #questions

Error handling like in Rust

If a cpython function is called and it throws an exception, I'm not sure how mojo would handle this.

Mojo supports try/except on functions decorated with the raises keyword (see e.g. https://docs.modular.com/mojo/manual/basics.html#python-integration), and this is used for the Python interop. This is a rather primitive mechanism at present. I am not familiar with plans for the future of error handling in Mojo.

11 replies

•Created by Pints'OPurpo on 12/2/2023 in #questions

Generating a new auth key

@Sigma I think you'd know best -- is this possible?

3 replies

•Created by mikegarts on 11/27/2023 in #questions

Casting between DTypePointer[DType.uint8] and Pointer[UInt8] ?

Oops, good catch. The type of address actually changed in-between the last Mojo release and the unreleased version I had been looking at. So as of the next Mojo release, it should work as I described. In the mean time, I believe you should be able to use bitcast[SIMD[DType.uint8, 1]](ptrd.address). I haven't tested this since I don't have the last-released Mojo installed at this time. But this workaround should become unnecessary once the next Mojo release comes out, which I believe should be soon.

5 replies

•Created by mikegarts on 11/27/2023 in #questions

Casting between DTypePointer[DType.uint8] and Pointer[UInt8] ?

If you have a DTypePointer value p, you can turn it into a normal Pointer with p.address. It's not super obvious but you can find this under "Fields:" here: https://docs.modular.com/mojo/stdlib/memory/unsafe.html#dtypepointer To go the other way and create a DTypePointer from a Pointer, use the appropriate constructor, e.g. to convert a Pointer p to DTypePointer[DType.float32], use DTypePointer[DType.float32](p).

5 replies

•Created by Kushagra on 11/27/2023 in #questions

Modular CLI Progress Bar

This is a good idea. Please file it on GitHub at https://github.com/modularml/mojo/issues/new so we can track it.

5 replies