Check for LLM usage

Analyze the project and check how efficient it is using the OpenAI API or LLMs in general.
GPT-4 is expensive so every token counts.
Think about improvements and write them down as issues.

for this problem, i think we can add API budget variable like auto-gpt

Gpt-4 also has a rate limiter,50 hits so I changed it to 3.5 turbo which also gives good results.

Hi, I'm fairly new to coding and I came across this question. I'd like to change the LLM model to GPT-3.5 turbo, but I'm having a hard time doing so. I went into session.py and changed the following line to "gpt-3.5-turbo" and I'm still having issues. Would you be able to help out?
def _choose_llm(
self, model: str = "gpt-4", openai_api_key: Optional[str] = None, **kwargs


ESLint error: '@generated/photon' should be listed in the project's dependencies.

I'm trying to run eslint on my prisma2 test project and it gives me the following error:
'@generated/photon' should be listed in the project's dependencies. Run 'npm i -S @generated/photon' to add it
From import/no-extraneous-dependencies
Installing @generated/photon (obviously) does not work.
I see some possible solutions:

Create a dummy @generated/photon repo that is only a placeholder and empty
Try to make the @generated prefix an NPM standard.
I just remove/disable this rule.
Put @generated/photon in the "peerDependencies" or "optionalDependencies". I'm not sure if this gives weird side-effects? At least it would not try to install if I run yarn or npm install.
Change the config so the generated files are placed somewhere else. But I actually like the @generated prefix.

Thoughts?

bundledDeps is the right place; a PR to the import plugin would be welcome.

This also ties into the discussion around this: https://github.com/prisma/photonjs/issues/88
If we have a npm package scope that we "own", adding an optional dependency might be a way to make the linter work.

Found this issue before I knew you could change the generated output via config. Linking for any other lost souls: https://github.com/prisma/prisma2/blob/master/docs/photon/codegen-and-node-setup.md

Should be fixed with the next version of eslint-plugin-import. Just put @generated/photon into bundledDependencies in package.json.
See https://github.com/benmosher/eslint-plugin-import/issues/1436


http://alpha.release.core-os.net/amd64-usr/%s/coreos_production_vagrant.json can't reach!

http://alpha.release.core-os.net/amd64-usr/current/coreos_production_vagrant.json can't reach!
all http://alpha.release.core-os.net can't reach!

This works fine for me (California, US).

I am Sorry, in China.

How can make mirror for china?

Ah, yeah. Our downloads are hosted by Google and thus not currently available in China. We plan on reworking our download site soon though.

Moved to https://github.com/coreos/bugs/issues/1331


[Decompiler] Test framework for decompiler regression tests

Pull Request Test Coverage Report for Build 492577945

77 of 82 (93.9%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.5%) to 58.894%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

decompiler/IR2/Form.cpp
0
1
0.0%

test/decompiler/test_FormRegression.cpp
71
75
94.67%

Totals

Change from base Build 492330847:
3.5%

Covered Lines:
23169

Relevant Lines:
39340

💛  - Coveralls

Pull Request Test Coverage Report for Build 492577945

77 of 82 (93.9%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.5%) to 58.894%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

decompiler/IR2/Form.cpp
0
1
0.0%

test/decompiler/test_FormRegression.cpp
71
75
94.67%

Totals

Change from base Build 492330847:
3.5%

Covered Lines:
23169

Relevant Lines:
39340

💛  - Coveralls

Having this type of test seems very valuable, and I already found a few bugs when creating this.  The biggest issue with these tests is it's really confusing to understand the output before all the expression stuff has been properly built (stuff like "hidden variables" set in branch delay slots, the ordering of body/condition in loops, etc).  But I think it's still worth it to come up with a set of test functions that we can test at various points in the decompiler, and it will only get easier to add more tests as the decompiler progresses.

Having this type of test seems very valuable, and I already found a few bugs when creating this.  The biggest issue with these tests is it's really confusing to understand the output before all the expression stuff has been properly built (stuff like "hidden variables" set in branch delay slots, the ordering of body/condition in loops, etc).  But I think it's still worth it to come up with a set of test functions that we can test at various points in the decompiler, and it will only get easier to add more tests as the decompiler progresses.


Improve segfault handling, fix unit tests on Windows

The Ceedling rspec tests were not passing on Windows (MinGW-W64), primarily because segfaults were not detected correctly. I have improved the segfault detection logic and test suite output as well as fixing a few other small issues I encountered along the way.

@tbates-redarc Thank you for this! There's some good changes and fixes in here. You also helped us see a couple further fixes needed. And thank you for doing the work on the tests.
Your changes aren't all that many, but they touch some sensitive and recently changed areas. We know some further changes we want to make as well. So, rather than directly merge, we're going to try peeling this PR off into a new branch, working on it with you, manually testing it thoroughly, and then merging, if that's okay?
We're in the final stretch for releasing 0.32. These are important fixes you submitted. We need to finish up a handful of other things before returning to your PR.

Thanks, happy to support whatever approach works for you. I would love it if you can get #818 into 0.32 as well.

Sorry for the slow response on #818, @tbates-redarc. It's very much on the radar and in the backlog for the final release. You pointed out some very real issues and made some great suggestions. Ceedling has just sorta grown and changed organically over time, and the set up order has not been properly revisited. Since you've suggested a pretty significant change, we need to really spend some time digesting and exercising it. But, rest assured, it will get attention before the release. We'll definitely reach out in a bit.

@tbates-redarc Finally working on incorporating your work into the nearly complete next release of Ceedling…
Can you help me understand the segfault logic you wrote in generator.rb? Specifically, I want to understand the check for exitstatus == 3. I am not aware of any specific exit handling in Unity that exits with 3, nor am I aware of a common platform convention for exit code 3. The logic for termsig = 11 makes lots of sense for Unix-like platforms, of course.
Thank you.

@mkarlesky Segmentation faults / access violations in Windows cause an SEH exception. These are used to implement C++ exceptions on Windows. The default behaviour for an unhandled C++ exception is to call the abort() function. On Windows, the abort() function returns an exit code of 3.
The only part of this I'm uncertain of is that SEH exceptions are not identical to C++ exceptions, and some references suggest that an unhandled exception will use the exception code as the exit code. For a STATUS_ACCESS_VIOLATION this would be 0xC0000005. However in my testing using MinGW-W64 and GCC, I got exit code 3. Perhaps on different implementations of the C compiler and/or runtime the outcome might be different.
Also it's worth noting that any call to abort() would cause the process to exit with code 3, so it is not ideal for detecting segfaults in this application. Perhaps a better solution would be for the Unity test runner to register its own signal/exception handler that e.g. prints the same 'Segmentation fault.' text that we're used to from Unix.

@tbates-redarc Thanks for the prompt reply!
I can confirm that using MSYS on Windows, the exit code for an access violating is 0xC0000005.
More importantly, Unity’s behavior is to emit an exit code with the number of failed tests (0 being success, of course) up to the platform limit on exit codes or any other platform manipulations. So, checking the exit code is problematic no matter what way we go. There's actually a not insignificant method in Ceedling that hardly ever gets used that does some basic validity checks on all this. It's complicated enough that it's never been enabled by default.
We're looking at simply expanding the concept of segfault checking to crash detection generally. We can check for certain conditions on some platforms for definitive evidence of a crash. Otherwise, we'll just look to see if there's no test summary. With high likelihood, the lack of a test summary means something went boom for any of the handful of reasons such things can happen.

@tbates-redarc I have new and improved crash detection working on both Linux and Windows now. I also expanded our Github Action CI setup to run the entire build on both Linux and Windows. So far, it looks pretty good.
I was surprised to find that all the backtrace / gdb features worked in the Windows build given the many Windows-specific changes you made for those features. My suspicion is that the build works because Github Actions default to MSYS on Windows. You were probably running into problems in a less Unix-y Windows setup? Can you briefly outline the changes you made related to the backtrace feature and why you made those changes? It looks like some good thought and some beads of sweat went into it!

@mkarlesky mostly it was about getting nicer and cleaner output from gdb.

As you've already seen, I created a genuine null pointer dereference in the test suite instead of calling raise because access violations on Windows don't cause signals natively (they cause exceptions which MinGW and friends translate into signals).
I found the flattening and unflattening of the gdb output (to avoid the backtrace being matched in GeneratorTestResults#process_and_write_results # process unity output) to be unreliable so I replaced that with a redirection to a file (which also worked differently on Linux and Windows as described in the comments in defaults.rb), so that I could be sure that test output and gdb (backtrace) output would be properly separated. This made for much nicer output as the failing test would show up in the test summary with the file and line number of the crash, without a mangled version of same also showing up in the test output.
The --eval-command run --eval-command backtrace that was on the default gdb command line had issues with either a) not properly killing the child process after printing the backtrace, or b) gdb getting upset about being asked for a backtrace for a child process that had already terminated. I solved this with the addition of the backtrace.gdb script because I couldn't make gdb accept the if $_isvoid ($_exitcode) conditional on the command line.
I added a call to fflush to make sure all the child process's output was printed before the backtrace to avoid confusion where a print statement just before a crash appears not to have been run (but it's actually just buffered).
Also I spent way too long being completely baffled by strings showing up frozen in the middle of tests, where there was nothing that could possibly be freezing them, only to finally figure out that Ruby itself freezes the strings in $LOAD_PATH inside rb_construct_expanded_load_path() in load.c, but only when something tries to search the load path (e.g. a call to pp). I put the solution (dup the string before adding it to $LOAD_PATH) in a separate commit.

