How to visualize attention map

Hi,
I want to visualize attention map.
I found https://github.com/jeonsworld/ViT-pytorch/blob/main/visualize_attention_map.ipynb
In this repo, I did not found vis option for attention map.
(If any, please let me know and I'd appreciate it.)
So, I decided to add this to model.py.
like this:
# In VisionTransformer
def forward(self, x):
    feat, attn_weights = self.extract_features(x)

    # classifier
    logits = self.classifier(feat[:, 0])
    return logits, attn_weights

# In Encoder
def forward(self, x):
    attn_weights = []
    out = self.pos_embedding(x)

    for layer in self.encoder_layers:
        out, weights = layer(out)
        attn_weights.append(weights)

    out = self.norm(out)
    return out, attn_weights

# In SelfAttention
def forward(self, x):
    b, n, _ = x.shape

    q = self.query(x, dims=([2], [0]))
    k = self.key(x, dims=([2], [0]))
    v = self.value(x, dims=([2], [0]))

    q = q.permute(0, 2, 1, 3)
    k = k.permute(0, 2, 1, 3)
    v = v.permute(0, 2, 1, 3)

    attn_weights = torch.matmul(q, k.transpose(-2, -1)) / self.scale
    attn_weights = F.softmax(attn_weights, dim=-1)
    out = torch.matmul(attn_weights, v)
    out = out.permute(0, 2, 1, 3)

    out = self.out(out, dims=([2, 3], [0, 1]))

    return out, attn_weights

And I got the result.

But I don't know that it is right or not.
Because the result of attention map above link is quite different for me.
(I used pretrained weights in here).

I am not sure if my results are correct.
I would be happy if I could hear the answer.
Thanks.

Looks good to me but one thing you should pay attention to is that vit-model-1 is finetuned on the cassava-leaf-disease-classification task. You may expect to visualize an image from that dataset. It is quite different from object classification and focuses on the low-level texture of the input leaf. To visualize the attention map of a dog, you can utilize pre-trained models here.
Anyway, it is a good first try. I'm still hesitating about the operation of extracting the "attention Map" since I don't want it to affect the inference process, that is, to modify the forward function. Maybe later I will check some best practices about hooks. If u r willing to, u can make a PR of your implement.

Thanks for answer.
I used your recommended pre-trained models.
Here is result for a dog.

Original attention map in repo for https://github.com/jeonsworld/ViT-pytorch/blob/main/visualize_attention_map.ipynb is below:

It seems to be something, but I'm not sure.
What do you think about this part?
If you think this part is okay,
It seems that a simple flag-vis can minimize the influence of inference.
If vis is False,
Model is working original forward function.

For people still looking for a solution, my package NoPdb allows capturing attention weights from pretty much any Transformer implementation without any modifications to the code. See a Colab notebook showing how to do this for ViT (a different implementation).
In this case, it would be something like:
with nopdb.capture_calls(SelfAttention.forward) as calls:
    logits = model(x)

calls[0].locals["attn_weights"]  # attention weights of the first layer

Hi, when I try to implement the changes by @piantic, this is the error I am getting:
Traceback (most recent call last):
File "C:\Users\Surya\Desktop\Automatic-Pain-Estimation-MQP\scripts\Visualize_Attention_Map.py", line 96, in
result_img = get_attention_map(viz_image)
File "C:\Users\Surya\Desktop\Automatic-Pain-Estimation-MQP\scripts\Visualize_Attention_Map.py", line 25, in get_attention_map
logits, att_mat = model(x.unsqueeze(0))
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\vision_transformer_pytorch\model.py", line 269, in forward
feat, attn_weights = self.extract_features(x)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\vision_transformer_pytorch\model.py", line 265, in extract_features
feat = self.transformer(emb)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\vision_transformer_pytorch\model.py", line 177, in forward
out, weights = layer(out)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\vision_transformer_pytorch\model.py", line 139, in forward
out = self.dropout(out)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\modules\module.py", line 1102, in _call_impl
return forward_call(*input, **kwargs)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\modules\dropout.py", line 58, in forward
return F.dropout(input, self.p, self.training, self.inplace)
File "C:\Users\Surya\AppData\Local\Programs\Python\Python39\lib\site-packages\torch\nn\functional.py", line 1169, in dropout
return VF.dropout(input, p, training) if inplace else _VF.dropout(input, p, training)
TypeError: dropout(): argument 'input' (position 1) must be Tensor, not tuple
Is there anything else I need to do? I feel that there might be some change that needs to be made in the EncoderBlock part of the model.py file

Hi, @Suryanshg.
This is my example notebook for visualizing attention map using this github.
https://www.kaggle.com/code/piantic/vision-transformer-vit-visualize-attention-map/notebook
And you can see visualized version of ViT in below link.
https://www.kaggle.com/datasets/piantic/visiontransformerpytorch121
I hope this helps you.
Thanks.


[Enhancement]: Add "How to play?" section

Do you want to have the enhancement of existing game ? 😀 Describe yourself..
Game enhancement:
As part of improving the user experience and guiding players through the game, we propose adding a "How to Play" section to the game interface. This section will provide clear instructions and guidance on how to play the game effectively, helping new players understand the gameplay mechanics and objectives.
Describe the solution you'd like
I will add a section card beside the introduction card describing game instructions

Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Please assign this issue to me under GSSOC .

https://github.com/ChromeGaming/Squard-line/assets/98798977/04f519ba-e5ed-4868-8204-f609b5083fe8

@Harsh-Burman Why did't you try this type

@Durgesh4993  sir, I can work on the issue mentioned above .
Assign it to me !!

I would like to work on this issue. Can you assign it to me?


Refactor the Describe API

And add tests.
The wip part of this work was that I meant to add even more new
tests, but we can postpone that, provided that the existing tests
pass reasonably.
Fixes #16

Pull Request Test Coverage Report for Build 178

363 of 449 (80.85%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 78.854%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/format_utils.js
23
24
95.83%

lib/describe.js
336
421
79.81%

Totals

Change from base Build 176:
0.4%

Covered Lines:
4333

Relevant Lines:
5349

💛  - Coveralls


SSL certificate problem: unable to get local issuer certificate

PHP Fatal error:  Uncaught Exception: SSL certificate problem: unable to get local issuer certificate in /Applications/MAMP/htdocs/OAuth2_PHP-master/OAuth_2/Client.php:186
Stack trace:
#0 /Applications/MAMP/htdocs/OAuth2_PHP-master/OAuth_2/Client.php(86): Client->executeRequest('https://oauth.p...', Array, Array, 'POST')
#1 /Applications/MAMP/htdocs/OAuth2_PHP-master/OAuth_2/OAuth2PHPExample.php(48): Client->getAccessToken('https://oauth.p...', 'Q011501220483w7...', 'https://ef0e5c5...', 'authorization_c...')
#2 {main}
thrown in /Applications/MAMP/htdocs/OAuth2_PHP-master/OAuth_2/Client.php on line 186
@hlu2 Any help here would be much appreciated.

I've added a PR #4 to resolve this issue

I am having the same issue.  The 1.0A sample app turned off peer verification to avoid the error (according to the comment), which with oAuth 1.0a seemed to cause no problem for API calls, but with OAuth2 API calls are failing (I can get the token by turning off peer verification).  Just wondering if this is not a problem coming from the new implementation of OAuth2 but existed under oAuth1 and everyone was just disabling peer verification (an unsecure solution).

Solution - https://stackoverflow.com/questions/43245262/getting-github-source-with-curl-in-php


setup design for calculator

In this project I further used react to design the calculator app:

I created a directory called components.
Inside components,  I created a new Calculator.js file.
In Calculator.js file , I created a React component that matches the design provided.

Hi @Jaymelfah
I am really sorry to have a short delay in submitting your project on your Dashboard. I was facing an issue on my Dashboard by getting some errors page when I want to any action.
But it is already solved.
Sorry again for that


AGPUSH-1894 Using join instead of sub-select

AGPUSH-1894
@matzew Can you give this one a try ?

One interesting thing I came across is that there is no proper association from PushMessageInformation to PushApplication in the model, instead it references a natural key ("api key") instead.
I guess there are reasons for that design, though it may be a good idea to reconsider it and work with a regular @ManyToOne association (referencing the PK of PushApplication) instead: You can navigate the model (with the referenced application being loaded lazily if needed), use the proper JOIN syntax in JPQL etc.
Btw. I tried to model an object association using the current natural key via property-ref (see here), but this is discouraged and seems to not work with lazy loading the reference, so I wouldn't go for that path.

@gunnarmorling thanks! 💋
Will take a 👀

Thans, merge this to master and 1.x branch! 🎉


bump version

Add limit for batch requests
Set version 4.5.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 88.112%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5863

Relevant Lines:
6654

💛  - Coveralls


bump: runtypes

Fixes #3647

Pull Request Test Coverage Report for Build 808244800

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage remained the same at 85.437%

Files with Coverage Reduction
New Missed Lines
%

libraries/botbuilder-lg/src/templateExtensions.ts
1
84.48%

Totals

Change from base Build 808164982:
0.0%

Covered Lines:
19217

Relevant Lines:
21393

💛  - Coveralls


Feat make smarter

generation JSON output from Gemini instead of the URL so we can combine the different outputs
Add jest for testing the generation of the various components of the url. Currently only works with the Cloud Function endpoint
Split the visualization and filter parameter generation into separate calls to be built and tested separately
Zero-example filter and visualization generation using the documentation
Supply the documentation to Gemini in Mardkown
build the explore URL in JS instead of relying on Gemini (which might hallucinate)

Todo:

add more test coverage for filter and visualization generation
add support for the bigquery backend in test mode by instantiating the looker SDK in jest
create better URL validation to prevent 404 on the page. The URL should always load, even if it has some mistakes.

@waziers WE almost had the same changes for the explore-assistant-extension/src/components/ExploreEmbed.tsx
I created a function that handles edge cases which cause errors for one of our clients.
Also I updated the prompt to give a better notion of the current time.
I updated the names of some of your variables to not rename variables without an explicit need.
https://github.com/datadriven-works/looker-explore-assistant/pull/13/commits/627a73046eaf6850e23eef053831967a93b4f0b0


Fix Adoption request for "sonar-gerrit" plugin typo

@MarkEWaite I can't push to https://github.com/jenkinsci/sonar-gerrit-plugin :
ERROR: Permission to jenkinsci/sonar-gerrit-plugin.git denied to reda-alaoui.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

In https://github.com/jenkins-infra/repository-permissions-updater/pull/2210, I provided my jenkinsci username reda_alaoui instead of my github username reda-alaoui. I believe this is the cause of my lack of permission :/

Looks like this was not the cause. I am going to raise the issue in the mailing list.


Audio and Microphone doesnt work

Description

I just can't get audio and microphone working, I've tried everything.
NOTE: I am using the wired method with ADBForwarder

General Troubleshooting

[x] I carefully followed the instructions in the README and successfully completed the setup wizard
[x] I read the ALVR GitHub Wiki

Environment
Hardware
Note: for Linux, an upload to the hw-probe database is preferred: hw-probe -all -upload
CPU: Intel(R) Core(TM) i3-10100F (8) @ 4,30 GHz
GPU: NVIDIA GeForce GTX 1650
GPU Driver Version: 555.58.02
Audio: PulseAudio (on PipeWire 1.2.2)
Installation
ALVR Version: 20.9.1
ALVR Settings File: ?
SteamVR Version: 2.8.3 (Latest)
Install Type:

[x] ALVR Launcher (tar.gz)
[ ] Packaged (exe, deb, rpm, etc)
[ ] Portable (zip)
[ ] Source

OS Name and Version: Arch Linux (Kernel: 6.10.5-arch1-1)

You need to set the alvr devices as default using the audio settings application of your choice. Note that you can only do this when the stream is connected, so it can be a tad bit annoying.

You need to set the alvr devices as default using the audio settings application of your choice. Note that you can only do this when the stream is connected, so it can be a tad bit annoying.

Thank you so much, I didn't think of that


Make head commands BSD compatible

Shortcut head -1 is not BSD compatible. Replace it with head -n 1.

Thanks - looks great. Can you please rebase, since I merged in some other PRs that conflict with your changes?

Sorry, head -1 is compatible with BSD. The error is caused by my aliases.


Feat: #30 jump on top of object jump again

Purpose of this PR:
when player jumps on top of an object, make it jump again
How to test:
Si Wai > JumpOnObject. increase jump force if needed
links:
Ticket
Documentation link

The bounche feels nice so defenitely keep that :) .
I do have a few points:

I think indeed .forward. is the way to go, however, currently you take the forward vector of the class Vector3 which is always (0,0,1) instead of a real forward. Instead you should probably use player.rb.transform.forward to take the real forward of the player.
I also think This is something that shoudnt be in the playerObject script (or any of the other players script) Since those scripts are responsible for everything directly related to the player.
Instead just create a new (monobehavior) script that check wheter or not a Rigit body hits it from the top, and apply this force to that rigit body.   You also dont have to check if that rigit body is acutally a player yes or no, since maybe in the future we make a ball that could be thrown on this launch pad. and then it should also work.  And enemy wont pathfind on this object anyways, so for them its also not an issue.
defenitly de-couple this from any of the player scripts. It provides more possibilities. Easier to maintain/modify/append on. And it also automatically solves the second problem Fabio already mentioned.
Also since you missed the meeting with the user stories, take in account this specific user story that the designers created XD

That being said. It may sound a lot what I just wrote, but you where defenitly on the right track, It already feels nice and satisfying. I think its just a matter of creating a new script, copy and pasting some bits of code, and done!


texlive.bin.dvisvgm: fix

Motivation for this change
Fixes: #75070
Things done
Tested:
cat > mwe.tex <<EOF
\documentclass{article}
\begin{document}
  mwe
\end{document}
EOF
nix-shell -I nixpkgs=`pwd` -p 'texlive.combined.scheme-medium' --pure --run  'latex mwe.tex && dvisvgm mwe.dvi -n -b min -o mwe.svg'
nix-shell -I nixpkgs=`pwd` -p 'texlive.combined.scheme-medium' --pure --run  'pdflatex mwe.tex && dvisvgm -P mwe.pdf -n -b min -o mwe.svg'

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @

@GrahamcOfBorg build texlive.bin.dvisvgm

This resolves the issue I encountered with #75070. Thanks for the fix!


Add tornadoweb comparisons

TornadoWeb is a Python web framework and asynchronous networking library.
Sure on Py3

Call me when you have a tornado comparison

Merged in tornado tests, closing :)


