DispatchOverlayShims.h issue with Sourcery 0.11.0

❌  error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/shims/DispatchOverlayShims.h:185:20: error: implicit conversion of C pointer type 'dispatch_data_t _Nonnull' (aka 'struct dispatch_data_s *') to Objective-C pointer type '__swift_shims_dispatch_data_t _Nonnull' (aka 'id') requires a bridged cast

I've tried with both Xcode 9.2 and Xcode 9.3. Reverting to Sourcery 0.10.1 fixes the issue.

I'm also seeing this when Sourcery is integrated with CocoaPods. If I use the system one installed with homebrew it works.

Yes, now I see the same issue with swift templates

But I only see that if there is an error in template. There were some breaking changes in types collections, this can cause this issue. Please try to check if you have those and if yes then try to fix them. You can also try to create some simple template to see if it works at all - works for me.

Type collections types.based, types.implementing and types.inheriting now return non-optional array. If no types found, empty array will be returned.
This is a breaking change for template code like this:

<% for type in (types.implementing["SomeProtocol"] ?? []) { %>

The new correct syntax would be:
<% for type in types.implementing["SomeProtocol"] { %>

I can confirm that the 0.11.0 release on CocoaPods has this issue, but the 0.11.0 release using homebrew does not.

Can you provide example that demonstrates the issue?

I think this can be also caused by different versions of dependencies used for different package managers.

@ilyapuchka Here is a sample repository demonstrating the issue with 0.11.0 integrated via CocoaPods. It works if you change the Sourcery script phase to use /usr/local/bin/sourcery using Homebrew 0.11.0, instead of the PODS_ROOT version. Rolling back to 0.10.1 also works. Note that it only compiles with Xcode 9.2.

Repo: https://github.com/Raizlabs/ios-template-output/tree/1cf8ae9ab2d94c9715478c2f91a28841c20db6df
CircleCI output: https://circleci.com/gh/Raizlabs/ios-template-output/8

@chrisballinger Homebrew uses SPM to build, so swift templates are not available there, that's why it's not crashing.

Ahh okay thanks!

@chrisballinger please check this with 0.11.2


thread_local

https://compiler-explorer.com/z/doExszzz9

It's also interesting to see how it works with the global variable version, where it seemingly reveals additional threads not explicitly created: https://compiler-explorer.com/z/PsKMq8PPM
It seems like the global variable needs to be referenced for it to be included though, commenting out the std::ignore = l; line changes the output.

/hj You hate so much std::endl you prefiere '\n' << std::flush over it.

/hj You hate so much std::endl you prefiere '\n' << std::flush over it.

std::endl should be deprecated. Virtually no one understands what it does (unless they watch my channel :D )


Integration Test - Release - 2020/05/12 17:23:07

Auto create for integration test. AnotherAuthorUpdatedArticleFlow

@PRMergerTest2 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Refactor becnmarks

WIP. I have some issues with ScodecSerial usage. For me, this code doesn't work. Any ideas why it doesn't compile:
info] Compiling 1 Scala source to /Users/vkostyukov/workspace/finagle-serial/scodec/target/scala-2.11/classes...
[error] /Users/vkostyukov/workspace/finagle-serial/scodec/src/main/scala/io/github/finagle/serial/scodec/ScodecSerial.scala:31: value toByteArray is not a member of scodec.Err
[error]       bits => Return(bits.toByteArray),
[error]                           ^
[error] /Users/vkostyukov/workspace/finagle-serial/scodec/src/main/scala/io/github/finagle/serial/scodec/ScodecSerial.scala:32: value message is not a member of scodec.bits.BitVector
[error]       e => codec.encode(Left(EncodingError(e.message))).fold(
....

See this conversation for context—it's just that the order of arguments to the fold changed.

@travisbrown,
I've fixed the compile error in benchmarks and managed to establish the scodec benchmarking. Here is the first results:
[info] Benchmark                               Mode  Samples     Score     Error  Units
[info] i.g.f.s.ScodecSmallRTBenchmark.test    thrpt       20  3798.150 ± 699.206  ops/s

This is a RT (Round Trip) benchmark. The message size is almost the same as we had for pickling benchmark previously (we had 37 round-trips per second). Now we have ~3.8k round-trips per second. Impressive!

Very nice!


⚠ Turnos 24x7 has degraded performance

In c92ec3a, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 2806 ms

Resolved: Turnos 24x7 performance has improved in 097760d.


fix: write assertion should not case about type restriction

Description
write_assertion should not care about type restriction as it is similar to check
References
Close https://github.com/openfga/openfga/issues/411
Review Checklist

[x] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[x] I have added tests to validate that the change in functionality is working as expected

Codecov Report
Base: 84.50% // Head: 84.52% // Increases project coverage by +0.02% :tada:

Coverage data is based on head (447d9d4) compared to base (5034eb6).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #412      +/-   ##
==========================================
+ Coverage   84.50%   84.52%   +0.02%
==========================================
  Files          84       84
  Lines       13754    13766      +12
==========================================
+ Hits        11623    11636      +13
  Misses       1752     1752
+ Partials      379      378       -1

Impacted Files
Coverage Δ

internal/validation/validation.go
90.50% <100.00%> (+0.32%)
:arrow_up:

server/commands/check.go
88.52% <100.00%> (+0.56%)
:arrow_up:

server/commands/write_assertions.go
70.37% <100.00%> (ø)

server/test/write_assertions.go
96.90% <100.00%> (+0.43%)
:arrow_up:

storage/postgres/iterators.go
69.14% <0.00%> (-2.13%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Changing keyboard layout in Manjaro Linux Installer does not work

I've connected a generic German 105 key keyboard and tried to set this keyboard layout during install.
The installer lets me select the correct layout and displays the correct layout image. However, in the line edit to check the keyboard layout, it falls back to the default English keyboard layout.
When going back to the Keyboard step of the installer, the previously chosen layout is not selected anymore.

Hi there! if you proceed with the install, will the correct layout get applied anyways?

Hi there! if you proceed with the install, will the correct layout get applied anyways?

One workaround could be that you set the correct layout on boot... (at least I added some code for that to work)

One workaround could be that you set the correct layout on boot... (at least I added some code for that to work)

Hi, thanks for the reply! I just tried selecting the correct layout on boot with release<PHONE_NUMBER>30. It results in the same error.
The problem persists in the other installation steps, e.g. when typing the username and is not applied to the installed system.

Hi, thanks for the reply! I just tried selecting the correct layout on boot with release<PHONE_NUMBER>30. It results in the same error.
The problem persists in the other installation steps, e.g. when typing the username and is not applied to the installed system.

while the issue with calamares (the installer) ins't such an easy fix, the workaround with setting this in the boot menu seems to work for me with the latest image:

Just to explain: calamares updates the language settings. after the install, your selected language should be the default language of your system due to a little script I built in. BUT: updating the language "ad hoc" by calamares is a "X11"-Feature.
what we need to do here, is to update calamares to issue sth like
swaymsg input type:keyboard xkb_layout de

whenever you change a language in the switcher. I don't see me doing that soon, but its definitely sth for the backlog.

while the issue with calamares (the installer) ins't such an easy fix, the workaround with setting this in the boot menu seems to work for me with the latest image:

Just to explain: calamares updates the language settings. after the install, your selected language should be the default language of your system due to a little script I built in. BUT: updating the language "ad hoc" by calamares is a "X11"-Feature.
what we need to do here, is to update calamares to issue sth like
swaymsg input type:keyboard xkb_layout de

whenever you change a language in the switcher. I don't see me doing that soon, but its definitely sth for the backlog.

Thank you for the explanation! Changing the boot setting works with the newest release for me too now

Thank you for the explanation! Changing the boot setting works with the newest release for me too now

i do not know if it is the same thing but when I set the keyboard layout to "International keyboard (with AltGr dead keys)" in the installer, then it is not set when I boot. i have fixed it myself by manually setting it in my sway config. but i do not see that the installer has set it anywhere.
just saying for the info :)

i do not know if it is the same thing but when I set the keyboard layout to "International keyboard (with AltGr dead keys)" in the installer, then it is not set when I boot. i have fixed it myself by manually setting it in my sway config. but i do not see that the installer has set it anywhere.
just saying for the info :)

"International keyboard (with AltGr dead keys)"

am I right in assuming that it doesn't set the variant, but the correct layout?

"International keyboard (with AltGr dead keys)"

am I right in assuming that it doesn't set the variant, but the correct layout?

@boredland
yes it's correct, my bad. it's the US layout with the "altgr dead key" variant, that i try to set from the installer. just to make it clear:)

