Keep virtual metadata on relationship delete

This PR adds the possibility to store virtual metadata as normal metadata when the virtual metadata would be lost due to the removal of a relation or a related entity.
On the "Item Relationship" tab of the admin edit item page a modal window will appear when selecting a relationship to be deleted. In this modal the entities that would lose virtual metadata and the virtual metadata that would be lost by deleting the relationship are listed. Next to each entity a checkbox is available to allow the administrator to select the entities for which virtual metadata should be stored as normal metadata.
Currently this feature is only available for administrators, but in the future we would want to update this feature to check if the user performing the relationship delete has submitter rights on each of the related entities before allowing the user to manage the virtual metadata for the related entities.
The “Item Relationships” UI allows the user to "undo" the relationship deleted, the actual relationship delete only happens when the user clicks on the “Save” button. The virtual metadata selected in the modal of the feature of this PR will also only be stored as normal metadata when the "save" button is clicked. No changes happen when the "undo button is clicked.
This PR is still a work in progress, but it should already allow you to start testing these features. Tests and documentation are still incomplete. We’ll push them to this PR in the next few days.

@PhilipVis : I found time to give this a test today as well.  The popup/modal seems to work as you described it.  However, I when I delete a relationship & check one (or more) of the boxes, I do not see the virtual metadata appear in the normal metadata.  I expected to be able to view the normal metadata and see new fields there, but that doesn't seem to be the case.
I'm uncertain if this is an issue on the frontend (this PR) or backend.  But, I'm not seeing any errors appear...the relationship is deleted, but the normal metadata doesn't seem to appear.  (It might also be that I'm testing with bad data...but I wanted to note this issue in case others can reproduce it)

I've having some difficulty testing this PR, like @tdonohue I'm not able to delete the item and having metadata copied into the related item (and tested with https://github.com/DSpace/DSpace/pull/2599), also, this PR it's seems to be far behind master, so the issue fixed by - https://github.com/DSpace/dspace-angular/pull/537 still occurs in this PR.

I would like to double-check regarding the problem you're encountering where the virtual metadata is not copied. Are you checking the relation.* (e.g. relation.isPublicationOfAuthor) metadata?
The REST backend explicitly doesn't copy that metadata since it's only used to identify the relationship's related item UUID.

@benbosman & @PhilipVis : I've retested this today with the more recent sample data set (from Ben).  It's still not seeming to work for me, but now I'm seeing a different issue.  Here's what I see:

From the /edit/relationships page, I click "Delete" on a relationship and I see the modal / popup.
From that modal, it looks like the only metadata that I can turn into "real metadata" is the UUID of the related object. That's not very useful, as that UUID has no meaning to a human...shouldn't I be able to save the name/label of the related object?  It seems odd to me that all I can save is the UUID.
Nonetheless, if I select one or more of the options and click Save, then the modal window goes away. and I see the (to be deleted) relationship highlighted in red
If I then click the (newly enabled) Save button on the /edit/relationships page, I get a confirmation that my changes to the relationships were saved.  However, the deleted relationship still exists on the (now reloaded) /edit/relationships page.
If I move over to the /edit/metadata page, no new metadata fields were added. I expected to see a relation.* field (as listed in the modal/popup), but all I see are the normal dc.* fields (which already existed).
If I now go back to the /edit/relationships page, the relationship is gone.  So, it was deleted, but it didn't appear deleted initially.
If I now go back to the /edit/metadata page, I still don't see any new relation.* or dc.* metadata fields added.  I expected that I should see some new metadata copied from the deleted relationship, but I do not.

@PhilipVis I've tested this branch as well, and I noticed:

When clicking on the checkbox in the modal window for copying the metadata, Angular sends requests to REST for all relationships in the item. Angular already has that info since it did request the search byLabel first, and doesn't need any additional info at that point in time. This makes clicking the checkbox a slow process
The actual save button at the top right doesn't fire off a DELETE to REST in my tests. Based on the feedback of others, it does seem I'm the only one experiencing this problem though
I think it would help understanding the functionality if the relation.* metadata would not be displayed in the modal windows since REST doesn't copy them to actual metadata (they're not useful)

The tests and documentation for this PR have now been completed.
@tdonohue Thank you for your feedback!
2. The UUID was indeed not very useful. The PR has now been updated to hide the relation.* metadata in the modal window.
4. and 6. The reason why the relationship didn't appear deleted at first, but did appear to be gone later on is because the page was not automatically being refreshed after a relationship delete. The PR has now been updated to automatically refresh the page when the relationship delete is finished, and the deleted relationship will correctly be gone from the item relationships page.
7. I'm not sure why the metadata wouldn't be visible on the related item. I have tested the behaviour with the latest version of the PR and the metadata selected in the modal window does correctly get added to the related item as normal metadata on relationship delete, and is visible on the full item page of the related item.
@benbosman Thank you for your feedback!

This PR has now been updated so that the unnecessary REST requests when clicking the checkbox in the modal window no longer occur.
I wasn't able to reproduce the issue of the save button not firing a DELETE request.
The PR has also been updated so that the relation.* metadata will now no longer be displayed in the modal windows.

To implement the automatic refreshing of relationships, I had to refactor the page to not get the relationships from a search endpoint, but from the item endpoint embedded relationships. This way the related cache can be cleared.
The problem Ben described (fetching the data again) was related to the validity time of a search result. Now the page is refactored to no longer use the search endpoint to obtain the relationships (see previous point) this is no longer relevant.

Merged the latest master branch in this PR (Angular 7 upgrade)


add company icons

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#962  👈
#961
#958
#957
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @shakyShane and the rest of your teammates on  Graphite


The data does not appear in the grid option only in the text option

System information:

Operating system (distribution) and version:
OS: Fedora 29 TwentyNine
Kernel: x86_64 Linux 5.0.16-200.fc29.x86_64
DE: Cinnamon 4.0.10
WM: Muffin

DBeaver version:
6.0.5

Java version:
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-b04)
OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode)

Additional extensions: -

Connection specification:
This not apply because its happen allways.
Describe the problem you're observing:
I can not view the data in grid mode. By clicking on the Grid icon it appears quickly and then it goes away.
You can see the data in the column with f7, you can also use the arrow keys to navigate between these results and see the others.
Log and images are in google drive, in the images will also have the mysql workbench only to demonstrate that there are data in the table.
Steps to reproduce, if exist:
Just click the Grid icon in a table.
Include any warning/errors/backtraces from the logs:
https://drive.google.com/drive/folders/1M3qT7g3IZCkia0G_jfrqreC55VDbQoKu?usp=sharing

Same issue. Linux Mint 19 with Mate DE and Oracle JDK 11.0.2.
Grid data appears until I try to click inside the panel (anywhere). Then it goes blank. Only text view works.

Same. Ubuntu 18.04 Mate, Java SE 1.8.0_201,DBeaver v6.1.0
Grid view:

Same table text view (content smudged)

I ran into this as well. Check if the solution referenced in #5854 fixes this for you.

@slamtrooper that's it, work for me!
I executed this command and started dbeaver in the terminal:
$ export GTK_IM_MODULE=ibus
Just for check if set:
$ echo $export GTK_IM_MODULE
And execute in terminal:
$ dbeaver
Thank you!


PREB-31: [Docs] Update Smaato FPD section

FPD section is updated for Smaato

Related to #3444 - thanks for jumping on this @Katarzyna-B


Derive raft id from public key

@dcmiddle addressed change requests

Will need to wait for the new nightly to be published after merging https://github.com/hyperledger/sawtooth-core/pull/1779


Create bcftools_merge_runner.py

bcftools merge seems to be an OK (and faster) alternative to mergeSTR (which has been stalling with larger catalogs see: https://centrepopgen.slack.com/archives/C030X7WGFCL/p1704685344162619).

disabling unsubscriptable-object lint check because it's throwing errors for other files in the repo that are not included in this PR

Not sure how to globally disable unscriptable-object
Test run on 2 samples: https://batch.hail.populationgenomics.org.au/batches/431698 used 1Gb of storage; so anticipate storage must be at least 50Gb for 100 samples, have added a storage param so we can modify it if we use this script to merge different number of samples.


Bug - Galaxy in a Galaxy on workflow search

The workflowsearch widget (and import workflows in tutorial headers) is amazing, but when accessed from tutorial mode, leads to a Galaxy in a Galaxy.
Is there a way for it to first check if its being selected from tutorial mode, and if so, to instead move to the workflow link in the wider Web page, not in the tutorial mode box?

yeah we have a proxy active CSS class that gets attached. someone could use it to fix this


Add minimum rust version

See also: https://github.com/librespot-org/librespot/issues/1033
This adds a nice error message in case the rust-version is too old to compile librespot:
$ cargo build --release
error: package `librespot v0.5.0-dev (/home/sqozz/git/librespot)` cannot be built because it requires rustc 1.62.2 or newer, while the currently active rustc version is 1.62.1

I tried 1.62.1 which also worked fine (just set it higher before to test the warning itself). It is the lowest rustc version available to me it might be possible 1.61.x works too but I've no way to verify this.

Thanks!
Two final points as I gather my thoughts:

In order not to repeat ourselves, let's remove the MSRV from COMPILING.md.

This may be nitpicking but the MSRV probably is not the same for all sub-packages. Some will need 1.61 to compile, others may be lower. If you have the time and interest to find out which is where, then by all means make the MSRV fine-grained per sub-package. If you do not want to then I'd totally understand. In that case let's just set it to 1.61 everywhere and we can update/downgrade later as changes occur, or some smart guys put in a PR because they found out a lower MSRV is OK too.

1. In order not to repeat ourselves, let's remove the MSRV from `COMPILING.md`.

I've removed the hint from COMPILING.md. I was thinking of maybe adding a link to the according line in Cargo.toml but decided against because it actually tells you quite clearly what the issue is. WDYT?

2. This may be nitpicking but the MSRV probably is not the same for all sub-packages. Some will need 1.61 to compile, others may be lower. If you have the time and interest to find out which is where, then by all means make the MSRV fine-grained per sub-package. If you do not want to then I'd totally understand. In that case let's just set it to 1.61 everywhere and we can update/downgrade later as changes occur, or some smart guys put in a PR because they found out a lower MSRV is OK too.

It's totally strange but on a second system I was perfectly able to compile librespot (everything!) with 1.60.0. At least we can be sure that at least 1.60.0 is required because 1.59.0 is not able to meet the rpassword = "^7.0" requirement. OTOH I only see the rpassword-requirement in the top Cargo.toml so I wonder if I might compile the sub-packages wrong? I enter the directory (e.g. "connect") and execute cargo build --release inside it.
Sorry if I'm being stupid, my rust knowledge is very limited.

Looks good to me. Don't know what you did exactly but if the CI passes, I'm happy. I'll merge now, thanks for this.


How do I make client certificates?

This article says, "Client certificates typically are not issued by a third-party CA. Instead, the Personal store of the current user location typically contains client certificates placed there by a root authority. The certificate should have an Intended Purposes value of Client Authentication."
How then do I make client certificates?
Here's an answer to verify that you can add to this article:
Go to your Key Vault, click new, select Generate cert (vs import), and set desired properties. Once its created you can download it and install it to the Local User\My store

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

ID: a5258d97-54db-f748-46bc-50d3162a9bfa
Version Independent ID: bd553e49-d868-c5e5-4b8a-0e1ed6e3ff5c
Content: Secure an Azure Service Fabric cluster - Azure Service Fabric
Content Source: articles/service-fabric/service-fabric-cluster-security.md
Service: service-fabric
GitHub Login: @erikadoyle
Microsoft Alias: edoyle

Thank you for your detailed feedback.  We are looking into the issue, and we will respond when we have more information.

@writex Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate. We will update you accordingly.

@erikadoyle Can you please check and add your comments on this doc update request as applicable

Thanks for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. Though the scope of our feedback channel here on GitHub covers specific documentation fixes, we can help redirect you to the right support channel to get an answer to your question: [reference to alternative product/service or community endpoint]. Because this issue does not relate to documentation, we are closing this issue. #please-close


build(webpack): get access to the region environment variable

Get access to the REGION environment variable
:construction_worker_man: Build
a28c927 - build(webpack): get access to the region environment variable
:house: Internal

No QC required.

All apps that refer to a Telecom product hasn't been changed.
Let me know if you think that all theses configurations must be updated as well or not.
Thanks!

I would have added it everywhere because right now we only have 1 difference but maybe in 1 year we will have 50 differences and it would be hard to keep track of why and where specific code was done :)