Proposal: Isomorphic pythonVariableRequester

This PR is a continuation of #10092
In this PR, rather than making the constants.node.ts work with URIs, I'm removing any reference to the root in that file and moving those references to the node file, and I'm also using these on the pythonVariableRequester to make non-node-specific.
How far from the goalpost am I in this PR?
Any feedback appreciated.
If this approach is ok, this might be my last PR before the web variable viewer.

Codecov Report

Merging #10142 (e5cf36f) into main (2f5f881) will increase coverage by 5%.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           main   #10142    +/-   ##
======================================
+ Coverage    55%      61%    +5%
======================================
  Files       203      203
  Lines      9238     9237     -1
  Branches   1490     1490
======================================
+ Hits       5099     5636   +537
+ Misses     3737     3126   -611
- Partials    402      475    +73

Impacted Files
Coverage Δ

src/platform/common/scriptConstants.ts
100% <100%> (ø)

src/platform/common/types.ts
100% <0%> (ø)

src/platform/common/configSettings.ts
80% <0%> (+<1%)
:arrow_up:

src/platform/common/utils/decorators.ts
82% <0%> (+<1%)
:arrow_up:

src/platform/common/variables/environment.node.ts
95% <0%> (+1%)
:arrow_up:

...ommon/process/environmentActivationService.node.ts
45% <0%> (+1%)
:arrow_up:

src/platform/common/cancellation.ts
55% <0%> (+1%)
:arrow_up:

src/platform/ioc/serviceManager.ts
44% <0%> (+2%)
:arrow_up:

src/platform/common/utils/misc.ts
61% <0%> (+2%)
:arrow_up:

...mon/variables/environmentVariablesProvider.node.ts
72% <0%> (+2%)
:arrow_up:

... and 40 more


Check default project and autoscan directories exist on project manager startup

Closes #45302.
A check is also added to ensure _scan_dir has a valid directory.

Thanks!

Cherry-picked for 3.2.4.


Issue with import and "_"

Hi,
I am using the last godep version and go 1.4.2 it's seems that import package using "_" is not working so well
import proto "github.com/cloudfoundry-community/firehose-to-syslog/Godeps/_workspace/src/github.com/gogo/protobuf/proto"
import math "math"

// discarding unused import gogoproto "github.com/gogo/protobuf/gogoproto/gogo.pb"

import io "io"
import fmt "fmt"
import github_com_gogo_protobuf_proto "github.com/cloudfoundry-community/firehose-to-syslog/Godeps/_workspace/src/github.com/gogo/protobuf/proto"
....
...
func (m *Envelope) MarshalTo(data []byte) (n int, err error) {
        var i int
        _ = i
        var l int
        _ = l
        if m.Origin == nil {
                return 0, github_com_gogo_protobuf_proto.NewRequiredNotSetError("origin")
        } else {
                data[i] = 0xa
                i++
                i = encodeVarintEnvelope(data, i, uint64(len(*m.Origin)))
                i += copy(data[i:], *m.Origin)
        }

When I use godep go build I got the error   undefined: proto.NewRequiredNotSetError
It seems that godep go build could not use the imported package with the "_"

Can you provide a complete program that exhibits the behavior you're describing? Please also include steps to reproduce the problem and describe the behavior you expected to see.

Hi,
Please try this repository  https://github.com/shinji62/firehose-to-syslog/ and the branch "feature/update-sonde-go" .
You can try a "godep go build"
Thanks

@kr Are you be able to reproduce with the code I give to you ?

Works fine for me.

Is your godep current (go get -u github.com/tools/godep)?

Still not working @freeformz can you update your local branch I forget to commit the dependency maybe that's why is was working on your env.
  I am using go 1.4.2 on Mac Osx 10.10.2

$ go version
go version go1.4.2 darwin/amd64
On a MacOS 10.10.4

Okay. I was able to duplicate the issue, but I think it's a problem with the github.com/cloudfoundry/sonde-go/events, which won't compile on master (the same commit that is vendored) with the same errors.

/cc https://github.com/cloudfoundry/sonde-go

Ahh os the problem appears to be with the vendored version of gogo protobufs.
This commit updates deps a bit...
https://github.com/shinji62/firehose-to-syslog/compare/feature/update-sonde-go...freeformz:feature/update-sonde-go
And the resulting errors are with the code in the repo.

So what should I do ??

@shinji62 I would try to pull in the linked patch, which updates gogo protobufs, then fix the issues in the code locally.

Hi, seems resolved when using last protobuf ..
Sorry guys and thanks for the help.

@shinji62 no worries.


CRA example

What do you think about creating an example with usage of create-react-app? I can make PR)

What do you think about creating an example with usage of create-react-app? I can make PR)

sounds good!

@mxschmitt I've got configured this repo but for now IDK how can I add this to your example. What do you think?

Looks awesome, I would maybe remove the service worker stuff. otherwise its super!

@mxschmitt I think we can close it


Wouldn't the website look better if it had white text instead of black text?

I'm personally not a huge fan of the contrast between the title / intro and the icons themselves. Shouldn't they use one cohesive color scheme?
Compare this:

With this:

I just quickly changed the colors in my browser ¯\_(ツ)_/¯
If someone else agrees, they could fork it and submit a PR idk

Made the PR myself in #461

Good idea!
@fr3fou is clearly versed in design


Bump Dependencies #8897067413

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/8897067413

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


sql_options defined per model

When multiple indices defined in search it becomes almost impossible to define sql includes. Different models has different relations usually
class City < ApplicationRecord
  has_one :overall_stat
  belongs_to :country
end

class Country < ApplicationRecord
  has_many :cities
end

This woudn't work
ThinkingSphinx.search("*", indices: %w(country_core city_core), sql: {include: [:overall_stat, :country]})

I suggest to define :sql option in the following maner (with fallback to previous variant):
ThinkingSphinx.search("*", indices: %w(country_core city_core), sql: {'City' => {include: [:overall_stat, :country]}})

This is a neat change, thank you :)

Just published v4.1.0 which includes this feature :)


Test comparable to combinatorial auction filtering

We are thinking about implementing combinatorial auctions. This would include filtering out solutions which do not provide more surplus on individual sell token-buy token pairs compared to solutions only including that token pair.
The test in this PR checks if the winning solution would have been filtered out based on this criterion.
One difference to the competition surplus test is that the test in this PR checks token pairs and not orders.
Potentially we want to check more in this test. E.g.

Who would have won the auction with the filtering rule?
Who would have won the auction with the option to declare multiple winners?
What would the benefit in surplus have been?

Todo

[ ] Fix relative test to compare price improvement and not surplus improvement.

I significantly changed the code to really run a simple combinatorial auction.
This gives slightly different information than previously: Before I logged which orders would have provided more surplus on token pairs and would have resulted in filtering the top solution. Now, I log who would have won the combinatorial auction and how much more surplus would have been provided. Both information is useful so I might add the old stuff back. I want to find a cleaner way to do that though. Since the old information is close to some other competition surplus test I went for the code as in the PR.

Tested locally and seems to be working. Will do one more pass to double-check everything but it looks good!
Added a few minor comments here and there.

Looks good! Added some minor comments, and I guess adding the test in the daemon.py is still missing.

Things look good. Let's merge and observe!
Can you create a new release btw once this is merged as there 2-3 PRs merged already so a release makes sense.


ci: add a job for checking fuel-core versions between sdk-harness and test suite

Description
We are currently out of sync in between sdk-harness and test suite, this is not ideal due to couple of reasons:

It is not nice to have our two test suites, testing with different versions of fuel-core, which means we do not test one version completely in the sense of our e2e and sdk-harness tests.
It can create problems in CI if a contract id needs to be updated, when the out-of sync versions are incompatible. (for example: one is using version 0.1.0, one is using 0.2.0)

The added job will fail and inform the dev bumping fuel-core version, to also bump it in sdk-harness or in general make them in sync.
The reason we need this as a CI job is we cannot enforce it via cargo. Since adding sdk-harness to the sway repo workspace, it creates our well known cyclic dependency between sdk and sway. So this should be checked in CI.

Was it expected to fail? https://github.com/FuelLabs/sway/actions/runs/8852823845/job/24312281868?pr=5930

It should fail as this is a current problem that we have but not like this. The script needs a little bit more attention. Currently trying to fix it locally.

Looks like sway repo bumped to fuel-core already. So this should not fail


Postgrest can be Clone

Feature request
Hi!
Is your feature request related to a problem? Please describe.
I would like to be able to pass my Postgrest around my program to be able to make requests from multiple places, notably from async tasks I spawn periodically. My approach would be:
let client = postgrest.clone();
let task = task_pool.spawn(async move {
    let result = build_query(client).execute().await;
    handle_result(result).await
});

Describe alternatives you've considered
Leave as is and require the user to either:

Create a new Postgrest at each call site. The downside to this would be that all information needed to build the client must be available as well. This breaks encapsulation as it requires users to "ship" state (access tokens, etc.) around instead of the Postgrest object, which could just do this for you.
Use Rc or similar to share the Postgrest object throughout the program. This feels redundant as Client already stores an Arc to all the persistent, non-Clone state.

Additional context
Two facts jump out at me when looking at the implementation:

Client is Clone (as are all other fields)
Constructing a Postgrest is a simple matter -- very little state is stored in the structure
Both of these hint to me that cloning should probably be a feature of the public API: if Postgrest only represents the state necessary to make a request, that state should probably be cloneable as it behaves similarly to POD.

Let me know what you think!

Thanks @jnhyatt! Builder is already Clone, I think it's reasonable to make Postgrest Clone too.

Awesome, I'll send up a PR. Thanks!


Don't panic: If a remote TUF root if corrupt, fallback on the embedded

Description

We hit this bug over the last few days: the GCS TUF root ended up in an expired and then corrupt state, which caused cosign to segfault. We should fallback on embedded targets when a TUF root fails verification (and log a warning to report maybe)

cc @dlorenc @haydentherapper @priyawadhwa
I am so sorry :/

I’m not sure we should fall back to embedded targets. This opens us up to various attacks. Say the keys associated with the embedded targets get compromised and we rotate the targets- now an attacker can target someone with a MitM attack to trick the client into trusting the local targets.
We should gracefully handle this error though.

It’s a trade off between usability and security. Since TUF forms the root of trust for this ecosystem, I’d prefer to lean towards security for these types of issues.
When I said gracefully I just meant to return an error and exit.

What's the risk of falling back? It's either valid or it's not right? And the embedded one expires, so I don't think I'm clear on the additional risk.

I'm thinking where if for some reason the embedded targets have been compromised, and an attacker tricks a client into seeing the TUF root is corrupted through MitM.

What @haydentherapper is advocating is definitely the "right" thing to do. IMO the question is: what are the odds that a target gets compromised and revoked, and the attacker has the ability to cause some clients to be unable to connect (e.g., via a DoS attack) -- it's easier than a fully general MITM. To me that feels like a scenario we want to cover so my vote is exit (with a clear explanation of what's going on) rather than fall back.
The tradeoff of course is that cosign stops working in the event of a real outage, or doesn't work in non-internet environments. We could have an "offline" mode with big warnings that it's less secure? And the nice thing too is that the TUF metadata is public so we can have mirrors for it that we fall back to.

I think the part I'm stuck on is that the embedded root is literally embedded. It can't be tampered with without modifying cosign itself, so it's defacto trusted. If you can compromise the client then nothing else matters. It's either still valid, unexpired, and trusted, or expired.

But I guess in this case we wouldn't even attempt to fetch the remote one, so maybe it's moot?

I'm thinking about where the keys that sign off on the embedded root become compromised or if the private keys associated with the targets are compromised. Under normal operations this is fine, we'd just issue a new TUF root or sign new targets, update the remote, and Cosign would pick up the update. I want to treat the embedded root as only a root of trust.

Ahhh sorry - I think I was using root and metadata interchangeably. This makes sense now I think.

I think we decided against this one?

Reopen if I'm missing something!


read(...) and write(...) no longer works with LWIP sockets

I noticed read(...) and write(...) no longer can operate on LWIP sockets. Does anyone know if is this intended or accidental? It used to work about a year ago with the following snippet working as a web server. Today write(...) sends the HTTP response to stdout (the uart) and read(...) returns nothing (probably as the part is idle).
struct sockaddr_in server_addr, client_addr;
int server_sock, client_sock;
socklen_t sin_size;
bzero(&server_addr, sizeof(struct sockaddr_in));
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = INADDR_ANY;
server_addr.sin_port = htons(80);

server_sock = socket(AF_INET, SOCK_STREAM, 0);
bind(server_sock, (struct sockaddr *)(&server_addr), sizeof(struct sockaddr));
listen(server_sock, 5);
sin_size = sizeof(client_addr);
for (;;) {
    if ((client_sock = accept(server_sock, (struct sockaddr *) &client_addr, &sin_size)) < 0) {
        printf("accept fail\n");
        continue;
    }
    printf("Client from %s:%d\n", inet_ntoa(client_addr.sin_addr), htons(client_addr.sin_port));
    int opt = 50;
    lwip_setsockopt(client_sock, SOL_SOCKET, SO_RCVTIMEO, &opt, sizeof(int));
    while ((recbytes = read(client_sock, buffer, BUF_SIZE)) > 0) {
        printf("%c", recbytes);
        buffer[recbytes] = 0;
    }
    sprintf(buffer, "HTTP/1.1 200 OK\nContent-Type: image/jpeg; charset=utf-8\nConnection: close\n\n");
    write(client_sock, buffer, strlen(buffer));
    close(client_sock);
}

I have not seen this problem with the lwip v2 branch. There SO_RCVTIMEO takes a struct timeval, and might that be a problem in your code. For some example code see the wificfg web server.

Thanks, I found this when sorting out some code rot needed for me to test your PR but I will skip digging into this and go to testing. Also, thanks for pointing out the mistake regarding SO_RCVTIMEO.

Please see #454. I will move the readdiscussion to this issue. I found a workaround by setting LWIP_POSIX_SOCKETS_IO_NAMES to 0 in a local lwipopts.h:
#include <../lwip/include/lwipopts.h> // Hackishly include EOR lwipopts.h :-/
#define LWIP_POSIX_SOCKETS_IO_NAMES 0

Still, I need to look into why lwip does not call _read_stdin_r...

Thank you. It's amazing this even worked, I had not seen this problem. Changing LWIP_POSIX_SOCKETS_IO_NAMES to 0 looks like the correct path. We need to also coming up with a strategy for allocation the descriptor index space so that the dispatching in core/newlib_syscalls.c can work.
The number of file descriptors used by lwip appears to be derived from MEMP_NUM_NETCONN so perhaps we could use that so set the block allocated to lwip. We could set the LWIP_SOCKET_OFFSET to the start of the block allocated to lwip so that the same fd could be used with read and lwip_read etc.
spiffs_fd_find_new appears to allocate from zero too. That also looks broken, e.g. what if it allocated a descriptor that matches one of stdin or stdout, then it would not work. The size of the spiffs fd allocation seems to be dynamic, so perhaps we could place that last.
Or perhaps we just allocate good blocks for each of these, the descriptor is a 32 bit integer so there is lots of space, so perhaps 4096 descriptors each for the newlib, then lwip, then spiffs.
It also looks like we need to do something with readv and writev and and open and close at least.
What do people think?

