Wrapping numpy.int_ and related types can break expected numpy dtype comparisons

(I noticed this issue in the sampyl MCMC library and initially logged it there as https://github.com/mcleonard/sampyl/issues/14 and in that issue autograd dev mattjj suggested that a fix could be possible in autograd)
The code is checking that a numpy array contains integral values like: if x.dtype != np.int_: but because it is using the autograd wrapped np.int_, the check throws an exception because it is treated as an unknown dtype.
A simple example is attached in test_dtypes.py.txt
Thanks!

Except, it was fixed while I typed in the issue. Great work :)

Sorry to beat you to the punch :) Let us know if there's any more trouble with this bug.


Refactor test in preparation for Groovy 4

Workaround an upcoming Groovy behavior change; Groovy 4.0.5 will apparently not coerce a list to typed array anymore. This may also be related to changes in calls to superclass constructors needing to be wrapped in @CompileStatic-built methods. Nevertheless, just fixing the problem with a cast is the cleanest solution.

This needs to be rebased after #21560 is merged

This needs to be rebased after #21560 is merged

Done.

@bot-gradle test and merge

OK, I've already triggered a build for you.


lsp-julia crashes with "Possible infinite loop" when typing in Julia document

I set up  lsp-julia in emacs to automatically initialize the LanguageServer once I navigate to a Julia file. However, when I try to type the letter d anywhere in the body of the file, I obtain an error (reproduced below) in julia-ls::stderr.
Is there a way to disable the relevant functionality in get_func_hover or collect_completions so that I can use lsp-julia without it constantly crashing? company-dabbrev is sufficient for my purposes, so I do not need completions from lsp.
ERROR: Possible infinite loop.
 Please reopen if the issue persists.


[feat] we should have pull request template

Implement a pull request template to enable users to review essential steps before submitting a pull request.

Hi, please assign me this issue for hacktoberfest. Thanks!


Confirm user

With this PR, users will not longer be able to edit other users events via link.

Codecov Report

Merging #71 into master will increase coverage by 10.08%.
The diff coverage is 85.39%.

@@              Coverage Diff              @@
##             master      #71       +/-   ##
=============================================
+ Coverage     75.22%   85.30%   +10.08%
- Complexity       76      166       +90
=============================================
  Files             9       17        +8
  Lines           452     1082      +630
  Branches         46      103       +57
=============================================
+ Hits            340      923      +583
- Misses          100      127       +27
- Partials         12       32       +20

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/com/google/sps/Firebase.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

...main/java/com/google/sps/servlets/TaskHandler.java
0.00% <0.00%> (ø)
0.00 <0.00> (?)

src/main/java/com/google/sps/SecretHandler.java
20.68% <11.76%> (+20.68%)
2.00 <1.00> (+2.00)

src/main/java/com/google/sps/Recommend.java
78.86% <81.25%> (ø)
16.00 <10.00> (?)

...main/java/com/google/sps/servlets/UserServlet.java
90.19% <84.04%> (+8.19%)
27.00 <10.00> (+7.00)

src/main/java/com/google/sps/Interactions.java
84.41% <84.09%> (+4.41%)
19.00 <12.00> (+10.00)

.../com/google/sps/servlets/KeywordSearchServlet.java
89.76% <89.76%> (ø)
23.00 <23.00> (?)

...in/java/com/google/sps/servlets/SearchServlet.java
92.85% <92.85%> (-1.77%)
9.00 <5.00> (-9.00)

src/main/java/com/google/sps/Utils.java
80.23% <93.33%> (ø)
15.00 <6.00> (?)

...main/java/com/google/sps/servlets/AuthServlet.java
100.00% <100.00%> (ø)
4.00 <0.00> (ø)

... and 19 more

Continue to review full report at Codecov.

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


Storage is currently broken when following the sample