I agree with @FredericEspiau this should probably be standard for all apps. Would it make sense to have it directly in our common webpack config ?

Yes it is!
You can refer to the actual configuration from @ovh-ux/manager-webpack-dev-server.
Previous controls panels used to pass the environment via a yarn run start|build:REGION command.
The way that the Public Cloud application is passing the environment variable to the development server configuration is the right way so that's why for all applications who can refer to multiple regions I have submitted this change.
In addition if you refer to the APIs, it doesn't make sense to provide this environment variable for all applications (meaning the telecom one for instance) because all API routes won't exist.


⚠ Bofrost.es has degraded performance

In fef13b8, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1476 ms

Resolved: Bofrost.es performance has improved in ec80b55 after 6 minutes.


Splitting strategies of payment amount in multi path payments

Looking at:
https://github.com/lightningnetwork/lnd/blob/19006b108cbb24502ca7e583607bb501dc48f686/routing/payment_session.go#L221
I see that currently the payment session route planner splits the amount into half if it was too large. While from a CS perspective I find this strategy very reasonable I believe there might be more things to consider.
As discussed with ZmnSCPxj on the Lightning dev mailinglist at: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002418.html there is the chance to use the necessity of splitting a payment to also rebalance ones own channels in order to be better equipped in future to fulfill payment requests. In that post I have referenced a small standalone python code
The main code that splits a payment amount according to ones own channels in an statistically optimal (meaning to provide best locally balanced channels) way boils down to these few lines of code which are easily implemented in go and in LND. Sorry for the weired variable naming - which follows main
# amount that is to be paid.
a = 0.7

# initial balance of channels
b = [0.1*i for i in range(10, 0, -1)]

if (a > sum(b)):
    print("not enough funds to conduct such a payment")
    exit()

new_funds = sum(b) - a

# assuming all channels have capacity of 1 btc
cap = len(b)
nu = float(new_funds) / cap
ris = [1*(float(x)/1 - nu) for x in b]

real_ris = [x for x in ris if x > 0]
s = sum(real_ris)
payments = [a*x/s for x in real_ris]

A strategy could be that if a payment won't go through instead of splitting by two one could use this initial strategy to select amounts and local channels which should be used for those amounts.
I have not simulated the effects of my strategy and did not compare them with your behaviour. However keeping the results of the original research in mind I am confident that the splitting strategy that I propose would result in overall lower routing failure rates on the lightning network.

I should mention that the line ris = [1*(float(x)/1 - nu) for x in b] is a little bit missleading as I multiply by 1 and devide by 1. This is because I assumed the capacity of the channel is 1. so in reality one would have to multiply and divide by the capacity of the channel for which the payment amount is computed.

It is an interesting thought, trying to rebalance channels as you pay. Things to keep in mind with the current implementation are:

There is no upfront planning of how to split the payment. Every time we want to send a new htlc, RequestRoute is called with the outstanding amount. As the return value, it expects a single route for either the total outstanding or a part of that. The code above would need to be adapted to that.
If you pick the amount (based on local channel info) for which you want to start pathfinding and force this through a particular channel, what do you do if it fails to find a route?
If you force paths through particular channels to be sure the rebalancing goal is met, how does this interact with other optmization goals like fee and reliability?
Pathfinding is performed from receiver back to sender.  The amount to send, including fees, is higher. This gives less control over how much your channel balance will actually change. Of course an alternative forward-looking algorithm could be added.

If you pick the amount (based on local channel info) for which you want to start pathfinding and force this through a particular channel, what do you do if it fails to find a route?

There could be several strategies.

Try several paths that start along that channel maybe another path will go through
Exclude that channel Recompute with the adopted payment amount for the remaining channels
Drop down to the current implementation

Regarding the second strategy I would always internally sort / prioritize paths from the most uneven one to the least uneven ones. Meaning if for example the first two channels are able to send the suggested amount and the third channel fails we could take the amount that was supposed to be send on channel 3 to 10 (assuming 10 splits) and distribute it now over channels 4 through 10 or we could distribute it via 4 through 11.

If you force paths through particular channels to be sure the rebalancing goal is met, how does this interact with other optmization goals like fee and reliability?

it doesn't out of the box. But of course one could have a strategy that looks at all of those goals. As rebalancing is usful and currently certainly not free it might make sense to rebalance at least when making a payment. In particular if this is the standard and all nodes act like this overall reliability should at least statistically increase.

The amount to send, including fees, is higher. This gives less control over how much your channel balance will actually change.

I would argue that the fees on single paths are usually less than 1% of the amount to be send along that path and could thus be neglected in the calaculation of the split. If fees are significantly higher we have other problems anyway. Of course one could compute the split not for the payment amount but for the payment amount + 1 or 2 % imaginary fees. Then reduce all computed amounts so that the sum is the actual amount and hope that the fees along each path will finally arrive at the computed split. But I think - in particular with the other considerations that you mentioned - this would be overengineered.

Just dropping the c-lightning plugin that prepares the split adopted to the c-lightning plugin. maybe it helps here to see how it was done for c-lightning: https://github.com/lightningd/plugins/pull/83

Thought this might be relevant with respect to that question: https://arxiv.org/abs/2107.05322

Most likely related to https://github.com/lightningnetwork/lnd/issues/5988 and https://github.com/lightningdevkit/rust-lightning/issues/1276

Thought this might be relevant with respect to that question: https://arxiv.org/abs/2107.05322

Also there is a scala implementation of the fast min cost flow approximation at https://github.com/renepickhardt/mpp-splitter/blob/master/code/scala/mincostflow/heuristic/MinCostFlow.scala
Computing a mcf and dissecting it to parts gives the optimal split (with respect to the selected cost function) this contradicts some of the older thoughts and suggestions in this issue.

I have added code for a piecewise linearized formulation of the problem that runs in less than a second and produces a reasonable approxination to the optimal solution to the same repo. You can find it at:
https://github.com/renepickhardt/mpp-splitter/blob/master/Minimal Linearized min cost flow example for MPP.ipynb
I think that approach - if all engineering details (propper handling of uncertainty network, channel reserves, htlc limits, pruning of piecewise linearized problem, adding fees to the cost function) are included - should be very practical for implementations and as discussed on the mailinglist allow for large payment amounts to be handled