@boredland
yes it's correct, my bad. it's the US layout with the "altgr dead key" variant, that i try to set from the installer. just to make it clear:)

yes it's correct, my bad. it's the US layout with the "altgr dead key" variant

Then my hopes are high that the workaround will apply soon.

yes it's correct, my bad. it's the US layout with the "altgr dead key" variant

Then my hopes are high that the workaround will apply soon.

I have a similiar issue with the keyboard layout. Even after changing it manually with the Manjaro Settings Panel, the layout still is locked to QWERTY.

I have a similiar issue with the keyboard layout. Even after changing it manually with the Manjaro Settings Panel, the layout still is locked to QWERTY.

Ya, I think using the Manjaro settings panel will be a similar issue as with the calamares installer. It sets xdg values that don't translate into a sway config. If we want to support that to be changed "ad hoc" we probably should check if those values are set and override the sway config if it is. Don't know if that's worth the effort tho.

Thanks for the reply. Do you forsee any other kind of workaround to set keyboard for the a GUI/the installer, or is the next step to dive into the Calamares updater/manjaro-settings-panel to add a support for Sway (Sorry fo the maybe dumb idea, new to sway)

Thanks for the reply. Do you forsee any other kind of workaround to set keyboard for the a GUI/the installer, or is the next step to dive into the Calamares updater/manjaro-settings-panel to add a support for Sway (Sorry fo the maybe dumb idea, new to sway)

I mean.. doesn't it work if you set it via Manjaro settings and reload sway? If so, that would be my proposed workaround :-D

I think I found a relatively easy solution to track the X11 changes and update sway accordingly:
https://github.com/Manjaro-Sway/manjaro-sway/issues/36

I installed the latest available ISO and I still found this problem.
The solution was to go to
cd ~/.config/sway/config.d

In the file you find there, you can set the language on your keyboard. Then press win+shift+c to apply inmediately.

I've encountered same issue except I want to use Us Dvorak. Switching didn't worked so I stopped further installation

but why then the installer offers to pick layout?