When you follow the sample the following error pops up when reading from the localstorage:
System.AggregateException: One or more errors occurred. (Could not load type 'System.Text.Json.Serialization.JsonSerializerOptions' from assembly 'System.Text.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.)
 ---> System.TypeLoadException: Could not load type 'System.Text.Json.Serialization.JsonSerializerOptions' from assembly 'System.Text.Json, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
   at Microsoft.AspNetCore.ProtectedBrowserStorage.ProtectedBrowserStorage.GetAsync[T](String purpose, String key)
   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.AspNetCore.ProtectedBrowserStorage.ProtectedBrowserStorage.GetAsync[T](String purpose, String key)
   at Microsoft.AspNetCore.ProtectedBrowserStorage.ProtectedBrowserStorage.GetAsync[T](String key)

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

ID: ae14b3e3-3271-b919-9e0a-6f317a6b2d2d
Version Independent ID: e5e1273b-195e-5da1-b4aa-66bbcff1425b
Content: ASP.NET Core Blazor state management
Content Source: aspnetcore/blazor/state-management.md
Product: aspnet-core
Technology: aspnetcore-blazor
GitHub Login: @guardrex
Microsoft Alias: riande

Hello @vertonghenb ... Open that for the repo where that package lives :point_right: https://github.com/aspnet/AspLabs/issues
... and then after you/they find out what went wrong if it's a docs issue, ping me back over here and then we'll re-open this issue and work it.


Can't Start HiddenEye-Reborn

I do hope this isn't a crazy question but this is the first time coming back to a newer version of hiddeneye, one which doesn't have any steps on how to run it, since theres no file or directory that was downloaded to the path i was on, im unable to locate how to run it successfully. i did notice its located in .local/bin. and tried running the following ./hiddeneye-reborn, but i only get this without further instructions. any assistance is appreciated
2024-08-31 14:47:44,658 [INFO] Success, you can access this via terminal!                                                                                hiddeneye.py:16
2024-08-31 14:47:44,662 [INFO] THIS IS NOT PRODUCTION READY, STOP MAKING USELESS ISSUES PLEASE                                                                                hiddeneye.py:17
2024-08-31 14:47:44,664 [DEBUG] Logging level set to 10                                                                                hiddeneye.py:18
2024-08-31 14:47:44,682 [WARNING] Unable to verify connection with https://google.com due to <urlopen error [Errno -3] Temporary failure in name resolution>, returning False                  verification.py:26
2024-08-31 14:47:44,686 [DEBUG] Non-interactive mode set to False                                                                                hiddeneye.py:20

@Midget-Man Try reading the output of line 16

This is my result after reading line 16.
sudo ./hiddeneye-reborn
Traceback (most recent call last):
File "/home/alpha/.local/bin/./hiddeneye-reborn", line 5, in
from hiddeneye_reborn.hiddeneye import execute
ModuleNotFoundError: No module named 'hiddeneye_reborn'

@Midget-Man No, literally read the message you posted above, specifically the "THIS IS NOT PRODUCTION READY, STOP MAKING USELESS ISSUES PLEASE" part 😅


Low score of Cumulative Layout Shift due to weird flashing of element on hydration

I am trying to investigate weird flashing of elements on hydration; specifically it happens to our Hero element on our page, that is set to hydrate when visible. Have a look at this example from Google Pagespeed:

It can also be seen on our website: https://beta.thejewelleryroom.com - try to hard refresh and notice the brief blinking:

Anybody who knows what this could cause, or could point me in some direction?

I analysed the problem a little.
When the element should be hydrated (this.hydrated is true) the LazyHydrate component returns the VNode in the default slot. However, the VNode's componentOptions.propsData is undefined.
Later, the propsData is set and we enter the render function again.

@janKollars interesting 🤔
Thanks for taking a closer look. I'll see if I can do something about it.
Any help is appreciated!

Thanks @janKollars! That was a good investigation. I am curious how you did it though. I wanted to replay the rendering frame-by-frame, but I haven't found a way to do this properly.

For debugging I copied the project's code and created a minimal setup.
Then, I placed breakpoints in my browser's DevTools.
You might want to watch the line where the child is returned and check its propsData.

Stumbled over this issue as well. It seems to be related to lazy loading the hydrated components using vue-lazy-hydration's scoped slot logic. Just lazy hydrating works and there's no flicker, but as soon as I want to lazy-load the component as well... trouble.
I managed to work around the issue by letting an independent observer watch for the intersection and using it to manually trigger the hydration. It looks like this:
      <lazy-hydrate
        v-slot="{ hydrated }"
        ssr-only

        :trigger-hydration="intersected"
      >

          <lazy-component
            v-if="hydrated"

          />

      </lazy-hydrate>

This seems to work just fine. The chunk lazy-loads and there's no flickering. Images are however reloaded, so I'm not sure this solves the issue of @simplenotezy. But if you just want to defer rendering outside the user's initial viewport, this might be a viable workaround.

@j0Shi82 Thanks for your reply. Funny that you just respond, I just went to this GitHub issue to bring an update, and here's your reply only 9 minutes ago.
Anyhow. I managed to get rid of the page jumping. It was related to something else than the data-prop I believe.
How I overcame the "page jumping" issue.
I load my Hero component like this:
Hero: hydrateWhenVisible(() => import('~/components/templates/FlexibleContent/partials/Hero.vue')),

And inside my template, I would reference it like this (simplified):
<component :data="section" :is="'Hero'" :class="'section'" />

Inside my Hero.vue, it would look like this:

What I had to do was to remove the :class from the lazyhydrated component, and instead add the class inside the component. So it would become this:
<component :data="section" :is="'Hero'" />

And in my component:

And now the page don't jump. So it appears to be related to :class/class being added directly to the lazy loaded component.
I still have issues with images being reloaded/flickering, and I am not yet sure how to overcome this.

@j0Shi82 why don't you use when-visible?
<Lazy-hydrate when-visible>

    <lazy-component

    />

</lazy-hydrate>

@maoberlehner Because then the lazy-loaded items "flicker" once they get hydrated. I'll try to get a minimal repro up to make sure it's nothing on my end. Turns out my solution does alleviate the flickering, but isn't able to completely solve it either. I'll try to come back with more information.

@maoberlehner Have you had any time to look at this yet? It's quite a big issue for our Cumulative Layout Shift score.
Here's another weird example:

The section hydration is triggered immediately like this:
<LazyHydrate :trigger-hydration="true">

So it's pretty weird.

I haven't been able to get a minimal repro up, but managed to find the cause of our flickering. It seems to only occur when using the LazyHydrate component with code splitting logic (in our case with when-visible). This example from the official docs should have the same issue:
   <LazyHydrate
      v-slot="{ hydrated }"
      when-visible
    >

        <CommentForm
          v-if="hydrated"
          :article-id="article.id"
        />

    </LazyHydrate>

Within the lazy-loaded component I inspected the state at the time of the created hook. You can clearly see that the component inside the LazyHydrate slot "disappears" completely and then gets re-rendered, leading to a noticable "flickering" on the screen, especially for large components. More than that, it can trigger a weird hydration chain:

Component A gets hydrated, disappears
Component B slides to the top into the viewport, gets hydrated, disappears
Component C slides to the top into the viewport, gets hydrated, disappears

This doesn't happen all the time, but in a good number of cases all when-visible components can get hydrated/rendered whenever the first when-visible is triggered.
Because of that I switched to the Wrappers, which seems to work just fine for use. You also don't run into issues when not using code-splitting.
Cheers!

Thanks for your throughout answer @j0Shi82. I also experience issues with page jumping to top once page has been hydrated (e.g. from the initially loaded HTML that is server side rendered, and to then when page hydrates using javascript, the page jumps to top). Not sure if that's related as well?
Anyhow, in regards to the use of wrappers, do you mean import wrappers? https://github.com/maoberlehner/vue-lazy-hydration#import-wrappers

Anyhow, in regards to the use of wrappers, do you mean import wrappers? https://github.com/maoberlehner/vue-lazy-hydration#import-wrappers

Yes

@j0Shi82 thanks. That worked way better, we don't see flickering anymore.

Our organic traffic has decreased 300% since october, and it has been a huge mystery to us, why this has happened all of a sudden. Upon hours of code review and investigation a very clear picture starts to be pained: flickering of lazy hydrated sections (resulting in page jumps and CLS) causes the decrease of traffic. Google must've changed their algorithm (and they did). They penalise much harder on CLS now than before, so this should be considered an quite important task.

Thanks all for your work on this. I'd like to take a closer look at this in the next days. It would be a great help if you can create a minimal reproduction repository.

I was wrong. It had nothing to do with props. Instead, I believe the problem is caused by the render function in loadingComponentFactory. I tried returning a vnode "copy" of the server-side-rendered element and it works.
I will create a quick pr so you can test my solution.

Although the page-jumping does not happen when using Wrappers, I noticed that it does/can happen when switching pages.

(try live example here: https://thejewelleryroom.com).
It specifically happens when loading Product pages, where I am lazy-loading an ImageSlider component like so:
ImageSlider: hydrateWhenIdle(() => import('~/components/product/ImageSlider')),

@maoberlehner I am happy to share access to our GitHub repo for you to review, if that would be helpful.

@simplenotezy thanks! But I highly prefer a minimal reproduction repository.

I just published an alpha version of 2.0! https://www.npmjs.com/package/vue-lazy-hydration/v/2.0.0-alpha.0
Although I did nothing specific to fix this issue, the changes I made could potentially fix this too.
Attention: ssr-only is now never as in Hydrate? Never!.

@simplenotezy Web Vitals hasn't hit Web Ranking yet.
https://twitter.com/dalmaer/status/1326201817647124480

Awesome @maoberlehner! Where's the changelog for this? Will apply version 2 and see if it fixes the CLS issue.

@maoberlehner I have just tested out version 2, and unfortunately it still has CLS issues, where the page will jump when switching page. See this recording:

The way I load the ImageSlider that is jumping is like so:
ImageSlider: hydrateWhenIdle(() => import('~/components/product/ImageSlider'))

If I do it without lazy hydrating, the section will not "jump".
ImageSlider: () => import('~/components/product/ImageSlider')

It is really hard for me to see the problem on that gif because Idk where it starts and everything happens so quickly. Would highly prefer a video, that I can pause and play on demand.

Hey @maoberlehner - Will this suffice? https://youtu.be/uhSBueZuFTI

Much better. Thanks!

Great. @maoberlehner. Perhaps if there was a way to disable LazyHydration once the page has hydrated once (and any PageSpeed score test would've completed). So when going to a new page, LazyHydration is disabled, unless explicitly enabled on some components.

This is already happening.  Not sure why this is not the case.

Can you please make sure that the problem still exists with 2.0.0-beta.2 I released today? Thanks!

@maoberlehner Apologies for my late response. The issue came to my attention again after discussing this matter with a colleague of mine. I just tried installing version 2.0.0-beta.2 instead of ^1.0.0-beta.12, however, I get this error notification right away:
render function or template not defined in component: FlexibleContent

Not sure if there are any breaking changes I need to take care of first?

And could we perhaps open this issue until a solution is found? I am more than happy to help out with anything you need.

How does Sections.vue look like?
Does it work without lazy hydration?


Enums not imported

Describe the bug
The generated index.ts doesn't import all enums from schema.prisma. In my case, it contains most but a few, and it looks like only enums that are set on just optional fields are not imported, despite being assigned correctly, which causes the app to break due to missing imports.
i.e Here the enum is set, but it's not imported

To Reproduce

Create an enum type in schema.prisma, and set it to an optional field. *Don't use the same enum elsewhere (especially in a required field).
generate Prisma models
Visit the generated module, and most likely you will see that enum is not imported

Expected behavior
The enums should be imported

@leandrit1
Thanks for your reporting this issue. I fixed this and published as v1.0.1

Thanks man. Awesome package!


Make a cleanup and update database script

Kind of request
Adding new functionality
Enhancement Description
Make a script to update the database for when we make changes to the database
Make a script (or combined) that cleans up the database
Task list

[ ] make script 1
[ ] Make script 2

Use case
No response
Additional Context
No response

The attached PR is closed as not necessary because it was implemented elsewhere. @LuukBlom does that mean we can close this issue?


route refresh support for exabgp

apparently i was looking at a bogus/outdated manpage as this doesnt actually work upon further testing. let me sort out the proper bits.

Ok, will let you sort out so it's working... but as for the code. Do you think we need an extra argument for this? Should it not just be enabled per default? or statically hard coded enabled?

i am fine with either enabled by default or hardcoded enabled...i think we've seen only a handful of sessions that dont support it by default in our network(and those were non bgp4 compliant stacks).
didnt want to assume people wanted this so didnt want to force it on anyone, but if thats what people want(we want it as some stacks operate differently depending on wether RR is negotiated. for example accept-remote-nexthop on juniper will bounce the session if RR isnt enabled).


Feature/tests

PENDING

[ ] lint stage too tests
[x] publish docker image
[ ] cherry-pick

https://github.com/ebanx/woocommerce-gateway-ebanx/pull/630


Tukan Theme Update for Sidebar

@Franco

5 columns would be worth considering. that would offer in my opinion now, since the screens in general tend to be wide. Also of the resolution. I have now taken the cicada theme as an example(screenshot). But of course it is possible for all themes. Worth a consideration? Pfsense can currently be adjusted to 6 columns. For monitoring purposes a must have. What do you think?

Beautiful screenshot! Gut gemacht Rene 👍

looks good but keep in mind that IPv6 addresses are longer.

@opnsenseuser yes, looks very nice. :) as users can select and save their column count it's ok to add more here. Do you want to do the change or should we?

would be great if you can do that. I'm on vacation for 2 weeks. best regards, rene
Freitag, 13. Juli 2018, 20:02 +0200 von Michael<EMAIL_ADDRESS>
@opnsenseuser yes, looks very nice. :) as users can select and save their column count it's ok to add more here. Do you want to do the change or should we?
—
You are receiving this because you were mentioned.
Reply to this email directly,  view it on GitHub , or  mute the thread .

@martin. Please pr the Main.css file i sent to you a few days ago. Maybe that file works.
Rene
Gesendet von myMail für iOS
Freitag, 13. Juli 2018, 20:14 +0200 von Michael<EMAIL_ADDRESS>
@fabianfrz commented on this pull request.
In  misc/theme-tukan/src/opnsense/www/themes/tukan/assets/stylesheets/main.scss :

@@ -1,8078 +1,9818 @@
-@charset "UTF-8"

@fichtner you are right:
sassc main.scss
Error: Invalid CSS after "...rder: 1px solid": expected expression (e.g. 1px, bold), was "#565656cc;"
on line 7960 of main.scss

border: 1px solid #565656cc;
--------------------^

—
You are receiving this because you were mentioned.
Reply to this email directly,  view it on GitHub , or  mute the thread .

Corrected in main.scss and regenerated.

Merged, thanks!


Adds support for .ts views.

Fixes #121

@Zoltu Thanks! If you would like, there's another place. In framework/plugins there's some code that would need the same fix. Interested in submitting another PR for that as well?

I don't mind, though I'm not sure where to find it.  I searched for html in templating repo to find this one, same search in framework doesn't yield promising results.

Ah, found it.  I'll fix.


Upgrade of postgres and solr

Our sysadmin asks for upgrading to newer versions of postgres and solr in the docker container setup. Currently, there are freeze versions in place that are already out of support (postgresql:9.6 and solr:8.2.0).
The first question would be, if there are any general objections against upgrading to more newer versions - ideally the newest ones - and if not, how to introduce a workflow so that we are able to upgrade continuously.
The second question is how to do the upgrade in detail, how to test and how to prevent unwanted side effects.
@tparkola What is your opinion on this?

@tparkola When importing the database dump of the old postgres 9.6.16 version into the new postgres 15.4.0 version, I got two errors, did you also encounter these errors when you tested the new postgres version?
ERROR:  column "id" of relation "item_links" is an identity column
HINT:  Use ALTER TABLE ... ALTER COLUMN ... DROP IDENTITY instead.
[...]
ERROR:  cannot drop sequence public.item_links_id_seq because column id of table public.item_links requires it
HINT:  You can drop column id of table public.item_links instead.

the first refers to the line ALTER TABLE public.item_links ALTER COLUMN id DROP DEFAULT; and the second to the line DROP SEQUENCE public.item_links_id_seq;

our sysadmins asked me if it is possible to upgrade the Solr to the version 9.x - @tparkola do you think that this is doable? I guess it is more troubling, as the major jump from current version 8.x to 9.x could be tricky. Can you maybe estimate, how easy this could be done?

Hi,

I cannot recall problems with importing data, however, I'm not sure if I did full import. If you will provide me with a dump I can try.
In case of solr 9.x - I was able to reach this version, though with some additional re-configuration of both solr and backend. In general the problem is that spring data for solr has been deprecated and does not support newer versions of solr. I was able to overcome that, but this is not a long-term solution. Please review / test these changes thoroughly, as they are not a typical way to do so.
We need to move from solr data to solrj at some point and this is a bigger task. I will add it to the backlog, so that we can plan it.

Thanks for the feedback - regarding the import of data: when inserting the dump the first time, the mentioned errors showed up, when doing the import of the dump again, the errors disappeared (it occurred for every instance). I leave it as it is as the database looks correct. If we discover problems in the future, then this could be a cause but I think this is very implausible.
Thanks for looking into the solr issue, I will test it in the next weeks. And yes, a long-term solution is very welcomed ;)

