Newsletters: add 309 (2024-06-28)

[ ] Lede, releases/RCs, topic entries @harding
[x] Stack Exchange @bitschmidty
[ ] Notable merges @Gustavojfe

@stefanwouldgo

The last paragraph about the comparison to min cost flow probabilities is misleading IMHO (because the OP is): the min cost flow probabilities and the feasibility probabilities are over different and incompatible probability spaces, so comparing them doesn’t really make sense. I think it’s best to just scrap that paragraph.

@renepickhardt

I disagree with @stefanwouldgo: While the probability that a payment is feasible (blue curve) is indeed not the same as the success probability of a single round of MPP attempts (green curve) I think the comparison of these two still makes some sense.

I'll be deleting the clause "Pickhardt [...] compares the likelihood of feasibility to the likelihood of a minimum cost flow solver making a successful payment" but I'm keeping (with some revision) "It also provides a useful basis for comparison."  That removes mention of the specific comparison that seems debatable while still mentioning that it can be useful for making some sort of comparisons, which seems unquestionably true to me.  It also addresses Rene's line comments.

   The likelihood of feasibility makes it clear that many LN payments
   that naively seem possible will not succeed in practice.  It also
-  provides a useful basis for comparison: Pickhardt provides a graph for
-  a simulated network that compares the likelihood of feasibility to the
-  likelihood of a minimum cost flow solver making a successful payment,
-  showing the solver succeeding most of the time a payment is possible.
-  In a [reply][pickhardt feasible2], he also describes how the
+  provides a useful basis for making comparisons.
+  In a [reply][pickhardt feasible2], Pickhardt describes how the
   likelihood metric could be used by wallets and business software to
   automatically make some intelligent decisions on behalf of its users.

Thank you. This seems like a good solution to me. I have added a counterexample to the original discussion (https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/5).

Thank you. This seems like a good solution to me. I have added a counterexample to the original discussion (https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/5).

As laid out in my reply I don't think you provided a counter example:
https://delvingbitcoin.org/t/estimating-likelihood-for-lightning-payments-to-be-in-feasible/973/6

just pushed all the merge summaries for this week's newsletter, left a comment on the 2nd one, Bitcoin Core #28984.

Made edits for all feedback, thanks @LarryRuane @stefanwouldgo @renepickhardt @bitschmidty @azuchi !  Added lede, releases/RCs, and topic entries.  Reviewed contributions by @bitschmidty and @Gustavojfe (thanks so much!).  Thanks everyone!


Refs #25588 -- Fixed GDAL dependency in spatial lookups.

I moved the attempt to convert to raster into a separate method that is only called if GDAL is installed.
Is there a way to create a regression test for this? I don't know how to mock a system that does not have gdal installed.

I don't think any tests are needed. This works besides the test failure reported by Jenkins and a few other issues, at least some of which don't appear to be related to this ticket:
======================================================================
ERROR: test_srid_option (gis_tests.geoapp.test_serializers.GeoJSONSerializerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/sf_django/tests/gis_tests/geoapp/test_serializers.py", line 85, in test_srid_option
    geojson = serializers.serialize('geojson', City.objects.all().order_by('name'), srid=2847)
  File "/media/sf_django/django/core/serializers/__init__.py", line 129, in serialize
    s.serialize(queryset, **options)
  File "/media/sf_django/django/core/serializers/base.py", line 96, in serialize
    self.end_object(obj)
  File "/media/sf_django/django/core/serializers/json.py", line 61, in end_object
    json.dump(self.get_dump_object(obj), self.stream,
  File "/media/sf_django/django/contrib/gis/serializers/geojson.py", line 58, in get_dump_object
    'Unable to convert geometry to SRID %s when GDAL is not installed.' % self.srid
django.core.serializers.base.SerializationError: Unable to convert geometry to SRID 2847 when GDAL is not installed.

======================================================================
ERROR: test06_f_expressions (gis_tests.relatedapp.tests.RelatedGeoModelTest)
Testing F() expressions on GeometryFields.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/media/sf_django/tests/gis_tests/relatedapp/tests.py", line 155, in test06_f_expressions
    c2 = c1.transform(2276, clone=True)
  File "/media/sf_django/django/contrib/gis/geos/geometry.py", line 524, in transform
    raise GEOSException("GDAL library is not available to transform() geometry.")
django.contrib.gis.geos.error.GEOSException: GDAL library is not available to transform() geometry.

======================================================================
FAIL: test_add_raster_field_on_db_without_raster_support (gis_tests.gis_migrations.test_operations.OperationTests)
----------------------------------------------------------------------
django.core.exceptions.ImproperlyConfigured: RasterField requires GDAL.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/media/sf_django/django/test/testcases.py", line 1092, in skip_wrapper
    return test_func(*args, **kwargs)
  File "/media/sf_django/tests/gis_tests/gis_migrations/test_operations.py", line 134, in test_add_raster_field_on_db_without_raster_support
    False, fields.RasterField
  File "/usr/lib/python3.5/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/media/sf_django/django/test/testcases.py", line 604, in _assert_raises_message_cm
    self.assertIn(expected_message, str(cm.exception))
AssertionError: 'Raster fields require backends with raster support.' not found in 'RasterField requires GDAL.'

======================================================================
FAIL: test_create_raster_model_on_db_without_raster_support (gis_tests.gis_migrations.test_operations.OperationTests)
----------------------------------------------------------------------
django.core.exceptions.ImproperlyConfigured: RasterField requires GDAL.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/media/sf_django/django/test/testcases.py", line 1092, in skip_wrapper
    return test_func(*args, **kwargs)
  File "/media/sf_django/tests/gis_tests/gis_migrations/test_operations.py", line 123, in test_create_raster_model_on_db_without_raster_support
    self.set_up_test_model(True)
  File "/usr/lib/python3.5/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/media/sf_django/django/test/testcases.py", line 604, in _assert_raises_message_cm
    self.assertIn(expected_message, str(cm.exception))
AssertionError: 'Raster fields require backends with raster support.' not found in 'RasterField requires GDAL.'

I fixed the test failures from Jenkins, and added @skipUnless(HAS_GDAL) decorators to the two raster support db tests. I suspect these would have failed on a system with PostGIS and without GDAL even before adding the lookups.
The other two tests do not seem to be related to the ticket.


Setting up Active-Hotstandby loadbalancing

Describe the feature request
A way to handle (load balance?) Active-Passive or Active-hot standby configuration
Describe alternatives you've considered
With precedence in RouteRule, it may be easier to achieve by giving higher precedence to active pod and lower ones for standby (while it is not foolproof and I am not 100% sure about this setup).
Since RouteRule was removed in the recent version. How we can achieve it via VirtualService?
Additional context
Envoy proxy very briefly talks about "Passive" connection here
With HAProxy, it is possible to add some annotation and make the switch happen in the gateway itself.
Check here

hi @sendilkumarn, how did you set the active-passive configuration in HAProxy Ingress? I already read the docs, but still not find it. Where did you put the configurations?

@ecojuntak We had used RouteRule with precedence but it is deprecated in the recent releases.


Making senders to use round robin load balancing based on reading sub…

…s from local cache.

this pr addresses https://github.com/romalev/vertx-consul-cluster-manager/issues/49


otOpenUdpSocket Requires Caller to use Internal class Ip6::UdpSocket

Because the Ip6::UdpSocket class now takes a parameter in its constructor (Udp &aUdp), code external from the main openthread library cannot call otOpenUdpSocket with a plain otUdpSocket object. otOpenUdpSocket immediately casts any otUdpSocket passed in to a Ip6::UdpSocket which will result in a null pointer read since the constructor was never called to set mTransport.

Shall we just have OpenThread maintain a fixed number of sockets for the client (with a compile-time configuration parameter)?

In #614, @wbober proposed to initialize the mTransport field as part of otOpenUdpSocket(), which could work as well.  Thoughts?

I'm fine with that approach.

Fixed in #623.


cli: check if 'teardown' is last stage for popper init --stages

Check on the popper init command to see if a user is using the --stages argument while defining
pipeline and is keeping the teardown stage at last.
Return a relevant error message if the convention is not being followed.
 Consider renaming it or putting it at the end.

Should this error cause an exit, or should it just give a warning and continue?


Create wireframes for prime admin request access

Describe the task
We need to create a new wireframe workflow that breaks down the process of requesting access as a prime admin. Users cannot edit Operator Information without being granted access into the system first, and so, they can add or edit operator information only when they are in OBPS.
Acceptance Criteria

[x] Created proposed wireframes
[x] Review with business area specifically for what fields should be added in for granting request
[x] Iterate wireframes

Additional context

Add any other context about the task here.
Or here

@hannavovk - ticket created here!

Completed, Figma updated accordingly. Good to be closed @hannavovk


Utilize Docker Socket/TCP API Instead of Local Binary

Currently, lazydocker supports only local docker management by directly interacting with the locally installed docker CLI binary. This also means, running it inside a container (as per #36) would require packaging the CLI binary in it. By utilizing the HTTP API exposed by the Docker the tool can easily be configured to work with both local and remote Docker instances.

Some initial thoughts on this:

When you say use the HTTP API, what are you referring to? Do you mean that we'll be sending HTTP requests from within lazydocker to the api? Or do you mean we'll be making use of the docker client go package? Or something else?

Using the docker CLI supports easy customisation. Right now if somebody wants to stop the logs from only going back an hour they just override the command template by removing the --since=60m like so:

commandTemplates:
  containerLogs: docker logs --follow {{ .Container.ID }}

How would a user go about customising these things if everything went through the api?

Is there anything that the CLI can do that the api cannot? I have used the docker client go package in a few places, however if I recall correctly there were some instances using that I could not get the same functionality as I could from the CLI command. (Worth noting I may be recalling incorrectly here)

If we could get this to work in a way where the user still has the same amount of configurability, I'd be all for it, but if not, I think packaging the binary may be the better solution. What are your thoughts?

I used HTTP API in a broader sense here, but I meant using the Docker SDK which is nothing but a wrapper in various languages around the HTTP API exposed by the TCP/Unix Socket. Docker CLI itself uses the same API underneath to talk to the Docker engine/daemon, so theoretically everything that the CLI can do should be possible using the API and perhaps some additional local request/response handling.
As far as --since is concerned, the HTTP API certainly has a parameter for that and other means to filter the log. Also, the Go SDK seems to have container log options too.

I suppose in that case my only remaining concern is that things are going to get much more complicated both for contributors and for users who want to configure things. Instead of just swapping out a command template with one the user already used on the command line, they'll now need to deal with the schema of the SDK in order to make changes, and we'll need to write the code that parses the config values and sends them to the SDK

also to confirm, is there any benefit to making the switch here beyond reducing the size of the docker container thanks to not having to include the docker binary?

Well, technically it is possible to call the CLI binary with any Docker daemon host (default is local socket) as it is now, by modifying command templates. However, I personally do not think it is the most user friendly way to use this tool. Command templates are global in nature, but one might want to apply different choices per container. Having good defaults, taking control of config parsing (instead of making users know CLI commands) and applying them on the fly would make this tool much more friendly. I would envision more features added to this on top of what is returned from the engine. For example, applying local filters on the buffer of various outputs (so that I can type anything to live filter only matching rows in logs/container/images/volumes/or anything for that matter) or choosing from a given set of options to apply on only one instance of the command (so that I can stream live logs of one container, but have a time boundary for another). I see this tool as [Portainer]9https://www.portainer.io/) for the terminal.

also to confirm, is there any benefit to making the switch here beyond reducing the size of the docker container thanks to not having to include the docker binary?

I am not too keen to reduce the size of the Docker image really (though it is a plus). Taking control of options eliminates the need for users to know every flag of docker CLI (though it comes with more work for this tool). I believe this tool can do a lot more without switching the context and without relying on a static set of command templates to run.

I just did a scan of our current docker CLI uses and luckily we've only got two that are currently exposed to the user config:
			ContainerLogs:            "docker logs --timestamps --follow --since=60m {{ .Container.ID }}",
			ViewContainerLogs:        "docker logs --timestamps --follow --since=60m {{ .Container.ID }}",

The other ones all look like it wouldn't be too hard to swap them out for the client, however:

Would you agree that the docker-compose commands should remain as-is? I haven't customised any of the docker commands on my end but I indeed have customised my docker-compose commands, in fact my workplace uses its own program in place of docker-compose which only has a CLI interface. It might be a bit awkward as a user to have direct CLI command templates for docker-compose but specific flags for docker (though I don't really have an issue with it)

I now recall the things I found hard via the SDK:
a) docker attach. If I recall correctly, with the SDK's docker attach you can access the stdout of a container, but not the stdin. I think we would need to solve this problem in order to make the switch to the SDK (though I think everything else is simple enough to change)
b) docker stats. I currently have this:

func (c *DockerCommand) MonitorContainerStats() {
	go c.MonitorCLIContainerStats()
	go c.MonitorClientContainerStats()
}

Because the stats returned from the two are different. It may be that if we dug into it deeper we could get everything we need from the SDK but we'd need to investigate

Regarding point 2a, I think I could try to do it. Since I've already made something similar here. Granted it is ExecAttach, not Attach, but it seems to be almost the same.

@dawidd6 sounds good :)

@jesseduffield
About docker attach you can reference this.
https://github.com/skanehira/docui/blob/master/docker/container.go#L186
About docker stats you can reference this.
https://sourcegraph.com/github.com/docker/cli/-/blob/cli/command/container/stats_helpers.go#L53
Also I developed docker.vim and that collect cpu/mem percent using api.
https://github.com/skanehira/docker.vim/blob/master/autoload/docker/monitor.vim#L89
If you want to know collect logic please reference this.
https://www.datadoghq.com/blog/how-to-collect-docker-metrics/
I hope lazydocker becomes better OSS :)

@skanehira thanks for those links!


Feature: import from JSON

Similar to CSV import.

Done by https://github.com/hangxie/parquet-tools/pull/68


Add the "interface" method to get public IP

Some ISPs do NAT on the way to public IP discovery services like icanhazip.com.
This MR adds a new method to get public IP, which is to get it from IP of primary interface directly.

Hey, thanks for your contribution.
So if I understand, it'll work for devices which are not behind a NAT?

Yes. I have a globally routable IPv4 address on my router. But my ISP is really bad. There is NAT on the way to some websites, including icanhazip.com. I can't get correct IP with them.


OpenJS Foundation Security Collab Space Meeting 2024-09-09

Time
US PDT Mon 09-September-2024 08:30 AM
Or in your local time:

https://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Security+Collab+Space+Meeting&iso=20240909T0830&p1=224
or https://www.wolframalpha.com/input?i=8:30am+PDT+Sepember+09+2024+in+local+time

Links

Minutes Google Doc: https://docs.google.com/document/d/1evmPmlOqALy82ka89dtH2UJhNfes3WUHj2qYtG9_8zA/edit

Agenda

https://github.com/openjs-foundation/security-collab-space/discussions/104
https://github.com/openjs-foundation/security-collab-space/issues/230
https://github.com/openjs-foundation/security-collab-space/issues/177

Invited

OpenJS Foundation Security Collab Space Members
OpenJS Foundation Cross Project Council
OpenJS Foundation Project Maintainers
OpenJS Foundation Board of Directors
All are welcome

Observers/Guests
Notes
Joining the meeting
Meeting link for participants:  https://zoom-lfx.platform.linuxfoundation.org/meeting/98301969246?password=889b7578-29b6-4be9-96c1-f74cbce812c4

For those who just want to watch: https://livestream.openjsf.org

Invitees
Please use the following emoji reactions in this post to indicate your
availability.

:+1: - Attending
:-1: - Not attending
:confused: - Not sure yet