for those not following twitter @C-Otto  has posted a baseic implementation to compute splits on top of lnd even using existing mission control data at: https://github.com/C-Otto/lnd-manageJ/issues/6..
Let me just cross post from my comment at the ldk repo
So far it is only the splitting logic and not the acutal payment loop and sending of onions. He computes a split of 0.5 BTC from his node to mine into 18 onions each of which has a probability higher than 50% to be deliverd. Meaning on the first attampt we can expect far less than half the onions to fail. his split can be seen at: http://web.archive.org/web/20220322080201/https://c-otto.de/rene.txt. As he indicated before the runtime of the solver was some 230 ms
{
  "amountSat" : "50000000",
  "probability" : 2.1549649398107696E-4,
  "routes" : [ {
    "amountSat" : "1000000",
    "channelIds" : [ "726473x703x1", "723312x509x1", "695077x1924x0" ],
    "probability" : 0.7806365608992074
  }, {
    "amountSat" : "1240000",
    "channelIds" : [ "726473x703x1", "725453x2192x0", "693476x1211x1", "607678x1509x1" ],
    "probability" : 0.7832342855787678
  }, {
    "amountSat" : "150000",
    "channelIds" : [ "726473x703x1", "725453x2192x0", "700081x698x1", "695339x624x1" ],
    "probability" : 0.9765214420387514
  }, {
    "amountSat" : "3600000",
    "channelIds" : [ "726473x703x1", "725453x2192x0", "701584x2083x1", "558577x633x1" ],
    "probability" : 0.5628769427691509
  }, {
    "amountSat" : "1400000",
    "channelIds" : [ "726473x703x1", "725453x2192x0", "704776x2087x1", "558568x1324x1" ],
    "probability" : 0.782495149685495
  }, {
    "amountSat" : "2470000",
    "channelIds" : [ "726473x703x1", "725453x2192x0", "727359x1244x0", "633778x1065x0" ],
    "probability" : 0.721747937413449
  }, {
    "amountSat" : "2000000",
    "channelIds" : [ "726473x703x1", "727788x1249x1", "728428x605x1", "704834x1737x4" ],
    "probability" : 0.6813327353327034
  }, {
    "amountSat" : "1530000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "727359x1244x0", "633778x1065x0" ],
    "probability" : 0.8251278610944093
  }, {
    "amountSat" : "4000000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "676072x1060x0", "686282x1219x0", "691162x595x0" ],
    "probability" : 0.5740134573960525
  }, {
    "amountSat" : "4860000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "693476x1211x1", "689644x832x0", "691162x595x0" ],
    "probability" : 0.5006147390405348
  }, {
    "amountSat" : "2200000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "696023x1445x0", "703341x959x1", "703310x168x0" ],
    "probability" : 0.6664443121338184
  }, {
    "amountSat" : "1710000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "696023x1445x0", "717839x1372x2", "673116x1599x3" ],
    "probability" : 0.6797308387358896
  }, {
    "amountSat" : "3200000",
    "channelIds" : [ "726473x703x1", "727924x2119x1", "727724x1365x0", "711388x1010x1", "695339x624x1" ],
    "probability" : 0.5872281922328147
  }, {
    "amountSat" : "3350000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "725718x1671x0", "681034x1665x1", "723869x1660x0", "723869x1660x1" ],
    "probability" : 0.5780281931840187
  }, {
    "amountSat" : "3350000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "725718x1671x0", "693136x794x1", "701684x1234x1", "695339x624x1" ],
    "probability" : 0.5944870013390141
  }, {
    "amountSat" : "10090000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "725718x1671x0", "726475x755x1", "700845x2390x1", "550923x1215x0" ],
    "probability" : 0.31021424023863053
  }, {
    "amountSat" : "1000000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "727359x1244x0", "701970x2117x1", "701584x2093x1", "694267x2038x2" ],
    "probability" : 0.776652821615024
  }, {
    "amountSat" : "2710000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "725718x1671x0", "681034x1665x1", "706688x1385x0", "723785x2343x1", "723869x1660x1" ],
    "probability" : 0.5892691058206754
  }, {
    "amountSat" : "140000",
    "channelIds" : [ "726473x703x1", "727904x1129x0", "725718x1671x0", "689644x832x0", "691162x595x0" ],
    "probability" : 0.9827758955245893
  } ]
}


JQMigrate issue

JQMigrate shows warnings for items like $.isFuction() and $.isArray()
I realize the library itself doesn't have an issue, due to the existence of the dependency lib which will provide a substitution when the methods are actually removed from Jquery - However, implementing it this way causes problems for teams updating to the newest jquery as JQMigrate only shows the first instance of a given warning.  This means InputMask can mask issues during the migration process in other libraries and code.
Rather than using the dependency lib for this purpose, native JS code should be used to prevent interference with Jquery migration efforts.

Hi @SteveDavis-TR ,
Thx for the heads up and accompanied PR.


[Part 1] Tabular: Added TabularPredictorV2

Issue #, if available:
Description of changes:

Added TabularPredictorV2
Numerous internal cleanup and extensibility improvements

Note:

I have various TODO's of logic that I plan to update after a few other major PRs are merged to avoid requiring rebases from other contributors.

This PR is part 1 of the API refactor logic:
Part 1: Majority of logic changes
Part 2: Migrate unit tests to use new API
Part 3: Remainder of logic changes + deprecate old API (Old API incompatible with the more complex logic changes without significant effort)
Part 4: Documentation of new API
Part 5: Removal of old Tabular API
Part 6: Update Text API to align with new API
Part 7: Update Vision API to align with new API
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-768-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/1/index.html

Perhaps we want to explicitly write out here all the common arguments to fit() for each task?
Also all the common instance-methods & attributes of the Predictor object for each task?

Job PR-768-3 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/3/index.html

Job PR-768-4 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/4/index.html

Job PR-768-5 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/5/index.html

Job PR-768-7 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/7/index.html

Job PR-768-8 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/8/index.html

Job PR-768-9 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/9/index.html

Job PR-768-10 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/10/index.html

Job PR-768-12 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/12/index.html

Job PR-768-14 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/14/index.html

Job PR-768-15 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/15/index.html

Job PR-768-16 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/16/index.html

Job PR-768-17 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/17/index.html

Job PR-768-20 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/20/index.html

Ran PR on automlbenchmark V2 (104 datasets), slightly outperformed mainline (likely due to the stopping metric logic change in NN) and had fewer errors.

Job PR-768-25 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/25/index.html

Job PR-768-26 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/26/index.html

Job PR-768-27 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/27/index.html

Job PR-768-28 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/28/index.html

Job PR-768-30 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/30/index.html

Job PR-768-30 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/30/index.html

Job PR-768-31 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/31/index.html

Job PR-768-31 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/31/index.html

Job PR-768-32 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/32/index.html

Job PR-768-32 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/32/index.html

Job PR-768-33 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/33/index.html

Job PR-768-33 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-768/33/index.html


UI 1264 pm window

Description
Issue link - https://github.com/ko4life-net/ko/issues/141
This pull request introduces whisper chat windows and enhances the server-side functionality for message targeting by adding support for message blocking. Currently, this blocking feature is implemented only on the server side, with the client-side lacking this functionality. We will need to address the client-side implementation of message blocking in a future update when we work on refining the main chat window.
I based the server-side function changes on the PDB of Ebenezer 1310, but the implementation of the private chat windows was done without using assembly code. Therefore, there may be differences, and it is necessary to verify against the client's assembly code.
💔 Thank you!

Awesome! Thanks for the pull-request @xGuTeK 🚀 As also discussed privately, I'll review it possibly on one of the weekends, because currently I'm unfortunately occupied with work.


Recovery flow: email address stays filled in the code field

Preflight checklist

[X] I could not find a solution in the existing issues, docs, nor discussions.
[X] I agree to follow this project's Code of Conduct.
[X] I have read and am following this repository's Contribution Guidelines.
[X] This issue affects my Ory Cloud project.
[X] I have joined the Ory Community Slack.
[X] I am signed up to the Ory Security Patch Newsletter.

Describe the bug
After sending the email in the recovery flow, the email stays filled in the UI, in the code field.
I think people would be quite confused about this, not realising that they need to delete the email address first and then copy-paste the code.
Reproducing the bug
Run the next.js example, do the recovery.
Version
master

I got this problem too.

Any updates on the pull requests?

I cannot reproduce this anymore, is this already fixed on the latest version? I used the next.js SPA example and recovery just worked as expected.

I think this might be related to when you use the returned payload from recovery to populate the fields. I've updated the examples to avoid this and re-fetch the flow data a while back.
https://github.com/ory/elements/commit/85cc97964328ff44488d10b35e385c070f2b2f5f#diff-88bbaecc97b612f9578a168dd4f2749e93c0844283f8c4f58736dc880a2b1e1f

Checking on a customer's deployed UI that has the issue, it appears that the same ID is used for the input field, which makes react not re-render the field and keeps the wrong content. I guess we can easily fix this by constructing a unique ID.


Update README.md

added a line under contributing

remember to ask someone else to merge silver changes and see if they get the same error


Changed _keyExtractor function to fix #51

Changed _keyExtractor function to build item key from image 'uri' and optional 'key' value. Fixing issue #51 .

@soukupl
Looks like an undefined reference breaking the test. .data is an optional property so referencing data.key is causing the issue within column.js

@brh55 hmmm... so maybe moving the key from data to main item as it is with uri? item.data.rui is moved somewhere to item.uri, so I can make this move at the same spot to fix the test issue :)

@soukupl sounds good to me, it seems more of a property of the item rather then meta data 👍.

@soukupl Did you end up figuring this out? Let me know if you need some assistance 👍

@brh55 sorry... was busy :) I will work on it later today and will update or create a new pull request with new code :)

@soukupl actually it looks like just the snapshot is failing, ill need to reset the snapshot and push

woops, looked like a minor change I had to update to the brick instead of the data object. Everything  is good now 👍

@brh55 sorry... we were out for holidays and I was quite busy days before leaving and didn't find a time to "work" on this :)
but I'm glad that it is now resolved :D


Keep record and address new bugs from MariaDB upgrade to 10.6.x

Impact of the bug
WMCore Jenkins and WMAgent
Describe the bug
Sub task of https://github.com/dmwm/WMCore/issues/9241
How to reproduce it
Jenkins will tell
Expected behavior
This issue is just a placeholder. Actual new issues with the MariaDB upgrade will have their own GH issue. We can of course link the new issues to this one though.
Once all the known issues have been resolved, this one can be closed as well and we can start considering upgrading WMAgents to this latest stable MariaDB version 10.6.x.
Additional context and error message
Dependent on Jenkins tests: https://github.com/dmwm/WMCore/issues/10836
and a sub-task of https://github.com/dmwm/WMCore/issues/9241

For the record, these are the 2 new unit tests that failed in master/head last night:
WMCore_t.JobSplitting_t.RunBased_t.RunBasedTest.testMultipleRunsCombine
WMComponent_t.JobSubmitter_t.JobSubmitter_t.JobSubmitterTest.testB_thresholdTest

@goughes if you'd rather have a new GH issue to address those, please go ahead and replace this one by the two new issues.

I forgot to mention that we have 12 new failures in python2 unit tests, they are:
WMCore_t.WMBS_t.JobSplitting_t.SizeBased_t.SizeBasedTest.testExactEvents
WMCore_t.ResourceControl_t.ResourceControl_t.ResourceControlTest.testInsertSite
WMCore_t.WMBS_t.JobSplitting_t.SiblingProcessingBased_t.SiblingProcessingBasedTest.testFilesWithoutOtherSubscriptions
WMComponent_t.JobSubmitter_t.JobSubmitterCaching_t.JobSubmitterCachingTest.testCaching
WMCore_t.WMBS_t.JobSplitting_t.RunBased_t.EventBasedTest.testMultipleRuns
WMCore_t.WMBS_t.JobSplitting_t.RunBased_t.EventBasedTest.testSingleRunsCombineUneven
WMCore_t.WMBS_t.JobSplitting_t.RunBased_t.EventBasedTest.testMoreRuns
WMCore_t.WMBS_t.JobSplitting_t.SizeBased_t.SizeBasedTest.testMultipleFiles
WMCore_t.WMBS_t.JobSplitting_t.SizeBased_t.SizeBasedTest.testMultipleFiles2500
WMComponent_t.JobSubmitter_t.JobSubmitter_t.JobSubmitterTest.testB_thresholdTest
WMCore_t.WMBS_t.JobSplitting_t.ParentlessMergeBySize_t.ParentlessMergeBySizeTest.testMinMergeSize1aNoRunMerge
WMCore_t.WMBS_t.JobSplitting_t.RunBased_t.EventBasedTest.testSingleRunsMultipleLumiCombineUneven

