:racehorse: Avoid setting hidden input value on textInput

Atom currently sets the value of the input on every textInput event, in an effort to appropriately handle changes made via the OSX diacritic menu (for accents, umlauts, etc).
The drawback of this is approach is that updating the value of the input will trigger layout and a subsequent layer tree update.
To resolve this, here is my proposal:

Track a flag for keypress events. When the diacritic menu is used, there are two textInput events, with no keypress in between. Therefore, when no keypress has occurred just prior to a textInput, the editor model can select the previous character to be replaced by the new accented character.
Track a flag for compositionstart events. When a user is in IME mode, the diacritic menu cannot be used, so the editor can skip the backward selection.

Test Plan:
Tested in a plaintext file.

Type Latin characters, verify proper character insertion.
Press and hold a. Diacritic menu appears. Select an option using the keyboard or mouse. Verify that the a is replaced by an accented a, with no extra characters.
Type test strings in Katakana, 2-Set Korean, Telex (Vietnamese), Simplified Pinyin. Verify that characters are inserted correctly while composing, and after committing strings.

cc @ssorallen @nathansobo

Looks like this broke some specs.

Taking a look at the test failures.

@hellendag I noted in the spec that the keypress event is deprecated. Did you look for any other non-deprecated events with a similar behavior? Odds are pretty low that Chrome will drop this event any time soon but it would be nice if we could avoid building on deprecated functionality.

I guess textInput isn't standardized either. Forgot about that 😬. I've never looked into the edit events that replace them but perhaps that's a topic for another PR. Disregard my previous comment.

@hellendag I think I've found a hole. When you open the accented character menu, you can use the left and right arrows to cycle through the options in addition to pressing a number or the mouse. I wonder if we need to filter out the left and right arrow keys when setting the keypress flag?

Yeah, I'm still hoping that beforeEdit/beforeInput gets implemented at some point. In the meantime, at least we've got textInput. :)

Our internal build passed and the Travis failure is due to connectivity issues. Going to merge.


Revert "Don't run Google Analytics locally. (#28384)

Reverts #28384.
Second of two PRs to supersede #28486.

Currently doing some light reading into GDPR and GA. #28351 was opened by a deleted account and while the motivation for that issue is in question, there do seem to be some things we should audit and consider. Hence, this PR.

I don't this really solves anything hence the revert.
If we want to care about GDPR we should do it properly in another PR.

Having reviewed our GA settings, the data retention period looks good and no data is being shared with Google's advertising or any other partner (thus, no need for consent to sharing data as I understand it). Whatever GA collects stays in GA.
Will revisit and confirm Carbon separately.

Just so we are on the same side, GDPR isn't about that. We need to inform every visitor their data is being collected and get their consent.
That being said, we can at least anonymize the IPs in GA. I will make a PR for this tomorrow.

I understand GDPR is about both—collection and sharing. My last comment was from reading multiple articles that has that guidance for GA as it relates to sharing though. Still reading more about it though and will see what we need to do for the pure collection aspect.
I'm no expert, so keep me honest. Just sharing what I'm learning along the way.

That being said, we can at least anonymize the IPs in GA. I will make a PR for this tomorrow.

Awesome, thanks for that!

Actually while reviewing our GA settings, realized we're on an old script and we can anonymize from that new one. See first stab at #28491 before getting going @XhmikosR.

This wasn't about GDPR, but rather that local users should not have their information beamed to GA (because local files don't match the domain, I think GA rejects their pings anyway). The references to ga in onclick handlers need to be made conditional on .Site.IsServer as well and then this won't throw errors.


Documentation update for standalone binary and gh-pages update process

Minor documentation update to put info about standalone binary following v0.24 and to clarify a bit more about how to update our gh-pages.
After this, I should submit a PR for gh-pages branch to reflect all the doc updates which have been merged to master (e.g. kubernetes example, helm input examples etc.). If possible, it might be nice in the future to deploy to gh-pages directly from Travis after successful merge to master.

Thanks!


Exclude ethnic group pattern from sitemap and nav

The ‘asking users for ethnic groups’ pattern was archived in #1582 and redirected to the new ‘asking users for equality information’ pattern.
However, the Design System currently relies on the ignore_in_sitemap flag in the frontmatter when deciding whether the page should appear in the sitemap and the site navigation.
This means that the pattern is still appearing in the sitemap, and also at the very bottom of the Patterns navigation.

Add the ignore_in_sitemap flag to the archived page to remove it from both places.
Fixes #1592.

You can preview this change here:
Built with commit 061d737bd90614f36f525f4129bc55d3353625e5
https://deploy-preview-1601--govuk-design-system-preview.netlify.app


FPGA ITRNG implementation

I believe the root cause of the repetition count failures is corruption on the AXI bus. Here is an example where a write to the itrng FIFO happens in the middle of writing zeroes to a fuse. In this scenario I force the fpga realtime model rust code to never write zero data, and the itrng_fifo_din takes the zero data from the fuse writes.

Here is another example where the itrng_fifo_din takes increment data from writes to the field entropy registers.

My chief suspect is the soc_adapter not complying with the AXI Lite spec.


Dropdown closes when I click on the scrollbar (IE8/11)

Two bugs are detected with boost 3.0.2 and boosted 3.3.0 for dropdowns.
We use a dropdown with many items. We defined a height for the "ul" tag. Thus, a scrollbar is used.
Issues :

The focus is still set on the first element and hover element instead of only being set on the hover element. (Usual behavior Bootstrap dropdowns and traditional select boxes) (IE, Chrome - not tested on Firefox)

The dropdown is closed when a click is done on a scollbar (IE only)
No issue when we use the mouse wheel. I guess there is a loss focus problem for this bug when we click on the scrollbar on IE as shawn on the image below

Could you please quickly provide us a solution for these two bugs?
Thank you.

Issue 1 fixed in commit 2b8bbc4
Issue 2 fixed in commit 9befc8a

Thank you. I will test it :)


Actions security

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.07%. Comparing base (cf178e8) to head (c39b98c).

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #65   +/-   ##
=======================================
  Coverage   99.07%   99.07%
=======================================
  Files        3292     3292
  Lines       29317    29317
  Branches      209      209
=======================================
  Hits        29047    29047
  Misses        210      210
  Partials       60       60

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Missing emotes

Cannot customize Explore emote, Shattered Relic emote or Party emote.

"Party" was added since I first released the plugin, so I need to add that one. As for the others, I logged in to check, and I was able to add highlights/labels to them just fine, so I'm not sure what's going wrong there without more info

I see. "Explore" can't be customized because you haven't unlocked it, and I don't see a use case for highlighting emotes you can't perform. Maybe I should update the documentation so it doesn't confuse people.
The leagues emote is more complicated than I thought, because it changes depending on which leagues outfit you have, and I have a different one. I'll look into fixing that one.

