Interpreter crash when interpreting sourcefile

[Yuhanun]

Title says a lot:

 ~/g/verona_test  verona-interpreter main.verona 
terminate called after throwing an instance of 'std::logic_error'
  what():  Instruction overflow 6 8307
fish: “verona-interpreter main.verona” terminated by signal SIGABRT (Abort)

class Main {
    main() {
       Builtin.print2("Hello World!"); 
    }
}

[Yuhanun]

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!"); 
    }
}

[mjp41]

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.

[Yuhanun]

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?

[mjp41]

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.

[Yuhanun]

Alright, thank you very much!

[plietar]

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

[Yuhanun]

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.

[mjp41]

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

[orcmid]

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?

[Yuhanun]

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 👀 )

[mjp41]

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?

[Yuhanun]

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?

[davidchisnall]

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.

[mjp41]

#81 closes this.