Unfortunately lwip does not build with LWIP_SOCKET_OFFSET not zero and FD_SET defined externally as we do in newlib. Obviously select is not going to work with descriptors across different drivers, but perhaps lwip sockets could do better here, so that it works with a non-zero LWIP_SOCKET_OFFSET - shall have to explore this lwip limitation first.
We probably also want to keep the FD_SET_SIZE small too, and the default for newlib is 64, so we would not want to allocate large blocks of index space for each driver as suggested above, rather pack them in. I think newlib needs only 0 to 2 for the std streams, and the default number of sockets for lwip is only 4.

Now that you mention it I recall LWIP_SOCKET_OFFSET from an earlier discussion (earlier as a year or two ago). Seems odd LWIP won't build with that feature. Is it a problem with our integration or on their master? I would be great to be able to use read/write on any FD but if not we need to make sure the behaviour is consistent. I was quite surprised the first time my image capture program sent a JPEG on the UART ;)

I am not sure what the lwip issue is with LWIP_SOCKET_OFFSET. A quick inspection, of socket.c, found only one issue. I have not actually run any tests of select() though. File a bug asking for feedback see https://savannah.nongnu.org/bugs/index.php?52190
Perhaps it was just that select() will not work across descriptors of different drivers that worried them. So it can not wait on both uart i/o and/or lwip socket i/o and/or spiffs i/o, rather just on the lwip descriptors. That might be a show stopper for some implementations, but is a limitation we can work around in practice in our limited apps.


Run apply_prep task with configured run_as

Use Case
Users should be able to run the puppet_agent::install task as root during apply_prep
Describe the Solution You Would Like
Should this be a new parameter to the puppet-library -> plugin config? A metaparameter to the task?
Proposed in #1123
plugin_hooks:
  puppet_library:
    plugin: task
    task: 'bootstrap'
    parameters:
      master: 'puppet.example.com'
      cacert_content: <cert>
      _run_as: root

I think we should make _run_as a global/meta option for the puppet_library hook. That will align better with it not being an acceptable parameter for other task plugin hooks and making it always available for task based plugins that implement a puppet_library hook.
ie:
  puppet_library:
    plugin: task
    task: 'bootstrap'
    _run_as: root
    parameters:
      master: 'puppet.example.com'
      cacert_content: <cert>


(Public swagger update) Add TeradataSource,TeradataPartitionSettings,TeradataTableDataset,TeradataTableDatasetTypeProperties

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-java

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-js

@nschonni , could you help approve this PR? The comment is resolved.

@xiaoyingLJ sorry, i'm not an MS employee, it'll need to be one of the actual repo admins

@jhendrixMSFT ,  could you help merge this PR?

@xiaoyingQQ ARM needs to approve the change before I can merge.

How long does it need for ARM approve? This PR is waiting for some days. We want this change is merged in this week to catch our ETA of this feature. Could you help me to  expedite this PR?
Great thanks
Xiaoying
From: Joel Hendrix<EMAIL_ADDRESS>Sent: Wednesday, June 19, 2019 11:33 PM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Xiaoying Zhang<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] (Public swagger update) Add TeradataSource,TeradataPartitionSettings,TeradataTableDataset,TeradataTableDatasetTypeProperties (#6346)
@xiaoyingQQhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FxiaoyingQQ&data=02|01|xiaoyz%40microsoft.com|ff457b7894314e85f2f908d6f4cb63a8|72f988bf86f141af91ab2d7cd011db47|1|0|636965551741621285&sdata=y%2FB%2F4aDiy4iQdBMHJyyoHEbboJXxYF0GmuoM1HMmLDw%3D&reserved=0 ARM needs to approve the change before I can merge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F6346%3Femail_source%3Dnotifications%26email_token%3DAF2AXXSIGXLSGMSEMWHK6T3P3JGSFA5CNFSM4HYFW25KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYCIC5A%23issuecomment-503611764&data=02|01|xiaoyz%40microsoft.com|ff457b7894314e85f2f908d6f4cb63a8|72f988bf86f141af91ab2d7cd011db47|1|0|636965551741621285&sdata=2jIpNr8x9yvTYgpSOFZNr6TDXAJg2%2B5YV2yMyiFp%2Bg8%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAF2AXXW7SZRK7ZKUWND2BQ3P3JGSFANCNFSM4HYFW25A&data=02|01|xiaoyz%40microsoft.com|ff457b7894314e85f2f908d6f4cb63a8|72f988bf86f141af91ab2d7cd011db47|1|0|636965551741631280&sdata=9qwE38aHR0Tc26znEEV465L%2B41IirXLf4272gEeUj8Q%3D&reserved=0.

@xiaoyingLJ please read the initial comment in the PR, it contains instructions for how to expedite the ARM review process.


"Requests" build error: No such file or directory

------ EXEC cp -R /home/ssm-user/aws-security-hub-automated-response-and-remediation/deployment/temp/source/solution_deploy/lambdalayer/python/requests /home/ssm-user/aws-security-hub-automated-response-and-remediation/deployment/build/playbooks/CIS/
cp: cannot stat ‘/home/ssm-user/aws-security-hub-automated-response-and-remediation/deployment/temp/source/solution_deploy/lambdalayer/python/requests’: No such file or directory

This was performed on an Amazon Linux2 EC2 instance. Same error on Ubuntu subsystem in Windows.

Look in the logs from your build for
echo "------------------------------------------------------------------------------"
echo "[Pack] Lambda Layer (used by playbooks)"
echo "------------------------------------------------------------------------------"
Find the pip install output. Are there errors? What version of python are you using? (python --version)

Ah. I have both python 2.7 and 3.6. I had to set an alias for pip to use pip3, and that worked. Thanks for the quick response!


Add note about VSCode variables not working

Currently VSCode variables do not work in Pylance. This should be documented.

Will do


create the concept of disable steps

Resolved with commit d90c246 [Fix Issue #9] - create the concept of disable steps


Revert Softmax optimizations using openmp.

squash related reverts together:
Revert "Simpler unused parameter in #if defined() switch."
This reverts commit 6b00e6bb4df23e77da73b72c67ff98ba605712f1.
Revert "Better opemmp parallel group count calculation in Softmax parallel running."
This reverts commit c530064ebe912621ac5627bc486c62356fbd1eeb.
Revert "Optimize softmax cpu by parallel using openmp."
This reverts commit e7bdfa00db1d0e9909f1d0d5e159173e3fbd608f.

What's the reason for reverting?

      What's the reason for reverting?

The perf gain is too small to the transformer model currently after it use dynamic input sequence length. And we do  not have enough real data to do the perf tuning based on this change.


[ZEPPELIN-6072] Unify tooltips across action bar buttons, and add tooltips to paragraph controller

What is this PR for?
I noticed that only some buttons in the first group of the action bar (highlighted in the red box in the image below) had tooltips, while others did not. To improve consistency and enhance user experience, I ensured that all buttons in the first group of the action bar display tooltips on hover.

I also considered adding tooltips to the other groups of the action bar (outside the red box), but due to the complexity of implementing this with the ng-zorro UI library, more time and investigation are needed. I aim to address this in a future update.
In addition, the paragraph controller currently lacks tooltips on its icons, which may be confusing for new users unfamiliar with Zeppelin (like myself). Without tooltips, it's unclear what each button does, leading to potential usability issues. I added tooltips to all icons in the paragraph controller to improve clarity and guide users of the functionality of each button.

These changes aim to enhance the overall usability of the interface, making it more intuitive and consistent for all users.
Before
Some buttons show no tooltips.

After
Missing tooltips are now displayed.

What type of PR is it?
Improvement
Todos

[x] - Add tooltips to action bar
[x] - Add tooltips to paragraph controller

What is the Jira issue?
ZEPPELIN-6072
How should this be tested?

Build and test - check if tooltips are visible

Questions:

Does the license files need to update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Thanks, merged to master/0.12


Issue found on page 'Transaction Management'

Please describe the problem you encountered in the DuckDB documentation and include the "Page URL" link shown below.
Note: only create an issue if you wish to report a problem with the DuckDB documentation. For questions about DuckDB or the use of certain DuckDB features, use GitHub Discussions, Stack Overflow, or Discord.

Page URL: https://duckdb.org/docs/sql/statements/transactions.html
In the example, the SQL statement is:
"INSERT INTO person VALUES ('Bruce', 39);".
In the explanation, the text mentions "Bob" instead of "Bruce" used in the example statement:
"... (deleting “Ada” and inserting “Bob”) ..."

@massaoalfredo thanks, indeed this was off. I'm submitting a fix.


Is/77 accessh20 utility views

Different Views
Important Changes

Added two seperate views for accessh20 and utility
removed "applicant view" and "info submit" from the home page
edited applicant table and applicant nav bar to be different between views
different profile views
fixed some linking issues on profile page

Related Github Issues

#77

Still need to complete in future sprints:

differentiate between views for info submission (ability to edit or not)

Closes #75


Bump matchcode-toolkit to 2.0.0

This PR updates matchcode-toolkit to 2.0.0 to address issues from https://github.com/nexB/purldb/issues/263

Added in https://github.com/nexB/scancode.io/pull/1031


Add tests in e2e pipeline for testing charts with containerd runtime cluster

COMPONENT

Litmus e2e

LITMUS VERSION

1.7.0

DETAILS

This issue is for adding experiment tests for contained runtime platform. We have all the tests running in a cluster having docker runtime in the e2e pipeline. We need to create another cluster having containerd runtime so that we can test all the supported experiments in containerd as well.
The currently supported experiments for containerd runtime is:

pod-memory-hog
pod-cpu-hog
pod-delete
container-kill

All other experiments are expected to be added in subsequent releases.

The chaos experiments are being executed on KIND as part of per-commit e2e runs in the litmus-go experiment repository


Fact 'jenkins_plugins' can exceed value length limit: 4096

Affected Puppet, Ruby, OS and module versions/distributions

Puppet: 7.17.0
Ruby: /opt/puppetlabs/puppet/bin/ruby --version : ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [aarch64-linux]
Distribution: Debian GNU/Linux 11 (bullseye)

What are you seeing
Info: Loading facts
Warning: Fact value 'JDK_Parameter_Plugin .... workflow-step-api 622.vb_8e7c15b_c95a_, workflow-support 804.vba10a18a1476, ws-cleanup 0.40' with the value length: '4944' exceeds the value length limit: 4096

This is probably because they increased version numbers to longer strings. We should really convert it to a structured fact.

Good news! I can now reproduce this too.


Support the serialization of enums

Enums should be serialized as their numerical equivalent

A lot of people prefer to serialize the name of the enum as a string.  Either option should be supported, IMHO.


Capabilities of the underlying loop

The Uv extension exposes functions for watching on signals and to execute operations on files.
Other loops may expose signal handling through pcntl.
a) I assume signal handlers will just throw an exception if you try to register one via onSignal() while unsupported? … Do we want to expose a way to actually access that information on whether it is supported without trying and catching?
b) In general loops are handled by one underlying loop resource (uv, ev) - do we want to be able to expose what type of loop exactly and the underlying loop actually is?
Regarding b), in Amp, it is simple, we have three implementations and can just check for the actual instance and have one function getLoop() (not in the interface) on the UvReactor. This can be used by our amphp/file library to actually operate on it.
But if we are going to have multiple implementations, we need to have a way to access that data (loop type, loop resource if existing).
I'm not really sure how to shape that though? Maybe a function getLoop() returning an array [$extension, $loop] … so that it would be ["uv", $the_uv_loop] or ["native", null]?
I'm really open to any better suggestion here!

