Re: crash in GUI / ProjectCenter
> Am 10.01.2023 um 18:37 schrieb Riccardo Mottola : > > Your fix appears to work > > > I still wonder if the bug is in GNUstep which shouldn't be "picky" about this > delegate or something done in ProjectCenter is fishy, something with the > editor instantiation. > > Observations: > 1) open a project. Do not select any file. There is already a splitview with > a generic text scroll view at the bottom. Yet closing the project window now, > does not cause issues > 2) open a project. select a file so that the editor opens. then from the menu > do "close file", the status of 1) returns... and closing makes no issues > 3) the fact that nilling the splitview delegates "macht mich stutzig" I've seen the very same crash that you reported happen in another application, so I'm fairly confident it is a GNUstep bug. :-) It seems difficult to reproduce, though. I've seen the crash happen with that other application only when quitting the application with sufficiently many Windows still open. Just closing a single window works fine. It also happens on Debian 11 under Gnome but not on OpenSUSE with KDE. But then, triggering the bug seems to involve at least one race condition, namely that the Window manager sends an event to the Window after it has been closed from the UI, but while its backend connection is still alive (and also while the delegate of the split view has gone already). I'm not so sure about my suggested fix/hack. Certainly, it does the job and I don't see a reason why a window should be updating its cursor rectangles after the window has been closed (at least if it is supposed to be released at that point). Another option would likely be to close the backend connection more swiftly when a window is closed. For instance, in -[NSWindow orderWindow:relativeTo:] we might change the last condition from else if ([self isOneShot]) to else if ([self isOneShot] || (_f.has_closed && _f.is_released_when_closed)) to close the backend window immediately rather than waiting for this to happen from an autorelease pool. One thing that is worrying is that you saw a crash even when resetting the delegates in the dealloc method. The stacktrace looks like -[NSWindow resetCursorRects] gets called for a window with a corrupted view hierarchy where a child window seems to have been deallocated while it is still present in the hierarchy. This is something that should never happen (at least not where sendEvent: can possibly be called). So maybe there is some other memory management bug at play here. Wolfgang
Re: Releases
On Tue 10 Jan 2023 at 19:43, Frederik Seiffert wrote: > > Am 10.01.2023 um 14:27 schrieb Ivan Vučica : > > I really would like to minimise the number of steps we have to go through >> by automating as much as possible. > > I did. :-) > > Please see my release jottings on Google Docs. They’re not formal > documentation, but can be interpreted as a playbook with some reading. > > > I’m not familiar with what needs to be done for releases (can you share a > link to that Google Doc maybe?), but I’m wondering if released could be > mostly automated on the GitHub Actions CI. > Mainly because it is a mess and it’s mainly my notes on what I did + to share with maintainers, I am not keen on making it publicly visible. If it were to be a playbook, I’d put it up somewhere in repos as proper documentation. However, I’ve added your corporate email address to the ACL for the doc for 2.9.0/1.28.0/0.29.0 release of ~March 2021: https://docs.google.com/document/d/1DGumTDgxGwsaamnFvJ5WI1puVHHKk2f1t7GNrwLHfi0/edit?usp=sharing I can add other interested maintainers to these docs, but again, there’s no point in making this more visible if it’s just notes and not proper documentation. I’ll see if I can turn this into something more widely shareable (maybe once I finally upgrade the wiki schema on the new gnustep.org machine…). > For the Android and Windows MSVC toolchains, every build on the master > branch creates a pre-release on GitHub (overwriting the previous one), and > then if I want to do a release I test the latest build and then simply > add/edit the change log and check a box to turn it into a release (which > also creates a corresponding git tag). Here’s the required Actions code: > > > https://github.com/gnustep/tools-android/blob/d71de40e60f71988b40610e39b5df926e6df1687/.github/workflows/ci.yml#L57-L84 > > In this case, the "prerelease" step will wait for the two builds (macOS > and Linux) to complete, and then create a "Latest Build" pre-release on > GitHub with the artifacts for the two platforms. > I think it makes sense if you’re doing binaries, but less so if most of the tedious process is actually getting documentation (release notes…) in shape, and invoking the correct commands to create the tag in the first place (using the release notes in the tag). -- Sent from Gmail Mobile
Re: Releases
On Wed 11 Jan 2023 at 10:25, David Chisnall wrote: > > This is on my to-do list for the runtime. It's something that we're > doing with other projects and it means that the release process is just > creating a tag. This then builds releases for any targets that we want > to ship binaries for, creates the GitHub release, pushes the built > artefacts to the release, and adds a new commit on the main branch > rolling over versions and so on. > > David There’s the GPG signing part that makes Github Actions less useful. That is: whether you want to use Github actions depends on where you want to store this rather secret key. (We should rotate the GPG key anyway, by the way; the one we use for gnustep make/base/gui/back is still a 1024 bit key, with no delegation to subkeys and no expiration dates set.) Besides, making the tarballs themselves is the easiest part. For the make/base/gui/back stuff, the hardest for me was going through the history, trying to make sense of everyone’s rather cryptic commit messages and rather lacking ChangeLog updates, identifying and summarizing the changes into something that might be useful to a reader, putting the changes into 2 different places, then generating the new release notes file. If I recall correctly, I touched up gnustep-make so invoking the magic git release commands will produce the correct annotated tag containing the release notes file as the tag’s commit message (meaning I have no need to do anything on Github releases page to make this text show up). But at that point, building the tarballs and signing them is easy. Uploading them to Github is just a drag and drop. Uploading them to FTP (…and I really need to sit down and bring it up on the ‘new’ DigitalOcean machine, but in a more secure way than using a password over unencrypted FTP) is easy. Writing release notes and dealing with GPG’s rejections of the passphrase on the key is difficult. I never fully completed the work on our own Debian packages so there’s no point in having Github Actions for that particular purpose. Besides, Debian ‘source’ packages also need to be GPG signed. (Note, I am not talking about the code we want to upstream into Debian proper; this would be ‘our’ packages, built with libobjc2 and clang, and preferring ‘steppiness’ over FHS. It was not to be about making them better than Debian-built packages, but about providing a different experience. And maybe adding a ‘defaults’ package that configures a different theme and such.) What about win32? I never built win32 releases with NSIS, either. There have been improvements on building .msi packages on free platforms (GNOME’s msitools have gotten some GUI support!), but last time I checked, it was still not sufficiently similar to WiX Tools on Windows. -- Sent from Gmail Mobile
Re: Releases
On 11/01/2023 10:40, Ivan Vučica wrote: There’s the GPG signing part that makes Github Actions less useful. That is: whether you want to use Github actions depends on where you want to store this rather secret key. (We should rotate the GPG key anyway, by the way; the one we use for gnustep make/base/gui/back is still a 1024 bit key, with no delegation to subkeys and no expiration dates set.) This should be stored in a GitHub Secret and not stored on anyone's machine. It is then exposed only to the release pipeline and compromising your dev VM does not leak it. Besides, making the tarballs themselves is the easiest part. It's not easy, it's free. Every GitHub commit is automatically exposed as a tarball via a special URL, you don't need to do anything with it. For the make/base/gui/back stuff, the hardest for me was going through the history, trying to make sense of everyone’s rather cryptic commit messages and rather lacking ChangeLog updates, identifying and summarizing the changes into something that might be useful to a reader, putting the changes into 2 different places, then generating the new release notes file. For the runtime, I have an `ANNOUNCE` file containing markdown that is updated with things that will go in the release announcement as they're added. I then just copy it to the release text. What about win32? I never built win32 releases with NSIS, either. There have been improvements on building .msi packages on free platforms (GNOME’s msitools have gotten some GUI support!), but last time I checked, it was still not sufficiently similar to WiX Tools on Windows. For the runtime, I use CMake's CPack support, which produces a zip file that can just be extracted on Windows and used. It can also produce NuGet packages if you want to manage dependencies like that. GNUstep Make makes all of this much harder (running GNUstep Make on Windows at all is sufficiently painful that I've never managed it successfully). David
Re: Releases
On 10/01/2023 19:42, Frederik Seiffert wrote: I’m not familiar with what needs to be done for releases (can you share a link to that Google Doc maybe?), but I’m wondering if released could be mostly automated on the GitHub Actions CI. This is on my to-do list for the runtime. It's something that we're doing with other projects and it means that the release process is just creating a tag. This then builds releases for any targets that we want to ship binaries for, creates the GitHub release, pushes the built artefacts to the release, and adds a new commit on the main branch rolling over versions and so on. David
