GSI::GetUserInfo    : api::403 Forbidden

have you logon hoyolab.com?

have you logon hoyolab.com?

yes

I think hoyoverse makes the server separate from global server. and i don't know that server url.
If not you chainesse!!, you can shard infomation more?  as..

what full link your login?
what os, chrome version
capture a network tab in a DevTools and all request this.

https://act.hoyolab.com/ys/event/signin-sea-v3/index.html?act_id=e&hyl_auth_required=true&hyl_presentation_style=fullscreen&utm_source=hoyolab&utm_medium=tools&lang=zh-cn&bbs_theme=light&bbs_theme_device=1
win11 22h2 Dev 23451.1000  chrome/113.0.5672.93

It's china server,  i can't access
but if you capture a request this all in network tab on a DevTools, Maybe I can help you.

HK TW MO server
i don't know how can do it
like this?

i want network capture with 3 path:
/event/luna/os/home
/event/luna/os/info
/event/luna/os/sign
and you current all cookie name please hidden value with domain hoyolab.com


Enable-WriteCore-for-Azure.AI.AnomalyDetector

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.AI.AnomalyDetector


Very hard to use with angular2 cli

The angular2 cli uses webpack to bundle the files, and really I have no idea how to integrate d3-tip.
d3 can be imported using
import * as d3 from 'd3'
but importing * as d3tip from 'd3-tip' for example doesn't work
There is also an option to install globally using the scripts field in angular-cli.json, but this also seems not to work
can anyone recommend how to do this, and what might be the problem?
When I import it, i can see  the file in the console, but i get the following message
EXCEPTION: Uncaught (in promise): TypeError: __WEBPACK_IMPORTED_MODULE_1_d3__.tip is not a function
TypeError: __WEBPACK_IMPORTED_MODULE_1_d3__.tip is not a function

import d3Tip from 'd3-tip';

Is the correct way to write that import statement.
When you use import *, you're actually saying "import everything that this module exports as this one object". What was once one giant module, d3 is now a collection of smaller independent modules that can be imported separately for smaller dependencies.
For more information about ES6 modules, see this article about the import and export syntax:
http://www.2ality.com/2014/09/es6-modules-final.html
For more information about d3's decision to move towards a collection of smaller libraries, see these release notes:
https://github.com/d3/d3/blob/master/CHANGES.md

Hi vdh
Thank you very much for answering, and I apologize for the poor example I used with import {* as d3Tip}. I have  been bashing my head out on this one for a long time and I think there is a deeper issue here.
I have tried the following options.
For example, yes i have tried
import d3Tip from 'd3-tip'
and also I have tried changing the d3-tip/index.js to export an es6 module so i can import it with
import {d3Tip} from 'd3Tip'
and I also tried using the d3Tip conversion to es6 by moglars
https://github.com/Caged/d3-tip/pull/166
and I have spent a lot of time on the typings files.
in all cases I am successfully importing the file. This can be seen using the chrome dev tools, but the problem is that the d3Tip.tip() function is not accessible, with the error message I have reported above, and I may be wrong here, but I have the feeling that this is related to the angular2-cli and its recent migration to webpack.
Reason: i came across this thread here:
http://stackoverflow.com/questions/39411091/d3-tip-doesnt-work-with-webpack
The author suggests there are some hoops that can be jumped through with a plugin, specifically
single-module-instance-webpack-plugin and maybe also dedupe-plugin
but with angular2-cli one cannot directly access the webpack.config.js
and also this thread here:
http://stackoverflow.com/questions/40861009/using-plugins-for-d3-in-angular2
user Velko Ivanov suggests this may be a problem with the way webpack handles modules sharing namespace, in particular when the d3 object is initially declared as null and then has methods added through a series of internal function calls, which is how the d3 object is created.
At present I have given up on this and have been writing my own (inferior) tooltip, since it seemed to me very difficult. (btw, this tooltip should be part of the standard d3 library)
Look, if I am just being stupid, then that's great, very sorry for wasting your time.

@Joegrundman

but the problem is that the d3Tip.tip() function is not accessible

Ahh, I think you need to be using d3Tip() instead? d3.tip() is only available on the d3 global when loaded outside of AMD or CommonJS environments. As of<EMAIL_ADDRESS>the CommonJS loader is anonymous (see explanation below).
My original reply I was writing, before I noticed that:
Which versions of d3 and d3-tip are you using, and are you using<EMAIL_ADDRESS>is designed for<EMAIL_ADDRESS>and<EMAIL_ADDRESS>is for d3@^3. There's also the<EMAIL_ADDRESS>alpha in development for the d3 micro libraries.
I've been using Webpack with<EMAIL_ADDRESS>+<EMAIL_ADDRESS>and later<EMAIL_ADDRESS>with the micro libraries, so it should be working within Webpack. So this is either a Webpack config issue or a bug in d3-tip that would need patching.
I know that in earlier versions of d3-tip, the CommonJS version had a bit of a weird use case where it returned a factory that modified the d3 variable passed into it, e.g.
//<EMAIL_ADDRESS>import d3 from 'd3';
import d3TipFactory from 'd3-tip';
const d3Tip = d3TipFactory(d3);
const tip = d3Tip(); // or const tip = d3.tip();

With 0.7.0, I updated it to properly use require('d3') and return an anonymous library, e.g.
//<EMAIL_ADDRESS>import d3Tip from `d3-tip`;
const tip = d3Tip();

Thanks a  lot @vdh, that did it. It was a simple thing!

Unfortunately this still isn't working for me. I'm using Typescript 2.4 with D3 V4 and both of the above give a similar error:
import d3Tip from 'd3-tip';
const tip = d3Tip();

The above gives "Cannot invoke an expression whose type lacks a call signature. Type 'typeof' "C:/my_project_root/node_modules/@types/d3-tip/index" has no compatible call signatures." No surprise, but there is also no tip() method on there either.
If I try the more verbose solution:
import * as d3 from 'd3'; // This works fine with all pure d3 code
import d3TipFactory from 'd3-tip';
const d3Tip = d3TipFactory(d3);
const tip = d3Tip();
I get the same call signature error on d3TipFactory(d3);.
Whilst I'm sure I'm just doing something simple wrong I have to agree somewhat with the sentiment expressed in the title of this bug. Why is it so hard to import d3-tip?
Thanks for the help!

Yes, I am also having issue on importing d3-tip as above.

import like this:
import * as d3Tip from 'd3-tip';

Use it like this:
this.tip = d3Tip().attr('class', 'd3-tip').html((d) => 'test' );

This seems to be a good starting point: http://bl.ocks.org/Caged/6476579

