Integer capacity checks

What was wrong?
Previously it was possible to use numeric type constructors with literals that would not fit into the type. E.g. u8(1000) should error but currently doesn't.
How was it fixed?

Added bound checks for all numeric types
Added tests for all expected compile errors
Added tests that retrieve the min and max values for each numeric type.

To-Do

[ ] OPTIONAL: Update Spec if applicable

[x] Add entry to the release notes (may forgo for trivial changes)

[x] Clean up commit history

I probably need to update the tarpaulin setup. If I install it via cargo install cargo-tarpaulin and then run cargo tarpaulin --all --verbose it works.  Will further investigate tomorrow.

Codecov Report

Merging #167 (ecb72be) into master (8e3189b) will decrease coverage by 0.46%.
The diff coverage is 38.77%.

@@            Coverage Diff             @@
##           master     #167      +/-   ##
==========================================
- Coverage   80.48%   80.01%   -0.47%
==========================================
  Files          44       44
  Lines        3202     3198       -4
==========================================
- Hits         2577     2559      -18
- Misses        625      639      +14

Impacted Files
Coverage Δ

semantics/src/errors.rs
4.76% <0.00%> (-0.24%)
:arrow_down:

semantics/src/lib.rs
77.89% <ø> (ø)

semantics/src/namespace/types.rs
52.63% <25.80%> (-4.23%)
:arrow_down:

semantics/src/traversal/expressions.rs
73.91% <68.75%> (+2.06%)
:arrow_up:

compiler/src/yul/constructor.rs
50.00% <0.00%> (-3.85%)
:arrow_down:

compiler/src/yul/abi/operations.rs
73.33% <0.00%> (-1.67%)
:arrow_down:

compiler/src/yul/runtime/abi_dispatcher.rs
30.76% <0.00%> (-0.81%)
:arrow_down:

parser/src/string_utils.rs
99.44% <0.00%> (-0.56%)
:arrow_down:

parser/src/parsers.rs
100.00% <0.00%> (ø)

parser/src/tokenizer/regex.rs
100.00% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8e3189b...ecb72be. Read the comment docs.


Updating roadmap for 1.5

A microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the develop branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.
For status checks on the main branch, please use microsoft.ProjectReunion
(https://dev.azure.com/ms/ProjectReunion/_build?definitionId=391&_a=summary)
and run the build against your PR branch with the default parameters.

/azp run

@codendone or @bpulliam, please merge at your earliest convenience. Thanks!

/azp run

@codendone Did you mean to close this? Or merge it?

Re-opening :)


refresh delay time for "Delayed message delivery"

Is your feature request related to a problem? Please describe.
Describe the solution you'd like
For the delayed message delivery, the delay time will be fixed when the message is produced. There is no way to update the delay time in the future even when the message is not been deliveried.
But in some business scenario like auction, the auction will keep active when the player bid price. So we need to refresh the delay time(end time)
Describe alternatives you've considered
Additional context

@hoswey You can resend a new delay message when received the old one.

@hoswey You can resend a new delay message when received the old one.

It is a work around. But it seems it is not so  efficient.

@hoswey Yes, it's not efficient for handling this case but seems this is only a way to achieve the purpose. Supports update delay time of the message will introduce more complex in Pulsar or a message system.

@hoswey Yes, it's not efficient for handling this case but seems this is only a way to achieve the purpose. Supports update delay time of the message will introduce more complex in Pulsar or a message system.

Ok.


User Guide: Combine CLI pages

Which issue does this PR close?

Closes https://github.com/apache/arrow-datafusion/issues/1352
Rationale for this change

Why have two mostly duplicate pages documenting the CLI when you can have just one?
What changes are included in this PR?

Combine pages and fix formatting
Are there any user-facing changes?

No

This closes #1352 actually

Codecov Report

Merging #3133 (9e433f0) into master (b1765f7) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3133      +/-   ##
==========================================
- Coverage   85.95%   85.95%   -0.01%
==========================================
  Files         291      291
  Lines       52382    52382
==========================================
- Hits        45025    45023       -2
- Misses       7357     7359       +2

Impacted Files
Coverage Δ

datafusion/expr/src/logical_plan/plan.rs
77.43% <0.00%> (-0.35%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks @kmitchener  for the assist


A Mindmap to organize the content

I think it'd be awesome if we had a big mindmap to organize all the topics and subtopics.

Do you have any examples to consider? Are there any tools for generating mindmaps?

@siriniok take a look at learn-anything and its repo

@shotgunner yeah, thanks, was thinking about it. Need to take a detailed look.


Updated workflow-cps to version 2.92, compatible with kubernetes 1.29.7

Fixes issue : #1292

/assign akram

#1294 should superseed your PR.

@max-allan-surevine  I will close this PR in favor of #1294
If you think that we need 2.92 explicitely please comment on #1294
https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_jenkins/1294/pull-ci-openshift-jenkins-master-images/1405880471593684992/artifacts/build-logs/jenkins.log
/close

/reopen
/ok-to-test

There is an issue with the cron job that copies built images to quay.
/close


Remote Debugging Login Failure

As documented in the resolving of "Remote Debugging Login Failure - TrackingID#2205100050000008" by Microsoft Support, the UserID and password has change from the Azure UserID and password to those parameters' values in the last publishing profile obtained and used.
VS needs to be modified to automatically use those parameters.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3a52d11c-1c52-fb1d-c785-75845f6edee3
Version Independent ID: 35a11332-d74c-03dd-dbdd-75f256bd68b3
Content: Remote debugging - Visual Studio (Windows)
Content Source: docs/debugger/remote-debugging.md
Product: visual-studio-windows
Technology: vs-ide-debug
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

@alaskanrogue -- Marc, thank you for your feedback.  As this is product-related, please add it here:

Report product issues to us via the Report a Problem tool that appears both in the Visual Studio Installer and in the Visual Studio IDE.
Suggest a feature, track product issues, and find answers in the Visual Studio Developer Community.

I am closing this issue now.  You are welcome to @ mention me for any followup.  We hope to hear from you again.
cc @Mikejo5000 for awareness

@WilliamAntonRohm, Although this has a product-related aspect, the documentation here needs to be temporarily updated to inform developers as to this change of the UserID and password source. There is no currently published documentation with this insight.

@alaskanrogue Do you have a link to this issue? I suspect access to the issue might be restricted.

@alaskanrogue OK, thanks for the reply. It sounds like this is a bug that has since been resolved. In most cases, we wouldn't include something like that in the docs, so I will close this.


HTML

HTML
User Story
As a boot camp student
I want the pre-work notes to be structured and available on a website
so that I can easily find and read information
Acceptance Criteria
GIVEN a pre-work study guide website
WHEN I visit the website in my browser
THEN I see four boxes titled; HTML, CSS, GIT and Java Script with associated notes listed.

CSS
User Story
As a boot camp student
I want the pre-work notes to be structured and available on a website
so that I can easily find and read information
Acceptance Criteria
GIVEN a pre-work study guide website
WHEN I visit the website in my browser
THEN I see four boxes titled; HTML, CSS, GIT and Java Script with associated notes listed.

Java Script
User Story
As a boot camp student
I want the pre-work notes to be structured and available on a website
so that I can easily find and read the information
Acceptance Criteria
GIVEN a pre-work study guide website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first.

README
User Story
As a boot camp student
I want the pre-work notes to be structured and available on a website
so that I can easily find and read information
Acceptance Criteria
GIVEN the pre-work project repository
WHEN I view the README for the repository
THEN I can see a professional README that provides information on the project and how to use it

Deployment
User Story
As a boot camp student,
I want the pre-work notes to be structured and available on a website
so that I can easily find and read information
Acceptance Criteria
GIVEN a pre-work study guide website
WHEN I visit the website using the URL,
THEN I can access my website from any browser

gyg


Allow subdomain for --domain in project init

Fixes #473. However, it seems like route53 does not provide API allowing to validate if a subdomain exists. With this change, if user put "subdomain.domain.tld" then the domain name can be validated, but cannot validate if the subdomain under the domain exists.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Is this addressing Clare’s issue? If so, I think we should drop the route53domain check and, instead, check to see if there’s a route 53 hosted zone which matches the domain provides.

Agree we should check hosted zone. However, even if there is a route 53 hosted zone matching the domain provided, we should still check if the domain is associated with the aws account, which requires the route53domain check.

Is this addressing Clare’s issue? If so, I think we should drop the route53domain check and, instead, check to see if there’s a route 53 hosted zone which matches the domain provides.

Agree we should check hosted zone. However, even if there is a route 53 hosted zone matching the domain provided, we should still check if the domain is associated with the aws account, which requires the route53domain check.


PBI-7046 Fix namespace error when integrating plugin.

Due to different environments having different project configurations which affects how dependencies are resolved may cause namespace/type conflicts with the Apptentive singleton implementation. Implementing an alias ensures that these type conflicts don't happen.

Sorry I'm so late at reviewing this, but what do you think of calling it something like ApptentiveSDK instead of ApptentiveAlias?

LGTM, but do we want to think about a different name than ApptentiveAlias?

I agree, I changed it to ApptentiveSDK.


Fix isochrone containment and add deintersect option

Hello! Thanks for your work on this library. This PR does two things:

Fixes urbica/galton#180

It seems that when grouping routed destinations into isochrone duration intervals, larger intervals did not contain the points of smaller intervals. In scenarios where the isochrones were near an area where the road network suddenly ends (like a body of water), the larger isochrones would not include points along the edge of the road network since those points were allocated to a smaller isochrone. By simplifying the groupByInterval code I've fixed this problem, by including all points below the interval duration in each isochrone interval.

Add an isochrone configuration option deintersect which specifies whether to deintersect the resultant polygons.

The deintersect behaviour of Galton, where each isochrone subtracts the area of the smaller isochrones, is unintuitive. Deintersection is nice for visualization but it is inconvenient for using the isochrone for geospatial analysis. I decided to allow the user to choose whether or not they wanted to deintersect the isochrones via a new config option.
I'd love to see these changes in master, please let me know if there's any changes required before its good to merge!

Wow, thanks for PR, @glifchits! I'll review it soon.


Infinite scroll is not showing the last page of paginator.

The problem is: the last page of my paginator, the 'next button' is not being 'read' by infinit scroll.
You can click the button to load more and more, but never the last page of products.

Sounds related to #840. Is the last page not returning a 404, and rather a valid empty page? If so, then its the 840 bug.

No it was a developer problem, in this case I was the problem hehehe thank
you :) The selector was wrong
Em seg, 18 de fev de 2019 às 21:49, David DeSandro<EMAIL_ADDRESS>escreveu:

