Range extension thunks

We are considering three use cases here.

A true large code model needs to support more than 2 GiB of text; data accesses are out of scope for this change but jumps and calls across a range of more than 2 GiB are needed.  Most users of a large model will have more than 2 GiB of data but small text, or text with a highly local call pattern, so we want most calls to be able to use the auipc+jalr sequence.  This would normally call for relaxation, but relaxation requires object files to contain the longest possible sequence, of which several are possible.  Instead, keep the sequences the same and allow thunk insertion.

For executables and shared objects in a Unix environment, most of the code size benefits of relaxation come from call->jal relaxation, not data or TLS relaxation.  If the compiler is modified to generate jal instructions instead of call instructions, the code size benefits can be achieved without relaxation at all, but this requires JAL_THUNK to avoid relocation errors at a 1 MiB limit.

If a function has many static call sites in a large binary but is known to be dynamically cold, due to a function attribute or PGO, the call sites can be replaced with jal instructions, sharing a single thunk between all call sites within a 2 MiB text region.  This saves code size at small runtime cost.

Restricting the register usage of the thunks is an intentional feature copied from the Go 1.15 toolchain, where every non-leaf function requires a conditional call to runtime.morestack in the prologue; since ra cannot be saved before the stack frame is allocated, the call is performed using t0 as the return register.

There's an argument to be made that we can use thunks for JAL, CALL, and CALL_PLT because linking would fail otherwise.  I'd rather not accept the risk of breakage with that.  There's also an argument that CALL_PLT is always allowed to use a PLT, and PLT stubs clobber t1 and t2 even with STO_RISCV_VARIANT_CC, so substituting CALL_THUNK for CALL_PLT is always fine.  I'm more sympathetic to that, but we need JAL_PLT for 2/3 use cases so why not add both.
I don't have a working PoC or a schedule for preparing a working PoC.  As this is my first time on this side of the current process, what level of functional completeness are we looking for?  Do I need to cover all three use cases or would it be enough to have a working clang -mshort-calls and lld combination and results showing a binary size decrease?
Recommend using CALL_THUNK for #388, FDPIC, and any other new code models or sub-ABIs.

For executables and shared objects in a Unix environment, most of the code size benefits of relaxation come from call->jal relaxation, not data or TLS relaxation. If the compiler is modified to generate jal instructions instead of call instructions, the code size benefits can be achieved without relaxation at all, but this requires JAL_THUNK to avoid relocation errors at a 1 MiB limit.

This seems out of scope to me, as it is a solution in search of a problem.  Also, we need to support functions that are >1 MiB in size--something we do poorly currently, but we will need to get better at.  That would require JAL thunks to be interspersed within a function, which sounds undesirably messy.
So, I'd focus on the large code model motivation.  (The dynamically cold call site optimization is also interesting, and though it also has problems with >1 MiB functions, that's OK, because it's purely opportunistic.)

PLT stubs clobber t1 and t2 even with STO_RISCV_VARIANT_CC

