Interpreter crash when interpreting sourcefile about verona HOT 14 CLOSED

I'm aware that you should use

veronac main.verona --output a.out

And then use the interpreter to interpret the bytecode, but still :)

However, Inference is failing for method main() aswel,

 ~  veronac main.ver 
main.ver:2:5: error: Inference failed for method main
    main() { 
    ^~~~~~~~
1 error generated

 ✘  ~  cat main.ver 
class Main {
    main() { 
        Builtin.print1("Hello World!"); 
    }
}

from verona.

The interpreter runs on bytecode produced by the compiler:

veronac main.verona --output main.bc
interpreter main.bc

You are trying to interpet the source as bytecode. We haven't put checks in for that yet.

Your program should be

Builtin.print("Hello World!"); 

as there are no arguments other than the format.

from verona.

Ah okay, thank you :)

General question, I'd like to contribute to the project, is this possible or is this meant to be more of a "microsoft employee"-only thing?

from verona.

We are definitely keen to build a community and it is definitely not a Microsoft employee project: @plietar has the largest changes since we open sourced and is a student at Imperial College London.

But at this stage it we don't have many issues that are easy to give to new people. As the project grows, I hope that will change, and we will flag issues as good for new people.

Thanks for your interest.

from verona.

Alright, thank you very much!

from verona.

We should add some magic number at the start of the bytecode, and give a nice error message if it isn't found.

from verona.

We should add some magic number at the start of the bytecode, and give a nice error message if it isn't found.

I'm fairly confident that's how python identifies versions in their bytecode (pyc) files, it starts with some magic number that indicates the version.

from verona.

@Yuhanun If you want to get involved adding that to the bytecode format would be a useful feature.

from verona.

You might want to look into some representation of a prefix and elements that also allow for verification of the integrity of a pyc file, with the prospect of a digital signature. You want to know it is likely a pyc and also the version, I suspect. Might want to look into known magic-number schemes and avoid collisions too.

It doesn't have to happen immediately, but it is useful to anticipate it. On the edge of research use, but don't want it to be disruptive if not anticipated?

from verona.

Could I get some feedback on this:
https://nedbatchelder.com/blog/200804/the_structure_of_pyc_files.html

I was thinking:

4 bytes of verona specific magic number
12 bytes of verona version (MAJOR.MINOR.BUILD)
-- rest of bytecode.

Would you also like there to be a 64 bit timestamp (future-proof 8 byte instead of 4, 2037 isn't that far away 👀 )

from verona.

So we don't expect to support the interpreter long-term. Once we have built the native codegen, the interpreter is only expected to be used for compile-time evaluation.

Personally, I would like to just use a magic number at the start of the file to catch incorrect use of what we have. If we decide we actually want a versioned bytecode in the future, we just pick a new magic number.

64bit magic number would make sense to me.

@davidchisnall , @sylvanc thoughts?

from verona.

Oh, so the plan is to go to a native language? I thought this was going to be bytecode, but damn i would way prefer native.

Okay, so basically double the size of the magic number and then only validate that + remove the version numbers?

from verona.

The goal is to generate native code. I think a 64-bit magic number is fine for now. For anything that we actually intend to support longer term, we need to think about upstreaming libmagic support as well, but I don't think we should for the current bytecode.

from verona.

#81 closes this.

from verona.