No probs, thanks for your help! 😊
Sent from Mailhttps://go.microsoft.com/fwlink/?LinkId=550986 for Windows
From: @.>
Sent: 12 June 2023 22:35
To: @.>
Cc: @.>; @.>
Subject: Re: [equirs/emotes] Missing emotes (Issue #2)
I see. "Explore" can't be customized because you haven't unlocked it, and I don't see a use case for highlighting emotes you can't perform. Maybe I should update the documentation so it doesn't confuse people.
The leagues emote is more complicated than I thought, because it changes depending on which leagues outfit you have, and I have a different one. I'll look into fixing that one.
—
Reply to this email directly, view it on GitHubhttps://github.com/equirs/emotes/issues/2#issuecomment-1588139960, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A74RJTNSNBIWO22TOJEFLODXK6DTJANCNFSM6AAAAAAZD4763I.
You are receiving this because you authored the thread.Message ID: @.***>

Fixed in version 0.0.3


feat(website): update setting up wallet docs

@2manslkh could we use the shortishName from the domain/config? this says "Grimsvotn L2", etc. instead of just "Grimsvotn". I think this is more verbose/useful for the user.
Secondly, can we add a button for adding all Eldfell L3 tokens as well?

Closes #14171


New Result Screen

Make some changes to the Result screen

Do you like it?

I don't see what's new here
On Thu, Oct 27, 2022, 10:20 PM Sagar Kattel @.***>
wrote:

Do you like it?
—
Reply to this email directly, view it on GitHub
https://github.com/salmannotkhan/typing-test/pull/31#issuecomment-1293805968,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGN64PAUQ564ULH3NW4IY6LWFKXDZANCNFSM6AAAAAARQHKTAY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Highlighting text and typing a block character should enclose that text.

For example, highlighting hello world and typing " should produce "hello world" instead of ".

@Kevsani this is also a low hanging fruit.


"Code review"

Hullo!
This isn't a real issue; instead I thought I'd drop a line since I used this project's code as a basis when implementing Intersection Observer into an older existing lib where I didn't want to have some of the baggage that this project currently has (or had), and I also wanted to do some minor changes to terminology that this project most likely doesn't want to include.
I think this project's implementation of Intersection Observer API for React is the best on npm, and I also think this project is now very close to version 1.0.0 as the Symbol issue was just removed. The weaknesses, from my point of view as an author who might want to use this project in their lib, are mostly in dependencies and use of modern code syntax that results into verbose results (as long as we need to keep babelizing and polyfilling).
I think it is ideal for any component that is used as a basis for other components to have as little dependency and as little unnecessary abstraction as possible. So, from this perspective here are some things that I changed when I refactored this project as part of react-lazy.
IntersectionObserverContainer.js
This goes a lot into opionated side of things, but I couldn't see any purpose for making IntersectionObserverContainer a class. Essentially all the methods are static functions and nothing is self-contained into the class itself. Thus I changed the file into intersectionObserver.js, removed class and renamed the functions to be a bit more verbose.
The advantage in this is reduced final code size. And there is also a little bit less confusion as well since IntersectionObserverContainer is not a React component, which one might first assume it to be.
The callback method
I had two thoughts related to the callback:

create method receives it, but ignores it's existance when calling getPooled method, yet it is required for new IntersectionObserver.
it feels a bit odd to find the callback method defined in IntersectionObserver component file since it relies more on internal mechanics of IntersectionObserverContainer file than what can be found in the component.

The first point introduces a possible future bug as callback is not checked against. Of course the current implementation always has the same callback, but the interface gives an impression that one could change it.
For the second point I think the callback method becomes easier to understand when it is moved to the other file as all the related Map and Set context is there.
Abstraction
Doing these changes would reduce code size.

IntersectionObserverContainer.clear() and IntersectionObserverContainer.count() are only used for tests, simple to just remove as storage is exposed anyway
compareObserverProps method in the component is easy to inline
reobserve method in the component is used only once, easy to inline
isDOMTypeElement is used only once, easy to inline

Unnecessary creation of new object in reduce
In component's get options is an unnecessary object spread: you can freely mutate an object you have created for a reducer.
warning is included for production build
I guess this should be inside a `process.env.NODE_ENV !== 'production' block. In the other hand onlyOnce is about to be removed so worth fixing only if it will take a while for the next major release.
Targetting
this.target, this.renderedTarget, this.targetChanged... I know these are very fast to access if compared to calling this.setState, but I can't really avoid the thought that the code could be simpler with setState.
PureComponent?
Current target management prevents using this. With setState this would become a viable solution to the shallow props checking. Of course it isn't exactly the same: the shouldComponentUpdate implementation doesn't check the contents of an array, only the reference. Maybe threshold could be a string instead of an array to make things easier?
Final thoughts
For reference, here are links to how I refactored those files:

IntersectionObserverContainer.js -> intersectionObserver.js
IntersectionObserver.jsx -> Observer.jsx

I did other minor changes as well which might be interesting to see, but there are so many changes (and I don't use semicolons) that diff isn't much of help. Most of the code should seem very familiar as it does implement the exact same logic, but only does it with either slightly faster means or code that results in reduced babelized code size or less dependencies.
And then there is also the addition of viewport (root) and cushion (rootMargin) props, which seem like easier to understand what those props do than what IntersectionObserver options say.
Anyway, hopefully these thoughts are of some value :)

Hey @Merri!
This is one of the most valuable issues I’ve received on Github thus far. Thank you for doing such a thorough code review, it's great!
There're very good points, so let me say first off that I agree with the majority of them. I'd like to include these changes – probably with the exception of terminology for obvious reasons – but I want to start with leveraging code size reduction and better organization and inlining of code.
Ideally we’d implement enough of your suggestions, so that react-lazy can include this package as one of its dependencies. If you think this is possible, I’d like for either you or us to open a PR soon, so that we can release a new version containing all the changes.
So let’s break down your suggestion into actionable points – let me know later if I left anything out:
IntersectionObserverContainer.js
I measured the uglified Babel output (after removing the runtime assuming it’s in a shared module) and yours comes out almost 200 bytes lighter 👍
Observer callback
Do not see the part of the future bug, but it should be moved to the above-mentioned file indeed 👍
Abstraction

clear/count can be removed 👍
compareObserverProps is idiomatic, but it can be inlined if you want as a variable with the same name 👍
reobserve can be inlined 👍
isDOMTypeElement is used once, but as a separate method makes is easier for testing, I would leave it (I don’t feel too strong about leaving it either, but it’s nice to ensure the child is valid in such a clear way).

new object in reduce
Yep, I didn’t see that one 👍
warning
I also though it’d be removed soon, but later I decided it might stay a while, since probably too many people have relied on onlyOnce on their codebases at this point. So let’s IF for NODE_ENV too 👍
Targetting
The problem with setState is that we’d be calling render() again. Despite the impression that we’re 100% declarative, we're still working with an imperative API and side-effects coming from the DOM. IMO setState must reflect the state of the UI, not an internal logic flag. We can be efficient at comparing whether the DOM node only by saving the previous+next targets. If we compare children, React will never compare them deeply, so you will have different children elements  – unless you store your element object reference in another place and you keep it in memory for further re-renders.
PureComponent
Unfortunately, PureComponent can’t compare children efficiently like I was saying. It's not the react-way to optimise things, to store a reference either. We won’t be able to determine if we need to re-observe a DOM node unless we re-render, because that node reference is inside the ref callback, so that's what we do.
Instead, when we use <Observer> inside a parent component, this parent usually takes charge of the bailing out part. At RG for instance, these parents are quite often HOC-wrapped – with connect() from redux or similar.
You can apply PureComponent on your parent components the way you prefer it, provided you know that the child node you’re observing will never change, and this is the case almost every time.
I’m extending myself quite long here, but the point is that you probably shouldn’t be re-using the observer for different target types, and if you do, we expect the correct behavior to happen.
Semicolons
I don’t care. I really don’t care, let’s remove them, let’s add them… Post-processing will get rid off most of them anyways.
Terminology
I am pretty sure you can keep viewport and cushion on your components <Lazy> and <LazyGroup> without changing it here; you don't even use <Observer> directly on your demo. Our terminology is the Native API one, and I'd like to keep it that way so that no one has to remember two APIs :simple_smile:

Great :)
I guess one way to go would be to create a pull request with a lot of micro size commits, then let you decide which ones of the changes you want to take and leave out the commits that don't make the cut (since there are some less important changes/suggestions). Then once there is a new version out I'll update react-lazy and add this package to the peerDependencies. Sounds like a plan? Or would you rather want pull requests that each have a specific theme?
Callback
The bug with callback is that if it was possible to actually change the callback then it would be become possible that an incorrect instance of IntersectionObserver would be given for options that match existing IntersectionObserver, but have a different callback, since there is no check against it. This is why I think callback shouldn't be passed to the create method as the code assumes it to always be the same.
isDOMTypeElement
To me testing this is testing a React feature and it shouldn't be a test concern for this component. This method would only break if React changed a lot, in which case they are probably responsible enough to create a new method instead of breaking an old one.
Target
This one (and PureComponent) were the things I were least sure of suggesting as I didn't go ahead and write any code. There is something that bothers me with using three variables for what essentially should need only two variables (past and present). Also, the fact there is mutative code in render method makes me think there would be something wrong.
If I understand the cycle correctly off the top of my head, it goes render -> handleNode -> componentDidUpdate. If this holds true then this.unobserve() is called two times when target changes. This then makes me think that handleNode should only be concerned about setting this.target and componentDidUpdate should be the one that checks whether the target has changed and then track the previous target. Furthermore this would remove the need for this.targetChanged and also remove this.renderedTarget from render. I'd also rename it prevTarget as that would match with React convention.
But this is again where I assume a lot without testing if my understanding is correct :)

I guess one way to go would be to create a pull request with a lot of micro size commits

Sounds like a plan.

If I understand the cycle correctly off the top of my head, it goes render -> handleNode -> componentDidUpdate. If this holds true then this.unobserve() is called two times when target changes

That's right, we need to stop observing it before the node is removed from the DOM. This part was thought out way before methods like getSnapshotBeforeUpdate() were introduced, and I decided to live with the fact that it's called twice (at a very low runtime cost).
If we do this, I have to introduce react-lifecycles-compat, unless you have a suggestion that's compatible with React 15.
I think it might be enough to just replace cDU with this:
componentDidUpdate(prevProps) {
    if (this.targetChanged) {
        if (!this.props.disabled) {
            this.observe();
        } else if (this.compareObserverProps(prevProps)) {
            this.reobserve();
        }
    }

Thoughts?

Hmmh, I guess that forces the boolean variable. Doesn't seem worthwhile to change the code to be "proper" and make react-lifecycles-compat a hard requirement as the current solution does work. With this about the only suggestion would be to document this detail in the code with comments and maybe make some kind of plan when to drop support of pre-16.3 versions of React so that it can then be fixed :) Seems quite hard to find React version share statistics.
I try to fork and start throwing commits together during the weekend. Had to wake up earlier than usual which isn't ideal for getting anything done.


It seems that a small number of people leave comments about the Google Search Console registration

For example, if you have a To register Google Search Console
Ex )
1. Google Search Console issues a meta tag.
2.  app/layout.tsx
It doesn't seem like a bad choice to add it to a Readme.md file, what do you think?

Sorry I don't understand this question


Everything wrong with Windows Mobile Phone

Nothing is correct on Windows Mobile: nor the version, nor the browser, nor the platform.
Here is the code:
use Jenssegers\Agent\Agent;

$agent = new Agent();

$txt = "";

$browser = $agent->browser();
$platform = $agent->platform();

$txt .= "Browser: ".$browser."
";
$txt .= "Version: ".$agent->version($browser)."
";

$txt .= "Platform: ".$platform."
";
$txt .= "Version: ".$agent->version($platform)."
";
$txt .= "Useragent: ".$_SERVER['HTTP_USER_AGENT']."
";

echo $txt;

and here the output
Browser: Safari
Version: 537
Platform: AndroidOS
Version: 4.0
Useragent: Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 730 Dual SIM) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537

This is actually an issue with the original MobileDetect library. Can you open an issue there?

Uhm... Maybe is it already fixed? I got this string if I test the MobileDetect demo. http://demo.mobiledetect.net/
Experimental version() method

version(Mobile) string(4) "11.0"
version(IE) string(4) "11.0"
version(Safari) string(3) "537"
version(Webkit) string(3) "537"
version(Trident) string(3) "7.0"
version(iOS) string(5) "7_0_3"
version(Android) string(3) "4.0"
version(Windows Phone OS) string(3) "8.1"
version(Windows Phone) string(3) "8.1"

Debug

Matching Regex string(19) "IEMobile|MSIEMobile"
Matching Array array(1) { [0]=> string(8) "IEMobile" }


Bugfix: Inverting bool value in rust

Description
When executing rust procedures, any boolean arguments get negated.
Pull request type

[x] Bugfix

Related issues
https://github.com/memgraph/mage/issues/426
######################################
Reviewer checklist (the reviewer checks this part)
Module/Algorithm

[ ] Core algorithm/module implementation
[ ] Query module implementation
[x] Unit tests
[ ] End-to-end tests
[ ] Code documentation
[ ] README short description
[ ] Documentation on memgraph/docs
[ ] Update GQLALchemy signatures in query builder using query module signature generator

######################################

@kgolubic
Changelog: Rust bool value conversion fixed.

Maybe add a test to rust/rsmgp-sys/src/value/tests.rs

@andrejtonev the milestone is missing. Can you please set it?

@kgolubic mage does not follow the same workflow as memgraph. No milestone is defined.


App key as web.AppKey

To work with keys that are inside the App, starting from version 3.9, it is recommended to use the object web.AppKey
Up minimal version of aiohttp - 3.9.0
Docs: https://docs.aiohttp.org/en/stable/_modules/aiohttp/web_app.html

Released in https://pypi.org/project/pydantic_aiohttp/1.0.1/ with modifications
https://github.com/Maillol/aiohttp-pydantic/pull/54/files in order to ensure backwards compatibility.


Please correct Define-XML Stylesheets project name

Please change the project name from Define-XML XLS Stylesheets to: Define-XML XSL Stylesheets.
The project does not use Excel ;-)

solved


cli: Fix #1897

Description
Added some logs to denote the current units used internally (everything is expressed in units of 10^-18).
Didn't add any name for this unit (i.e. 'wei') since it sounds like we are not decided on what we want to call these.
Tested
Ran yarn test to verify balance logging doesn't change test execution
Related issues

Fixes #1897

I agree that I'd like to get Claire's opinion, so I'll wait on merging until then.
I wanted to divide by 10^-18 but I'm worried about creating inconsistencies if there are other places these values are exposed and those are not reduced.

i don't there are other places.. but yeah, not sure
On Tue, Nov 26, 2019 at 9:45 PM lucasege<EMAIL_ADDRESS>wrote:

I agree that I'd like to get Claire's opinion, so I'll wait on merging
until then.
I wanted to divide by 10^-18 but I'm worried about creating
inconsistencies if there are other places these values are exposed and
those are not reduced.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/celo-org/celo-monorepo/pull/1925?email_source=notifications&email_token=AAFAHFD4A6LRBILYIWAJAN3QVW7LPA5CNFSM4JR7J3PKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFH46ZA#issuecomment-558878564,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFAHFDPO6LBUPSVMQ5C2KTQVW7LPANCNFSM4JR7J3PA
.


 tag is not adapting the column width in bootstrap

I am using Bootstrap 5 to style my page. When I am using the
...
 tag inside the class="col" then it is not adapting the width of the column instead of that it is increasing the width of the whole column. But when I am using the class="col-lg-8" it is working fine.
HTML CODE

             ...

With
 tag and class="col"

With
 tag and class="col-lg-8"

Without
 tag

Check it live here
https://thelovekesh.github.io/cbtheme-debug/blog/
Originally posted by @thelovekesh in https://github.com/twbs/bootstrap/discussions/33640

This is a feature of flex box. This explains the behaviour pretty well.
We could add min-width: 0 to our columns to override the default behaviour but not sure if that's really preferred in every situation 🤔

min-width: 0 didnt work here. :(

Closing as a won't fix per comment above. All depends on the situation, so keeping the solution as such. <3


Revision of BYOL module and tests

What does this PR do?

Fixes part of #839

pl_bolts.models.self_supervised.byol.byol_module.BYOL
pl_bolts.models.self_supervised.byol.models.MLP
pl_bolts.models.self_supervised.byol.models.SiameseArm
pl_bolts.tests.models.self_supervised.test_models.test_byol

I cannot fix the CLI script as I do not have a GPU
pl_bolts.tests.models.self_supervised.test_models.test_ssl_scripts.test_cli_run_ssl_byol
Summary

[x] Add method in BYOL to calculate loss for given online and target views
[x] Add initial value of tau as an argument for BYOL
[x] Remove predictor network from SiameseArm since it was not being used for target network and move to BYOL
[x] Modify test_byol to use SimCLR transforms instead of CPC transforms
[x] Fix CLI run test case

Before submitting

[x] Was this discussed/approved via a Github issue? (no need for typos and docs improvements)
[x] Did you read the contributor guideline, Pull Request section?
[x] Did you make sure your PR does only one thing, instead of bundling different changes together?
[x] Did you make sure to update the documentation with your changes?
[x] Did you write any new necessary tests? [not needed for typos/docs]
[x] Did you verify new and existing tests pass locally with your changes?
[ ] If you made a notable change (that affects users), did you update the CHANGELOG?

PR review

[x] Is this pull request ready for review? (if not, please submit in draft mode)

Anyone in the community is free to review the PR once the tests have passed.
If we didn't discuss your PR in Github issues there's a high chance it will not be merged.
Did you have fun?
Make sure you had fun coding 🙃

@otaj I realized that the BYOL module is initialized with data_dir=datadir in test_byol. Should I re-open this PR to fix it or create a new PR?


ELB creation function only handles internet-facing ELBs

create_elb only does internet-facing ELBs.  I want the ability to set Scheme="internal" for an internal ELB.

https://github.com/DualSpark/cloudformation-environmentbase/commit/21dcbac6e192ef4334657c3cf7a989e14c436427


How to locate RTL-SDR v5 on macOS for the docker device ID /dev/?????

Specifications

Image hash or version:  latest
Platform:   macOS Sequoia
Subsystem:  Docker

Expected Behavior
WIth the RTL-SDR v5 plugged in there is no device listed in /dev that I can use to tell dump1090 where the SDR is. It is there and can be found by SDR++ and also when I do a  'system_profiler SPUSBDataType'  :
`    USB 3.0 Bus:
  Host Controller Driver: AppleEmbeddedUSBXHCIFL1100
  PCI Device ID: 0x1100
  PCI Revision ID: 0x0010
  PCI Vendor ID: 0x1b73

    NESDR SMArt v5:

      Product ID: 0x2838
      Vendor ID: 0x0bda  (Realtek Semiconductor Corp.)
      Version: 1.00
      Serial Number: 00000001
      Speed: Up to 480 Mb/s
      Manufacturer: Nooelec
      Location ID: 0x02200000 / 3
      Current Available (mA): 500
      Current Required (mA): 500
      Extra Operating Current (mA): 0`

Actual Behavior
Unable to locate a device so container won't start
Steps to Reproduce the Problem

Create a docker container
Fill in my ID for FlightRadar
Unable to enter a device ID for dump1080 as no device for the SDR listed in /dev

I realise I should have posted this on the dump1090, I will go do that now, but if anyone has any ideas how to fix this that would be great.

Bumping this. I'd love to see a solution and if I figure something out I'll report back.


CronWorkflow not starting - error in entry template execution Pod is invalid [spec.containers[0].image: Required value.

Checklist

[x] Double-checked my configuration.
[x] Tested using the latest version.
[x] Used the Emissary executor.

Summary
What happened/what you expected to happen?
I've tried to run example CronWorkflow from your repository to see how it works before deploying anything more advanced:
https://github.com/argoproj/argo-workflows/blob/master/examples/cron-workflow.yaml
What version are you running?
Argo-Workflows version: v.3.3.1
Kubernetes version: v1.22.7 and v1.20.15
Diagnostics
Paste the smallest workflow that reproduces the bug. We must be able to run the workflow.
apiVersion: argoproj.io/v1alpha1
kind: CronWorkflow
metadata:
  name: hello-world
spec:
  schedule: "* * * * *"
  timezone: "America/Los_Angeles"   # Default to local machine timezone
  startingDeadlineSeconds: 0
  concurrencyPolicy: "Replace"      # Default to "Allow"
  successfulJobsHistoryLimit: 4     # Default 3
  failedJobsHistoryLimit: 4         # Default 1
  suspend: false                    # Set to "true" to suspend scheduling
  workflowSpec:
    entrypoint: whalesay
    templates:
      - name: whalesay
        container:
          image: docker/whalesay:latest
          command: [cowsay]
          args: ["🕓 hello world. Scheduled on: {{workflow.scheduledTime}}"]

# Logs from the workflow controller:
kubectl logs -n argo deploy/workflow-controller | grep ${workflow}
time="2022-03-25T08:31:00.000Z" level=info msg="Running hello-world" namespace=argo workflow=hello-world
time="2022-03-25T08:31:00.013Z" level=info msg="Create workflows 201"
time="2022-03-25T08:31:00.014Z" level=info msg="Processing workflow" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.018Z" level=info msg="Get configmaps 404"
time="2022-03-25T08:31:00.018Z" level=warning msg="Non-transient error: configmaps \"artifact-repositories\" not found"
time="2022-03-25T08:31:00.019Z" level=info msg="resolved artifact repository" artifactRepositoryRef=default-artifact-repository
time="2022-03-25T08:31:00.019Z" level=info msg="Updated phase  -> Running" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.019Z" level=info msg="Pod node hello-world-1648197060 initialized Pending" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.020Z" level=info msg="Patch cronworkflows 200"
time="2022-03-25T08:31:00.021Z" level=info msg="Processing argo/hello-world" cronWorkflow=argo/hello-world
time="2022-03-25T08:31:00.021Z" level=info msg="CronWorkflow argo/hello-world added" cronWorkflow=argo/hello-world
time="2022-03-25T08:31:00.031Z" level=info msg="Create events 201"
time="2022-03-25T08:31:00.031Z" level=info msg="Create pods 422"
time="2022-03-25T08:31:00.031Z" level=warning msg="Non-transient error: Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]"
time="2022-03-25T08:31:00.032Z" level=info msg="Failed to create pod hello-world-1648197060 (hello-world-1648197060): Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=warning msg="Non-transient error: Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]"
time="2022-03-25T08:31:00.032Z" level=error msg="Mark error node" error="Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]" namespace=argo nodeName=hello-world-1648197060 workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=info msg="node hello-world-1648197060 phase Pending -> Error" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=info msg="node hello-world-1648197060 message: Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=info msg="node hello-world-1648197060 finished: 2022-03-25 08:31:00.032455969 +0000 UTC" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=error msg="error in entry template execution" error="Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=warning msg="Non-transient error: Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]"
time="2022-03-25T08:31:00.032Z" level=info msg="Updated phase Running -> Error" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.032Z" level=info msg="Updated message  -> error in entry template execution: Pod \"hello-world-1648197060\" is invalid: [spec.containers[0].image: Required value, spec.initContainers[0].image: Required value]" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.033Z" level=info msg="Marking workflow completed" namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.033Z" level=info msg="Checking daemoned children of " namespace=argo workflow=hello-world-1648197060
time="2022-03-25T08:31:00.036Z" level=info msg="Create events 201"
time="2022-03-25T08:31:00.039Z" level=info msg="cleaning up pod" action=deletePod key=argo/hello-world-1648197060-1340600742-agent/deletePod
time="2022-03-25T08:31:00.044Z" level=info msg="Delete pods 404"
time="2022-03-25T08:31:00.044Z" level=info msg="Update workflows 200"
time="2022-03-25T08:31:00.046Z" level=info msg="Workflow update successful" namespace=argo phase=Error resourceVersion=171698488 workflow=hello-world-1648197060
time="2022-03-25T08:31:00.051Z" level=info msg="DeleteCollection workflowtaskresults 200"

# If the workflow's pods have not been created, you can skip the rest of the diagnostics.

# The workflow's pods that are problematic:
kubectl get pod -o yaml -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

# Logs from in your workflow's wait container, something like:
kubectl logs -c wait -l workflows.argoproj.io/workflow=${workflow},workflow.argoproj.io/phase!=Succeeded

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

It appears that for some reason the executor image is not set in your config. Please try updating your workflow controller configmap or the —executor-image parameter.

That was it, thank you for the help.


proposal: print flags in --help with two dashes

Golang accepts flags with one or two dashes, e.g. my_binary -foo is the same as my_binary --foo.
Long flags traditionally use two dashes (as seen in various GNU tools such as grep), and I think it would be useful to promote this convention by formatting help output in the same way.
I don't want to change the parsing behavior, just the formatting of --help (and possibly other related text). For a related precedent, Abseil made this same change a few years back.

cc @robpike

Now "short" options would have a double dash, which also goes against the those conventions.
  --c string
    	some help text
  --foobar string
    	some help text

And if you want to special case single letter flags without changing parsing behavior, it's even more confusing for users.

Thanks, but the standard library flag package uses a single dash.  It does accept a double dash for convenience.  But we aren't going to change the way that it reports flags.
Other flag packages are available, including ones that act more like the GNU tools.


[4.1] Relationship field & Fetch field and operation Bugs

Copied changes in #2577 since that branch can't be merged as-is.

Merged into relationship-field-bug-fixing, then merged that one into 4.1.


are you planning to expand the configuration?

Encountered a problem when deploying in docker graphql is deployed along the way http://localhost:8080/graphql , and graphiql at home looks at http://localhost:8080/service/myservice/graphql . Specifying dgs.graphql.path does not help, it is simply added to the path. Question is there any plans to add additional management settings, for example, by which graphiql will be viewed?

What's the exact problem you're having with dgs.graphql.path?
As for the general question the only answer I can give is "Probably, when the needs arrises". If there is anything specific that you might need, let us know.

the problem is that when deploying an application in docker, graphql expands along one path, and graphiql tries to find it in another place.Specifying dgs.graphql.path does not help as described above. In Docker, when deploying graphql, it turns out to take into account the path to the service, and in graphiql this path is not taken into account. Super if it would be possible to set separately <DGS_GRAPHQL_PATH> in graphql-dgs-spring-webmvc-auto configure index.html

Closing because AFAIK this is not an issue anymore, also it would have to be changed in Spring GraphQL if it is.


[Bug] Opening links in the same window

Reproducible in vscode.dev or in VS Code Desktop?

[ ] Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

[ ] Not reproducible in the monaco editor playground

Monaco Editor Playground Code
monaco.editor.create(document.getElementById('container'), {
	value: "function example() {\n ref$: 'https://microsoft.github.io/monaco-editor/' \n}",
	language: 'javascript'
});

Reproduction Steps

Open example on Monaco Editor Playground Code
Follow 'https://microsoft.github.io/monaco-editor/' link

Actual (Problematic) Behavior
Our Monaco Editor is a part of SPA. We use relative paths and we don't intend to switch tabs.
Found WA: https://stackoverflow.com/questions/46746798/monaco-editor-follow-link-hook, it works, but we would like you to fix it
Expected Behavior
If link navigate to the same origin -> it will be open in the same window
If link navigate to another origin -> it will be open in the new tab
Additional Context
No response

Another WA is to replace openExternal function. (I'm using)
const editor = monaco.editor.create(document.getElementById('container'), {
	value: "function example() {\n ref$: 'https://microsoft.github.io/monaco-editor/' \n}",
	language: 'javascript'
});
editor.getContribution('editor.linkDetector').openerService._defaultExternalOpener.openExternal = function(url) {
    // need origin check
    window.location.assign(url);
};

Playground uses iframe, so only the right pane's url will be changed.

We also use the Monaco editor inside an SPA and we never ever want the editor to change the page in the same tab when the user clicks a link. Because then you explicitly have to prevent losing unsaved changes (especially in the case of an accidental click). That said, we also have the need to handle some links differently and we hook into the LinkDetector contribution. That has an openerService with a list of "openers". Our util function gives us the ability to handle links first and if we handled them, indicate to Monaco that the default opener does not have to act anymore. Using a Disposable as return value we can also easily unregister a handler again. (CAUTION: unofficial APIs)
So I would rather a) see a setting that lets me choose between the current behavior (new tab) or your proposed behavior, or b) have an official API to hook into this. Just changing the behavior would probably break a lot of users.
// The Monaco Editor can be easily created, given an
// empty container and an options literal.
// Two members of the literal are "value" and "language".
// The editor takes the full size of its container.

const editor = monaco.editor.create(document.getElementById('container'), {
    value: "function hello() {\n\talert('Hello world!'); // https://microsoft.github.io/monaco-editor/playground.html\n}",
    language: 'javascript'
});

/**
 * Registers a handler that is called when a link is opened. The handler callback should return `true` if the link was handled and `false` otherwise.
 * The handler that was registered last will be called first when a link is opened.
 *
 * Returns a disposable that can unregister the opener again.
 *
 * CAUTION: Uses internal unofficial APIs
 *
 * @param {monaco.editor.IStandaloneCodeEditor} editor
 * @param {{open: (resource: monaco.Uri) => bool}} opener
 * @returns {monaco.IDisposable}
 */
function registerLinkOpener(editor, opener) {
    const linkDetector = editor.getContribution("editor.linkDetector");
    /** @type {(() => void) | undefined} */
    let remove = linkDetector?.openerService._openers.unshift({
        async open(resource) {
            if (typeof resource === "string")
                resource = monaco.Uri.parse(resource);
            return opener.open(resource);
        }
    });
    return {
        dispose() {
            remove?.();
            remove = undefined;
        }
    };
}

const opener = registerLinkOpener(editor, {
    open(resource) {
        console.log(resource);
        return true; // handled
    }
});

// opener.dispose(); // to unregister

I've noticed email addresses attempt to open in the same window instead of in a new window, which seems inconsistent. Perhaps with @spahnke 's PR this point will be moot, as we can handle them however we want to make the behaviour consistent.


Two-Fer appears twice on Exercise tab

After completing the Hello World Exercise and going to the "Exercises" tab I could see "Two-Fer" exercise listed three times intially.  After a few minutes it changed to two.  There are a total of 20 exercises, but the "All Exercises" shows 21.
To recreate perform the following:

Log into Exercism
If you have not joined VB.NET track join it
If you have not completed Hello World, complete it.
Select "Tracks" at the top of the screen
Select VB.NET track from list of tracks
While on the "Overview" tab, select "Exercises" tab

Screen shot of initial view of issue.  Since this image, the "locked" exercise has gone away.

There was a change in the two-fer uuid.  The fix was to deprecate the old uuid.


Leaflet cannot determine the correct window sizing information immediately in Ionic Framework

Facing the same issue described in Interacting with a Leaflet Map in an Ionic Framework PWA:

[...] Because Ionic Framework does some things at load time prior to the views being built, Leaflet cannot determine the correct window sizing information immediately. Because of this, some or all tiles may be missing from the view. To correct this, we can set a short timeout and invalidate the map size causing it to refresh.

To workaround this issue, the following was added after the map is instantiated
        setTimeout(() => {
            map.invalidateSize();
        }, 1000);

Fixed by e47336856de7f2e5dd078fb009307cb9c17b9ce6


Scrollview horizontal crushing my app

React Native version:

Steps To Reproduce

Describe what you expected to happen:
Snack, code example, screenshot, or link to a repository:

I was expecting my views to be arranged in horizontal here is my package.json file
{
"main": "node_modules/expo/AppEntry.js",
"scripts": {
"start": "expo start",
"android": "expo start --android",
"ios": "expo start --ios",
"web": "expo start --web",
"eject": "expo eject"
},
"dependencies": {
"expo": "^34.0.1",
"expo-file-system": "~6.0.0",
"expo-image-picker": "~6.0.0",
"expo-permissions": "~6.0.0",
"expo-sharing": "~6.0.0",
"firebase": "^6.3.5",
"react": "16.8.3",
"react-dom": "^16.8.6",
"react-native": "https://github.com/expo/react-native/archive/sdk-34.0.0.tar.gz",
"react-native-dialog": "^5.6.0",
"react-native-gesture-handler": "~1.3.0",
"react-native-paper": "^2.16.0",
"react-native-reanimated": "~1.1.0",
"react-native-uuid-generator": "^6.0.0",
"react-native-web": "^0.11.4",
"react-navigation": "^3.11.1",
"react-navigation-material-bottom-tabs": "^1.0.0",
"uuid": "^3.3.3"
},
"devDependencies": {
"babel-preset-expo": "^6.0.0"
},
"private": true
}

Please provide reproducible demo code.


Update dependencies to support Generics

Hello! First of all, thanks for this project. It is very helpful and makes dependency injection a breeze.
We've experience some problems working with wire and generics (as I think other people has experienced too according to #354)
I dont know for sure if these changes added full support for generics but I've managed to fix all the issues I had in my projects.
Mainly, I had to update the dependencies to use<EMAIL_ADDRESS>The main issue was here:
https://github.com/golang/tools/blob/master/go/ast/astutil/rewrite.go#L255
that was included in this commit
this is a version adapted from the tutorial that works only with the updated version:
// main.go
package main

import (
	"errors"
	"fmt"
	"os"
	"time"
)

// Message is what greeters will use to greet guests.
type Message string

type Resolver[K comparable, V any] struct {
	store map[K]V
}

func NewResolver[K comparable, V any]() Resolver[K, V] {
	return Resolver[K, V]{
		store: map[K]V{},
	}
}

func (o Resolver[K, V]) Resolve(key K) (V, error) {
	val, exists := o.store[key]
	if !exists {
		return val, errors.New("not found")
	}

	return val, nil
}

func (o Resolver[K, V]) Add(key K, val V) {
	o.store[key] = val
}

// NewMessage creates a default Message.
func NewMessage(phrase string) Message {
	return Message(phrase)
}

// NewGreeter initializes a Greeter. If the current epoch time is an even
// number, NewGreeter will create a grumpy Greeter.
func NewGreeter(m Resolver[bool, Message]) Greeter {
	var grumpy bool
	if time.Now().Unix()%2 == 0 {
		grumpy = true
	}
	return Greeter{MessageResolver: m, Grumpy: grumpy}
}

// Greeter is the type charged with greeting guests.
type Greeter struct {
	Grumpy          bool
	MessageResolver Resolver[bool, Message]
}

// Greet produces a greeting for guests.
func (g Greeter) Greet() Message {
	m, err := g.MessageResolver.Resolve(g.Grumpy)
	if err != nil {
		return Message("not found")
	}
	return m
}

// NewEvent creates an event with the specified greeter.
func NewEvent(g Greeter) (Event, error) {
	if g.Grumpy {
		return Event{}, errors.New("could not create event: event greeter is grumpy")
	}
	return Event{Greeter: g}, nil
}

// Event is a gathering with greeters.
type Event struct {
	Greeter Greeter
}

// Start ensures the event starts with greeting all guests.
func (e Event) Start() {
	msg := e.Greeter.Greet()
	fmt.Println(msg)
}

func main() {
	e, err := InitializeEvent("hi there!")
	if err != nil {
		fmt.Printf("failed to create event: %s\n", err)
		os.Exit(2)
	}
	e.Start()
}

// wire.go
package main

import "github.com/google/wire"

func getMessageResolver() Resolver[bool, Message] {
	r := NewResolver[bool, Message]()
	r.Add(false, Message("happy false"))
	r.Add(true, Message("grumpy true"))
	return r
}

// InitializeEvent creates an Event. It will error if the Event is staffed with
// a grumpy greeter.
func InitializeEvent(phrase string) (Event, error) {
	wire.Build(NewEvent, NewGreeter, getMessageResolver)
	return Event{}, nil
}

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
For more information, open the CLA check for this pull request.

signed  ⚡ ✍

Great @jayzhuang . should we merge this PR or wait until the whole functionality is there? (I'm now working with my forked repo and would love to come back to using the original go install github.com/google/wire instead of git clone + go install .)

Hey Enrique, I'm supportive of merging this PR, but I don't have write access. @stytchiz can you take a look?

One vote for this PR, 👍 .

Hey Enrique, I'm supportive of merging this PR, but I don't have write access. @stytchiz can you take a look?

Understood, thanks for the support @jayzhuang

From the description ...

I dont know for sure if these changes added full support for generics but I've managed to fix all the issues I had in my projects.

Can you provide more details on what use case this PR is solving (as well as not solving)? I can take a deeper look during the weekend. My major concern is that this PR will down the line require supporting generics as a new feature which we don't have the bandwidth for at the moment.

Thanks for your comment @stytchiz. I understand the concern about bandwidth and it totally makes sense.
Regarding

I dont know for sure if these changes added full support for generics but I've managed to fix all the issues I had in my projects.

This was mostly a disclaimer or cautionary comment, since I didnt try all possible options involving generics.
In the first comment I provided an example where (google:main) wire . was failing but succeeded to wire the code with the changes from this PR.
To my understanding, this change doesnt include complete support for generics (like @jayzhuang commented): you cannot do wire.Build(NewEvent, NewGreeter, getMessageResolver[bool, Message]), it basically includes the changes needed to parse and understand ast.IndexList which is what is used in generics. So wire can tolerate code that includes generics, this gives us a way to work with generics without further changing wire.
The code from #354  still doesnt work with this change, however they would have a workaround. They just have to remove the generics from wire.Build and move it to an internal function:
Example from #354 that works changing their wire.go to this:
//go:build wireinject

package main

import "github.com/google/wire"

func getV() int {
	return NewV[int]()
}

func InitializeEvent() Event {
	wire.Build(NewEvent, NewGreeter, NewMessage, getV)
	return Event{}
}

Previous wire.go
//go:build wireinject

package main

// The build tag makes sure the stub is not built in the final build.

import "github.com/google/wire"

func InitializeEvent() Event {
	wire.Build(NewEvent, NewGreeter, NewMessage, NewV)
	return Event{}
}

Let me know if you need anything else and thanks for your support

Hello @stytchiz, I understand that you are very busy but I wanted to check if you had a chance to review the comment or if you need further information.
Best,
Enrique

Sorry for the delay @efueyo ! Your response was very helpful.
LGTM. The changes adds a new switch case for ast.IndexListExpr which should be invoked only for generics per https://go.googlesource.com/proposal/+/master/design/47781-parameterized-go-ast.md#for-type-and-function-instantiation.
I'll also update #354 that this is a workaround and that full support for generics is not on the table.

Thanks for your support and c

Sorry for the delay @efueyo ! Your response was very helpful.
LGTM. The changes adds a new switch case for ast.IndexListExpr which should be invoked only for generics per https://go.googlesource.com/proposal/+/master/design/47781-parameterized-go-ast.md#for-type-and-function-instantiation.
I'll also update #354 that this is a workaround and that full support for generics is not on the table.

No need to apologize, I understand we all might be very busy. Thanks for finding the time to carefully look at this, though!


Fix mismatched go versions (and AS casing)

What was changed

Updated the image for building from golang:1.22-bookworm to golang:1.23-bookworm in the Dockerfile
Changed casing on AS statement to match the rest of the Dockerfile

Why?

Dockerfile was using golang:1.22-bookworm as the builder image, but go.mod requires >= 1.23, and so the docker image build fails.
The case of the AS keyword was causing a (non fatal) build error in Docker

Checklist

Closes n/a

How was this tested:
docker build . the original version, observe the errors...

 => ERROR [builder 4/4] RUN go build ./cmd/temporal                                                                                0.2s
------
 > [builder 4/4] RUN go build ./cmd/temporal:
0.146 go: go.mod requires go >= 1.23 (running go 1.22.8; GOTOOLCHAIN=local)
------

 1 warning found (use docker --debug to expand):
 - FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 1)
Dockerfile:9
--------------------

docker build . this version and observe that these errors are not present

Any docs updates needed?

no.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


keymap fixes

This creates an error: Pressing Esc return to Home when playing.
I'll fix it soon(probably tomorrow).

As far as I could understand the Pages enum, the Help variant was completely unnecessary and just made life harder. Therefore I removed it and utilized the app.show_help_popup. I also removed 'x' keybinding and replaced it's functionality with Esc. Let me know if there's anything that you think could further be changed.

Sorry bro dunno how this works

I've found a bug in my code which is kind of hard to resolve, as the currently it depends on move_history, which does not contain starting positions of course and therefore when a piece is kicked from it's original position, it won't be placed back by takeback(). Any ideas about resolving this?

I have no idea how to deal with promotions. Do you?

I haven't tested many scenarios, but one thing that still doesn't work is promotions. I'll try to implement them though.

Nice job already hope you will be able to get over the promotion !

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

might be a pain in the ass but can be worth it in the end so what does x and y represent x being the rows and y the lines of the board ?

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

might be a pain in the ass but can be worth it in the end so what does x and y represent x being the rows and y the lines of the board ?

just the other way round: y: rows, x: lines

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

might be a pain in the ass but can be worth it in the end so what does x and y represent x being the rows and y the lines of the board ?

just the other way round: y: rows, x: lines

ok i see maybe we could directly put
struct Coordinate {
line: i8,
row: i8,
}
for it to be very clear ?

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

might be a pain in the ass but can be worth it in the end so what does x and y represent x being the rows and y the lines of the board ?

just the other way round: y: rows, x: lines

ok i see maybe we could directly put
struct Coordinate { line: i8, row: i8, }
for it to be very clear ?

only: col (column) instead of line, is that good?

Now that I know the code somewhat better, I got fed up with the way coordinates are stored, so this is what I came up with: instead of [i8; 2] or Vec<i8>, which is not that much to the point to tell the truth, I made something like this:
struct Coordinate {
    x: i8,
    y: i8,
}

I also started rewriting every occurence to comply with this new Coordinate design. It is quite a pain in the neck, but overall I'd say it's worth the time.
What do you think about it?

might be a pain in the ass but can be worth it in the end so what does x and y represent x being the rows and y the lines of the board ?

just the other way round: y: rows, x: lines

ok i see maybe we could directly put
struct Coordinate { line: i8, row: i8, }
for it to be very clear ?

only: col (column) instead of line, is that good?

sounds good to me !

Fixes #55, #56, hopefully will once fix #52.

As I'm working on dealing with edge cases for takeback:

castle
en-passant
promotion

I explored some weird things: I wrote some tests, made Coords check(panic) if a coordinate is not between 0 and 7. Well that happens quite often, not only when UNDEFINED_POSITION is used. Why is that? I can't work it out really, if I'm right, only between (0;0) and (7;7) coordinates are correct to index board which I made a type alias now(also Piece).

One more thing: board::tests::takeback_kick is a test I wrote to check whether takeback works in case of a place has been kicked, needs to be placed back on the board. Well as far as you can tell (from actually playing with the game) it works. But the test fails for some reason I can't work out. Could you check please? it'd be a huge help.

One more thing: board::tests::takeback_kick is a test I wrote to check whether takeback works in case of a piece has been kicked, needs to be placed back on the board. Well as far as you can tell (from actually playing with the game) it works. But the test fails for some reason I can't find. Could you check please? it'd be a huge help.

Hi, thanks for the feedback I will check both your test and the panick you mentioned above in the week (lot of work in parallel :disappointed: I don't have a lot of time) !

One more thing: board::tests::takeback_kick is a test I wrote to check whether takeback works in case of a piece has been kicked, needs to be placed back on the board. Well as far as you can tell (from actually playing with the game) it works. But the test fails for some reason I can't find. Could you check please? it'd be a huge help.

Hi, thanks for the feedback I will check both your test and the panick you mentioned above in the week (lot of work in parallel 😞 I don't have a lot of time) !

I'm sorry to hear. It can wait anyway.

How is it going Jerome I see that you made a lot of commits which is great ! feel free to put the pr in a ready tstae when you need be to review it

Hey @JeromeSchmied,
I was looking at the source and was going to submit some ideas I had to improve this, but this PR seems to be a large rewrite of a significant portion of the app. It has many different changes rolled up into a single PR. Monolithic changes like this are problematic as it makes it difficult to work in any areas of the app without conflict, and they're more difficult to review as the time investment to do so scales exponentially (or at least more than linearly) with the size of the changes.
@thomas-mauran / @JeromeSchmied what's your preferred way forward here? I see a couple of options:

Get this to a state where it can be reviewed and merge it soon?
Split this up into smaller mergable chunks. I think there's some really good ideas in here that could be easily broken up into smaller PRs if you wanted to.
Submit PRs that ignore what's going on with this PR and expect this PR to merge those changes instead.

Regarding coordinates: currently these are Row/Col but the chess terms are Rank/File, why not make these explicit enums and implement ops::Index against the board https://doc.rust-lang.org/std/ops/trait.Index.html

@joshka thanks for this comment, I couldn't agree with you more. The only reason for putting this huge amount of commits in one PR is because I have no idea how to create more than one PRs at once, but I spotted out some crucial issues in the code while working on the takeback.
issues? I fixed:

Using Coords has a huge impact on development speed I think.
Handling key release events just like you did it in #59 which is in fact prettier code than the one I wrote.
Usage of methods instead of functions taking potential self as argument.
Popup window handling.

issues I've been working on, but are not yet done:

takeback
pgn import
fen import

To resolve the conflict, in my opinion it'd be best if I reverted my commits about

takeback(which can be written a lot more easily once pgn import is done I guess)
pgn import
fen import
and also keyrelease fix
and then make PRs for each remaining, also implement std::ops::Index for Board.

I'll see what I can do.

I'm sorry, it looks like I can't actually revert any commits other than KeyRelease fix from the issues I just mentioned, as my git history is such a huge mess.
To fix this, may we merge this PR as is, if I just comment out code using functions I wrote for pgn import (takeback is already commented out), so that the extra code I wrote will remain there, and soon I'll try to implement then one by one.
Is this ok?
Sorry for any inconveniences I made.

Hey, no problem on the inconvenience. If @thomas-mauran is ok with your direction, then that's his call as he code owner, not mine. I have a preference for small orthogonal chunks of work over large ones, but not everyone shares that approach.
It sounds like you're using git as a single branch in your local repository, and so you're thinking about the history is one dimensional. What I'd generally try to do in this sort of thing is a branch for each feature, trying to make each branch have little overlaps in the code that they're touching, and having a clear goal / finished state. Thing two dimensional in terms of non-overlapping areas.
At a high level splitting up the PR looks something like:
0. You're currently using a local branch named main, this can make things a little confusing as your main and the main here are two different things. Run git branch all-the-things' to create a new branch at the current point in your local to come back to if you need to, then run git reset --hard upstream/mainto reset your main branch to be the same as the repo main. (your remote name might be different than upstream, rungit remote -v` to check).