PLT stubs clobber t1 and t3 unconditionally (I don't know why that was picked in the first place, but hey, that's what we've got). Without STO_RISCV_VARIANT_CC and -z now / LD_BIND_NOW the header also clobbers t0 and t2, but of course the resolver then clobbers some arbitrary subset of the caller-saved register set.

but we need JAL_PLT for 2/3 use cases so why not add both.

Because that eats precious relocation encoding space for something that does nothing new. We've already got the wastage from CALL+CALL_PLT, we don't need to add yet another relocation that implementations will treat identically to the other two. RV64 has enough space that one should never run out, but RV32 is very constrained.

This change would significantly diverge the RISC-V psABI from the psABIs of other RISC processors. Other psABIs do not distinguish range-extendable CALL relocation and the usual one. The linker automatically takes care of everything and creates range extension thunks as needed. (2) and (3) can be implemented without making a modification to the psABI, too. So I don't see a reason to add new relocations.

@aswaterman

This seems out of scope to me, as it is a solution in search of a problem.

Are you saying that code size / speed tradeoffs in general are out of scope (what about Zcmt?), or are you making a narrower point that I'm failing to see?
My current thought for the prototype is
-mshort-calls=never   don't use short calls
-mshort-calls=cold    if [[gnu::cold]] is present
-mshort-calls=always  if function/section size is less than 2 MiB

That would require JAL thunks to be interspersed within a function, which sounds undesirably messy.

The compiler knows how large the function/section is and can switch to AUIPC+JALR if external references would struggle to reach outside it, it needs to do this anyway for internal references and I've done it before (there was function larger than 1 MiB in the Go test suite).
I don't intend for the linker to ever insert bytes in the middle of an input section.

So, I'd focus on the large code model motivation. (The dynamically cold call site optimization is also interesting, and though it also has problems with >1 MiB functions, that's OK, because it's purely opportunistic.)

Unfortunately, the large code model isn't close to done, so I can't do much with it without taking over a much larger project.  Likewise I am not confident in my ability to get PGO working on a nontrivial project.  So short calls on the basis of a command line option / attribute are the most likely thing I'll be able to have an end to end demonstration of in a reasonable length of time.
@jrtc27

PLT stubs clobber t1 and t3 unconditionally

Good catch.  Unfortunately, we need t2 as one of our registers for future Zicfilp support (range extension thunks are software-guarded branches), whether or not Zicfilp modifies the PLT stub to use t2.

we don't need to add yet another relocation that implementations will treat identically to the other two

I'll drop CALL_THUNK then.  It potentially turns link failures into runtime undefined behavior if anyone is using CALL_PLT for DSO-local functions with a custom calling convention that uses t2, which won't affect -msave-restore but is anyone doing interprocedural register allocation?
@rui314

So I don't see a reason to add new relocations.

To be clear, you want to drop both CALL_THUNK and JAL_THUNK, and add range extension thunk semantics for CALL, CALL_PLT, and JAL?
I think at a minimum we'd need a clear statement that R_RISCV_JAL within a single section over less than a 1 MiB range will never generate a thunk.

Are you saying that code size / speed tradeoffs in general are out of scope (what about Zcmt?), or are you making a narrower point that I'm failing to see?

Not at all!  My point was that motivation (2) is unconvincing unless you assume a fictitious universe in which linker relaxation does not exist.  But, as I wrote, (1) is a sufficient motivation for this idea, and (3) is an interesting direction.  I'm not pooh-poohing the idea; I'm just trying to help hone it.

To be clear, you want to drop both CALL_THUNK and JAL_THUNK, and add range extension thunk semantics for CALL, CALL_PLT, and JAL?

Only CALL (and CALL_PLT as it's a synonym for CALL) would require a range extension thunk, as that's the only relocation in this ABI to call a function that may be at an arbitrary memory address.
Essentially, I don't think you need to invent something new for RISC-V for range extension thunks. We can instead just do what other RISC psABIs do. As a reference, this is what AArch64 psABI do for range extension thunks: https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aaelf64/aaelf64.rst#L1281

Take 2, now with a better description of use case 2 and with the requested feature of "surprise ABI breaks for currently working code".
There are at least three ways to get current gcc or clang to expect t2 to be valid across a call:

clang -mllvm=-enable-ipra calls to a non-interposable function which does not use t2
clang uses t2 for the ninth actual argument of a dso_local function which is converted to fastcc
GCC nested functions called by name (not a pointer) use t2 as the static chain
it is unclear if MachineFunctionSplitter or BasicBlockSections can be enabled in any effective way

What is the path forward for these? Do we change them to not use t2 and retroactively declare old compilers buggy? Do we add a new mechanism for compilers to communicate which registers they expect to live across a call? Do we do nothing, and call it user error to create a binary which exceeds 2 GiB of text when using the medlow/medany code models?

It looks much better, but I think we need to first answer that question: do we need range extension thunks for RISC-V?
Other RISC psABIs required range extension thunks because, without them, they couldn't support a medium code model of 2 GiB binary size. They use only a single instruction for function calls, and therefore the "reach" of function call instructions is limited (typically equal to or less than ±128 MiB). On the other hand, they use longer code sequences for data access, so range extenders are not needed for data loads and stores.
In other words, other RISC-V psABI required range extension thunks to bridge the discrepancy between code and data references's reaches. To build binaries larger than 2 GiB, we usually need to build them with the large code model in the first place so that data references can refer to a location beyond ±2 GiB.
The RISC-V's medium code model doesn't have the above-mentioned issue because both code and data references can address ±2 GiB. That means the situation in which range extension thunks are useful is very limited; they're useful only when we have code scattered across more than a 2 GiB address range while all data references are within 2 GiB from the code location. There might be a program that fits into that use case, but I honestly think it would be very rare.

do we need range extension thunks for RISC-V?

No.
It's an optimization, albeit an important one that will be painful to retrofit if it isn't considered early.

That means the situation in which range extension thunks are useful is very limited; they're useful only when we have code scattered across more than a 2 GiB address range while all data references are within 2 GiB from the code location.

That's the situation in which range extension thunks are present. They are useful precisely when they are absent: less than 2 GiB of relatively contiguous code, and data scattered across the address space. I expect this to represent the majority of uses of large models.
If we want to close the call performance gap between the medium and large models, we need to either define relaxations to turn a 64-bit-range call into a 32-bit-range call and then use them on every call in every input object, or define range extension thunks and not use them.
I think that the latter option is better for several reasons:

Between non-PIC, PIC, FDPIC, different options for intermediate range, etc there are a substantial number of plausible long call sequences. We would need to add relaxation semantics for all of them. By contrast, the semantics of thunks are agnostic of the details of the call sequence.
Relaxation requires linker work in the common case when the short call is generated. Thunks require linker work in the rare case when the long call must be generated.
Thunks use the short sequence in object files, so they are smaller.
Fully relaxing a long call which uses a literal island requires deleting bytes in two independent places, an unprecedented situation for relaxation.
Thunks have secondary uses for binary size optimization which are difficult to

All of the bullet points appear to be hypothetical and not validated by any actual experience or implementation. Utilizing a long code sequence with a full 64-bit offset for a function call and allowing the linker to relax it would be a logical expansion for the RISC-V large code model, as that's what we are doing for the medium code model.
Moreover, the linker relaxation and range extension thunks are independent. The linker is permitted to insert range extension thunks into a program, even with the current psABI, as long as it doesn't violate the ABI's assumptions (i.e., as long as range extension thunks preserve registers just like to how PLT entries do). Therefore, I believe defining range extension thunks at this moment is not absolutely necessary. To me, it appears that this proposal is too early to be ratified.

I would also favor relaxation from the hypothetical large code model to the current regime as the default approach, given that we already have the relaxation arrow in our quiver.
It’s clear to me that consideration (3) from Stef’s original proposal could bear some fruit.

All of the bullet points appear to be hypothetical and not validated by any actual experience or implementation.

https://review.gerrithub.io/c/riscv/riscv-go/+/352852/5

The linker is permitted to insert range extension thunks into a program, even with the current psABI, as long as it doesn't violate the ABI's assumptions (i.e., as long as range extension thunks preserve registers just like PLT entries do).

Do you consider it a bug that LLVM treats t3/X28 as preserved by call instructions for the purposes of ipra and fastcc, despite the fact that PLT entries clobber t3?
When Zicfilp happens, "PLT entries" for address not taken functions without a landing pad will need to be changed to use t2/X7 for software-guarded branch reasons. Does this mean that t2 will be removed from the list of registers preserved across a CALL_PLT? Does this mean that the register used for LLVM trampoline intrinsics and GCC nested functions will have to change to something else?
(What external constraint is responsible for Zicfilp using X7 instead of X6 in spite of the ABI problems this causes?)

I guess it depends. ipra and fastcc doesn't follow the calling convention defined by this psABI, so I'd think they are implementation-defined optimizations.

ipra and fastcc opt out of the calling convention, but they don't opt out of the relocation scheme, and LLVM generates normal relocatable files with nothing to prevent them from being consumed by a third-party linker that implements the psABI exactly. So I don't think that "it's implementation-defined" is a blanket license to ignore relocation rules.

That needs to be address in the Zicflip spec, no?

Are you advocating changing the draft Zicfilp spec from using t2 to using t1 for compatibility with the ratified ABI, or advocating for Zicfilp to define a new ABI that reserves t2 in PLT stubs?

FYI, I think...we should reconsider Zicfilp should use t1 rather than t2 for the landing pad label register https://github.com/riscv/riscv-cfi/issues/208


[BUG/QUESTION] Chunk Queue Fires After Delay In Between Each Queue

Package version, Laravel version
5.4
Expected behaviour
Queue should fire off with 3-4 seconds in between each queue.
Actual behaviour
Only 1 queue fires per minute
I know it's not the queue, because I did a test queue which fires off instantly.

Another thing... for the chunk, only

php artisan queue:work

seems to work

php artisan queue:listen

wouldn't.

There's a huge gap between each queue call. Is this a bug or actual behavior? I'm chunking 2000 for with only 1 email column from a csv file (about 30,000)

It means the job takes long to process. You could try using smaller chunks, that should make the execution time of each chunk shorter. But it's possibly a limitation of the parent package PHPExcel.


cks: fix token TTL, set it to never expire

Description
Fixes #4742
kubeadm init is called with --token-ttl 0
This will allow the token to remain valid forever.

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[x] Minor
[ ] Trivial

Screenshots (if appropriate):
How Has This Been Tested?

Checked token details after k8s cluster deployment;
Container Linux by CoreOS stable (2303.3.0)
Update Strategy: No Reboots
core@t2-master ~ $ sudo kubadm token list
sudo: kubadm: command not found
core@t2-master ~ $ sudo kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
00dec2.178dc8478dbecfc5   <forever>   <never>                authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token
ul9g7i.jl1ehlghm8apx634   1h          2021-03-03T12:03:15Z   <none>                   Proxy for managing TTL for the kubeadm-certs secret        <none>

Explicitly set the base branch to 4.14 in case 4.14.2 is released in future.
@blueorangutan package

@shwstppr a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✖centos8 ✔debian. JID-2860

@blueorangutan test

@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

Trillian test result (tid-3646)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 32954 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4747-t3646-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_internal_lb.py
Intermittent failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
Smoke tests completed. 81 look OK, 2 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_04_rvpc_internallb_haproxy_stats_on_all_interfaces
Error
190.60
test_internal_lb.py

test_01_migrate_VM_and_root_volume
Error
60.69
test_vm_life_cycle.py

test_02_migrate_VM_with_two_data_disks
Error
48.77
test_vm_life_cycle.py

Packaging result: :heavy_check_mark: centos7 :heavy_multiplication_x: centos8 :heavy_check_mark: debian. SL-JID 49


Bug: Focus at SDK 3.2.0 doesn't show

Hi,
When you add the "debug": true on the settings.json, now the Focus (that tells you where the focus is) is not there anymore on the console as was on the previous versions.

I have seem that the problem is on src/application/Application.mjs at line 142, the one which get the focus that this code has been removed from the previous:
if (this.__options.debug) {
   console.log('FOCUS ' + newFocusedComponent.getLocationString());
}

So I guess that retrieving it...


Extract annotations into its separate package

We currently have annotations (comments) implementation into JupyterCAD https://github.com/QuantStack/jupytercad/tree/main/src/annotation. This should be moved into another package so that it can be reused in other extensions (Notebook, GlueLab etc). A potential place to put this could be https://github.com/jupyterlab/jupyter_collaboration

After internal discussions, we agreed that https://github.com/jupyterlab/jupyter_collaboration would be the right place for this.


forgot cloudfunctions.googleapis.com

Don't forget to enable cloud functions

Thank you very much for your contribution.


Buidling for iOS Simulator, but linking in object file for iOS

Summary
Created similar issue 4 months ago, this has been blocking development of our maps feature since
Added react-native-maps to my project and never manged to get it working in Simulator.
Whenever I run a debug build from Xcode I get
error build: Building for iOS Simulator, but linking in object file built for iOS, file '/Users/shashawa/Documents/projects/myapp/ios/Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.framework/GoogleMaps' for architecture arm64

Reproducible sample code
no code involved

Steps to reproduce
Just follow the instructions to add the library to an iOS project, with the following setup
System:
    OS: macOS 12.6
    CPU: (8) arm64 Apple M1 Pro
    Memory: 206.11 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.6.0 - ~/.asdf/installs/nodejs/18.6.0/bin/node
    Yarn: 1.22.19 - ~/.asdf/shims/yarn
    npm: 9.1.1 - ~/.asdf/plugins/nodejs/shims/npm
    Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
  Managers:
    CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 16.0, macOS 12.3, tvOS 16.0, watchOS 9.0
    Android SDK:
      API Levels: 23, 29, 30, 31, 33
      Build Tools: 29.0.2, 29.0.3, 30.0.2, 30.0.3, 31.0.0, 33.0.0
      System Images: android-29 | Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play ARM 64 v8a, android-29 | Google Play Intel x86 Atom, android-30 | Google APIs ARM 64 v8a, android-30 | Google Play ARM 64 v8a
      Android NDK: Not Found
  IDEs:
    Android Studio: 2021.3 AI-213.7172.25.2113.9014738
    Xcode: 14.0/14A309 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.13 - /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.0.0 => 18.0.0
    react-native: ^0.69.0 => 0.69.7
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
    ```

### Expected result

I expect builds to succeed on Xcode for debug builds on Simulator

### Actual result

Building for iOS Simulator, but linking in object file built for iOS, file '/Users/shashawa/Documents/projects/myapp/ios/Pods/GoogleMaps/Maps/Frameworks/GoogleMaps.framework/GoogleMaps' for architecture arm64

### React Native Maps Version

    "react-native-maps": "^1.3.2",

### What platforms are you seeing the problem on?

iOS (Google Maps)

### React Native Version

0.69.7

### What version of Expo are you using?

Not using Expo

### Device(s)

Simulator

### Additional information

_No response_

This seems like an arm issue. Checkout v.1.4.0. If it doesn't fix your issue, feel free to open another issue :)

Same problem, with react-native-maps 1.7.1, any solution ?


feat: add file output for TypeScript generator

Description
This PR adds file output for the TypeScript generator.
Related issue(s)
Fixes #399

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

11 of 11 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 93.22%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
2309

Relevant Lines:
2359

💛  - Coveralls

Blocked by #557

I really hate windows and Linux differences.......... 🙄
tsc --downlevelIteration -t es5 ${path.resolve(renderOutputPath, './*.ts')} works fine in linux... However, windows only works with tsc --downlevelIteration -t es5 --baseUrl ${renderOutputPath}....

Thanks @magicmatatjahu !


Add compat section to Project.toml

#1
@matbesancon should I add anything more to compat ? There are other external dependencies as of now.

hard to tell like this, we should activate travis for this project to be sure it is correct as-is.
@abhinavmehndiratta what do you mean by "external dependencies"?, not on the Project.toml?

@abhinavmehndiratta what do you mean by "external dependencies"?, not on the Project.toml?

I meant there are no other packages outside the standard library that I use, except BinaryProvider.

we should activate travis for this project to be sure it is correct as-is.

So, I should start writing tests and add .travis.yml file ?

Ok, I don't think other deps are needed in the Project then. Yes you need a
.travis.yml file, then we can activate the repo on Travis and we'll get a
nice badge (hopefully green)
On Mon, Jun 10, 2019, 06:42 Abhinav Mehndiratta<EMAIL_ADDRESS>wrote:

@abhinavmehndiratta https://github.com/abhinavmehndiratta what do you
mean by "external dependencies"?, not on the Project.toml?
I meant there are no other packages outside the standard library that I
use, except BinaryProvider.
we should activate travis for this project to be sure it is correct as-is.
So, I should start writing tests and add .travis.yml file ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/abhinavmehndiratta/SuiteSparseGraphBLAS.jl/pull/2?email_source=notifications&email_token=AB2FDMT32JJE3KJYN3AV4XLPZXLVFA5CNFSM4HWMGOWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXI5COQ#issuecomment-500289850,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2FDMTJAV3NAVNVKBU2N6LPZXLVFANCNFSM4HWMGOWA
.

Ok, I don't think other deps are needed in the Project then. Yes you need a .travis.yml file, then we can activate the repo on Travis and we'll get a nice badge (hopefully green)

Okay thanks !


[ZFSPV] blog on ZFSPV snapshot and clone

Blog has been published : https://blog.mayadata.io/openebs/snapshot-and-clone-for-zfs-localpv


Field onBlur's newValue and previousValue are always identical

Are you submitting a bug report or a feature request?
Bug report.
Previously reported and closed in #2618 for lack of a test case.
What is the current behavior?
The onBlur event of <Field> states that it comes with newValue and previousValue:
http://redux-form.com/6.7.0/docs/api/Field.md/#-onblur-event-newvalue-previousvalue-void-optional-
In testing, newValue and previousValue always appear to be identical.
See https://codesandbox.io/s/Rgn6BVQxq for a simple test case reproducing the issue. newValue and previousValue are logged to the console.
What is the expected behavior?
That previousValue contain the value the component had when we entered the field.
Sandbox Link
https://codesandbox.io/s/Rgn6BVQxq (based on the SimpleForm sandbox)
What's your environment?
Redux Form 6.7.0
MacOS/Chrome 59

This is very interesting. It's not so much a bug as a misunderstanding. I can totally understand why one would expect "that previousValue contain the value the component had when we entered the field'. What it's giving you is the previous value before onBlur was called, which is whatever is in the field from the onChange calls. We are currently not storing the "value on focus" anywhere, but perhaps we could in the future...

Hm, that does actually make more sense now that I think about it. Thanks for the quick clarification :)
What would be your recommended approach to work around this for now? (Custom component hooking into onFocus and accessing that value in onBlur?)

If you don't need the Redux value to update in realtime on every keystroke, you could not pass onChange, and then it would work as you presumed earlier.

I may be missing something, but if I omit onChange doesn't the field become read-only?
React suggests setting defaultValue={value} on the field in that case, but then I think I lose the ability for reset/initialize on the form to change the value of the field.
(Note to self: c.f. https://github.com/erikras/redux-form/issues/1835)

Because this issue saw almost no activity for a few months, I'm closing it.


Multiple guards are first-come, first-serve

This is just a documentation request. The page on multiple guards implies that they are followed in sequence and first-come, first-serve:

For example, you can model a door that listens for an OPEN event, goes to the 'opened' state if you are an admin, or goes to the 'closed.error' state if alert-ing is true, or goes to the 'closed.idle' state otherwise.

Might be helpful to make an explicit mention of this in the docs

I'm open to accepting a PR for this 🙏


HTTPS on Claim Uri

URI for Claim windowsaccountname had HTTPS instead of HTTP

Thanks for fixing! We had a bulk change a few months ago that inadvertently changed this. You'll see the fix live today.


Remove AsyncFileWriter in Armeria backend

AsyncFileWriter could be replaced with Armeria's StreamMessages.writeTo().
Refer to https://github.com/line/armeria/pull/3874 for details.
Before submitting pull request:

[x] Check if the project compiles by running sbt compile
[x] Verify docs compilation by running sbt compileDocs
[x] Check if tests pass by running sbt test
[x] Format code by running sbt scalafmt

I see some NPEs in tests for ArmeriaFutureHttpTest could you check it ?

Great, thanks !


Django 1.8 support?

I really want to use this package in my project, and I'm also hoping to use django 1.8 since this is a new project and 1.8 is the next LTS release due out in just a few days.
I get errors like this when trying to create a TranslatableModel in my app:
https://dpaste.de/oc54
Also, I noticed that the django.template.loader.find_template() function used in parler.template should be replaced with django.template.loader.get_template() for 1.8.
This will probably be where the problem is coming from:
https://docs.djangoproject.com/en/dev/ref/models/meta/#migrating-from-the-old-api

FYI the snippet you pasted has expired. Can you repost it without an expiry time?

+1 to this, 1.8 support would be awesome.

There's more to it than just the template system, seems like the app&model loading also doesn't make Django 1.8 loader very happy.

The latest github code has Django 1.8 support. Everything seems to work fine in the runserver, but tests still fail. If anyone could look into that, I'd be delighted!

Correct that, code has been fixed to run in 1.8 too!

\o/

Thanks :D

And.. 1.4 has just been uploaded to PyPI! :D


Kifu mode repeated move numbers not respecting --first-move-number

          sorry, another bug...

When doing something like this:
for m in {50,100,150}; do sgf-render input.sgf -o move-$m.svg --move-numbers --node $m --first-move-number $(( $m - 49 )); done
The annotations at the bottom box keep the original move numbering in the sgf, and not the --first-move-number change.
Originally posted by @AprilInParis in https://github.com/julianandrews/sgf-render/issues/29#issuecomment-1963026144

I think the actual args need --kifu instead of --move-numbers since the repeated move annotations only render in kifu mode.
Given that --first-move-number starts the count at 1, this is pretty clearly a bug, and should be fixed by having the repeated move box use the same numbering as on the board.
I do think that there's a second subtle "bug" here in that right now there's no way to render moves with their actual move number but only start the labeling at a specific number. This merits more thought, and probably a little bit of a reshuffle of the rendering logic, but in the immediate, I'm content to just fix the numbering in the repeated moves box.

This should be fixed in abafd29. Now to put out a new release!

Digging in a little more, this is clearly related to #24. I think the proposed changes there still make sense, but in the short term, this bug fix is good.


MbxHeading component

MbxHeading will just style some text. The class list they apply will be short but valuable — with txt-fancy and some media-query-based sizing.
How about a variant property with primary, secondary, tertiary, and minor styles that correspond to these established patterns:

You end up wrapping your MbxHeading tag with a semantic heading element, when appropriate, e.g.
<MbxHeading variant="primary">Primary heading</MbxHeading>


Review and prepare GIS files for Shrewsbury.

Emma found discrepancies between zoning map provided by Shrewsbury and GIS map online

Can you describe the nature and extent of the discrepancies? Are there missing/extra districts, or do the district polygons not match the static map? How extensive are any mismatches?


find all ibm-odf services and delete old one

Signed-off-by: 662962756<EMAIL_ADDRESS>

 multistorage - change operator reconcile to delete old objects (service / serviceMonitor / deployment) according to prefix + kind + label odf=storage.ibm.com + add new label for future releases


how about some rigor behind the primary_locales, bozo?

note to self: use a real, sourced metric for determining the primary_locales for each timezone, and then document that metric. some options:

most populous of the "canonical" locale(s) in the official tzdb list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
the one or two canonical locales in each offset with the most internet users

determining the number of primary locales for each offset is something else I need to put some rigor behind. some potential criteria to use:

always one locale, unless the offset spans multiple hemispheres or continents, then one from each hemisphere or continent (minus antarctica)
one from each large political entity, meaured by either population or internet users, in the event two similar-sized, large political entities make up the majority of the population in each offset (e.g., baghdad and moscow)
one from each large political entity, again meaured by either population or internet users, in the event there is a political conflict between the two political entities that might cause users in either entity to be unwilling or unable to select an offset only represented by a locale in the other entity.

yikes, sounds like I'm about to charter the EU or something, this sucks. timezones suck.

worth noting: the only reason for having primary_locales in the first place is for user clarity. reading [+0800] Pacific Time (America/Los_Angeles) generally makes most users' choice easier than if they were just reading [+0800] Pacific Time.
but if this whole thing turns into a giant can of worms, I dunno, maybe we could drop it. or, tell people "tough crackers, if you don't like a certain primary_locale just don't show it.

"


[RFC] convert to pass-by-reference intrinsics + remove intrinsics unit tests

This RFC proposes three things:

Change all type 2 intrinsics (see definition below) throughout the project to use a pass-by-reference, in/out parameter style

Update all of the APIs (including the extended APIs) to use the new style of intrinsics

Delete all of the intrinsics unit tests

Background
All of Bareflank's intrinsics that access a data structure of some kind (MSRs, control registers, page table entries, etc) all follow the same basic pattern. For each accessor (get, set, enable, disable, etc), there is a "type 1" function to access the data structure directly, and a "type 2" function to access a representation of the data structure in memory. For example:

Type 1 accessor:

inline void enable()
{ _write_msr(addr, set_bit(_read_msr(addr), from)); }

Type 2 accessor:

inline auto enable(value_type msr)
{ return set_bit(msr, from); }

This RFC concerns type 2 accessors only. Currently, all of the type 2 accessors take arguments by-value, and then return a new value that contains the result after the modification. This works great for all of the intrinsics that we have currently, because every data structure we have an intrinsic for is 64-bits or less in size. Looking into the future (VT-d support), there are some data structures on the Intel platform that are larger than 64 bits in size. For example, VT-d interrupt remapping entries are 128 bits in size, and posted interrupt descriptors are 512 bits. While the current pass-by-value style will technically work, it would make more sense in these cases to pass values by reference, and then modify those values directly in the style of "in/out" parameters. For example:
inline void enable(value_type &msr)
{ msr = set_bit(msr, from); }

Reasons for this proposal
For item 1, the type 2 intrinsics are all so similar that this transformation can be scripted (I'm confident that I already have a working solution for that part).
For item 2, most of intrinsics that are actually called by the base hypervisor and extended APIs are the type 1 kind. There are only maybe a few dozen calls to the type 2 intrinsics, so not much to update there.
For item 3, every unit test for the intrinsics would need to be manually rewritten to support the new style. But beyond that, I propose that we get rid of all these unit tests anyways because they aren't all that useful in my opinion. For example, consider the following test case:
TEST_CASE("ia32_platform_id_platform_id")
{
    using namespace intel_x64::msrs::ia32_platform_id;

    g_msrs[addr] = 0xFFFFFFFFFFFFFFFFULL;
    CHECK(platform_id::get() == (platform_id::mask >> platform_id::from));
    CHECK(platform_id::get(platform_id::mask) == (platform_id::mask >> platform_id::from));
}

This test case uses the internals of the implementation to verify the behavior of each function. In the above two checks, if a developer gets the values wrong for platform_id::mask and platform_id::from, the unit test will still pass. Furthermore, the file that test case came from (test_msrs.cpp) is nearly 10,000 lines long, containing mostly this exact same test case duplicated for every msr. I feel that this adds unnecessary complexity and SLOC to the project with no real value, and therefore should be removed. If desired, we could also mark the bfintrinsics directory as excluded from codecov.

I like the looks of this! What tests exactly will be removed? All the .cpp under bfintrinsics/tests?

Yeah, I would only consider getting rid of the tests in bfintrinsics as
they really don't provide any value (they are just bit masks). The rest of
the logic actually tests things that could end up buggy and should stay /
be expanded upon.
On Thu, May 24, 2018 at 12:02 PM, Connor Davis<EMAIL_ADDRESS>wrote:

Nope I think those are good to go. The other tests that are somewhat
intrinsic-y are the vmcs check tests, but they are under bfvmm, and they
actually do worthwhile tests.
👍
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Bareflank/hypervisor/issues/675#issuecomment-391768977,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFqD47RjcCgqvMRhDxj4SCeD2ECeap9Nks5t1tmCgaJpZM4ULRB3
.

See #676


AGALMiniAssembler doesn't support array vc lookup

The following is valid AGAL
vc[va1.x].x
This works in the adobe version of AGALMiniAssembler and is a really useful feature for things like highly dynamic particle systems. Any idea who ported this code and why they decided to leave it out?
It looks like it would be done in the emitSource function, however doesn't look to be complete.

Looks like it's an issue with this regex
var indexed = getGroupMatches (~/vc[(v[tcai])(\d+).([xyzw])([+-]\d+)?](.[xyzw]{1,4})?/i, token, 5);
If I pass in:
vc[vt1.w].xyz
I would expect to get an array of
["vc[vt1.w].xyz", "vt", "1", "w", "vc", ".xyz"]
however the last two strings are not present
["vc[vt1.w].xyz", "vt", "1", "w"]
Anyone know their regular expressions?

The expression isn't correct, the first [ should be escaped, could that be the issue?

Hi Pete,
I started digging into your issue, and found that our AGALMiniAssembler did not resemble the Adobe version very much. This was probably due to the old Stage3D implementation, which did not rely upon AGAL byte code, but source code.
Since we have a byte code-based new implementation, there's no reason for AGALMiniAssembler to be different from the original version. I just ported it from ActionScript, and it appears to be working fine in all of my tests
https://github.com/openfl/openfl/commit/1e37e00dde8589b82492fc5a1cbb7710a3c2c4fd
I'm going to close this (because I assume this is all resolved) but let me know if there are any regressions with the new assembler port :smile:

Oh awesome... I was wondering why it was so different to the Adobe version. Thanks for looking into this.


No way to provide port number for "Network Printer" in web interface

When adding a printer from the web interface, the "Network Printer" device doesn't allow specification of a port number.

[master 03b7b13] Fix port number user input when adding a printer (Issue #360)
[v1.4.x 3f1c329] Fix port number user input when adding a printer (Issue #360)


Custom Player for Google IMA Ads

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
v4.2.3
Please ask your question
Hi! How do I create a custom Ad Player without using IMA ADs SDK? I see that it creates an Iframe source and then manually creates an overlay with video element interacting with our Shaka's AdManager. I plan to create a similar Ad Player like this which loads VAST Ads. However, I dont understand is there some parser script that we load or if provided externally who provides us the parsed VSAT Data and itself triggers the tracking events? I expect my custom AdPlayer to always load video files and present a static layout as shown below.
Kindly help with this, In case there are any examples or references please drop that will be really helpful.

If you want to handle client-side ads yourself, or integrate with another ads SDK, you can do that on top of Shaka Player.  Here are some tips:

When it's time for an ad, you can pause the main video and overlay another video element for the ad.
If you can't have multiple video elements for some reason:

capture the main video's currentTime and the player's getAssetUri()
call player.detach() to ask it to detach from the video element
load ad content in the video element
wait for the ad to complete
await player.attach(videoElement) to reattach to the video element
await player.load(assetUri, previousVideoTime) to resume playback at the previous position

Does this help?

Thanks for your response. However my current plan is to create two different video elements and toggle between them. I definitely understand the plan you shared above, Thanks again. Can you help in letting me know,

How do I parse VAST XML file recieved without using the IMA Ads SDK Script or any other (since they are generally iFrame loaded, which I definitely don't prefer to use). Is there any open source library sort of thing available out there, which can do this for us?
Commonly who is handling the ad events/trackers (ad-complete)? Should we do that ourself or some XYZ Script loaded externally should do this?

It would be great if you could please answer these as well.

Hi @joeyparrish Is there any update on this? Humbly waiting for your response.

Understood, Thanks a lot. Will be happy to drop updates for reference for other in case I find one.


InPas proof of concept

Before we implement InPas execution workflow, we want to do the following:

Tool testing
Run InPAS to see if it works with our test data
Is it running in a reasonable amount of time? Any bugs/blockers?
List the steps to run from preprocessing to final output
What are the challenges (identification, quantification, differential) it qualifies for based on the output files?
Screenshots of output files, what are the columns to be extracted for the challenges?
What are the files to be post-processed for the challenges?
Any specific packages and versions to install?

Update the execution workflow summary table with relevant findings

Estimate: 1d
Parent issue: https://github.com/iRNA-COSI/APAeval/issues/249

InPAS needs R version 4.2
InPAS package be installed from Bioconductor: https://bioconductor.org/packages/release/bioc/html/InPAS.html
They provided a vignette to show how InPAS is used to get results: https://github.com/jianhong/InPAS/blob/master/vignettes/InPAS.Rmd

I first tried to run the vignette locally. I was unable to run the script as is and had to do a few tweaks to it so I'm attaching my version of the vignette here.
The vignette consists of the following steps:

Set up a SQLite database
Extract 3'UTR annotation. The resulting utr3_anno table from this step looks like this:

Reformat coverage data. This results in coverage qc table
Identify potential polyadenylation sites using cleanUpdTseq package. The final output is CPsites table below:

Predicted_Distal_APA and Predicted_Proximal_APA are two columns containing coordinates of distal and proximal APA sites for identification challenge
Estimate usage of proximal and distal CP sites. The two tables from this step are utr3_cds_cov and eSet:

Identify differential PDUI events. The final output is the filter_out table below:

In this example, the table contains 1 row and 34 columns
This output can be used to qualify for differential output challenge by taking the transcript and P.Value columns

@SamBryce-Smith @yuukiiwa @ninsch3000 @mrgazzara @dominikburri I looked into this more and tried running InPAS with our test data. Found the following:

InPAS takes in two conditions

Doesn't take in a given annotation. Requires BSgenome, TxDB, and EnsDB R packages for the specified species

Runs one chromosome at a time. E.g.

Meaning we would have to run it multiple times for each chromosome and then add a postprocessing step in the workflow to combine the the outputs.

There are PDUI values provided in the very last output, but these are per condition if i understand the output correctly. E.g.

When I tried running with the same sample file for the two groups, which we have done for other tools that also only take two groups, I get errors and the script doesn't run properly

I've attached the two scripts I did for using different conditions (srsf3 and control) for differential, and another script in attempt to get identification and quantification outputs by using the same sample file for the two groups.
InPAS_with_APAeval_test_data_differential.pdf
InPAS_with_APAeval_test_data_identification_quantification.pdf
Since I think it doesn't qualify for identification and quantification per sample but qualifies for differential, I'm good with closing InPAS related issues since it's not a priority now.
What do you guys think?

Put it on hold. :)

Closing this and other InPAS related issues for now!


Removing grpcio-channelz

Looks like the grpcio-channelz package has been breaking CI. Since this package isnt even used anywhere since the streamz days, we should remove it.

@gpucibot merge


ceph: 12.2.7->13.2.4

Motivation for this change
This upgrades ceph to the latest version. Closes #42830.
There are caveats:

The dashboard is not included. This seems to be in line with other distributions, upstream master has a less byzantine build system for it coming.
The package builds its own boost, I couldn't get it to locate ours.
I ended up making changes to generic.nix that probably would break ceph 12, and I didn't see a reason to maintain several simultaneous versions, so I merged it with default.nix (in it's own commit).

Additionally I added a client output containing just enough to manage rbd mounts (modelled on debian's ceph-common) and fixed some permission and path stuff in the module (see commit).
Ping @nh2, @wkennington, @adev, @ak3n.
Things done

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

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

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

cc @lejonet if you're still Ceph-knowledgeable. :)

I've gone through the PR and see no shenaningans you haven't addressed. I fully agree with the name changes on the variables in the service module and thank you for removing the mgr requirement that I have forgotten to fix with a PR of my own (@srhb and I have talked about that one before, it was a naive assumption from my part when making the module, because I was only testing single node configuration).
I'd ofc also like an answer of the extraUsers vs users, because from my understanding, they should be the same and equivalent to each other but I never found any docs telling which should be preferred, which is why I chose the ones without extra.

I'm putting a wip on this. Just discovered that ceph-volume has disappeared from the output, and I bet some people find that tool useful.

Outstanding issues:

Check that things that depend on ceph still work after the changes to all-packages
Rebase on master/unstable (and remove the extraneous argparse dep)
?

@krav Do you want to address the points above, or would you rather one of lejonet or I do it? :) I don't want to force push to this branch without your go-ahead.

@krav Do you want to address the points above, or would you rather one of lejonet or I do it? :) I don't want to force push to this branch without your go-ahead.

@srhb I'm easily confused by git, but I've rebased and squashed now.
Regarding your first point, what things other things depend on Ceph and need checking?

@krav Hm, looks like nothing by default. There's a bunch of things that has it as an optional dependency, but we don't have any relevant tests for that.
@lejonet has done extensive testing and thinks we're good.
Status: I know of just one problem left, and that's the dashboard module failing to get the version from cherrypy. I suspect it does not in fact get launched with the correct python env, but I need to actually investigate this.
Surprisingly, due to the way the release tarball is made, we're fine on the frontend side, so it really is just the dashboard backend being broken.

This (sledgehammer) appears to work, but I'd really prefer to figure out why cherrypy reports a wrong version, but only in the (weird?) ceph env.
https://github.com/srhb/nixpkgs/commit/ef3a3807f75719f26563128e0bce5dc1b0afe64f

This (sledgehammer) appears to work, but I'd really prefer to figure out why cherrypy reports a wrong version, but only in the (weird?) ceph env.
srhb@ef3a380

I will see if I can get some digging done on it tonight, I agree with you that even if that sledgehammer works, it feels appropriate to find the root cause of it. So that we can fix the actual problem instead of hiding the symptoms.

guys, @lejonet: any news on this?

I sadly was hit with a lot of real life so I haven't been able to do more digging than we did at this time, @srhb might have done more but iirc theu also were hit with real life

@srhb @lejonet I finally managed to get some time at work allocated for ceph. Where do you suggest I start? I guess we might just jump directly to Ceph 14 now, but question is whether we should try and get this PR merged first thing?

While I personally would prefer to have Nautilus, Mimic is an LTS release, so there's an argument to be made for focusing on getting that working instead.

@lordcirth Oh.. I thought Nautilus was LTS. Appently not. In that case, I agree with you.

@lordcirth Oh.. I thought Nautilus was LTS. Appently not. In that case, I agree with you.
Yes, it's noted here in the .0 changelogs:

http://docs.ceph.com/docs/master/releases/nautilus/#v14-2-0-nautilus
http://docs.ceph.com/docs/master/releases/mimic/#v13-2-0-mimic

I've spent some time in testing this PR out and it builds issue, but then I haven't tried a real setup and I stopped looking into this ....I was trying to understand if that problem with the dashboard is still there but I'm kind of a newbie on ceph and there is a ton of stuff in here ;-).. anyway, if I can be of any help, let me know

v13.2.6 just landed:
Notable Changes
---------------
* Ceph v13.2.6 now packages python bindings for python3.6 instead of
  python3.4, because EPEL7 recently switched from python3.4 to
  python3.6 as the native python3. See the announcement[1] _`
  for more details on the background of this change.

@johanot as @lordcirth noted, mimic is a LTS and thus there is value to ensure that this PR gets merged first. Mainly because it comes with some needed "upgrades" to the service module, in my own opinion at least, and secondly because its more or less done.
"The only thing" that needs to be fixed iirc is the dashboard plugin. The problem there is that they are using an embedded python interprenter, which they instrument through the CPython API. This means that our munging with env vars and so, to get stuff to find the relevant python env for it, doesn't have any effect.
This in turn results in the env being lost between the loading of a module and executing it, which leads to the dashboard plugins usage of cherrypy failing because it cannot find the .egg file to do a version check that enables some monkeypatching on very old version of cherrypy.
With that said, in 14.2 they have refactored the dashboard plugin to be its own thing, and thus isn't "a part of" standard ceph anymore so I would suggest that minor work should be done with this PR to get it to 13.2.6. Potentially using the sledgehammer approach that @srhb found in https://github.com/NixOS/nixpkgs/pull/49866#issuecomment-469406445
Work should then be done to get us up to using python3 and potentially 14.2.x (might be possible in the same PR, I haven't scrutinized the changes between 13 and 14).

Ok.. I've managed to bump to 13.2.6 here: https://github.com/NixOS/nixpkgs/compare/master...johanot:ceph-13 .. But unfortunately it required applying the sledgehammer a couple of times again, removing two more cherrypy version checks. :( (https://github.com/johanot/nixpkgs/commit/153479459f0d7cd433d927804e8f53ed38c8ac6d)
Without hesitation I've deployed this branch to our production env. Will try to test it sufficiently during the coming week.

The news from my side is that we are now on ceph 14 in production. The ceph 14 upgrade (which I have on another branch somewhere) is largely based on the changes in this PR, and while we ran ceph 13 (https://github.com/johanot/nixpkgs/commit/153479459f0d7cd433d927804e8f53ed38c8ac6d) in prod, we saw no issues. So basically, I'm ok with my changes getting merged, sledgehammering included, but... I neither have permissions to push nor merge.

@johanot Maybe, if you have time, it would be good to open a separate PR for Ceph 14 and reference this PR?

@grahamc @srhb Could one of you please rebase this branch with master and perhaps my ceph-13 branch as well? Then we can do another round of integration-testing and a collective review of all the changes.

I can do that tonight if you don't just want to open a separate PR with those changes. :)

@srhb as we talked about in another channel, I'll try to assemble a new branch and PR it separately. I can say already that ceph 13.2.6 doesn't build after rebasing with master :P I'll be back at some point once I get that sorted.

TLDR; there's a collision on python2 backports on master, preventing ceph from building. I decided that instead of wasting time fiddling around with the python2-env, perhaps we should try to have a go with ceph 14, which uses python3. Please see #65470 and please comment and review over there.

Included in #65470 -- thanks again

"The only thing" that needs to be fixed iirc is the dashboard plugin. The problem there is that they are using an embedded python interprenter, which they instrument through the CPython API. This means that our munging with env vars and so, to get stuff to find the relevant python env for it, doesn't have any effect.
This in turn results in the env being lost between the loading of a module and executing it

@lejonet Can you explain this a bit further?
I'm trying to get the dashboard to work with Ceph 15.2.3, and get:
10 mgr[py] Computed sys.path '/nix/store/ahn8d1bnkrvj7gbxc90cwqq037g740rs-ceph-15.2.3/lib/python3.7/site-packages:/nix/store/4naw242f2izj1rs55hxcc66zifqcqbn0-python3-3.7.6-env/lib/python3.7/site-packages:/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python37.zip:/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7:/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7/lib-dynload:/nix/store/icpiyydgbnp62pvdh96ff0g4by2zy145-ceph-unwrapped-15.2.3/share/ceph/mgr:/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7/site-packages'
-1 mgr[py] Module not found: 'cephadm'
-1 mgr[py] Traceback (most recent call last):
  File "/nix/store/icpiyydgbnp62pvdh96ff0g4by2zy145-ceph-unwrapped-15.2.3/share/ceph/mgr/cephadm/__init__.py", line 6, in <module>
    from .module import CephadmOrchestrator
  File "/nix/store/icpiyydgbnp62pvdh96ff0g4by2zy145-ceph-unwrapped-15.2.3/share/ceph/mgr/cephadm/module.py", line 31, in <module>
    from ceph.deployment import inventory, translate
ModuleNotFoundError: No module named 'ceph'

-1 mgr[py] Class not found in module 'cephadm'

which is this.
I do not understand why it cannot find the ceph module, because it uses PySys_SetPath(get_site_packages()) which correctly includes /nix/store/...-ceph-15.2.3/lib/python3.7/site-packages/ (which contains ceph-1.0.0-py3.7.egg/ceph/__init__.py), and if I set PYTHONPATH to this for my python3 and import ceph, that works just fine.
What does the CPython API do different that results in this breakage?

I can see in strace that the maximum it does with ceph-1.0.0-py3.7.egg is to read the contents of this dir:
getdents64(22</nix/store/...-ceph-15.2.3/lib/python3.7/site-packages/ceph-1.0.0-py3.7.egg>, [{d_ino=1317894, d_off=783223069217015699, d_reclen=32, d_type=DT_DIR, d_name="EGG-INFO"}, {d_ino=1194113, d_off=3081453319264304844, d_reclen=24, d_type=DT_DIR, d_name=".."}, {d_ino=1317901, d_off=5351582700327092632, d_reclen=24, d_type=DT_DIR, d_name="ceph"}, {d_ino=1317893, d_off=9223372036854775807, d_reclen=24, d_type=DT_DIR, d_name="."}], 32768) = 104
getdents64(22</nix/store/...-ceph-15.2.3/lib/python3.7/site-packages/ceph-1.0.0-py3.7.egg>, [], 32768) = 0
close(22</nix/store/...-ceph-15.2.3/lib/python3.7/site-packages/ceph-1.0.0-py3.7.egg>) = 0

But then it never does more than that, it never goes into ceph-1.0.0-py3.7.egg/ceph/.

Looks like I can work around it by putting $(toPythonPath $out)/ceph-1.0.0-py3.7.egg straight onto the PYTHONPATH, I'm not sure why that's necessary though, and it's ugly.

Also I found that some nixpkgs python packages do
rm -f "$out/lib/${python.libPrefix}"/site-packages/site.py*

but i don't know why and none of them have comments on it. @FRidh @jonringer Do you know?
Maybe it's related?

When I run (tip from energizer on IRC):
# PYTHONPATH=/nix/store/1fy23hzpll8kx160z1mb502bq7rrirzc-ceph-15.2.3/lib/python3.7/site-packages/ python3 -m site
sys.path = [
    '/root',
    '/nix/store/1fy23hzpll8kx160z1mb502bq7rrirzc-ceph-15.2.3/lib/python3.7/site-packages',
    '/nix/store/1fy23hzpll8kx160z1mb502bq7rrirzc-ceph-15.2.3/lib/python3.7/site-packages/ceph_volume-1.0.0-py3.7.egg',
    '/nix/store/1fy23hzpll8kx160z1mb502bq7rrirzc-ceph-15.2.3/lib/python3.7/site-packages/ceph-1.0.0-py3.7.egg',
    '/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python37.zip',
    '/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7',
    '/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7/lib-dynload',
    '/nix/store/55b9ip7xkpimaccw9pa0vacy5q94f5xa-python3-3.7.6/lib/python3.7/site-packages',
]
USER_BASE: '/root/.local' (doesn't exist)
USER_SITE: '/root/.local/lib/python3.7/site-packages' (doesn't exist)
ENABLE_USER_SITE: True

That looks like what it needs (putting ceph-1.0.0-py3.7.egg onto the path), but I don't understand why that's not in effect, and why it would be bad.
I can also see:
# cat /nix/store/1fy23hzpll8kx160z1mb502bq7rrirzc-ceph-15.2.3/lib/python3.7/site-packages/easy-install.pth
./ceph_volume-1.0.0-py3.7.egg
./ceph-1.0.0-py3.7.egg

But I'm not sure what that does.

@nh2 It was a while since I did the deep dive into the whole mess that is cephs handling of python modules with Cpython, but if I remember correctly, due to how they initialized the actual interprenter, the PYTHONPATH env variable did not propagate to the actual interprenter that it then starts all modules with. This is a "working as intended" of the Cpython API, iirc it even said in the documentation around the functions they used that if you wanted to preserve env vars, like PYTHONPATH, you had to explicitly set them ahead of invoking the Cpython interprenter.


Lazyload and smooth scroll not playing well together

This might be more of an enhancement request, (or I'm likely missing a work-around).
Function: I'm currently using a smooth scrolling script. A click on a button in the top nav causes the page to automatically scroll directly to the anchor set in the footer.
Problem: With Lazyload in use, not all of the images have loaded between the navigation and the set anchor at the bottom of the page. So the scroll stops short of where the actual anchor is, mistaking the end location for an image that was successfully loaded.
Attempted Solution: All my images have width and height values set in the HTML, but smooth scroll still refuses to scroll past anything that lazyload hasn't yet loaded.

The solution you’ve attempted should work, meaning reserving space by setting the width and height of images.
Could you post an example on Codepen, so I can check what is wrong?

Hey @welling11 ,
I created a working example on Codepen so you can see how you could implement it, and it seems to me it's working fine.
I hope you enjoy ☕ it!

Thanks so much for setting this up!  I played around and think my issue could be from using responsive images. I set width/height in the HTML on images to maintain an aspect ratio. But depending upon the browser window size the set image height value isn't the exact image size of what the viewport shows -- possibly causing the scroll to fall short of the destination. The reserved space isn't equaling what is actually needed.
I've been trying a few workarounds (thus far unsuccessfully) and I'll try and get a pen up with the initial issue. But I'm guessing the initial .js just wasn't built with this flexibility in mind.
thx again!

You need to occupy vertical space using responsive images so. If you read the readme, there are a couple of ways to do so. One is the percent padding hack, the other one is to use a placeholder SVG.
You’re welcome!

@welling11 I'm closing this now. If you still need help, feel free to reopen.


error while inserting large image

Cannot insert large image. When I try to paste a  large image, I get an error in the console.
Screenshot:

If you are uploading it, check your api for uploading

@imzbf On the demo page, I also get an error when  try attaching a large image.
Video: https://drive.google.com/file/d/1uRql6eMELeQ1QRa4ZgMaMb8pt-vyStRX/view?usp=share_link

@imzbf Ok thanks, I'll check the api and let you know

I haven't prepared a service for the document, so we can't upload images here😀

Thanks, the problem was really not related to md-editor-rt


Polyfill

I found writing a polyfill to be a useful tool for discussions.
This polyfill can live in this repository for simplicity, and shouldn't be published (others will publish polyfills).
It should also be as pedantic as possible, being explicit about matching the entirety of the spec.

(in case polyfill authors make their way here: also, polyfills shouldn't BE published or used in production prior to stage 3)
If you want the in-repo polyfill to have running code, you can also use https://npmjs.com/es-abstract so it maximally matches the spec text.

https://github.com/zloirock/core-js/pull/990
Waiting for the TC39 discussion and stabilization.

If you want the in-repo polyfill to have running code, you can also use npmjs.com/es-abstract so it maximally matches the spec text.

After issues like this that are not fixed for many years, I don't think that makes sense to recommend it to third-party polyfills authors.

Let's keep this issue on topic, I don't want to have a huge meta conversation about process here


Added support in Code.py for Batching

Pull Request Description
What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)
Closes #1654
Partially solves #1632 (implementation with MPI still not working)
What are the significant changes in functionality due to this change request?
Added batching support for Code.py

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[x] 1. Review all computer code.
[x] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[x] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[x] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
[x] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.
[x] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[x] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[x] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
[x] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

All jobs on 8c870e9 : invalidated by @wangcj05
retest, some machine is not responding

@aalfonsi XSD failed:

Could you fix it?

Job Test Ubuntu 16 on 8c870e9 : invalidated by @joshua-cogliati-inl
restarted civet

Job Test Ubuntu 18-2 Python 3 on 8c870e9 : invalidated by @joshua-cogliati-inl
restarted civet

Job Test Ubuntu 18-2 Python 3 on 8c870e9 : invalidated by @joshua-cogliati-inl
test civet

@aalfonsi XSD failed:

Could you fix it?

sorry did not see it


Can't start Terminal with admin privileges

Environment
Windows build number: Windows 10 v 2004 build 19041.508
Windows Terminal version (if applicable): preview 1.4.2652.0

Steps to reproduce
Right click on any Windows Terminal icon and select Run as Administrator.
Expected behavior
Windows Terminal should open normally, with administrator privileges.
Actual behavior
After asking for admin password 2 times, it doesn't start and throws an error instead:

Are you trying to elevate the same user or are you trying to "Run as Administrator" as another user?

I'm clicking Run as Administrator in the context menu of the exe, but I'm not logged in as one, so I'm prompted to type in the password of another administrative user.

Unfortunately, this scenario doesn't work quite right today. IIRC you need to have the Terminal installed for the admin user as well. There are more details in #4217, which is tracking this issue with the platform team as well. Thanks!
/dup #4217

I'm clicking Run as Administrator in the context menu of the exe, but I'm not logged in as one, so I'm prompted to type in the password of another administrative user.

As @zadjii-msft said you need to have WT installed for the other user too, but from what I recall you also need to have WT in both users at the same version. If you've updates it through the store in your non-admin user but haven't updated it in your admin user, you'd get this error.


Warnings require cycle

Describe the bug
When i run the app i get these warnings and it takes about 5 seconds to enter the app
Require cycle: node_modules\react-native-track-player\lib\index.js->
node_modules\react-native-track-player\lib\hooks.js->
node_modules\react-native-track-player\lib\index.js
node_modules\react-native-track-player\lib\index.js->node_modules\react-native-track-player\lib\ProgressComponent.js->node_modules\react-native-track-player\lib\index.js
To Reproduce
Steps to reproduce the behavior:
Environment (please complete the following information):
Run react-native info in your project and share the content.
What react-native-track-player version are you using?
Are you testing on a real device or in the simulator? Which OS version are you running?
Code
Please, share the code that is causing the issue

 "react-native-track-player": "^1.2.3",

Issue still actual and quite annoying. Any plans to fix it?

 "react-native-track-player": "^1.2.3",

Issue still actual and quite annoying. Any plans to fix it?

Hello, I still get these cycle warnings too, that's not ideal. Any plan of fixing them soon? There is other issue opened on the topic that seems to be related. Commenting there too: https://github.com/react-native-kit/react-native-track-player/issues/989

This issue was fixed on PR #1077 and it just need to be merged.

same issue

Fix released in 1.2.4

The require cycle warning is back again, now on version v4.0.1:

Issue still present on version 4.0.1

Getting the same issue in 4.0.1.

same issue in 4.0.1

curious to why this is closed when it is clearly still present?
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
  factory (node_modules/react-native-track-player/lib/web/TrackPlayerModule.js:2:1)
  factory (node_modules/react-native-track-player/lib/web/index.js:1:1)
λ  WARN  Require cycle: node_modules/react-native-track-player/lib/src/index.js -> node_modules/react-native-track-player/lib/src/trackPlayer.js -> node_modules/react-native-track-player/lib/src/TrackPlayerModule.web.js -> node_modules/react-native-track-player/lib/web/index.js -> node_modules/react-native-track-player/lib/web/TrackPlayerModule.js -> node_modules/react-native-track-player/lib/web/TrackPlayer/index.js -> node_modules/react-native-track-player/lib/web/TrackPlayer/PlaylistPlayer.js -> node_modules/react-native-track-player/lib/src/index.js


[hmac,difs] Update DIFs and DIF-based TLTs

Description
At the moment, HMAC DIFs and drivers configure HMAC by default in SHA-2 256 and 256-bit key. To support TLTs configuring different digest sizes and key lengths, the DIFs need to be updated and the corresponding documentation. Additionally, we need to exercise reading the HMAC error code for invalid configuration.

At the moment, we are using TLTs implemented on top of cryptolib HMAC driver to get nightly results. It would make sense to implement these tests on top of DIFs instead of the driver, but I think that is not M4 priority.
We have two relevant top-level tests, one is testing oneshot calls and the other one is testing multistream (i.e. streams that are running in parallel and interleaving each other with context switching).
Relevant PRs:

#23335
#23471
#23494

I would update the milestone as M5 or later.

Labeling this as M5 since at M4 we exercise the new features at block-level and test one-shot and streaming HMAC with KAT test vectors at the top-level using the driver-based TLTs referenced above by @ballifatih.
cc @martin-velay

In my view, if we have TLTs using these hardware features through the cryptolib, we don't need to write further TLTs for these features. Ideally, the DIF can still be extended provide those interfaces.
However, both tasks don't sound like a M5 item to me. What we care about is the coverage of these features at the top level (and block level) and my understanding is that we have that coverage now already.

So in my view we can de-prioritze this.

From an offline discussion between @gdessouky and @martin-velay : "this will enable us to try out at top-level different scenarios with context switching" - 4 days estimated effort.

Discussed in triage meeting to leave this in.

Moved to M7 backlog as this is not relevant for the V3 signoff

Doesn't required for D3-V3 signoffs as it concerns mostly SW


New version: Microsoft.Gaming.TAK.CLI version 11.3.0

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.6 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

FYI - The first time we submitted this, an automatic validator failed because our tool did not return exit code 0 when run as-is: tak.exe.
This is because our product is a command line tool which requires a "command" to be provided to it to successfully run, and running it just by itself yields an error with the manual printed that tells the user what commands they can run.
cc @stephengillie who helped with applying the waiver last time to get this submitted.

Automatic Validation ended with:

Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Packages\Microsoft.Gaming.TAK.CLI__DefaultSource\tak.exe returned exit code: 1
Executable C:\Users\validator\AppData\Local\Microsoft\WinGet\Links\tak.exe returned exit code: 1

(Automated response - build 880.)

FYI - The first time we submitted this, an automatic validator failed because our tool did not return exit code 0 when run as-is: tak.exe. This is because our product is a command line tool which requires a "command" to be provided to it to successfully run, and running it just by itself yields an error with the manual printed that tells the user what commands they can run.
cc @stephengillie who helped with applying the waiver last time to get this submitted.

This is very common - something of a known issue. I regularly mark CLI applications with an exit code as complete for this reason. It feels like there should be an ExpectedReturnCode for this situation.


back2source: Run pipeline for JavaScript

We have an existing map_deploy_to_devel pipeline to analyze deployment of JavaScript apps using symbols found map files. There is a plan to further improve this with this issue:

https://github.com/aboutcode-org/scancode.io/issues/1405

The plan in #1405 is to refine the analysis using symbols and string matching between minified bundles and sources including JS and TS.
The purpose of this issue #1477 is to evaluate at some scale the results of #1405. And:

Collect a bunch of npm projects that use minification and TS
Run the pipeline on this.
Collect issues and either report as bugs in our code to fix (and fix them)
... or as real issues upstream, then push mini report on this issues for reference here

Could you provide some context for this

@Illucious I updated the description of this issue
If you want to help here, finding a few popular npm packages that contain minified or webpacked bundles in their released npms would be useful towards this, but we will need #1405 completed before we can do actual d2d runs

FYI, d2d is short for "Deploy To Development"


Fix magento2 php-fpm 8.2 xdebug image builds

https://github.com/swiftotter/den/actions/runs/2961721269

https://github.com/swiftotter/den/runs/8107645582?check_suite_focus=true#step:7:586

Images are built and ready to pull!


Arbiter UI NPE

Issue Description
NPE in the arbiter basic example
Exception in thread "main" java.lang.NullPointerException
	at org.deeplearning4j.ui.VertxUIServer.stop(VertxUIServer.java:306)
	at org.deeplearning4j.arbiterexamples.quickstart.BasicHyperparameterOptimizationExample.main(BasicHyperparameterOptimizationExample.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

Version Information
beta6, macos

So far I've been unable to reproduce this (5 runs through on master, CPU backend).
Was this on current master also?

This was on beta6. I can try with snapshots and see if it is still an issue.

Still seeing this on snapshots:
Exception in thread "main" java.lang.NullPointerException
	at org.deeplearning4j.ui.VertxUIServer.stop(VertxUIServer.java:306)
	at org.deeplearning4j.arbiterexamples.quickstart.BasicHyperparameterOptimizationExample.main(BasicHyperparameterOptimizationExample.java:179)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

thanks. Though based on the line numbers, that doesn't make a whole lot of sense, as it would require the server field to be null, which it can't be
Line 306: https://github.com/eclipse/deeplearning4j/blob/master/deeplearning4j/deeplearning4j-ui-parent/deeplearning4j-vertx/src/main/java/org/deeplearning4j/ui/VertxUIServer.java#L306
Unless there's a missing "caused by" here you haven't posted?
Can you post the complete output of the run? Maybe there's some other hint there

I can't load the UI. I get "ERR_CONNECTION_REFUSED" when I try.
The run gives no other errors. Here is a snapshot of the screen

I think that PR #8856 will fix this. In that PR, I replace server.close() with vertx.close(). In beta6, server.close() did not actually stop the UI.
I have run BasicHyperparameterOptimizationExample with my build of 1.0.0-SNAPSHOT on Windows, and the UI properly stopped.

Closing this due to likely being fixed by this PR: https://github.com/eclipse/deeplearning4j/pull/8856
@eraly Can you retest to confirm it's fixed at some point? We'll re-open if not. Thanks

Retested and I can confirm it is fixed. Thanks!


Upstream changes from our IDB mocks fork

In the longer term, we should try to upstream the changes made in https://github.com/philipwalton/shelving-mock-indexeddb back into the main repo. There have also been 3 patch releases since the fork that have not been merged/rebased in, so we should fix that as well.

Closing this as we've now updated to run our unit tests in a service worker environment and no longer need these mocks.


Unable to scp specific files to prose.sh

Attempting to upload _style.css and favicon.ico to prose.sh but files are being rejected due to filetype.
_style.css                                                                                100%  115     1.2KB/s   00:00
WARNING: (_style.css) invalid file, format must be (.md,.jpg,.jpeg,.png,.gif,.webp,.svg), skipping
scp favicon.ico prose.sh:/
favicon.ico                                                                                100% 9610    88.7KB/s   00:00
ERROR: (favicon.ico) invalid file, format must be (.md,.jpg,.jpeg,.png,.gif,.webp,.svg), skipping
I also tried uploading them as an acceptable filetype and then changing the extension but was also denied that action as well

File should be "_styles.css"
I'll look into the ico

I deployed a fix to allow .ico file formats to be uploaded to prose.sh -- could you please confirm your issues are fixed?


MQTT Password

Thank you for coding this interesting QA.
I was wondering if its possible to use MQTT servers with Username/password protection?
could you elaborate om the
hc3Auth - login and password for pulling events from Fibaro HC3. Must be encoded with Base64, e.g. "admin:password" -> "YWRtaW46cGFzc3dvcmQ="
hc3Auth _ is the the HC3 admin password i need to base64 encode, not sure what is ment here.
And the IP for MQTT is for an external MQTT server - right ?

Sure, I'll add support for MQTT authentication tomorrow, it is on my roadmap already.
This is how "hc3Auth" and "mqttUrl" look like at my setup:

"hc3Auth" variable stores both username and password, same way as HTTP Basic Authentication encodes user credentials => you take your username, then append it with ":" character, then append with password, and then encode the resulting String with Base64.

I could store username and password in two separate variables (plain text), but because those variables are maintained at GUI - it felt right to use Base64 encoding and improve a sense of security slightly. This is not something what everyone need, and is mostly aiming to protect you while browsing QA settings in front of other people, reducing risk of exposing a sensitive information

"mqttUrl" is a standard MQTT connection URL.  MQTT broker host could be addressed by internal/external IP or DNS. Just need to make sure this IP/DNS is addressable from your Fibaro Home Center 3.

I personally use Mosquitto MQTT broker within my home network, as you can see on the screen address (IP address class C). I also tried to use MQTT broker in cloud, but it has a limited number of use cases for my setup, so I decided to stay with a local one for now.
Please let me know if this description helps, and I can probably move it to the home page.

i think I got it :-)
Username admin
i will wait for the update with U/P for MQTT :-) - i use Mosquitto MQTT broker as well
Password = Password
admin:password will be YWRtaW46cGFzc3dvcmQ=
using CyberChef ;-)

local function connect()
    local status, data = pcall(mqtt.Client.connect, mqttUrl, {clientId="HC3-"..plugin.mainDeviceId, username = 'user', password = 'Pass',
        keepAlivePeriod=keepAlivePeriodSeconds, lastWill={topic='test/last_will', payload=os.date()}})
    if status then
        self.client=data
        self.client:addEventListener('published', function(event) self:onPublished(event) end)
        self.client:addEventListener('message', function(event) self:onMessage(event) end)
        self.client:addEventListener('connected', handleConnect)
        self.client:addEventListener('subscribed', function(event) self:debug('subscribed: '..json.encode(event)) end)
        self.client:addEventListener('error', handleError)
    else
        self:debug("connect error: "..data)
        fibaro.setTimeout(retryMilliSeconds, connect)
    end
end

Added additional QuickApp variables to control MQTT connection parameters:

mqttAuth to setup user credentials in Base64 encoded form
mqttUsername and mqttPassword to setup user credentials in plain text
mqttClientId to setup custom client id, or using "HC3-" .. plugin.mainDeviceId by default
mqttKeepAlive to setup custom MQTT Keep Alive Period

I should add pcall wrapper around MQTT connect function as you suggested => introduce an additional layer of error handling/protection... but then I somehow started thinking on how Fibaro may possibly implement their MQTT connectivity lib... would it be possibly to cause a race condition issue when MQTT connection is failed, and their lib reports same issue with both pcall and "error" callback function, resulting in 2 simultaneous MQTT reconnect attempts :)

I downloaded the new version - its Corrupted or something else is wrong. When changing the variables - HC3 shows an error with red - "cannot save". Old version works. I tried download again - try all over, but i cant save/change the variables. actually i have never seen this error in HC3 before,


Make .dir-locals.el sensible

Directory-local variables have been moved so that they are set directly
in .dir-locals.el.
Motivation:
The variables set in swiftpm-project-settings.el can be set directly
in dir-locals.el. There is no reason to move them to a separate file,
and in fact doing that will automatically make Emacs flag the dir-locals
as unsafe, since it will be being requested to evaluate a block of code,
instead of setting known-safe variables.
Modifications:
Utilities/Emacs/swiftpm-project-settings.el has been removed. All variables
set in it have been moved to .dir-locals.el itself. This allows the evaluation
of all directory locals to be considered safe.
Additionally, swift-basic-offset was changed to swift-mode:basic-offset.
That appears to be the proper variable for setting indent width for Swift in Emacs.
Result:
Emacs users can edit the project more peacefully.

@swift-ci test


Track Files

Gather collection of 30 sec song samples

This issue was moved to kroehl/MusicDiscoveryApp#8


Fix: update docker compose version at least up to v2.24.6

Describe the bug
The docker compose package had this bug https://github.com/docker/compose/issues/11404
And you use Docker Compose version v2.24.5 right now with this bug.
To Reproduce
No response
Expected behavior
To avoid this bug, need to update orbstack's docker compose version at least up to v2.24.6
Diagnostic report (REQUIRED)
No response
Screenshots and additional context (optional)
No response

Done for the next version.

Released in v1.5.1.


How to change timeout for a single request in okhttp

What kind of issue is this? - Question.
I asked in StackOverflow no one responded. So repeating same here :
https://stackoverflow.com/questions/46845206/how-to-change-timeout-for-a-request-in-okhttp
In general we set timeout for the okHttp client and we use single instance of that client. So, we can't change the timeout for that client once it's generated.
How to change the timeout for a particular request ?? Is there anyway to do it without creating new client??
It's very common that some calls take more time atleast 1/2 per app, which needs more timeout than others. it would be great if request object can override the default timeout.

See https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/PerCallSettings.java which creates shallow clones that only modify some settings.


ocamlPackages.pythonlib: init at 0.14.0

Motivation for this change
https://github.com/janestreet/pythonlib/issues/11
https://github.com/ejgallego/pycoq/issues/17
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build ocamlPackages.pythonlib


CMake error, if version less than 3.8

If I want to create the json_dto library with a CMake version lesser than 3.8 I get the following error:
CMake Error at json_dto/CMakeLists.txt:13 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties.  The
property "CXX_STANDARD" is not allowed.
CMake Error at json_dto/CMakeLists.txt:13 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties.  The
property "CXX_STANDARD_REQUIRED" is not allowed.
CMake Error at json_dto/CMakeLists.txt:13 (set_target_properties):
INTERFACE_LIBRARY targets may only have whitelisted properties.  The
property "CXX_EXTENSIONS" is not allowed.

CMake prior to 3.8 is a rather old version. Do you really haven't a possibility to use more modern versions of CMake?

I am currently testing if I can use json_dto on different Linux distributions.
Debian 9.x for example uses cmake 3.7.2
BTW: If cmake 3.8 is default, you should change "cmake_minimum_required(VERSION 3.3)".

I remember that we did testing of json_dto's CMake build files with old CMake a long time ago and because of that CMakeLists.txt contains the following lines:
IF (${CMAKE_VERSION} VERSION_LESS "3.8.0")
	set_target_properties(${JSON_DTO} PROPERTIES
		CXX_STANDARD 14
		CXX_STANDARD_REQUIRED YES
		CXX_EXTENSIONS NO
	)
ELSE ()
	target_compile_features(${JSON_DTO} INTERFACE cxx_std_14)
ENDIF ()

But I can't understand why it's not working now. Googling such errors leads to CMake's issues and it seems that this approach should work.
We'll investigate this issue further. If there the actual reason won't be found we'll accept your PR.
Thanks for reporting that!

I think it has something to do with the whitelist restriction that is used when using INTERFACE_* or IMPORTED_* in CMake < 3.8
https://gitlab.kitware.com/cmake/cmake/issues/17214
https://gitlab.kitware.com/cmake/cmake/issues/17217

The current problem for me now is to understand why we decided that this approach works. Maybe it was our mistake during the testing, maybe something else. I don't know yet.


Test CDC-ELIMS messages: Part 7 - RS Overrides

User Story
As ELIMS, I would like RS not to apply its default overrides so that the output HL7v2 can match the input as much as possible.
Description/Use Case
Presently, there are four scenarios identified in this spreadsheet that relate to differences in the output message from the input. See rows 2-5 for details.
UPDATE: Each of the rows 2 through 5 are related to the default sender transform that had been used with the ELIMS sender on staging. There is an ELIMS specific transform that is now being used on staging which will resolve those discrepancies for ELIMS. However, there is still a question of why those changes are present in the default sender transform. This ticket should be used to investigate the current default sender transform and for anything that really shouldn't be a default, find a new home for those elements, either in a different sender transform (for example, simple report), or in a receiver transform. This should involve coordination with Victor and the engagement team.
Risks/Impacts/Considerations
Dev Notes
Acceptance Criteria

[ ] Sample test message run through pipeline and output message confirmed to equal input message. (Done after updating sender transform for ELIMS)
[x] Default sender transform only contains transformations that are generally safe for a default case

Blocked. Need test messages that repro this issue from ELIMS team

Hey team! Please add your planning poker estimate with Zenhub @arnejduranovic @brick-green @jack-h-wang @jalbinson @JessicaWNava @jimmyfagan @mkalish @thetaurean @JFU-NAVA-PBC

We haven't seen these issues because locally, we’re using an ELIMS specific sender transform that prevents those few changes, but in staging, the elims sender uses the default sender transform, which does cause those changes. So the fix there is probably two-fold: 1) update the settings in staging to reference the elims transform and 2) consider moving some of those pieces out of the default sender transform and into a SR sender transform or into receiver transforms.

The elims transform just negated the default transform and since none of the things in the default transform actually belong there, I renamed it to something more appropriate, deleted the elims sender transform, and updated the places that it needed to be updated in the code. Once this gets pushed out staging will need to be updated so that they no longer have a sender transform.

In terms of rollout strategy here, I think we should remove the sender transform from staging before the changes get deployed, just to make sure there isn't any gap where we are referencing a schema that doesn't exist. Other than that, sounds like a plan!


client-sdk/go/crypto: Implement secp256k1 signer

Closes #95.

OK, I'll add that :)

do we have any external things to test compatibility against? I have a draft of similar signing/verifying in the typescript lib, so if you have something, I'd like to test the typescript part against that as well.

The library I'm using (btcec) already has extensive tests, so I didn't feel the need to repeat them here, since this PR basically just wraps their library.  I do test if our code properly generates a signature that's in their examples, but that's just a quick sanity check.
If you find any offical test vectors, we can add those in a separate PR, just to be extra sure.

Thanks!


Use pick_first balancer for discovery attempts

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

Codecov Report
Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 43.50%. Comparing base (4d80170) to head (613028f).

Files with missing lines
Patch %
Lines

internal/balancer/balancer.go
0.00%
3 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (4d80170) and HEAD (613028f). Click for more details.
HEAD has 529 uploads less than BASE

Flag
BASE (4d80170)
HEAD (613028f)

macOS
24
1

unit
72
1

go-1.21.x
48
1

ubuntu
103
0

go-1.22.x
48
0

go-1.23.x
55
0

windows
24
0

integration
72
0

ydb-23.3
24
0

ydb-nightly
7
0

experiment
7
0

ydb-24.1
24
0

ydb-24.2
24
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master    #1548       +/-   ##
===========================================
- Coverage   70.87%   43.50%   -27.37%
===========================================
  Files         362      295       -67
  Lines       37509    31687     -5822
===========================================
- Hits        26583    13785    -12798
- Misses       9841    17429     +7588
+ Partials     1085      473      -612

Flag
Coverage Δ

experiment
?

go-1.21.x
43.50% <0.00%> (-26.85%)
:arrow_down:

go-1.22.x
?

go-1.23.x
?

integration
?

macOS
43.50% <0.00%> (+2.46%)
:arrow_up:

ubuntu
?

unit
43.50% <0.00%> (+2.46%)
:arrow_up:

windows
?

ydb-23.3
?

ydb-24.1
?

ydb-24.2
?

ydb-nightly
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Create a blog post/demo of using the Twitter API using the Twitter HTTP Config

Overview
There currently exists a repository which is a dockerized demo of how to use the Twitter API and Summon to manage secrets.
We would like to use the new Secretless config for Twitter to connect to the Twitter API instead.
Acceptance Criteria

[x] There is a working demo/repository which uses the Twitter API to connect to Secretless

Check out the demo here: https://discuss.cyberarkcommons.org/t/video-demonstration-of-the-secretless-broker-http-configuration-in-a-dockerized-node-react-application/866/2


Update of fingerprint

fix #506

@googlebot I signed it!

@googlebot I signed it!

Merhaba teşekkürler, bu parmak izinin ne zaman geçerli olduğunu merak ediyorum.
Firebase ile iletişim kuran makineler yapıyorum veya kodumda özel iletişimi engellemeyecek bir parmak izi almak mümkün mü?
parmak izi nasıl alınır.

Hello, I couldn't fix the problem. What should I do?

Merhaba teşekkürler, bu parmak izinin ne zaman geçerli olduğunu merak ediyorum.
Firebase ile iletişim kuran makineler yapıyorum veya kodumda özel iletişimi engellemeyecek bir parmak izi almak mümkün mü?
parmak izi nasıl alınır.

Hello, I couldn't fix the problem. What should I do?

I use https://www.grc.com/fingerprints.htm page for get fingerprint. That page was mentioned in some other issue. May by that fingerprint is different for each project, based on server region. You can try search and use fingerprint for your project firebase server (https://.firebaseio.com/)

I use https://www.grc.com/fingerprints.htm page for get fingerprint. That page was mentioned in some other issue. May by that fingerprint is different for each project, based on server region. You can try search and use fingerprint for your project firebase server (https://.firebaseio.com/)

This patch saved my brew day.  I can confirm it fixes communication with Firebase!

This patch saved my brew day.  I can confirm it fixes communication with Firebase!

@paxsipornax
Use library by Mobizt to fix it permanently :- https://github.com/mobizt/Firebase-ESP8266/
https://youtu.be/nLzC0-VaqDs

@paxsipornax
Use library by Mobizt to fix it permanently :- https://github.com/mobizt/Firebase-ESP8266/
https://youtu.be/nLzC0-VaqDs


Scrape Docs

Starting by adding a test that asserts that the docs have been scraped. This will help prevent needing fix PRs like #2. Once I see a red build on Circle, I'll re-run the scraper and push and hopefully that will turn it green.

Hm, tests didn't run. I suppose they may not be enabled for forked PRs in the circle settings. I'll just push the next commit now, but it would be good to verify that it's working by inspecting the build output after this is merged.

@sivakumar-kailasam thanks for merging - made a follow-up PR #8 to get the build running. I'm hoping to see a build failure after that's merged which indicates that the docs are out of sync. Then we can re-run the scrape-docs script and should have a green build. It would be great to enable builds for forked PRs as well