Migrate pt-run to a complete Lua frontend

[singul4ri7y]

Changelog:

• Migrate pt-run to pt-lua, which acts like a complete Lua frontend with our custom traceback function being the default one.
• Add -isystem flag in CPPFLAGS of Makefile, because if Lua and Lua internals are installed in the same machine, sometimes compiler finds it troublesome regarding which Include directory to use, /usr for Lua or /usr/local for Lua internals. Maybe don't need this if Lua internals always copes up with the upstream Lua version, but I would like to keep it just incase. Noteworthy to mention, using -I won't do.
• Update tracebacks tests, removing the change directory to each tests. Makes the tracebacks inconsistent (module traces having path prefix where Lua traces does not) in the tests and also unnecessary now that we don't have separate Makefiles to take care of.

Resolves #13

[hugomg]

Since renaming pt-run is an API change that will break Pallene builds, can we implement pallene-tracer version numbers before we merge this?

[singul4ri7y]

Let's do it after we are done stabilizing it? We are almost done tbh

[singul4ri7y]

I think we better merge this after Lua internals and Pallene is bumped up to Lua 5.4.7.

[hugomg]

Agreed on merging this after 5.4.7

As for the version numbers, I suppose we might as well do it now? We already had unrelated Pallene PRs breaking because of ptracer API changes.

[singul4ri7y]

Yes, let's do version tagging after this merge. I will come up with commits fixing the nits tomorrow. We won't be releasing on this tag though. Also it would be wise to mark the tag as alpha if possible.

[hugomg]

The problem is that since we switched Pallene to use the separate pallene tracer repo, any changes we make here break the CI on all the Pallene PRs, including that one that Gabriel is working on. Can we please do the version numbers first?

[singul4ri7y]

Fine by me. But it would have been great if we had atleast pt-lua. If version numbers can wait one more day, I can complete this PR and then can do version numbering.

[hugomg]

I'm still not convinced about the -isystem. I have never seen that in a makefile. The -I ought to have been sufficient? What do you mean by headers are not properly resolved? Have you tested using LUA_PREFIX=/usr/local?

[singul4ri7y]

Have I tested with LUA_PREFIX=/usr/local? Yes.

It does not work, simple as that. There is nothing to be convinced about. the -I prefix supposed to append the dir to the leftmost (or topmost) header searching path string, but clearly the verbose logging I showed you earlier does not follow that. I also have double checked for multiple times, it does not work.

[hugomg]

In the verbose logging, you use -I/usr/include and -L/usr/lib compilation flags. Why wasn't it /usr/local?

[singul4ri7y]

@hugomg Again, that's not the point. I used it because in my case if I wanted to compile pt-lua against my system Lua. It was still grabbing Lua internal headers from /usr/local/include, the -I was not working. So, I had to switch to -isystem for that. Now, the situation can be very well vice versa, say you have a backdated Lua in your system that you want to compile against and a newer version of Lua is installed in /usr/local.

By the way, using /usr/local was still giving me errors, because as usual with -isystem the /usr/local was getting resolved first.

[singul4ri7y]

I highly suggest that you try the -isystem flag yourself. Also try having Lua internals 5.4.6 with you, that would make my point aloud.

[hugomg]

That is not a configuration that we have to support. The C header file include system is not designed to handle using ptracer from usr/local but then not using the Lua from /usr/local. If the user really wants to do that, they should install lua-internals and ptracer to different prefixes.

[singul4ri7y]

I am not convinced. The -I flag is not clearly working as the documentation suggested. Moreover, users won't be using our Makefile to build other projects, so I think the flag is fine. If the -I flag works as intended, we may change it back.

As for prefixes. I am pretty much sure users won't like to make their life a hassle by installing to a different prefix and adding it to their path just for a single goddang flag, which is not total taboo.

[hugomg]

Consider adding version numbers before merging this.

[singul4ri7y]

Should we create version tag after merging this? Because regardless, we have to make changes to Pallene with another PR.

[hugomg]

We're overdue for a version tag Em 14 de ago. de 2024 9:24 AM, SD Asif Hossein ***@***.***> escreveu: Should we create version tag after merging this? Because regardless, we have to make changes to Pallene with another PR. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>