Using d3-tip 0.7.1, @types/d3-tip 3.5.5, angular 5.2.4 and typescript 2.5.0 I had to import d3-tip using the code snippet below in one of my components:
import * as d3Tip from "d3-tip";
(d3 as any).tip = d3Tip;```

This solution was suggested in a (StackOverflow answer)[https://stackoverflow.com/questions/45569419/d3-tip-is-not-a-function-webpack-and-typescript]. Then, in order to overcome a type check error when invoking the tooltip in the component visualization context I had to use the keyword `as`:

```this.svg.call(this.detectorTooltip as any);```

Hope this helps another poor soul trying to get this to work.

thanks dereklin , your solution works for me i loved it

I created a (semi) working example in StackBlitz, check it out: https://stackblitz.com/edit/d3-tip-angular-example?file=app%2Fd3-chart%2Fd3-chart.component.ts
I say "semi" because the screen location of the tip is messed up. The tips are anchored at the top of the screen instead of appearing above the mouseover point. The console says it can't figure out the bounding box:
ERROR TypeError: Cannot read property 'target' of null at getScreenBBox

Perhaps someone smarter than me can help debug this and get it working properly.
Note, here is how to import the library in StackBlitz:
import d3Tip from 'd3-tip' // works

This appears to be unique to StackBlitz projects, however, because the following import works fine for my offline Angular 6 project:
import * as d3Tip from 'd3-tip' // doesn't work

However, in my actual offline project I haven't succeeded in getting my tips to show up. tip.show is calling fine, but my tips are invisible. I suspect it is due to the same problem reported in StackBlitz. Would appreciate any help.

This is what seems to be working for me.
import * as d3 from 'd3';
import d3Tip from 'd3-tip'

d3.tip = d3Tip;
const tip = d3.tip()
      .attr('class', 'd3-tip')
      .html(function(data) {
        return data.date.format('ll'); // Format: Sep 4 1986
      })
      .direction('n')
      .offset([-6, 0]);

@jplew thank you so much for this. I'm just learning D3 now and I'm using it in an Angular 6 app, and your Stackblitz was the key to getting it to work.

Using d3-tip 0.7.1, @types/d3-tip 3.5.5, angular 5.2.4 and typescript 2.5.0 I had to import d3-tip using the code snippet below in one of my components:
import * as d3 from "d3";
import * as d3Tip from "d3-tip";
(d3 as any).tip = d3Tip;

This solution was suggested in a StackOverflow answer. Then, in order to overcome a type check error when invoking the tooltip in the component visualization context I had to use the keyword as:
this.svg.call(this.detectorTooltip as any);

Hope this helps another poor soul trying to get this to work.

I am the poor soul here having tried every page from the web's book. This is best solution for me. Kudos.
(d3 as any).tip.show()
(d3 as any).tip.hide()

for anyone else trying to figure out.

Okay, so going through many SO posts and tuts around, I found the d3-tip typings lib to be the culprit. I had to silently uninstall this
npm uninstall @types/d3-tip
Then I make changes like
import * as d3 from 'd3';
import * as d3Tip from 'd3-tip';
....

const tip = d3Tip.default()
.attr('class', 'd3-tip')
....

This tip can be used anywhere like
svg.call(tip)
// or
tip.show()
tip.hide()

Then I stop/start the angular server, the errors are all gone. Now hoping it will work finally. :)


The link to "Using the Registry in a Driver" is broken (404)

The link to "Using the Registry in a Driver" in this page (https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-the-registry-in-a-driver) is broken (404 Not Found)

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

ID: b636b5a9-c3b9-b80f-6c5a-e1da53418cdc
Version Independent ID: 065eb7fc-9b4e-1493-471e-fd49d1f2b7c4
Content: ZwOpenKey function (wdm.h) - Windows drivers
Content Source: wdk-ddi-src/content/wdm/nf-wdm-zwopenkey.md
Product: windows-hardware
Technology: windows-devices
GitHub Login: @tedhudek
Microsoft Alias: tedhudek

Thanks for the heads-up @rhymu8354.  I put a redirect in place.


Demonstrate backward-compatible deprecation of enums

I would like to get rid of using C# enums in the SDK. They unnecessarily constrain the
values that a user can send to the ShipEngine API. The API expects a string, the SDK
should allow the user to specify a string. An enum requires converting values to an integer,
which has no value for our purposes. It also leads to awkwardness when the default is 0,
which will correspond to an enum value we don't necessarily want. It requires the user
to update their SDK any time there is a new possible value accepted by the API.
We can still provide guidance for valid values via classes that expose static strings.
However, there is likely code in the wild where users are setting properties to an enum value.
This is an experiment to demonstrate using implicit conversion operators, and a custom JsonConverter,
to allow a user to set a "string enum" value using a string or an enum.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

46 of 58 (79.31%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.1%) to 84.271%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

ShipEngine/Models/Dto/CreateLabelFromShipmentDetails/StringEnum.cs
41
53
77.36%

Totals

Change from base Build<PHONE_NUMBER>:
-1.1%

Covered Lines:
690

Relevant Lines:
793

💛  - Coveralls


First MenuItem in a Menu is no longer auto focusable.

Expected Behavior 🤔
It is expected that the first item of a menu should be focused by default when opening the menu. This should occur because the default value for the "disableAutoFocusItem" prop is false. Explicitly setting this prop to false, and the "autoFocus" prop to true, does nothing however, indicating that the feature itself is broken.
Current Behavior 😯
The first item is never focused, regardless of the prop values you supply to "disableAutoFocusItem" and "autoFocus".
Steps to Reproduce 🕹
The examples for the Menu Component will show that this behaviour is not working.
Your Environment 🌎
Windows 10
Latest versions of Chrome // Firefox.
@Material-ui/core 4.2.0

Should be closed by #17506.


Parallel recovery for nodePool with 2 replicas

Config -
  nodePools:
    - component: masters
      replicas: 2
      resources:
         requests:
            memory: "1Gi"
      roles:
        - "data"
        - "cluster_manager"
      diskSize: "1Gi"

When I delete only one pod, the pod starts up again and the 2 pods are able to form quorum again. But if I delete both the pods, only one pod comes up at a time as sts has OrderedReady podManagementPolicy so the single pod is not able to form a quorum. The parallel recovery should also kick in in this case and allow both the pods to come up together.

But the operator doesn't explicitly disallow down-scaling clusters right? There can be a use-case where a user had to temporarily scale down the cluster to 2 replicas and something went wrong during that time.

@saketmht There is no technical limitation in the operator on having less than 3 nodes, correct. But with less than 3 it will not behave correctly.

There can be a use-case where a user had to temporarily scale down the cluster to 2 replicas and something went wrong during that time.

I'd consider that an edge case not worthy of extra logic.
Without having checked the code or tested it: If you had 3 replicas deployed (so the PVCs are there), scaled down to 2, lost one, and then changed replicas back to 3 it should start the recovery.

@swoehrl-mw I don't think it requires any extra logic. The current parallel recovery code should be more than enough.
https://github.com/Opster/opensearch-k8s-operator/blob/4edd47a61f05e2a3b2e38d826f9fb5ca33e55f1f/opensearch-operator/pkg/reconcilers/cluster.go#L179
Changing this to
if pvcCount >= int(nodePool.Replicas) && existing.Status.ReadyReplicas < nodePool.Replicas-1 {

should do the job and I think comparing with ReadyReplicas is actually more accurate than just the Replicas count.

@idanl21  @saketmht I tested with replacing Replicas to ReadyReplicas, and it works fine and with 2 replicas, pods are able to come back up, I tried few other scenarios as well to make sure it doesn't break any existing path.

Scaling up and scaling down after recovery for 2 replicas
Trying recovery for more than 2 replicas
Is there anything specific which you would think should be tested before I raise a PR?


conformance: Github action not building image with git version

For some reason, Github action does not have access to the .git directory:
Step 5/9 : RUN make conformance-binary && mv output/conformance.test /conformance.test
 ---> Running in 66d264dd2646
fatal: not a git repository (or any of the parent directories): .git
cd conformance && \
	CGO_ENABLED=0 go test -c -o /go/src/github.com/opencontainers/distribution-spec/output//conformance.test \
		--ldflags="-X github.com/opencontainers/distribution-spec/conformance.Version="
go: downloading github.com/opencontainers/distribution-spec v1.0.0-rc0.0.20200108182153-219f20cbcfa1

Perhaps we use build args instead of relying on git?

Once #104 is merged, build args will be available, but im not seeing ways to do this with github actions..
I think a more sensible approach would be to point to a remote image (via docker:// syntax, see here), that is pushed by this repo, tagged to some release. Maybe even move the action into its own repo "distribution-spec-conformance-action"

Related GitHub support ticket: https://github.community/t5/GitHub-Actions/Feature-Request-Build-args-support-in-Docker-container-actions/m-p/37802

@jdolitsky is this still an issue?

@jdolitsky is this still an issue?

@vbatts not quite. But waiting to use the github image until a release is made: https://github.com/opencontainers/distribution-spec/blob/master/action.yml#L11
Will rename this to reflect

@vbatts not quite. But waiting to use the github image until a release is made: https://github.com/opencontainers/distribution-spec/blob/master/action.yml#L11
Will rename this to reflect


Add more detailed metrics to http_sd_config

Proposal
It would be nice to get metrics from within Prometheus as to whether an http_sd_config refresh succeeded or failed.  It would also be nice to have the timestamp of the last time an http_sd_config succeeded. Right now, the only metric I can find is prometheus_sd_refresh_failures which only notifies of global service discovery failures. Examples of other service discovery metrics are:

prometheus_sd_dns_lookups_total / prometheus_sd_dns_lookup_failures_total
prometheus_sd_file_mtime_seconds / prometheus_sd_file_read_errors_total

Use case. Why is this important?
If service discovery is not operating, it's possible that critical hosts are not being monitored. Therefore it's important to monitor each SD refresh and alert if a failure happened -- this requires metrics to alert on. The best available metric I can find, prometheus_sd_refresh_failures, does not break down by SD provider or config name, making it difficult to diagnose what is going on.
It's possible that this information is available in a different metric that I wasn't able to find -- maybe some kind of HTTP scraping metric? If so, then feel free to close this issue! Regardless, it might be helpful to update https://prometheus.io/docs/prometheus/latest/http_sd/ with a list of metrics applicable to http_sd.
Thanks for taking the time to read this, and thanks for making such an awesome monitoring platform!

This makes sense. I am not sure that last successful timestamp is userful. it is useful with file_sd as the value will generally not change. But we could definitively have a failures counter.

@mst-ableton I put up a PR that adds the prometheus_sd_http_failures_total counter metric, with a url label set to the value in the config. Let me know if you want anything additional.

@David-N-Perkins that PR looks great, thanks for taking the time to work on it!

@mst-ableton I need to remove the url label from the metric, because multiple http_sd_config's with the same value would cause a panic. So there will be a single prometheus_sd_http_failures_total counter metric for all http_sd_config's. I wanted to make sure that still works for you.

The PR is merged. I think this can be closed now.

Thanks!


feat: show queue banned

This is a very temporary solution. Randomly decides not to work and does not auto update. Web rewrite soon:tm:...

Probably don't want to merge this if it isn't consistently working.

It's a short term fix. /shrug


Reinsertion into source

Given today's published news regarding 2-player support in Super Punch-Out, would it be possible to have your multi-player support additions to be reinserted into the source ROM?

You mean patching the Fight Night ISO to allow two controllers in Super Punch-Out? Technically, yes, it would be pretty simple, and it could be distributed in the form of an ips patch or similar, but what's the benefit? You can already use fn22snesticle to play Super Punch-Out with two controllers, and without having to load up Fight Night first.

Yes! Exactly! Thank you for your reply.
As for the question around the benefit, I will refer to your FAQ:
Why would I use this when Snes9x is already ported to the Gamecube?
 This is SNESticle!

I still don't get it. It's SNESticle either way. Why would you want it on a 1.5 GB ISO where you have to wade through the Fight Night menus rather than a 5 MB ISO which boots directly into Super Punch-Out?

I agree its more practical to run the emulator as you have already provided directly from Swiss. This request as more of a feature enhancement and correction to Fight Night Round 2. The purpose would be to showcase the new 2-player discovery in Super Punch-Out, accessed in a way that has been made commercially available.

Ok, I see, and while I do appreciate efforts to bugfix and improve old games, I guess I just don't care enough in this instance. I've never played a Fight Night game in my life and I would much rather just have SNESticle. But feel free to take a stab at it. Like I said, it should not be difficult. The controller patches are in the p_main dictionary. The target offset might be different on a real Fight Night ISO, though. And the patch will remap the buttons unless you also apply the patches for literal button mapping (located further down in the script).

Thanks, again - and also thank you for your work on making SNESticle available on GameCube, and the excellent devlog you created for this.
I do have a fondness for Fight Night Round 2 and decided to take a stab at it this. My thought was to use your python script and only keep the p_main dictionary keys and values that would be necessary for additional controller inputs and the literal joypad mappings. I could then take the created SNESticle ISO and use Dolphin to extract the main.dol as a replacement for Fight Night's main.dol.
With this approach, Fight Night was able to load Super Punch-Out, but no joypad input worked for Player 1 other than 'z' which exited SNESticle. I suspect I may have a misunderstanding on some of the dictionary keys or I removed some necessary binary data. I tried again by only adding player 2 instead of 4 players, but had the same results. I have attached the python script changes I used.
fn22snesticle.py --p1 literal --p2 literal Fight Night Round 2.iso superpunchout.iso
If this approach might be feasible, do you think you could point me to an appropriate modification of p_main or any other suggestions that might point me in the right direction?
fn22snesticle-p_main_changes.zip

That sounds like a reasonable approach! I think one problem you are having is that you have deleted the NOPs at the end of p_main. While the comment says "for good measure" they are actually important (sorry!) as they are overwriting original Fight Night code that could otherwise interfere with the patch. And likewise, if you want to remove controllers two and three (which could make sense, some games will actually fail to run if they are connected) you need to replace those instructions with NOPs rather than delete them (or you could jump to a known good location).

Adding the NOPs at the end worked!!! Thank you! I was able to get 2-player Super Punch-Out to work in Fight Night in Dolphin...
fn22snesticle.py --p1 literal --p2 literal --p3 off --p4 off Fight Night Round 2.iso superpunchout.iso
However, 'Z' is not quitting SNESticle.
Can you think of any NOP I would need to add/remove from the dictionary to add the 'z' as quit option back in?
Is there any button mapping option that retains the original double mapping of 'y' as both 'y' and 'select'?
p_main = {0xdee44: [0x39200000],   # li r9, 0
0x28b560: [0x60000000,   # Placeholder for exit check
0x54093C2E,   # rlwinm r9, r0, 7, 16, 23
0x50094CAC,   # rlwimi 9, 0, 9, 18, 22
0x5009452A,   # rlwimi 9, 0, 8, 20, 21
0x500904E6,   # rlwimi 9, 0, 0, 19, 19
0x5009fEB6,   # rlwimi 9, 0, 31, 26, 27
0x50092C62,   # rlwimi 9, 0, 5, 17, 17
0x5009EE30,   # rlwimi 9, 0, 29, 24, 24
0x5009DE72,   # rlwimi 9, 0, 27, 25, 25
                 0x5529801E,   # rlwinm r9, r9, 16, 0, 15 ; Shift up
                 0x80030094,   # lwz r0, 0x94(r3) ; Load P2

                 0x50093C2E,   # Same as above except rlwimi
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,

                 0x91210008,   # stw r9, 8(r1) ; Store P1, P2
                 0x80030120,   # lwz r0, 0x120(r3) ; Load P3

                 0x54093C2E,
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,

                 0x5529801E,   # rlwinm r9, r9, 16, 0, 15 ; Shift up
                 0x800301ac,   # lwz r0, 0x1ac(r3) ; Load P4

                 0x50093C2E,
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,

                 0x9121000C,   # stw r9, 12(r1) ; Store P3, P4
                 0x60000000,   # Some nops for good measure
                 0x60000000,
                 0x60000000,
                 0x60000000,
                 0x60000000,
                 0x60000000,
                 0x60000000]}

Cool!
The exit check should be easy to add, just replace the placeholder NOP at the top with 0x701f1000 (from the p_multirom patch dictionary).
To get Y to double as Select again you'll need to add an rlwimi instruction. Gamecube Y is 0x800 and SNES Select is 0x2000 so you want to shift it left twice and then bring in only bit 13 which when counting in the opposite direction in a 32 bit word becomes 18 (uh, I think), so rlwimi r9, r0, 2, 18, 18 probably, which is opcode 0x500914A4 (I may have messed this up completely though, let me know how it goes). You can insert it right after the first seven rlwimis (just before the "Shift up" comment. And if you want it for player 2 just insert it again before the "Store P1, P2" comment. Don't forget to remove a NOP at the end any time you add an instruction. The list length needs to stay the same.

Oh, and you only need the entry with key 0x28b560 from p_main. The li r9, 0 patch is only needed when you are bypassing Fight Night. In fact it could mess things up for you now.

Thanks again for your help, especially since you said this was out of scope.
I made your suggestions: replaced the placeholder NOP at the top with 0x701f1000, added the rlwimi r9, r0, 2, 18, 18 opcode 0x500914a4 before the "Shift up" and again for player 2 before the "Store P1, P2" comment, removed 2 NOP values at the end of the dictionary, and removed the li r9, 0 0xdee44 key.
I observed odd button press behavior in Super Punch-Out so I replaced the embedded SNES ROM for Super Punch-Out with a controller test ROM. Pressing 'start' acts as 'Z' and exits back to Fight Night. Pressing 'y' activates 3 buttons at once - 'y', 'x', and 'select'. All other buttons are mapped appropriately.
Is this a miscalculation for the rlwimi or do I need to modify the p_literal dictionaries since I am setting the mapping as literal?
`p_main = {0x28b560: [0x701f1000,   # Placeholder for exit check
0x54093C2E,   # rlwinm r9, r0, 7, 16, 23
0x50094CAC,   # rlwimi 9, 0, 9, 18, 22
0x5009452A,   # rlwimi 9, 0, 8, 20, 21
0x500904E6,   # rlwimi 9, 0, 0, 19, 19
0x5009fEB6,   # rlwimi 9, 0, 31, 26, 27
0x50092C62,   # rlwimi 9, 0, 5, 17, 17
0x5009EE30,   # rlwimi 9, 0, 29, 24, 24
0x5009DE72,   # rlwimi 9, 0, 27, 25, 25
0x500914A4,   #custom rlwimi r9, r0, 2, 18, 18 for y as select
0x5529801E,   # rlwinm r9, r9, 16, 0, 15 ; Shift up
0x80030094,   # lwz r0, 0x94(r3) ; Load P2
                 0x50093C2E,   # Same as above except rlwimi
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,
                 0x500914A4,   #custom rlwimi r9, r0, 2, 18, 18 for y as select
                 0x91210008,   # stw r9, 8(r1) ; Store P1, P2
                 0x80030120,   # lwz r0, 0x120(r3) ; Load P3

                 0x54093C2E,
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,

                 0x5529801E,   # rlwinm r9, r9, 16, 0, 15 ; Shift up
                 0x800301ac,   # lwz r0, 0x1ac(r3) ; Load P4

                 0x50093C2E,
                 0x50094CAC,
                 0x5009452A,
                 0x500904E6,
                 0x5009fEB6,
                 0x50092C62,
                 0x5009EE30,
                 0x5009DE72,

                 0x9121000C,   # stw r9, 12(r1) ; Store P3, P4
                 0x60000000,   # Some nops for good measure
                 0x60000000,
                 0x60000000,
                 0x60000000,
                 0x60000000]}`

Sorry, I missed some details. I use Start to exit SNESticle in the ROM menu. To get Z instead you want 0x701f0010 (Z has bitmask 0x10) at the top. Then, since you have inserted instructions, the offsets in the p_literal_* dictionaries need to be adjusted:
p_literal_2 = {0x28b590: [0x50094CAC] + literal}
p_literal_3 = {0x28b5bc: [0x54094CAC] + literal}
p_literal_4 = {0x28b5e4: [0x50094CAC] + literal}

And same thing with the p_off dictionaries:
p_off_3 = {0x28b5d8: [0x6129ffff]}
p_off_4 = {0x28b600: [0x6129ffff]}

I'm not sure this explains why Y acts as three different buttons, though. Perhaps it's a bug in my original patch. If the problem remains, would you mind running your test rom with my unmodified script to see if it has the same problem?

OK, I have a lot of info to try and explain, some you might find interesting and some may not be as relevant.
Your last comment worked as expected - Changing the placeholder bitmask as you provided did change the exit function from 'start' to 'z"
Also changing the offsets in p_literal_* worked as expected. Now P1 and P2 have the original "y" button double mapping as "Y" and "select". The changes you recommended above were accurate for what was proposed.
However, this had an unintended consequence in Super Punch-Out. The newly discovered 2-player mode requires P2 to press Y+R while P1 press Start to enter the hidden player selection menu. But when 'y' is double mapped, this P2(Y+R) and P1(Start) combo does not work. The game does not recognize P2(Y+Select+R) and P1(Start) as a trigger for this hidden menu.
Therefore, I proceeded to modify your python script dictionary again with keeping P1 with double mapped Y as Y+Select and removing the P2 double mapping by removing the rlwinm inserted instruction before the Store P1, P2 commented line.
Then, since I removed an instruction, I added an additional NOP back to the end of p_main, and also needed to make offset accommodations to p_literal and p_off dictionaries. I think I comprehend how that is done (by subtracting 4 bits from the Hex keys on p_literal_3, p_literal_4, p_off_3, and p_off_4. If you want to check my revisions, its attached.
So with those change, we now have the ability to enter the hidden menu and use the P2 controls with the "literal" button mappings, which is how Fight Night Round 2 + Super Punch-Out was originally mapped.
With all that said.. there is a bit of a twist to this tail... I'll close out this comment since its getting wordy and gather thoughts for a reply.
fn22snesticle - p1 double mapped y, p2 y to y.zip

My goal when I raised this issue was to integrate the 2 player enhancements into Fight Night Round 2's implementation of Super Punch-Out!!. However, it seems there was a ROM hack applied to Super Punch-Out for the default controller scheme, which does not apply in the 2 player mode. I want to think about how to proceed with the controller scheme.

Right, I remember noticing that. I just figured they had SRAM on the Fight Night disc, but you are right, the ROM itself has been modified. Looks like it's just two bytes that have been changed so it would be easy to undo, but the patched control scheme makes more sense for the GC controller... I see your predicament!
Anyway, fiddling with the script yesterday I found two disastrous (but trivial) bugs in the menu system, so thanks for getting me to take another look at this stuff! :)


x/mod/sumdb: Server.ServeHTTP serves data tiles in different format than sum.golang.org

Go version
n/a (go1.23.1 on linux/amd64)
Output of go env in your module/workspace:
n/a

What did you do?
I used<EMAIL_ADDRESS>to write a sumdb server for local testing.
I already had earlier code that parses data tiles (level -1 tiles) into records, and then verifies the hash of each record. It's part of gopherwatch, with the parsing at https://github.com/mjl-/gopherwatch/blob/3d50ff988dade2e571f3983c4194e451515a39d1/sums.go#L288. The parser is a bit sloppy, but it can verify the data tiles served by sum.golang.org.
Configuring gopherwatch to verify the data tiles of a sumdb server written with sumdb#Server.ServeHTTP was giving me unexpected verification errors (hashes of record data different than expected based on the tiles containing hashes).
It turns out that data tiles served by sum.golang.org have a different format than the data tiles served by golang.org/x/mod/sumdb.Server. In sumdb.Server, each record is prefixed with its record ID and a newline. On sum.golang.org they are not. The hashes of the records stored in the level 0 tiles are calculated over the record data without a record ID, that explains the errors I was seeing.
For example, a (random) data tile from sum.golang.org: https://sum.golang.org/tile/8/data/x115/673
It looks like this:
github.com/hewo233/cxsj_homework1 v0.0.0-20240826052307-bcb3e2e71e36 h1:QRoUMkmrcJluJBuUNVVVDUfaB1YyFlgbbZwDwrjPrss=
github.com/hewo233/cxsj_homework1 v0.0.0-20240826052307-bcb3e2e71e36/go.mod h1:6C5wTFANZQ6jZIu6UdOkia0qn8b4fQ+HFLF4CijMthE=

github.com/arkadiyt/bounty-targets-data v0.0.0-20240908180608-4f76f96365cf h1:vPLwkW3FLd+R2haNqSfa3CMizSYn2nSEaUyGg12aEeI=
github.com/arkadiyt/bounty-targets-data v0.0.0-20240908180608-4f76f96365cf/go.mod h1:0QqDOBpcXYlM/8MU2nsGjwvUOgJkKrVA/RA5hxf078s=

github.com/jaganathanb/dapps-api v0.0.0-20240617075156-dbbed11228b4 h1:IHcmr6+bukh2ZCyKbH2VkVfUsJGiwTYZKRbP7WCb7n8=
github.com/jaganathanb/dapps-api v0.0.0-20240617075156-dbbed11228b4/go.mod h1:ZBo/O1yJ08TwyEtzMQIQDL8dQz4vyLyW4m1Fss3WDDA=

...

However, a data tile served by sumdb.Server would look like this (note the extra number before the record data: the record id):
1234
github.com/hewo233/cxsj_homework1 v0.0.0-20240826052307-bcb3e2e71e36 h1:QRoUMkmrcJluJBuUNVVVDUfaB1YyFlgbbZwDwrjPrss=
github.com/hewo233/cxsj_homework1 v0.0.0-20240826052307-bcb3e2e71e36/go.mod h1:6C5wTFANZQ6jZIu6UdOkia0qn8b4fQ+HFLF4CijMthE=

1235
github.com/arkadiyt/bounty-targets-data v0.0.0-20240908180608-4f76f96365cf h1:vPLwkW3FLd+R2haNqSfa3CMizSYn2nSEaUyGg12aEeI=
github.com/arkadiyt/bounty-targets-data v0.0.0-20240908180608-4f76f96365cf/go.mod h1:0QqDOBpcXYlM/8MU2nsGjwvUOgJkKrVA/RA5hxf078s=

1236
github.com/jaganathanb/dapps-api v0.0.0-20240617075156-dbbed11228b4 h1:IHcmr6+bukh2ZCyKbH2VkVfUsJGiwTYZKRbP7WCb7n8=
github.com/jaganathanb/dapps-api v0.0.0-20240617075156-dbbed11228b4/go.mod h1:ZBo/O1yJ08TwyEtzMQIQDL8dQz4vyLyW4m1Fss3WDDA=

...

The data tiles are composed  at https://github.com/golang/mod/blob/46a3137daeac7bd5e64dc5971191e4a7207e6d89/sumdb/server.go#L148,
using tlog.FormatRecord from https://github.com/golang/mod/blob/46a3137daeac7bd5e64dc5971191e4a7207e6d89/sumdb/tlog/note.go#L75.
The comment on that function also says that format is used by a data tile. That is true for sumdb.Server, but not for sum.golang.org.
The record format (with signature) is used in the responses to individual module lookups, e.g<EMAIL_ADDRESS>The Go tooling may not be parsing the data tiles, working only on lookups and the tiles containing hashes. But I think it would be good to have sumdb.Server serve the same format as sum.golang.org for data tiles, so clients that can process data tiles from sum.golang.org can also parse data tiles served by a sumdb.Server.
There could be concerns about compatibility: existing code may now depend on the format currently served by sumdb.Server. But parsing data tiles doesn't seem very common.
If the format of sumdb.Server is deemed better and should stay, it would be good to document this difference. Clients parsing the data tiles could then recognize both formats.
What did you see happen?
sumdb.Server.ServeHTTP serving data tiles in a format different from what sum.golang.org is serving.
What did you expect to see?
sumdb.Server.ServeHTTP serving data tiles in the same format as sum.golang.org.

CC @matloob @samthanawalla as owners of x/mod.

@FiloSottile

cc @rsc, as author of this package.

Thank you for the thorough report! Indeed, it looks like tlog.FormatRecord reflects the /lookup format but not the sumdb data tiles. I think the x/mod/sumdb package should mirror the sum.golang.org implementation, so I'm in favor of editing the comment of tlog.FormatRecord not to mention data tiles, and changing the served format of Server.ServeHTTP.
I doubt anyone is depending on the current format since no one noticed the discrepancy before.

@mjl- thanks for the CL. Should that have fixed this issue?

@findleyr yes, thanks! closing the issue.


fix(pkg/da): ensure DAH.hash is always calculated during ValidateBasic

This is useful for headers downloaded from the network. Each such header goes through validation during which the hash should be calculated. Otherwise, the hash is calcualated at much later point, which is prone to races. In celestia-node we observed such races when the DAH.Hahs is read from multiple routines, where both end up calculating the hash and setting the it to the cache value making the race detector complain. Such precompute fixes this, similar to how Hash is precomputed in the constructor.

is this needed for https://github.com/celestiaorg/celestia-node/pull/1160?

Merging based on https://github.com/celestiaorg/celestia-node/pull/1160?notification_referrer_id=NT_kwDOADhxZ7I0NDY0MzU0MDEyOjM2OTkwNDc#issuecomment-1273054501


Improve: MaxPool2D Perf Model (Grayskull)

Explore collecting empirical data on this op and create an interpolated function based on LLK calls.

Modelling via LLK call counting on hold until more detailed models required for other ops (SFPU etc)

#6622 and #6623 need to be prioritized over this work.


test: avoid lots of no-kubectl errors for non-kubernetes test layers

Description of what you did:

My PR is a:

[ ] 💥 Breaking change
[ ] 🐛 Bug fix
[x] 💅 Enhancement
[ ] 🚀 New feature

Please confirm that your PR fulfills these requirements

[x] Multiple commits are squashed into one commit.
[x] The commit message follows Conventional Commits, which allows us to autogenerate release notes; e.g. fix(plugins/plugin-k8s): fixed annoying bugs
[x] All npm dependencies are pinned.

never mind, no time


Ghosts in the Home app?

When I start matterbridge from the console it runs and everything works. But just for some minutes, then it goes offline and is not accessible on its IP. I run the matterbridge on a raspberry pi parallel to the homebridge and installed matterbridge from the console in homebridge. May that caused an error?

Bridge is always Matterbridge, like the original device. Interesting point, it depends on the device type.
Always ghosts for: 2.5, mini G3, RGBWs
no ghosts for: i4, Bulbs and plug plus
in the screenshot you see the ghosts for 2 of 3 devices, and the details for the mini G3.

Sorry for the late reply.
Why you say that they are ghosts?
To understand what is exposed on Matter, go to Devices page of the frontend and check if there are any differences between there and what you see on the Home app.
Sometimes Home takes a while (few minutes) to update the node. The time is clearly related to your network conditions.

In the frontend there appear 20 devices like its my actually setup. In Homekit in summary appear about 35 devices, like I said some kinds of device are shown up 2 times. And this is since a week and didn’t change.
For example a RGBW2 is shown as a lamp, and a copy shown up as switch. When I enter the settings of the devices in both of them is shown Matterbridge as the bridge, and in Matterbridge settings are the 20 devices what is right. Even when I go there from the wrong device.

This is not a Matterbridge or Matter issue.
The node has what you see in the frontend.
Home must have some issues due to all the tests you made maybe.
To solve this:
restart matterbridge, wait the controller is connected, then disable the plugins (all).
wait till you see all devices disappear. Eventually repowoer your controller.
When all devices are gone, enable the plugin.

I had that problem with iOS previous beta and it's solved in the  current one as of December 12 2024. No more ghosts.

Ok, then start from the beginning:

what controller and version you have ?
wired or wifi ?

Did you try also to unpair matterbridge (I know is painful), delete all pairing from settings on your phone, repower the controller, factoryreset matterbridge and pair it again?
Is clearly a Home issues. I don't see these kind of problems after version 17.5 of tvOs.

I had that problem with iOS previous beta and it's solved in the current one as of December 12 2024. No more ghosts.

Exactly the same with version before 17.5

I use an Apple TV, connected wired with tvOS 18.1
On the iphone iOS 18.2
I think when its an OS issue, it would be the tvOS and not the phone.

Any news ?

No, but after I reseted the device storage one day i can add actions to the buttons of the i4’s in homekit, what earlier caused an error.
so everything works, but the issue of doubled devices remains.
I think I have to arrange with this.

Send me a full backup of your setup to understand where is the problem if it is still there.

Sure. Problem is still there. I would give you all informations you need. But I’m a bit confused. What do you mean wirh backup of my setup?

Can you also send me a screenshot from Home app / Home settings / Home Hubs & Bridges / Bridges (chose matterbridge) / Accessories...
If you have 20 devices there can show much more if have the inputs enabled in the config...
They are not ghosts but simply the Inputs components from the shellies.

Sure, i‘ll do that after the holidays, but i‘ll need 2 weeks.
Until then, i have f.e. an extra button (with 2 inputs) for one RGBW in homekit. You said that is wanted behavior? This button shouldn’t show up. if I want to execute actions on the RGBW i‘ll choose this. i don’t need the buttons in HomeKit. different for i4 or other buttons, these ones should be programmable in homekit.

All components can be blacklisted on a device base if you like.
Check the readme.
Other users may want to have them also for the history on the controller side and not only for automations. New devices allow you to detach the inputs so you can use them for something else.

To clarify that: F.e. I have only one RGBW in matterbridge, but an actor and a button in homekit. If I would blacklist this one in matterbridge, both would disappear in homekit. also if I hide the button in homekit, the actor would also be hidden. I can’t seperate them.
After the holidays i‘ll give you the backup, maybe that‘ll help

https://github.com/Luligu/matterbridge-shelly/blob/dev/COMPONENTS.md

Oh, I didn’t knew this feature. This should work. How about the 2.5s and others?

Is a general function.
It applies to all devices.
Just check the log to learn the component names and ids.
The component id is also shown on the Devices page of the frontend cause it is the child endpoint name.
Feel free to ask if you need help.
@tammeryousef1006 and I will clarify if something is still not clear.


InsecureServerCredentials hangs forever!

What version of gRPC and what language are you using?
1.41.1 and c++
What operating system (Linux, Windows,...) and version?
custom Linux(kernel 3.14.169)[Yocto(gatesgarth (3.2.2))]
What runtime/compiler are you using (e.g. python version or version of gcc)
GCC :10.2
What did you do?
using the following dependencies:

libprotoc 3.13.0
abseil 2021_03_24

have tried to run basic an ARM-Architektur(32 bit)  built grpc server with the following Code
        const std::shared_ptr<ServerCredentials> ptr = InsecureServerCredentials();
        builder.AddListeningPort("<IP_ADDRESS>:1234", ptr);
        _server = unique_ptr<Server>(builder.BuildAndStart());
        logger << INFO << "[workingThread] Listing for on " << uri << ".";
        const auto work = [&]()
        {
            _server->Wait();
            logger << INFO << "[workingThread] stop.";
        };
        _thread = thread(work);

What did you expect to see?
should work
What did you see instead?
my server hangs forever in InsecureServerCredentials() function, therefore I've enabled
the debug mode with export GRPC_TRACE=all GRPC_VERBOSITY=debug"
and I've got these logs
D0101 01:27:06.958168525    8969 ev_posix.cc:172]            Using polling engine: epollex
D0101 01:27:06.958927049    8969 lb_policy_registry.cc:42]   registering LB policy factory for "grpclb"
D0101 01:27:06.959040827    8969 lb_policy_registry.cc:42]   registering LB policy factory for "priority_experimental"
D0101 01:27:06.959154606    8969 lb_policy_registry.cc:42]   registering LB policy factory for "weighted_target_experimental"
D0101 01:27:06.959211495    8969 lb_policy_registry.cc:42]   registering LB policy factory for "pick_first"
D0101 01:27:06.959249421    8969 lb_policy_registry.cc:42]   registering LB policy factory for "round_robin"
D0101 01:27:06.959287347    8969 lb_policy_registry.cc:42]   registering LB policy factory for "ring_hash_experimental"
D0101 01:27:06.959344237    8969 dns_resolver_ares.cc:489]   Using ares dns resolver
D0101 01:27:06.959533868    8969 certificate_provider_registry.cc:33] registering certificate provider factory for "file_watcher"
D0101 01:27:06.959609720    8969 lb_policy_registry.cc:42]   registering LB policy factory for "cds_experimental"
D0101 01:27:06.959704536    8969 lb_policy_registry.cc:42]   registering LB policy factory for "xds_cluster_impl_experimental"
D0101 01:27:06.959742462    8969 lb_policy_registry.cc:42]   registering LB policy factory for "xds_cluster_resolver_experimental"
D0101 01:27:06.959799351    8969 lb_policy_registry.cc:42]   registering LB policy factory for "xds_cluster_manager_experimental"

but that did not help much in understanding the Problem.
so in the end, I decided to comment out the function, which cause the infinite loop
and the following patch was helpful for me
diff --git a/src/core/lib/surface/init.cc b/src/core/lib/surface/init.cc
index 2812427f7a..3c6a547b20 100644
--- a/src/core/lib/surface/init.cc
+++ b/src/core/lib/surface/init.cc
@@ -156,7 +156,7 @@ void grpc_init(void) {
      * at the appropriate time */
     grpc_register_security_filters();
     register_builtin_channel_init();
-    grpc_tracer_init();
+    // grpc_tracer_init();
     /* no more changes to channel init pipelines */
     grpc_channel_init_finalize();
     grpc_iomgr_start();

I would like to know if you know the reason behind this issue and whether you have solved it in a new version

Hi, thanks for bringing up the issue!
Just to confirm, was the program hanging at the line
const std::shared_ptr<ServerCredentials> ptr = InsecureServerCredentials();
```,  and the next line is never reached? And when you comment out `grpc_tracer_init();`, the problem is fixed?