@tbates-redarc This is so very helpful.
I have already imported your more general solution to triggering a segfault as well as your shell handling improvements. But, I have not delved into any significant changes to backtrace itself yet.
Backtrace is all a great new feature, but the community submitted code is a bit difficult to follow and work with — especially for layering in some basic improvements we have in mind. Your hard work and these explanations are so helpful to that end!

I think we got it, @tbates-redarc. Your PR was such a helpful reference. Other refactoring and some other features mean rejecting your PR, but its spirit and pieces of its code are now in the pre-release code.
I found a way to “flatten” / ”unflatten” multiline text that is quite a bit simpler and much more reliable than the original. If we can avoid writing to a file only to turn around and use its contents, we should. File I/O slows down a build. More importantly, writing to a file and then reading it back as a type of information exchange between parts of the application can cause trouble in a multi-threaded build (especially on Windows). Sometimes files don't get flushed to the filesystem before other code expects their existence. This approach also eliminates double tool declarations depending on Windows or Linux.


Link to tutorial

The link from the Github page to the tutorial should go directly to https://simio-continuum.readthedocs.io/en/main/tutorials/tutorial_1.html, rather than the general documentation.  (This is a minor issue.)
https://github.com/openjournals/joss-reviews/issues/4942

Thanks!
The links have been updated to point directly to the mentioned content, instead of the general documentation. I have implemented this changes in all the contents and tutorials.