Create and switch to a new branch for the first feature you want to merge (e.g. git switch -c coords)
Cherry pick commits that have the code that you want to be part of that branch (e.g. git cherry-pick fc42fc5) to bring in fc42fc53fadf1fd5e00ffc08dc6f839036f70ca0 and then pick up more commits to make up the PR
Resolve any conflicts (there will probably be some places where you update code in unrelated parts to use the new code)
Make sure tests etc. compile
Create a PR from that new branch - hopefully being smaller will make it easier to review and merge quickly
switch to the all-the-things branch
rebase the all-the-things branch onto the coords branch (you can also create a new branch to do this on if you want the placeholder branch in place to come back to at some later date to compare). You'll notice that any of the cherry picked commits will be removed as they have already been applied to the source, though you might have to resolve some conflicts.

Repeat for each small chunk of work.
Another approach is to just throwaway your changes (but use them as a reference point for doing them again right upfront). I do this fairly often myself (implement something incrementally and then redo it correctly).
The last approach is just to get this to a point where it's bug free and mergable as-is. I think this might be difficult.

Yep, as @joshka said the best thing would be to split your pr in multiple ones, thanks a lot @joshka for providing details on how to do that easily for @JeromeSchmied I think this will be very hepful. @JeromeSchmied tell me if you are having any issue splitting the pr

