Allow setting phone height on background image logo variant

Coverage remained the same at 99.364% when pulling 289f0ababee5e81f7ec4680aec73a1eb3ef98565 on Modularfield:phone_logo_height into 8e38646dc27c194361ad84ba0d647cc78a2ce473 on codevise:master.

Coverage remained the same at 99.364% when pulling 289f0ababee5e81f7ec4680aec73a1eb3ef98565 on Modularfield:phone_logo_height into 8e38646dc27c194361ad84ba0d647cc78a2ce473 on codevise:master.


Custos after staff

Sometimes a custom is not printed/written (completely) on the lines of the staff.

Is there a possibility to encode this?
@music-encoding/ig-mensural Would it make sense and be sufficient if we add the @onstaff attribute here, or is there a finer method needed, that allows saying something like "80% off the staff"?
(Example taken from Petrucci's Frottole libro 3)

Perhaps x/y offsets need to be added to custos to support a different rendered placement of the symbol.

@ahankinson That would probably make sense, but I'm not completely sure if this will be enough if you want to reconstruct the look with tools like Verovio. The specific given example needs more like @cutout from mRest.

I’m not sure I follow. This looks like a pretty standard custos, just horizontally offset. Why would we need something like @cutout?

Actually it's not offset, the notation stops and after the staff lines it is printed. If you just say to a renderer "shift it horizontally" it would still reserve space on the staff lines for the symbol.
This is what Verovio produces:

This is what you get if you only move the custos:

If you remove the "offset" in the original example it would be printed above the last two semibreves.

I agree that this isn't an offset – it's not positioning something to the right of where it would normally go. Rather, it's applying a (common) layout rule that says that a custos is a marginal addition and shouldn't be within the staff area. Often it applies globally or fairly globally, but if we wanted to encode it, we'd need to be able to do it on a per-symbol basis too.
I don't know @onstaff, so can't comment on its applicability.

Gotcha.
@onstaff seems to be pretty generic, so it could probably work -- making att.custos.vis a member of att.placementOnStaff.
There's a lot of overlap in other "placement" attributes, it seems -- data.STAFFREL (both basic and extended flavours), data.PLACEMENT, data.NONSTAFFPLACE. I would avoid any of those, though, since it might lead to unintended consequences. (like allowing a value of above for a custos placement, which of course makes very little sense.)

We do have a value of rightmar in data.NONSTAFFPLACE, which seems quite appropriate. However, that it's not really accessible in this situation, as it's bringing too much other stuff. I therefore agree that att.placementOnStaff seems much more appropriate. However, as it is rather generic, I would recommend to explicitly explain how it is used in conjunction with a custos in an example / remark within the documentation of that element.

Yeah, I saw that but thought that having a custos with a possible placement value of "facing" would be all kinds of weird. 😆

will close this, according to the arguments given in #951


Multi-targeting project build failed when including Swashbuckle.AspNetCore 5.6.3

We need our project to support both .netCore2.2 and .netCore 3.1. In .netCore2.2, we include Swashbuckle.AspnetCore 4.0.1 and In .netCore 3.1, we include Swashbuckle.AspnetCore 5.6.3. When building the project, get "MSB4057 The target "GenerateOpenApiDocuments" does not exist in the project."
If we remove multi-targeting, just support .netCore3.1 (ie. Set netcoreapp3.1), and include Swashbuckle.AspnetCore 5.6.3, then it builds without error.
This error can be reproduced by creating an empty .netCore 3.1 console project with .csproj like below:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp2.2;netcoreapp3.1</TargetFrameworks>
  </PropertyGroup>

  <PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp2.2'">
    <DefineConstants>NETCORE22</DefineConstants>
  </PropertyGroup>
  <PropertyGroup Condition="'$(TargetFramework)' == 'netcoreapp3.1'">
    <DefineConstants>NETCORE31</DefineConstants>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp2.2'">
    <PackageReference Include="Swashbuckle.AspNetCore" Version="4.0.1" />
    <PackageReference Include="Swashbuckle.AspNetCore.Filters" Version="4.5.5" />
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.1'">
    <PackageReference Include="Swashbuckle.AspNetCore" Version="5.6.3" />
    <PackageReference Include="Swashbuckle.AspNetCore.Filters" Version="6.0.0" />
  </ItemGroup>
</Project>

Is there a way to walk around this error?
Thank you

I had same issue. Seems to be a regression in recent versions. There are multiple workarounds listed in https://github.com/domaindrivendev/Swashbuckle.WebApi/issues/1358
For example in csproj:
<PropertyGroup>
<OpenApiGeneratorDocumentsOnBuild>false</OpenApiGeneratorDocumentsOnBuild>
</PropertyGroup>

Thanks, @eric-b ! the above solution works. I close this ticket since it is a duplicate of https://github.com/domaindrivendev/Swashbuckle.WebApi/issues/1358

For example in csproj:
<PropertyGroup>
<OpenApiGeneratorDocumentsOnBuild>false</OpenApiGeneratorDocumentsOnBuild>
</PropertyGroup>

Experienced that the property name ~OpenApiGeneratorDocumentsOnBuild~ is incorrect, it should be OpenApiGenerateDocumentsOnBuild instead.
https://github.com/dotnet/aspnetcore/blob/main/src/Tools/Extensions.ApiDescription.Server/src/build/Microsoft.Extensions.ApiDescription.Server.props#L26

Experienced that the property name ~OpenApiGeneratorDocumentsOnBuild~ is incorrect, it should be OpenApiGenerateDocumentsOnBuild instead.

You’re right, thanks for clarifying.


More collections lib helpers

Discovered that I need a few more things...
Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

[x] I acknowledge that all my contributions will be made under the project's license.

Codecov Report

Merging #876 (bdef770) into master (7d12a01) will decrease coverage by 0.06%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##           master     #876      +/-   ##
==========================================
- Coverage   83.45%   83.39%   -0.07%
==========================================
  Files          74       74
  Lines        5488     5492       +4
  Branches      164      163       -1
==========================================
  Hits         4580     4580
- Misses        908      912       +4

Impacted Files
Coverage Δ

...ators/Java/collectionslib/CollectionsLibType.scala
90.90% <33.33%> (-9.10%)
:arrow_down:

...nerators/Java/AsyncHttpClientClientGenerator.scala
94.30% <100.00%> (ø)

Continue to review full report at Codecov.

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

gonna take a new approach!


Symbol.metadataKey vs Symbol.metadata

README uses both for one case. In the Decorators proposal was used Symbol.metadata. So, what should be used? It's strange to add key to well-known symbols - all of them are unique keys, the case is similar, for example, to Symbol.iterator.

Symbol.metadataKey is a key to be used to get the metadata key.
class C {}
const key = C[Symbol.metadataKey]

The metadata itself is then accessible from some user-defined structure (e.g. a WeakMap).
const metadata = userDefinedWeakMap.get(key)

The old implementation used Symbol.metadata as a key to get to the metadata directly. Examples using Symbol.metadata should be updated to be using Symbol.metadataKey.

So maybe Symbol.metadata in this case should be removed from the README? In the case of the related use case, for example, @@species is not called @@speciesConstructor. However, OK, Symbol.metadataKey is fine for me.


1-feature-rules_and_regulations

Bot needs to send rules and regulation of our community to the users as private messages. Provided contents of the rules and regulation on discussion

Regulation content pending

Regulation content pending


Import fails to identify entry point

In v3, package.json is missing main property and because of which build systems fails to compile the library.
Include main for entry point.

bump

Hey @madhusudhand,
first of all sorry for the late response. In v3 we decided to only support ES Modules. In this scenario only exports are used and therefore we dropped the main property since it also wouldn't work with non esm build systems.


[IOSP-443] fix tests on linux

DispatchServiceTests were not added to the XCTestManifest so not run on Linux.
It appears that despite them passing consistently on macOS, they only fail on Linux.
This PR attempts to debug and fix that.

@AliSoftware are you still working on this one?

Ok I think I start to understand what might be going on here, but not sure how to solve it in a proper manner.
If my investigation is right, the issue is mainly that some signals emit multiple values at the exact same time.

Especially, in tests, since we use a TestScheduler, all the MergeServices call the MockGitHubAPI on the same scheduler's tick. This might mess up with RAF which expect only one event at a time and never 2 event as the exact very same tick.
The impact of that is that the State Machine might not be deterministic when that occurs as to which of the 2 simultaneous event is processed first: on Mac it's one, on Linux it can be the other

Statistically, such a use case probably can't really happen with a real scheduler and GitHub API network requests that will never take the exact same time down to the smallest time unit possible. But that's still something we should potentially account for in RAF code.
This theory is still to be proven; I'm planning to do some more tests to check it first

Ticket returned to backlog as I spent too much time and experiments on it without managing to fix it (and getting more and more obscure behaviors when trying). Will keep the branch open so that we have a history of what was tried though.


Add event type indicators in OverviewPanel.java

Coverage increased (+2.1%) to 71.533% when pulling 5c0632f4613f57e2546b3a7d3f13eb89f07547c5 on Kratious:event-management into 7eef6147ca66dc4ed68c6eb5f98acae3883addf0 on CS2103-AY1819S1-W16-2:master.


recipes for ICASSP

recipes for ICASSP

With reference to many of these comments it's probably worth noting that this is 99% duplicated from the cec2 recipes which weren't authored by me.  As such most of these comments will apply to that code too.
When addressing these I'll apply those changes to the other as to make sure there is consistency in the repository.
Will.

From: Gerardo Roa Dabike @.>
Sent: Tuesday, November 22, 2022 5:50:34 PM
To: claritychallenge/clarity @.>
Cc: jwillbailey @.>; Author @.>
Subject: Re: [claritychallenge/clarity] recipes for ICASSP (PR #120)
@groadabike commented on this pull request.

In recipes/icassp_2023/baseline/evaluate.pyhttps://github.com/claritychallenge/clarity/pull/120#discussion_r1029657270:

ave_score = np.mean(list(score_dict.values()))

logger.info(

   "si.csv exists, and the average combined score is {:.4f}".format(ave_score)

)

if cfg.evaluate.cal_unprocessed_si:

   with open(unproc_si_file, "w") as csv_f:

       csv_writer = csv.writer(

           csv_f, delimiter=",", quotechar='"', quoting=csv.QUOTE_MINIMAL

       )

       for line in unproc_csv_lines:

           csv_writer.writerow(line)

   score_dict = read_csv_scores(unproc_si_file)

   ave_score = np.mean(list(score_dict.values()))

   logger.info(

       "si_unproc.csv exists, and the average HASPI scores for unprocessed scenes is {:.4f}".format(

f-strings are more clear than .format(), especially when you have several variables in the same string.
—
Reply to this email directly, view it on GitHubhttps://github.com/claritychallenge/clarity/pull/120#discussion_r1029657270, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHDQ7YGDLNY3CWRE6P2EZ53WJUBWVANCNFSM6AAAAAASHVSUYU.
You are receiving this because you authored the thread.Message ID: @.***>

@jwillbailey - please just fix the issues in the ICASSP recipe and commit this. We can then raise a separate issue if we want to go back and change old recipes and make them consistent. I'm not saying that isn't worth doing, but it's  not good if the PR  for the ICASSP recipe touches all recipes. This will cause confusion later. The PRs should be linked to well-defined issues and be small where possible. Thx!

@jonbarker68  I'll look into including the README.md from the recipes and adding them to the GitHub Pages.
@jwillbailey I agree with @jonbarker68 about keeping the PR focused. Switching to pathlib should indeed be a separate issue.

@TuZehai - could you have a quick look at the recipes/icassp_2023 please? We need to release it Tuesday for the ICASSP challenge. The evaluate.py now has a fixed hearing aid amplifier and HASPI/HASQI scorer. It seems to be producing sensible scores but it would be good if you could check that it looks correct. The HA amplifier should be the same as we used as the baseline in CEC2. The enhance.py is just dummy code that takes the front mic pair and is the bit that entrants will need to replace. I've tried to make it reasonably clear how they would hook in. I've also defined a standard smaller dev set for more convenient rapid scoring; plus I've separated out the score reporting. Please check that the README looks clear. Thanks!

Hi @jonbarker68, I just had a quick look at this and it looks nice and clear except for two issues:

I suppose the development set of ICASSP should be the same as CEC2? However, the baseline (i.e. NALR) HASPI is 0.332 according to the README, while the CEC2 is 0.249.
In the README file, it might be better to use python xxx.py instead of python3 xxx.py to be consistent..

Thanks. Good point re the haspi score. This was actually based on the
smaller set, but still 500 scenes of the 7500 evenly sampled so I’d be
surprised if very different. But it’s also using floating point rather than
CEC2 which used 16bit - but I’m still doing the tanh soft clip so I don’t
see why that would make a difference.
Think I’ll need to check more carefully. Perhaps the reference
normalisation is different or something.
On Mon, 28 Nov 2022 at 22:14, Zehai Tu @.***> wrote:

Hi @jonbarker68 https://github.com/jonbarker68, I just had a quick look
at this and it looks nice and clear except for two issues:

I suppose the development set of ICASSP should be the same as CEC2?
However, the baseline (i.e. NALR) HASPI is 0.332 according to the README,
while the CEC2 is 0.249.
In the README file, it might be better to use python xxx.py instead
of python3 xxx.py to be consistent..

—
Reply to this email directly, view it on GitHub
https://github.com/claritychallenge/clarity/pull/120#issuecomment-1329824445,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACO7SJEZ6LLEA5TMTCJTHUDWKUVEDANCNFSM6AAAAAASHVSUYU
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Professor Jon Barker,
Department of Computer Science,
University of Sheffield
+44 (0)<PHONE_NUMBER>


Add a join to load only existing modules

Questions
Answers

Description?
Modules are added in the table psgdpr_consent but are never removed from this table even when uninstalled, and still appear as ghost modules in the BO. This join fixes this issue

Type?
bug fix

Category?
BO

BC breaks?
no

Deprecations?
no

How to test?
Go to the psgdpr module in the BO, in the second and third tabs there is no more ghost modules (without a name, icon etc)

Before and after :


Provide vlan plugin documentation

I noticed for a while that the vlan plugin documentation was missing. I wanted to get the ball rolling on it. I wasn't sure if I should put this in current and 1.0.0 or the other directory? If the maintainers have a preference I can update the PR.

👍🏻 for getting this merged


Removed try-catch in test's index.js

Description

Just had to remove the smelly code by getting rid of the try catch block. Tests run perfectly showing that the future is bright! :100:

Related issue(s)
Fixes #440

Haha, Glad to help!

It is actually not included in the release. This was an unintentional release caused by the release automation initial run. 1.0 version of the spec was released a long time ago. The release mentioned by the bot was removed.

Not included in release 2.1 yet, 2.1 was mistakenly triggered by our automation.


GPL-985-2 Added accepted plate format HSLnnnnnnnnn

Closes #3164
Coupled with Crawler PR

Yep, on holiday this week. Thought I put an issue in but can't find it. Might have been a comment one one of the previous barcode format issues.
Essentially:

There is already a catch all barcode format. (Something like external barcode formats)
The array of acceptable formats was intended to describe only those that could come in via manifests, hence why the catch all was missing.
The heron plate import currently shares the lookup method with the one used by manifests,
Instead it could:

always use the catch all format
Use the catch all as fallback

Only issue is the Eagle route, as that does come. in via manifest. (Although check was mainly to provide validation that a customer hadn't just arbitrarily changed the field)


Feature/product alerts

Codecov Report

Merging #54 (b7a2bd9) into master (44bc80f) will decrease coverage by 2.34%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master      #54      +/-   ##
============================================
- Coverage     26.59%   24.24%   -2.35%
- Complexity      147      210      +63
============================================
  Files            12       17       +5
  Lines           707      965     +258
============================================
+ Hits            188      234      +46
- Misses          519      731     +212

Impacted Files
Coverage Δ

woorule/inc/class-rulemailer-api.php
34.37% <0.00%> (-7.74%)
:arrow_down:

woorule/inc/class-woorule.php
64.51% <0.00%> (-5.26%)
:arrow_down:

woorule/inc/class-woorule-shortcode.php
37.70% <0.00%> (-1.96%)
:arrow_down:

woorule/inc/class-woorule-utils.php
100.00% <0.00%> (ø)

woorule/inc/class-woorule-options.php
89.47% <0.00%> (ø)

woorule/inc/class-woorule-checkout.php
100.00% <0.00%> (ø)

woorule/inc/partials/admin-settings.php
100.00% <0.00%> (ø)

woorule/inc/class-woorule-cart-hooks.php
0.00% <0.00%> (ø)

woorule/inc/class-woorule-order-hooks.php
0.00% <0.00%> (ø)

.../class-woorule-klarna-checkout-for-woocommerce.php
0.00% <0.00%> (ø)

... and 5 more

Continue to review full report at Codecov.

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


When will iOS 16.6 support A13

😭😭😭😭�

Not until a PPL bypass is discovered for these devices

Thank you for your answer.


Superset ingestion failure - yield_dashboard_chart

Affected module
Does it impact the UI, backend or Ingestion Framework?
Ingestion
Describe the bug
A clear and concise description of what the bug is.
When performing a Superset ingestion through metadata cli, it fails at some point with the following error. I'm doing my best to find with chart is the offender and exclude from the ingestion task for now, but running metadata --debug ingest -c open-metadata/ingestion/superset.yml does not yield any valuable info.
Traceback (most recent call last):
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/bin/metadata", line 8, in <module>
    sys.exit(metadata())
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/cmd.py", line 73, in ingest
    run_ingest(config_path=config)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/cli/ingest.py", line 47, in run_ingest
    workflow.execute()
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/ingestion/api/workflow.py", line 161, in execute
    for record in self.source.next_record():
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/ingestion/api/topology_runner.py", line 104, in next_record
    yield from self.process_nodes(get_topology_root(self.topology))
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/ingestion/api/topology_runner.py", line 89, in process_nodes
    yield from self.process_nodes(child_nodes)
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/ingestion/api/topology_runner.py", line 73, in process_nodes
    for entity_request in stage_fn(element) or []:
  File "/home/pava/code/com.github.loadsmart/data-catalog-poc/.venv/lib/python3.10/site-packages/metadata/ingestion/source/dashboard/superset.py", line 260, in yield_dashboard_chart
    chart_id = chart_json["id"]
TypeError: 'NoneType' object is not subscriptable

To Reproduce
Screenshots or steps to reproduce
Expected behavior
A clear and concise description of what you expected to happen.
Version:

OS: Ubuntu 22.04
Python version: 3.10.4
OpenMetadata version: <IP_ADDRESS>
OpenMetadata Ingestion package version: <IP_ADDRESS>

Additional context
Add any other context about the problem here.

Hey, @caiopavanelli  can you share which superset version and Openmetadata version you are using?
also were find the chart that was causing this issue?

hi @caiopavanelli if you could please give some more info on this it would be really helpful :) Otherwise, we are currently having issues trying to replicate the error you are facing.
Thanks!

Hi there, I'll try to refine the details and post it here if I can replicate that.

@caiopavanelli any news on this? thanks!

We'll be closing this as we're lacking information. Whenever we get some more details we can reopen it if needed


Add specific libs to the tsc compiler to fix compilation issues in angularjs

Motivation
Fix compilation issues for camera and filestore-client on angularjs repo CI
Description
Add extra libs from the typescript compiler to assure compilation runs okay.
Tested locally with a fresh checkout from angularjs and using raincatcher-angularjs/scripts/checkoutCore clone -b fix-angularjs-compilation && npm run bootstrapCI && npm run testCI, so it should turn angularjs' travis build green.

Changes Unknown when pulling f66b540bdf75589a612d3fb4a1ac1a63f56ccdfe on fix-angularjs-compilation into ** on master**.

Should make https://github.com/feedhenry-raincatcher/raincatcher-angularjs/pull/129 pass after merge


Automatically append /ncr to all https?://*.blogspot.com/ URLs when added to queue

Else, Google redirects to another domain and wpull gets very little of the blog.

abfc08f9160c3de1dcaece542ab3011b17cd59c2 is even better, no need to append /ncr now


what to do about file/src/test/resources/nested-sample.tar ?

Used in a unit test.

remove the file but then need to rewrite the test to create a temp tar file

this is not as easy as it sounds - this tar contains multiple tgz files
it's not clear if the test needs it to be this complicated

document what is in our repo and the source release to highlight that this is a test artifact and not a jar

ASF bans us from having binaries like jars in our repo and source releases but it doesn't ban all binary files
unfortunately, release reviewers might still find the file and still -1 or generally the release

@Claudenw there is a test that relies on nested-sample.tar. The tar file has a complicated structure and the test wants this.
I've read https://www.apache.org/legal/release-policy.html and when ASF bans compiled binaries from source releases - nested-sample.tar is not a compiled binary so IMHO this file is ok for inclusion in the source release.

I swear we had a discussion before about this file and it was resolved, no?

I can't find any previous discussions about this file. I think we have discussed other binary data files in other repos and I think generally, we've been able to remove them. This one isn't as easy to remove.

Now I remember, it was a discussion about binary files and this tile was mentioned and we had to demonstrate it wasn't a binary file

Some of the items I listed can be fixed by adding headers, others I think
can be addressed by adding README or other documentation in the directory
tree where the problematic files are listed.  This is how I would address
the sample.tar file; create a document that explains what it is for and
perhaps points to the test.
q: can you add files to the tar or is the test that picky?  i.e. can you
add a LICENSE and README file to the tar?
On Sat, Jan 20, 2024 at 10:19 PM Matthew de Detrich <
@.***> wrote:

Now I remember, it was a discussion about binary files and this tile was
mentioned and we had to demonstrate it wasn't a binary file
—
Reply to this email directly, view it on GitHub
https://github.com/apache/incubator-pekko-connectors/issues/320#issuecomment-1902267437,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASTVHSF2ZOQVVO67OM4MR3YPQYHDAVCNFSM6AAAAABCDI2Y62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGI3DONBTG4
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
LinkedIn: http://www.linkedin.com/in/claudewarren

Some of the items I listed can be fixed by adding headers, others I think can be addressed by adding README or other documentation in the directory tree where the problematic files are listed. This is how I would address the sample.tar file; create a document that explains what it is for and perhaps points to the test. q: can you add files to the tar or is the test that picky? i.e. can you add a LICENSE and README file to the tar?
…
On Sat, Jan 20, 2024 at 10:19 PM Matthew de Detrich < @.> wrote: Now I remember, it was a discussion about binary files and this tile was mentioned and we had to demonstrate it wasn't a binary file — Reply to this email directly, view it on GitHub <#320 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASTVHSF2ZOQVVO67OM4MR3YPQYHDAVCNFSM6AAAAABCDI2Y62VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGI3DONBTG4 . You are receiving this because you were mentioned.Message ID: @.>
-- LinkedIn: http://www.linkedin.com/in/claudewarren

@Claudenw The file was created by Akka team. Why do we need to add license to it? The ASF have no claim to ownership of the file. Akka didn't bother claiming ownership of the file. I will argue this over and over.

@Claudenw My memory is coming back now and I am fairly certain that this file was already reviewed with a fine tooth comb by @justinmclean some time ago and it hasn't change since then.


Support downloading portions of the video

My current use for youtube-dl is downloading videos from a specific point onwards, this isn't supported but done by using the URL provided with -g inside curl and appending the begin query parameter.
Example of using the begin param:
curl $(youtube-dl -g fjImkK1xAZI)'&begin=38' -o kobe-block.mp4

There is an issue that youtube starts playing from the nearest keyframe which could be before or after the given time. My workflow now is download the video starting 10 seconds prior, run that through ffprobe, find the closest preceding keyframe and start the download again from there.
I am not sure that google provides and end or equivalent parameter but it would be useful to have that functionality as well. Ideally I'd be ably to do something like this:
ytdl fjImkK1xAZI --start 38 --end 42 --output --format 18 kobe-block.mp4

I'll look into this, I wasn't aware YouTube urls supported time ranges.

They at least support begin, which takes milliseconds from beginning to start at.

I can't find any support for any end parameter, I'll consider putting in just an option for begin, but it feels incomplete without an end specifier also.

Thanks for looking into it, I didn't find anything for end either. I think having the begin option is nice since it's undocumented and not something even youtube-dl does.
I'll probably end up using Accept-Ranges: bytes to handle getting a trimmed video.

ytdl supports ranges, e.g. ytdl -r 0-100

There is also a query string param I noticed in the URL that appears to be the duration of the video, when I changed it I got a 403, I wonder if it has to do with the signature?
dur=247.060

I'll look into it


Proposed changes before release

Proposed breaking changes to the API:

GET /v1/content/{digest} endpoint instead of GET /v1/package/{logId}/record/{recordId} for getting content source download URLs;
Current API is not ideal, since records can have multiple releases which provides more download links than clients likely want. Also, when Wasm naked imports are implemented, this new endpoint could more cleanly be extended to provide the dependency URLs for each digest.
Upload HTTP URLs can now specific the method and headers, so that can use POST or PUT as well as Authorization and Content-Type headers; In the future, it would be helpful to add multipart upload support for large files as a new variant type;
Download HTTP URLs can specify whether the Range header is supported to download pieces of large files in parallel; Optional sizeHint field is provided to hint at the expected file size; (Although client doesn't yet take advantage of this functionality.)

Proposed additive changes:
4. Added warg reset command to reset local registry state (clearing package logs etc);
5. Added warg clear command to clear local cache of downloaded content;
Also, there's a fix so that the client CLI verifies the TimestampedCheckpoint signature when updating checkpoints. I'm pretty sure it was not verifying the signature before.

GET /v1/content/{digest} endpoint instead of GET /v1/package/{logId}/record/{recordId} for getting content source download URLs;
Current API is not ideal, since records can have multiple releases which provides more download links than clients likely want. Also, when Wasm naked imports are implemented, this new endpoint could more cleanly be extended to provide the dependency URLs for each digest.

My only concern here is that its an extra round-trip for the common flow of fetching/validating a package log immediately before fetching contents.

Upload HTTP URLs can now specific the method and headers, so that can use POST or PUT and possibly Authorization or other headers; In the future, it would be helpful to add multipart upload support for large files;

I think this is probably fine, but my intention was to add UploadEndpoint variants if this gets much more complicated.

Download HTTP URLs can specify headers and whether the Range header is supported to download pieces of large files in parallel; Optional size field is provided to hint at the expected file size; (Although client doesn't yet take advantage of this functionality.)

I'm somewhat wary of adding "headers" here specifically. I'd really like this baseline download URL type to work with just the URL to make sure it works in as many client scenarios as possible. Do you have a use case where headers are required on download?

GET /v1/content/{digest} endpoint instead of GET /v1/package/{logId}/record/{recordId} for getting content source download URLs;
Current API is not ideal, since records can have multiple releases which provides more download links than clients likely want. Also, when Wasm naked imports are implemented, this new endpoint could more cleanly be extended to provide the dependency URLs for each digest.

My only concern here is that its an extra round-trip for the common flow of fetching/validating a package log immediately before fetching contents.

At moment, this endpoint GET /v1/package/{logId}/record/{recordId} is being used for 2 use cases:

polling for publish status (sourcing, processing, rejected, published) after a publish attempt;
requesting download URLs for content;

This proposed change separates these concerns into different endpoints.
At the moment, this current endpoint is not used for the fetching/validating step, but rather only the POST /v1/fetch/logs endpoint. The record base64-encoded protobuf returned when published status was not being used by the client, since the client already had it when attempted to publish.
In addition, each record could have many release entries and the client often only cares about a single release. The current endpoint would return download URLs for all release entries published in a record.

Upload HTTP URLs can now specific the method and headers, so that can use POST or PUT and possibly Authorization or other headers; In the future, it would be helpful to add multipart upload support for large files;

I think this is probably fine, but my intention was to add UploadEndpoint variants if this gets much more complicated.

Yep, that keeps this pattern to extend the enum variants. It just adds a bit more flexibility in what HTTP requests can be made, without adding much complexity.
I was thinking that multipart uploads would be another variant type that could be used for large file uploads.

Download HTTP URLs can specify headers and whether the Range header is supported to download pieces of large files in parallel; Optional size field is provided to hint at the expected file size; (Although client doesn't yet take advantage of this functionality.)

I'm somewhat wary of adding "headers" here specifically. I'd really like this baseline download URL type to work with just the URL to make sure it works in as many client scenarios as possible. Do you have a use case where headers are required on download?

The ability to provide a Authorization header does come in handy.

The ability to provide a Authorization header does come in handy.

True, but its also an easy place for a client implementation to trip up and e.g. leak credentials. I'm just trying to understand whether this needs to be part of the "baseline" http download type.

Is the concern that it is too much flexibility in what headers that could be provided?

Yes, because some clients (browser fetch, notably) can't send all headers in all contexts, e.g. under CORS constraints.

Is the concern that it is too much flexibility in what headers that could be provided?

Yes, because some clients (browser fetch, notably) can't send all headers in all contexts, e.g. under CORS constraints.

Yeah, agree with those considerations. If it was a protocol restriction as opposed to a registry implementation's choice, that does affect usage patterns.
Not sure if it changes things or not, but it is worth pointing out that the endpoint returns an list (JSON Array) of download options. In theory, there could be options. But not sure if that makes sense in this particular case.
I'll drop the headers field for download URLs. Can choose to add later.

Keep command name for warg reset, but rename warg clear to something else?

Could also combine the functionality of warg reset and warg clear with an opt-in flag e.g. warg reset --clear-content.

I think I would also slightly favor warg clear over warg reset, but that might just be my Rust (cargo clear) bias.

Could also combine the functionality of warg reset and warg clear with an opt-in flag e.g. warg reset --clear-content.

Combining the commands like so wouldn't give you the ability to clear the content cache without clearing the registry log data. Not sure if that matters.

I think I would also slightly favor warg clear over warg reset, but that might just be my Rust (cargo clear) bias.

I was thinking of reset because we were referring to doing a "trust reset", which would require clearing previous registry log data and requesting the updated logs. However, I don't feel strongly about the command names. Just need something that does the job in the CLI without manually doing it (annoying).

It probably isn't that big of deal to rename the CLI commands (reset and clear) later. I doubt there will be many people initially using these commands regularly (except for Warg devs). Not a lot of muscle memory to fight after a rename.
That said, happy to reconfigure it in this PR. Just let me know preferences.

It probably isn't that big of deal to rename the CLI commands (reset and clear) later.

Agreed

I was thinking of reset because we were referring to doing a "trust reset"

Out of scope for this PR, but I have imagined a "trust reset" to be an entirely separate UX flow where the implications of the trust reset are explained to the user before they opt-in.


Request to revert OSS licenses of flomesh modules

I am one of the maintainers of loxilb. It has come to our notice that Flomesh repo https://github.com/flomesh-io/flb/tree/main/ebpf has changed the original copyright of loxilb-ebpf modules.
If it is due to some mistake, we request to revert the original license. If not, we request to take down the repository at the earliest. @cybwan  @addozhang  @naqvis  @keveinliu @reaver-flomesh  @wanpf

We've closed flb as per your request.
And this repo is not related to flb or loxilib, will close this issue as well.


Allow Stack to contain Null children

When building a Stack, it's useful to allow objects to be null in the children for widgets that don't need
to be rendered. My current use case is adding a login widget over my main app by stacking it on top,
but I can't directly include my loginWidget in the children: <Widget>[] list because a Stack doesn't
allow null children inside the list. (I got around it by constructing the list outside of the stack and adding
the login widget to the stack if it's not null.)
The error points to these lines of code:
https://github.com/flutter/flutter/blob/e4b574d3d3c211d9fa2c44f2f862617b6075b708/packages/flutter/lib/src/widgets/framework.dart#L1654-L1657
My hope would be to skip over any null objects and not render them.

You can use children: [...].where((c) => c != null).toList() to filter out nulls yourself.
It might be more comfortable if the framework does this for you, but then the cost for this checks can't be avoided, even when you're sure you never pass null.

That's a beautiful solution!
Similar question, what would to recommend for only assigning an optional argument if a variable isn't
null? I've got a Scaffold and I want to set the bottomNavigationBar only if a field isn't null. Currently
bottomNavigationBar: theField isn't throwing any error but I want to be sure that it's safe for the future.

Ah, excellent! Thanks for the help!

You can also do widget ?? new Container() where it passes a Container if the widget is null (a Container alone doesn't have a form).

well but in a Row() where you set mainAxisAlignment to spacebetween it does and it just ruins my UI is there no other fix


There is a bug when using pynndescent.NNDescent

Nice work!
When my data volume is very large, I will use the "NNDescent" in the "pynndescent" library according to the "Python" code, and then an error will occur.

my “pynndescent” version is ‘0.5.5'. how to fix it?
Looking forward to your reply, thanks.

hi thanks for letting me know. have fixed it. please clone again .

It works, thanks! ^_^!


Provide function to extract error information from a rejected token.

This functionality is used in two places: to build a string to
print errors and in the extraction of the json output for
verible-verilog-syntax.
In the future, there will be another use when generating the
information for the language server.
This function makes it simpler to do custom formats and limits
the leaky abstractions accessed by the user, such as
TextStructure line column map; for the user they are
interested in getting ready resolved line/column-Range, so this
is readily provided.
To convey the full information, introduce a LineColumnRange
to represent the start and end of the region to complain about.
Add printing functionality to print it in a way compatible with
common editors <line-start>:<coli-start>:<line-end>:<col-end>:
The printing is not yet used to first make sure other tools
relying on the format don't break; the finaly switch is then
one simple change (TODO left in code).
Use the new function in

printing an syntax error message for the user
generate the JSON diagnostic print.

Signed-off-by: Henner Zeller<EMAIL_ADDRESS>

Codecov Report

Merging #982 (85cfc2a) into master (fc29a1f) will increase coverage by 0.03%.
The diff coverage is 97.72%.

:exclamation: Current head 85cfc2a differs from pull request most recent head 9a47c56. Consider uploading reports for the commit 9a47c56 to get more accurate results

@@            Coverage Diff             @@
##           master     #982      +/-   ##
==========================================
+ Coverage   92.81%   92.84%   +0.03%
==========================================
  Files         324      324
  Lines       21077    21085       +8
==========================================
+ Hits        19563    19577      +14
+ Misses       1514     1508       -6

Impacted Files
Coverage Δ

common/analysis/file_analyzer.h
100.00% <ø> (ø)

common/strings/line_column_map.h
100.00% <ø> (ø)

common/analysis/file_analyzer.cc
93.81% <96.55%> (+0.71%)
:arrow_up:

common/strings/line_column_map.cc
100.00% <100.00%> (ø)

verilog/analysis/json_diagnostics.cc
84.61% <100.00%> (+15.86%)
:arrow_up:

Continue to review full report at Codecov.

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


Computed properties can have widely different performance characteristics on client and server (because they are not cached during SSR)

Version
v2.4.3 - current (v2.6.10)
Reproduction link
https://jsfiddle.net/anc6Lf23/2/
Steps to reproduce

Open the JSFiddle
You will see the time it takes to compute a value without caching of computed properties (~1 second) in the output
Set "CACHE = true" in the first line of the JS part to see the time it takes to compute the value with caching (~2 ms)

This issue concerns SSR but for simplicity I created the fiddle which emulates the behavior of the server render:

CACHE = true – the behavior we usually have in the client
CACHE = false – the behavior during SSR

What is expected?
I would expect computed properties to have comparable performance characteristics on the server and client, so that I don't need to write custom code.
I.e. I would expect computed properties to be cached during SSR.
What is actually happening?
Computed properties are not cached and therefore have drastically different performance characteristics in some cases.

Description if the issue
Since computed properties are not cached during SSR some components unexpectedly take significantly longer to render. This is the case if it is heavy to compute the property or if it is accessed a lot.
I would usually expect a computed property to have constant time complexity (O(1)) no matter how often we access it. But on the server it suddenly becomes linear time complexity (O(n)). This is especially critical when the computed is accessed in a loop. When we have multiple computed properties relaying on each other, each containing loops, this gets really bad. Then it has polynomial time with the exponent being the amount of nested computed properties (E.g. O(n^3) for three levels of computes, like in the JSFiddle)
Real world example
I noticed this issue because our server renderer suddenly took multiple seconds (5-8 seconds) to respond after enabling a new component for SSR. Normally rendering the app on the server takes about 100ms.
The effected component is part of a proprietary code base but it is similar to the one in the JSFiddle. You can see the component in production here:

Open: https://www.ikea.com/de/de/bereiche/wohnzimmer/
Click on the "Serien" button
The flyout content is the effected component

After finding out about this I also investigated other occurrences of this:
In our Vuex store we did not have any nested getters with loops, like described above, however some of the getters are somewhat heavy to compute (~1ms) and accessed a lot in various templates. So I decided to introduce a very simple custom caching layer to our store. This sped up server rendering by about 20%.
This could also be a low hanging fruit for optimizing SSR performance:
Based on analyzing our own app, I would roughly estimate that caching all computed properties could speed up server rendering by about 30% in an average Vue.js app.
For me this issue was hard to understand because the affected code seemed harmless at first.
Mitigation
To mitigate this issue you can move access to computes out of loops: access them once, store them in a local variable and then use this variable in the loop. This is generally a good idea since any look up of a property on a Vue.js VM has a small cost.
However this is not possible if you have a loop inside your templates.
References

The code that controls this behavior:
https://github.com/vuejs/vue/blob/0948d999f2fddf9f90991956493f976273c5da1f/src/core/instance/state.js#L208-L219

The issue that lead to this behavior being introduced: vuejs/vuex#877

The commit that introduced this behavior 06741f32

Earlier occasion of someone stumbling over this:

nuxt/nuxt.js#2447
https://forum.vuejs.org/t/ssr-performance-problems-due-to-lack-of-caching/24653/5

I think you are aware of this (jusdging from how deep you digged into this), but I want to quickly re-iterate so people are on the same page:

Reactivity is disabled on the server for a reason.
Yet disabling it leads to stale caches for computed properties.
So disabling the cache for computed properties is technically necessary to ensure that the app shows the correct data.

There's no straightforward solution to this, as far as I can tell at least.
The best I can think of right now would be to

Improve SSR docs to raise awareness and
maybe provide a helper function or something to use for memoizing computed props when on the server.

I think your proposed changes would be good improvements but I'm wondering if we can not go a bit further.
I would even question if the performance advantage of disabling reactivity on the server pays off, considering that that means computed properties aren't cached. It would be interesting to get some numbers on that.
But maybe there is a way to cache computed properties without having stale caches:
As far as I understand it caching for computed properties was only disabled because the Vuex state changes during SSR and getters then return outdated results. Though, in the Vuex case, we don't need the whole reactivity system to tell if the state changed because all state changes are encapsulated in mutations. So perhaps Vuex could just "rest" the computed cache for the getters after a mutation.
This would mean that the Vue.js Core had to provide a new API for "resetting" computes on the server. And Vuex would need to trigger that API after a mutation.

To @LinusBorg's second bullet, we ran into this recently and I wanted to drop in our optimization workaround.  We had a single getter that was massaging some data we get back from an API (in a particularly unuseful data structure) and the getter was converting the data into a much simpler data structure to be used in components.  However, computing the simpler structure took a triple-nested loop that could take close to 1ms - and that method could 50+ times during a single SSR page load because it was accessed in a bunch of places.
One option would have been to lift the getter access to a parent component and pass it via a prop all the way down - however, the component tree is fairly large and that would have been a pretty invasive change at the moment.  Another would be to move this computation out of the UI and offload to the server, but that would require a pretty significant refactor to the app as well.
So instead we decided to pre-compute the value during SSR and store it in the store state,  but since it's derivative data of other data in state we didn't want to increase the size of the stringified state sent to the client.  So we used a custom JSON.stringify replacer function to this key when stringifying the state.
The end code looked something like:
// store.js
return new Vuex.Store({
    state: {
        apiData: null,
        _ssr_uiMap: null,
    },
    mutations: {
        setApiData(state, apiData) {
            state.apiData = apiData;
        },
        setUiMap(state, uoMap) {
            state._ssr_uiMap = uiMap;
        },
    },
    actions: {
        loadApiData({ commit }) {
            const apiData = await loadApiData();
            commit('setApiData', apiData);

            if (process.env.VUE_ENV === 'server') {
                commit('setUiMap', computeUiMap(apiData));
            }
        },
    },
    getters: {
        uiMap(state) {
            if (process.env.VUE_ENV === 'server' && state._ssr_uiMap) {
                return state._ssr_uiMap
            }
            return computeUiMap(state.apiData);
        },
    },
});

// And then when we stringify the store in entry-server.js, we use the following
// to strip any _ssr_ prefixed keys from the state
JSON.stringify(store.state, (k, v) => k.startsWith('_ssr_') ? undefined : v)

So we can memoize the value on the server and only calculate it once, while still leveraging the built-in getter caching client side without impacting payload size of the stringified store.
It's not a 100% ideal solution, but it works quite well in limited cases and we saw around a 20-25% increase in SSR render time.

I have also experienced significant performance issues in SSR mode due to this behaviour. Even if I have later found and optimized the main bottleneck, I still don't like such greatly different behaviour of computed properties in SSR mode. That's why I tried to find en easy way to selectively enable caching of computed properties in components, where it is safe to do. Here is my solution, which seems to work fine for me, so maybe it could be also useful for others.
My idea was to add support for a new option, which will enable/control caching of computed properties on server.
// Vue component
export default {
  computed: {
    compA () {},
    compB () {}
  },
  ssrComputedCache: true, // enable caching for all computed properties
  ssrComputedCache: ['compA'] // or enable cache for selected computed properties
}

And here is a global mixin implementing this feature, which can be used in nuxt app as plugin
// nuxt plugin (mode: 'server')
import Vue from 'vue'

Vue.mixin({
  created () {
    if (process.server && this.$options.ssrComputedCache) {
      const { computed, ssrComputedCache } = this.$options
      const cachedProperties = ssrComputedCache === true ? Object.keys(computed) : ssrComputedCache
      cachedProperties.forEach(name => {
        let value
        let cached = false
        Object.defineProperty(this, name, {
          // for repeated re-definition in dev mode, depending on runInNewContext setting
          // (https://github.com/nuxt/nuxt.js/issues/7171)
          configurable: true,
          get () {
            if (cached) {
              return value
            }
            value = computed[name].apply(this)
            cached = true
            return value
          }
        })
      })
    }
  }
})

I have also experienced significant performance issues in SSR mode due to this behaviour. Even if I have later found and optimized the main bottleneck, I still don't like such greatly different behaviour of computed properties in SSR mode. That's why I tried to find en easy way to selectively enable caching of computed properties in components, where it is safe to do. Here is my solution, which seems to work fine for me, so maybe it could be also useful for others.
My idea was to add support for a new option, which will enable/control caching of computed properties on server.
// Vue component
export default {
  computed: {
    compA () {},
    compB () {}
  },
  ssrComputedCache: true, // enable caching for all computed properties
  ssrComputedCache: ['compA'] // or enable cache for selected computed properties
}

And here is a global mixin implementing this feature, which can be used in nuxt app as plugin
// nuxt plugin (mode: 'server')
import Vue from 'vue'

Vue.mixin({
  created () {
    if (process.server && this.$options.ssrComputedCache) {
      const { computed, ssrComputedCache } = this.$options
      const cachedProperties = ssrComputedCache === true ? Object.keys(computed) : ssrComputedCache
      cachedProperties.forEach(name => {
        let value
        let cached = false
        Object.defineProperty(this, name, {
          // for repeated re-definition in dev mode, depending on runInNewContext setting
          // (https://github.com/nuxt/nuxt.js/issues/7171)
          configurable: true,
          get () {
            if (cached) {
              return value
            }
            value = computed[name].apply(this)
            cached = true
            return value
          }
        })
      })
    }
  }
})


Use babel for the build project

Codecov Report

Merging #68 (df7148c) into main (3aa5028) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #68   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           29        29
  Lines          195       195
  Branches        40        40
=========================================
  Hits           195       195

Continue to review full report at Codecov.

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


No changes detected

node watcher.js works great, but changes dont works on a Geny Virtual device. (LiveSync Watcher v0.02)
Checking updated file:  ./app/main-page.xml
Pushing to Device:  ./app/main-page.xml

Does your adb log show any errors on the Geny Virtual Machine?
Did you compile your own Android-runtime and use my patch https://github.com/NativeScript/android-runtime/pull/92 -- without this patch, the Android side won't be able to reload the files.

adb log dont has errors related to it. But I didnt use your android-runtime. I am not a power user to do that.

One option is I could distribute my runtime that I compiled...    Then you would just download the runtime and do a
tns platform remove android
and then
tns platform add android --frameworkPath=<downloadedRuntimeName>

Distribute tour runtime will be great :)

Yeah, that'd be great for us non-eclipsers!

I have uploaded my runtimes.  See the main https://github.com/Nathanaela/nativescript-livesync/blob/master/README.md instructions.
(I also don't use eclipse -- I do all my compiling from the command line)

I have spent some time getting ready for the new plugin interface.  Once you have the new TNS v1.1.3 command line (which should be released very, very, very shortly) -- you can do tns plugin add nativescript-livesync and it will take care of everything including installing the replacement runtimes.
The current version I just uploaded has v1.1.0 runtimes, in case their are people who are going to stay on the v1.1.0 android runtimes.     But I have already compiled the v1.2.0 runtimes (as they have tagged them as v1.2.0 already) and just waiting for Telerik to pull the trigger on actually releasing v1.2.0 in the next day or so.

That`s cool. I expect NativeScript goes ready to the "production time" very soon! Have you take a look at Tabris.js? https://tabrisjs.com/

Tabris-JS is an interesting project, I hadn't seen it before; but it does not seem to be nearly as well thought out as NativeScript.   It does have a couple things going for it; but based on reading through several of its repos; I will definitely don't think it is prime time either...


Errno 111

Please tell me why
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='<IP_ADDRESS>', port=8080): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fc24086c130>: Failed to establish a new connection: [Errno 111] Connection refused'))

Please tell me why raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPConnectionPool(host='<IP_ADDRESS>', port=8080): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fc24086c130>: Failed to establish a new connection: [Errno 111] Connection refused'))


examples: Do not use SSL for etcd in minikube for k8s <= 1.9

Minikube does not provide SSL certificates for etcd and configures
apiserver to use HTTP when the Kubernetes version is lower than 1.9.
Fixes: #6940
Signed-off-by: Michal Rostecki<EMAIL_ADDRESS>

This change is

test-me-please

Coverage decreased (-0.01%) to 42.989% when pulling 78d6734c683eb4e3f11306227897a8f662ca65ba on mrostecki:minikube-etcd-ssl into e8aabe0578ff2f026b3d5fbef9d55917835d2470 on cilium:master.

16:29:32 • Failure [316.768 seconds]
16:29:32 RuntimeKVStoreTest
16:29:32 /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:376
16:29:32   Etcd KVStore [It]
16:29:32   /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/ginkgo-ext/scopes.go:408
16:29:32
16:29:32   Error getting names of endpoints from cilium
16:29:32   Expected
16:29:32       <*errors.errorString | 0xc4202e8400>: {
16:29:32           s: "`cilium endpoint list` was not successful",
16:29:32       }
16:29:32   to be nil
16:29:32
16:29:32   /home/jenkins/workspace/Cilium-PR-Ginkgo-Tests-Validated/src/github.com/cilium/cilium/test/runtime/kvstore.go:103

Unrelated, I just modified minikube yaml files.

test-me-please

test-me-please


How to use it with secret gists?

Hi,
I'm trying to use this with secret gist but I'm facing this issue.
Error: Failed to create gist, response status code: 404, status message: Not Found
I tried it with public gists and it works fine with public ones, so the issue is definitely not with the token. Is there something else that needs to be passed while using it with secret gist?

@Schneegans I just started getting this too (and not due to what happend in #15 ).

@Schneegans False alarm again. I just needed to update by SECRET key.

False alarm, the gist ID's creator was different than the one I created PAT for. Other users cannot update GISTS, so the PAT has to be created for the same user. My bad! Closing this issue.

Thanks for the update! I was just trying to reproduce this and wondered how this could happen :)


How do I specify the contents of the TX Fifo prior to running a program?

Title pretty much says it all.  I've looked at the two documents I can find, the Quick start guide, and the Tour, and neither of them say anything about how to specify the contents of the TX Fifo prior to starting execution.  I know it's supported, otherwise the OUT instruction would not be able to work properly.

Hi @dgnuff :wave:
It should be possible to pass the TX FIFO into emulate() via the optional initial_state parameter. For example:
from collections import deque
from pioemu import emulate, State

initial_state = State(transmit_fifo=deque([1, 2, 3]))
opcodes = [0x80a0, 0x6060]

for before, after in emulate(opcodes, initial_state=initial_state, stop_when=...):
    pass # etc.

However, if this doesn't work for you please let me know.

That works - thanks for the help.
Closing this issue.

Thanks @dgnuff. If you find this mechanism doesn't scale to your needs then please just raise another issue!


Accounts: Settings Page - remove the save column and added the save button

On the settings page - remove the save button column from the table. And place the save button next to the setting adjustment similar to the domains page. A spacing treatment should also be added to the save buttons to create spacing between icon and text
MUI button treatments:
https://mui.com/material-ui/react-button/#buttons-with-icons-and-label
Update to this layout:

Remove Save column:


⚠ Bofrost.lu has degraded performance

In fbeb750, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1243 ms

Resolved: Bofrost.lu performance has improved in 2d622e7.


2.0 NPM package is missing the code

The 2.0 release on NPM is missing the dist directory. So npm can't install it and pnpm appears to install it but then the export is empty.

Thanks for flagging it. Weird. I will take care of it soon!

The releases are a bit wonky. It seems like the sentence satisfy matcher was missing from the types declarations.
I added the missing type and also release version 2.0.1.
If the issue is not resolved for you in the new version, LMK.
Closing for now


show error code in ble error popup

feat(#28): show error code in ble error popup

If the above comments are addressed. The code Looks good to me for merge.


Up for PR's?

Will anyone be allowed to do PR to this repo? We have used libvirt with rpc for a while (better than creating and using binding) but in a different language but thought about bringing it to Go and then I saw this and thought it would be cool to just contribute instead of doing the same thing

Ignore the issue. Overlooked the CONTRIBUTING.md.

Absolutely!  We'd love contributions from anyone with experience with the libvirt RPC protocol.  If there's a feature you'd like to add, just open an issue first with your idea and proposed changes, and we'd be happy to discuss it.

Thanks!


Missing design token for $rounded-pill

When trying to use the design tokens compiled CSS from @edx/paragon in frontend-app-profile, there was a drop-in replacement for every SCSS variable and media query except for $rounded-pill. On the alpha branch, it doesn't appear we have any tokens that specify a source: '$rounded-pill', which seems to indicate we may not have a design token to go along with $rounded-pill.
### Tasks
- [ ] Check whether we're missing a design token for the current state `$rounded-pill` SCSS variable; if so, add one.

PR: https://github.com/openedx/paragon/pull/2361


migrate to formal python package

What is this
As the design has evolved it's coming clear we need to bundle the pipeline code as a simple python package rather than just a repo of scripts - this makes for much cleaner separation of code vs infrastructure.
This means adding some packaging considerations and removing some infrastructure ones.
This task is therefore a small collection of associated tasks to complete that transition.
What to do
You'll need to update the repository structure followed by the documentation.
Repo Structure changes:

1.) /pipelines to /dpypelines
2.) move /schemas into /dpypelines/schemas - you'll need to update paths in code and tests accordingly - I would suggest getting the unit tests back to running before moving on to point 3.
3.) poetry not pipenv - use python 3.9 please
4.) be sure to include non python assets (see below)
5.) Also remove builder.yml and s3_file_recieved.yml
6.) remember to update the makefile for poetry not pipenv

non python assets - you'll need to specify that the json files need to be bundled with the python code, look into [tool.poetry.files] - ideally (if possible, I dont know) include all json files in the schemas directory tree with some sort of wildcard rather than having to specify them individually - regardless you'd probably best pip install from your branch a few times and use them "schema from config" function a bit to sanity check you've nailed this one down, from memory it can be fiddly.
Documentation
add pip install instructions (from github for now)
dont add usage yet, that's still undecided, just add the section and stick TODO in there - the exact signature for the first entrypoint (s3_tar_recieved.start()) is being nailed down in another task.
to add a LICENCE file and licence comment in the readme, copy both from dp-python-tools.
get rid of all infrastructure information, the pictures can go, infrastructure aspects will live in their own repo - we want this repo to simply just be a python package, the fact
that some infrastructure uses it is incidental and not to be alluded to.
Acceptance Criteria

[ ] Repo restructured as packahge and is installable
[ ] Tests pass
[ ] Documentation updated, infrastructure concerns removed.

done


Switch to the mesons

Why not, considering that meson is sort of standard build tool in the wayland sphere.


Movement powers are ignoring reduced endurance

module/ruler.js:109  has the following code which explains. We can't use the expected endurance cost of the movement because it's always 0.
                            // Assuming every 10 costs 1 endurance
                            let totalEnd = Math.ceil(currentDistance / 10);
                            let costEnd = totalEnd - spentEnd;
                            if (costEnd > 0) {

Additionally, the cumulative endurance costs will be wrong for multi segment moves with different movement types as dragRuler.getMovedDistanceFromToken returns the total distance moved and not the distance moved in the last segment.

In that same section you will see references to flags.dragRuler which keep track of endurance during partial moves.  When the spentEnd is calculated you can use the current movement type/cost to adjust spentEnd.  You might use a float to track half endurance.  You might also consider spending END every 5 or 20 meters for half/double endurance, although that may not follow rules exactly.  Note that we can put anything we want in flags, possibly tracking END for each movement segment.


When running out of ingredients on the loom, on the the 3x3 grid, it doesn't really have the red background with yellow icon

Basically, this only happens after you run out of the dye and/or banner patterns, and going into the same thing you're trying to create, it doesn't have the red background with yellow icon. (idk what exactly it's called lol)

Currently, you still have dye in your inventory, this cannot be considered a bug, as it works the way it should, in LE the dye is consumed even if you haven't crafted it yet


Use Addon CatalogSource from openshift-marketplace

The RHODS addon CatalogSource has moved to the openshift-marketplace namespace [1].
[1] https://gitlab.cee.redhat.com/data-hub/olminstall/-/merge_requests/30/

Depends on https://gitlab.cee.redhat.com/data-hub/olminstall/-/merge_requests/30/

The https://gitlab.cee.redhat.com/data-hub/olminstall/-/merge_requests/30/ has been merged, please review, thanks!

@winklerm could you run this pr for verification of v1 and v2 operator to make sure everything is working fine with new changes

I have run the Jenkins job for verification : smoke job : #3348,#3349#3350#3351

@tarukumar Thank you! I have run the operator v2 DW smoke job for verification: https://opendatascience-jenkins-csb-rhods.apps.ocp-c1.prod.psi.redhat.com/view/Distributed_Workloads_Jobs/job/rhods-dw-smoke-new-operator/lastCompletedBuild/, the one failure is unrelated (other tests passed, so the deployment worked).


Having issues with worksheets on Eclipse 2019-12(4.14.0)

Not sure if this is just an issue with me or eclipse.
So I am able to get metals to work in a .scala file.. (By work I mean that it will makes completion suggestions)
An issue that I am coming up against is getting worksheets to work.
My steps
Created a file in my project directory. The file name is src/main/scala/attempt.worksheet.sc
Expected Once creating this file I was expecting to see the result for my expressions show as text within the worksheet.
Actual worksheet file is not being interpreted
I checked the logs for eclipse and language server and I am not finding anything to indicate what the issue might be
Could be user error but felt like I tried what I could. Let me know if any additional troubleshooting that I might preform.
Side note
I have also notice that I am not able to access the command interface http://<IP_ADDRESS>:5031/. Not sure if this is a indication of something so wanted to mention it.

Thanks for reporting! It looks like the worksheets are really not being updated and the command interface is not there, we to take a look at it and figure out what's going on.

From what I see it looks like the worksheets are no longer sent to be evaluated to the server, it might be due to the different extension.

@tgodzik is there something that I can do to help?
If someone can help me with a starting place I can do a little leg work.
I would like to use the worksheets. I know that repl can be used but I still would prefer the worksheet.

@KCulture I planned to take a look, but couldn't really find the time for it. I am not 100% sure what we need to do there. It seems .sc files are not treated as scala files, which is why worksheets don't get updated. There should be a part of the code that registers it, so I am thinking the only issue might be to add it? I will try to take a look next week finally, I need to update a bit of things there.


Update celeryconfig.py

Original error:
celery.exceptions.ImproperlyConfigured:

Cannot mix new and old setting keys, please rename the
following settings to the new format:

CELERYD_MAX_TASKS_PER_CHILD          -> worker_max_tasks_per_child
CELERYD_TASK_SOFT_TIME_LIMIT         -> task_soft_time_limit

LGTM, but I do not understand why, we didn't change the version and it's currently working.

I was also surprised when I saw this error in cabot-celery log.


arm64 image differences

Description
Some binaries and libraries are not present on the arm64 image.
Impact
It may be confusing to users or block a migration to arm64 when suddenly something is missing that was present on amd64
Environment and steps to reproduce
This will give the list:
BOARD_A=amd64-usr BOARD_B=arm64-usr CHANNEL_A=alpha CHANNEL_B=alpha FILE=flatcar_production_image_contents.txt FILESONLY=1 CUTKERNEL=1 flatcar-build-scripts/package-diff  3185.0.0   3185.0.0

Expected behavior
Where it makes sense the arm64 image should be the same as the amd64 image
Additional information

Here one concrete case: https://github.com/flatcar-linux/Flatcar/issues/690

sssd pulls in samba which pulls in liburing, which doesn't cross-compile. I've opened an upstream PR with a fix: https://github.com/gentoo/gentoo/pull/24733.

Now that liburing has been updated in 3200.0.0 would it be possible to get sambda updated so sssd can be cross-compiled too so https://github.com/flatcar-linux/Flatcar/issues/690 can be fixed?

I'm working on samba update among some other things here - https://github.com/flatcar-linux/coreos-overlay/pull/1819.

Perhaps you could contribute a PR to remove the amd64 condition from here: https://github.com/flatcar-linux/coreos-overlay/blob/main/coreos-base/coreos/coreos-0.0.1.ebuild#L76-L84 so that those sssd becomes part of arm64 images @mtougeron

I've checked with
BOARD_A=amd64-usr BOARD_B=arm64-usr CHANNEL_A=developer CHANNEL_B=developer MODE_A=/developer/ MODE_B=/developer/ FILE=flatcar_production_image_contents.txt FILESONLY=1 CUTKERNEL=1 ./package-diff  2022.06.13+dev-flatcar-master-5850 2022.06.13+dev-flatcar-master-5850

and when ignoring some harmless differences I see the following files missing:
[…]
-/usr/lib64/security/pam_oslogin_admin.so
-/usr/lib64/security/pam_oslogin_login.so
-/usr/libexec/google_authorized_keys
-/usr/libexec/google_oslogin_nss_cache
-/usr/share/google-oslogin/[…]
-/usr/lib/firmware/isci/isci_firmware.bin
-/usr/lib/firmware/mellanox/mlxsw_spectrum-13.2008.2406.mfa2
-/usr/lib/firmware/mellanox/mlxsw_spectrum2-29.2008.2406.mfa2
-/usr/lib/firmware/mellanox/mlxsw_spectrum3-30.2008.2406.mfa2
[…]

and of course the kernel configs are a bit different which results in different modules being available in /usr/lib/modules/a.b.c-flatcar/kernel/drivers/.
I think the oslogin parts are only relevant for GCE which doesn't have an arm64 image at the moment, so ok to ignore, but the firmware and kernel configs for the drivers like mlx* could be something to look into.


/admin/users/<user_id> admin role?

Improve documentation
Link
https://github.com/supabase/gotrue#post-put-adminusersuser_id
Describe the problem
In the code sample the comment says // admin role required
Describe the improvement
The endpoint cannot be called with a user that has the role set to "admin".
It works when the user has assigned the role "service_role" with the anon_key
Is this problematic to assign a user the role "service_role" so he can set the app_metadata of other users?
I want to move the role management of my application to the app_metadata json

Hey,
Thanks for the query! The service role is needed to execute /admin functions and correspondingly any supabase.auth.admin  bindings in the supabase-js library. I've amended the README to reflect this.
Role wise,  our recommendation is to not expose the service key (which grants the service role) in the browser. An options which might be worth considering are to expose a server side route which calls the admin route and sets the metadata for you
Hope this helps - let me know if there are further queries.
Thanks!

Updated the docs to reflect this


Fix PointerBox storybook

Closes #https://github.com/primer/react/issues/4228
This PR gets rid of storybook error that prevented this particular story from rendering in both docs and storybook

Yes, i think its no longer required in storybooks


Fixing long time gap imputation #622

Fixes #622:
The issue was that time gaps calculated for the remainder of the previous data chunk stored in object S were ignored.
I have tested this by creating a dummy file, which I created with:
now = as.numeric(as.POSIXlt("2022-09-09 16:30:00", tz = "Europe/Amsterdam"))
time = seq(now, (now + (48*3600)) , by = 1/10)
x = y = z = rnorm(n = length(time), mean = 0, sd = 0.5)
A = data.frame(time = time, x = x, y = y, z = z)
A = A[-c(500001:600000),] # remove chunk of data to simulate time gap
write.csv(x = A, file = "~/testfile/test.csv", row.names = FALSE)

EDIT: Just tested that it also works with another time gap on the second day:
A = A[-c(500001:600000),] # gap on first day
A = A[-c(1080001:1280000),] # gap on second day

Next, I processed it with GGIR:
datadir = "~/testfile"
outputdir = "~/testresults"
GGIR(datadir = datadir,
     rmc.firstrow.acc = 1,
     rmc.col.acc = 2:4, rmc.col.time = 1,
     rmc.unit.time = "UNIXsec",
     imputeTimegaps = TRUE,
     rmc.sf = 10,
     idloc = 2,
     do.cal = FALSE,
     outputdir = outputdir,
     overwrite = TRUE,
     mode = 1,
     do.report = NULL,
     visualreport = TRUE,
     printsummary = TRUE)

The dimensions of M$metalong and M$metashort match the 24 hours you would expected from the original data before the timegap was created.
Note: If the dummy recording starts a few minutes before a round clock time then GGIR will (as it has always done) ignores the start of the recording until the first round clock time (integer numbers of long epoch size).
@jhmigueles do you have a .csv + .gt3x combi to again check that results are comparable between both formats?

Checklist before merging:

[ ] Existing tests still work (check by running the test suite, e.g. from RStudio).
[ ] Added tests (if you added functionality) or fixed existing test (if you fixed a bug).
[ ] Updated or expanded the documentation.
[ ] Updated release notes in inst/NEWS.Rd with a user-readable summary. Please, include references to relevant issues or PR discussions.
[ ] Added your name to the contributors lists in the DESCRIPTION and CITATION.cff files.

Additionally: It would be good to confirm again that .gt3x and converted .csv from the same recording identical GGIR output.

Hi @vincentvanhees, just run gt3x and csv files from the same recording and got different results. I've just done part 1 with do.cal = FALSE and compared M$metashort and M$metalong.
Consider that the csv is already imputed in actilife because it automatically gets exported with the zeroes imputed from the software.
Recording durations

Timestamp
CSV
GT3X

First
2018-11-19T00:15:00+0100
2018-11-19T00:15:00+0100

Last
2018-12-07T12:14:55+0100
2018-11-24T01:59:55+0100

The recording duration is much shorter than it should be when imputing the gt3x file.
Angle z comparison
Just run this to check where the inconsistencies are. It seems that the long timegaps that can be seen in the csv files (black line) are not there when processing the gt3x file (red line).

Thanks Jairo for checking this. I have now rewritten the code, including a lot of bug fixes in my earlier work (sorry about that). I think it now works. See new result based on your test files below:

Codecov Report

Merging #641 (f0dc847) into master (ed1cd87) will decrease coverage by 0.03%.
The diff coverage is 19.51%.

@@            Coverage Diff             @@
##           master     #641      +/-   ##
==========================================
- Coverage   71.13%   71.10%   -0.04%
==========================================
  Files          87       87
  Lines       10622    10630       +8
==========================================
+ Hits         7556     7558       +2
- Misses       3066     3072       +6

Impacted Files
Coverage Δ

R/g.imputeTimegaps.R
63.91% <ø> (ø)

R/g.getmeta.R
63.38% <19.51%> (-0.52%)
:arrow_down:

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

Thanks @vincentvanhees! It looks great now. There is one minor thing we still should fix here I think. In this specific file, the start time is 00:01:00, and the first timegap occurs 10 seconds after that and has a duration of almost 5 hours. In g.getmeta, GGIR removes the data before the first long epoch (e.g., 00:15:00). When doing so, g.getmeta will skip this timegaps as it is not imputed yet, and there is a time mismatch at the begining of the files.
So I would try to always impute all data until the GGIR-defined start time within g.imputeTimegaps, do you agree? I can look into this probably tomorrow if you don't have the time for it.

Just drafted some code and it seems to work, but I can't test it more now, will do later or tomorrow.

It seems that metalong does not get imputed correctly. We get several days less of data and different nonwear values. I'm working on this now.

I just found the issue for the non-wear:
metnames %in%  "nonwearscore"
needs to be:
"nonwearscore" %in% metnames)

We get several days less of data and different nonwear values

Yes, I see: metashort is only 11 epoch shorts, but metalong is indeed substantially shorter
Ok, I will not commit anything and first post here if I see the cause of the problem. In case you are planning to make major changes then maybe good to start a new branch for that.

I am on it, I think I can get this in ~30 min. When we fill up the epoch in g.imputeTimegaps, I think we should use there the longEpochSize instead of the short. This way the data imputation at epoch level will never be affected because the data is in the middle of a long epoch. Give me today to try to fix this, if I get into major problems then we make a new issue/branch.

Thanks, I will log off for today.

Seems that it works well now =)
Black line is the data processed from csv, the red line above is the data from the gt3x file.

Looks good, I can confirm that it also works here. All edits are logical.
Are we ready to merge this PR?
How about following merging order:
Today (I can work on this this morning):

Merge this PR (641 long time gaps)
Update branches
Merge PR 640 (Speeding up ...)
Update branches
Merge PR 633 (Issue628 prepare cran 2.8-0)
Prepare master branch for 2.7-7 GitHub only release.
Update branches

Wednesday afternoon:

Make new 2.7-7 GitHub-only release

Later this week or next week when you are ready:

Merge PR 630 (Documentation branch)
Prepare CRAN 2.8-0 release

Sounds good! I'm working on the documentation branch applying your feedback in the morning, if it gets ready in time we can add it already to the merging list.

Ok, so then I will not update the documentation branch in between de PR merges and leave that up to you.


bhighley bio - add

This pull request adds a bio for me

@Hutchasmuch - test

Looks Good
@bhighley


Fix cargo-bisect-rustc issues during CI.

Works around https://github.com/rust-lang/cargo-bisect-rustc/issues/186.

This change will always be valid, since we can always invoke a cargo custom subcommand via cargo-*. Since our CI is currently broken until this is fixed, we can revert it if the upstream issue is fixed.
bors try --target aarch64-unknown-linux-gnu

Bisect now passes.
bors r=Emilgardis


prog: detect pointer <-> non-pointer argument type change

As reported in https://github.com/google/syzkaller/issues/62#issuecomment-243740390
If you change argument types in some particular ways, old programs won't be detected during loading, but later lead to panics. Need to detect these cases better.

I think this can be merged into #217


Convert hop-node to hop-node-core, v1-hop-node, and v2-hop-node

As discussed.

Closed with https://github.com/hop-protocol/hop/pull/613


fix error with s/measureBounds/measureBoundingBox

@ahdinosaur sorry. i merged some changes before seeing this pull request. there are conflicts.
there are two choices:

fix the conflicts (@ahdinosaur )
push on with master, which also works with recent V2

i think the second choice is the easiest. thoughts?


Custom components

I´ve done the BLE configuration in ESPHome and now I´ve two sensors (weight and impedance) working in my HA. I also installed your custom component and configurated the file bodymiscale.yaml. However the sensors created at bodmiyscale.yaml doesn´t show me any information about weight and impedance.
Should these sensors been vinculated to ESPHome sensors somehow?? In afirmative case, what should I do to get it?
Thanks

yes you must put your sensor. (weight) and sensor. (impedance)

I don´t know what do you mean.
This is my configuration for the BLE tracker in ESPHOME:

platform: xiaomi_miscale2
mac_address: 'XX:XX:XX:XX:XX:XX'
weight:
name: "Xiaomi Mi Scale Weight"
id: weight_miscale
impedance:
name: "Xiaomi Mi Scale Impedance"
id: impedance_xiaomi

platform: template
name: Peso Wafa
id: weight_wafa
unit_of_measurement: 'kg'
icon: mdi:weight-kilogram
accuracy_decimals: 2

Then, what must be the configuration for the bodymiscale.yaml??

https://github.com/dckiller51/bodymiscale#example

Closing due inactivity


[Relay][Strategy] Fix arm_cpu int8 conv2d schedule selection for 32-bit targets

https://github.com/apache/tvm/pull/12455 slightly altered the behaviour when selecting an int8 conv2d schedule. Previously conditions that decide which schedule to select used is_aarch64 which checks for the existance of aarch64 in the target triple. However, the conditions now use has_asimd which is true if aarch64 exists in the target triple OR +neon is used in the mattr.
Both conv2d_NHWC_quantized_interleaved.arm_cpu and depthwise_conv2d_nhwc.arm_cpu makes calls to LLVM intrinsics that require both aarch64 and +neon. But in the case of the target rasp4b, the updated conditions result in compilation failure since the target has +neon but doesn't have aarch64 in the target triple. The conditions have been updated to fix the compilation failure.
Likewise, the previous behaviour of the condition for conv2d_nhwc_spatial_pack.arm_cpu has been restored ensure a program with a 32-bit target can still be compiled.
Finally, we should only select the depthwise_conv2d_nhwc_dsp.arm_cpu schedule when a backend that understands pragma_import_c has been selected, i.e. "c".
For a more detailed discussion of the issue please see: https://discuss.tvm.apache.org/t/tflite-llvm-llvm-error-when-compiling-tflite-model/15411
cc @Mousius @ashutosh-arm @ekalda @neildhickey

Thanks @lhutton1!


Application to submit Simplified Chinese language pack

Improve the translation of Simplified Chinese language pack.
zh_CN.zip

You can do a PR with your improvements.


BasicFormat outputs incomplete indentation when formatting multiline string literals containing blank lines

Description
The following code is formatted using BasicFormat (spaces are replaced with ␣ for clarity),
assertionFailure("""
␣␣First␣line

␣␣Second␣line

␣␣""")

It produces the following code
assertionFailure("""
␣␣First␣line
␣␣␣␣
␣␣Second␣line
␣␣␣␣
␣␣␣␣␣␣""")

This is an incorrectly indented literal closing quote.
This causes a compilation error Insufficient indentation of line in multi-line string literal.
This problem can easily occur if both the "Automatically trim trailing whitespace" and "Including whitespace-only lines" settings in Xcode are enabled.
Also, macros now automatically format the code they generate by default, which can easily cause problems if the above settings are enabled.
For example, passing the following string to the #stringify macro created by the Swift Macro Project template will result in a compilation error due to the same issue.
#stringify(
␣␣"""
␣␣First line

␣␣Second line

␣␣"""
)

^ The above macro will generate the following code, which will result in a compiation error
(
␣␣"""
␣␣First␣line
␣␣
␣␣Second␣line
␣␣
␣␣␣␣""",␣#"\#n␣␣"""\#n␣␣First␣line\#n\#n␣␣Second␣line\#n\#n␣␣""""#)

Steps to Reproduce
To reproduce this problem, run the following code
let source = #"""
  assertionFailure("""
    First line

    Second line

    """)
  """#
print(Parser.parse(source: source).formatted().description)

The result of the execution will be as follows This code results in a compilation error "Insufficient indentation of line in multi-line string literal".
assertionFailure("""
  First line

  Second line

      """)

Tracked in Apple’s issue tracker as rdar://113021776


Not able to get the files copied inside Dockerfile

While building the image the build is failing due to unavailibility of several files like proto, benchmark, Makefile-flash-att-v2 Makefile, Makefile-eetq Makefile etc on the repo. Please kindly let me know if there is a url or a repo which I can refer to get the files copied inside Dockerfile ..
Also if there is an alternative solution to resolve this issue please let me know.
The error i am getting is " COPY failed : file not found in build context or excluded by .dockerignore: stat proto: file does not exist"

I think you will need to copy the huggingface folder into your copy of text-generation-interface and build from there.
It builds now, but I can't find the missing recipe.json anywhere:
~/source/text-generation-inference tags/v1.4.0* 31s
base ❯ docker build -f huggingface/pytorch/tgi/docker/1.4.0/Dockerfile .
[+] Building 1.3s (24/78)                                                                                docker:orbstack
 => [internal] load build definition from Dockerfile                                                                      0.0s
 => => transferring dockerfile: 8.98kB                                                                                0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:12.1.0-base-ubuntu20.04                                            1.0s
 => [internal] load metadata for docker.io/lukemathwalker/cargo-chef:latest-rust-1.71                                     0.9s
 => [internal] load metadata for docker.io/nvidia/cuda:12.1.0-devel-ubuntu20.04                                           1.0s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 94B                                                                                0.0s
 => [base  1/23] FROM docker.io/nvidia/cuda:12.1.0-base-ubuntu20.04@sha256:191e7e562d485c2adaf6fecab0a65af69d31d1858f97b  0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 12.93kB                                                                                0.0s
 => [pytorch-install 1/5] FROM docker.io/nvidia/cuda:12.1.0-devel-ubuntu20.04@sha256:0678daf5d9f3800c714df6c3983d3106515  0.0s
 => [chef 1/2] FROM docker.io/lukemathwalker/cargo-chef:latest-rust-1.71@sha256:1d0c049f0f6007531a1fca3f3d81ee571fc46135  0.0s
 => CACHED [base  2/23] WORKDIR /usr/src                                                                                0.0s
 => CACHED [base  3/23] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends   0.0s
 => CACHED [pytorch-install 2/5] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-re  0.0s
 => CACHED [pytorch-install 3/5] RUN case linux/arm64 in     "linux/arm64")  MAMBA_ARCH=aarch64  ;;     *)                0.0s
 => CACHED [pytorch-install 4/5] RUN chmod +x ~/mambaforge.sh &&     bash ~/mambaforge.sh -b -p /opt/conda &&     rm ~/m  0.0s
 => ERROR [pytorch-install 5/5] RUN case linux/arm64 in     "linux/arm64")  exit 1 ;;     *)              /opt/conda/bin  0.1s
 => CACHED [chef 2/2] WORKDIR /usr/src                                                                                0.0s
 => CACHED [planner 1/8] COPY Cargo.toml Cargo.toml                                                                       0.0s
 => CACHED [planner 2/8] COPY Cargo.lock Cargo.lock                                                                       0.0s
 => CACHED [planner 3/8] COPY rust-toolchain.toml rust-toolchain.toml                                                     0.0s
 => CACHED [planner 4/8] COPY proto proto                                                                                0.0s
 => CACHED [planner 5/8] COPY benchmark benchmark                                                                         0.0s
 => CACHED [planner 6/8] COPY router router                                                                               0.0s
 => CACHED [planner 7/8] COPY launcher launcher                                                                           0.0s
 => CANCELED [planner 8/8] RUN cargo chef prepare --recipe-path recipe.json                                               0.2s
------
 > [pytorch-install 5/5] RUN case linux/arm64 in     "linux/arm64")  exit 1 ;;     *)              /opt/conda/bin/conda update -y conda &&      /opt/conda/bin/conda install -c "pytorch" -c "nvidia" -y "python=3.10" "pytorch=2.1.1" "pytorch-cuda=$(echo 12.1 | cut -d'.' -f 1-2)"  ;;     esac &&     /opt/conda/bin/conda clean -ya:
------
Dockerfile:78
--------------------
  77 |     # On arm64 we exit with an error code
  78 | >>> RUN case ${TARGETPLATFORM} in \
  79 | >>>     "linux/arm64")  exit 1 ;; \
  80 | >>>     *)              /opt/conda/bin/conda update -y conda &&  \
  81 | >>>     /opt/conda/bin/conda install -c "${INSTALL_CHANNEL}" -c "${CUDA_CHANNEL}" -y "python=${PYTHON_VERSION}" "pytorch=$PYTORCH_VERSION" "pytorch-cuda=$(echo $CUDA_VERSION | cut -d'.' -f 1-2)"  ;; \
  82 | >>>     esac && \
  83 | >>>     /opt/conda/bin/conda clean -ya
  84 |
--------------------
ERROR: failed to solve: process "/bin/sh -c case ${TARGETPLATFORM} in     \"linux/arm64\")  exit 1 ;;     *)              /opt/conda/bin/conda update -y conda &&      /opt/conda/bin/conda install -c \"${INSTALL_CHANNEL}\" -c \"${CUDA_CHANNEL}\" -y \"python=${PYTHON_VERSION}\" \"pytorch=$PYTORCH_VERSION\" \"pytorch-cuda=$(echo $CUDA_VERSION | cut -d'.' -f 1-2)\"  ;;     esac &&     /opt/conda/bin/conda clean -ya" did not complete successfully: exit code: 1

Hi ,
Alright I will proceed with the method you suggested.
Thank you .
On Fri, Feb 23, 2024, 5:44 AM Feng Ye @.***> wrote:

I think you will need to copy the huggingface folder into your copy of
text-generation-interface and build from there.
It builds now, but I can't find the missing recipe.json anywhere:
~/source/text-generation-inference tags/v1.4.0* 31s
base ❯ docker build -f huggingface/pytorch/tgi/docker/1.4.0/Dockerfile .
[+] Building 1.3s (24/78)                                                                                docker:orbstack
=> [internal] load build definition from Dockerfile                                                                      0.0s
=> => transferring dockerfile: 8.98kB                                                                                0.0s
=> [internal] load metadata for docker.io/nvidia/cuda:12.1.0-base-ubuntu20.04                                            1.0s
=> [internal] load metadata for docker.io/lukemathwalker/cargo-chef:latest-rust-1.71                                     0.9s
=> [internal] load metadata for docker.io/nvidia/cuda:12.1.0-devel-ubuntu20.04                                           1.0s
=> [internal] load .dockerignore                                                                                0.0s
=> => transferring context: 94B                                                                                0.0s
=> [base  1/23] FROM @.:191e7e562d485c2adaf6fecab0a65af69d31d1858f97b  0.0s
=> [internal] load build context                                                                                0.0s
=> => transferring context: 12.93kB                                                                                0.0s
=> [pytorch-install 1/5] FROM @.:0678daf5d9f3800c714df6c3983d3106515  0.0s
=> [chef 1/2] FROM @.***:1d0c049f0f6007531a1fca3f3d81ee571fc46135  0.0s
=> CACHED [base  2/23] WORKDIR /usr/src                                                                                0.0s
=> CACHED [base  3/23] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends   0.0s
=> CACHED [pytorch-install 2/5] RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-re  0.0s
=> CACHED [pytorch-install 3/5] RUN case linux/arm64 in     "linux/arm64")  MAMBA_ARCH=aarch64  ;;     *)                0.0s
=> CACHED [pytorch-install 4/5] RUN chmod +x ~/mambaforge.sh &&     bash ~/mambaforge.sh -b -p /opt/conda &&     rm ~/m  0.0s
=> ERROR [pytorch-install 5/5] RUN case linux/arm64 in     "linux/arm64")  exit 1 ;;     *)              /opt/conda/bin  0.1s
=> CACHED [chef 2/2] WORKDIR /usr/src                                                                                0.0s
=> CACHED [planner 1/8] COPY Cargo.toml Cargo.toml                                                                       0.0s
=> CACHED [planner 2/8] COPY Cargo.lock Cargo.lock                                                                       0.0s
=> CACHED [planner 3/8] COPY rust-toolchain.toml rust-toolchain.toml                                                     0.0s
=> CACHED [planner 4/8] COPY proto proto                                                                                0.0s
=> CACHED [planner 5/8] COPY benchmark benchmark                                                                         0.0s
=> CACHED [planner 6/8] COPY router router                                                                               0.0s
=> CACHED [planner 7/8] COPY launcher launcher                                                                           0.0s
=> CANCELED [planner 8/8] RUN cargo chef prepare --recipe-path recipe.json                                               0.2s

[pytorch-install 5/5] RUN case linux/arm64 in     "linux/arm64")  exit 1 ;;     *)              /opt/conda/bin/conda update -y conda &&      /opt/conda/bin/conda install -c "pytorch" -c "nvidia" -y "python=3.10" "pytorch=2.1.1" "pytorch-cuda=$(echo 12.1 | cut -d'.' -f 1-2)"  ;;     esac &&     /opt/conda/bin/conda clean -ya:

Dockerfile:78
77 |     # On arm64 we exit with an error code
78 | >>> RUN case ${TARGETPLATFORM} in
79 | >>>     "linux/arm64")  exit 1 ;;
80 | >>>     *)              /opt/conda/bin/conda update -y conda &&
81 | >>>     /opt/conda/bin/conda install -c "${INSTALL_CHANNEL}" -c "${CUDA_CHANNEL}" -y "python=${PYTHON_VERSION}" "pytorch=$PYTORCH_VERSION" "pytorch-cuda=$(echo $CUDA_VERSION | cut -d'.' -f 1-2)"  ;;
82 | >>>     esac &&
83 | >>>     /opt/conda/bin/conda clean -ya

84

ERROR: failed to solve: process "/bin/sh -c case ${TARGETPLATFORM} in     "linux/arm64")  exit 1 ;;     *)              /opt/conda/bin/conda update -y conda &&      /opt/conda/bin/conda install -c "${INSTALL_CHANNEL}" -c "${CUDA_CHANNEL}" -y "python=${PYTHON_VERSION}" "pytorch=$PYTORCH_VERSION" "pytorch-cuda=$(echo $CUDA_VERSION

—
Reply to this email directly, view it on GitHub
https://github.com/awslabs/llm-hosting-container/issues/56#issuecomment-1960549725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXMT75JUNTS3P4EWK6AQOXTYU7NOVAVCNFSM6AAAAABC6CD7HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRQGU2DSNZSGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

Also, I think the Dockerfile is almost a direct copy from https://github.com/huggingface/text-generation-inference/blob/main/Dockerfile

Thanks, I'll check it out.
On Sat, Feb 24, 2024 at 6:03 AM Feng Ye @.***> wrote:

Also, I think the Dockerfile is almost a direct copy from
https://github.com/huggingface/text-generation-inference/blob/main/Dockerfile
—
Reply to this email directly, view it on GitHub
https://github.com/awslabs/llm-hosting-container/issues/56#issuecomment-1962176792,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXMT75PVOYXWZQQ66E5MCCDYVEYPDAVCNFSM6AAAAABC6CD7HKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRSGE3TMNZZGI
.
You are receiving this because you authored the thread.Message ID:
@.***>


I can't find a way to get the prompt again after click "do not disturb"

Version: 1.66.2 (user setup)
Commit: dfd34e8260c270da74b5c2d86d61aee4b6d56977
Date: 2022-04-11T07:46:01.075Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22000
I uninstall autopep8 and then format my python file.
Vscode gives me a question like this:
Formatter autopep8 is not installed? Install?
Yes|Use black|Use yapf|Do not disturb
I'm so sorry that I don't have a screenshot.
After choosing the last one, I can't find any way to get this prompt again, though I looked all over settings and setting.json.
Expect:
I want to get this prompt again

I found it is saved in the .db file. Is there any way to change this in vscode?