Spotify freezing

I'm using the AAIdrive on ID5 since 3 days but there is this freezing problem when using Spotify.
You can find and start Spotify from the media menu in ID5 but sometimes when you click to skip a song it freezes for 10 seconds.
The seconds in the display are freezing and the song doesn't jump to the requested next one.
After 10 seconds it skips to the next song automatically... : (
Thanks for the help!

I've heard of this symptom happening when the AAIdrive app is suspended by the phone for being in the background. Does the car interface become responsive again if you open AAIdrive's phone interface? You should be able to dig around in the phone's background execution limits to allow AAIdrive to run in the background.

Hallo,
First of all thank you for all the improvements you made in the AAIdrive app :)
I’m connecting my phone on ID5 in a 7 series G11 2016 and YT Music works but can’t search into the folders?
Met vriendelijke groeten,
Kurt Car Company
Laat je passie voor rijden tot leven komen met een prachtige tweedehands BMW van dé BMW-specialist!
Elke BMW in onze collectie is zorgvuldig geselecteerd en ondergaat strenge inspecties om ervoor te zorgen dat alleen de hoogste kwaliteit voertuigen onze showroom verlaten.
@.***
Kurt Car Company
BMW Specialist
Kasteelstraat 22
9140 Temse
GSM : +32.489.287.099
www.kurtcarcompany.behttp://www.kurtcarcompany.be/
@.***
Van: Walter Huf @.>
Verzonden: zondag 17 juli 2022 21:58
Aan: BimmerGestalt/AAIdrive @.>
CC: Esco54 @.>; Author @.>
Onderwerp: Re: [BimmerGestalt/AAIdrive] Spotify freezing (Issue #593)
I've heard of this symptom happening when the AAIdrive app is suspended by the phone for being in the background. Does the car interface become responsive again if you open AAIdrive's phone interface? You should be able to dig around in the phone's background execution limits to allow AAIdrive to run in the background.
—
Reply to this email directly, view it on GitHubhttps://github.com/BimmerGestalt/AAIdrive/issues/593#issuecomment-1186597604, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATZ73NVRVFDOAPKKKCUJ6WDVURQTDANCNFSM53DFQ34A.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

YTMusic doesn't allow AAIdrive to browse the library, please reach out to Google to request that they change the policy.


docker 17.06-ce

RancherOS Version: (ros os version)
Where are you running RancherOS? (docker-machine, AWS, GCE, baremetal, etc.)

https://github.com/rancher/os-services/pull/124 needs to be backported into the v1.1.0-rc2 branch

and is in v1.0.4


[Bug]: llama-agents human-in-the-loop quickstart does not work

Bug Description
Got attribute error
Version
0.0.3.post1
Steps to Reproduce
Run this quickstart: https://github.com/run-llama/llama-agents/blob/main/examples/pipeline_human_local_single.py
Relevant Logs/Tracbacks
site-packages\llama_agents\orchestrators\pipeline.py", line 34, in get_service_component_message
    if module.module_type == ModuleType.AGENT:
       ^^^^^^^^^^^^^^^^^^
AttributeError: 'RouterComponent' object has no attribute 'module_type'

I just fixed this. pip install -U llama-agents, you are several versions behind actually
https://github.com/run-llama/llama-agents/pull/118
Also, llama-agents has it'd own repo/issues. Would make sense to open over there in the future 👍


Gradle build Failed"Task :app:mergeDebug Resources FAILED"  Aapt2InternalException:AAPT2 aapt2-3.4.0-5326820-windows Daemon #0: Daemon startup failed

Issue:
No matter Jave or Kotlin project  build failed

My Environment

Android Studio Version:3.4
Window 7
java jdk 1.8.0_101

Can anyone fix it ???

Same probleme here :(
My Environment:

Alpine Linux 3.9 (Kernel: 5.4.14-100.fc30.x86_64)
openjdk 1.8.0_242
Gradle 4.10.3
(works on Debian Stretch)

The problem is that Alpine Linux ships with Musl instead of GNU libc, the Android SDK tooling requires glibc..

wo have same issue, anyone help?

I have been having this problem using gradle 4.1.2 and 4.1.3 .
I tried gradle 4.0.0 [randomly trying versions] and IT WORKED PROPERLY!!!
This stack overflow describes a similar problem that was fixed by using 4.0.2
https://stackoverflow.com/questions/65190931/android-studio-with-aapt2-windows-problems/67078572#67078572
Apparently version 4.1.x of gradle introduced this problem.
Here is the uname for the Linux (Devuan) I'm using
Linux xxxx 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
Again, my solution is to DOWNgrade the gradle plugin version to 4.0.0 or 4.0.2 (I just tested 4.0.2)
AAPT2 fails on files over "a certain size".  When I remove icon resources larger than 'xhdpi' then the build fails stop, but only because the files causing the bug to surface are no longer there.  So whatever was done to AAPT2 since version 4.0.2 is the problem.
Simple fix:  put it BACK the way it was!
How can I accelerate the handling of this bug?  It has been documented for MONTHS, and has NOT been resolved, even with a version of Gradle that Android Studio recently released...
Is the new AAPT2 even WORKING for anyone else?

I have been having this problem using gradle 4.1.2 and 4.1.3

Sorry, gradle 4.1.2 and AGP 4.1.2 are totally different things. From you description, this seems like an AGP issue and can't be resolved on Gradle's side. Closing.


boost::filesystem::basename no longer exists

This API, which was deprecated, has been removed in boost-1.85.0.
The following modifications are required to support the latest boost library.

That's merged, thanks!


Validation plugin: Error "Intersection results could not be merged" on array fields

Could be related to this: https://github.com/colinhacks/zod/issues/636
When having validation on the input level and having an object with array of objects, get error Intersection results could not be merged. See:
builder.mutationField('testMutation', (t) =>
  t.field({
    type: 'Boolean',
    nullable: true,
    errors: {
      types: [ZodError],
    },
    args: {
      input: t.arg({
        type: SomeInput,
        required: true,
        validate: {
          schema: z.object({
            anArray: zod.array(zod.object({}))
          }),
        },
      }),
    },
    resolve: async () => {
      return true;
    },
  })
);

BUT this does work:
const inputSchema = z.object({
  anArray: zod.array(zod.object({}))
});

builder.mutationField('testMutation', (t) =>
  t.field({
    type: 'Boolean',
    nullable: true,
    errors: {
      types: [ZodError],
    },
    args: {
      input: t.arg({
        type: SomeInput,
        required: true,
      }),
    },
    resolve: async (_r, {input }) => {
      inputSchema.parse(input)
      return true;
    },
  })
);

I think there are a few different issues with array validation.  Something I obviously did not test thoroughly enough.  I think I am going to have to look into the intersection stuff, because it seems to pop up in a few different ways (mostly around validating arrays)

Sounds good. I will keep testing things out @hayes :)

Fixed the other issue, but this one is a little trickier

pushed up a temporary workaround. It's not perfect, because the path in errors will now just be the path in the validation validation schema, not the full path if its in a nested object, but its better than nothing.

If you get a change, and could test if<EMAIL_ADDRESS>fixes this issue that would be cool (core needs to be updated too to fix the other issue)

fix: https://github.com/hayes/giraphql/blob/main/packages/plugin-validation/src/createZodSchema.ts#L90-L96

Will do first thing tomorrow


luci-mod-dsl: initial commit

This commit imports the Luci DSL Spectrum graph into LUCI. The spectrum graph shows up as an option in the toplevel
status menu. Code works completely standalone, no dependency on other packages (e.g. chart.js)
Signed-off-by: Roland Barenbrug<EMAIL_ADDRESS>

I've had a look at it now. I think the feature is great. But I noticed that it doesn't look good with different themes. I have the darktheme from bootstrap installed.  But apart from that, I have always missed such a feature in OpenWrt.

Below a screendump of how it looks like without any theme (or the default theme). Let me have a look how the graph can anticipate the theme being used. Valid comment, never considered this as I only use the defulat one.

@feckert would this be better ?

You need to properly handle scaling for the SNR data, as the group size isn't always 8. There is a maximum of 512 subcarrier groups, and the group size depends on how many subcarriers are actually in use. For ADSL the group size is always 1 (as there is only a maximum of 512 subcarriers), but for VDSL2 the group size can even be different for up- and downstream (for example on a line with profile 35b, the downstream group size is typically 16, while it is 8 for upstream data).
As g997sansg does not report the group size, it makes sense to use g997dsnrg instead (the first parameter of that command is the direction, the second is the data type and needs to be 1 for showtime data). If you implement support for the output of that command, it should also be easy to add support for QLN and Hlog using g997dqlng and g997dhlogg.
Here is data from a VDSL2 profile 35b line (from my own standalone tool): dsl_20220520_195501_raw.txt
If it would be helpful for testing, I can also provide data for other VDSL2 profiles (8a/b/c/d, 12a/b, 30a).

You need to properly handle scaling for the SNR data, as the group size isn't always 8. There is a maximum of 512 subcarrier groups, and the group size depends on how many subcarriers are actually in use. For ADSL the group size is always 1 (as there is only a maximum of 512 subcarriers), but for VDSL2 the group size can even be different for up- and downstream (for example on a line with profile 35b, the downstream group size is typically 16, while it is 8 for upstream data).
As g997sansg does not report the group size, it makes sense to use g997dsnrg instead (the first parameter of that command is the direction, the second is the data type and needs to be 1 for showtime data). If you implement support for the output of that command, it should also be easy to add support for QLN and Hlog using g997dqlng and g997dhlogg.
Here is data from a VDSL2 profile 35b line (from my own standalone tool): dsl_20220520_195501_raw.txt If it would be helpful for testing, I can also provide data for other VDSL2 profiles (8a/b/c/d, 12a/b, 30a).

Hi @janh , thnx for your feedback. Let me cook on this for some days and I'll come back.

@janh , @feckert updated the commit to take care of

better colors in case of dark-mode themes
handling sub-carriers depending on their number (scaling)
added graphs covering QLN and HLOG

Please check and share your results.

Scaling in x-direction looks good now: vdsl2-35b.png
In some cases, the x value range may not be the same for each graph and the graphs don't align (but it isn't wrong): vdsl2-8b.png
The scaling in y-direction for QLN and Hlog is broken, though. It should be -23 - v/2 for QLN, and 6 - v/10 for Hlog.
Another thing I noticed is that small details may be hidden due to the way the graphs are drawn. In the profile 8b example, there are actually quite a few invalid SNR values around the range of subcarriers 128-256. However, the graph fails to show that. Here is the raw data: dsl_20220729_185621_raw.txt