`grpc_init` is needed by most of the credential creation. If something wrong with it, likely it will affect other credential types as well. If your program didn't hang at the credential creation but a few lines below, I think that's expected - your server is waiting there for incoming connections.

Also upgrading the gRPC version to the latest(1.44) might help solve the issue as well. Would you mind giving it a try?

Usually this would be a symptom of the ODR (link) would you show how to build it (preferably a build script) if possible.


Boring !!

Hello
I use android CM browser (cookies are on)
When connecting to "decathlon.fr ", i always have "update your browser .." but my browser is updated.
 it's boring !!
BTW when connecting to your site with CM Browser : no message !! it's funny !!
What can you do ?
If this situation goes on , i will answer Decathlon to remove your application from the site.
Thanks for your response.

Strange. Somehow your cookie must get deleted.
Anyway, I will whitelist CM browser as a niche browser not getting notified.
Also I will try to investigate the reason why your cookie does not get set
or kept.
Am Mi., 25. Juli 2018 um 09:24 Uhr schrieb antec74<EMAIL_ADDRESS>
:

Hello
I use android CM browser (cookies are on)
When connecting to "decathlon.fr ", i always have "update your browser
.." but my browser is updated.
 it's
boring !!
BTW when connecting to your site with CM Browser : no message !! it's
funny !!
What can you do ?
If this situation goes on , i will answer Decathlon to remove your
application from the site.
Thanks for your response.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/browser-update/browser-update/issues/407, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIErKjQfgUxfjz0J55D_ECtAkriUyWsKks5uKB0vgaJpZM4VfkQa
.