however, it looks like we are very soon going to stop supporting Python2 within WMCore, so I would suggest not to invest any effort on these.

Sure, I will close this one out after I create the new issues. I have a 3rd as well, which I found when deploying my agent.
ERROR 1396 (HY000) at line 1: Operation CREATE USER failed for 'cmst1'@'localhost'
Installing WMAgent Database: wmagent
Checking Server connection...
Connection OK
Done!

/data/srv/wmagent/v1.5.7.pre1/sw/slc7_amd64_gcc630/external/mariadb/10.6.5/scripts/mysql_install_db now creates the cmst1@localhost account. This is due to the default authentication method being changed in 10.4. https://mariadb.com/kb/en/authentication-from-mariadb-104/
Now you can connect via the local socket file without a password by default. It might be worth considering removing passwords for the root and cmst1 accounts due to this. In fact, if you install an agent now, it never sets a password for the cmst1 account and everything still works. There are some good points in the link above about why setting a password doesn't make that much sense when connecting via localhost.

I made this issue for WMComponent_t.JobSubmitter_t.JobSubmitter_t.JobSubmitterTest.testB_thresholdTest: https://github.com/dmwm/WMCore/issues/10953
For WMCore_t.JobSplitting_t.RunBased_t.RunBasedTest.testMultipleRunsCombine, it looks like that one is flapping for as long as Jenkins remembers. https://cmssdt.cern.ch/dmwm-jenkins/job/DMWM-WMAgentPy3-TestAll/SLICE=6,label=cms-dmwm-cc7/530/testReport/junit/WMCore_t.JobSplitting_t.RunBased_t/RunBasedTest/testMultipleRunsCombine/history/
I just ran this same test with MariaDB 10.1.21 in an old container and was able to reproduce the inconsistent test results. Shall we leave that one alone then @amaltaro?

@goughes Erik, if we have the remaining python3 issues tracked in a different GH issue, shall we close this one out?

The remaining pieces are tracked in separate issues. I think we can close this out and open new issues is anything pops up when you deploy the remaining FNAL agents.


Add code coverage

Codecov's maven plugin can only run in Java 8.

[ ] Downgrade to Java 8
[ ] Readd codecov

Added in #24


Remove "sharesqueaks" message

It probably shouldn't exist.

https://github.com/yzernik/squeaknode/pull/959


Update main_workflow.ga

edited to the working version

updated everything

could we merge this?

when i moved it the checks failed for me

I think I fixes all the issues

The bot will add it back in the correct spot I think.


Import cloudflare_tunnel got 'missing an identifier during ImportResourceState'

Confirmation

[X] This is a bug with an existing resource and is not a feature request or enhancement. Feature requests should be submitted with Cloudflare Support or your account team.
[X] I have searched the issue tracker and my issue isn't already found.
[X] I have replicated my issue using the latest version of the provider and it is still present.

Terraform and Cloudflare provider version
Terraform v1.4.5
on darwin_amd64

provider registry.terraform.io/cloudflare/cloudflare v4.37.0
provider registry.terraform.io/hashicorp/aws v4.25.0

Affected resource(s)
cloudflare_tunnel
Terraform configuration files
resource "cloudflare_tunnel" "default" {
  for_each = local.tunnel_spec[terraform.workspace]
  account_id = var.account_id
  name       = each.key
  secret     = each.value["secret"]
}

locals {
  tunnel_spec = {
    default = {
      test1 = {
        secret = var.test1_secret
        network = "<IP_ADDRESS>/16"
      }
    }
  }
}

Link to debug output
No
Panic output
No response
Expected output
import sucessfully
Actual output
Error: The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers.
Steps to reproduce
terraform import 'cloudflare_tunnel.default["test1"]' <account_id>/<tunnel_id>
Additional factoids
No response
References
No response

Here is the output of TF_LOG=DEBUG:
2024-07-15T17:35:42.251+0800 [DEBUG] provider.terraform-provider-cloudflare_v4.37.0: Set-Cookie: __cfruid=b08548f47f82237a4c2672cfdd81d10986da20c8-1721036142; path=/; domain=.api.cloudflare.com; HttpOnly; Secure; SameSite=None
2024-07-15T17:35:42.251+0800 [DEBUG] provider.terraform-provider-cloudflare_v4.37.0: Vary: Accept-Encoding
2024-07-15T17:35:42.251+0800 [DEBUG] provider.terraform-provider-cloudflare_v4.37.0:
2024-07-15T17:35:42.251+0800 [DEBUG] provider.terraform-provider-cloudflare_v4.37.0: {"success":true,"errors":[],"messages":[],"result":null}
2024-07-15T17:35:42.251+0800 [ERROR] provider.terraform-provider-cloudflare_v4.37.0: Response contains error diagnostic: tf_proto_version=6.6 tf_provider_addr=registry.terraform.io/cloudflare/cloudflare tf_req_id=ac766965-6e5e-5053-e631-309eb4c066c5 tf_resource_type=cloudflare_tunnel diagnostic_detail= diagnostic_severity=ERROR diagnostic_summary="The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers." tf_rpc=ImportResourceState @caller=github.com/hashicorp/terraform-plugin-go@v0.23.0/tfprotov6/internal/diag/diagnostics.go:58 @module=sdk.proto timestamp=2024-07-15T17:35:42.251+0800
2024-07-15T17:35:42.252+0800 [ERROR] vertex "cloudflare_tunnel.default (import id "/")" error: The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers.
2024-07-15T17:35:42.252+0800 [ERROR] vertex "cloudflare_tunnel.default (expand)" error: The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers.
2024-07-15T17:35:42.253+0800 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = error reading from server: EOF"
2024-07-15T17:35:42.256+0800 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/cloudflare/cloudflare/4.37.0/darwin_amd64/terraform-provider-cloudflare_v4.37.0 pid=95204
2024-07-15T17:35:42.256+0800 [DEBUG] provider: plugin exited

@hansqiu68 can you post the full output log in a gist rather than just a snippet of it.


⚠ Bofrost.at has degraded performance

In cdf1688, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1789 ms

Resolved: Bofrost.at performance has improved in c3b2186 after 14 minutes.


With threading enabled, small matrix gemm performance gets worse.

As @oon3m0oo has reported, small matrix gemm < 32x32, which should not be affected by threading get slower with pthreads as well as OpenMP.