I don't think we will allow an implementation to not support onSignal(). The C select() call is woken by signals and alarms so I think it's trivial to support signals even using a stream select loop in PHP. I know Icicle does and I've had to write similar code for PHPFastCGI.
B) really comes back to the discussion in the other thread. Async interop won't be involved in actually implementing the event loop, so the most we can do here is provide an API to retrieve the active driver.

a) if you don't have pcntl installed and not an Uv-driver you are actually pretty much out of luck ?!
b) I mean, if we provide an interoperable way for event loops, we also need an interoperable way to access its underlyings. Else we'll end up with Amp/file just being compatible with the Amp implementation of the Uv Driver, but nothing else. It'd then have to fall back to native (blocking) behavior, which definitiely isn't what you want if you have a React Uv driver for example.

Is the filesystem the only thing that ever needs these? In that case, we might just add something to the interface. Otherwise, this won't ever work in an interoperable way.

I'm assuming pcntl is only not installed on Windows machines, as Windows doesn't have unix signal handling capabilities?

A quick suggestions:
EventLoop::supports(EventLoop::SIGNAL_HANDLING);

Then we could also have
class FeatureNotSupportedException extends \RuntimeException
{
    public function getFeature(); // ...
}

Suggestion: UnsupportedFeatureException
pcntl can also be missing, because you're using a disable-all build of PHP, like I usually do.