Yeah! I found the bug. A fix is coming today!

It should be fixed now. Can you please verify this?


Handler on inline buttons does not work if the bot is restarted.

It is expected behavior if you create the handler during runtime. After restart you handler possibly not exists. In this case you should recreate handler with same Unique and pass it to tb.Handle.


Annoying Sankaku issue

Bug description
Seems like Sankaku is displaying results that are clearly not what you're searching for.
Steps to reproduce

New tab
Search literally anything
Click 'Ok'
Results shown are no where close to search query.

 But searching X, results in Y, Z, and sometimes A.
Context

Provide your main.log file to see if any obvious error occured.

main.log

Providing your settings.ini file will greatly help maintainers reproduce your problem if it may be caused by your configuration.

settings.log
System information

OS: Win10
Grabber version: 6.0.6

Additional context
I know that Sankaku has been a MASSIVE pain in the ass for the devs (who are all rockstars, btw!), I'm not looking for a resolution, just letting y'all know.

Nevermind! My credentials were broken.


Sometimes Actions of the agent does not take effect to envs!

🐛 Bug
On the tag home-robot-ovmm-challenge-2024 branch, the actions of any agent does not take effect to the env no matter what kind of agent I choose.
The visualization stays the same as follows:

My agent keeps saying turn right but the observation from env stays the same:

I just checked my earlier challenge project at nips'23, it turns to be just the same, which was not...
I'm not sure this is a package trouble or my machine trouble...
I wonder what kind of hardware problem would cause such weird issue>>? GPU/CPU out of memory?

I highly suspect that this could be a GPU memory insufficient problem! It gets back to normal the other day! But how come no warnings or exceptions coming out?

I have also encountered a similar problem...

The agent wouldn't move if the action takes it outside the navmesh. We can print warnings here if it tries to move outside the navmesh.
But @Yonggie it should be able to rotate in the screenshot you shared. I doubt if it is a hardware issue. Can you check if you are using the right habitat-lab commit too?
@GuanxingLu were you running the default agent too?

I think it's about the hardware, cus it got back to normal yesterday with the same device and same codes. But I wonder how come there's no warnings or exceptions even when encoutered insufficient hardware requirements?


feat(autoware.repos): use version tag for sensor_kits

Description
This updates the version for sample_sensor_kit_launch and awsim_sensor_kit_launch to make sure that we are using a compatible version with autoware.universe 0.39.0
https://github.com/autowarefoundation/autoware/issues/5544
How was this PR tested?
I have tested locally with AWSIM.
Notes for reviewers
None.
Effects on system behavior
None.

@xmfcx Yes, that has to be fixed as well. I just started with the ones that was reporting the rosdep error.
I will create other PRs to fix other repositories as well.


Linking two bridge devices together?

This might be a silly question (or I am not thinking hard enough!) but how do I link two bridge devices together so Alexa can effectively do two things at the same time? I'm thinking here about the following scenario which I have already setup but need to issue two voice commands to accomplish:

Alexa turn on my gaming machine which does simple WOL and powers on my desktop,
Alexa turn on my TV which talks to my Harmony Hub to trigger an activity to turn my TV on.

How do I simply say "Alexa turn on my gaming machine" and that triggers two actions to a) wol my gaming PC and b) turn on my TV?
What am I missing here to get this done?
cheers,
Adrian

The next version allows multi commands across different types. You will just create the two actions in the given device.... But! There is a hack that works now as multi commands work for http!
Device Name: Gaming Machine
On URL: [{"item":"http://:/api/anyusername/lights//state"},{"item":"http://:/api/anyusername/lights//state"}]
HTTP Verb: PUT
On Body: {"on":true}
This will do the same thing for now.

Not sure why you would not just create a group in the Alexa app where you would put both bridge devices.

I knew there was something that I was blatantly overlooking! Thanks @rafale77 for opening my eyes!
@bwssytems, thank you for your reply as well.  Keep it up!


fix jemalloc upstream homebrew formula

