how to configure "OutputType=HTML" in the "View" section of config.json

Dear Sirs
Document Preview, in Find, always fails (HTTP-Code 500) for most of indexed documents that are not html, neither have public urls.
In my installation docs' DREREFERENCEs points to local web server and docs' formats are: txt, doc, docx, xls, pdf, odt, ods, and so on; Find Document Preview is not able to show their Preview.
I suspect that the calls to the Idol View Server have not the OutputType parameter set to "html" (it would convert every doc-format into html)
I checked in the "home/config.json" file and in the Help ("Find_12.0_Administration_en.pdf") but I cannot find any description of the "view" section, if the "OutputType" param could be added there:
[currently I have the following]:
  "view" : {
    "connector" : {
      "protocol" : "HTTP",
      "host" : "<IP_ADDRESS>",
      "port" : 10000
    },
    "referenceField" : "DREREFERENCE",
    "viewingMode" : "FIELD",
    "highlighting" : true,
    "host" : "<IP_ADDRESS>",
    "protocol" : "HTTP",
    "port" : 19080
  },

Error example
the following image shows Find unable to Preview an outer html page, from an external RSS site:

the usr is:

https://www.repubblica.it/cronaca/2018/06/14/news/diete_truffa_ordine_medici_denuncia_alla_procura_adriano_panzironi-199004441/?rss

This isn't a Find question, it's a view server question; you should check the admin guides or contact support if you're running into problems.
At a guess, it might be you're missing the SSL config section
[Viewing]
  …
OutgoingSSLConfig=SSLSection
  …

[SSLSection]
SSLMethod=SSLV23

or the proxy settings (change them to point at your own proxy server)
 [Viewing]
  …
 ProxyHost=web-proxy.sdc.hpecorp.net
 ProxyPort=8080
 NoProxyHostsCSVs=localhost
  …


Local build fails on Windows

$ yarn run build
yarn run v1.7.0
$ gulp build && yarn run build:functions
[16:39:42] Using gulpfile ~\Documents\Personal_projects\eleventyone\gulpfile.js
[16:39:42] Starting 'build'...
[16:39:42] Starting 'generate'...
Writing dist/index.html from ./src/site/index.md.
Writing dist/about/index.html from ./src/site/about.md.
Writing dist/search.json from ./src/site/search.njk.
Writing dist/posts/a-post/index.html from ./src/site/posts/a-post.md.
Writing dist/posts/another-post/index.html from ./src/site/posts/another-post.md.
Processed 5 files in 0.31 seconds
[16:39:45] Finished 'generate' after 2.29 s
[16:39:45] Starting 'assets'...
[16:39:45] Starting 'images'...
[16:39:45] Starting 'styles'...
[16:39:45] Starting 'scripts'...
[16:39:45] Starting 'resize_400'...
[16:39:45] Starting 'resize_1000'...
[16:39:45] Starting 'copyOriginalImages'...
[16:39:45] Finished 'scripts' after 19 ms
[16:39:45] Finished 'resize_400' after 29 ms
[16:39:45] Finished 'resize_1000' after 30 ms
[16:39:45] Finished 'copyOriginalImages' after 31 ms
[16:39:45] Finished 'images' after 33 ms
[16:39:45] The following tasks did not complete: build, assets, styles
[16:39:45] Did you forget to signal async completion?

events.js:183
      throw er; // Unhandled 'error' event
      ^
Error: Error: write EOF
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This appears to be a separate issue from https://github.com/philhawksworth/eleventyone/issues/1
Not sure what the root cause might be, will investigate if I have some time.

I am also having this issue. Would love some help!

This should get the windows build working (assuming you are using choco as you package mgr:
choco install graphicsmagick

@mariealine - you need graphicsmagick installed local

see https://github.com/philhawksworth/eleventyone/issues/1#issue-339182269


Trouble installing

I installed an older version via a youtube link and tried to install the newer version ,which has a bug fix for gamepad connection. And it won't show as a open able software.

It looks like you have downloaded the source code. Check the releases page for the .dmg file (as you are running on a Mac).

Thank you so much!


globs nothing when directory contains backets

Basically my gulp.src('test/*.js') returns nothing when my process.cwd() contains [] brackets.
Tracing down the gulp dependency tree:
├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>│   ├─┬<EMAIL_ADDRESS>│   │ ├─┬<EMAIL_ADDRESS>
I explicitly installed those versions and here is my test scripts:
require('vinyl-fs')
  .src('test/*.js')
  .on('data', function() { console.log(arguments); }); // no output

require('glob-stream')
  .create('test/*.js')
  .on('data', function() { console.log(arguments); }); // no output

require('glob')('test/*.js',
  function() { console.log(arguments); }); // lists out my files

Further testing shows that with the current version<EMAIL_ADDRESS>the problem still occurs.

https://github.com/isaacs/minimatch/issues/50

Oh thanks, closing this.


Support for zhimi.airpurifier.v7

lib doesn't work for air purifier with version 7. I can connect to device but can not get any data from device
C:> miio discover
INFO  Discovering devices. Press Ctrl+C to stop.
Device ID: "My device id"
Model info: zhimi.airpurifier.v7
Address: "my internal ip assigned to air purifier"
Token: ???
Support: At least generic
When execute
C:>miio protocol call "ip address of air purifier" get_prop '["temperature"]'
Console output:
INFO  Attempting to call get_prop on "ip address of air purifier"
INFO  Device found, making call
Nothing is returned here. Waited 5 min with making call but nothing was returned
Checked also in node.js
const miio = require('miio');
miio.device({ address: '"ip of my purifier"', token: '"my token which was displayed after direct connection to purifier wifi network and execute miio discover"' })
.then(device => {
console.log('connected');
      if(device.matches('type:air-purifier')) {
    console.log('air-purifier');
            }
  })

.catch(err => console.log(err));
MY OUTPUT:
D:\node.js\homeMonitor>node build/test.js
connected
So it seems that connection is established but purifier is not detected. No output for console.log('air-purifier');

Is there any plan or update for 'zhimi.airpurifier.v7'?

I had same issue from homebridge-mi-air-purifier.
I solved this issue myself temporarily from model information adding as below.

Stop to upgrade miio
docker exec -it marcoraddatz-homebridge1 /bin/bash
vi /root/.homebridge/install.sh
#npm install -g miio

Add model info
vi /usr/local/lib/node_modules/miio/lib/models.js
'zhimi.airpurifier.v7': AirPurifier,


Cancel the default "prevent default" behavior when clicking on a link in a message

Description
How can I cancel the default "prevent default" behavior when clicking on a link in a message, but execute some function?
For example, a bot creates a message with a link that, when clicked, opens a modal window.
What type of issue is this? (place an x in one of the [ ])

[ ] bug
[ ] enhancement (feature request)
[x] question
[ ] documentation related
[ ] example code related
[ ] testing related
[ ] discussion

Requirements (place an x in each of the [ ])

[ ] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[ ] I've read and agree to the Code of Conduct.
[ ] I've searched for any related issues and avoided creating a duplicate issue.

Hi @FIREguardSPB, thanks for asking the question!
Unfortunately, there is no way to customize the Slack app behavior for a link click event. Instead, I would recommend having a button that opens a modal when it's clicked. Refer to the latter half of the Getting Started document: https://slack.dev/bolt-js/tutorial/getting-started for learning how to implement it with bolt-js.
I hope this was helpful to you!

👋 Let us know if you have any follow-ups here. If we don't hear back for a few more days, we'll close this issue due to inactivity.


Relation between HighlightRange#priority and other highlight pseudo elements

moving from https://github.com/dlibby-/highlight/issues/13
@Reinmar as FYI
As I understand, HighlightRange#priority is needed to control which highlight is rendered above which. Since we have other highlight pseudo-elements like ::selection or :spelling-error, could we prioritize our highlight range above those?
In other words – do the UA's highlight pseud-elements have defined priorities?
Crazy idea – couldn't z-index be used for that instead of priorities?

Since the spec is now in the css-wg, I suggest moving the discussion there and closing this issue. w3c/csswg-drafts#4594 is largely the same topic. You may want to repeat your comments there.

Closing this issue. This has now been moved to the CSS WG drafts repo (see link above).


roll Aki's suggestions for GP into manual

Moved here from #211

[ ] add radial basis example

[ ] update w.r.t. Aki's comments for GP

@bob-carpenter I think this exists in the manual now. Can we close this?

Can you check, and if it's not, add it to the longer-term manual issue?  Thanks.


Better handling of removed directives?

V1:
#CommentFlag NewString
#EscapeChar _

MsgBox, This is a test NewString should be omitted
MsgBox % "This is a _nnewline"

V2 (Converted):
; REMOVED: #CommentFlag NewString
; REMOVED: #EscapeChar _

MsgBox("This is a test NewString should be omitted")
MsgBox("This is a _nnewline")

V2 (Expected):
; REMOVED: #CommentFlag NewString
; REMOVED: #EscapeChar _

MsgBox("This is a test") ; should be omitted
MsgBox("This is a `nnewline")

Currently working on this
Updated test:
#CommentFlag NewString
#EscapeChar _
#DerefChar #
#Delimiter /

Var = String

MsgBox/ This is a test NewString should be omitted
MsgBox # "This is a _nnewline"
MsgBox/ #Var#

How would it handle something like this?
MsgBox, Test
#Delimiter -
MsgBox- Test
#Delimiter /
MsgBox/ Test

Current PR handles this

Current PR handles this

Gotcha... nice job :)
Btw... I found a bug in the masking. When I fixed it, it cause one of the onMessage tests to fail. Will be submitting a fix for that soon. I mention it because (similar to this) I think you warned me about the potential of breaking certain conversions when I first suggested masking. I hadn't run into any till now. Luckily there is only one (so far)... lol.

When I fixed it, it cause one of the onMessage tests to fail.

Could it be failing because it's masking my mask? OnMessage conversion is very finicky  :)

Luckily there is only one (so far)... lol.

If it has already lasted this long without too many major issues I doubt itll cause any now

Could it be failing because it's masking my mask? OnMessage conversion is very finicky :)

Lol... It is the one you masked, but my mask causes your code not to see the function, since it becomes a tag instead. I made a mistake in one of my edits that caused the masking not to return the masked version of code, so all was left exposed as normal code when it made it to _convertLines(). Without masking many more are broken than just the one, so will need to make an adjustment so all work correctly with masking turned on. I haven't had power for 4 days, and it might be another 2 weeks until I do. So, progress might be delayed.


Can't send transactions

