[New Mock] - Reviews

Add more real worded reviews for  a series of fake products. eg. A Gaming Sports drink, a new dvd player etc. (The more we do the merrier)
Add fake worded reviews for a fake product using faker.lorem.sentence the same way we do in getRandomChat

Added two new endpoints in version 0.10.0
I have currently only added 5 fake reviews for a gaming sports drink. Need to make a few more categories and products so there is more options avaliable.

I can take up this issue. How many products and its reviews do you need tho?

Hi @Vishwak-Kiran . As with our other endpoints we can allow the user to define the qty.  Please see chat api endpoints as example.
Please branch from v.0.12.0

Hi @ageddesi, I'd like to contribute to this.

Hi @janetthieu it's all yours. :)

Hi @ageddesi , do you need more contributions to this for Hacktoberfest?

I'm still very much a rookie at this but I used to teach English so I can come up with a bunch of nonsense if you have something to assign to me @ageddesi !

That sounds awesome. Feel free to take a crack at this ticket. :) the more
fun and real they sound the better as atm they will be random Latin
strings. :(
On Tue, 11 Oct 2022, 22:45 Lindsay Shelton, @.***>
wrote:

I'm still very much a rookie at this but I used to teach English so I can
come up with a bunch of nonsense if you have something to assign to me
@ageddesi https://github.com/ageddesi !
—
Reply to this email directly, view it on GitHub
https://github.com/ageddesi/Mocked-API/issues/18#issuecomment-1275308403,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ5YPHY55PF6TFWZDF2JE3WCXNX5ANCNFSM57OZRPDA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Well, I also took 2 years of Latin in high school ;)

Haha, well your fully setup for this kind of work then lol.
On Tue, 11 Oct 2022, 22:47 Lindsay Shelton, @.***>
wrote:

Well, I also took 2 years of Latin in high school ;)
—
Reply to this email directly, view it on GitHub
https://github.com/ageddesi/Mocked-API/issues/18#issuecomment-1275310285,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ5YPBFG7BCDAYIOZEEVBDWCXOAZANCNFSM57OZRPDA
.

I am looking to expand to a variety of products and fake reviews. The more
the merrier, so will be keeping this ticket open for a long time I imagine.
On Tue, 11 Oct 2022, 22:52 Lindsay Shelton, @.***>
wrote:

Are you looking for more fake reviews on the one product, or more products
with their own fake reviews/categories/etc?
—
Reply to this email directly, view it on GitHub
https://github.com/ageddesi/Mocked-API/issues/18#issuecomment-1275314126,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ5YPAHTFRIMKUZNFQO3OLWCXOQLANCNFSM57OZRPDA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello !
I'm new to hacktoberfest and should be able to help with this too.
Just to clarify, we need to add more reviews to this file modules/products/data/product-reviews.ts ?
Does the language matter?
Thanks !

Welcome @, yes more are welcome. We do jot have other languages yet. But want to open that up soon.

Great, I will share a few in English then.
Awesome project, btw!

Hi there @ageddesi ,
Another newby looking to help out! I see you're looking for new products, with fake reviews, added to this file: modules/products/data/product-reviews.ts . Anything else to mention?
Thanks!

Yerp feel free to add more. Either same products or new.

Add more real worded reviews for  a series of fake products. eg. A Gaming Sports drink, a new dvd player etc. (The more we do the merrier)
Add fake worded reviews for a fake product using faker.lorem.sentence the same way we do in getRandomChat


Public named functions/parsers

I guess re-exporting would be an alternative to adding a public export option to named parsers. What do you think of adding something like named!(pub foo<&u8>, ...)?

I see, rust-lang/rust#17436 is now closed and macros can contain pub. This is definitely a good idea. I may not have much time to add it this week, could you try a PR?

Now, you can add the pub keyword. It works with the 3 syntaxes:

named!(pub tst, tag!("abcd"));
named!(pub tst<&[u8],&[u8]> , tag!("abcd"));
named!(pub tst(input: &[u8]) -> IResult<&[u8], &[u8]>, tag!("abcd"));

@Geal Thanks a ton!


add canvas binary build step to happo

Fix https://github.com/transcom/mymove/actions/runs/12205276489/job/34052242369?pr=14232

Copying Dre's https://github.com/transcom/mymove/pull/14296/commits/6186ff8d7a7e3c45fbabefae38e979b2b512229f to trigger happo step

Fixed it, reverting dummy commit
https://github.com/transcom/mymove/actions/runs/12206029967/job/34054649194?pr=14343


[Bug?]: Cannot read properties of undefined (reading 'devServer') when building

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Cannot read properties of undefined (reading 'devServer') (full error message: https://discord.com/channels/722131463138705510/910635844119982080/1196842080144736306)
Expected behavior 🤔
Builds without errors
Steps to reproduce 🕹
Steps:

Check out this branch https://github.com/danieltroger/vinxi-repro/tree/dt/patched
yarn
yarn build

Context 🔦
No response
Your environment 🌎
No response

Also when setting ssr: false no index.html is emitted, probably due to this issue?

I followed a bit of the conversation in Discord but it seems that part of the issue was fixed in 1.4? And that this is related to which package manager you use? Just hoping the consolidate the state of things here because tracking through discord is a bit of a mess.

but it seems that part of the issue was fixed in 1.4?

No, not this exact issue, the reproduction link above runs 1.4

And that this is related to which package manager you use?

Yeah for some reason this only happens when using yarn berry.

Just hoping the consolidate the state of things here because tracking through discord is a bit of a mess.

Makes sense, that's why I opened an issue here too, for better tracking.
The last status was that I gave @nksaraf some pointers on how to dig into what's happening here (since I'm not sure they know all the tricks of debugging packages in yarn berry) and confirmed it only happens on yarn berry.

So this is another Yarn Berry related issue. I just want to keep this clean. Can we close as a duplicate of #1177?


Rule AA0232 for Enums

Describe the bug
The rule AA0232

The FlowField "My Enum" of "My New Table" should be added to the SIFT key.

is raised on Enum fields although they cannot be created as SIFT key.
To Reproduce
Enable the CodeCop in the settings.json
"al.enableCodeAnalysis": true,
"al.backgroundCodeAnalysis": true,
"al.codeAnalyzers": ["${CodeCop}"]

New Enum
enum 50100 "My Enum"
{
    value(0; Open)  { Caption = 'Open'; }
    value(1; Closed) { Caption = 'Closed'; }
}

New Table 1
table 50101 "My Table 1"
{
    Caption = 'My New Table';
    DataClassification = ToBeClassified;

    fields
    {
        field(1; "My PK"; Integer)
        {
            Caption = '';
            DataClassification = CustomerContent;
        }
        field(2; "My Enum"; Enum "My Enum")
        {
            Caption = 'My Enum';
            DataClassification = CustomerContent;
        }
    }
    keys
    {
        key(PK; "My PK")
        {
            Clustered = true;
        }
        key(MyEnum; "My Enum") { }
    }
}

New Table 2 with AA0232
table 50102 "My Table 2"
{
    Caption = 'My Table 2';
    DataClassification = ToBeClassified;

    fields
    {
        field(1; "My PK"; Integer)
        {
            Caption = 'My PK';
            DataClassification = CustomerContent;
        }
        field(2; "FlowField on Enum"; Enum "My Enum") // AA0232
        {
            Caption = 'FlowField on Enum';
            CalcFormula = min("My Table 1"."My Enum");
            Editable = false;
            FieldClass = FlowField;
        }
    }
    keys
    {
        key(PK; "My PK")
        {
            Clustered = true;
        }
    }
}

You cannot add the Enum field as SumIndexField in table 1:
 key(PK; "My PK")
        {
            Clustered = true;
            SumIndexFields = "My Enum" // AL0199
        }

This would raise AL0199:

The type of the sum index field '"My Enum"' must be numeric(Decimal, BigInteger, Integer, or Duration)

which is weird since Enums are numeric.
Expected behavior
Either the warning AA0232  not appear, or it must be possible to use Enums as SumIndexFields.
Versions:

AL Language: 6.1.362735

When do you think this might get corrected?

@PaulIvan can you provide an ETA?

Still no update :-(

Hi @NKarolak I agree this looks a bit weird but just because something is possible doesn't mean it should be used.
I'm just a bit confused as to why a lookup flowfield wouldn't be better in this case?

I guess the example code is deliberately oversimplified, to the point of being nonsensical in practice, but it demonstrates the issue in theory.
That said, it seems brittle to rely on the numeric values of enums or options, and I never like it when I find code that does that.
Did this work with options? If not, I guess it was never intended to work.

@dtkb
In reality, my enum flow field is a "Print Status" (1 = Open; ... 10 = Error; 20 = Printed) on a header record. It returns the minimum Print Status value from all related line records. Hence: only if all lines are printed (without errors), then the header record is displayed as printed.

@PaulIvan Can you give an ETA?

@qutreson push ;-)

Thanks for reporting this issue. Sorry we haven’t completed it yet, but we’ve had to prioritize elsewhere. We’re planning to give the CodeCop engine and its rules an overhaul in a future major release. Thanks for your patience.
Going forward we will not track progress on CodeCop issues here on GitHub. Hence, we are closing this issue.


Update application to Rails 7

Update all dependencies in advance of Rails update
Update Rails to 7.0.1
Run rails app:update and integrate meaningful config changes
Generate and run ActiveStorage migrations
Update Spring to 4.0 (and temporarily disable spring-watcher-listen
due to incompatibility)
Disable config.cache_classes in test environment (should no longer
be enabled when using Spring)
Set test values for ActiveRecord encryption in test environment
Fix deprecated use of to_s on Date/Time/TimeWithZone
Fix use of renamed ActionMailer::DeliveryJob

Closing as rspec-rails is not ready yet and we're hitting a few edge cases with niche Rails 7 deprecations (and might not be for a while).
Will create a new PR sorting out the bulk of the deprecations so we're ready to hit the ground running when everything falls into place.


Template Ref watcher not triggered in Vue 2.7

Version
2.7.0-beta.4
Reproduction link
codesandbox.io
Steps to reproduce
Open the CodeSandbox and watch the console output.
What is expected?
There should be a log entry.
What is actually happening?
There's no log entry because the watcher is not triggered.

This works in Vue 2.6 (with Composition API plugin) and Vue 3:
https://codesandbox.io/s/vue-2-6-14-template-ref-watcher-working-example-3fec25?file=/src/App.vue
https://codesandbox.io/s/vue-3-2-33-template-ref-watcher-working-example-nd1imp?file=/src/App.vue

Hmm this still isn't resolved in 2.7.7...

My CodeSandbox reproduction works with v2.7.7: https://codesandbox.io/s/vue-2-7-template-ref-watcher-issue-be6ghd

Unfortunately not with an array of template refs:
https://github.com/vuejs/vue/issues/12675