Scaling in x-direction looks good now: vdsl2-35b.png In some cases, the x value range may not be the same for each graph and the graphs don't align (but it isn't wrong): vdsl2-8b.png
The scaling in y-direction for QLN and Hlog is broken, though. It should be -23 - v/2 for QLN, and 6 - v/10 for Hlog.
Another thing I noticed is that small details may be hidden due to the way the graphs are drawn. In the profile 8b example, there are actually quite a few invalid SNR values around the range of subcarriers 128-256. However, the graph fails to show that. Here is the raw data: dsl_20220729_185621_raw.txt

@janh, are you sure regarding the value translation? Reading the ITU recommendation:
<IP_ADDRESS> Downstream QLN(f) (QLNpsds)
Description: Reports the downstream QLN(f) as one value per sub-carrier group. A first special value
(255) indicates that the QLN(f) for this sub-carrier group is undetermined. A second special value
(254) indicates that no measurement could be done for this sub-carrier group because it is out of the
downstream MEDLEY set. A third special value (0) indicates that the QLN(f) for this sub-carrier
group is greater than or equal to −35dBm/Hz. A fourth special value (251) indicates that the QLN(f)
for this sub-carrier group is less than or equal to −160.5 dBm/Hz. The object is updated only in L0
link state.
Type: Array of QLNdescriptor[0…N–1], where N = index of highest sub-carrier index in the
downstream MEDLEY set, divided by QLNGds, rounded to the higher integer.
QLNdescriptor:
Type: 8-bit unsigned integer.
Unit: −0.5 dBm/Hz.
Offset: −35 dBm/Hz.
Valid values: 1..250 (−35.5 to –160 dBm/Hz), 0, 251, 254, 255 (special values).

HLOG is indeed wrong, had to remove the minus sign:
<IP_ADDRESS> Downstream HLOG(f) (HLOGpsds)
Description: Reports the downstream Hlog(f) as one value per sub-carrier group. A first special value
(1023) indicates that the Hlog(f) for this sub-carrier group is undetermined. A second special value
(1022) indicates that no measurement could be done for this sub-carrier group because it is out of the
MEDLEY set. A third special value (0) indicates that the Hlog(f) for this sub-carrier group is greater
than or equal to +6.0 dB. A fourth special value (1020) indicates that the Hlog(f) for this sub-carrier
group is less than or equal to −96.0 dB. The object is updated only in L0 link state.
Type: Array of HLOGdescriptor[0…N–1], where N = index of highest sub-carrier index in the
MEDLEY set, divided by HLOGG, rounded to the higher integer.
HLOGdescriptor:
Type: 16-bit unsigned integer.
Rec. ITU-T G.997.2 (03/2019) 57
Unit: −0.1 dB.
Offset: 6 dB.
Valid values: 1…1019 (+5.9 to –95.9 dB) and 0,1020,1022,1023 (special values).
Reference: Clause <IP_ADDRESS>.1 of [ITU-T G.9701].

@janh, are you sure regarding the value translation? Reading the ITU recommendation:
<IP_ADDRESS> Downstream QLN(f) (QLNpsds)

This seems to be from G.997.2, which applies to G.fast. For xDSL, the QLN value is encoded differently. If you look in G.993.2 (VDSL2) or G.997.1 (Physical layer management for DSL transceivers), you'll find that -23 is used as offset (the reserved values are also different for xDSL).

@janh, are you sure regarding the value translation? Reading the ITU recommendation:
<IP_ADDRESS> Downstream QLN(f) (QLNpsds)

This seems to be from G.997.2, which applies to G.fast. For xDSL, the QLN value is encoded differently. If you look in G.993.2 (VDSL2) or G.997.1 (Physical layer management for DSL transceivers), you'll find that -23 is used as offset (the reserved values are also different for xDSL).

Clear, wrong recommendation. Fixed.
Just need to decide on a way to represent the out of range values.

One way to represent the error values is by plotting a little red cross as in the example below. The cross is positioned are the defined minimum or maximum value depending on the error. Would that a sensible way forward ?

In my opinion there is no need to draw missing values in a special way. For xDSL there is only a single special value anyway, which doesn't tell why the value is not valid (and being outside the supported/used carrier set is the most likely reason).
I think fixing the issue I mentioned in my previous comment instead would be enough. It looks to me like the cause is that each data point is drawn using separate overlapping rectangles. Drawing the entire data as a single path should avoid this issse (the drawing code in my own tool does it that way).

Created a  new commit with rewritten drawing routing. Rather than drawing bar by bar, it first draws the outline and then fills the graph. This is done block by block .

Something went wrong with your latest commit, it contains conflict markers.

Mmh, guess these are the red lines in the json files. Really need some help how to solve this.

@janh , should all be fixed now.

Tested OK @ FB7362SL

It doesn't work properly here, there is an exception when drawing downstream SNR for VDSL2 profile 35b (looks like the code assumes a group size of 8 there):
Looking for  65 859
Found  4 -1
Uncaught TypeError: this.dataPoints[endIndex] is undefined
    drawBlock …/luci-static/resources/view/status/dsl/dsl-graph-new.js:22
    drawBlocks …/luci-static/resources/view/status/dsl/dsl-graph-new.js:18
    drawChart …luci-static/resources/view/status/dsl/dsl-graph-new.js:17
    <anonymous> …/luci-static/resources/view/status/dsl/dsl-graph-new.js:37

I am not sure if drawing each band separately is a good idea at all. During showtime state, the bbsg command returns values for the MEDLEY set. However the QLN and Hlog data is available for the SUPPRTEDCARRIERS set, which is a superset of the MEDLEY set. So, a part of the data may actually be cut off in some cases. Even for SNR, you would need to use the limit values instead of the border values (the former is based subcarriers that are allowed to be used, the latter is based only on subcarriers that are currently used).
And in any case, the drawing code also needs to be able to handle invalid/zero values within a band, so I don't think drawing bands separately actually adds any value. If performance is a concern, it may help to omit redundant points from the path (i.e. when subsequent values are identical).
Other than that, I can confirm that invalid values are now drawn correctly. (It looks like the code still handles special values as defined for G.fast, though).

All four graphs are now working here.

All four graphs are now working here.

That's great news. Let's wait for some more review results. Won't touch this for a while until there is some feedback.

For those curious, this is how the charts look like:

after updating *.js graph look like below

@turboproc I'm not sure what's going wrong here, but git seems to suggest there's duplicate files in the PR somehow? I grabbed the plain patch (done by appending .patch to the PR URL). These are the errors git is throwing:
$ git am ../../../patches/luci/0001-luci-mod-dsl.patch
Applying: luci-mod-dsl: initial commit
.git/rebase-apply/patch:57: trailing whitespace.
 }
.git/rebase-apply/patch:99: trailing whitespace.
   ]
warning: 2 lines add whitespace errors.
Applying: luci-mod-dsl: initial commit
.git/rebase-apply/patch:81: trailing whitespace.
//console.time();
.git/rebase-apply/patch:83: trailing whitespace.
 const dsSnrData   = new DataSet(document.getElementById("dsdB").innerText, mySnrFunction);
.git/rebase-apply/patch:174: trailing whitespace.
   ]
.git/rebase-apply/patch:367: trailing whitespace.
      ctx.fillStyle = "#A0A0A0";
error: modules/luci-mod-dsl/Makefile: already exists in index
error: modules/luci-mod-dsl/htdocs/luci-static/resources/view/status/dsl/dsl-graph-new.js: already exists in index
error: modules/luci-mod-dsl/htdocs/luci-static/resources/view/status/dsl/dsl-spectrum.js: already exists in index
error: modules/luci-mod-dsl/root/usr/share/luci/menu.d/luci-mod-status-dsl.json: already exists in index
error: modules/luci-mod-dsl/root/usr/share/rpcd/acl.d/luci-mod-status-dsl.json: already exists in index
Patch failed at 0002 luci-mod-dsl: initial commit
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.

When I inspect the plain patch, I see it creating modules/luci-mod-dsl/Makefile twice, but also other files (the JavaScript files differ in size between patch 1/7 and 2/7 in your patch set though). E.g. dsl-graph-new.js is being added once (patch 1/7, 201 lines of code) and then a second time (patch 2/7, 373 lines of code). I've uploaded the patch here. Result of wget https://patch-diff.githubusercontent.com/raw/openwrt/luci/pull/5895.patch -O 0001-luci-mod-dsl.patch.

@Borromini , not sure what happened. When checking the files in the changed files tab all files look OK.

I have seen in the history, that you have a merge commit.
To fix your git issue you could do the following:

git reset HEAD~8 remove your last commits with out removing our changes
git add . add your changes
git push --force Make a push force to your pullrequest branch

It's a bit late, but shouldn't we consider using the Ubus to get the information we need? I am thinking of checkmk or grafana (without time series input) to push this information to these backends as well. Also the advantage would be that we have the whole thing as json. But I am not sure if this works? I have seen that the output of the command is large.

