Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

copy command #162

Merged
merged 33 commits into from
May 14, 2024
Merged

copy command #162

merged 33 commits into from
May 14, 2024

Conversation

JumpLink
Copy link
Collaborator

@JumpLink JumpLink commented Apr 11, 2024

This PR adds a new copy command to scan for *.gir files and copy them to a new directory. We want to use this to copy the newest GIR files found on the developer machines to this repository.

To copy all the latest GIR files from your machine into this repository just run yarn copy:girs .

Changes

  • Moved XML parsing to DependencyManager to be able to compare the library versions of the found dependencies
  • Allow glob patterns for GIR directories to search in
  • Allow glob patterns for GIR ignore list
  • New copy command
  • General clean-up like removing unused code
  • Split module loading and parsing to omitted the parsing for the list and copy commands
  • Logger output improved and more used
  • Compare GIR library versions and use the latest one
  • Copied the GIR files of my machine into this repository
  • Bump version 4.0.0-beta.3
  • Published ts-for-gir v4.0.0-beta.3 of this PR with the next tag
  • Published all generated types of this PR with the next tag
  • Added a helper shell script to find all Fedora packages which contains at least one *.gir file

@JumpLink JumpLink marked this pull request as ready for review April 15, 2024 20:03
@JumpLink
Copy link
Collaborator Author

I think I'll soon be finished with the copy command, the only thing missing is the library version comparison. @ewlsh maybe you would like to have a look at this PR? I'm sorry that it has become so extensive again 😅

@JumpLink JumpLink requested a review from ewlsh April 18, 2024 07:20
@JumpLink
Copy link
Collaborator Author

JumpLink commented Apr 18, 2024

@ewlsh Should be finished now, feel free to also update the GIR files from you machine into this PR or as soon as this is merged 👍

@JumpLink
Copy link
Collaborator Author

@ewlsh ping

@JumpLink
Copy link
Collaborator Author

JumpLink commented May 3, 2024

Positive feedback for the packages published of this PR on gjsify/gnome-shell#39 👍

.ts-for-gir.copy-all.rc.js Show resolved Hide resolved
examples/gjs/adw-1-hello/package.json Show resolved Hide resolved
@@ -0,0 +1,94 @@
/**
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we default to a list of directories based on XDG_DATA_DIRS and print what directories we are searching?

We could construct the shell and mutter directories based on the data directories too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already checking XDG_DATA_DIRS as long as no search directories are passed.

I'm happy to add logging for the search directories

@@ -88,49 +125,241 @@ export class DependencyManager extends GirNSRegistry {
: `import type ${namespace} from '${importPath}';`
}

protected async parseGir(path: string) {
Copy link
Collaborator

@ewlsh ewlsh May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caching the XML in my experience tends to lead to memory issues because you're caching massive strings for each library processed while the command is running. I don't think there is a need to cache the XML anymore, is there?

Copy link
Collaborator Author

@JumpLink JumpLink May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to parse the xml to extract the version number to compare the gir files for the copy command and so that I don't have to parse the xml again for the "real" gir parsing - I cache it, but after that we could delete it. Do you think that would make sense?

Copy link
Collaborator

@ewlsh ewlsh May 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would cache the version number itself, caching the XML structure or parsed XML adds a lot of memory usage which will/does require increasing node's memory limits. Reading from disk and re-parsing is not particularly expensive in the grand scheme of things.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I will implement it like this

packages/lib/src/utils.ts Show resolved Hide resolved
@@ -10,7 +10,7 @@ export class InterfaceVisitor extends GirVisitor {

if (!GObject) {
throw new Error(
`GObject.Object could not be found while generating ${node.namespace.name}.${node.name}`
`GObject.Object could not be found while generating ${node.namespace.namespace}.${node.name}`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the original was correct 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have another look, I think I had renamed the proboerty

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the slow turn around, I find this renaming a bit confusing. namespace.name matches the pattern elsewhere.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this is aligning the previous properties in GirModule which calls the prop namespace, I still find it confusing but I don't think this is a blocking issue.

@@ -5151,6 +5151,9 @@ If the value is 0, the number of lines won't be limited.</doc>
<type name="PreferencesRowClass" c:type="AdwPreferencesRowClass"/>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GIRs as a submodule might make sense in the future. types we usually have to update in MRs, but girs does not have as tight a dependency.

Copy link
Collaborator

@ewlsh ewlsh May 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively I think you can flag files as "binary" to avoid them spamming MR review but I'm not sure that is ideal unless we have a CI check that validates the GIRs are unedited.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it makes sense to move them to a submodule, I can do that

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe the gir files are also interesting for other projects (like we used the ones from vala), so I think a submodule would be useful

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good as a follow up

Copy link
Collaborator

@ewlsh ewlsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've left comments, the only one I think is high priority is avoiding caching the XML. But that could be done in a follow up MR given the length of this one.

@JumpLink
Copy link
Collaborator Author

@ewlsh That would be great, as I don't have much time at the moment, then this could already be merged and I will do that later

@JumpLink JumpLink merged commit 978c3b7 into main May 14, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants