Error: EPERM: operation not permitted

Hi!
I run npm run dev on cmd (run as administrator) but I got this error.
I have verified with 'is-elevated' module but I got true.
I'm on windows.
This is my code :
const isElevated = require('is-elevated');
isElevated().then(elevated => {
  console.log(elevated);// return true in my case
});
const fs = require('fs')
var emitter = require('etcher-image-write').write({
  fd: fs.openSync('\\\\.\\E:', 'rs+'), // '\\\\.\\PHYSICALDRIVE1' in Windows, for example.
  device: '\\\\.\\E:',
  size:<PHONE_NUMBER>
}, {
  stream: fs.createReadStream("D:\\Users\\mbess\\Documents\\2018-04-18-raspbian-stretch-lite.zip"),
  size: fs.statSync("D:\\Users\\mbess\\Documents\\2018-04-18-raspbian-stretch-lite.zip").size
}, {
  check: true
});

emitter.on('progress', (state) => {
  console.log(state);
});

emitter.on('error', (error) => {
  console.error(error);
});

emitter.on('done', (results) => {
  console.log('Success!');
});

That is the error :
LandingPage.vue?1fd2:64 Error: EPERM: operation not permitted, write
    at Object.exports.usingStreaming (D:\workspace\thingmill.retrobox.desktop\node_modules\etcher-image-write\lib\write.js:114:10)
    at Object.exports.inferFromOptions (D:\workspace\thingmill.retrobox.desktop\node_modules\etcher-image-write\lib\write.js:210:18)
    at D:\workspace\thingmill.retrobox.desktop\node_modules\etcher-image-write\lib\index.js:133:18
    at <anonymous>
From previous event:
    at Object.exports.write (D:\workspace\thingmill.retrobox.desktop\node_modules\etcher-image-write\lib\index.js:132:31)
    at VueComponent.burn (webpack-internal:///10:19:45)
    at click (webpack-internal:///42:79:23)
    at invoker (webpack-internal:///0:2028:18)
    at HTMLButtonElement.fn._withTask.fn._withTask (webpack-internal:///0:1827:18)

Etcher's documentation still needs updating, but Etcher hasn't used this module since November 2017.
@jhermsmeier Should this etcher-image-write module be marked as deprecated / unsupported?

@lurch Ok, How I can have a module to write

@lefuturiste I dunno, all I can suggest is looking at https://github.com/resin-io/etcher/pull/1671 :man_shrugging:
@jhermsmeier Does he need to wait for the release of the "Etcher SDK" ?

I oso facing the same error. It this issue fixed ?

Hello,
Cleaning up here, this project is deprecated, and you should use https://github.com/balena-io-modules/etcher-sdk instead


ruff server does not consider config include

I want to use ruff server on a project where I want to introduce formatting and linting gradually.
My idea was to use the include feature in the ruff.toml config:

# only lint & format opt-in files
include = [
    'src/plots.py',
    'src/reports.py',
]

This perfectly works when using ruff format . and ruff check .  from the CLI, meaning that only the two files listed are formatted and linted, nothing else.
However when using the ruff server all files are formatted and linted. This is especially problematic when using the format on save or auto-fix on save feature via an IDE. Also way to many diagnostics from the linting are shown.
I looked at the formatting handler source code and can see that the exclude list is already parsed from the config. However the include property is not considered at all. The same is true for fixes and linting.
I would really appreciate, if the include mechanism could be added to the ruff server as well. Meaning that the server ignores format and fix requests, and returns no diagnostics for files not in the include list. In the same way it works for the CLI tool.

Looking into this...

Your assessment is correct. The new server isn't considering anything from the file-resolver settings apart from exclude and extend-exclude.

I think the simplest solution here is to use the logic of the various FileResolverSettings information from python_files_in_path function and incorporate it into the linting and formatting entry point for the ruff server.
But, a long term goal would to have some kind of abstraction which can resolve the path based on the given settings.


Fix shellcheck hook by removing additional dependencies

The shellcheck hook breaks with the latest version of pre-commit (2.10.0) because of pre-commit/pre-commit#1771, which errors out when you use language: script and also specify additional dependencies.
From the pre-commit docs on script:

This hook type will not be given a virtual environment to work with – if it needs additional dependencies the consumer must install them manually.

I've also added an error message if shellcheck isn't locally installed, to match what already exists for the shfmt hook (https://github.com/jumanjihouse/pre-commit-hooks/blob/master/pre_commit_hooks/shfmt#L13-L16)
[The CI failure is because of ruby + rubocop stuff and is unrelated to this PR - shellcheck passes]

Same problem here, CI suddenly failed this morning...

Same problem here, CI suddenly failed this morning...

LGTM, team can we get a review on this please.
Look for any errors in the above output or in docs/_build/linkcheck/output.txt
pre-commit installed: appdirs==1.4.4,cfgv==3.2.0,distlib==0.3.1,filelock==3.0.12,identify==1.5.13,importlib-metadata==3.4.0,nodeenv==1.5.0,pre-commit==2.10.1,PyYAML==5.4.1,six==1.15.0,toml==0.10.2,typing-extensions==<IP_ADDRESS>,virtualenv==20.4.2,zipp==3.4.0
pre-commit run-test-pre: PYTHONHASHSEED='491141206'
pre-commit run-test: commands[0] | pre-commit run --all-files --show-diff-on-failure
[ERROR] The hook `shellcheck` specifies `additional_dependencies` but is using language `script` which does not install an environment.  Perhaps you meant to use a specific language?
ERROR: InvocationError for command /home/user/git/common-packer/.tox/pre-commit/bin/pre-commit run --all-files --show-diff-on-failure (exited with code 1)
__________________________________________________________________________________________________________________ summary ___________________________________________________________________________________________________________________
  docs: commands succeeded
  docs-linkcheck: commands succeeded
ERROR:   pre-commit: commands failed

Thanks everybody!

I merged the PR to update rubocop (and was causing this PR to fail), then
rebased this PR on master and opened https://github.com/jumanjihouse/pre-commit-hooks/pull/85
merged 85

(apologies that i didn't see this before...i missed the notification in email for it)

tag 2.1.5 has the fixes


bug(list): MatIcon not displayed with matListItemMeta tag

Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
14.2.0
Description
After the material migration to the mdc-based components MatIcons are not displayed correctly in the meta section of a list item.
Reproduction
Steps to reproduce:

Build a simple page with a MatList and a MatListItem.
Add an icon to the meta section.
Icon will display only the selector as text.

https://stackblitz.com/edit/components-issue-mmrxed?file=src%2Fapp%2Fexample-component.html
Code example:
<mat-list>   <mat-list-item>     This shows no icon in the meta section ->     <mat-icon matListItemMeta>edit</mat-icon>   </mat-list-item> </mat-list>
Expected Behavior
The icon has to be displayed.
Actual Behavior
The icon name is shown.
Environment
Angular CLI: 15.0.4
Node: 18.12.1
Package Manager: npm 8.19.2
OS: win32 x64
Angular: 15.0.4
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Package                         Version
@angular-devkit/architect       0.1500.4
@angular-devkit/build-angular   15.0.4
@angular-devkit/core            15.0.4
@angular-devkit/schematics      15.0.4
@angular/cdk                    15.0.3
@angular/material               15.0.3
@schematics/angular             15.0.4
ng-packagr                      15.0.3
rxjs                            7.5.7
typescript                      4.8.4

The problem is that matListItemEnd has a specific font-family assigned from MDC. This overrides the ligature font. A workaround would be to use:
 <div matListItemMeta>
  <mat-icon>edit</mat-icon>
</div>

The problem is that matListItemEnd has a specific font-family assigned from MDC. This overrides the ligature font. A workaround would be to use:
 <div matListItemMeta>
  <mat-icon>edit</mat-icon>
</div>

Thank you, @devversion. Your workaround is working. Maybe providing an example in the official docs would help. :)

@crisbeto would you like the fix for this to be the docs update to share the the example (workaround)? Or would it be to address the font-family being applied to matListItemEnd?

Hi @crisbeto, I want to help with this issue. I have a question. Shall we add an example based on this issue? Or just add an annotation description regarding the function of matListItemEnd into the table-style directive list item?


Release v0.5.0

Several features were added since we last released.

add vlans on uplink
bump to go 1.19
implement device info spec 1.1 (add representor-device field)

It would be great to do a release so that users can use a tagged version of accelerated-bridge-cni with latest features.
Do we want additional content to be added for release ?

lets also have PR#63

v0.5.0 has been released.


[Bug] ELSE IF parsing error message changed in RF 5

It's not catched in RF 5.0: ELSE IF cannot have more than one '  'condition

Partly covered in #562 . I will see what else we're missing and if something was added in 5 beta 1 - 2


Fix bug with GRPC client implementation not properly invoking GRPC server on chain

https://github.com/palomachain/paloma/issues/71


v0.9.1_16: Vizabi container is disturbed by clicking “Restore” on Firefox

SEVERITY:  Major
MODULE: Bubble chart
Platform:  Windows 7 / Firefox 43.0
RELEASE: v0.9.1
STEPS TO REPRODUCE:

Navigate to the URL : http://static.gapminderdev.org/vizabi/release/v0.9.1/preview/bubblechart.html
Bubble chart will be loaded.
Click “Expand”
Click “Restore”
Note that chart is disturbed by clicking “Restore”

ACTUAL RESULTS:
Chart is disturbed by clicking “Restore” on Firefox
EXPECTED RESULTS:
Chart should not disturb by clicking “Restore”
SCREENSHOT:

@k6Labz still an issue?

Retest Result: Pass
Testing Environment: http://static.gapminderdev.org/vizabi/develop/preview/bubblechart.html
Platform: Windows 7 / Firefox 44.0


Struct filtering & comparison functions

currently:
compare_scalar/compare_int
                        time:   [41.517 ms 41.610 ms 41.700 ms]
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) low mild
  1 (1.00%) high mild

compare_scalar/compare_bool
                        time:   [3.2470 ms 3.2555 ms 3.2640 ms]
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) low mild

Turns out wrapping in a const array and calling into compare() is like 10x slower than just constructing a booleanbuffer and doing things manually
compare_scalar/compare_int
                        time:   [42.124 ms 42.214 ms 42.299 ms]
                        change: [+0.3621% +0.6780% +1.0019%] (p = 0.00 < 0.05)
                        Change within noise threshold.
Found 10 outliers among 100 measurements (10.00%)
  1 (1.00%) low severe
  8 (8.00%) low mild
  1 (1.00%) high mild

compare_scalar/compare_bool
                        time:   [283.62 µs 287.99 µs 292.13 µs]
                        change: [-8.2366% -6.2883% -4.3882%] (p = 0.00 < 0.05)
                        Performance has improved.


Update the top nav with Learn Pulumi link

Part of https://github.com/pulumi/pulumi-hugo/issues/617
This PR updates the top nav as defined in the above issue. What this PR doesn't do is update the actual URLs from /resources/* -> /events-and-workshops/*. This is intentional as the last attempt at the updating the URLs ran into an issue and had to be reverted.
I broke out the cosmetic changes from the URL changes so that we will reduce the risk of hitting an issue when all this merges. I think updating the URLs can happen right after we ship the main chunk of the Learn Pulumi stuff. That way we can reduce this risk of hitting a deployment issue during the actual release of the Learn content.

@zchase something went weird with this pr, there are a whole bunch of extra commits in it

@susanev Alright I fixed up the branch. Git is hard 😂

@zchase do you know why this never got a preview link?

so i guess its cause ur not merging into main, ill try it out locally


fix(sdk): How to create Connectors and DataSources

depends on https://github.com/ydataai/platform-python-sdk/pull/127

this also should be a feat


poet: allow one submission of PoST per miner per round per poet service

Description
condensing Noam's comments in slack:
To enforce this, the node will need to submit the entire “poet challenge” (NIPostChallenge) to the PoET and it will calculate the hash itself (could be good to return the hash in the response)
This part is not trivial, I think we may want the PoET to ask a node (it already has access to the “PoET gateway” - maybe we should rename it) to validate this data structure.
If this is a smesher’s first ATX, then the NIPostChallenge includes the initial PoST proof - which needs to be validated.
If it’s a subsequent ATX, the NIPostChallenge only includes a reference to the PrevATXID - that previous ATX includes the PoST proof that came after the previous PoET run (we only do one PoST proof each epoch). So validation here must be contextual - the challenge only tells the PoET which smesher it is, but to validate that they still expend resources, we must actually inspect the mesh. This is trivial for the node to do, but not for the context-less PoET.

LGTM
Good job on the structure of this spec! Very readable, keeping the technicalities to the footnotes...

It needs to be added as well (I didn't mention it because it didn't exist at the time I wrote the proposal).

@moshababo few more questions:

Calculate Sequence according to the prev ATX's Sequence.

Why not just pass the sequence in the challenge data?

Calculate the challenge hash and apply it for the upcoming round

For an initial ATX: sha256( NodeID ++ PubLayerID ++ PositioningATX ++ InitialPostIndices )
For a non-initial ATX: sha256( NodeID ++ Sequence ++ PrevATXID ++ PubLayerID ++ PositioningATX )

Challenge data must be serialized consistently anyway for signing. How about we use the serialized representation for hashing too? Then it would become consistent for both cases (initial and non-initial):
sha256(NodeID ++ codec.Encode(challengeData))

(I cannot decide ATM if NodeID should be part of challengeData).

What about the structure of an ATX? It currently contains the NIPostChallenge structure defined in go-spacemesh/types/activation.go. I feel we should avoid defining the same data in multiple places. Perhaps it should contain the same data that were submitted to Poet?

It needs to be added as well (I didn't mention it because it didn't exist at the time I wrote the proposal).

Could You please update the design proposal to include it? I guess that the challenge hash for an initial ATX:

sha256( NodeID ++ PubLayerID ++ PositioningATX ++ InitialPostIndices )

should include CommitmentATX too?

Yes, the challenge hash should include it.
I think that updating the original proposal comment isn’t the best approach (assuming it won’t be the last time). I suggest that you’ll maintain a snapshot of the latest design/impl specs elsewhere, or just consider the entire thread for that purpose.

Verify the metadata with respect to consensus rules.

Could You please point out these rules?

The PoST consensus rules are currently defined in the node’s config, with the following params: BitsPerLabel, LabelsPerUnit, MaxNumUnits, MinNumUnits, K1, K2. The given NumUnits in the metadata needs to be checked for range, while the rest should just be equal.

Node’s SmesherService.PostConfig RPC can be used
Node's MeshService.AccountMeshDataQuery RPC can be used

Do I understand correctly that Poet is supposed to call back the Node that submitted challenge data to ask it for more details?
These details will always be required, so perhaps they should be passed in the initial Submit() GRPC? For example, instead of sending just PreviousATXId, send the whole ATX.

The PoST config are network-level params, so they will need to be queried just once.
The prev-ATX query will happen frequently, but getting it from the submitting client is problematic because it cannot be considered as an honest party (hence why this feature is implemented in the first place). The PoET server’s gateway node(s) are the ones to be trusted (and can be considered as part of the same operation, running the node’s implementation as a service).

Calculate Sequence according to the prev ATX's Sequence.
Why not just pass the sequence in the challenge data?

The value is ought to be the prev sequence + 1. So I didn’t see much utility in passing and then verifying it, instead of just computing it. But passing it might allow better flexibility for future use cases.

Calculate the challenge hash and apply it for the upcoming round

For an initial ATX: sha256( NodeID ++ PubLayerID ++ PositioningATX ++ InitialPostIndices )
For a non-initial ATX: sha256( NodeID ++ Sequence ++ PrevATXID ++ PubLayerID ++ PositioningATX )

Challenge data must be serialized consistently anyway for signing. How about we use the serialized representation for hashing too? > Then it would become consistent for both cases (initial and non-initial):
sha256(NodeID ++ codec.Encode(challengeData))

(I cannot decide ATM if NodeID should be part of challengeData).

This serialization and hashing are currently done in the node. The implementation purpose is to mimic it. Appending well-defined byte arrays is the simplest way to serialize, and the usual practice for producing preimages. I’m not sure that incorporating a more robust serialization scheme is needed here, even if it’s used elsewhere.

What about the structure of an ATX? It currently contains the NIPostChallenge structure defined in go-spacemesh/types/activation.go. I feel we should avoid defining the same data in multiple places. Perhaps it should contain the same data that were submitted to Poet?

The ATX wire serialization is defined in the node's gRPC API via protobuf. Once fetched, that should be sufficient in order to perform the associated checks. Why else would you need to define it separately?

Done


Auth Exchange's didAuthError hook returns a locked ReadableStream for Response.Body

I'm trying to inspect the response body from within didAuthError. I can see that error.response is a Response but I'm unable to use any serialize methods on it (.json(), .text(), etc).
const client = createClient({
      url: "http://localhost:4000/graphql",
      exchanges: [
        authExchange({
          ...
          didAuthError: ({ error }) => {
            const body = await error.response.json();
          }
          ...
        }),
        cacheExchange,
        fetchExchange,
      ],
    });

urql version & exchanges:
"urql": "^2.1.3", "@urql/exchange-auth": "^0.1.7",
Expected behavior
Given the example above, I'd expect to have access to a JSON-serialized representation of the response body.
Actual behavior
I get the error TypeError: Failed to execute 'json' on 'Response': body stream already read

This is intentional and expected behaviour for two reasons 😅

We don't make an assumption that the response is delivered via HTTP and instead only standardise on the GraphQL serialisation format, hence the CombinedError#response property is mostly for debugging
When an error occurs we expect that the GraphQL serialised response is all that's needed (plus at most response.status in exceptional circumstances when there's no other way) hence error.graphQLErrors or error.networkError are the only accessible methods to inspect the error

So, since the response's body has already been consumed we make no effort to clone it and repeat the body or make the JSON blob available otherwise :v:

That makes sense, cheers @kitten  for explaining


Create RandomPasswordGenerator.c

Will you accept? Because some of my PRs are ineligible.
On Mon, 2 Nov, 2020, 1:01 pm Aliya Rahmani<EMAIL_ADDRESS>wrote:

Merged #504 https://github.com/aliya-rahmani/-HACKTOBERFEST2K20/pull/504
into main.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aliya-rahmani/-HACKTOBERFEST2K20/pull/504#event-3946621884,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APPEAPND4T743SYLSEWRNCLSNZN55ANCNFSM4TFHOUFA
.

I've already done that @ashokravihal

Tq sir
On Sun, 8 Nov, 2020, 12:13 pm Aliya Rahmani<EMAIL_ADDRESS>wrote:

I've already done that @ashokravihal https://github.com/ashokravihal
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aliya-rahmani/-HACKTOBERFEST2K20/pull/504#issuecomment-723537866,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APPEAPI4P3P3FK4X6REFMJDSOY425ANCNFSM4TFHOUFA
.

Not yet merged sir.
On Sun, 8 Nov, 2020, 12:19 pm Ashok kumar A<EMAIL_ADDRESS>wrote:

Tq sir
On Sun, 8 Nov, 2020, 12:13 pm Aliya Rahmani<EMAIL_ADDRESS>wrote:

I've already done that @ashokravihal https://github.com/ashokravihal
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aliya-rahmani/-HACKTOBERFEST2K20/pull/504#issuecomment-723537866,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APPEAPI4P3P3FK4X6REFMJDSOY425ANCNFSM4TFHOUFA
.

can you merge it #504


Episodes won't play

If you click the play button the channel locks up. All other videos play.

I'll need to know the url of your feed file so I can test. There may be something different about the way your series is defined.

This appears to be a regression bug.  I will investigate further.  Check back later for an update.

Thanks. One other question: Is there a way I can make the posters smaller like in the Roku sample channel?

From: rrirower @.>
Sent: Wednesday, August 16, 2023 9:28 AM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
This appears to be a regression bug. I will investigate further. Check back later for an update.
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1680607448, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE32DB3P47GHULQEAXMTXVTDHTANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

Can you provide a sample of what you're describing in the Roku channel?  This project uses a grid layout.   It may not be able to support your request.

Sure. The current channel shows smaller posters as in the attached "preview" and the channel itself. Your software channel shows larger posters.

From: rrirower @.>
Sent: Wednesday, August 16, 2023 10:48 AM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
Can you provide a sample of what you're describing in the Roku channel? This project uses a grid layout. It may not be able to support your request.
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1680758654, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE3YIGITNXIA262RBCLTXVTMSJANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

Do you have a Paypal account? I would like to send you an offering.

From: rrirower @.>
Sent: Wednesday, August 16, 2023 10:48 AM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
Can you provide a sample of what you're describing in the Roku channel? This project uses a grid layout. It may not be able to support your request.
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1680758654, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE3YIGITNXIA262RBCLTXVTMSJANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

Sure. The current channel shows smaller posters as in the attached "preview" and the channel itself. Your software channel shows larger posters.

Can you provide a screen image of what you are seeing in the channel?  There was no attachment.
Donations are not required, but, are appreciated.  If you'd like to contribute to this project, please start the Wizard tool and click on the About button on the bottom right of the first screen.  You should see a donation button on the next screen.

Fixed in version <IP_ADDRESS>-alpha-4

I followed the instructions, downloaded Alpha 4 and followed the Wizard,  but when I upload the newly created zip file I get this message.

From: rrirower @.>
Sent: Friday, August 18, 2023 2:18 PM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
Fixed in version <IP_ADDRESS>-alpha-4
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1684271734, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE32GHONG6EY6YOEYMNDXV6WYBANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

There's no message attached.

Apparently the attachment didn't come through. It was a screenshot that said this:
Application Received: 181587 bytes stored
Install Failure: Compilation Failed.PlayerTask

From: rrirower @.>
Sent: Friday, August 18, 2023 8:08 PM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
There's no message attached.
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1684564050, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE35KHJQIERELGBMBHXDXV77YBANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

Please see issue #14

That fixed the error issue but the initial one still exists even with the software update.

From: rrirower @.>
Sent: Friday, August 18, 2023 10:17 PM
To: rrirower/DP2SceneGraphWizard @.>
Cc: JLNjolo @.>; Author @.>
Subject: Re: [rrirower/DP2SceneGraphWizard] Episodes won't play (Issue #11)
Please see issue #14https://github.com/rrirower/DP2SceneGraphWizard/issues/14
—
Reply to this email directly, view it on GitHubhttps://github.com/rrirower/DP2SceneGraphWizard/issues/11#issuecomment-1684690713, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANFYE3YNFSD2MRED3VHEHYLXWAO5DANCNFSM6AAAAAA3SFBHNM.
You are receiving this because you authored the thread.Message ID: @.***>

Fixed with latest zip file.


use rpki-client 8.4.1 in container

Confirming that container builds locally and JSON output is valid.


[docs] [update notes] March, 8-21

[ci skip]

This change is

Review status: 0 of 2 files reviewed at latest revision, 1 unresolved discussion.

docs/update-notes/Q1-18-03-21.md, line 17 at r1 (raw file):

* Fixed loading of the `ebtables` module on non-Ubuntu systems.
* Fixed handling of the HTTP errors during image pulls.
* Added support for libvirt v3.7.0.

It's not exactly "support" as libvirt is a part of standard Virtlet container. Virtlet doesn't officially support using external libvirt or anything like this (i.e. no such setups are documented or recommended atm). Perhaps just "Updated libvirt to 3.7.0"?

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

docs/update-notes/Q1-18-03-21.md, line 15 at r1 (raw file):

* Fixed the CNI error handling.
* Fixed the CNI teardown.
* Fixed loading of the `ebtables` module on non-Ubuntu systems.

ebtables kernel module

Comments from Reviewable

Review status: 0 of 2 files reviewed at latest revision, 2 unresolved discussions.

docs/update-notes/Q1-18-03-21.md, line 15 at r1 (raw file):
Previously, jellonek (Piotr Skamruk) wrote…
ebtables kernel module

Done.

docs/update-notes/Q1-18-03-21.md, line 17 at r1 (raw file):
Previously, ivan4th (Ivan Shvedunov) wrote…
It's not exactly "support" as libvirt is a part of standard Virtlet container. Virtlet doesn't officially support using external libvirt or anything like this (i.e. no such setups are documented or recommended atm). Perhaps just "Updated libvirt to 3.7.0"?

Done.

Comments from Reviewable

Reviewed 1 of 2 files at r1, 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


New version: Pipelines v0.4.2

Registering package: Pipelines
Repository: https://github.com/cihga39871/Pipelines.jl
Created by: @cihga39871
Version: v0.4.2
Commit: 2c88f3356edc11e470e6d33ce1f71fe728e891d5
Git reference: main

Hi Please delete or ignore this pull request. I dropped the version to 0.4.1 from 0.4.2, so this pull request is no longer used.


genereos-testing-libraries-milestone-1.md

Milestone Delivery Checklist

[x] The milestone-delivery-template.md has been copied and updated.
[x] The invoice form has been filled out for this milestone.
[x] This pull request is being made by the same account as the accepted application.
[x] In case of acceptance, the payment will be transferred to the EOS account name provided in the application.
[x] The delivery is according to the Guidelines for Milestone Deliverables.

Link to the application pull request: genereos-testing-libraries

https://github.com/eosnetworkfoundation/grant-framework/pull/10

Some of the tests fail randomly, I doubt this is the desired result?  On one run 28 failed, the next 1 failed.

@larryk85 The test with 28 failed only happens the first time, right? Because the test was timeout when it pulled the docker image.
@timmwest  We should have a  better way to handle this case

@larryk85 The test with 28 failed only happens the first time, right? Because the test was timeout when it pulled the docker image. @timmwest We should have a better way to handle this case

Yes it was when first starting up.  I reran on a fresh machine and that seemed pretty consistent.

@timmwest strange that Qtest is build using Typescript, but types are not being exposed when importing library

Regarding the slow boot process:

8177 ms setup chain using QTest
21 ms using an EOSIO VM emulator (Vert).

If every cold start is going to be ~8 seconds, this will get extremely irritating for any developers running tests continuously.

@larryk85

Yes it was when first starting up. I reran on a fresh machine and that seemed pretty consistent.
Qtest lib relies on Jestjs to start up, So the only way now to pull the docker image when the user starts the unit test. We've added a warning message that tells users they might be faced with this issue at the first test in Qtest v0.3.5

@DenisCarriere

No typescript support (once resolved, milestone seems to be complete)
This was resolved at Qtest v0.3.5


Multiple iSpindels for a single temperature controller/chamber

I have a chest freezer with room for 2 fermenters.  So I have 2 iSpindels to track the fermentation of those 2 fermenters.  Unfortunately it looks like I can only associate a single iSpindel to a temperature controller (chamber).  Is there a way to associate multiple devices so that I can see the log of the fermentation?
Without that feature, I can't see a graph of the second iSpindel unless I add a second 'log' for the same beer fermenting in the first fermenter

Fermentrack will allow you to add both iSpindels, but as you noted, it will only allow one at a time to be associated with a temperature controller/fermenter.
I'm not sure if this is what you were referring to by "adding a second log", but you can log a fermentation on a gravity sensor in the same way you can log a temperature controller or controller+gravity sensor combination. In this way, you're able to log both sensors separately - but you won't see both on the same graph.


Document Java version compatibility

What versions of Java is this library intended to support?  Please document this in the README.

Fixed in #12


[Feature Request] Custom dom nodes as info for lint diagnostic actions

When using the lint extension it's currently possible to pass a dom element to a diagnostics action in the name attribute. The HTML is rendered correctly but e.g. the aria-label is wrong since the .toString() message is returning the default placeholder [object HTMLDivElement].
It is quite nice to pass a dom element for custom content which is also possible in the autocompletions info https://codemirror.net/6/docs/ref/#autocomplete.Completion.info
It would be nice to have a separate property, like info, to define custom content for those diagnostic actions like:
const dom = document.createElement('div');
// ... fill dom with content

const diagnostic: Diagnostic = {
    from: 0,
    to: 10,
    message: 'Something is wrong',
    severity: 'error',
    actions: [{
        // for aria-label and internal house keeping as before
        name: 'Click to fix',
        // for content of the action if available, with fallback to name for backwards compatibility
        // similar to autocompletion info:
        // undefined | string | fn() => Node | (Promise<Node>)?
        info: dom,
        apply: () => {
            // do something to fix
        }
    }]
}

Has been implemented in the lint package via renderMessage https://codemirror.net/docs/ref/#lint.Diagnostic.renderMessage so this can be closed.


Enabling use of up/down asymmetric images

This PR address #27. It contains an implementation of the BASEX algorithm for Abel-inverting images which do not possess up/down symmetry. Up/down symmetry is defined as f(r,-z) = f(r,z). The underlying BASEX algorithm only requires the images being inverted to have axial symmetry, i.e. f(-r) = f(r). This PR enables using PyAbel for this more general case.
The major changes can be summarized as

From the end user's perspective, asymmetric transforms are toggled with a new parameter vertical_symmetry = <True, False, or None> (see changed function definition here). The default setting is vertical_symmetry=False so PyAbel should work just as before if the end user does not change anything.
n is decomposed into n_horz and n_vert (see lines here through here)
nbf is treated as nbf_horz and nbf_vert (here). Using nbf = 'auto' is strongly recommended for now.
Independent basis sets are generated for the vertical and horizontal directions (see lines here and here)
The inverted image is generated by matrix multiplying the horizontal and vertical components to the raw data (here)
A few new helper functions are introduced, including a new centering function. My centering conventions might be different from what was the provision conclusions in #37 and #34. If necessary, I can amend the PR to reflect the community's consensus on how even-shaped images should be handled, etc.

Both Travis and AppVeyor seem to have similar errors
ERROR: Failure: ImportError (cannot import name 'get_basis_sets_cached')
As per #36, I have renamed certain functions, including get_basis_sets_cached as get_bs_basex_cached. Possibly that's the reason for this error? I am not very familiar with how the CI tools work, so I will ask the veterans  @DanHickstein, @rth, and @stggh to help me out here.

You are correct. See abel/tests/test_basex.py

Travis seems to fail when nbf is set to n//2+1 in test_basex_basis_set() of abel/tests/test_basex.py.
From what I understand about the number of basis sets necessary to resolve the image, if n=101, that needs 51 basis functions (n//2+1) rather than 50 (n//2) as I mentioned here before.
Maybe @DanHickstein can look into updating dan_basis100{}_1.bst.gz to have this work? Thoughts?

Nice work @DhrubajyotiDas!
Currently, abel.BASEX (soon to be renamed abel.iabel_basex) is using vertical symmetry, so if we wanted to keep the current behavior, shouldn't we use vertical_symmetry=True? Not arguing for one default rather than the other (either seems fine to me), but if we want to maintain current behavior, I think it should be False.
TravisCI and Appveyor just automatically run the tests that are located in abel/tests. You can run them on your system with
python  -c "import abel.tests; abel.tests.run_cli(coverage=True)"
which is much faster than waiting for Travis. (I always forget this command, but luckily @rth wrote it down here: https://github.com/PyAbel/PyAbel/blob/master/CONTRIBUTING.md)
You are right that we now believe it to be foolish to run Basex with n=101 and nbf=50. A long time ago we were generating the basis sets with a matlab script and wanted to make sure that the python code was producing the same thing. So, we included this test. Now, it seems a little silly. But it is a good test that nothing changes with the results of the basis set generation algorithms. Maybe open a separate issue and we can decide what to do.
On the topic of tests, I think that it would also be a good idea to include a test that ensures that both the symmetric and asymmetric BASEX transforms return (nearly) identical results.

Should we consider merging everything into one centering function? I can see that the current centering function does not satisfy the need for returning asymmetric images, but can't the current function be modified fairly easily? Currently, it takes the parameter n - which should probably be renamed size or output_size -  but couldn't the function be modified to accept either integer (size=200) or tuple (size=(350,200)) arguments?
I suppose that we may also want to give the user the option to only specify the center column, and also it might be nice to allow the image to be cropped to the maximum size possible given the specified center (in which case the output size need not be specified). The function could default to size=(-1,-1), in which case the maximum image size is returned. The user could specify size=(-1,200) to crop/pad the image to 200 columns, but use all of the rows. The only issue is, in the case of something like size=(200,-1) (or size=(-1,-1)), it's not clear if an odd or even sized image should be returned. I think an additional col_parity='odd' keyword argument would be necessary.
BTW, the consensus was actually to move the centering functions out of the transform functions (i.e., abel.BASEX should just assume that it's given a proper image and we leave the centering to the user), we just had not gotten around to this yet. So, if you don't feel like modifying your centering function, we can probably still merge and just open a separate issue about creating a single centering function.

That is very nice! I am eager to try this non asymmetric transform with my images (that don't have the up/down symmetry).
For the naming, IMO at some point we could rename basex_transform to iabel_basex (and similarly for the _asym case), while the BASEX function could be renamed to something else, separated from the centering function, and made to return objects as discussed in this comment? But in either case, I think this is a different issue and maybe we can talk aboutit separately (on the same topic iabel_direct currently works on only 1 quadrant unlike iabel_basex (whichever function we decide it is) and iabel_hansenlaw)?
I agree that merging the 2 two centering functions in a single one would be a good idea, but maybe we can merge this PR and then open a separate one for that (as there is already lots of changes here)?
Regarding unit tests,

I think that it would also be a good idea to include a test that ensures that both the symmetric and asymmetric BASEX transforms return (nearly) identical results.
+1 Although, would this give us more information, than say just comparing whether BASEX reproduces some analytical function?

@DhrubajyotiDas  Would you mind adding a few unit tests for the asymmetric case, for instance the same ones as for the symmetric case. You could for instance,

Create a abel/test/test_basex_asym.py as a copy of abel/test/test_basex.py.
Keep only the test_basex_basis_sets_cache, test_basex_shape, test_basex_zeros, test_basex_step_ratio functions inside and rename them with a _asym suffix.
Replace n = number to n = (number1, number2)  and all basex_transform by basex_transform_asym etc.

This should work out of the box, and just insure some tests coverage for the asymmetric case (which would help to detect if something gets broken after a future code change).
Also, @DhrubajyotiDas, I  wondering something about the basis set generation for this assymetric case. I have not read the original article in much details so it might be an ignorant question :) So as I understand when there is no up/down symmetry,  the different rows are decoupled and can essentially be solved separately, right? Then, I would have expected the M_vert and Mc_vert not be used at all (or  be scalar), but not depend on both i and j indices as it is the case for Mc_vert. I mean, the fact that Mc_vert has a shape (n_vert, nbf_vert) with basis functions in the vertical direction, does this means that different rows are somehow coupled during the transform?

@DanHickstein Thanks for the feedback!
I agree that the default symmetry setting should be vertical_symmetry=True. That was an oversight on my part. Strangely, the options become incomprehensible after staring at them continuously for a few hours!

Currently, the user can specify the center as

integer, in which case it is assumed to be the center column of the image, or
tuple, where the center is given in (x,y) format. This is for backwards compatibility.

The size of the image output from my centering function center_image_asym is always (n_vert, n_horz), either by cropping or padding zeroes as necessary.
IMO, since the user has already specified n (which, as you mentioned, we should rename to something more intuitive such as size), it seems appropriate to use that as the spec for how big the inverted images ought to be.
I think the original unified centering function might be suited to do all this OOTB. My main reason for writing another centering function was simply for code readability, and because I wanted rows of zeroes to be padded when a vector was passed as rawdata. I believe the original centering function duplicated the vector.

@rth Thanks for the suggestions!
I'll add the unit tests and send up a few more commits. Currently both symmetric and asymmetric BASEX show excellent agreement for a Gaussian function.

Awesome work guys!
@rth, I think that our new convention is actually that abel.basex_transform should be renamed abel.iabel_basex_transform and abel.BASEX should re-constructed (without centering) as abel.iabel_basex. We can probably implement this change to BASEX after this merge, though we may want to hold off on messing with Hansen-Law until @stggh is done with his PR.
I didn't realize before that your abel.iabel_direct only works for one quadrant (more precisely, doesn't it work for half of the image?). I think that the convention that we decided upon is that the function abel.iabel_xxxx_transform contains the core routine, but can have non-standard inputs and outputs depending on the transform. abel.iabel_xxxx will contain a wrapped function that will accept a centered (but whole) image and return an object containing results.transform (and potentially other results). So, I think that you probably just need to change your abel.iabel_direct to abel.iabel_direct_transform and add abel.iabel_direct as a wrapper function that will handle a full image. Similar change for the forward transform is probably needed.
No need to worry about this for this PR, but in the future we can make the change. Same thing for the centering function. Let's combine the two functions later.
I'm glad that @rth asked about the basis functions. I've read the paper many times, and I think that I understand the simple matrix multiplications that take place during the actual transform. But I really have no idea what's going on with the generation of the basis functions. If you can shed light on this, it would be much appreciated.

@rth and @DanHickstein
Regarding the vertical basis functions, here are the relevant sections from the original Dribinksi et al. paper

Let's look at the vertical_symmetry=True case (classical BASEX):
To clarify the notation, the basis sets that were being calculated earlier

M, and Mc

are equivalent to the RHS of Eq 14 and 15 respectively. Unfortunately, the expressions as provided are hard to evaluate numerically (lots of things go haywire when for example, k = 0). However, the authors do provide a nicer algorithm in the Appendix of the paper (Eq A1 - A3) which can be implemented numerically in order to do the actual evaluation. The original matlab code, and all python ports use this formulation. This might explain the mismatch between the matlab code and the paper that @DanHickstein noticed in the past.
Once we have values for rho_k and X_ki (saved inside M and Mc), we need to evaluate Z_mj. While there are no real restrictions on what this should be, in BASEX, Z_mj is taken to have the same form as the Gaussian-type functions of rho_k. This is reflected in the last equation pasted above.
What happens in the case of vertical_symmetry = True is that we can adopt a very useful shortcut, which is that we can simply copy the values of M into Z_mj directly. M stores rho_k evaluated from -r_max to r_max, and for square images with up/down symmetry, that's also -z_max to z_max. Reusing M so that Z_mj contains the same value of -z and z is where the up/down symmetry is enforced.
Once we have X_ki and Z_mj, we can calculate A and B, which are the M_left and M_right matrices in the code.
M_left = inv(Mc.T.dot(Mc)).dot(Mc.T)
M_right = M.dot(inv((M.T.dot(M) + E)))
In the current iteration of BASEX there isn't any regularization (q_1 and `q_2
Regarding @rth's concern

I mean, the fact that Mc_vert has a shape (n_vert, nbf_vert) with basis functions in the vertical direction, does this means that different rows are somehow coupled during the transform?

This is directly addressed in the next paragraph of the paper (Pg. 2636), where the authors state that the two transformations (matrix A and B) are completely independent, and work on the raw data matrix P independently. Because of the way the three matrices A, P, and B are multiplied to calculate the matrix of coefficients C (Eq 13 in the clipped image above), every row (and essentially every pixel) of P sees a single, uncorrelated element in A and B.

@rth and @DanHickstein
Regarding the vertical basis functions, here are the relevant sections from the original Dribinksi et al. paper

Let's look at the vertical_symmetry=True case (classical BASEX):
To clarify the notation, the basis sets that were being calculated earlier

M, and Mc

are equivalent to the RHS of Eq 14 and 15 respectively. Unfortunately, the expressions as provided are hard to evaluate numerically (lots of things go haywire when for example, k = 0). However, the authors do provide a nicer algorithm in the Appendix of the paper (Eq A1 - A3) which can be implemented numerically in order to do the actual evaluation. The original matlab code, and all python ports use this formulation. This might explain the mismatch between the matlab code and the paper that @DanHickstein noticed in the past.
Once we have values for rho_k and X_ki (saved inside M and Mc), we need to evaluate Z_mj. While there are no real restrictions on what this should be, in BASEX, Z_mj is taken to have the same form as the Gaussian-type functions of rho_k. This is reflected in the last equation pasted above.
What happens in the case of vertical_symmetry = True is that we can adopt a very useful shortcut, which is that we can simply copy the values of M into Z_mj directly. M stores rho_k evaluated from -r_max to r_max, and for square images with up/down symmetry, that's also -z_max to z_max. Reusing M so that Z_mj contains the same value of -z and z is where the up/down symmetry is enforced.
Once we have X_ki and Z_mj, we can calculate A and B, which are the M_left and M_right matrices in the code.
M_left = inv(Mc.T.dot(Mc)).dot(Mc.T)
M_right = M.dot(inv((M.T.dot(M) + E)))
In the current iteration of BASEX there isn't any regularization (q_1 and q_2 = 0, so E = empty).

No up/down symmetry case:
In this situation, we cannot reuse M so that Z_mj contains the same value of -z and z because the image is undefined for z < 0. So while Z_mj will contain values evaluated using the same function rho_k, the domain is z >= 0, which means the calculation for Z_mj needs to be done explicitly. Fortunately, because we don't need to calculate a forward Abel transform on rho_k for Z_mj (see difference between the expressions for X_ki and Z_mj in Eq 12), this additional calculation is quick.
The new A and B in this case are given by
vert_left = inv(Mc_vert.T.dot(Mc_vert) + E_vert).dot(Mc_vert.T)
horz_right = M_horz.dot(inv(M_horz.T.dot(M_horz) + E_horz))
Once we have A and B, the image reconstruction is identical.

Regarding @rth's concern

I mean, the fact that Mc_vert has a shape (n_vert, nbf_vert) with basis functions in the vertical direction, does this means that different rows are somehow coupled during the transform?

This is directly addressed in the next paragraph of the paper (Pg. 2636), where the authors state that the two transformations (matrix A and B) are completely independent, and work on the raw data matrix P independently. Because of the way the three matrices A, P, and B are multiplied to calculate the matrix of coefficients C (Eq 13 in the clipped image above), every row (and essentially every pixel) of P sees a single, uncorrelated element from A and from B. The rows are therefore calculated independently; in fact, I am pretty sure that if the rows were not independent, you couldn't write P = XCZ
Hope this helped clear things up!
P.S. The linear algebra is also pretty confusing to me, but I think I managed to work it out explicitly for a small 5 by 5 image by hand it seemed to work.

@rth I'm still working on squashing the n and nbf are tuples bug and vectorizing the inner loops, so let's not merge the PR just yet.

@DhrubajyotiDas Thank you for this very extensive explanations! I understand it better now.
I think when we do the documentation, we should include your comment above in the technical subsection of the BASEX algorithm, as this is the first real connexion we have between the Python (or Matlab) code and the Dribinksi et al. paper. So this would be very useful for someone who would want to understand how the BASEX implementation works (in particular with respect to the basis set generation). Thanks again for your comment.

@DhrubajyotiDas, Thanks for this detailed analysis of the BASEX algorithm! I feel like I almost understand what's going on now!
It would be great if you could include some comments in the code to indicate which sections of the code are performing which equations in the paper. Also, if the variables can be renamed in order to offer better agreement with the paper, I think that we should do this. There is nothing sacred about the current variable names – in general, we just adopted whatever the authors of the original matlab code used – and I suspect that they were working quickly and not giving much thought to code readability.
Maybe a crazy thought, but, if we have the asymmetric transform, is there any reason to keep the symmetric transform? If the user wants a symmetric transform, it seems like we could just average the top and bottom half of the image, and pass the averaged half-image to the asymmetric BASEX algorithm. I would expect that it would run even faster since it would, for example, be performing the transform on a 500x1000 image instead of the full 1000x1000 pixel image. More importantly, there is a lot of duplicated code between the symmetric and asymmetric transforms, and it would be nice to keep just one well-documented basis set generation function.
A few more features we can think about implementing:

Is it possible to enable BASEX to run on just one horizontal part of an image? I expect that some users will just have one side of an image, and all of the other algorithms can handle this, except for BASEX, which would require that we

Can we implement the forward Abel transform using BASEX? Now that @DhrubajyotiDas has a good handle on the linear algebra, this should be reasonably straightforward, as the same basis sets should be used for both the forward and the inverse transform, correct?

Are we any closer to figuring out how to use basis functions that are larger than a pixel? Intuitively, this seems possible, and highly desirable when the data contains only broad features, since it would tend to eliminate high-frequency noise.

Thanks again for your great work on this!
Merry Christmas everyone!

In relation to item 2), IMO the naming convention:
fabel_<implemenation> : forward transform (when defined)
 iabel_<implemenation> : inverse implementation (when defined)
is now somewhat redundant in light of the inverse parameter  inverse=False/True) used in <direct> and <hansenlaw> code.  For HL it results in 6 functions (4 wrapper functions, and the 2 actual), which IMO, unnecessarily obfuscates the code, reducing user comprehension of the algorithm.
I would like to suggest that we now drop the f/i-prefix and just pass the boolean parameter inverse?

@DanHickstein Regarding your comment:

Maybe a crazy thought, but, if we have the asymmetric transform, is there any reason to keep the symmetric transform?

I agree, the asymmetric transform is a superset of the symmetric transform, and averaging the top and bottom halves of the given image and performing an asymmetric transform on that ought to be equivalent to performing a symmetric transform on the entire image. I have yet to verify this explicitly, but if it turns out to be true (and I believe it will), we should be able to condense a lot of the code into a single approach. I think a cleaner way to handle this would be to open a new PR for these after the changes in this PR have been merged, just to keep the git history clean.
Regarding the speed-up in transforming an averaged half-image versus a full-image, I don't think there will be that much of an impact during the actual inversions, since those are just matrix multiplications and are very fast as it is. The basis-set generation will be (slightly) faster, but most of the computational time is spent on calculating the horizontal functions (related to the horizontal width of the image), which will be the same between the half and full images.

Is it possible to enable BASEX to run on just one horizontal part of an image?

This is definitely possible. I can think of two ways of doing this:
a) Generate basis sets from r = 0 to r = r_max and proceed as usual. This option would entail writing more code in the xxxx_basis.py file.
b) Mirror the input raw data to make a full horizontal slice from r = -r_max to r = r_max and proceed as usual. This option would entail a small modification to any preprocessing functions we use before sending stuff over to xxxx_basis.py functions.
My personal preference would be for Option b), mainly in the interests of maintaining code legibility. The basis set generation code is pretty esoteric as it is, and a new mechanism for dealing with half-images could be hard to digest.

Can we implement the forward Abel transform using BASEX?

I think the original Matlab script had the command to implement the forward transform using the calculated matrices. It's here in the current code
P = dot(dot(Mc,Ci),M.T) # This calculates the projection, which should recreate the original image
I haven't tested this to see if this actually recreates an image similar to the given raw_data. If it does, I think it would be very useful in testing the goodness of the transform.
Regarding calculating the forward transform directly from inverted raw_data, I don't think BASEX provides a direct method of calculating the forward Abel transform. However, one technique that I can think of is to do something analogous to what is currently happening (when the given raw_data is already forward transformed):

Currently in BASEX, we try to express the provided (forward transformed) raw_data as sums of basis functions.
These basis functions were calculated by forward transforming Gaussian-ish functions. BASEX provides a way to do these calculations.
Now, when we are provided with raw_data that has not been forward transformed (or in other words, the provided raw_data is similar to what is currently being output by BASEX), we could try to express this raw_data as sums of the Gaussian-ish functions.
We can then forward transform these Gaussian-ish functions according to the technique in BASEX to arrive at the desired forward transform of raw_data

I don't know yet how to do this, but I suspect it could be as simple as switching M and Mc in the code...

Are we any closer to figuring out how to use basis functions that are larger than a pixel?

I haven't had a chance to investigate this (traveling for the holidays), but I plan to look into this once I get back (early January). Hopefully then I'll finally be able to incorporate some of Roman's recommended changes to this PR and close this to work on the new stuff we have discussed so far, including the naming conventions that @stggh mentioned in his last comment.

Happy New Year everybody!

Also, just curious, do you see a way to vectorize the other double loop in that basis set calculation function (starting here)?

Well the Matlab basis set generation consisted of 3 loops. The inner one got vectorized in the current Python implementation. We might factorize one more, which would be much faster, although I'm not sure how easy that would be. I didn't see anything immediate when writing this a while back, but it might be worth getting back to it at some point later.
@DhrubajyotiDas Can we merge this PR then?

Yes, I think this PR can be merged now, and some of @DanHickstein's suggestions tackled with a separate PR.

Yes, a separate PR for the other changes is fine.
@DhrubajyotiDas, I leave it to you do push the "big green button"! :)

Huzzah!

"big green button"!
I have been driving github via the command line. I like the command line, but often git complains about my lack of git-knowledge. Is there another way?

There actually is/was a big green button that says Merge pull request.

I avoid the command line for the most part. I use the GitHub app on the Mac. Also, the web interface offers nice functionality for opening and merging pull requests.
@stggh may not see the big green button, since I don't think that he has write access to the repo.

@DanHickstein same here as far as command-line trepidation goes. I use the Sourcetree app on Windows, and it seems to get the job done, except for that weird merge issue I had a few weeks ago that @rth bailed me out from. I do like the functionality of the Github web-interface quite a bit.

For my part, I also do everything  git related in the command line. However, for merging pull requests on github I don't think there is another solution than pushing the "big green button" in the github web-interface (it just disappeared after this PR was merged)...


Only include original line info in stack trace when using source map

I don't think it's useful at all to list the compiled line number/column in stack traces, especially since it's displayed first before the original line number/column info from the source map.  Especially when using something like browserify, you get these horribly useless paths to look at.  For example:
at /var/folders/_p/kll4xqzn0hn9znq6607nr14m0000gn/T/a5fdf7b6ec86e5a5a2a6f44ed6234a6791e3a679.browserify:203:0 <- /Users/devongovett/projects/editor/node_modules/chai/lib/chai/assertion.js:110:0

This commit removes the compiled line information from stack traces and only displays the original line information.  The output of the above example would just be:
at /Users/devongovett/projects/editor/node_modules/chai/lib/chai/assertion.js:110:0

@devongovett I think the suggestion @aymericbeaumet made is a good one, would you be up to update this PR to the latest master and add a debug log message for the full details? That way people who need debugging details can see it and everyone else doesn't need to care about it. (Yes I know this is a late response :( )

Closing for now. Feel free to open a new PR updated to the latest master.


How can I set Samesite=None for Weblogic application?

How can I set Samasite=None for Weblogic application?

I wasn't able to find any documentation on Weblogic supporting the SameSite attribute for cookies at all.  There is this thread in the support forum. I would suggest commenting there or raising this with any support contacts you may have at Oracle.

After adding samesite= none same we application is not working in IE and microsoft edge please sir provide any solution for that

Document 2637652.1.pdf
Refer: Google Chrome 80 Changes and Cross-Site Request Forgery (CSRF) Concerns for Applications Deployed to Oracle Weblogic Server (Doc ID 2637652.1)


Revert "update django version specifier syntax"

This reverts commit be7fca6e436a42b0bc4ee0f5c005395c6deb901c.
The ~= requirement syntax isn't supported by older pip releases including but not limited to 1.5.4, see #1753 for further discussion.

Current coverage is 66.34% (diff: 100%)

Merging #1759 into master will not change coverage

@@             master      #1759   diff @@
==========================================
  Files            54         54
  Lines          6189       6189
  Methods           0          0
  Messages          0          0
  Branches       1222       1222
==========================================
  Hits           4106       4106
  Misses         1865       1865
  Partials        218        218

Powered by Codecov. Last update 89d21b7...929c513

Can we get older pip for distros we support in the Travis config?


[Bug] Re-introduced Date Range field's endDate hidden input use a date format that is different than the startDate (javascript)

Bug report
What I did
Updated to 4.1 and working with the date_range.blade.php field.
What I expected to happen
Date to be in the same format.
What happened
The endDate miss an H in its format, so the result differ from startDate and endDate and validation, and date casting with format throw errors.
What I've already tried to fix it
I updated the endDate format as the startDate format in fields/date_range.blade.php.
I created a branch and everything ready for a PR, but I re-search for an already issue and I found one. So I stop and change the narrative for letting the team know about this tiny issue.
@fakefakers already fix that in this commit : 3e8abeefef80a625d64ea6dc9de80747dde5e4d1 on april 1 2020. It's the commit on appril that return the tiny bug; if I follow the file history : https://github.com/Laravel-Backpack/CRUD/commits/master/src/resources/views/crud/fields/date_range.blade.php
After that, I'm out of clue, for what is the best way for fixing this kind of git history or juste remerging the fix ? I'll learn a lot from what you'll do :)
Anyhow, let me know what is the simplest way of fixing this ? A new PR or something. I'm not shure what is best for that kind of fix.
Note: The 4.2 branch have this issue too.
Backpack, Laravel, PHP, DB version
PHP VERSION:
PHP 7.4.13 (cli) (built: Nov 28 2020 06:24:27) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.13, Copyright (c), by Zend Technologies
LARAVEL VERSION:
v7.30.4@9dd38140dc2924daa1a020a3d7a45f9ceff03df3
BACKPACK VERSION:
4.1.30@62856b1f01fc3e05c80140fc22f85ea2aac8368c
Thanks in advance and have a good day :)

Hello @mamarmite thanks for the report.
Indeed, I think this slipped us. So sorry. The fix had been merged in 4.0.x branch, but was not carried over to 4.1. Dunno why exactly at the moment.
But it's a bug for sure, so if you are willing to send a PR for it, I will review and merge it asap. Send the PR to 4.1 branch (master).
If you don't have time or some other reason don't allow you to do it, just let me know and I can do it, no worries.
Best,
Pedro

Yes, np :) The PR was already added in github. I wasn't shure if that would be the good way of fixing this issue.
It's added : #3509.

Closed by PR #3509


dispatch to several index within one import batch

will elasticsearch-jdbc support the feature that customizing output like logstash?
here is an example.
doc1: {"id":1, "type":"a", "message": "blabla"}
doc2: {"id":2, "type":"b", "message": "blabla"}
if (type == a) {
//  index into index hot
}
else if (type == b) {
// index into index cold.
}。
and similar operation uopn type.

You can send
doc1: {"_id":1, "_index":"a", "message": "blabla"}
doc2: {"_id":2, "_index":"b", "message": "blabla"}

to index into a or b

Does it mean the value of _index will override that one inside configuration files？
Is this a feature of your project or of es index api? I just scaned over es reference and didn't find it.
Thanks～

With SQL pseudo columns of _index, _type, and _id in JDBC importer SQL statement, you can address where the ES document should be indexed.
They are translated to index/type/id in the ES indexing API.


Not able to connect to sponge server behind BungeeCord proxy

It's not able to connect to a sponge server which is behind a BungeeCord proxy. The sponge server does not give out any information of a try of connection to the server.

The devs would probably need more information to figure this out.

Any error messages, including the disconnect message
The Forge, Sponge, and BungeeCord versions

please move this to common

There are no error-messages, the player simply does not connect to the server. The bungeecord-proxy says, that the player connected but also shows that he disconnected in the next message. There are no logs at the sponge server.
Sponge-Version: sponge-1.8-1487-2.1DEV-523
BungeeCord-Version: Build 1076

this issue occurs in both implementations please re-open it in the common repo


Quick search does not retain search term when moving to view

Notice the term isn't carried over to the view:

Created a PR https://github.com/microsoft/vscode/pull/234368
Hoping it gets accepted:)