For a few days now I have not been able to send any transactions. First I thought the problem was just the smart contracts stuff, but I tried to send just ADA and the transaction failed there too.
Tried to delete the collateral and put it back, now can't set the collateral because that fails too.
I reset the whole wallet and imported from seed phrase, still the same problem. Now running out of things to try.
Thanks in advance!

@drible12 Talk to Cardano Support on the Live support page so that your issue can be looked into.


[BUGFIX] Correctly read request credentials.

When reading credentials from the auth object on request, we try to access the first element of an array.
Unfortunately, the credentials object is not an array but a plain object.
By returning directly the auth.credentials in the session auth strategy, we can now access the current admin in the rest of the code.
This means we can use the useCurrentAdmin in custom component or that the profile menu (on top right) is now displayed, letting user to log out.

wrong origin repo, I am closing it.


segmentation fault (core dumped) with cuckaroo_cpu_avx2_xx plugin on ubuntu 18.04

When running with cuckaroo_cpu_avx2_xx miner plugins, grin-miner always be stop with below error
segmentation fault (core dumped)

it's no problem with miner plugins: cuckatoo_mean_cpu_avx2_31 and cuckaroo_cpu_compat_29

It crashes for me on both i7 and i9 CPU.  The stack trace shows:
Thread 9 "grin-miner" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffef13c8700 (LWP 17730)]
edgetrimmer::genUVnodes (this=this@entry=0x7ffff540e000, id=id@entry=0)
    at /home/bdoyle/tmp/grin-miner/cuckoo-miner/src/cuckoo_sys/plugins/cuckoo/src/cuckaroo/mean.hpp:333
333               _mm256_store_si256((__m256i *)(buf + e),     XOR(XOR(v0,v1),XOR(v2,v3)));
(gdb)

Should be fixed by https://github.com/tromp/cuckoo/commit/7454620fc3ca42f7cbc43c53b5a501fc3a3ca350
To fix this before the next grin-miner update, you can run
git submodule update --remote --recursive
and rebuild grin-miner

Should be fixed by tromp/cuckoo@7454620
To fix this before the next grin-miner update, you can run
git submodule update --remote --recursive
and rebuild grin-miner

it seems I still have problem with cuckaroo_cpu_avx2_29 miner plugin

Note that I needed a fix in another place too. Are you using https://github.com/tromp/cuckoo/commit/a074dcc44240e09d8494b75b5bbab9d674d92a68 or a later commit?

Note that I needed a fix in another place too. Are you using tromp/cuckoo@a074dcc or a later commit?

I will recheck later. I just run git submodule update --remote --recursive and rebuild

thanks, it worked with this commit https://github.com/tromp/cuckoo/commit/4ec7302515b95178a04652985d078dbb38bbde7d

Ok, feel free to close this issue.


Allow key value metadata to be set after writing rows

This adds a KeyValueMetadata method to the writer to allow key value file metadata to be updated after the writer is created.  This allows for writing metadata that might be derived from the rows without having to buffer all the rows before creating the writer.
Fixes #397.

Should we add these methods to the GenericWriter type as well?

Latest commit adds the method to GenericWriter as well.


Help Panel

This commit addresses this issue by adding a HelpPanel. You can pass in a template or html that will show up as a panel on the admin UI to help content managers.

Related to #2335

@chungky 👏
To make this PR easier to review, it would be helpful if you could:

Add a screenshot to demonstrate what this looks like for end users.
From what I understand this is introducing reusable code – does it need to be documented somewhere? Not expecting you to know how and where to do that, but please let us know what you think would be useful.
This introduces a bit of front-end code – please mention what browsers you tried it in (the code is fairly simple in that instance so I'm not expecting issues, but it's still good to know what has been tested so far, no matter how little).

Tested on the latest versions of chrome, firefox, and safari.

Could you put as well a screenshot for the version of the panel with a title, please? :)
After all these little changes I suggested, it’ll be good to merge :D

@BertrandBordage Any other tweaks?

Thank you very much @chungky :)


Update to preview 8

I ended up skipping preview 6 because some JSON APIs didn’t line up between CoreFX and ASP.NET.
We should give preview 7 a try and see if we can get it to link successfully with CoreRT.

Alright, I'm going to give this a go before there's a preview 9 and I have to change the issue title again 🤞


onConflict().ignore() doesn't alter return type to allow undefined

An .onConflict().ignore() query will return undefined on conflict, however the typings don't reflect that:
const image_id = await db.image.get("id").create({ id: 1 }).onConflict("id").ignore()
// image_id is typed as number, yet it can easily be undefined

This appears to be more complex to solve than expected (SO answer regarding this), but interesting.

Without getting deep into details, there are cases in which what is suggested in that SO answer cannot be implemented. Besides it's an abnormal query that can cause race conditions unless done super carefully.
So let the ignore indeed return undefined if not created.

image_id is typed as a number, yet it can easily be undefined

I couldn't reproduce it, because get will throw on undefined. getOptional is returning a proper type.
Correct me if I'm missing something, but looks like no code updates are needed, only I should update docs to make this behavior clear. onConflict().ignore() may return nothing. In some cases, it may be a desired behavior. If it's not, there is find().orCreate()  that will always return data.

I couldn't reproduce it, because get will throw on undefined.

This makes sense, and I can't reproduce it now either. I was sure there was a typing error (I would open this without reason, I have to overcome the laziness every time lol), but now I'm not seeing it in the standalone reproduction script in the latest orchid. Sorry for the noise.

Correct me if I'm missing something, but looks like no code updates are needed

Correct — I wasn't implying any (other than adding | undefined if there was a need — but apparently there is none). I'm not familiar with all the idiosyncrasies of ON CONFLICT so can't really advise on the specifics. I have no specific use case for pursuing these potential complex queries so I agree that it should be left as is for the time being.

There was a bug: table.create().onConflict().ignore() didn't have undefined and now it will have.
And I changed ignore to add undefined in any case:
// can be undefined despite of `get`
const res: number | undefined = db.table.get('id').create(data).onConflict().ignore();

Updated ignore docs to highlight this.


Mobile optimised version

Currently the app is not usable on mobile at all (iPhone). The announcement popup is in the way and cannot be closed.
For a first improvement it would be great just to be able to add or edit cards, someone on a desktop (the organiser) could move things around if needed.

I agree, currently the app is lacking mobile love.
Would you be interested in helping on it and create some pull requests on this issue here on github? It would be awesome.
Thanks,
Glauber

I made some improvements and now it's way easier to use on mobile.
I have a question: should we keep functions like "add column", "delete cards" on mobile version?

@glauberramos we should. Users would expect to be able to access all features regardless of device


TypeError: argument of type 'ABCMeta' is not iterable

Hi,
I encountered this error when I was trying to run this command: 'python -m behavior.benchmark.behavior_benchmark --agent-class PPO --ckpt-path /tmp/my_checkpoint --split cleaning_toilet'.
It seems that because of loading the checkpoints. Do you know how to fix it?
Many thanks!

Hi
Could you post the error?
thanks

Hi,
The error is posted. I am using stable_baselin 3 = 1.5.0, torch = 1.11.0

Hi!
Yes, we are seeing some issues with stable_baselines ourself, even importing PPO crashes.
Do you need stable baselines for your work? Otherwise, I would recommend commenting out the imports until they fix the issues.

@HUSTColinLee , could you share an example of your checkpoint to help me reproduce your issue? our other issues with SB3 are gone

Hi!
I tried the checkpoint you provided in the repository. Its path is '/behavior/behavior/benchmark/agents/checkpoints'. Here are two checkpoints: ' onboard_sensing_ppo_random.zip' and 'full_observability_ppo_random.zip'. Both of them are not working in my case.
And I encountered another problem when I was trying to implement the imitation learning baseline today. According to the documentation, the BC agent uses task observations (456) and proprioception feedback (20) as state space. But in fact, the training dataset you provided has 456 observations and 22 proprioceptions.
The above problem is not difficult to fix but I encountered another one when I run 'test_bc_agent.py'. The config file I used is 'behavior_full_observability.yaml'. It has 90 proprioceptions and 456 task observations. This code cannot run successfully, as in the training phase there are only 22 proprioceptions. The content of config file and the error are attached. Can you help me with this issue?

Many thanks!

@HUSTColinLee Hi Colin I basically had the same issues. It seems that the two checkpoint files do not work for current version of code. I tried simple_bc_agent.py and found the inconsistencies of dimensions of proprioception. You only need to change line 21 and 49, proprioception_dim=22 and it should work.
I think more important questions include 1) the baseline of training agents using action primitives 2) how to reproduce and replay the demo using action primitives...

@HUSTColinLee , sorry for the delay. I was exploring this. The issue is a newer version of python. Are you using python 3.7? I think the breaking change is with python newer versions, e.g., 3.10. Those versions are incompatible with stable baselines

It might be due to opencv, stable-baselines or cloudpickle version mismatch.
Can you try these?
pip uninstall cloudpickle
pip uninstall opencv-python
pip uninstall opencv-contrib-python
pip uninstall stable-baselines3

pip install stable-baselines3==1.5.0
pip install cloudpickle==2.1.0
pip install opencv-contrib-python==<IP_ADDRESS>