I started extracting my commits to different PR-s.
I think I shall close this one, as I'll make new ones anyway, right?

I started extracting my commits to different PR-s. I think I shall close this one, as I'll make new ones anyway, right?

Sounds good!


Self hosting

Can we host this project if yes then make a .env-example file so we can add

Hey 👋
Yep, you can. Following your request, I've added a .env.example file (#8 ) containing all the necessary variables needed to start the bot.
Happy coding!


Server translates error object thrown from method into SOAP Fault

A service method can send back a SOAP Fault response to a client by throwing an object that contains a Fault property.
Note that the generated XML uses the "soap" NS that is defined by the _envelop method.
It isn't the best option but I don't know how to do better. I gave a quick look at wsdl.js but ran away ;-)

Thanks a lot for your contributions @mdhooge - we appreciate it a lot :+1:
Before we can merge this, I'll have to ask you to squash your commits into a single one, like it's described in our Guidelines for Submitting a Pull Request (this is also necessary for your follow up PR at #558)

Hi,
I'm not very good at pushing changes for PRs! I removed a branch, so PR558 is closed. :-(
However I created branches PR557 & PR558; with PR557 == PR558~1 and PR558 == master.
And, good news, both commits still pass the tests.
There is one test ("should not append :80 to the Host header...") that doesn't pass, but it was already the case before my changes.
Cheers

Oh, that's a pitty @mdhooge, sorry for this inconvenience, but I have to insist on the "one Commit per Pull Request" rule here at node-soap. See the excellent GitHub Help on Git Rebase and GithHub Help on Using Git Rebase for further information. Thanks.

OK, so it was simpler to create a new PR.
And because #558 needs that one to be applied, I'll wait for you to merge it first.
Cheers


updating the notebook after running it at DLMBL2024

This PR udpates the DLMBL2024 notebook for demo-ing Virtual Staining with VisCy.
After many inputs and debugging from  Diane, Anna, and Albert.
Co-authored-by: Diane Adjavon<EMAIL_ADDRESS>Co-authored-by: AlbertDominguez<EMAIL_ADDRESS>Co-authored-by: Anna Foix<EMAIL_ADDRESS>

@edyoshikun Let's add the solution.ipynb with images embedded.

the last commit addresses #152


Internal compiler error when all match branches return Never

This code fails with Internal compiler error: Program erroneously uses uninitialized virtual registers: $r2.
script;

struct S {  x: u8, }

fn revert_me() -> Never {
  __revert(0)
}

fn main() -> bool {
  let s =  S { x: 0 };

  match Option::Some::<S>(s) {
    Some(_) => revert_me(),
    None => revert_me(),
  }

  true
}

As expected, the changes done in #5602 and #5643 have indirectly fixed this issue as well. It cannot be reproduced on master anymore so I am closing it.
Of course, since we've replaced Never with ! in the attempt to reproduce the issue the revert_me function returns !.


⚠ Samsung has degraded performance

In 6f69f89, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2292 ms

Resolved: Samsung performance has improved in 22d4e2c.


[WIP] Conversation API

SpongeAPI | SpongeCommon | SpongeVanilla | SpongeForge
Note: This write-up is outdated at the moment. I am getting much closer and will update this soon once I get a more stable API and properly working implementation to show it off. We're getting there my friends :)
So this is something I have been dabbling around with and it is still work in progress, but I would love to get some feedback from you while I continue this process. As a whole, I have looked at other similar APIs from the past and other proposals such as @pie-flavor's Dialogue API which I especially found a lot of initial inspiration from as it seemed to match with many of Sponge's conventions and be fairly easy to use.
So far I have tested this on SpongeVanilla and it works relatively well so far, outside of a few issues, meeting all of my initial goals and more.
A Conversation is simply a form of back and forth between two or more people. With this API, it allows plugin developers to create one of their own, with any amount of Conversants if they so desire. A common use case is to collect information over a plethora of questions, to create something such as a new world. This can replace a long command with a lot of different arguments and flags. Each argument with a conversation would simply be a new Question.
A Conversation is an active conversation or one that has recently ended and is still being manipulated. A ConversationArchetype is what these are started from and can easily be built by calling ConversationArchetype.builder() with many of the values having a default.
As plugins handle answers to questions, they can either store the data they collect themselves or store it with data queries within the DataContainer present in the Conversation, by using Conversation#getContext.
One goal of this PR is to allow the use of GenericArguments and CommandElements as a whole, as that system is already pretty great and extensive, instead of having a separate idea of different kinds of Prompts. This will also allow me to add support for tab completion easily soon and makes the whole idea of conversations similar to what developers are already used to with commands.
Much of it branches off there and the Javadocs should do it justice until I have some more time to add to this PR description, but if you have questions feel free to ask.
New Goals -

[ ] Allow other types of Conversants, maybe such as ConsoleSource and RconSource.

[x] Possibly keep weak references to Conversants, so if they die or their object is recreated the conversation can remove them. Looking for input on a good solution here.

[x] Utilize the ability of the CommandElement of the current question to allow for tab completion.

Here is a small example I threw together quickly:
final Question two = Question.builder()
            .id("seed")
            .argument(GenericArguments.longNum(Text.of("seed")))
            .prompt(Text.of("Enter desired seed:"))
            .handler((convo, conversant, quest, context) -> {
                Optional<Long> optionalLong = context.getOne("seed");

                if (optionalLong.isPresent()) {
                    convo.getContext().set(DataQuery.of("seed"), optionalLong.get());
                    return QuestionResult.end();
                } else {
                    return QuestionResult.repeat();
                }
            }).build();

        final Question question = Question.builder()
            .id("name")
            .argument(GenericArguments.string(Text.of("name")))
            .prompt(Text.of("Type in the desired world name:"))
            .handler((convo, conversant, quest, context) -> {
                Optional<String> optionalName = context.getOne("name");

                if (optionalName.isPresent()) {
                    convo.getContext().set(DataQuery.of("name"), optionalName.get());
                    return QuestionResult.nextQuestion(two);
                } else {
                    return QuestionResult.repeat();
                }
            }).build();

        ConversationArchetype.builder()
            .id("world-builder")
            .title(Text.of(TextColors.GREEN, "World Creation"))
            .padding(Text.of("-"))
            .startingMessage(Text.of("You will be creating a world within this conversation."))
            .allowCommands(false)
            .catchesOutput(true)
            .exitString("cancel")
            .defaultChatHandler(ExternalChatHandlers.sendOnFinish())
            .firstQuestion(question)
            .endingHandler(((conversation, dataContainer, conversationEndType) -> {
                if (conversationEndType.equals(ConversationEndTypes.FINISHED)) {
                    final String name = dataContainer.getString(DataQuery.of("name")).get();
                    final long seed = dataContainer.getLong(DataQuery.of("seed")).get();

                    conversation.getConversants().forEach(c -> c.sendThroughMessage(Text.of(
                        "Your world will be called: " + name + " and have the seed: " + seed)));

                    // In reality you could ask for all of the arguments for this
                    WorldArchetype.builder()
                        .seed(seed)
                        .build(name.toLowerCase(), name);
                }

                conversation.getConversants().forEach(c -> c.sendThroughMessage(Text.of("Thanks for playing!")));
            })).build().start(this.pluginContainer, player);

Love it. Thanks for finishing this idea; I couldn't finish Dialogue because I had no idea how I was going to implement it and a lot of stuff came up IRL. Hope to see this in the API!

@Meronat Can you move the package under extra?

This would fit under the text package.

For starting a conversation, I accept a PluginContainer, should I accept a plugin object instead?

For starting a conversation, I accept a PluginContainer, should I accept a plugin object instead?

That is what we usually do

So I completely messed up this PR somehow when rebasing and it includes commits I rebased on as well as duplicated my commits. How can I fix this :L

I'll be getting back to this soon, probably this weekend. Will be makes changes according to feedback received and hopefully extending this to ConsoleSources as well.

So I went ahead and added a CancellingHandler which can be specified to handle input to see if a Conversant should quit the conversation. This replaces the exit keyword.
I also have moved to allow for contextual prompts through a PromptHandler.
Next step is moving ExternalChatHandler to some sort of CatalogType/Factory solution.
Then finally is supporting consoles as a Conversant.
Will see you all soon with an updated example and some documentation.

Also i suggest adding a new ECHT that uses a scheduler to send the messages after completion.
Ex One message per second otherwise the user might get spammed with the messages and is unable to read/see them.

@ST-DDT That sounds like a great idea actually. I'm going to refactor ECHs with the other suggested changes tomorrow so I'll add that to my list. Thanks for the consistent feedback.

So at the moment, due to there being the handlers to catch chat, I have to add a sendThroughMessage method to conversants for our messaging uses and plugin creators to use if they want to send something extra during their answer handlers. I'm not super happy with this solution if anyone has any input in this area.

I've still got some cleaning up to do related to the closing event, messages, and the console as a conversant. Getting closer though :)

I plan to get back to this soon. At the moment I've got some cleaning up to do as well as figuring out messaging better, and of course full console functionality.

@Meronat any update on this PR?

@bloodmc I was going to wait until dual's command PR was finished since conversations rely on that backbone for quite a lot(being quite similar to commands), and will experience API changes due to changes in his.
If that is okay, I could work on getting this updated and finished, with the expectation of breakages in bleeding once his PRs are merged as well as the cause and context refactor.

By and large I think this is pretty cool. One idea that came to mind while looking it over was to incorporate additional ways to receive the answer to a question besides direct typing.  One of the biggest benefits in my mind of having a conversation API is to spare the user from having to type out long and complicated commands, however it also has the potential to remove the need to type entirely.  One use case that comes to mind is that the question presents the user choices in the form of clickable links in chat, the user only has to click a choice to provide an answer to a question.  This could streamline the conversation process even more.  Consideration would have to be made for Conversants without a mouse to click though, like the console for example.  The same effect could also be achieved by simply asking the user to type a choice out, though it introduces more potential for input errors. Just food for thought.

We discussed this after SoS, but to confirm, I’ll co-ordinate with @Meronat to ensure that the command API is structured in a way that exposes what Conversations need easily.

Thanks for the continuing feedback, keep it coming. I plan to rebase on-top of dual's command PR once I return from a trip and address feedback then as well :)

@Meronat Please have a look at #1587 - particularly the last comment and about the Parameters part. Also have a look at the CommandContext and how the implementation works with arguments. Does this seem reasonable in the context of the conversations?
Note that any implementation between commands and conversations DO NOT have to be shared once commands are merged, if there needs to be impl differences, that's not unreasonable and we will be able to handle that now. Thus, I'm more interested about whether the API is suitable, rather than impl.
We can discuss this in a more informal setting when you and I get a bit more time, but for now, it's worth starting to make sure that things should work fairly simply from merge.

Closing this given the age that has passed and the lack of activity. If someone wants to continue the work done here then we can re-open at a later time.


I got some compiles problem!

When I compile the iFreeRDP.xcodeproj,I got about 156 errors.
What's the problem with it?
There are the problems:
Ld iFreeRDP.build/Debug-iphoneos/iFreeRDP.build/Objects-normal/armv7s/iFreeRDP normal armv7s
cd /Users/Programer/Desktop/FreeRDP-master/client/iOS
export IPHONEOS_DEPLOYMENT_TARGET=4.3
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk -L/Users/Programer/Desktop/FreeRDP-master/client/iOS/Debug-iphoneos -F/Users/Programer/Desktop/FreeRDP-master/client/iOS/Debug-iphoneos -filelist /Users/Programer/Desktop/FreeRDP-master/client/iOS/iFreeRDP.build/Debug-iphoneos/iFreeRDP.build/Objects-normal/armv7s/iFreeRDP.LinkFileList -dead_strip -Wl,-headerpad_max_install_names -framework Foundation -framework CoreGraphics -framework Security -framework UIKit -framework SystemConfiguration /Users/Programer/Desktop/FreeRDP-master/client/common/Debug-iphoneos/libfreerdp-client.a /Users/Programer/Desktop/FreeRDP-master/winpr/libwinpr/Debug-iphoneos/libwinpr.a /Users/Programer/Desktop/FreeRDP-master/libfreerdp/Debug-iphoneos/libfreerdp.a /Users/Programer/Desktop/FreeRDP-master/channels/audin/client/Debug-iphoneos/libaudin-client.a /Users/Programer/Desktop/FreeRDP-master/channels/disp/client/Debug-iphoneos/libdisp-client.a /Users/Programer/Desktop/FreeRDP-master/channels/echo/client/Debug-iphoneos/libecho-client.a /Users/Programer/Desktop/FreeRDP-master/channels/rdpei/client/Debug-iphoneos/librdpei-client.a /Users/Programer/Desktop/FreeRDP-master/channels/rdpgfx/client/Debug-iphoneos/librdpgfx-client.a /Users/Programer/Desktop/FreeRDP-master/channels/tsmf/client/Debug-iphoneos/libtsmf-client.a /Users/Programer/Desktop/FreeRDP-master/channels/cliprdr/client/Debug-iphoneos/libcliprdr-client.a /Users/Programer/Desktop/FreeRDP-master/channels/drdynvc/client/Debug-iphoneos/libdrdynvc-client.a /Users/Programer/Desktop/FreeRDP-master/channels/encomsp/client/Debug-iphoneos/libencomsp-client.a /Users/Programer/Desktop/FreeRDP-master/channels/rail/client/Debug-iphoneos/librail-client.a /Users/Programer/Desktop/FreeRDP-master/channels/rdpdr/client/Debug-iphoneos/librdpdr-client.a /Users/Programer/Desktop/FreeRDP-master/channels/rdpsnd/client/Debug-iphoneos/librdpsnd-client.a /Users/Programer/Desktop/FreeRDP-master/channels/remdesk/client/Debug-iphoneos/libremdesk-client.a /Users/Programer/Desktop/FreeRDP-master/channels/drive/client/Debug-iphoneos/libdrive-client.a /Users/Programer/Desktop/FreeRDP-master/channels/parallel/client/Debug-iphoneos/libparallel-client.a /Users/Programer/Desktop/FreeRDP-master/channels/serial/client/Debug-iphoneos/libserial-client.a /Users/Programer/Desktop/FreeRDP-master/channels/smartcard/client/Debug-iphoneos/libsmartcard-client.a /Users/Programer/Desktop/FreeRDP-master/libfreerdp/Debug-iphoneos/libfreerdp.a /Users/Programer/Desktop/FreeRDP-master/winpr/libwinpr/Debug-iphoneos/libwinpr.a -lm /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libssl.a /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libcrypto.a /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.2.sdk/usr/lib/libz.dylib -fobjc-link-runtime -miphoneos-version-min=4.3 -Xlinker -dependency_info -Xlinker /Users/Programer/Desktop/FreeRDP-master/client/iOS/iFreeRDP.build/Debug-iphoneos/iFreeRDP.build/Objects-normal/armv7s/iFreeRDP_dependency_info.dat -o /Users/Programer/Desktop/FreeRDP-master/client/iOS/iFreeRDP.build/Debug-iphoneos/iFreeRDP.build/Objects-normal/armv7s/iFreeRDP
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/client/common/Debug-iphoneos/libfreerdp-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/client/common/Debug-iphoneos/libfreerdp-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/winpr/libwinpr/Debug-iphoneos/libwinpr.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/winpr/libwinpr/Debug-iphoneos/libwinpr.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/audin/client/Debug-iphoneos/libaudin-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/audin/client/Debug-iphoneos/libaudin-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/disp/client/Debug-iphoneos/libdisp-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/disp/client/Debug-iphoneos/libdisp-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/echo/client/Debug-iphoneos/libecho-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/echo/client/Debug-iphoneos/libecho-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/rdpei/client/Debug-iphoneos/librdpei-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/rdpei/client/Debug-iphoneos/librdpei-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/rdpgfx/client/Debug-iphoneos/librdpgfx-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/rdpgfx/client/Debug-iphoneos/librdpgfx-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/tsmf/client/Debug-iphoneos/libtsmf-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/tsmf/client/Debug-iphoneos/libtsmf-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/cliprdr/client/Debug-iphoneos/libcliprdr-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/cliprdr/client/Debug-iphoneos/libcliprdr-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/drdynvc/client/Debug-iphoneos/libdrdynvc-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/drdynvc/client/Debug-iphoneos/libdrdynvc-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/encomsp/client/Debug-iphoneos/libencomsp-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/encomsp/client/Debug-iphoneos/libencomsp-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/rail/client/Debug-iphoneos/librail-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/rail/client/Debug-iphoneos/librail-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/rdpdr/client/Debug-iphoneos/librdpdr-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/rdpdr/client/Debug-iphoneos/librdpdr-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/rdpsnd/client/Debug-iphoneos/librdpsnd-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/rdpsnd/client/Debug-iphoneos/librdpsnd-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/remdesk/client/Debug-iphoneos/libremdesk-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/remdesk/client/Debug-iphoneos/libremdesk-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/drive/client/Debug-iphoneos/libdrive-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/drive/client/Debug-iphoneos/libdrive-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/libfreerdp/Debug-iphoneos/libfreerdp.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/libfreerdp/Debug-iphoneos/libfreerdp.ald: warning:
ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/parallel/client/Debug-iphoneos/libparallel-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/parallel/client/Debug-iphoneos/libparallel-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/serial/client/Debug-iphoneos/libserial-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/serial/client/Debug-iphoneos/libserial-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/channels/smartcard/client/Debug-iphoneos/libsmartcard-client.a, file was built for archive which is not the architecture being linked (armv7s): /Users/Programer/Desktop/FreeRDP-master/channels/smartcard/client/Debug-iphoneos/libsmartcard-client.a
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libssl.a, missing required architecture armv7s in file /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libssl.a (1 slices)
ld: warning: ignoring file /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libcrypto.a, missing required architecture armv7s in file /Users/Programer/Desktop/FreeRDP-master/external/openssl/lib/libcrypto.a (1 slices)
Undefined symbols for architecture armv7s:
"_freerdp_context_free", referenced from:
_ios_freerdp_free in ios_freerdp.o
"_freerdp_free", referenced from:
_ios_freerdp_free in ios_freerdp.o
(maybe you meant: _ios_freerdp_free)
"_cache_new", referenced from:
_ios_post_connect in ios_freerdp.o
"_freerdp_channels_post_connect", referenced from:
_ios_post_connect in ios_freerdp.o
"_freerdp_client_load_addins", referenced from:
_ios_pre_connect in ios_freerdp.o
"_freerdp_channels_pre_connect", referenced from:
_ios_pre_connect in ios_freerdp.o
"_freerdp_channels_close", referenced from:
_ios_context_free in ios_freerdp.o
"_freerdp_get_fds", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_disconnect", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_cache_free", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_channels_new", referenced from:
_ios_context_new in ios_freerdp.o
"_PKCS5_PBKDF2_HMAC_SHA1", referenced from:
-[Encryptor initWithPassword:] in Encryptor.o
"_freerdp_channels_load_static_addin_entry", referenced from:
_ios_init_freerdp in ios_freerdp.o
"_freerdp_channels_get_fds", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_context_new", referenced from:
_ios_freerdp_new in ios_freerdp.o
"_freerdp_check_fds", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_channels_check_fds", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_new", referenced from:
_ios_freerdp_new in ios_freerdp.o
(maybe you meant: _ios_freerdp_new)
"_freerdp_channels_free", referenced from:
_ios_context_free in ios_freerdp.o
"_BIO_push", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_BIO_s_mem", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_gdi_free", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_BIO_f_base64", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_BIO_write", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_GetVirtualScanCodeFromVirtualKeyCode", referenced from:
-[RDPKeyboard(Private) sendVirtualKey:up:] in RDPKeyboard.o
"_BIO_new", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_freerdp_connect", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_freerdp_register_addin_provider", referenced from:
_ios_init_freerdp in ios_freerdp.o
"_freerdp_channels_disconnect", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_BIO_set_flags", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_BIO_ctrl", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
"_freerdp_shall_disconnect", referenced from:
_ios_run_freerdp in ios_freerdp.o
"_gdi_init", referenced from:
_ios_allocate_display_buffer in ios_freerdp_ui.o
"_BIO_free_all", referenced from:
-[NSData(TSXAdditions) base64EncodedString] in TSXAdditions.o
ld: symbol(s) not found for architecture armv7s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I use README.ios compilation, I do not understand why I compiled unsuccessful, how did you do that. If it is not a bug, please help me see where I have a problem.
But it looks like the updated version of the result of a bug.
I is the Macbook, OS X 10.10.2, Xcode 6.2, sdk 8.2.

This is really strange, I think it should be the individual machine environmental issues, but this bothers me a long time, have any good suggestions?

Finaly，I've solve this problem.I just retry this command :./scripts/OpenSSL-DownloadAndBuild.command.But I've change the USER_OS_SDK=""
USER_SIM_SDK="" to USER_OS_SDK="iPhoneOS8.2.sdk"
USER_SIM_SDK=“iPhoneSimulator8.2.sdk".
And then cmake.It's worked well.


[Bug]: map doesn't load iOS v10 SDK

Mapbox Implementation
Mapbox
Mapbox Version
10.7.0
Platform
iOS
@rnmapbox/maps version
10.0.0-beta.11
Standalone component to reproduce
import React from 'react';
import {
  MapView,
  ShapeSource,
  LineLayer,
  Camera,
} from '@rnmapbox/maps';

const aLine = {
  type: 'LineString',
  coordinates: [
    [-74.00597, 40.71427],
    [-74.00697, 40.71527],
  ],
};

class BugReportExample extends React.Component {
  render() {
    return (
      <MapView style={{flex: 1}}>
        <Camera centerCoordinate={[-74.00597, 40.71427]} zoomLevel={14} />
        <ShapeSource id="idStreetLayer" shape={aLine}>
          <LineLayer id="idStreetLayer" />
        </ShapeSource>
      </MapView>
    );
  }
}

Observed behavior and steps to reproduce
When app starts loading map, it crashed with following

Expected behavior
Running without error
Notes / preliminary analysis
No response
Additional links and references
Packaer debuger: error<EMAIL_ADDRESS><EMAIL_ADDRESS>Unknown node type: "TSInstantiationExpression"

pls attach npx react-native info

happens to me as well

See https://github.com/rnmapbox/maps/issues/2423#issuecomment-1328003731


[release-0.53]: make generate to switch copyright to 2023

What this PR does / why we need it:
Execute make generate to switch copyright to 2023
Release note:

NONE

/cc @enp0s3 @Barakmor1 @EdDev

/retest-required

/retest

/retest-required

/test pull-kubevirt-e2e-k8s-1.23-sig-compute-nonroot-0.53


feat: convert OR detailed router drc file to klayout xml

Steps

OpenROADStep.DetailedRouting

Moved DRC report file to <step_dir>/reports/drc.rpt
Created a converted DRC KLayout xml file in <step_dir>/reports/drc.xml

Fixes https://github.com/efabless/openlane2/issues/527

Delayed till OpenLane 3. For cleaner implementation with API break