Should user be allowed to modify default vmgroup attributes

Currently user can change access rules of default vmgroup.
Operations allowed on default vmgroup are as follows:
E.g.
1. Change --allow-create right to False/True,
2. Set max-volume-size
We have number of tests which play with configuration of default vmgroup. Need some clarity before moving ahead with test automation for default vmgroup tests.
What is our official position regarding manipulating default vmgroup? Should these operations be allowed ?
===================
Operations performed on default vmgroup their output are as follows:

Change allow-create to false for _DEFAULTtenant.

[root@sc-rdops-vm17-dhcp-4-8:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vmgroup access ls --name=_DEFAULT
Datastore  Allow_create  Max_volume_size  Total_size
---------  ------------  ---------------  ----------
_ALL_DS    True          Unset            Unset
_VM_DS     True          Unset            Unset

[root@sc-rdops-vm17-dhcp-4-8:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vmgroup access set --name=_DEFAULT --datastore=_VM_DS --allow-create=False
vmgroup access set succeeded
[root@sc-rdops-vm17-dhcp-4-8:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vmgroup access ls --name=_DEFAULT
Datastore  Allow_create  Max_volume_size  Total_size
---------  ------------  ---------------  ----------
_ALL_DS    True          Unset            Unset
_VM_DS     False         Unset            Unset

Set --volume-maxsize for _DEFAULT tenant to 2GB

[root@sc-rdops-vm04-dhcp-100-33:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vmgroup access set --name=_DEFAULT --datastore=_VM_DS --allow-create=True --volume-maxsize=2GB
vmgroup access set succeeded
[root@sc-rdops-vm04-dhcp-100-33:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py vmgroup access ls --name=_DEFAULT
Datastore  Allow_create  Max_volume_size  Total_size
---------  ------------  ---------------  ----------
_ALL_DS    True          Unset            Unset
_VM_DS     True          2.00GB           Unset

[root@sc-rdops-vm04-dhcp-100-33:~]

May have had this discussion earlier, default vmgroup is best left unchanged - its a canned configuration thats not modifiable. ANy flexibility in attributes must be only in vmgroups created by the user. The DEFAULT vmgroup should really never be used at all to store workload data volumes.

As Govindan has highlighted, should we leave default vmgroup unchanged?
/ CC @msterin @pdhamdhere @shaominchen @tusharnt

I had this discussion with Mark and Prashant before. My preference was that we should not allow user to modify DEFAULT vmgroup. Even after Mark had explained the design intent to me, I was still not fully convinced. My personal opinion is - making DEFAULt vmgroup same as others doesn't gain much, but has caused too many complexities and we have to deal with a lot of unexpected corner cases.
Since multi-tenancy is currently an experimental feature, I don't think we want to change this design right now. But in the future after we fix the open issues and make it as an official feature, I think it makes more sense to make DEFAULT vmgroup unmodifiable. I tend to agree with Govindan that the DEFAULT vmgroup should really never be used at all to store workload data volumes. It's just a convenient default configuration for customers to try out the cool features quickly without bothering to deal with tenancy.

Can you elaborate on why do you think it should be a special immutable group. what use cases it will address and  *what specifically are the complications you refer to ?
I am not sure what would be the reason to even have "default" group if it's immutable, and how would you address the use cases like "I want all my dev Vms to be on  , and allocate 1/2 of DS1 capacity to them, and everyone else goes to DS1, which is slow, and we allocate 1/3 capacity them" ?  Feel free to take it offline though

We should definitely take this offline as this is a complicated discussion :) I will just put some comments here as a memo:
I don't believe we even need default vmgroup at all if vDVS starts with multi-tenancy feature from the beginning. We started without any access control, and later added this feature based on customer feedback, but still want to keep it simple for new customers to try out this product, and also maintain a seamless user experience for existing customers to transition from old mode (no access control) to new mode (with access control). Default vmgroup is a great idea/solution that addressed all these requirements.
However, allowing user to modify system-predefined default vmgroup, or mixing default vmgroup with user-defined vmgroup is not really a good idea. We have already run into quite some awkward scenarios (@lipingxue) where the implementation becomes very complicated and buggy. I don't want to spend time to list all those issues right now, but we can definitely discuss in the future.
In my opinion, default vmgroup should only be used as a sandbox in which user can try out vDVS. After initial experiment, once user starts to use vDVS in production, the default vmgroup should simply be locked down. All production volumes should be created in user-defined vmgroups. The vmgroup design should provide enough flexibility to support all kinds of access control scenarios without default vmgroup.

However, allowing user to modify system-predefined default vmgroup, or mixing default vmgroup with user-defined vmgroup is not really a good idea.

Why ? You need to spell out use cases. Implementation we can improve.

All production volumes should be created in user-defined vmgroups.

Why ? Other than exiting implementation complexities, I do not hear any arguments. I understand your view but it's hard to agree or disagree when there are no arguments

I don't think there are any use cases we can't support without default vmgroup. Let's take your use case above as an example (BTW, I think you meant "everyone else goes to DS2", right?). We can support that easily by introducing regular expressions for VM names. Currently our logic does exact match between vm_uuid and tenant, which is really unusual in a typical algorithm of authorization engine. Just introducing one more level of indirection (i.e. vm_uuid -> vm_name -> tenant), we will get a more flexible authorization algorithm and make the problem easier to resolve.
I really don't want to get into more detailed discussions on this topic right now, so I will stop here :)

The issue is also this,

To view access attrs for the DEFAULT tenant the DB has to be there (auth_api.py:_tenant_access_ls()). Because, when the DB is created, the default vmgroup is created in it with the _VM_DS and _ALL_DS entries.
But the other parts of the code assume these values (VM_DS) which seems inconsistent.
So, if we want to be able to update default vmgroup attributes then we need the DB to persist that or add code to hold that in memory which is lost across restarts of the plugin.

These fixes can be done but do we want to do that now with the number of tests that are pending to be developed. I'd suggest lets document these and fix only whats obviously buggy.
If it takes more code to fix the bug (reverting max/total volume sizes) then lets disallow setting these in the first place.

Please see update in #1396, the changes to get the CLI commands all working reliably with the DEFAULT vmgroup are much more and  unnecesary (can create more bugs if not fixed correctly). A refactoring exercise would be needed to ensure the code can handle requests on the DEFAULT vmgroup.
For example, the auth-api code expects that a DB exist in order to access/update any vmgroup. Changing that seems to need more changes in a trail of functions. Preferrably this should be a refactoring exercise after identifying all the changes. Possbly after the present set of test functions are all developed.

@shaominchen, @govint - let's finalize the behavior and make it final  (I thought we did have agreement the last time around though), before.making decisions on simply cutting it.

Related to #1441

This is more a question vs. a bug needing a code fix. Closing and can be taken offline.

Until we come to conclusion on whether properties of default vmgroup are modifiable, I think we should leave this issue open. Reopening this issue.

Its not a P0 issue as there isn't going to be any code changes and I'm not making this decision either. Right now issues that depend on this decision are moved to "Future" #1520  for example.

Right now issues that depend on this decision are moved to "Future" #1520 for example.

#1520 is for the test automation being blocked on this issue.

What is our official position regarding manipulating default vmgroup? Should these operations be allowed ?

Reference: https://github.com/vmware/docker-volume-vsphere/issues/1397#issue-235356286
I guess this is opened to get closure before GA. If we'll agree to treat _DEFAULT the same as "user created named group" then we should close this as invalid.
@govint if you are agree then please close as invalid; pulling back to current sprint to decide.

Its agreed that removing the default vmgroup is ok, but attendant bugs aren't and those must be fixed.


Add configuration options for Windows in the Telegraf Installation Instructions page

as a windows user
when i create a telegraf config and want to install it on windows
then i would like to see instructions for running telegraf on windows.
once we have https://github.com/influxdata/influxdb/issues/15279
we will need to update the telegraf install instructions modal to allow the user to view windows installation instructions:

see this docs issue for the instructions: https://github.com/influxdata/docs-v2/issues/493

bump


Constructor parameters in internal classes get prefixed.

Bug report
Input code
class Measure {
    height: number;

    constructor(public width: number, public ascent: number, public descent: number) {
        this.height = ascent + descent;
    }
}

export class Foo {}

Expected output
class Measure {
      constructor(width, ascent, descent) {
              this._internal_width = width;
              this._internal_ascent = ascent;
              this._internal_descent = descent;
              this._internal_height = ascent + descent;
       }
}

export class Foo {
}

Actual output
class Measure {
      constructor(_internal_width, _internal_ascent, _internal_descent) {
              this._internal_width = _internal_width;
              this._internal_ascent = _internal_ascent;
              this._internal_descent = _internal_descent;
              this._internal_height = ascent + descent;
       }
}

export class Foo {
}

Additional context
Reproducible if the code above is added as input.ts to the test directory in this repo and npm run test is started.

I confirm it's a bug.

The fix is just published in 0.7.0 version.


socket.io 1.x.x is not supported

Please add support for latest socket.io.

Bump, without the 1.x support it's absolutely useless, even though it's the most starred Socket.io Java client on GitHub


Release cobigen-textmerger-v7.0.0

This issue has been automatically created. It serves as a container for all release related commits

Automatically processed.
The decisions taken by the developer and the context of the decisions throughout the script:

User confirmed that tests are running on CI and the build is not failing.


[3.x] Revert "Fix ViewportPreview upside-down in 3.x."

This reverts commit 1426df66a8397f3f03aaa541399054f0487fc8a1.
ViewportPreview should show what the ViewportTexture renders and it is upside-down by default. An extra V-flip makes the Render Target > V Flip property confusing.
Fixes #57246

Thanks!

Cherry-picked for 3.4.3.

Is non 3d stuff supposed to be upside down as well? https://i.imgur.com/PXEXTjg.png richtextlabel on 3.4.4 not readable without flipping.

Yes, it's how Viewport works: https://docs.godotengine.org/en/stable/classes/class_viewport.html#description
You can enable Render Target > V Flip to get the correct orientation.


GH-35961: [C++][FlightSQL] Accept Protobuf 3.12.0 or later

Rationale for this change
We can use optional with Protobuf 3.12.0 by specifying --experimental_allow_proto3_optional explicitly.
If we accept Protobuf 3.12.0 or later for Flight SQL, we can use system Protobuf on Ubuntu 22.04. Because Ubuntu 22.04 ships Protobuf 3.12.4.
What changes are included in this PR?
Specify  --experimental_allow_proto3_optional explicitly when Protobuf is < 3.15.0.
Are these changes tested?
Yes.
Are there any user-facing changes?
Yes.

Closes: #35961

@github-actions crossbow submit ubuntu-jammy-* ubuntu-kinetic-*

@github-actions crossbow submit test-ubuntu-22.04-cpp

is the failure related?
 /build/apache-arrow-13.0.0.dev186/cpp/src/arrow/flight/sql/server.cc:364:20: error: could not convert ‘any.google::protobuf::Any::PackFrom((* & message))’ from ‘void’ to ‘bool’
  364 |   if (!any.PackFrom(message)) {
      |        ~~~~~~~~~~~~^~~~~~~~~
      |                    |
      |                    void
/build/apache-arrow-13.0.0.dev186/cpp/src/arrow/flight/sql/server.cc:364:20: error: in argument to unary !

Oh, it's related. I'll take a look at it.

@github-actions crossbow submit ubuntu-jammy-* ubuntu-kinetic-* debian-bullseye-* test-ubuntu--cpp test-debian--cpp

@kou are the issues found on the RC1 failed jobs related to the new Protobuf version on MacOS for AMD and ARM64 supposed to be solved with this one?
 /Applications/Xcode_14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../release/libarrow.a(util_avx2.cc.o) has no symbols
ld: illegal thread local variable reference to regular symbol __ZN6google8protobuf8internal15ThreadSafeArena13thread_cache_E for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

A couple of examples:

verify-rc-source-python-macos-arm64
verify-rc-source-python-macos-amd64

To give more context as shared with Zulip, I think this is due to the new version of protobuf on hombrew that was merged yesterday:
https://github.com/Homebrew/homebrew-core/pull/132957 and https://github.com/Homebrew/homebrew-core/pull/132988

I think that it's not related to the problem.
I've opened #35987. See it for details.

@github-actions crossbow submit ubuntu-jammy-* ubuntu-kinetic-* debian-bullseye-* test-ubuntu--cpp test-debian--cpp-*

@github-actions crossbow submit ubuntu-focal-* debian-bookworm-*

+1


Unable to access API via Docker

Hi,
When I run my Swaggered project via Spring boot I can access the Swagger UI page via http://localhost:9080/swagger-ui.html
If I Dockerize my app and then run it. and then try to hit the same end point I get the error:
Whitelabel Error Page

This application has no explicit mapping for /error, so you are seeing this as a fallback.

Wed May 27 16:39:52 UTC 2015
There was an unexpected error (type=Internal Server Error, status=500).
class path resource [META-INF/resources/swagger-ui.html] cannot be resolved in the file system for resolving its last-modified timestamp

Any ideas what the issue might be?
Thanks
Nick

No idea frankly. If I were to guess the port mapping on your docker image isn't right

Turns out that if I use a Dockerfile to create the image with the Spotify docker plugin, Swagger works fine. It was only a problem if set the base image etc in my POM file directly.
FROM java:8
VOLUME /tmp
ADD content-link-service-*.jar app.jar
RUN bash -c 'touch /app.jar'
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

Nick


Unable to import the thread pool

I am unable to use the Threadpool. Getting compilation error. Any help?
my cargo.toml is as follows
actix-rt = "2.8.0"
actix-web = "4.3.0"
bytes = "1.4.0"
env_logger = "0.10.0"
json = "0.12"
log = "0.4.17"
log4rs = "1.2.0"
aws-config = "0.54.1"
aws-sdk-s3 = "0.24.0"
tokio = { version = "1.26.0", features = ["full"] }
async-trait = "0.1.64"
aws-smithy-http = "0.54.4"
self-meter = "0.6.0"
serde = { version = "1.0.126", features = ["derive"] }
serde_json = "1.0.64"
# cmake = "0.1.49"
rdkafka = { version = "0.29.0", features = ["cmake-build"] }
# kafka = "0.9.0"
uuid = {version = "1.3.0" , features = ["v4" , "fast-rng", "macro-diagnostics" ] }
futures = "0.3.27"

I am trying to use the Threadpool in my rust code src/utils.rs ON adding the statement to my rust code
use futures::executor::ThreadPool;

I get the below error
unresolved import `futures::executor::ThreadPool`
no `ThreadPool` in `executor`rustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic%20message%20%5B0%5D?0#file%3A%2F%2F%2FUsers%2Fravichandra.chitrapu%2Fpoc%2Frust_fair_scheduler%2Fsrc%2Faws_utils.rs)

it needs thread-pool feature
https://docs.rs/futures/latest/futures/executor/struct.ThreadPool.html

This type is only available when the thread-pool feature of this library is activated.

nice if docs can be updated. Thank you.


A pre-computed kernel

In my previous work I've encountered the case where you want to pre-compute a gram matrix (which has fixed hypers) and load it into some GP software without implementing all the code you used in that software. The solution I came to was to store the gram matrix and make the data inputs integer indeces into that matrix. then K(i,j) = K_{i,j} . Do we think this is of general interest?  Is the integer index trick the best way to do it?

In GPy, there's a 'Fixed' kernel, which just returns a designated matrix (times a scalar parameter).
The problem is, what to do at predict time? Presumably you just want to ignore this kernel when predicting?
I think GPy's fixed kernel is confusing for users.

I guess you would upload those elements of the matrix too :) . Consider a case I've come across where the data inputs are actually a large set of graphs. We may not want to have to deal with that sort of complex data structure in GPflow. I can always implement it myself but its just a question of whether we think it is core and more of use to others than a hindrance.

Ah. Now I have had a think about this sort of thing. What I would suggest, is that the 'X' in GPflow becomes some integer values, and the kernel stores a big lookup table. so the kernel would look like
class LookupKern(GPflow.kernels.Kern):
    def __init__(self, K):
        self._K = K
    def K(X, X2):
            return self._K[X, X2]

big_K = np.load(...)
k = LookUpKern(big_K)

X = np.random.randint(0, big_K.shape[0], (10, 1))
Y = np.foo

Then, if you wanted to combine this kernel with other kernels, you'd use separate columns of X, and the active_dims feature of the kernels.
In this case, I think it's core, and a definite upgrade on GPy.kern.Fixed.

Just some feedback which may be of use - models such as the PANAMA model use fixed kernels so this enhancement would be useful when trying to implement such models.
PANAMA is a GPLVM model that includes known confounding factors

OK. I'm now thesis writing so I will open this one up if someone fancies it.

Note: This is already pretty-much implemented in the Coregion kernel. The difference in that in the Coregion kernel the positive-definite matrix can be optimized (sampled), whereas this proposal is for a fixed matrix.


ENH: Speed up time frequency code

I adapted @jona-sassenhagen's example to make it smaller:
import numpy as np
import time
import mne

sfreq = 128.
n_epochs, n_ch, n_time = 144, 29, 1921
data = np.zeros((n_epochs, n_ch, n_time))
info = mne.create_info(n_ch, sfreq, 'eeg')
epochs = mne.EpochsArray(data, info)

t0 = time.time()
mne.time_frequency.tfr_morlet(epochs, [1, 2], n_cycles=3, use_fft=True,
                              n_jobs='cuda', verbose=True)
print(time.time() - t0)

Using CUDA made it slower. I think we should:

Refactor our overlap-add filtering code to allow multiple filters applied to the same data (we do this in CWT).
Refactor our overlap-add filtering code to work with complex data (morlet coefs).
refactor _cwt (the core of most TFR functions) to use overlap-add filtering. That should be faster on CPU already.
deprecate use_fft (it should always be faster)
Add support for CUDA (should be trivial after the _cwt refactoring)

I like that you say "we".

deprecate use_fft (it should always be faster)

Oh, that sounds like a no brainer. Fewer options is better.

I think with faster FFTs available via pocketfft in SciPy and NumPy nowadays this is probably less critical. Though perhaps we should someday change the default use_fft=True since it's probably always faster nowadays.


HTML

HTML
user story
As a bootcamp student
I want the prework notes to be structured on a webpage
so that
I can easily find and read the information
acceptance criteria
GIVEN a prework stufy guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Javascript, and GIT with associated notes listed

HTML added


Secrets

The link https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md is broken

Hey @brodier Could you provide the page in which you found this broken link!

/triage needs-infomation
/language e

/language en
/triage needs-information

The broken link is on the following page:
https://kubernetes.io/fr/docs/concepts/configuration/secret/

/aasign

/assign

@sftim the language is not en, it's fr.
/language fr

/remove-language en

/triage accepted
/priority backlog

/retitle Stale link in French concept page “Secrets”


[Feature Request] Allow keyboard navigation

As subj says - allow users to use keyboard navigation and action in lists (like 'All items' on 'Items' page), dropdowns (like 'Main Skill' dropdown on the left bar), popups (delete confirmation window).

Finally got around to working on this; the changes in 1.2.10 should be a major improvement.

Thanks, will check it out!
Got distracteda a bit from poe by gwent :D

This one can also be closed, current state looks fine for me.


Text control is in the ft.DataColumn ,how to set the Text control's  margin

Text control is in the ft.DataColumn ,how to set the Text control's  margin,eg:

Looking forward to your answer，thanks


Removed unwanted strikethrough effect from Select

Select doesn't reserve enough space for the label unless you specify the label prop

Indeed, nice catch.
Why did you rename defaultThemes.ts though?

It was a while ago, sorry, but I think it was a lint error.   Maybe a windows/linux thing?  I'm on windows
If you look here its referenced as DefaultThemes
https://github.com/Zenoo/mui-theme-creator/blob/master/src/components/SavedThemes/DefaultThemesComponent.tsx#L6
Another thing I had to change (but did not add to PR) was removing the word "bash" from the yarn deploy command.   Not sure if that's helpful or hurtful to anyone else.   But after that I was able to build/deploy my fork

It would be better to change the import statement than to rename the file itself then, it's less likely to break things down the line that way.

I reverted it and I could still build.   Must be an "intellisense only" error in VS Code.   But not relevant to this PR so someone else can fix those later if needed.

Thanks for your contribution !


update sample app model and inference activity input

Resolving #413

@abramvandergeest I updated the cnn sample that leverages the flogo api to reflect the input object change from []map[string]interface{} to []interface{} however have not tested that it works as expected...

LGTM


Marking the Memory Area with Color Explicitly

Is your feature request related to a problem? Please describe.
Hello,
I am very grateful for your efforts, which have enabled the use of memory view in VSCode. While studying C language using CLion, I gained many insights through its memory view feature. I am delighted to have this functionality now in my preferred editor, VSCode.
However, there's one feature I feel is missing, and I apologize if I've overlooked it since I haven't used it extensively yet.
Currently, in memview's memory view, when tracking a specific variable in memory, it highlights the changed bytes in green when the values in that memory space change.

However, when tracking the memory space itself where &a is located, it doesn't seem to color-mark the position or size of &a.

Describe the solution you'd like
In CLion, for instance, the memory space occupied by &a is colored like below.

it makes easier to use the memory view. It would be greatly beneficial, especially for beginners like me, if such a feature were added to memview as well. In CLion, the tracked memory area is highlighted in light green, and changed bytes are marked in orange like below.

Even without this feature, memview is very helpful to me, and I hope it continues to be widely used and developed further. Thank you for creating such an amazing extension.🙇♂

Thank you for the kind words.

However, when tracking the memory space itself where &a is located, it doesn't seem to color-mark the position or size of &a.

The method for highlighting is always the same. Can you make sure your address ranges are correct. I see totally different ranges between all the screenshots so, it is hard for me to tell what is going on.
The way highlighting works is that every time the program pauses for whatever reason, we do a delta. So, the history is only one level deep. Let's say you do two single steps kinda fast, you may not see the changed bytes at all. Especially if you single step at an assembly level. Please let me know the steps to reproduce the issue.
I can see that our decoded bytes look a little bit messy. But instead of a dot, I still find it more useful to know what character it represents. I am a C/C++ desktop and embedded programmer myself.
Finally, the colors chosen are actually from your VSCode theme. I didn't pick or hardcode them.


Why speed does not increase with AWQ

Why speed does not increase with AWQ? I have a model gemma 2 9B. With one A100.
with float16 the benchmark is 4267.62 tokens per second
with awq 4 bit the benchmark is 4963.73 tokens per second
I expected that with awq i take 16000 tokens per second.

@byshiue
python3 tensorrtllm_backend/tools/inflight_batcher_llm/benchmark_core_model.py -i grpc --request-rate 500 --max-input-len 3000 --num-requests 50000 --decoupled --exclude-input-in-output dataset --dataset dataset.json --tokenizer-dir data/merged_model

Please share the scripts to build the engine.

@byshiue
    "quantization_config": {
      "model_dir": "/app/data/merged_model",
      "dtype": "bfloat16",
      "qformat": "int4_awq",
      "output_dir": "/app/data/tllm_checkpoint",
      "awq_block_size": "128",
      "calib_size": "32",
      "calib_dataset": "/app/src/quantization/dataset"
    },
    "build_config": {
      "checkpoint_dir": "/app/data/tllm_checkpoint",
      "output_dir": "/app/model_repository/tensorrt_llm/1",
      "gemm_plugin": "auto",
      "max_batch_size": "32",
    }

and:
python3 quantization/quantize.py + {quantization_config}
trtllm-build + {build_config}

For BS 32, the acceleration of INT4 AWQ is not obvious. It also depends on your input lengths and output lengths. But it is not surprised that there is no speedup.


Bug report

Loading...
(0/6) Loading siad...
(1/6) Loading gateway...
(2/6) Loading consensus...
(3/6) Loading transaction pool...
(4/6) Loading wallet...
(5/6) Loading host...
(6/6) Loading renter...
Finished loading in 0.420833647 seconds
Wallet: scanned to height 6024...
Wallet: scanned to height 9137...
Wallet: scanned to height 11236...
Wallet: scanned to height 14982...
Wallet: scanned to height 17873...
Wallet: scanned to height 20450...
Wallet: scanned to height 22690...
Wallet: scanned to height 23463...
Wallet: scanned to height 26266...
Wallet: scanned to height 28509...
Wallet: scanned to height 30486...
Wallet: scanned to height 32510...
Wallet: scanned to height 33396...
Wallet: scanned to height 34034...
Wallet: scanned to height 34371...
Wallet: scanned to height 34555...
Wallet: scanned to height 34662...
Wallet: scanned to height 34776...
Wallet: scanned to height 34895...
Wallet: scanned to height 34998...
Wallet: scanned to height 35156...
Wallet: scanned to height 35323...
Wallet: scanned to height 35727...
Wallet: scanned to height 36118...
Wallet: scanned to height 36429...
Wallet: scanned to height 36789...
Wallet: scanned to height 37023...
Wallet: scanned to height 37351...
Wallet: scanned to height 37576...
Wallet: scanned to height 38100...
Wallet: scanned to height 38485...
Wallet: scanned to height 38627...
Wallet: scanned to height 38830...
Wallet: scanned to height 39199...
Wallet: scanned to height 39382...
Wallet: scanned to height 39572...
Wallet: scanned to height 39785...
Wallet: scanned to height 40028...
Wallet: scanned to height 40445...
Wallet: scanned to height 40879...
Wallet: scanned to height 41608...
Wallet: scanned to height 41706...
Wallet: scanned to height 41781...
Wallet: scanned to height 42000...
Wallet: scanned to height 42224...
Wallet: scanned to height 42423...
Wallet: scanned to height 43427...
Wallet: scanned to height 43830...
Wallet: scanned to height 44293...
Wallet: scanned to height 44365...
Wallet: scanned to height 44489...
Wallet: scanned to height 44614...
Wallet: scanned to height 44741...
Wallet: scanned to height 44896...
Wallet: scanned to height 45031...
Wallet: scanned to height 45207...
Wallet: scanned to height 45450...
Wallet: scanned to height 45615...
Wallet: scanned to height 45830...
Wallet: scanned to height 46134...
Wallet: scanned to height 46734...
Wallet: scanned to height 47196...
Wallet: scanned to height 47497...
Wallet: scanned to height 47646...
Wallet: scanned to height 48069...
Wallet: scanned to height 48694...
Wallet: scanned to height 49477...
Wallet: scanned to height 50546...
Wallet: scanned to height 51053...
Wallet: scanned to height 51684...
Wallet: scanned to height 52993...
Wallet: scanned to height 53387...
Wallet: scanned to height 53768...
Wallet: scanned to height 54195...
Wallet: scanned to height 54513...
Wallet: scanned to height 55475...
Wallet: scanned to height 56306...
Wallet: scanned to height 56895...
Wallet: scanned to height 57721...
Wallet: scanned to height 58738...
Wallet: scanned to height 60133...
Wallet: scanned to height 60564...
Wallet: scanned to height 60979...
Wallet: scanned to height 61414...
Wallet: scanned to height 61791...
Wallet: scanned to height 62125...
Wallet: scanned to height 62530...
Wallet: scanned to height 62939...
Wallet: scanned to height 63313...
Wallet: scanned to height 63674...
Wallet: scanned to height 64037...
Wallet: scanned to height 64413...
Wallet: scanned to height 64801...
Wallet: scanned to height 65171...
Wallet: scanned to height 65566...
Wallet: scanned to height 65849...
Wallet: scanned to height 66157...
Wallet: scanned to height 66496...
Wallet: scanned to height 66789...
Wallet: scanned to height 67197...
Wallet: scanned to height 67575...
Wallet: scanned to height 67955...
Wallet: scanned to height 68315...
Wallet: scanned to height 68670...
Wallet: scanned to height 69055...
Wallet: scanned to height 69447...
Wallet: scanned to height 69864...
Wallet: scanned to height 70205...
Wallet: scanned to height 70512...
Wallet: scanned to height 70825...
Wallet: scanned to height 71161...
Wallet: scanned to height 71488...
Wallet: scanned to height 71829...
Wallet: scanned to height 72170...
Wallet: scanned to height 72542...
Wallet: scanned to height 72892...
Wallet: scanned to height 73227...
Wallet: scanned to height 73577...
Wallet: scanned to height 73934...
Wallet: scanned to height 74294...
Wallet: scanned to height 74629...
Wallet: scanned to height 74977...
Wallet: scanned to height 75315...
Wallet: scanned to height 75637...
Wallet: scanned to height 75972...
Wallet: scanned to height 76278...
Wallet: scanned to height 76633...
Wallet: scanned to height 76986...
Wallet: scanned to height 77387...
Wallet: scanned to height 77834...
Wallet: scanned to height 78303...
Wallet: scanned to height 78699...
Wallet: scanned to height 79069...
Wallet: scanned to height 79429...
Wallet: scanned to height 79777...
Wallet: scanned to height 80177...
Wallet: scanned to height 80530...
Wallet: scanned to height 80632...
Wallet: scanned to height 80906...
Wallet: scanned to height 81221...
Wallet: scanned to height 81309...
Wallet: scanned to height 81564...
Wallet: scanned to height 81890...
Wallet: scanned to height 82227...
Wallet: scanned to height 82562...
Wallet: scanned to height 82907...
Wallet: scanned to height 83306...
Wallet: scanned to height 83715...
Wallet: scanned to height 84075...
Wallet: scanned to height 84445...
Wallet: scanned to height 84822...
Wallet: scanned to height 85209...
Wallet: scanned to height 85585...
Wallet: scanned to height 85944...
Wallet: scanned to height 86060...
Wallet: scanned to height 86197...
Wallet: scanned to height 86385...
Wallet: scanned to height 86540...
Wallet: scanned to height 86779...
Wallet: scanned to height 87075...
Wallet: scanned to height 87330...
Wallet: scanned to height 87698...
Wallet: scanned to height 87864...
Wallet: scanned to height 88044...
Wallet: scanned to height 88297...
Wallet: scanned to height 88686...
Wallet: scanned to height 89116...
Wallet: scanned to height 89462...
Wallet: scanned to height 89827...
Wallet: scanned to height 90289...
Wallet: scanned to height 90680...
Wallet: scanned to height 91109...
Wallet: scanned to height 91597...
Wallet: scanned to height 91980...
Wallet: scanned to height 92085...
Wallet: scanned to height 92302...
Wallet: scanned to height 92703...
Wallet: scanned to height 93124...
Wallet: scanned to height 93556...
Wallet: scanned to height 93967...
Wallet: scanned to height 94361...
Wallet: scanned to height 94811...
Wallet: scanned to height 95300...
Wallet: scanned to height 95711...
Wallet: scanned to height 96112...
Wallet: scanned to height 96536...
Wallet: scanned to height 96846...
Wallet: scanned to height 97211...
Wallet: scanned to height 97503...
Wallet: scanned to height 97558...
Wallet: scanned to height 97624...
Wallet: scanned to height 97718...
Wallet: scanned to height 97892...
Wallet: scanned to height 98121...
Wallet: scanned to height 98408...
Wallet: scanned to height 98578...
Wallet: scanned to height 98802...
Wallet: scanned to height 99069...
Wallet: scanned to height 99326...
Wallet: scanned to height 99550...
Wallet: scanned to height 99666...
Wallet: scanned to height 99790...
Wallet: scanned to height 99954...
Wallet: scanned to height 100062...
Wallet: scanned to height 100166...
Wallet: scanned to height 100259...
Wallet: scanned to height 100430...
Wallet: scanned to height 100628...
Wallet: scanned to height 100732...
Wallet: scanned to height 100809...
Wallet: scanned to height 100880...
Wallet: scanned to height 100953...
Wallet: scanned to height 101038...
Wallet: scanned to height 101138...
Wallet: scanned to height 101318...
Wallet: scanned to height 101564...
Wallet: scanned to height 101786...
Wallet: scanned to height 102008...
Wallet: scanned to height 102180...
Wallet: scanned to height 102342...
Wallet: scanned to height 102508...
Wallet: scanned to height 102685...
Wallet: scanned to height 102889...
Wallet: scanned to height 103103...
Wallet: scanned to height 103301...
Wallet: scanned to height 103504...
Wallet: scanned to height 103662...
Wallet: scanned to height 103809...
Wallet: scanned to height 103947...
Wallet: scanned to height 104116...
Wallet: scanned to height 104338...
Wallet: scanned to height 104567...
Wallet: scanned to height 104766...
Wallet: scanned to height 105103...
Wallet: scanned to height 105373...
Wallet: scanned to height 105638...
Wallet: scanned to height 105949...
Wallet: scanned to height 106265...
Wallet: scanned to height 106485...
Wallet: scanned to height 106701...
Wallet: scanned to height 106873...
Wallet: scanned to height 107062...
Wallet: scanned to height 107158...
Wallet: scanned to height 107269...
Wallet: scanned to height 107378...
Wallet: scanned to height 107578...
Wallet: scanned to height 107792...
Done!
goroutine 1 [running]:
runtime/debug.Stack(0x1043857, 0x0, 0xc420fdf5f8)
/usr/local/go/src/runtime/debug/stack.go:24 +0x79
runtime/debug.PrintStack()
/usr/local/go/src/runtime/debug/stack.go:16 +0x22
github.com/NebulousLabs/Sia/build.Critical(0xc420fdf948, 0x1, 0x1)
/home/jrh/go/src/github.com/NebulousLabs/Sia/build/critical.go:16 +0xa7
main.startDaemon(0x0, 0x0, 0x7fff5fbffd54, 0xe, 0x7fff5fbffd80, 0x5, 0x7fff5fbffd6f, 0x5, 0x0, 0x7fff5fbffdd4, ...)
/home/jrh/go/src/github.com/NebulousLabs/Sia/siad/daemon.go:295 +0xaa9
main.startDaemonCmd(0xc420083200, 0xc420019310, 0x0, 0x5)
/home/jrh/go/src/github.com/NebulousLabs/Sia/siad/daemon.go:309 +0x6d
github.com/spf13/cobra.(*Command).execute(0xc420083200, 0xc42000e0d0, 0x5, 0x5, 0xc420083200, 0xc42000e0d0)
/home/jrh/go/src/github.com/spf13/cobra/command.go:651 +0x23a
github.com/spf13/cobra.(*Command).ExecuteC(0xc420083200, 0x16c7c0f, 0x3b, 0xc420150960)
/home/jrh/go/src/github.com/spf13/cobra/command.go:726 +0x339
github.com/spf13/cobra.(*Command).Execute(0xc420083200, 0x1aa6520, 0x16b10c0)
/home/jrh/go/src/github.com/spf13/cobra/command.go:685 +0x2b
main.main()
/home/jrh/go/src/github.com/NebulousLabs/Sia/siad/main.go:174 +0x79d
Critical error: accept tcp <IP_ADDRESS>:9980: accept: too many open files in system
Please submit a bug report here: https://github.com/NebulousLabs/Sia/issues
Closing renter...

When did you download v1.2.2, right when it released? Also which OS are you running? Might be related to #1840

I downloaded it just a 3 days ago, I'm using Mac OS X.
On Jun 4, 2017, 06:15 +0200, Luke Champine<EMAIL_ADDRESS>wrote:

Closed #1875.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Still can't see coins, please help to fix
On Jun 4, 2017, 06:15 +0200, Luke Champine<EMAIL_ADDRESS>wrote:

Closed #1875.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Fix / Custom Messages and update examples/docs

Background
I was trying to implement the new locust version, running into a few errors.
In our implementation we rely on the messaging feature, when I saw that when registering a message a class ´CustomMessageListener` is now expected I tried to change my code accordingly.
The Error
Beforehand it worked, but after these changes it didn't.
After some research if found out that using a class with a __call__ method, still needs proper instantiating.
Solution
Therefore I changed the runner code from
self.custom_messages[message_type](environment=self.environment, msg=msg)

to
listener = self.custom_messages[msg.type]()
listener(environment=self.environment, msg=msg)

and it worked as expected.
I also updated the examples and the documentation to the latest state regarding this feature.
Happy to hear your comments / ideas / input.  Thanks a lot in advance.
Best Sam

Hmm thinking about it, and reading more I think it could be that the code changes in the PR are not necessary.
When using @CustomMessageListener as a decorator for a given function it should work the way it was probably intended to be.
Is my assumption correct?
If yes, then I would remove the code changes and just update the examples and documentation.
Best

Ping @nathan-beam who created them in the first place

Okay, so I did some more testing and if possible I would like you @cyberw or somebody else to confirm my results.
My test were always against a stock locust 2.12.0.
First Test
This is the custom_messages.py example from the example folder. running it with locust -f examples/custom_messages.py --master / locust -f examples/custom_messages.py --worker should work just fine, despite that we are ignoring the type hinting right now.
from locust import HttpUser, task, events, between
from locust.runners import MasterRunner, WorkerRunner, CustomMessageListener
from locust.env import Environment

usernames = []

def SetupTestUsers(self, environment: "Environment", msg, **kwargs):
    # Fired when the worker receives a message of type 'test_users'
    usernames.extend(map(lambda u: u["name"], msg.data))
    environment.runner.send_message("acknowledge_users", f"Thanks for the {len(msg.data)} users!")

def OnAcknowledge(self, msg, **kwargs):
    # Fired when the master receives a message of type 'acknowledge_users'
    print(msg.data)

@events.init.add_listener
def on_locust_init(environment, **_kwargs):
    if not isinstance(environment.runner, MasterRunner):
        environment.runner.register_message("test_users", SetupTestUsers)
    if not isinstance(environment.runner, WorkerRunner):
        environment.runner.register_message("acknowledge_users", OnAcknowledge)

@events.test_start.add_listener
def on_test_start(environment, **_kwargs):
    # When the test is started, evenly divides list between
    # worker nodes to ensure unique data across threads
    if not isinstance(environment.runner, WorkerRunner):
        users = []
        for i in range(environment.runner.target_user_count):
            users.append({"name": f"User{i}"})

        worker_count = environment.runner.worker_count
        chunk_size = int(len(users) / worker_count)

        for i, worker in enumerate(environment.runner.clients):
            start_index = i * chunk_size

            if i + 1 < worker_count:
                end_index = start_index + chunk_size
            else:
                end_index = len(users)

            data = users[start_index:end_index]
            environment.runner.send_message("test_users", data, worker)

class WebsiteUser(HttpUser):
    host = "http://<IP_ADDRESS>:8089"
    wait_time = between(2, 5)

    def __init__(self, parent):
        self.username = usernames.pop()
        super().__init__(parent)

    @task
    def task(self):
        print(self.username)

Second Test:
Importing the CustomMessageListener and using it as a class decorator.
@CustomMessageListener
def SetupTestUsers(self, environment: "Environment", msg, **kwargs):
    # Fired when the worker receives a message of type 'test_users'
    usernames.extend(map(lambda u: u["name"], msg.data))
    environment.runner.send_message("acknowledge_users", f"Thanks for the {len(msg.data)} users!")

@CustomMessageListener
def OnAcknowledge(self, msg, **kwargs):
    # Fired when the master receives a message of type 'acknowledge_users'
    print(msg.data)

This results in the following error:
TypeError: Can't instantiate abstract class CustomMessageListener with abstract method __call__
Third Test:
Making the events to subclasses.
class SetupTestUsers(CustomMessageListener):
    def __call__(self, environment: "Environment", msg, **kwargs):
        # Fired when the worker receives a message of type 'test_users'
        usernames.extend(map(lambda u: u["name"], msg.data))
        environment.runner.send_message("acknowledge_users", f"Thanks for the {len(msg.data)} users!")

class OnAcknowledge(CustomMessageListener):
    def __call__(self, msg, **kwargs):
        # Fired when the master receives a message of type 'acknowledge_users'
        print(msg.data)

After starting the test this results in:
TypeError: SetupTestUsers.__init__() takes exactly one argument (the instance to initialize) 2022-09-15T07:02:10Z <Greenlet at 0x1059c0040: <bound method WorkerRunner.worker of <locust.runners.WorkerRunner object at 0x10599b1f0>>> failed with TypeError
Solving
So I think there are two solutions to that. One is the current solution in this PR, which I think is still a bit bulky and not that pretty.
The second one would be to go with the class decorator, probably as it was intended to be. So after some reading, we could probably change the CustomMessageListener from:
class CustomMessageListener(Protocol):
    @abstractmethod
    def __call__(self, environment: "Environment", msg: Message) -> None:
        ...

to
class CustomMessageListener(Protocol):
    def __init__(self, f):
        self.f = f  # Store the function

    def __call__(self, environment: "Environment", msg: Message) -> None:
        self.f(environment, msg)

This should make
@CustomMessageListener
def someEvent(self, environment: "Environment", msg, **kwargs):
    ...

work, and also should probably be the only thing that would need to be changed if I understood the concept correctly.
Thanks a lot in advance!
Really looking forward to your comments :)

I had a quick look and really dont quite understand this. Why do you need to use an object method? And wouldnt this be a breaking change for everyone who uses simple methods?

Also, the current implementation in examples/custom_messages.py works fine for me.
locust -f custom_messages.py  --master --headless
[2022-09-15 20:43:45,011] .../INFO/root: Waiting for workers to be ready, 0 of 1 connected
Type     Name                                # reqs      # fails |    Avg     Min     Max    Med |   req/s  failures/s
--------|----------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
--------|----------------------------------|-------|-------------|-------|-------|-------|-------|--------|-----------
         Aggregated                               0     0(0.00%) |      0       0       0      0 |    0.00        0.00

[2022-09-15 20:43:45,084] .../INFO/locust.runners: Worker ..._c52b8c5e8da741dcaf6e941446bb65a9 (index 0) reported as ready. 1 workers connected.
[2022-09-15 20:43:45,085] .../INFO/locust.runners: Worker ..._c52b8c5e8da741dcaf6e941446bb65a9 (index 0) reported as ready. 1 workers connected.
[2022-09-15 20:43:46,016] .../INFO/locust.main: No run time limit set, use CTRL+C to interrupt
[2022-09-15 20:43:46,016] .../INFO/locust.main: Starting Locust 2.11.2.dev15
[2022-09-15 20:43:46,017] .../INFO/locust.runners: Sending spawn jobs of 1 users at 1.00 spawn rate to 1 ready workers
Thanks for the 1 users!
[2022-09-15 20:43:46,095] .../INFO/locust.runners: All users spawned: {"WebsiteUser": 1} (1 total users)

locust -f custom_messages.py --worker
[2022-09-15 20:43:45,085] .../INFO/locust.main: Starting Locust 2.11.2.dev15
User0
User0

Okay sorry for the late response. Probably I didn't make myself clear, or couldn't explain what I was thinking. Sorry for that.

Also, the current implementation in examples/custom_messages.py works fine for me.

Same for me. And that is what I was talking about.
So right now everything is working. And that's great. But also right the type hinting class CustomMessageListener for the messages, which was implemented a while ago, is being ignored.
Right now when trying to be type accurate, if you would at the @CustomMessageListner decorator or wrap it into the CustomMessageListener class it would fail.
Did I make it clearer? 😅

ah, ok, I understand a little better now. But you are suggesting a change breaking backwards compatibility? And the unit tests are failing?

ah, ok, I understand a little better now. But you are suggesting a change breaking backwards compatibility? And the unit tests are failing?

The unit tests were failing because, my previous change was not backwards compatible. And I didn't adjust the tests that time.

So the change in this pull request is not the change I would request. The change rn is more than it needs to be.
I think changing
class CustomMessageListener(Protocol):
    @abstractmethod
    def __call__(self, environment: "Environment", msg: Message) -> None:

to
class CustomMessageListener(Protocol):
    def __init__(self, f):
        self.f = f  # Store the function

    def __call__(self, environment: "Environment", msg: Message) -> None:
        self.f(environment, msg)

Should be the only necessary change, and also retain backwards compatibility.
 :)

Cool! Yes, lets do a separate PR that doesnt include all of my confusion (but reference this one). Ping @nathan-beam there as well.


Fused moe triton cfg opt for rocm

Motivation
As it is.
Modifications
Change the triton moe configuration file
Checklist

[+] Format your code according to the Contributor Guide.
[+] Add unit tests as outlined in the Contributor Guide.
[+] Update documentation as needed, including docstrings or example tutorials.

@HaiShaw :
Please help to review it.
Thanks


Is there a way to get the actual sync progress of the db?

Hello
I can't figure out a way to get the sync progress of the db with a sql query. Is this even possible?
I guess that the only way to achieve this would be to query the cardano-node component that runs alongside the cardano-db-sync component.
I also feel somehow bad to post those questions as "issues" and i apologize. Is there some other channel I might use for this kind of conversation?
Have a great day!

All blocks in the db are time stamped. Therefore if you do:
select max (time) from block ;

If the timestamp returned by the query is the same (within say 20 seconds) as the current UTC time, the database is fully synced.

Thank you @erikd. I will use the timestamp difference to calculate the approximate number of missing blocks. The 20s block production is a variable parameter in ouroboros if I am not wrong. It would be nice to be able to perform a sync progress check dynamically in the future somehow.

To get the sync progress as a number between 0 and 1
select
   (extract (epoch from (max (time) at time zone 'UTC')) - extract (epoch from (min (time) at time zone 'UTC')))
      / (extract (epoch from (now () at time zone 'UTC')) - extract (epoch from (min (time) at time zone 'UTC')))
  from block ;

I will assume that the above (or better yet the query in the interesting queries document satisfies this ticket and hence I will close it.


Create deployment starting state script

We need to be able to deploy the current mainnet starting state to test deployment for the router, fee handler and continuous rewards upgrades.

I have deployed a new environment which is equivalent to our current main net :
{"loans": "cx903637cfbc1c459a96c037efab67cf639b2877ea", "staking": "cxd28829b2d0f1391edb1ffc1ec46ac353db2ff4dd", "dividends": "cxdaa020d6fffb5da94d83faccc2a469a189ed2480", "reserve": "cxbb0c4c10c971e0dd3935ce270c6cfc2f878670db", "daofund": "cx65ecd947aca52f35f90f9559615d468f3ac1cde4", "rewards": "cxa885447965656de083f8b3b27e0372afbf5b3555", "dex": "cx481f7e10c7c4fc59d6ac68472018f10977a91b39", "rebalancing": "cx6f070006befbabe45bbd6c0b1ffa1f538a6bb009", "governance": "cx82d3a59eda11ce5540d2a1793633486711c8f6f2", "oracle": "cx0999df3af49a227fc8799f0d78d19cd8fe4bb76d", "sicx": "cxd5f4901712c93d846a454f861c579e54366953de", "bnUSD": "cx4428ab698443e62b88dc374f939c2fa251af6cd3", "bnXLM": "cx6c2b6c8dd300d5c96fc67a5617781de071b51159", "bnDOGE": "cx204a61990e3d7b9432b4b9da37bb9b8b83ec5f79", "baln": "cx1b0cb6da2d07be642eeebbdb0c5e3df248d4461b", "bwt": "cx598a1a4613e0790d35116421ef06038f0614ceee"}

Will need to update this when feehandler and router are accepted.


Dialog's open state is not fully controllable

Current behavior
When using useDialogStore with open and setOpen properties defined, there's a glitch happening. When Ariakit calls setOpen, it assumes that open will be updated accordingly to the value passed as an argument. While the final value is what I expect it to be, it will be briefly incorrect. Best understood with example below.
Steps to reproduce the bug

Open https://stackblitz.com/edit/ds7plf?file=dialog-nested%2Findex.tsx&theme=dark
Click "View Cart"
Click outside the dialog
Watch the dialog disappear for one frame. Also, check out the console - the open state will flicker from true to false to true.

Expected behavior
Since I'm controlling the value, I never expect it to be out of sync.
It also makes sense to explain why I'm doing this. I want to display a confirmation dialog (a nested modal) when a user tries to close the dialog, including on click outside.
Workaround
It's possible that onClose event on the modal will solve my problem in a different way (I haven't tried it yet, and I'm aware that it doesn't get called in all scenarios).
Possible solutions
No response

I've seen this behavior before, but I'm not sure if there's an action we can take here given how React works.
The current solution is to prevent the onClose event:
<Dialog onClose={(event) => event.preventDefault()}>

I've seen this behavior before, but I'm not sure if there's an action we can take here given how React works.

I haven't seen this in React. For example, if you have a controlled input <input type="text" value="foo" onChange={() => {}}/>, it doesn't matter what the user tries to type, the value will always be foo, without temporary glitches.

I've seen this behavior before, but I'm not sure if there's an action we can take here given how React works.

I haven't seen this in React. For example, if you have a controlled input <input type="text" value="foo" onChange={() => {}}/>, it doesn't matter what the user tries to type, the value will always be foo, without temporary glitches.

Yes, React does some magic to manage controlled inputs, but this isn't how native elements typically work. For instance, you can't fully control a native dialog element using the open and onClose props: https://stackblitz.com/edit/stackblitz-starters-gwwkum?devToolsHeight=33&file=src%2FApp.tsx
We're not using the native dialog element, and I agree we should do something to avoid these glitches. However, when I say "how React works," I'm referring to the fact that controlled behavior isn't the norm in React. It's a special approach that React uses for inputs.

I agree that turning native elements into controlled ones is a hack on React's side, since HTML elements are not designed to be controlled in the first place. The fact that details and dialog don't work as controlled elements can probably be considered a bug in React (there's an issue open at least about details).
When it comes to making custom controlled components, the solution typically lies in abandoning internal state in favour of external one, I would consider this approach clean, and it doesn't cause glitches. Whether it's trivial to do so for a given component, of course, depends on component's implementation, e.g. when implementation requires to have internal state and thus synchronising it with the external one (and I assume this might be happening in case of  <Dialog>).


The search app sort also implicitly filters by the sort attribute

For example, if you are searching on a table of images in the RBK implementation, and if you sort by Number of Comments it also filters out any rows that have null values.
This doesn't seem like the expected behavior. Should we treat null like the lowest value? I think that would be more intuitive.
Also by having sort also filter, it conflicts with the filters set in faceting.

In ERMrest, sort is always NULLS LAST in the underlying SQL.  Are you
sure the NULLs have been filtered out and not just displaced to the
last page?

Ah, that helps to know. So the bug is a little different then but still a bug. Steps:

go to the search page on www.rebuildingakidney.org
filter on Submitted By = Jill...
Sort by Number of Annotations

The display now is "Showing 1-4 of 125 results..." and you can click More to see more results.
I would expect that I would still see "...1-25 of 125 results..." but in sorted order. I don't think its very intuitive to make the other 25-N results disappear from the display. Obviously, it wasn't intuitive for me.

The bug is fixed in the commit ad793a7ea17d49596677cb7dd361d12adc3ea435.

@robes This is no longer the case on rbk-dev. All null values have been converted to 0. Will close the issue.


YARN-11305. Fix TestLogAggregationService#testLocalFileDeletionAfterUpload Failed After YARN-11241(#4703).

YARN-11305. Fix TestLogAggregationService#testLocalFileDeletionAfterUpload Failed After YARN-11241(#4703).
ERROR Message:
Directory [/home/jenkins/jenkins-home/workspace/hadoop-multibranch_PR-4846/ubuntu-focal/src/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager/target/TestLogAggregationService-localLogDir/application_1234_0001] was not deleted

testReport:
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4846/23/testReport/
Yarn's unit tests, with parallel mode enabled
/usr/bin/mvn --batch-mode -Dmaven.repo.local=/home/jenkins/jenkins-home/workspace/hadoop-multibranch_PR-4846/yetus-m2/hadoop-trunk-patch-0 -Ptest-patch -Dsurefire.rerunFailingTestsCount=2 -Pparallel-tests -P!shelltest -Pnative -Drequire.fuse -Drequire.openssl -Drequire.snappy -Drequire.valgrind -Drequire.zstd -Drequire.test.libhadoop -Pyarn-ui clean test -fae

Because the automatically generated application_id is the same, testLocalFileDeletionAfterUpload is affected by testLocalFileRemainsAfterUploadOnCleanupDisable
testLocalFileDeletionAfterUpload needs to check that the log of an application is deleted, and testLocalFileRemainsAfterUploadOnCleanupDisable regenerates the log of the same application.

@ashutoshcipher @aajisaka Please help to review the code, I found that in parallel test mode, YARN-11241 will cause junit test to
fail.
I let different junit tests use different application_id to avoid mutual influence.

FYI - This failure is observed with parallel mode enabled, hence was uncaught in YARN-11241(https://github.com/apache/hadoop/pull/4703)

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 53s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  1s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
38m 49s

trunk passed

+1 :green_heart:
compile
1m 38s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 41s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 49s

trunk passed

+1 :green_heart:
mvnsite
0m 56s

trunk passed

+1 :green_heart:
javadoc
1m  5s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 44s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 47s

trunk passed

+1 :green_heart:
shadedclient
21m 23s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 41s

the patch passed

+1 :green_heart:
compile
1m 28s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 28s

the patch passed

+1 :green_heart:
compile
1m 22s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 22s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 31s
/results-checkstyle-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-nodemanager.txt
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager: The patch generated 1 new + 112 unchanged - 0 fixed = 113 total (was 112)

+1 :green_heart:
mvnsite
0m 46s

the patch passed

+1 :green_heart:
javadoc
0m 39s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 34s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 34s

the patch passed

+1 :green_heart:
shadedclient
20m 59s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m 25s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

124m 12s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4893

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux db6c6bfcbefa 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 748fa05119f192c6a92794f4b4aeea51aae62520

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/1/testReport/

Max. process+thread count
693 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ayushtkn Please help to review the code again, thank you very much!

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  1s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 15s

trunk passed

+1 :green_heart:
compile
1m 39s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 35s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 50s

trunk passed

+1 :green_heart:
mvnsite
0m 55s

trunk passed

+1 :green_heart:
javadoc
1m  0s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 47s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 54s

trunk passed

+1 :green_heart:
shadedclient
21m 20s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 39s

the patch passed

+1 :green_heart:
compile
1m 36s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 36s

the patch passed

+1 :green_heart:
compile
1m 23s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 23s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 32s

the patch passed

+1 :green_heart:
mvnsite
0m 44s

the patch passed

+1 :green_heart:
javadoc
0m 38s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 38s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 43s

the patch passed

+1 :green_heart:
shadedclient
20m 39s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
23m 57s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 43s

The patch does not generate ASF License warnings.

123m 41s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4893

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux ca6005ffa7d9 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b62f0abdd6bd86bd7f75958250258b50c9ed5297

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/3/testReport/

Max. process+thread count
685 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 41s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 29s

trunk passed

+1 :green_heart:
compile
1m 46s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
compile
1m 41s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
checkstyle
0m 52s

trunk passed

+1 :green_heart:
mvnsite
1m  1s

trunk passed

+1 :green_heart:
javadoc
0m 58s

trunk passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 48s

trunk passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 50s

trunk passed

+1 :green_heart:
shadedclient
21m 25s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 42s

the patch passed

+1 :green_heart:
compile
1m 30s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javac
1m 30s

the patch passed

+1 :green_heart:
compile
1m 30s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
javac
1m 30s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 31s

the patch passed

+1 :green_heart:
mvnsite
0m 48s

the patch passed

+1 :green_heart:
javadoc
0m 42s

the patch passed with JDK Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04

+1 :green_heart:
javadoc
0m 35s

the patch passed with JDK Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

+1 :green_heart:
spotbugs
1m 35s

the patch passed

+1 :green_heart:
shadedclient
20m 56s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
24m 10s

hadoop-yarn-server-nodemanager in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

124m 47s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4893

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux ea2e7072eb9c 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b62f0abdd6bd86bd7f75958250258b50c9ed5297

Default Java
Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.16+8-post-Ubuntu-0ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_342-8u342-b07-0ubuntu1~20.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/4/testReport/

Max. process+thread count
698 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4893/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

@ayushtkn Please help to review the code again, thank you very much!

@ashutoshcipher @ayushtkn Thank you very much for helping to review the code!


Running tests that create sockets leads to failures in WSL due to Windows firewall blocking socket activity

Environment

Platform ServicePack Version      VersionString

Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:        16.04
Codename:       xenial
/proc/version: Linux version 4.4.0-18362-Microsoft<EMAIL_ADDRESS>(gcc version 5.4.0 (GCC) ) #836-Microsoft Mon May 05 16:04:00 PST 2020
Steps to reproduce
I'm looking at whether it would be possible to build our software under Ubuntu running on WSL rather than in a full VM.  During the build a number of test programs are created that create listen sockets and make connections to test the behaviour of that code.
When the programs are run, the Windows firewall pops up asking whether to allow the connection to be set up.  While normally this isn't a significant issue, it become a problem when there are a number of executables being created which may appear in different locations, though in fact be the same, due to being built under different paths.
This isn't what I'm doing but it demonstrates the point.  Although the names of the generated programs are not random, the effect is similar to them being so.  Thus, the following shell script demonstrates the problem
for i in 1 2 3 4 5 6 7 8 9 10; do    new_name=/tmp/foo$(rand);    cp /bin/nc $new_name;    $new_name -l 10000 &    proc_id=$!;    sleep 2;    kill $proc_id; done
Because the /tmp/foo$(rand) generates a new name each time, every single invocation will cause a pop-up to permit the access to the network.
In my case, the access is only really necessary for localhost though the sockets bind to allow connections over any interface (for the applications in question, loopback only would be ok for the tests but the behaviour they are checking would need to be able to connect across any interface).
Expected behavior
I'd like to be able to set a firewall rule up that allowed any executable under a given path to proceed, or somehow to say that executables generated under certain conditions.  I created a firewall rule and tried to associate it with a package to allow any inbound connections but this has not helped.
Actual behavior
There are firewall popups every time one of these programs is executed and this then causes the tests to fail.

I am not able to reproduce "popup every rename invocation" behavior here. I get one popup to allow port 10000 through. This is with default Windows firewall rules.
I think you'll get the same behavior if you were to do an equivalent powershell script in windows and launch a bunch of different executables listening on port 10000, given your firewall configuration. You'll probably get better eyeballs over in serverfault on firewall configuration than here. You'll get better answers if the question is frame as a Windows powershell script that renames Windows netcat (or anything that listens on a port).

Ok.  Thanks for the prompt response.  I'll follow up on that suggestion.

Looks like I was confusing two different problems.  I will close this issue.


The email group doesn't appear to be public

I went to the group listed here: https://github.com/ossf/wg-securing-critical-projects#communications
And the group doesn't appear to exist or be public

I'd like to contribute, but it isn't clear how I can

It looks like permissions were misconfigured. The group was set so anyone could join, but you had to join to see messages. Anyone should be able to see and join now.

Please let me know if you have trouble!


Correctly handle xmlNs memory in xpath query results

This patch addresses #1155
This patch introduces a bifurcation in how Namespace objects are managed; Namespace objects wrapped around xmlNs structs from an xpath query now have their own Ruby object lifecycle and are GCed independently from their original document.
See commits and comments in xml_node_set.c and xml_namespace.c for more details.
Shout out to @akshaysawant who helped diagnose the underlying issue.
Also note that this is clean under valgrind, and doesn't leak memory related to namespace xpath queries.
(This replaces #1360 and is rebased on a green commit.)

Great work @flavorjones ! Looks like a correct solution to the GC issue. For sure much better than the previous way per st_table .

Merged manually (with conflicts).


choiceSDK and HMS Toolkit Convertor

HI,
There is a tool named HMS Toolkit, which is developed by Huawei.
The Convertor component of HMS Toolkit can automatically help developer wrap hms and gms api.
The link is here:https://developer.huawei.com/consumer/en/doc/development/Tools-Guides/convertor-0000001050147221
Is ChoiceSDK relative to this toolkit?
Thansk!

ChoiceSDK is not related to HMS Toolkit Converter.
HMS Toolkit Converter is a code conversion tool provided by Huawei, whereas ChoiceSDK is a third-party open-source library that aims to wrap similar functionalities from GMS and HMS to one common interface.


Error in using entropy discretization

I am trying to create a LimeTabularExplainer instance using entropy discretization.
However, I got the error AttributeError: 'module' object has no attribute 'tree' because of this line dt = sklearn.tree.DecisionTreeClassifier(criterion='entropy', max_depth=3).
How do I make it work without changing the script?

We were missing an import in that discretizer. Fixed in <IP_ADDRESS>, please update your version.


Provide pip and/or conda installable Python package

It would really help to have a pip installable Python 3.7 compatible package published on https://pypi.org/ . This could then be updated whenever there is a new release of zfp. It will lower the barrier to using zfp. Thanks.

Agreed, but unfortunately our Python developer has moved on to another project.  Any assistance with this would be appreciated.  In case it's helpful, I do have a pypi account.

In that case, do you have a FTE opening for a Python developer?

I'm afraid I don't have sufficient funding for an FTE, nor do I have enough work to keep a Python developer busy long term.

Dummies guide to packaging is to do python setup.py test , ensure that works, and then run PyPI check-manifest to ensure MANIFEST.in is complete, and then python setup.py sdist and use twine to upload it to PyPI.
Then get some python people to build it at home, fix any errors, etc, and then in the next release also do python setup.py bdist_wheel which is better for normal users.

@lindstro Would there be interest in making a conda package for zfp/zfpy instead of pip?  Pip is nice for pure python packages, but it's not the best for python packages with special C/C++ dependencies.
If this would be of interest, I think I can direct some effort to this tomorrow.

...Although, I agree that a wheel would be good, too.

@kmpaul Speaking as a user, yes, conda works fine.

@kmpaul Thanks for the offer!  Python is not my strength, and I'm not sure I'm qualified to answer your question.  Of course, any contributions that simplify life for our Python users are welcome.
I'm roping @GarrettDMorrison in on this, who is our resident Python expert.

I definitely think that a conda forge package for zfp would be loved by many.  So, since I'm in a hackathon for the next day (or two), I'll go ahead and start making some progress on this.  If the result is something you like, we can transfer ownership.

Of course!  And I'm happy to transfer ownership.  I understand that you all might be busy, though, so I happen to have some free cycles at the moment to do it.

Awesome!  Thank you so much for your contributions, Kevin.

@lindstro You're more than welcome.  Thanks for the awesome zfp package!
Incidentally, who should I list as "conda recipe maintainers"?  I need github user IDs for everyone who will be (willing to be) a "maintainer" of this conda recipe.

I hope you're willing to be one of them :-)  Please add me and @GarrettDMorrison.

Yes.  I'm the first person on the list.  :-)  And I'll stay there.
I'll add you and Garrett.  Thanks!

Someone should register https://pypi.org/project/zfp/ , even if it is only an empty package, to reserve the name.  One of the first questions of distro packaging is "what name to use", and for Python to first answer is "the PyPI name".

@jayvdb I'd be happy to do so through my PyPI account but could use some help.  I know there is documentation out there, but I cannot dedicate hours to figuring out how to set up an empty package at this time.  Is there an easy way to just register the package?

@lindstro I have now registered zfp on PyPI. I believe it is not necessary to do anything at all with this PyPI package right now, since @kmpaul is targeting an initial conda-forge package instead.
If I were to nevertheless transfer it, I suppose I would require an LLNL service account to grant ownership to, with @lindstro and @GarrettDMorrison added as maintainers. Any added PyPI account should ideally first enable 2FA for security.

@impredicative Thanks for setting this up.  If you'd like to transfer the project, my PyPI account is lindstro.

@lindstro Done. You now have Owner level access to it. From here you can adjust its permissions accordingly. Please however refer to the second paragraph of my prior post though for maximizing security and for organizing it to outlast any one person.

@impredicative I demoted you to maintainer and will add @GarrettDMorrison as owner.  I also set up 2FA.
We could still use some help with setting up the pip package, in case anyone is willing to contribute.

I realized that I never posted that zfpy is now on conda-forge.  Has been for a little while.  In fact, if you look here (https://anaconda.org/conda-forge/zfpy) you can see that it already has >600 downloads.
Note that this package is meant to build zfp and install the zfpy Python bindings, so the package is named zfpy.

Please also reserve https://pypi.org/project/zfpy/ to avoid it being misused by someone else.

Please also reserve https://pypi.org/project/zfpy/ to avoid it being misused by someone else.

I will do this.

Please also reserve https://pypi.org/project/zfpy/ to avoid it being misused by someone else.

Done. @lindstro and @GarrettDMorrison are now its Owners.

Thanks, @impredicative.

Thanks to the efforts of @da-wad, we now have a pip installable package: https://pypi.org/project/zfpy/.  I'd like to thank @da-wad, @kmpaul, and everyone else who helped resolve this issue.


Lazy initialisation with built-in DI.

Func<T> support for lazy initialization

The above is listed as one of the features not supported by the built-in container, but the built-in AddXXX methods all have overloads that can take a Func<IServiceProvider, T>, which I believe is initialised lazily. e.g. AddSingleton.
I realise that initialisation and instantiation are different things and that the line I referenced might be referring to something else.

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

ID: 0d78f540-81fd-1ba9-cb90-591e4ec27d9b
Version Independent ID: 2251f557-dd3a-ec35-2558-6243337db009
Content: Dependency injection in ASP.NET Core
Content Source: aspnetcore/fundamentals/dependency-injection.md
Product: aspnet-core
Technology: aspnetcore-fundamentals
GitHub Login: @guardrex
Microsoft Alias: riande

Thanks @serpent5 ... I'll mark this for the Product Unit to address.

@serpent5 My understanding is that engineering will be pinged on these at some point. If it's still an open question, you could leave this open to see if that happens.

@guardrex Thanks. I closed this for another couple of reasons:

It's not had any :+1:s so it's not something of interest to others.
I concluded that it likely means the ability to delay creation of a service until it's used, rather than what I described where it's done before construction of the dependent component.


Bump build to JDK 17

Required because of https://github.com/quarkusio/quarkus/pull/37335. See https://quarkus.io/blog/jdk-17 for more details

In the quarkiverse parent we are stil using 11

You'll only have to update when upgrading to Quarkus 3.7, otherwise it must still build in 11.
The Quarkiverse parent will be updated once 3.7 is released


Build Interactive mode

Summary
Build the functionality to connect to a host interactively.
The command should be something like:

konnect -i

Done https://github.com/exitshell/konnect/pull/11


Manage token lifecycle

child of #228
Finish implementing Implicit flow.
When token has expired remove it.
When the token is about to expire, do a silent auth.
More details can be found here: https://auth0.com/docs/api-auth/tutorials/implicit-grant

Removing the token after it expired would be highly appreciated. If I do it myself (removing it from the cookies), I additionally expect the strange behavior that the login-button disappears. At some point it comes back (still investigating under which conditions).

Yes, I'm hoping to finalise my PR today. Token will be renewed silently if possible, otherwise user will be invited to login again.
Keep me up to date with the login button disappearing. As long as you have a ACL for Anonynous on / with the realms/read permission, it should display. I'll investigate on my side as well

It definitively comes back if I recreate the server... :) Caching issue?


perf: add query optimizer

please review and merge #828 and #827 before this.
This PR adds a rule optimizer that re-orders the nodes in the rule logic tree to try simpler/faster cases before complex cases. For example, it prefers OS checks before mnemonic checks before regex checks.
In practice, this seems to make a small, but measurable difference in execution time:

label
count(evaluations)
avg(time)
min(time)
max(time)

18c30e4 base
108,121
0.38s
0.34s
0.55s

a6e2cfc base short circuiting
69,401
0.23s
0.22s
0.26s

152d0f3 de-optimizer
78,900
0.28s
0.26s
0.36s

e287dc9a optimizer
68,275
0.22s
0.21s
0.25s

(via: PMA01-01, 30 iterations)
Note that originally, in 152d0f3, I had the sign of the cost function inverted, so the optimizer was actually a de-optimizer: it  picked approximately the worst possible order of evaluation. This led to a 13% increase in feature evaluations, whereas the correct ordering improves evaluation performance by about 2%. The mistake demonstrates that evaluation order can have a substantial impact on performance, though our rules are already fairly well structured (e.g. we typically have OS checks as the first line).
My opinion is that we should probably merge this PR because it does provide some performance benefit, code is very localized, and it doesn't change any of our public APIs/behaviors.
Further perf metrics, using k32 (2 iterations):

label
count(evaluations)
avg(time)
min(time)
max(time)

18c30e4 base
66,561,622
177.59s
172.27s
182.92s

6909d6a optimizer
41,772,519
100.44s
99.38s
101.49s

About 44% faster with 38% fewer feature evaluations.
Checklist

[ ] No CHANGELOG update needed

[x] No new tests needed

[x] No documentation update needed

I think for samples with many functions and large functions this could make a big difference (see K32 results).


Fix typo and inconsistency around unique annotation

Pull Request Test Coverage Report for Build 447

2 of 2 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 82.19%

Totals

Change from base Build 445:
0.0%

Covered Lines:
5732

Relevant Lines:
6795

💛  - Coveralls


rust-project: add support for alternative Buck2 commands

This is useful for users of wrappers such as Buckle, as well as developers hacking on Buck2 that need to use a custom build.

WDYT @davidbarsky?

The CI failure looks completely unrelated :/


Browser starts to lag after playing 3-5 videos when using  player.configure to update the source url

Browser:
Firefox 88.0.1
OS:
Pop OS  20.04 LTS
Clappr Version:
latest from http://cdn.clappr.io/latest/clappr.min.js
Steps to reproduce:
play 3-5 video one after another.

I was expecting to have a smooth playback but instead it started lagging(my browser)

Did you try to reproduce this issue at http://cdn.clappr.io/
No
I'm trying to update the video source using the following code:
// [...]
player.configure({
  source: 'another-url',
  // ...
});

which updates the video but after playing around 3-5 videos one after another the browser starts to lag.
I also tried to reproduce this issue on multiple devices, the same issue occurred.
NOTE : source URL is an HLS video encrypted with AES-128

Did you try to reproduce this issue at http://cdn.clappr.io/
No

Can't you reproduce the reported behavior or just haven't tried?

I also tried to reproduce this issue on multiple devices, the same issue occurred.

Yes I have but not on http://cdn.clappr.io/

Yes, I understand that you have tested it on other devices. The recommendation to test on http://cdn.clappr.io/ (specifically on http://cdn.clappr.io/demo) is that it becomes a common point that we can also validate on our side.
I was unable to reproduce this issue. Can you generate any evidence of this? (CPU / Memory consumption of the tab that is running Clappr, some video showing the problem visually)

Hi @unique1o1, is the problem still happening? Can you generate any evidence of this? (CPU / Memory consumption of the tab that is running Clappr, some video showing the problem visually)

I'm closing this issue due to inactivity. If needed, please feel free to reopen it.


Fix coveralls icon

Coverage remained the same at 77.4% when pulling e80b271b03a997a9cde3c2da634feca8590592a5 on frewsxcv:patch-1 into b3b5571c7946584be04a8a4f83dc68f39c1b5c38 on hydralabs:master.


Explicitly typecast Update Mutation set argument

What kind of change does this PR introduce?
Adds explicit column type casting to the set argument of update mutations.
I verified this issue is not present in the filter and objects args for other mutation types.
Bug fix, feature, docs update, ...
https://twitter.com/aiji42_dev/status/1512305435017023489
What is the current behavior?
Passing a value as a variable to a column that is not represented as text (int, bigint) returns an error
column \"some_id\" is of type integer but expression is of type text

#162


Store screenshot in PNG format by default

JPEG usually produce some noises due to its lossy encoding method, which is probably affect the image quality even if this app is set to use the PNG format. If this app use PNG format to store the mage by default while the app is doing capture on screen, it would avoid some visual artifacts around high-contrast areas, also give benifits to users while using PNG and WEBP formats.
See: https://en.wikipedia.org/wiki/Portable_Network_Graphics#Comparison_with_other_file_formats

Interesting! Thank you for informing me about that :) I didn't know that! :)

As you can see, I just implemented your suggestion! I hope I get around pushing a new release soon :)


feature(search): Add capability to run time range query

Description
This adds support for being able to run queries such that you can select a specific interval of time
Checklist

[ ] Investigated and inspected CI test results
[ ] Unit test and regression tests added
[ ] Evaluated and added CHANGELOG entry if required
[ ] Determined and documented upgrade steps
[ ] Documented user facing changes (create PR based on openshift/openshift-docs and merge into rhacs-docs)

If any of these don't apply, please comment below.
Testing Performed
Unit tests

Since you are already adding support for >= and <=, I feel we should take this opportunity to add support for queries with only >= and <=

Supporting this will really make the language more complicated. Also, the current code makes this possible today, you just need to add one ms. Without a use case, I'm not sure it's worth it

To follow up on my previous comment, I would rather not add double ended inclusive now and instead refactor the queries so they don't come into postgres as unstructured and instead would come in as a TimeRangeQuery where then we can customize it much more


Left Column Hover Changed when Showing/Hiding Hidden Files

What system are you running Yazi on?
macOS
What terminal are you running Yazi in?
iTerm2
Yazi version
0.1.5
Did you try the latest main branch to see if the problem has already been fixed?
Tried, but the problem is still present
Describe the bug
The left column hover position (parent folder) changed when Showing/Hiding Hidden Files. Now when you press left and then right, you will end up in a different folder.
Expected Behavior
The hover position should remain unchanged.
To Reproduce
https://github.com/sxyazi/yazi/assets/109451175/f7f7b9bb-a372-4555-a216-fa953077901b
Configuration
No response
Anything else?
No response

Thanks for the reporting.
I made a PR to fix this, https://github.com/sxyazi/yazi/pull/339, let me know if it works for you!

Thanks for your fix! It works.


Use correct name to validate ClearChargingProfileConfirmation

ClearChargingProfileConfirmation should use clearChargingProfileStatus for validating the status, not chargingProfileStatus

Nice catch, thanks for opening this!


Omit attributes on withRelated

When using withRelated to join two tables, I'd like to omit specific attributes from the table being joined on. Specifically I'm joining submissions with users, and I don't want the sensitive user details like hash and other information to be returned.
Model
exports.model = Bookshelf.Model.extend({
  tableName: 'submissions',

  submissions: function() {
    return this.hasMany(Submission, 'user_id');
  },

  users: function() {
    return this.belongsTo(User);
  }
});

Collection
exports.collection = bookshelf.Collection.extend({
  model: Submission
});

Controller
var Submissions = require('../collections/submissions').collection;

exports.videos = function(req, res) {
  new Submissions().fetch({
    withRelated: ['users']
  }).then(function(collection) {
    res.send(collection.toJSON());
  });
};

I suppose in my controller, I could just loop through the collection object and use underscore's omit, but I was hoping of a cleaner method to do this within the model.
Any ideas?
Cheers

Use Submission.prototype.toJSON to only include the attributes you need when serializing.


Added 'disabled' prop

During submit I don't want to allow user to perform cropping.
Maybe others have similar use-cases as well.

Thanks @yury-dymov this seems like a useful option


Add hotkey options for common characters

It would be nice if the user was able to bind a few -like 3 to 5- certain Unicode characters to hotkeys in the plugin settings menu.

Could you elaborate on the specific use-case?
I had the idea of favourite characters which would be bound to hotkeys, but it didn't seem useful for me in the end.
Is the purpose of the hotkey just to be faster than using the searchbar?
Do you see yourself using it as you type for something like punctuation, currency symbols, etc.?

My specific use-case is the zero width non-joiner/ZWNJ character. Some of my notes are in Farsi and ZWNJ is required if you want to write something. The default keyboard layouts for nearly all devices have a hotkey or dedicated button for this character in them. For example, it is Shift+Space for Windows. But in my case, I am using Samsung DeX with a bluetooth keyboard and it doesn't have a dedicated shortcut for ZWNJ. Hence the issue.
I'm pretty sure others would also benefit from this idea of favorite characters. I commonly use arrow, star and heart characters in my notes as well.


[resotocore] add CSV and markdown table output format

Motivation
From Discord discussion:
@isme: CSV output would certainly be useful because it's a format that pretty much every analysis tool supports.

But sometimes, as in the above example, I just use CSV as a "staging" format so that I can render a table using csvlook. A table is often the most readable way to present results.

So if resh also had a table format it would save a lot of manual labor. You'd get bonus points if the table output was in Github syntax because then you could immediately paste it into a Markdown document or Github issue.

Desired Behavior
Have a CSV format output, including header, as well as markdown pre-formated table output.
Additional Context
No response

In the Discord chat I showed how I would generate a Markdown table using csvlook.
I just discovered a more convenient way using jtbl. It skips the CSV staging part so there's no need to faff about with --no-inference options in csvkit.
https://github.com/kellyjonbrazil/jtbl
It doesn't seem to support Markdown-formatted tables yet, so I opened an issue for that.
https://github.com/kellyjonbrazil/jtbl


Smart packing takes a lot of time when device iterations is increased

This stalls the start of training/validation after Poplar graph compilation, especially in estimate_max_pack_node_size

Fixed in #391 by reducing the thresholds to use fast_packing


Switching ChainlinkOracleAddress to a command line param rather than being pulled from the Chainlink process

In versions 0.9.x of Chainlink, it looks like they removed the ORACLE_CONTRACT_ADDRESS config option: https://github.com/smartcontractkit/chainlink/blob/master/docs/CHANGELOG.md#0817---2020-09-28
This patch allows you to pass your Oracle Contract Address in as a command line param (the -o option). It parses the address with common.HexToAddress and passes the reference through as normal.
Thoughts on this PR to support 0.9.x versions of the Chainlink client?

Nice catch, appreciate the PR.


Add Zuplo to Development

[X] My submission is formatted according to the guidelines in the contributing guide
[X] My addition is ordered alphabetically
[X] My submission has a useful description
[X] The description does not have more than 100 characters
[X] The description does not end with punctuation
[X] Each table column is padded with one space on either side
[X] I have searched the repository for any relevant issues or pull requests
[X] Any category I am creating has the minimum requirement of 3 items
[X] All changes have been [squashed][squash-link] into a single commit

@touero @matheusfelipeog any chance either of you can merge?

Or @apilayer-admin


Mirror mode: only the first URL for each package is presented

When mirror mode is enabled, the get_fallback_packages function only presents the first URL for each of the packages available upstream (via this break statement).

This can cause problems, because sometimes the first URL is a "wheel" package. Then, if the client uses --no-use-wheel, the package cannot be installed.
I don't have all the context required to make the call, but could that break line simply be removed?

I'll have to dig into it, but I think removing the break might Just Work™
Could you tell me which package is failing so I can test this locally?

Sure, the package was pyopenssl. I was trying to install the latest version specifically (0.15.1) with --no-use-wheel enabled. pypicloud only presents pyOpenSSL-0.15.1-py2.py3-none-any.whl for that version, so it fails.
Thanks for looking into it! :smile:


[Python] ENH: Preserve tzinfo from datetime.time objects when contructing pa.array

Describe the enhancement requested
In [45]: pa_array = pa.array([datetime.time(12, 0, tzinfo=datetime.timezone.utc)])

In [46]: pa_array
Out[46]:
<pyarrow.lib.Time64Array object at 0x7fb0c86045e0>
[
  12:00:00.000000
]

In [47]: pa_array.to_pylist()
Out[47]: [datetime.time(12, 0)]

It looks like the tzinfo information is currently discarded. It would be great if it were kept.
Component(s)
Python

The builtin datetime.time is converted to time64 in Arrow (see https://arrow.apache.org/docs/python/pandas.html#time-types) and pa.time64() is not, as far as I understand, timezone aware.
The information about the timezone is stored in pa.timestamp() data type which works correctly:
>>> dt = datetime.datetime(2023, 1, 24, 0, 12, 0, tzinfo=datetime.timezone.utc)
>>> pa.array([dt]).type
TimestampType(timestamp[us, tz=UTC])
>>> pa.array([dt]).to_pylist()
[datetime.datetime(2023, 1, 24, 0, 12, tzinfo=<UTC>)]

Right, this would be an enhancement request for the time types in Arrow to be timezone aware.
Context: In pandas I am working on supporting pyarrow backed data types in pandas working with datetime functionality. We have a Series.dt.timetz method that returns times + timezones of a time series, but to return this as a pyarrow backed data type the timezone information is lost.

Well, that's a bigger change (a request for a change in the Arrow C++ format).
For this kind of changes a discussion should be opened on the dev Mailing List.
Honestly, I am not sure the context you are mentioning is a good reason to change the format.

Since currently the Arrow format spec doesn't have timezone for the time type, I am going to close this as python issue.
As Alenka mentioned, actually adding this to the spec would require a broader discussion.

Context: In pandas I am working on supporting pyarrow backed data types in pandas working with datetime functionality. We have a Series.dt.timetz method that returns times + timezones of a time series, but to return this as a pyarrow backed data type the timezone information is lost.

@mroeschke if we want to preserve that functionality in pandas, I think we can probably implement that differently there? (eg let it return object dtype with datetime.time objects, as it does now for datetime64tz?)

Yeah that's probably the correct workaround in pandas

Just ran into this.  It's reasonable for arrow to not implement this, but I would expect the constructor to raise/warn instead of silently dropping tz info