-
Notifications
You must be signed in to change notification settings - Fork 68
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
fix: #listAtCategoryNamed: has been deprecated in Pharo 12 #606
Conversation
4093e06
to
0f9ddae
Compare
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.
LGTM.
Unfortunately, the Pharo stable builds almost always segfault. I didn't manage to get a clean run of all builds. |
Is this due to a new and fault VM? It's not related to your changes, right? Maybe we need to inform the VM maintainers and mark the test as allowed to fail? |
I'm pretty sure it's not my fault. Since the Pharo-alpha builds are good, I suspect that the VM used for stable builds really has an issue that has been fixed upstream. |
smalltalkCI uses zeroconf scripts to pull the VM, so this is out of our control. Any suggestion how we could proceed? |
It's weird. Looking at the builds, the one's for Pharo 11 (explicitly) are fine, the one's for "stable", which is Pharo 11, are not. But since we have both builds anyway, I suggest removing the "stable" builds. Also, I'm not sure how much sense it makes to test newer versions against the 32-bit VM. We could say that we only support 64-bit explicitly as of Pharo 12 (usually, 32-bit will be fine). That will reduce the number of additional builds in the future |
Actually, we could conceivably remove all the 32-bit builds. The only ones registered are for Pharo 3, stable and alpha. |
I've committed a proposal to this PR. |
.github/workflows/main.yml
Outdated
- Squeak32-trunk | ||
- Squeak32-6.0 | ||
- Squeak32-4.5 | ||
- Pharo64-stable |
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.
Why remove Pharo64-stable
here?
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.
- Because that's the failing build
- Because Pharo64-11 is a separate build, already in the list
I'm not saying this is a good suggestion :)
Looks like you broke the GemStone jobs. Not sure what's going on and not got enough time to help. Sorry! |
Do we maybe need to upgrade the stable VMs? Line 182 in d3a45fe
|
It's the Line 12 in 12a3bd3
Not sure what to do there, except for using dynamic sends to hide the selector... |
I can't remember how this works. Maybe @dalehenrich can help? |
Oh! Yes, absolutely! I hand't realised that the VMs are hard coded. I'll do that. |
It's not a GemStone issue. The issue is that the |
12a3bd3
to
7d23f15
Compare
There's a hierarchy for that test now. What do you think? |
d0eb162
to
bf9266a
Compare
Yes, LGTM, thank you! When can this be merged? There is still a job failure. |
#607 needs to be merged first. |
Can you cherry-pick the changes so we see a green gate? |
Note: This commit also changes `Pharo-stable` and `Pharo-alpha` to be synonyms of `Pharo64-stable` and `Pharo64-alpha`, respectively. Previously, these aliases referred to the 32-bit versions.
360e56f
to
78b6bd2
Compare
Done. |
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.
LGTM, thanks!
No description provided.