Sounds related to #840
https://github.com/metafizzy/infinite-scroll/issues/840. Is the last
page not returning a 404, and rather a valid empty page? If so, then its
the 840 bug.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/metafizzy/infinite-scroll/issues/865#issuecomment-464935187,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AiVQJkYZY0h-kVfRvmGUc2g0j3PXfE15ks5vO0oQgaJpZM4a9gVU
.


Fix erroring clippy lints about if let options

It also fixes the issue where clippy wasn't available on some nightlies so this got ran sporadically by using the new rustup feature to give us the latest nightly that has clippy in it.
The build is still failing, but that's fixed by #145

already fixed in master


Error injection for testing metadata table

What is the purpose of the pull request
Error injection for testing metadata table

@zhangyue19921010 FYI.  This one regarding error injection is cleaner, excluding all irrelavant changes.


proposal: log/slog: clean up the handler constructors

There are two ways to constructors
slog.NewJSONHandler(os.Stdout)
slog.HandlerOptions{}.NewJSONHandler(os.Stdout)

The former cannot set any options, the latter is a method on the options.
I believe this is a workaround for not having function overloads, if we had them it would have been written
slog.NewJSONHandler(os.Stdout)
slog.NewJSONHandler(os.Stdout, slog.HandlerOptions{})

The trouble is, the method construction form is not discoverable. Our documentation tools do a good job of recognizing that free functions are constructors and showing them with the type the construct, but the method form is not that, it is a method on what is an unrelated type. If you go to pkgsite trying to work out how to make a slog.JSONHandler, it is not easy to even know that it is possible to set options on it.
It also blesses the two handlers in that package as special, when the HandlerOptions is a generally useful struct that can be accepted by many external handler implementations.
The downside of the transformed form is that you always have to have slog.HandlerOptions{} even to get the defaults.
Maybe that is okay, we don't expect that new handler construction will be very common, if it is not we could use the pointer form, so that it is
slog.NewJSONHandler(os.Stdout, nil) // for nil
slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level:slog.LevelInfo}) // with options

Either way I think the methods on slog.HandlerOptions should be removed in favor of free functions.

Link to original slog proposal: #56345.

@dsnet, I'd love your thoughts. I was partly inspired by your design of encoding/json v2.

The way the v2 "encodingjson" prototype handles options is not something we particularly like and is subject to potential change.
In terms of API aesthetics, I personally like variadic options similar to how cmp.Equal operates.
The main reason why we didn't use variadic options for json.Marshal was for performance. It is occasionally the case that someone marshals incredibly tiny values (e.g., just a Go bool), where the amount of time spent iterating over a variadic list of options is a significant fraction of CPU time. It's on my TODO list to re-explore variadic options again to see if we can make it sufficiently performant, and we might switch to that (or some other options API).
Given that slog.NewJSONHandler is only called occasionally where you're not squeezing every nanosecond of performance out of the constructor, I don't think the concerns we were running into is applicable to your situation.

slog.NewJSONHandler(os.Stdout, nil) // for nil

One objection I've often heard with this approach is that the presence of nil is often a code-smell when calling APIs. It legitimately makes one ask themselves: "Is it okay to call nil here? How do I know that it doesn't lead to a nil-pointer derefence panic?". Even if the documentation of NewJSONHandler says it's okay, it's still a mental barrier that needs to be overcome.

The trouble is, the method construction form is not discoverable.