UnsupportedFeatureException is fine … in case it is actually tried.
But IMHO we should also have a way which allows checking capabilities directly (e.g. at top-level to immediately abort if e.g. signal watching isn't available) instead of throwing.

Oops, I actually missed this thread...
@AndrewCarterUK That is actually a spot-on idea; I really like it! I'd have supports() just return a boolean so that features can be tested ahead of time, like @bwoebi mentioned. Of course, it would be a little strange of an API if there is only one optional feature defined. What else would there be other than signal handling that could be optional?

Polling for priority reads.

I makes sense to have a method for checking if signal handling is enabled on the loop, but beyond that I think code requiring a particular feature would have to just use EventLoop::get() (or similar) to get the loop instance and see if it implements a particular interface.

I wouldn't check for a concrete, capabilities may depend on more than just the reactor, but possibly also on the OS or on an additional extension.
Using a method for that in any case makes things simpler.

Sure, using a method makes sense, but the only use-case I can see is signal handling. Defining a constant like EventLoop::FILE_HANDLING doesn't make a lot of sense if EventLoop doesn't include file handling methods.

As @kelunik mentioned, priority reads.
Obviously doesn't make sense for file reads, if we don't specify an API here.

So you're suggesting if we want to support out-of-band watchers, such as an onException watcher, support for it would be indicated through a call such as EventLoop::supports(EventLoop::OUT_OF_BAND)?

basically that.

To implement that, we could add EventLoopDriver::getSupportedFeatures() to simplify and centralize feature processing as well. supports could just compare the given feature against all the ones the driver supports.

I like the idea of EventLoopDriver::getSupportedFeatures() and supports. But are these going to be string constants implementers can define themselves or are we going to define them in the specs and release new specs for when there is the need for new one (the latter sounds aweful tbh).

I was thinking integer constants, but they could also be strings. Something like SIGNAL_HANDLING and OUT_OF_BAND would be defined as part of the spec since it is tied to the driver interface.

All of these constants have to be tied to the spec, otherwise they don't make sense, if every vendor introduces their own constants.

I was thinking integer constants

With integer constants it would be possible to store all the supported features in one integer and use bitwise operations to store and retrieve supported features.

All of these constants have to be tied to the spec, otherwise they don't make sense, if every vendor introduces their own constants.

Let me rephrase that: How do we handle new constants after the spec is finalized? Release a new minor version of the spec. The thing I'de hate to see is a new feature popping up and we have no way of adding it to the spec later on.

Why do we need a new major version? A new minor one is fine.

Why do we need a new major version? A new minor one is fine.

Minor is exactly what I said :wink:

Oops, it's late. Yes, that's the way I'd go.

Anyone want to submit a PR for this?
I'm away at a conference this weekend but if not I'll do it when I head back - seems like there is good agreement here.

@AndrewCarterUK What for? For UnsupportedFeatureException and the optional feature support API?
I think we still don't have a solution for the main issue: Accessing the underlying event loop resource e.g. for file handling.

@kelunik - The UnsupportedFeatureException() and the supports()
I'm not sure I like getSupportFeatures(). If that was the name, I feel you'd need to list everything that was supported (delays, alarms, normal streams, etc...).
I prefer the ability to ask if specific features are there and get a response (supports()) - and maybe allow it to accept a variable number of arguments.
The obvious feature is signal handling and I don't see any reason not to add out of bound data too (but that might be best in a later PR as it requries a new method onOutOfBound() or similar).

I'm not sure we need to be specify the loop driver type (uv, stream select, etc...). What we're creating here is an abstraction layer.
If anyone does want to do driver specific things they can use the get() method to get the underlying driver and test with instanceof (which they would need to do anyway before manipulating).

The obvious feature is signal handling and I don't see any reason not to add out of bound data too (but that might be best in a later PR as it requries a new method onOutOfBound() or similar).

We need a solution here anyway, because we can't simply add methods later for other optional features.

I'm not sure I like getSupportFeatures(). If that was the name, I feel you'd need to list everything that was supported (delays, alarms, normal streams, etc...).

How about getOptionalFeatures()? That way only the accessor needs to implement supports to figure it out, the driver could just return an array.

If anyone does want to do driver specific things they can use the get() method to get the underlying driver and test with instanceof (which they would need to do anyway before manipulating).

The get() method? I don't see one. But we probably don't need to standardize it, because instanceof will be called first anyway.

Agreed.

Sounds good.

The get() method is here: https://github.com/async-interop/event-loop/pull/17/files#diff-cdc07fcba9000e5df0e709e2ff024127R40

PR #32 is a thing now. I removed getOptionalFeatures and went with supports instead, otherwise we have to determine support for all features instead of maybe just one.

PR #32 has the problem that it doesn't solve files.
We really need also a capability of exposing the underlying loop.
I don't like it too much, but e.g. you have two file components which each are coupled to the respective UvLoop implementation. Now, you cannot use the two independent libraries at the same time (in a non-blocking way).
Also, we need to be able to know what type of Loop it is (libuv, libevent, native)?

We really need also a capability of exposing the underlying loop.

We have Loop::get. The driver can then have a method to get the internal loop without it being in the interface. But that makes file system access probably implementation dependent again, right.
Maybe introduce an interface for each driver? UvLoopDriver, NativeDriver, ...? If a new extension appears, we can update the spec and add another driver type.

Exactly that's the issue …
The idea of using different interfaces for the different drivers is interesting and probably worth pursuing.
I'd be interested on feedback from the others here.

But at that point one may wonder again if it should really be interfaces or just directly implementations. There's not much which changes between the loop implementations of a specific type, except that the one implementation may be more performant than the others.

@bwoebi You're right, but you canstill implement a new driver. Just implement no interface at all or the NativeDriver (maybe we should just kill that one), other packages such as the ones for filesystem access will just fall back to the native one. Once the implementation is fine, it can be added to the spec.

I feel, given we should be validating against LoopDriver for factories, that the LoopDriver should be the lowest defined interface. Folks can get access to the drivers through Loop::get() without us having to define three (?) seperate interfaces for three (?) separate implementations.

@assertchris the point is that we cannot check against a specific driver … but code using e.g. amphp/file shall be still able to run [in a non-blocking way] with e.g. an Icicle uv driver. And thus we need some interoperability there.

Oh! I understand. It's not that the interop group will suggest multiple Uv drivers but that Icicle/AMPHP/React etc could. It's not that easy to see from https://github.com/async-interop/event-loop/pull/37 since it doesn't describe any Uv-specific methods...

Yeah, I don't really like the approach with the interfaces … but I don't know of any better approach :-/

It looks weird, was thinking about a sort of enum holding different options, as for example: https://github.com/WyriHaximus/reactphp-child-process-pool/blob/master/src/Options.php But not sure if it would work here

What about an interface for FileLoopDriver that defines the Filesystem operations Uv can do without tying it to Uv?

That could work, AFAIK Uv is the only one doing it, but a new one might emerge so it is future proof

@assertchris Files are currently the only thing I think, but there might be other primitives later? Don't know.

Yeah, I don't really like the approach with the interfaces … but I don't know of any better approach :-/

What's the issue with it?

If we need to create the interfaces to contain certain driver-specific behaviours, why don't we instead create interfaces for those behaviours?

Because those things are tied to the underlying loop, but they don't need to be implemented by the loop ifself. It's perfectly fine to have a loop driver separate from the filesystem handling.
@WyriHaximus Eio is another possible driver, but that's another thing, because that one works with threads and isn't tied to any loop.

@kelunik I'm aware of EIO, spent a significant amount of time working with it, didn't mention it because it's not an event loop :). It has one but it doesn't expose it so we can't tie into it

Let's keep the event loop interface simple and not worry about interoperability for signals, file handling, etc. and eliminate the supports() method.
To allow interoperability of signal and file handling, we can have separate standards extending the event loop interface that add methods for signal handling, file handling, or anything else that a particular loop implementation may be capable of doing.
// Just examples, names aren't meant to be suggestions.

class SignalLoop
{
    public static function onSignal($signo, callable $callback, $data = null);
    {
        $loop = Loop::get();

        if ($loop instanceof SignalLoopDriver) {
            throw new UnsupportedFeatureException();
        }

        return $loop->onSignal($signo, $callback, $data);
    }
}

interface SignalLoopDriver extends LoopDriver
{
    public function onSignal($signo, callable $callback, $data = null);
}

@trowski  I think that's a bad idea. Keeping it simple is for me just having one interface.

Then what does Loop::supports(Loop::FEATURE_FILE_HANDLING) mean without file handling methods on Loop and LoopDriver? Without defining those, checking for file handling support is meaningless. To keep this interface from getting bloated, I would prefer to move support of other features to a different interface.

Loop::supports(Loop::FEATURE_FILE_HANDLING)

It won't exist, because it doesn't make sense.
It's also the reason why I suggested using driver interfaces instead.

Hypothetically, suppose another extension using libuv as the underlying loop is released, we'd have to add a NewUvLoop interface to allow interoperability between packages implementing LoopDriver using this underlying loop extension. If instead an interface such as FileLoopDriver was available based on supported features, implementers of LoopDriver written using this new underlying loop extension could also implement FileLoopDriver and immediately have the same interoperability benefits of any of the other loop implementations.

@trowski The issue is that this makes the driver then not only responsible for its basic loop functionality, but it has to implement the complete file handling instead.

Regardless of that, we can't drop supports, as interfaces are compile time, but support might be runtime dependent, such as OS or a missing pcntl extension.

@kelunik True, an object implementing LoopDriver may also implement complete file handling methods to implement a FileLoopDriver interface, but only because those methods are tied to the underlying loop extension. File operations will be dependent on the loop, even if the underlying loop was wrapped in a different object. Neither situation is optimal, but if an operation is dependent on the loop, personally I'd rather see it as a method of the loop.
File handling packages will need to provide several drivers (for example, to support EIO if available). One of these drivers could check for a LoopDriver implementing FileLoopDriver and defer file operations to the event loop.

@trowski The issue is, that we have to standardize the file system access API then, something which isn't required for interoperability.
But I agree, there are issues with the interfaces, because there might be a UV v2.

Regarding driver interfaces, it strikes me as a step in the wrong direction (towards coupling to implementations and away from abstractions).
Unless these interfaces are going to offer different functionality (and even then we now have supports()) being able to test them with an instanceof doesn't actually offer anything. Just because a driver uses libuv doesn't mean it supports the operation you were intending. You still need to test that it's a specific libuv driver to perform any off-spec operations.

@AndrewCarterUK Our goal isn't really abstraction, but rather interoperability.

libuv doesn't mean it supports the operation you were intending. You still need to test that it's a specific libuv driver to perform any off-spec operations.

If you have the underlying loop resource, you don't need support in the driver. That's how Amp does it currently.

@kelunik Abstraction is integral to interpretability. I don't understand what you're trying to say.

@assertchris Something like those driver interfaces is still interoperable, even if it doesn't abstract anything. But yes, we would have to extend the spec every time there's a new driver type, which is bad.

@kelunik - I can see a bit more what you're getting at here. I'm torn because these methods open an incentive for people to create code that isn't interoperable, but by not having them we potentially close the door on functionality.
I'll have a look through again this evening and see if I can source some external opinions.

Put me on record as strongly opposed to supports() ... Why have an interface contract if you then have to check which parts of the abstraction actually apply? That defeats the whole purpose.

@rdlowrey - Understand totally, but the other options appear to be:

Remove onSignal
Don't allow the standard to be used in environments that don't support signal handling

@rdlowrey Because signal handling isn't available on all systems. That way you can check for support before it throws and maybe warn the user or do something else.

My early amp implementations had an interface EventLoop (or equivalent) with a interface SignalHandlingEventLoop extends EventLoop that implementations could implement if they supported the onSignal() event.
I subsequently merged the two into a single loop and if a user tried to use onSignal() in the one environment where signals were unavailable I preferred to throw a YourOperatingSystemIsTerribleException ... I really feel like that's the only sane option.

@rdlowrey: Of course, it does throw if that feature is not available. supports just ensures you don't have to create a dummy handler on application startup to check for availability. That way you can immediately error out.

@rdlowrey In addition to @rdlowrey there may be signal handlers which just do some non-essential (or just more user-friendly) cleanup e.g. in SIGINT … these are optional and shall just not be set then. That's why we need some way to determine availability (apart from exception catching).

After talking to @trowski I feel like #48 is absolutely the cleanest and ideal way to go in this problem for getting the underlying resource/object.

@bwoebi Agreed. This is probably the simplest and best solution.

After reviewing this thread and re-thinking the problem, I've changed my stance. I agree with what @rdlowrey said earlier as the only sane and clean option, and I'd like to share my reasoning.
Other than implementing event loops themselves, when have you ever "kind of" needed to handle process signals? A supports() method would let you check to see if it is supported ahead of time, like so:
if (Loop::supports(Loop::SignalsFeature)) {
    Loop::onSignal(SIGUSR1, function () {
        /* ... */
    });
} else {
    // Um, now what?
}

What are you going to do if signals aren't supported? To what end are we trying to avoid an exception? If you need to use signals and they aren't supported, there's nothing more you can do to get signal handling. Signal handling not being supported then is clearly an error in your library / app, when clearly you need it.
I'm not trying to say that we shouldn't allow graceful failure, we can still do that with exceptions:
try {
    Loop::onSignal(SIG_FOO, function () {
        /* ... */
    });
} catch (LoopFeatureNotSupportedException $e) {
    // Fail gracefully here
}

As you can see, this has the same if/else structure, without dealing with supports(), extra interfaces, or anything complex. If a driver does not support a feature, it should throw an exception.

I'm not sure on the issue. Pretty much indifferent here.
There's the advantage of supports() to cleanly indicate support (Also for testing at startup die("Need signal handling!"); without actually setting a signal handler … but well, you can also set and cancel immediately).
The disadvantages are, as you say, that we always need manual error handling here. And an extra function.

Other than implementing event loops themselves, when have you ever "kind of" needed to handle process signals?

Uhm, never in event loop themselfs. Always if you want to ensure a clean shutdown, e.g. in Aerys.


Fix version number in wxglade script

The wxglade shell script does not find the wxGlade installation otherwise.

Thanks. I don't understand why, though...


Implement Struve Functions

The Struve functions are special functions that are useful in physics. There is no arbitrary precision implementation for these in Julia. This PR implements them in in this package.
The Struve functions are not directly implemented in the Arb C Library and can be expressed in terms of the 1F2 hypergeometric function. The README for this package claims to have a hypgeom1f2 function, but it instead has an implementation of the 2F1 hypergeometric function called hypergeometric_2F1. This PR adds a wrapper for the 1F2 hypergeometric function and corrects the mistake in the README.
TODO:

[ ] The 1F2 wrapper currently does not appear to work. There is a segmentation fault when calling the C library. I suspect this is because the types required for the acb_hypgeom_pfq function are slightly different from the rest of the wrapped hypergeometric functions (acb_poly_t instead of acb_t and acb_srcptr  instead of const acb_t). Any suggestions?

@mdavezac

this is helpful!  I am looking forward to adding the capability to the main version. Can you suggest a few good tests for the hypergeometric functions and the struve function?
meanwhile, I have created the branch #struve and am merging your PR there so the functionality is available for you immediately.
About the second question .. that happened quite a while ago, I need to review older commits to recollect and respond.

Thank you! I am unsure of tests, they don't have many identities or analytic solutions I know of. There is a Struve function implementation in Julia that has tests that could be used as inspiration.
For future changes, would you like me to make PRs to the struve branch?
Let me know if you find anything about the types.

do use the struve branch

I am constructing the tests (no worries)

"look at all that snow" here in New York City

regarding the Hypergeometric functions known in the literature as:    ₀F₁    ₁F₁     ₂F₁
from arb_hypgeom.h there is direct support for ArbReal

arb_hypgeom_0f1
arb_hypgeom_1f1
arb_hypgeom_2f1

from acb_hypgeom.h there is direct support for ArbComplex

acb_hypgeom_0f1
acb_hypgeom_1f1
acb_hypgeom_2f1

to support ArbFloat, we use the support for ArbReal
function 0f1(a::ArbFloat{P}, b::ArbFloat{P}, z::ArbFloat{P}) where {P}
  ar = ArbReal{P}(a)
  br = ArbReal{P}(b)
  zr = ArbReal{P}{z}
  res = 0f1(ar, br, zr)
  result = ArbFloat{P}(midpoint(res))
  return result
end

that is how it should work

I will see if I get a segfault and let you know how to go forward if that occur

I switched the numbers when writing the function calls, misnaming _1F2  as _2F1.

There is already support for the Confluent Hypergeometric Functions (₀F₁ ₁F₁ ₂F₁) in this package, but the Struve functions requires the generalized hypergeometric function 1F2 (which is not the 2F1 confluent function already implemented). This function is not specifically available in the Arb library, so it is required we use the general functions (acb_hypgeom_pfq and arb_hypgeom_pfq).

I did not know that.

Calling an Arb library function that expects or returns a datatype not mirrored (fully recreated and managed) within ArbNumerics is problematic.  There was a good deal of work required to support the Fourier  transform for just that reason.

Sorry that wasn't clear in my original description. A bit more detail:
The segmentation fault is happening when I call the acb_hypgeom_pfq or arb_hypgeom_pfq functions. I believe it might be because they have slightly different types for the inputs than the pre-existing confluent functions I based my wrapper off:
void acb_hypgeom_pfq(acb_t res, acb_srcptr a, slong p, acb_srcptr b, slong q, const acb_t z, int regularized, slong prec);
vs
void acb_hypgeom_0f1(acb_t res, const acb_t a, const acb_t z, int regularized, slong prec);
Note the use of acb_srcptr instead of const acb_t

Calling an Arb library function that expects or returns a datatype not mirrored (fully recreated and managed) within ArbNumerics is problematic. There was a good deal of work required to support the Fourier transform for just that reason.

Thank you, I think this gets to what the issue is. Because I am unfamiliar with what has been mirrored, I was wondering if there already existed a wrapper or mapping for acb_srcptr

from the library "type acb_srcptr Alias for const acb_struct *, used for vectors of numbers when passed as constant input to functions"
So, try
"""
regular_hypergeometric_1F2(a, b, z)
regularized generalized hypergeometric function ``₁F₂ / gamma(a)``
"""
function regular_hypergeometric_1F2(a::ArbComplex{P}, b::ArbComplex{P}, z::ArbComplex{P}) where {P}
    result = ArbComplex{P}()
    srcptr = Ref(b)
    regularized = Cint(1)
    p = Clong(1)
    q = Clong(2)
    ccall(@libarb(acb_hypgeom_pfq), Cvoid, (Ref{ArbComplex}, Ref{ArbComplex}, Clong, Ref{Ref{ArbComplex}}, Clong, Ref{ArbComplex}, Cint, Clong),
         result, a, p, srcptr, q, z, regularized, P)
    return result
end

I'm getting this error.
ERROR: MethodError: Cannot `convert` an object of type
  Base.RefValue{ArbComplex{128}} to an object of type
  ArbComplex
Closest candidates are:
  convert(::Type{ArbComplex}, ::ArbComplex{P}) where P at <path-to-ArbNumerics.jl>/src/libarb/promote.jl:100
  convert(::Type{ArbComplex}, ::ArbFloat{P}) where P at <path-to-ArbNumerics.jl>/src/libarb/promote.jl:105
  convert(::Type{T}, ::T) where T<:Number at number.jl:6

last guess for the moment
Take out the doubled Ref. If this does not work, I will enlist C-interfacing expertise.
"""
regular_hypergeometric_1F2(a, b, z)
regularized generalized hypergeometric function ``₁F₂ / gamma(a)``
"""
function regular_hypergeometric_1F2(a::ArbComplex{P}, b::ArbComplex{P}, z::ArbComplex{P}) where {P}
    result = ArbComplex{P}()
    srcptr = Ref(b)
    regularized = Cint(1)
    p = Clong(1)
    q = Clong(2)
    ccall(@libarb(acb_hypgeom_pfq), Cvoid, (Ref{ArbComplex}, Ref{ArbComplex}, Clong, Ref{ArbComplex}, Clong, Ref{ArbComplex}, Cint, Clong),
         result, a, p, srcptr, q, z, regularized, P)
    return result
end

The same error occurs, I believe it happens on the inner Ref. Let me know if you can't find someone with appropriate expertise.
I can reproduce the error with:
convert(ArbComplex, Ref(ArbComplex(1)))

I noticed I didn't include the original stacktrace:
Stacktrace:
 [1] Base.RefValue{ArbComplex}(::Base.RefValue{ArbComplex{128}}) at ./refvalue.jl:8
 [2] convert(::Type{Ref{ArbComplex}}, ::Base.RefValue{ArbComplex{128}}) at ./refpointer.jl:63
 [3] cconvert(::Type{T} where T, ::Base.RefValue{ArbComplex{128}}) at ./essentials.jl:388
 [4] hypergeometric_1F2(::ArbComplex{128}, ::ArbComplex{128}, ::ArbComplex{128}) at <path-to-ArbNumerics.jl>/src/float/hypergeometric.jl:130

ok -- shucks -- will advise

To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort.  I cannot get to it for a while, though.

To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a while, though.

Okay, thank you. I suspect this is for implementing wrappers for the extra types required for this function?

To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a while, though.

Okay, thank you. I suspect this is for implementing wrappers for the extra types required for this function?

yes and then some (types and related support)
On Tue, Mar 16, 2021 at 7:54 AM AdrianDAlessandro @.***>
wrote:

To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a
while, though.
Okay, thank you. I suspect this is for implementing wrappers for the extra
types required for this function?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/JeffreySarnoff/ArbNumerics.jl/pull/49#issuecomment-800194047,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAM2VRTJHKQ6ECADSOSKJHTTD5BF3ANCNFSM4XYXGB7A
.

bi-directional conversions are also needed

To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a while, though.

@JeffreySarnoff Have you found any time to look into this?

Yes. .. enough to understand it requires about a month of my time ..
:(
Jeffrey Sarnoff

On Jun 3, 2021, at 10:15 AM, AdrianDAlessandro @.***> wrote:
To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a while, though.
@JeffreySarnoff Have you found any time to look into this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

The underlying difficulty is that the Arb library does not correctly
compute the function you need -- and at present has no plans to correct
that.
I understand that you have a way around that using the Arb library poly
support.  That is tangled (much of Arb was not designed for adaptation
to other languages originally). I did not mean to be dismissive -- I'll see
if cobbling something works well enough for you ..
please tell me each arb library routine you would need to call and what
types they require -- that will make it simpler to really quantify.
On Thu, Jun 3, 2021 at 12:07 PM Jeffrey Sarnoff @.***>
wrote:

Yes. .. enough to understand it requires about a month of my time ..
:(
Jeffrey Sarnoff
On Jun 3, 2021, at 10:15 AM, AdrianDAlessandro @.***>
wrote:
To make this work requires implementing part of the arb|acb_poly interface.
That is doable, and may be worth the effort. I cannot get to it for a
while, though.
@JeffreySarnoff https://github.com/JeffreySarnoff Have you found any
time to look into this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JeffreySarnoff/ArbNumerics.jl/pull/49#issuecomment-853948253,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAM2VRTI3I4EFERYZWDAVKDTQ6MBNANCNFSM4XYXGB7A
.

Okay thank you, I will follow up later on if this feature is still required.


Support for other code Format

I feel following is the more used standard code format for methods -
    + (void)someMessage:(NSString *)subdomain {
    }

Is it possible to select different coding style ?

currently, you can modify the source code and remove the semicolumn and new line requirement

Please provide me where i need to edit rules source code to check this type of coding style

(void)someMessage:(NSString *)subdomain {
}

https://github.com/Cue/ocstyle/pull/4
you can refer the this PR.


Can not use  as leader

I am using a brand-new install of spf13-vim. My ~/.vimrc.before.local contains the following line:
let g:spf13_leader='\<space>'

However, <space> does not trigger the leader. It moves the cursor one char forward. At the same time, the old leader key (,) does not work anymore. I can confirm that using the setting
let g:spf13_leader='\'

does work as expected: \ becomes the leader key. It seems that only the <space> key can not be set as leader key.
I can also confirm that :let mapleader prints
mapleader     \<space>

I am on Mac OSX Yosemite using vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 30 2015 13:30:48)
MacOS X (unix) version
Included patches: 1-865
Compiled by Homebrew
Huge version without GUI.  Features included (+) or not (-):
+acl             +farsi           +mouse_netterm   +syntax
+arabic          +file_in_path    +mouse_sgr       +tag_binary
+autocmd         +find_in_path    -mouse_sysmouse  +tag_old_static
-balloon_eval    +float           +mouse_urxvt     -tag_any_white
-browse          +folding         +mouse_xterm     -tcl
++builtin_terms  -footer          +multi_byte      +terminfo
+byte_offset     +fork()          +multi_lang      +termresponse
+cindent         -gettext         -mzscheme        +textobjects
-clientserver    -hangul_input    +netbeans_intg   +title
+clipboard       +iconv           +path_extra      -toolbar
+cmdline_compl   +insert_expand   +perl            +user_commands
+cmdline_hist    +jumplist        +persistent_undo +vertsplit
+cmdline_info    +keymap          +postscript      +virtualedit
+comments        +langmap         +printer         +visual
+conceal         +libcall         +profile         +visualextra
+cryptv          +linebreak       +python          +viminfo
+cscope          +lispindent      -python3         +vreplace
+cursorbind      +listcmds        +quickfix        +wildignore
+cursorshape     +localmap        +reltime         +wildmenu
+dialog_con      -lua             +rightleft       +windows
+diff            +menu            +ruby            +writebackup
+digraphs        +mksession       +scrollbind      -X11
-dnd             +modify_fname    +signs           -xfontset
-ebcdic          +mouse           +smartindent     -xim
+emacs_tags      -mouseshape      -sniff           -xsmp
+eval            +mouse_dec       +startuptime     -xterm_clipboard
+ex_extra        -mouse_gpm       +statusline      -xterm_save
+extra_search    -mouse_jsbterm   -sun_workshop    -xpm
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: /usr/bin/clang -c -I. -Iproto -DHAVE_CONFIG_H   -F/usr/local/Frameworks -DMACOS_X_UNIX  -Os -w -pipe -march=native -mmacosx-version-min=10.10 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: /usr/bin/clang   -L. -L/usr/local/lib -L/usr/local/lib -F/usr/local/Frameworks -Wl,-headerpad_max_install_names -o vim        -lm  -lncurses -liconv -framework Cocoa   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl -F/usr/local/Cellar/python/2.7.10_2/Frameworks -framework Python   -lruby.2.0.0 -lobjc

I can confirm the same behaviour on MacVim Custom Version 7.4 (77). Both vim and MacVim are installed using brew.

I met the same problem, I tried to modify the .vimrc.before.local and the .vimrc.local, but none of them works.

I put this in my .vimrc.before.local and it worked. Try ' ' instead of \<space>
let g:spf13_leader=' '

@davidhan527 , thanks.


Support for icons & labels in Progress Indicator

The current progress indicator component does not allow to customize the icon in each step. The user needs to hover the indicator to understand what the step is about.

Proposed Implementation
In thesteps property of the component, I propose we should add an optional support for icon and text, which will allow the progress indicator to be displayed like the following -

The step property should be taking 2 extra parameters - icon, showText
 [{
   id: <PropTypes.number> or <PropTypes.string>, has to be unique
   label: <PropTypes.string>, representing the tooltip content
   assistiveText: <PropTypes.string>, The default is `[Step props.index + 1]: [status]`. Status is if the step has been completed or in an error state.
   icon: <PropTypes.string>, name of LDS icon
   showText: <PropTypes.bool>, whether to show or hide label in the progress Indicator
 }],

This library is an implementation of https://github.com/salesforce-ux/design-system . You want to make UX pattern suggestion there.

This page may be helpful too for contextual usage such as for a modal footer. https://lightningdesignsystem.com/components/progress-indicator/


feat: add retry count value of custom metric

Fixes #7705
Motivation
Currently, there is no way to obtain the retry count for each step. If we can use the retry count as a custom metric, it would be useful for identifying problematic steps.
Modifications
I have added the retry count as a metric value.

Verification
I conducted a test as follows:
If a step is successful, the retry metric will not be shown. However, if a step fails and is retried, the retry metric should be displayed.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: retry-with-steps-
spec:
  entrypoint: retry-with-steps
  templates:
    - name: retry-with-steps
      steps:
        - - name: success
            template: random-success
          - name: fail
            template: random-fail
    - name: random-success
      container:
        image: python:alpine3.6
      metrics:
        prometheus:
          - name: retry_count_success
            help: "retry count of success step that would not be appear, as it would not be retried"
            counter:
              value: "{{retries}}"
    - name: random-fail
      retryStrategy:
        limit: "3"
      container:
        image: python:alpine3.6
        command: [python, -c]
        args: ["invalid_args@@@; import sys; print('retries: {{retries}}'); exit_code = random.choice([0, 1, 1]); sys.exit(exit_code)"]
      metrics:
        prometheus:
          - name: retry_count_fail
            help: "retry count of fail and retry step that would be appear, as it would be retried"
            counter:
              value: "{{retries}}"

The fail step retried 3 times.
And this is what I got from localhost:9090/metrics
# HELP argo_workflows_retry_count_fail retry count of fail and retry step that would be appear, as it would be retried
# TYPE argo_workflows_retry_count_fail counter
argo_workflows_retry_count_fail 3

So sorry, I'm going through old PRs and I see that unfortunately this one has been forgotten. I will try to review it soon.
Argo Workflows needs more people approving PRs unfortunately. If your company is by chance interested, I am gauging interest in this idea: https://github.com/argoproj/argo-workflows/issues/12229


[Feature Request] Add Setting to Change Notification Sound

Hei, i like this app, it can boost my productivity, and i would like to change notification sound from pomotroid like school bell or maybe custom sound but unfortunatelly there is not any feature like that in pomotroid, maybe you can consider to add setting to change notification sound, thank you

I second this request. I have looked into the programs folder and unfortunately I was unable to find a way to replace the default sound file (this would have been easiest).
When I am listening to music while working, Pomotroid's faint chime doesn't quite manage to grab my attention. I'd need something like a foghorn or a AWOOOGA cartoon sound to get me out of my groove.
Please, developer(s), make this a possibility.


Does Nitro work with the COMPOSER_AUTH environment variable?

Description
I have a Craft 3 project which is trying to pull in a private repo as a composer dependency. I am trying to use the COMPOSER_AUTH environment variable as this is portable across all environments.
The main composer.json has this:
 "repositories": [
     {
       "url": "https://github.com/xxxxxxxxxxx/xxxxxxxxxxxxx.git",
       "type": "git"
     }
]

However upon running composer update after adding the dependency I am getting:
Cloning failed using an ssh key for authentication, enter your GitHub credentials to access private repos
When working with _public_ GitHub repositories only, head to https://github.com/settings/tokens/new?scopes=&description=Composer+on+ae7cfe7257f4+2022-05-26+1801 to retrieve a token.
This token will have read-only permission for public information only.
When you need to access _private_ GitHub repositories as well, go to https://github.com/settings/tokens/new?scopes=repo&description=Composer+on+ae7cfe7257f4+2022-05-26+1801
Note that such tokens have broad read/write permissions on your behalf, even if not needed by Composer.
Tokens will be stored in plain text in "/tmp/auth.json" for future use by Composer.
For additional information, check https://getcomposer.org/doc/articles/authentication-for-private-packages.md#github-oauth
Token (hidden):

My .env file contains:
COMPOSER_AUTH="{\"github-oauth\":{\"github.com\":\"xxxxxxxxxxxxxxxxxxxxxxxxxxxxx\"}}"

I'm not sure if this is a Nitro thing, but I think I have the correct formatting of storing the token in an environment variable, however it appears composer cannot see it.

Nitro version: 2.0.10
Docker version: 4.8.2

@jamesmacwhite are you running nitro composer or nitro ssh?
Also, if you are defining the environment variable in your .env composer won't read that by default.


Middle mouse button canvas move does not work Windows.

Current Behavior
When you try to drag the canvas with middle mouse button on Windows (e.g. in Chrome), the cursor change to a "scroll cursor" and the canvas scrolls endlessly instead of being dragged accurately.
Other web "canvas" programs, e.g., Miro has solved this issue and middle button drag works fine.
Expected Behavior
Expected to work like middle mouse button move like on Mac and Linux
Steps To Reproduce
Just drag canvas with middle mous button
Example flow
n/a
Environment

Node-RED version: 3.0.2
Node.js version: version in official docker image
npm version:
Platform/OS: Windows 10 (updated)
Browser: Chrome Version 114.0.5735.199 (Official Build) (64-bit)

i can confirm this! windows 10, chrome Version 116.0.5845.188 (Official Build) (64-bit), latest nodered

Current Behavior
When you try to drag the canvas with middle mouse button on Windows (e.g. in Chrome), the cursor change to a "scroll cursor" and the canvas scrolls endlessly instead of being dragged accurately.
Other web "canvas" programs, e.g., Miro has solved this issue and middle button drag works fine.
Expected Behavior
Expected to work like middle mouse button move like on Mac and Linux
Steps To Reproduce
Just drag canvas with middle mous button
Example flow
n/a
Environment

Node-RED version: 3.0.2
Node.js version: version in official docker image
npm version:
Platform/OS: Windows 10 (updated)
Browser: Chrome Version 114.0.5735.199 (Official Build) (64-bit)

a simple fix is holding shift while dragging, then the dragging works normally.

Holding down Shift is a temporary solution. In fact, many times, in order to improve work efficiency, we should simplify things. We do want to directly click the middle button to manipulate the canvas. This will make our operations faster! As a user here and I like this project very much, I hope the official can make some improvements.

Holding down Shift is a temporary solution. In fact, many times, in order to improve work efficiency, we should simplify things. We do want to directly click the middle button to manipulate the canvas. This will make our operations faster! As a user here and I like this project very much, I hope the official can make some improvements.

I fully agree.

Came here hoping others had filed an issue about this behavior. I'm glad to see there's a workaround (holding shift), however I hope this can be resolved, as it's currently the only issue I have with Node-Red currently!

Hopefully a maintainer sees this!
This will disable middle mouse scroll on Windows by preventing the default behavior:
document.addEventListener('mousedown', (e) => e.button === 1 && e.preventDefault())

Run this in the browser console to see the glorious intended behavior of middle mouse drag.
node-red's project layout and code style is unconventional in javascript/web world but I can try to find the relevant parts to make this change, no promises.
For anyone else who wants to try: I'm hitting D3 vendor breakpoints when monitoring the click events and middle clicking.

Hopefully a maintainer sees this!
This will disable middle mouse scroll on Windows by preventing the default behavior:
document.addEventListener('mousedown', (e) => e.button === 1 && e.preventDefault())

Run this in the browser console to see the glorious intended behavior of middle mouse drag.
node-red's project layout and code style is unconventional in javascript/web world but I can try to find the relevant parts to make this change, no promises.
For anyone else who wants to try: I'm hitting D3 vendor breakpoints when monitoring the click events and middle clicking.

Thank you so much, I hope this will even if temporarily fix the issue.

Such an easy and straightforward fix, and it has been open for almost a year now...


VSCode Extension plugin not formatting on save (v0.0.11)

Aim
Have .nr files autoformat on save
Expected Behavior
.nr files auto-format on save with noir-lang extension v0.0.11 as it does on v0.0.9
Bug
.nr files do not auto-format on save with noir-lang extension v0.0.11 as it does on v0.0.9
To Reproduce

Open .nr file
Make it un-pretty
Save
v0.0.11 does NOT format
install version v0.0.9, save, does format .nr file

Environment
No response
Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response

@lang:noir settings (not general settings, not @ext setting) -> "format on save" defaults to on for the older version, and defaults to off for 0.0.11.  Which appears to explain the difference between versions.

Solution: Check the general VS Code "Format On Save" setting.
Thanks @jzaki 🙏


Remove the '…' for the action 'Select Statistics…' on blob context menu

Storage Explorer Version: 1.3.1
Platform/OS Version: Windows 10/MacOS High Sierra/ Linux Ubuntu 16.04
Architecture: ia32/x64
Build Number: 20180716.1
Commit: 47039639
Regression From: Not a regression
Steps to Reproduce:

Expand one storage account and open one blob container.
Upload one blob to it -> Check the context menu for the blob.

Expected Experience:
It displays 'Select Statistics' on the blob context menu.
Actual Experience:
It displays 'Select Statistics...' for the blob context menu.

This issue doesn't reproduce for files/directories.
Add '...' for the 'Set Default Access Tier' on one GPV2 account context menu.

The reason the "…" should be removed is because this menu option doesn't open a dialog.

More Info:
Add '...' next to 'Change Access Tier' for one blob under GPV2 accounts.

This issue has been fixed on latest master build 20190709.5 for blobs.
But it still reproduces for files. So keep it open to track.

This issue has been fixed on build master/20190719.7. So we close it.