In this commit we disabled jemalloc because it of https://github.com/neovim/neovim/issues/5681, which was caused by an attempt to fix https://github.com/neovim/homebrew-neovim/issues/194.
Going forward, the best (only) option is to use the upstream homebrew jemalloc formula, but before doing so we need to figure out what changes are needed in it to avoid https://github.com/neovim/neovim/issues/5681. That means sending a pull request to homebrew core.
Then we can restore depends_on "jemalloc" => :recommended (i.e. revert https://github.com/neovim/homebrew-neovim/pull/200).

The problem is probably that jemalloc libraries from homebrew don't have je_malloc,je_calloc,je_realloc, or je_free.
This is because they are built with --with-jemalloc-prefix= (disable prefixed functions).

jemalloc provided by Linux package manager (at least on ubuntu, fedora, archlinux) don't have je_* functions neither.
Then neovim/neovim#5681 should occur on those environment if build against their jemalloc?

vim-plug works fine with jemalloc when --with-dev is enabled

Linking static library libjemalloc.a solves the problem as workaround.
(Haven't found out formula-suitable way to choose appropriate library though)


Defect: coarray of derived type: crash during allocation of an allocatable member

The title of the issue should start with Defect: followed by a
succinct title.
Please make sure to put any logs, terminal output, or code in
fenced code blocks. Please also read the contributing guidelines
before submitting a new issue.
Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information.

[x] I am reporting a bug others will be able to reproduce and not asking a question or requesting a new feature.

System information including:

OpenCoarrays Version: output of 'caf --version':
OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 2.9.2)
Copyright (C) 2015-2020 Sourcery Institute
Copyright (C) 2015-2020 Sourcery, Inc.

Fortran Compiler:  output of 'gfortran --version':
GNU Fortran (Homebrew GCC 11.2.0_1) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.

C compiler used for building lib:  output of 'gcc --version':
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Installation method: homebrew

Output of 'caf -s':
/usr/local/bin/gfortran -I/usr/local/Cellar/opencoarrays/2.9.2_1/include/OpenCoarrays-2.9.2_GNU-11.2.0 -fcoarray=lib -Wl,-flat_namespace -Wl,-commons,use_dylibs -L/usr/local/Cellar/mpich/3.4.2/lib ${@} /usr/local/Cellar/opencoarrays/2.9.2_1/lib/libcaf_mpi.a /usr/local/lib/libmpifort.dylib /usr/local/lib/libmpi.dylib /usr/local/lib/libpmpi.dylib

Output of 'cafrun -s':
/usr/local/bin/mpiexec -n <number_of_images> /path/to/coarray_Fortran_program [arg4 [arg5 [...]]]

Output of uname -a:
Darwin mycomputer.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Jun 22 19:37:08 PDT 2021; root:xnu-4903.278.70~1/RELEASE_X86_64 x86_64

MPI library being used: mpich (OpenMPI unlinked) output of 'mpichversion':
MPICH Version:    	3.4.2
MPICH Release date:	Wed May 26 15:51:40 CDT 2021
MPICH Device:    	ch4:ofi
MPICH configure: 	--disable-dependency-tracking --enable-fast=all,O3 --enable-g=dbg --enable-romio --enable-shared --with-pm=hydra FC=gfortran-11 F77=gfortran-11 --disable-silent-rules --prefix=/usr/local/Cellar/mpich/3.4.2 --mandir=/usr/local/Cellar/mpich/3.4.2/share/man FFLAGS=-fallow-argument-mismatch  CXXFLAGS=-Wno-deprecated CFLAGS=-fgnu89-inline -Wno-deprecated
MPICH CC: 	clang -fgnu89-inline -Wno-deprecated   -DNDEBUG -DNVALGRIND -g -O3
MPICH CXX: 	clang++ -Wno-deprecated  -DNDEBUG -DNVALGRIND -g
MPICH F77: 	gfortran-11 -fallow-argument-mismatch  -g
MPICH FC: 	gfortran-11   -g
MPICH Custom Information:

Machine architecture and number of physical cores:  Intel Core i7, 4 cores

To help us debug your issue please explain:
Dear Opencoarrays developers,
consider the following minimal example (a module (mymod) and a main in separate files):
cat mymod.f90
module mymod
   implicit none

   type :: my_t
      integer, allocatable :: i(:), j(:)
   end type my_t

contains

   subroutine set ( n, var )
      integer   , intent(in    ) :: n
      type(my_t), intent(   out) :: var

      integer            :: err
      character(len=100) :: msg

      err = 0 ; msg = ''

      allocate(var%i(n), stat = err, errmsg = msg)
      if (err /= 0) error stop "in set: allocation failure (for %i): "//trim(msg)

      allocate(var%j(n), stat = err, errmsg = msg)
      if (err /= 0) error stop "in set: allocation failure (for %j): "//trim(msg)

      ! ...
      ! ...
      ! ...
   end subroutine set

end module mymod

cat main.f90
program foo
   use mymod
   implicit none

   type(my_t) :: myvar[*]

   if (this_image() == 1) then
      ! allocate and set the members of myvar[1]:
      call set ( var = myvar, n = 5 )
   end if

   sync all
   ! ...
   ! ...
   ! ...
   if (this_image() == 1) print*,'terminated'
end program foo

What happened (include command output, screenshots, logs, etc.)
When compiling with caf:
caf mymod.f90 main.f90 -Wall -fcheck=all -fbacktrace
and running with cafrun:
cafrun -n 4 ./a.out
an error occurs:
Program received signal SIGABRT: Process abort signal.

Please see the FAQ page for debugging suggestions
Error: Command:
   `/usr/local/bin/mpiexec -n 4 ./a.out`
failed to run.

Please also note that

if I replace the intent(out) by intent(inout) an allocation error is reported:

ERROR STOP in set: allocation failure (for %j): Attempt to allocate an allocated object
Abort(1) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
Error: Command:
   `/usr/local/bin/mpiexec -n 4 ./a.out`
failed to run.

the issue goes away when I use a single source file:
cat mymod.f90 main.f90 > foo.f90
caf foo.f90 -Wall -fcheck=all -fbacktrace
cafrun -n 4 ./a.out
terminated

@hassaniriad thanks for submitting this.   I just discovered what is likely the same issue the day before you submitted this.
@vehre could this be related to your recently merged PR?

Hi @rouson
my latest merge was about static arrays. Here I see only allocatable ones. I am more intrigued to look for this issue in the module handling. But that is just a guess w/o having taken a decent look into it.
When you want me to analyse and work on this, just say so.

This seems to be fixed with gfortran 15 (current development) and on the main branch of OpenCoarrays.


Run examples with make in DevNet always-on device

What do you think if the examples run against the DevNet always-on IOS-XE device, so anyone can run the examples?
I also added them to the Make file, so you can execute them from the root (all but the NETCONF one)
$ make
base-example                   Run Base example
lint                           Run linters
net-channellog-example         Run Network Channel Log example
net-factory-example            Run Network Factory example
net-interactive-example        Run Network Interactive example
net-log-example                Run Network logging example
net-onopen-example             Run Network On Open example
net-simple-example             Run Network simple example
test                           Test execution

I added a note in the readme on how you would run the examples.
$  make net-simple-example
found prompt:
csr1000v-1#

sent command 'show version', output received:
 Cisco IOS XE Software, Version 16.09.03
Cisco IOS Software [Fuji], Virtual XE Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 16.9.3, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2019 by Cisco Systems, Inc.
Compiled Wed 20-Mar-19 07:56 by mcpre
...

PS: I added a bit more space between the outputs to make it more clear.

Hey @nleiva thanks for opening this!
Sorry to be nit picky, but would you mind doing away with the make directives for the examples? I don't want to have to think about it when we hopefully add more examples in the future and I kinda hope folks can (esp w/ the running examples section you added) handle go run blah :)

Sure, it's up to you. Let try to explain where I'm going with it before I remove it.
As you add more examples, you can optionally create a make target for it (or not). Creating the target has the following benefits:

The example is briefly documented via the help menu and made available to the user via one command. You don't need to explore the examples folder.
You can now periodically run make examples as you make code changes to the library. This target will run all examples, so you can make sure they are still valid and that the code changes do not impact the functionality against real network devices (this is additional to go test).
Examples are the entry point for users, so we want to make sure they always work. That's why I normally try to have them run automatically in my CI workflows or as I make changes.

Let me know what you think, it's not a big deal for me to get rid of it.

All solid points of course. For now, if we can drop 'em that'd be cool. We may have another "always on" vendor available in a bit then we can reevaluate adding them. I def have plans to continue to expand/improve testing of this and you are absolutely right that that should (and will!) include examples!
Thanks for being flexible, and for contributing!
Carl

No worries, I removed the following code (leaving it here, so I can pick it up in the future if required). Notice you can pass arguments as well to the examples, so make can test on different always-on targets. I tried unsuccessfully to get different vendors in the past to provide that capability for us to test without success :-(
examples: base-example net-simple-example net-log-example net-interactive-example net-factory-example \
          net-onopen-example net-channellog-example

base-example: ## Run Base example
	-@go run examples/base_driver/main.go

net-simple-example: ## Run Network simple example
	-@go run ${NET_EXAMPLES}/simple/main.go -argument=${NET_EXAMPLES}/simple/commandsfile

net-log-example: ## Run Network logging example
	-@go run ${NET_EXAMPLES}/logging/main.go

net-interactive-example: ## Run Network Interactive example
	-@go run ${NET_EXAMPLES}/interactive/main.go

net-factory-example: ## Run Network Factory example
	-@go run ${NET_EXAMPLES}/factory/main.go

net-onopen-example: ## Run Network On Open example
	-@go run ${NET_EXAMPLES}/custom_onopen/main.go

net-channellog-example: ## Run Network Channel Log example
	-@go run ${NET_EXAMPLES}/channellog/main.go

Thanks a bunch!


FWIW, there is a View.window_to_text(vector) now

Has been added couple builds ago for the "Open ..." context menu addition.

Oh cool! I missed that. I'll have to check it out. Thanks for the heads up!


Playflx blitters optimisations (-55 bytes)

rebased to streamingio.asm, shortened few more bytes in decoders


Add SlimToolkit CNCF Sandbox project to Landscape

Pre-submission checklist:
Please check each of these after submitting your pull request:

[x ] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[x ] Have you picked the single best (existing) category for your project?
[x ] Does it follow the other guidelines from the new entries section?
[ x] Have you added your SVG to hosted_logos and referenced it there?
[x ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ x] Does your project/product name match the text on the logo?
[ x] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~30 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

@kcq
FATAL: No cached entry, and SlimToolkit has issues with logo: slimtoolkit.svg, SVG file embeds a png. Please use a pure svg file

@kcq
FATAL: No cached entry, and SlimToolkit has issues with logo: slimtoolkit.svg, SVG file embeds a png. Please use a pure svg file

updated (should be a pure svg now)

[x] ~30 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?
LGTM


Support for Hazelcast cache

Like other cache support for example redis , memcache . Tool should be extended to provide support for hazelcast.

@eko I am willing to add support for hazelcase issue

Hi @smsufyian,
I will be interested if you could add support for Hazelcast.
Closing this issue because this is a duplicate of https://github.com/eko/gocache/issues/6, please continue on this thread.
Thank you


Changes Libsodium: checks at startup if it is found

https://github.com/Alliander/ri.usef.energy/commit/b1ea6c444ddf5cf7d3502e0d147fccf513e1dfc7

This was a first pull request, and something went wrong. Let's close this one!

Dear Sender,
Please be aware that I will be out of office until and including Monday 1 May 2017. I will read and answer your email less frequently during my absence.
Best regards,
Jeroen Bode,
Director USEF.
www.usef.energy


Images are not showing up on SAML docs page

The Okta screenshots on the SAML docs page aren't showing up right now

However it looks like they are showing up if you look at that docs page directly in github: https://github.com/pachyderm/pachyderm/blob/master/doc/auth/saml.md

fixed


Update .gitignore

add text to .gitignore

2.7 branch is EOL, for any change please raise a PR to trunk & create a jira first


Error closing the environment

What:
The environment gives an error on env.close() call if env.render() has not been called because the "http_server" attribute as not been created
How:
Executing the environment using this modified test code:
import gym
import time

def run():
   env = gym.make('gym_anm:ANM6Easy-v0')
   o = env.reset()

   for i in range(100):
       a = env.action_space.sample()
       o, r, done, info = env.step(a)

   env.close()

if __name__ == '__main__':
    run()

Where:
"gym_anm\envs\anm6_env\anm6.py", line 231, in close
 rendering.close(self.http_server, self.ws_server)
AttributeError: 'ANM6Easy' object has no attribute 'http_server'
How to fix:
I see two options to potencialy fix this issue:

Initialize the attributes "http_server" and  "ws_server" on the "init" function
check if the render has been called/initialized and only then call rendering.close.

server_up= getattr(self, "http_server", None)
if server_up:
        rendering.close(self.http_server, self.ws_server)
        self.render_mode = None

Thanks! This is now fixed in v1.1.6.
See: https://github.com/robinhenry/gym-anm/pull/19


Generic and non-generic overloads of the same method have separate pages

If a method has multiple overloads, some generic and some non-generic, it seems the generic overloads are put on one page and the non-generic overloads on another page.
For example, this happens with Task.WhenAll:

Non-generic overloads
Generic overloads

I don't see any reason to consider the two groups of overloads separately. In fact, I think doing it this way is going to be confusing: if I click on a link for WhenAll(Task[]) and then scroll up to look at the overloads and don't find all of them.

Filed internal bug to track this: #980593
/cc @dend @DuncanmaMSFT @adkinn

Looks like this was fixed. Closing.


[icu] Build error on arm64 macos

Host Environment

OS: mac
Compiler: clang 14, according to https://github.com/actions/runner-images/blob/macOS-12/20230318.1/images/macos/macos-12-Readme.md#language-and-runtime

To Reproduce
Steps to reproduce the behavior:
./vcpkg install --overlay-triplets=. --triplet=arm64-osx-openrct2 icu
Contents of arm64-osx-openrct2.cmake:
set(VCPKG_TARGET_ARCHITECTURE arm64)
set(VCPKG_OSX_ARCHITECTURES arm64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)

set(VCPKG_CMAKE_SYSTEM_NAME Darwin)
set(VCPKG_OSX_DEPLOYMENT_TARGET "11.0")

set(VCPKG_BUILD_TYPE release)

Failure logs
Run export VCPKG_COMMIT_HASH='23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d'
  export VCPKG_COMMIT_HASH='23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d'
  brew install automake autoconf-archive
  ./macos_build.sh
  shell: /bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    VCPKG_COMMIT_HASH: 23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d

==> Fetching automake
==> Downloading https://ghcr.io/v2/homebrew/core/automake/manifests/1.16.5
==> Downloading https://ghcr.io/v2/homebrew/core/automake/blobs/sha256:ae77a247a13ea860236a29b02769f5327395f712413f694d8a8d20cb6c21332d
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:ae77a247a13ea860236a29b02769f5327395f712413f694d8a8d20cb6c21332d?se=2023-03-29T22%3A05%3A00Z&sig=qTO9yE3FPw%2BbKnnS5l88GUVEX51ht%2F5o8LUqjxRM%2BQ8%3D&sp=r&spr=https&sr=b&sv=2019-12-12
==> Fetching autoconf-archive
==> Downloading https://ghcr.io/v2/homebrew/core/autoconf-archive/manifests/2023.02.20
==> Downloading https://ghcr.io/v2/homebrew/core/autoconf-archive/blobs/sha256:241f7af27fa98b3cde170df669f5041e1af971fb4846890269d01df8ab26e74b
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:241f7af27fa98b3cde170df669f5041e1af971fb4846890269d01df8ab26e74b?se=2023-03-29T22%3A05%3A00Z&sig=UBX2UZ2tknjIgL5Vg0F%2FH%2Bov6yrN%2BhnFKYBbmZJCwGo%3D&sp=r&spr=https&sr=b&sv=2019-12-12
==> Pouring automake--1.16.5.monterey.bottle.tar.gz
🍺  /usr/local/Cellar/automake/1.16.5: 131 files, 3.5MB
==> Running `brew cleanup automake`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
==> Pouring autoconf-archive--2023.02.20.monterey.bottle.tar.gz
🍺  /usr/local/Cellar/autoconf-archive/2023.02.20: 600 files, 3.6MB
==> Running `brew cleanup autoconf-archive`...
+./macos_build.sh:6> easy_install --user 'pyyaml==5.4.1'
Searching for pyyaml==5.4.1
Reading https://pypi.org/simple/pyyaml/
Downloading https://files.pythonhosted.org/packages/42/c5/440fd6200c345c3d522fbe47a52558733c4661aac3c8cf06b7de31bababd/PyYAML-5.4.1-cp27-cp27m-macosx_10_9_x86_64.whl#sha256=3b2b1824fe7112845700f815ff6a489360226a5609b96ec2190a45e62a9fc922
Best match: PyYAML 5.4.1
Processing PyYAML-5.4.1-cp27-cp27m-macosx_10_9_x86_64.whl
Installing PyYAML-5.4.1-cp27-cp27m-macosx_10_9_x86_64.whl to /Users/runner/Library/Python/2.7/lib/python/site-packages
Adding PyYAML 5.4.1 to easy-install.pth file

Installed /Users/runner/Library/Python/2.7/lib/python/site-packages/PyYAML-5.4.1-py2.7-macosx-10.9-x86_64.egg
Processing dependencies for pyyaml==5.4.1
Finished processing dependencies for pyyaml==5.4.1
+./macos_build.sh:8> git clone -q https://github.com/Microsoft/vcpkg.git
+./macos_build.sh:10> [ -v VCPKG_COMMIT_HASH ']'
Using pinned vcpkg commit: 23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d
+./macos_build.sh:11> echo 'Using pinned vcpkg commit: 23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d'
+./macos_build.sh:12> pushd vcpkg
+./macos_build.sh:13> git checkout -q 23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d
+./macos_build.sh:14> popd
+./macos_build.sh:17> vcpkg/bootstrap-vcpkg.sh
Downloading vcpkg-macos...
+./macos_build.sh:19> ARM_TRIPLET='--overlay-triplets=. --triplet=arm64-osx-openrct2'
Telemetry
+./macos_build.sh:20> X64_TRIPLET='--overlay-triplets=. --triplet=x64-osx-openrct2'
---------
+./macos_build.sh:21> LIBRARIES='libpng freetype openssl icu libzip[core] nlohmann-json openal-soft sdl2 speexdsp discord-rpc gtest libflac libogg libvorbis'
vcpkg collects usage data in order to help us improve your experience.
+./macos_build.sh:22> vcpkg/vcpkg install '--overlay-triplets=.' '--triplet=arm64-osx-openrct2' icu
The data collected by Microsoft is anonymous.
You can opt-out of telemetry by re-running the bootstrap-vcpkg script with -disableMetrics,
passing --disable-metrics to vcpkg on the command line,
or by setting the VCPKG_DISABLE_METRICS environment variable.

Read more about vcpkg telemetry at docs/about/privacy.md
Computing installation plan...
The following packages will be built and installed:
  * icu[core,tools]:x64-osx -> 72.1#3
    icu[core]:arm64-osx-openrct2 -> 72.1#3
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-osx...
Detecting compiler hash for triplet arm64-osx-openrct2...
Restored 0 package(s) from /Users/runner/.cache/vcpkg/archives in 60.629 us. Use --debug to see more details.
Installing 1/2 icu:x64-osx...
Building icu[core,tools]:x64-osx...
-- Downloading https://github.com/unicode-org/icu/releases/download/release-72-1/icu4c-72_1-src.tgz -> icu4c-72_1-src.tgz...
-- Extracting source /Users/runner/work/Dependencies/Dependencies/vcpkg/downloads/icu4c-72_1-src.tgz
-- Applying patch disable-escapestr-tool.patch
-- Applying patch remove-MD-from-configure.patch
-- Applying patch fix_parallel_build_on_windows.patch
-- Applying patch fix-extra.patch
-- Applying patch mingw-dll-install.patch
-- Applying patch disable-static-prefix.patch
-- Applying patch fix-win-build.patch
-- Using source at /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/src/c-72_1-src-deba61ed52.clean
-- Getting CMake variables for x64-osx-dbg
-- Getting CMake variables for x64-osx-rel
-- Generating configure for x64-osx
-- Finished generating configure for x64-osx
-- Configuring x64-osx-dbg
-- Configuring x64-osx-rel
-- Building x64-osx-dbg
-- Installing x64-osx-dbg
-- Building x64-osx-rel
-- Installing x64-osx-rel
-- Installing: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/tools/icu/config/icucross.inc
-- Installing: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/tools/icu/config/icucross.mk
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/lib/pkgconfig/icu-i18n.pc
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/lib/pkgconfig/icu-io.pc
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/lib/pkgconfig/icu-uc.pc
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/debug/lib/pkgconfig/icu-i18n.pc
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/debug/lib/pkgconfig/icu-io.pc
-- Fixing pkgconfig file: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/debug/lib/pkgconfig/icu-uc.pc
-- Installing: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/share/icu/vcpkg-cmake-wrapper.cmake
-- Installing: /Users/runner/work/Dependencies/Dependencies/vcpkg/packages/icu_x64-osx/share/icu/copyright
-- Performing post-build validation
Stored binary cache: "/Users/runner/.cache/vcpkg/archives/8d/8dfe3d4c9c12b9a07f0226addc9904b232aeeadcb5a3865654d1adca03ab748a.zip"
Elapsed time to handle icu:x64-osx: 7.535458184733334 min
Installing 2/2 icu:arm64-osx-openrct2...
Building icu[core]:arm64-osx-openrct2...
-- [OVERLAY] Loading triplet configuration from: /Users/runner/work/Dependencies/Dependencies/arm64-osx-openrct2.cmake
-- Using cached icu4c-72_1-src.tgz.
-- Cleaning sources at /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/src/c-72_1-src-deba61ed52.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /Users/runner/work/Dependencies/Dependencies/vcpkg/downloads/icu4c-72_1-src.tgz
-- Applying patch disable-escapestr-tool.patch
-- Applying patch remove-MD-from-configure.patch
-- Applying patch fix_parallel_build_on_windows.patch
-- Applying patch fix-extra.patch
-- Applying patch mingw-dll-install.patch
-- Applying patch disable-static-prefix.patch
-- Applying patch fix-win-build.patch
-- Using source at /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/src/c-72_1-src-deba61ed52.clean
-- Getting CMake variables for arm64-osx-openrct2-rel
-- Generating configure for arm64-osx-openrct2
-- Finished generating configure for arm64-osx-openrct2
-- Configuring arm64-osx-openrct2-rel
-- Building arm64-osx-openrct2-rel
-- setting rpath prefix for macOS dynamic libraries
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: /usr/bin/install_name_tool -id @rpath/libicutu.72.dylib libicutu.72.1.dylib
    Working Directory: /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/arm64-osx-openrct2-rel/lib
    See logs for more information:
      /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/make-build-fix-rpath-arm64-osx-openrct2-rel-err.log

Call Stack (most recent call first):
  ports/icu/portfile.cmake:90 (vcpkg_execute_build_process)
  scripts/ports.cmake:147 (include)

error: building icu:arm64-osx-openrct2 failed with: BUILD_FAILED
error: Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+icu
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[icu]+Build+error
Include '[icu] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
    vcpkg-tool version: 2023-03-14-105f7f7e8a5ea10dfac9874ff9d1a6bacba5f454
    vcpkg-scripts version: 23f0707b1 2023-03-29 (5 hours ago)

Please use the prefilled template from /Users/runner/work/Dependencies/Dependencies/vcpkg/installed/vcpkg/issue_body.md when reporting your issue.
+./macos_build.sh:22> true
+./macos_build.sh:23> cat /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/make-build-fix-rpath-arm64-osx-openrct2-rel-err.log
error: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: libicutu.72.1.dylib (No such file or directory)

Note the last line contains the logs produced by cmake/vcpkg in /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/make-build-fix-rpath-arm64-osx-openrct2-rel-err.log file:
error: /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: can't open file: libicutu.72.1.dylib (No such file or directory)

After running vcpkg, following dylibs are found:
$ find /Users/runner/work/Dependencies/Dependencies/vcpkg/ -name '*icu*.dylib'
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/stubdata/libicudata.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/stubdata/libicudata.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/stubdata/libicudata.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicui18n.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicui18n.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuio.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicudata.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuuc.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicudata.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuio.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuuc.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuuc.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicui18n.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicudata.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/arm64-osx-openrct2-rel/lib/libicuio.72.dylib

Similar issue is present when using x64-osx-openrct2.cmake:
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic)

set(VCPKG_CMAKE_SYSTEM_NAME Darwin)
set(VCPKG_OSX_DEPLOYMENT_TARGET "10.13")

set(VCPKG_BUILD_TYPE release)

…
 -- setting rpath prefix for macOS dynamic libraries
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: /usr/bin/install_name_tool -id @rpath/libicudata.72.dylib libicudata.72.1.dylib
    Working Directory: /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/x64-osx-openrct2-rel/lib
    See logs for more information:
      /Users/runner/work/Dependencies/Dependencies/vcpkg/buildtrees/icu/make-build-fix-rpath-x64-osx-openrct2-rel-err.log

Call Stack (most recent call first):
  ports/icu/portfile.cmake:90 (vcpkg_execute_build_process)
  scripts/ports.cmake:147 (include)

error: building icu:x64-osx-openrct2 failed with: BUILD_FAILED
error: Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+icu
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[icu]+Build+error
Include '[icu] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
    vcpkg-tool version: 2023-03-14-105f7f7e8a5ea10dfac9874ff9d1a6bacba5f454
    vcpkg-scripts version: 23f0707b1 2023-03-29 (15 hours ago)

Please use the prefilled template from /Users/runner/work/Dependencies/Dependencies/vcpkg/installed/vcpkg/issue_body.md when reporting your issue.
+./macos_build.sh:22> true
+./macos_build.sh:24> find /Users/runner/work/Dependencies/Dependencies/vcpkg/ -name '*icu*.dylib'
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/stubdata/libicudata.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/stubdata/libicudata.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/stubdata/libicudata.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicui18n.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicui18n.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuio.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuuc.72.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuio.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuuc.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuuc.72.1.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicui18n.dylib
/Users/runner/work/Dependencies/Dependencies/vcpkg//buildtrees/icu/x64-osx-openrct2-rel/lib/libicuio.72.dylib

I can also confirm libicutu.71.1.dylib was present with the same triplet on vcpkg version 5e7cbdceacd2b3cb85e057963fdb605136805bd3

$ git lol 5e7cbdceacd2b3cb85e057963fdb605136805bd3..23f0707b1a46bbf7fff9fb95cde2aa0c7213c31d ports/icu
* f67d9135a - [icu] Fix x86 MinGW build (#29532) (7 weeks ago)      <Todor Prokopov>
* 261f5b1fc - Fix https://github.com/microsoft/vcpkg/issues/29322 (#29329) (7 weeks ago)      <Matthias Kuhn>
* cdbcc0321 - [icu] Add tools, fix building for ios (#29196) (9 weeks ago)      <Matthias Kuhn>
* cd08228e4 - [icu] Update to 72.1 (#28794) (3 months ago)      <Kai Pastor>

f67d9135a - fails
261f5b1fcc106428df91d2f44f2bec9e50e11868 - fails
cdbcc0321216fe46e4b20941f76ad21429d2a90c - fails
cd08228e4a081ab5a2ee1756bf846ee24520615e - works

cdbcc0321216fe46e4b20941f76ad21429d2a90c (https://github.com/microsoft/vcpkg/pull/29196) is the regression

I submitted a fix: https://github.com/microsoft/vcpkg/pull/30544
Until this is fixed, installing icu[core,tools] instead of just icu addresses my immediate needs.


MSID: 99192 Version: 1 DOI: 10.1101/2<IP_ADDRESS>8235

MSID: 99192
Version: 1
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>8235
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=99192
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>8235

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/99192v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>8235
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/99192/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

@acollings The formatting on the assessment for this article has gone wonky:

Sorry @JGilbert-eLife: this should now be fixed!

Bril, thanks!


php artisan vendor:publish --tag=laravel-bible

/Hi, when i run publish, I get an error "Can't locate path: <../vendor/djunehor/laravel-bible/src/config/laravel-bible.php>". And the other files ,2019_11_22_145649_create_words_table.php.stub,LaravelBibleSeeder.php.stub,entries.csv.zip. I am using the latest laravel 8. Seems like you have not added the files to github. can you please look into it ?

Hi,
Thank you for reporting the bug. The issue has been resolved. You don't need to run an extra step (publish command) after installing the package.  Do let me know how I can be of further help


[Q] Is it possible to keep only x days of backup logs?

Hello,
Currently the logs under logs/latest are simply moved to logs/backup directory. As a result, the logs/backup directory continues to grow. We would like to limit how many logs are kept inside logs/backup. Everything I have found regarding this recommends setting up a scheduled task to nuke older logs. So I just wanted to check directly with you on whether it possible to do this via configuration?
Thanks!

A new snapshot release of HTTP Collector was just made.  You can now add unmanaged="true" to the logsDir configuration option to tell the collector not to manage file-logging.  E.g.:
  <logsDir unmanaged="true"/>

With that new flag, the collector will no longer generate any logs by itself.  With the default log4j.properties, that means it will log to the "console" only.  If you want it to still write to a file and limit the quantity and volume, you can modify the log4j.properties file to do so.  Here is an appender example that will rollover log files larger than 10MB and keep only a maximum of 5 log files:
log4j.appender.rollingFile=org.apache.log4j.RollingFileAppender
log4j.appender.rollingFile.File=/path/to/your/preferred/location/mycollector.log
log4j.appender.rollingFile.layout=org.apache.log4j.PatternLayout
log4j.appender.rollingFile.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %m%n
log4j.appender.rollingFile.MaxFileSize=10MB
log4j.appender.rollingFile.MaxBackupIndex=5
log4j.appender.rollingFile.append=false

log4j.rootLogger=ALL, rollingFile

A few dependencies were updated, so make sure you use a fresh install, or that you do not have multiple versions of the same .jar files under lib.

Question regarding the Jef-monitor: is it true, that if you configure logs to be "unmanaged", then JEF UI will not be able to display job's logs any longer?
Thanks!

That is correct.

What happens if we we match the path of the new log file to the original one. Will the JEF Monitor be able to use that even though the "unmanaged"setting is true? The original log4j file is still being used, with the only exception of it now being rolling?
Thanks

If you look under your working directory, you will find somewhere a file called [Your Crawler Name].index.
That file keeps track of where your progress files are located and what log manager was used to retrieve the logs.  This is what JEF Monitor uses since it does not interact with the processes directly (to not mess with them), it simply reads their progress output.
The default log manager portion of that file looks like this:
<logManager class="com.norconex.jef4.log.FileLogManager">
 <logDir>/some/path</logDir>
</logManager>

Right now, since you are using "unmanaged", it is probably like this:
<logManager class="com.norconex.jef4.log.NoLogManager"/>

So the only way I can think of at the moment is if you somehow manage to copy that index file just for JEF Monitor usage, and change its content to use a log manager like the first example above.  Also, change the other paths if need be.

Hi Pascal,
Thanks