gabrieldemarmiesse Posts - Answer Overflow

gabrieldemarmiesse

•Created by gabrieldemarmiesse on 1/26/2024 in #questions

How to do recursive structs?

I'm trying to implement a json decoder, but I can't even make a struct that will hold the result. Here is the code I'm trying to run:

from stdlib_extensions.builtins import list, dict, HashableStr
from collections.optional import Optional

@value
struct JsonObbject(CollectionElement):
    var possible_list: Optional[list[JsonObbject]]
    var possible_dict: Optional[dict[HashableStr, JsonObbject]]
    var possible_int: Optional[Int]
    var possible_string: Optional[String]

from stdlib_extensions.builtins import list, dict, HashableStr
from collections.optional import Optional

@value
struct JsonObbject(CollectionElement):
    var possible_list: Optional[list[JsonObbject]]
    var possible_dict: Optional[dict[HashableStr, JsonObbject]]
    var possible_int: Optional[Int]
    var possible_string: Optional[String]

I get the error:

/projects/open_source/mojo-stdlib-extensions/trying_stuff.mojo:6:38: error: 'list' parameter #0 has 'CollectionElement' type, but value has type 'JsonObbject'
    var possible_list: Optional[list[JsonObbject]]
                                     ^~~~~~~~~~~
Included from /projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/__init__.mojo:1:
/projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/_generic_list.mojo:21:1: note: 'list' declared here
struct list[T: CollectionElement](Sized, Movable):
^
/projects/open_source/mojo-stdlib-extensions/trying_stuff.mojo:7:51: error: 'dict' parameter #1 has 'CollectionElement' type, but value has type 'JsonObbject'
    var possible_dict: Optional[dict[HashableStr, JsonObbject]]
                                                  ^~~~~~~~~~~
Included from /projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/__init__.mojo:5:
/projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/_dict.mojo:60:1: note: 'dict' declared here
struct dict[K: HashableCollectionElement, V: CollectionElement](Sized):
^
mojo: error: failed to parse the provided Mojo

/projects/open_source/mojo-stdlib-extensions/trying_stuff.mojo:6:38: error: 'list' parameter #0 has 'CollectionElement' type, but value has type 'JsonObbject'
    var possible_list: Optional[list[JsonObbject]]
                                     ^~~~~~~~~~~
Included from /projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/__init__.mojo:1:
/projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/_generic_list.mojo:21:1: note: 'list' declared here
struct list[T: CollectionElement](Sized, Movable):
^
/projects/open_source/mojo-stdlib-extensions/trying_stuff.mojo:7:51: error: 'dict' parameter #1 has 'CollectionElement' type, but value has type 'JsonObbject'
    var possible_dict: Optional[dict[HashableStr, JsonObbject]]
                                                  ^~~~~~~~~~~
Included from /projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/__init__.mojo:5:
/projects/open_source/mojo-stdlib-extensions/stdlib_extensions/builtins/_dict.mojo:60:1: note: 'dict' declared here
struct dict[K: HashableCollectionElement, V: CollectionElement](Sized):
^
mojo: error: failed to parse the provided Mojo

It Seems that Mojo doesn't like the recursivity of my struct. It it something that should be reported or am I misunderstanding something?

3 replies

MModular

•Created by gabrieldemarmiesse on 1/15/2024 in #questions

In which situation are IntLiteral, FloatLiteral, StringLiteral useful?

I know those refer to the type use by the compiler, and they mean that they are compile time constant. But it seems to interfer with the alias/var distinction. The constness isn't really clear here. It seems to me that those type are just compiler implementation details. If we use alias and that the compiler cast automatically IntLiteral to Int, FloatLiteral to Float and StringLiteral to String, we don't loose anything (since those can be used in compile-time with alias), or am I missing something? If those types are not useful in the language, should we remove them? In all my programs, I always cast them to the conrresponding runtime types, even if the value is known at compile time. I guess the more general question is "in which situations is the decorator @nonmaterializable https://docs.modular.com/mojo/manual/decorators/nonmaterializable.html useful?"

38 replies

MModular

•Created by gabrieldemarmiesse on 10/20/2023 in #questions

What kind of tools do people use to profile Mojo binaries?

I tried using "perf" but I had no luck displaying the symbols, I only see exadecimal values. Did someone make a tutorial somewhere? I'd be interested 🙂

1 replies

MModular

•Created by gabrieldemarmiesse on 10/16/2023 in #questions

Should we fuse Python's array class and mojo's DynamicVector's struct?

They are extremely similar. Here is the documentation for array: https://docs.python.org/3/library/array.html Here is the documentation for DynamicVector: https://docs.modular.com/mojo/stdlib/utils/vector.html#dynamicvector With just a few more attributes and methods, Python's array could become a DynamicVector. If Mojo wants to be a good member of the Python family, maybe we should not reinvent what's already in the stdlib.

4 replies

MModular

•Created by gabrieldemarmiesse on 10/10/2023 in #questions

Will mojo let third parties handle the compiler distribution and packaging like python?

The cpython core team and steering council has the responsability of providing the source code but not to distribute it. It also doesn't have the responsability of defining how the packaging should be done. This is a huge issue as third parties must implement tools to do this and there are many different tools now. Let's take for the installation: - anaconda - the py installer on windows from the windows store - the installer from the python.org website - rye - deadsnakes - pre-installed python in ubuntu - ... Since there is no solution that is "blessed" by the core team, newcomers don't understand how to install Python. Python.org just provide the source code and no installer on linux for example (python beginners have to compile python themselves.😰 ) There is also no tool to change easily the version of python (anaconda does it but it doesn't work with Pypi). For the packaging of the code, many tools are available: - poetry - anaconda - pyproject.toml - setup.py - pip tools - pip - twine - ... Navigating among all those tools for non-experts is very hard. Let's be honest, it's hell for beginners who usually want one "blessed" solution that works well and satisfy 95% of use cases. For the extreme use cases, third party tools should be available. I know experienced (4y+) Python devs who are unable to make multiple packages depend on each other inside a monorepo because there is no clear standard. They are unable to change python versions without destroying their whole dev environment. Can Mojo take example on rust which seems to be the gold standard for distribution and packaging?

8 replies

MModular

•Created by gabrieldemarmiesse on 10/2/2023 in #questions

Provide a optional pure-python mode like Cython does to ease code sharing?

I have my Python library maintainer hat here. It would be cool to support both Python and Mojo (with speedups from struct & other) within a single wheel on Pypi, but without having to provide a Python extensions (which are harder to distribute) and without duplicating all the code. Cython already solves this problem with pure-python mode. Maybe let's steal those ideas? I made a discussion about it on github but I didn't get much attention there: https://github.com/modularml/mojo/discussions/922 What do you think? Maybe it could be a metaprogramming third-party lib?

5 replies

Gaming

Programming