Because that is the standard Manjaro installer. That works for all other Manjaro variants, but ours. If you're interested in getting into how to configure / recompile it more tailored to our needs, I'd be very open for contributions. Calamares itself seems to support configurations and extensions already, but I never figured out how they work (see: https://gitlab.manjaro.org/explore?utf8=✓&name=calamares&sort=latest_activity_desc)

I do not understand how this issue is fixed. In the recent days I had to boot from a live stick multiple times to fix configuration oversights, manually changing the keytable to german is annoying, and remembering the english layout on a german keyboard is also annoying. How hard is it to create a custom ISO that has a different keyboard layout by default?

create a custom ISO that has a different keyboard layout by default

while this would be certainly possible, this is not what this ticket is about. It is about the installer (calamares) setting the keyboard layout, which does work differently for us at sway than it does for any other distribution. It should be fairly easy to set up our own "keyboard" module in calamares though, I never saw this issue as sever enough and probably would just remove the keyboard module from calarmares in our version if I find the time.

Sorry, I misphrased my question, see the edit now.
I intended to inquire about two things:

whether there is any possibility to support what is set through calamares (since it is a ´swaymsg´ one-liner it should not be too hard, huh?)
if it would be easy to fork a custom iso as workaround


Network Error with axios.js XHR GET requests

This plugin causes Network Error with https://github.com/axios/axios GET requests that includes Authentication header.
Please consider supporting cors headers if request is mapping or cutting off headers in some way.
Occurs in Chrome 79+

*cough* somehow this issue passed me by a bit. Sorry. 🙈
Is this still a current issue?

Not anymore.


Added support for quantizing models on IBM Power systems (ppc64le)

What does this PR do?
This PR adds quantization support for IBM Power systems (ppc64le). This addition was made so that users running AI models on Power systems have the ability to quantize models in a standard format using optimum.
Authored by : mgiessing<EMAIL_ADDRESS>Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

Awaiting review


Compilation with ITK 5?

Hello
I was wondering if SimpleElastix is compatible with ITK 5?
I've been unsuccessfully trying to compile SimpleElastix using ITK 5. The main reason I'm trying to do that because there is a bug in SimpleITK that is solved with ITK 5:
https://github.com/SimpleITK/SimpleITK/issues/750
Thanks
Martin

Yes that is correct, the new version of SimpleITK and elastix (which does support ITKv5 now) has not been merged into this repo. Contributions are welcome! (otherwise I will do it when I get around to it but I don't have much time maintenance these days)


Wrong script charset when using dynamic import

Bug report
Page encoded in windows-1251. All chunks are encoded in windows-1251 using the webpack-encoding-plugin.

What is the current behavior?
Doing dynamic import() call. Windows-1251 encoded chunk injected with charset="utf-8" attribute.
If the current behavior is a bug, please provide the steps to reproduce.
https://github.com/irudoy/webpack-charset-repro

What is the expected behavior?
Doing dynamic import() call. Windows-1251 encoded chunk injected with charset="windows-1251" attribute.

Other relevant information:
webpack version: 4.27.1
Node.js version: 11.4.0
Operating System: macOS 10.14.1
Possible solution: https://github.com/webpack/webpack/pull/8288

this is my repo
https://github.com/alexey-sh/webpack_and_babel_broken_encoding
webpack converts
"\u0002\u001E\u012E\b\u0001\b\u0001\u0004\u0002\t\u0002\u0004\u0003\t"
into
"Į		"
browserify doesn't have such bad bad behaviour

Original answer https://github.com/webpack/webpack/pull/8288#issuecomment-510047730.
Ref (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script):

charset
If present, its value must be an ASCII case-insensitive match for "utf-8". It’s unnecessary to specify the charset attribute, because documents must use UTF-8, and the script element inherits its character encoding from the document.

Also:

Module scripts are always interpreted as UTF-8.

If you still need to use non utf-8 charset you can use a plugin - https://github.com/dromru/encoding-plugin/blob/master/EncodingPlugin.js


the problem of datasets

if the image without the information of bbox, what should I do

You can use COCO dataset and leave the annotation empty. Thus you could inference on the dataset.


Multiplatform Support needed

Please add compose multiplatform support

As a former maintainer, I can share my POV only - i.e. nothing official, but this library is in maintenance mode. Do not expect any big development.


Add single match page

Trello
https://trello.com/c/kaBJc36i/71-frontend-int-page-single-match
Summary
Blocked on #87
Adds a single page and implements messaging
TODO:

[x] Page should refresh when sending message
[x] Press enter to send message (move to use a form tag)
[x] Center the rating stars
[x] Input scores + mark match as complete

Testing

Tested with example database:

Interesting, tests pass locally...


If there is a Result just allow one Result

https://jira.mitre.org/browse/BONNIE-853
Align the behavior of Bonnie with the QDM spec (5.02, 5.3) that for certain data criteria there can be up to 1 Result per instance of that criteria.
This change will have the side effect that if a user selects a DateTime that this message will display:

(where the measure id will be for whatever measure the user is on.)

good idea! kristian, can you pull that together?

i've approved code changes. @c-monkey can you re-run the tests for this to confirm it all still works? Thanks!


Disable zooming for the CatalogGraphCard

@freben suggested to disable it for the graph card as it interacts with the zooming on the entity page.
:heavy_check_mark: Checklist

[x] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

I'm a bit confused that the core-components API report isn't updated.

@Fox32 Oh I see what's up - the DependencyGraphProps type isn't exported, you can see a warning about that in the api report actually. You might want to add that to the public API while you are at it

@Fox32 Oh I see what's up - the DependencyGraphProps type isn't exported, you can see a warning about that in the api report actually. You might want to add that to the public API while you are at it

Oh yeah, thanks!


Bump to 3.8

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

Hi @traversaro, sorry to ping you, but do you have any idea what I’m doing around here on windows with metis?

I may be missing something, but it seems to me that there is no explicit dependency on metis and on Windows metis it is not installed, while on *nix it is installed probably being a transitive dependency?

How embarrassing, I was sure I added it .. thank you!


Document post_stats

Document https://github.com/Pelican-Elegant/elegant/pull/268

Any suggestion where to put the file here https://github.com/Pelican-Elegant/elegant/tree/master/documentation/content ? Should it in "Analytics" ?

@talha131 , suggestions?

Supported Plugins
On Fri, Jul 5, 2019, 11:56 Pablo Iranzo Gómez<EMAIL_ADDRESS>wrote:

@talha131 https://github.com/talha131 , suggestions?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Pelican-Elegant/elegant/issues/302?email_source=notifications&email_token=AAILIREUKKDMRWVDCWLBGL3P53WBVA5CNFSM4HWMIQUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZIWWIA#issuecomment-508652320,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAILIRD6V2CUTLGR4QY5O73P53WBVANCNFSM4HWMIQUA
.

@azzamsa any update on it?
Our new member @jackdewinter has taken up documentation tasks. Let me know how you feel if I  assign this task to @jackdewinter. If you already have a draft then please share it with us.

@jackdewinter

From what I am reading there, this is a net new article, correct?  Would I be correct that adding post_stats to plugins is the only required step?

Yes a new article.
Yes adding post_Stats plugin is the only required step.
Necessary detail to add is READING_TIME_LOWER_LIMIT

Have a look at code

https://github.com/Pelican-Elegant/elegant/blob/master/templates/_includes/post_stats.html
https://github.com/Pelican-Elegant/elegant/blob/master/templates/_includes/_defaults.html#L148-L154

But before you write, lets wait for @azzamsa to get back to us.

When I will work on this, you recommend me to better take the 'code' side. So I step back and (thought) that this already handled by Jackdewinter.

My apologies. Our earlier conversation slipped from my mind.
On Tue, Jul 16, 2019, 01:57 azzamsa<EMAIL_ADDRESS>wrote:

When I will work on this, you recommend me
https://github.com/Pelican-Elegant/elegant/issues/303#issuecomment-508718884
to better take the 'code' side. So I step back and (thought) that this
already handled by Jackdewinter.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Pelican-Elegant/elegant/issues/302?email_source=notifications&email_token=AAILIRA7IIIJ4XPJ7AWZTGTP7TQC3A5CNFSM4HWMIQUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ66JVA#issuecomment-511567060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAILIRCOYUG6XJQ7DVZ7KTTP7TQC3ANCNFSM4HWMIQUA
.

Just submitted a PR for this.  https://github.com/Pelican-Elegant/elegant/pull/448

:tada: This issue has been resolved in version 3.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


merge package from arlac77/npm-package-template

.npmignore

chore(npm): update .npmignore from template

Coverage remained the same at 86.076% when pulling a1c6ffc01bf214e34c029075d88a37660311787b on template-sync-1 into 5e9c57948ba0dc1ae64d039eaa6ea16dfeea32a9 on master.


Fix #16: Add support for additional Hydra instances

Add support for additional Hydra instances - following same convention followed in Rhythm bot implementation

LGTM
Thank you very much!


[BUG]enter the wrong address in the transfer, transfer Xcc to XCH's address. This XCH address will be converted to an unknown Xcc address.

Describe the bug
If I enter the wrong address in the transfer, transfer Xcc to XCH's address. This XCH address will be converted to an unknown Xcc address.
I have done such a thing once on October 17.
Same address.
Can I get it back?
To Reproduce
use xch address for: xch1a83ce5uxkr94ek9nea3aj0rs8cnj4dafkx7ftf49jmhfndpgc8vqdsmxyy
convert xcc address: xcc1a83ce5uxkr94ek9nea3aj0rs8cnj4dafkx7ftf49jmhfndpgc8vqt80g5f
Expected behavior
Can I get it back?
Screenshots

I don't think there is a way to get it back. It was sent to some random xcc wallet...


Disable/enhance "unused" warning for event handling methods

Note that I'm only going to talk from a Forge perspective here since I don't know any of the other systems in-depth.
Due to the fact that methods annotated with SubscribeEvent or EventHandler (usually) never get called directly, IDEA marks them as unused. This can easily be disabled by using IDEA's built-in support for marking certain annotations as "users". It would be great if the plugin could automatically add these exceptions.
Alternatively, enhanced usage detection could be put in place. This would entail marking the method as used whenever an instance of the containing class is passed into the event bus's register method. Whilst this is a great solution for simple setups, there are some mods out there which search for classes marked by their own annotation (something like @RegisterBus) and then create and register an instance automatically. These mods would obviously have to fall back to the built-in method mentioned above.

The plugin actually does add these exceptions automatically, but only when you create the project (so if you open an already-made project it won't do it). I've been thinking about enabling it for whenever a Minecraft mod is detected, to catch these cases as well.
How prevalent are the more complex mods vs the standard mods which use the event bus explicitly?

I honestly do not know how common automatic registration of event handlers is. I personally can only come up with one case off the top of my head and I'm not even sure if that still uses this system.
However, it's great to read that the exceptions are already automatically added, even if only on project creation.


Post release automated changes for resourcesdeploymentstacks releases

Post release automated changes for azure-arm-resourcesdeploymentstacks

API change check
API changes are not detected in this pull request.


Upgrade Typer Version

Having a lower Typer version seems to create conflicts with other packages.
Upgrading Typer seems to bring in a new rich update that throw colored expectations we want to upgrade Typer but not throw these.

Related to #2068

Merged in #2976


[List] unknown prop 'containerElement'  in ListItem

Warning: Unknown prop `containerElement` on <div> tag. Remove this prop from the element. For details, see https://fb.me/react-unknown-prop
    in div (created by ListItem)
    in div (created by ListItem)
    in ListItem (created by SimpleNav)
    in div (created by List)
    in List (created by SimpleNav)
    in div (created by Paper)
    in Paper (created by Drawer)
    in div (created by Drawer)
    in Drawer (created by SimpleNav)
    in SimpleNav (created by App)
    in div (created by App)
    in App (created by RouterContext)
    in RouterContext (created by Router)
    in Router
    in MuiThemeProvider
    in Provider

Versions

Material-UI: 0.15.4
React: 15.3.0

Could you provide a reproduction test case? That would help a lot 👷 .
It could be a code sample or a live example. You can use this playground to do so: http://www.webpackbin.com/4yHN_S7ab.

@oliviertassinari , currently i have same error, but can't reproduce in www.webpackbin.com (don't know why 😢 )
On my live project, code
<MenuItem disabled={true} primaryText={<FormattedMessage id="left_menu.reports" />} containerElement={<Link activeClassName="active" to="/reports" />} leftIcon={<ReportsIcon style={style.icon} hoverColor={style.iconHover} />} />

will give
warning.js:37Warning: Unknown prop `containerElement` on <div> tag. Remove this prop from the element. For details, see https://fb.me/react-unknown-prop
    in div (created by ListItem)
    in div (created by ListItem)
    in ListItem (created by MenuItem)
    in MenuItem (created by LeftMenu)
    in div (created by List)
    in List (created by Menu)
    in div (created by Menu)
    in ClickAwayListener (created by Menu)
    in Menu (created by LeftMenu)
    in div (created by Paper)
    in Paper (created by LeftMenu)
    in div (created by LeftMenu)
    in LeftMenu (created by App)
    in div (created by App)
    in App (created by RouterContext)
    in RouterContext (created by Router)
    in Router
    in IntlProvider

Error will disappear, if i remove disabled={true}
I try to create live example ( http://www.webpackbin.com/41W0wqaa- ) with my project structure, but in this case he works correct.

@NewOldMax: did you figure out what was wrong?

@lucasbento , not, currently i'm busy with other things. I use <MenuItem disabled={true} /> for for not yet implemented pages, so in my case sometime i just delete this prop and all will be ok.  But I still have this warning on 0.16.0

Here is the origin of this warning.
The containerElement is forwarded to the <EnhancedButton /> when disabled is false.
However, it's forwarded to a <div /> when disabled is true.

Shouldn't we use the containerElement instead of a <div /> when disabled is true?
Otherwise you shouldn't be providing this property.

@oliviertassinari: has this been fixed?

@lucasbento I don't think so. The warning is just the tip of the iceberg.

We have been porting the component on the v1-beta branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.
Still, we will accept PR fixes until v1-beta takes over the master branch.


Update installation.rst to fix Apple Silicon instructions

ocpsvg was in the wrong spot (needs the --no-deps flag)

Thanks.


Improve handling of bbox state

Handling the bbox state (or more generally the view port state) is a bit tricky, because we partly control it from our application (using /info, selectedPath.bbox etc.) and partly it is maintained by direct user interactions with the map (zooming, scrolling etc.).
In some cases we just want to set the bounds of the map (fitBounds), for example when we want to zoom to a calculated route. This means we want to control the viewport ourselves. In other cases we want to keep the current viewport, for example when we change the map layer or clear a query input box. This means we want to neglect the bbox state of our application and the internal map state should take precedence.
Here I refactored some of the bbox state handling and fixed #72. Unfortunately with my current solution the map no longer zooms to the calculated route when the page is loaded initially. See more comments inline.
Fixes: #72

Btw not sure if we already need this, but the Mapbox documentation also describes how to keep the lat/lng/zoom state of the map in sync with the application state:
The code is here: https://github.com/mapbox/mapbox-react-examples/tree/master/basic

Thanks for investigating this, this works for me. I think this also supersedes #71?
And is it easy to reduce the world bbox to avoid seeing some continents twice?

I think this also supersedes #71?

Yes, I think so.

And is it easy to reduce the world bbox to avoid seeing some continents twice?

I think we can do this in Mapbox.ts:
 this.map = new Map({
            // ...
            maxBounds: [[-180, -90], [180, 90]],
            renderWorldCopies: false
        })

See also here:
https://docs.mapbox.com/mapbox-gl-js/example/restrict-bounds/
https://docs.mapbox.com/mapbox-gl-js/example/render-world-copies/

Also this is related to #53.

Not sure. This PR is mostly about how the bbox is applied to the map, but #53 seems also about determining the right bounding box for a route (use appropriate padding, do not zoom in too much etc.)

I just disabled the world copies here: b29801b169b0ff797a4ee5ba56e06365589f9150, but feel free to adjust

I briefly tried avoiding the initial jump when points are specified (also not fixed in #71), but let's do this in a separate PR. I opened https://github.com/graphhopper/graphhopper-maps/issues/82 for this.


Use modern META filename

The META.info is a legacy, pre-Christmas name. While it's still currently supported, META6.json is the new name. And since a lot of people simply copy some module's  structure, the old name still proliferates, so we're trying to get rid of it for good  by sending PRs to any modules that use the old name, to switch to the modern name.

👍  onward and upward...


how do I use this?

I mean, thx so very much for this but I do not know how to use it!
I mean I'd like to do this: http://www.dropzonejs.com/bootstrap.html with your directive, but I do not know how to start!
where and how do I set the event listeners? How to add a preview box? how do I set the action for uploading? thx.

This module is a very thin directive wrapper for the Dropzone object. This is essentially the guts of the module.
The listeners and config are done in your controller. In the controller and in the template is where you will deal with all of the bootstrappy stuff. Your controller will look a lot like this but without the calls to myDropzone. This will instead be an object (the events object mentioned below).
dropzoneConfig is your config object which is the same as the second argument here.
Your event listeners will be an object where the keys are event names and the values are functions to handle them sent in with the attribute eventHandlers. You can see how this is handled here.
These attributes will be named dropzone-config and event-handlers respectively in the form element you're setting up.

a detailed usage page wouldn't be a luxury :)

I've added a pull request for a new readme in case anyone is still having problems after @pferdefleisch's explanation. Don't know if it will be merged since the author doesn't seem very active in this repo.
https://github.com/sandbochs/angular-dropzone/pull/13

@ChezFre merged your PR. I've been less active here since I spend most of my time in React land these days. Thanks for the README update.


Added DI link

Fixes #8265

@scottaddie Would this work? I'm editing from the UI and don't know if this will resolve...
xref:ef/core/miscellaneous/configuring-dbcontext#using-dbcontext-with-dependency-injection

@daveabrock Great question. The answer is no. An "xref"-style link won't work in this case because the doc you're linking to lives outside of the aspnet/Docs repo. The link syntax should be:
[Using DbContext with DI](/ef/core/miscellaneous/configuring-dbcontext#using-dbcontext-with-dependency-injection)

@daveabrock Thank you for your contribution and patience.


Feature 1124 user table

Removing Redundent code in user unit tests
1124
What user problem are we solving?
There were a couple unused imports and code snippets
What solution does this PR provide?
I removed these imports and code snippets
Testing Methodology

How did you test your changes and verify that existing functionality is not broken
I reran the unit tests after removing the extra code and ensured that they still passed and worked.

Any other considerations
Added complete vitest and dynamodb mocking guides on notion
vitest link: https://www.notion.so/Using-Vitest-for-Unit-Testing-1ccb7a93b51d4887a69ab6d10f408021?pvs=4
dynamodb mocking link: https://www.notion.so/DynamoDB-mocking-9fefc3cf8be94048b7e054d6863987c5?pvs=4

link to guide on notion @ssh51117

link to guide on notion @ssh51117

added @karkir0003

link to guide on notion @ssh51117

added @karkir0003

@ssh51117 guide looks really well written :)

@ssh51117 can u please fix the merge conflicts!

link to guide on notion @ssh51117

added @karkir0003

@ssh51117 can we update the Notion with the new unit test samples + info on the vitest config stuff

great job! feel free to merge in @ssh51117


Check for openssl/awk/sed and all are executable

This fixes #715 by checking the commands are not just in path, but executable. It also checks for the presence of awk and sed.
NOTE: [ -x "" ] will fail correctly so if no file is found, the correct result will still be achieved.
Signed-off-by: Krayon<EMAIL_ADDRESS>

Thanks for your input. I modified the dependency checks a bit and all your issues should be resolved with that. See a07c8d14f62c3b32e4f9e963dabc0691f55fcde6.


[PE-D][Tester D] Missing client validation for finance/event entries when data is loaded from storage

Problem: Unlike other fields (when users attempt to modify the fields such as time in the json file to be of invalid format, all the data will be reset when the application starts - as cautioned in the User Guide), when I attempted to change client name field in the financebook.json and addressbook.json files to someone who do not exist in the addressbook.json, the application still starts with these incorrect information (instead of reseting the data), so I think there was some missing validation for client names during storage loading.
Example: change the sample eventsbook.json to below and the application still runs with the incorrect information in the data.
{
  "events" : [ {
    "eventName" : "Meeting with Alex",
    "timeStart" : "03-11-2024 09:00",
    "timeEnd" : "03-11-2024 10:00",
    "location" : "Conference Room",
    "clients" : [ {
      "name" : "Does not exist",
      "phone" : "87438807",
      "email"<EMAIL_ADDRESS>      "address" : "Blk 30 Geylang Street 29, #06-40",
      "company" : "Does not exist",
      "telegramName" : "@Does_not_exist"
    } ],
    "eventDescription" : "Discussion"
  }, {
    "eventName" : "Conference with Bernice",
    "timeStart" : "03-12-2023 18:00",
    "timeEnd" : "03-12-2023 19:00",
    "location" : "Conference Room",
    "clients" : [ {
      "name" : "Does not exist",
      "phone" : "99272758",
      "email"<EMAIL_ADDRESS>      "address" : "Does_not_exist, #07-18",
      "company" : "FAPro",
      "telegramName" : "@Does_not_exist"
    } ],
    "eventDescription" : "Discussion"
  }, {
    "eventName" : "Team Lunch",
    "timeStart" : "04-11-2023 12:00",
    "timeEnd" : "04-11-2023 13:00",
    "location" : "Conference Room",
    "clients" : [ ],
    "eventDescription" : "Discussion"
  }, {
    "eventName" : "Project Presentation",
    "timeStart" : "10-11-2023 15:00",
    "timeEnd" : "10-11-2023 16:30",
    "location" : "Conference Room",
    "clients" : [ ],
    "eventDescription" : "Discussion"
  } ]
}

Labels: type.FunctionalityBug severity.Medium
original: ncduy0303/ped#10

Validation is not part of our feature set. To be iterated in documentation


Usage creates a classless div with 'data-overlay-container' attribute.

Discussed in https://github.com/nextui-org/nextui/discussions/804

Originally posted by MARCA-Charlie October  7, 2022
I am using in Next.JS, the div stops children growing to their parent's height and width. As the div is classless it is hard to target with styles to overcome this.
Please see screenshot for context.

Workaround:
[data-overlay-container=true] {
  height: 100%;
  width: 100%;
}

Hey please upgrade to V2 since V1 will no receive more updates.


Add content-type to the nginx location block

Referring to your example:
rewrite.nginx.conf
location ~ "\.md$" {
	if (!-f $request_filename) {
		return 404;
	}

	if ($query_string = "ghmd") {
		rewrite "^" /path/to/ghmarkdownrender/index.php? last;
	}
}

maybe into something like this:
location ~ "\.md$" {
	if (!-f $request_filename) {
		return 404;
	}

	if ($query_string = "ghmd") {
        add_header Content-Type text/markdown;
		rewrite "^" /path/to/ghmarkdownrender/index.php? last;
	}
}

Hello Craig,
thanks for the suggestion - but what you have I believe to be wrong. When a route of /path/to/file.md?ghmd is called and the script is executed, the return output is rendered markdown - making it text/html as a content type.
I think this would be more fitting ```
location ~ ".md$" {
if (!-f $request_filename) {
return 404;
}
add_header Content-Type text/markdown;
if ($query_string = "ghmd") {
    rewrite "^" /path/to/ghmarkdownrender/index.php? last;
}

}

But even then, I don't think this offers too much. Also (at least for my Nginx config's on my dev boxes) I have `.md` mapped to `text/markdown` anyway in `/etc/nginx/mime.types`.

  Pete

No problem at all. You are the life saver here! It's not often I stumble
upon something online that makes my life easier. Thank u so much
On 10 May 2016 23:44, "Peter Mescalchin"<EMAIL_ADDRESS>wrote:

Hello Craig,
thanks for the suggestion - but what you have I believe to be wrong. When
a route of /path/to/file.md?ghmd is called and the script is executed,
the return output is rendered markdown - making it text/html as a content
type.
I think this would be more fitting ```
location ~ ".md$" {
if (!-f $request_filename) {
return 404;
}
add_header Content-Type text/markdown;
if ($query_string = "ghmd") {
rewrite "^" /path/to/ghmarkdownrender/index.php? last;
}
}
But even then, I don't think this offers too much. Also (at least for my Nginx config's on my dev boxes) I have .md mapped to text/markdown anyway in /etc/nginx/mime.types.
Pete
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/magnetikonline/ghmarkdownrender/issues/4#issuecomment-218301303

Thanks @craigiswayne - love to receive positive feedback like this! 😄


add slider element

create a slider / input[type=range]

Codecov Report

Merging #17 (4400773) into main (c23ca6c) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           10        13    +3
  Lines          239       330   +91
  Branches        21        29    +8
=========================================
+ Hits           239       330   +91

Impacted Files
Coverage Δ

src/FormBuilder.ts
100.00% <100.00%> (ø)

src/elements/AbstractElement.ts
100.00% <100.00%> (ø)

src/elements/Details.ts
100.00% <100.00%> (ø)

src/elements/Dropdown.ts
100.00% <100.00%> (ø)

src/elements/Input.ts
100.00% <100.00%> (ø)

src/elements/Range.ts
100.00% <100.00%> (ø)

src/elements/range/RangeProgress.ts
100.00% <100.00%> (ø)

src/elements/range/RangeTicks.ts
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


v3.5.3 "fails" when using PostgresContainer

Update/TL;DR:
Nothing actually broke and is not specific to PostgresContainer, it is just due to a change in logging level, see this post
Using v3.5.3 testcontainer-python breaks when using PostgresContainer, downgrading to 3.4.2 solves the issue. I have tried against several versions of the official container image with the same result.
$ docker --version
Docker version 20.10.7, build 20.10.7-0ubuntu5~20.04.2

$ pip freeze
attrs==21.4.0
certifi==2021.10.8
charset-normalizer==2.0.12
click==8.1.2
deprecation==2.1.0
docker==5.0.3
Flask==2.1.1
Flask-Injector==0.13.0
greenlet==1.1.2
idna==3.3
importlib-metadata==4.11.3
importlib-resources==5.7.0
iniconfig==1.1.1
injector==0.19.0
itsdangerous==2.1.2
Jinja2==3.1.1
jsonschema==4.4.0
MarkupSafe==2.1.1
packaging==21.3
pluggy==1.0.0
psycopg2-binary==2.9.3
py==1.11.0
pyhocon==0.3.59
pyparsing==2.4.7
pyrsistent==0.18.1
requests==2.27.1
six==1.16.0
SQLAlchemy==1.4.35
testcontainers==3.5.3
tomli==2.0.1
typing-extensions==4.2.0
urllib3==1.26.9
websocket-client==1.3.2
Werkzeug==2.1.1
wrapt==1.14.0
zipp==3.8.0

import unittest

from testcontainers.postgres import PostgresContainer

class TestPostgreSQLDataRepository(unittest.TestCase):
    def test_persist(self):
        with PostgresContainer('postgres:14.2') as postgres:
            postgres.get_exposed_port(5432)
            print(f"exposed port: {postgres.get_exposed_port(5432)}")
            connection_string = postgres.get_connection_url()
            print(connection_string)

 python -m unittest lib/repositories/test_data.py
Pulling image postgres:14.2
Container started: 1cb6a935e2
Waiting to be ready...
container is not yet ready: Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server at "localhost" (<IP_ADDRESS>), port 49173 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/waiting_utils.py", line 49, in wrapper
    return wrapped(*args, **kwargs)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/generic.py", line 33, in _connect
    engine.connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3234, in connect
    return self._connection_cls(self, close_with_result=close_with_result)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 96, in __init__
    else engine.raw_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3313, in raw_connection
    return self._wrap_pool_connect(self.pool.connect, _connection)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3283, in _wrap_pool_connect
    Connection._handle_dbapi_exception_noconnection(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2117, in _handle_dbapi_exception_noconnection
    util.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (<IP_ADDRESS>), port 49173 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

(Background on this error at: https://sqlalche.me/e/14/e3q8)

container is not yet ready: Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server at "localhost" (<IP_ADDRESS>), port 49173 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/waiting_utils.py", line 49, in wrapper
    return wrapped(*args, **kwargs)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/generic.py", line 33, in _connect
    engine.connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3234, in connect
    return self._connection_cls(self, close_with_result=close_with_result)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 96, in __init__
    else engine.raw_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3313, in raw_connection
    return self._wrap_pool_connect(self.pool.connect, _connection)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3283, in _wrap_pool_connect
    Connection._handle_dbapi_exception_noconnection(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2117, in _handle_dbapi_exception_noconnection
    util.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (<IP_ADDRESS>), port 49173 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

(Background on this error at: https://sqlalche.me/e/14/e3q8)

exposed port: 49173
postgresql+psycopg2://test:test@localhost:49173/test
.
----------------------------------------------------------------------
Ran 1 test in 2.725s

OK

$ pip install testcontainers[postgresql]==3.4.2
Collecting testcontainers[postgresql]==3.4.2
  Using cached testcontainers-3.4.2-py2.py3-none-any.whl (31 kB)
Requirement already satisfied: docker in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (5.0.3)
Requirement already satisfied: deprecation in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (2.1.0)
Requirement already satisfied: wrapt in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (1.14.0)
Requirement already satisfied: sqlalchemy; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (1.4.35)
Requirement already satisfied: psycopg2-binary; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (2.9.3)
Requirement already satisfied: websocket-client>=0.32.0 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.4.2) (1.3.2)
Requirement already satisfied: requests!=2.18.0,>=2.14.2 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.4.2) (2.27.1)
Requirement already satisfied: packaging in ./venv/lib/python3.8/site-packages (from deprecation->testcontainers[postgresql]==3.4.2) (21.3)
Requirement already satisfied: greenlet!=0.4.17; python_version >= "3" and (platform_machine == "aarch64" or (platform_machine == "ppc64le" or (platform_machine == "x86_64" or (platform_machine == "amd64" or (platform_machine == "AMD64" or (platform_machine == "win32" or platform_machine == "WIN32")))))) in ./venv/lib/python3.8/site-packages (from sqlalchemy; extra == "postgresql"->testcontainers[postgresql]==3.4.2) (1.1.2)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (1.26.9)
Requirement already satisfied: idna<4,>=2.5; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (3.3)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (2021.10.8)
Requirement already satisfied: charset-normalizer~=2.0.0; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (2.0.12)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in ./venv/lib/python3.8/site-packages (from packaging->deprecation->testcontainers[postgresql]==3.4.2) (2.4.7)
Installing collected packages: testcontainers
  Attempting uninstall: testcontainers
    Found existing installation: testcontainers 3.5.3
    Uninstalling testcontainers-3.5.3:
      Successfully uninstalled testcontainers-3.5.3
Successfully installed testcontainers-3.4.2

$ pip freeze
attrs==21.4.0
certifi==2021.10.8
charset-normalizer==2.0.12
click==8.1.2
deprecation==2.1.0
docker==5.0.3
Flask==2.1.1
Flask-Injector==0.13.0
greenlet==1.1.2
idna==3.3
importlib-metadata==4.11.3
importlib-resources==5.7.0
iniconfig==1.1.1
injector==0.19.0
itsdangerous==2.1.2
Jinja2==3.1.1
jsonschema==4.4.0
MarkupSafe==2.1.1
packaging==21.3
pluggy==1.0.0
psycopg2-binary==2.9.3
py==1.11.0
pyhocon==0.3.59
pyparsing==2.4.7
pyrsistent==0.18.1
requests==2.27.1
six==1.16.0
SQLAlchemy==1.4.35
testcontainers==3.4.2
tomli==2.0.1
typing-extensions==4.2.0
urllib3==1.26.9
websocket-client==1.3.2
Werkzeug==2.1.1
wrapt==1.14.0
zipp==3.8.0

$ python -m unittest lib/repositories/test_data.py
Pulling image postgres:14.2
Container started: 574de53a16
Waiting to be ready...
exposed port: 49171
postgresql+psycopg2://test:test@localhost:49171/test
.
----------------------------------------------------------------------
Ran 1 test in 1.795s

OK

Thanks for reporting. I can't reproduce the issue here. Would you mind running your test on master? You can run pip install git+https://github.com/testcontainers/testcontainers-python to install the master version.

import unittest
from operator import contains

import psycopg2
from testcontainers.postgres import PostgresContainer

class TestBugReport(unittest.TestCase):

    def test_bug_report(self):
        with PostgresContainer('postgres:14.2') as postgres:
            postgres.get_exposed_port(5432)
            print(f"exposed port: {postgres.get_exposed_port(5432)}")
            connection_string = postgres.get_connection_url()
            print(connection_string)

            connection = psycopg2.connect(
                user=postgres.POSTGRES_USER,
                password=postgres.POSTGRES_PASSWORD,
                host=postgres.get_container_host_ip(),
                port=postgres.get_exposed_port(5432),
                database=postgres.POSTGRES_DB,
            )

            cursor = connection.cursor()
            cursor.execute("""select version()""")
            row = cursor.fetchone()
            self.assertTrue(contains(row[0], 'PostgreSQL 14.2'))

if __name__ == '__main__':
    unittest.main()

$ pip install testcontainers[postgresql]==3.5.3
Collecting testcontainers[postgresql]==3.5.3
  Using cached testcontainers-3.5.3-py2.py3-none-any.whl (35 kB)
Requirement already satisfied: deprecation in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.5.3) (2.1.0)
Requirement already satisfied: docker in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.5.3) (5.0.3)
Requirement already satisfied: wrapt in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.5.3) (1.14.0)
Requirement already satisfied: psycopg2-binary; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.5.3) (2.9.3)
Requirement already satisfied: sqlalchemy; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.5.3) (1.4.35)
Requirement already satisfied: packaging in ./venv/lib/python3.8/site-packages (from deprecation->testcontainers[postgresql]==3.5.3) (21.3)
Requirement already satisfied: requests!=2.18.0,>=2.14.2 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.5.3) (2.27.1)
Requirement already satisfied: websocket-client>=0.32.0 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.5.3) (1.3.2)
Requirement already satisfied: greenlet!=0.4.17; python_version >= "3" and (platform_machine == "aarch64" or (platform_machine == "ppc64le" or (platform_machine == "x86_64" or (platform_machine == "amd64" or (platform_machine == "AMD64" or (platform_machine == "win32" or platform_machine == "WIN32")))))) in ./venv/lib/python3.8/site-packages (from sqlalchemy; extra == "postgresql"->testcontainers[postgresql]==3.5.3) (1.1.2)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in ./venv/lib/python3.8/site-packages (from packaging->deprecation->testcontainers[postgresql]==3.5.3) (2.4.7)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.5.3) (1.26.9)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.5.3) (2021.10.8)
Requirement already satisfied: charset-normalizer~=2.0.0; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.5.3) (2.0.12)
Requirement already satisfied: idna<4,>=2.5; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.5.3) (3.3)
Installing collected packages: testcontainers
  Attempting uninstall: testcontainers
    Found existing installation: testcontainers 3.4.2
    Uninstalling testcontainers-3.4.2:
      Successfully uninstalled testcontainers-3.4.2