To this point, I feel like chainable methods on a configuration struct flow well into go doc or go.dev pages. I did like this approach when experimenting with slog. This is definitely a subjective conclusion (I think this is technically sound, but it's not the only way to do things) - I tried approaches more oriented around structs or variadic options, and I found chaining comfortable and capable, and the best for documenting.
To very quickly sketch that style of API, limited to slog:
// Opening a new logger configuration
func New() *Config

// Discrete configuration tasks
func (*Config) AddSource(bool) *Config
func (*Config) Ref(Leveler) *Config
func (*Config) Replace(func([]string, Attr) Attr) *Config
func (*Config) Writer(io.Writer) *Config

// Closing a configuration and producing a Logger
func (*Config) JSON()
func (*Config) Text()

Building a logger might look like:
// very fast to get up and running (if a default writer / ref of os.Stderr, INFO is sane enough)
log := slog.New().JSON()

// more detailed configuration, the per-line method calling survives "go fmt'ing"
log := slog.New().
	Replace(quirkyTimestamp).
	Ref(slog.DEBUG).
	Writer(os.Stdout).
	JSON()

Another solution could be to just name the constructors different things.
func NewJSONHandler(w io.Writer) *JSONHandler
func NewJSONHandlerWithOptions(w io.Writer, opts HandlerOptions)

My thought is the current model is effectively two constructors already.
You just replace:
slog.HandlerOptions{}.NewJSONHandler(os.Stdout)

With:
slog.NewJSONHandlerWithOptions(os.Stdout, HandlerOptions{})

@travbale, to be precise, you'll actually be replacing:
slog.HandlerOptions{}.NewJSONHandler(os.Stdout)

with
slog.NewJSONHandlerWithOptions(os.Stdout, slog.HandlerOptions{})

which is 17 characters longer unless we have #12854, in which case, it reduces down to:
slog.NewJSONHandlerWithOptions(os.Stdout, {})

which is 2 characters shorter.

@dsnet, Yep it would certainly is a bit more verbose so its not one to one. I know functional options could be done which is a pattern I like as well. Any implementation using functional options would increase the API surface area and would probably add more characters as well given each would be prefixed with slog so that would probably need to be considered if the constructors were to go that route. The benefit would be a single constructor.

Here's a example of the Opt form: https://pkg.go.dev/golang.org/x/net/http2#Transport.RoundTripOpt.

I personally think NewJSONHandlerOpt reads like you are making a new value for a type called JSONHandlerOpt rather than a new JSONHandler.

Here are some reasons why I think that functional options are inferior to option structs:

It isn't clear what happens when there are duplicates.

They are wordy, because you have to type the package prefix before each one.

(minor) They clutter the godoc: it has a separate function for each option, instead of a single struct entry.

It's clumsier to combine sets of options. If you have a group of options as a slice and you want to add some for a call,  you have to append, and if you don't clip the original you could have aliasing problems:
common := []Option{a, b, c}
f1 := newFoo(append(common, d))
f2 := newFoo(append(common, e)) // could overwrite the location containing d

Their advantages are:

The no-option case is easier to use (or, you only need one function instead of two).
You don't have to figure out how to handle cases where the default option is not the zero value. That is, you can distinguish a missing option from one set to its default value.

Here's another idea: keep the HandlerOptions struct but have the arg be ...HandlerOptions. Fail if there is more than one.
Problems:

No one ever does this.
Right now, NewJSONHandler and NewTextHandler have no error return, so you can put them directly inside slog.New. The new versions would either return an error, making them clumsier to use, or panic, which some might find too severe (although I think it's fine).

I sometimes wish that Go had a two-dot variadic argument that meant "zero or one".

@AndrewHarrisSPU, I think your fluent-config design is elegant. But it isn't idiomatic Go. In particular, people would expect slog.NewHandler to return a Handler, but it would actually return a HandlerConfig that only turns into a Handler when you call JSON or Text.
It also has one of the problems of the current design: the built-in handlers have special status with respect to the config/option type, because they're the only ones with constructors that are methods. That seems mildly unfair to third-party handlers.

How about
func NewJSONHandler(w io.Writer, opts HandlerOptions) *JSONHandler
func NewDefaultJSONHandler(w io.Writer) *JSONHandler

and then if we ever get the improved type inference rules we can deprecate NewDefaultJSONHandler in favour of using NewJSONHandler(w, {})

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I'd be +1 on a variadic approach, similar to cmp. A variadic options approach makes it easier to have defaults where the zero value could theoretically be significant.

Passing slog.HandlerOptions via *New* method would also allow to wrap both default handlers and override some methods.
ATM I have to copy full slog.JSONHandler just to add two additional fields to the Record when output is set to send data to logstash. Those 2 fields are totally irrelevant when logging to StdErr or StdOut

@mrhov, can you elaborate on that? Why can't you wrap the handlers now?

Here's another idea, mentioned at the end of the top post:
func NewJSONHandler(w io.Writer, opts *HandlerOptions) *JSONHandler

Yes, the tried-and-true, old-fashioned way. Its great advantages are that there is only one function, and it has precedent on its side. Almost anywhere you find an Options struct in the standard library, you will find a constructor that takes a pointer to it:

https://pkg.go.dev/database/sql#Conn.BeginTx
https://pkg.go.dev/image/jpeg#Encode
https://pkg.go.dev/image/gif#Encode
https://pkg.go.dev/net/http#PushOptions
https://pkg.go.dev/net/http/cookiejar#New
https://pkg.go.dev/crypto#Signer (the option type is an interface, so it can be nil)
https://pkg.go.dev/crypto#Decrypter (ditto)

I personally have no problem with passing nil to get the defaults, although others feel differently. I think that when the reader sees nil with a New function, they can make a pretty good guess that default options are being passed. It also alerts them to the fact that options are available, which in most other designs is hard to discover from reading a call.

func NewJSONHandler(w io.Writer, opts HandlerOptions) *JSONHandler

seems preferable. Passing slog.HandlerOptions{} more clearly communicates what's going on versus nil. If a shorter-form constructor is desired, NewJSONHandler could take io.Writer and no options (defaulting to the default values of each field) and a separate e.g. NewJSONHandlerOpts constructor could take the opts field.

@08d2, one problem with your idea is that people interpret NewX as "make me an X", unless certain words like "With" or "From" appear in "X". So NewJSONHandlerOpts would suggest that it creates  JSONHandlerOpts. This is the point that @travbale made above.

I said above that no one ever uses a variadic argument for a single optional value. Not true; here's an example from the standard library: https://pkg.go.dev/go/doc#NewFromFiles.

@mrhov, can you elaborate on that? Why can't you wrap the handlers now?

I had a brainfart. I can also wrap it now but I have to proxy all methods. Embedding it and just overwriting handle method was what I had in mind and that also won't work with new New* method. Sorry for noise.

@08d2, one problem with your idea is that people interpret NewX as "make me an X", unless certain words like "With" or "From" appear in "X". So NewJSONHandlerOpts would suggest that it creates  JSONHandlerOpts. This is the point that @travbale made above.

I don't think that NewJSONHandlerOpts implies that it creates a value of type JSONHandlerOpts. That seems like an overly-strict assumption about constructor naming conventions.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group


Update code to new std.process

There are some nice new cross-platform functions in std.process.
http://dlang.org/phobos/std_process.html#.spawnProcess

I just made and pushed a SpawnProcess implementation version.
It can be enabled by uncomenting:
version = SpawnProcess;
at the top of the file.
Sadly, it has a (very small) measurable overhead, and I cannot leave it as default, since I want to rely on this tool for measuring time with the smallest possible overhead.
Depending on the program that is passed to avgtime, this small overhead won't be noticed. But I cannot leave it as default, because one does not know in advance what I or the users will be measuring.
One can easily see it by compiling a test program:
void main() { }
and using thousands of repetions. The version with SpawnProcess has more "Total time", always, and the minimum times do differ too.
I didn't want this to be true, since the spawnProcess() implementation was so much cleaner. But I tested it several times and this difference was kept in Kubuntu, Windows and OS X.
Since the overhead is systematic, one could still rely on the SpawnProcess implementation for comparing the times of two programs under test. But I still want to get the closest measurement of absolute time possible.
Cheers, and thanks for creating the issue!
I know it took me a long time to reply but things have been crazy busy.
--jmcabo


thread pool used by rest client shall be daemon

otherwise it is possible to block the app to exit

https://github.com/hdinsight/spark-eventhubs/pull/67


NET::ERR_CERT_COMMON_NAME_INVALID for classic cite

Description
Clearly and concisely describe the issue or suggestion here:
There is a mismatch with the domain name for the classic site. When I navigate to https://classic.csunplugged.org/, I receive the NET::ERR_CERT_COMMON_NAME_INVALID error and cannot access the site. I am using Chrome, but the error is reproducible in Edge.
I am a teacher and need to print content from this website on 20 September 2021. Thank you for the quick response.

Checklist
Change the space in the box to an x for those you have completed. You can also fill these out after creating the issue.

[X] I have linked any relevant existing issues/suggestions in the description above (include #??? in your description to reference an issue, where ??? is the issue number).

If this is a code related issue, please include the following in your description:

[X] Steps to reproduce the behavior
[X] The platform(s)/software you are encountering the issue on
[X] The behavior you expect to see, and the actual behavior

Hi @BitsAndBytesTeacher, we have solved this issue a few hours ago however our classic website is currently down due to a urgent server migration. However if you send me an email at<EMAIL_ADDRESS>I can send you the resource you are looking for.


Is libhevc support iOS ?

Hi guys, is libhevc support iOS now? And how to build it for iOS if supported?

No, not supported currently.


Breadcrumb component className inconsistency

I'm submitting a ...

[x] bug report
[ ] feature request
[ ] support request

I'm labeling as 'designy' because the issue is regarding the class name of the component, but anyone can make this fix.
What is the current behavior?
The Breadcrumbs component does not match our naming schema
For bugs: please provide steps to reproduce and tell us a little about your environment (e.g., what OS and version of the package you're using)
If you inspect the Breadcrumb component you will notice that the rev- prefix is not there
What is the expected behavior?
The rev- prevfix should be present on all components so that the class names are consistent

Note: At this point we can't just add rev- before all of the Breadcrumb classNames b/c that will break styles for any current Harmonium projects using the Breadcrumb component. A better solution would be to update the classNames to match our naming schema and then extend those styles to legacy .Breadcrumb classNames


ivan: 055 -> 056

Motivation for this change
IVAN update
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build ivan

:alien: :+1:


cloudflare_zone_settings_override -> ciphers doesn't set back to default

Confirmation

[X] My issue isn't already found on the issue tracker.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.5.6
on linux_amd64

provider registry.terraform.io/cloudflare/cloudflare v4.26.0

Affected resource(s)

cloudflare_zone_settings_override

Terraform configuration files
resource "cloudflare_zone_settings_override" "website" {
  zone_id = local.cloudflare_zone_id
  settings {
    minify {
      css  = "off"
      html = "off"
      js   = "off"
    }
    #HSTS headers
    security_header {
      enabled            = false
      include_subdomains = false
      max_age            = 0
      nosniff            = false
      preload            = false
    }
    always_online               = "on"
    always_use_https            = "on"
    automatic_https_rewrites    = "off"
    brotli                      = "on"
    browser_cache_ttl           = 14400
    browser_check               = "on"
    cache_level                 = "aggressive"
    challenge_ttl               = 1800
    cname_flattening            = "flatten_at_root"
    development_mode            = "off"
    early_hints                 = "on"
    email_obfuscation           = "on"
    #filter_logs_to_cloudflare   = "off"
    hotlink_protection          = "off"
    http2                       = "on"
    http3                       = "on"
    ip_geolocation              = "on"
    ipv6                        = "on"
    #log_to_cloudflare           = "off" # cf-terraforming on : Error: filter_logs_to_cloudflare cannot be modified for this zone (1057), It is not possible to change Visitor IP settings for this zone. (1025), It is not possible to change Orange To Orange settings for this zone. (1024), log_to_cloudflare cannot be modified for this zone (1057)
    max_upload                  = 100
    min_tls_version             = "1.2"
    mirage                      = "on"
    #http2 client offer encryption in http 80
    opportunistic_encryption    = "off"
    opportunistic_onion         = "on"
    #orange_to_orange            = "on" # cf-terraforming off :  Error: log_to_cloudflare cannot be modified for this zone (1057), It is not possible to change Visitor IP settings for this zone. (1025), filter_logs_to_cloudflare cannot be modified for this zone (1057), It is not possible to change Orange To Orange settings for this zone. (1024)
    origin_error_page_pass_thru = "off"

    #https://github.com/cloudflare/terraform-provider-cloudflare/issues/495
    # first terraform apply  webp = "on" and polish="off" then polish="lossy"
    # webp on ONLY if Polish is on[lossy|losslest]
    webp                        = "on"
    polish                      = "lossy" # cf-terraforming lossy [off|lossy|losslest] : Error: Polish WebP conversion can be only triggered when Polish setting is enabled (1020)

    prefetch_preload            = "off"
    privacy_pass                = "on"
    #proxy_read_timeout          = "310"
    pseudo_ipv4                 = "off"
    response_buffering          = "off"
    rocket_loader               = "off"
    security_level              = "medium"
    server_side_exclude         = "on"
    sort_query_string_for_cache = "off"
    ssl                         = "strict"
    tls_1_3                     = "zrt"
    tls_client_auth             = "off"
    true_client_ip_header       = "on"
    #visitor_ip                  = "off" # cf-terraforming on :  Error: log_to_cloudflare cannot be modified for this zone (1057), It is not possible to change Visitor IP settings for this zone. (1025), filter_logs_to_cloudflare cannot be modified for this zone (1057), It is not possible to change Orange To Orange settings for this zone. (1024)
    #waf                         = "off"
    websockets                  = "on"
    zero_rtt                    = "on"
    #ciphers = ["ECDHE-RSA-CHACHA20-POLY1305","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-RSA-AES256-GCM-SHA384"]
  }
}

Link to debug output
https://gist.github.com/marccortinas/f09f040465bb6bd2983357a68bd9dad5
Panic output
no panic output
Expected output
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # cloudflare_zone_settings_override.website will be updated in-place
  ~ resource "cloudflare_zone_settings_override" "website" {
        id                       = "XXXX"
        # (6 unchanged attributes hidden)

      ~ settings {
          - ciphers                     = [
              - "ECDHE-RSA-CHACHA20-POLY1305",
              - "ECDHE-RSA-AES128-GCM-SHA256",
              - "ECDHE-RSA-AES256-GCM-SHA384",
            ] -> null

        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Actual output
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Steps to reproduce

Create a new zone
Apply my terraform configuration with a several resources, but the important one for this issue is cloudflare_zone_settings_override enabling TLS 1.3 and allowing only this ciphers ciphers = ["ECDHE-RSA-CHACHA20-POLY1305","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-RSA-AES256-GCM-SHA384"]

I can see with sslcan the ciphers han been properly filteres, let me show the ciphers supported.
  Supported Server Cipher(s):
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253

The issue appears when I comment the terraform line

resource "cloudflare_zone_settings_override" "website" {
  zone_id = local.cloudflare_zone_id
    ...
    tls_1_3                     = "zrt"
    ...
    #ciphers = ["ECDHE-RSA-CHACHA20-POLY1305","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-RSA-AES256-GCM-SHA384"]
  }
}

Terraform doesn't change the ciphers to the defaults ones.... It seems is not totally deterministic.
Additional factoids
Let me also share the interesting part of terraform state
108:31:47 ⏚ 190° 12d [mcortinas:~] lab(+1/-1)* 10s ± terraform state show cloudflare_zone_settings_override.website
# cloudflare_zone_settings_override.website:
resource "cloudflare_zone_settings_override" "website" {
    id                       = "XXXXXXXXXXXX"

    ....
    settings {
    ...
        ciphers                     = [
            "ECDHE-RSA-CHACHA20-POLY1305",
            "ECDHE-RSA-AES128-GCM-SHA256",
            "ECDHE-RSA-AES256-GCM-SHA384",
        ]
        ...
        ssl                         = "strict"
        tls_1_2_only                = "off"
        tls_1_3                     = "zrt"
        tls_client_auth             = "off"
       ...
    }
}

References
No response

Let me attach TF_LOG=DEBUG output applying terraform with cyphers line commented like this:
resource "cloudflare_zone_settings_override" "website" {
  zone_id = local.cloudflare_zone_id
    ...
    tls_1_3                     = "zrt"
    ...
    #ciphers = ["ECDHE-RSA-CHACHA20-POLY1305","ECDHE-RSA-AES128-GCM-SHA256","ECDHE-RSA-AES256-GCM-SHA384"]
  }
}

terraform.apply.debug.cipherscommentedandNOTrollbacked.filtered14.log

thanks for this @mcortinas - a couple of things to note.
the first is that i highly recommend you do not manage all zone settings in this resource, only the modified ones. our docs also mention this in case it wasn't clear - https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/zone_settings_override . we will be superseding this resource in the near-ish future with individual settings to avoid some of the baggage and misunderstanding that has been created with this resource.
the second is along a similar vein but the way this resource "defaults" values back is really inconsistent and not supported for all endpoints. it attempts to track the state internally and when it notices a change, force the defaults back to the expected values. there are a bunch of issues with the resource as well as the internal diff customisation that makes this pretty hard to do and realistically, it against how resources should be managed in terraform.
this is all to say, the problem here is kind of expected and we shouldn't depend on it operating correctly. instead, if you want this to work, you'll need to always provide the expected values. sorry! hoping to make this better with the replacement resources in time.

sure! thank you for your answer and also thank you for share your strategy in order to avoid use this resource and use other little resources just to simplify this kind of consistency and idempotency. step by step, right now, this resource is very useful to onboard with Terraform in Cloudflare
apologies I should close this issue last 21Mar due to Unsmart|Tech debt bot answered quickly to me in this discord thread https://discord.com/channels/595317990191398933/1043025669036187678/1222251756772393152
Thank you @jacobbednarz for your effort in this provider/project , I'm using a lot and it has been pretty useful for me


updating of property members and outdated libraries.

update of testbench to 6.17, properties are modified
Requirements
Please take note of our contributing guidelines: https://nikazooz.github.io/laravel-simplesheet/1.0/getting-started/contributing
Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
Mark the following tasks as done:

[x ] Checked the codebase to ensure that your feature doesn't already exist.
[ x] Checked the pull requests to ensure that another person hasn't already submitted the feature or fix.
[ x] Adjusted the Documentation.
[ x] Added tests to ensure against regression.

Description of the Change

orchestra / testbench library update 6.17.

Modify the member of the function getContainer () protected to public.

Misnamed function SpreadsheetServiceProviderTest to SimplesheetServiceProviderTest

Use Orchestra \ Testbench \ TestCase as TestCase is added. instead of phpunit / framework / testCase

can be run now ./vendor/bin/testbench package: test new way to run tests

Why Should This Be Added?
the upgrade to the test library is a fundamental part of any library. It should be added so that other developers have the facility to be able to execute the tests and provide solutions to the errors that arise from the new versions of laravel
Benefits
run tests with packages that have been updated, for example phpunit 9, testbrench and their new features. so that the community can grow
Possible Drawbacks

Incompatibility with libraries already installed, as the change is in test it will not affect the productive part.

Verification Process
errors arose from the library that were not foreseen, so I could verify that the update in the test folder was useful

Applicable Issues
no hassle applicable to new changes

Important changes from this PR have already been integrated into the package


Give proper theming using styled-component

Example supported for the darkmode.

[Dark Mode]

[Light Mode]


FreeCourseSite, FreeTutorials.eu and tpget have shut down

Thanks for the info. 'FreeCourseSite' is live now. Let me know if you can find any other problems.


[20.09] haskellPackages.hakyll: fix build

Motivation for this change
Things done
I appended the commits from https://github.com/jaspervdj/hakyll/pull/787.
Edit: This also fixes hakyll-contrib-hyphenation, so I marked it as unbroken.

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

The PR has not been merged, so the referenced commits may disappear when the PR is rebased.

Mh right, any idea how I could circumvent this?
There are already about 8 occurences of this pattern in the file, so I guess it is somewhat common?

Okay, let's stop this here.
I'm not willing to put any more energy into pushing such a minor change forward. The amount of bikeshedding I've encountered in the Haskell part of Nixpkgs is just too high for me as a low-volume contributor. Somehow this is really haskellPackages specific for me. For the last few months I consistently regretted it to have opened a PR to haskellPackages. That is not the case for any other part of Nixpkgs.
I'm not saying that the individual nitpicks in this PR and other PRs I opened aren't justified. It's just that I fail to see how meeting these high code standards stands in any relation to the utility of bringing these changes upstream. Most of the time when Hakyll broke in the last few years, there was no visible reaction in the NixOS community. This tells me, that only a few people use it. Why go through so many review iterations for this little gain?
I'm perfectly fine with just rebasing my changes ontop of my own branch, without bringing them upstream. Considering that bringing my changes upstream usually takes an order of magnitude more time than just fixing it for myself, it just doesn't add up to me anymore. I think I'll still open PRs to haskellPackages, but close them immediately, so other people in need of a fix can at least find and cherry-pick the solution.

@erictapen I assume you're talking about me, and I do appologize that you haven't had a good experience contributing to the Haskell part of Nixpkgs.
Let me try to explain some of my thinking so you can see where we're coming from.
The Haskell part of Nixpkgs has few regular contributors (only three of us).  However, there is a relatively high volume of drive-by contributions.  These are often one-off contributions by people that don't "follow-up" on stuff they get merged in.  So if the stuff they submit becomes broken, it is up to the three regular maintainers to either fix it up or tear it out.
Without ample comments (for example above, why were certain patches applied to hakyll, and why were they only applied when building with Linux), it is pretty challenging for us to continue to maintain all the overrides in configuration-common.nix.  This is doubly true when none of us personally use a package, or understand the reason for the overrides.
A lot of the brunt of fixing up Haskell stuff falls on @peti (since he does the weekly updates), so my main goal over the past year has been to make sure new contributions are well documented.  This lets the other maintainers (as well as new users) easily figure out the reason for the various overrides we apply here in nixpkgs.

I think I'll still open PRs to haskellPackages, but close them immediately, so other people in need of a fix can at least find and cherry-pick the solution.

While I think it is unfortunate you no longer want to contribute to the Haskell stuff here in nixpkgs, a lot of people will be thankful that you at least create the PR initially.  I think a lot of people search for old PRs before creating new ones, so this will hopefully save some people from figuring out everything from scratch!

Hakyll builds just fine in LTS-16.12, which Nixpkgs is based on. It seems to have been broken by https://github.com/NixOS/nixpkgs/pull/96560/commits/05bf5320827b3105abfc450da60228ca01f90c2f.
I would expect that updates on top of stackage are opt-in. Doing it that way increases the chance that stackage builds successfully, which has most of the important packages.

@cdepillabout Thank you for taking the time to elaborate on your perspective. First I'd like to make clear, that my rant wasn't about your reviews specifically, but more about a broader "the way thinks work" I noticed for quite some time in haskellPackages. Second I now understand better, that the high ratio of drive-by contributions vs. long-term maintainers is a situation with high incentives to avoid maintainenance debt. Maybe there really is no way around the high standards currently.
I think I'll take a break to bringing my commits through review, until I have more time/energy to do it.


Shape info

Add shape info to all distributions
@chrisb83 opening this up to make it easy to see the diff
@tirthasheshpatel @kai-striega if you'd like to help, we can divide and conquer, I'll start at the bottom and work my way up.

Thanks @chrisb83. Not sure if it's needed, but just a reminder to not to force-push. (Some people don't mind it, but I don't like erasing history mid-review. Besides, we're almost certainly going to squash-merge anyway!)

if you'd like to help, we can divide and conquer, I'll start at the bottom and work my way up.

I will start from the top :smile: !!

Oops I'll merge upstream main into my main to clean this up

One more PR to your branch to consider @chrisb83. I added tests for the three distributions that failed the default test. I don't think they're particularly problematic, the default test is just unlucky.

One more PR to your branch to consider @chrisb83. I added tests for the three distributions that failed the default test. I don't think they're particularly problematic, the default test is just unlucky.

Thanks, I merged it.
I also addressed all your comments except the one on genextreme

OK, other than genextreme this looks good to open against the main repo.

OK, other than genextreme this looks good to open against the main repo.

I will create a PR tomorrow


Updated commercial resources and E2E tests

Context
AB#234352 AB#233625
Guidance to review
Ensure links updated according to the latest recommended resources attached to the story.
Checklist (add/remove as appropriate)

[x] Work items have been linked (use AB#)
[x] Your code builds clean without any errors or warnings
[x] You have run all unit/integration tests and they pass
[x] Your branch has been rebased onto main
[x] You have tested by running locally
[ ] You have reviewed with UX/Design

Can we leave this as draft? This was due to be done post public beta.

This will need a design/client review, so me and @J05h-L can pick up next week.


Error on generated package.json: unmarshalling package.json

I've got the followwing error when deploy the app:
status: FAILURE unmarshalling package.json: json: cannot unmarshal array into Go struct field PackageJSON.dependencies of type map[string]string
The generated package.json is set to an empty array in dependencies, when changed to an empty object it works.
Before:
  {
    "type": "commonjs",
    "dependencies": []
  }

After:
  {
    "type": "commonjs",
    "dependencies": {}
  }

Few questions

which version of nodejs are you on
which os are you using
are you providing any configuration to the adapter?

I just figured out what was causing this: An empty array on adapter dependencies configuration in svelte.config.js. Just remove it and everything works as expected.


Add code coverage reporting

:tada: This PR is included in version 2.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Format documet couse an issue for json

I have json file when I applied format document in that, VScode has added an extra bracket at the end of the JSON file

Is this a duplicate of #91125? Can you re-test using Insiders?


Add unit tests to API endpoints

Add unit tests to API endpoints
Summary
Provide unit tests for existing API endpoints using Jest to ensure reliable and maintainable code. The goal is to validate the functionality of the API and catch any potential issues early in the development process.
Description
This feature will introduce Jest unit tests for each API endpoint in the application. These tests will cover various scenarios, including successful responses, error handling, and edge cases. The tests will be organized by endpoint and will use mocking libraries where necessary to simulate dependencies like databases or external APIs.
Requirements

Jest should be used as the testing framework.
Each API endpoint must have corresponding test cases covering all major functionality.
Use mocking for external dependencies (e.g., database connections, third-party APIs).
Ensure that the tests are integrated with the CI/CD pipeline to run automatically on each pull request.
The tests should be written in a way that is easy to understand and maintain.

Alternatives

Considered using other testing frameworks like Mocha or Jasmine, but Jest was chosen due to its popularity and integration with the current toolchain.

Completion Criteria

All tests pass successfully in both local and CI environments.
The tests should cover at least the following scenarios:
Successful request handling (200 status code).
Proper handling of invalid input or request parameters (e.g., 400, 422 status codes).

Additional Context
By adding these tests, we aim to catch regressions and bugs earlier in the development cycle, reducing the time spent on manual testing and debugging.
Images and Resources

Jest Docs
Setting up Jest with Next.js

Not worrying about this. See closed issue #72 and #67


[Request] allow for connecting to non-standard Twitch hosts/port

I'd like to be able to specify a non-standard TMI host and port.
This is currently supported by the tmi_host and tmi_port parameters in the native Twitch stack.

In the configuration, you can pass connection.server and connection.port.
let client = new tmi.Client({
        connection: {
            server: 'hostname',
            port: 1234,
            ...
        },
        ...
    });

https://github.com/tmijs/tmi.js/blob/0fba732f2d03a20150abfbe3833001d2fcf81aa4/lib/client.js#L903-L908
https://github.com/tmijs/tmi.js/blob/0fba732f2d03a20150abfbe3833001d2fcf81aa4/lib/client.js#L926


misc: Fix LLVM team dropping libclang-rt-dev dependency

See https://groups.google.com/g/linux.debian.bugs.dist/c/jFEvS84SakQ

Codecov Report

Merging #1 (0ea9891) into main (343f2df) will decrease coverage by 2.25%.
The diff coverage is 0.00%.

:exclamation: Current head 0ea9891 differs from pull request most recent head daf82b6. Consider uploading reports for the commit daf82b6 to get more accurate results

@@            Coverage Diff             @@
##             main       #1      +/-   ##
==========================================
- Coverage   77.97%   75.72%   -2.26%
==========================================
  Files          13       18       +5
  Lines         840      865      +25
  Branches      147      150       +3
==========================================
  Hits          655      655
- Misses        184      209      +25
  Partials        1        1

Impacted Files
Coverage Δ

src/bootstrap/ast/symbolTable.cxx
0.00% <0.00%> (ø)

src/bootstrap/ast/symbolTable.hxx
0.00% <ø> (ø)

src/bootstrap/core/utf8/string.hxx
87.23% <ø> (-1.90%)
:arrow_down:

src/bootstrap/core/utf8/stringView.hxx
14.28% <0.00%> (-5.72%)
:arrow_down:

src/bootstrap/parser/parser.cxx
0.00% <0.00%> (ø)

src/bootstrap/parser/parser.hxx
0.00% <0.00%> (ø)

src/bootstrap/core/flags.hxx
0.00% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@dragonmux libclang-rt-14-dev seems to be intentionally designed to break existing Clang 14 installations. Quoting from their Packages manifest:
Package: libclang-rt-14-dev
Source: llvm-toolchain-14
Version: 1:14.0.6~++20230109103106+f28c006a5895-1~exp1~20230109223114.123
Architecture: amd64
Maintainer: LLVM Packaging Team<EMAIL_ADDRESS>Installed-Size: 42863
Depends: lib32gcc-s1 (>= 3.0), lib32stdc++6 (>= 4.1.1), libc6 (>= 2.34), libc6-i386 (>= 2.34), libgcc-s1 (>= 3.0), libstdc++6 (>= 4.1.1)
Breaks: libclang-common-14-dev (<< 1:14.0.6-10~exp4)
Replaces: libclang-common-14-dev (<< 1:14.0.6-10~exp4)

yet the package only has a handful of libraries:

Many thanks for this! And yeah, all of those are extremely important to much of building/linking with Clang shakes head at. We'll get this reviewed and merge ASAP


Update Hello.java

Sending sample pull request.

Author tags are discouraged in Apache projects (as well as some others).
Recognition of contribution comes from the release notes (for new contributors) and being asked to act as a committer (for longer-term helpers).
Can you revise the pull request?

Removed the Author tag.


What else broke my heart... Microsoft who now owns Github... o... and Adobe recommening Microsoft Visual Studio Code as a brackets replacement :(((( I will stick to Sublime Text, thanks (and Typescript?... no thanks, Linkedin... no thanks).

There is nothing more cliche than someone online going "X company sucks", make your own company then, let's see how awesome and perfect yours is.

#15329

Hi :-)
Let's organise!
https://github.com/brackets-cont/brackets


frontend: Adjust protocol related code to reflect latest contract changes

Fixes #1025
Its discussable whether we should also remove the fulfillmentInformation from the code.
It was nowhere used nor there is any plan to use it in the near future.
The only critical question is: is the code still backward compatible?
IMO, since no logic depended on this information except the tests, it is safe to say that it wont break compatibility.
Also the "encoding"/"decoding" of the persistent store will not break since we are just removing a field.
Would love to hear others opinions.
I removed it in this PR but if the discussions lead to bringing it back will do so.

Also spotted & fixed an edge case where the wallet provider is not properly initialized as a ref inside Transfer.vue component and therefore making withdraw requests fail when the user comes to the app directly to the "Activity" tab.
To reproduce this you need to create & wait for a request to expire - shows up as expired and ready for withdrawing on the UI. After that refresh the page with /#/?activeTabLabel=Activity and try withdrawing funds.
You should get this:

I never questioned the fulfillmentInformation because I thought Thore added it with a specific feature in mind. I'm in for removing it. There is a todo comment in the transfer.ts: // TODO: set this.fulfillmentInformation . It was never in use as far as I can see. Also it is an optional property of a transfer. Probably, never a transfer with this property was put into anyone's local storage. Anyway removing an property should not break anything as long as we just ignore unexpected fields.

These changes will definitely not work with local storage data of an earlier version of the dapp. An older transfer id cannot get parsed as the new byte based identifier for example. The old transfer would not be in the new contract anyway. But still we need to make sure that old local storage data is not accessed in a new dapp deployment.
How should we address this issue? I would like to find a solution to this before this is merged.
Interestingly, when we designed the transfer storage we considered so many cases where the frontend could have breaking changes for the local storage, but we never considered breaking changes from the smart contracts.
This makes my earlier comment about the fulfillmentInformation a bit irrelevant as we have breaking changes here anyway.


Full Body Monitoring using Mediapipe

What type of PR is this? (check all applicable)

[x] 🚀 Added Name
[x] ✨ Feature
[ ] 🌟 stared the repo
[ ] 🐛 Grammatical Error
[ ] 📝 Documentation Update
[ ] 🚩 Other

Description
Add Link of GitHub Prof
My github profile: https://github.com/mrsparkle-70

@Nitin-Diwakar Can u check it

I only accept 1 personal project. This repository is for a person creating a project/analysis report by given dataset in the for data analysis directory. If you want to pull request, read about the rules of this repository in the Readme.md section.

Ok sir
On Tue, Oct 4, 2022 at 11:55 AM Nitin Diwakar @.***>
wrote:

I only accept 1 personal project. This repository is for a person creating
a project/analysis report by given dataset in the for data analysis
directory. If you want to pull request, read about the rules of this
repository in the Readme.md section.
—
Reply to this email directly, view it on GitHub
https://github.com/Nitin-Diwakar/Data-Science-Data-Analystics-Contribution---Hacktoberfest-2022/pull/8#issuecomment-1266453262,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZLJHE7H5IWTTPFL2GR5TRTWBPEWRANCNFSM6AAAAAAQ4HLEYU
.
You are receiving this because you authored the thread.Message ID:
<Nitin-Diwakar/Data-Science-Data-Analystics-Contribution---Hacktoberfest-2022/pull/8/c1266453262
@github.com>

Sir
Should I upload Datasets then ?
I am not clear about this
It would be very nice if u clear this doubt of mine
On Tue, Oct 4, 2022 at 11:56 AM Subham Sinha @.***> wrote:

Ok sir
On Tue, Oct 4, 2022 at 11:55 AM Nitin Diwakar @.***>
wrote:

I only accept 1 personal project. This repository is for a person
creating a project/analysis report by given dataset in the for data
analysis directory. If you want to pull request, read about the rules of
this repository in the Readme.md section.
—
Reply to this email directly, view it on GitHub
https://github.com/Nitin-Diwakar/Data-Science-Data-Analystics-Contribution---Hacktoberfest-2022/pull/8#issuecomment-1266453262,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZLJHE7H5IWTTPFL2GR5TRTWBPEWRANCNFSM6AAAAAAQ4HLEYU
.
You are receiving this because you authored the thread.Message ID:
<Nitin-Diwakar/Data-Science-Data-Analystics-Contribution---Hacktoberfest-2022/pull/8/c1266453262
@github.com>

In the For data analysis directory there are different types of datasets, pick one of them and push your analysis report to the repo. You can use any application for analysis such as PowerBI, jupyter notebook, excel, etc


Cache file update not atomic

I intend to include this library in an app which automatically refreshes the public suffix list at regular intervals, but I am worried that the file_put_contents method used within the library is not atomic, so in theory a page request could come in while the file is being altered which uses a partially-written list.
https://github.com/jeremykendall/php-domain-parser/blob/6c1a256/src/Pdp/PublicSuffixListManager.php#L206
Could this method be rewritten to use a temporary file followed by an atomic @rename() instead?  I could put together a PR if you would accept it.

I am worried that the file_put_contents method used within the library is not atomic ...

You're correct. It never crossed my mind, and that's an obvious shortcoming in the library.

I could put together a PR ...

Awesome!

... if you would accept it.

I never promise to accept a PR, but I do promise to give it a thorough review and either 1) merge or 2) ask for modifications. I rarely reject PRs, for what that's worth.
I'd also like to consider using flock seeing as how that would avoid the use of a temp file, with the caveat that I've never used it myself and obviously don't have experience with atomic writes :disappointed:
Thanks so much!

@mikegreiling a new stable version of PHP Domain Parser has been released and it nows uses PSR-16 instead of caching to resolve this issue and allowing caching the data in numerous backend not only files.


[Event Request] Codeunit 5056 CustCont-Update - OnAfterOnModify

Please add a new publisher event to the function OnModify as follows:
.
.
Cont.OnModify(OldCont);
Cont.MODIFY(TRUE);
Cust.GET(Cust."No.");

//>> Start New Publisher Call
OnAfterOnModify(Cont, OldCont, Cust);
//<< End New Publisher Call

New Publisher Event:
LOCAL [IntegrationEvent] OnAfterOnModify(VAR Contact : Record Contact;VAR OldContact : Record Contact;VAR Customer : Record Customer)

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


chore(autoware_auto_perception_rviz_plugin): higher visibility of predicted path color

Description
The visibility of predicted path is not so good depending on the path confidence.
It's hard to tell the difference in the figure.

Tests performed

planning simulator
Effects on system behavior

nothing
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@taikitanaka3 Could you approve the PR.


Confusing error if metadata.json contains nested data

Create an invalid metadata.json file like this:
{"settings": {"trace_debug": 1}}

And start Datasette like so:
datasette -m metadata.json

Datasette appears to start correctly, but when you attempt to load any page you get this error:

Error binding parameter 1 - probably unsupported type

I ran datasette -m metadata.json --get / --pdb and found that the problem was here:
126  	    async def execute_write(self, sql, params=None, block=True):
127  	        def _inner(conn):
128  ->	            return conn.execute(sql, params or [])
129
130  	        with trace("sql", database=self.name, sql=sql.strip(), params=params):
131  	            results = await self.execute_write_fn(_inner, block=block)
132  	        return results
133
(Pdb) print(sql)
              INSERT INTO metadata_instance(key, value)
                VALUES(?, ?)
                ON CONFLICT(key) DO UPDATE SET value = excluded.value;
(Pdb) params
['settings', {'trace_debug': 1}]

That's happening here: https://github.com/simonw/datasette/blob/1f3fb5f96b3f6e773b8c1b8ec5d8f7516c6860b0/datasette/app.py#L737-L746
Two options:

Add metadata validation, such that problems like this are spotted and Datasette refuses to start until the metadata.json is fixed
Teach that feature to convert complex values to JSON and write those to the table

I'm tempted by option 2 - I think it will be easier and supporting nested JSON in metadata feels like it could be useful.

With that fix in place, the above example can do this:
datasette -m bad.json --get '/.json' | jq

{
  "databases": {
    "_memory": {
      "name": "_memory",
      "hash": null,
      "color": "a6c7b9",
      "path": "/_memory",
      "tables_and_views_truncated": [],
      "tables_and_views_more": false,
      "tables_count": 0,
      "table_rows_sum": 0,
      "show_table_row_counts": false,
      "hidden_table_rows_sum": 0,
      "hidden_tables_count": 0,
      "views_count": 0,
      "private": false
    }
  },
  "metadata": {
    "settings": "{\"trace_debug\": 1}"
  }
}


Carla crashes when running python scripts : python3 manual_control.py

CARLA version: 9.15
Platform/OS: Ubuntu 20.04.6 LTS
Problem you have experienced: Carla crashes after running python3 manual_control.py and other python scripts inside PythonAPI/Examples
Error appeared: ValueError: sticky_control: invalid value type
Screenshot:

What you expected to happen: It should launch successfully.
Steps to reproduce:

Launch : ./CarlaUE4.sh
From PythonAPI/examples, Launch manual_control.py

Try changing the default value of --generation to 3 at line 1330 of the manual_control.py !

When the Python client is the dev branch and the server is the 0.9.15 release, I encountered a similar issue. If both the server and client are the latest dev branches, there is no such problem.

I faced the same problem and I solved it by:
As you can see, your Client API version (0.9.15-......) is different with Simulator API version (0.9.15). This is may because you have installed another Carla Python Client API before.
So you can just create a new Python virtual env and:
pip install pygame numpy
cd PythonAPI/carla/dist/
pip install carla-0.9.15-cp37-cp37m-manylinux_2_27_x86_64.whl (maybe your filename is different)

Problem

I faced the same problem but my environment is win10 and I was running CppClient example

The version seems to match correctly between server and client

environment

system: win10

carla server: downloaded from ue4-dev branch of github README

carla client: build from ue4-dev branch of github

Log
The log after running cppclient.exe
Client API version : 0.9.15
Server API version : 0.9.15
Loading world: /Game/Carla/Maps/Town02
INFO:  Found the required file in cache!  Carla/Maps/Nav/Town10HD_Opt.bin
INFO:  Could not find the required file in cache, downloading...  Carla/Maps/Nav/Town02.bin

Exception: sticky_control: invalid value type


Topic/reflection without remorse

I've been kicking around these changes for a while, but I wanted to get them together in this PR to spark a discussion and get a feel for what others think about taking a new direction with the free monad implementation.
The main change is that the implementation is in the spirit of the implementation described in the paper Reflection without Remorse. I think going this route is beneficial because it alleviates quadratic complexity issues in both left-associated binding and in observability. Mandubian's blog gives some additional of these issues in terms of Scala.
Attached is a preliminary benchmark for left-associated binding of the current free monad implementation at v0.6.0, and then the new implementation based on Reflection without Remorse.

Even though these results are preliminary, I think it is clear on what gains are possible with this implementation. On that note, I am totally open to discussion on the underlying data structure used to store up the binds of the free monad. I currently have a linked-based structure, which seems to perform well. I tried Data.Sequence, but I couldn't get the performance. In any case, I am up for a discussion on this.
Also, the free monad is defined more operationally, which allowed for a simplified API. We no longer really need FreeC since most of the Free functions no longer require a functor instance. I think this makes the free monad more straightforward to use and removes duplicating functions implemented for both Free and FreeC.
I know that these are significant changes to the free monad internals, as well as some breaking changes. So I am up for any feedback, comments, questions, and/or suggestions.

Wow, this looks really interesting! I can't really see any downsides in what you're proposing in that it gives us better performance and a simpler API, but I primarily understand Free in how its used, not it's "deeper" meaning, so not sure if there are any cons on that side of things.
My only (rather silly) comment after having a quick look is can we keep the type synonym as just Natural? I've been using it a lot lately, and NaturalTransformation seems a bit wordy now :smile:

This is exciting :)

I'm a big fan of this approach. A few comments:

Obviously this approach requires some unsafety in the implementation, which is totally OK as long as we can hide that in the external API.
I'm a fan of minimizing unnecessary changes, e.g. Natural versus NaturalTransformation, and also retaining some helper functions that this PR doesn't have (e.g. bindF). Obviously, we'd want to delete the dual versions of functions, but beyond that, I don't think the external API has to change that much.

If you need a structure with fast uncons, snoc and append, maybe a difference list would work? Or maybe a pair of lazy lists where you move elements across as needed?

One more: I would recommend using a PureScript data structure rather than a native one. Performance penalty should be quite small and the additional type safety and readability would be nice. A difference list (which does not exist yet in PureScript?) does seem like a possible first choice.

https://github.com/Thimoteus/purescript-difflists
:smile:

https://github.com/Thimoteus/purescript-difflists

I had no idea. :smile: I would not recommend that representation in PureScript (I don't think it will have good performance characteristics), instead I would recommend data DList a = DList (List a) (List a). Also the project has no license file.

Thank you everyone for taking a look at these changes. I am excited by the direction this is going.
In terms of the API changes, we can definitely keep Natural over NaturalTransformation. Should we pull Natural out into its own module or leave it in Data.Coyoneda? Or leave NaturalTransformation and define an alias in Data.Coyoneda? I am open to any option we decide on.
Regarding bindF, I wrote an implementation for that but I ended up just writing it in terms of foldMapF
bindF :: forall f g a. Free f a -> NaturalTransformation f (Free g) -> Free g a
bindF fa t = foldMapF t fa

Does foldMapF fit the use-case for bindF? If so, I am unsure if we need bindF.
Regarding the underlying data structure, I am definitely open to changing this. I originally tried purescript's Data.Sequence, but it did not end up with having good performance here. Below is an updated chart with those numbers.

I didn't dig very deep on why this wasn't performing well. However, I'd be open to taking a second look. Also, using a difference list sounds appealing. I will test out a few options and see what works best. Any other thoughts or options are most welcome.

I think bindF as foldMap makes sense. foldMap is expressing the adjointness of the free monad construction to the "only keep the functor" operation, so it makes more sense to have that than bindF I think. The free library calls it foldFree.

This PR is amazing :rainbow:

:)
@paf31 Sounds good about bindF. And I am open to renaming foldMapF to foldFree or maybe even foldF. But I am just as happy to leave it as-is.

@paf31 @jdegoes I wasn't expecting anyone to use my difflist package, but I'm updating it now (currently adding benchmarks, already added an MIT license that'll come in the next push). And my idea for it was to support difference lists for a variety of "cons"able structures.

And my idea for it was to support difference lists for a variety of "cons"able structures.

I may be wrong, but I think a singly-linked list (aka List) is possibly the only structure which can benefit from this technique, so I'd suggest specializing specifically to List.

EDIT: I updated it. Also @jdegoes are you thinking of the first type of difference list as explained here?

No, it's the same idea, just represented differently. data DList a = DList (List a) (List a) has two lists, one which represents prepends and one which represents appends. You get all the nice properties of a difference list without building up the very complex structure of the more classic representation of DList.

I've been working on a bare-bones implementation of a DList as well as a catenable list built on top of the DList in the repo ethul/purescript-catenable. @jdegoes I am not sure if this was more or less the implementation you had in mind.
However, the linkAll function is not currently stack safe. I am wondering if we can come up with some ideas of how to make this tail recursive. Any thoughts would be greatly appreciated.
Also, it is possible to get linkAll to O(1) amortized time if we introduce laziness. I haven't gotten that far yet, but it might be a good next step. Or maybe there is a better way to do this entirely.

@paf31 I've been working on a stack safe version of linkAll using the purescript-safely module. However, it still seems to be giving me a stack overflow. Is there something you can spot that is amiss with how I've got it wired up? I appreciate any thoughts or pointers.

@ethul That's still pretty experimental, but it only attempts to make the binds safe, not the rest of the computation. I've seen it fail before for things like traverse, where you build up a big data structure in the result. Maybe that's the issue? Can you see where the stack overflow is occurring?

@paf31 Thanks for taking a look. Noted on the experimental status. It is possible that the issue is where the data is built up. I will have to dig more into it. However, the stack overflow trace produced is:
RangeError: Maximum call stack size exceeded
    at new Bind (/path/purescript/purescript-free/output/Prelude/index.js)
    at /path/purescript/purescript-free/output/Control.Coroutine/index.js:164:16
    at null.__superclass_Prelude.Bind_1 (/path/purescript/purescript-free/output/Control.Coroutine/index.js:158:44)
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:88
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120
    at /path/purescript/purescript-free/output/Data.CList/index.js:89:120

So it looks to fail at the return new Prelude.Bind(function () { in
var bindCo = function (__dict_Functor_28) {
    return function (__dict_Monad_29) {
        return new Prelude.Bind(function () {
            return applyCo(__dict_Functor_28)(__dict_Monad_29);
        }, function (_43) {
            return function (f) {
                if (_43 instanceof Bind) {
                    return Data_Exists.runExists(function (_23) {
                        return bound(_23.value0)(function (x) {
                            return bound(function (_22) {
                                return _23.value1(x);
                            })(f);
                        });
                    })(_43.value0);
                };
                return bound(function (_24) {
                    return _43;
                })(f);
            };
        });
    };
};

But that's just the top stack frame right? Looks like it gets stuck at /purescript/purescript-free/output/Data.CList/index.js:89:120

@paf31 You're right. That is the line return Prelude[">>="]... in
var foldrM = function (__dict_Monad_1) {
    return function (k) {
        return function (b) {
            return function (dlist) {
                var _94 = Data_DList.uncons(dlist);
                if (_94 instanceof Data_Maybe.Nothing) {
                    return Prelude.pure(__dict_Monad_1["__superclass_Prelude.Applicative_0"]())(CNil.value);
                };
                if (_94 instanceof Data_Maybe.Just) {
                    return Prelude[">>="](__dict_Monad_1["__superclass_Prelude.Bind_1"]())(foldrM(__dict_Monad_1)(k)(b)(_94.value0.value1))(k(_94.value0.value0));
                };
                throw new Error("Failed pattern match: " + [ _94.constructor.name ]);
            };
        };
    };
};

@paf31 Good catch. So the trick is to make that foldrM call tail recursive I think.

Sorry for the delay here.
I've switch over to a catenable list implementation for the underlying data structure. I tested with a strict version and lazy version.

Adding laziness was suppose to ideally improve the cost of the linkAll function, but it looks like the overhead is not worth it (given my preliminary benchmarks).
Most of this is coming from Purely Functional Data Structures, section 7.2.1.
What does everyone think? I am inclined to go with the strict version. Seems pretty good in terms of performance. And comparable to the new data structure in the figure. It is more costly in terms of memory than new (I couldn't get it to push 6 million left-binds). In any case, if this works for everyone I will revert to the strict CList and make the other changes as mentioned above:

Add Natural back to Data.Coyoneda (perhaps as an alias for NaturalTransformation)
Rename foldMap to foldFree

Also, any suggestions on names for what I am calling CList and DList? I was thinking potentially CatList or CatenableList for CList. But I am open to ideas for these.

Looks great to me at least :+1:
Re: Natural, having it as Natural in Data.Natural or Data.NaturalTransformation is probably my preference.

Strict version sounds good to me :+1:

I couldn't get it to push 6 million left-binds

How does it fare if you use something like forever? Does it run out of memory, or do things get cleaned up incrementally? (Sorry, I still need to read the paper...)

I've updated the PR to include the strict CatList implementation from purescript-catenable-lists, and made the updates mentioned above.
Updated benchmarks:

@garyb I took your suggestion to keep Natural in Data.NaturalTransformation, adding it as an alias.
@paf31 In running the tests on a large inputs I have to run node with --max_old_space_size=<my computer's maximum about of memory>. Otherwise node segfaults with an out of memory error. So it seems things are not getting cleaned up. I haven't tried forever yet, but image it will yield the out of memory error. I can look into this further though to see if there is a way to avoid this.
Also, I'd like to add a few more benchmarks now that we have the CatList in place. I've benchmarked the operations on CatList separately however using @hdgarrood's great purescript-benchotron package. I'd like to add such benchmarks here too.
Let me know if there are any other additions and/or changes.
Thanks again for taking a look at this.

Ahhh, thank you! :) Just out of interest, how are you generating those graphs? They look much nicer than the ones I managed to generate!

@hdgarrood They are nothing too fancy, just produced from a spreadsheet using libreoffice

Ah, interesting. Thanks :)

@hdgarrood welcome

I think we'd definitely want to be able to support forever without issues. Again, I need to read the paper, but I'd hope the data structure would hover around the same size.

CatList looks fantastic by the way :+1:

@paf31 Thanks! :)
Regarding forever, even with the Free implementation using Gosub (v0.6.0), node would segfault with an out of memory error. I believe I was able to get to just over 3 million left-binds. So using CatList we can double that, but eventually node will run out of memory.
But let me give forever a try to see what happens. Actually, what is the precise test case you have in mind? Is it to build up left-binds using forever? Or something like:
forever $
  make a program
  interpret the program

No, just something like
loop :: forall a. Free TeletypeF a
loop = forever $ writeLine "blah"

using the Teletype example. Then, building and interpreting that should both work, ideally. I'm pretty sure they do now.

@paf31 Gotcha. Running the program now

Oh, one other thing - would you consider moving catenable-lists to the core libraries? I think it would be a great addition in its own right, but generally things in core only depend on other things in core, so that we can be sure they are all in sync and build against the latest compiler.
If you'd rather not, we can figure something else out.

@paf31 I'd be happy to move it over to core. And it looks like bower has an unregister now. So hopefully it would be an easy endpoint switch :)

@paf31 Okay, I've unregistered it from bower. Let me know if I can transfer over the repo. I will reregister it after the transfer.

@ethul Thanks, you should get an invite.

@paf31 Transfer done and registered to bower.

:+1: Thanks!

Welcome!

I've added you as an admin on the free and catenable-lists repos too.

@paf31 Awesome. Thanks!

@paf31 By the way, Forever has been running now for a good amount of time and memory usage has been stable.

:+1: Excellent

Is there anything else that needs doing here? It'd be great to get this in before the new Halogen, as it would simplify a lot of the variations I have in there for Coyoneda.

@garyb I was thinking of add some more benchmarks with purescript-benchotron, but I can bring these in in a separate PR.

I've added the following benchmark images for reference:

Awesome!
Something I meant to ask before, what's the performance like for much smaller numbers of binds? Is there much/any overhead vs the old method? A bit harder to measure I guess due to much greater variability.

@garyb Here are the benchmarks at a smaller scale:

@garyb Note that I will remake these benchmarks with variance once I switch it over to using purescript-benchotron. But let me know if you'd like me to include that switch-over in this PR.

Perfect, thanks for taking the time to do those too. I don't mind whether we include the benchotron stuff or not in this PR :)

@garyb Welcome. Maybe I will save the benchotron changes for a separate PR then.

I'll merge this as it is so I can start using it in Halogen actually via hash-versioning (I have an addition I might propose via PR too). I'll hold off making a release until you're happy with the benchmark situation.

Thanks by the way, this is amazing! :tada:

Great! Thanks for merging. I will send a PR with the benchotron updates.


Adding a function for connection for more attempt / fix #1761

Fix #1761. Forgive for my poor coding ability.

No thanks - if we are going to add a retry facility, we should do it with something like a RetryHandler interface to include support for backoff, jitter, total timeout, etc.
Also, this commit is not production ready - it has no tests, is formated like Python and not Java, etc.


Use selectedValue instead of valueProperty.

Such breaking change :P

@toranb please don't merge this yet, let me do a bunch of things on top of this branch and then we can merge in.

Thanks for the heads up - I'll track along side you on this one

Is this PR still needed/ desirable ? If yes, what can I do to help? If no, can we close it out?

@toranb sorry man, I lost track of this, I think extending for this is better, it worked great for me, I'll try to open source a select-component I built out of this.

@toranb  put it in a gist in the meantime https://gist.github.com/abuiles/3353197ac9e1881bc5af

Also included the template


Tutorial, again, fails and is likely out-dated

As usual, many, if not most, of these tutorials fail; likely, due to being outdated. I followed these tutorials exactly as illustrated, and, yet they still fail.
I am getting a 'stubbed_public_client_application_called' error when running the App: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/errors.md#stubbed_public_client_application_called
The preceding means the files aren't structured correctly.

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

ID: 91f81499-5314-8295-b6fb-f597dc8d7f97
Version Independent ID: 00301f3d-8ec1-619f-2c7d-408592acd3d7
Content: Tutorial: Call an API from a React single-page app - Microsoft identity platform
Content Source: docs/identity-platform/tutorial-single-page-app-react-call-api.md
Service: identity-platform
GitHub Login: @OwenRichards1
Microsoft Alias: owenrichards

Thanks for your feedback! We will investigate and update as appropriate.

Hi,
This is related to this tutorial:
https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-single-page-app-react-call-api
I performed all of the steps, to a T, and the app loads without any issues,
but the following browser (Chrome 123.0.6312.106 (Official Build) (64-bit))
console error appears when clicking on the 'Sign in using Popup' button:
BrowserConfigurationAuthError: stubbed_public_client_application_called:
Stub instance of Public Client Application was called. If using msal-react,
please ensure context is not used without a provider. For more visit:
aka.ms/msaljs/browser-errors http://aka.ms/msaljs/browser-errors    at
createBrowserConfigurationAuthError (chunk-IUUUWHG4.js?v=d94a6890:162:10)
at Object.loginPopup (chunk-V26QY2UY.js?v=d94a6890:1292:27)    at
handleLogin (SignInButton.jsx:17:22)    at onClick
(SignInButton.jsx:33:55)    at Object.current
(chunk-AFCKHMCG.js?v=d94a6890:2185:32)    at
chunk-DJS4V3AL.js?v=d94a6890:996:31    at HTMLUnknownElement.callCallback2
(chunk-XBHG3ID7.js?v=d94a6890:3674:22)    at
Object.invokeGuardedCallbackDev (chunk-XBHG3ID7.js?v=d94a6890:3699:24)
at invokeGuardedCallback (chunk-XBHG3ID7.js?v=d94a6890:3733:39)    at
invokeGuardedCallbackAndCatchFirstError
(chunk-XBHG3ID7.js?v=d94a6890:3736:33)
The calls to the useMsal function do seem to be included within the
context of MsalProvider:
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/errors.md#stubbed_public_client_application_called
Regards,
Mike
On Mon, Apr 8, 2024 at 2:30 AM Owen Richards @.***>
wrote:

HI @MikeyCSharpDude https://github.com/MikeyCSharpDude,
Thanks for the feedback - can you provide some screenshots or
troubleshooting you have performed?
The sample used for this tutorial is working fine on my side, is there any
custom features you have set up?
Please feel free to let me know so I can look into this further for you.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/entra-docs/issues/619#issuecomment-2042285942,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMSE4R4AMMAIPO5OBZXD4LY4JPS7AVCNFSM6AAAAABF3O3UWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGI4DKOJUGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Also There is no "sample" associated with this tutorial: it's created and
completed from scratch. Since you're referring to a "sample" that works for
you, can you please share that sample with me?
Regards,
Michael Gonzalez
On Mon, Apr 8, 2024 at 4:52 AM Mike G. @.***> wrote:

Hi,
This is related to this tutorial:
https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-single-page-app-react-call-api
I performed all of the steps, to a T, and the app loads without any
issues, but the following browser (Chrome 123.0.6312.106 (Official Build)
(64-bit)) console error appears when clicking on the 'Sign in using Popup'
button:
BrowserConfigurationAuthError: stubbed_public_client_application_called:
Stub instance of Public Client Application was called. If using msal-react,
please ensure context is not used without a provider. For more visit:
aka.ms/msaljs/browser-errors http://aka.ms/msaljs/browser-errors    at
createBrowserConfigurationAuthError (chunk-IUUUWHG4.js?v=d94a6890:162:10)
at Object.loginPopup (chunk-V26QY2UY.js?v=d94a6890:1292:27)    at
handleLogin (SignInButton.jsx:17:22)    at onClick
(SignInButton.jsx:33:55)    at Object.current
(chunk-AFCKHMCG.js?v=d94a6890:2185:32)    at
chunk-DJS4V3AL.js?v=d94a6890:996:31    at HTMLUnknownElement.callCallback2
(chunk-XBHG3ID7.js?v=d94a6890:3674:22)    at
Object.invokeGuardedCallbackDev (chunk-XBHG3ID7.js?v=d94a6890:3699:24)
at invokeGuardedCallback (chunk-XBHG3ID7.js?v=d94a6890:3733:39)    at
invokeGuardedCallbackAndCatchFirstError
(chunk-XBHG3ID7.js?v=d94a6890:3736:33)
The calls to the useMsal function do seem to be included within the
context of MsalProvider:
https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/errors.md#stubbed_public_client_application_called
Regards,
Mike
On Mon, Apr 8, 2024 at 2:30 AM Owen Richards @.***>
wrote:

HI @MikeyCSharpDude https://github.com/MikeyCSharpDude,
Thanks for the feedback - can you provide some screenshots or
troubleshooting you have performed?
The sample used for this tutorial is working fine on my side, is there
any custom features you have set up?
Please feel free to let me know so I can look into this further for you.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/entra-docs/issues/619#issuecomment-2042285942,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMSE4R4AMMAIPO5OBZXD4LY4JPS7AVCNFSM6AAAAABF3O3UWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGI4DKOJUGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thanks @MikeyCSharpDude - you have raised some clear issues with this tutorial, which i'll address in a PR this week.
In the meantime, please check out the repo that this tutorial is built on:
https://github.com/Azure-Samples/ms-identity-docs-code-javascript/tree/main/react-spa
I'll keep this issue open, and advise when updates have been made.
Thanks,
Owen.

Great; thanks; much appreciated!
Regards,
Mike
On Mon, Apr 8, 2024 at 5:25 AM Owen Richards @.***>
wrote:

Thanks @MikeyCSharpDude https://github.com/MikeyCSharpDude - you have
raised some clear issues with this tutorial, which i'll address in a PR
this week.
In the meantime, please check out the repo that this tutorial is built on:
https://github.com/Azure-Samples/ms-identity-docs-code-javascript/tree/main/react-spa
I'll keep this issue open, and advise when updates have been made.
Thanks,
Owen.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/entra-docs/issues/619#issuecomment-2042613851,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMSE4XUGOZGDAXQPTQ6Y5LY4KEEBAVCNFSM6AAAAABF3O3UWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGYYTGOBVGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@MikeyCSharpDude
if there are any further questions regarding the documentation, please tag me in your reply and we will be happy to continue the conversation.

So, the repo you provided "that this tutorial is built on" is not the same:
the tutorial I followed uses Visual Studio:
https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-single-page-app-react-prepare-spa?tabs=visual-studio
Do you have the VS-based code?
If not, that's fine. I will use VS Code; although, it would've been nice to
get the VS solution/tutorial working.
Regards,
Mike
On Mon, Apr 8, 2024 at 5:32 AM Mike G. @.***> wrote:

Great; thanks; much appreciated!
Regards,
Mike
On Mon, Apr 8, 2024 at 5:25 AM Owen Richards @.***>
wrote:

Thanks @MikeyCSharpDude https://github.com/MikeyCSharpDude - you have
raised some clear issues with this tutorial, which i'll address in a PR
this week.
In the meantime, please check out the repo that this tutorial is built on:
https://github.com/Azure-Samples/ms-identity-docs-code-javascript/tree/main/react-spa
I'll keep this issue open, and advise when updates have been made.
Thanks,
Owen.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/entra-docs/issues/619#issuecomment-2042613851,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMSE4XUGOZGDAXQPTQ6Y5LY4KEEBAVCNFSM6AAAAABF3O3UWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGYYTGOBVGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

The git repo version of this tutorial worked for me. However, the VS Code
version of the tutorial (on MS Learn) did not work:
https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-single-page-app-react-prepare-spa?tabs=visual-studio-code
I am moving on. Thanks.
Regards,
Mike
On Tue, Apr 9, 2024 at 5:22 AM Mike G. @.***> wrote:

So, the repo you provided "that this tutorial is built on" is not the
same: the tutorial I followed uses Visual Studio:
https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-single-page-app-react-prepare-spa?tabs=visual-studio
Do you have the VS-based code?
If not, that's fine. I will use VS Code; although, it would've been nice
to get the VS solution/tutorial working.
Regards,
Mike
On Mon, Apr 8, 2024 at 5:32 AM Mike G. @.***> wrote:

Great; thanks; much appreciated!
Regards,
Mike
On Mon, Apr 8, 2024 at 5:25 AM Owen Richards @.***>
wrote:

Thanks @MikeyCSharpDude https://github.com/MikeyCSharpDude - you have
raised some clear issues with this tutorial, which i'll address in a PR
this week.
In the meantime, please check out the repo that this tutorial is built
on:
https://github.com/Azure-Samples/ms-identity-docs-code-javascript/tree/main/react-spa
I'll keep this issue open, and advise when updates have been made.
Thanks,
Owen.
—
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/entra-docs/issues/619#issuecomment-2042613851,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMSE4XUGOZGDAXQPTQ6Y5LY4KEEBAVCNFSM6AAAAABF3O3UWWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBSGYYTGOBVGE
.
You are receiving this because you were mentioned.Message ID:
@.***>


[React] Wrong position of nested floating element when open on initial render, react 17, autoUpdate

Noticed a bug when using floating with react 17 and autoUpdate, as in title opening nested floating element that is initially open has wrong position. Looks like those two elements are rendered in same time, as we skip the initial callback of ResizeObserver https://github.com/floating-ui/floating-ui/blob/master/packages/dom/src/autoUpdate.ts#L80 second content is not placed correctly.
I think more bulletproof would be to to remove this initialUpdate optimization and run the callback always as gains are not that significant and elements can change between sync render and update.
Steps to reproduce

click on My button 1
https://codesandbox.io/s/floating-ui-react-dom-template-forked-gbhr85?file=/src/App.js

expected positon

I think that's this issue: https://github.com/floating-ui/floating-ui/issues/1531
I don't think it's related to autoUpdate, rather React's down-up initialization of effects (whereas it needs to be top-down because the parent needs to be positioned first).

I don't think it's related to autoUpdate, rather React's down-up initialization of effects (whereas it needs to be top-down because the parent needs to be positioned first).

hmm thanks will check it, but if we remove the initialUpdate in autoUpdate check in RO callback, it's position correctly 🤔 Just saying that skipping this has not that big impact on performance, or has it?

Oh ok interesting, does removing the check work if there's 3+ nested children?

Oh ok interesting, does removing the check work if there's 3+ nested children?

yes it will, checkout this https://codesandbox.io/s/floating-ui-react-dom-template-forked-e9w54p?file=/src/App.js using custom autoUpdate just wrapping over ResizeObserver and running update for every callback

In case elementResize is disabled or autoUpdate isn't in use, this is also a workaround:
React.useLayoutEffect(() => {
  isOpen && requestAnimationFrame(update);
}, [isOpen, update]);


How to send a my custom object from Parent to content page

I want to send some data object to the content page once the iframe was loaded completely. And also how to receive this object in the content window. How can I do these?

I created a addEventListenner('message') on the contentWindow and got messages passed through postMessages. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Thanks for the reply. I'll try that. If possible can you post the code how can I send from the ParentPage?

You don't need to use the native methods. Their is a simpler option which is explained in the documentation. For personal support you should ask a question on Stack Overflow. This issue tracker is for bug reports etc.


Add kind-dev command to start a kind dev cluster

Description of changes:
Add make kind-dev SERVICE=$SERVICE to setup a cluster for development or debug quickly.
the command will execute the following actions:

create kind cluster
install CRD and RBAC into cluster without controller

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@A-Hilaly   thanks for review,  just see your comments.  the title and description have been updated!

@Julian-Chu Are we ready to ship this?

Just want to double check that this is not gonna break the existing testing rule