-
Notifications
You must be signed in to change notification settings - Fork 18
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
copy command #162
Conversation
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 😅 |
@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 👍 |
@ewlsh ping |
Positive feedback for the packages published of this PR on gjsify/gnome-shell#39 👍 |
@@ -0,0 +1,94 @@ | |||
/** |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -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}` |
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"/> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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.
@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 |
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
copy
commandlist
andcopy
commands4.0.0-beta.3
ts-for-gir v4.0.0-beta.3
of this PR with thenext
tagnext
tag