Have been looking into this when starting this topic. Concluded that in that case the ubus connector would require extension as the information required is not exposed yet by any ubus call. For now it works, indeed the data provided is not in JSON format but with some effort it was possible to parse all data.

I have seen in the history, that you have a merge commit. To fix your git issue you could do the following:

git reset HEAD~8 remove your last commits with out removing our changes
git add . add your changes
git push --force Make a push force to your pullrequest branch

Thnx for the suggestion. Will give it a try (just afraid of losing information with this kind of steps).

@turboproc I'm not sure what's going wrong here, but git seems to suggest there's duplicate files in the PR somehow? I grabbed the plain patch (done by appending .patch to the PR URL). These are the errors git is throwing:
$ git am ../../../patches/luci/0001-luci-mod-dsl.patch
Applying: luci-mod-dsl: initial commit
.git/rebase-apply/patch:57: trailing whitespace.
 }
.git/rebase-apply/patch:99: trailing whitespace.
   ]
warning: 2 lines add whitespace errors.
Applying: luci-mod-dsl: initial commit
.git/rebase-apply/patch:81: trailing whitespace.
//console.time();
.git/rebase-apply/patch:83: trailing whitespace.
 const dsSnrData   = new DataSet(document.getElementById("dsdB").innerText, mySnrFunction);
.git/rebase-apply/patch:174: trailing whitespace.
   ]
.git/rebase-apply/patch:367: trailing whitespace.
      ctx.fillStyle = "#A0A0A0";
error: modules/luci-mod-dsl/Makefile: already exists in index
error: modules/luci-mod-dsl/htdocs/luci-static/resources/view/status/dsl/dsl-graph-new.js: already exists in index
error: modules/luci-mod-dsl/htdocs/luci-static/resources/view/status/dsl/dsl-spectrum.js: already exists in index
error: modules/luci-mod-dsl/root/usr/share/luci/menu.d/luci-mod-status-dsl.json: already exists in index
error: modules/luci-mod-dsl/root/usr/share/rpcd/acl.d/luci-mod-status-dsl.json: already exists in index
Patch failed at 0002 luci-mod-dsl: initial commit
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.

When I inspect the plain patch, I see it creating modules/luci-mod-dsl/Makefile twice, but also other files (the JavaScript files differ in size between patch 1/7 and 2/7 in your patch set though). E.g. dsl-graph-new.js is being added once (patch 1/7, 201 lines of code) and then a second time (patch 2/7, 373 lines of code). I've uploaded the patch here. Result of wget https://patch-diff.githubusercontent.com/raw/openwrt/luci/pull/5895.patch -O 0001-luci-mod-dsl.patch.

@Borromini, @feckert , cleaned the chain of commits and did a new commit. Should look better now.  Very interested myself, but I have no time to swap out my main router (which is on 22.03) for one with a master build atm :(.

It's a bit late, but shouldn't we consider using the Ubus to get the information we need? I am thinking of checkmk or grafana (without time series input) to push this information to these backends as well. Also the advantage would be that we have the whole thing as json. But I am not sure if this works? I have seen that the output of the command is large.

Did some work on this. Pleasr check out https://github.com/openwrt/openwrt/pull/10420. The ubus part has been done. The luci part using ubus is almost ready for commit.

@turboproc Thank four your great work on this. I will test the ubus integrration in one go when you are ready with the LuCI.
I have now tested the last LuCI status. The look and feel for the dark them looks good now.
But somehow I think something is wrong. The graphics look strange.
I will test the ubus integration with my setup when you have updated the LuCI.

@turboproc Thank for your great work on this. I will test the ubus integration in one go when you are ready with the LuCI.
I have now tested the last LuCI status. The look and feel for the dark them looks good now. But somehow I think something is wrong. The graphics look strange. I will test the ubus integration with my setup when you have updated the LuCI.

Indeed a kind of weird. Will commit the Luci DSL module that uses dbus a.s.a.p. Curious whether that gives the same results (hopefully not).

@feckert, any better updates by using the new ubus commit combined with the latest luci-mod-dsl commit ?

I have now tested this again with the ubus backend.
The ubus works as it should.
Only now the graph looks the same as before!
I have uploaded my dsl json to https://pastebin.com/jfcRD7fu
That is the graph I get with this json data.

.q

I have now tested this again with the ubus backend. The ubus works as it should. Only now the graph looks the same as before! I have uploaded my dsl json to https://pastebin.com/jfcRD7fu That is the graph I get with this json data.  .q

OK, observed already one issue: in your case US and DS numbr of groups is different (512 versus 64). Would be helpful to understand the profile your DSL modem is using (ADSL/VDSL, etc, ...)

OK, observed already one issue: in your case US and DS numbr of groups is different (512 versus 64).

I don't think that's actually an issue. Only the first 64 sub-carriers are used for upstream (looks like ADSL2+), so any additional values should be invalid anyway.
To me it looks like there are a few other issues though.

For downstream Hlog, only the first 256 groups seem to contain valid values, the rest looks like garbage. The actual group size seems to be 2.
Downstream QLN extends to the upstream range and contains weird values there.
For Hlog and QLN it looks like a raw value of 0 is reported for invalid value instead of the proper 255/1024.
SNR seems to reports 0 (raw value 64) for some invalid values (start of upstream band).

These all look to me like the data returned by the firmware/driver is already wrong. Maybe the raw data would be useful here to confirm that.
For the first two issues it probably isn't worth it doing anything about that (except for making sure the drawing code doesn't draw outside the graph boundaries). The Hlog issue may be fixable by some heuristic, but it is not clear if this would break more than it fixes (this could just be a bug in a specific firmware version).
The third issue could be worked around by also treating 0 as an invalid value (unlikely to break anything, as values on the edge of the value range are probably extremely rare anyway).
For the fourth issue, I think the best options would be either just leaving it like that, or reducing the value range of the graph to start at 0 (I guess the question is how useful negative SNR values are, although there are actually a few in the data here).

OK, observed already one issue: in your case US and DS numbr of groups is different (512 versus 64).

I don't think that's actually an issue. Only the first 64 sub-carriers are used for upstream (looks like ADSL2+), so any additional values should be invalid anyway.
To me it looks like there are a few other issues though.

For downstream Hlog, only the first 256 groups seem to contain valid values, the rest looks like garbage. The actual group size seems to be 2.
Downstream QLN extends to the upstream range and contains weird values there.
For Hlog and QLN it looks like a raw value of 0 is reported for invalid value instead of the proper 255/1024.
SNR seems to reports 0 (raw value 64) for some invalid values (start of upstream band).

These all look to me like the data returned by the firmware/driver is already wrong. Maybe the raw data would be useful here to confirm that.
For the first two issues it probably isn't worth it doing anything about that (except for making sure the drawing code doesn't draw outside the graph boundaries). The Hlog issue may be fixable by some heuristic, but it is not clear if this would break more than it fixes (this could just be a bug in a specific firmware version).
The third issue could be worked around by also treating 0 as an invalid value (unlikely to break anything, as values on the edge of the value range are probably extremely rare anyway).
For the fourth issue, I think the best options would be either just leaving it like that, or reducing the value range of the graph to start at 0 (I guess the question is how useful negative SNR values are, although there are actually a few in the data here).

Hi @janh, thnx for stepping in. As you might have seen, changed my conclusion already that the 64 / 256 carrier groups are probably OK in the case of a ADSL2+ profile.
Regarding the US part of HLOG and QLN, could it be the case that these measurements do not exist at all in combination with ADSL/ADSL2+, i.e. VDSL only? In that case it might be better to bring some logic that filters that data based on the profile or standard actually used.

Regarding the US part of HLOG and QLN, could it be the case that these measurements do not exist at all in combination with ADSL/ADSL2+, i.e. VDSL only? In that case it might be better to bring some logic that filters that data based on the profile or standard actually used.

Support for SNR, Hlog and QLN was added in ADSL2 and VDSL2, and it was always designed to allow access to both up- and downstream data from both ends of the line. In the original ADSL and VDSL standards these three test parameters weren't available at all (but both should be practically irrelevant today). Grouping of data was added only in VDSL2, so for ADSL2 and ADSL2+ the data should always be reported for all subcarriers.
This means that special casing for different xDSL standards doesn't make sense (at least not because of the standards itself).
I have seen similar issues (i.e. missing upstream or downstream data) before on non-OpenWrt Lantiq-based modems, with actual results depending on the used DSL firmware version. So it is possible these are just driver/firmware/interoperability issues, and we probably have to accept that the data returned from the modem may not always be perfect.

Regarding the US part of HLOG and QLN, could it be the case that these measurements do not exist at all in combination with ADSL/ADSL2+, i.e. VDSL only? In that case it might be better to bring some logic that filters that data based on the profile or standard actually used.

Support for SNR, Hlog and QLN was added in ADSL2 and VDSL2, and it was always designed to allow access to both up- and downstream data from both ends of the line. In the original ADSL and VDSL standards these three test parameters weren't available at all (but both should be practically irrelevant today). Grouping of data was added only in VDSL2, so for ADSL2 and ADSL2+ the data should always be reported for all subcarriers.
This means that special casing for different xDSL standards doesn't make sense (at least not because of the standards itself).
I have seen similar issues (i.e. missing upstream or downstream data) before on non-OpenWrt Lantiq-based modems, with actual results depending on the used DSL firmware version. So it is likely these are just driver/firmware/interoperability issues, and we probably have to accept that the data returned from the modem may not always be perfect.

Clear explanation. Let me just introduce the additional exceptional values as mentioned above.

I have now tested this again with the ubus backend. The ubus works as it should. Only now the graph looks the same as before! I have uploaded my dsl json to https://pastebin.com/jfcRD7fu That is the graph I get with this json data.  .q