using strace on a small matrix multiply shows that we do
openat(AT_FDCWD, "/sys/devices/system/cpu", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3</sys/devices/system/cpu>
fstat(3</sys/devices/system/cpu>, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(3</sys/devices/system/cpu>, /* 38 entries /, 32768) = 1128
getdents(3</sys/devices/system/cpu>, / 0 entries /, 32768) = 0
close(3</sys/devices/system/cpu>)       = 0
sched_getaffinity(5432, 8, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]) = 8
fstat(0</dev/pts/0>, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(1</dev/pts/0>, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
fstat(2</dev/pts/0>, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
openat(AT_FDCWD, "/sys/devices/system/cpu", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3</sys/devices/system/cpu>
fstat(3</sys/devices/system/cpu>, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents(3</sys/devices/system/cpu>, / 38 entries /, 32768) = 1128
getdents(3</sys/devices/system/cpu>, / 0 entries */, 32768) = 0
close(3</sys/devices/system/cpu>)       = 0
sched_getaffinity(0, 8, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]) = 8
for each... which is likely part of the extra cost.

@fenrus75  Is this only for when threading is enabled or is this the dynamic dispatch logic in general?

@oon3m0oo

Pretty sure this cpu enumeration happens only once on (any) startup. Trying to identify the various callers of YIELDING now - setting a breakpoint on sched_yield() with gdb seems to hit only once per thread, but adding a printf to the macro generates several lots of output - maybe I am using gdb wrong.

All calls to sched_yield() (in benchmark/sgemm.goto 30 30 1) appear to originate from https://github.com/xianyi/OpenBLAS/blob/2f957947a6ed0712f13c8ff97a6ff60c60d6e1e0/driver/others/blas_server.c#L319-L320
in blas_thread_server()  waiting for the thread_status[cpu].queue to change

level3_thread.c also emits many sched_yield calls; I'm seeing many of them come from there.  At least, when I replaced sched_yield with __builtin_ia32_pause suddenly inner_thread was in the top 3 in my profile, since the profiler seems to count the pause as time.

level3_thread is not called for small matrices, I am just trying to find what the other, supposedly dormant threads are up to while one is busy with the "single-threaded" gemm for 30x30. Apparently entering YIELDING again and again is not a good idea, but I have no idea how to turn this into something based on pthread_cond_wait() or whatever... It seems libGoto2 was not designed for situations where not all threads are busy, and the various nthreads=1 kludges added much later did not address the scheduling, they only avoid splitting a small problem into even tinier chunks.
I have tried using openblas_set_num_threads(), but this can only add additional workers to the pool
created on initialization.

I've identified the root cause of the slowdown.  When SMP is defined, blas_memory_alloc does a large amount of locking and unlocking.  Adding:
#undef LOCK_COMMAND
#define LOCK_COMMAND(a)
#undef UNLOCK_COMMAND
#define UNLOCK_COMMAND(a)

before the definition of blas_memory_alloc in memory.c, and all that extra time goes away for small matrices.  Obviously we don't want to do this when we're actually using threads, but I believe this is the culprit. Each call to gemm (with matrix size 4) is causing 14 lock/unlock pairs (13 in alloc, 1 in free), which seems excessive.

I had already limited the use of locks to the non-OpenMP case in #1468 . Without them OpenBLAS would be back at the racy 0.2.19 stage as mentioned above, but perhaps it would be possible to use fewer locks around larger sections of the code. Not sure if/how blas_memory_alloc could act differently with a knowledge that only a single thread is truely active.

I'm wondering if some things here might be usable as thread-local, such as memory, release_info, etc.  The dynamic initialization still needs to be global, but I think there's a better way to ensure one-time initialization than locking on every allocation.  Have you tried this before?  I'm happy to spend some time seeing if I can make it fast while keeping it safe.

I never tried this, and am not aware of anyone who has.

while mutexes are not cheap, in single threaded mode there shouldn't be any
contention so surprised this shows up at all....
On Tue, Jun 12, 2018 at 4:01 AM Martin Kroeker<EMAIL_ADDRESS>wrote:

I never tried this, and am not aware of anyone who has.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xianyi/OpenBLAS/issues/1614#issuecomment-396550707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPeFVTQiDWd_WoSEZv3OLLpTS14Q7MRks5t75-LgaJpZM4UjDzB
.

Not sure what "single threaded mode" is in this OpenBLAS context - the gemm interface keeps the work all in one thread if the matrix is small, but initialization created a thread pool (with each thread doing its blas_memory_alloc) earlier and the other threads are spinning sched_yield(). Maybe I just got tricked (by helgrind) into adding lots of locks around code that cannot develop races in any case - but if this was the full story, shouldn't 0.2.19 and earlier show much smaller difference between single-threaded build and multihreaded running with OPENBLAS_NUM_THREADS=1 ?

Returning to that while(!tscq) {YIELDING in blas_server.c , that section of the code seems to want to check if it is time for an idle thread to go to sleep. Is deriving the elapsed time from the TSC the right tool for this job ? Is the compile-time constant THREAD_TIMEOUT of 1 << 28 (not 1<<26 as suggested in Makefile.rule) or 100(?) milliseconds appropriate ? Should the gemm interface itself send the excess threads to sleep when it wants to go single-threaded, and wake them up when it is done ? Clearly reducing the THREAD_TIMEOUT to values below 20 reduces the number of  pointless calls to sched_yield() as the idle threads quickly end up in pthread_cond_wait().

the sad part is that glibc has a flag you can set on the pthread locks/etc
that makes glibc spin an appropriate amount of time
normally apps then don't have to do their own spinning on top ;-)
100 msec is forever for spinning though. The other sad part is that a
sched_yield() is approximately as expensive as just waking up from a
cond_wait()
(at least in terms of order of magnitude and the work they do in the
process scheduler)
On Tue, Jun 12, 2018 at 3:39 PM Martin Kroeker<EMAIL_ADDRESS>wrote:

Returning to that while(!tscq) {YIELDING in blas_server.c , that section
of the code seems to want to check if it is time for an idle thread to go
to sleep. Is deriving the elapsed time from the TSC the right tool for this
job ? Is the compile-time constant THREAD_TIMEOUT of 1 << 28 (not 1<<26 as
suggested in Makefile.rule) or 100(?) milliseconds appropriate ? Should the
gemm interface itself send the excess threads to sleep when it wants to go
single-threaded, and wake them up when it is done ? Clearly reducing the
THREAD_TIMEOUT to values below 20 reduces the number of pointless calls to
sched_yield() as the idle threads quickly end up in pthread_cond_wait().
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xianyi/OpenBLAS/issues/1614#issuecomment-396757105,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPeFc-x0TZU0icp3hTC2x1R00FqkSmrks5t8EM3gaJpZM4UjDzB
.

Created #1618.

Merged #1618.

This seems to have caused some regressions on small matrices on ARM64 in single threaded mode. @oon3m0oo and I are investigating.

Seems to me you introduced a lock/unlock in single threaded mode around line 1023 (which was previously in an #ifdef OPENMP section) ?

My late-night blunder with the CannonLake cpuid patch also makes me realize we have grown a build warning on the windows/mingw platform:
memory.c:433:15: warning: thread attribute directive ignored
memory.c:434:1: warning: thread attribute directive ignored
memory.c:977:15: warning: thread attribute directive ignored

and potentially more seriously with gcc on both Linux and Windows,
memory.c: In function blas_memory_free:
memory.c:1149:13: warning: array subscript is above array bounds

(and also a "cast to pointer from integer of different size" in blas_server_win32.c:506:30 that could be
related)

I don't think there's a new lock, it's only hit a single time, the first time threads hit this routine.  After that the if will fail and you don't lock.
Also, I've got a patch in the works that will reduce this down to a single TLS index (which should help with Android), and should resolve these two, and makes it easier to emulate for arches which don't support TLS like this.
If you'd rather revert the original patch first, that's ok by me.

Depends on the timeframe you envisage for the patch - as the issue does not appear to be catastrophic I guess we can live with a slowdown on one platform for a few days. Not sure about the bounds check warning yet, could be a false positive from gcc.

I've put up #1625 which ought to resolve this, though I'll let the automated builder check a few thing for me.

I can confirm that this has been fixed.


Keep handling OTEL_EXPORTER_OTLP_SPAN/METRIC_ENDPOINT

Now that 0.17.0 renamed the final environment variables, we need to handle the old ones as deprecated:

Check  OTEL_EXPORTER_OTL_SPAN_ENDPOINT and if there's any value set, pass it to OTEL_EXPORTER_OTLP_TRACES_ENDPOINT. In case they are both set, give preference to the TRACES one*
Do 1) for Metrics (less important as we are hiding that for now).

*Maybe we can do some logging for that, but that can be done in a future PR (if/as needed).

we cannot pass any value to OTEL_EXPORTER_OTLP_TRACES_ENDPOINT because it's not supported by java to set env variables.
otel.exporter.otlp.endpoint system property is used to pass endpoint. It's common for trace and metrics exporter:

https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/MetricExporterConfiguration.java#L59
https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk-extensions/autoconfigure/src/main/java/io/opentelemetry/sdk/autoconfigure/SpanExporterConfiguration.java#L73

As discussed today, let's support _SPAN_ENDPOINT only for now.

handling is implemented


[run_process_replay] linearizer: fix get_grouping_dims to respect global/local max

Not sure if this was intentional but looks like it also cleverly reorders indexing ALUs based on scope!
https://github.com/tinygrad/tinygrad/actions/runs/9521487566/job/26249009174#step:23:55
But the process replay output mixes up these changes with lidx starting at 0
https://github.com/tinygrad/tinygrad/actions/runs/9521608695/job/26249418646#step:23:50
can you keep it as before to separate signal from noise in the process replay diff?

cool, thanks @flammit!
would you wanna get this merged or delete the old way here too?

cool, thanks @flammit! would you wanna get this merged or delete the old way here too?

probably better to merge this as is, then I'll push another PR that changes the behavior and we can verify the benchmarks on that?
gimme a bit though - I'm gonna retest unet3d so make sure @francislata's issue is resolved.

@Qazalin looks like unet3d worked fine.  rebased to master and good to merge if you don't see any other issues.
I'll post a separate, follow-on PR tomorrow to do the behavioral changes that are not replay safe (direction of variable indexing and which side of the sizes (.x or .z) to accumulate extra dims into first.


Add Piped installation link to user guide index

What this PR does / why we need it:
Add the link to piped installation guide to user guide index page

Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

What a nice idea. 👍
/lgtm

Holy moly!
/approve


fix tmpreaper to delete puppet reports

tmpreaper need to be called through bash in order to work with cron, so doing
it.

please test this

Test FAILed

please test overcloud

please test this

Test PASSed

please test this

Test FAILed

please test this

Test PASSed


Show error message on mismatched password for keystore file creation

How should this work exactly? :pensive:


BCMOHAD-14077||Added New Report

Deployment Tracker :
Report : MAiDCaseManagementReports/S7_2023_HC_ReportDied_Prior_XPB

@ahshaik1 Also this PR has two files but you listed only one file in the deployment tracker. Can you fix or explain why? Thanks!


Can not init vue project with arco-cli

[x] I'm sure this does not appear in the issue list of the repository

Basic Info

Package Name And Version: @arco-design/arco-design-pro-vue
System: Mac
Browser: Chrome
Reproduction Link: https://github.com/arco-design/arco-design-pro-vue

What is expected?
Can create arco design pro vue
Steps to reproduce
npm i @arco-design/arco-cli@latest yarn -g
arco init my-project

can not see - Arco Pro 项目

It works now, please close this issue

It works now

It works now

Have a good time！


Buffers list window in tree view mode doesn't work on Windows

using it on a Windows 10, PowerShell 7.4.6.
With tree mode, vessel doesn't show any buffer on the list:

if mode is flat, it doesn't display the basename only (not sure why the 3rd is correct):

Noted.. I'll try testing on a window installation and will report back

I can help with logs, if you guide me

I think I can manage, thanks!

hey, I submitted a PR that addresses this issue on Windows, and another issue with displaying basenames also on Windows. https://github.com/gcmt/vessel.nvim/pull/12

Thanks for putting in the time Rui! I've been real busy these weeks and barely had the time to set up a window vm to fix it myself. I'll test it as soon as possible.

hey, no problem. It fixes the issues I have on Windows, but I'm only using the bufferlist. I guess it could be fixed more generically instead of the detail fixes on my PR. The problemm is around the use of \\ as a separator on Windows file paths.


Show labels using 4 color theorem

🚀 Feature
Give the possibility to show labels colors using 4 color theorem (https://en.wikipedia.org/wiki/Four_color_theorem)
Motivation
This is really convenient when two touching objects with different labels are randomly given the same color which makes think a segmentation failed.
Pitch
Would it be possible to give the possibility to use this representation? An implementation of this theorem is already available at: https://pypi.org/project/ncolor/. So I think it would not be very costly to add as a feature.

This is really convenient when two touching objects with different labels are randomly given the same color which makes think a segmentation failed.

I don't think this should happen anymore after 0.4.19 is released.
Still labels could have similar colors which would make discerning objects difficult.
So I like this idea quite a bit as a toggle-able mode?

Yes the idea would be to switch between the two modes, so users can choose.

I don't think this should happen anymore after 0.4.19 is released.

I think that it still could happen. 0.4.19 will resolve consistency between the color picker and the color visible on the canvas. It will not solve the problem of casing the same color for two touching objects.

An implementation of this theorem is already available at: pypi.org/project/ncolor. So I think it would not be very costly to add as a feature.

for many use cases, this steep will be really costly. And will be not possible to apply to chunked data.
This issue is partially related to #6449

@Czaki ncolor is very fast on typical label matrices, but I agree that it should be compatible with chunked data if it were to be integrated into napari. I'm open to pull requests on that front if anyone wants to work on it. That said, @koopa31, it might make more sense to make a plugin for ncolor instead.

@kevinjohncutler Because of performance reasons, we do not even calculate min/max on enough big data.
The algorithm that will reconstruct the connection graph cannot be faster.
Also, it may happen that there will be few distinct. component with a single number that breaks the assumptions of 4 color theorem.

It's funny, I was just thinking about this yesterday. But, another issue is that in napari we deal with multidimensional images, which breaks the four color assumption — for example, if you are tracking cells, they might not touch in one frame but then touch in a later frame.
My instinct is the same as @kevinjohncutler — this functionality could/should go in a plugin, which would take in a labels layer, apply the 4-color theorem, and then apply direct color mode to the layer with the computed colors. (And I'll note that we do plan for plugins to be able to contribute to menus, potentially including right-click menus, in the near future, so this plugin would be much more easily accessible.)
After fixing #6448 (will happen before 0.4.19), it should be possible to check on touching labels after 1-2 shuffles.
Given all this, and the fact that we have a lot of work to do optimising labels rendering in general, I'm inclined to close this as wontfix... But I am happy to leave it open for a bit for further discussion.


fix: emit errors that happen before open event

While using this library I noticed that network connection errors are currently not emitted or throw on new Client(addr). An example of this is a 500 http status code from the server. After some digging I realized that is because WebSocket connection errors that are emitted before the open are not surfaced to the serverless client.

Can I ask why you closed this?

Yeah I was working through a bug on my own code and I believe I opened this when I still didn't quite understand the problem 100%. I wasn't sure if this PR actually did anything so wanted to close before anyone spent time on it. I will reopen if I can confirm the issue.

OK, thanks.


Disable global overwriting

It may make sense for the polyfill here to only write to window.SystemPolyfill and not create a window.System. Because this project always requires functionality built on top of it to create a useful loader, these specific loader implementations can then handle the global assignment cases.
This is in line with this project being a starting point for loader construction over something end-users use directly.

Or would it make sense to, rather, for this polyfill to be a no-op if System.loader, Reflect, etc. are already implemented?

@joeldenning there may be implementation differences in some cases so that the polyfill may still be desired over native implementations if there happen to be any implementation gaps. Just like how Promises had better perf and rejection handling through polyfills until the native implementations caught up. Providing an alternative polyfill global in some form is useful for these sorts of scenarios.

The 1.0 release provides no global setting.


Uncaught TypeError: Cannot read property 'isHorizontal' of undefined at Swiper.getTranslate

Hello,
I use the package from npm, I think i have the latest version. After setup a slider, everything seem be good. But when I swipe the slider, this error be alerted. How can I fix it?
Uncaught TypeError: Cannot read property 'isHorizontal' of undefined
at Swiper.getTranslate (swiper.esm.bundle.js?41d6:910)
at Swiper.loopFix (swiper.esm.bundle.js?41d6:1333)
at swiper.autoplay.timeout.Utils.nextTick (swiper.esm.bundle.js?41d6:5939)
Thank you for helping.

I'm experiencing the same error, but with autoplay: on and loop: true. The error is happening when the slide is supposed to switch automatically.
Did you find a solution?
If I set loop: false it works.

I have a similar error and I use the built dist file, so missing build files shouldn't be an issue in my case. I have the problem only while looping. Line 934 throws an error because it tries  win.getComputedStyle(el, null) on an undefined element since in function  loopFix it calls getTranslate() without parameters.

@david-treblig

I have a similar error and I use the built dist file

esm files in dist folder are also must be transpiled. If you use transpiled umd version then please provide a JSFiddle or live example with the issue

I think my issue is different, now that I've looked at it further. I have this on a live website right now : http://patrimoinecotedebeaupre.com. The rotating images in the header are a Swiper instance as well, but the one causing the issue is the one down where it says "Type architecturaux". It only does this when I activate "loop" which I had disabled untill I'd find an answer, but I reactivated it for demonstration purposes.
Both the header swiper and this one are initialized on load. The problematic one is initialized like this :
new Swiper('.block-tax-slider', {
    direction: 'horizontal',
    loop: true,
    slidesPerView: 4,
    spaceBetween: 46,
    speed: 750,
    autoplay: {
        delay: 7000,
        disableOnInteraction: false
    },
    navigation: {
        nextEl: '.tax-slider-button-next',
        prevEl: '.tax-slider-button-prev',
    },
    breakpoints: {
        768: {
            slidesPerView: 1,
        },
        1280: {
            slidesPerView: 2,
        },
        1440: {
            slidesPerView: 3,
        }
    }
});

The error triggers once on autoplay navigation, on every click prev / next navigation and on every single movement of the drag or swipe. I was wondering if placing my nav elements outside the main container was the issue, but it doesn't seem to be the case. I've tried to replicate the issue in a JS Fiddle with the same init values and it won't reproduce... -_-x  (https://jsfiddle.net/w2pmhqed/18/). I'm really scratching my head over this one!
The fact is that nothing is broken... everything works as expected. It's just reporting that the $wrapperEl is not an instance of Element once every two calls. It's happening in the loopFix function on swiper.getTranslate()...

same errors on every slides where I set the options as the following:
slideOptsOnlyExternal: SwiperOptions = {
    allowTouchMove: false
};

I had the similar issue with the swiper at :
Uncaught TypeError: Cannot read property 'autoplay' of undefined
at custom.js:495
I got this issue when using multiple sliders.


Develop

@froster82 I need one more translation:
https://github.com/pachi81/GlucoDataHandler/pull/122/files#diff-0908d478f1e1608a4d8bf0d6e84f3c23dd963a61f2ff17a7984af7e3e9f938d1
Thank you.

@pachi81, line 293 done.


Pans – make ansistype 1..1

decision not to worry about enforcing mandatory restrictions, unless they were already in ontology v1 or without it the Thing could not exist as x without the restriction on a certain property


Write original version in YAML

It is common use to write specifications in YAML (either directly JSON Schema or using a higher abstraction such as LinkML) and then have a generated JSON version of the schemas for referencing. Also, before v2.0.0-draft.4 the unified OpenAPI schema had been written in YAML - the move to write-in-JSON had not been fully transparent.
My strong recommendation here is to follow VRS:

The machine readable VRS is written using JSON Schema.
The schema itself is written in YAML (vrs.yaml) and converted to JSON (vrs.json).
Contributions to the schema MUST be written in the YAML document.

There are several advantages:

readability
easier editing
use of structured inline documentation (e.g. descriptions w/ bullet points, lists...) using inlined Markdown (or plain multi-line text)
error-checking during .yaml -> .json conversion
...

As a reminder: YAML is a superset of JSON; so anything written in JSON Schema can always be expressed in YAML.
The best option would be to do the rewrite (which is basically a converter run & some clean-up - we're maintaining our Beacon schemas in YAML...) together with a repository merge.

We've heard and noted your preferences Michael, but IMU we've decided to use Json Schema in one of the initial meetings. So far, I've seen no strong preferences in our community to one or another solution. But we have one already and I see your points above but my own experience with the conversion is that it is not as straigthforward and it requires manual editing. The potential overhead and side effects of switching at this point in time, when we are rushing to finish all pending stuff overruns the benefits above.
We can, of course, engage in the discussion again after v2.0 is approved.

But the point is that the "we do JSON Schema" means "we write it in YAML" (as one does). "JSON Schema written in .json file format" is ... unusual.
I agree that all the current PRs should be handled w/ the current code base; but that we should have a clear path towards

a unified repo (more important)
move to JSON Schema in .yaml w/ .json output branch (c.f. VRS).

The transparent conversion from YAML to JSOtN Schema should be tested before we decide any transition, so we control de potential side effects. If we prove that is sideeffect-less, I have no big concerns in doing as you suggest. Again, I suggest trying that once we are done with all the pending tasks.
The conversation about repos should continue in the relevant issue, or we would be confusing the flow of such conversation.

@jrambla Re structure: Only mentioning this here as "YAML is a standing topic but write in .yaml or .json isn't so relevant technically as other topics" ¯\_(ツ)_/¯

There has been agreement on the Beacon call 2022-05-10 to move ahead w/ YAML in unified repo; closing this.


using Object.prototype.hasOwnProperty.call instead of .hasOwnProperty to prevent prototype pollution vulnerability

UsingObject.prototype.hasOwnProperty.call instead of <object>.hasOwnProperty to to check if a property exist in an object
This also fixes a security bug "Prototype Pollution" using "hasOwnProperty"
This vulnerability causes the addition or modification of an existing property that will exist on all objects and may lead to Denial of Service or Code Execution under specific circumstances.
example exploitation:
await db.set("hasOwnProperty", "this will cause breakage to the application");
await db.has("somekey"); // Throws an error `db.hasOwnProperty is not a function`

Codecov Report

Merging #8 into master will not change coverage.
The diff coverage is 80.00%.

@@           Coverage Diff           @@
##           master       #8   +/-   ##
=======================================
  Coverage   52.33%   52.33%
=======================================
  Files           2        2
  Lines         107      107
=======================================
  Hits           56       56
  Misses         51       51

Impacted Files
Coverage Δ

src/jsoning.js
51.42% <80.00%> (ø)

Continue to review full report at Codecov.

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

This issue has been fixed, thanks @oadpoaw: https://github.com/khalby786/jsoning/commit/8d17ef7f805341dcad95b4b523c3e83828a02bce


Added ease of access features

Added ease of access features for command creation and initialization. I'm not sure if I had to edit the cmake files but I assume I don't have to since I was just adding an hpp file

Feel free to request a link and mention of this as a separate wrapper on our discord #resources channel.


ERROR in bundle.js from UglifyJs

Hello!
During the build with webpack
SyntaxError: Unexpected token: operator (>) [./~/sec-to-min/index.js:3,0]

UglifyJs doesn't support ES6.


[WFLY-13088] Ejb binding should not be listed if there is no Remote i…

https://issues.redhat.com/browse/WFLY-13088

Can one of the admins verify this patch?

@tadamski , @chengfang could you please review this.
Thanks.

Thanks!


Links privacy attributes from main object's attributes (remarks, event, etc.) use the same configuration from their parent object

The user can configure the privacy for the attributes from the main objects (domain, nameserver, ip, autnum). These attributes include some of the following: handle, entities, status, lang, remarks, events, links, etc. In a similar way, some of these attributes (remarks, events, links) have attributes which privacy settings could be configured too (for example: lang, description, title, links(again), etc).
However, there is a third level of attributes: the attributes of attributes of attributes of an object (for example, the attributes from link attribute from remark attribute from domain object). In this case, the user cannot configure these last attributes privacy settings because the rdap server assume the configuration for the attribute with the same name in the parent level (for example, using the privacy settings for links attributes from domain object instead of requiring a specific setting for links attributes from remark attributes from domain object). This assumption is invalid because the user may want to hide the links from a domain object and display the links for the remarks from a domain, and not only to hide every link in all the hierarchies.
The list of all the attributes that requires a way to configure their own privacy:

domain.events.links
domain.remarks.links
domain.secureDNS.dsData.events
domain.secureDNS.dsData.events.links
domain.secureDNS.dsData.links
domain.secureDNS.keyData.events.
domain.secureDNS.keyData.events.links
domain.secureDNS.keyData.links
nameserver.events.links
nameserver.remarks.links
ipnetworks.events.links
ipnetworks.remarks.links
autnum.events.links
autnum.remarks.links

The missing configuration was added to the latest commit in devl-it07 branch

Verified. Every privacy configuration file allows to define the privacy for every attribute and object, including the deepest levels such as object's event links.


Devstats showing inactive?

Checking in here, Devstats is showing your project as inactive in the past 90 days.
(https://all.devstats.cncf.io/d/53/projects-health-table?orgId=1 )
If this is an error, we can help get you updated!
If it's accurate, can we help? The Technical Oversight Committee is beginning to review inactive projects, and we want to make sure that we're getting good data for them.
Please make sure that you update your developer affiliation data accurately via https://github.com/cncf/gitdm?tab=readme-ov-file#addingupdating-affiliation and openprofile.dev - so we have an accurate representation of what organizations are contributing to CNCF projects. You may also want to update maintainers.cncf.io to reflect the latest list of maintainers for your projects.
Let us know how we can help!

Wonderful - let's get a pull request back into devstats to resolve this:
https://all.devstats.cncf.io/d/53/projects-health-table?orgId=1 shows 113 days since your last commit.

closing this towards teller 2.0


Warning from newlib/include/sys/cdefs.h

As discussed in this issue (https://github.com/dvidelabs/flatcc/issues/77#issuecomment-363529004), when compiling c files:
In file included from ./lib/flatcc/include/flatcc/flatcc_flatbuffers.h:24:0,
                 from ./lib/flatcc/include/flatcc/flatcc_builder.h:68,
                 from ./lib/flatcc/src/runtime/builder.c:21:
./lib/flatcc/include/flatcc/portable/pstdalign.h:48:0: warning: "_Alignas" redefined
 #define _Alignas(t) __attribute__((__aligned__(t)))
 ^
In file included from /esp-idf/components/newlib/include/stdlib.h:19:0,
                 from ./lib/flatcc/src/runtime/builder.c:16:
/esp-idf/components/newlib/include/sys/cdefs.h:281:0: note: this is the location of the previous definition
 #define _Alignas(x)  __aligned(x)
 ^
In file included from ./lib/flatcc/include/flatcc/flatcc_flatbuffers.h:24:0,
                 from ./lib/flatcc/include/flatcc/flatcc_builder.h:68,
                 from ./lib/flatcc/src/runtime/builder.c:21:
./lib/flatcc/include/flatcc/portable/pstdalign.h:49:0: warning: "_Alignof" redefined
 #define _Alignof(t) __alignof__(t)
 ^
In file included from /esp-idf/components/newlib/include/stdlib.h:19:0,
                 from ./lib/flatcc/src/runtime/builder.c:16:
/esp-idf/components/newlib/include/sys/cdefs.h:288:0: note: this is the location of the previous definition
 #define _Alignof(x)  __alignof(x)
 ^
CC build/request_manager/lib/flatcc/src/runtime/json_parser.o
In file included from ./lib/flatcc/include/flatcc/flatcc_flatbuffers.h:24:0,
                 from ./lib/flatcc/include/flatcc/flatcc_builder.h:68,
                 from ./lib/flatcc/include/flatcc/flatcc_json_parser.h:20,
                 from ./lib/flatcc/src/runtime/json_parser.c:2:
./lib/flatcc/include/flatcc/portable/pstdalign.h:48:0: warning: "_Alignas" redefined
 #define _Alignas(t) __attribute__((__aligned__(t)))

And the esp-idf file at which has the other definition:
https://github.com/espressif/esp-idf/blob/master/components/newlib/include/sys/cdefs.h#L273-L289
The library author suggests this is an esp-idf issue:

it is an issue with cdefs because it doesn't check if __alignas_is_defined is defined
https://github.com/dvidelabs/flatcc/issues/77#issuecomment-363530016

And I guess that file needs to be modified to #define __alignas_is_defined, and also check if it is already defined to avoid redefining?

The underscore prefix is reserved (by the C standard) for compiler & system libraries. Newlib is the system C library for ESP-IDF.
We can't stop application code from defining names with underscore prefixes. However the point of having a reserved namespace is that the system can define these names without having to do checks for use of these names outside the compiler & system libs.
I had a look at the issue and I understand that the flatcc author is working around some stdlibs which don't set some of these macros.  From a quick look, I think the best solution would be that pstdalign.h should directly include system stdalign.h, which will define whatever the system libc defines on that platform. After this in pstdalign.h it's then safe to use #ifndef checks to define any macros that may be missing in that system stdlib implementation, without the possibility of stepping on the system libc's toes.
Note this isn't specific to ESP-IDF, upstream newlib has this behaviour so any newlib-based system will experience this:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/sys/cdefs.h;h=fc564a5c602be4d328e525dd5f19e4ee58bb4406;hb=HEAD#l280
(Maybe glibc doesn't do this, I can only guess why or why not...)

Feel free to reopen if you think I'm misinterpreting the C standard or the problem here.
However in general if there's a conflict between the compiler & system libraries and a non-system library over an underscore-prefixed name, for better or worse it's the non-system library which has to adapt to this.

OK thanks for your attention! I will mention your suggestions back to the flatcc maintainer.
FWIW I am able to workaround the problem in the interim by adding to CFLAGS for the specific objects: CFLAGS += -D__alignas_is_defined=1. But I am interested in a cleaner solution.

OK, I'm glad to hear you have a workaround for now!

The thing is the pstdalign.h does include stdalign.h but it cannot do so when it cannot be sure that it is present - in that case it falls back to the library provided defines designed to handle this case.
In my view pstdalign.h, part of the portable library, does take the form of a limited system library, otherwise it couldn't do what it does - provide missing library functionality.
If newlib is sufficiently popular it could be identified by pstdalign, but it is already difficult enough to support broken glibc in different versions and C++ changing behaviour every third year or so. As a fallback users can opt out defining a suitable macro which in this case is __alignas_is_defined.

Hi @mikkelfj ,
Thanks for weighing in here with your perspective on the matter.

does include stdalign.h but it cannot do so when it cannot be sure that it is present

I had another look at pstdalign.h and I see the predicament now.
(BTW one thing I noticed is that gcc 5 or newer seems to always have a C11 compliant stdalign.h bundled with it, but maybe there's an exception to that lurking out there...)
Defining __alignas_is_defined in our libc will not solve this problem, at least without breaking otherwise correct code. The C11 standard says that __alignas_is_defined should be defined in stdalign.h. And for gcc it is: https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/gcc/ginclude/stdalign.h#L26 (same header as our gcc 5.2.0). Maybe we could also include stdalign.h from cdefs.h, but this may have other unintended consequences.
@PerMalmberg , if the workaround you have shows any problems then instead append -std=c11 to the CFLAGS for building the flatcc component only. This should work, as it looks like flatcc's portability library headers are only needed by the implementation not the public interface.

Another workaround might be for the end-user to include stdalign.h before flatcc headers when it is sure that header is present. This still only works if __alignas_is_defined is indeed defined in that header.

@projectgus Thanks for thinking about me, but I think you meant to tag @paulreimer

@mikkelfj Yes, __alignas_is_defined is defined there by gcc. See the comment above yours (with a link to the header).
@PerMalmberg oops, sorry!

@projectgus I'm not sure that it is in general, but for some versions yes. The problem pstdalign.h originally solved was that clang defined _Alignas as a builtin with std=c11, but glibc stdalign.h did not define alignas or alignof. I don't recall the entire history, but I could imagine gcc defining neither _Alignas nor alignas until recent versions, which are being tested for in pstdalign.h. So if you have on older version of gcc/glibc, it would not solve the problem. But, if newlib always imports a recent glibc stdalign.h header, that might work.

@projectgus I see that newlib is fairly widely used. Do you have any suggestions for how to detect presence of newlib to avoid the exception blocking inclusion of stdalign.h?
https://github.com/dvidelabs/flatcc/blob/775675487889a5bc5a7970493f1025ce5996393e/include/flatcc/portable/pstdalign.h#L19-L23
The detection might require inclusion of a header, but in that case it should be standard header such as <stdlib.h>

Yes, newlib is pretty widely used.
A few points which may help you figure something out:

Neither glibc nor newlib include stdalign.h. This is a toolchain header, it comes from the gcc sources (as per above link) - it's not a file in the glibc source tree or the newlib source tree. AFAIK whatever libc gcc is built against, stdalign.h will come from gcc itself.
As far as I can tell,  gcc 4.7 and newer include some kind of stdalign.h. In recent gcc (from 5, I think) it is definitely C11-compliant, meaning it defines the macros listed in the standard - alignas, alignof, __alignas_is_defined and __alignof_is_defined. I haven't looked at gcc 4.7 source to see what it's like there.
gcc 5 and newer include a macro, __has_include, which can be used to determine if a given header exists. This is also supported in Clang. You can test for existence of the feature itself with #ifdef __has_include.
On newlib, including unistd.h or string.h will, among others, pull in sys/features.h which will define __NEWLIB__ (newlib major version) and __NEWLIB_MINOR__ (newlib minor version). I'm not sure this helps you though, because existence of stdalign.h will depend on the gcc version not the newlib version...

So, to answer your question, I would actually suggest something like:
#if !defined(__cplusplus) && ((__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)))
#include <stdalign.h>
#endif

#if !__alignas_is_defined
// deficient stdalign.h, do some workaround
#endif

#if !__alignof_is_defined
// deficient stdalign.h, do some other workaround
#endif

Above should work on any libc for gcc 4.7+. Older gcc versions you already set PORTABLE_C11_STDALIGN_MISSING. For Clang, maybe try checking for __has_include...?

Thanks for the pointers, that is informative. I believe I already do what you suggest though, except stdaligh.h inclusion also requires stdc=c11. Perhaps it suffice to remove the C11 requirement for the GCC case after checking version.

Perhaps it suffice to remove the C11 requirement for the GCC case after checking version.

I think that will probably be enough.

Thanks, FYI I added the tests early in the file similar to C++14 handling and also added #ifndef around _Alignas and friends, and added the option to define HAVE_STDALIGN_H
https://github.com/dvidelabs/flatcc/blob/issue-77/include/flatcc/portable/pstdalign.h

Looks pretty comprehensive!
Note that due to preprocessor awkwardness you can't write this:
#elif defined(__has_include) && __has_include(<stdalign.h>)
The preprocessor tries expand the whole line at once and then evaluate it, and NONEXISTENTMACRO(X) is an expansion error.

NONEXISTENTMACRO

Never encountered that problem, but will look into it, thanks.

Never encountered that problem, but will look into it, thanks.

Well Travis just failed on that, and the suggested change made it work again!

Changes integrated into flatcc master branch and confirmed to resolve the issue.


fix(launcher): output correct error message for browser

When running npm run release today I got this error logged:
Error: Could not find browser revision 848005. Run "PUPPETEER_PRODUCT=firefox npm install" or "PUPPETEER_PRODUCT=firefox yarn install" to download a supported Firefox browser binary.
    at ChromeLauncher.launch (/Users/jacktfranklin/src/puppeteer/lib/cjs/puppeteer/node/Launcher.js:80:27)

The error is only partially correct; I did have the browser revision
missing, but I needed the Chromium browser, not Firefox. It turns out
the logic in Launcher.ts didn't take this into account; it mistakenly
had been hardcoded to always log out the error as if the Firefox binary
was missing.
This PR updates the message depending on the browser:
Chrome error:

Error: Could not find expected browser (chrome) locally. Run npm
install or yarn install to download the correct Chromium revision
(848005).

Firefox error:

Error: Could not find expected browser (firefox) locally. Run
"PUPPETEER_PRODUCT=firefox npm install" or "PUPPETEER_PRODUCT=firefox
yarn install" to download a supported Firefox browser binary.

Well I am still getting the same error


Bing Chat

Just a thought for the development map:
Microsoft Bing has just announced beta testing for an AI based, conversational web search engine.  I've been checking it out, and I've been impressed.
It would be very cool to bridge this new function with rhasspy on the front end, Bing AI on the back end (for internet based inquiries).
I just thought it might be worth mentioning...

It's not free to do this, so one would have to have a business model/plan to pay for it.
"This starts at $28 per 1,000 transactions for under a million requests per day, rising to $200 per 1,000 transactions for more than a million requests per day."
https://techmonitor.ai/technology/software/bing-microsoft-api-openai-chatgpt


chore: release 1.1.0

:robot: I have created a release *beep* *boop*
1.1.0 (2019-06-28)
Features

batch operation support (#69) (9c76a71)

This PR was generated with Release Please.

Release is at https://github.com/googleapis/nodejs-talent/releases/tag/v1.1.0

The release build has started, the log can be viewed here. :sunflower:

:egg: You hatched a release! The release build finished successfully! :purple_heart:


Property 'backgroundColor' does not exist on type 'WebGLRenderer | CanvasRenderer'

Hi,
with pixijs v4.5.3 when I try to set background color in renderer:
let app = new PIXI.Application(this.WIDTH, this.HEIGHT);
app.renderer.backgroundColor = 0xffffff;
I get this error:

Property 'backgroundColor' does not exist on type 'WebGLRenderer | CanvasRenderer'

I checked the documentation https://pixijs.download/v4.5.3/docs/PIXI.WebGLRenderer.html, and the property is available.
How to set background color in rederer with pixijs v4.5.3?

This seems to work fine: https://jsfiddle.net/Lu1gnkqq/
In addition, you can change the backgroundColor as a constructor option:
let app = new PIXI.Application({
  width: this.WIDTH,
  height: this.HEIGHT,
  backgroundColor: 0xffffff
});

@bigtimebuddy it's works.
Thx!


[future] consider dropping send/sync/static trait bounds once possible

There might be a future where:

the trait resolver and friends become better in detecting such trait bounds and we do not need to declare them everywhere
we no longer aim to support tokio multi-threaded work-stealing but instead have structured concurrrency (e.g. 1 runtime per thread0
we become better at coding (or a contributor appears on the stage who is) and finds a more ergonomic way to write this

It would allow us to write simpler code, where we also can work more often with references (e.g. not tied to 'static) instead of having to either resort to non-sync or use the pass-the-ball pattern (where you return the args back via result... dirty).
It's a word I do want to live in, but at the time it was too much of a distraction and either way Rust async still has plenty of work. This is more of a zombie tracker so we can look into this somewhere mid/late 2025. And maybe it just turns out to be a "grass is greener on the other side" kind of issue that we drop as won't do. We'll see.
Also feel free to start discussions here related to these bounds and the use in rama.

No need to keep this open. I bet the day that it becomes possible it might even be a linter that tells us that.
If someone has concrete input for this or a need they can also re open this before that time.


add --changedSince=tag flag

Would be useful to run commands on items that have changed (in git) since a certain tag or branch, similar to how Jest does it.

Might also need to had a --dependenciesChangedSince=tag

We can use https://www.npmjs.com/package/jest-changed-files


Collect the output of ovn-sbctl show in gather

In order to know if the logical submariner_router is
properly pinned to the active Gateway node in the cluster,
we require the chassis-id to the hostname mapping info which
is part of ovn-sbctl show output.
Signed-off-by: Sridhar Gaddam<EMAIL_ADDRESS>

Backport PR: https://github.com/submariner-io/subctl/pull/243


Top bar cut off

In expanded view, it appears that the top of the shadow does not reach fully to the top of the screen.

Unable to reproduce


Why is Promise.then considered a microtask

This comment says that:

[MicroTask]s represent work which will be done in current VM turn as soon as possible, before VM
yielding.

However, while debugging Zones I can see that Promise.then, which is executed in the following VM turns is scheduled as a microtask. My understanding is that it should be scheduled as a macrotask.
Can someone please explain the inconsistency?

@maximusk , Promise.then should be a microtask, and it will be executed in the current loop. zone.js only wrap Promise with Zone information, and will not change the lifecycle of Promise.

@JiaLiPassion
Thanks, but that's still confusing. The callback that is added to .then is not executed in the loop.

@maximusk , Promise.then should be executed in the loop, it will not be executed immediately, but will be scheduled as a microTask, and when current loop finish all running job, it will check any microtask is pending or not, if there are, those microtasks will be executed in the same loop.

@JiaLiPassion,

those microtasks will be executed in the same loop.

but AFAIK promise is guaranteed to be executed asynchronously, even the ones that resolve immediately:
return new Promise({resolve}=>{resolve();})

@maximusk ,
return new Promise({resolve}=>{resolve();})

in my understanding,
this will not be an async operation, it just create a new Promise whose state is resolved.
It will only be async as microTask when .then is called.
const p = new Promise({resolve}=>{resolve();})
p.then(r => {
 // this callback will be run in the current loop as microTask but after other main operations finish.
});

@JiaLiPassion

this will not be an async operation, it just create a new Promise whose state is resolved.

it will be, you can see the debugger in a browser

@maximusk , I have tried
<!DOCTYPE html>
<html>
<head>
  <script src="./zone.js"></script>
  <script>
    const promise = new Promise((resolve => {
      console.log('resolver');
      resolve(5);
    }));
    promise.then(r => {
      console.log('resolved ', r);
    })
    console.log('main task');
  </script>
</head>
<body>
</body>
</html>>

the output is
resolver
main task
resolve 5

@JiaLiPassion
sorry, don't really understand what your code example proves. It's consistent with what I'm saying.  console.log('resolved') is evaluated asynchronously in the next VM turn and that's why it's outputted the last

@maximusk ,
The sample try to explain.

 const promise = new Promise((resolve => {
      console.log('resolver');
      resolve(5);
    }));

is not async

Promise.then is async.

And console.log(resolved) occurs after main task doesn't mean it is in the next event loop.
It just means microTask will be executed after main script.

@JiaLiPassion
I seem to understand what you mean. Are you saying that promise executor is defined as microTask and will be executed in the end for the current VM turn and not the callback passed to then?

@maximusk , promise executor is not microTask, here is animation, you can see it more clearly.
https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

@JiaLiPassion, thanks for the link, I'll read it. In the meantime,

And console.log(resolved) occurs after main task doesn't mean it is in the next event loop.

It does mean it in the current implementation of Promise spec in all browsers without zones.

@JiaLiPassion , thanks a lot for your time and especially the link to the article. I think you should've put it in the first post :). I wasn't aware of microtasks queue. Getting back to my browser screenshot, it seems that Chrome shows microtasks as async operations in the debugger.
Thanks again for the quick response! Good luck)

@maximusk , sure, glad to help:)


Applied a small fix to the project file, so that 4steps can be built …

…using the Clang/LLVM compiler as well as the G++/GCC compiler.
To generate a Makefile that will build the project in Linux with Clang instead of GCC, append the parameter "-spec linux-clang" to the qmake command.

This should fix issue #1.


Glitched sound while playing through Denon Heos Music

What version of Music Assistant has the issue?
2022.12.1
The problem
Sound glitches when I select this player.
How to reproduce
You only have to start playing a song.
Relevant log output
No response
Additional information
No response
What version of Home Assistant Core are your running
2022.12.1
What type of installation are you running?
Home Assistant Container
On what type of hardware are you running?
Linux

Please read the FAQs in the discussion area

Please read the FAQs in the discussion area

Thanks, @OzGav . It's working like a charm now.
Regards.