this is now finished and solr 9.3.0 is in place on all instances, especially also in the production instance.


facial asymmetry placement

facial asymmetry MP:0030099 should be made a child of craniofacial asymmetry MP:0008863 and abnormal face development MP:0030313.

Done.


[Tooltip] Downgrade disabled error to a warning

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Summary 💡
I get the following error when I have a disabled button nested in a tooltip:
You are providing a disabled `button` child to the Tooltip component.
A disabled element does not fire events.
Tooltip needs to listen to the child element's events to display the title.

This is the behavior I want - for the tooltip to be disabled while the button is disabled.
Can we downgrade this from an error to a warning? An ideal solution would be to add a disabled prop to the tooltip component that passes down.
Examples 🌈
No response
Motivation 🔦
No response

Agree, a warning sounds better for this. cc @mui/core

Also could you please tell us which Tooltip?
We have more than 40 Tooltips in our app and this is what we see:

How are we supposed to find out which Tooltip is causing this error/warning?

@Nefcanto thanks for reaching out and sorry for the delay.
I'll add the  waiting for 👍🏼 label so the community can vote for this new feature. If you want to see this implemented, please add a 👍🏼 reaction to the issue's description. I'll also add the ready to take label in case anyone wants to work on this before the team gets to it. Please reach out if you're interested, I'll gladly guide you.

Hi @DiegoAndai
Can you please tell me what needs to be done here?
Replace console.error with console.warn?

Hey @DiegoAndai @siriwatknp
I've raised a PR https://github.com/mui/material-ui/pull/44846
Can you please review it

Under #21979, I guess error -> warn make sense.

An ideal solution would be to add a disabled prop to the tooltip component that passes down.

@Nefcanto You are expected to set the title to an empty string in this case. At least, it's the DX that was designed to support your use case.


Add math related abbreviations

Mathematic terms:

mathematic • math : Useful for class names or lib names | Ex: rpc_math, math_lib, math_basics
matrix • mtx / mat : Used for math purposes related to matrix operations | Ex: mtx_scale(), mtx_rot(), new_mat(), cpy_mat

Trigonometric functions:

arccosine • acos
arcsine • asin
arctangent • atan
cosecant • cosec
cotangent • cot • ctg
secant • sec

Mathematic measures:

degrees • deg
radians • rad

Matrix operations:

inverse • inv
inverted • inv

I think math is not an abbreviation also because is super obvious.
Sin and cos are there, tan is missing I'm also adding it.
There're also arcsec, arcosec and arccot.
Deg and rad👍
I think inverted is already included in inverse.
I've seen you also added exponential which is ok.
Geometric same story as inverted I think is already included in geometry.

@T1xx1 Done! Applied your suggestions 😉

Thank you @Firemanarg!
Merging, fixing and rebuilding.


Revert Notification Color Defaults To Pre-Revamp Colors

Follow-up to #1591
This reverts the notification colors to what we had pre-revamp, with one exception. I changed the warning foreground from white to almost black, because white on bright yellow isn't very legible.
Note also that in #1591 I prefixed the keys with oni. to distinguish them from the "standard" vscode colors. I'm trying to do that with all the keys, to prevent future collisions, so that users get a better idea of which colors won't be themed by vscode themes and that they therefore might have to tweak themselves, and for us to have a better idea of what we can freely change without breaking vscode compatibility and not have to dig around in the vscode source for.

This reverts the notification colors to what we had pre-revamp, with one exception. I changed the warning foreground from white to almost black, because white on bright yellow isn't very legible.

Perfect 👌

Note also that in #1591 I prefixed the keys with oni. to distinguish them from the "standard" vscode colors.

Sounds good. It makes sense to be able to easily differentiate the theme colors we are adding.


Auto Some-wrapping of Option config values

E.g. if the Config struct contains a foo: Option<i32>, a value of foo: 42 in the config should be accepted, and converted to Some(42) automatically, instead of failing to deserialize.

I believe this is what the newtype extension does - #72

@kvark I don't mean newtype wrapping, I meant if my struct has a field #[serde(default)] foo: Option<i32> then currently the ron file has to contains foo: Some(42), even though if I want None, I just omit the field.
With serde_json, writing foo: 42 works, too (becomes Some(42)).
But maybe that's not a good behavior because of ambiguity in cases like Option<Option<T>>..

Ah sorry, you are totally right, discard my previous comment 😅

@Boscop If you are willing to use third-party crates you could try serde_with::rust::unwrap_or_skip. It was written for RON. It only requires some attributes on the optional fields: #[serde(default, skip_serializing_if = "Option::is_none", with = "::serde_with::rust::unwrap_or_skip")]

@jonasbb Thanks. (Btw, this issue was about deserializing T into Option<T> which is now supported via the implicit_some extension.)
But yes, I also often want the reverse: Skipping None during serialization (and serializing only val instead of Some(val) in that case.
So the point of with = "::serde_with::rust::unwrap_or_skip" instead of just #[serde(default, skip_serializing_if = "Option::is_none")] is that Some(val) will serialize as just val, right?

@Boscop The listed combination of attributes works for serialization and deserialization. This allows you to round trip the data. It also allows you to omit the Some(_) part without explicitly listing it as an extension.
I didn't know about the extensions yet, I should check how implicit_some interacts with serde_with::rust::unwrap_or_skip.

So the point of with = "::serde_with::rust::unwrap_or_skip" instead of just #[serde(default, skip_serializing_if = "Option::is_none")] is that Some(val) will serialize as just val, right?

Yes, exactly. This then allows you to also serialize these documents.

It also allows you to omit the Some(_) part without explicitly listing it as an extension.

That's a great advantage, the extension line confuses people who come from JSON.
I wish I could also enable the unwrap_newtypes extension statically (https://github.com/ron-rs/ron/issues/281) so that it also works when serializing (https://github.com/ron-rs/ron/issues/284).


⚠ ClamAV has degraded performance

In d5db6dd, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 69 ms

Resolved: ClamAV performance has improved in b12a116 after 540 days, 9 hours, 58 minutes.


LUCENE-10463: increment java version to 17 in smoke tester

Update java version in the smoke tester for main branch. We don't run the script on CI servers for main; just to make it work on main for testing purposes etc.
This works for me on main / java 17.
Alternative java home is also updated to '18' for now. This will be updated to the desired version in a future follow-up if needed.

I'm skipping Actions CI checks (this does not run the smoke tester as far as I know).


Jenkinsfile checkout SCM leaves repo in detached head

... therefore the jgitver plugin refuses to add a branch name to the artifact I'd.
My Jenkins console says "obtaining jenkinsfile from [the hash]"
So my builds are always detached.
Does this plugin work with multi ranch pipelines?
Thanks

@Johnlon even if I am not a big fan of it, as a follow up of #40, you can now specify a branch qualifier as a system property or as an environment variable

using either jgitver.branch system property or JGITVER_BRANCH environment variable.

See https://github.com/jgitver/jgitver-maven-plugin#command-line-arguments or https://github.com/jgitver/gradle-jgitver-plugin#building-on-detached-head

reopen if required


All That Money Can Buy Quest Won’t Start

I completed the Crimson Fleet quest and the main quests up until this one. No new quest started after I finished the quests with the temples, and I was confused. The next quest is supposed to be All That Money Can Buy, but it won’t prompt me to begin.

Details
I did run a command to complete the Empty Nest quest, which was also bugged for me(I made a post about this too.), it let me progress but in the quest menu the quest itself it checked off, but not “pick up the artifact”. I’m thinking this has something to do with this, but I couldn’t go around using a command, since it was bugged.
Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
Yes
Reproduction Steps
Do all Crimson Fleet quests, siding with the fleet, then all the main quests, Emoty Nest will be bugged so fix it with a command, after that the next main quest isn’t starting.

It's still broken after the Update 1.10.30, at least for current save games.


EntityCluster support customized primitive

I can only add label, point and billboard primitives by listening the cluster event, but I want to be able to add primitives more freely.
Currently I can add primitive by cluster.label.position:
dataSource.clustering.clusterEvent.addEventListener(
  (clusteredEntities, cluster) => {
    const position = cluster.label.position

    scene.primitives.add(new Primitive(/* use position */))
  }
)

However I cannot know when these primitives should be removed, because the cluster event is for each clustering point be created rather than camera changed each time.
Expected usage case:
dataSource.clustering.clusterEvent.addEventListener(
  (clusteredEntities, cluster) => {
    cluster.customPrimitive = new Primitive()
  }
)

For my suggestion, may be made some modifications here:
function addCluster(position, numPoints, ids, entityCluster) {
  const cluster = {
    position,
    billboard: entityCluster._clusterBillboardCollection.add(),
    label: entityCluster._clusterLabelCollection.add(),
    point: entityCluster._clusterPointCollection.add(),
    customPrimitive: undefined
  }

  // ...

  entityCluster._clusterEvent.raiseEvent(ids, cluster)

  if (defined(cluster.customPrimitive)) {
    entityCluster._customPrimitives.push(
      entityCluster._scene.primitives.add(cluster.customPrimitive)
    )
  }
}

function createDeclutterCallback(entityCluster) {
  return amount => {
    // ...

    const scene = entityCluster._scene
    const customPrimitives = entityCluster._customPrimitives // Primitive[]

    // ...

    if (defined(customPrimitives) && customPrimitives.length) {
      customPrimitives.forEach(scene.primitives.remove)
      customPrimitives.length = 0
    }
  }
}

Thanks.

I noticed that I can listening to the camera.changed event before adding dataSource into viewer to perform remove primitives, but I think this may not atomic.
Another expected usage is to add a before event:
function createDeclutterCallback(entityCluster) {
  return function (amount) {
    // ...

    entityCluster._beforeClusterEvent.raiseEvent()

   // ...
  }
}

Thanks for the suggestion @qmhc! We're currently working on other parts of the code but we'll keep an eye out on this for the future. In the meantime, the users on our community forum might be able to help figure out a workaround.

Thanks for your reply @ebogo1!
In my opinion, this case is different from #5760.
I want to create and add a custom primitive at the clustering position to instead of the original primitive, is not to know whether the entity is clustered.
Currently I use the following way:
const customClusterPrimitives = []

const removeListener = viewer.scene.camera.changed.addEventListener(() => {
  customClusterPrimitives.forEach(viewer.scene.primitives.remove)
  customClusterPrimitives.length = 0
})

dataSource.clustering.clusterEvent.addEventListener(
  (clusteredEntities, cluster) => {
    cluster.label.show = false
    cluster.point.show = false
    cluster.billboard.show = false

    const position = cluster.label.position
    customClusterPrimitives.push(
      scene.primitives.add(new Primitive(/* use position */))
    )
  }
)

// on destroy
removeListener()

I want EntityCluster can provide a way to resolve this case to avoid external actions.

Ah, my mistake. Thanks for the clarification!

@qmhc Yeah, that seems to be what is covered by #4656 as well :+1:. I'll leave a comment there as well, thanks.


Feature/new platforms

XRTK - Mixed Reality Toolkit Pull Request
Overview

Added https://github.com/XRTK/Etee
Added https://github.com/XRTK/Examples
Added https://github.com/XRTK/Lenovo
Added https://github.com/XRTK/Nreal
Added https://github.com/XRTK/SteamVR
Added https://github.com/XRTK/Ultraleap
Updated build pipeline to build and validate android builds

Submodule Changes

[ ] ARCore
[x] Etee
[x] Examples
[x] Lenovo
[x] Nreal
[x] SteamVR (OpenVR)
[x] Ultraleap

Remember to review the submodules and let them get merged to dev before approving this PR

etee showing ticked in the list but has not been added as a submodule @StephenHodgson ?

I have not added it yet. Still working on the ARCore setup and Template Gen Tutorial

#598 submitted to add etee module and fix gitnore file for new platforms

Thanks mate! approved


[Bug]: the Space_Grotesk font-family is not used in the navbar

Current Behavior
The navbar just uses the default font provided by the browser.
Expected Behavior
I think we should use the Space Grotesk font in the navbar too since it's used everywhere else on the website
What browsers are you seeing the problem on?
Firefox, Chrome, Safari, Microsoft Edge

Same for the Footer also @NDOY3M4N
The issue is general; I tested it on Chrome, Edge, and Safari.


fix: broken installation link

Type of change

Documentation

Changes
The following changes have been made:

updated broken link

Notes

Note 1

Related Issues

Closes #215

Awesome 👍


Ignores HUSKY_GIT_PARAMS

Thanks for this migration tool, has been really helpful migrating all my hooks!
It did ignore HUSKY_GIT_PARAMS though and put the command unmodified into .husky/pre-commit
Was an easy fix using the migration FAQ, but the tool should at least warn about it.
BTW: in my case I had to replace
commitlint -E HUSKY_GIT_PARAMS

by
commitlint --edit $1

Thanks for the feedback. A warning should be shown (maybe it wasn't apparent enough though)
https://github.com/typicode/husky-4-to-5/blob/main/src/config.ts#L59

Just ran it again and can confirm the warning to show. Must have missed it due to my terminal color theme :-) Sorry.


add swagger doc using utoipa resolves #85

Basics

[ ] Details of what you changed are in commit messages
(first line should have module: short statement syntax)
[ ] References to issues, e.g. close #X, are in the commit messages.
[ ] The buildserver is happy.
[ ] The PR is rebased with current master.

Checklist

[ ] I added unit tests for my code
[ ] I fully described what my PR does in the documentation
(not in the PR description)
[ ] I fixed all affected documentation
[ ] I fixed all affected decisions
[ ] I added code comments, logging, and assertions as appropriate
[ ] I mentioned every code not directly written by me in reuse syntax

Review

[ ] Documentation is conforming to our Documentation Guidelines
[ ] Examples are well chosen and understandable
[ ] Code is conforming to our Coding Guidelines
[ ] Code is consistent to our Design Decisions

@markus2330 here is how the swagger doc using utoipa as described in #85 would look like. Currently there is quite a lot of configuration that has to happen and generics are only somewhat nice to use (e.g. the get endpoint for seeds doesn't display an array in swagger, because it is a double nested generic Body<Vec<SeedDto>>).
An easy solution for that would be to remove the Body<T> struct as mentioned here: https://github.com/ElektraInitiative/PermaplanT/pull/68#issuecomment-1448299425. It shouldn't take longer that ~30min to remove body (including the frontend).

Please also write a decision about it so that it is clear what the pros/cons are. In particular it should be clear which extra effort it is to maintain it.

@markus2330 I just pushed the decision. Is that what you are looking for?
If that is ok I would continue with Utoipa and as a next step remove the Body struct from frontend and backend. After that I might add a few examples in swagger and then this would be ready to merge.

I removed this from the project (we only add issues to the project)


Failure when using --replication still reports import in osm.pgosm_flex table

What version of PgOSM Flex are you using?
0.7.0.beta.1

Docker image
0.7.0.beta.1
What did you do exactly?
I ran docker exec ... --replication to update a database that was configured with max_connections=50.  Per https://github.com/openstreetmap/osm2pgsql/discussions/1650, this failed.  The result was a failed update, yet the osm.pgosm_flex table reported the import.
SELECT id, imported, osm_date, pgosm_flex_version,
        osm2pgsql_mode
    FROM osm.pgosm_flex
    WHERE id >= 3
;

id|imported                     |osm_date  |pgosm_flex_version|osm2pgsql_mode|
--+-----------------------------+----------+------------------+--------------+
 3|2022-12-14 19:02:41.425 -0700|2022-12-14|0.6.3-97a1fe3     |create        |
 4|2023-01-16 17:24:37.244 -0700|2023-01-16|0.7.0.rc.1-e4eec24|append        |
 5|2023-01-16 17:26:25.813 -0700|2023-01-16|0.7.0.rc.1-e4eec24|append        |

What did you expect to happen?
The row with id = 4 should either:  a) Not exist; or b) Report the failure
id|imported                     |osm_date  |pgosm_flex_version|osm2pgsql_mode|
--+-----------------------------+----------+------------------+--------------+
4|2023-01-16 17:24:37.244 -0700|2023-01-16|0.7.0.rc.1-e4eec24|append        |

What did happen instead?
There is no indication other than the terminal output that anything went wrong.

I can reproduce with the following, assuming I have the --osm-date available locally.
export POSTGRES_USER=postgres
export POSTGRES_PASSWORD=mysecretpassword

docker run --name pgosm -d --rm \
    -v ~/pgosm-data:/app/output \
    -v /etc/localtime:/etc/localtime:ro \
    -e POSTGRES_PASSWORD=$POSTGRES_PASSWORD \
    -p 5433:5432 \
    -d rustprooflabs/pgosm-flex:0.7.0.rc.1 \
    -c max_connections=100 # 100 is default.  Works for initial import, fails for subsequent import.  See https://github.com/openstreetmap/osm2pgsql/discussions/1650

# Initial import works
docker exec -it \
    pgosm python3 docker/pgosm_flex.py \
    --ram=8 \
    --region=north-america/us \
    --subregion=district-of-columbia \
    --pgosm-date 2022-12-30 \
    --replication

# Subsequent refresh fails
docker exec -it \
    pgosm python3 docker/pgosm_flex.py \
    --ram=8 \
    --region=north-america/us \
    --subregion=district-of-columbia \
    --replication

The second docker exec command fails with
2023-01-18 19:44:27,991:INFO:pgosm-flex:helpers:2023-01-18 19:44:27    Processed 3472 nodes in 0s - 3k/s
2023-01-18 19:44:27,992:INFO:pgosm-flex:helpers:2023-01-18 19:44:27    Processed 1096 ways in 1s - 1k/s
2023-01-18 19:44:27,992:INFO:pgosm-flex:helpers:2023-01-18 19:44:27    Processed 176 relations in 0s - 176/s
2023-01-18 19:44:28,576:INFO:pgosm-flex:helpers:2023-01-18 19:44:28  ERROR: Connecting to database failed: connection to server at "localhost" (<IP_ADDRESS>), port 5432 failed: FATAL:  sorry, too many clients already
2023-01-18 19:44:28,576:INFO:pgosm-flex:helpers:.
2023-01-18 19:44:28,581:INFO:pgosm-flex:helpers:Traceback (most recent call last):
2023-01-18 19:44:28,581:INFO:pgosm-flex:helpers:File "/usr/local/bin/osm2pgsql-replication", line 556, in <module>
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:sys.exit(main())
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:File "/usr/local/bin/osm2pgsql-replication", line 550, in main
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:return args.handler(conn, args)
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:File "/usr/local/bin/osm2pgsql-replication", line 410, in update
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:subprocess.run(osm2pgsql, check=True)
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:File "/usr/lib/python3.9/subprocess.py", line 528, in run
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:raise CalledProcessError(retcode, process.args,
2023-01-18 19:44:28,582:INFO:pgosm-flex:helpers:subprocess.CalledProcessError: Command '['/usr/local/bin/osm2pgsql', '--append', '--slim', '--prefix', 'planet_osm', '--output=flex', '--style=./run.lua', '--slim', '-d', 'postgresql://postgres:mysecretpassword@localhost:5432/pgosm?application_name=pgosm-flex', '-d', 'postgresql://postgres:mysecretpassword@localhost:5432/pgosm?application_name=pgosm-flex', '/tmp/tmp5ggs5l4u/osm2pgsql_diff.osc.gz']' returned non-zero exit status 1.
2023-01-18 19:44:28,611:WARNING:pgosm-flex:pgosm_flex:Failure. Return code: 1
2023-01-18 19:44:28,611:INFO:pgosm-flex:pgosm_flex:Skipping pg_dump
2023-01-18 19:44:28,611:WARNING:pgosm-flex:pgosm_flex:PgOSM Flex completed with errors. Details in output

The info in osm.pgosm_flex would indicate success  :(
SELECT id, imported, osm_date, pgosm_flex_version,
        osm2pgsql_mode
    FROM osm.pgosm_flex
;

id|imported                     |osm_date  |pgosm_flex_version|osm2pgsql_mode|
--+-----------------------------+----------+------------------+--------------+
1|2023-01-18 19:43:17.405 -0700|2022-12-30|0.7.0.rc.1-e4eec24|create        |
2|2023-01-18 19:44:26.132 -0700|2023-01-18|0.7.0.rc.1-e4eec24|append        |

It doesn't look like the run.lua file can easily catch / report this error.  It starts with...
-- Loads the `conf` var from layerset INI file
require "layerset"

require "style.pgosm-meta"

if conf['layerset']['amenity'] then
    print('Including amenity')
    require "style.amenity"
end

...

When the whole processing fails, the new row (from the first require) does get added.  I don't think there is an easy way for style.pgosm-meta to be aware of the Postgres connection failure, and I don't think we can guarantee that failure will always generate the row incorrectly reporting success.
However, this error should be easy enough to catch.
 ERROR: Connecting to database failed: connection to server at "localhost" (<IP_ADDRESS>), port 5432 failed: FATAL:  sorry, too many clients already

Then do a check on the timestamp of the latest row in osm.pgosm_flex to ensure it's within the last 30 seconds.  (That's to be paranoid in case there are cases where the new row does not get created.  I don't want to update an old meta row to be a failure when a new import failed...)
We'll need a new column in osm.pgosm_flex.  Maybe success BOOLEAN.  Or,  completed TIMESTAMPTZ.  The former requires an update on either success or failure (depending on approach).  The latter would only need an update on success.  If it's NULL the import either a) hasn't completed or b) failed.
Not a trivial fix, not going to try to fix before 0.7.0.


Serial connection

Is it possible to make pli and chat exchange via bluetooth serial port without using meshtastic, only serial exchange?

Hey can you clarify whether you mean USB serial here? I'm not sure what Bluetooth serial is -- Meshtastic uses Bluetooth Low Power (i think?) by default to connect to phone devices.
You can connect to the phone via USB with a USB On-the-Go connector and the plugin supports this kind of connection.

Ah I understand now, this is not currently supported.
Which radios are you using? If I can pick some up I might be able to add support in the future.

I use mototrbo dp4801. They also have UDP/IP support but atak's message too big for it, messages and pli not always reach destination EUDs

I'd also love this capability in the atak-forwarder plugin - I've got a pair of tnc3's, and am currently using a workable setup of an RPi to do UDP bridging, but it's finicky, complicated, and doesn't get to share any of the cotshrink previous work here. If the plugin could interface directly w/a KISS bluetooth serial device, I could pull the whole Pi bridge out of the chain and have a much better experience.

Ok this might be as simple as having a menu option to pick a serial port and having the plugin send every broadcast CoT to that port / listen to incoming from that port. I probably won't be able to work on this for a month or so because of my work obligations but it is technically possible. If someone else wants to give it a try check out the MeshSender class that interfaces with Meshtastic. Might be able to make a SerialSender class that does the same sort of thing and a SerialReceiver class for the other end. the CommandQueueWorker would also need to be modified to send to both MeshSender and SerialSender.
I am looking to make some of these mods to support DigiMesh but again probably not for a month or two.

Hi. Can you add usb-cdc support for atak forwarder? I have some radio with usb interface and it can send serial data over usb

I use mototrbo dp4801. They also have UDP/IP support but atak's message too big for it, messages and pli not always reach destination EUDs

Could you please elaborate on that one? I too have dp4801 and never knew it could act like a Bluetooth TNC/udp gateway

This will be a tangent, but I've been playing with an RPi Zero as a COT router.  Keeps most of the stuff out of ATAK, but still using the libcotshrink library on the Pi.  RaspberryPi Zero W (and just picked up a few Zero 2W), acts as a USB OTG Ethernet gadget for the phone (operating in airplane mode, basically only a display device).
  The bandwidth degrades when WiFi mesh is not available and causes the COT messages to be run through libcotshrink.  Based on type of message, I choose to filter even more when LoRa/Meshtastic is not available to reduce the bursts on Iridium (not cheap at all).
It seemed to me to be a high burden to put all of the decision making into ATAK, and the system design was very use-specific, more so I thought than I wanted to subject Paul to at least.  Since I'm running the Mehtastic protocol on the RPi for the LoRa radio, it's still compatible with vanilla implementations of the ATAK Forwarder+Meshtastic, but I get the bonus of remote sensor video and data packages when on WiFi mesh and any COT exchange when on B.L.O.S. Iridium.
I've also been toying with some legacy 915MHz ISM Ubiquity cards to attempt a longer range WiFi degradation (1-2MHz channels vs up to 160MHz channels) before fall-back to LoRa, but I have to built a base-board for a RPi CM4 so that I can adapt Mini-PCI card to that with a PCIe bridge.  Given the power demand for all of that additional hardware, those nodes will be routers+vehicle only.
I kind of see a hierarchy depending on the size of deployment:

Server+Iridium
Fixed Router+Cellular+915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa (<-- intended for permanent remote installations only)
Mobile Router+Cellular+915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (<-- Vehicle Borne)
Fixed/Portable Restock/Rally-Point Comms Box 915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (bigger battery, probably solar recharge - could be air-dropped)
Mobile Unit Comms Guy 915MHzWiFiMesh+2.4MHzWiFiMesh+LoRa+Iridium (bigger battery)
Mobile Team Comms Guy 2.4MHzWiFiMesh+LoRa
Individual Team Member LoRa-only
Tracking an item, simple remote control device or sensor, Meshtastic LoRa device only no ATAK head

Point of this tangent is, there is more than one way to skin a cat, and the Forwarder plugin might get a bit messy and harder to maintain if it has to wear too many hats and convert too many protocols.  Simple Serial Stream Out of COT-XML with selectable libcotshrink reduction is probably as far as I'd advocate pushing Forwarder.
After all it's forwarding, not doing all the work.

I just want to second the sentiment that @tim292stro expressed about the most straightforward path being where atak-forwarder is a forwarder to a single common standard rather than a jack-of-all-trades converter/adapter to a myriad of protocols and interfaces.
In my opinion, the root source of the difficulty is that ATAK is an implementation nightmare... in many senses.
One of these difficulties is associated with trying to use ATAK with anything other than a cloud-connected high-bandwidth Wi-Fi connection or a cellular data plan.
Even the tim292stro suggested notion of using USB Ethernet is replete with gotchas and potential problems.  Android is simply not designed to have multiple non-cellular network connections.  Many Android devices don't even have USB Ethernet drivers included in their Linux kernel, and even if they do have the right compatible ones (RNDIS, CDC-ECM, CDC-NCM, and CDC-EEM just to name a few industry-standard variants... never mind the proprietary ones from ASIX and others popular with physical USB Ethernet adapters), the Android API can't fathom the possibility of having two (non-cellular) network connections where one connection for the "Internet"/"cloud" and the other for talking to ATAK and there are all sort of weird behavioral issues.  (The Google authors of the Android API have provided for choosing between cellular data vs Wi-Fi, but that is all.)
So, many ATAK users who want to use ATAK without Wi-Fi access points nearby or cellular data (the two Android network options) are stuck.  Thankfully, this is a path blazed by @paulmandal, which is a great thing, but it also makes atak-forwarder a lightning rod for everyone else who would like to follow in those footsteps.
This leads to the second major difficulty with ATAK, IMHO.  Look at all the mid-2022 issues with atak-forwarder not being able to interoperate with the Play Store ATAK, and this is with a comparatively mainstream ATAK plugin.  I don't think it is malice on the ATAK developers' part per se; it is just that their plug-in architecture is an utter nightmare to use and they seem indifferent to making it any easier.
Consider that a developer has to manage to compile ATAK with private keys before they can ever hope to compile the atak-forwarder code.  Even if they manage to compile atak-forwarder after this, find the seemingly unfindable "CommHardware" interface mentioned in README.md, and then modify the source code to talk to something else, they only have bespoke ATAK and atak-forwarder apps that can only be side-loaded on a limited number of devices.  Furthermore, each time the ATAK developers update their source code, the process has to begin all over again.
The communications API between atak-forwarder and Meshtastic-Android is nowhere near as rigid and fragile as the one between ATAK and its plugins.  It seems that one can mix and match atak-forwarder and Meshtastic-Android versions without everything breaking.
Given this, would there any hope that there could be a atak-forwarder that just did CoT/chat exfiltration and infiltration, both with (optional?) libcotshrink, to user-chooseable companion app?  If there were a standard inter-app API to send and receive these messages and a companion 'Hello, world' sample app to do the interfacing to the transmitter and receiver, such a companion app (whether it were Meshtastic-android or other custom one implementing whatever interface is needed) could encapulate these messages into whatever protocol as needed.  The major advantage I see of this approach is that the developer only has to modify the companion app, not an entire spectrum of apps from ATAK onwards.
Aside: for what it is worth, I've prototyped the approach of emulating a USB Meshtastic-device as a way to side-step the ATAK plugin nightmare.  (ATAK -> atak-fowarder -> Meshtastic-Android -> custom-Meshtastic-device)  It does function, but I should warn you that with the Meshtastic developers controlling both Meshtastic-Android and Meshtastic-device, it is all too easy for them to change things frequently and so the USB serial protocol (and protobufs) are in constant flux (particular with v1.3 in development).
A third major difficulty with ATAK is its total lack of cybersecurity.  The cellular data, Wi-Fi, and (sometimes feasible) USB Ethernet interfaces all have no security.  The app comes with all network ports open, and some of these vulnerabilities cannot be disabled as they are hard-coded into the source code.  (IMHO, this gives further reason to NOT use ATAK with these interfaces.  If I had my way, all the ATAK network interface code for CoT/TAK servers, external GPS adapters, their TAK mesh protocol, etc. would be moved out of the app and into plugins so that said plugins could be disabled and removed for added cybersecurity.)
However, for anyone just trying to get data into and out of ATAK for test purposes, here are some options that worked for me and might bear fruit:

If you need to both send CoT to ATAK and get CoT back from ATAK: set up a private CoT/TAK server (this, I believe, is what tim292stro is doing) accessible via Wi-Fi or USB Ethernet.  ATAK sends CoT messages up to the server via a TCP socket, and it acts upon CoT messages that are sent back from the server (via the same TCP socket).  I have ANSI C source code for a bare-bones "TAK server" that accepts CoT messages here.

If all you want to do is send CoT messages to ATAK: figure out what the IP address is of the Android device, open a TCP socket on port 4242 of that IP address, and write the CoT message, and close the socket.  You can repeat this as often as needed.  A quick and dirty ANSI C example of this is here.


[BUG] regexp: ast fuzz tests with unicode fail in CI but pass locally

Describe the bug
The new ast fuzz tests with unicode inputrs added in https://github.com/NVIDIA/spark-rapids/pull/5573  fail in CI but pass locally
Steps/Code to reproduce bug
Run these RegularExpressionTranspilerSuite tests in CI:
  test("AST fuzz test - regexp_find - full unicode input") {
    doAstFuzzTest(None, REGEXP_LIMITED_CHARS_FIND,
      RegexFindMode)
  }

  test("AST fuzz test - regexp_replace - full unicode input") {
    doAstFuzzTest(None, REGEXP_LIMITED_CHARS_REPLACE,
      RegexReplaceMode)
  }

Expected behavior
Should have same behavior locally and in CI
Environment details (please complete the following information)
N/A
Additional context
N/A

We documented this issue in 22.06

We need changes to CI to be able to complete this issue

Duplicate of #5629


Add categories to AppTP breakage form

Task/Issue URL: https://app.asana.com/0/0/1202621146530750/f
Description
Updates AppTP breakage flow to add category selection & drop login info
Steps to test this PR
New breakage report screens

[x] Install the app from develop
[x] Go to AppTP main landing screen
[x] Click through "Having problems with an app" -> "submit a report" -> pick any app & click "SUBMIT"
[x] Ensure that new screens function as expected
Selecting any category except "Something else" enables "SUBMIT" button -> clicking SUBMIT = finish
Selecting "Something else" loads an edit text box for details & enables "SUBMIT" button -> clicking SUBMIT = finish
[x] Run ReportBreakageCategorySingleChoiceViewModelTest

UI changes

Before
After

@laghee Left another comment that needs fixing but approve the review already to unblock you as you can directly commit my suggestion.


Bump actions versions, set-output to use GITHUB_OUTPUT

also update set-output to use new format to pipe into envar, per GitHub warnings in current action output!
Signed-off-by: vsoch<EMAIL_ADDRESS>

okay just removed that previous comment as a sanity check that the builds still work (and I can look for more warning messages).

Don't merge yet - a few new warnings popped up I will look into tomorrow! https://github.com/rse-ops/docker-images/actions/runs/3293422368

okay I see the issue! We have a few set-output in uptodate so I need to fix there to write to this output variable file instead.

okay! Granted these finish green, we are free of warnings now!


CI: Address TODOs for test/new_relic/transaction_ignoring_test_cases.rb

In November 2022, both JRuby v<IP_ADDRESS> and v<IP_ADDRESS> were seen as creating 2 objects instead of 1 in fully 3 separate places. The existing "== 1" tests were relaxed (for JRuby only) to test for ">= 1".
We should investigate why this relaxing of the assertions was needed, make any updates as necessary, and remove the TODOs from the tests.
test/new_relic/transaction_ignoring_test_cases.rb

this one has been rolled into #1663


Prefer highest value of same type when deduping modifiers

Allows implementing kingmaker vacancy penalties, but also adhoc "custom modifier types" without adding to the global modifier type list.

Is this not also done in the constructor?

You are correct, I certainly missed a spot. Give me a bit.


feat: Implement BINARY

Closes #444

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-7 of 36 (80.56%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.04%) to 92.902%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

imap-types/src/extensions/binary.rs
3
4
75.0%

imap-types/src/response.rs
1
2
50.0%

imap-codec/src/extensions/binary.rs
0
5
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
10130

Relevant Lines:
10904

💛  - Coveralls


Inaccurate Handling of '-e' Command Line Option and 'UKIBAK_ESP' Environment Variable in ukibak

Description:
When running ukibak with the '-e /efi' command line option or the 'UKIBAK_ESP' environment variable set to '/efi', the program fails to locate the source image '/EFI/Linux/arch-linux.efi', despite its presence at '/efi/EFI/Linux/arch-linux.efi'. This issue persists regardless of using the command line option or the environment variable.
Steps to Reproduce:
Set the 'UKIBAK_ESP' environment variable to '/efi'.
- or - Execute ukibak using the command line option '-e /efi'.
Observe the error message: "ERROR [ukibak] Source image '/EFI/Linux/arch-linux.efi' not found."

Expected Behavior:
The program should recognize the specified EFI partition mount point (either through the '-e' option or the 'UKIBAK_ESP' variable) and locate the source image at the provided path.
Actual Behavior:
The program outputs an error message indicating it cannot find the source image, suggesting it does not correctly process the provided mount point path.
Additional Information:
Operating System: Arch Linux with Linux-zen 6.7.0-zen3-1-zen
ukibak Version: 1.0.0

Attempted Troubleshooting:
I attempted different values for invoking ukibak with the command line option -e, including the whole path to the uki-image.

Hello @mib1982, thank you for your well written bug report. Unfortunately I'm unable to reproduce the problem. I tried the steps you described on two different Arch Linux installations and on both the -e switch and the UKIBAK_ESP environment variable are working flawlessly.
Looking at your observed behavior, it looks to me that only the first / of the option is used by ukibak. Could you please check the following things:

/efi is the default value for the mount point of the EFI partition. If your EFI partition is mounted as /efi it should work without using the -e switch or the UKIBAK_ESP variable. Does ukibak work if you call it without a command line option or set environment variable?
Could you please call ukibak with the -d switch set and post the result here?

Hi,
I had the same issue @mib1982 mentioned, so I had a quick look and I believe the issue lies with use of the Path#join method: since the loader image name in the EFI variable will always be absolute, joining it with the EFI path doesn't do anything, because joining anything with an absolute path returns that exact path; as shown by the example in the Path#join documentation:
assert_eq!(Path::new("/etc").join("/bin/sh"), PathBuf::from("/bin/sh"));

My Rust-fu is pretty weak, but I managed to write some naive code that appears to fix it; which may be useful, so here goes:
--- a/src/main.rs
+++ b/src/main.rs
@@ -236,12 +236,18 @@ fn backup_uki(args: &Args) -> Result<(), Error> {
     // Select a path from the list.
     let esp_path = get_esp_path_from_list(&esp_paths, args.force)?;

-    let active_esp: PathBuf = get_loader_image_name(&PathBuf::from(&args.efivarfs))?.into();
+    let mut active_esp: PathBuf = get_loader_image_name(&PathBuf::from(&args.efivarfs))?.into();
     debug!("Active loader image name is '{}'.", active_esp.display());

+    if active_esp.is_absolute() {
+        active_esp = active_esp.strip_prefix("/").unwrap().to_path_buf()
+    }
+
     // Combine the relative path of the active ESP with the mountpoint of the ESP
     // specified on the command line (or the default).
     let source_path = esp_path.join(active_esp);
+
+    debug!("Active loader image source path is '{}'.", source_path.display());
     if !source_path.exists() {
         Err(Error::SourceNotFound(source_path.clone()))?;
     }

Thanks for creating this project BTW!

Hello @FlashSystems, thank you for taking the time to look into this issue.
First, here is an excerpt of /etc/fstab showing the relevant line for /efi:
/dev/sda2                                       /efi            vfat            umask=0077      0 2

Here is the output of ukibak if I call it without a command line option and no environmental variable set.

-> # ukibak
ERROR [ukibak] Source image '/EFI/Linux/arch-linux.efi' not found.

Here is the output of ukibak -d :

-> # ukibak -d
DEBUG [ukibak] Active loader image name is '/EFI/Linux/arch-linux.efi'.
ERROR [ukibak] Source image '/EFI/Linux/arch-linux.efi' not found.

I assume it takes the active loader image name somewhere from /sys/firmware/efi/efivars/, but it doesn't put it in relation to the mount-point of the EFI System Partition /efi.
However, I was able to make it work by creating a symlink /EFI which points to /efi/EFI. This leads to the creation of a backup of the last bootable uki. Here is the output of ukibak -d with the symlink in place:

ukibak -d
DEBUG [ukibak] Active loader image name is '/EFI/Linux/arch-linux.efi'.
DEBUG [ukibak] Parsing image /EFI/Linux/arch-linux.efi...
DEBUG [ukibak] Found section .text
DEBUG [ukibak] Found section .rodata
DEBUG [ukibak] Found section .data
DEBUG [ukibak] Found section .sbat
DEBUG [ukibak] Found section .sdmagic
DEBUG [ukibak] Found section .reloc
DEBUG [ukibak] Found section .osrel
DEBUG [ukibak] Found section .uname
DEBUG [ukibak] Found section .cmdline
DEBUG [ukibak] Found section .splash
DEBUG [ukibak] Found section .linux
DEBUG [ukibak] Found section .initrd
DEBUG [ukibak] Image is self contained.
DEBUG [ukibak] Time since last reboot is 910s
DEBUG [ukibak] File was modified 84011s ago. Minimum age is 910s.
DEBUG [ukibak] Parsing image /EFI/Linux/linux-last.efi...
INFO  [ukibak] Copying '/EFI/Linux/arch-linux.efi' to '/EFI/Linux/linux-last.efi'...
DEBUG [ukibak] Copy succeeded.

For the time being, the workaround is a good solution which works for me. I leave it up to you if you would like to further investigate the problem or close this issue.

Hello @d-tux, you are absolutly right, this EFI implementations return an absolute path. On both of my systems the returned path is relative. Maybe it depends on how the path was supplied to efibootmgr command.
Thank you for your effort and for suggesting a fix. I'll update my code, add some tests and release a new version as soon as possible.
@mib1982: Thank you for supplying the log. This confirms @d-tux's assumption: DEBUG [ukibak] Active loader image name is '/EFI/Linux/arch-linux.efi'.. The load image name starts with a slash.

I've fixed the bug and added a test to make sure there will be no regressions. Please test Version 1.1.0. It would be great if you could let me know whether it also works in practice.

It looks like it has been fixed for me. Here is the output of ukibak -d after updating to Version 1.1.0:

-> # ukibak -d
DEBUG [ukibak] Active loader image name is 'EFI/Linux/arch-linux.efi'.
DEBUG [ukibak] Parsing image /efi/EFI/Linux/arch-linux.efi...
DEBUG [ukibak] Found section .text
DEBUG [ukibak] Found section .rodata
DEBUG [ukibak] Found section .data
DEBUG [ukibak] Found section .sbat
DEBUG [ukibak] Found section .sdmagic
DEBUG [ukibak] Found section .reloc
DEBUG [ukibak] Found section .osrel
DEBUG [ukibak] Found section .uname
DEBUG [ukibak] Found section .cmdline
DEBUG [ukibak] Found section .splash
DEBUG [ukibak] Found section .linux
DEBUG [ukibak] Found section .initrd
DEBUG [ukibak] Image is self contained.
DEBUG [ukibak] Time since last reboot is 16284s
DEBUG [ukibak] File was modified 12537s ago. Minimum age is 16284s.
INFO  [ukibak] File '/efi/EFI/Linux/arch-linux.efi' was modified since the last reboot. Skipping copy.

Thanks for taking care of this issue so quickly and for creating this project.


New package: PrivateExample v0.1.0

Registering package: PrivateExample
Repository: https://github.com/vdayanand/PrivateExample.jl
Created by: @vdayanand
Version: v0.1.0
Commit: c852bbfd57347a4b74650429ec4b887e233b6b89
Git reference: master

This is a test PR. Can be closed

Would it be possible to test against a dummy registry instead?


Color does not look right when writing a interface [or another things]

VSCode Version: 1.10.2 (1.10.2)
OS Version: MacOS 10.12.3

Steps to Reproduce:

This issue was moved to Microsoft/TypeScript-TmLanguage#433


build: revert config change for actions/checkout@v4

This reverts a change in the CI configuration for actions/checkout@v4 that slipped in during #74.

Thx @phrxmd for finding the issue and the solution!


Setting serviceType to NodePort results in error

I receive the following error when specifying serviceType: NodePort within my values. Is the chart supposed to support coredns being deployed as a NodePort service?
Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Service.spec.ports[0].port): invalid type for io.k8s.api.core.v1.ServicePort.port: got "string", expected "integer", ValidationError(Service.spec.ports[1].port): invalid type for io.k8s.api.core.v1.ServicePort.port: got "string", expected "integer"]

I have investigate this more and port is converted in _helpers.tpl for both servicePorts and containerPorts to be used as keys in a common dict. However, the ports are just included in service.yaml and deployment.yaml without being converted back to integers.
I assume that I have made an error in how to use the chart, otherwise more users should have experienced the same issue. Could someone please point me in the right direction?

Found the issue. The issue was caused by wrong indentation level in the values file, this resulted in the port becoming nil.


The "default" IConfiguration provided to Startup contains multiple nested providers with duplicates/triplicates in places

Describe the bug
The "default" IConfiguration provided to Startup seems overly complex, containing multiple nested providers with duplicates/triplicates in places.  This causes difficulty in reasoning about how the default configuration setup should work!
I'm mostly interested in whether this is intentional (and if so what the reasoning is) or whether it is inadvertent (passing around builders through various parts of the framework, with multiple places adding providers onto an already complicated provider list?)
To Reproduce
dotnet new webapi
Set a breakpoint in Startup.cs Configure() method and inspect the Configuration.Providers property at run time.
It contains 5 top level providers and a total of 3 nested levels, with EnvironmentVariables in the list 3 times and CommandLine being in the list 2 times.
The heirarchy is as follows (indentation showing the child items of the ChainedConfigurationProviders):

ChainedConfigurationProvider

MemoryConfigurationProvider

MemoryConfigurationProvider

EnvironmentVariablesConfigurationProvider

CommandLineConfigurationProvider

ChainedConfigurationProvider

EnvironmentVariablesConfigurationProvider

JsonConfigurationProvider (appsettings.json)
JsonConfigurationprovider (appsettings.Development.json)
EnvironmentVariablesConfigurationProvider
CommandLineConfigurationProvider

This seems overly complicated and in my case has led to unexpected behaviour trying to reason about how configuration values are ultimately being surfaced!
Further technical details

ASP.NET Core version

3.0.0

Include the output of dotnet --info

.NET Core SDK (reflecting any global.json):
Version:   3.0.100
Commit:    04339c3a26
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.18362
OS Platform: Windows
RID:         win10-x64
Base Path:   C:\Program Files\dotnet\sdk\3.0.100\
Host (useful for support):
Version: 3.0.0
Commit:  7d57652f33
.NET Core SDKs installed:
1.0.0 [C:\Program Files\dotnet\sdk]
1.0.1 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
2.0.0 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.300 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 1.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version
VS2019 16.3.6

NOTE: It does appear the EnvionmentVariables providers have different prefixes "ASPNETCORE_" "DOTNET_" and "" so I guess that does start to make things clearly if they come from different areas/layers of the eco system...

@ryangribble thanks for contacting us.
As you mention, this is this way because the information comes from multiple sources at different levels, for example hosting has a provider that handles ASPNETCORE_... environment variables that are used to set up things like listening urls etc.
See https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-3.0#default-configuration for more details
/cc:@tratcher in case he wants to add anything else.
Hope that helps


Issue: Improve Landing Page Background Image for Enhanced Appeal and Relevance

Hello @MonalikaPatnaik  and @i-am-SnehaChauhan
Description:
Upon visiting the website, I have noticed that the current background image on the landing page is of low quality and does not effectively convey the mission of the site. As the landing page serves as a crucial first impression for users, it should be visually appealing and representative of the site's purpose.
Proposed Solution:
To enhance the landing page, I suggest replacing the existing background image with a high-quality image, animation, or video that better aligns with the site's mission. The new media asset should effectively communicate the purpose of the site and engage the target audience.
Tasks:
1.Find or create a high-quality image, animation, or video that aptly represents the site's mission.
2.Resize or edit the chosen media asset, if necessary, to ensure it fits well within the landing page layout and maintains its quality.
3.Replace the current background image with the new media asset in the website's HTML code.
4.Test the modified landing page across various devices and browsers to ensure responsiveness and proper display.
Request for Assignment:
As a contributor in GSSoC'23, I would like to be assigned to this task in order to improve the landing page background image. I am confident in my ability to source or create a high-quality media asset that will better convey the site's purpose and appeal to end users.
Please assign me this task, and I will promptly begin working on it to enhance the landing page's visual impact and relevance.
Thank you for considering my contribution!

Hey..I think a similar issue has already been raised: #126
If I won't get an update there...will assign it to you!
Thanks!


Skip over left side nav when using skip link on pages with left side nav

Skip links are currently all skipping to #main. On pages with left side nav, this means that they weren't skipping over that nav. This change skips them to #content_main on pages with a left sidebar.
Fixes GHE/CFGOV/platform/issues/2704
Additions

Added id="content_main" to the div with the class of the same
Added a new template block of skip_nav_target wrapping the href value in the skip link in base.html, which is overridden in the content-base-sidebar-first.html template to point to #content_main

Testing

Pull branch
Visit a page with left side nav, e.g., http://localhost:8000/about-us/newsroom/
Press Tab to reveal the skip link and Enter to activate it
Confirm that it targets #content_main instead of #main
Try it on any other type of page and see that it still targets #main

Checklist

[x] PR has an informative and human-readable title
[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[x] Code follows the standards laid out in the CFPB development guidelines
[x] Passes all existing automated tests
[x] Any change in functionality is tested
[x] New functions are documented (with a description, list of inputs, and expected output)
[x] Placeholder code is flagged / future todos are captured in comments
[x] Visually tested in supported browsers and devices (see checklist below :point_down:)
[x] Project documentation has been updated
[x] Reviewers requested with the Reviewers tool :arrow_right:

Testing checklist
Browsers

[ ] Chrome on desktop
[x] Firefox
[ ] Safari on macOS
[ ] Edge
[ ] Internet Explorer 9, 10, and 11
[ ] Safari on iOS
[ ] Chrome on Android

Accessibility

[x] Keyboard friendly
[x] Screen reader friendly

Other

[x] Is useable without CSS
[x] Is useable without JS
[x] Flexible from small to large screens
[x] No linting errors or warnings
[x] JavaScript tests are passing

@anselmbradford I'm sorry, I completely missed your comment and only noticed Cat's! If I had noticed before merging, I'd have considered it, but it does seem like it could go either way. I do personally prefer the idea of linking to the actual element with the content in it you want people to go to, versus an empty element.


asm/f32:  Adding dot product asm functions.

Migrated from gonum/internal#58 with uintptr corrections.

Are these asm PRs ready to be merged?

Yes, I was just giving @vladimir-ch an opportunity to take a look.

I will be able to take a look starting Tuesday or Wednesday if you are
willing to wait.
On Sep 3, 2017 08:47, "Chad Kunde"<EMAIL_ADDRESS>wrote:

Yes, I was just giving @vladimir-ch https://github.com/vladimir-ch an
opportunity to take a look.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gonum/gonum/pull/209#issuecomment-326775389, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABwJvsUm2cwxMP7b3gsIbEaZApUBPJvlks5seeklgaJpZM4O_NLk
.

@vladimir-ch  That sounds good.  It's not adding functionality, so it's not a big rush.

aside comment:
could we always rebase before merging?
with the mono-repo structure and with more people (yay!) working on different parts of the mono-repo, if we don't rebase before merging, we'll get a mess of a history.
it's already starting to be quite the spaghetti monster:
$> git l
*   5779c127 (HEAD -> master, origin/master, origin/HEAD) Merge pull request #209 from gonum/f32/dot
|\
| * 9d7baa81 asm/f32: Fixes from PR comments.
| * e0a0508f asm/f32: Asm dot functions.
| * 7f0e3341 asm/f32: Adding tests for dot asm functions.
| * 51fc8a3f asm/f32:  Adding stubs for dot asm functions.
| | * ab2c1e6e (origin/flow) Revert "graph/path: implement sophisticated algorithm"
| | * a9929ba0 graph/path: implement sophisticated algorithm
| | * 09fc4a20 graph/path: add benchmarks for Dominators
| | * bd6dc762 graph/path: replace map and slice index chasing with pointer chasing
| | * c5923049 Revert "graph/path: replace recursive dfs with iterative implementation"
| | * 7a3afb07 graph/path: add dominator tree API
| | * 4c195282 graph/path: replace recursive dfs with iterative implementation
| | * a4553c6e graph/path: replace Dominators with naive Lengauer and Tarjan
| | | * a6e52c49 (origin/kconnected) graph/community: add k-clique community function
| | | * a1136aba graph/topo: add clique graph construction function
| | |/
| | | * 70474858 (origin/f64/ger) asm/f64: Merging logic changes from #225
| | | * 9dd91876 blas/gonum, asm/f64: Incorporate Ger routine in blas for testing.
| | | * e11ffa2c Build flags for go1.7 testing and guards for oversized test.
| | | * a9c13538 asm/f64: Cleaned up with go1.8-supported instructions.
| | | * 59c56216 asm/f64: Ger asm function added.
| | | * e82f927d asm/f64: Ger asm function framed out for loop construct/flow.
| | | * f8ea1eb8 asm/f64:  Adding stubs for Ger asm implementation.
| |_|/
|/| |
* | |   4ac7663e Merge pull request #227 from gonum/generate-error-fix
|\ \ \
| * | | 1fc51d6a travis: Print git diff when check-generate fails.
* | | | 34774386 blas/gonum:  Fix NaN popagation in Dger.  (#225)
|/ / /
* | | 49f3edb2 travis: reduce verbosity of test output
* | | f01292bb floats: Fix Argsort documentation.
* | | e01a71d4 mat: make RowView and ColView return Vector type and add RowViewOf and ColViewOf
| |/
|/|
| | * 134c8aaf (origin/negative-cycles) graph/path: allow Shortest to traverse negative cycles
| |/
|/|
* | d7342e68 travis: add go-1.9.x
* | 40dbcd03 travis: remove go-1.6.x
| | * 767fa7a0 (origin/degeneracy) graph/topo: use degeneracyOrdering instead of VertexOrdering for BronKerbosch
| | * 781be0e4 graph/topo: fix error reporting for VertexOrdering test
| | * 93093475 graph/topo: add function to find k-core of undirected graph
| | * 12013324 graph/{internal,path,topo}: factor reverse function out into internal
| |/
|/|

compare this to the Go stdlib mono-repo:
$> git l
* 0202aa8ec7 (origin/master, origin/HEAD) doc: update DWARF version
* 13772edbbd cmd/compile: simplify exporting universal 'error' type
* 261a8d9abd testing: use time.Since instead of time.Now().Sub
* 6367c19f26 cmd/internal/obj/x86: add some more AVX2 instructions
* 31ddd8a39d cmd/compile: more compact DWARF location for locals and arguments
* 84188296e9 cmd/compile: more compact representation of DW_AT_high_pc
* 50f1f639a4 cmd/asm: add most SSE4 missing instructions
* b15e8babc8 cmd/asm: add amd64 PALIGNR instruction
* 4074e4e5be cmd/asm: add amd64 CLFLUSH instruction
* 26dadbe32c cmd/asm: add amd64 PAB{SB,SD,SW}, PMADDUBSW, PMULHRSW, PSIG{NB,ND,NW}
* 16edf0b1f7 crypto/cipher: panic when IV length does not equal block size in NewOFB
* 6c102e141c cmd/compile: avoid stack allocation of a map bucket for large constant hints
* 034d825ea3 runtime: avoid redundant zeroing of hiter
* 9c3f268558 cmd/compile: set hiter type for map iterator in order pass
* bb31217579 runtime: move map ismapkey check to the compiler
* 2d362f7a49 flag: simplify arg logic in parseOne
* 6675fadfb8 runtime: cleanup amd64p32 memmove and memclr file organization
* 0fb82fbcce cmd/compile: remove global bout variable
* 34db5f0c4d cmd/compile: fix evaluation order for OASOP
* d349fa25df cmd/compile: fix and improve struct field reflect information
* 812b34efae cmd/compile: ignore non-code nodes when inlining
* b2e8630f2f cmd/compile: simplify "missing function body" error message
* 53d24f76fb doc: Fixed missing dot in effective_go.html
* aed1c119fd cmd/compile: fix assembly test
* fb165eaffd cmd/compile: combine x*n - y*n into (x-y)*n
* 03c3bb5f84 math: Add Round function (ties away from zero)

much more linear. much more readable.

A rebase after approval would wipe out the review, so we might end up chasing each other around trying to rebase before merging.  Squashing merges might be a better option to keep the history clean.

(let's move this to gonum-dev)


Contract Versions

Add version to contracts

It was created a way to have multiple versions of the contracts
Today, inside the bridge directory we have the contracts in the root of the contracts directory or even inside other directories, like:

This way we have like _old contracts to test the deploy to new contracts when upgrading
So, the idea is to make it possible to have multiple versions of the same contracts doing in a way that we don't need to use _old_old.sol but instead we could use like BridgeV1.sol and BridgeV2.sol each time we are going to deploy a new contract we could create a new version inside a contract path, the last contract (more updated one) would not have any versions at the end, so it would be Bridge.sol
The last version of the contract would not have any Version at the end, so if we happen to have 3 Federation contracts it would be the first called V1 the second V2 and the last one (more updated contract) would be just Federation.sol

Description

Created directories for contracts
Removed previous directory
Add test for upgrading from the federationV2 to federation

How to Test

Run both ganache-cli
Enter into the bridge directory and run all the tests

Case 1

Go to bridge directory

$~ cd bridge

Run the first ganache-cli

$~ npm run ganache

Open another shell and run the ganache mirror

$~ npm run ganache-mirror

Run all the tests

$~ npm run test

Expected Result

It should pass the test

Deploy the contracts to the federator tests

$~ npm run deployLocalIntegrationTest

Go to the federator directory

$~ cd ../federator

Run the integration tests

$~ npm run integrationTest

Checklist
Bridge Directory cd bridge

[x] Lint is clean npm run lint
[x] Test is passing npm run test
[x] Contracts are compiling npm run compile

Federator Directory cd federator

[x] Lint is clean npm run lint
[x] Test is passing npm run test
[x] Typescript is compiling npm run build

Coverage decreased (-29.1%) to 63.39% when pulling 99e530643d456d078c10d1a468fa7d8128717f93 on feature-contract-versions into b843995e090fd78155bfa2a570243b3a4750b4a1 on nftbridge.


Parse local network by environment uuid

Plse see https://github.com/rancher/rancher/issues/8535

@niusmallnan Logic looks good. If you can confirm that testing both ipsec and calico worked with these changes, you are good to go.

@leodotcloud Tested both ipsec and calico, they work fine.
I have built a test setup with backported patches applied.
Calico: http://<IP_ADDRESS>:8082/env/1a7/infra/hosts
IPSec: http://<IP_ADDRESS>:8082/env/1a5/infra/hosts

LGTM
Ping @ibuildthecloud.

Sorry, I should use AWS US.
Here, new URL:
Calico: http://<IP_ADDRESS>:8080/env/1a7/infra/hosts
IPSec: http://<IP_ADDRESS>:8080/env/1a5/infra/hosts

LGTM.


Potential issue with generated C code for iso2

Quick background:
I was using the decoder functions from your previous project (openV2G, at least I assume it was yours since the syntax is pretty much the same) and wanted to switch to this project since I need the -20 support.
I was looking at the generated code functions for -2, specifically the decode_iso2_SignedInfoType() function, and I noticed that you are not decoding Reference field as an array, which differs from openV2G project. Here is the comparison:
openV2G:
#define iso2SignedInfoType_Reference_ARRAY_SIZE 1
struct iso2SignedInfoType {
	struct {
		exi_string_character_t characters[iso2SignedInfoType_Id_CHARACTERS_SIZE];
		uint16_t charactersLen;
	}  Id ;
	unsigned int Id_isUsed;
	struct iso2CanonicalizationMethodType CanonicalizationMethod ;
	struct iso2SignatureMethodType SignatureMethod ;
	struct {
		struct iso2ReferenceType array[iso2SignedInfoType_Reference_ARRAY_SIZE];
		uint16_t arrayLen;
	} Reference;
};

cbexigen:
struct iso2_SignedInfoType {
    struct {
        char characters[iso2_Id_CHARACTER_SIZE];
        uint16_t charactersLen;
    } Id;
    unsigned int Id_isUsed:1;
    struct iso2_CanonicalizationMethodType CanonicalizationMethod;
    struct iso2_SignatureMethodType SignatureMethod;
    struct iso2_ReferenceType Reference;
};

And lastly, the Reference entrance from the XML schemas:
<element name="SignedInfo" type="ds:SignedInfoType"/>
    <complexType name="SignedInfoType">
        <sequence>
            <element ref="ds:CanonicalizationMethod"/>
            <element ref="ds:SignatureMethod"/>
            <element ref="ds:Reference" maxOccurs="unbounded"/>
        </sequence>
        <attribute name="Id" type="ID" use="optional"/>
    </complexType>

The Reference field has maxOccurs="unbounded" which should mean that it should be an array.
Just checking if this is an issue or did I understood it wrong.

This project is not associated with OpenV2G, though it seemed logical to create a similar interface/API to OpenV2G initially, for easier transition. This project cbExiGen/cbV2G aims to provide an open source ISO 15118-20 codec, which OpenV2G does not plan to provide (you need to pay for an implementation). At the same time, DIN 70121 and ISO 15118-2 shall of course also be supported.
Regarding your observation:
Indeed, we artificially reduced the size of Reference to 1:
https://github.com/EVerest/cbexigen/blob/3e78459a68cab0ab272a65ee78b0ee9daaf909fe/src/cbexigen/typeDefinitions.py#L41
But since OpenV2G provides an array, we probably also should provide this. The logic for identifying arrays reduced to one and retaining them as array is not yet in place, but work in progress. Thanks for pointing out this particular restriction.
Note: OpenV2G does also only provide room for decoding one single Reference:
https://github.com/chargebyte/openv2g/blob/87591ab3b7172d9661c118a318c60a0ce2be240e/src/xmldsig/xmldsigEXIDatatypes.h#L448
#define xmldsigManifestType_Reference_ARRAY_SIZE 1
So, in the meantime, as either library only accepts one Reference, you can replace the array access with access to the single provided variable.

It is true that the default array size for Reference is set to 1 by default, but in my adaptation, I've increased the value to 10.
This is probably done to accommodate the encoded message, but since it was long time ago, I cannot recall how the encoded message looked like.
I can try and dig up the encoded bytes and send it to you so you have some testcase. That is, if there are indeed multiple References.

Good point. We strive to have an API which does not change significantly with the modification of such restrictions.
Do I understand correctly that OpenV2G also cannot decode this message unless you lift its quoted limitation?
Please do provide the testcase. If you even have both EXI and XML (or some other representation such as JSON), that would be great.

Thanks for the explanation of your motivation. This is one of the goals we also see.
Thanks also for the inputs.

This is probably done to accommodate the encoded message

I thought you had an actual message with more than one Reference. We can create it ourselves using Josev/iso15118 though.
Feel free to share your integrations of OpenV2G and cbV2G for the community. ;-)

Yeah, I thought so too, but it was just one reference.
I definitely plan to release something when I finish it :)

For the sake of debugging, I am attaching your inputs, complemented with pretty-printed JSON, and with EXI streams as hex-encoded strings.
AuthReqEncode.txt
CertInstallationReqEncode.txt

Hello @PKrza,
could you kindly test the codec, as generated from current branch main (commit https://github.com/EVerest/cbexigen/commit/82976af6a0ff7a4946bfd19e349bbc4f2b53fabf)?
We increased the array size of References to 4, as mandated by ISO 15118-2 [V2G2-909]. We kept the size for DIN at 1, since it is unused.
We also fixed a lot of coding errors.
Thanks for your input, and looking forward to your integrations.

Closing, as References now appear as an array (in ISO 15118-2), albeit with a preconfigured limit of 4 (instead of unlimited), as stated by requirement [V2G2-909]:

The signature shall not reference more than 4 signed elements.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


CI: Q 2.5.0.Final version bump

https://github.com/Karm/mandrel-integration-tests/blob/master/testsuite/src/it/java/org/graalvm/tests/integration/DebugSymbolsTest.java#L255
Needs a change. The Quarkus version comparator is still not in PR. I need to get back to that. Sorry for inconvenience.

Fixed in https://github.com/Karm/mandrel-integration-tests/pull/70/commits/2c67a22862ab34e484036ea6c036a793699a7e83 thanks for the info, it saved me quite some time from trying to figure out why it didn't work.


Major refactor - strict mode and functions

Two main changes here:

Refactor to use bash "strict" mode.
Put all code in functions, with a main() entry-point.

(1) means you don't need to test every command for success - the script exits if a command fails
(2) is my preferred coding style as it it makes it very clear what the script is doing
I also added a fail() utility function.
Fixes #14

You can add a (fixes #14) to this one 👍
I assume you've done what testing you can manually on this?

This should now be good for testing.
I've done some testing myself (upgraded my smartoOS node) but it probably needs more.


Update manifests/a/Azul/ZuluFX/18/JDK/18.28.13/Azul.ZuluFX.18.JDK.locale.en-US.yaml

Fixes an issue where this package has multiple different monikers
Microsoft Reviewers: Open in CodeFlow

[Policy] Reset Labels