How about .xcassets file?

I want to put all icons into xcassets like below:

The xcode now can see the assets like below:

May I ask how to use it as UIImage(named:"fullscreen_white").
Thanks a lot

@likeconan I hope you found the answer for your question. If you didn't, this is covered by the Flutter's documentation: https://docs.flutter.dev/development/ui/assets-and-images#loading-flutter-assets-in-ios.

@vital-edu  Yes I did, thanks a lot again.


Remove / rename the "Debug" button

Almost any newcommer to Karma seems to think that pressing big, inviting "Debug" button is going to enable debugger for their code, but no dice, it doesn't work like this!
This happens with almost everyone I've introduced to Karma and is a common question on different forums. My proposal: let's remove / make smaller / rename this button to let users know that it is not for debugging their code but rather for changing the way files are loaded.
WDYT?

+1 I was confused by this for the past days until @pkozlowski-opensource enlightened me.

@pkozlowski-opensource not sure I understand, I always use the Debug button to debug my tests, as it makes it much easier to do that.

@Dignifiedquire it might be mine lack of understanding of the purpose of the "Debug" button, but my impression was that all it does is changing the way load files (code under tests + specs) in the way those files are:

not loaded via ajax but rather by adding script tags
URLs pointing to scripts don't have caching info

So, to actually debug scripts / tests one still needs to:

open dev tools
add a breakpoint or debugger; statement

while what I could see is that beginners were expecting is that it will automagically kick-off debugging (opening dev tools)

I always use the Debug button to debug my tests, as it makes it much easier to do that.

Interesting. What is your exact workflow? How using the  Debug button helps here?
Once again, I might be very well missing essential info / steps here so would love to chat about it! The only thing I can say is that I can see a consistent petter where people new to Karma struggle with debugging tests.