bind the inputRef to the input element then add .value in watch. In my case:
watch( () => inputRef.value, () => { // } )


Long legend makes scatter plot unviewable

To reproduce:

Launch Resonant Laboratory and open a new project.
Add the cars.json data set.
Add a scatter plot.
Place Acceleration on the x-axis and Miles_per_Gallon on the y-axis.
Observe the well proportioned chart.
Place Name on the Color field.
Observe the unviewable chart and the spatially overwhelming color legend.

I assume this problem afflicts other charts as well and I'm not quite sure what to do to fix it. I am also not sure whether this is a Vega bug or a Candela bug, but I lean towards thinking it's our responsibility to handle long legends etc. in our chart instantiations.

We currently always display a legend if the color field is populated. We could do a few things:

Provide an option for showing the legend.
Add logic that will disable the legend if it would be unwieldy.
Change the Vega spec to truncate long names and limit the number of items displayed.
Open a Vega issue to change default legend behavior.

I'm thinking it would be best to at least do 1 and 3.


Do not disable mailbox blocks

Fix #1306

Download:
Environment: QT=5.12, ARCH=32, CONFIGURATION=release, QTIFW=C:\Qt\Tools\QtInstallerFramework\3.1

Download:
Environment: QT=5.12, ARCH=32, CONFIGURATION=release, QTIFW=C:\Qt\Tools\QtInstallerFramework\3.1


ufw setup fails on raspbian Jessie

[X] I have read and understood the contributors guide.
[X] The issue I am reporting can be replicated.
[X] The issue I am reporting can be is directly related to the pivpn installer script.
[X] The issue I am reporting isn't a duplicate (see FAQs, closed issues, and open issues).

debug output:
net.ipv4.ip_forward = 1
::: Detected UFW is enabled.
::: Adding UFW rules...
ERROR: Invalid syntax
::: UFW configuration completed.
dig failed, now trying to curl checkip.amazonaws.com
::: Using Google servers.
sleep 0.1
::: Install Complete...
::: Restarting services...
Synchronizing state for openvpn.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d openvpn defaults
Executing /usr/sbin/update-rc.d openvpn enable
::: Flushing writes to disk...
::: done.

It looks like the route command doesn't exist on the version of ufw packaged in Jessie: https://manpages.debian.org/jessie/ufw/ufw.8.en.html
Upgrading to raspbian Stretch fixed it: https://manpages.debian.org/stretch/ufw/ufw.8.en.html
Maybe the installer needs a min-ufw-version check?

Are you able to pinpoint the exact version that started supporting the route command?

fix pushed into test branch.

Thanks for the fix! It looked like every version in the Jessie repo is pre-route support. I didn't bother trying to install a later .deb version and just upgraded my base raspbian install to Stretch (which also gave me modern versions of a bunch of other packages)

@edalquist @orazioedoardo
Test branch Merged into Master.
closing


ModuleNotFoundError: No module named 'pdftotext' even when installed

I have installed pdftotext as seen here when typing the command
GlossikaNativeGLS$ pdftotext
pdftotext version 0.74.0
Copyright 2005-2019 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC
Usage: pdftotext [options]  []
But when I do this your script doesn't find the module:
GlossikaNativeGLS$ python3 ./split_text.py
Traceback (most recent call last):
File "./split_text.py", line 5, in
import pdftotext
ModuleNotFoundError: No module named 'pdftotext'
How to solve?, many thanks.

Never mind solved it, have to install it using pip3 and not using normal pip

Never mind solved it, have to install it using pip3 and not using normal pip


local rate limit: more robust refill logic

Signed-off-by: Kuat Yessenov<EMAIL_ADDRESS>Commit Message: Change token refill logic for descriptors to take into account the inherent variability in the real world clock.
Additional Description: Descriptors are refilled at multiples of the global refill interval. Because the global timer hits with some uncertainty +/-O(10ms), there is a high likelihood that the recorded clock time at the refill times N and N+1 is less than the interval itself. That means that even when the descriptor fill interval and the global fill interval are the same, the descriptors are not refilled as often. That's very counter-intuitive and results in a very noticeable rate limit under-run (~20% less than desired observed at refill interval 10s).
This change simply uses modular arithmetic to count when to trigger the descriptor refill. This fixes the example shown in https://github.com/envoyproxy/envoy/issues/19474.
Risk Level: low
Testing: tests do not regress
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Fixes: https://github.com/envoyproxy/envoy/issues/19474

https://github.com/envoyproxy/envoy/pull/21361 is the follow-up.


feat: handle high price impact/slippage at confirm step

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #5032   👈

This comment was auto-generated by Graphite.


Add h5netcdf to the engine import hierarchy

h5netcdf is now part of the import statements in the _get_default_engine() function. The order is: netcdf4, scipy.io.netcdf, h5netcdf.

[ ] Closes #xxxx
[ ] Tests added / passed
[ ] Passes git diff upstream/master **/*py | flake8 --diff
[ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

Is it really common to have h5py but not scipy installed?
I guess we could do this, but inspecting the magic number of the files to find an appropriate reader (scipy for netcdf3, h5netcdf for hdf5/netcdf4) feels like it would be more useful.

Closing. Superseded by #1682.


Implement offchain DNS Registrar support

This PR implements a new resolver that can be set as a wildcard resolver for any TLD other than .eth. Once set, it resolves all subdomains that do not exist in the registry by making CCIP-Read calls to a DNS gateway, which returns signed DNS TXT records. It verifies those using the DNSSEC oracle in a call operation, and thus makes it possible to find the resolver for a name without any gas required to set it.
TXT records are expected to be on the name in question, and take the format:
ENS1 <name-or-address> [context]

name-or-address is either an ENS name or the 0x-prefixed address of the resolver to use to resolve this DNS name. If an ENS name is specified, it must be in the ENS registry - eg, it cannot be resolved using wildcard resolution or via CCIP-Read.
The resolver will be queried using ERC165. If it supports the new IExtendedDNSResolver interface, resolve() is called on it, passing the namehash, encoded query, and context. If it supports IExtendedResolver, resolve() is called with namehash and encoded query, but any context data is ignored. If neither is supported, the resolver is called with the encoded query directly.
This makes it possible to use either a regular resolver (for example, the OwnedResolver; PublicResolver will not work here, as it cannot check ownership of offchain names) with records stored onchain, or a DNS-specific resolver that understands how to parse context and use it to resolve the query without any onchain write operations at all. A standardised implementation of this will be forthcoming shortly.

Can you add a deploy script or deploy to tenderly fork so we can test on the real data?

Is context where you set an actual record like addr, contanthash,  text, abi, pubkey, etc?

Can you add a deploy script or deploy to tenderly fork so we can test on the real data?

I'll add a deploy script.

Is context where you set an actual record like addr, contanthash, text, abi, pubkey, etc?

The interpretation of context is up to the resolver contract, but that's the most obvious use for it, yes.

Assuming we have more PR to complete the whole featureset, can you create an integration branch and make PR against the integration branch, rather than merging directly into master?

The code in this PR is useful on its own, and there are an unlimited number of possible resolver implementations that work with it. I don't think there's any point in holding it back.

@makoto PTAL.


[BUG] nvtabular.ops.Categorify: Argument cat_cache is ignored, leading to GPU OOM each time

Hi there,
Describe the bug
Disclaimer: this might also be my misunderstanding of the documentation which I want to clarify
I am using NVTabular for preprocessing the Twitter RecSys Challenge 2021 dataset (https://recsys-twitter.com/). I use Categorify for mapping string hashes for diverse feature columns into proper int64-codes. Here is an example from last years challenge: https://github.com/NVIDIA/NVTabular/blob/main/examples/winning-solution-recsys2020-twitter/01-02-04-Download-Convert-ETL-with-NVTabular-Training-with-XGBoost.ipynb
I am actually running my stuff on a GCP instance (machine type: a2-highgpu-1g) with 12 cores, 85 GB memory and one NVIDIA Tesla A100 with 40GB GPU RAM.
I have already encountered big problems with converting user ids using the Categorify operator when I decided to do it without NVTabular. Now, I am running into the same problem again.
Even though I provide host or device as value for cat_cache during fitting of the Workflow I always run into an OOM of the GPU RAM
MemoryError: std::bad_alloc: CUDA error at: /home/mkurovski/miniconda3/envs/recsys/include/rmm/mr/device/cuda_memory_resource.hpp:69: cudaErrorMemoryAllocation out of memory

Steps/Code to reproduce bug
Since I guess NVIDIA people are also working on their contribution for RecSys 2021 challenge and an example will be pretty much to provide here, I hope the following helps to get an understanding of what I am trying to do and hopefully some help:
I am trying to categorify three columns of a cudf DataFrame which may contain None or a string that contains hashes separated by \t.
cat_features = ["hashtags", "present_links", "present_domains"]

cat_cols = (
    nvt.ColumnGroup(cat_features) >>
    (lambda col: keep_n(col, max_n=32)) >>
    Categorify(dtype=np.int64, cat_cache="disk", freq_threshold=10)
)

The function keep_n basically keep the first hash which has 32 characters if there is at least one hash, if not, it returns None.
Expected behavior
I would expect this to run smoothly and not overshoot the GPU RAM which in fact is quickly running OOM. Also using cat_cache="host" does not change anything. I would expect for the latter case that my CPU RAM is exploited which is not the case. Regardless of the option, I am always running into OOM issues for the GPU.
Environment details (please complete the following information):
I first used version 0.5.1 which was installed using conda. I also tried with installing from master branch with version '0.5.3+3.g50f04df'. I didn't observe any changes here.
I am actually running my stuff on a GCP instance (machine type: a2-highgpu-1g) with 12 cores, 85 GB memory and one NVIDIA Tesla A100 with 40GB GPU RAM.
Am I misunderstanding the documentation here which states that cat_cache defines the Location to cache the list of unique categories for each categorical column. or is there something buggy here?
Thanks in advance!

Update:
Setting cudf.set_allocator("managed") in the beginning seems to solve the problem. I suggest to add this to the documentation.

@mkurovski Thanks Marcel for reporting this issue. part_size or part_memory_fraction arguments are recommended to be used in case you hit an OOM issue. you can easily set part_size to the different desired sizes to avoid OOM.
https://github.com/NVIDIA/NVTabular/blob/11a4d627b268e5069fdc0cc1cc9ec2bc28d9a730/nvtabular/io/dataset.py#L164
Can you try reducing the partition sizes you're processing? You can do this by setting the part_size or part_mem_fraction parameters you pass to the nvtabular.Dataset object.
Let us know if that works at your end or not.


Add labels for Solver Selection in Feature Model Input Mask

See here for the current state. You don't immediately see which solver selection is used for which anomaly.

obsolete with #51


List of Implemented Syscalls

I definitely may have missed it somewhere, but if not, I think it'd be great to have a status table for which of the Linux kernel's syscalls have been implemented in WSL. Just an idea :)

There is also a running list of syscalls that are implemented in our release notes page. The first list was compiled for build 14328 and for every build we mention the additional syscalls that were supported ex: 14986.

Of interest: Test cases for WSL system calls
Includes section: How to install and run Linux Test Project (LTP) on WSL

This is great, @EricGT. We want to encourage all different kinds of tests runs on WSL and are interested in the reports/issues etc.. Thanks for taking the initiative.

Quick follow-up.  We added a new syscall list for build 15014 here.  We will be adding the Syscalls.txt file to more builds in the future.

Perfect! Thanks!


TestNG 7.4.0 throws an exception "sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection" when xml file contain "ENTITY  SYSTEM" grammer

TestNG Version

Note: only the latest version is supported
7.4.0

Expected behavior
works as 7.1.0
Actual behavior
TestNG 7.4.0 throws an exception "sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection" when case xml file contain raw XML mechanism grammer like below:
<!ENTITY raw_listeners SYSTEM "testng/_listener/raw_listeners.xml">
        ]>

see java stack:
Connected to the target VM, address: '<IP_ADDRESS>:62526', transport: 'socket'
[TestNGContentHandler] [WARN] Failed to read [/E:/A_Project/A_Code/ose-test/jss_test/testng/_listener/raw_listeners.xml] from CLASSPATH. Attempting to read from [file:///E:/A_Project/A_Code/ose-test/jss_test/testng/_listener/raw_listeners.xml].
org.testng.TestNGException: java.lang.ClassCastException: sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection
	at org.testng.TestNG.parseSuite(TestNG.java:356)
	at org.testng.TestNG.initializeSuitesAndJarFile(TestNG.java:376)
	at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:39)
	at com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:109)
Caused by: java.lang.ClassCastException: sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection
	at org.testng.xml.TestNGContentHandler.lambda$new$0(TestNGContentHandler.java:70)
	at org.testng.xml.TestNGContentHandler.resolveEntity(TestNGContentHandler.java:138)
	at com.sun.org.apache.xerces.internal.util.EntityResolverWrapper.resolveEntity(EntityResolverWrapper.java:110)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.resolveEntityAsPerStax(XMLEntityManager.java:997)
	at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1212)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEntityReference(XMLDocumentFragmentScannerImpl.java:1908)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3061)

Is the issue reproductible on runner?

[X ] Shell
[X ] Maven
[ ] Gradle
[ ] Ant
[ ] Eclipse
[ ] IntelliJ
[ ] NetBeans

Test case sample

Please, share the test case (as small as possible) which shows the issue

write a testng xml case file like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" [
        <!ENTITY raw_listeners SYSTEM "testng/_listener/raw_listeners.xml">
        ]>
<suite name="ECBench Suite">
  <groups>
    <run>
      <exclude name = "known_bug"/>
      <exclude name = "disabled"/>
    </run>
  </groups>
  <test name="ecbench test">
    <classes>
      <class name="com.cloud.test.ecbench.ecmaster.Node.AddNodeTest" />
    </classes>
  </test>
  &raw_listeners;
</suite>

and write another file which will be imported by using XML ENTITY grammer
<?xml version="1.0" encoding="UTF-8"?>

<listeners>
    <listener class-name="com.cloud.report.listener.TestNgReportListener"/>
</listeners>

execute this case, and testng 7.4.0 will throw an exception "sun.net.www.protocol.file.FileURLConnection cannot be cast to java.net.HttpURLConnection"

but testng versions before 7.1.0 can recognize ENTITY in xml case files,

@xirs - How are you running your test?
I tried running this from within IntelliJ and I dont see any exception. I also dont see the listener being invoked as well (which is a separate problem)

ping @xirs

Hi, I'm pretty sure that I have the same problem, asked a question about this on StackOverflow, you can find more details here - https://stackoverflow.com/questions/66118355/java-lang-classcastexception-when-trying-to-import-document-entities-in-a-testng .  Also tested with 7.4.0, it's the same. Let me know what more info do you need, I'll be happy to assist. Running from Maven project using Eclipse 2020.03, TestNG plugin 7.4.0, openjdk 14. I could also try running it from IntelliJ if it's any help.

@gdflorea - Can you please try downgrading your JDK to JDK8 and let us know what you see ? I think this could be related to JDK

Same problem with JDK8, TestNG 6.9.11 is ok, 7.4.0 fails

@gdflorea - It would be really good if you could please help debug more to find out if you can help get us any additional context on how we can reproduce this error.
Maybe the JDK flavour and JDK version also will help. Can you please create a sample project that we can use to reproduce this via a runner (Maven/Gradle) or maybe using a public static void main method ?

@krmahadevan I created a IDEA project, it will help to reproduce this issue.
Testng.zip
I use JDK 1.8, see the configutation when I run the testngxml

@krmahadevan See attached archive. Tried to do everything as simple as possible, so I went for the public static void main method and classpath in cmd.
TestProject.zip
Running with TestNG 6.9.11 everything is ok
d:\TestProject\bin>java -cp ./;../lib/testng-6.9.11.jar;../lib/jcommander-1.78.jar Main
produces the output(among other things)
Total tests run: 1, Failures: 0, Skips: 0
But running with TestNG 7.4.0 it crashes:
d:\TestProject\bin>java -cp ./;../lib/testng-7.4.0.jar;../lib/jcommander-1.78.jar Main
results in
[TestNGContentHandler] [WARN] Failed to read [/d:/TestProject/bin/params.xml] from CLASSPATH. Attempting to read from [file:///d:/TestProject/bin/params.xml].
Exception in thread "main" org.testng.TestNGException: java.lang.ClassCastException: class sun.net.www.protocol.file.FileURLConnection cannot be cast to class java.net.HttpURLConnection (sun.net.www.protocol.file.FileURLConnection and java.net.HttpURLConnection are in module java.base of loader 'bootstrap')
        at org.testng.TestNG.parseSuite(TestNG.java:356)
        at org.testng.TestNG.initializeSuitesAndJarFile(TestNG.java:376)
        at org.testng.TestNG.initializeEverything(TestNG.java:1011)
        at org.testng.TestNG.run(TestNG.java:1023)
        at Main.main(Main.java:10)
Caused by: java.lang.ClassCastException: class sun.net.www.protocol.file.FileURLConnection cannot be cast to class java.net.HttpURLConnection (sun.net.www.protocol.file.FileURLConnection and java.net.HttpURLConnection are in module java.base of loader 'bootstrap')

openjdk 14.0.2 2020-07-14
OpenJDK Runtime Environment (build 14.0.2+12-46)
OS: Windows 10
I'm pretty sure that the jdk version is not relevant, I also tested with 8, but not with the attached files.

@gdflorea - Thanks for the persistence on bringing out this issue. The problem was because of embedding file entities in the suite xmls which was the root cause. I have fixed it and raised a PR. So this problem should go away after 7.5.0 (upcoming version) gets released.


all: reopen tree for Go 1.17 development

Current Tree Status: Accepting early Go 1.17 changes only (see list below)
As we're getting closer to the final Go 1.16 release, we will soon need to open the tree for Go 1.17 development.
As usual, the tree will initially be open to changes that must land early. Tentatively:

[x] CL 275297 that bumps internal/goversion—this must be the very first CL to be submitted; CC @bcmills
[x] dev.regabi branch will be merged to master as described here—tracking issue #44224; CC @cherrymui, @jeremyfaller
[x] dev.typeparam branch will be merged to master assuming the proposal is accepted; CC @griesemer, @jeremyfaller
[ ] windows/arm64 @rsc
[x] cmd/go lazy loading refactoring @bcmills
[ ] //go:build changes @rsc
[ ] (Add/reorder any other CLs or stacks or branches that must land early.)
[ ] Finally, open the tree for all general Go 1.17 changes.

We will send status updates to golang-dev@ as part of this work.
This is the tracking issue for completing this task.
CC @golang/release, @ianlancetaylor.

It's planned by @golang/release for this issue to begin progressing after the Go 1.16 release is issued.

The "Current Tree Status" was just changed from "Frozen for Go 1.16 changes only" to "Accepting early Go 1.17 changes only (see list below)". I've sent a message to golang-dev.
I'll work with @bcmills on the first CL on the list.

internal/goversion is in. Time to merge some branches (@cherrymui, @jeremyfaller)?

Merging dev.regabi into master (issue #44224) was resolved (thank you @cherrymui). The next item currently in the list is:

dev.typeparam branch will be merged to master assuming the proposal is accepted; CC @griesemer, @jeremyfaller

When it's done (or if plans change), please update this issue and coordinate with the people working on the next item. Thank you!

Quick update. Merging the dev.typeparams branch will require 1) to merge master into dev.typeparams (today), 2) isolating API changes that we may need for 1.18 but not for 1.17 (next couple of days), and then 3) merging dev.typeparams into master (hopefully by end of this week).

While we wait for dev.typeparams, it is OK for the cmd/go changes to proceed - I just checked and there are no changes in cmd/go on dev.typeparams.

It also looks OK for the windows/arm64 changes to proceed - there is no overlap except for one if statement in cmd/compile deciding about whether arm64 frame pointers are enabled, and dev.typeparams won't be changing that.

The cmd/go changes that were ready to merge are in — we're all clear there from the perspective of opening the tree.

Status update on dev.typeparams:

we've done a recent (this afternoon) merge from master, so dev.typeparams is tracking master closely
all outstanding CLs are in
the build looks green but for (now) linux-ppc64le-power9osu (API check killed)

Currently we are trying to get x/tools tests to pass: They rely on go/parser and go/types which have changed significantly. We have fixed several failures and should be down to one or two at the most by tonight. Once x/tools passes, we can merge once more with master (should be clean) and then dev.typeparams can be merged into master. Maybe tomorrow, and hopefully before Monday.

Status update on dev.typeparams:

build looks green but for linux-ppc64le-power9osu (API check killed) and netbsd-argm64-bsiegert (intermittent failure)
x/tools seems to be ok but for x/tools/internal/lsp/source (but I may not have the correct setup, @findleyr will know more)

Once the lsp tests are deemed ok we should be ready to go. Next steps:

merge master -> dev.typeparams (expected to be trivial and conflict free)
merge dev.typeparams -> master

I merged the windows/arm64 changes last night and broke a few builders. I have CLs out for those.
We should probably wait to get those fixed before doing the dev.typeparams merge, but they should be fixed soon.

@dmitshur FYI, Russ has asked me to do an early submit https://go-review.googlesource.com/c/go/+/293309 with the fix for https://golang.org/issue/44344. Hope that is ok.

I think the guidelines should be that pure bug fixes are OK at any time.

@thanm Yes, as Russ said that CL is a follow up to the dev.regabi merge and is okay. Thanks.

Status update on dev.typeparams:
x/tools should now be green. I tested the merge in https://golang.org/cl/293770, and all Trybots succeeded (including x/tools).  To be extra careful I'll also run x/tools tests on various other builders using gomote, though I'm not actually aware of changes in dev.typeparams that would cause failures on specific builders.

@findlyr and @griesemer are going to work on the dev.typeparams -> master merge in about an hour.
Consider the tree locked until they are done.
(The tooling requires that no commits appear on master between the preparatory master -> dev.typeparams merge and the final dev.typeparams -> master merge, so we can help them avoid doing multiple of the first merge by not submitting anything.)
Thanks!

dev.typeparams has been merged into master.
(Perhaps give it 30min or so to settle on the build dashboard for a clear picture.)

dev.typeparams is merged.
I still have some pieces to pick up from windows/arm64, and I need to send in the //go:build CLs.
So we're not open for business yet.
But hopefully soon.
Watch this space.

If any +2'ers want to help move things along, once these reformatting CLs are in I think we can soft-open the tree.
https://go-review.googlesource.com/q/o:rsc+status:open+fmt

I've submitted what must be submitted before soft-reopening. I'm waiting for the dashboards to clear and will post when it is time. One more reformatting CL for anyone who wants it: https://go-review.googlesource.com/c/sys/+/294490.

OK, things look stable enough on the dashboard. Thanks for the reviews.
The tree is now open for bug fixes only.
This is a soft reopening for the weekend, before the full re-opening Monday.
An email to golang-dev@ will announce the full re-opening.
Again, bug fixes only for now.
No new features, new implementations, new API, etc. (Not yet.)
The compiler underwent major surgery during the freeze in preparation for generics,
and the runtime had minor surgery in preparation for the windows/arm64 port.
There is still a bug to find to revive windows/arm (32-bit), which I'll try to do in the next few days.
Everything else seems to be working decently on the dashboard.
But certainly there are bugs, and help finding and fixing them is always appreciated. :-)
Happy hacking!

The "Current Tree Status" was updated from "Open for bug fixes only" to "Open for Go 1.17 development". I've sent an announcement to golang-dev.
Closing, as this issue is resolved. Thanks everyone!

Q


"Reset blueprint" button should reset to the blueprint in the recording (if any)

The "Reset blueprint" button currently clears the blueprint, going to the heuristic definition.
Instead, if there was a blueprint bundled with the recording, we should reset to that.
"Reset to heuristics" is arguably a much less useful feature, and could perhaps be hidden in a conext menu on the reset button, or in the selection panel for the recording, app_id, or blueprint.

To implement this we need to keep track of which blueprint came with which recording. We can do so via the data sources (if they came from the same source, they belong together).
We also need to create a copy of each blueprint, as it was before the user edited it, or have some way of rolling it back to when the user started editing it.

We should probably save all the blueprints on shutdown, not just the active ones.

Closing based on the work done in: https://github.com/rerun-io/rerun/pull/5678
Note, this doesn't strictly implement the feature as described. Reset will reset to the current default blueprint (which may or may not be the one from the given recording). I believe this is close enough given our discussions on downsides of the "always use the recording-blueprint". We can open a new issue if necessary.


Extract default config into their own files

Much of the work that is being done is copying config files for every municipality and playing with the values until the extract is just right. This can be very confusing for some people that are new to the project.
This PR attempts to extract the though of what configs are needed by putting them all into their own file and exporting a generator type function that will return the config for a specified config.

I used the same configs as for the legislative one (see L19-L37).

I used the same configs as for the legislative one (see L19-L37).

Seeing this makes me thing we are on a good path to help automate this to some extent. @Jpadilla1 thoughts?

Closing this out as not need/wanted at this time for this repo. We'll reuse this once we finish work and get a breather to extract the parser from this repo.


Synchronize two clients to control one device

i have two clients (Phone App) using the same account.
with the first I carry out commissioning with a device, I would like to synchronize the second via cloud so that I can use the device without having to repeat the commissioning
Could you tell me the correct flow?
it is sufficient to share the NOC with the second client

You need to make sure you transfer enough information to stand up the second app's node on the relevant fabric.  So

Either the root certificate and a pre-generated NOC (and ICA cert if any are in use) or enough information to generate the operational certificate chain (root private key, root public key, root certificate matter-rcac-id, fabric id), depending on whether the second app will be doing commissioning too.
The IPK.

We want to achieve the same, totally skipping the commissioning on the second phone.
@stefano055415  Did you solve this?
@bzbarsky-apple  Assume we have everything ( root certificate, NOC, IPK , IP, discriminator, passcode , ... anything) whats the fastest flow to pair the device?

@DanijelBojcic I don't follow the question.  If you have all the relevant info, once you "pair" (that is commission) the device onto the fabric once, the second client on the same fabric does not need to do any "pairing".  It can just do operational lookup and talk to the device.

My concern is how to load all the information onto the second client. I can't seem to find any existing functions that can do this. Should I simply copy the KeyValueStore from the first client?

My concern is how to load all the information onto the second client.

That's up to you; it depends on how you are storing that information, etc.  For example, you probably want to copy the root cert and the IPK, but for the operational cert you presumably want to issue the second client a cert for the same fabric but a different node id.
There are no "existing functions" to do this because it depends on your exact PKI setup.

@bzbarsky-apple we would like to use Matter as a communication interface between our controller and the mobile apps which connect to it. We would like to avoid the commissioning process as much as we can. So the algorithm would be that for example the first mobile app who connects to the network commissions the device and shares the required information to the other applications, so store them in the cloud.
We tried to share the required information and also the NOC as well and use the same NOC on all mobile devices to connect to the controller. I don't know if it's a valid way or not, therefore I tried to validate it with chip-tool. I've run two chip-tools in parallel in two different windows. Let's call the first chip-tool as 'A', the second one as 'B'.

chip-tool 'A' subscribed to an attribute on the controller:
onoff subscribe on-off 1 100 1 4
chip-tool 'B' subscribed with the same NodeId to the same attribute on the controller:
onoff subscribe on-off 1 100 1 4 --keepSubscriptions true

At this point, chip-tool 'A' hasn't got any error/event/information from the server, but its subscription doesn't work. BUT, if chip-tool 'A' re-subscribes within the timeout window (maxInterval parameter from the subscription above which was 100s), then the subscription works on both chip-tools. onoff subscribe on-off 1 100 1 4 --keepSubscriptions true
It means, two chip-tools - so two clients - are connected to the server with the same NOC, but with different Network addresses (in my case the IP is the same, but different ports are used).
My question would be: Is this the intended behavior? So, should it work with two clients with the same NOC? (then the issue is that the first client has to re-subscribe) Or, it shouldn't work at all that two clients are connected with the same NOC and this is not permitted?

the first mobile app who connects to the network commissions the device and shares the required information to the other applications, so store them in the cloud

This is all fine and doable, yes.

and use the same NOC on all mobile devices to connect to the controller

This is not a great idea for the following reason: if you are using the same NOC on all of them, you are using the same node ID for all of them.  The other side of the interaction can get very confused when it needs to "send a message to this node id" (which is what the spec requires) but the node id conceptually corresponds to multiple IPs/ports.

then the subscription works on both chip-tools

This basically happens to work by accident, sometimes, and is very much not guaranteed.   And anything that causes either of the clients to establish a new CASE session will make the subscription for the other client stop working.  You observred that when B established its subscription initially and A's subscription stopped working.

It shouldn't work at all that two clients are connected with the same NOC and this is not permitted?

It's not expected to work, but might work by accident, in some circumstances.  The set of circumstances where it happens to work is not clearly defined and not guaranteed to stay the same as changes happen to the underlying core code.
Per spec, a node id is supposed to map to exactly one thing on the network.  That thing's ip+port can change (most simply: dhcp assigns a new IP), but you really should not have multiple things all using the same node id at the same time; that will not work well.


Please add this to the Readme so it is clear on the Github landing page for the project.

https://github.com/ProjectSulphur/ProjectSulphur/blob/4a83bc842458ba9297b764455040104a29f05b6a/3RDPARTYLICENSES#L502

Fixed!


chore: clean code with clippy

Codecov Report
Patch coverage has no change and project coverage change: +0.02 :tada:

Comparison is base (fa51ea4) 10.86% compared to head (ca6a6aa) 10.88%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #111      +/-   ##
==========================================
+ Coverage   10.86%   10.88%   +0.02%
==========================================
  Files          53       51       -2
  Lines        2108     2104       -4
==========================================
  Hits          229      229
+ Misses       1879     1875       -4

Impacted Files
Coverage Δ

src/common/event_bus/mod.rs
92.50% <ø> (ø)

src/config/util.rs
100.00% <ø> (ø)

src/config/worker.rs
0.00% <0.00%> (ø)

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

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


Human Ancestry Ontology (HANCESTRO) must be downloaded and prepared

The following ontology dependency is pinned for this version of the schema.

Ontology
OBO Prefix
Required version

Human Ancestry Ontology
HANCESTRO
hancestro.owl : 2021-01-04 (2.5)

Parsing requirement:

Extract the term identifier and its human-readable label

Implemented in cellxgene-schema v2.0.0


Vina installation

I am experiencing a problem installing Vina 1.2 in Ubuntu 20.04 LTS. After the step where in I need to input "python setup.py build install", this error showed.
File "setup.py", line 280
sep='\n')
^
SyntaxError: invalid syntax
Upon checking the entire code it says os.path.sep but it also did not work either.
I will appreciate your help. Thanks.
Joanna

Hi,
Vina only works with python3, not with python2.
See here for more information: https://autodock-vina.readthedocs.io/en/latest/installation.html#python-bindings

Hi,
My python version is 3.7.11.

So should I use python3 setup.py install instead?

The error you posted occurs because the sep argument is unknown to the print function in python 2. If by typing python you get python 3, there should be no need to type python3.

When I type python --version I get the Python 3 version. Even the conda environment where vina directory is located is using Python 3. I am not exactly where what went wrong along the way.

I have no idea about what might be happening. Please post here when you find out, I'm curious about the mysterious ways of conda/python :-)

The installation went successfully after I used python3 instead of python (equivalent to python2). However, when I tried calling vina, there was no vina.

Hi,
Yes, this is normal. The python bindings and binary installations are still two separate processes..
Best,

@jmechua-itsrdc the command line executables are available here for download: https://github.com/ccsb-scripps/AutoDock-Vina/releases


Cluster ready Queue Mode

This PR aims to implement the the new send API (with RequestTicket) for QueueMode.
LwM2mRequestSender
The new LwM2mRequestSender is a listener based instead of callbacks. Callbacks are not cluster friendly. All the previous send methods using callbacks are marked deprecated. It also has two new methods to add/remove ResponseListener. A ResponseListener gets notified when a response or error response is received from a LWM2M client. Each request and its response is correlated by means of a RequestTicket.
There is now a concrete implementation LwM2mRequestSenderImpl of the LwM2mRequestSender interface which delegates the send call to either to a QueuedRequestSender or to a CaliforniumLwM2mRequestSender.
QueuedRequestSender
QueuedRequestSender doesn't implement the deprecated methods of LwM2mRequestSender and is also not aware of clients binding mode. This responsiblity is now moved to LwM2mRequestSenderImpl as described above.
Signed-off-by: Bala Azhagappan<EMAIL_ADDRESS>

@sbernard31 I am finished with implementing the new send API for QueueMode. Observations are also working as expected. Upon review If there are no further changes required, please go ahead merging the changes in to the cluster_queue_mode branch and the branch itself in to master. Thanks.

Some remarks about this PR/branch (clustering and queue mode) :

Should we delete request from queue on exception ?
We must use usesQueueMode() instead of getBindingMode().equals(BindingMode.UQ)  in LwM2mRequestSenderImpl .
About LwM2mRequestSenderImpl.createBindingAwareResponseListener(), I think this is not the responsability to LwM2mSender to listen response and to store listeners it must delegate it to its internal implementation queuedRequestSender and defaultRequestSender.

From my point of view, after we are done with clustering and queue mode the next steps will be :

Avoid duplication code from LeshanServer to QueueModeLeshanServer. I think we should remove QueueModeLeshanServer and change LeshanServer to allow to use custom request sender.
Avoid duplication code from LeshanClient to QueuedModeLeshanClient by adding a protected createObjectResource method in LeshanClient.
Do not use fixed/static port for QueueMode tests. Use free port like the others tests.

Each of those last 3 points could be done in separate PR to facilitate discussion.

Should we delete request from queue on exception ?

Except TimeoutException, I don't see any reason to keep it in the queue as it is up to the application layer to decide further actions which could also be a requeue.

We must use usesQueueMode() instead of getBindingMode().equals(BindingMode.UQ) in LwM2mRequestSenderImpl .
Done.

hi Simon,
About the third question, on first look your question seems very logical and valid. But there is a reason why it is done the other way.

About LwM2mRequestSenderImpl.createBindingAwareResponseListener(), I think this is not the responsability to LwM2mSender to listen response and to store listeners it must delegate it to its internal implementation queuedRequestSender and defaultRequestSender

To facilitate discusson on your third question,  I have put forth two sequence diagrams.
The following one shows the current state of implementation in which the LwM2mRequestSenderImpl has a single responsibility of delegating the calls (add/remove response listeners and also dispatching response/errors) based on client's binding mode (Binding Aware responsiblity).

The next one is as per your suggestion (just delegating add/remove listener calls to concrete implementation), in which case the CaliforniumLwM2mRequestSender, on error should check whether client is in queue mode and the exception is not a TimeoutException before notifying the listeners. Because if a client is in queue mode and the exception is a TimeoutException, the Queue mode will eventually retry.

As you see, now CaliforniumLwM2mRequestSender also takes on the responsiblity to check whether the client is in queue mode. So the Binding Aware Responsibility is split across CaliforniumLwM2mRequestSender and LwM2mRequestSenderImpl which I don't think is good.
What do you think?

Ok I see the problem.
But from my point of view, the first solution has several issues.

LwM2mRequestSenderImpl should not know how QueueRequestSender is implemented. So this class should not know that all responses will be received by defaultRequestSender. So it should listens the 2 senders.
2.QueueRequestSender  implements LwM2mRequestSender but does not respect the "contract" as you can not add or remove listener on it.

So what should we do ?
I propose to change LwM2mRequestSenderImpl to make it only depend of LwM2mRequestSender not QueueRequestSender and delegate add/remove listener to delegate senders.
To fix the issue you raised about timeoutException, I suppose this must be handle in  QueueRequestSender.  In this case you must implement something like what you do in LwM2mRequestSenderImpl. You could even remove the access of ClientRegistry and the check about queue mode if the QueueRequestSender use its own instance of CaliforniumLwM2mRequestSender.

Ok, I see your point. I have two follow up questions.

As per your proposal, still in method LwM2mRequestSenderImpl.send(), we need to check whether the client is in QueueMode and not delegate to all the senders which when done will send the message twice. Checking for client binding and TimeoutException on error can be done in QueueRequestSender as you said. right?
Also, I am not comfortable with exposing the implementation details of LwM2mRequestSenderImpl to the application, which, in order to use LwM2mRequestSenderImpl should instantiate a QueueRequestSender and a CaliforniumLwM2mRequestSender. One purpose of LwM2mRequestSenderImpl  can also be to remove the burden of depending on the concrete implementations from the application. Is it not? A solution to this might be that the LwM2mRequestSenderImpl  instantiates QueueRequestSender and CaliforniumLwM2mRequestSender.

hi Simon,
I tested your proposal (except for instantiating the CaliforniumLwM2mRequestSender in QueueRequestSender, instead passed a second instance of CaliforniumLwM2mRequestSender to QueueRequestSender from my demo application layer). It looks good. Now QueueRequestSender is also fully compliant with the LwM2mRequestSender contract and LwM2mRequestSenderImpl just delegates the add/remove listeners to both the delegate senders and doesn't register itself as listeners with any of the delegate senders. See my latest commit.
Still would be good if you can answer my questions above. Thanks.

Yes: "Checking for client binding and TimeoutException on error can be done in QueueRequestSender"
I think QueueRequestSender should not be depend of Californium.
I'm not sure to understand the problem with LwM2mRequestSenderImpl ? I suppose this should be the default implementation, so the complex instantiation will be done by LeshanServerBuilder. If some one want to tweak sender behavior by implementing its own sender, it's ok for me if it's a bit complex.

Ok. Good. Then lets leave the LwM2mRequestSenderImpl as it now (compared to the very first commit in this branch, it is now very lean).
Yes, as you say, we could leave the complex instantiation to LeshanServerBuilder.
If you are ok with the state here, please do merge and I can proceed with the next PR's as you suggested above (test/util cleanups).
IMO, we need one more PR's. Currently LeshanServer is using CaliforniumLwM2mRequestSender.cancelPendingRequests() to cancel requests on the CoAP layer when a device is deregistered. I would like to move this method to LwM2mRequestSender interface. Then QueueRequestSender can also use this feature and I can also integrate LwM2mRequestSenderImpl in LeshanServer instead of CaliforniumLwM2mRequestSender. What do you think?

Except my last comment, I think we are ok to merge it. I will do that as soon as you fixed that.
I agree about the fourth PR.

hi Simon,
I just pushed your last request. Thanks for looking in to it so fast.
As the 3 further PRs (test/util cleanup) and the 4th PR (cancelling of request on coap layer) related to Queue mode in general and not to clustering of queue mode, I would like to proceed on it with master as the base.
Could you also merge this branch to master? or should I open a separate PR for that?

Pushed on master (commit b91f346e3f01d4d8d07cc84e926fb6dd4d42c411)


Propagate cargo-features from project's Cargo.toml

The [profile.release] section of the project's Cargo.toml is propagated into the xbuild, but may rely on Cargo features that require explicit enabling.  This PR also propagates any cargo-features from the project's Cargo.toml into the xbuild.
(I encountered this case when attempting to use Cargo's new strip feature).

Looks good to me, thanks!

Published as v0.5.34.


services cannot communicate enabling istio inject

I'm havin issues when I enable istio-injection: seems the services can't communicate w/ each other any longer.
Please find attached the microk8s.inspect tarball
Any hints highly appreciated, thx
Joerg
Inspecting services
  Service snap.microk8s.daemon-containerd is running
  Service snap.microk8s.daemon-apiserver is running
  Service snap.microk8s.daemon-proxy is running
  Service snap.microk8s.daemon-kubelet is running
  Service snap.microk8s.daemon-scheduler is running
  Service snap.microk8s.daemon-controller-manager is running
  Service snap.microk8s.daemon-etcd is running
  Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system info
  Copy network configuration to the final report tarball
  Copy processes list to the final report tarball
  Copy snap list to the final report tarball
  Inspect kubernetes cluster

 WARNING:  IPtables FORWARD policy is DROP. Consider enabling traffic forwarding with: sudo iptables -P FORWARD ACCEPT

inspection-report-20190711_000336.tar.gz

Hi @joergeb, could you try to sudo iptables -P FORWARD ACCEPT ?

And that's it? Just read the WARNING :smile: Cool, sry for inconvenience. Should I install iptables-persistent saving the change, or is persisting rather obstructive?

Yes, @joergeb you would install iptables-persistent to make this change permanent.


Backport clusterrole aggregation to release-0.6

Add clusterrole aggregation for kubevirt CRDs
(cherry picked from commit d7dd22ab01fc6abd91f7d1a40598c6b408127243)
Signed-off-by: Adam Litke<EMAIL_ADDRESS>
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

Aggregate cluster-wide view, edit, and admin roles to KubeVirt CRDs

/cc @fabiand

/cc @davidvossel


Add docs on (E)WKT, (E)WKB, GeoJSON, and SRID 4326

Fixes #8564, #8565, #8566, #8572.
Summary of changes:

Add new reference pages for:

Well known text (WKT) shape format

Well known binary (WKB) shape format

GeoJSON data format (see also: geojson.org)

SRID 4326 (coordinate system for longitude and latitude)

Add links from the glossary to these pages, whereas before we were
relying on PostGIS docs in several cases.

This change is

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/3b876014444b7818f17a856f0599f9ec5631f2b2/
Edited pages:

v20.2/geojson.md
v20.2/spatial-features.md
v20.2/spatial-glossary.md
v20.2/srid-4326.md
v20.2/well-known-binary.md
v20.2/well-known-text.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/292638486d1cdf4caf9045b19576333ba8bee5f7/
Edited pages:

v20.2/geojson.md
v20.2/spatial-features.md
v20.2/spatial-glossary.md
v20.2/srid-4326.md
v20.2/well-known-binary.md
v20.2/well-known-text.md

Eric, I'm still working through some feedback from Oliver but I think it's getting close - can probably start Docs Team part of review concurrently.

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/96935077e7d7d5cb63e9582cbcb4751ea682807d/
Edited pages:

v20.2/geojson.md
v20.2/spatial-features.md
v20.2/spatial-glossary.md
v20.2/srid-4326.md
v20.2/well-known-binary.md
v20.2/well-known-text.md

Online preview: http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e1229b4f3f7cad8ca9c9fb2f87b905cc1eda3f78/
Edited pages:

v20.2/geojson.md
v20.2/spatial-features.md
v20.2/spatial-glossary.md
v20.2/srid-4326.md
v20.2/well-known-binary.md
v20.2/well-known-text.md


Runtime variables

This adds a feature where if you put ($1, $2, $3, $4, or $5) inside a command within .projectlaunch.json, you will be prompted to fill it in at runtime.
This has been very useful for me. I often have similar commands where only one argument changes. This allows me to store only one version of the command in my config rather than having to copy the command ~5 times and create different versions.
If the command had any vars in it, the command name is updated to have () appended with the value of the arguments you sent.

I'll look into this. I just recently learned that Lua defaults all vars to
global unless you use the local keyword. I didn't know that when I wrote
this. I'm used to "sane" block scoping. 😁
On Tue, Sep 5, 2023, 17:03 sheodox @.***> wrote:

@.**** commented on this pull request.
Sorry again for taking so long to get to this, couple minor things then
this should be good to go!
Also, I have nvim set up to run Stylua (with default settings). I haven't
gotten around to making CI validate the styles but could you make sure to
run Stylua too if you hadn't already?
In lua/projectlaunch/jobs.lua
https://github.com/sheodox/projectlaunch.nvim/pull/6#discussion_r1316453895
:

local args = ""

for key, value in pairs(runtimeVars) do

   args = args .. value .. ","

end

args = args:sub(1, -2) --Remove trailing comma

I think this could be replaced with table.concat(runtimeVars, ',')
In lua/projectlaunch/jobs.lua
https://github.com/sheodox/projectlaunch.nvim/pull/6#discussion_r1316456571
:

+function getTableSize(t)

local count = 0
for _, __ in pairs(t) do

   count = count + 1

end
return count
+end

You can use vim.tbl_count(t) for this instead.
In lua/projectlaunch/jobs.lua
https://github.com/sheodox/projectlaunch.nvim/pull/6#discussion_r1316461115
:

@@ -5,7 +5,12 @@ local api = vim.api
local term_name_prefix = "ProjectLaunch terminal - "

local Job = {}
+runtimeVars = {}
Could you do this slightly differently so runtimeVars doesn't need to be
global? You could either move all the new functions to be part of Job
like Job:new is, or move all of the functions inside of generateCommand.
My lua is a little rusty but I believe right now runtimeVars (and I think
all the new functions) are all global, and it'd be really nice to not leak
stuff to the global scope.
—
Reply to this email directly, view it on GitHub
https://github.com/sheodox/projectlaunch.nvim/pull/6#pullrequestreview-1612002767,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNFNXNHYAMDDHCRENRQQE3XY6OSPANCNFSM6AAAAAA2JQGHOI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Totally understandable, lol. It's definitely a quirk I wouldn't have expected if I didn't see someone else's warning at some point.

Alright. That should fix the problems. I moved the runtime var functions
into their own module to fix the global problem.
On Tue, Sep 5, 2023, 17:27 sheodox @.***> wrote:

Totally understandable, lol. It's definitely a quirk I wouldn't have
expected if I didn't see someone else's warning at some point.
—
Reply to this email directly, view it on GitHub
https://github.com/sheodox/projectlaunch.nvim/pull/6#issuecomment-1707394464,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNFNXIIUATSZYFFRQV72TLXY6RLVANCNFSM6AAAAAA2JQGHOI
.
You are receiving this because you authored the thread.Message ID:
@.***>

The reason it ended up like this is because I was trying to leave command
names unchanged if they don't contain runtime vars. So a "node index.js"
command will still show up as "node index.js" in the floating window. If
the command is "node index.js $1 $2" and you input an "a" and "b", the
command in the floating window will be "node index.js $1 $2 (a, b)". The
output of generateJobName() depends on whether runtime vars have been
prompted or not.
On Thu, Sep 7, 2023, 17:27 sheodox @.***> wrote:

@.**** commented on this pull request.
In lua/projectlaunch/runtime_variable_manager.lua
https://github.com/sheodox/projectlaunch.nvim/pull/6#discussion_r1319170566
:

function(input)

	vars[i] = input

end

)
+end

+function RuntimeVarManager.generateJobName(command)

if vim.tbl_count(vars) > 0 then

return command.name .. createArgSuffix()

end

return command.name
+end

+function RuntimeVarManager.interpolate(originalCommand)

vars = {}

My one last concern is with this vars variable still. I'd rather not have
this vars variable work like this where subsequent calls (like to
generateJobName) rely on having called interpolate first for vars to be
relevant. Maybe interpolate could return both the name and the command in
a table? Like since we're still passing command to both, it seems
unintuitive to me that generateJobName implicitly depends on interpolate to
have been called with the same command first. I don't see any obvious bugs
with this, but if things were different I could see running into issues.
Also, I think it's totally fine to use the final command with
substitutions as the name! What was your motivation for doing it this way?
Let me know if this makes sense at all!
—
Reply to this email directly, view it on GitHub
https://github.com/sheodox/projectlaunch.nvim/pull/6#pullrequestreview-1616316703,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNFNXLGCYUKKTUUTDQFXDTXZJC6FANCNFSM6AAAAAA2JQGHOI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ahhhh, sorry I misunderstood how this was working, I didn't realize it was appending the args to the user-defined name, that makes more sense.

Alright. The runtime vars are now not local to the module. I reorganized it
so that you prompt first which returns the vars. You then use those vars in
subsequent calls.
On Mon, Sep 11, 2023, 18:45 sheodox @.***> wrote:

@.**** commented on this pull request.
In lua/projectlaunch/jobs.lua
https://github.com/sheodox/projectlaunch.nvim/pull/6#discussion_r1322188730
:

name = runtimeVarManager.generateJobName(command),

cmd = finalCommand,

The possible future issues I was referring to in my other comment
https://github.com/sheodox/projectlaunch.nvim/pull/6/files#r1319170566
was talking about a situation like if I'm refactoring this code sometime in
the future and forget about this conversation, then if I were to remove
creating finalCommand on line 11, then moved the interpolate call to this cmd
= line, then just reused j.cmd instead of finalCommand on line 37.
That would seem like a harmless way to refactor this as it removes
creating a variable and the rest looks equivalent. But then you'd be not
showing the right name, because vars in the runtime variable manager
module is some module local variable that stores only the last interpolate
call's variables, so reordering those calls will make it show variables for
the previous command, then people are running the wrong command without
realizing it.
—
Reply to this email directly, view it on GitHub
https://github.com/sheodox/projectlaunch.nvim/pull/6#pullrequestreview-1621002895,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNFNXK6CO4ENKSDK5XRZZDXZ6PDBANCNFSM6AAAAAA2JQGHOI
.
You are receiving this because you authored the thread.Message ID:
@.***>


feat: recording video in exported html

If you export to html and then open the html file in Chrome, you can record video of your slides (with or without animations).
Steps without audio

Click record button
Select Chrome Tab in screen sharing
Deny microphone access
(after finished) Stop screen sharing

Steps with audio

Click record button
Select Chrome Tab in screen sharing
Allow microphone access
(after finished) Stop screen sharing
Click the record button again to save file

https://user-images.githubusercontent.com/490574/130374726-46553208-3834-46a1-969c-07e53d0ec228.mov

Are you planning to add the usage instructions to the readme?

good point. do you have an idea to improve the description in README?

At some stage we should probably add some documentation that is accessible from the app itself (similar to or replacing the excalidraw help) but I think the pull request link is ok for now.

Thanks!


Explicitgeos dependency

GEOS is linked against but not declared. The PROJ920 migration needs to have GEOS migrated to 3.12 first, but we first need to have GEOS explicit to trigger such a migration.
Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin please rerender


No visual change when clicking "Update"

This isn't a bug, more of a design flaw.
When an update is available (Windows) clicking the "Update" button seeming does nothing. Leading me to click the button a few times, and then going online to manually download the update before realizing that the Application had updated.
Wouldn't it be really simple to display a message saying "The Application will be updated shortly..." or at least grey out the "Update" button so I know it did something..?

@TheCyaniteProject What OS are you using?

Windows 10 - Updated.

@TheCyaniteProject That is quite weird. What version of the app are you using now?
Normally the moment you click the update button, it should immediately close the application and show you the progress bar of installing. Once that is done, it should open the application again.

I was only one version behind, and now I'm up-to-date. Though, I have a really slow internet connection - 100-300kb/s

@TheCyaniteProject the speed should not matter as in Windows, it downloads the update in the background and shows you update notification once the app has been downloaded.
I am going to release another update (some bugfixes) today. Let me know if it's correctly this time.

Alright, I'll reply here after the update.

Seems to be fixed now. Upon clicking "Update", the application stopped responding and closed after a few seconds, and then opened up the updater.

@TheCyaniteProject Great!


XML Deserialization error when call ArticleFolder's schema method

When making a call to ArticleFolder's schema method, I am getting the following error message:
System.InvalidOperationException: There is an error in XML document (0, 0).
  Stack Trace:
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader)
   at ParatureSDK.XmlToObjectParser.ParaEntityParser.EntityFill[T](XmlDocument xmlDoc)
   at ParatureSDK.ApiHandler.Article.ArticleFolder.Schema(ParaCredentials ParaCredentials)

System.FormatException: The string '' is not a valid Boolean value.
  Stack Trace:
   at System.Xml.XmlConvert.ToBoolean(String s)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderArticleFolder.Read1_NullableOfBoolean(Boolean checkType)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderArticleFolder.Read5_ArticleFolder(Boolean isNullable, Boolean checkType)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReaderArticleFolder.Read6_ArticleFolder()

This can be fixed by updating the following code:
ArticleFolder = ParaEntityParser.EntityFill<ParaObjects.ArticleFolder>(ar.XmlReceived);

to
var purgedSchema = ApiUtils.RemoveStaticFieldsNodes(ar.XmlReceived);
ArticleFolder = ParaEntityParser.EntityFill<ParaObjects.ArticleFolder>(purgedSchema);

An alternative option would be to remove the Schema method, as I don't suppose there are any custom fields for this entity anyway.
Thanks!

Same should done for the following entities:

CsrStatus
CustomerStatus
TicketStatus

Same should done for the following entities:

CsrStatus
CustomerStatus
TicketStatus

Thanks for the catch on the ArticleFolder! Will be fixed in the next release. Going to leave for now - will reevaluate when we go through the non-business entities with a fine-toothed comb. I've found some duplicate entities under the ApiHandler namespace (Csr.CsrStatus and Entities.CsrStatus, for example), so this needs to be cleaned up.
I don't see schema calls for the CsrStatus, CustomerStatus, or TicketStatus classes. Are they under the ApiHandler.Entities folder or subclasses of the business classes (in Csr.cs, Account.cs, etc)?

Schema call for CsrStatus is under ApiHandler.Csr class, and CustomerStatus is under ApiHandler.Entities, so is TicketStatus (under ApiHandler.Entities).
Thanks for looking into this!

My apologies, the issue with CsrStatus and CustomerStatus is a totally different one, since they do not have a Schema method. The problem happens when reading data from Parature. I have two problems here.

When reading data for CsrStatus, CsrStatusGetList method will fail, since the root node of the XML document returned from Parature is "entities" while ParaEntityList<ParaObjects.CsrStatus> serializer expects an "Entities" root node.
I tried to change the root node's name to "Entities", I am getting another problem, the individual record can not be serialized to CsrStatus, since the node is "Status", not "CsrStatus".

Sorry again for the confusion.

Fixed the ArticleFolder issue (schema call removed), but haven't gotten to the latest issue you pointed out. First, thanks for clarifying! It'll be in the next push.

The lower case "entities" in the schema is a bug, but we've added a temporary workaround while we report and push for a fix. You'll now be able to retrieve the status for Csrs, Customers, and Tickets in 2.0.4+ (NuGet) and the master branch.
Also removed the schema calls to these entities, since they shouldn't be necessary (no custom fields).


add vitest support

add vitest support
v0.3.0

CallbackSuite generates an error
@testdeck/vitest:  FAIL  test.ts > tests > CallbacksSuite
@testdeck/vitest: TypeError: Callback must be a function. Received <ref *1> {

where a vitest suite object is passed as a callback.

While this builds and works, the available tests and also the necessary deprecation of node v15.x (EOL), bothers me a lot.

rebased to current main and also bumped version to v0.3.0 since we are adding a new feature

BTW, I would be happy to help on this PR. I don't mind dropping node 15. It is not an LTS anyway.

@pana-cc I do not understand and how this is relevant to adding support for vitest?
About the timeout - maybe we can calculate the timeouts and somehow store them in the LifecycleSettings:

Can you please elaborate on this?

About the timeout - maybe we can calculate the timeouts and somehow store them in the LifecycleSettings: Nevermind. I think I read some sort of "TODO" that for @timeout on a class to work we have to put it in a stack for the @test to be able to reference it. If my suggestion doesn't ring a bell - ignore it.

BTW, I would be happy to help on this PR. I don't mind dropping node 15. It is not an LTS anyway.

@pana-cc Feel free. I will no longer force push commits on this branch.
I for my part am mostly done. There are a few tests that I would like to add, however, these could be added to the other packages as well. I think it is best to do this in a different PR.

About the timeout - maybe we can calculate the timeouts and somehow store them in the LifecycleSettings: Nevermind. I think I read some sort of "TODO" that for @timeout on a class to work we have to put it in a stack for the @test to be able to reference it. If my suggestion doesn't ring a bell - ignore it.

Found it: testdeck/jest/index.ts:
  5             // TODO: Push settings.timeout on the stack and pass it to each child test...

However, for this we need to investigate further.

requires #317

I squashed all commits and reverted versions to 0.2.1 so that we can use the lerna-publish workflow

rebased to current main


defines shape for a subset slice

addresses #408

We're missing unittests for subset. can anyone thing of some?
from ccpi.astra.utils import *
from ccpi.framework import *
import numpy as np

n_angles = 10
angles = np.linspace(0, np.pi, n_angles, dtype=np.float32)

ag = AcquisitionGeometry('cone', 'edo', pixel_num_h=20, pixel_num_v=2, angles=angles,
                         dist_source_center = 312.2,
                         dist_center_detector = 123. )
#ag = AcquisitionGeometry('parallel', 'edo', pixel_num_h=20, pixel_num_v=1, angles=angles )
ig = ImageGeometry(20,20,20)
astra_ig, astra_ag = convert_geometry_to_astra(ig, ag)
print (astra_ig)
print (astra_ag)

vol = ig.allocate().subset(vertical = 9)

sino = ag.allocate()
print(sino.dimension_labels)
subsino = sino.subset(angle=0)
print (sino.shape, subsino.shape)

I believe below is about the same issue.
data = ag.allocate()
data.fill(X)
print(data) --> Number of dimensions: 4
Shape: (40, 80, 60, 80)
Axis labels: {0: 'channel', 1: 'vertical', 2: 'angle', 3: 'horizontal'}
I can take a subset of either 'channel=..' or 'vertical=...' successfully with no issues.
But taking a subset for 'angle' or 'horizontal' gives me:
ValueError: Wrong number of labels. Expected 4 got 3


HTTP resources fails at a lower concurrency than expected.

Description:
HTTP resources fail at a lower concurrency than expected. It fails around 30 threads on my laptop, while similar java application can tolerate more than 200 (could be even higher).
Steps to reproduce:
create a simple service
import ballerina/http;

listener http:Listener apiListener = new(8080);

isolated service / on apiListener {
    resource isolated function get hello() returns error|json {
        return {"hello": "world"};
    }
}

Stress test with JMeter. test-bal-threads.txt (rename .txt to .jmx)
Affected Versions:
Ballerina 2201.9.1
Related Issues (optional):
https://discord.com/channels/957996897782616114/1017493204326686860/threads/1255528309769506969

After some testing it looks like issue was introduced between 2201.4.3 -> 2201.5.0

The JMX script using a stepping thread group to identify the maximum concurrent threads which can be handled by the server without a timeout.
There seems to be some interruption errors in the jmeter client side. Will get a thread dump for further analysis

The issue here is the jmeter plugin client's behaviour. I saw that regardless of HTTP2Sampler.http1_upgrade property the client is sending a mixed of HTTP/1.1 requests and HTTP/1.1 upgrade requests(There is no HTTP/2 requests)(There is also a known issue in this plugin). This was verified by wireshark.

In the above screenshot, the very first request is coming as a HTTP/1.1 upgrade but the next request is a normal HTTP/1.1 request. Also there is a unexpected GO_AWAY from the client to close the established HTTP/2 connection. This is when we make HTTP2Sampler.http1_upgrade property true. When we set it to false, the very first request is normal HTTP/1.1 and the next request is HTTP/1.1 Upgrade. (I used a single user to check this)
Due to these factors, the number of established connections are keep increasing since the ballerina server side does not limit the connections made by the client. So, there is an interruption exception occurred in the client used in the jmeter plugin.
As the core jmeter does not have a HTTP/2 client, it is not advisable to trust the results of these plugins without verifying its behaviour. We recommend to use h2load as a bench marking tool for HTTP/2. You can do a similar stress test using the following script:
#!/bin/bash

URL="http://localhost:8080/hello"
TOTAL_REQUESTS=100000
INITIAL_CONCURRENCY=1
MAX_CONCURRENCY=200
STEP=1

for ((c=$INITIAL_CONCURRENCY; c<=$MAX_CONCURRENCY; c+=$STEP))
do
  echo "Running with concurrency: $c"
  h2load -n $TOTAL_REQUESTS -c $c $URL
  sleep 2  # Pause between steps, adjust as necessary
done

Keeping this issue open, to check the server's behaviour when we get a unexpected GO_AWAY from the client. @dilanSachi is checking on this

From my observation, this GO_AWAY comes after 20s. Looks like the client is just holding and closing it after a set timeout.

Keeping this issue open, to check the server's behaviour when we get an unexpected GO_AWAY from the client. @dilanSachi is checking on this

At the moment, ballerina service does not act to the GO_AWAY from the client. The connection is kept open until client initiates a connection close. This can be seen in the following server trace logs.
[2024-07-03 15:06:02,057] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, correlatedSource: n/a, host:/<IP_ADDRESS>:8080 - remote:/<IP_ADDRESS>:37470] ACTIVE
[2024-07-03 15:06:02,110] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] OUTBOUND SETTINGS: ack=false settings={INITIAL_WINDOW_SIZE=65535, MAX_HEADER_LIST_SIZE=8192}
[2024-07-03 15:06:02,113] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, correlatedSource: n/a, host:/<IP_ADDRESS>:8080 - remote:/<IP_ADDRESS>:37470] OUTBOUND: << Payload could not be decoded >>
[2024-07-03 15:06:02,120] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] INBOUND SETTINGS: ack=false settings={HEADER_TABLE_SIZE=25700}
[2024-07-03 15:06:02,122] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] OUTBOUND SETTINGS: ack=true
[2024-07-03 15:06:02,928] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] INBOUND SETTINGS: ack=true
[2024-07-03 15:06:02,934] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] INBOUND HEADERS: streamId=3 headers=DefaultHttp2Headers[:path: /hello, :method: POST, content-type: text/plain, user-agent: wso2] padding=0 endStream=false
[2024-07-03 15:06:03,929] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] INBOUND DATA: streamId=3 padding=0 endStream=true length=11 data=11B
hellosworld
Payload received hellosworld
1
[2024-07-03 15:06:03,974] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] OUTBOUND HEADERS: streamId=3 headers=DefaultHttp2Headers[:status: 201, content-type: application/json, server: ballerina, date: Wed, 3 Jul 2024 15:06:03 +0530] padding=0 endStream=false
[2024-07-03 15:06:03,980] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] OUTBOUND DATA: streamId=3 padding=0 endStream=true length=17 data=17B
{"hello":"world"}
[2024-07-03 15:06:05,930] TRACE {http.tracelog.downstream} - [id: 0x24bd4c93, L:/<IP_ADDRESS>:8080 - R:/<IP_ADDRESS>:37470] INBOUND GO_AWAY: lastStreamId=3 errorCode=11 length=0 bytes=

However, this can cause issues with malformed clients. @TharmiganK observed something similar to this with the above client. Here, the client opens a connection and do some communication and send a GO_AWAY, but does not close the connection. Then the client opens another connection and do some comm and send a GO_AWAY again. If this happens repeatedly, there will be too many open connections that cannot do any communication and this is a wastage. So we offline discussed to add a feature for Ballerina http2 server that would act upon receiving GO_AWAY frames. The proposed approach is to wait for sometime until the client closes the connection/wait until the existing streams complete the communication and close the connection from the server side.

Improved the behaviour by handling the GO_AWAY from server side with a stale eviction implementation


Rpi5 core-image-sato requires /etc/X11/xorg.conf.d/99-vc4.conf file for GUI to appear (not needed for Rpi4...)

Used yocto/poky and meta-raspberrypi "nanbield" branch to build core-image-sato for MACHINE?= "raspberrypi5".
(as an aside, had to increase boot partition size by adding BOOT_SPACE = "61440" in local.conf to create sd_image...)
Made an SD card and booted Rpi5 - the xserver fails, and the GUI does not appear as expected, and boots to console to login.
After searching for solutions, found the following:
Add below configuration to a file named 99-vc4.conf and save to /etc/X11/xorg.conf.d/ directory:
Section "OutputClass"
  Identifier "vc4"
  MatchDriver "vc4"
  Driver "modesetting"
  Option "PrimaryGPU" "true"
EndSection

Following reboot, the xserver succeeds and the GUI appears as expected.
References:
https://forums.raspberrypi.com/viewtopic.php?t=361902
https://forums.raspberrypi.com/viewtopic.php?p=2159161#p2159161
Seems like this /etc/X11/xorg.conf.d/99-vc4.conf should be added to the recipe.

@PSkeberdis thanks for reporting the issue and also possible patch. Would be great if you can push it for a PR

I  think I just met the same issue, X11 failed, before at commit meta-raspberry :Author: Vivien Didelot<EMAIL_ADDRESS>Date:   Thu Aug 3 01:36:48 2023 -0400
I use almost the same local.conf
my X11 worked well in pi4,
but in pi5 , X sever is failed. let me try this solution.
directly run X, output
root@raspberrypi5:/etc/init.d# X
X.Org X Server <IP_ADDRESS>
X Protocol Version 11, Revision 0
Current Operating System: Linux raspberrypi5 6.6.22-v8-16k #1 SMP PREEMPT Tue Mar 19 17:41:59 UTC 2024 aarch64
Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  smsc95xx.macaddr=D8:3A:DD:DE:27:D6 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyAMA10,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Mar  9 12:45:15 2018
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(EE)
Fatal server error:
(EE) Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
root@raspberrypi5:~# export DISPLAY=:0
root@raspberrypi5:~# chromium  -no-sandbox
[852:852:0515/125839.814911:ERROR:ozone_platform_x11.cc(243)] Missing X server or $DISPLAY
[852:852:0515/125839.814954:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.

right!
the solution works for me
Thanks

Greetings everyone!
Was someone able to configure rotation of the screen? I can't find a way to do it over x11.
Here I'm having issues with xrandr returning xrandr: Failed to get size of gamma for output default.


Add ray to zeroshot_results

Add ray to zeroshot_results, making it ~10x+ faster to compute, with identical results.

Closing in favor of #27 , which avoids code dupe and added loop_utils.py


Fix #310 - Round scaled size on getCroppedCanvas

It's unnecessary to do this. see #310. Thank you!


Perf: Telemtery upload requires CI to pause when exiting each time

Problem
At the moment, our CLI runs for only a few hundred milliseconds for each command to complete. There is some variance, depending on work load, but snappy responsiveness is vital for CLI users. Since the tool is expected to be run somewhere between once and a hand full of times for any use case. Some use cases (like defining a pattern), may have the user using the tool 20-30 times in a row.
For every use, usage telemetry is captured, and is destined to reach the cloud at some point in time in the future.
However, it may not be able to be delivered to the cloud. Depending on a few factors:

Is the network available when the CLI is run?
How much buffered telemetry is there to deliver
How much telemetry can be delivered (in the background) before the CLI process actually exits?

Of course, undelivered telemetry will remain in a buffered file store in the {INSTALLDIRECTORY}/automate/telemetry directory, until it is delivered to the cloud. This buffer has storage limits locally on the machine, and it implements roll-over. (See ServerTelemetryChannel)
There is a potential race condition here.
It is likely that the CLI has already terminated either before or while uploading of the buffered telemetry that was created with the current use of the CLI (session). That means that it is likely that undelivered telemetry will grow on disk and never be delivered to the cloud - since there is not enough time to deliver it successfully (round trip). The local disk limits (that we configure) will mean that generated telemetry will "roll-over" and overwrite older telemetry.
This means that telemetry never get delivered.
Current Solution
At present, to deal with this issue. We enforce a hard 2 sec wait period before allowing the CLI to terminate the process. The hope is that the background delivery process has enough time to connect and deliver all buffered telemetry (for this session and past sessions).
Current Solution Challenges
For a CLI users perspective (and from a Plugin's perspective) adding a 2 sec delay to every command significantly decreases the usability of the CLI. And this is annoying.
Future Solution
Instead of enforcing a 2 sec delay for every use of the CLI.
Perhaps:

We enforce a longer delay (like `5 secs) every ~3 uses. Or some combination of these variables.  (like 10secs for every 8 uses) and notify the user (on stdout) what we are doing as we are doing it.
We find a way to be notified when the delivery of all buffered telemetry is completed and we only wait until that is delivered. However, if offline, we could be introducing other delays determining if online or not.

Evidently TelemetryClient.FlushAsync now does flush all pending telemetry and thus delays as long as needed for each execution of the CLI.


meta-overc: use libsdl2 instead of libsdl

The libsdl had been moved out of oe-core because it is obsolete. It is
safe to switch to libsdl2.
Signed-off-by: Yi Zhao<EMAIL_ADDRESS>

Looks good. I have this staged and will merge it shortly.

merged


Added default connect_timeout  in cluster config

Signed-off-by: Manish Kumar<EMAIL_ADDRESS>Added default value of 5s for  connect_timeout in the cluster config
Fixes #16439

@mk46 looks good, but i would like to check that it really is required
afaict from quick grep all of the config has this setting - so it seems like it is required as @daixiang0 has found - i would like to confirm this 100%
the other thing im wondering is if it isnt marked required already in the api - is the problem  with the (api) docs or should it have some default in the actual code
cc @htuch

@mk46 not sure why exactly - but looks like CI doesnt like this change

I had fixed the CI error in CdsApiImplTest  but not sure about ExampleConfigsTest.

not 100% sure but looking here https://dev.azure.com/cncf/envoy/_build/results?buildId=75433&view=logs&j=8c169225-0ae8-53bd-947f-07cb81846cb5&t=6b0ace90-28b2-51d9-2951-b1fd35e67dec&l=21656
...it looks to me like making this required is also enforcing for xDS (eds) and not just bootstrap config - afaict whatever the situation with bootstrap it looks as though its not currently required for non-boostrap config of clusters

@phlax @htuch  Please take a look.

Can this be tested somehow?

Hi @lizan, I have added a unit test for checking the default value.  Please take a look.

/retest

I am not sure why GCC is failing, which is not related to current changes.

I am not sure why GCC is failing, which is not related to current changes.

its a problem on main - its being worked on here #16484

/retest

docs rendered here https://storage.googleapis.com/envoy-pr/16453/docs/index.html


Dumb question, but why?

Making a terminal in Python, is a bit inefficient. I don't get the point of doing this anyway, no offense tho. Python is a really slow language and isn't really easy to debug. I would make a terminal if I used C/C++ as the main language.

I was trolling :\

May I convert this into a cross-platform Rust-based terminal as a slight "improvement"? I'll let you know about the progress. (it's gonna take long since developing a windows app from macos is complicated but i'll try it with wine)

@therealandreww sure


[doc] metric learning tutorial is missing

for metric learning task, only config files is provided, but detailed tutorials should be more helpful

same question


In depth darkmode

Applied dark theme to the following elements :

nutrition_level_card.dart
labels_expandable.dart
nutriscore_expandable.dart
product_processing_expandable.dart
smooth_product_edit.dart
smooth_product_found.dart
smooth_product_loading.dart
smooth_product_not_found.dart
smooth_product_thanks.dart
personalized_ranking_page.dart
product_page.dart
product_query_page.dart
smooth_navigation_bar.dart
smooth_expandable_card.dart
smooth_search_bar.dart

Theme has been updated slightly.

Screenshots

I'll check it out right away

I'll check it out right away

Here is the change from bodyText1 to bodyText2. Now we just have to refresh the design guidelines. But that's a job for another PR. Thanks for your help.

Here is the change from bodyText1 to bodyText2. Now we just have to refresh the design guidelines. But that's a job for another PR. Thanks for your help.

Hey @M123-dev looks like your commit changes a lot more than just a bodyText1 to bodyText2.
There are a lot of style parameter being removed, I don't know if it was made on purpose, can you look into it? :slightly_smiling_face:

Hey @M123-dev looks like your commit changes a lot more than just a bodyText1 to bodyText2.
There are a lot of style parameter being removed, I don't know if it was made on purpose, can you look into it? :slightly_smiling_face:

I checked it again, I didn't notice anything in itself, I commented on two big changes again. If you notice something, or you want to question something else, feel free to ask again

I checked it again, I didn't notice anything in itself, I commented on two big changes again. If you notice something, or you want to question something else, feel free to ask again

This occurs in a lot of other places, is that normal?

This occurs in a lot of other places, is that normal?

Oh, now I know what you mean. So yes that was the plan.
Above in the PR @monsieurtanuki asked if there is a default textstyle and you said that you tried it but there is none.
Thereupon I looked it up and found out that bodyText2 is the default parameter, not bodyText1.
In your test you didn't see any difference, because bodyText2 changed between black and a dark accent black.
bodyText2 had no use at the moment anyway, so I sat down and transferred the default style from bodyText1 [can be found here] to bodyText2.
This has now the effect, that every text without specified style gets the style of bodyText2.
Therefore every
bodyText1 does not exist anymore and is replaced with bodyText2.
but since this is now standard:
style: Theme.of(context).textTheme.bodyText2,
is now also obsolete.
only in the places where this is edited with .copyWith, I have left the style.
I see my little explanation above was not quite so understandable 🔢

Oh, now I know what you mean. So yes that was the plan.
Above in the PR @monsieurtanuki asked if there is a default textstyle and you said that you tried it but there is none.
Thereupon I looked it up and found out that bodyText2 is the default parameter, not bodyText1.
In your test you didn't see any difference, because bodyText2 changed between black and a dark accent black.
bodyText2 had no use at the moment anyway, so I sat down and transferred the default style from bodyText1 [can be found here] to bodyText2.
This has now the effect, that every text without specified style gets the style of bodyText2.
Therefore every
bodyText1 does not exist anymore and is replaced with bodyText2.
but since this is now standard:
style: Theme.of(context).textTheme.bodyText2,
is now also obsolete.
only in the places where this is edited with .copyWith, I have left the style.
I see my little explanation above was not quite so understandable 🔢

Oh now I understand, great thank you for the clarification :smile:
Merging now

Oh now I understand, great thank you for the clarification :smile:
Merging now

No problem, rather thank you for helping. I just think we should add a comment in the file in the future

No problem, rather thank you for helping. I just think we should add a comment in the file in the future


QA & Cert: RATA Run DTO Checks

The scope of this ticket is to address the following RATA Run DTO validations
QA and Certification Data Checks

[x] RATA-27 - CEM Value Valid (Results A, B)
[x] RATA-63 - Barometric Pressure Valid
[x] RATA-64 - Static Stack Pressure Valid (Results A, B) (Note: Has inconsistent field names)
[x] RATA-65 - Percent CO2 Valid
[x] RATA-66 - Percent O2 Valid

Test Case: TC1042
Test Passed


Detect language automatically according to browser preferences

I've noticed that my main browser language is PT-BR but game instance is always loaded in english due to this validation:

messages.languageActive.hasOwnProperty(requestLang)

Because portuguese is added as pt-br and requestLang returns "pt".
Changing it through settings seems fine. I will create a fork to pull request this fix.

#182