Hello @ChengshuLi  @roberto-martinmartin I am facing the same issue as @HUSTColinLee : "the dimension of proprioceptions is 90 from test_bac_agent.py while it is 22 for the model". Running all the pip installs (as you've mentioned previously) did not solve this issue. How to go about this?
My pyhon version is Python 3.8.13

Hi, I'm getting the same error as in the second comment. I am running the following:
python -m behavior.benchmark.behavior_benchmark --agent-class="PPO" --ckpt-path=".../behavior/benchmark/agents/checkpoints/onboard_sensing_ppo_random.zip"


ready event fired multiple times

Is it intended behavior that 'ready'event fires multiple times ?
To reproduce:
var chokidar = require('chokidar');

var watcher = chokidar.watch([ '**', 'a', 'ak', '**.js*' ]);

watcher.on('ready', function() {
    console.log('ready');
});

chokidar version 1.0.1

For a temp hack I'll add a debounce for the callback:
    watcher.on('ready', _.debounce(function() {
        // stuff
    }, 500));

Hmm, I think it's a bug, but I haven't really thought about it in the context of an array of watch patterns. Will need to look into it.
A better temp hack may be watcher.once('ready', ...

Ok good to know. Yeah that's definitely a better temp hack.

This has been reported again in #338. Will close this one and allow discussion on the topic to resume in the newer thread.


deleting a Terraform should delete any pending apply jobs first

we're using the most excellent terraform-operator  on the Jenkins X project as a way to run multiple system tests on each Pull Request build. Its working really well so far. We'd love to extend that further and use the terraform-operator inside Jenkins X's preview environments so that its super easy to get automated preview environments via Terraform (e.g. spin up preview k8s clusters and associated cloud infrastructure for each PR).
However we've hit a minor issue.
We're using the postrunScript  mechanism like this example: https://github.com/jstrachan/jxr-versions/blob/tf-operator/.lighthouse/jenkins-x/bdd/terraform.yaml#L54 to connect to the BDD test kubernetes cluster and run tests inside that cluster and report back the success/failure.
The problem we have is if we trigger another BDD test of the same Pull Request (e.g. via a new commit or triggering a retest) we garbage collect old tests (via the jx test plugin which the performs essentially the following:
kubectl delete terraform $the-terraform-for-the-old-build

this generally works OK apart from if the apply job is still running (e.g. the terraform apply completed and now the test is running in the postrunScript.
The problem is the terraform destroy then runs, destroys the cluster, usually makes the postrunScript fail and re-run the pod in the Job which then brings back the cluster we've just removed ;)
To work around this it would be awesome if we could add a flag to eagerly remove any pending apply Job before running the destroy Job. Then we don't have old cloud infrastructure coming back again which then needs a manual garbage collect.
I'm happy to submit a Pull Request - I just wanted to double check this all sounds fine to you.
I'm thinking of adding a deleteApplyJobOnDelete flag or something like that - which if enabled would remove the apply job if its not completed before running the delete Job

I'm humbled and flattered jenkins-x is using this project. This use case here makes a lot of sense. I'll take a look at the implementation soon.

our BDD tests got switched over to the operator yesterday and so far things are working great ;)
the terraform-*.yaml files are the main Terraform resources used in testing: https://github.com/jenkins-x/jx3-versions/tree/master/.lighthouse/jenkins-x/bdd
then the script actually triggers the terraform operator: https://github.com/jenkins-x/jx3-versions/blob/master/.lighthouse/jenkins-x/bdd/terraform-ci.sh#L200-L210
typically Jenkins X BDD tests involve creating 2 git repositories; one for terraform/infra and one for helm stuff (used by the git operator installed via a helm chart via terraform) - though the nice thing about the terraform operator + the Terraform resource is its just declarative configuration whether a new repo is created per BDD test / PR or whether we just reuse the same terraform repo. e.g. the kube bdd test just uses a simple GKE based terraform repository for terraform

btw we're using this little CLI tool jx test to create the Terraform resource and tail the log of the operator job to then report BDD tests in pipelines nicely so developers get feedback + logs of the terraform + the actual test running and then pass/fail the pipeline etc.


list typed-json in new Scala section

This is early stage, but is already passes tests in JSON-Schema-Test-Suite/tests/draft2020-12.

Thanks!


nvidia-kernel-oot: Conflicts with intree kernel modules of the same name

There seems to be an error when installing intree kernel modules that are also RPROVIDED by nvidia-kernel-oot.
Relevant prerequisites:
Branch: scarthgap
PREFERRED_PROVIDER_virtual_dtb = "nvidia-kernel-oot"
IMAGE_INSTALL += "kernel-modules
Only nvidia-kernel-oot-base is explicitly added to the custom image.
When I try to build a custom image the following error occurs:
ERROR: jetson-image-custom-1.0-r0 do_rootfs: \
Unable to find package with name 'kernel-module-tegra-drm-5.15.136-l4t-r36.3-1009.9+g46cdb595bebc' \
in SPDX file /home/tschuster/project-lms/build/tmp/deploy/spdx/by-hash/jetson_agx_orin_orito/ \
sstate:nvidia-kernel-oot:jetson_agx_orin_orito-lms-linux:36.3.0:r0:jetson_agx_orin_orito:12: \
/nv-kernel-module-tegra-drm-5.15.136-l4t-r36.3-1009.9+g46cdb595bebc.spdx.json

This error occurs for all conflicting modules.
Possible solution:
By filling the RPROVIDES and RREPLACES variables of the oot modules, intree kernel modules of the same name are replaced and the above error is resolved.
nvidia-kernel-oot_36.3.0.bb:
-        d.appendVar('RPROVIDES:' + oot_pkg, ' ' + newprovides + ' ' + newprovides_virt)
+        newprovides_str = ' ' + newprovides + ' ' + newprovides_virt
+        d.appendVar('RPROVIDES:' + oot_pkg, newprovides_str)
+        d.appendVar('RREPLACES:' + oot_pkg, newprovides_str)
+        d.appendVar('RCONFLICTS:' + oot_pkg, newprovides_str)

I can't reproduce this in master, and I think that's because there's a fix for dependency handling in create-spdx-2.2.bbclass there that isn't in scarthgap.  Unfortunately, the fix depends on some bitbake changes that haven't made their way to scarthgap, so I can't easily test that hypothesis.
This appears only to affect the SPDX report generation, though. Package selection for rootfs construction works fine, because the OOT kernel modules have a higher version number (36.3.0) than the in-tree ones (5.15...), so they get selected. That said, it might be a good idea to add the RREPLACES/RCONFLICTS to the OOT module packages, although doing so for every module, when only 15 out of the 163 OOT modules actually conflict, seems like overkill.
There's the additional consideration of using other, newer, upstream kernels, that some folks may try to do.  I'm not sure the out-of-tree versions should still be favored in that case, so we may also need to add PREFERRED_RPROVIDER settings for each of the conflicting modules as well, which could be overridden when needed.
So I'm not sure what the right answer is, especially when it looks like the issue is actually in the SPDX report generation code.

The error does not occur if the conflicting modules are explicitly added to the image, e. g. via MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "nvidia-kernel-oot-alsa nvidia-kernel-oot-display. I will try on my end if the updated bbclass would fix the problem.
I also want to use newer upstream kernels, but for newer kernels the oot modules do not build due to changes in kernel APIs. Are the OOT modules supported for newer kernel version or would I have to manually patch the oot modules I need to use (especiallly nvpgu)?

I think do_rootfs gets confused because it wants to install the conflicting kernel-module (explicitly added by IMAGE_INSTALL += "kernel-modules") and sees nvidia-kernel-oot as the provider because it set as PREFERRED_PROVIDER_virtual/dtb and has a higher version number. Then it fails because it was never explicitly specified that the oot version should be added to the image and is missing from the SPDX file like the error message suggests.

The SPDX generator is definitely confused. I'd be surprised if it was due to the virtual/dtb build-time provider preference, but maybe.  I haven't studied the code enough, and it's rather complicated. If you don't care about building the SPDX files, you could remove create-spdx from INHERIT as a workaround.

Are the oot modules supported for newer kernel version or would I have to manually patch the oot modules I need to use (especiallly nvpgu)?

Yes, based on what I've seen in the Jetson Linux documentation (look for "Bring Your Own Kernel" there), at least for certain versions. I've seen some postings in the developer forum from folks that have run into some issues, though.  @ichergui has been doing some work with this, I believe, and he may be able to provide more information.ee

The SPDX generator is definitely confused. I'd be surprised if it was due to the virtual/dtb build-time provider preference, but maybe. I haven't studied the code enough, and it's rather complicated. If you don't care about building the SPDX files, you could remove create-spdx from INHERIT as a workaround.

NOTE: selecting nvidia-kernel-oot to satisfy runtime nv-kernel-module-tegra-drm due to PREFERRED_PROVIDER_virtual/dtb = nvidia-kernel-oot
I get that message in the do_rootfs log for 140 kernel modules, so I think it has something to do with having it provide virtual/dtb.
But nonetheless, it is probably a SPDX creation issue. For now, I can live with the problem and just remove the conflicting packages from the kernel config as I do not really need them in my image.

Do you really need to set newprovides to RPROVIDES here:
d.appendVar('RPROVIDES:' + oot_pkg, ' ' + newprovides + ' ' + newprovides_virt)
Wouldn't be appending the newprovides_virt enough:
d.appendVar('RPROVIDES:' + oot_pkg, ' ' +' ' + newprovides_virt)
That atleast resolves the error.

I do not think that virtual/dtb is the underlying problem but I think it would be nice to be able to disable the dtb part of the recipe via .bbappend. I for instance always provide my own devicetree recipe that inherits devicetree.bbclass and uses upstream devicetree sources.

The usual way to handle that is to have your recipe also set PROVIDES = "virtual/dtb", then set PREFERRED_PROVIDER_virtual/dtb to point to your recipe in your configuration. (Although I'd be surprised if the upstream device trees would be compatible with the NVIDIA out-of-tree drivers.)

Yes, I can work around it but as RCONFLICTS/RREPLACES is working, would adding it conditionally via a variable like e. g. PREFER_OOT_MODULES (default = "0") be an option to generally offer the possibility to preferably use the OOT modules if set?

Try the latest on master or scarthgap... I've implemented this a bit more selectively, only adding the RCONFLICTS/RREPLACES for the small number of drivers that actually conflict, and adding PREFERRED_RPROVIDER settings to point to them. That should allow for selective overrides for individual drivers, if something like that is ever needed.

Try the latest on master or scarthgap... I've implemented this a bit more selectively, only adding the RCONFLICTS/RREPLACES for the small number of drivers that actually conflict, and adding PREFERRED_RPROVIDER settings to point to them. That should allow for selective overrides for individual drivers, if something like that is ever needed.

Yes, that works and it is a more verbose solution. Thanks.


Update to standard-library 1.7.1

Apparently it's not that simple?

It is :-) You can test it using:

nix-shell -I nixpkgs=https://github.com/iblech/nixpkgs/archive/patch-agda-stdlib1.7.1.tar.gz -p "agda.withPackages (p: [ p.standard-library p.agda-categories ])"

(This pull request is a dependence of a pull request for NixOS, https://github.com/NixOS/nixpkgs/pull/147061.)

I saw that 1.7.1 was released just earlier today - I was just under the impression that the CI would grab the latest. If it doesn't, then something else needs adjusted too, so that CI passes.

I think you need to bump the STDLIB_VERSION variable in github actions as well: https://github.com/agda/agda-categories/blob/1c027debdb615b4f941f08b81647c9be504a75b2/.github/workflows/ci-ubuntu.yml#L49
Otherwise CI will always pull the specific version 1.7

Just a heads up that upgrading to this release is purely optional. Doesn't change any actual Agda code, only makes the cabal file  compatible with GHC 9.2 (hence why it hasn't been announced).

I wasn't going to upgrade, but I also won't refuse a ready-made PR that makes it all work!

@MatthewDaggitt Thank you for the pointer! I force-pushed to my branch. Let's see what the CI will make of this! :-)

The CI liked it. I'm still vaguely reluctant.  Opinions?

My two cents: If you merge it you'd have to bump (and eventually release) the agda-categories version as well, since it will not be compatible with standard-library-1.7 anymore.

Ah, the perils of making our first backwards compatible release. We realise we don't have any mechanism for compatible versioning management :laughing:

Hm... yes indeed. Any thoughts on that? We could also patch agda-categories locally in nixpkgs.

I think you should merge and bump agda-categories. Releases are simple to download, so people can stay with 1.7 if that's important to them.

I'm going to pull in a few more PRs first, and then merge-and-bump.

Is this in process still?

The PRs that I wanted to pull in are in. I just have not had any time to devote to this in the last few weeks. Looks like the next 2 weeks are also a disaster, but clear up after that. I'd be happy to get a co-maintainer though from the people who have submitted many PRs previously, such as @TOTBWF or @sstucki .

I'd be more than happy to help out!

I'd be more than happy to help out!

Great - see your email for more.


Fixing regression from #202

AccumulateNode needs to accumulate once per fact-binding group instead of sharing an accumulated result across fact-binding groups
Added test to expose the issue

I'd like some more clarity on https://github.com/rbrush/clara-rules/pull/216/files#r75279029 and I think the testing could use some improvement.  Otherwise +1.

I have addressed all the comments I've seen at this point.

Merged!


Naming is hard, need help

@gquintard I need your naming skills for the few leftover items.... but make sure your Rust hat is on... not the C one :)

VSC -> Statistics (?)
VSCInternal -> StatsInt  /  StatsImpl / ...?
VSCBuilder -> ?
VSCBulder::build -> attach -- I think build is a bit confusing here (funny - in this case I actually am siding with the internal Varnish naming)
vsm_error -> ?

This is a followup from #39

I'd go with Stats;  StatsImpl is ok, I don't think it's pub anyway.
vsm_error -> VSMError?


Vs code Open file Explorer Can't automatically track file location.

Vs code Open file Explorer Can't automatically track file location. This feature is normal in previous versions. After updating this version, it won't work.

/needsMoreInfo are you talking about the behaviour controlled by the autoReveal setting?
What version did you upgrade from and notice the change?
Does the problem also happen when you run with all extensions disabled?

@gjsjohnmurray thanks .i don't know how to do.now

@AtlantisDe it looks like you tried to paste images into your original post, but the links don't work for me.
Does the explorer.autoReveal setting exist in the workspace-level settings file .vscode/settings.json for either of your workspaces?

@gjsjohnmurray
I am sure that it is a folder, and occasionally it will not work properly. I am now all replaced, the  workspace open.


Tag stages take two - additional tags for the rootless install - replacement PR

Description
This is a replacement for the original PR 639, merged with 6.2.x code and review changes applied. I have no permissions to the original PR so created a new one.
Original description:
Add additional tags to various stages, allowing certain operations to be skipped if they require root access (using --skip-tags).
Adds additional variables that does not hardcode the location of /etc/, so that configuration files can be placed in alternative locations (applies mostly to archive installation).
Fixes # (issue)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Test Configuration:
Completed archive based installation with and without specifying --skip-tags.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Any dependent changes have been merged and published in downstream modules
[x] Any variable changes have been validated to be backwards compatible

This is an old PR and corresponding Jenkins pre-check has expired. I have verified it on my setup and it works fine.


Alignment of Articles Section Blue lines and Read Box

Is there an existing issue for this?
I have searched the existing issues
What happened?
Alignment of blue lines in the Article section and Read line Box

Record:

I agree to follow this project's Code of Conduct
I'm a GSSOC'24 contributor
I want to work on this issue.

@akshitagupta15june, Please assign me this task.

Go for it!


NetworkReachabilityManager reports notReachable after each change

I having a strange issue, not sure if it is my fault or a real issue. Using the NetworkReachabilityManager, after each update a notReachable-flag gets fired about 0.01 - 0.04s later.

Xcode version 8.2.1
iOS target version 10.0 (in Podfile and Xcode)
Tested on hardware 10.2.1 (iPhone SE) and emulators
Alamofire version 4.3 (installed via pod today)

Am I doing something wrong?
View controller class:
import UIKit
import Alamofire

class MainViewController: UIViewController {

    var api_url: String = ""
    var reachability: NetworkReachabilityManager? = nil
    @IBOutlet weak var statusLabel: UILabel!

    override func viewDidLoad() {
        super.viewDidLoad()
        registerSettingsBundle()
        api_url = getApiUrlFromSettingsBundle()
        pingHostForReachability(stringUrl: api_url)

    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)

        // stop listening for reachability when view will disappear
        if let reachability = reachability {
            reachability.stopListening()
            NSLog("stopped listening for reachability")
        }
    }

    func registerSettingsBundle() {
        let appDefaults = [String:AnyObject]()
        UserDefaults.standard.register(defaults: appDefaults)
        UserDefaults.standard.synchronize()
    }

    func getApiUrlFromSettingsBundle() -> String {
        let defaults = UserDefaults.standard
        if let url = defaults.string(forKey: api_url_key) {
            return url
        }
        return String()
    }

    func pingHostForReachability(stringUrl: String) {
        NSLog("new reachability manager, listening @ \(stringUrl)")
        if reachability != nil {
            reachability?.stopListening()
        }
        reachability = NetworkReachabilityManager(host: stringUrl)
        reachability?.listener = { status in
            NSLog("Network Status Changed: \(status)")
            switch status {
            case NetworkReachabilityManager.NetworkReachabilityStatus.reachable(let connectionType):
                let type = connectionType.hashValue == 0 ? "WLAN" : "WWAN"
                self.statusLabel.text = "Status: Connected (via \(type))"
                break

            /*case NetworkReachabilityManager.NetworkReachabilityStatus.notReachable:
                self.statusLabel.text = "Status: No Connection"
                break
            case NetworkReachabilityManager.NetworkReachabilityStatus.unknown:
                self.statusLabel.text = "Status: Unknown"
                break*/

            default:
                self.statusLabel.text = "Status: No connection"
                break
            }
        }
        reachability?.startListening()
    }

}

Logs, switched between 3g and wlan:
2017-02-03 15:03:06.211886 app[752:117893] new reachability manager, listening @ http://google.de
2017-02-03 15:03:06.237435 app[752:117893] Network Status Changed: reachable(Alamofire.NetworkReachabilityManager.ConnectionType.ethernetOrWiFi)
2017-02-03 15:03:06.238725 app[752:117893] Network Status Changed: notReachable
2017-02-03 15:03:19.688307 app[752:117893] Network Status Changed: reachable(Alamofire.NetworkReachabilityManager.ConnectionType.wwan)
2017-02-03 15:03:21.736435 app[752:117893] Network Status Changed: notReachable
2017-02-03 15:03:24.618858 app[752:117893] Network Status Changed: reachable(Alamofire.NetworkReachabilityManager.ConnectionType.wwan)
2017-02-03 15:03:24.622224 app[752:117893] Network Status Changed: notReachable
2017-02-03 15:03:32.554985 app[752:117893] Network Status Changed: reachable(Alamofire.NetworkReachabilityManager.ConnectionType.ethernetOrWiFi)
2017-02-03 15:03:32.602293 app[752:117893] Network Status Changed: notReachable

I have the same kind of problem when first subscribing for reachability changes. If the app is launched with internet connection, listener closure gets .reachable status and then immediately .notReachable.

Same problem here. It actually happens with any reachability frameworks so I think problem is in SCNetworkReachability

Yes, you should not have the scheme on the string you're checking for reachability.

It seems if the URL has any "/" characters really funny stuff will happen. It will report as reachable then immediately after it will report as .notReachable
I want to hit the health check pages to get a 200 OK. Some services are more than the URL that hosts them.

Yes, the reachability URLs are only supposed to be the host (e.g. https://apple.com/imac would be apple.com).

But I have many services that I want to monitor.
Is www.apple.com the only actual supported url?

No, you can check any host, but you should setup the ReachabilityManager with only host strings. Trying to monitor some.host/something won't work correctly.

Host used to evaluate network reachability. Must not include the scheme (e.g. https).


tests: Disable CT cleanup tests for now

Signed-off-by: Thomas Graf<EMAIL_ADDRESS>

There's also 03-docker.sh line 67-76

There's also 03-docker.sh line 67-76

Also addressed


vq-wav2vec train.py unrecognized arguments

❓ Questions and Help
Before asking:

search the issues.
search the docs.

What is your question?
Code

What have you tried?
What's your environment?

fairseq Version (e.g., 1.0 or master):
PyTorch Version (e.g., 1.0)
OS (e.g., Linux):
How you installed fairseq (pip, source):
Build command you used (if compiling from source):
Python version:
CUDA/cuDNN version:
GPU models and configuration:
Any other relevant information:

Hello, I am hoping to train a new vq-wav2vec model as described in the example on this page:https://github.com/pytorch/fairseq/tree/master/examples/wav2vec. I am using Google Colab with the code from this page, edited to include the paths for my files and manifest:
! python train.py /manifest/path --save-dir /model/path --num-workers 6 --fp16 --max-update 400000
--save-interval 1 --no-epoch-checkpoints --arch wav2vec --task audio_pretraining --lr 1e-06 --min-lr 1e-09
--optimizer adam --max-lr 1e-05 --lr-scheduler cosine
--conv-feature-layers "[(512, 10, 5), (512, 8, 4), (512, 4, 2), (512, 4, 2), (512, 4, 2), (512, 1, 1), (512, 1, 1), (512, 1, 1)]"
--conv-aggregator-layers "[(512, 2, 1), (512, 3, 1), (512, 4, 1), (512, 5, 1), (512, 6, 1), (512, 7, 1), (512, 8, 1), (512, 9, 1), (512, 10, 1), (512, 11, 1), (512, 12, 1), (512, 13, 1)]"
--activation gelu --offset auto --skip-connections-agg --residual-scale 0.5
--log-keys ["prob_perplexity","code_perplexity","temp"] --vq-type gumbel --vq-groups 2 --vq-depth 2
--combine-groups --vq-vars 320 --vq-temp "(2,0.5,0.999995)" --prediction-steps 12 --warmup-updates 1000
--warmup-init-lr 1e-07 --criterion binary_cross_entropy --num-negatives 10 --max-sample-size 150000
--max-tokens 300000 --cross-sample-negatives 0 --update-freq 1 --seed 2 --skip-invalid-size-inputs-valid-test
I get the following error: train.py: error: unrecognized arguments:  --log-keys [prob_perplexity,code_perplexity,temp]
Do you know how to fix this problem? I appologize if I am missing something obvious as I am new to Python. Thank you!

What version of fairseq are you using?  It looks like 3335de5f441ee1b3824e16dcd98db620e40beaba was the commit that added --log-keys, so you will need to use master, not the latest release.  You should be able to do pip install git+https://github.com/pytorch/fairseq to install the latest master version.


[Event Request] report 81 "Import Budget from Excel" - OnAfterGetRecord

Hello,
Please add this handled event:

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Panic when backing up to Amazon S3

Output of restic version
restic 0.6.1 (v0.6.1-56-g0b55be25)
compiled with go1.8.3 on linux/amd64

How did you start restic exactly?
Amazon S3
Expected behavior
I expected my backup to succeed? :man_shrugging: I know that's not incredibly useful. Happy to answer more questions though.
Actual behavior
scan [/home/gabe/projects/aten /home/gabe/projects/contrib /home/gabe/projects/github.com /home/gabe/projects/bitbucket.org /home/gabe/projects/drupal.org /home/gabe/projects/go/src /home/gabe/projects/presentations /home/gabe/projects/devops /home/gabe/Documents]
scanned 172600 directories, 620951 files in 1:50
panic: client.PutObject: Put https://s3-us-west-2.amazonaws.com/<mybucket>/restic/data/02bda62992525e37cd5a0f7920a5be25b916d541beeacd928b6b6be0147f6f9c: dial tcp: lookup s3-us-west-2.amazonaws.com on [2601:282:204:3d83:6a1:51ff:fee7:cc58]:53: read udp [2601:282:204:3d83:931b:80a:708a:3256]:48578->[2601:282:204:3d83:6a1:51ff:fee7:cc58]:53: i/o timeout

goroutine 52544 [running]:
restic/archiver.(*Archiver).saveChunk(0xc420337950, 0xc194a0, 0xc420018428, 0x0, 0x2e4d8, 0x1, 0xc421cca000, 0x2e4d8, 0x80000, 0xc420434840, ...)
	src/restic/archiver/archiver.go:164 +0x293
created by restic/archiver.(*Archiver).SaveFile
	src/restic/archiver/archiver.go:238 +0x3a4

Steps to reproduce the behavior
I'm not sure if there's anything especially unique or complicated that I'm doing to get this bug to come up. This happens every time I run the backup script above.
Do you have any idea what may have caused this?
The only thing that I might have done that was strange is killed the backup script with ^C multiple times as I was attempting to get all my --excludes correct. Perhaps this corrupted my bucket in some way? Sorry, wish I knew more about this to give a better bug report.

Thanks for the report, and for providing all the details in the template. Could you please run the backup again, and when the error occurs then dump the currently active connections with netstat -an | egrep :(443|53) > /tmp/netstat? Then either paste this file here (maybe redacted) or have a look at the number of connections to s3 (in state ESTABLISHED or TIME_WAIT). Are there a lot?

The issue should be fixed in #1025, could you please give the code in the branch fix-1013 a try?

Here is the output of netstat pre fix-1013.  I am running with fix-1013 now and will report back on whether the issue is resolved.
tcp        0      0 <IP_ADDRESS>:37224       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 309313 <IP_ADDRESS>:57440       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:44730       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:35882       <IP_ADDRESS>:443      TIME_WAIT
tcp        0    748 <IP_ADDRESS>:55146       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:55112       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 765047 <IP_ADDRESS>:34116       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 227689 <IP_ADDRESS>:57400       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:41236       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:49680       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44808       <IP_ADDRESS>:443        ESTABLISHED
tcp        0      0 <IP_ADDRESS>:48026       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:48872       <IP_ADDRESS>:443      ESTABLISHED
tcp        0 254897 <IP_ADDRESS>:53302       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0 297857 <IP_ADDRESS>:57410       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:41206       <IP_ADDRESS>:443       ESTABLISHED
tcp        0    573 <IP_ADDRESS>:60984       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0 736049 <IP_ADDRESS>:34832       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48612       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:35884       <IP_ADDRESS>:443      TIME_WAIT
tcp        0 625688 <IP_ADDRESS>:35880       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0 279241 <IP_ADDRESS>:57412       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 273513 <IP_ADDRESS>:43206       <IP_ADDRESS>:443        FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48884       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:43208       <IP_ADDRESS>:443        TIME_WAIT
tcp        0     32 <IP_ADDRESS>:54790       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 884977 <IP_ADDRESS>:34114       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:42278       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 231985 <IP_ADDRESS>:43212       <IP_ADDRESS>:443        FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:44264       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:51920       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 571369 <IP_ADDRESS>:57416       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:47980       <IP_ADDRESS>:443       ESTABLISHED
tcp        0  79716 <IP_ADDRESS>:60978       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48032       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:35886       <IP_ADDRESS>:443      TIME_WAIT
tcp        0      0 <IP_ADDRESS>:51922       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 1018153 <IP_ADDRESS>:34834       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 180433 <IP_ADDRESS>:57434       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 204777 <IP_ADDRESS>:57402       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48030       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:41216       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:47824       <IP_ADDRESS>:443     ESTABLISHED
tcp        0      0 <IP_ADDRESS>:49862       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:48028       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:41740       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 276377 <IP_ADDRESS>:57408       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:44608       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:60980       <IP_ADDRESS>:443      TIME_WAIT
tcp        0      0 <IP_ADDRESS>:43768       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:53308       <IP_ADDRESS>:443      TIME_WAIT
tcp        0      0 <IP_ADDRESS>:53306       <IP_ADDRESS>:443      TIME_WAIT
tcp        0 497398 <IP_ADDRESS>:54862       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 219097 <IP_ADDRESS>:57420       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0 242009 <IP_ADDRESS>:57432       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48034       <IP_ADDRESS>:443       ESTABLISHED
tcp6       0      0 2601:282:204:3d83:37748 2001:1838:2001:e::1:443 TIME_WAIT
tcp6       0      0 2601:282:204:3d83:56462 2a00:1450:400e:800::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:34888 2607:f8b0:400e:c04::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:35770 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:35894 2607:f8b0:4005:80a::443 TIME_WAIT
tcp6       0      0 2601:282:204:3d83:36168 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:45136 2607:f8b0:4005:80a::443 TIME_WAIT
tcp6       0      0 2601:282:204:3d83:35924 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36178 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:34848 2607:f8b0:400e:c04::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:33808 2607:f8b0:400a:809::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:37750 2001:1838:2001:e::1:443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36816 2607:f8b0:4005:804::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:44798 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:34840 2607:f8b0:400e:c04::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:46098 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:46100 2607:f8b0:4005:80a::443 ESTABLISHED
udp        0      0 <IP_ADDRESS>:5353            <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:5353            <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:44837       <IP_ADDRESS>:53          ESTABLISHED
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*

fix-1013 did not resolve the issue. Here is the output of netstat with that version:
tcp        0      0 <IP_ADDRESS>:37224       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44730       <IP_ADDRESS>:443      ESTABLISHED
tcp        0 1111233 <IP_ADDRESS>:33052       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:57790       <IP_ADDRESS>:443       TIME_WAIT
tcp        0      0 <IP_ADDRESS>:57778       <IP_ADDRESS>:443       TIME_WAIT
tcp        0      0 <IP_ADDRESS>:44078       <IP_ADDRESS>:443      TIME_WAIT
tcp        0 292129 <IP_ADDRESS>:41664       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:57780       <IP_ADDRESS>:443       TIME_WAIT
tcp        0      0 <IP_ADDRESS>:55476       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:57786       <IP_ADDRESS>:443       TIME_WAIT
tcp        0 830561 <IP_ADDRESS>:33064       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:48872       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:58938       <IP_ADDRESS>:443      TIME_WAIT
tcp        0 339385 <IP_ADDRESS>:33048       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:44076       <IP_ADDRESS>:443      TIME_WAIT
tcp        0      0 <IP_ADDRESS>:48612       <IP_ADDRESS>:443      ESTABLISHED
tcp        0 165266 <IP_ADDRESS>:33050       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:44068       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:48884       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44070       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44264       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:51920       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:47980       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 297857 <IP_ADDRESS>:55570       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:51922       <IP_ADDRESS>:443       ESTABLISHED
tcp        0 462537 <IP_ADDRESS>:36020       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      1 <IP_ADDRESS>:42924       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0 443921 <IP_ADDRESS>:55568       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:40374       <IP_ADDRESS>:443      TIME_WAIT
tcp        0 307881 <IP_ADDRESS>:55566       <IP_ADDRESS>:443       FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:41740       <IP_ADDRESS>:443       ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44072       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:50782       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:44608       <IP_ADDRESS>:443      ESTABLISHED
tcp        0      0 <IP_ADDRESS>:57782       <IP_ADDRESS>:443       TIME_WAIT
tcp        0 667313 <IP_ADDRESS>:33066       <IP_ADDRESS>:443      FIN_WAIT1
tcp        0      0 <IP_ADDRESS>:43768       <IP_ADDRESS>:443       ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36598 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:46524 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:45284 2607:f8b0:4001:c0c::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:45850 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:45874 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36512 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36596 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36014 2607:f8b0:400e:c04::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36480 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36496 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36486 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36010 2607:f8b0:400e:c04::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:46522 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       0      0 2601:282:204:3d83:36494 2607:f8b0:4005:80a::443 ESTABLISHED
tcp6       1      1 2601:282:204:3d83:36478 2607:f8b0:4005:80a::443 CLOSING
udp        0      0 <IP_ADDRESS>:5353            <IP_ADDRESS>:*
udp        0      0 <IP_ADDRESS>:5353            <IP_ADDRESS>:*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*
udp6       0      0 :::5353                 :::*

Hm, interesting. From the error message it looks like restic (via the minio-go s3 client library we're using) tries to open a new connection to s3 but the hostname lookup fails. This may be the case when too many file descriptors are used, we've seen that before but never really figured out the cause...
I have two suggestions on what you could try:

Lower the number of concurrent connections to s3, use the code in the branch fix-1013 and run restic -o s3.connections=2 backup ....  Let's see if that is of any help.
Try building restic with go run build.go --enable-cgo. This (among others) uses the libc's DNS resolver instead of the internal Go resolver.

I'm looking forward to your feedback!

When I run with the s3.connections option, I get: option s3.connections is not known
I'm wondering if I'm actually compiling the right version, I have fix-1013 checked out, but I still get:
[0] gabe ~ $ restic version
restic 0.6.1 (v0.6.1-22-ga0eebf85)
compiled with go1.8.3 on linux/amd64

I'm compiling like so:
[0] gabe restic:fix $ pwd
/home/gabe/projects/go/src/github.com/restic/restic
[0] gabe restic:fix $ git branch
* fix-1013
  master
[0] gabe restic:fix $ go run build.go

I'm running a backup with --enable-cgo and will report when done.

Something is off here, that's a very old commit. Could you please run: git fetch origin and git reset --hard origin/fix-1013?

Okay, ran fetch and reset hard.
restic 0.6.1 (v0.6.1-69-g422c0dfb)
compiled with go1.8.3 on linux/amd64

Without s3.connections=2:
scan [/home/gabe/Documents /home/gabe/projects/github.com /home/gabe/projects/aten /home/gabe/projects/contrib /home/gabe/projects/bitbucket.org /home/gabe/projects/drupal.org /home/gabe/projects/go/src /home/gabe/projects/presentations /home/gabe/projects/devops]
scanned 172876 directories, 622536 files in 1:48
panic: client.PutObject: Put https://s3-us-west-2.amazonaws.com/backup.slatebox/restic/data/88/880f109d1cb23cc04448623e8134054d1b4445c69be62786ef1b14d42cf125fc: dial tcp <IP_ADDRESS>:443: connect: network is unreachable

goroutine 21394 [running]:
restic/archiver.(*Archiver).saveChunk(0xc4201d4f00, 0xc19460, 0xc420018408, 0xc65b3d, 0x594d7b, 0xd928754100000, 0xc424592000, 0x594d7b, 0x5e4000, 0xc4202d6630, ...)
	src/restic/archiver/archiver.go:165 +0x395
created by restic/archiver.(*Archiver).SaveFile
	src/restic/archiver/archiver.go:239 +0x3a4

With s3.connections=2
To be determined, but it's been uploading for 45 minutes and there's an estimated 45 minutes left. That's the longest and furthest I've gotten yet. I will report back if it succeeds/fails.

What's your upstream bandwidth? We've had a similar case in #1013, which is probably caused by too many connections on a very narrow upstream bandwidth...

Success with s3.connections=2!
It averages just about ~1.5 Mb/s.

Thanks! I'll merged the branch later today, I've added a comment about future plans here: https://github.com/restic/restic/issues/1013#issuecomment-307752029

Thanks for all your help! Great project!

The branch is merged, thanks for your patience!


[core] Avoid !important in borderColor prop

[x] I have followed (at least) the PR section of the contributing guide.

Avoid adding !important to the style rule when using borderColor.

Closes https://github.com/mui-org/material-ui/issues/16853

@rogerclotet Thanks.


Property:endedAtTime

Label
Ended At Time

Definition
The date or time when a Person stopped fulfilling the role specified in the role property.

Usage

Existing property

Existing class

Existing property identifier

Format
Datetime

Required
No

Repeatable
No

Constraints
Date format conforming to https://www.w3.org/TR/NOTE-datetime date format.

Examples
1886, 1984-09, 2001-10-22, 1997-07-16T19:20+01:00, 1997-07-16T19:20:30+01:00

Notes
This property maps to the PROV-O term endedAtTime (http://www.w3.org/ns/prov#endedAtTime) in the Activity class (http://www.w3.org/ns/prov#Activity).

This property is deprecated as part of the expert review in favour of including temporal coverage. See issue https://github.com/tdwg/cd/issues/466


Fix #1885: Check return value before creating dynamic class.

Hello!

Type: bug fix
Link to issue: #1885

In raising this pull request, I confirm the following:

[x] I have checked that another pull request for this purpose does not exist
[x] I wrote some tests for this PR
[x] I updated the CHANGELOG

Small description of change:
Code to check the $classEntry value before calling the method Zephir\BaseBackend::initObject() inside of Zephir\Operators\Other\NewInstanceOperator.
Without this check, it's possible that NULL could be passed through and end up causing a segment fault. Happens when auto-loading a class with a syntax error.
Thanks

@davidofferman Thank you for contributing. We don't add changes directly to stable branches or master. Could you please send this PR to the development branch?


Live Share cursor is incorrect on Linux distros with desktop environments other than Gnome or Unity

While Ubuntu has been the primary focus of initial validation for Live Share, we have found that many other distributions also work once the correct pre-requisite libraries are installed.
However, one distribution specific issue we have found is that some distributions that use non-Gnome based desktop environments (e.g. SuSE KDE, Manjaro Xfce) will see an incorrect representation of participant's cursors.

Seems to be working here, Arch Linux w/ KDE.

I'm going to close this since we haven't actually heard anyone report it, and @odensc claims that it didn't even repro on distros we thought it did 😄 Please re-open this if the issue is still happening, and we can look into fixing it.

Same error found in a section opened in OpenSuse Tumbleweed with Xfce4
The participant is in Windows 10, my cursor is ok in his PC,
but his cursor is looking like this on mine:

Closing due to age of bug. Please re-activate if the issue is still appearing.

@Davsterl I'm having this issue in Opensuse Tumbleweed.
Desktop environment: GNOME
Another person was having the same problem in the thread.
It would be great if this could be reopened.

@Davsterl I'm having this issue in Opensuse Tumbleweed.
Desktop environment: GNOME
Another person was having the same problem in the thread.
It would be great if this could be reopened.

We’re not able to prioritize this issue over the other higher-impact issues we receive every week, based on the votes and comments from others in the community and our understanding of the issue. However, rest assured that we love your input. If you feel it deserves to stay open, then clarify your use case and contact us to let us know how severe it is for you.

That cursor uses U+19D9 (https://www.compart.com/en/unicode/U+16D9). therefore you have to install fonts that contains it.
sudo pacman -S gnu-free-fonts


No offhand slot visible

I've installed backhands and backhand slot does not wrok
Might be connected to other instaled mods, like baubles, or traweler'sGear

the mod is now maintained by GTNH in this fork


Reduce requirements

In particular dask[array] now depends only on toolz and numpy  cc @stefanv
Changes

Remove use of psutil when finding number of cores.  multiprocessing does this instead
Remove unused chest import from dask.array
Protect chest import in dask.dataframe
Removed toolz from core dependencies, still required for all collections though

:+1:

Closes #194


Suspicious stew texture doesnt change on gui

The issue
suspicious stew texture doesnt change on the gui

How to reproduce
fortheissue.zip
Logs
my game didnt crashed so it is useless(idk how to add file here)
Checklist

[X] I checked the issues(both open and closed) and could not find a duplicate of my issue
[X] I am using the latest version of CIT Resewn for my Minecraft version
[X] I have disabled Broken Paths and the issue persists
[X] I am running the mod using Fabric Loader

https://github.com/SHsuperCM/CITResewn/issues/272
https://github.com/SHsuperCM/CITResewn/issues/321
May be those are related? If u have Eating Animations mod then it's likely its problem


Make someone the lead developer/maintainer who has got time on their hands

@rianjs As it is apparent, that you have other things on your mind, you should transfer the development and support of this project to active members of the community.
This is preferable over the community creating a fork and continuing development from there, since this package is the number one on nuget in regards to iCalendar support and the community will profit from easy discoverability of its continued development under the same name.

https://github.com/rianjs/ical.net/issues/495


Update cache action

Instead of using the simple change from the dependabot, let's update the config for the v2 of the action, which allows to use multiple paths in one step.

Pull Request Test Coverage Report for Build a34eea96effb4ecac099e7c3d8b209b744deef8e-PR-92

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.412%

Totals

Change from base Build 4458b3fe0f02462049910e6148824977bd923bd5:
0.0%

Covered Lines:
108

Relevant Lines:
136

💛  - Coveralls


chore: [FX-3408] use Davinci by parts

FX-3048
Description

Remove @toptal/davinci from dependency and add missing @toptal/davinci-* packages

How to test

Everything should be the same, start storybook, generate new component, lint, run tests, etc

Screenshots

Before.
After.

Insert screenshots or screen recordings
Insert screenshots or screen recordings

Development checks

Add changeset according to guidelines (if needed)
Read CONTRIBUTING.md and Component API principles
Make sure that additions and changes on design follow Toptal's BASE design, and it's been already discussed with designers at #-base-core
Annotate all props in component with documentation
Create examples for component
[x] Ensure that deployed demo has expected results and good examples
[x] Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.
[x] Self reviewed
Covered with tests

Breaking change

codemod is created and showcased in the changeset
test alpha package of Picasso in StaffPortal

All development checks should be done and set checked to pass the
GitHub Bot: TODOLess action

PR commands

List of available commands:

@toptal-bot run all - Run whole pipeline
@toptal-bot run build - Check build
@toptal-bot run deploy:documentation - Deploy documentation
@toptal-bot run package:alpha-release - Release alpha version
@toptal-anvil ping reviewers - Ping FX team for review

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

@toptal-anvil ping reviewers


Connect to Mongo DB

Story
As a developer I want my data to be saved and persist. As a result we should make sure our data is stored in a database.
AC

[x] NoSQL is preferrable because we can extend this to make the objects more descriptive as time goes on and not having to worry about a bunch of Foreign Keys.

Passed testing


To solve the issue of generating excessively large execution plans when encountering multiple levels of subqueries while enabling DynamicPartitionPruning.

[SPARK-48486][CORE] Instead of PartitionPruning#prune is expected
What changes were proposed in this pull request?
The code of method: prune in class: org.apache.spark.sql.execution.dynamicpruning.PartitionPruning is modified. And class: org.apache.spark.sql.internal.SQLConf has added a property value: DYNAMIC_PARTITION_PRUNING_MAX_LENGTH and a dynamicPartitionPruningMaxLength method.
Why are the changes needed?
In order to address the issue of Spark's DynamicPartitionPruning generating plans with excessive character length and causing excessive memory usage leading to OOM errors when encountering too many levels of subqueries.
Does this PR introduce any user-facing change?
yes
When DYNAMIC_PARTITION_PRUNING_ENABLED is set to true and DPP optimization is enabled, the generated execution plan may trigger a potential issue.
How was this patch tested?
I have provided test cases as much as possible.
Was this patch authored or co-authored using generative AI tooling?
no

Mind filing a JIRA please? See also https://spark.apache.org/contributing.html


Add Copy packages command for registry to registry image and chart copy

New command that takes advantage of oras copy command to copy images from one registry to another. The primary use case for this would be to copy images from ECR to Harbor or other private registry.

supports multiple architecture image copy duplicating arm and amd
preserves shasum of images from ECR to harbor so we can use the shasum for installation

/test eks-anywhere-release-tooling-test-presubmit

/test eks-anywhere-release-tooling-test-presubmit

Closes: https://github.com/aws/eks-anywhere/issues/4109

/approve

/test eks-anywhere-release-tooling-test-presubmit

/lgtm
Good luck with those tests

/test eks-anywhere-presubmit
/test eks-anywhere-release-tooling-test-presubmit

/test eks-anywhere-release-tooling-test-presubmit

/override eks-anywhere-release-tooling-test-presubmit
this is failing because of the golden file being out of date again. I just merged a new one this morning and already it is out of date.

/override eks-anywhere-release-tooling-test-presubmit

/cherry-pick release-0.14


[SPARK-37791][EXAMPLES] Use log4j2 in examples

What changes were proposed in this pull request?
This PR aims to use log4j2 in examples.
Why are the changes needed?
Since Spark is migrating to log4j2, we best use this in our examples.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Manually review.

cc: @viirya and @dongjoon-hyun

@dongjoon-hyun I missed these log4j usage in the examples. Actually they are on log4j 1.x bridge api, not log4j 1.x now. We should also move them to log4j2.

Got it. Thank you, @viirya .
Merged to master. Thank you, @williamhyun and @viirya .

@williamhyun . While you are here, could you add a scalastyle to ban org.apache.log4j? It would be very helpful for preparing the removal of the bridge.

FYI. I'm going to remove bridge api usage at #35075.

Oh, I made a PR for adding a new checkstyle rule without seeing, #35075 .

https://github.com/apache/spark/pull/35077

What can I proceed with #35075 , @viirya and @dongjoon-hyun ?

No problem. Just please wait a while. We will merge @viirya 's PR first. Then, you can rebase your PR against master branch, @williamhyun .


Limit List of Concurrent Jobs

Hi,
There might be a need to limit the list of concurrent jobs for long running shared jobs on the job details page, see screenshot:

Moved list into own scrollable card component.


Stop harvesting packages in runtime: remove prebuilts

Conditionally remove the import of restore\harvestPackages.targets to remove some PackageDownload elements bringing in prebuilts.
For https://github.com/dotnet/source-build/issues/1844.

The last leg succeeded but timed out during publish/cleanup. Now it's not able to get build agents for a retry due to https://github.com/dotnet/core-eng/issues/11320. Going ahead with merge since it was effectively green.


fix displayName of connected components

Sometimes when using general-store you see components named "Connected(undefined)" when you'd expect "Connected(MyRealComponentName)". general-store does the right thing React createClass-style components which expose a displayName prop, but not for plain javascript functions and classes. Those things expose Function.name. I think that making this change will fix that.
I'm opening this PR as a reminder for myself, if it sounds good then I can add unit tests and a changelog line.
TODOs

[x] linter, checker, and test are passing
[ ] THEO ADD A NEW UNIT TEST PLEASE
[x] any new public modules are exported from src/GeneralStore.js
[ ] version numbers are up to date in package.json and bower.json
[ ] CHANGELOG.md is up to date

Since Function.name isn't a standard API and can be overridden fairly easily, wouldn't it better to just assign displayName to the class/stateless components?
// es6 component
class Foo extends React.Component {
  static get displayName() {
    return 'Foo';
  }
}

// stateless component
const Foo = () => <div />;
Foo.displayName = 'Foo';

Just my 2c 😅

Another thing to consider is that name will be the minified name in production, unlike displayName of createClass (one of the many many many annoying complexities ES6 classes introduce).
I haven't looked into it a whole lot, but I assume someone somewhere wrote a Babel plugin to take care of this (after all, with createClass its a babel plugin that handles it too)

(That wouldn't help with function components since they are not statically analyzable and there's no efficient way to figure out which are components and which aren't...and you wouldn't want to add a property on every function that kind of look like a component, so this change is probably still useful...minified name of a function component is still better than "undefined". My above comment is just for ES6 class components)

@Phoenixmatrix Heh, I was just about to retract my statement for stateless components since it actually works better than I expected (in ES2015 environments). But as you observed, it still an issue on ES6 class components.

yeah, classes also have a name and its pretty reliable, but since class components are statically analyzable, we can do a bit better at build time.

@geekjuice that's a fair point! As users of this library we could write things differently so that stuff works as designed. But I think that writing components as plain functions and es6 classes is pretty popular and unlikely to go away any time soon, so why not make general-store work for those as well?
And @Phoenixmatrix I think that you're reasoning is a good explanation for why any Component.displayName should have the higher priority over a potentially minified Function.name.
fwiw the change in this PR is pretty much what redux does too: https://github.com/reactjs/react-redux/blob/a5e45d9806492d0fe1354437111722cf15b17b4d/src/components/connectAdvanced.js#L96-L98


Caching fails when default argument value is nan

Reporting a bug

[x] I have tried using the latest released version of Numba (most recent is
visible in the change log (https://github.com/numba/numba/blob/main/CHANGE_LOG).
[x] I have included a self contained code sample to reproduce the problem.
i.e. it's possible to run as 'python bug.py'.

File test.py:
from numba import njit

@njit(cache=True)
def f_finite(x=0):
    pass

@njit(cache=True)
def f_nan(x=float("nan")):
    pass

@njit(cache=True)
def f_inf(x=float("inf")):
    pass

Running the functions for the second time:
import os
os.environ['NUMBA_DEBUG_CACHE'] = "1"

from test import f_finite, f_nan, f_inf

f_finite()
[cache] index loaded from '/.../test.f_finite-3.py39.nbi'
[cache] data loaded from '/.../test.f_finite-3.py39.1.nbc'

f_nan()
[cache] index loaded from '/.../test.f_nan-7.py39.nbi'
[cache] index loaded from '/.../test.f_nan-7.py39.nbi'
[cache] index saved to '/.../test.f_nan-7.py39.nbi'
[cache] data saved to '/.../test.f_nan-7.py39.2.nbc'

f_inf()
[cache] index loaded from '/.../test.f_inf-11.py39.nbi'
[cache] data loaded from '/.../test.f_inf-11.py39.1.nbc'

While I understand that it's all based on identity checks and nan != nan and one can use None as a substitution, every time the users passes np.nan (for example as a fill value for an array), the function will be needlessly re-cached.

@polakowo thank you for submitting this. I can confirm I am able to reproduce this with the current main at 2f2e2c1a7f940977e37901f4289b771fedbe4af2 --yes I believe that the fact that nan is always unequal to nan is the cause here. I suppose when comparing a function, it may be possible to override this default.

I don't think this is something that we should fix. It is similar to the best practice of not using NAN as key of dictionary.
Python inspect also treat two instances of the signature of f_nan as not equal:
import inspect

def f_nan(x=float("nan")):
    pass

def f_inf(x=float("inf")):
    pass

assert inspect.signature(f_inf) == inspect.signature(f_inf)   # this is ok
assert inspect.signature(f_nan) == inspect.signature(f_nan)   # this is not

NaN not being equal to NaN is an important principle in scientific computing, but I don't see any advantage of having NaN being treated differently across function signatures since two identical functions taking NaN are guaranteed to produce the same compiled code. It took me a while to understand why a bunch of my functions produce tons of cache without any particular reason (on the other hand, a zero-dimensional array with NaN will do fine because of the same data type).
I also wouldn't want to rely on None since explicitly passing NaN would still re-cache the entire thing each time.

I wonder if a workaround might be to create a custom float type that overrides __eq__ and __hash__ to do something special for the nan value and then use that?

a HashableNan just for Numba?

I also wouldn't want to rely on None since explicitly passing NaN would still re-cache the entire thing each time.

If the default value is NaN, you will get two versions:

x: omitted(default=NaN) --- goes here when the argument is omitted.
x: float64  --- explicitly passing NaN or other float value goes here.

The None case will get 3 versions:

x: omitted(default=None) --- omitting arg
x: None  --- explicitly passing None
x: float64 --- passing in float

@sklam you're right, passing NaN is reusing cache as expected.


C# SDK

[ ] Create a C# SDK that allows developers to easily integrate Chimoney's API capabilities into their C# applications.
[ ] Ensure compatibility with various versions of the .NET framework and runtime.
[ ] Provide support for popular C# frameworks and libraries, such as ASP.NET and Xamarin.
[ ] Implement comprehensive error handling and exception management mechanisms.
[ ] Optimize SDK performance for web applications and real-time data processing.
[ ] Develop a user-friendly interface for integrating Chimoney's global payout capabilities into C# applications

Hello, I saw this from the GDSCU group, could I be assigned to this issue?

Sure!

Hi @gearhead041
How's this coming along?

Oh it's good. I'm almost done here's the repo https://github.com/gearhead041/Chimoney-SDK-Challenge-Covenant-University

Awesome!
Looking forward to it.

hey I made a pull request #8

Great,
Let me review it 👍🏾

Hi, how's the review going

Hi @gearhead041
The PR is currently being reviewed. Thanks for the patience 👍🏾

Okay @phyleria no problem thank you


Support "setupFilesAfterEnv"

Custom matcher libraries  like jest-extended suggest to load the extension by specifying setupFilesAfterEnv in the Jest configuration. This doesn't work with jest-light-runner, it is simply ignored so I have to load jest-extended in every test file manually. Maybe it would be possible to support the setupFilesAfterEnv configuration?

Hi! Would you like to open a PR for this? We can probably:

Get that option from config in https://github.com/nicolo-ribaudo/jest-light-runner/blob/5258d9e673a580ab48e1f43b9b754dcfd663365d/src/index.js#L11-L23, and pass it to Piscina using the workerData option
At the top level of https://github.com/nicolo-ribaudo/jest-light-runner/blob/main/src/worker-runner.js, do something like const setupP = Promise.all(setupFilesAfterEnv.map(path => import(path)));
In the worker main function at https://github.com/nicolo-ribaudo/jest-light-runner/blob/5258d9e673a580ab48e1f43b9b754dcfd663365d/src/worker-runner.js#L27, before doing anything (before port.postMessage("start");), we should await setupP to make sure that the setup files are loaded before running any test.

Ignore the previous message. After that https://github.com/nicolo-ribaudo/jest-light-runner/pull/21 is merge, it can be implemented in the same way that setupFiles is implemented.

Ok, I ended up implementing this by myself in #21.


Fix unknown/unknown for docker containers

See https://github.com/eclipse/kuksa.val/issues/752

outdated manual rebase needed @erikbosch

outdated manual rebase needed @erikbosch

Rebase in UI seemed to work, waiting for builds to finish


Moving aria hook imports into first doc example

Closes https://github.com/adobe/react-spectrum/issues/2665
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:
RSP

haven't tested the docs yet, will do later

Finished testing, looks fine to me locally. Note: merge in after https://github.com/adobe/react-spectrum/pull/2634

Did you run docs-differ, something else or is manual inspect the way to make sure this works?

Merge this after parcel


Remove IAM Managed Policy rule and need for regex package

Regex package requires gcc which is causing some issues.
Issue #, if available:
Fix #504
Description of changes:

Remove rule E3507 and its dependency package regex.  The rule will have to be reworked and not require the regex package.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

docker run --rm -it -v ${PWD}:/test python:3.7.1-alpine3.8 /bin/sh
/ # cd /test
/ # pip install -e .

completes without issue


Python unit test module LookTest update

Result of the LookTest module update:
test_constructor_with_keyword (LookTest.LookTest) ... ok test_constructor_without_keyword (LookTest.LookTest) ... ok test_constructor_without_parameter (LookTest.LookTest) ... ok test_constructor_wrong_parameter_type (LookTest.LookTest) ... ok test_description (LookTest.LookTest) ... Segmentation fault: 11
The wrong type tests in setName(), setProcessSpace(), and setDescription() will trigger a segmentation fault. That seems like a really harsh rejection and perhaps it would be nice to have it throw exceptions instead of a crash? The rest of the test are fine and should pass without issues.

If it's crashing that's a bug. I'll take a look at the bindings.

Found the cause of the segfault. For certain argument types, pybind11 will convert None to nullptr, which OCIO is not happy about. The fix is to explicitly tell pybind11 when an argument can't support this implicit None conversion, as documented here:
https://pybind11.readthedocs.io/en/stable/advanced/functions.html#allow-prohibiting-none-arguments
I've tested this in for Look and BuiltinTransform (which had the same issue in my tests), and it fixes it. Following the fix, these calls raise a TypeError instead. You can fix this for Look in this PR. Just make the following change to PyLook.cpp:
Change FROM:
        .def("getName", &Look::getName)
        .def("setName", &Look::setName, "name"_a)
        .def("getProcessSpace", &Look::getProcessSpace)
        .def("setProcessSpace", &Look::setProcessSpace, "processSpace"_a)
        .def("getTransform", &Look::getTransform)
        .def("setTransform", &Look::setTransform, "transform"_a)
        .def("getInverseTransform", &Look::getInverseTransform)
        .def("setInverseTransform", &Look::setInverseTransform, "transform"_a)
        .def("getDescription", &Look::getDescription)
        .def("setDescription", &Look::setDescription, "description"_a);

TO (note the 3 added .none(false)):
        .def("getName", &Look::getName)
        .def("setName", &Look::setName, "name"_a.none(false))
        .def("getProcessSpace", &Look::getProcessSpace)
        .def("setProcessSpace", &Look::setProcessSpace, "processSpace"_a.none(false))
        .def("getTransform", &Look::getTransform)
        .def("setTransform", &Look::setTransform, "transform"_a)
        .def("getInverseTransform", &Look::getInverseTransform)
        .def("setInverseTransform", &Look::setInverseTransform, "transform"_a)
        .def("getDescription", &Look::getDescription)
        .def("setDescription", &Look::setDescription, "description"_a.none(false));

Just a quick follow up question. If I were to print(OCIO.Look()), this is the result I get:
<Look name=, processSpace=>
Should it be more like <Look name=, processSpace=, transform=None, inverseTransform=None, description=>
Would it more clear to list them all in the right order for ease of constructor readability?

The print() result echos the C++ lib's ostream operator<< result,

It looks like Look.cpp operator<< is unchanged from v1.  As is the case with many of the op<<, some members are not printed if they have empty/default values.  Important members (name and process space in this case) are printed, however, even if empty.  The names seem to be sorted based on importance rather than alphabetically.  Doesn't the order already match the python constructor?  What order do you think would be better?
I'm noticing that we added a description member to Look but we did not update the op<< to print it, so that is a minor bug to be fixed.

Per discussion today in the meeting, I can understand that the string representation of Look() object is just showing the more important bits. Just to elaborate more on what I was referring to earlier:
>>> print(OCIO.Look())
<Look name=, processSpace=>

By default, it pretty much has nothing. So now I purposely pass in a wrong type parameter so that I know exactly what Look() object parameters there are. I was only wondering if there is a more elegant way to display what parameters are available in this object otherwise (besides using print dir(lk))?
>>> lk = OCIO.Look(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__(): incompatible constructor arguments. The following argument types are supported:
    1. PyOpenColorIO.Look()
    2. PyOpenColorIO.Look(name: str = '', processSpace: str = '', transform: PyOpenColorIO.Transform = None, inverseTransform: PyOpenColorIO.Transform = None, description: str = '')

>>> lk = OCIO.Look(description="Hello world")
>>> print(lk)
<Look name=, processSpace=>

I put in a description parameter and it doesn't get displayed.
But ultimately, I get the desire to only show the more important stuff per today's meeting discussion!

@meimchu, I think you raise a good point that it would be nice for python users to easily see what are the available members to set.  But at the same time, we want to keep the printed values compact and not print seldom used members that are at their default value.
Perhaps the best solution is for the doc string to list the available members and what they do?


MTP-1502: fix for upload

use inclusively-hidden-initial to be able to make anchor link work.
use clear button to be consistent with search clear
update styles for long file names

@amundlindstol can you have a look at this? I need it for https://github.com/Mattilsynet/mattilsynet-web/pull/406


[BUG] Chart Installs - Setting global.cattle.psp.enabled=true during install is not respected in the actual chart install

Rancher Server Setup

Rancher version: v2.7.2-rc7
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE1 v1.24.10

Proxy/Cert Details: byo-valid

Information about the Cluster

Kubernetes version: v1.24.10
Cluster Type (Local/Downstream): both Local and Downstream

If downstream, what type of cluster? (Custom/Imported or specify provider for Hosted/Infrastructure Provider): AWS EC2

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom): Admin

Describe the bug
When installing the monitoring chart v102.0.0+up40.1.2 and setting the global.cattle.psp.enabled=true, the install completes but PSPs are not actually enabled. When looking for policies in the cluster there are only pod disruption budgets, and if you check the chart's yaml you'll find that the global.cattle.psp.enabled value is set to false.
To Reproduce

Create an HA on v2.7.2-rc7
Create a downstream AWS EC2 Cluster - RKE1 v1.24.10 (3 workers, 1 control plane, 1 etcd)
Begin the install of the monitoring chart (v102.0.0+up40.1.2)
Before completing the install, edit the chart's yaml and set global.cattle.psp.enabled to true
Complete the chart install
Once the chart is done installing, check the cluster's policies
Check the monitoring chart's yaml

Result
PSPs are not enabled for the monitoring chart, even though the global.cattle.psp.enabled value is set to true
Expected Result
PSPs are enabled if global.cattle.psp.enabled is set to true on a cluster with k8s v1.24.10 or older
Additional context
This is happening on both my local and a downstream cluster

Update: I originally wrote this in regards to the Monitoring chart, but I'm seeing the same thing happening with Alerting Drivers and Istio, likely other charts as well.
I discovered this while trying to test https://github.com/rancher/dashboard/issues/8062 so not sure if it's related in some way (seems unlikely, but figured I'd mention it just in case).

We tested this using the helm CLI and were unable to reproduce the issue. The chart works as expected.

The root cause of this issue is a UI/Dashboard issue being tracked here: https://github.com/rancher/dashboard/issues/8566

Seems the above UI ticket is resolved and moved to-test.

Please test this with a new rc to make sure Dashboard fix is included. @nickwsuse

can be validated in rancher v2.7.2-rc8

Fail checked in rancher v2.7.2-rc8

installed monitoring with psp.enabled: false
chart values.yaml = false
update monitoring with psp.enabled: true
chart values.yaml = false

saved value always == false; user change to true is not saved in the chart values.yaml

I can partly reproduce the issue in Rancher v2.7.2-rc8.
Cluster type: local
Kubernetes version: v1.24.4-rancher1-1
Steps used:

Create an RKE local cluster with RKE 1.4.3 and Kubernetes v1.24.4.

Check Values YAML for both rancher-monitoring-crd and rancher-monitoring; CRD shows global.cattle.psp.enabled=true whilst main chart shows global.cattle.psp.enabled=false.

I am unable, however, to reproduce the same issue from the command-line. Steps used:

Copy the values.yaml from Rancher UI.
Paste it in a file.
Install the Rancher Monitoring CRD chart v102.0.0+up40.1.2 from the tarball using the copied content as the values.yaml file:helm upgrade --install rancher-monitoring-crd \
    --namespace cattle-monitoring-system \
    https://github.com/rancher/charts/raw/dev-v2.7/assets/rancher-monitoring-crd/rancher-monitoring-crd-102.0.0%2Bup40.1.2.tgz \
    --values /tmp/monitoring-values.yaml

Check in the Rancher UI that no PSPs were installed:

I realize that my values YAML is not equal to the one generated by the Rancher UI, but I am not sure how the values YAML for the CRD chart is generated by the UI.


New Widget: PRs merged vs PRs rejected

I'm not sure I understand the difference between this and https://github.com/MeasureOSS/Measure/issues/31 ?

The aim of this widget was so that we could, in a glance, know they we're currently merging $num% of PRs. It's possible we can get that information easily accessible in the other widget.


command attributes issue

Command attributes not working properly in (some/all ?) cases. As reported by @ajain-work
command_object
<ansys.fluent.core.solver.flobject.setup_unsteady_statistics object at 0x000002910AD05730>
attrs=command_object.get_attrs(["active?"])
attrs is None
True

@ajain-work please add any details you think are needed here

from ansys.fluent.core.session import Session
session = Session("10.18.xx.xx", 0000, cleanup_on_exit=False)
root=session.solver.root
solution = getattr(root,"solution")
runCalculation = getattr(solution,"run_calculation")
cmd_object= getattr(runCalculation, "dual_time_iterate", None)
attrs=cmd_object.get_attrs(["active?"])
attrs is None
cmd_object.is_active()

Require server side fix for the command argument attributes

Looking at the proto file response structure for GetAttrs (for PyFluent) and scheme implementation of api-get-attrs (for PyConsole), the difference in the return value structure of get_attrs is expected by design. So, we can go ahead with the defensive check which @prmukherj has already committed in a PR.


Apply the schemaEnhancer from the main block even if no variations …

…are found

@tiberiuichim I have no clear opinion if this should also be backported to the withBlockSchemaEnhancer helper.


S2U-18: Search questions by keywords in question pools - master

Thank you very much Juan David @JuanDavid102 !