Rename RawObject to RawDocument

RawObject will decode only 1st level fields of the encoded documet.
On the other side RawDocument is already an encoded document and no processing should be made.

or just Raw ?

FWIW: https://github.com/FerretDB/FerretDB/blob/main/internal/bson/raw_document.go


Adding netstorage, appsec and siteshield cachers

This is awesome @stuartio ... thank you.  We will get this reviewed shortly.

Tested this out.  Thank you @stuartio


Parameter 'zip_code' not found in 'ADDRESS' category for 'fr' locale

https://github.com/serpro69/kotlin-faker/blob/b128f4142fb78ad31aff5ad82793600c12be8740/core/src/main/resources/locales/fr/address.yml#L19-L20

That's a pity the issue is not described. :)
Is it the same one that causes Parameter 'street_prefix' not found in 'address' category error for Polish locales?
I've approached it when using: faker.address.streetAddress()
Link to Polish locales:
https://github.com/serpro69/kotlin-faker/blob/master/core/src/main/resources/locales/pl.yml#L17

Hi @dariabajda ,
It could be similar, yes, but I'm not really sure how you're getting that error because street_prefix is there in the pl.yml file: https://github.com/serpro69/kotlin-faker/blob/5731ae67aef792d862cd8fef722b374d6fb23436/core/src/main/resources/locales/pl.yml?rgh-link-date=2022-07-11T14%3A54%3A08Z#L7
Can you please open a separate issue for this and mention the version that you're using. Thanks.

Polish street name & address work like a charm in 1.12.0-rc.0, thanks a lot! :)