I too use the Debug button frequently to debug my tests; but I agree that the first time I did this I wasn't totally sure what the Debug button did.   My workflow is described here.
Perhaps we just need some instructional test on the debug.html page, that tell new users what to do? (in my mind I'm picturing something like what appears when you open a new incognito tab/window in Chrome)

@pkozlowski-opensource the important part in the debug window for me is that

no caching (as you mentioned)
no iframe around my testing context (easier access and less restrictions for debugging)
reload triggers a test run

You are right you still need to open the dev tools and add breakpoints but it's much more straight forward in this way

Perhaps we just need some instructional text on the debug.html page, that tells new users what to do?

This sounds like a good idea, but we can't put anything on the page itself as it could interfere with the tests, but we could show a docs link/text on the main page next to the debug button

One more idea here
When I use the debug button almost 99% of the time I would use it with ?grep=foo option
to limit the number of tests
It would be nice if the link was
debug.html?grep=

This way it would save the user to type the ?grep= everytime
small thing but could be usefull
I think there would be no harm changing this link


Add Battle Programmer Shirase and the anime shows section

Add Battle Programmer Shirase and also the anime shows section for anime shows

Checklist for submitting a pull request to Movies For Hackers:

[X] I have carefully read and comply with the Contributing Guidelines of this repo.
[X] I have searched the PRs of this repo and believe that this is not a duplicate.

Title: Battle Programmer Shirase
Link: https://www.imdb.com/title/tt1587391
Genre: Comedy/Sci-Fi/Animation
Rating: 6.4/10

Description: A young computer hacker who doesn't work for money, steals from big bank corporations sucking every last cent out of them, all while battling the King of America.

There are a lot of amazing anime shows (and movies) that fit this list wonderfully, so I added the anime shows category and with it the amazing anime show Battle Programmer Shirase

Not sure if it would be ideal to have anime links point to https://myanimelist.net/ instead of imdb as that is the anime communitys favorite.

1. "Hackers" (1995)

Plot: This cult classic follows a group of high school hackers who accidentally stumble upon a conspiracy involving a corporate computer virus. The film offers a stylized and somewhat exaggerated look at hacker culture during the 1990s.
Motivation: The film's protagonists are driven by curiosity, a sense of adventure, and, eventually, the desire to expose corruption and prevent a global financial disaster.

2.  The film explores themes of control, freedom, and reality.
Motivation: Neo’s motivation shifts from personal curiosity to a quest for truth and the liberation of humanity from machine control.

3. "WarGames" (1983)

Plot: A young hacker accidentally accesses a U.S. military supercomputer designed to simulate and strategize nuclear war, mistaking it for a video game. He unwittingly triggers a potential World War III scenario.
Motivation: Initially driven by the desire to play games, the protagonist’s motivation evolves into preventing global catastrophe as he realizes the gravity of his actions.

4. "Sneakers" (1992)

Plot: A group of security experts are blackmailed into stealing a powerful code-breaking device. The film blends elements of espionage, technology, and thriller.
Motivation: The characters are motivated by their pasts, some seeking redemption, others justice, and ultimately the prevention of the device falling into the wrong hands.

5. "Blackhat" (2015)

Plot: A convicted hacker is released from prison to help U.S. and Chinese authorities track down a high-level cybercriminal responsible for attacks on financial and infrastructure systems.
Motivation: The protagonist is driven by a mix of personal and professional motivations, including a chance at freedom and the desire to stop a global threat.

6. "Mr. Robot" (2015-2019)

Plot: While technically a TV series, "Mr. Robot" deserves mention. It follows Elliot, a cybersecurity engineer by day and a vigilante hacker by night, who is recruited by an underground group to take down corporate America.
Motivation: Elliot’s motivations are complex, involving personal trauma, a sense of justice, and a desire to disrupt a system he sees as corrupt.

7. "The Girl with the Dragon Tattoo" (2011)

Plot: This film adaptation follows a journalist and a hacker, Lisbeth Salander, as they investigate a wealthy family’s dark secrets.
Motivation: Lisbeth is driven by a personal code of ethics, seeking to expose wrongdoings, avenge personal injustices, and protect those she cares about.

8. "Takedown" (2000)

Plot: Based on the true story of Kevin Mitnick, one of the most famous hackers of all time, the film chronicles his life on the run from the FBI and his eventual capture.
Motivation: Mitnick’s motivations range from intellectual challenge and curiosity to a deeper sense of rebellion against authority.

9. "Ghost in the Shell" (1995)

Plot: In a futuristic world where cybernetic enhancements are common, a hacker known as the Puppet Master begins to manipulate people by hacking into their cyber brains. The story delves into themes of identity, consciousness, and the nature of humanity.
Motivation: The motivations in this film are deeply philosophical, exploring the boundaries between human and machine, and questioning what it means to be alive.

10. "The Social Network" (2010)

Plot: This film chronicles the founding of Facebook, focusing on the motivations and actions of its creator, Mark Zuckerberg.
Motivation: Although not a traditional hacking film, it explores the drive for innovation, power, recognition, and control, highlighting the ethical dilemmas and personal betrayals involved.

Themes and Motivations in Hacking Films
These films often depict hackers as individuals driven by a mix of curiosity, a desire to expose truth, challenge authority, and in some cases, rectify perceived injustices. Hacking is portrayed not just as a technical skill but as a means of achieving broader goals, whether they be personal, political, or ethical. In many of these films, hackers are anti-heroes—flawed but principled, navigating the gray areas of legality and morality.
In some cases, hacking serves as a metaphor for deeper themes, such as control versus freedom, the impact of technology on society, and the search for identity in an increasingly digital world. Whether these characters are fighting for a cause, seeking redemption, or simply trying to survive, their stories reflect the complex relationship between humanity and technology.


BreadCrumb Behavior Broken

The Javascript doesn't seem to be connected to this component in the samples, so none of the behaviors are showing up. For example the context menu is absent.

Are you looking at it on our docs site, or http://localhost:2020 with a local build of Fabric running? The docs site is out of date and many of the samples are broken.

Looking at http://localhost:2020.

I'm not familiar enough with this component to know what it's supposed to do, but the overflow menu is opening fine for me. Here's a GIF showing what I see.

Thanks for the illustrating what you're seeing with the gif. That is expected behavior. I nuked and rebuilt Fabric and it seems to be working now for me.


UITableView bind to custom xib UITableViewCell

#530

Thanks @pilmen !

Note that I've renamed the property to numberOfItemsInAllSections since Items is the term usually used for the elements of a 2D array section.

Yes, numberOfItemsInAllSections is more explicit. Thanks.


Cleanup/1192 prep

Submisison Checklist

[x] Run tests: ./runCmdStanTests.py src/test
[x] Declare copyright holder and open-source license: see below

Summary:
The method command (file src/cmdstan/command.hpp) parses the command-line arguments, fills in default argument values, and then calls the appropriate service method.
This PR reduces the command method own to 670 lines

for sample method, process groups of command line arguments, group by calls to NUTS-HMC vs static HMC.
use helper method get_arg_val instead of traversing object hierarchy using pointers.

This PR also removes several argument classes, as well as unused and non-user facing functionality in the argument classes.
To reduce the number of argument classes,  instead of using a 1:1 mapping from arg names to C++ objects, as much as possible, leaf node arguments are implemented using commond classes "arg_single_XXX".   This PR also removes unused and/or non-user facing elements from the argument classes and argument parser.
Intended Effect:
Make code easier to maintain in general, and reduce amount of redundant code that would otherwise be required if adding additional arguments to the adaptive sampler.
How to Verify:
Unit tests.
Side Effects:
N/A
Documentation:
N/A
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Columbia University
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

This PR mainly cleans up logic for the sample method.
It doesn't address the variational method - more cleanup is possible, but maybe not worth it.

cleaned up the variational method as well.

I think you may need to remove probe_args() as well, which is only used in one test and probably should be removed

also remove class argument_probe.hpp ?
this code and the tests for argument consistency aren't doing anything for the end user.

this is ready for re-review.

ready for re^N-review


chore: fix ruff RET505

Codecov Report
Attention: Patch coverage is 13.79310% with 25 lines in your changes missing coverage. Please review.

Project coverage is 22.78%. Comparing base (13d4788) to head (fb90d1a).
Report is 1 commits behind head on main.

Files
Patch %
Lines

midealocal/devices/b6/message.py
0.00%
22 Missing :warning:

midealocal/devices/da/message.py
0.00%
1 Missing :warning:

midealocal/devices/db/message.py
0.00%
1 Missing :warning:

midealocal/devices/dc/message.py
0.00%
1 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #110   +/-   ##
=======================================
  Coverage   22.78%   22.78%
=======================================
  Files          77       77
  Lines        6644     6644
=======================================
  Hits         1514     1514
  Misses       5130     5130

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


[feature] Add Edge-Side-Include functionality to API

Description

Purpose

Edge-Side-Includes allow Varnish to replace specific xml tags with the contents of the url specified at the href property.

Example: <esi:include href="http://www.google.com"/> would be replaced with the contents of the google homepage.

The embed functionality in the API makes this very useful since a user embedded into a node is the same as a user requested individually. So varnish can cache /v2/users/1234z/ and anytime that user is embedded in a request it can use the cached version replacing the <esi:include href="/v2/users/1234z/"/> with the full json representation of the user.

Changes

There is a to_esi_representation method that was added on certain serializers. This method takes the place of the to_representation when the ENABLE_ESI setting is True and a resource is embedded.
Instead of python embedding the full content of the user as it does with to_representation it responds with <esi:include href="{{ self.get_absolute_url() }}" />. When the response is processed by Varnish it will do a request for the specified href and replace the xml tag with the response from that request and caching the response. The next time that url is included in an esi tag it will be pulled from cache.
Blinker events were added to GuidStoredObject that fire upon model save. When these events fire they're caught by a listener that fires off a celery task to send a BAN HTTP request to the varnish server in the pattern of BAN {{ self.get_absolute_url }}.*. This is processed as a regex and should account for all possible urls that represent that object. Since objects are stored by varnish individually, even when they're embedded in another object, this pattern should remove all instances, even those that are embedded, from cache.

BAN /v2/users/1234z/.*, to varnish, means add this pattern to the list of invalid url patterns. When someone requests a URL that matches an invalid url pattern make sure to request it from the backend server instead of serving it from cache. BANning instead of PURGEing means that we can avoid the thundering herd problem that commonly occurs with cache invalidation and it also means that we're not actually emptying the cache until we need to.

Side Effects

URLs are supposed to represent unique data. Since we combine URLs and user authentication information to represent unique data this complicates caching. Varnish's configuration is VARYing on osf cookie, Authorization HTTP header, and URL. This should account for different users hitting the same url and getting a different result based on their individual permissions. There is always a chance that I've missed something. My hope is that the only side-effect of this is a low cache hit-rate. Meaning that since we're caching things per user our cache won't be utilized as well as it could for non-anonymous users.
Embed code is somewhat in flux right now. I've been basing my changes off of the two PRs that Dawn has been working on related to embeds but they have been changing while I've been working. I've tried to keep this branch as up to date with her stuff as I possibly could but there is a chance that a merge has gone sideways or I've missed a PR that was related to the embed work.
Since everything is behind a setting, unless you've switched ENABLE_ESI to true there should be no change from this PR.
The JSONAPIRenderer has a bit of code in it that I would really like to refactor but I couldn't find a better way to do it. Right now, because ESI is XML and all our stuff is JSON, DRF is quoting the value of the to_esi_representation method. Varnish doesn't expect ESI tags to be in quotes so "<esi:include href="something"/>" is ignored. The JSONAPIRenderer.render method has a regex that removes the double-quotes from the outside of the xml tag. This causes invalid JSON to be passed to varnish and varnish replaces the ESI tag prior to the client seeing it making it valid JSON again. While I love regex it can be brittle. Advice and alternate approaches are welcomed.

Test Setup
For testing/CR, you'll need to install and setup varnish. A sample VCL file is attached to this PR. VCL is a domain-specific language designed to be used to define request handling and document caching policies for Varnish Cache. It is compiled when varnish starts up. The final VCL, very similar to the attached one, is included in the private docker repo.

Assumptions

Your API server is running on port 8000
You want Varnish to listen on port 8193
You've got 2 gigs of free ram for varnish to use for caching (change -s malloc,2G in the varnish startup command to something else, -s malloc,256M for instance)

Steps

brew update; brew install varnish
Download the attached VCL file and copy it to /usr/local/etc/varnish/default.vcl or wherever your varnish installation is. default.vcl.txt
Startup varnish with the following command sudo /usr/local/opt/varnish/sbin/varnishd -n /usr/local/var/varnish -f /usr/local/etc/varnish/default.vcl -s malloc,2G -T <IP_ADDRESS>:2000 -a <IP_ADDRESS>:8193 -p feature=+esi_disable_xml_check -p workspace_backend=262144 -p workspace_client=262144
Change the ENABLE_ESI setting in your api/base/settings/local.py to True
Navigate to http://localhost:8193/v2/nodes/?format=jsonapi&embed=contributors&page[size]=100. In your inv apiserver console you should see the initial request followed by several other requests for individual contributors. This is varnish replacing the ESI tags with the individual responses. If you refresh this page you should see your pageload time decrease significantly and you should see no requests in your inv apiserver console.
Now update a contributor or node that was included in your previous request. If celery is running in your development environment the next time you request the list of nodes you should see the node and or the contributor you updated be requested from the API server but the other components should be pulled from the varnish cache. This means that the signal fired upon save, the celery task banned that content from varnish, and varnish re-requested the banned content the next time you needed it.
Making the same list-of-nodes request with either a non-logged-in user or logged in as a different user should cause requests to the python apiserver. But repeated requests as a non-logged in user or repeated requests as the same logged in user should be drawn from cache instead of making a request to the python apiserver.

Random informations

Varnish is ONLY configured to cache GET and HEAD requests where the URL starts with /v2/. Anything that does not meet that criteria will be passed directly to the python api server.
If you open the developer console in your browser and have a look at the response headers you should see X-Cache: HIT (it was a cache hit) and X-Cache-Hits: # (there have been # hits on this version of the cached object) and Age: ## (the cached object is ## seconds old) and X-beresp-ttl: 120.000 (the time-to-live of this cached object is 120.000 seconds). When Age == X-beresp-ttl the object is removed from the cache.
We can send headers back from DRF to control the TTL based on whatever we'd like. Individual objects could be cached for days or seconds. This is not implemented yet.

@cwisecarver Please resend this to develop if this PR is still relevant


Not possible to define Docker labels and routers in dynamic config

It seems that it is not possible to source configuration for Docker provided-services from both the Docker labels and the File provider without creating errors.
The rationale for wanting to do so is that I have a Docker project that should be routed through Traefik, but the actual domains (Host rules) should not be part of the Docker labels, since the Docker service may be deployed on dozens of domains, and it would mean committing the domains/hostnames to the code (which should not care about where it is deployed).
Instead, the Host config should live in a dynamic config set via the Traefik file provider, so that I can choose different Traefik configs for the same Docker projects.
What did you do?
Docker Compose file:
version: "3.7"

services:
  traefik:
    image: "traefik:v2.1.0"
    container_name: "traefik"
    ports:
      - "80:80"
      - "8080:8080"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./traefik.yml:/traefik.yml"
      - "./config/:/config"

  test:
    image: containous/whoami
    labels:
      - "traefik.enable=true"

traefik.yml:
entryPoints:
  web:
    address: ":80"
api:
  dashboard: true
  insecure: true
  debug: true
providers:
  docker:
   endpoint: "unix:///var/run/docker.sock"
   exposedbydefault: false
   defaultRule: "Host(`{{ .Name }}.localhost`)"
  file:
    directory: /config
    watch: true

config/config.yml:
http:
  routers:
    test:
      rule: Host(`test.localhost`)
      service: test-traefik-test@docker

Then run:
$ docker-compose up

Note that this works fine I can reach test.localhost as defined in the config file (not in the Docker labels!):
$ curl -v http://test.localhost
*   Trying ::1:80...
* TCP_NODELAY set
* Connected to test.localhost (::1) port 80 (#0)
> GET / HTTP/1.1
> Host: test.localhost
> User-Agent: curl/7.66.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 357
< Content-Type: text/plain; charset=utf-8
< Date: Fri, 13 Dec 2019 17:56:36 GMT
<
Hostname: 06dabf3b0828
IP: <IP_ADDRESS>
IP: <IP_ADDRESS>
RemoteAddr: <IP_ADDRESS>:33342
GET / HTTP/1.1
Host: test.localhost
User-Agent: curl/7.66.0
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: <IP_ADDRESS>
X-Forwarded-Host: test.localhost
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: e33c96377017
X-Real-Ip: <IP_ADDRESS>

* Connection #0 to host test.localhost left intact

However, in production, I want TLS, so I add:
tls:
  certResolver: le

to the config file, and define a corresponding cert resolver in the traefik.yml.
What did you expect to see?
I expected no errors.
What did you see instead?
I get such weird messages:
Starting traefik             ... done
Starting traefik-test_test_1 ... done
Attaching to traefik, traefik-test_test_1
traefik    | time="2019-12-13T17:55:50Z" level=info msg="Configuration loaded from file: /traefik.yml"
traefik    | time="2019-12-13T17:55:50Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=web routerName=test@file
traefik    | time="2019-12-13T17:55:50Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=traefik routerName=test@file
test_1     | Starting up on port 80
traefik    | time="2019-12-13T17:55:50Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=traefik routerName=test@file
traefik    | time="2019-12-13T17:55:50Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=web routerName=test@file
traefik    | time="2019-12-13T17:55:51Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=traefik routerName=test@file
traefik    | time="2019-12-13T17:55:51Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=web routerName=test@file

When running the production configuration, with certificate resolution, I get errors. Certificate resolution fails with errors similar to:
traefik    | time="2019-12-13T18:39:58+01:00" level=error msg="Unable to obtain ACME certificate for domains \"test.example.com\": unable to generate a certificate for the domains [test.example.com]: acme: Error -> One or more domains had a problem:\n[test.example.com] acme: error: 403 :: POST :: https://acme-v02.api.letsencrypt.org/acme/finalize/73738425/1746489749 :: urn:ietf:params:acme:error:orderNotReady :: Order's status (\"valid\") is not acceptable for finalization, url: \n" routerName=surfmeterServer@file rule="Host(`test.example.com`)" providerName=le.acme

This seems to be related to https://github.com/containous/traefik/issues/5317?
Output of traefik version:
2.1.0
If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
Starting traefik-test_test_1 ... done
Starting traefik             ... done
Attaching to traefik-test_test_1, traefik
test_1     | Starting up on port 80
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Configuration loaded from file: /traefik.yml"
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Traefik version 2.1.0 built on 2019-12-11T17:51:14Z"
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Static configuration loaded {\"global\":{\"checkNewVersion\":true},\"serversTransport\":{\"maxIdleConnsPerHost\":200},\"entryPoints\":{\"traefik\":{\"address\":\":8080\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{}},\"web\":{\"address\":\":80\",\"transport\":{\"lifeCycle\":{\"graceTimeOut\":10000000000},\"respondingTimeouts\":{\"idleTimeout\":180000000000}},\"forwardedHeaders\":{}}},\"providers\":{\"providersThrottleDuration\":2000000000,\"docker\":{\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ .Name }}.localhost`)\",\"swarmModeRefreshSeconds\":15000000000},\"file\":{\"directory\":\"/config\",\"watch\":true}},\"api\":{\"insecure\":true,\"dashboard\":true,\"debug\":true},\"log\":{\"level\":\"DEBUG\",\"format\":\"common\"}}"
traefik    | time="2019-12-13T18:00:46Z" level=info msg="\nStats collection is disabled.\nHelp us improve Traefik by turning this feature on :)\nMore details on: https://docs.traefik.io/v2.0/contributing/data-collection/\n"
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Starting provider aggregator.ProviderAggregator {}"
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Start TCP Server" entryPointName=web
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Starting provider *file.Provider {\"directory\":\"/config\",\"watch\":true}"
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Start TCP Server" entryPointName=traefik
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Starting provider *traefik.Provider {}"
traefik    | time="2019-12-13T18:00:46Z" level=info msg="Starting provider *docker.Provider {\"watch\":true,\"endpoint\":\"unix:///var/run/docker.sock\",\"defaultRule\":\"Host(`{{ .Name }}.localhost`)\",\"swarmModeRefreshSeconds\":15000000000}"
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Configuration received from provider file: {\"http\":{\"routers\":{\"test\":{\"service\":\"test-traefik-test@docker\",\"rule\":\"Host(`test.localhost`)\"}}},\"tcp\":{},\"tls\":{}}" providerName=file
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Configuration received from provider internal: {\"http\":{\"routers\":{\"api\":{\"entryPoints\":[\"traefik\"],\"service\":\"api@internal\",\"rule\":\"PathPrefix(`/api`)\",\"priority\":2147483646},\"dashboard\":{\"entryPoints\":[\"traefik\"],\"middlewares\":[\"dashboard_redirect@internal\",\"dashboard_stripprefix@internal\"],\"service\":\"dashboard@internal\",\"rule\":\"PathPrefix(`/`)\",\"priority\":2147483645},\"debug\":{\"entryPoints\":[\"traefik\"],\"service\":\"api@internal\",\"rule\":\"PathPrefix(`/debug`)\",\"priority\":2147483646}},\"middlewares\":{\"dashboard_redirect\":{\"redirectRegex\":{\"regex\":\"^(http:\\\\/\\\\/[^:]+(:\\\\d+)?)/$\",\"replacement\":\"${1}/dashboard/\",\"permanent\":true}},\"dashboard_stripprefix\":{\"stripPrefix\":{\"prefixes\":[\"/dashboard/\",\"/dashboard\"]}}},\"services\":{\"api\":{},\"dashboard\":{}}},\"tcp\":{},\"tls\":{}}" providerName=internal
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Provider connection established with docker 18.09.7 (API 1.39)" providerName=docker
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [web traefik]" routerName=test@file
traefik    | time="2019-12-13T18:00:46Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=web routerName=test@file
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Creating middleware" entryPointName=web middlewareName=traefik-internal-recovery middlewareType=Recovery
traefik    | time="2019-12-13T18:00:46Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=traefik routerName=test@file
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Creating middleware" middlewareType=Recovery entryPointName=traefik middlewareName=traefik-internal-recovery
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="No default certificate, generating one"
traefik    | time="2019-12-13T18:00:46Z" level=debug msg="Filtering disabled container" providerName=docker container=traefik-traefik-test-e33c96377017aedbb2a8f3c54428653ab85e4d6e508bbf91e648c24a9eb1eb40
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [web traefik]" routerName=test@file
traefik    | time="2019-12-13T18:00:47Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" entryPointName=web routerName=test@file
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" entryPointName=web middlewareName=traefik-internal-recovery middlewareType=Recovery
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware dashboard@internal" routerName=dashboard@internal middlewareName=tracing middlewareType=TracingForwarder entryPointName=traefik
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" entryPointName=traefik routerName=dashboard@internal middlewareType=StripPrefix middlewareName=dashboard_stripprefix@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareName=dashboard_redirect@internal entryPointName=traefik routerName=dashboard@internal middlewareType=RedirectRegex
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Setting up redirection from ^(http:\\/\\/[^:]+(:\\d+)?)/$ to ${1}/dashboard/" middlewareName=dashboard_redirect@internal entryPointName=traefik routerName=dashboard@internal middlewareType=RedirectRegex
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_redirect@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=debug@internal middlewareName=tracing middlewareType=TracingForwarder
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware api@internal" entryPointName=traefik routerName=api@internal middlewareName=tracing middlewareType=TracingForwarder
traefik    | time="2019-12-13T18:00:47Z" level=error msg="the service \"test-traefik-test@docker\" does not exist" routerName=test@file entryPointName=traefik
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareType=Recovery entryPointName=traefik middlewareName=traefik-internal-recovery
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="No default certificate, generating one"
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [web traefik]" routerName=test-traefik-test@docker
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="No entryPoint defined for this router, using the default one(s) instead: [web traefik]" routerName=test@file
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareType=Pipelining entryPointName=web serviceName=test-traefik-test routerName=test-traefik-test@docker middlewareName=pipelining
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating load-balancer" routerName=test-traefik-test@docker entryPointName=web serviceName=test-traefik-test
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating server 0 http://<IP_ADDRESS>:80" routerName=test-traefik-test@docker entryPointName=web serviceName=test-traefik-test serverName=0
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware test-traefik-test" entryPointName=web routerName=test-traefik-test@docker middlewareType=TracingForwarder middlewareName=tracing
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" routerName=test@file middlewareName=pipelining middlewareType=Pipelining serviceName=test-traefik-test@docker entryPointName=web
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating load-balancer" serviceName=test-traefik-test@docker entryPointName=web routerName=test@file
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating server 0 http://<IP_ADDRESS>:80" entryPointName=web routerName=test@file serviceName=test-traefik-test@docker serverName=0
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware test-traefik-test@docker" routerName=test@file entryPointName=web middlewareName=tracing middlewareType=TracingForwarder
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareType=Recovery entryPointName=web middlewareName=traefik-internal-recovery
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware api@internal" middlewareName=tracing middlewareType=TracingForwarder entryPointName=traefik routerName=debug@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware api@internal" middlewareName=tracing entryPointName=traefik routerName=api@internal middlewareType=TracingForwarder
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Added outgoing tracing middleware dashboard@internal" routerName=dashboard@internal middlewareType=TracingForwarder middlewareName=tracing entryPointName=traefik
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareName=dashboard_stripprefix@internal middlewareType=StripPrefix entryPointName=traefik routerName=dashboard@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Adding tracing to middleware" entryPointName=traefik routerName=dashboard@internal middlewareName=dashboard_stripprefix@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" routerName=dashboard@internal entryPointName=traefik middlewareType=RedirectRegex middlewareName=dashboard_redirect@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Setting up redirection from ^(http:\\/\\/[^:]+(:\\d+)?)/$ to ${1}/dashboard/" routerName=dashboard@internal entryPointName=traefik middlewareType=RedirectRegex middlewareName=dashboard_redirect@internal
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Adding tracing to middleware" routerName=dashboard@internal middlewareName=dashboard_redirect@internal entryPointName=traefik
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="Creating middleware" middlewareType=Recovery entryPointName=traefik middlewareName=traefik-internal-recovery
traefik    | time="2019-12-13T18:00:47Z" level=debug msg="No default certificate, generating one"

To me it looks like a race condition between the two providers; only when Docker is ready and announcing its services, everything works, but the certificate gets requested already before (from the File provider), and then proabably twice?

Hi! I'm Træfiker :robot: the bot in charge of communication regulation.
Thanks for your interest in Traefik!
We dedicate the issue tracker to bug reports and feature requests only. My advanced AI has spotted that your issue might be a configuration problem or relates to something that doesn't look like a bug.
To confirm this, please join our Community Forum and reach out to us on the Traefik section.
In case I'm wrong (well, that would be embarrassing :sweat_smile:), my developers will re-open the issue and fix me!
In the meantime, you can double check Traefik's documentation.


Use lake indexes to speed up queries

Similarly to what is done with the filter push down, grab simple
predicates in the immediate filter after the "from" and match these
with any created object indexes along query path.
For now this only supports single Field rules, but will eventually
expand to the other rule types.
Closes #3073

Need to add tests but this is feature complete, and from what I see actually working.


Bug? Continuous crashing on ESP8266 (not on ESP32) when OneWire::begin(pin) tries to run

Working with https://github.com/SignalK/SensESP, which used the https://github.com/PaulStoffregen/OneWire library for a couple of years without issue. Recently switched to pstolarz/OneWireNg and  pstolarz/Arduino-Temperature-Control-Library, and now several users are getting continuous crashes when using it with ESP8266, but not with ESP32. I've traced it down to somewhere inside the begin(pin) method.
The first line of the error from PlatformIO (VS Code) says Exception Cause: 9  [LoadStoreAlignmentCause: Load or store to an unaligned address]. I noticed that the following line in the begin(pin) method is trying to store the new OneWireNg_CurrentPlatform in a specific spot in memory:
_ow = new (_ow_buf) OneWireNg_CurrentPlatform
I removed the (_ow_buf) from that line, and the crash stopped. Unfortunately, I'm away from the rest of my equipment that consumes the data from this program, so I can't test it all the way through. But could this be the cause of the crash?

Yay, it's great to see that this bug got unearthed and fixed! It's been a showstopper for SensESP ESP8266 users for quite some time but I just haven't had the time to investigate...
If I may make a kind request - could you make a new release of OneWireNg now that this issue has been fixed? TIA!

@mairas Do you confirm the resent fix works of your setups?

Tried with ESP8266, that works now. But ESP32 is broken due to the recent ESP32-C3 commit. I made a separate issue for that: #17.
I'm digressing here, but that ESP32-C3 is actually a pretty great little chip. The cheapest MCU with an integrated CAN controller you can get... I'm planning on using the bare chip in some projects. Sure, you'll need an oscillator and a flash memory, but still some pretty great peripherals at very little cost.


HBASE-27896 Disable hdfs readahead for pread reads

I left the option in place, but just changed the default. If desired, I could just remove the option as well. I can't think of a case where it would be good to enable, am just trying to preserve compatibility if anyone has set it.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 27s
Docker mode activated.

Thanks @Reidddddd! Here's the list thread: https://lists.apache.org/thread/pokw1bwtr26hdbmlmx4tx1g1fczqrtxt. I'll add it to the ticket as well.

The spotless failure was more of a failure in the mvn process. I don't see any actual formatting issues in the log, and spotless previously succeeded. Going to merge.


Example maximum value incorrect

The Example on this page is incorrect, depending on how you look at it.
For people expecting a maximum size of 20GB would need to enter MAXIMUM=20480, as this value is GiB rather than GB.
Specifying MAXIMUM=20000 equates to a VHD file 19.53GB.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d4bf76f3-73e6-1d63-641f-847ca717bf18
Version Independent ID: dbfd6085-572c-e6d7-1b67-d993beea1927
Content: expand vdisk
Content Source: WindowsServerDocs/administration/windows-commands/expand-vdisk.md
Product: windows-server
Technology: windows-commands
GitHub Login: @JasonGerend
Microsoft Alias: jgerend

The following users don't have valid GitHub IDs, or are not collaborators on this repo: ingridatmicrosoft
gh issue comment 5436 -b ingridatmicrosoft

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


Create Equally distributed random BigNums

CURRENT:
EXPECTED: This should have numbers generated from 1 till 1000 which are equally distributed and randomly generated.

@all-contributors please add @sumitsinghhazard  for infra, tests

Deployed.
Closing the issue.


heaptrack detects memory leak on example in README

When trying this code on godbolt
rpp::source::from_callable(&::getchar)
   | rpp::operators::repeat()
   | rpp::operators::take_while([](char v) { return v != '0'; })
   | rpp::operators::filter(std::not_fn(&::isdigit))
   | rpp::operators::map(&::toupper)
   | rpp::operators::subscribe([](char v) { std::cout << v; });

I get a report for a memory leak. This might be a false positive.

Details of the tool report

heaptrack stats:
	allocations:          	5
	leaked allocations:   	2
	temporary allocations:	0
reading file "/app/heaptrack_interpreted.txt" - please wait, this might take some time...
Debuggee command was: ./output.s
finished reading file, now analyzing data:
MOST CALLS TO ALLOCATION FUNCTIONS
2 calls to allocation functions with 8.19K peak consumption from
_IO_file_doallocate
in /lib/x86_64-linux-gnu/libc.so.6
1 calls with 4.10K peak consumption from:
_IO_doallocbuf
in /lib/x86_64-linux-gnu/libc.so.6
_IO_file_underflow
in /lib/x86_64-linux-gnu/libc.so.6
_IO_default_uflow
in /lib/x86_64-linux-gnu/libc.so.6
getchar
in /lib/x86_64-linux-gnu/libc.so.6
auto rpp::details::from_callable_invoke::operator()<>(int (* const&)()) const
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:154
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:89
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:64
in /app/output.s
immediate_scheduling_while_condition<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/utils.hpp:101
in /app/output.s
defer_for<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/current_thread.hpp:157
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:45
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:38
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:130
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
drain<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:102
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
1 calls with 4.10K peak consumption from:
_IO_doallocbuf
in /lib/x86_64-linux-gnu/libc.so.6
_IO_file_overflow
in /lib/x86_64-linux-gnu/libc.so.6
_IO_putc
in /lib/x86_64-linux-gnu/libc.so.6
std::ostream::put(char)
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
std::basic_ostream<>& std::operator<< <>(std::basic_ostream<>&, char)
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
operator()
at /app/example.cpp:12
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/filter.hpp:34
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/take_while.hpp:32
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:62
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:89
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:64
in /app/output.s
immediate_scheduling_while_condition<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/utils.hpp:101
in /app/output.s
defer_for<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/current_thread.hpp:157
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:45
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:38
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:130
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
drain<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:102
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
1 calls to allocation functions with 144B peak consumption from
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/new_allocator.h:147
in /app/output.s
1 calls with 144B peak consumption from:
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocator.h:198
in /app/output.s
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/alloc_traits.h:482
__allocate_guarded<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocated_ptr.h:98
__shared_count<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr_base.h:969
in /app/output.s
__shared_ptr<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr_base.h:1712
in /app/output.s
shared_ptr<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr.h:464
in /app/output.s
make_shared<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr.h:1010
in /app/output.s
make<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/disposables/disposable_wrapper.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:132
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
1 calls to allocation functions with 24B peak consumption from
std::__new_allocator<>::allocate(unsigned long, void const*)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/new_allocator.h:147
in /app/output.s
1 calls with 24B peak consumption from:
std::allocator<>::allocate(unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocator.h:198
in /app/output.s
std::allocator_traits<>::allocate(std::allocator<>&, unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/alloc_traits.h:482
std::_Vector_base<>::_M_allocate(unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_vector.h:378
void std::vector<>::_M_realloc_insert<>(__gnu_cxx::__normal_iterator<>, rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/vector.tcc:459
in /app/output.s
std::vector<>::push_back(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_vector.h:1289
in /app/output.s
rpp::details::disposables::dynamic_disposables_container_base::push_back(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/disposables/details/container.hpp:30
in /app/output.s
rpp::details::observers::local_disposable_strategy<>::add(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/details/disposable_strategy.hpp:77
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:59
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:40
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/filter.hpp:41
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/take_while.hpp:41
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:134
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
1 calls to allocation functions with 73.73K peak consumption from
0x711ab3ec99ec
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
1 calls with 73.73K peak consumption from:
0x711ab408847c
in /lib64/ld-linux-x86-64.so.2
0x711ab4088566
in /lib64/ld-linux-x86-64.so.2
0x711ab40a22c8
in /lib64/ld-linux-x86-64.so.2
PEAK MEMORY CONSUMERS
73.73K peak memory consumed over 1 calls from
0x711ab3ec99ec
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
73.73K consumed over 1 calls from:
0x711ab408847c
in /lib64/ld-linux-x86-64.so.2
0x711ab4088566
in /lib64/ld-linux-x86-64.so.2
0x711ab40a22c8
in /lib64/ld-linux-x86-64.so.2
8.19K peak memory consumed over 2 calls from
_IO_file_doallocate
in /lib/x86_64-linux-gnu/libc.so.6
4.10K consumed over 1 calls from:
_IO_doallocbuf
in /lib/x86_64-linux-gnu/libc.so.6
_IO_file_underflow
in /lib/x86_64-linux-gnu/libc.so.6
_IO_default_uflow
in /lib/x86_64-linux-gnu/libc.so.6
getchar
in /lib/x86_64-linux-gnu/libc.so.6
auto rpp::details::from_callable_invoke::operator()<>(int (* const&)()) const
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:154
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:89
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:64
in /app/output.s
immediate_scheduling_while_condition<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/utils.hpp:101
in /app/output.s
defer_for<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/current_thread.hpp:157
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:45
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:38
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:130
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
drain<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:102
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
4.10K consumed over 1 calls from:
_IO_doallocbuf
in /lib/x86_64-linux-gnu/libc.so.6
_IO_file_overflow
in /lib/x86_64-linux-gnu/libc.so.6
_IO_putc
in /lib/x86_64-linux-gnu/libc.so.6
std::ostream::put(char)
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
std::basic_ostream<>& std::operator<< <>(std::basic_ostream<>&, char)
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
operator()
at /app/example.cpp:12
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/filter.hpp:34
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/take_while.hpp:32
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:62
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:107
in /app/output.s
on_next<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:33
in /app/output.s
on_next
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:89
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:64
in /app/output.s
immediate_scheduling_while_condition<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/utils.hpp:101
in /app/output.s
defer_for<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/current_thread.hpp:157
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:45
in /app/output.s
schedule<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/schedulers/details/worker.hpp:38
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/from.hpp:130
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
drain<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:102
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
144B peak memory consumed over 1 calls from
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/new_allocator.h:147
in /app/output.s
144B consumed over 1 calls from:
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocator.h:198
in /app/output.s
allocate
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/alloc_traits.h:482
__allocate_guarded<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocated_ptr.h:98
__shared_count<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr_base.h:969
in /app/output.s
__shared_ptr<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr_base.h:1712
in /app/output.s
shared_ptr<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr.h:464
in /app/output.s
make_shared<>
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/shared_ptr.h:1010
in /app/output.s
make<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/disposables/disposable_wrapper.hpp:135
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:132
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
24B peak memory consumed over 1 calls from
std::__new_allocator<>::allocate(unsigned long, void const*)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/new_allocator.h:147
in /app/output.s
24B consumed over 1 calls from:
std::allocator<>::allocate(unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/allocator.h:198
in /app/output.s
std::allocator_traits<>::allocate(std::allocator<>&, unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/alloc_traits.h:482
std::_Vector_base<>::_M_allocate(unsigned long)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_vector.h:378
void std::vector<>::_M_realloc_insert<>(__gnu_cxx::__normal_iterator<>, rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/vector.tcc:459
in /app/output.s
std::vector<>::push_back(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/stl_vector.h:1289
in /app/output.s
rpp::details::disposables::dynamic_disposables_container_base::push_back(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/disposables/details/container.hpp:30
in /app/output.s
rpp::details::observers::local_disposable_strategy<>::add(rpp::disposable_wrapper_impl<> const&)
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/details/disposable_strategy.hpp:77
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:59
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/map.hpp:40
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/filter.hpp:41
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/take_while.hpp:41
in /app/output.s
set_upstream
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observers/observer.hpp:60
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/sources/concat.hpp:134
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:85
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/details/chain_strategy.hpp:51
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:61
in /app/output.s
subscribe<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:189
in /app/output.s
operator()<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/operators/subscribe.hpp:156
in /app/output.s
operator|<>
at /opt/compiler-explorer/libs/reactive_plus_plus/v2/src/rpp/rpp/observables/observable.hpp:348
in /app/output.s
main
at /app/example.cpp:12
in /app/output.s
MOST TEMPORARY ALLOCATIONS
1 temporary allocations of 1 allocations in total (100.00%) from
0x711ab3ec99ec
in /opt/compiler-explorer/gcc-13.2.0/lib64/libstdc++.so.6
1 temporary allocations of 1 allocations in total (100.00%) from:
0x711ab408847c
in /lib64/ld-linux-x86-64.so.2
0x711ab4088566
in /lib64/ld-linux-x86-64.so.2
0x711ab40a22c8
in /lib64/ld-linux-x86-64.so.2
total runtime: 0.01s.
calls to allocation functions: 5 (625/s)
temporary memory allocations: 1 (125/s)
peak heap memory consumption: 82.09K
peak RSS (including heaptrack overhead): 4.72M
total memory leaked: 8.19K
</pre></p>
</details>

Yeah, that was my fear. Nonetheless, I wanted to report it so that another person could look at it.

Yeah, I see. Anyway, I'm pretty sure there is no memory leakage at all + I have memory sanitizer in ci, it have to warn about it in such an case


cameraview: remove glflush

You can revert https://github.com/commaai/openpilot/commit/7a3754d50b2325863259cb31b8da6c5e31990246  if the cpu usage is back to 20%

Do you still want to look into the blocking of glMap, or is this the best we can do?

glmap usually blocking for a few milliseconds, and occasionally more than 10ms, it's ok because it's run in vipc thread, the main  thread will not be blocked.
I can't think of other ways for the time being to improve the performance of async pbo.

Oh, assumed it was much more than a few ms. Then this is fine.

Weird, I really though CPU usage was lower when I tested this change before. Guess I didn't rebuild properly or something. There must be something else we can do to lower CPU.


Interactive Console Input (Learn.adacore.com) for Ada Get() not working

Hello Everybody,
My students raised this issue with me.
The online tutorial at learn.adacore.com under imperative programming and other section that make use of Get() e.g Get(N) under the if statement are not working as expected. Please see below screenshot:

If you hit the Run button, we only get the following:
 Console Output: $ gprbuild -q -P main.gpr Build completed successfully.
No input box to enter a value.
Please help!
On ==> https://www.jdoodle.com/execute-ada-online/
We could run same code with console input interactively as shown below:

And also on tryitonline.com ( https://tio.run/#ada-gnat ) as shown below:

Many thanks for all your efforts!
God blesses!!!
Best regards,
Sanyaade

Hello Everybody,
My students raised this issue with me. The online tutorial at learn.adacore.com under imperative programming and other section that make use of Get() e.g Get(N) under the if statement are not working as expected. Please see below screenshot:
If you hit the Run button, we only get the following:  Console Output: $ gprbuild -q -P main.gpr Build completed successfully. No input box to enter a value. Please help!
On ==> https://www.jdoodle.com/execute-ada-online/ We could run same code with console input interactively as shown below:
And also on tryitonline.com ( https://tio.run/#ada-gnat ) as shown below:
Many thanks for all your efforts!
God blesses!!!
Best regards, Sanyaade

Hi
This was reported over 3 years ago in 2021 but is still not working as of today. The prompt/input terminal still lacking
God blesses!!!
Regards


about passage-level human annotations

could you show us the human annotation score result of each passage? (which is used to calculate the Pearson and Spearman)

Hi @141forever
To obtain the passage-level score, we simply took the average of sentence-level scores, e.g., using np.mean(). We didn't perform weighting or anything extra.

To obtain the sentence-level score from labels, you can use the following mapping {"major_inaccurate": 1.0, "minor_inaccurate": 0.5, "accurate": 0.0}

thanks a lot! best wishes!


Horse token can't be bridged from taiko to ethereum

Describe the feature request
Description of the feature request here.Horse token can't be bridged from taiko to ethereum
Describe alternatives you've considered
There is no alternative
Additional context
Additional context here.

@shadab-taiko please confirm whether this is true.

Hi @trezagit could you give us more details as to what error you are facing when trying to bridge HORSE from L2 to L1?
I was able to successfully bridge HORSE from L2 to L1, pasting my transactions for your reference:
Bridge transaction on L2: https://l2explorer.a1.taiko.xyz/tx/0xa25e8992f493dc0199ec14df20fce16ec83d0f1d9b9b8ecd98b4982df11744a0
Claim transaction on L1:
https://l1explorer.a1.taiko.xyz/tx/0x98632bd000a4da9419a861a41b0a4b44905fa52fddadc15811c8f09c1f4e4d9e/internal-transactions

Hello. See what could be the problem.
First of all, you need to send tokens from ETH to Taiko, and in this case, transactions with a round amount of 1000 2000 3000 simply do not reach the user. I think this is a bug.
Solution: try to send an amount like 512 HORSE and then everything should reach Taiko and be fine.
Here are my transactions: https://l1explorer.a1.taiko.xyz/tx/0x8b8cc08c33edd6751682a0c6bca4bfea01244aeadc3e32cada9be0521338eef3 ( didnt get horse )
https://l1explorer.a1.taiko.xyz/tx/0xfbcfbf9e371be3c233ad65f9b38ecd55efef64729c1dadf6cc0883ea66a1e4ea ( got horse )
See HORSE amount
After pending i claimed horse: https://l2explorer.a1.taiko.xyz/tx/0x557ed071d839c26a1262a0ec0f588937a8f36e4a45c9a92e44fb80d68aa719aa
And sent back to ETH: https://l2explorer.a1.taiko.xyz/tx/0xd3f76c2a18932522946316c076037eb1f5dae3e8f7f8192b147d6dc0acd8c608
Was glad to help you. WhiteGod#8401

@0xWhiteGod the first transaction you listed is an approval for ERC20 approve method.
To be able to bridge you must first approve then transfer.
You approved for 1000, then transfer for 512.

@0xWhiteGod the first transaction you listed is an approval for ERC20 approve method. To be able to bridge you must first approve then transfer. You approved for 1000, then transfer for 512.

After that, I tried again to send 1000 and 1500, and still nothing worked.

Hey @0xWhiteGod , here's a step by step along with some screenshots to help you bridge ERC20 tokens:

Enter the amount in the field and Approve the bridge contract to be able transfer the ERC20 tokens. Metamask (or whichever wallet you are using) pops up and asks you to submit a transaction.

The button on the UI now changes to Bridge.

After the above transaction is confirmed you can see the transaction in the transactions tab

You will have to wait some time before the tokens can be claimed on the destination chain. Once you see the Claim button and click on it, depending on which chain you wallet is currently pointed to:

If bridging from L2 to L1 and you are on L2, the wallet will first pop up and ask you to confirm switching the chain to L1
and then pop up to ask you submit the Claim transaction. If the wallet doesn't ask you to switch the chain you can
first change the chain manually in the wallet and then come back to the UI and click on Claim again.
If bridging from L2 to L1 and you are on L1 the wallet will straightaway pop up to ask you submit the Claim
transaction.

Also sharing with you links to my transactions bridging 1000 HORSE from Taiko (L2) to Ethereum (L1):
ERC20 Approval: https://l2explorer.a1.taiko.xyz/tx/0xdc6d88c528b3b7be9ff8aeef4f128e093c44fdef63e41b5d4dcdc159bbe80b2a
Bridging: https://l2explorer.a1.taiko.xyz/tx/0xd5a54ca8530ea639cf585762343bbcf7b33ee5c1a206f1ebfe1eee7b6f555709
Claim on L1: https://l1explorer.a1.taiko.xyz/tx/0x2839e90da5745630675c63a95d66ea14d44743121a5e2fef34203b59fdd2dc76

Closing due to duplciate issue + seems to be issue on user's end, only approved.


Select which gpu to train on

Is your feature request related to a problem? Please describe.
I am trying to train yolo-nas in an environment with multiple gpus (device=0 and 1), but I only want to use 1. Is there a way to train the model specifically in the 2nd gpu (device=1)
Describe the solution you'd like
Train the model by only using the 2nd gpu
Describe alternatives you've considered
Nothing really.

export CUDA_VISIBLE_DEVICES=0 python -m super_gradients.train_from_recipe ...

You can always pass target device to instance of Trainer manually if you want:
trainer = Trainer(..., device = "cuda:1")

You can set it with env variables at the beginning of your script
import os
os.environ['CUDA_VISIBLE_DEVICES'] = "0,3,4,5"

... # Script you are using

Already tried, but it's giving me a KeyError: "Trainer does not accept anymore 'device' and 'multi_gpu' as argument. Both should instead be passed to super_gradients.setup_device(device=..., multi_gpu=..., num_gpus=...)"

Trainer(device=...) is legacy and will soon be removed from SG.
The same can be done with
from super_gradients.training.utils.distributed_training_utils import setup_device

setup_device(device=...)

But this is only useful if you want to train on cpu, or with multiple gpus (DP/DDP). The default behavior is single GPU so you don't need to call it in your case


Update Dockerfile example

Hey I would not recommend this Dockerfile approach. It is less secure (running Pynecone as root) and the image size will be blown up by a lot of unnecessary software.

The Dockerfile is missing basic functions like the default entrypoint of the image. which is called when the image is started without command, as present in the current example. Likewise, Pynecone will launch the project in dev mode.  Likewise, Pynecone will launch the project in dev mode. In addition, an Ubuntu base image is not necessary, Python-slim is sufficient and is by far smaller than the result of the build. I would not recommend doing an image build based on this Dockerfile, as it gives the impression that it can be used productively that way.

I see nice fix will test this today.


fix group mounting paths

Reference Issues or PRs
fixes #2737

What does this implement/fix?
Put a x in the boxes that apply

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds a feature)
[ ] Breaking change (fix or feature that would cause existing features not to work as expected)
[ ] Documentation Update
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build related changes
[ ] Other (please describe):

Testing

[ ] Did you test the pull request locally?
[ ] Did you add new tests?

How to test this PR?

Any other comments?

Before

after these changes


Turn Off Autoplay not working (21h1)

I'm trying to use Administrative templates / settings catalog or Custom profile following https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-autoplay to turn off Autoplay without success.

@Malanho
Can you link to the article that you are referring to? Thanks.


added error handling for invalid handlers and some debug messages

Hi,
first of all, sorry if I did something wrong, its the first time I fork/create a pull request.
Regarding the issue #5 I thought of some tiny additions.
I added some debug messages for example if the controller that gets passed is not an object (basically what caused my problems regarding issue #5,
wrote a little check, if those handlers are actually existing before they are called,
and made it configurable if an exception shall be thrown if they can not be called.
cap5lut

No problem, there is a first time for all :)
But can you please move the class to manage exception into another file?
After can you please add tests for that piece of code?
Is possible?
Thanks for your contribute!
P.S. remember that I have make some little edit, so make a rebase of your branch with new version 3.0.2 to be sure if you have take code from v 3.0.1

I'll do it as soon as possible, currently I'm busy.

Ok I'll waiting for your update :)

Sorry for the long delay, moved the exception to its own file and added the tests, the base is at v3.0.2 as well


Conditional Displayer Dropdown not loading properly on Server/app-service

Hi,
I was using Our.Umbraco.ConditionalDisplayers v2.3.4 on Umbraco latest v8 and now migrated to V11.4.2, and installed with Our.Umbraco.ConditionalDisplayers v3.4.0, everything loads and works fine with my local laptop, but the same when deployed to Azure app service the datatype are not loading properly and even in content section the property not loads, along with an angular console error, attaching a screenshot.
Error Screenshot from Server

No Error screenshot from local

Also, I see that from server url browser console source i dont see conditional displayers --> prevalueditors--> controller js file not loading

But the same loads in local

looking for some suggestions/help here or what's wrong am I doing
Thanks,
Gurumurthy JV

@gurumurthyjv in you csproj add the below and republish, test and see if that helps.
<ItemGroup>
    <Content Include="App_Plugins\**" CopyToOutputDirectory="Always" />
</ItemGroup>


Sync changes from grpc.io's version wire.md

wire.md was deleted in https://github.com/grpc/grpc.github.io/pull/601 to avoid duplication.
Some changes to wire.md weren't synced, so syncing them now.

Docs only change, merging.


metasploit: 6.1.14 -> 6.1.15

Motivation for this change
Update to latest upstream release 6.1.15
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 146555 run on x86_64-linux 1

1 package built:

msf (metasploit)


MT Safe Array & Hash

I think one of the biggest roadblocks for MT Usage is SafeHash and SafeArray.
I've been playing around with some concepts together with suggestions from @bcardiff.
Array is here: https://github.com/NeuraLegion/mt_helpers/blob/master/src/mt_helpers/safe_types/safe_array.cr

class SafeArray(T)
  include Synchronizable

  getter :inner

  def initialize(@inner : Array(T) = Array(T).new) forall T
    @synchronize_lock = Mutex.new(:reentrant)
  end

  macro method_missing(call)
    synchronize do
      @inner.{{call}}
    end
  end

  def safe_inner
    synchronize do
      @inner.dup
    end
  end
end

Hash is here: https://github.com/NeuraLegion/mt_helpers/blob/master/src/mt_helpers/safe_types/safe_hash.cr
class SafeHash(K, V)
  include Synchronizable

  getter :inner

  def initialize(@inner : Hash(K, V) = Hash(K, V).new) forall K, V
    @synchronize_lock = Mutex.new(:reentrant)
  end

  macro method_missing(call)
    synchronize do
      @inner.{{call}}
    end
  end

  def safe_inner
    synchronize do
      @inner.dup
    end
  end
end

This seems to be the minimal changes needing to make access to the structures safe.
Any feedback?
P.S
module Synchronizable
  @synchronize_lock = Mutex.new

  protected def synchronize(lock : Mutex = @synchronize_lock)
    lock.synchronize do
      yield
    end
  end
end

You could easily have a generic wrapper like this:
class Synchronized(T)
  def initialize(*args)
    @value = T.new(*args)
    @lock = Mutex.new(:reentrant)
  end

  macro method_missing(call)
    @lock.synchronize do
      @value.{{call}}
    end
  end

  def inspect(io)
    @value.inspect(io)
  end
end

arr = Synchronized(Array(String)).new
arr << "a" << "b"
p arr

I don't see much value on including a wrapper that just synchronizes on every method access, even on things that might not need synchronization. If we include a Thread-safe container, it should either be lock-free (nice but complex) or "lock-minimal", to only lock on some operations. Not a priority, I would say.

@lbguilherme I think lock-free is a nice dream :) but I don't see that happening, so let's talk lock-minimal.
We have this generic structure here: https://github.com/NeuraLegion/mt_helpers/blob/master/src/mt_helpers/synchronized.cr
What list of actions would you suggest be part of the lock?
It might not be a Priority to you btw, but it is a priority for people using MT daily :)

I think for people using MT daily the solution is to use channels and communicate data through data, not sharing values between fibers.

@asterite that's usually the case, but sometimes you need a container that holds and aggregates information to be used by multiple Fibers.

@lbguilherme I'm asking cause I really want to know, there are things which are a mystery to me, like, should Array.each be protected? or only things which changes the actual array (delete, <<)

@bararchy It depends a lot on the internals and mostly require some use of Atomics. For example, if we change the array size and buffer pointer to be Atomics it is then possible to access, iterate, push new values to the end with only the last one needing to synchronize. But it won't be possible to change an element in the middle or remove anything. It could be possible to use an intermediary array of Atomic pointers to the real values (much like Qt's QList) and then it would be possible to change elements too, but still not remove.
All those changes have performance impacts (that are smaller than the synchronization overhead, ofc) ans requires changing the container implementation. The current container does require synchronization on ALL method calls. not very optimal.
If you have some global state shared between fibers, it is better to have an explicit lock, because then you can acquire the lock and do multiple operations at once, instead of acquiring it per operation. You can also consider using immutable data (swapping the whole container when something changes), depending on your usecase.
My opinion: Having anything better than "synchronize on all methods" requires creating a new container implementation with specific MT care. Either the stdlib has a full MT implementation (lock-minimal, at least) or then doesn't have anything at all. Synchronization can be made on user code.
Note: on Ruby all containers are thread-safe (but actually their "threads" are much more like single thread fibers and we are "fiber-safe").

Thanks for taking the time and explain this

Seems like something like this would be useful in certain cases...

Reason for closing: As stated above, we moved to use mainly https://github.com/NeuraLegion/generic_actor instead of the Mutex based logic.


Remove Elasticsearch 6.3 logic

Rally only supports Elasticsearch 6.8+.

Please take another look!


Examples: with-nestjs example implementation

What is the improvement or update you wish to see?
It would be great to have a with-nestjs example integrated
Is there any context that might help us understand?
Starting a NestJs project managed within turbo-repo is just great and I recommend it!
However, the turbo repo doesn't include an official example to start a NestJS Turbo-repo project.

If it's possible, I'm volunteering to contribute to this one

No one on our team has experience with Nest.js so we'd appreciate a contribution for this!

@Neosoulink what the config you use in launch.json for debug purpose?

Hey @Cirilord,
I did not integrate a launch.json for this example

https://github.com/vercel/turbo/pull/8162

Do you have any idea what it would look like?

@Cirilord,
I'm not sure about the context... Could you share more details or needed behavior?

Sure, i'm trying to create a configuration inside launch file to debug my nextjs application

@Cirilord okay...
Note that you're free to configure your debugger as you prefer and it's beyond this issue's scope.
But, as an example, if you want to set a configuration that launches both apps in development mode (/api and web), you can use TurboRepo as follows:
{
  "version": "0.0.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Launch apps in dev mode (using turbo repo)",
      "runtimeExecutable": "pnpm",
      "runtimeArgs": ["run-script", "dev"],
        "env": {
          "NODE_ENV": "development"
      },
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen"
    }
  ]
}

This configuration will execute the script at the root of your project and will launch your apps/packages in the development mode.

Thanks @Neosoulink! It worked very well


fix: implemented temporary workaround suggested by TileDB. (#2251)

Reviewers
Functional:
@bkmartinjr, @MDunitz
Readability:
@ebezzi

Changes

modify: TileDB-Py version 0.9.5 -> 0.10.0 plus workaround for threading issue

Reviewer Notes

Bruce provided a bug repro to TileDB which showed that the failure occurs on TileDB-Py versions 0.8.8 and above, including the current version, 0.10.0.
This temporary workaround was suggested by Seth from TileDB.

Note, as discussed at the war room meeting, holding off on merging this workaround until 15:00 PT today til we hear back from TileDB regarding an ETA for a fix.


Edit delete feature in user guide

Codecov Report

Merging #19 (67a416a) into ug (eaf8bde) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##                 ug      #19   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

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 eaf8bde...67a416a. Read the comment docs.