Jesse: Watch cairbos(?#sites.google)

Jesse requests the watch of the watch_keyword cairbos(?#sites.google). See the MS search here and the Stack Exchange search in text, in URLs, and in code.

cairbos(?#sites.google) has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jeff Schaller in Charcoal HQ


control flow blocks with local assignments should not be rewritten as postfix expressions

Using syntax_tree v1.1.0. Rewriting the following code:
n = 1

if (b = n+1) > 1
  puts b
end

is rewritten as:
n = 1

puts b if (b = n + 1) > 1

which will cause an "undefined local variable or method" NameError exception to be raised.

Fixed by 802d6476065f03a3eb11f5171c0c00a15008fcb2 and will be out in 1.1.1


run sourcery with multiple configurations

Resolves #727
When yaml contains "configurations" root key then we try to parse it as array of configurations and run sourcery for each of them. In watch mode we will observe all paths from all configurations.

[x] Haven't tested that on a real config yet but based on code we run in main don't see why it wouldn't work.
[x] After successful test will update documentation for configuration as well.

@krzysztofzablocki I've tested this on my actual project and it woks well, also updated the docs, so it's ready for review.

          1 Error

:no_entry_sign:
Any changes to library code need a summary in the Changelog.

  Generated by :no_entry_sign: Danger

👌


OutputDir in vcxproj files

The default "Output Directory" for the generated vcxproj is "$(SolutionDir)$(Configuration)".
IMHO it is wrong because you may want multiple solutions referencing the same project files while keeping the binaries in the same directory.
I would put instead "$(ProjectDir)$(Configuration)".
Anyway, I tried to change it in several ways with no luck:

I could not find a way to override that value using .props or .vsprops files
I tried the --build-dir command line with no luck

Is there any other workaround to impose the desired Output Directory?
Thanks!

maybe cc/ @refack

Currently it's hardcoded https://github.com/nodejs/node-gyp/blob/master/gyp/pylib/gyp/generator/msvs.py#L1421
We can discuss a patch to GYP, but I would like to understand the use case better 🤔

Isn't that just a hardcoded default? Can OutputDirectory be set in binding.gyp under msvs_configuration_attributes?

@refack I believe the use-case is quite common.
Gyp generates the folder with the project, solution and binaries, therefore I need to avoid to put there anything that is hand-made, otherwise it can be lost.
The advantages in having another solution are many:

Add a number of new projects, with no sources but just nodejs.exe as a target, with different command lines to ease debugging. Having these empty projects + the real project in the same solution is convenient to immediately find the sources and trigger the recompilation if needed
A variant of the previous point is when you need to add electron as the debugging target
Adding external libraries that are used from the project described in Gyp.

Basically I just need to have one or more custom solution files, that may be kept outside the directory structure that will be deleted/re-created by Gyp, but without moving the binaries which is disturbing because of any other relative path management or post-build actions you run.
Said that, it would be nice to specify the "Output Directory" directly in the gyp file so that anyone can get control over it. This way you may leave the default to the current value to avoid breaking any existing code.
Thanks

@richardlau Could you please provide me a link with the msvs_configuration_attributes documentation?
Even if it looks like it cannot be used for my purpose (Output Directory is hadcoded) it may be useful for other options.
Thanks

Could you please provide me a link with the msvs_configuration_attributes documentation?

The docs are not-amazing, but not completely useless 🤷♂  https://gyp.gsrc.io/docs/LanguageSpecification.md#Generated-Visual-Studio-vcproj-Files

@refack I already read that page but I have no clue on how customize that part.
Reading many threads in the Issues I tried to use the props and vsprops files with no luck at all.
Others tried to customize the Output Directory before me without success. Since the props and vsprops files are applied in a specific order, I guess my customizations gets overriden by the vcxproj itself.
Anyway, if you can provide working samples of gyp files, I would be more than happy to give a try.
thank you

Anyway, if you can provide working samples of gyp files, I would be more than happy to give a try.

One of GYP's test manipulates OutputDirectory — https://github.com/refack/GYP/blob/master/test/builddir/src/builddir.gypi
To run the following (fill in the ) to:
set PYTHONPATH=<GYP_DIR>\test\lib
set PRESERVE=1
set PYTHONUNBUFFERED=1
set TESTGYP_FORMAT=msvs
set GYP_BUILD_TOOL=<PATH_TO_VS>\MSBuild\15.0\Bin\MSBuild.exe
cd <GYP_DIR>
python.exe test/builddir/gyptest-default.py

Now, I'm not sure how well this works for node-gyp but worth a try

@raffaeler I don't have any links; I just read the gyp source that @refack posted.
A quick Google search throws up https://github.com/haywire/haywire/blob/master/common.gypi as an example. I won't be able to test on a development box until Monday.

@refack @richardlau
I guess I am missing something basic, because I tried both the samples you posted (specifying a gypi file with an include in my gyp) but every time I run node-gyp configure and node-gyp rebuild I always see the Output Directory se to $(SolutionDir)$(Configuration)\

Now, I'm not sure how well this works for node-gyp but worth a try

I guess I am missing something basic, because I tried both the samples you posted (specifying a gypi file with an include in my gyp) but every time I run node-gyp configure and node-gyp rebuild I always see the Output Directory se to $(SolutionDir)$(Configuration)\

So node-gyp is a wrapper around GYP and I was afraid it might override the options in the .gyp files. I think the "offending" point is https://github.com/nodejs/node-gyp/blob/master/lib/configure.js#L308

So node-gyp is a wrapper around GYP and I was afraid it might override the options in the .gyp files. I think the "offending" point is https://github.com/nodejs/node-gyp/blob/master/lib/configure.js#L308

@refack The link specifies the "build" directory where the vcxproj and sln files are created.
My request is different. I need to change the Output Directory written inside the vcxproj file.
From @richardlau link I understood that my binding.gyp file can specify the include directive referencing a gypi file.
But I still can't get the msvs_configuration_attributes working. The syntax to override the Output Directory in not clear too (what does this mean: '<(DEPTH)\\builddir/Default' ?).

@raffaeler try adding this to your targets (or try to add a 'target_defaults': { } section)
      'msvs_configuration_attributes': {
        'OutputDirectory': '$(ProjectDir)$(Configuration)',
      }

I got the follwing in the vcxproj files:
  <PropertyGroup>
    <ExecutablePath>$(ExecutablePath);$(MSBuildProjectDirectory)\..\bin\;$(MSBuildProjectDirectory)\..\bin\</ExecutablePath>
    <IgnoreImportLibrary>true</IgnoreImportLibrary>
    <IntDir>$(Configuration)\obj\$(ProjectName)\</IntDir>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Release|x64'">false</LinkIncremental>
    <LinkIncremental Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</LinkIncremental>
    <OutDir>$(ProjectDir)$(Configuration)\</OutDir>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetExt Condition="'$(Configuration)|$(Platform)'=='Release|x64'">.node</TargetExt>
    <TargetName>$(ProjectName)</TargetName>
    <TargetPath>$(OutDir)\$(ProjectName).node</TargetPath>
  </PropertyGroup>

I played a little bit, best results come with:
{
  "target_defaults": {
      "msvs_configuration_attributes": {
        "OutputDirectory": "$(MSBuildProjectName)\\$(Configuration)"
      }
  },
  "targets": {
    "..."
  }
}

@refack Thank you, it worked!
I didn't know the msvs_configuration_attributes could be added to the config.gyp target :)
And I don't get why it did not work inside the gypi included file
The docs definitely need a lot of work :) :)

@raffaeler glad I could help.
Generally this issue should have gone to either to https://groups.google.com/forum/#!forum/gyp-developer or to https://github.com/nodejs/help/issues/.
I'm closing this issue, feel free to reopen if you find any followup problems with node-gyp itself.


chef hostsfile

Hi,
In the context of an arcgis enterprise upgrade on windows - does chef utilise the hostsfile deployed on the system - C:\Windows\System32\Drivers\etc\hosts
Or does it require its own hostsfile be populated?
I am keen to QA our upgrades by using the hostsfile (retaining the production DNS).

Hey @drobinson13
Chef can make a host update if designated within the roles file.
We will need to access the roles file being utilized and in the "arcgis" segment, we will need to include "hosts" , bracket, hostname inclusion, and an empty quote (empty quotes = local IP).  Please check the example below:
"arcgis":{
"run_as_user":"usernamethings",
"run_as_password":"passwordthings",
"version":"10.7.1",
"hosts":{
"trevor.test.com": ""
}
We will want to make sure that within the run_list we have "recipe[arcgis-enterprise::system]" in there as the system cookbook is what kicks off the /etc/hosts file manipulation.

Changes to C:\Windows\System32\Drivers\etc\hosts make the system-wide effect. They definitely can have affect  ArcGIS Enterprise upgrades with Chef.
For ArcGIS Enterprise deployment in certain cases we use hosts file to alias certain host and domain names, for example:

Use fixed alias like FILESERVER instead of actual file server machine hostname or IP address, so the file server machine can be easily replaced/recovered without other configuration changes.
Loop back the load balancer's domain name to the local IP address to shorten the loop and to prevent chicken-egg sort of problems with the load balancer's health checks.

Closing since original question was addressed.


[typespec-python] tspconfig basic-setup-py: false option still generates setup.py

In the Schema Registry setup.py, there is an extras_require option which we would like to keep. When re-generating from tsp, this setup.py is overwritten. I tried adding setup-basic-py: false to the tspconfig options here: https://github.com/Azure/azure-rest-api-specs/blob/b8a35f3d6c033d9cd51b12e15d1e788edd0bca46/specification/schemaregistry/SchemaRegistry/tspconfig.yaml#L21
However, the setup.py is still being overwritten. I can't find any docs on this, but is this the correct way to make sure the setup.py is not overwritten?

Hi @swathipil, it is better to permit emitter to overwrite the setup.py since new emitter can help update dependency (e.g. azure-core) for new feature to make the SDK work. Do you want to avoid the overwrite because of PACKAGE_PPRINT_NAME change. If that, you can set package-pprint-name: "Schema Registry" in tspconfig.yaml.

Hi @msyyc - I wanted to avoid this so that I can include a package in the extras_require section. Is there another way to add this?

Python don't support partially update for setup.py for now. And we will discuss about it.
@lmazuel @iscai-msft for awareness

closing because we've switched our design


Speedup CI

Description

Improved runtime of "Download Mainnet Mirror" from 5~8 Min to 1.5 Min. Renamed it from a less descriptive "Git Clone" name
Fixed caching.
Stop triggering CI on pushes, which caused duplicate runs. We want to run upon any PR, regardless of the target branch. Fixed.

Checklist

[x] Commit sequence broadly makes sense
[x] Commits have useful messages
[x] New tests are added if needed and existing tests are updated
[x] Any changes are noted in the changelog
[x] Code is formatted with fourmolu (which can be run with scripts/fourmolize.sh
[x] Self-reviewed the diff

Does this fix #3037?

Does this fix https://github.com/input-output-hk/cardano-ledger/issues/3037?

No this is unrelated. I have no idea how to depend one run on another. So, killing one run depending when another one for the same trigger is present, seems like an impossible task for me with GithubActions. However, Github Actions surprised me in positive ways many times before and I might be totally wrong on this.


Incorrect average calculation in luci/view/admin_status/bandwidth.htm

The calculation of the bandwidth average incorrectly weights the current value as 1/2 the average instead of 1/Nth the average.  The average should be calculated by adding all values in the 3 minute window, then at end of loop dividing by the number of values
bandwidth.htm.diff.txt

Merged, thanks!


DVector::resize - mem.is_locked() is true

Windows 8
Godot 2.1.1-stable & Godot 2.1.2-stable
Running the game gives following error

Sometimes after a few minutes, sometimes after an hour.
I am not really sure how to reproduce this, as it seems pretty random when it occurs. I can also confirm that this isn't happening on Ubuntu 16.04 as it is my daily OS.
Some quotes from IRC that might be helpfull (thanks to kitkat_):

<kitkat_> multithreading shenanigans
<kitkat_> SSE2 maybe? (since windows 8 needs SSE2)

<kitkat_> godot\core\dvector.h line 365
<kitkat_> It means the program is trying to resize the vector while another thread has locked it

So, I managed to reproduce the bug both on windows an linux, the problem is in the HTTPClient ( https://github.com/godotengine/godot/blob/2.1/core/io/http_client.cpp#L580 ) and is NOT related to threads (actually, using threads in the requests does not trigger the bug).
The reason is that when not using threads the request is done in non-blocking mode, so it fetch partial data.
If the data fetched is not complete (would block) he tries to resize the DVector (which is locked by the Write).
I'll give it another look tomorrow, in the meantime, here is the backrace:
#0  DVector<unsigned char>::resize (this=0x7fffffffd4c0, p_size=3817) at core/dvector.h:365
#1  0x00000000018993cf in HTTPClient::read_response_body_chunk (this=0x380d810) at core/io/http_client.cpp:580
#2  0x0000000000e0bd9e in HTTPRequest::_update_connection (this=0x38105a0) at scene/main/http_request.cpp:403
#3  0x0000000000e0d0e8 in HTTPRequest::_notification (this=0x38105a0, p_what=17) at scene/main/http_request.cpp:466
#4  0x0000000000e0fb1e in HTTPRequest::_notificationv (this=0x38105a0, p_notification=17, p_reversed=false) at scene/main/http_request.h:39
#5  0x0000000001790726 in Object::notification (this=0x38105a0, p_notification=17, p_reversed=false) at core/object.cpp:908
#6  0x0000000000dd33d1 in SceneTree::_notify_group_pause (this=0x37f2fc0, p_group=..., p_notification=17) at scene/main/scene_main_loop.cpp:900
#7  0x0000000000dd1822 in SceneTree::idle (this=0x37f2fc0, p_time=0.0170409996) at scene/main/scene_main_loop.cpp:528
#8  0x000000000042f41b in Main::iteration () at main/main.cpp:1604
#9  0x0000000000410a0f in OS_X11::run (this=0x7fffffffdb00) at platform/x11/os_x11.cpp:1934
#10 0x0000000000408755 in main (argc=3, argv=0x7fffffffdff8) at platform/x11/godot_x11.cpp:41

closing as fixed by #7749/#7750


Update Node.gitignore

I have been using this .gitignore file for many months, although I realized everytime I have to custom add for the config files and in config files every one of your private details is saved, So, I just added it to this file. Thanks & Regards!
Reasons for making this change:

TODO
Links to documentation supporting these rule changes:
TODO
If this is a new template:

Link to application or project’s homepage: TODO

Hi I am newbie .
Can someone help me out making my first contribution ?


Include GA for build and deploy with Minikube

Resolves: #9

It seems that this is not valid due to the lack of TPM2, and a solution based on: https://github.com/keylime/keylime-vagrant-ansible-tpm-emulator seems to be ongoing


Upload newest version of Polish 4.0 BY translation

See email from Natalia

http://rob.tech.creativecommons.uk0.bigv.io/cc4_0_polishversion_htmlfinal/


Sodium only renders models from smartleaves resourcepack in current chunk

Mods:
cullleaves-2.2.0.jar
fabric-api-0.36.0+1.17.jar
indium-1.0.0.jar
sodium-fabric-mc1.17.1-0.3.0+build.5.jar
Vanilla

Sodium * graphics settings ended up being a bit different but regardless of options this behaviour is present

this is more obvious when you are on top of a tree that passes into a new chunk on the XYZ as the backface will not show for chunks outside of the one you are in.

this does not happen with other model-based resource packs, your own https://www.curseforge.com/minecraft/texture-packs/motschens-better-leaves seems to renders fine with sodium as expected.

turns out this affects all models in sodium.

solved. sodium 0.3 was missing the ability to disable BlockFaceCulling.


Add project as a FAB

The Add project bottom tab should be a floating action button instead, therefore also removing the need of any tab bar at all.

Both would work. Why should the FAB be preferred over swiping?

Because FABs are used for creating things, per Material Design guidelines and behaviour of many other apps (consistency!).
I didn't know it swiped though, bottom tabs shouldn't swipe at all.

Fair enough.

Solve in #155 BTW use lambdas, don't kill cats 😄

#155 merged. Closing issue.


to_json/from_json

This is a backwards compatibility break
Simplifies the BinaryQuadraticModel.to_json method to always return a string. We also remove a lot of boilerplate used to encode bqms with low memory footprint. That case will be covered by #235 .
We will also close #218 as redundant. In order to prevent having too many serialization methods, we don't include to_dict/from_dict.

@wbernoudy @randomir
For from_json the default pattern is
bqm = BinaryQuadraticModel.from_json(json_string)

But I left in the
with open('file', 'r') as fp:
    bqm = BinaryQuadraticModel.from_json(fp)

pattern. because it doesn't really change the behaviour. It looks a bit odd though with the new to_json. Thoughts?

Codecov Report

Merging #236 into master will decrease coverage by 0.05%.
The diff coverage is 89.47%.

@@            Coverage Diff             @@
##           master     #236      +/-   ##
==========================================
- Coverage    93.4%   93.35%   -0.06%
==========================================
  Files          30       30
  Lines        1804     1790      -14
==========================================
- Hits         1685     1671      -14
  Misses        119      119

Impacted Files
Coverage Δ

dimod/binary_quadratic_model.py
98.67% <75%> (-0.01%)
:arrow_down:

dimod/io/json.py
91.52% <91.17%> (-1.44%)
:arrow_down:

Continue to review full report at Codecov.

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

Re: to/from_dict, I would actually prefer to keep those to vanilla to/from_json, because they are a more general form. Once you have dict of standard objects, it's easy to store that in many other formats (i.e. you get json/bson/yaml/pickle/mongo/postgresql/mysql/redis/memcache/etc adapters with oneliners). I don't mind having performant, specialized converters in addition (as we do), but there's value in providing general base format.


Misinterpreted/missing feature?

Line 936 of the primary list mentions the ability to press tab to comment out specific URLs.
However, I'm personally unable to get this to work. I'm unsure if there's something I'm missing, or if this was merely an internal dev comment that should be ignored. If it's intended to be a user-accessible feature and I'm simply not understanding how to utilize it, could a tutorial be added to the readme? If it's meant to be a dev comment and otherwise ignored, could that be clarified?

Hey!
I originally created this list on pastebin, but then was asked to implement a subscription alternative here on GitHub. Before it became a subscription, initially you would copy & paste the text into your uBlock Origin's filter list, which would then allow you to individually tab-out (comment out) different url's that you didn't want blocked.
That line was an artifact from bringing it over to GitHub (and i forgor about it 💀)
Now with this different implementation, you have to do it a different way.
For uBlockOrigin:

Toggle the DOM inspector </> through uBlock Origin's logger.
Locate the url you want to whitelist.
Click on the filter you want to disable (eg. vecteezy.com); it should be crossed out.
Then press the save icon, then the "Create" button.

Boom! Now it's whitelisted!
Or, if you don't want to go through that mumbo-jumbo, add this line in your filter list: www.google.com#@#a[href*="example.com"]:upward(div):style(opacity:0.00!important;)
Change "example.com" to the url you want to whitelist. Copy & paste that in uBlock Origin's "My filters" list, and you're set!
For uBlacklist:

Enter uBlacklist's options panel.
In the text box, add this line in the text box: @://.example.com/*
Change "example.com" to a website you want whitelisted.
Click save. Done!

Sorry for the hassle, and hope this works well for you! Cheers!

Ah, I see, and that explains it. The curse of copy, paste, forgor is a devious one 😔
I do appreciate the explanation!

Hi again! I added a section in the readme 12d763b523d2d8f07714744771a155754cc523dd that explains how to whitelist sites in both uBlock Origin & uBlacklist (so you don't have to reference this issue anymore). Going to close this issue since it is resolved. Have a good day! <3


Xgboost pyspark: Support external memory mode

Xgboost pyspark: Support external memory mode

Bump - what are the plans to support that? Right now it seems like total memory allocated across all executors must fit the whole dataset. It would be much more practical to have ability to have datasets larger than memory available still be processable with PySpark's XGB implementation.

That's a drawback of gradient boosting trees with Newton method, unlike DL, one cannot train the model in small batches. External memory is still in an exploratory phrase where we try to optimize as much as possible.


HDR on ChimeraOS

I just watched this video by Fan the Deck, which is about HDR implemented by Valve for Linux.
I remember looking out for this a year ago when I bought a new monitor & tv, but sadly foundoutits not supported.
Now this issue can track all related stuff with implementation in ChimeraOS.
See these reddit postfrom r/linux & r/linux-gaming:

https://www.reddit.com/r/linux_gaming/comments/odibda/what_is_the_current_state_of_hdr_on_linux/
https://www.reddit.com/r/linux/comments/ks8er5/does_anyone_have_any_news_of_hdr_on_linux/
https://www.reddit.com/r/linux_gaming/comments/jao7jj/state_of_hdr_on_linux_october_2020/

Awesome! It just worked using your version!

Nope i did not see any issues, or are those hard to recognize? Nothing obvious yet...

Which games?
Rx6600
R5 1600x

Seems Joshua still does downstream kernel work for the HDR stuff. https://gitlab.freedesktop.org/JoshuaAshton/linux-hdr/-/commits/josh-hdr-colorimetry

After todays update it finally works again :)


Add backwards compatibility tests for automation

Add backwards compatibility tests for the plugin to automate end-to-end upgrade paths for faster releases. Developer documentation for implementing bwc tests and hooking them to CI: https://github.com/opensearch-project/opensearch-plugins/blob/main/TESTING.md#backwards-compatibility-testing

Initial backwards compatibility tests have been added and hooked into CI. Closing this issue.


prefix function names ?

Is it possible to prefix the generated function names ?
something like:
elementOpen to {prefix}elementOpen
The use case is, I want to have a global IncrementalDom object, instead of importing it in each module, and then set the prefix to 'IncrementalDom.' so it will transform jsx to:
IncrementalDom.elementOpen (and all the other element*).

We were actually waiting for plugin options so we could support arbitrary prefixes, but I'm not sure when Babel will support it. I think @jayphelps was going to work on adding IncrementalDOM. to all the function calls in the meantime.

Done, just add the extra options when using babel:
{
  "blacklist": ["react"],
  "plugins": ["incremental-dom"],
  "extra": {
    "incremental-dom": {
      "prefix": "IncrementalDOM"
    }
  }
}


Box requires a specific claim

Box expects http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name claim as emailAttribute which is required in SAML SSO. The claim is mapped to user.userprincipalname by default. So users may need to change it to user.mail in the configuration.
It would be helpful if this is mentioned like the doc for G Suite.

Your Google Cloud (G Suite) Connector application expects the SAML assertions in a specific format, which requires you to add custom attribute mappings to your SAML token attributes configuration. The following screenshot shows an example for this. The default value of Unique User Identifier is user.userprincipalname but Google Cloud (G Suite) Connector expects this to be mapped with the user's email address. For that you can use user.mail attribute from the list or use the appropriate attribute value based on your organization configuration.

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

ID: 9a6d67a1-eade-6bdd-ab13-744a7c351c53
Version Independent ID: 9c1bce95-5f19-6175-7df6-a1e26368704f
Content: Tutorial: Azure Active Directory single sign-on (SSO) integration with Box
Content Source: articles/active-directory/saas-apps/box-tutorial.md
Service: active-directory
Sub-service: saas-app-tutorial
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@tomatsue Thank you for your feedback . We will investigate and update the thread.

@tomatsue Thank you for your feedback . We will investigate and update the thread.

@v-hagamp This is a good feedback. Can you please update the article and mention that claim can be changed as needed. The example given above is good and we can use the same in this document.

@v-hagamp This is a good feedback. Can you please update the article and mention that claim can be changed as needed. The example given above is good and we can use the same in this document.

Closes MicrosoftDocs/azure-docs#69168

Closes MicrosoftDocs/azure-docs#69168

@tomatsue This document has been updated as per suggestions and the changes should be live in the next 48 ours maximum as per the next release cycle.
Thank you.

@tomatsue This document has been updated as per suggestions and the changes should be live in the next 48 ours maximum as per the next release cycle.
Thank you.


Blueprints Not Loading

Experiencing issues? Check our Troubleshooting FAQ wiki!
Describe the Bug
Blueprints not Load. I can't use it
Screenshots

Logs
FactoryGame.log

You need to put the blueprints under a directory with the name of your session, that's how the game stores them. Create a blueprint in-game, it'll create the directory for you.

True sorry

You need to put the blueprints under a directory with the name of your session, that's how the game stores them. Create a blueprint in-game, it'll create the directory for you.

No

And i have created one.


Futures 0.1.1 docs not showing up

It looks like the latest version of the futures crate (0.1.1) is not showing up: https://docs.rs/futures

Thanks for reporting. It is fixed now.
I think this issue is related to this human error. Build queue kinda messed up for crates uploaded on 10-11 September.
I am leaving this issue open to investigate crates that uploaded on 10-11 September.

Well looks like docs.rs skipped one more crate: winrt-0.1.0.
I believe docs.rs is failing to populate build queue correctly. It is working fine for the most of the time (we detected only one crate have been skipped), but it should never skip any crate.

With #77 docs.rs should not skip anything anymore. Closing this for now.


Overhaul library database for ML and other analysis procedures

I kind of backed us into a corner with the way the library database is set up because it is all clean processed spectra. Many machine learning procedures would benefit from the use of unclean spectra in the library and some matching procedures might perform better too. It could also be that we want to allow people to propose a "better cleaned" version of the library spectra in the app. We would need to have the raw spectra loaded somewhere in the app to pull that off. Thinking about a new library structure which has Raw_Spectra, Clean_Spectra, Sample_ID, and Peak_Number columns. If we rewrite some of the code we can get around the current need to have a peaks only version of the library (which is creating some duplication of data), by having the peak number only correspond to the peak locations and put NA where there is no peak. It would be nice if we could then create a tool in Open Specy where people can adjust the "Clean_Spectra" values for the matches by reprocessing the "Raw_Spectra" column.  The adjustments would be sent to MongoDB and we would need to review them. I also want to add the preprocessing parameters we used from Open Specy to clean the spectra into the metadata. The metadata view right now is pretty bad when there is too much metadata. Perhaps we can add some onhover information or something else for the metadata so that the metadata doesn't bleed across the screen.

[x] Create new library format.
[ ] Integrate into shiny app and function workflows in app.
[ ] Improve metadata display when there is a lot of metadata.
[ ] Develop a user cleaning tool for users to clean the database.
[ ] Integrate a mongodb alert system.

I think this has been resolved, we can resurrect if needed.


Segmentation creation app

Based on the existing puzzle pieces already used in DataSet.restrict, a new app should allow drawing of multiple polygons in combination with the selection of a filter per polygon using the filter selection app.

After today's meeting it was decided that the creation of segmentations is deferred to external tools. The app should only map segments to pipelines - making use of existing segment classifications.


Amount: Introduce operator overloads

Fixes #1824 in the process.
Some usages of mustSub / mustAdd were replaced by if / assert(0) as this is just a refactoring.
The assert should be eliminated in the future.
This should also be useful for improving fee calculation.

The ddoc should be updated.
https://github.com/bosagora/agora/blob/009b7e1e3707b5da2ba3add8de8e18f3bda5b714/source/agora/common/Amount.d#L9

Fixed DDOC


Ensure the cli reads the weights file correctly

If the model is small, it's possible that the buffers for the model and weights are stored in a single underlying ArrayBuffer, so when we access this with Buffer.buffer we incorrectly read the text of the JSON model as it's own weights.

That works for my case! However, I'm not sure that this will work in all cases, since you're still accessing the underlying buffer without checking it's bounds - will creating a new object here always create a fresh buffer?

Yes, provided it's Uint8Array. Buffer is supposedly a subclass but slice() is different.
https://nodejs.org/api/buffer.html#buffer_buffers_and_typedarrays
In particular
Passing a Buffer to a TypedArray constructor will copy the Buffers contents, interpreted as an array of integers, and not as a byte sequence of the target type.

I think this is resolved