Successfully installed testcontainers-3.5.3

$ python -m unittest lib/repositories/test_bug_report.py
Pulling image postgres:14.2
Container started: 0ecf8811aa
Waiting to be ready...
container is not yet ready: Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server at "localhost" (<IP_ADDRESS>), port 49284 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/waiting_utils.py", line 49, in wrapper
    return wrapped(*args, **kwargs)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/generic.py", line 33, in _connect
    engine.connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3234, in connect
    return self._connection_cls(self, close_with_result=close_with_result)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 96, in __init__
    else engine.raw_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3313, in raw_connection
    return self._wrap_pool_connect(self.pool.connect, _connection)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3283, in _wrap_pool_connect
    Connection._handle_dbapi_exception_noconnection(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2117, in _handle_dbapi_exception_noconnection
    util.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (<IP_ADDRESS>), port 49284 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

(Background on this error at: https://sqlalche.me/e/14/e3q8)

container is not yet ready: Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
psycopg2.OperationalError: connection to server at "localhost" (<IP_ADDRESS>), port 49284 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/waiting_utils.py", line 49, in wrapper
    return wrapped(*args, **kwargs)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/testcontainers/core/generic.py", line 33, in _connect
    engine.connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3234, in connect
    return self._connection_cls(self, close_with_result=close_with_result)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 96, in __init__
    else engine.raw_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3313, in raw_connection
    return self._wrap_pool_connect(self.pool.connect, _connection)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3283, in _wrap_pool_connect
    Connection._handle_dbapi_exception_noconnection(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 2117, in _handle_dbapi_exception_noconnection
    util.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/base.py", line 3280, in _wrap_pool_connect
    return fn()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 310, in connect
    return _ConnectionFairy._checkout(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 868, in _checkout
    fairy = _ConnectionRecord.checkout(pool)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 476, in checkout
    rec = pool._do_get()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 146, in _do_get
    self._dec_overflow()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/impl.py", line 143, in _do_get
    return self._create_connection()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 256, in _create_connection
    return _ConnectionRecord(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 371, in __init__
    self.__connect()
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 666, in __connect
    pool.logger.debug("Error on connect(): %s", e)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/langhelpers.py", line 70, in __exit__
    compat.raise_(
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/util/compat.py", line 207, in raise_
    raise exception
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/pool/base.py", line 661, in __connect
    self.dbapi_connection = connection = pool._invoke_creator(self)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/create.py", line 590, in connect
    return dialect.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/sqlalchemy/engine/default.py", line 597, in connect
    return self.dbapi.connect(*cargs, **cparams)
  File "/home/ndlarsen/src/job/lego/data-engineer/ingestion-service/venv/lib/python3.8/site-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "localhost" (<IP_ADDRESS>), port 49284 failed: server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.

(Background on this error at: https://sqlalche.me/e/14/e3q8)

exposed port: 49284
postgresql+psycopg2://test:test@localhost:49284/test
.
----------------------------------------------------------------------
Ran 1 test in 2.740s

OK

pip install git+https://github.com/testcontainers/testcontainers-python

$ python -m unittest lib/repositories/test_bug_report.py
Pulling image postgres:14.2
Container started: 509d2513ec
Waiting to be ready...
exposed port: 49282
postgresql+psycopg2://test:test@localhost:49282/test
.
----------------------------------------------------------------------
Ran 1 test in 2.751s

OK

$ pip install testcontainers[postgresql]==3.4.2
Collecting testcontainers[postgresql]==3.4.2
  Using cached testcontainers-3.4.2-py2.py3-none-any.whl (31 kB)
Requirement already satisfied: deprecation in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (2.1.0)
Requirement already satisfied: docker in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (5.0.3)
Requirement already satisfied: wrapt in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (1.14.0)
Requirement already satisfied: sqlalchemy; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (1.4.35)
Requirement already satisfied: psycopg2-binary; extra == "postgresql" in ./venv/lib/python3.8/site-packages (from testcontainers[postgresql]==3.4.2) (2.9.3)
Requirement already satisfied: packaging in ./venv/lib/python3.8/site-packages (from deprecation->testcontainers[postgresql]==3.4.2) (21.3)
Requirement already satisfied: requests!=2.18.0,>=2.14.2 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.4.2) (2.27.1)
Requirement already satisfied: websocket-client>=0.32.0 in ./venv/lib/python3.8/site-packages (from docker->testcontainers[postgresql]==3.4.2) (1.3.2)
Requirement already satisfied: greenlet!=0.4.17; python_version >= "3" and (platform_machine == "aarch64" or (platform_machine == "ppc64le" or (platform_machine == "x86_64" or (platform_machine == "amd64" or (platform_machine == "AMD64" or (platform_machine == "win32" or platform_machine == "WIN32")))))) in ./venv/lib/python3.8/site-packages (from sqlalchemy; extra == "postgresql"->testcontainers[postgresql]==3.4.2) (1.1.2)
Requirement already satisfied: pyparsing!=3.0.5,>=2.0.2 in ./venv/lib/python3.8/site-packages (from packaging->deprecation->testcontainers[postgresql]==3.4.2) (2.4.7)
Requirement already satisfied: charset-normalizer~=2.0.0; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (2.0.12)
Requirement already satisfied: idna<4,>=2.5; python_version >= "3" in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (3.3)
Requirement already satisfied: certifi>=2017.4.17 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (2021.10.8)
Requirement already satisfied: urllib3<1.27,>=1.21.1 in ./venv/lib/python3.8/site-packages (from requests!=2.18.0,>=2.14.2->docker->testcontainers[postgresql]==3.4.2) (1.26.9)
Installing collected packages: testcontainers
  Attempting uninstall: testcontainers
    Found existing installation: testcontainers 3.5.3
    Uninstalling testcontainers-3.5.3:
      Successfully uninstalled testcontainers-3.5.3
Successfully installed testcontainers-3.4.2

$ python -m unittest lib/repositories/test_bug_report.py
Pulling image postgres:14.2
Container started: 6058b98753
Waiting to be ready...
exposed port: 49285
postgresql+psycopg2://test:test@localhost:49285/test
.
----------------------------------------------------------------------
Ran 1 test in 1.756s

OK

So, whaterever is happening in versions 3.5.0, 3.5.1, 3.5.2 and 3.5.3, does not seem be be happening in 3.4.2 or in current master.

It seems like the only relevant change is a change in logging level (see here for details).
I still can't reproduce the issue either on 3.5.3 from pypi or by installing from the v3.5.3 tag. We could release a new patch version to see whether that fixes your issue, but I'm not sure it will resolve things.

First of all, thank you for your time, I appreciate it. Second, seeing the implementation of def wrapper(wrapped, instance, args, kwargs), it is clear that the code is not breaking at all but logging during the retry loop and, as you are pointing out, this is just evident due to a change in logging level. I wrongly assumed that it broke as the exception was logged. I expect whatever is the actual cause for connection retries is local to my setup (perhaps due to some sort of timing issue) and as such also present while trying out other versions but not immediately evident due to different logging level. I apologise.
Now, from a user's point of view, I think keeping the logging level at debug makes most sense as at the point of logging the code is still in a state of trying to connect to a container. If, however, config.MAX_TRIES is reached, a more expressive logging might be in order but not needed per se. If anything should be logged while caught in the retry loop, it could be a simple informative message without the actual exception/stack trace, as illustrated here

Closing this for now as #207 is merged. But feel free to restart the discussion if this issue persists.

Same issue here on 3.5.3, had to downgrade to 3.4.2.
Looking forward to testing it again on the next release.

Fresh out of the oven :slightly_smiling_face:
3.5.4 works fine, thanks!


HOSTEDCP-954: Remove ec2:ReleaseAddress

What this PR does / why we need it:
Checking if ec2:ReleaseAddress is needed for NodePool management polcy or not
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story:
Fixes https://issues.redhat.com/browse/HOSTEDCP-954
Checklist

[x ] Subject and description added to both, commit and PR.
[ x] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

area/hypershift-operator

/retest

@fahlmant you need to make update to update automation with the API comment and get CI happy

@enxebre what is the infra cmd? It looks like its referencing the ReleaseAddress API?

@jharrington22 hypershift provides a helper CLI for devs to bring their infra before creating a HostedCluster.
In that infra topology we create nat gateways with EIPs.

@enxebre what is the infra cmd? It looks like its referencing the ReleaseAddress API?

@jharrington22 hypershift provides a helper CLI for devs to bring their infra before creating a HostedCluster. In that infra topology we create nat gateways with EIPs.
That's separate from the iam policies that the operators we run might need.

I thought that might be the case just making sure. Thanks @enxebre

/retest

/approve
/lgtm


Error when building goloop-0.9.4

Hello,
I got this error when following the build instructions on a Linux & Mac environment :
$ wget https://github.com/icon-project/goloop/archive/v0.9.4.zip && unzip v0.9.4.zip && cd goloop-0.9.4
$ python3 -m venv ./venv
$ source ./venv/bin/activate
$ pip3 install -r pyee/requirements.txt
$ make

It outputs the following error
go build ./cmd/goloopgo build -tags "" -ldflags "-X 'main.version=v0.9.4' -X 'main.build=linux/amd64 tags()-2021-02-02-16:41:28'" -o ./bin/goloop ./cmd/goloop
# github.com/icon-project/goloop/icon/iiss
icon/iiss/base.go:212:2: cannot use tx (type *baseV3) as type transaction.Transaction in return argument:
    *baseV3 does not implement transaction.Transaction (missing IsSkippable method)
icon/iiss/base.go:233:2: cannot use tx (type *baseV3) as type transaction.Transaction in return argument:
    *baseV3 does not implement transaction.Transaction (missing IsSkippable method)

Is there's something missing in the build instructions or am I missing something ?
Thanks!

I managed to compile goloop v0.9.5 on the "base" branch.
Could you update the .zip in the Release?
$ ./bin/goloop version
goloop version v0.9.5 linux/amd64 tags()-2021-02-02-17:35:05

The .zip file is managed by github.com. It's automatically generated by the tagged source.
We already know that v0.9.4 has a build problem.  It would be removed or marked as "broken" to let you know that it's not usable.

Hi @Spl3en
You can find the zip file of v0.9.5 at https://github.com/icon-project/goloop/archive/v0.9.5.zip
It seems github only regards tags with the default branch as latest, but you can browse all the tags at Release section.


Removes the last of circa 2012 Cassandra

This cleans up both the build and the source tree of orphaned cassandra
code and dependencies.

Nice! I had forgotten about all this stuff in my haste on #585. Thanks.


Don't get it working

With below config (as in the example) I try to send something to a webhook tester. I get the "failed to fetch" message.
Please advise.
[
{
"name": "myslack",
"action": {
"url": "https://webhook.site/72e72360-b9c6-4cdc-8d5d-a6bbd9d250e6",
"payload": {
"text": "%s"
}
}
}
]

There is nothing we can do if the webhook api is not reachable, please double-check its url, method and cross-origin requirements.


Fix requirements for versioned commits

Change-type: patch
Signed-off-by: Kyle Harding<EMAIL_ADDRESS>

@balena-ci I self-certify!


csv.csvwriter not actually writing to tempfile.TemporaryFile

Describe the bug

Looks like csv.csvwriter is not working when in a tempfile.TemporaryFile.
How To Reproduce

import csv
import pathlib
import tempfile

import pytest

THIS_DIRECTORY = pathlib.PurePath(__file__).parent

@pytest.fixture(name="this_dir_fs")
def fixture_this_dir_fs(fs):
    fs.add_real_directory(THIS_DIRECTORY, read_only=False)
    return fs

def test_csv_in_tempfile(this_dir_fs) -> None:
    with tempfile.TemporaryFile(mode="w+", newline="", encoding="utf-8") as f:
        csv.writer(f).writerows([(1, 2), (3, 4)])
        assert len(f.readlines()) == 2  # Fails

Your environment

> python -c "import platform; print(platform.platform())"
macOS-12.6-arm64-arm-64bit
> python -c "import sys; print('Python', sys.version)"
Python 3.10.9 (main, Jan  6 2023, 11:19:20) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
> python -c "from pyfakefs import __version__; print('pyfakefs', __version__)"
pyfakefs 5.2.2
> python -c "import pytest; print('pytest', pytest.__version__)"
pytest 7.3.1

Closing as this has nothing to do with pyfakefs, this also fails:
import csv
import tempfile

with tempfile.TemporaryFile(mode="w+", newline="", encoding="utf-8") as f:
    csv.writer(f).writerows([(1, 2), (3, 4)])
    assert len(f.readlines()) == 2  # Fails

The fix is resetting f to the beginning of the file before readlines() with f.seek(0)


Question: How to add description to tags?

Problem statement
In the swagger specification you can add a description to a tag when you declare it globally.

Optionally, you can specify description and externalDocs for each tag by using the global tags section on the root level. The tag names here should match those used in operations.
tags:

name: pets
description: Everything about your Pets
...

Is there a way to add a description to tags when using go-swagger to generate your server spec? I am having a hard time finding a way.
Swagger specification
Swagger Spec 2.0

Any workaround for this feature?

i need it too...description

Start with an input spec that has your tags
swagger generate spec --input seedfile.json


Terminal: search context isn't focused on successive toggles with Ctrl+F

When testing https://github.com/microsoft/vscode/issues/78108
Local OS: macOS/windows/linux
Stable:

Insiders:

Good catch. Looks like the subsequent ctrl+f's try to give focus back to the editor's find widget and will open it even though the terminal find widget is already open. You just don't see that in this case because there is no file open in this case

@Tyriar this is a regression even before #77958 as reverting my changes doesn't fix the problem.