Add VSTS CI badges in package.json

Setup VSTS badges in package.json
@d3r3kk I should have picked this up when you created the PR to add the badges to CONTRIBUTION.md.
Please add the necessary badges in package.json under the following section:
    "badges": [
        {
            "url": "https://travis-ci.org/Microsoft/vscode-python.svg?branch=master",
            "href": "https://travis-ci.org/Microsoft/vscode-python",
            "description": "Continuous integration (Travis)"
        },
        {
            "url": "https://ci.appveyor.com/api/projects/status/s0pt8d79gqw222j7?svg=true",
            "href": "https://ci.appveyor.com/project/DonJayamanne/vscode-python-v3vd6/branch/master",
            "description": "Continuous integration (AppVeyor)"
        },
        {
            "url": "https://codecov.io/gh/Microsoft/vscode-python/branch/master/graph/badge.svg",
            "href": "https://codecov.io/gh/Microsoft/vscode-python",
            "description": "Test coverage"
        }
    ]

Didn't know about this file/usage for the badges. Will throw something together today.

FYI I updated CONTRIBUTING.md as the links for the badges just went to the JSON response.

Wow, that's odd - I copied the "Markdown Links" that VSTS supplies! Weird. (Admittedly, I did not test the links when I did the change so thanks Brett!).


v_max and a_max sometimes appear to be switched

First of all, thanks for the library, it is really useful.
Based on the examples given on the README, I changed the values of the script to make sense to my application:
from pyscurve import ScurvePlanner, plot_trajectory
import numpy as np

if __name__ == "__main__":
    q0 = [-2., 0.]
    q1 = [2., 5.]
    v0 = [0., 0.]
    v1 = [0., 0.]
    v_max = 0.5
    a_max = 2
    j_max = 10.

    p = ScurvePlanner()

    tr = p.plan_trajectory(q0, q1, v0, v1, v_max, a_max, j_max)
    plot_trajectory(tr, dt=0.01)

However, that is the result of plot_trajectory:

Note how my velocity limit is 0.5 and the speed profile on the left reaches values higher than 1. Also, the acceleration on the left saturates at 0.5, which is my velocity limit.
Do you have any clue on what could be causing this behavior?

I renamed the title because the use-case I had before had shown this issue on the 2nd trajectory. But on this case it happens on the 2nd trajectory:
from pyscurve import ScurvePlanner, plot_trajectory
import numpy as np

if __name__ == "__main__":
    q0 = [10., 0.]
    q1 = [4., 5.]
    v0 = [0., 0.]
    v1 = [0., 0.]
    v_max = 0.5
    a_max = 1
    j_max = 10.

    p = ScurvePlanner()

    tr = p.plan_trajectory(q0, q1, v0, v1, v_max, a_max, j_max)
    plot_trajectory(tr, dt=0.01)

I renamed the title because the use-case I had before had shown this issue on the 2nd trajectory. But on this case it happens on the 2nd trajectory:
from pyscurve import ScurvePlanner, plot_trajectory
import numpy as np

if __name__ == "__main__":
    q0 = [10., 0.]
    q1 = [4., 5.]
    v0 = [0., 0.]
    v1 = [0., 0.]
    v_max = 0.5
    a_max = 1
    j_max = 10.

    p = ScurvePlanner()

    tr = p.plan_trajectory(q0, q1, v0, v1, v_max, a_max, j_max)
    plot_trajectory(tr, dt=0.01)

Fix merged


extra labels being detected during tf.record generation

Hi, my program is detecting fake labels during tf.record script.
Uploading some screenshot of anaconda:

Uploading images showing error:
a_100.png:

a_101.png:

a_102.png:

a_103.png:

a_104.png:

a_105

a_106

a_107

a_108

a_109

a_110

a_111

a_112

a_113

a_114

a_115

a_116

a_117

a_118

a_119

a_120

a_121

a_122

a_123

a_124

a_125

a_126

I think that it could be due to this weird border surrounding the images. Is it possible to remove this border, if that is causing it?

What is the number of classes you have and what pixel value are you assigning for each class?
Please share your label.pbtxt and create_mask_rcnn_tf_record.py