Next Steps (also captured in https://github.com/openjs-foundation/security-collab-space/discussions/104)
@rginn: wrt EMCAScript in CNA Scope talk to OpenJS Legal
@ctcpip: wrt EMCAScript, assuming CNA Legal approves, get topic on agenda for ECMAScript meetings in early October
@ruddermann: coordinate with nodejs to deprecate the Node.js CNA
@ruddermann: create task+document next steps on cna@ and security@ mailing lists
@ruddermann create task+document next steps on creating security advisories Github page
@ruddermann: create task+document on documenting CNA processes (eg: publishing CVEs, how projects engage with us)
@ruddermann: coordinate public comms with @rginn and Jen Shelby


Views

Add the 'View' portion of the MVC model.
Use handlebars for each page: login, signup, dashboard, tickets, user setting, manage users...etc.
Use partials layout to handle multiple comments and tickets.

Views section template completed. Close broad/general issue. New issues to be more specific.

Views section template completed. Close broad/general issue. New issues to be more specific.


tiny wording improvement in "Can I be identified as COVID-19-positive…

… by network traffic monitoring"
Hi, people might get worried by the words "false notifications",
so my addition mentions that they have no consequences on the server side.
The diff is a bit difficult to grasp first sight, I added:
... and sending false notifications that will be discarded on the server side.
and
... and upload of real infection data cannot be distinguished from this background noise.
Yours, Steffen

Good point, thanks very much!


fixed example

The example was missing the module itself
I have added it to the example

i just ran your pre-commit hook...
- hook id: terraform_docs
- files were modified by this hook```
that is why the readme has changed

I have a look. Seems like new pre-commit version works differently


pip install -e '.[api]' fails - Installation/setup instructions are confusing

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/111
Originally created by @MadLittleMods on 2018-10-04 17:12:41

The installation/setup instructions are confusing.
The docs https://gitlab.com/meltano/meltano#local-environment seem to be conflicting/duplication with https://gitlab.com/meltano/meltano#with-docker
Windows
I am trying to setup Meltano on Windows 10 with python 3.6 and pip 18
I saw https://gitlab.com/meltano/meltano#local-environment first and tried the following,
$ pipenv install --skip-lock
$ pipenv shell

Then saw https://gitlab.com/meltano/meltano#without-docker and tried,
Because the previous command, created a virtualenv, I figured I could skip the first part (python -m virtualenv ~/path/to/melt_venv, source ~/path/to/melt_venv/bin/activate)
$ pip install -e '.[api]'
'.[api]' should either be a path to a local project or a VCS url beginning with svn+, git+, hg+, or bzr+

What am I missing? Perhaps running make which is only mentioned in the Docker section above (and isn't Windows friendly)
Which instructions should I be following? I want a local setup
Perhaps I just have to wait for https://gitlab.com/meltano/meltano/issues/87

View 21 previous comments from the original issue on GitLab


Planning hangs

how to recreate:
plan -> success
provision -> success
deploy -> success
refresh -> success
plan -> hangs

No activity


MAISTRA-2169 Show Projects instead of Namespaces in ServiceMeshMember form

This is a cherry-pick of #685

/test unit

/test istio-operator_unittests


WIP: Add the glance serverspec

Dependent on PR #1554

Can one of the admins verify this patch?

"ok to test" to accept this pull request for testing
"test this please" for a one time test run
"add to whitelist" to add the author to the whitelist

ok to test


Named colors

Some of the wrapped graphics APIs have concept of named colors (eg. NSColor on macOS). These could be system colors (eg. window background, border color) or custom catalog colors. Converting them to the internal Color type however loses their lazy resolution to actual RGB value (eg. the named color can have different color based on system wide dark mode / light mode). Is there any plan to expose this functionality? Even System.Drawing had it in some limited form.

Related discussion, which may make this issue obsolete: https://github.com/dotnet/runtime/issues/32418

Even System.Drawing had it in some limited form.

This is a huge wart in System.Drawing.Color that needs correction. Adding something like names to the Color type causes ineffiency and complex interdependencies.
Maui (not Maui.Graphics) could have functions like getBorderColor:unit -> Color etc. or even tryGetColorFromOSNamedColor(name:string):Color?. That would allow users to get these colors without adding complexity to the Color type.

@charlesroddie I think there's quite a distinction between color manipulation type and abstract color description type. System.Drawing.Color tried to do both at the same time and lacked a bit on both.
Just like R,G,B is only describing a color when interpreted in a specific color space (eg. sRGB, Adobe RGB), named colors are also meaningful only within their respective color space (eg. dark theme, light theme).
This library specifically states the goal of abstraction over native graphics libraries for drawing. CoreGraphics has concept of named colors (extensible), Windows has concept of named colors (albeit limited).

Understood. I see several problems:

Unless this is specced out to guarantee a clear separation of the types, there is a strong risk that it will be done in some terrible complex interconnected way. Especially because the name of this repo now has "Maui" in it and Maui is what was Xamarin and Xamarin would definitely do it that way.
To justify putting this in the repo, all targets would need to support names (which I believe they don't) and not only that but the same names.
How could you write a test for consistent rendering across platforms if some settings (e.g. dark mode) could cause platforms to render things differently at different times?

Unless this is specced out to guarantee a clear separation of the types, there is a strong risk that it will be done in some terrible complex interconnected way.

I intentionally omitted the API shape because of this. Thanks for raising it as a concern which I agree is a valid one.

To justify putting this in the repo, all targets would need to support names (which I believe they don't) and not only that but the same names.

I don't think that is necessarily a requirement but most, if not all, of the targets have the concept. I checked it exists on macOS, iOS, Android and to some extent on Windows.
For me it's important that there is a way to express it at all even if at some point there is a platform specific way to create the named color. To put this into context. Suppose I care only about iOS and Android and I maintain my own color catalogue (ie. some XML/Plist that is embedded in the app and maps my own names to colors). Then I want to be able to use these colors for a custom drawn control in Maui but with late binding of the actual values at the graphics layer (since the OS usually knows the system settings and can choose some variation of the color catalogue). I could think of many other use cases where it's just matter of being able to pass an existing named color through some layer implemented through Microsoft.Maui.Graphics.
Actually unifying the names may be difficult or even impossible (even though the system color set has huge overlap between different OSes). I consider acquiring the system colors by name a separate issue from being able to pass them through the layer.

How could you write a test for consistent rendering across platforms if some settings (e.g. dark mode) could cause platforms to render things differently at different times?

I think the question comes from the assumption that I would use Maui.Graphics along with the custom controls to get consistent rendering across platforms. While that may be one of the reasons why the library exists it's certainly not the only use case. I want to share code across platforms for things like rendering avatar icons with borders (simplest example I could think of) but set the border to the color of native borders of the platform.


fix(curriculum): update challenge to heading tags instead of headers

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the main branch of freeCodeCamp.
[x] I have tested these changes either locally on my machine, or GitPod.

Closes #43427

Hey @Anurag5086,
I mentioned you in the linked issue, as for now, I will put the blocked label on it.

Hey @Anurag5086,
I mentioned you in the linked issue, as for now, I will put the blocked label on it.

Sure! Sounds good!

You will want to read about how to change the title of a challenge:
https://contribute.freecodecamp.org/#/curriculum-file-structure

Also, please, if you are not doing the whole list of challenges to change but only part of it, say so

@ieahleen I have made changes in the English language, what should i do about the other languages?

please follow the steps here on how to rename a challenge: https://contribute.freecodecamp.org/#/curriculum-file-structure

I have followed the steps given here. I hope I did them as expected.

good for the renaming of the challenges you did until now
will you do also all the other challenges on the list?

@ieahleen I have made changes for other challenges as well.

@ieahleen I have a doubt in this file - /curriculum/challenges/english/03-front-end-development-libraries/sass/store-data-with-sass-variables.md
Not sure what changes should I make here.

Not sure why I'm getting a failed test here.

Not sure why I'm getting a failed test here.

That's likely due to changed file name for the English language, but still having previous file name in other languages. Other languages need to have file name changed as well.

@ieahleen I have a doubt in this file - /curriculum/challenges/english/03-front-end-development-libraries/sass/store-data-with-sass-variables.md

the seed and solution refer to an h2 element as an header, it is not used in the tests so it should be trivial to change

@ieahleen I have a doubt in this file - /curriculum/challenges/english/03-front-end-development-libraries/sass/store-data-with-sass-variables.md

the seed and solution refer to an h2 element as an header, it is not used in the tests so it should be trivial to change

Okay, thanks! :)

@ieahleen Can you guide me through, what needs to be done now?

wait for it to be reviewed, and then redirects will be need to be set up for the challenge with the changed title

wait for it to be reviewed, and then redirects will be need to be set up for the challenge with the changed title

Sure, thanks! 👍

Hey @raisedadead,
Can you help @ieahleen and @Anurag5086 on what needs to be done with the redirects?
Thanks

You would need to add redirects to this file: https://github.com/freeCodeCamp/client-config/blob/master/serve.json
This is not ideal but will do.

@raisedadead I see,
Though only the titles are changed of the challenges.

@Sembauke changing the title means changing file name and dashed name, so the url to the challenge changes

I would like to see what @ojeytonwilliams thinks, but I am currently not keen on adding redirects to the serve config. We could do a one-off Nginx based redirection for broken links.

I would like to see what @ojeytonwilliams thinks, but I am currently not keen on adding redirects to the serve config. We could do a one-off Nginx based redirection for broken links.

Neither solution is great, but I slightly prefer modifying serve.json. That approach means we only need to adjust one file and all languages get the redirects.  If we go the NGINX route we have to duplicate the redirects for each language.

If you are only concerned about code duplication, NGINX does have "include" statements for modularity. Logically, serve is a worse place, to be honest. I think we should redirect early.

@raisedadead we've discussed this a bit before: https://github.com/freeCodeCamp/freeCodeCamp/pull/42596#issuecomment-875579093
The TL;DR was we considered NGINX, routing inside the app and a separate redirection 'layer' (i.e. serve).  The conclusion was that the order of preference was app routing > serve > NGINX, but we tried to get Gatsby to handle the redirects and failed.
Unless you've changed your mind about this, I'm fine with continuing to use serve until either Gatsby changes or we migrate to something else that allows us to handle the redirection in the app.  What do you reckon?

The context here is this change is going to break backlinks shared outside of "the app", i.e the forum, etc. I would recommend redirecting those early.

@raisedadead unless I'm missing something, this is essentially the same problem that we've faced before, so the same solutions should work.
To break it down, I'd recommend the following

Create a Cypress test to verify that the redirects work.  Something like this: https://github.com/freeCodeCamp/freeCodeCamp/pull/43133/commits/728ae64f2ed56c3f3252f17b7c5c508fdf0f6a43
Create a PR to client-config to change serve.json. Like this: https://github.com/freeCodeCamp/client-config/pull/5

Once the client-config changes are in, the Cypress tests should pass and we can deploy.

Sure.

Just opened a PR to handle the redirect for the challenge title that's being changed here. I think the only thing we're missing now are tests to verify that the redirect is working.
@Anurag5086, could you add a test similar to this?: https://github.com/freeCodeCamp/freeCodeCamp/commit/728ae64f2ed56c3f3252f17b7c5c508fdf0f6a43
If not, I could go in, add a test, and push it to your PR here.


[th/gitignore] ignore ctags' tags file and various spellings for the *venv*/ directory

ctags is useful (at least to me, or anybody who likes to use this tool). It leaves a tags file behind, that I'd like not to see in git status. Ignore /tags file.
allow for various venv directories, not only ocp-venv/. Instead, ignore /*venv*/. This allows to create different venvs for different python versions. Also, on other python projects, I tend to call the venv directory ./venv (because they are not strictly ocp related). I'd like to use the same directory everywhere and don't see it in git status, as that is what I am used to.

In general, ignoring files that are not relevant for one or the other user (or even the majority of users), tends to be a non-issue. It would only be an issue if tomorrow a user wants to add a file "/tags" or "/*venv*/". But even then, they still can do git add -f FILE, and once it's tracked by git, the gitignore no longer matters. That makes it a non-problem to ignore files somewhat eagerly.

ctags is used by you. For that reason, please use git config --global core.excludesfile. Other commit lgtm.


Develop COMPILER TOOLSET API for local

Let's develop COMPILER TOOLSET API for local.
Plan

4/11 discussion
4/15 done to design/draft(impl+test)
4/22 Completed

the discussion means that we need to discuss whether the rough(naive) plan is right or wrong.

Tasks & Assignees

UI: @jyoungyun
API: @YongseopKim
Backend:  @hyunsik-yoon

4/15 done to design/draft(impl+test)
4/22 Completed

Regarding implementation, I wonder the scope of this work.
Until 4/22, what function/method should we implement?
My guess is that basic goal is to enable these.

list installed toolchains
compile

and others are stretch goal (until 4/22).
Please let me know if we need to implement more.

Requirement from UI
install

Get available(but not installed) package list
Request to install package with some id(?) from package list

search for installed package

Get installed package list with information

backend name
version
type(debian or docker image)
installed date
official(or nightly)
some id(?)

Get dependency package information with some id(?)

dependency packages name with version

https://github.com/Samsung/ONE-vscode/issues/569 will replace this issue.


Duplicate on incremental refresh page

The paragraph about "There's no requirement the final query support folding...." is repeated on this page
[Enter feedback here]

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

ID: 23849d95-194e-b2b1-735a-03aebb56703a
Version Independent ID: 391f63a3-2b18-3676-a151-d9859df54ad6
Content: Incremental refresh for datasets and real-time data in Power BI - Power BI
Content Source: powerbi-docs/connect-data/incremental-refresh-overview.md
Service: powerbi
Sub-service: pbi-data-sources
GitHub Login: @Minewiskan
Microsoft Alias: owend

@elaynejones - Thanks for letting us know!  The updated page will appear later today.


Remove DR jobs of AWS platform and add jobs for GCP

Remove DR jobs of AWS platform and add new jobs for GCP platform.

/lgtm

/hold
@wangke19 will add new informing job for arm64

/unhold

/lgtm
/approve


Update k8s registry reference

What's this PR for?
For #142
What's new in this PR?
Per https://github.com/kubernetes/k8s.io/issues/4780, Kubernetes is migrating its image registry to registry.k8s.io, and this repository is impacted.
This PR update the references of k8s.gcr.io to registry.k8s.io.

@yaron2 can you PTAL?


Import from filesystem dialog is hard to use.

Godot version
2f57a11ed9b383706b72783c0d9b1e869774e08a
System information
Windows 11, Nvidia 3000 series, Vulkan
Issue description

deactivating it solves the animation, the weird thing is that I never used the importer because it would close godot and let it import only by copying the folder

People have mentioned that it's odd that double clicking on the glb will have the advanced import dialog. My expectation is something like default to instance or default to inherit (not three choices).
Steps to reproduce

Open godot 4
Hover the filesystem
Select the .glb
Double click
Issue is here

Minimal reproduction project
Busy, but the idea is to create a new project and then add a glb like https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/2.0/Fox/glTF-Binary/Fox.glb

By the way, yes, I did not understand how to use it. I just created an empty scene, dragged my gltf file there, then copied it to another scene and from there saved the objects into separate scenes (for multiple use).
Maybe there are easier options?


"setup.bash" didin't work correctly

To do

remove unnecessary part

@Mt-is-at-O Is it possible to change ssh -> https rather than removing the essential packages?


Update avocode to 2.14.5

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[ ] If the sha256 changed but the version didn’t,
provide public confirmation by the developer: {{link}}

Thank you for the contribution. It was merged directly as 168c5174bcdb166ac11fcd1b0054916376acab7b. Your contribution is still credited to you.


feat: Enable Twitter API Function Calls for Social Media Interactions

Description
This PR introduces a new API function along with a suite of test cases to ensure its functionality. It significantly enhances the CAMEL project by enabling access to the Twitter API. https://github.com/camel-ai/camel/issues/57 https://github.com/camel-ai/camel/issues/500
The update facilitates functionalities for an authenticated user to create and delete tweets, and to retrieve user information.
To leverage these new features, obtaining two API keys from Twitter is necessary. Contributors and users aiming to utilize this functionality must:

Generate Twitter consumer key and consumer secret in the Projects & Apps section under the Keys and Tokens tab at https://developer.twitter.com/en/portal/products/free.

Securely store the keys in the environment variables as TWITTER_CONSUMER_KEY and TWITTER_CONSUMER_SECRET. It's crucial for the security and privacy of your API key. Avoid hardcoding the keys directly into the codebase.

Ensure TWITTER_CONSUMER_KEY and TWITTER_CONSUMER_SECRET are correctly set up in the environment before running the application. Mismanagement of the API key could result in errors.
Motivation and Context
Before this update, the agent lacked the capability to access and interact with Twitter. The introduction of create_tweet, delete_tweet, and get_user_me functions allows the Agent to utilize the functionalities of the Twitter free API, integrating them within the CAMEL framework. Specifically,

create_tweet function: Enables an authenticated user to post a text tweet, publish a tweet with a poll using poll_options and poll_duration_minutes parameters, or reference another tweet via the quote_tweet_id parameter when tweeting.

delete_tweet function: Allows for the deletion of a specified tweet by an authenticated user.

get_user_me function: Retrieves personal information of the authenticated user, including details of pinned tweets.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds core functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (update in the documentation)
[x] Example (update in the folder of example)

Checklist

[x] I have read the CONTRIBUTION guide. (required)
[ ] My change requires a change to the documentation.
[x] I have updated the tests accordingly. (required for a bug fix or a new feature)
[ ] I have updated the documentation accordingly.

Summary by CodeRabbit

New Features

Introduced Twitter integration for creating, deleting tweets, and fetching user profile information.
Added support for OAuth authentication with Twitter.

Documentation

Updated user prompts to include Twitter functionalities.

Tests

Added tests for Twitter API interactions.

Chores

Included requests_oauthlib as a dependency for improved Twitter API interaction.

@coderabbitai review

@yiyiyi0817 Hi, I have seem you merged it, so have you resolved all the conversation? If yes, please click "Resolve conversation" each time to avoid misunderstand. Thanks. Just a tip.

@yiyiyi0817 Hi, I have seem you merged it, so have you resolved all the conversation? If yes, please click "Resolve conversation" each time to avoid misunderstand. Thanks. Just a tip.

OK, Thanks for your tip.


not allowing removal of images after the run

Pull Request Test Coverage Report for Build 910

0 of 0   changed or added relevant lines in 0 files are covered.
48 unchanged lines in 14 files lost coverage.
Overall coverage decreased (-0.006%) to 87.414%

Files with Coverage Reduction
New Missed Lines
%

datmo/cli/command/base.py
1
92.96%

datmo/snapshot.py
1
83.49%

datmo/core/controller/file/driver/local.py
2
91.92%

datmo/cli/command/datmo_command.py
2
100.0%

datmo/core/util/i18n.py
2
100.0%

datmo/cli/command/run.py
2
81.5%

datmo/core/controller/code/driver/file.py
2
93.99%

datmo/cli/command/snapshot.py
2
100.0%

datmo/cli/command/session.py
2
95.7%

datmo/core/util/json_store.py
6
84.62%

Totals

Change from base Build 905:
-0.006%

Covered Lines:
3917

Relevant Lines:
4481

💛  - Coveralls


Please fix our node.js logging

Now that Winston is integrated into story 0.0 we need to get all console.log statements replaced with appropriate log statements at appropriate levels. I would suggest the following:
info - This is really just for debugging. People should feel very comfortable throwing these around.
Warning - Something bad happened but we can recover.
Error - Game over.
Please split this work between yourself and Sreejumon.

This will be a check in requirement for all the new code so this should (famous last words) fix itself.


xptracker: add "reset paused" menu entry

Allows players to reset their paused skills only, removing skills that they are no longer working on without resetting the skills still being trained. Useful for reducing clutter when you forget to reset the panel between activities.

Stale, undesirable


Reference to undefined pattern comment

I tried converting http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd to rnc using this stylesheet and then trang. However, when I tried to use the .rnc file in nxml-mode in emacs, it said: nxml-display-file-parse-error: Reference to undefined pattern comment.
My XSD is a bit rusty but it looks to me like comment is defined in the .xsd file, but is not defined in the .rng or .rnc files.

I managed to workaround this by specifying the start parameter.

I was able to get this schema to work first by applying greenrd's sed script to the xsd file, renaming it with 'mod', then using
xsltproc --stringparam start databaseChangeLog XSDtoRNG.xsl dbchangelog-3.1.mod.xsd > dbchangelog-3.1.rng.  I then converted it to rnc with trang.


Give removeUndefinedProps an explicit type

Looks like static analysis is failing in one spot? https://github.com/manifoldmarkets/manifold/runs/6681379906?check_suite_focus=true

I am a Typescript beginner, but this seems very wrong to me.
Here is an example that fails:
type FooContract = { id: string, resolution: number | undefined }
let foo: FooContract = { id: "abc", resolution: undefined }

// type of cleanedFoo is { id: string, resolution: number } which is obviously wrong
let cleanedFoo = removeUndefinedProps(foo)

// blows up at runtime
console.log(`Resolution: ${cleanedFoo.resolution.toString()}`)

Generally speaking, I think the existing implementation of removeUndefinedProps is almost correct. The only part that seems wrong to me is that it's conflating e.g. T | undefined with T? -- removeUndefinedProps is guaranteed to actually delete any undefined properties, so it's like it's converting their type from T | undefined to T?.
It's not going to be possible to express "removing the undefined properties" in more detail in the Typescript type system, because Typescript basically doesn't know at compile time whether any given T | undefined property is going to be T or undefined, so it's not going to know at compile time whether any given property is going to be removed.


Sender Public-Facing Content Outline - Research/Investigation

This task is connected to Issue #2393

Problem statement
Outline sender focused content based on current comms from Mike C. Will be published on the website.
What you need to know
[Links to documents, workflows, or list of key people and contact info]
Currently have:

Welcome email (see Email Template from #2393)
One pager (see PRIME 1-pager)

Acceptance criteria
We have:

[ ] An outline of index content changes
[ ] Outline sender "how it works" section"

To do
Research/investigation

[ ] What does a user need to know to get started with us?

How can we save you time?

What does this mean for your location/lab/staff/etc?

What does this cost me? How is this free?

[ ] What can we publish that helps reduce meetings or other back and forth?

Things to look at later:
What changes do we need to make to the website:

[ ]  Index content (need to re-work)
[ ]  Split Sender/Reciever in "How it works"
[ ]  Sender content section w/sidebar
[ ]  Quick start?

Future state?

[ ]  Guides/tutorials/videos?
[ ]  FAQs?

11.15.2021 Sent @drew-usds @inkandsound suggested content revisions for RS web copy via Sharepoint docs here. Will discuss in Design sync.

12.3.2021 Should have outline ready and uploaded here before Sprint end.

12.7.2021 Completed outline of proposed revisions to RS website content infrastructure (See PPT here). Since there is more content to build out, let's either add this again to the next sprint or create a new issue with a similar AC. We can discuss at sprint planning. @loripusey @rachelhanster @HeatherRienks @drew-usds

Issue is now closed!
FYI: Created new Issue # 3348 to break up this large task. Here are the To Do's that will go into the new issue for Sprint 31:
Things to look at later:
What changes do we need to make to the website:

[x]  Index content (need to re-work)
[x]  Split Sender/Reciever in "How it works"
[ ]  Sender content section w/sidebar
[ ]  Quick start?

Future state?

[ ]  Guides/tutorials/videos?
[ ]  FAQs?


Performance: Remove render-blocking JavaScript

If you have JavaScript at the top of your page, the browser isn't allowed to display anything until after it has finished downloading your JavaScript files.
Ideally, you should make it so that the page will render once the HTML and CSS are done loading, without having to wait for JavaScript. This is worth doing even if you don't have server-side rendering set up. If you do have server-side rendering set up, render-blocking JavaScript makes it so that nobody ever sees the server-rendered content.
There are a few ways to fix this. For details, see: https://developers.google.com/speed/docs/insights/BlockingJS
The offending files are:
https://widget.cloudinary.com/global/all.js
https://www.lesserwrong.com/…8e5f0e6100439.js?meteor_js_resource=true

Discovered using: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.lesserwrong.com%2F&tab=desktop

This should now be fixed, if I am not horribly confused. I am definitely seeing the HTML render before the full javascript package loads, so I am not sure about the second link (which is the link to the complete javascript package).


Split cvat/apps/iam/permissions.py into per-app permissions modules

Motivation and context

This improves the dependency graph of apps with regards to IAM and other apps. IAM is a generic app, so it should not depend on specific apps, like webhooks.
It's also easier to work with a bunch of smaller files rather than one giant one.
Having permissions classes in separate modules introduces the risk that they will never be loaded directly. To mitigate that, add a function to ensure permissions are loaded and call it from every app.
How has this been tested?

I made sure that OpenPolicyAgentPermission.__subclasses__() returns all permission classes.
Checklist

[x] I submit my changes into the develop branch
[ ] I have created a changelog fragment
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (see GitHub docs)
[ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

/check


Getting few fields undefined in user data object after login successful using redux-oidc

Below fields are getting undefined
expires_at
session_state
expired
expires_in
scope
scopes
I tried below 2 type of configuration

const userManagerConfig = {
client_id: 'client_id',
redirect_uri: ${origin}/callback,
response_type: 'token id_token',
scope: 'openid profile expires_at',
authority: 'http://localhost:3001/api/v1/system/',
filterProtocolClaims: true,
loadUserInfo: true,
metadata: {
issuer: ${AUTHENTICATIONSRV_URL},
jwks_uri: ${AUTHENTICATIONSRV_URL}/openid-configuration/keys,
userinfo_endpoint : ${AUTHENTICATIONSRV_URL}/userinfo,
authorization_endpoint: ${AUTHENTICATIONSRV_URL}/oauth
},
signingKeys: signingKeys
}

const userManagerConfig = {
client_id: 'client_id',
redirect_uri: ${origin}/callback,
response_type: 'token id_token',
scope: 'openid profile expires_at',
authority: 'http://localhost:3001/api/v1/system/',
filterProtocolClaims: true,
loadUserInfo: true
}
If anyone already fixed this issues please share the solution.

Your config looks fine, maybe this is related to your authentication server?

Closing this for now. Feel free to comment if your issue persists.

I have the same issue. This is my config:
const userManagerConfig = {
  authority: process.env.AUTHORITY_URL,    // The URL of the OIDC provider
  client_id: 'testClient',                 // Application's identifier registered in YaraSSO
  redirect_uri: redirectUri,               // The redirect URI to receive response (e.g token) from YaraSSO
  response_type: 'id_token token',         // The type of response desired from the YaraSSO
  scope: 'openid profile email',           // The scope being requested from the YaraSSO
  silent_redirect_uri: silentRedirectUri,  // URI for token refreshing
  post_logout_redirect_uri: postLogoutUri, // URI to redirect after log out
  automaticSilentRenew: true,              // Automatic attempt to renew token
  filterProtocolClaims: true,              // Should OIDC protocol claims be removed from profile
  loadUserInfo: true,                      // Additional identity data for the profile
};

And this is how I get user:
userManager.signinSilent()
      .then((result) => {
        // log the result if successfully obtained a token
        console.log('Succesfully obtained user', result)
      })
      ...

Result has scope, state values as undefined

@MangeshGawai  do you have any clue where the problem can lie on the server side?


ARROW-3409: [C++] Streaming compression and decompression interfaces

@fsaintjacques Thanks for posting your comments. I've now addressed them.

LGTM

Codecov Report

Merging #2696 into master will increase coverage by 0.83%.
The diff coverage is 85.43%.

@@            Coverage Diff             @@
##           master    #2696      +/-   ##
==========================================
+ Coverage   87.65%   88.48%   +0.83%
==========================================
  Files         403      341      -62
  Lines       61483    58247    -3236
==========================================
- Hits        53891    51540    -2351
+ Misses       7520     6707     -813
+ Partials       72        0      -72

Impacted Files
Coverage Δ

cpp/src/arrow/util/compression_zstd.h
50% <ø> (ø)
:arrow_up:

cpp/src/arrow/util/compression_brotli.h
50% <ø> (ø)
:arrow_up:

cpp/src/arrow/util/compression_snappy.h
50% <ø> (ø)
:arrow_up:

cpp/src/arrow/util/compression_lz4.h
50% <ø> (ø)
:arrow_up:

cpp/src/arrow/util/compression_snappy.cc
66.66% <0%> (-24.25%)
:arrow_down:

cpp/src/arrow/util/compression.h
100% <100%> (ø)
:arrow_up:

cpp/src/arrow/util/compression.cc
89.47% <100%> (+1.23%)
:arrow_up:

cpp/src/arrow/util/compression_lz4.cc
73.91% <72.54%> (-9.43%)
:arrow_down:

cpp/src/arrow/util/compression_zlib.cc
76.56% <79.72%> (+3.75%)
:arrow_up:

cpp/src/arrow/util/compression_zstd.cc
82.97% <83.13%> (-0.36%)
:arrow_down:

... and 78 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 54634dd...891bfaf. Read the comment docs.


NodeJS: fix protobuf import

Codecov Report

Merging #1626 into master will decrease coverage by 0.01%.
The diff coverage is 50%.

@@             Coverage Diff              @@
##             master    #1626      +/-   ##
============================================
- Coverage     85.54%   85.53%   -0.02%
- Complexity     4772     4774       +2
============================================
  Files           457      457
  Lines         19124    19130       +6
  Branches       2053     2055       +2
============================================
+ Hits          16360    16362       +2
- Misses         2142     2143       +1
- Partials        622      625       +3

Impacted Files
Coverage Δ
Complexity Δ

...sformer/nodejs/NodeJSImportSectionTransformer.java
90.9% <50%> (-4.33%)
5 <0> (ø)

...ormer/nodejs/NodeJSPackageMetadataTransformer.java
91.26% <50%> (-2.12%)
24 <2> (+2)

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 6c6c7df...bcdc447. Read the comment docs.


Add note about running clean before using -vv for build script development

This solves an issue that came up in the beginners chat that took about fifteen minutes to finally understand what was going on.
This should help users who are actively developing build.rs consistently get debugging information printed to the terminal.

@bors: r+

:pushpin: Commit 72c9242 has been approved by alexcrichton

:hourglass: Testing commit 72c924230c3df67261642f74ba415cb34086935f with merge d85b020745bdc7d2e8aee99bcb20c6689030c61b...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing d85b020745bdc7d2e8aee99bcb20c6689030c61b to master...


f303 VP9 stream with lower bitrate than f299 has higher total file size? bestvideo defaults to f299 seemingly because of this

Please follow the guide below

[ x ] I've verified and I assure that I'm running youtube-dl 2018.08.04
[ x ] At least skimmed through the README, most notably the FAQ and BUGS sections
[ x ] Searched the bugtracker for similar issues including closed ones
[ x ] Checked that provided video/audio/playlist URLs (if any) are alive and playable in a browser

What is the purpose of your issue?

[ x ] Question

-f bestvideo+bestaudio is defaulting to picking, in the case of one particular video, a 6.01GiB f299 MP4 over a 6.74GiB f303 VP9 stream for me.
youtube-dl -F https://www.youtube.com/watch?v=mZVAl_cwsik

Also the total size of the video streams or the bitrates of the video streams appear to be inaccurate? Lower bitrate = higher total size?
303          webm       1920x1080  1080p60 5212k , vp9, 60fps, video only, 6.74GiB
299          mp4        1920x1080  1080p60 6779k , avc1.64002a, 60fps, video only, 6.01GiB

Total bitrate is preferred over filesize. Metadata is provided as is, whether it's accurate or not is up to Youtube.


API to upload file streams, with known stream length, to blob storage.

Add API to blob client wrapper/blob client to upload file streams, which does not support tellg/seekg to calculate length of the stream, to blob storage.

@JasonYang-MSFT Can you also take a look?

@vinjiang Looks good to me.


Please add support for Telos EVM

Name: Telos EVM
Symbol: TLOS
Mainnet ChainID: 40
Testnet ChainID: 41
RPC: https://mainnet15.telos.net/evm
Explorer: https://teloscan.io
Chain Socials:
X: https://x.com/hellotelos
Telegram: @HelloTelos
Logo URL: https://www.telos.net/community-resources
Chainlist: https://chainlist.org/chain/40
Additional Info (optional: audits, bridges, etc)
Contract Audits: https://sentnl.io/audits/telos-0
Bridge : https://bridge.telos.net/bridge (LayerZero Bridge)

https://github.com/enkryptcom/enKrypt/pull/470/commits/9896d91ce660c0dc13af912eaa4d83b2172923e5


Create authentication page in wiki

Describe the task that needs to be done.
A new page has to be created called Authentication Flow in the wiki. This page should contain information about how Google's OAuth is being used so that users can sign into the application. It should also contain signatures of those endpoints managed by the Users team, namely /api/users/login and /api/validate.
Describe how a solution to your proposed task might look like (and any alternatives considered).
N/A
Notes

This issue was agreed upon by the team as this documentation will help the next team understand our implementation.

LGTM

This page has been created!


[ISSUE #2165][Client] Fix Slave read enable not work sometimes When cluster deployed on DLedger mode

What is the purpose of the change
issue https://github.com/apache/rocketmq/issues/2165
Brief changelog
1.when broker id is 1 and can't find the key, use broker id 2
2.add unit test
Verifying this change
XXXX
Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

[x] Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
[x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[x] Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
[x] Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test  to make sure integration-test pass.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Coverage increased (+0.1%) to 51.418% when pulling 0a7f802b8efedbe69605d09145968814df6b5dbb on maixiaohai:slave_read_enable_not_work_sometimes into 9f95a972e10e0681bc3f2d00e9957aa212e897b5 on apache:master.


MMS ASR models with shared multilingual vocabulary

❓ Questions and Help
What is your question?
Are there any plans to release MMS ASR models with shared multilingual vocabulary (as described in the first paragraph of section 5.1 of the paper)?

At this moment, we don't plan to release a shared multilingual vocab model.


Computed atoms get needlessly triggered again

Problem statement
Let's consider this example:
import { atom, useAtomValue } from "jotai";
import { ScopeProvider } from "jotai-scope";

const AtomA = atom(() => {
  console.log("Computing AtomA");
  return "ValueA";
});

function Child() {
  const valueA = useAtomValue(AtomA);

  return
{valueA}
;
}

export default function App() {
  return (

      <Child />
      <ScopeProvider atoms={[]}>
        <Child />
      </ScopeProvider>

  );
}

Note that I purposely do not pass AtomA in the scope provider, so I would intuitively assume that the inner child would read from the same "scope instance" as the parent one. As the read function normally only triggers when dependencies change, I would except it not to trigger again but just return the same cached value as for the parent component.
However that turns out not to be the case here. "Computing AtomA" gets logged twice in the console almost as if the atom was scoped.
Additional context
Perhaps this was implemented with the idea that read functions are pure, so even if we compute them again they'll return the same result. And if they depend on other atoms, the value for those would match the parent scope, so it would again return the same value as the parent scope.
However I find that hinders the assumption that read functions only trigger when dependencies change. For example I have use cases with async read functions that fetch data from an API into a cached atom. So if I were to consume those atoms inside unrelated ScopeProviders, then they'd trigger the API fetch again which is an undesired and unpredictable behavior.

Thank you for submitting the issue, I know what happens but I am not sure what is the correct recipe. Let me first explain some design considerations, they are mainly about derived atoms:

Constraint: all the dependency of jotai atoms are dynamically computed.
An atom has a read function and a write function. Inside the read function, it can access other atoms via get(anotherAtom) call, then such atoms are derived atoms. Otherwise, it becomes a primitive atom.
Note that get(anotherAtom) is an expression within the read function, which means we have no idea which atom it depends on until we call anAtom.read(). That's what we mean by dynamically computed.
Design: if an atom is scoped, then all of its dependents are also scoped.
We choose to do so, because atom dependency chains could be complicated, and it makes no sense if an atom is scoped while its dependents are not. Therefore, we choose to implement it as if an atom depends on an scoped atom, then it is also scoped even the atom is not explicitly specified in the ScopeProvider

OK, here comes the issue: In a ScopeProvider's nested children component, when calling useAtom(anAtom), we are not aware whether the atom is scoped or not. We need to first find its dependency chain (by calling anAtom.read), then check if any of the dependency atom is scoped.
So, to make it work, we PESSIMISTICALLY creates a copy of all the atoms called within a ScopeProvider (including atoms depended by them), then calls their read function to detect their dependencies. If they are actually not scoped, what we do is like, making the copy subscribe the original atom, so they look like the same. However, internally, all the atoms within a ScopeProvider are copied. They are different instances.
Comming back to your original case, I have two ideas. The first one would be add another API to explicitly tells ScopeProvider that I don't want the atom to be scoped, but I am not in favor of it because that would lead to additional stuff to learn and I am not sure if that's a good implementation. The second one would be decoupling the cache with your atom. You can implement the "cache fetch" code outside of read function and determines if the cache is available in your read function. Would you like to share a piece of code of your async cache? I'm interested in if it is only initialized once and never changes then, or it could be invalid and retrieved at some time. Anyway, I think the recipe is not so difficult.
I am not so clear if some deeper assumptions are behind. Async functions are not pure. "read functions only trigger when dependencies change" is true, but unfortunately a scoped atom is not the original atom, so multiple initializations occur for each ScopeProvider.

I see there are some implications that are more complex than what I thought. For example, what if a derived atom is not scoped, but one of its dependent atoms is, it leads to confusing situations indeed.

Would you like to share a piece of code of your async cache?

Sorry I might have mislead you with my language. What I meant by "cache" was really just the atom itself and it how it buffers the result of a derived atom. For example, it could look like this:
import { Suspense } from "react";
import { atom, useAtomValue } from "jotai";
import { ScopeProvider } from "jotai-scope";

const MyObjAtom = atom(async () => {
  // Expecting this to only be called once (unless someone explicitly scopes it)
  const response = await fetch('/api/myobj');
  return response.json();
});

function MyObjView() {
  const myObj = useAtomValue(MyObjAtom);

  return
{myObj}
;
}

export default function App() {
  return (

      <Suspense>
        <MyObjView />
        <ScopeProvider atoms={[]}>
          <Suspense>
            <MyObjView />
          </Suspense>
        </ScopeProvider>
      </Suspense>

  );
}

The problem we have is that we constructed most our API requests using plain async atoms like these, which works well enough for our current stage, but whenever someone uses a ScopeProvider, even if it's for a set of unrelated atoms, if they read from any of those API call atoms, they will re-fetch again.
One workaround I found is manually cache those atoms, a bit like so:
const MyObjCacheAtom = atom();
const MyObjAtom = atom(async (get) => {
  if (get(MyObjCacheAtom)) {
    return get(MyObjCacheAtom);
  }
  const response = await fetch('/api/myobj');
  return response.json();
});

This actually works well as MyObjCacheAtom will not be scoped. I guess we could also use jotai-cache for the same effect. My issue with that solution is that we would need to change all our API calls and take the habit of caching them all, not because we want/need the cache, but because some components might potentially use an unrelated ScopeProvider.
I was prioritizing simplicity with this approach for as long as we don't need more advanced features (e.g. invalidation), but it seems that this simplicity won't work with jotai-scope and I either need to drop it, or bring an additional general layer of complexity to our API interactions (e.g. jotai-cache, jotai-tanstack-query, custom caching, ...) which I was hoping to avoid.

Yes yes your workaround is exactly correct, I can understand what a more intuitive API would like, but unfortunately I don't know how to do that (maybe that's a wont-fix) :/
The key takeaway is One should not expect the read function being called exactly once, even though the atom is not scoped.
I'll consider documenting it instead of patching it if that is a rare case.

Updated readme, close it for now.

apologies but i don't think i understand the work around. Are you writing to this cache atom somewhere?
const MyObjCacheAtom = atom();
const MyObjAtom = atom(async (get) => {
  if (get(MyObjCacheAtom)) {
    return get(MyObjCacheAtom);
  }
  const response = await fetch('/api/myobj');
  return response.json();
});

@yf-yang @RaffaeleCanale curious if you have more detail on how you're using the cache.
For context, we have two separate bugs when using jotai-scope with atomWithObservable (at first via jotai-urql but it also manifests when used directly).
One involves a combination of unwrap and the observable atom creating a loop. The other manifests as a permanently hung suspense boundary.
I'm not sure how to use a caching solution with the observable since I specifically need it to recalculate on updates from the URQL cache.
Part of my difficulty here is that this also only manifests in our production nextjs build. I have tried hard to create a repro here: https://codesandbox.io/p/sandbox/urql-plus-suspense-plus-scope-mzkct6?file=%2Fsrc%2FApp.tsx and haven't been able to create a consistent one. I have seen an infinite loop intermittently but not often. Whereas, the prod bugs I mentioned happen reliably every time.
Any thoughts here would be very appreciated.

@scamden Is the sandbox public? Following that link tells me the sandbox wasn't found.
In the workaround I suggested, the atom MyObjCacheAtom is the "cache". My issue was that when using jotai-scope, all derived atoms (even the ones not listed in the scope) will be sort of invalidated and recompute. In other words, the derivation function (in my case, the one making an API call) would get called again if that atom was accessed within the scoped tree.
So by copying the response of the API in a separate atom (which I also don't scope), then even if my derived atom gets computed again, it's fine as it will just return the value from the MyObjCacheAtom.
So in the end, my problem was really just about derived atoms getting recomputed again despite not being in the scope list, which caused unnecessary API calls.
Full disclosure: In the end it was too cumbersome and error prone to cache all our API derived atoms into simple value holders atoms, so we went an alternative route and stopped using jotai-scope altogether unfortunately.

Is this still an issue? I just merged a full ground-up rewite of jotai-scope. We will create a new release version shortly.
In the new implementation derived atoms still get copied (because they may access scoped atoms), but the way they get copied doesn't call their read or init functions. This also fixes atomWithLazy from jotai/utils.

Can you share a codesandbox example of your issue? I would like to try something out.

@RaffaeleCanale How do you like this api?
<ScopeProvider atoms={[]} noScope={[AtomA]}>

@scamden Is the sandbox public? Following that link tells me the sandbox wasn't found.

Whoops it wasn't! Now it is.

Full disclosure: In the end it was too cumbersome and error prone to cache all our API derived atoms into simple value holders atoms, so we went an alternative route and stopped using jotai-scope altogether unfortunately.

If you stopped, what alternative did you choose? I experimented briefly with bunshi personally

If you stopped, what alternative did you choose? I experimented briefly with bunshi personally

None. For the atoms we intended to scope, we kept them global and manually reset them when relevant. We wanted to scope them to avoid unnecessarily holding onto global memory longer than needed, so for now we just accepted to keep them global nevertheless.
I'm sorry I can't be of more help, but I have hopes that this latest feature could truly help.


pacth correct and there are but system can not read that

File [/home/u1694184/public_html/demo-sip-simakberita.com/storage/app/livewire-tmp/nhaUTQr5TnrrzFHbfk4T5SJ0yo5y9z-metaZm9ybWF0LXBlbWFpbi54bHN4-.xlsx] (local) does not exist and can therefor not be imported.

I am also facing this issue.

install "konnco/filament-import": "^2.0.2-beta" solves the issue.

konnco/filament-import": "^2.0.2-beta

yess this is work. thank you

composer require konnco/filament-import:^2.0.2-beta

Sorry, this issue is still around. I have tried:

composer remove konnco/filament-import
composer require konnco/filament-import:^2.0.2-beta
php artisan cache:clear
set the storage and below to 777 (to make sure it is not in the way)

And still receiving : File [/var/www/html/storage/app/filament-import/01J6DPX7QDYJBE380FWCRFFM4F.xlsx] (local) does not exist and can therefor not be imported.
I really love this plugin and do not want to be forced onto the terrible inbuilt batch imports. Any advice would be appreciated.

+++

This error was related to laravel-excel package and not this package.
Try running composer update and see if it solves...


Firefox support

Can you set up publishing to the Mozilla Addons store? Once that’s set up and you verify it’s working as a new extension, I can pass you the control of the existing extension: https://addons.mozilla.org/en-US/firefox/addon/notifications-preview-github/
This is easier to implement than the Chrome version and the API is also very easy to get.

My original thought was that my personal version might not be maintained, and I just contribute to the original version: notifications-preview-github.
I had migrated all the fixes and new feature by recent prs except the typescript and deps upgrade.

Ok, I contribute to that extensions if I have anything want to improve.
Will check anything I can do when I have free time.


Rename retworkx to rustworkx

This commit renames the retworkx project to rustworkx. The maintainers of
NetworkX requested that we change the name of the library because they
viewed networkx as being too similar to retworkx. Out of respect for
this request and the NetworkX library which inspired retworkx we are
renaming the library to rustworkx. Rustworkx is a similar name to
retworkx and enables us to keep using the rx abbreviation for imports
which is commonly used.
This commit, migrates all the internal usage and names from retworkx to
rustworkx. This includes the retworkx-core crate which has similarly been
renamed to rustworkx-core. However, for backwards compatibility and to
ease the migration of our existing user base the retworkx package is
still included in rustworkx. An import redirect is added so that
import retworkx.foo will return return rustworkx.foo. Additionally, the
README and documentation are updated to mention the rename.
The migration plan this commit takes is that for the pending 0.12.0
release we'll migrate to rustworkx for everything but keep the backwards
compatibility shim in place with no warning. In the 0.13.0 release we'll
emit a DeprecationWarning (or a FutureWarning) that the name is
deprecated (this waits a release to ensure there is upgrade path where
more than 1 version works without raising a warning to ease migration). We can
then remove the deprecated retworkx name as part of the 1.0.0 release.
During the transition period we'll continue to publish releases to both
the rustworkx and retworkx names through at least 0.14.0 (but with the option
to keep publishing both until 1.0.0) so that users will see the deprecation
warnings when importing retworkx.
Closes #641

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

54 of 55 (98.18%)  changed or added relevant lines in 8 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 97.059%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/union.rs
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
12377

Relevant Lines:
12752

💛  - Coveralls

I think if we install rustworkx locally before installing retworkx we will not need to relly on rustworkx being on PyPI, as pip will find it is already installed. I comment a possible workaround.

sgtm


Mock AppSync API response size limit with Lambda resolver

There seems to be a response size limit when mocking AppSync API with a Lambda resolver that isn't there with the deployed version.
My setup/code
Amplify CLI 4.20.0
package.json
{   "name": "amptest",   "version": "0.1.0",   "private": true,   "dependencies": {     "react": "^16.13.1",     "react-dom": "^16.13.1",     "react-scripts": "3.4.1"   } }
schema.graphql
type Query {   echo(len: Int) : String @function(name: "ldaEcho-${env}") }
ldaEcho resolver
exports.handler = async (event) => {     return 'x'.repeat(event.arguments.len); };
API Queries Tests
AWS AppSync Console

echo(len: 8158) ==> valid response
echo(len: 9200) ==> valid response

Mock API
In terminal, run amplify mock api.
GraphiQL Explorer (http://<IP_ADDRESS>:20002/)

echo(len: 8157) ==> valid response
echo(len: 8158) ==> hangs (busy spinner spins indefinitely)

Note that this bug wasn't there in prior Amplify CLI versions though I'm not sure when it crept in. Also note that this isn't a GraphiQL bug as the same response-hanging behavior can be replicated  by an AppSync client querying the API in mock mode.

This is no longer an issue with Amplify CLI 4.29.1 so I am closing it. Thanks to whoever fixed it!


ECONNREFUSED

Sir,
I cloned the repo, did npm install inside it, filled input.csv as instructed, and finally ran node index.js inside src to run the app.
Unfortunately I am getting this:-
PS C:\Users\MBS\Downloads\Multi-2\src> node index.js
Running Lighthouse for 1 page(s) in input.csv

Run 1 of 3: page 1 of 1

>>> Error:   Caught error for https://dawn.com:
Error: connect ECONNREFUSED ::1:58607

I am using Windows 10 latest version 22H2 and Node latest version 18.14.0 as well.
Would be grateful if this is explained.
Wishing you success,
mbsc26

Hi @mbsc26 !
Thanks for the heads-up.
I can reproduce this on Mac 13.2 using Node 18.9.0: I've replied to the Lighthouse bug here.
Using Node 16.17.1 (via nvm), Multihouse works fine.


fix: calendar heatmap examples

CATEGORY

[x] Bug Fix

SUMMARY
Fixing a set of examples that trip on ValueError vs TypeError, related to https://github.com/apache/incubator-superset/pull/6719
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

Codecov Report

Merging #7375 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #7375   +/-   ##
=======================================
  Coverage   64.92%   64.92%
=======================================
  Files         428      428
  Lines       20960    20960
  Branches     2333     2333
=======================================
  Hits        13608    13608
  Misses       7228     7228
  Partials      124      124

Impacted Files
Coverage Δ

superset/viz.py
71.53% <100%> (ø)
:arrow_up:

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 f83b979...c16e95f. Read the comment docs.


4.03.0

Work in progress - so do not merge obviously.
This builds upon the work already done by @kayceesrk.

The last formatTest issue that I'm facing is that let _ isn't properly removed in certain situations when converting OCaml code to Reason code.
For example https://github.com/facebook/reason/blob/master/formatTest/typeCheckedTests/input/mlSyntax.ml#L48 should result into https://github.com/facebook/reason/blob/master/formatTest/typeCheckedTests/expected_output/mlSyntax.re#L63

So everything works (famous last words) - I still have to write some extra formatTests though for the new 4.03 features.

FormatTests to write for 4.03

[x] PR#5528: inline records for constructor arguments
[x] GPR#234: allow "[]" as a user-defined constructor.
[ ] PR#6374: allow "_ t" as a short-hand for "(_, _, ..) t" for n-ary type
[ ] PR#6806: Syntax shortcut for putting a type annotation on a record field
[ ] PR#6806: Allow type annotations before the "->" in "fun  -> "
[ ] GPR#26: support for "(type a b)" as syntactic sugar for "(type a) (type b)"
[ ] GPR#42: short functor type syntax: "S -> T" for "functor (_ : S) -> T"
[ ] GPR#88: allow field punning in object copying expressions

Taken from: http://caml.inria.fr/pub/distrib/ocaml-4.03/notes/Changes.
Please let me know if I miss something here.

Regarding let _ = expression being converted into expression;. I would say that it seems preferable to preserve the let _ =. Or at least I'd say it doesn't matter much. I know the internal representation of top level imperative commands changed some time around 4.02.3-4.03. What you're seeing might be that change. I'd say, all else being equal, preserving more is desirable and we should be thoughtful about the things which we don't preserve.

see PR#6865: remove special case for "let _ = expr" structure items https://github.com/ocaml/ocaml/commit/01bf671f33d7b20e1357f71ef064aaddba642992

@SanderSpies Are you still adding tests to this diff?

So the plan for this is to either make Reason 4.03+ or two use the 4.03 AST, but then create a thin adapter that uses the 4.03 AST in the parser (for our own sanity, only having one canonical AST representation), but then converts it to the 4.02 representation for older compiler versions.
@cristianoc How is Infer support for 4.03 looking?

FYI, we decide to target 4.04 (skip 4.03) for BuckleScript, some patches needed for Buckle are landed. 4.04 beta will be coming soon.

@yunxing not actively at the moment - I'm waiting on input here.
I know the wish to convert to 4.02 but haven't put any effort in that yet. I believe others in OCaml ecosystem want to do something similar.

Bob, so we will not be able to use BuckleScript with Reason unless we also target 4.04?

It will take a while for us to upgrade for 4.04, so we will stay at 4.02.3 for at least a couple of months, but I think we will skip 4.03

btw, there will be no bug fix release for 4.03

I think everyone should be targeting the 4.04 AST then (not sure how many changes there were since 4.03). Then we can build support for previous versions on an as-needed basis.

@jordwalke Infer could switch to 4.03 whenever there is support, or 4.04.
There are plans to switch to a newer version of Reason, as soon as comment formatting is stable. I originally thought about converting to 4.03 at the same time, but there's no strong motivation for doing that.

Okay, so there's no issue with Infer's use of Obj.magic anymore?

That's good to hear. I think we can get this diff in if that's the case!

@jordwalke the issue with Obj.magic was actually in joyson, a depenency. There was a pull request to fix it some time ago, I should check but I guess it will have been pushed by now.

Sander, do we need to do anything for PR 6374? Do we at least need to test that we can convert from ML to Reason?

Yes, that would be a wise idea - I'll continue this PR once JSX is merged.

Closing this in favour of the "OCaml lost in spacetime" edition.


Upgrade to Chrome 44

[x] Not building on OS X
[x] Not building on Linux
[x] Not building on Windows
[x] Renderer process crashes when using Buffer
[x] Renderer process crashes when printing Buffer in devtools
[x] Rewrite the protocol module (#2475)
[x] Crash when using protocol module
[x] Warn about old protocol API usages
[x] Make release build working
[x] Make native modules work
[x] Pass tests
[x] Merge https://github.com/atom/brightray/pull/127

:clap: :sparkles:

:clap:

Thank you @hokein and @zcbenz for your valiant effort.You guys are super hero's to us mortals!


Minor Fixes

Hi,
this merge request fixes some minor issues.
It was created with help of Feram.
If it helped to improve this repository,
please consider to star Feram's repo to show some love! 😊
PS:
The Feram team is currently working on making this technology
available for everyone. If you want to be one of the first to use it,
please sign up up for the newsletter on feram.co.

Automated message from Dropbox CLA bot
@ronbak, thanks for the pull request! It looks like you haven't yet signed the Dropbox CLA. Please sign it here.

This seems to be an automated PR which just spell-checks a typo in a comment.  Not high value, and no CLA, so I'm going to close it out.
@ronbak I'm willing to merge if you sign the CLA.  Feram sounds like a cool idea, so I wish you luck, but apparently it's not finding anything really interesting in this repo yet.

Automated message from Dropbox CLA bot
@ronbak, thanks for signing the CLA!

I signed the CLA. Why does everything have to be so complicated =D
Thanks for the good luck. We'll need it … YC interview on Monday =P

Yeah, the CLA is a necessary evil.  Since this library is used in commercial apps at Dropbox, we want to be really careful that nobody submits code without giving us the appropriate rights to use it.


lr_scheduler order changed since PyTorch 1.1.0

Many thanks for the wonderful library.
A warning message emerged when a scheduler was used in the callbacks:
scheduler = torchbearer.callbacks.torch_scheduler.StepLR(step_size=5, gamma=0.1)
Hope it could be considered in later update if not yet included.
Python37\lib\site-packages\torch\optim\lr_scheduler.py:100: UserWarning: Detected call of `lr_scheduler.step()` before `optimizer.step()`. In PyTorch 1.1.0 and later, you should call them in the opposite order: `optimizer.step()` before `lr_scheduler.step()`.  Failure to do this will result in PyTorch skipping the first value of the learning rate schedule.See more details at https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate
  "https://pytorch.org/docs/stable/optim.html#how-to-adjust-learning-rate", UserWarning)

Hi @kikatuso, thanks for your comment! This should now be fixed if you install from master (use the build from source instructions here: https://github.com/pytorchbearer/torchbearer#install). I should point out that torchbearer is not currently in active development and so may not be very reliable. Consider switching to an alternative like pytorch-lightning.
Thanks :smiley:


DNN-6576

LanguageSelector Menu is broken

SAme bug, same fix, work as expected, hope it will be merged for 7.4.1


[Edit Profile] The 'Save' button is not clickable when the 'City' text field is empty

Environment: Windows 10 Pro, Google Chrome (116.0.5845.96)
Reproducible: when the text field has already been edited once
Build found: 24.08.2023
Preconditions
There should already be some value in the 'City' text field
Steps to reproduce

Go to https://www.greencity.social/#/profile
Sing in as user
Open 'My space' page
Click on the 'Edit profile icon near the photo
Erase a value in 'City' text field
Click on 'Save' button

Actual result
The 'Save' button is not clickable and the empty 'City' text field is not saved
https://github.com/ita-social-projects/GreenCity/assets/138515375/df04b620-18e6-4830-af10-f53723211e5c
Expected result
The 'Save' button is clickable and the empty 'City' text field is saved
User story and test case links
User story #1010
GC-7826

resolved


feat!: create IceFlow nodes based on application DAG

This is the follow-up PR to #107, which attempts to perform an overhaul of the IceFlow API using our application DAG. This PR is still heavily WIP and gradually incorporate further changes made to #107.

I think this PR should now be ready for an initial review. The changes might have turned a bit more drastic (and in some places even controversial) than I originally intended, but I think this should point into the right direction.
Some of the most important aspects:

I removed any kind of publish internal and even the internal consumer queue, so data is immediately published and passed to the application on arrival. As data is temporarily stored inside ndn-svs anyway, the latter aspect should not have negative downsides from my understanding. We can of course discuss this aspect, though, and could add the queue back in, if needed.
Consumers and Producers are now not intended to be used by a user anymore and are only used internally (and are constructed based on the application graph and a node name). The registration of consumer callbacks and pushing data are now performed by providing the respective edge name.
The IceflowScaler class now accepts an IceFlow object instead of individual producers and consumers
Besides a consumer callback, users can also register a "prosumer" callback that itself can access an interface for pushing data to downstream consumers.

Looking forward to your feedback – if you like, I can also walk through the PR on Monday.

Applied some further adjustments to the prosumer callback registration, that allows the user to specify which downstream edge they to push to, in order to make to it possible to push data to multiple downstream edges at once.

I think after the recent commits, this PR should now be ready for (hopefully) a final review :)

(Just spend about 15 minutes debugging some newly appearing errors involving segmentation faults – in the end, the fix came down to a6c21c58837720ce3851299b0e743cf47ca79830 🤦 This is always great fun :D)

When the pipeline succeeds, I am now going to finally squash and merge this PR :)


Implement player UI

Dev Notes

This should remain something fairly simple with just health and items (when implemented)

This issue was closed because the project was archived


New workflows for app-mesh

Description
Currently this repository doesn't have any workflows, would be really nice to get some up and running
The following are needed

build-and-release
ci
error-ref-update
release-drafter
updating-aom-defs

we can take inspiration from other repos like Istio and Kuma

The meshery.io website uses Jekyll and GitHub Pages. Site content is found under the master branch.

See the Contributing to Meshery.io Website section of the readme.md and other contributing instructions, too.
See Meshery site designs in this Figma designfile. Fill-in the Layer5 Community Member Form and join the Layer5 Community Slack for access.

@sayantan1413 will you be willing to take this ?:sweat_smile:


Edits pass through 01_MC_NVT; added references

This is already great, but I've taken an edits pass and flagged a few instances where we will need to make some alterations---notably the addition of a smooth switching function.

I can add the switching function changes if we're OK with adding that to the MC part.
Next up is the integrators in 02_MD_NVE.tex, but I think it will be easier to have them actually do NVT instead of NVE (which opens up a can of worms we don't want to deal with).

Sure, adding the switching function sounds good to me!

Sure, adding the switching function sounds good to me!

Thanks! Should I do that?

Might be easier if you add it, if you're ok with that!

On it!


study programme: the numbers, what do they mean?

the numbers in productivity seems to be pretty random

Apparently the numbers add up but seem weid because of people transferring to the new studyprogramme and productivity is calendar year but population progress is school year


Fix return type annotation

Summary
(Describe the goal of this PR. Mention any related issue numbers)
Category (place an x in each of the [ ])

[ ] slack_sdk.web.WebClient (sync/async) (Web API client)
[ ] slack_sdk.webhook.WebhookClient (sync/async) (Incoming Webhook, response_url sender)
[ ] slack_sdk.socket_mode (Socket Mode client)
[ ] slack_sdk.signature (Request Signature Verifier)
[x] slack_sdk.oauth (OAuth Flow Utilities)
[ ] slack_sdk.models (UI component builders)
[ ] slack_sdk.scim (SCIM API client)
[ ] slack_sdk.audit_logs (Audit Logs API client)
[ ] slack_sdk.rtm_v2 (RTM client)
[ ] /docs-src (Documents, have you run ./scripts/docs.sh?)
[ ] /docs-src-v2 (Documents, have you run ./scripts/docs-v2.sh?)
[ ] /tutorial (PythOnBoardingBot tutorial)
[ ] tests/integration_tests (Automated tests for this library)

Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run python3 -m venv .venv && source .venv/bin/activate && ./scripts/run_validation.sh after making the changes.

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

@ehdgua01 Thank you very much for taking the time to correct the type hint!
Without a signed CLA, we are unable to merge your contribution. Would you mind signing our CLA? Please check the above bot message.

Ok, I signed 😄


Added auto theme based on user selected system theme for composer

Code changes

Added a new theme option auto for Composer component, which will use corresponding theme related to prefers-color-scheme.

Readiness checklist

[x] Cypress tests passing?
[x] Included before/after screenshots, if the change is visual

Screen Capture
https://user-images.githubusercontent.com/14408339/150432006-881949fa-d616-4598-a5b2-18252ab68963.mov
License
I confirm that this contribution is made under the terms of the MIT license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Code looks good!
A discussion point I'd like others to chime in on: are we okay with making auto the new default? This might result in some of our users seeing an unexpected theme change when they upgrade.

That's right. If we want a consistent component style for users (unless they want to customize it), then we need to set all the  components' default themes to either dark or light. At least, mailbox and composer should be in the same default theme.


[7077] Remove guide who needs them

Context
api guide
Changes proposed in this pull request
remove api guide
Guidance to review
It is removed
Important business

[ ] Does this PR introduce any PII fields that need to be overwritten or deleted in db/scripts/sanitise.sql?
[ ] Does this PR change the database schema? If so, have you updated the config/analytics.yml file and considered whether you need to send 'import_entity' events?
[ ] Do we need to send any updates to DQT as part of the work in this PR?
[ ] Does this PR need an ADR?

NB: Please notify the #twd_data_insights team and ask for a review if new fields are being added to analytics.yml

 Do preparation for API v1.0 development


Localize validation attribute messages

Fixes #3537. Allows localization of validation messages on models.

@NTaylorMullen, @dougbu, could you guys give me a code-review?

:watch:

Are there already existing localization tests for all the added localization attributes?

:watch:

There are tests in https://github.com/aspnet/Mvc/blob/dev/test/Microsoft.AspNet.Mvc.DataAnnotations.Test/DataAnnotationsModelValidatorTest.cs unless you think they don't cover enough.

:up: :date:

Talked offline.
Going to wait for changes to ValidationAttributeAdapterTable. Right now it's a dictionary where you lookup a factory and then instantly invoke said factory for the IAttributeAdapter. Instead, going to transition that entire piece into the equivalent of public static IAttributeAdapter DoMagics(attribute, stringlocalizer.... to instantly retrieve the validation adapter without ever creating a dictionary, factory etc.

unless you think they don't cover enough

Need to double-check that all of the attribute adapters include the expected arguments when forming a localized error message.

changes to ValidationAttributeAdapterTable ... going to transition that entire piece ...

This does not seem like a good idea. We don't have an extensibility story for this component and need one. Don't adjust the approach until we know the final design.

:watch:

This does not seem like a good idea. We don't have an extensibility story for this component and need one. Don't adjust the approach until we know the final design.

Wha? Maybe I misunderstood the scope of the issue, was extensibility for this already designed? If so, my bad for suggesting otherwise. Saw the dictionary as super unnecessary.

:up::date: looks like the extensible aspect of this is in another bug, so I didn't address that here.

:watch:

:watch:

:up: :date: I BELIEVE all the test are passing, but CI is backed up so I figured I may as well try for a :shipit: while I wait.

:watch:

:up: :date:

:shipit: once @dougbu/@pranavkm is happy

:watch: very close

:up::date:

Also, preemptively sorry about regressing to the CompareAttributeWrapper pattern but the behavior on CompareAttribute is super unhelpful and that was the only way I could make it do the right thing.

:watch: for test improvements

:up: :date:
If what I said about the IStringLocalizer doesn't actually address your concern let me know.

:shipit: after fixing up your numeric literal suffixes.


perf: remove markdown parsing

Rather than parsing markdown on every request we can skip this altogether and just use Lua. This decreases the space where bugs can occur and also increases the lookup performance since we don't need to check the filesystem if the file exists and parse it. Plus lua module caching makes this fast.

Actually I'm going to revise this a bit to improve the loading more and I will reopen


Update updates-operations.md

Added line shift after headings.
Replaced text that called out important information, with alert markdowns.
Renumbered headings, since levels were skipped (e.g. going from two to four).

Learn Build status updates of commit b8d6dca:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

WindowsServerDocs/administration/windows-server-update-services/manage/updates-operations.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

@Xelu86, @robinharwood,
Can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


possibly issue with strict mode

The AMD / UMD wrapper has an undefined root in specific cases where strict mode is used.
In this cases we have to set root to window if it is defined.
I'll prepare a testcase which demonstrates this (this is often the case with Gulp, webpack and other solutions).

Facing same issue, also found this one #481

Something like https://github.com/bebraw/libumd/commit/f43a331e7c484ed9c5696d4827d5b16a918ec3bb
https://github.com/dimsemenov/PhotoSwipe/pull/1413

More references:
https://github.com/fians/Waves/pull/181
https://github.com/jonathantneal/svg4everybody/issues/162