@feckert , with the latest commit of ltq-vdsl-app (https://github.com/openwrt/openwrt/pull/10420/commits/c47cfa11a7c7fb461bf72e551a583fb14c121e92) your graphs should look a lot more decent.
BTW: could you share the Lantiq firmware version that you run? Would be helpful to understand how well various versions behave with respect to correctly providing statistics data.

Thats my output from ubus call dsl metrics
root@VR2-103954 ~ # ubus call dsl metrics
{
        "api_version": "<IP_ADDRESS>",
        "firmware_version": "<IP_ADDRESS>.0.2",
        "chipset": "Lantiq-VRX200",
        "driver_version": "<IP_ADDRESS>",
        "state": "Showtime with TC-Layer sync",
        "state_num": 7,
        "up": true,
        "uptime": 152,
        "atu_c": {
                "vendor_id": [
                        181,
                        0,
                        66,
                        68,
                        67,
                        77,
                        164,
                        96
                ],
                "vendor": "Broadcom 164.96",
                "system_vendor_id": [
                        0,
                        0,
                        48,
                        48,
                        48,
                        48,
                        0,
                        0
                ],
                "version": [
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0,
                        0
                ],
                "serial": [
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48,
                        48
                ]
        },
        "power_state": "L0 - Synchronized",
        "power_state_num": 0,
        "xtse": [
                0,
                0,
                0,
                0,
                0,
                0,
                1,
                0
        ],
        "annex": "J",
        "standard": "G.992.5",
        "mode": "G.992.5 (ADSL2+)",
        "upstream": {
                "trellis": true,
                "bitswap": true,
                "retx": false,
                "virtual_noise": false,
                "interleave_delay": 4000,
                "data_rate": 2260000,
                "latn": 1.700000,
                "satn": 0.800000,
                "snr": 7.700000,
                "actps": -41.000000,
                "actatp": 12.800000,
                "attndr": 2251000
        },
        "downstream": {
                "trellis": true,
                "bitswap": false,
                "retx": false,
                "virtual_noise": false,
                "interleave_delay": 7000,
                "data_rate": 5330000,
                "latn": 1.300000,
                "satn": 0.800000,
                "snr": 6.200000,
                "actps": -57.300000,
                "actatp": 4.500000,
                "attndr": 5316000
        },
        "errors": {
                "near": {
                        "es": 0,
                        "ses": 0,
                        "loss": 0,
                        "uas": 50,
                        "lofs": 0,
                        "fecs": 0,
                        "hec": 0,
                        "ibe": 362840426,
                        "crc_p": 0,
                        "crcp_p": 0,
                        "cv_p": 0,
                        "cvp_p": 0
                },
                "far": {
                        "es": 1320,
                        "ses": 1163,
                        "loss": 1120,
                        "uas": 50,
                        "lofs": 0,
                        "fecs": 697409,
                        "hec": 4857,
                        "ibe": 340761,
                        "crc_p": 0,
                        "crcp_p": 0,
                        "cv_p": 0,
                        "cvp_p": 0,
                        "rx_corrupted": 0,
                        "rx_uncorrected_protected": 0,
                        "rx_retransmitted": 0,
                        "rx_corrected": 0,
                        "tx_retransmitted": 0
                }
        }
}

And this is spectrum for this setup:

@feckert this starts to look better already (confirming the ADSL2+ profile in the output) now running into the limitations of the firmware version (<IP_ADDRESS>.0.2). Would you be able to change to a different firmware version (5.9.something) and check whether the results are the same? We could improve the HLOG graphs but that would essentially mean we're fixing some broken output and it might uninentially impact proper data. Preference would be to use simply better data. That might be provided by another firmware version.

@feckert this starts to look better already (confirming the ADSL2+ profile in the output) now running into the limitations of the firmware version (<IP_ADDRESS>.0.2).

I seem to remember that this two data types are only valid to VDSL. If you also see it that way with ADSL2/ADSL2+ for HLOG and QLN data, then we can only display the data or output it via the ubus if we are in VDSL mode.

Would you be able to change to a different firmware version (5.9.something) and check whether the results are the same?

I'll have to see how I can update it. Unfortunately, I can't do it that quickly.

We could improve the HLOG graphs but that would essentially mean we're fixing some broken output and it might uninentially impact proper data. Preference would be to use simply better data. That might be provided by another firmware version.

I agree that we should not fix the DSL firmware expenditure because we do not know what is right or wrong. That must be done by the DSL firmware.

This is absolutely bangin'. Get it in. With the fixes landing in openwrt for VRX300 series DSL chipsets, platforms like Fritzbox 7520/30 are becoming available. These devices have a large penetration in the UK, and DE (and potentially other) markets.

@turboproc - Is this PR ready to merge? Are any required changes in OpenWrt base / OpenWrt packages merged?

@turboproc - Is this PR ready to merge? Are any required changes in OpenWrt base / OpenWrt packages merged?

Hi @jow, thought this has been comitted already. The only action to take care of is that the relevant Luci package needs to be committed as well, otherwise nothing will happen.

To get this over the finishing line:
This commit contains the cleanups I mentioned above. Works for me on ipq40xx/vr11.
If this works on lantiq/vr9 can we agree to merge that, please? I don't see a reason why this should bitrot here...
@feckert do you mind giving that commit a test drive, please - combined with this branch as mentioned in the base PR?

@dhewg I've build and run your branches on FB7412 vr9 and graph works . Black one below is to compare with  1st edition commented above

I'm new to openwrt. I want these charts but couldn't see any instructions on how to use them. Please explain.

Thanks for your work.
Pushed with https://github.com/openwrt/luci/commit/cd48d766add74df60b6c6a882defa859b311ec97 directly. Made some changes see commit Message


Fix: NSNotification.Name.AVPlayerItemDidPlayToEndTime never arrive

Thanks a lot!, merging now

Will make it available today as 0.3.3

Thank you @pbeast , version 0.3.3 has been made available.
As a side note, you have been added to the contributors list at the readme page. Thank you for your support and for making VersaPlayer possible.


Libnetwork Integration with Plugin and Remote Driver Backend

Now that the modular plugin infra is available as a Docker Package, we can integrate it to support Remote Driver.
This PR integrates Libnetwork and the Plugin Infra to dynamically discover NetworkDriver.
Being a modular package, there is no dependancy on the Docker runtime itself as evidenced in the tests added to libnetwork_test.

@squaremo took care of your comments. it certainly simplifies and makes the remote driver more readable.

took care of your comments

Nice one. The implementation of both lazy- and auto-registration looks good to me.

Thanks @squaremo . ping @mrjana & @aboch

LGTM

LGTM


Type inference fails with complex generic tuples

I've been trying to come up with a smarter type def for Angular's $q.all (https://docs.angularjs.org/api/ng/service/$q#all) which takes an array of promises and spits out a promise with an array of results as the value.
For reference, the current DefinitelyTyped implementation is:
    all(promises: IPromise<any>[]): IPromise<any[]>;

I'm attempting to rewrite it with tuples, like so:
    all<T1, T2, T3>([t1, t2, t3]: [IPromise<T1>, IPromise<T2>, IPromise<T3>]): IPromise<[T1, T2, T3]>;
    all<T1, T2>([t1, t2]: [IPromise<T1>, IPromise<T2>]): IPromise<[T1, T2]>;
    all<T1>([t1]: [IPromise<T1>]): IPromise<[T1]>;

Usage:
    // Fails type inference, causes error
    var a = $q.all([$q.when<string>(), $q.when<number>()]);

    // Explicit types work fine
    var b = $q.all<string, number>([$q.when<string>(), $q.when<number>()]);

    // Same generic type works fine
    var c = $q.all([$q.when<string>(), $q.when<string>()]);

Full example on Typescript playground: http://goo.gl/UOKBp7
Attempting to use this with multiple different implicit generic types (example a) causes this error:

The type argument for type parameter 'T1' cannot be inferred from the usage. Consider specifying the type arguments explicitly. The argument candidate 'string' is not a valid type argument because it is not a supertype of candidate 'number'.

As far as I can tell, the Typescript compiler should (ideally) be able to infer this fine. The error seems wrong: 'number' shouldn't be a candidate for T1 at all.

We currently treat tuple types like any other object type in type inference. Tuples are basically arrays with extra numerically named members for the elements and a union of the tuple types as the array element type. It is this union that messes up type inference: Instead of inferring string for T1 and number for T2, we end up inferring both string and number for both T1 and T2. This also explains why it works when T1 and T2 are the same type.
It's fairly easy to fix, we just need to special case tuple-to-tuple inference and not dive into the structure of the types as we do now.


ListView with absolutely positioned items doesn't show full content

Perhaps I'm missing something, but it seems something wrong when the ListView component with the absolutely positioned items.
Here's an example showing a simple listview with 4 rows, the last one I set {position: 'absolute', left: 0, top: 1000, width: 100, height: 100}
https://rnplay.org/apps/i08SuA
the scrollbar can't reach the right end of the listview, and I can't see the last row.

I tried your sample code and notice a few things:

you're using the old syntax (React.createClass instead of class ... extends Component, getInitialState instead of this.state = {} etc.).
it's a bit hard to notice if anything is missing as both images are fully displaying and the rest of the 'rows' are empty. Due to the size of the viewport you just have to swipe in order to see the bottom image fully.

@facebook-github-bot label Icebox

@facebook-github-bot close

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/listview-with-absolutely-positioned-items-doesnt-show-full-content
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.


Support Obsidian style [[#Heading]] Links

Context
If have a page:
// example.md
# Example Page

## Heading 2
This is some context

### Heading 3
Reference to [[#Heading 2]] // this doesn't work
Another Reference to [[Example#Heading 2]] // this works

We get a bit of weird behaviour.
The first heading reference; [[#Heading 2]], returns a WikiLink to
#Heading 2

The first heading reference; [[#Heading 2]], returns a WikiLink to
Example#Heading 2

Is this something we could target to solve? I'm happy to give it a crack - I imagine both mdast-util-wiki-link and this project would need to change to support it?

Apologies - was very sleep deprived when I raised the issue originally - have updated with clearer details and scope.

The expectation is that [[#Heading 2]] renders to Example#Heading 2?

@landakram yep, Obsidian treats those two examples as equal. The [[#Heading 2]] is effectively a short hand for [[Example#Heading 2]]

Any update on this? I'm interested in using this project for some Obsidian-related tooling, and this is a must have.


my birthday

I added my birthday

Why did you delete birthday/dionysis.zindros.txt ?

by mistake..

Please revert the commit deleting my birthday before I merge you ;)

I tried to revert but it created a new commit. :/

A new commit is fine for this. Make sure the final diff just adds your birthday.


firebase_auth: error while running flutterfire configure to add android support

Is there an existing issue for this?

[X] I have searched the existing issues.

Which plugins are affected?
Auth
Which platforms are affected?
No response
Description
Hey all! I'm running flutterfire configure to try and add support for Android in my Flutter app. I have created my Flutter app based on the instructions here, and then I started following the instructions here to add firebase to my Flutter app. When I get to the step of running flutterfire configure, I get an error any time it reaches the Registering new Firebase android app on Firebase project step. As a sanity check, I tried running flutterfire configure and only selecting ios and web as the supported platforms, and it successfully ran. But anytime I try to add support for Android, I get this error:
FirebaseCommandException: An error occured on the Firebase CLI when attempting to run a command.
COMMAND: firebase apps:create android threepio (android) --package-name=com.deck-star.this-is-the-swuiz --json --project=this-is-the-swuiz
ERROR: Failed to create Android app for project this-is-the-swuiz. See firebase-debug.log for more info.

When I check the firebase-debug.log file for further details, this is what I see:
[debug] [2024-07-30T17:48:08.672Z] ----------------------------------------------------------------------
[debug] [2024-07-30T17:48:08.676Z] Command:       /usr/local/Cellar/node/21.7.1/bin/node /usr/local/bin/firebase apps:create android threepio (android) --package-name=com.deck-star.this-is-the-swuiz --json --project=this-is-the-swuiz
[debug] [2024-07-30T17:48:08.676Z] CLI Version:   13.14.2
[debug] [2024-07-30T17:48:08.676Z] Platform:      darwin
[debug] [2024-07-30T17:48:08.676Z] Node Version:  v21.7.1
[debug] [2024-07-30T17:48:08.677Z] Time:          Tue Jul 30 2024 11:48:08 GMT-0600 (Mountain Daylight Time)
[debug] [2024-07-30T17:48:08.677Z] ----------------------------------------------------------------------
[debug]
[debug] [2024-07-30T17:48:08.731Z] Object "" in "firebase.json" has unknown property: {"additionalProperty":"flutter"}
[debug] [2024-07-30T17:48:08.736Z] > command requires scopes: ["email","openid","https://www.googleapis.com/auth/cloudplatformprojects.readonly","https://www.googleapis.com/auth/firebase","https://www.googleapis.com/auth/cloud-platform"]
[debug] [2024-07-30T17:48:08.736Z] > authorizing via signed-in user<EMAIL_ADDRESS>[info] Create your ANDROID app in project this-is-the-swuiz:
[debug] [2024-07-30T17:48:08.740Z] >>> [apiv2][query] POST https://firebase.googleapis.com/v1beta1/projects/this-is-the-swuiz/androidApps [none]
[debug] [2024-07-30T17:48:08.740Z] >>> [apiv2][body] POST https://firebase.googleapis.com/v1beta1/projects/this-is-the-swuiz/androidApps {"displayName":"threepio (android)","packageName":"com.deck-star.this-is-the-swuiz"}
[debug] [2024-07-30T17:48:09.942Z] <<< [apiv2][status] POST https://firebase.googleapis.com/v1beta1/projects/this-is-the-swuiz/androidApps 400
[debug] [2024-07-30T17:48:09.942Z] <<< [apiv2][body] POST https://firebase.googleapis.com/v1beta1/projects/this-is-the-swuiz/androidApps {"error":{"code":400,"message":"Request contains an invalid argument.","status":"INVALID_ARGUMENT"}}
[debug] [2024-07-30T17:48:09.943Z] HTTP Error: 400, Request contains an invalid argument.
[debug] [2024-07-30T17:48:10.517Z] FirebaseError: HTTP Error: 400, Request contains an invalid argument.
    at responseToError (/usr/local/lib/node_modules/firebase-tools/lib/responseToError.js:49:12)
    at RetryOperation._fn (/usr/local/lib/node_modules/firebase-tools/lib/apiv2.js:305:77)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
[error]
[error] Error: Failed to create Android app for project this-is-the-swuiz. See firebase-debug.log for more info.

I've tried nuking everything and recreating the Flutter app and running flutterfire configure again, but get the same INVALID_ARGUMENT error every time.
Any ideas what might be up?
Reproducing the issue
Follow the instructions here to create an empty app, and then follow the instructions here. On the step where you run flutterfire configure, you should only select android, ios, and web as the platforms you want to support. Curious if other people are seeing the same error as me (you'll need to go and check your firebase-debug.log file to confirm.
Firebase Core version
uncertain
Flutter Version
3.22.3
Relevant Log Output
No response
Flutter dependencies

Expand Flutter dependencies snippet

Replace this line with the contents of your `flutter pub deps -- --style=compact`.

Additional context and comments
No response

Hi @andrewgwoodruff. This issue is most likely related to the format of your package name(com.deck-star.this-is-the-swuiz) for Android. Kindly replace the hyphens(-) with an underscore(_) and try again.

@SelaseKay Thank you so much!! That was the problem, and I've confirmed that it's working now, so I'm closing this issue. Thank you again!

Hi @andrewgwoodruff. This issue is most likely related to the format of your package name(com.deck-star.this-is-the-swuiz) for Android. Kindly replace the hyphens(-) with underscores(_) and try again.
com.deck-star.this-is-the-swuiz should be com.deck_star.this_is_the_swuiz instead.

How do I replace them when I didn't even type any bundle name? Typing there doesn't take or indicate that it's taking my input. I suppose it's being detected from gradle or AndroidManifest. Besides, my bundle name includes no special characters


dbeaver is unable to recover from an error in sql query - new sql query is required

Description
hi
If I send an malformed/incorrect SQL query twice - DBeaver will not recover from this error - the only solution is to open new SQL query window and execute the corrected query there.
It is very annoying.
It will stuck like in the below screenshot

DBeaver Version
community edition Version <IP_ADDRESS>310221533
Operating System
macOS Ventura 13.6
Database and driver

DB: postgres (PostgreSQL) 14.1. (running on RHEL 8.6)
org.postgresql.Driver - 42.5.2

Steps to reproduce

New SQL window with a SQL query which is incorrect
Click Execute SQL query
Edit (or not) the query so that it still does not work
Click Execute SQL query
Correct the query so that it is correct
Click Execute SQL query - DBeaver will be still locked with the same error like in the screenshot I pasted above

Additional context
No response

@wirowka I was not able to reproduce this. Can you please check if the last (correct) query is shown in query manager and if it has a success or error status, when there is an error in result set view.

It's been a while since no update here. If the issue is still actual please let me know and provide additional information.


F-Droid build failed

The current Dart SDK version is 2.10.4.
Because git_touch requires SDK version >=2.12.0 <3.0.0, version solving failed.

Which flutter version should be used? Thanks!

Stable channel should be fine

I tried 2.2.1 and it stucked forever.

This is the version in my local machine:
> flutter --version
Flutter 2.2.1 • channel stable • git@github.com:flutter/flutter.git
Framework • revision 02c026b03c (7 days ago) • 2021-05-27 12:24:44 -0700
Engine • revision 0fdb562ac8
Tools • Dart 2.13.1

The build recipe is
  - versionName: 1.12.4
    versionCode: 25
    commit: v1.12.4
    output: build/app/outputs/flutter-apk/app-release.apk
    srclibs:
      -<EMAIL_ADDRESS>    build:
      - $$flutter$$/bin/flutter config --no-analytics
      - $$flutter$$/bin/flutter build apk --no-tree-shake-icons

It stuck at
To see a detailed report, use the untranslated-messages-file
option in the l10n.yaml file:
untranslated-messages-file: desiredFileName.txt
<other option>: <other selection>
This will generate a JSON format file containing all messages that
need to be translated.
lib/screens/ge_search.dart:28:39: Warning: Operand of null-aware operation '?.' has type 'String' which excludes null.
  String get _keyword => _controller!.text?.trim() ?? '';
                                      ^
lib/screens/gh_repo.dart:273:54: Warning: Operand of null-aware operation '?.' has type 'GRepoCommit_history' which excludes null.
 - 'GRepoCommit_history' is from 'package:git_touch/graphql/github.data.gql.dart' ('lib/graphql/github.data.gql.dart').
                        ((ref.target as GRepoCommit).history?.totalCount ?? 0)
                                                     ^
lib/screens/gl_search.dart:29:39: Warning: Operand of null-aware operation '?.' has type 'String' which excludes null.
  String get _keyword => _controller!.text?.trim() ?? '';
                                      ^
lib/screens/gh_search.dart:28:39: Warning: Operand of null-aware operation '?.' has type 'String' which excludes null.
  String get _keyword => _controller!.text?.trim() ?? '';
                                      ^

The current Dart SDK version is 2.10.4.
I tried 2.2.1 and it stucked forever.

@linsui seems like your dart version is 2.10.4 but your flutter version is fine. You've to update dart separately. Or are you already using dart >= 2.12.0?

The current Dart SDK version is 2.10.4.

This is from an old flutter version. I'm not sure which Dart version is used. The full log is available at https://gitlab.com/linsui/fdroiddata/-/jobs/1321205433 if it's useful.

Oh ok
  String get _keyword => _controller!.text?.trim() ?? '';
                                      ^
lib/screens/gh_repo.dart:273:54: Warning: Operand of null-aware operation '?.' has type 'GRepoCommit_history' which excludes null.
 - 'GRepoCommit_history' is from 'package:git_touch/graphql/github.data.gql.dart' ('lib/graphql/github.data.gql.dart').
                        ((ref.target as GRepoCommit).history?.totalCount ?? 0)
                                                     ^
lib/screens/gl_search.dart:29:39: Warning: Operand of null-aware operation '?.' has type 'String' which excludes null.
  String get _keyword => _controller!.text?.trim() ?? '';
                                      ^
lib/screens/gh_search.dart:28:39: Warning: Operand of null-aware operation '?.' has type 'String' which excludes null.
  String get _keyword => _controller!.text?.trim() ?? '';

These shouldn't cause a problem. They're just warnings. I tried building android releases on my local machine and it works fine. Not sure what the problem is. Did a re-run of the build work?

I tried to rerun it but got the same error.

1.13.0 stuch at
"ca": 4 untranslated message(s).
"hu": 87 untranslated message(s).
"ru": 15 untranslated message(s).
"si": 85 untranslated message(s).
To see a detailed report, use the untranslated-messages-file
option in the l10n.yaml file:
untranslated-messages-file: desiredFileName.txt
<other option>: <other selection>
This will generate a JSON format file containing all messages that
need to be translated.

@linsui is there any way to test this locally? Do you have any links?

Yes, you can test it with fdroidserver locally. The gitlab CI use the docker image.

Please note that the last available F-Droid version does not include #236, so GitHub authentication does not work for new users. They cannot complete the auth flow.


[Event Request] Codeunit 7307 "Whse.-Activity-Register" - OnCodeOnBeforeCreateRegActivHeader

Hi team,
In Codeunit 7307 "Whse.-Activity-Register" procedure "Code" we would like to run some custom code after warehosue activity lines are checked, for that an event after running CheckLines would be a good solution:

[IntegrationEvent(false, false)]
local procedure OnCodeOnBeforeCreateRegActivHeader(var WhseActivHeader: Record "Warehouse Activity Header")

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


make dist *** No rule to make target `dist'

Description
Looks like the documentation is outdated and has missing steps (may be obvious for go developers but not that much for others): make dist
Expected results by the docs: "This creates the extension binary in ./extensions/newrelic-lambda-extension."
Actual result: "make: *** No rule to make target `dist'. Stop."

Merged PR to update the readme


[FSDE-8807] Migrate Dropdown component to new Vue documentation

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/5/. :white_check_mark:

You can check this PRs instance in https://61886f5a6c7042d0c317101500a8990fcf03639b-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/6/. :white_check_mark:

You can check this PRs instance in https://2936ca3ad414e2aa73f98440004dcafe39207f07-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/7/. :white_check_mark:

You can check this PRs instance in https://a4f27124d950c6ea408620d3fe1ed1aabd38cc76-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/8/. :white_check_mark:

You can check this PRs instance in https://b47a1eba2c31b2f17e2559e245fec0e6ee79dc5c-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/9/. :white_check_mark:

You can check this PRs instance in https://d8568bb50204dad3252da5f4299960f447997e19-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/10/. :white_check_mark:

You can check this PRs instance in https://26e53011521a3321eba143d071d34632b8483a14-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/12/. :white_check_mark:

You can check this PRs instance in https://c7abc445af4cf6fad0e75b91a7736356b9fc7196-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/13/. :white_check_mark:

You can check this PRs instance in https://3a25b000d3ead3c3df116c701c337b87f953c54c-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/14/. :white_check_mark:

You can check this PRs instance in https://1966abddb4d5d78aeb1c15d7859fa325a8e47214-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/15/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/16/. :white_check_mark:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/17/. :white_check_mark:

You can check this PRs instance in https://7cbd9bf3b9ccbd4093cb950a2d446cd28ef79ded-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/18/. :white_check_mark:

You can check this PRs instance in https://35f5952ef849a8b3948fe97b9d383856367d9e6e-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/19/. :white_check_mark:

You can check this PRs instance in https://2f622dfdcedb00d982fbfaae039140de4b735193-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/20/. :white_check_mark:

You can check this PRs instance in https://93044a8d7ebeb07fb0ed8d79e0b2986a606315a4-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/21/. :white_check_mark:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/22/. :white_check_mark:

You can check this PRs instance in https://682248d76866022805873f40b072108f02b120f0-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/23/. :white_check_mark:

You can check this PRs instance in https://a7f8ca0ff160a9a647d9870c142a9ca804f17277-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/24/. :white_check_mark:

You can check this PRs instance in https://1e20d903aefb6ffc3b0fc879ff1d658bdc317a68-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/25/. :white_check_mark:

You can check this PRs instance in https://eb37bc49ed872588b57833b629ff5d081093840d-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/26/. :white_check_mark:

You can check this PRs instance in https://8ac788124ec83afbaeb05a6fb6b7948a750a2e83-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/27/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/28/. :white_check_mark:

You can check this PRs instance in https://5e6e495b30fff0122425dd2d225b764b4be6c73a-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/29/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/30/. :white_check_mark:

You can check this PRs instance in https://2f6196c66ea47bcb7ff1bc3bbfcc305b738c7144-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/31/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/32/. :white_check_mark:

You can check this PRs instance in https://139e40c2ee21426f5a396249de528d8b39f44213-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/33/. :white_check_mark:

You can check this PRs instance in https://74c2e55124bb3e8525c0c2b7cb44100b711e6293-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/34/. :white_check_mark:

You can check this PRs instance in https://c52d9f13d866709aff7d53908e9701615593783c-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/35/. :white_check_mark:

You can check this PRs instance in https://e45238fd97e3feb907d9c0ba6060195d45f425a0-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/36/. :white_check_mark:

You can check this PRs instance in https://a6ac252b212d107ba14c65a6ce74b0dd6ed1b7d9-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/37/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/38/. :white_check_mark:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/39/. :white_check_mark:

You can check this PRs instance in https://c136113b44185e3280bda81b787bd45da8d68b7f-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/40/. :white_check_mark:

You can check this PRs instance in https://a6e531ddb65ed1b37edb1921d19c2d32a4696cf8-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/41/. :white_check_mark:

You can check this PRs instance in https://92ea39c6d87d6e36209509e49d63a512264b3929-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/42/. :white_check_mark:

You can check this PRs instance in https://7994e4fb4082052b826e9b905237c0e7c691604c-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/43/. :white_check_mark:

You can check this PRs instance in https://20ebe8b2327ab38058d7ad7c5c521860b7d4377a-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/44/. :white_check_mark:

You can check this PRs instance in https://6f80c1f81b44ccc701a4fdc232b0fbd29516a19d-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/45/. :white_check_mark:

You can check this PRs instance in https://d585fa433274611a98bd07432b737f4e6a87cb21-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/46/. :white_check_mark:

You can check this PRs instance in https://ef893604b85b3618fa236b185fad915ae72b8a1a-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/47/. :white_check_mark:

You can check this PRs instance in https://ac6efc6f3ab5112c60fa315e3a04be10fed57a0b-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/48/. :white_check_mark:

You can check this PRs instance in https://a7bb0cc9c12a91964f171086cd665042221fb1e9-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/49/. :white_check_mark:

You can check this PRs instance in https://06a440001ed79f09b1a00a8313258d0487e814ea-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/50/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/51/. :white_check_mark:

You can check this PRs instance in https://d09ccfcc977ad1f8991f8e0632b1e8d402de39bb-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/52/. :x:

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/54/. :x:

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/55/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/56/. :white_check_mark:

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/57/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/58/. :white_check_mark:

You can check this PRs instance in https://926e0e2002d0117973fb93f7a762a614664bc01d-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/59/. :white_check_mark:

You can check this PRs instance in https://7c80d47be93aabc218c966dbaad2b8978510d10a-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/60/. :white_check_mark:

You can check this PRs instance in https://6d3631a54942109736a65c726ca76c4444d4c81a-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/61/. :x:

The CI pipeline did not run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/62/. :x:

The CI pipeline run successfully in https://jenkinsprod.corp.intranet:8443/job/UX-CHI/job/Productive/job/Chi/job/PR-221/63/. :white_check_mark:

You can check this PRs instance in https://8081c0df2e4b39b8440ebbfb8fb7d5d9f6081d33-chi-pr.enterprise.ctl.io (external) and in https://nginx-pr-221-ux-chi.kubeodc-test.corp.intranet/ (internal)


--prefix

http://irclog.perlgeek.de/perl6/2013-02-21#i_6481756

Fixed by 38b8365, I think. Please reopen with specific issues if it's doing something wrong.


Revert "Fix incorrect type casting for alpha and beta in f16 compute type"

Tests failed on gfx94x

Urgent to revert the PR that just merged yesterday


Change the return type of ArgMatches::subcommand.

Make the return type of ArgMatches::subcommand consistent with the other
ArgMatches::subcommand_* methods. In particular, subcommand_name returns
an Option<&str>, but when the subcommand is missing subcommand returns ("", None) instead of None.
This is a breaking change, so I understand you'd have to wait until the next major version bump to merge this.

This change is

:+1:
Yeah I'll have to wait until 3.x but thanks! :smile:


[Noncopyable generics] Suppress inverse conformance mangling for more symbols

Don't mangle inverse conformances for symbols related to dispatch thunks, protocol members, and other entities that are inexorably tied to the primary definition of the type and must have stable names.
Extend the conditional suppression of inverse conformance mangling to property descriptors and more conformance-related symbols.

@swift-ci please smoke test

@swift-ci please smoke test Linux

@swift-ci please smoke test macOS

@swift-ci please smoke test Windows

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test

@swift-ci please smoke test macOS


As a service author I would like all types passed through broker extension points to have a sensible toString method

...so I can understand Matcher failures in my tests :)
Here's an example using a custom matcher we wrote. Because BackingApplication doesn't have an overridden toString, it's impossible to work out what's wrong without using the debugger.
io.pivotal.spring.cloud.configserver.servicebroker.ServiceBrokerComponentTest > createMirrorsMultipleGitReposInComposite() FAILED
    Argument(s) are different! Wanted:
    backingAppDeploymentService bean.deploy(
        BackingApplications containing a single app with environment equal to: <{spring.cloud.config.server.composite[0].cloneOnStart=true, spring.cloud.config.server.composite[0].uri=http://mirror.example.com/fortune-teller, spring.cloud.config.server.composite[1].label=myLabel, spring.cloud.config.server.composite[1].type=git, spring.cloud.config.server.composite[1].uri=http://mirror.example.com/fortune-teller2, spring.cloud.config.server.composite[0].label=myLabel, spring.cloud.config.server.composite[0].type=git, spring.cloud.config.server.composite[1].cloneOnStart=true}>
    );
    -> at io.pivotal.spring.cloud.configserver.servicebroker.ServiceBrokerComponentTest.createMirrorsMultipleGitReposInComposite(ServiceBrokerComponentTest.java:111)
    Actual invocation has different arguments:
    backingAppDeploymentService bean.deploy(
        [org.springframework.cloud.appbroker.deployer.BackingApplication@382b4f80]
    );

Fixed in 986d72cba157429c181c12e12a844185e92fd870

Awesome thanks @scottfrederick !


Spearman score for CIFAR10

Hi,
Thanks for your great work and data! I download the datamodel data of cifar10 with 50pct. Specifcally, train_masks_50pct.npy, train_margins_50pct.npy,  and datamodel train_50pct.pt are ready. Then I use datamodel for prediction with LASSO like:
pred_margin = mask @ weight + bias
corr = scipy.stats.spearmanr(pred_margin, train_margin).correlation
mse = np.mean((pred_margin - curr_margin) ** 2) / 2

However, the mean Spearman correlation is around 0.91 and the MSE is around 1.9, which is lower than the paper (Spearman 0.993 and MSE 1.4). Is there something I missing or it is not proper to directly predict the marginal like this? (I am not sure the lambda is useful during inference)
Hope you can help me with the problem,
Thank you

Hi Yuntao!
Thanks for the kind words!
I believe this discrepancy is due to us using a different evaluation set
for the Figure in the paper,
where we averaged the outputs for a given mask over ten different models
(i.e., for a given mask,
we train a model ten times, and record the average outputs).
This reduces the variance, which would account for the discrepancy you're
seeing.
Also, make sure you're using a "hold out" set when evaluating correlation
or MSE
(e.g., the masks/outputs used to compute the datamodels is non-overlapping
with those used to evaluate).
Let me know if you have other questions.
On Tue, Mar 5, 2024 at 5:09 PM Yuntao Du @.***> wrote:

Hi,
Thanks for your great work and data! I download the datamodel data of
cifar10 with 50pct. Specifcally, train_masks_50pct.npy,
train_margins_50pct.npy, and datamodel train_50pct.pt are ready. Then I
use datamodel for prediction with LASSO like:
pred_margin = mask @ weight + bias
corr = scipy.stats.spearmanr(pred_margin, train_margin).correlation
mse = np.mean((pred_margin - curr_margin) ** 2) / 2
However, the mean Spearman correlation is around 0.91 and the MSE is
around 1.9, which is lower than the paper (Spearman 0.993 and MSE 1.4). Is
there something I missing or it is not proper to directly predict the
marginal like this? (I am not sure the lambda is useful during inference)
Hope you can help me with the problem,
Thank you
—
Reply to this email directly, view it on GitHub
https://github.com/MadryLab/datamodels-data/issues/4, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIKU6NQWJGFHP5YOIAF7G6TYWY7DBAVCNFSM6AAAAABEH6DBBSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE3TAMRSGU3TGMI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hi @sung-max ,
Thanks for your reply! So for the provided downloadable margins, has it been averaged? Or the average is only used in evaluation?
I also noticed that when you train the datamodel for x, x is always not included on the subset (mask) you train (equation 13 in paper). Is there some reason to do this? What if the datamodel is trained with the subset that x is in it?
Looking forward to your reply,
Thanks,
Yuntao


FORNO-665: Public facing Media Import

Description
This PR adds a new command that gives VIP customers the ability to import Media files into their VIP Go application.
The tool takes a web URL as input which must be publically accessible and contains an archive of the files that need to be imported.
The tool detects the root folder structure of the archive and looks for the first occurence of the /uploads directory and imports all the files after it.
Any files that are intentionally skipped or fail to be imported into the site, are logged and exported to the user in the form of a plain text file.
Options

Export file errors to a json file instead of a plain text file: -E
Import intermediate image files: -i
Overwrite existing files: -o

Constraints

Imports can be carried out only on Production environments of VIP Go applications
Only Web Archives are allowed ( no local files )
Archives can be of a maximum of 30 GB in size
Imports can be carried out only on WordPress application of VIP Go applications
Importing an archive that is hosted in Google Drive isn't supported

Steps to Test

Check out PR.
Run npm run build
Ensure that your local GOOP, Parker and MMS are running and connected
Run the following command:

VIP_PROXY="" API_HOST=http://localhost:4000 node ./dist/bin/vip-import-media.js @70.production http://transfer.sh/BenQY/test.zip

Ensure that the command runs successfully and that the import is completed with the likeness of the following output:

→ VIP_PROXY="" API_HOST=http://localhost:4000 node ./dist/bin/vip-import-media.js @70.production http://transfer.sh/BenQY/test.zip
===================================
+ App: test-ms-subdir-01-vipv2-net (id: 70)
+ Environment: production (id: 70)
+ Archive URL: http://transfer.sh/BenQY/test.zip
+ Overwrite any existing files: x No
+ Import intermediate image files: x No
+ Export any file errors encountered to a JSON file instead of a plain text file: x No
===================================
✔
NOTE: If the provided archive's directory structure contains an `/uploads` directory,
only the files present inside that directory will be imported and the rest will be ignored.
If no `/uploads` directory is found, all files will be imported, as is.

Are you sure you want to import the contents of the url?
 (y/N) · true

Importing archive from: http://transfer.sh/BenQY/test.zip
to: testingmapped.com (PRODUCTION)

=============================================================
Processing the files import for your environment...
Imported Files: 1/2 - 50% ✓
=============================================================
Status: COMPLETED ✓ : The Imported files should be visible on your site testingmapped.com
App: test-ms-subdir-01-vipv2-net (PRODUCTION)
=============================================================

⚠ 1 file error(s) found
All errors have been exported to /Users/saroshaga/Projects/Automattic/vip/media-import-test-ms-subdir-01-vipv2-net-1621859354156.txt

You can also check the status of an import with the vip import media status command

→ VIP_PROXY="" API_HOST=http://localhost:4000 node ./dist/bin/vip-import-media-status.js @70.production                                           (media-import|✚1…)

=============================================================
Checking the Media import status for your environment...
Imported Files: 1/2 - 50% ✓
=============================================================
Status: COMPLETED ✓ : The Imported files should be visible on your site testingmapped.com
App: test-ms-subdir-01-vipv2-net (PRODUCTION)
=============================================================

⚠ 1 file error(s) found
All errors have been exported to /Users/saroshaga/Projects/Automattic/vip/media-import-test-ms-subdir-01-vipv2-net-1621859583457.txt

thanks @aswasif007 and @nejclovrencic !!


Fixed Bot Disconnecting And Not Following After Death!

I Will Not Release This To Public. Only To The People Who Are Willing To Join My Project!

what project

well im starting a project with haxtv and opax for slitherbots and we need more coders by our side.

are those free slither bots or paid

well were using the lib but making it more better so were not gonna fully make it expensive when were done. were gonna be doing something like chither with time.


Stremio app

Stremio is a modern media center that's a one-stop solution for your video entertainment. You discover, watch and organize video content from easy to install addons.
Stremio.json
Display name of your application
title: Stremio
Publicly accesible HTTP/HTTPS URL, or data uri to icon image.
iconUri: https://github.com/Stremio/stremio-web/blob/development/images/icon_x192.png
Publicly accessible manifest file of your application
manifestUrl: https://github.com/Stremio/stremio-web/blob/development/manifest.json
Category for your application
category: Streaming
If this is an open source application, use main, otherwise non-free
pool: main
Long description for your application, in Markdown format
description: |
Stremio is a modern media center that's a one-stop solution for your video entertainment. You discover, watch and organize video content from easy to install addons.
Sponsor information, like .github/FUNDING.yml
funding: https://github.com/Stremio/stremio-web/tree/development,yml
github: [ SouoLK ]

I don't understand. Where's the IPK? Have they added webOS support?

Can be closed in favor of #83


[backport] Add work-around for issue in cutensorReduction of cuTENSOR 1.2.1

Backport of #4081

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit ba0971c05fa45c5cbcafab2dac41faaaee80cb64, target branch v8) succeeded!


Fixes to X3D LOD to support child objects

Added support for X3D's <LOD> (level of detail) node to enable child and sibling 3d meshes using <Transform> and <Group> nodes.
Fixes a bug identified by T.Flynn.
There is also a pull request of tests and documentation in the GVRf Tests repository at:
https://github.com/gearvrf/GearVRf-Tests/pull/132
GearVRf-DCO-1.0-Signed-off-by: Mitch Williams
<EMAIL_ADDRESS>

Investigating an issue from Tom.  Recommend not merging till I can resolve this LOD issue.

It definitely fixes a known, significant issue, so it would help if it's included in an upcoming release.  Tom's issue didn't arise from the code in this Pull Req.  Thus, I would recommend going into the next release.

Looks good to me. The tests pass with this change in. Planning to merge on Monday.


[update] Add more test function

Codecov Report
Base: 17.88% // Head: 20.90% // Increases project coverage by +3.01% :tada:

Coverage data is based on head (3f5ebc9) compared to base (2a22500).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
+ Coverage   17.88%   20.90%   +3.01%
==========================================
  Files           8        8
  Lines         218      220       +2
==========================================
+ Hits           39       46       +7
+ Misses        179      174       -5

Impacted Files
Coverage Δ

handy_graph/nx/Interface.py
38.46% <100.00%> (+12.46%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Vendor qemu

This PR replaces ciao's in house qemu package with a vendored version (eacde4d)  of github.com/intel/govmm/qemu.  github.com/intel/govmm/qemu is actually the new home of the old ciao qemu package so there are no code changes to ciao apart from updates to an import path.

Coverage decreased (-0.3%) to 64.318% when pulling 12943aaabb3a5b3fba0ac23ac30751b216e9b81e on markdryan:vendor-qemu into e937a09dac9cba3ececaee80a72365af2c2f1656 on ciao-project:master.


Add custom error type

Currently (2015-04-16) Promissum only uses NSError for errors.
By changing the type Promise<T> to Promise<Value, Error> a custom error type can be provided.
This would allow for more type-safe, fine grained error handling.

For reference, this is being worked on in the feature/error-type branch.

This is now in the Swift 2 branch https://github.com/tomlokhorst/Promissum/pull/9.
To be merged when Swift 2 is out of beta.


Gateways should store roots in ring buffer

To have a constant size O(1) instead of a linear size O(n) depending on messages that will be sent with the gateways, the storage roots in gateway base should be stored in a circular buffer that prunes old storage roots.
In GatewayBase the messagebox offset should be made public, such that the proof generation can query the offset.
Was potentially done in #669
Regenerate the proof using the tool from #711

CircularBufferUint.sol has an implementation of the circular buffer.
If the GatewayBase extends CircularBufferUint.sol then the position of message box in the EVM storage will change because of the variables declared in the CircularBufferUint.sol
The position of message box i.e. MESSAGE_OUTBOX_OFFSET in the outbox is used to generate Merkel proofs.
This change looks like an interface change to me. Maybe there is a work around of this, which I am not aware of.

I suggest we use the inherited contract approach.  It is clearer to understand the storage layout, even if it changes the position.


Add support for INHERITS in postgres dialect

Is your feature request related to a problem? Please describe.
I use INHERITS in my postgres schema. The parser does not recognize create table statements that use INHERITS
Describe the solution you'd like
Create entries for tables that use INHERITS with their inherited fields
Describe alternatives you've considered
Currently I have to manually edit my ddl for any tables that use INHERITS
Additional context
CREATE TABLE public.identifier (
    system text NOT NULL,
    value text NOT NULL
);

CREATE TABLE public."Diagnosis" (
    id text NOT NULL,
);

CREATE TABLE public."Diagnosis_identifier" (
    "Diagnosis_id" text NOT NULL
)
INHERITS (public.identifier);

resulting file does not include a table for Diagnosis_identifier

@ahaessly  Thanks for reporting the issue! Sorry for the delay with answer, I had a lot of personal things to do. I added support for INHERITS. It will be available in 0.30.0 version - I will add one more comment when I will release it to pypi

@ahaessly I just released version 0.30.0, try it. Test was added - https://github.com/xnuinside/simple-ddl-parser/blob/main/tests/dialects/test_psql.py#L10,  if will be needed anything more - open new issue. And thanks for reporting that!


closes #85, adds support for channel variables

:+1:
Great work! Thanks.

We can merge on monday, with more news from @johanwilfer.
Thanks for the review!

Works great. Tested with asterisk 1.8. Thank you!


[Bug] Fix the empty values when runtime filter is LOCAL mode

Fixed #7798
This PR change the IN RS operator when values is empty. Using return RSResult::None instead of thrown exception when values is empty.
The In RS Operator is only used for runtime filter. When filter is empty (the build side is empty infact), the IN values will be empty. So this is not a exception and it should skip all of scan of packs.
What problem does this PR solve?
Issue Number: close #7798
Problem Summary:
What is changed and how it works?
Check List
Tests

[x] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/run-unit-test

/merge

/run-all-tests

/run-unit-test

/run-unit-test


Allow NULL in select dropdown for relation

Laravel Version: 5.4
Voyager Version: v0.11.12
PHP Version: 7
Database Driver & Version:

Description:
I am forced to select a value for foreign key even if it is nullable, first value from parent table always selected in relation select dropdown ...
Regards,
Steps To Reproduce:

This worked :)
{
    "relationship": {
        "key": "id",
        "label": "name"
    },
    "default": "",
    "null": "",
    "options": {
        "": "-- None --"
    }
}

tgc/voyager v1.0.6
The problem persists.

@ateresi, please open your own issue instead of commenting on ones that have been closed for months.

@KhalidNoufal how do you use that json?


Merge 1.38 into vector tiles

Merge the newly released v1.38 into vector tiles.
This merge allows people relying on the vector-tiles branch to publish their own packages. This is similar to https://github.com/AnalyticalGraphicsInc/cesium/pull/5810.

@gberaudo, thanks for the pull request! Maintainers, we have a signed CLA from @gberaudo, so you can review this at any time.
I noticed that a file in one of our ThirdParty folders (ThirdParty/, Source/ThirdParty/) has been added or modified. Please verify that it has a section in LICENSE.md and that its license information is up to date with this new version. Once you do, please confirm by commenting on this pull request.
I am a bot who helps you make Cesium awesome! Thanks again.


Experiments on CoNLL03NER

Hello!
I try to run your code on conll03-ner dataset. But, performance I get is not as good as bilstm-crf. Could you help me find the bug? Thanks.
Here is part of my experiment log.
 Time: 125.29s, speed: 119.62st/s,  total loss:<PHONE_NUMBER>5019379
totalloss:<PHONE_NUMBER>5019379
gold_num =  5942  pred_num =  6508  right_num =  2556
Dev: time: 11.00s, speed: 317.98st/s; acc: 0.9036, p: 0.3927, r: 0.4302, f: 0.4106
gold_num =  5648  pred_num =  6351  right_num =  2261
Test: time: 10.95s, speed: 339.54st/s; acc: 0.8919, p: 0.3560, r: 0.4003, f: 0.3769
Exceed previous best f score: -10

uhnn, i got f1 which is 89, and i use the BIO format

but in some chinese dataset . The results are also low


Fixed issue #5392

Issue Reference
#5392

@akathuria289
Not working, please run npm run prod  and do a fresh PR

@Sanjaybhattwebkul Created PR - https://github.com/bagisto/bagisto/pull/6587


Support directory models (SavedModel)

Models that are saved as a directory (e.g., TF's SavedModel) require SLSA changes to record the hash. This is different that what we use for signing, where we can compute a directory hash.
Until we standardize this for SLSA, we won't be able to support these directory models for now. We need to converge on a single scheme for both signing and SLSA.

Could you explain what's wrong with the current approach, where each file is listed individually in the subject?

Models beyond a certain size (SavedModel or not) split the weights into multiple files. Each will be listed individually in the subject, but the verification only looks at the hashes, not at the file names. So someone could swap the names of two files (model-0001.pth and model-0042.pth for example), the model will still load but will misbehave (unclear how possible this is and what would be an upper bound on impact). SLSA verification will still pass though, so that's why we need something else.

Another issue here is that you can remove a file from the directory, SLSA verification will still pass, but most models will no longer work

Let's implement a Go library (or just create a Go reference implementation) of the existing serialize_v1 https://github.com/google/model-transparency/blob/main/model_signing/serialize.py#L325. https://github.com/slsa-framework/slsa-verifier/issues/730 and https://github.com/slsa-framework/slsa-github-generator/issues/3070 can make use of it. It will avoid duplicating implementations. Overtime we can create ref implementation for other languages in this repo. Wdut?

This sounds great! Let's chat about this and plan it

We should migrate to using the same hashing scheme as in model signing, but this will require first a standardization and then updating SLSA tooling


Error with Request.Body handling, receiving GOAWAY frames..

websocket.Dial https://buxflip.com/ws: http2: Transport: cannot retry err [http2: Transport received Server's graceful shutdown GOAWAY] after Request.Body was written; define Request.GetBody to avoid this error
not exactly sure the reason for this, but would like to understand why it is happening and if you could fix it.

I just made this fork to have a place to post example patches for the go standard library. This isn't a place for websocket support. I would try sending your question to the go-nuts mailing list or posting on stackoverflow.

damn. i really wish they impleted websockets for http2 already

I've written the patches, and there was just recently some movement from the maintainers on it. I'm just waiting for a confirmation that I should go ahead and bake the first of the patches into its final form. If you want, you could try bumping this thread: https://github.com/golang/go/issues/53208


Nuke Camera Loader

 Freshdesk Ticket ID: 255
 Freshdesk Ticket Agent: Jakub Jezek
 Freshdesk Ticket Agent Email<EMAIL_ADDRESS> Ticket Priority: Medium
 Freshdesk Ticket Description: Can we please add camera loader to nuke?

Agent Jakub Jezek linked Freshdesk ticket 255 for this issue.


Feature-Request: Image size

Thanks for the plugin.  It is really helpful.
Is there a way to scale the image to fit e.g. to a PDF Export?
I have a diagram that's too wide to fit to regular paper, but I would be ok when there would be an option to lets say scale it to 90% of page width...

@cschaba sadly this plugin doesn't have control over how Mermaid is rendered :( it's done by Obsidian itself.
I wonder if a plugin like https://github.com/l1xnan/obsidian-better-export-pdf could resolve your issue? It seems to have an option for something like what you need 🤔