search

rockobonaparte / cloaca

A deranged attempt at a Python 3 bytecode interpreter in C# with green threading and state serialization.
4 stars 1 forks source link

Solution Found :-) #4

Closed GeorgeS2019 closed 2 years ago

rockobonaparte commented 2 years ago

Maybe "discovered" is a better term than "found" because it even took me a bit to figure out what was going on.

(for anybody reading later: the supporting ANTLR generation had to be created before just about anything else)

Now I have to figure out where I should make a note about that. Is there anywhere you looked in the project before filing the issue? Wherever you tried to look for it is probably where I should put a note about it lol.

GeorgeS2019 commented 2 years ago

@rockobonaparte thx for replying back so soon.

For Windows, I need to install Visual Studio ANTLR Extension. Then the build will work.

It is still not straight forwards, as the 6 files created are linked from Language/bin/obj back to LanguageInterpretation GeneratedFile folder.

It is a symbolic link.

This is something that still preventing straight forwards compiling using VS2019 ...

Problem still not solved. It is solved as I need to install the ANTLR VS2019 extension

rockobonaparte commented 2 years ago

I think I was going to run into this when I started doing some kind of automated QA on the code. I haven't gotten that far yet because I want the get some more FAANG coding interview examples to run successfully. At that point, I'd get whacked trying to build it in a fresh environment.

I'll have to figure out what to do about the extension. I don't think I can reference NuGet dependency and just have it solved from that; there's probably an implicit VS2019 restart somewhere in there. So it might be a mix of things.

rockobonaparte commented 2 years ago

I gave this all a courtesy paragraph in the thing I'm acting as if it was a manual: https://github.com/rockobonaparte/cloaca/blob/master/manual.md#building-the-project

I'll have to fight this by the horns when I start doing that automated QA. I'm hoping to get some more integration tests passing first to make it worthwhile, so I haven't started that yet.

GeorgeS2019 commented 2 years ago

@rockobonaparte This repos is not just a .NET python interpreter, but a meeting place for people who simply refuse to say "NO" :-)

GeorgeS2019 commented 1 year ago

@rockobonaparte

I revisited your progress :-)

I ported the following projects to .NET6

Most tests passed except the following. Any suggestion?

image

GeorgeS2019 commented 1 year ago

You have not included any license?

rockobonaparte commented 1 year ago

I'm using PSF license since I have been aping their stuff so much. It's BSD style and shouldn't be constraining. I went with it since I reference CPython so much and have some of its code in my imports now.

I might be interested in .NET 6 but I have to see what Unity 3d has been up to. If they up'd their runtime then I will probably join that bandwagon. I wouldn't be surprised if the CLR importing mechanisms got goofy between 5 and 6.

GeorgeS2019 commented 1 year ago

Do u know Godot, fully.NET6

rockobonaparte commented 1 year ago

I heard of it. I have a bunch of tooling in Unity though.

I still haven't really seen what .NET version Unity supports nowadays (if it was actually updated in the past, like 1.5 years or so). This might be a case if using #if preprocessor stuff to do different stuff with a newer .NET version.

GeorgeS2019 commented 1 year ago

I heard of it. I have a bunch of tooling in Unity though.

I port stuff in Unity to Godot. Just follow a few youtube videos (Godot from Unity3D users) and U will find enlightenment :-)

rockobonaparte commented 1 year ago

So I looked up the .NET 6 thing and I'm absolutely unsurprised that stuff like the CLR importer screwed up. If the .NET integration generally wasn't also completely broken, then that's more of a surprise. I hadn't been following what was going on with the different .NET runtimes and didn't know about .NET 6 being a new merge of .NET Core and .NET Framework. So that probably wrecked something in how assemblies are loaded. I'd have to go into that with a nice block of free time, and the solution would probably just be a bunch of #if clauses.