I opened an issue in the PixelAnnotationTool library and they have fixed this issue in the latest version 1.3.2
I will report if i encounter any other problems.

Great! Can you please share link of the issue you opened in the PixelAnnotationTool library.

Here you go.
https://github.com/abreheret/PixelAnnotationTool/issues/31

Thank you!


Not able to generate bollinger band signals

hi,
Thanks for that great work!!
I am trying to generate just the buy/ sell signal (and not the pattern). I took the 5 years stock data however signals[signals['signals']!=0] is always empty irrespective of any stock I take. Appreciate any help.
Thank you!

Empty DataFrame
Columns: [Open, High, Low, Close, Adj Close, Volume, std, mid band, upper band, lower band, signals, cumsum, coordinates]
Index: []

Thanks for the response. The issue is resolved now.

@sabirjana - What was the issue and how did you resolve it?


Autoscaling inference endpoints

This PR:

makes a lot of parameters completely optional to allow creating an inference endpoint from only the model name if needed
tries to auto-suggest relevant endpoint size
if not possible, tries to spin up the endpoint with the lowest hardware needed, then tries rescaling automatically for an hour until an appropriate hardware size is reached (or until 1h has elapsed)
catches a bunch of possible exceptions (endpoint already present, connection issues, compute not available, etc)

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Yep! That's the idea, since I wanted to streamline process as much as possible - either the user already has an endpoint, or they want one created and don't care about the name

Would you want do be able to select a name in all cases?

I do not have a strong opinion. I just wanted to be sure to understand all possible use cases and if we should allow all of them:

Use an existing endpoint

endpoint_name is required, model not passed, instance not passed

Create a new endpoint

model is required
Custom endpoint_name? Either pass it or not
Delete endpoint at the end? Yes or not
Custom instance? Yes or not (autoscale)

The simplest cases:

User only passes endpoint_name: use an existing endpoint
User only passes model_name: create endpoint (we decide its name), autoscale, and delete

At the moment we only cover the simple cases with this PR: user passes endpoint name or model name, we see if it's an already existing endpoint or if we need to spin it up, if we need to spin it up we delete it afterwards

My general suggestion would be:

make it as easy as possible for simple use cases, convenient for most users
also make it highly customizable, for advanced users

But some aspects if considered useful could be addressed in other PRs.
The only inconvenient I see is:

this PR changes current YAML format: endpoint_name and model are replaced by model_or_endpoint_name

this is a breaking change and has an impact in UX

future advanced use cases may again require differentiating between endpoint_name and model

Very fair point, I'll revert this specific change


Change the cmdlet to get app load information

Hello, the correct command let to get application information is Get-ServiceFabricApplicationLoadInformation

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5df7cff5-ece0-a956-2395-60ef65c41995
Version Independent ID: 4f829849-d587-abaf-91af-c54419e398e7
Content: Service Fabric Cluster Resource Manager - Application Groups
Content Source: articles/service-fabric/service-fabric-cluster-resource-manager-application-groups.md
Service: service-fabric
GitHub Login: @masnider
Microsoft Alias: masnider

Thanks for the feedback! We are currently investigating and will update you shortly.

@EVMartinez thanks for pointing this out. I confirmed and you are correct.
I made the changes. Once the PR merges the issue will automatically close and the changes will go live in a few hours.


Ruby version issue

bundle install shows this error
Your Ruby version is 3.0.2, but your Gemfile specified 2.6.2
I guess not all versions of Ruby are supported

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b9d5437c-5b4f-bf5b-4877-e810d5fefb4f
Version Independent ID: eea67277-74ba-c23c-bee5-af4cf6eb14db
Content: Quickstart: Create a Ruby app - Azure App Service
Content Source: articles/app-service/quickstart-ruby.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

Thanks for your feedback! We will review and update this doc accordingly.

You would be correct @cherchyk. If you find yourself encountering errors, the recommended course of action is to use a docker container for your app.


OP-12761: Feature - Property To Enable / Disable Authentication For Spinnaker Webhooks

https://devopsmx.atlassian.net/browse/OP-12761
(cherry picked from commit 8919e7b91d98aa16881946eba396271025379873)
We prefer small, well tested pull requests.
Please refer to Contributing to Spinnaker.
When filling out a pull request, please consider the following:

Follow the commit message conventions found here.
Provide a descriptive summary for your changes.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Add inline code comments to changes that might not be obvious.
Squash your commits as you keep adding changes.
Add a comment to @spinnaker/reviewers for review if your issue has been outstanding for more than 3 days.

Note that we are unlikely to accept pull requests that add features without prior discussion. The best way to propose a feature is to open an issue first and discuss your ideas there before implementing them.

This PR  triggered this build in this execution, please merge to master only if this succeeds:  https://spin.prod.opsmx.com/#/applications/gcp-gitprtrigger/executions/details/01FX5E7Y77XVG4VMYCFMH6KW0S


Get-PartnerCustomer -Domain $CustomerDomain

No customers is using the .onmicrosoft.com domain.
The cmdlet should support customer domain, like the MSOnline module does.
Originally posted by @skille in https://github.com/Microsoft/Partner-Center-PowerShell/issues/32#issuecomment-439345001

This functionality will be delivered with the next release of the module. With the recent integration with Microsoft Graph, it is now possible to query for customers based on the default domain.

I have just released version 2.0.1911.4 that contains the ability to get customers based on their default domain.


how to get currently selected item from multiple select text box

I m using multiple select configuration.
I want to catch the on select event when user clicks on one of the selected options which are already in the text box.
when i m using bootstrap theme, color of the selected item changes to blue. I want to do custom action on user click event

One can just use the provided event handlers.
Closing as a support issue.


add rhel9.3 support in test case

Added rhel9.3 support in following test cases:
ostree-ignition.sh ostree-ng.sh ostree-raw-image.sh ostree-simplified-installer.sh ostree.sh
No need to run CI as 9.3 trigger is not added yet.

@yih-redhat Thanks for doing this. :+1:
PR #3282 covered 9.3, 8.9, arm, adds-on, packages, I think we can close this PR and focus on #3282.

That's great, I will close this one.


feat(terraform/gcp): Add GKE Shielded Nodes is Disabled query for Terraform.

Add Terraform query for "GKE Shielded Nodes is Disabled".
Closes https://github.com/Checkmarx/kics/issues/6243
I submit this contribution under the Apache-2.0 license.

Hi @bbergstrom,
Thank you for this amazing contribution!
Regarding the proposed changes. The query logic LGTM.
I will just ask our Application Security to validate the metadata and should be good to go!

@cxMiguelSilva The first query detects for the implicit default, which should be a positive because the value could drift if it is changed outside of Terraform.  The best practice for these is to explicitly set the default value in Terraform to ensure it catches and corrects drift to the secure value.

Hi @bbergstrom ,
Would you have time in the near future to do the changes Miguel asked for?

@kaplanlior Pushed suggested changes.  Awaiting approval for test suite.

@gabriel-cx Tests all passed. 🎉   Would you finish the review or should I wait for @cxMiguelSilva ?


Change Plot Axes using OSC Messages and MIDI CC Messages

Because we're conceiving of controlling this application via MIDI and OSC from other applications (such as Max or SuperCollider) (most of which is already implemented!) it would be great to also be able to change the axes with osc messages and midi control change messages so that the performative space could be changed in real-time during a performance!

Fixed with PR #24


opt: add option to limit the max size of MANIFEST file

MANIFEST file records the changelogs of compaction. After long time
running of leveldb, MANIFEST file keeps growing larger and larger,
casuing long time to replay MANIFEST file when reopening leveldb.
This commit adds an option MaxManifestFileSize to limit the max
size of MANIFEST file. The default value is 64 MiB.

#378

Merged! Thanks @Alex-duzhichao.


Add a spec for String#to_sym with same content but distinct encoding

I found a bug in JRuby while working on msgpack:
https://github.com/msgpack/msgpack-ruby/blob/37949d20920225972b51f4cc69c8fbec775cc9fd/spec/factory_spec.rb#L338-L341
cc @eregon
Also cc @headius (in case this isn't a known or expected difference)

the symbol is interned on the first touch to the symbols table as Encoding::ISO_8859_1. On the second touch, the symbol is already known because the binary representation is exactly the same, but the original encoding has been changed so it doesn't match anymore. This sharing is quite unexpected and it should be fixed.
very nice reproduction btw