chore: relocate tm2/std.MemFile in gnovm/std

[moul]

This PR removes "gno.land" from all tm2/.../*.go files.

[codecov]

Codecov Report

Attention: Patch coverage is 86.11111% with 5 lines in your changes missing coverage. Please review.

Project coverage is 63.59%. Comparing base (a478348) to head (9104fe6).
Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
gno.land/pkg/keyscli/run.go	66.66%	1 Missing ⚠️
gno.land/pkg/sdk/vm/keeper.go	0.00%	1 Missing ⚠️
gnovm/pkg/gnolang/machine.go	75.00%	1 Missing ⚠️
gnovm/pkg/gnolang/nodes.go	83.33%	1 Missing ⚠️
gnovm/pkg/gnolang/store.go	85.71%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2910      +/-   ##
==========================================
+ Coverage   63.39%   63.59%   +0.19%     
==========================================
  Files         565      566       +1     
  Lines       79457    79614     +157     
==========================================
+ Hits        50375    50633     +258     
+ Misses      25691    25589     -102     
- Partials     3391     3392       +1     

Flag	Coverage Δ
contribs/gnodev	60.57% <ø> (ø)
contribs/gnofaucet	14.82% <ø> (-0.95%)	⬇️
gno.land	67.37% <77.77%> (ø)
gnovm	67.87% <87.50%> (+<0.01%)	⬆️
misc/genstd	79.72% <ø> (ø)
tm2	62.41% <100.00%> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[moul]

I chose to create gnovm/pkg/std, but we should consider merging it with gnovm/pkg/stdlibs/std. What do you think?

I removed the .pb.go files that were added forcefully. Should I revert this change?

[thehowl]

I have a more general question - why do we name anything std? Is there any standard involved?

[moul]

I have a more general question - why do we name anything std? Is there any standard involved?

Right now, we refer to these as "lowest level types." The closest name we have is "sys," and the system contracts are currently named "r/sys." We also considered naming them "r/std." Essentially, this serves as our standard for low-level system components.

In this repository, we have three standard packages designed to be imported to connect with the components without loading other parts (lightweight, no side effects).

An alternative for the Go side would be to rename them to "types." However, it's important to distinguish between "system/low-level types" and "all types." One invites connection with a minimal API (communication layer), while the other is more internal and advanced.

I'm open to reconsidering a renaming, although I believe we will likely prefer to stick with the current approach. My question is about balancing independence with unifying gnovm's standard messages.

[moul]

By the way, the relocation is complete, and the CI is green. I have two other PRs in mind that will depend on merging this one. Please feel free to review it, and we can discuss the "naming" topic later, maybe.

[moul]

Discussing the naming with @gfanton.

Another suitable location for MemFile and MemPackage could be directly in the gnovm/pkg/gnolang package, as they are frequently used by gnovm. However, since we are considering splitting this package, the question arises: "If the type was initially implemented in gnovm, what would be a good location if we split it?"

[zivkovicmilos]

Let me take a peek at this before merging please 🙏

[gfanton]

I also feel that std can be confusing due to its use everywhere.

@moul, what do you think about simply prefixing the package name (not the structure, as mentioned in the review meeting) like std to stdsys (or std-sys), for example? Even if it seems redundant in the package path, it could enhance file and import readability.

In any case, I don't believe we should block this PR for this, as it's not a regression. Let's open an issue so we can revisit this later.

[moul]

TODO: relocate to gnovm/types.go.
Edit: done.