Merge ungoogled-chromium back into the chromium expressions

Motivation for this change
Resolve #102965.
cc @squalus
My additional changes for this merge:
https://github.com/primeos/nixpkgs/compare/ungoogled-chromium-merge-no-changes..primeos:ungoogled-chromium-merge
git diff primeos/ungoogled-chromium-merge-no-changes primeos/ungoogled-chromium-merge (unfortunately it seems like the GitHub UI can only diff primeos/ungoogled-chromium-merge-no-changes...primeos/ungoogled-chromium-merge)
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Btw this is the nix-diff output (explains the rebuild that the second commit causes, s. commit message):
$ nix-diff /nix/store/nl4b0hwiaaahpfr910qhamr6r70j70cv-ungoogled-chromium-87.0.4280.88.drv /nix/store/z2br0hkbvrgbqdmwyzr5a5ignn5rhs43-ungoogled-chromium-87.0.4280.88.drv
- /nix/store/nl4b0hwiaaahpfr910qhamr6r70j70cv-ungoogled-chromium-87.0.4280.88.drv:{out}
+ /nix/store/z2br0hkbvrgbqdmwyzr5a5ignn5rhs43-ungoogled-chromium-87.0.4280.88.drv:{out}
• The input named `chromium-unwrapped-87.0.4280.88` differs
  - /nix/store/iddxb9yrhc6anvz3c3blbrcfvr8hmkn7-chromium-unwrapped-87.0.4280.88.drv:{out,sandbox}
  + /nix/store/jx2dbhdgwkhn10q77wlyj4bfhjjh01fl-chromium-unwrapped-87.0.4280.88.drv:{out,sandbox}
  • The environments do not match:
      channel=stabungoogled-chromium
• Skipping environment comparison

The color is missing but it's basically channel=stable vs. channel=ungoogled-chromium in /nix/store/iddxb9yrhc6anvz3c3blbrcfvr8hmkn7-chromium-unwrapped-87.0.4280.88.drv. AFAIK channel shouldn't even be set as environment variable but that seems outside the scope of this PR. Anyway, the two outputs/realizations of the derivation should remain unchanged.

Let's give it a try :)

Looks great! Thanks for doing this.

I think this broke unstable-small, see https://hydra.nixos.org/build/133143744 or rather https://nix-cache.s3.amazonaws.com/log/74kfh3pc10y5iin2r6crplabd0ky6vq4-nixpkgs-tarball-21.03pre258838.85298db412b.drv

@ajs124 thanks for notifying me! be94a4cf235ca11e05a549a1128bc2ae19ab4293 should hopefully fix it (not completely sure if there was a second problem - I was actually aware of this one but didn't expect that Hydra would try to evaluate ungoogled-chromium.chromeSrc but it seems like it will eagerly evaluate all attributes, even if they're not required/used anywhere).

Yay, the fix worked: https://hydra.nixos.org/build/133146064
@squalus and I just pushed 94bee1090426c1aaee8e20cc5bbb1e30da86c792 so you should now be able to update ungoogled-chromium by simply running pkgs/applications/networking/browsers/chromium/update.py ;)

Hey @primeos! It seems your last commit is now making my configuration throw an error at me (Google Chrome is not supported for the ungoogled-chromium channel.) when trying to install the ungoogled-chromium package :/.

@r3v2d0g oh, that"s a bit unexpected. I didn't think anyone would like to combine ungoogled-chromium with Google's proprietary DRM technology but I guess why not. I'll change the update script then to include the Google Chrome sources for the ungoogled-chromium channel as well.

@r3v2d0g could you please test if 86ff1e45cece6f001cf0971559cdec6d25bb9db7 works as expected (I only verified that it builds)?

@primeos Yes, this is now works as expected! Thank you for taking the time to fix this :)


Revert "BMP280 ADD"

Reverts TSKangetsu/RaspberryPiBARO#1
commit all rebased, need to check again

提交原因全部基于，重置


Add a code preview for diagnostics

fix #422

Should we have a flag --no-codeframe to disable this feature?

Awesome!

Should we have a flag --no-codeframe to disable this feature?

FWIW, looks like tsc uses --pretty false, so maybe we call this pretty too? It took me a while to figure out how to pass false, though, lol.

I think it would be nice to be able to coloring too

This looks great!
One more question: Does the lib let you customize how much before/after context you get? I wonder if that should be an option and if we should default to less. Maybe even only showing the offending lines without before/after context by default. That seems to be what clang and tsc do. I like seeing the context in an example with just one error, but I worry that it will take too much screen real estate when there are more errors.

it does can configure the before and after independently. Believe the default is what babel error would show up as and jest also does that in the tests.

Here is a few examples with 3 errors:
Single line(0 above, 0 below)

1 above, 1 below

Default

I like the single line, personally and it matches other compilers I use. But we could consider making it cutsomizable or changing it down the road.

yeah, I like single line too, changed it to that already


Does it work with http2?

Was getting errors when pip install Twisted[http2], does this work for you?

Can you provide more detail about the errors? The endpoint should "work"; http2 support will be completely disabled due to #26 / glyph/txsni#9, but I don't think you should get any errors as a result of this.

Closing this for now; if you can provide additional information I'll be happy to look into it, though.


How to override coord with a MultiIndex ?

What is your issue?
A pattern we used in xclim (and elsewhere) seems to be broken on the master.
See MWE:
import pandas as pd
import xarray as xr

da = xr.DataArray([1] * 730, coords={"time": xr.date_range('1900-01-01', periods=730, freq='D', calendar='noleap')})
mulind = pd.MultiIndex.from_arrays((da.time.dt.year.values, da.time.dt.dayofyear.values), names=('year', 'doy'))

# Override previous time axis with new MultiIndex
da.assign_coords(time=mulind).unstack('time')

Now this works ok with both the current master and the latest release. However, if we chunk da, the last line now fails:
da.chunk(time=50).assign_coords(time=mulind).unstack('time')

On the master, this gives: ValueError: unmatched keys found in indexes and variables: {'year', 'doy'}
Full traceback:

ValueError                                Traceback (most recent call last)
Cell In[44], line 1
----> 1 da.chunk(time=50).assign_coords(time=mulind).unstack("time")
File ~/Projets/xarray/xarray/core/dataarray.py:2868, in DataArray.unstack(self, dim, fill_value, sparse)
2808 def unstack(
2809     self,
2810     dim: Dims = None,
2811     fill_value: Any = dtypes.NA,
2812     sparse: bool = False,
2813 ) -> DataArray:
2814     """
2815     Unstack existing dimensions corresponding to MultiIndexes into
2816     multiple new dimensions.
(...)
2866     DataArray.stack
2867     """
-> 2868     ds = self._to_temp_dataset().unstack(dim, fill_value, sparse)
2869     return self._from_temp_dataset(ds)
File ~/Projets/xarray/xarray/core/dataset.py:5481, in Dataset.unstack(self, dim, fill_value, sparse)
5479 for d in dims:
5480     if needs_full_reindex:
-> 5481         result = result._unstack_full_reindex(
5482             d, stacked_indexes[d], fill_value, sparse
5483         )
5484     else:
5485         result = result._unstack_once(d, stacked_indexes[d], fill_value, sparse)
File ~/Projets/xarray/xarray/core/dataset.py:5365, in Dataset._unstack_full_reindex(self, dim, index_and_vars, fill_value, sparse)
5362 else:
5363     # TODO: we may depreciate implicit re-indexing with a pandas.MultiIndex
5364     xr_full_idx = PandasMultiIndex(full_idx, dim)
-> 5365     indexers = Indexes(
5366         {k: xr_full_idx for k in index_vars},
5367         xr_full_idx.create_variables(index_vars),
5368     )
5369     obj = self._reindex(
5370         indexers, copy=False, fill_value=fill_value, sparse=sparse
5371     )
5373 for name, var in obj.variables.items():
File ~/Projets/xarray/xarray/core/indexes.py:1435, in Indexes.init(self, indexes, variables, index_type)
1433 unmatched_keys = set(indexes) ^ set(variables)
1434 if unmatched_keys:
-> 1435     raise ValueError(
1436         f"unmatched keys found in indexes and variables: {unmatched_keys}"
1437     )
1439 if any(not isinstance(idx, index_type) for idx in indexes.values()):
1440     index_type_str = f"{index_type.module}.{index_type.name}"
ValueError: unmatched keys found in indexes and variables: {'year', 'doy'}

This seems related to PR #7368.
The reason for the title of this issue is that in both versions, I now realize the da.assign_coords(time=mulind) prints as:
<xarray.DataArray (time: 730)>
dask.array<xarray-<this-array>, shape=(730,), dtype=int64, chunksize=(50,), chunktype=numpy.ndarray>
Coordinates:
  * time     (time) object MultiIndex

Something's fishy, because the two "sub" indexes are not showing.
And indeed, with the current master, I can get this to work by doing (again changing the last line):
da2 = xr.DataArray(da.data, coords=xr.Coordinates.from_pandas_multiindex(mulind, 'time'))
da2.chunk(time=50).unstack('time')

But it seems a bit odd to me that we need to reconstruct the DataArray to replace its coordinate with a "MultiIndex" one.
Thus, my questions are:

How does one properly override a coordinate by a MultiIndex ? Is there a way to use assign_coords ? If not, then this issue would become a feature request.
Is this a regression ? Or was I just "lucky" before ?

@benbovy

On the current main you should be able to do this:
mulind_coords = xr.Coordinates.from_pandas_multiindex(mulind, 'time')

da.chunk(time=50).assign_coords(mulind_coords)

Directly using a pandas MultiIndex for creating or overriding Xarray coordinates is now deprecated. That said, it should still be supported in principle, so the inconsistent coordinates vs. multi-index state you get after chunk is probably a bug (maybe a special case that was missed during the index refactor and for which there is no xarray test?). We should fix it with a nicer user (deprecation) warning.

It seems to me that overriding a coordinate variable should be possible with assign_coords, even if the new coordinate is not "alignable" with the old one.

Agreed. We don't need full alignment but we would still need to check that dimension sizes match and whether the new assigned coordinate(s) do not break any multi-coordinate index in the original object. Maybe we could just use xarray.core.merge.merge_coordinates_without_align internally but I haven't checked.

@aulemahal Since you have a noleap calendar, you should be able to use .coarsen(time=365 ).construct() to reshape.

@pydata/xarray does any one have time to fix this. I think we should consider it a release blocker.

@aulemahal I've just run your MWE on the main branch (eceec5f7bbbe93b2f24f49af6361a135ae72e2e4) and it seems to work, could you confirm?
>>> import pandas as pd
>>> import xarray as xr
>>> da = xr.DataArray([1] * 730, coords={"time": xr.date_range('1900-01-01', periods=730, freq='D', calendar='noleap')})
>>> mulind = pd.MultiIndex.from_arrays((da.time.dt.year.values, da.time.dt.dayofyear.values), names=('year', 'doy'))
>>> da.chunk(time=50).assign_coords(time=mulind).unstack('time')
<xarray.DataArray (year: 2, doy: 365)>
dask.array<reshape, shape=(2, 365), dtype=int64, chunksize=(1, 365), chunktype=numpy.ndarray>
Coordinates:
  * year     (year) int64 1900 1901
  * doy      (doy) int64 1 2 3 4 5 6 7 8 9 ... 358 359 360 361 362 363 364 365

There are still two issues to fix:

da.assign_coords(time=mulind) should correctly create coordinates for multi-index levels, and we should warn that this is deprecated
da.assign_coords(time=mulind_coords) shoudn't raise an alignment error, i.e., we should also check and maybe drop single indexed coordinates in the original object prior to align it with the new coordinates (currently only multi-index coordinates are checked in the _maybe_drop_multiindex_coords internal function).

But if the MWE works in main at least we shouldn't consider this as a release blocker.

The initial "regression" is fixed, it works for me! Thanks a lot!

Great, although I have no idea on what could have fixed that initial regression since #7368 :-)

Thanks all! Let's leave the issue open to track https://github.com/pydata/xarray/issues/8039#issuecomment-1681844054


to-do lists' "done" status is not registered

Inside an admonition, I like adding to-do items. When I select the square box

the box is checked, meaning the task is done. However, if I switch to another page and come back, the box in unchecked again. If you check a box and look at the source, you get this:
```ad-info
- [ ] buy some bread
```

The checked status of a box is not registered.
What I currently do: edit the source code and add an x manually. However, clicking on the square would be simpler. It would be great if this issue could be addressed. Thanks.

Can confirm, having the same problem. I don't really know how hard it is to fix, but I concur with you that it would be great if this issue would be addressed

Unfortunately this is difficult to implement and the feature works in native callouts.
this is going to be marked won’t fix. Please use callouts.


Rename env to env_name in server/client for clarity.

Current dependencies on/for this PR:

main

PR #296   👈

This stack of pull requests is managed by Graphite.


box format

In your nms code, your comments say that the box format is: x1, y1, x2, y2, score, label
From my testing, it is actually: x1, y1, width, height, score, label
This format follows the Yolo detection box standard.  Otherwise, your code seems to work fine and is very clean.
UPDATE:  I had an index wrong.  The box format is x1,y1,x2,y2,score,label
Sorry1

My mistake.

@rbgreenway
Good!


Missing bidders in the AdUnits tab when setting up multiple adunits with the same code

Hi,
In the AdUnits tab the bidders information is uncomplete when multiple adunits objects are set with the same code. Only one of them is shown in the bidders column. In the Bids tab all the the bidders are correctly shown.
Just an example of two adunits objects with the same code:
[
  {
    code: "Top",
    bids: [
      {
        bidder: "appnexus",
        params: {
          placementId: 123456,
        },
      },
    ],
    mediaTypes: {
      banner: {
        sizes: [
          [970, 90],
          [970, 250],
        ],
      },
    },
  },
  {
    code: "Top",
    bids: [
      {
        bidder: "richaudience",
        params: {
          supplyType: "site",
          pid: "XYZ",
        },
      },
    ],
    mediaTypes: {
      banner: {
        sizes: [
          [970, 90],
          [970, 250],
          [1, 1],
        ],
      },
    },
  },
]

In this example two different adunits are set because the banner sizes must be different for each bidder.
Regards,
Armando

I share a fake site to test it:
https://professor-prebid-issue-55.netlify.app/?pbjs_debug=true
The AdUnits tab (only one bidder is shown):

The Bids tab:

It is just an example without a CMP and fake data.

HI @aanton ,
thanks for your feedback! I published a new version today. Please let me know if that fixes your issues.

Hi @florianerl,
it works perfectly :+1:
I have checked it in the test page. It uses five different AdUnits objects and all of them are reported correctly in the AdUnits tab.

Thanks!


key prop in field when using radio buttons

Using v3.0.5

Getting a key passed is generally ok, but in this case the field is a set of radio buttons, and each radio button input is getting passed the same key, throwing a React error:
<div>
  <input type='radio' {...alignment} value='left' checked={alignment.value == 'left'} />
  <input type='radio' {...alignment} value='center' checked={alignment.value == 'center'} />
  <input type='radio' {...alignment} value='right' checked={alignment.value == 'right'} />
</div>

Warning: flattenChildren(...): Encountered two children with the same key, `.$alignment1447084163136`. Child keys must be unique; when two children share a key, only the first child will be used.

I should note that I am passing formKey into reduxForm.

Ooh, good bug! Thanks. :+1:


Create a sitemap for Ecological

Can we create a sitemap dynamically based on stac catalog?

https://github.com/LTREB-reservoirs/vera4cast

Would be nice to have the ingestion ready before AGU


issue on v0.2.9

would it be possible to correct this? i'm trying to get the package pushed to cdnjs cdnjs/cdnjs#12418 and they don't love this issue
$ diff venn.js build/venn.js
921,949d920
<     /// Uses multidimensional scaling to approximate a first layout here
<     function classicMDSLayout(areas) {
<         // bidirectionally map sets to a rowid  (so we can create a matrix)
<         var sets = [], setids = {};
<         for (var i = 0; i < areas.length; ++i ) {
<             var area = areas[i];
<             if (area.sets.length == 1) {
<                 setids[area.sets[0]] = sets.length;
<                 sets.push(area);
<             }
<         }
<
<         // get the distance matrix, and use to position sets
<         var distances = getDistanceMatrices(areas, sets, setids).distances;
<         var positions = mds.classic(distances);
<
<         // translate rows back to (x,y,radius) coordinates
<         var circles = {};
<         for (i = 0; i < sets.length; ++i) {
<             var set = sets[i];
<             circles[set.sets[0]] = {
<                 x: positions[i][0],
<                 y: positions[i][1],
<                 radius:  Math.sqrt(set.size / Math.PI)
<             };
<         }
<         return circles;
<     }
<
1218a1190,1191
>     /*global d3 console:true*/
>
1745c1718
<     var version = "0.2.8";
---
>     var version = "0.2.9";
1759d1731
<     exports.classicMDSLayout = classicMDSLayout;
1775c1747
< }));
---
> }));
\ No newline at end of file

Hi @benfred I am a member from cdnjs, I think we just need to check which file is correct for<EMAIL_ADDRESS>Sorry for not noticing the discussion here previously, thanks for you guys' help 😄

@benfred any thoughts on this before i close?


Manually Stand Up Sugar CRM

What happened (or feature request):
Feature Request
What you expected to happen:
We had a specific opportunity that requires the ability to stand up a Sugar CRM website in DDEV Local.
Related source links or issues:

META: inventory, research, and rank CMS and hosting provider support plans
Sugar CRM Developer Docs

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)
2

Just a heads up to the rest of the team. This is not actionable at this time and may get closed.

Here is the start of requirements at the stack level http://support.sugarcrm.com/Documentation/Sugar_Versions/7.8/Pro/Installation_and_Upgrade_Guide/.

Hitting this error https://community.sugarcrm.com/thread/19749
Using ddev v0.15.0 w/configs of docroot = code and projecttype = php


bug with responsive mode and lazyLoad

I create carusel with this parameters:
https://jsfiddle.net/otdelnov/2z7vatgt/1/
var settings = {
infinite: true,
lazyLoad: true,
responsive: [{
breakpoint: 990,
settings: {
slidesToShow: 1,
slidesToScroll: 1,
dots: true
}
},{
breakpoint: 10000,
settings: {
slidesToShow: 2,
slidesToScroll: 1,
dots: false
}
}]
};
When i open page in vertical ipad i have 1 slide
But when i rotate ipad to horizontal i need 2 slide, but second slide is empty and not load.
I think lazyLoad not worked when i change page width.
And second problem with Infinity and lazyLoad. When i open page and click to Left button Carusel flasing and not working.
And when i click to Right and go to last slide, next click to Right button not move me to Clone first slide on the right, but carusel very fast moving to first slide on left.
And i need parameter to disabled create Cloned slide, becose i have many warning in console that key dublicate
PS: My slides have iframe video and any text or buttons.

I've examined the issue, and I'm reopening it and will set appropriate priority. Thanks!

fixed: d6d5e92629869a0969d4af507ec598376189b91f


Update wp-application-lifecycle-management.md

Added more details in the "Moving reference data to another environment" section

@ericregnier
Thanks for the update. Taking to live via internal branch.


Support implementing quickfixes via language server

As far as I could figure out, implementing a quickfix via a language server isn't really possible. I think this is a shortcoming of the protocol. Though I'm not really sure about that. It could just be I'm missing something.
I tried getting some answers here: http://stackoverflow.com/questions/43328582/how-to-implement-quickfix-via-a-language-server
But got no replies.
Anyhoo. The problem seems to be the following:
The closest thing we have to implementing quickfixes is via textDocument/codeAction.
But... this only allows the server to request that the client executes some command on the client-side to perform the 'quickfix'.
There seem to be a number of problems with this kind of an approach:

there is no way for the server to implement commands.
there is no standard list of commands that can be relied upon.
if we accept the fact that we have to implement commands on the client:

we have to implement them for every client we want to support (so this is not portable)
the client is the wrong place to implement code transformation that require understanding the document structure (the knowledge for doing such transformations lives in the server).

So my conclusion is, this is rather broken / impossible at the moment. Wonder if it could be fixed.
One idea is that protocol should offer some mechanic similar to how content-assist completions work. I.e. a 'code action' item should provide the means to be resolved to some document or workspace edits when the user invokes it.
PS: I did manage to implement a some quickfixes, following exactly the mechanism described in the SO question. I.e. I defined a client-side command that executes a quickfix by sending back the info attached to it back the the language server using some custom protocol. The server then responds with workspace / document edits to be applied, which the client-side custom command then applies to the workspace.

I am also trying to thread this particular needle, and have come to the conclusion that it is something to do with textDocument/executeCommand, but there is some kind of registration that needs to be done from the server to the client so that it knows the command is external.
I look forward to a comprehensive explanation.

Hmm... yeah textDocument/executeCommand seems promising.  I.e. the 'custom protocol' extension is no longer needed (textDocument/executeCommand will do instead). Still not clear how we get the client to recognize the command and send it to the server.

Quick fixes are currently textDocument/codeActions, taking the Diagnostic as context: https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#textDocument_codeAction . The codeAction rely on textDocument/commands, which happens to become client specific.
Some other reports relate to this issue of commands which are not very usable in the context of multiple clients: #178 , #61, #126 ,
FYI, in LSP4J, it turns out we decided to implement support for any command in a greedy way, only considering the arguments ( http://git.eclipse.org/c/lsp4e/lsp4e.git/tree/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/codeactions/CodeActionMarkerResolution.java#n52 ). Although it's not a nice strategy nor piece of code, it's currently the most pragmatic and working way we found to integrate properly with VSCode language servers.

Okay... I think the pieces of this puzzle finally are starting to click together in my head.
To indicate which commands to execute on the server I think we need to use client/registerCapability and provide it a ExecuteCommandRegistrationOptions , where we can list the command-ids that the client should send to server rather than execute locally.
I think that was the only piece of this puzzle that was still missing. I'll try this out tomorrow and see if I can make that work.

Hmmm... vscode sends a rather sparse looking 'capabilties' object upon initialization.
{
  "jsonrpc": "2.0",
  "id": 0,
  "method": "initialize",
  "params": {
    "processId": 1698,
    "rootPath": "/home/kdvolder/git/sts4\/concourse",
    "capabilities": {},
    "trace": "off"
  }
}

So I guess it doesn't provide support for this stuff yet. Which also means that I won't be able to keep good on my promise to try this out tomorrow and report back. Or would that support be available already on the 'insiders build'? Currently I'm just using the latest stable vscode release.

Never mind I am dumb. I needed to update the language-server-client module version in my package.json to get protocol version 3.0 support.

And does vscode then actually use the new features if you do that? Are you running a dev version of vscode?

Ok, I get it now. The package.json for my client extension.

@alanz I'm still trying to figure out exactly what versions I need for everything to work together. I just updated the client version but I'm getting some compile errors, which I gather is because it needs a more up-to-date vscode api to compile against. I'll post an update if I figure it all out. Right now I can't really answer your questions yet as until this compiles I can't really see it run and debug things.

FYI, I updated my extension package.json to be https://github.com/alanz/vscode-hie-server/blob/master/package.json, did an npm update in that dir and the newer protocol is now used for my extension.
Using the standard vscode, current version, installed from a deb.

 But hit a little snag. When I try to register the my quickfix commands via the protocol I'm getting an error like this:
[pool-2-thread-1] ERROR org.springframework.ide.vscode.commons.util.Log - Error
org.eclipse.lsp4j.jsonrpc.ResponseErrorException: Unhandled method client/registerCapability

Not really 100% sure of this, but poking around a bit with the debugger, I find that there is no handler for client/registerCapability however there is one called client/registerFeature. Also found in the source-code for the language-server client here:
https://github.com/Microsoft/vscode-languageserver-node/blob/143fb3928737db949bb800ba27d1c6580ad0c024/client/src/protocol.ts#L95
Is the reference implementation actually using a different name than the Spec?

Indeed that seems the case, after switching over to using registerFeature my quickfixes are working now. Raised issue here:
https://github.com/Microsoft/vscode-languageserver-node/issues/199
I think its clear now that the LSP protocol has everything it needs to handle quickfixes properly. So I'm closing this ticket.

@kdvolder Can you give me an example of the registration message you send that works?

nevermind, I got it going too, by making sure my extension code is up to date. See https://github.com/alanz/vscode-hie-server/tree/168ad64931af4ff700d4a62eff724d3af9a2987c

@alanz Maybe you don't need it anymore. But I'm sending something like this:
{
   "jsonrpc":"2.0",
   "id":"1",
   "method":"client/registerFeature",
   "params":{
      "registrations":[
         {
            "id":"4165c42a-1ced-49b0-b2fd-ad08bca1702c",
            "method":"workspace/executeCommand",
            "registerOptions":{
               "commands":[
                  "sts.vscode-concourse.codeAction"
               ]
            }
         }
      ]
   }
}

FYI: I have updated my SO question with an answer that provides a summary of what I have learned. Hopefully it can save someone else some time figuring this out :-)

What I have is the response to initialize as
{
  "result":{
    "capabilities":{
         "textDocumentSync":1,
         "hoverProvider":true,
         "codeActionProvider":true,
         "renameProvider":true,
         "executeCommandProvider":{
              "commands":["applyrefact:applyOne"]}}}
  ,"jsonrpc":"2.0"
  ,"id":0
}

The in the codeAction reply
{"result":[{"title":"apply hint:Redundant do","command":"applyrefact:applyOne"}],"jsonrpc":"2.0","id":4}

No parameters yet, but it arrives as an executeCommand request at the server

@alanz Ah that's interesting. I used the 'dynamic capability registration'. I didn't know you can also register your commands via the 'initialize response'. That's actually slighlty simpler if you don't need the commands to be registered dynamically (which I don't). Thanks for the info.

The big thing that is missing in this spec is scenario based flows, so you can see how it is intended to be used.
cc @dbaeumer


Small Optimization of XS Lookups

This PR adds the ability for a caller to control what kind of data gets passed back from the Nuclide::calculate_xs() function. Previously, this function always passed back an entire NuclideMicroXS struct, which included quite a lot of extra state variables that weren't needed in most places the function was called.
// Old
NuclideMicroXS Nuclide::calculate_xs(int i_log_union, Particle& p, bool depletion_rx_needed)
// New
void Nuclide::calculate_xs(int i_log_union, Particle& p, MicroXS* micro, double* reaction, NuclideMicroXS* cache)

The MicroXS struct contains only the four main reaction channels, which is typically all that's needed when building macroscopic cross sections. The reaction argument allows the caller to retrieve the depletion reactions. The cache argument allows the user to retrieve the full cache, which contains both the core XS values and the reaction values (if needed), along with all the other interpolation, ptable, scattering XS, etc data that is needed to complete a microscopic XS cache entry in the particle.
More info on this optimization is in PR #8, although we take a more limited approach here. In PR #8, I had proposed splitting the calculate_xs() functions up into a number of copies with each handling a different use case. While that is likely more optimal as there would be fewer conditionals in the kernel, the downside was it created a lot of copied code that would be a pain to manage going forward. Therefore, in this PR, I keep a single unified function.
Once all the components of PR #8 have been merged in, I can revisit how much might be gained from splitting the kernels up.
Current this PR gives (for A100, single rank, 8M particles in-flight):
| Old | This PR
-- | -- | --
HM Large Inactive | 356 | 366
SMR Active | 165 | 162
Oddly, the "optimization" here appears to be slowing things down a little in active batches for the SMR. I'm not sure what might be causing this, but I am going to leave this PR in draft status until the other parts of PR #8 have been merged so we can see if that changes the value of this optimization.

In re-running the test, I'm actually getting 161k for the baseline of the SMR on this card, so it does appear to be at least a small optimization for that problem rather than a regression.

@jtramm Now that the other pieces have been merged, do you want to re-run the numbers on this one to see how it fares? Also, it looks like there's a conflict in tally_scoring.cpp that needs to be resolved.

So with the nightly build of LLVM working again I went back and measured performance across the various branches. It looks like the optimization strategy that this PR takes is not going far enough, as it's not resulting in the gains we were getting in PR #8:
| openmp-target-offload | depletion_xs_opt (this PR) | tally_opt (PR #8)
-- | -- | -- | --
HM Large Inactive | 360 | 363 | 418
SMR Inactive | 212 | 215 | 236
SMR Active | 167 | 168 | 167
In PR #8, we were actually splitting the XS lookup function into several totally different versions depending on what was required from the function. In PR #8, we then actually decided on the host which version of the kernel to call, such that the kernels themselves could be a slim as possible. This seems to be great for making inactive batches as fast as possible, but the PR #8 strategy results in a lot of duplicated code. The strategy in this PR avoids the code duplication by just controlling what sorts of data gets passed to/from the functions, but appears to result in basically no performance gain.
So -- I think I'll need to keep hacking on this. I don't really like the idea of duplicating code as in PR #8, as it seems like it will make maintaining things tougher. I'l going to try to see if there's an easier way around this.

I was able to find a decent way of doing this that avoids code duplication but still gets a good performance improvement.
After some experimentation, I found that the LLVM compiler was just not generating fast code if we were passing in a pointer to a struct for it to populate, e.g.:
void Nuclide::calculate_xs(int i_log_union, Particle& p, MicroXS* micro, double* reaction, NuclideMicroXS* cache)

was not as fast as if we directly passed back a stack object. I attempted to improve this by using the __restrict__ keyword but that did not result in any improvements for the SMR problem.
The general problem is we have different things we need to pass back depending on who is calling the function. It gets called in three places right now (the material::calculate_xs function, in the collision function, and when scoring tallies). Each of these has different requirements for what it actually needs back from the function. The tally_opt branch was just making multiple copies of the function to handle each case, but that is a lot of duplicated code.
So, as a better solution, I just moved the calculate_xs function to the nuclide.h header and templated it as:
  template <typename T>
  T calculate_xs(int i_log_union, Particle& p, bool need_depletion_rx, double E, double sqrtkT)
  {...

Then, at the end of the function, we pass off all possible data to a constructor for T that gets returned to the caller:
    return T(
        total,
        absorption,
        fission,
        nu_fission,
        elastic,
        thermal,
        thermal_elastic,
        photon_prod,
        reaction,
        i_grid,
        i_temp,
        f,
        index_sab,
        index_temp_sab,
        sab_frac,
        use_ptable,
        E,
        sqrtkT);

I've defined constructors for the various types we want to pass back (MicroXS, NuclideMicroXS) that will only store the data that type actually contains, e.g.:
struct MicroXS {
  double total;         //!< macroscopic total xs
  double absorption;    //!< macroscopic absorption xs
  double fission;       //!< macroscopic fission xs
  double nu_fission;    //!< macroscopic production xs
  double reaction[DEPLETION_RX_SIZE];

  MicroXS() = default;

  MicroXS(
      double total,
      double absorption,
      double fission,
      double nu_fission,
      double elastic,
      double thermal,
      double thermal_elastic,
      double photon_prod,
      double reaction_in[DEPLETION_RX_SIZE],
      int index_grid,
      int index_temp,
      double interp_factor,
      int index_sab,
      int index_temp_sab,
      double sab_frac,
      bool use_ptable,
      double last_E,
      double last_sqrtkT
      ) :
    total(total),
    absorption(absorption),
    fission(fission),
    nu_fission(nu_fission)
  {
    for (int r = 0; r < DEPLETION_RX_SIZE; r++) {
      reaction[r] = reaction_in[r];
    }
  }

};

The upside here is we don't have duplicated code and its fast. The downside is we now have a rather large template function in a header, and we have a few goofy looking constructors for the MicroXS and NuclideMicroXS structs. If interested, one strategy we could potentially pursue is moving a lot of the logic out of the templated function and into smaller regular functions, then just having the templated function call a few higher level tasks. The downside is we have to manage passing a lot of arguments between those functions, so it's a little fiddly to implement, though not hard.
I'm also open to other ideas!
I also spotted something that I'd missed porting from PR #8 -- namely, that when storing data to the particle's macro_xs_ field at the end of a lookup, we only need to store the data we actually know rather than a full object copy. I've added in this optimization.
I also thought of another unrelated optimization for the lookup. Basically, we are accessing the particle's E_ and sqrtkT_` fields a few times throughout the lookup (and in particular, at least once for every nuclide lookup), which is potentially a lot of loads when we could just load it once and store it in a register. We now just load the energy and temperature from the particle once and store them on the stack outside the loop over nuclides.
WIth that said, I re-ran our performance tests. I also realized I was running the SMR without multipole, so the new numbers for all branches are running the SMR with multipole now.
| openmp-target-offload | depletion_xs_opt (this PR) | tally_opt (PR #8)
-- | -- | -- | --
HM Large Inactive | 360 | 419 | 418
SMR Inactive | 209 | 236 | 229
SMR Active | 178 | 198 | 174
This PR is now running faster than the tally_opt PR #8, so we are all caught up. Apologies for the large code delta due to templating the function. The only material changes to it were the prototype, the logic of what gets returned, and the change from accessing the particle's E_ and sqrtkT_ fields directly. So, the function does not need to be re-reviewed besides those areas.

Yes, this should be possible to split back up into smaller functions. However, I think one of the benefits we saw from inlining was that some compilers did better when we didn't have variables being passed by reference. I think there are probably decent ways around this by passing in as stack variables and having the return type be a tuple, but if we make that change I'd like to do some careful performance studies with all the compilers/GPUs to verify we aren't getting a performance penalty anywhere.

OK, we can defer that for another day and another PR :smile: Thanks @jtramm!


merge main into 0.3.0-pre

Codecov Report

Merging #818 (478fda3) into 0.3.0-pre (baf62dd) will decrease coverage by 1.09%.
The diff coverage is 87.36%.

@@              Coverage Diff              @@
##           0.3.0-pre     #818      +/-   ##
=============================================
- Coverage      87.63%   86.53%   -1.10%
=============================================
  Files            438      475      +37
  Lines          10833    12615    +1782
  Branches        1903     2298     +395
=============================================
+ Hits            9493    10916    +1423
- Misses          1278     1594     +316
- Partials          62      105      +43

Impacted Files
Coverage Δ

...s/formats/models/CredentialFormatServiceOptions.ts
100.00% <ø> (ø)

...les/credentials/protocol/v2/V2CredentialPreview.ts
88.88% <ø> (ø)

...ckages/core/src/modules/routing/RecipientModule.ts
61.85% <0.00%> (-0.65%)
:arrow_down:

...ntials/formats/indy/IndyCredentialFormatService.ts
88.01% <80.00%> (-0.25%)
:arrow_down:

...redentials/protocol/v2/CredentialMessageBuilder.ts
96.19% <95.08%> (+8.78%)
:arrow_up:

.../core/src/modules/credentials/CredentialsModule.ts
90.73% <100.00%> (ø)

...les/credentials/protocol/v1/V1CredentialService.ts
87.22% <100.00%> (+0.03%)
:arrow_up:

...les/credentials/protocol/v2/V2CredentialService.ts
94.19% <100.00%> (ø)

.../modules/credentials/services/CredentialService.ts
100.00% <100.00%> (ø)

...ules/routing/services/MediationRecipientService.ts
84.37% <100.00%> (+1.63%)
:arrow_up:

... and 55 more

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 baf62dd...478fda3. Read the comment docs.


Address generation error when connecting to remote wallet

Description
When connecting to a remote wallet I'm seeing this error in the console:

Expected Behavior
Addresses should be generated without errors.
Actual Behavior
It looks like the address is generated but subsequently the failure action dispatches regardless.
Steps to Reproduce
Connect to remote wallet and inspect console

Closed via https://github.com/LN-Zap/zap-desktop/pull/3121#merged-event


Is there an option to save or convert the drawing in SVG format?

Hey @bharatbondu - thanks for asking! SVG export isn't built in to the library, but you could implement it by recording the stroke data and generating SVG paths from it. Have a look at the Programmatic Drawing section of the readme - essentially instead of then calling atrament.draw, you could use the stroke data to build a SVG path string.
N.B. SVG paths have uniform stroke thickness, so you'd have to find a way to render the variable thickness as well.
Please do let me know if you implement such a thing, I'd happily link to your code as a solution for future users :)


NTR: symbiont-mediated disruption of host mucosa

Please provide as much information as you can:

Suggested term label:

Definition (free text)

Reference, in format PMID:#######
(REQUIRED)

Gene product name and ID to be annotated to this term

Parent term(s)
'disruption of anatomical structure in another organism'

Children terms (if applicable) Should any existing terms that should be moved underneath this new proposed term?

Synonyms (please specify, EXACT, BROAD, NARROW or RELATED)

Cross-references

For enzymes, please provide RHEA and/or EC numbers.

Can also provide MetaCyc, KEGG, Wikipedia, and other links.

Any other information

@genegodbold will provide references

Bacterial proteins causing mucosal barrier dysfunction:

C2 toxin, component I (C2I) from Clostridium botulinum (UniProt:D4N871): The C2 binary toxin ADP-ribosylates globular actin which has the effect of depolymerizing filamentous actin capped by the modified actin in sensitive cells. This induces cell rounding and dermonecrosis. C2 toxin induces dermonecrosis and hermorrhagic enterocolitis in avians but rarely in animals [PMID:28800062].
Iota toxin Ia from Clostridium perfringens: The enzymatic Ia iota toxin subunit is an ADP-ribosyltransferase that targets host actin at Arg177. Its activity blocks the formation of filamentous actin in cells, disrupts the cytoskeleton, and leads to cell rounding [PMID:30297616]. The cytoskeletal dysfunction induced by iota toxin Ia ultimately kills the intoxicated cell. The iota toxin alters intestinal permeability by destruction of the mucosal epithelium and altering intestinal motility [PMID:28764997].
Shigella extracellular protease A (Serine protease A, Serine protease autotransporter, SepA) from Shigella: SepA facilitates invasion into the host by opening the epithelial barrier. Shigella strains carrying SepA, but not the isogenic deletion mutants, caused lesions on the intestinal barrier indicated by epithelial desquamation in which the cells are shed from the tips of the villi [PMID:28598765].
Phospholipase A2 (VvPlpA) from Vibrio vulnificus: VvPlpA is essential for virulence in mice. It is secreted via a type II secretion system. Mice infected with a bacterial mutant in which the gene encoding PlpA was deleted have greater survival percentages than those infected with the wild type bacterium though bacterial survival in vitro is not affected. VvPlpA is essential for lysis and necrotic death of INT-407 mouse epithelial cells. Phospholipase A2s hydrolyze a fatty acid from the sn-2 position of the glycerol moiety. The recombinant PlpA protein has hemolytic activity toward both human and horse red blood cells with phosphatidylcholine the specific target. The proposed mechanism of action involves the disruption of intestinal epithelial cells, allowing the bacterium to reach the blood stream and invade other organs. The gene is induced when exposed to human intestinal cells [PMID:28855258].
Yersinia outer protein J (YopJ) from Yersinia pseudotuberculosis: YopJ is a T3SS effector that inhibits activation of host MAPK (ERK1/2, JNK, p38) and NFkappaB via acetylation of Ser and Thr residues on MAPKK and IKKbeta. Acetylation prevents  their activation by upstream kinases [PMID:16728640]-[PMID:17116858]. YopJ is activated by  host inositol hexakisphosphate [PMID:20430892]. YopJ increases gut permeability and allows bacterial translocation from the gut during Y. pseudotuberculosis infection. This increases mortality in a mouse model of infection. YopJ acetylates host proteins RICK and TAK1 thereby inhibiting them. This provokes a defect in the intestinal barrier [PMID:22520462].

+[Term]
+id: GO:0141139
+name: symbiont-mediated disruption of host mucosa
+namespace: biological_process
+def: "The disruption of the host mucosa by a symbiont, leading to damage or temporary subversion of that tissue. The mucosa is a membrane that lines various cavities in the body of an organism and covers the surface of internal organs." [PMID:22520462, PMID:28598765, PMID:28764997]
+is_a: GO:0141062 ! disruption of tissue in another organism
+property_value: term_tracker_item "https://github.com/geneontology/go-ontology/issues/26745" xsd:anyURI
+created_by: pg
+creation_date: 2024-01-16T09:44:42Z


sync_read support

Currently all the fuse operations are handled in parallel. C-fuse has a sync_read option which performs all the reads synchronously, which is useful when the filesystem wants to perform its own readahead, for example.
Ideally this would be per fd.

To elaborate a little, because each read currently spawns a goroutine, the filesystem may receive the read operations out of order.

Are you sure this isn't already the case in this package? It's been awhile since I've looked at the mounting process, but I think it may be.
The sync_read option to the C fuse library appears to cause the async_read field of the connection struct to be set to zero. Later in do_init, this will cause the response to the kernel to not have the FUSE_ASYNC_READ flag set. (I can't find any other effect in the interaction with the kernel or the way requests are dispatched locally than this.)
In contrast, this package never sets the async read flag. In other words, I believe sync_read is in effect always on.

I dug a little bit further and found that yes, I disabled async reads on purpose in 348ed9e731d013c43ea857ac6a9e1330e99faaa0, for exactly the reason you describe. :-)
(For the record, the measurements for gcsfuse that inspired this are recorded in GoogleCloudPlatform/gcsfuse@1d92d3e1ed20aa09227d591568d4c7ac79c1509e and<EMAIL_ADDRESS>

sorry forgot to respond. I wasn't able to reproduce the original problem anymore and this could be a problem on my side. Closing.


29 feature request add support for ply files

What is the reason for this pull request?
#29
What was added, removed or changed in this pull request?
Added a loader class that can load .ply files with the binary_little_endian format. Triangles can be streamed in using the ReadTriangle function
Contributors
@ClemensU42

Beautiful work!  We will open a new issue for some more optimizations for this loader so it can handle larger file. 👍


Add WPP tracing feature to DSHMC

Started working on integrating a little utility method to take care of running a WPP trace session for both BthPS3 components and DsHidMini so users need less steps to follow when we need driver insights for diagnostics. Still kinda wonky, work in progress:

This "feature" refusing to work has gotten on my nerves so I removed it entirely, I can spend my time elsewhere (like writing an article for the user to do it themselves 🙃 )
Case dismissed.


list-all not working on mac

asdf list-all sml on mac is giving this output:

Does anyone else have this issue? I think it should be just fixing the grep command in the list all.
There's some little differences between mac and linux shell commands.

I don't have a mac readily available to test it, but I could try to look into, or if you find something that works pull requests welcome


Use context manager for ledger query

For discussion
The ledger table has its associated columns / function, the use of context manager has a few advantages:

shortens the code,
creates a single entry .select() vs. various get_XXXX()
creates "context" to implement joining further (not done yet).

I have converted all examples.
https://github.com/credmark/credmark-models-py/blob/context-for-ledger/models/examples/e_07_ledger.py
Example
        with ledger.Block as bl:
            ledger_output = bl.select(
                columns=[bl.Columns.DIFFICULTY],
                limit="10",
                order_by=bl.Columns.NUMBER + " desc")

LegerQuery is a class combines query and table specification (e.g. column names).
In-line doc not updated yet.

TODO

Automatic lower case for address

f'{TokenTransferTable.Columns.TO_ADDRESS} = lower(\'0x5291fBB0ee9F51225f0928Ff6a83108c86327636\') or '

@leafyoung Generally I like the idea. I kind of expected to be using the Table subclass to run the queries but this is OK.
The query_method decorator is broken now. It used to be a called with the table name so it set the doc string but left the function calls unchanged by returning the function. Now it seems like it only sets the doc string if the function is actually called.

This has been sitting on the shelf for a month. Is it still relevant?

@iwyrkore, ready for review now. This updates both the ledger and contract ledger utility and added tests.
This commit has been tagged as 0.8.27.
Models have been updated and in https://github.com/credmark/credmark-models-py/pull/159


Missing some links

If the links on this page are supposed to be a comprehensive list of the ones under this navigation heading, it's missing "AD Forest Recovery Guide" and a couple more of the single-page entries.

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

ID: c7cd10d3-56ba-96d8-999f-959cde3b41f3
Version Independent ID: 827006e0-d880-88c2-6468-3a851256ca19
Content: AD DS Operations
Content Source: WindowsServerDocs/identity/ad-ds/manage/component-updates/AD-DS-Operations.md
Product: windows-server
Technology: identity-adds
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

Thanks for your dedication to our documentation. If we have been unable to review your issue in a timely manner, we sincerely apologize for the delayed response. We have captured the informtion you have provided for review. We are closing this issue for now, but if you feel that it's still a concern, please respond and let us know. If you determine another possible update to our documentation, please don't hesitate to reach out again. #please-close


Failed to mark file for deletion - Update 1.48.2

VSCode Version: 1.48.1
OS Version: Windows 10 Enterprise 1909 - Latest CU

Steps to Reproduce:

Attemp install of 1.48.2

Does this issue occur when all extensions are disabled?: Yes
vscode-inno-updater-1598411092.log

/duplicate #47841
As a workaround, please disable Windows background updates by setting update.enableWindowsBackgroundUpdates to false.


The completion of EasyEDA training

Complete this training series published on EasyEDA's own page :
https://www.youtube.com/watch?v=MsuR6W-jN5M&list=PLbKMtvtYbdPMZfzGuVTdc0MWKrFvU4nsu

Please add an estimated time.

I successfully completed the EasyEDA training.


Give extension popup styling consistent with app

Fixed by https://github.com/killergerbah/asbplayer/pull/25


refactor(client-services): finish migrating spaces service to new proto defs

Current dependencies on/for this PR:

main

PR #2373

PR #2401

PR #2410

PR #2462
PR #2503

PR #2463

PR #2505

PR #2528

PR #2561   👈

Current dependencies on/for this PR:

main

PR #2373

PR #2401

PR #2410

PR #2462
PR #2503

PR #2463

PR #2505

PR #2528

PR #2561   👈

⏳ This pull request is set to merge as part of a Graphite merge job
Job ID: C0c9xGl3nn9qGlpBEl2O.
See details on graphite.dev


Angular 2 : How to lazy load node_modules dynamically based on requested URL

lets say i have different versions of my library like -

player library has the following

|-player1
|-config.json
|-player1.module.ts
|-player1.component.ts

|-player2
|-config.json
|-player2.module.ts
|-player2.component.ts

How can i load player1 version of library if requested URL is xyz.com/p1 and player2 for xyz.com/p2.

@sowmya108 This question has nothing to do with the CLI. I think your question is answered in the docs and here
If you still don't get it going you can ask in the support group, or on SO


Properly delete Slack Chat Bot Messages

Description

When we moved to BigInt our primary keys in the connectors table. We also took the opportunity to remove all the cascade effect on the foreign keys.
A monitor surfaced an error when attempting to delete a Slack connector. This PR fixes it.
Risk

Deploy Plan

Is there any other resource we don't delete?


First call takes over 20 seconds on .NET 5 and above

Repro:
using System;
using System.Unicode;
using System.Diagnostics;

public class Program
{
    public static void Main()
    {
        var stopwatch = Stopwatch.StartNew();
        UnicodeInfo.GetCharInfo('a');
        Console.WriteLine(stopwatch.ElapsedMilliseconds);
    }
}

.csproj:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <OutputType>Exe</OutputType>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="UnicodeInformation" Version="2.6.0" />
  </ItemGroup>

</Project>

The above code prints numbers circa 300 on my machine but when I change the <TargetFramework> to net5.0, the numbers vary from 7000 to 28000 ms.

This seems a bit weird, but could be related to changes in the GZip implementation in recent versions. The tests are already running on .NET 5 and I didn't observe such a long startup delay. (Checked here: about 1.5s here on Core i5-10600 for the first test, which is already quite high, but far from what you are observing)
Did you make sure to run your test in Release mode and outside of VS ?

I was able to reproduce it using a laptop computer, but the performance variations between CPUs are really weird.
In order to fix this, I tried using an intermediate MemoryStream while reading the database. It seems to accelerate the startup very significantly, at the cost of increased memory usage. This seems to confirm a problem with the new DeflateStream implementation. 😕
The long term goal is to refactor the use of GZip for data compression and have static (uncompressed) data structure instead, but this fix should do it for now: https://github.com/GoldenCrystal/NetUnicodeInfo/commit/c2ab5227094d8f934b34fe6d3186c7f1e2be5e74


Pyro lr scheduler working perfectly and not at all

Intended to be a bug report.
It perfectly schedules the learning rate, but it just doesn't do any optimization steps.

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


Add demoralize events to TTT-Core

Done, see https://github.com/Vek17/TabletopTweaks-Core/commit/f919c727dad035bd64879ac2ebc7ce65e31f92a1
Should roll out with next release (presumably the 31st).


update dependencies where no code changes are necessary

update dependencies where no code changes are necessary
crate builds and tests pass (at least locally)

Would be great to merge this in and publish a new crate!

Will do soon! Sorry, I've been super busy lately, but I'll try to get this
out next week.
On Fri, Aug 28, 2020, 4:56 AM Johan Andersson<EMAIL_ADDRESS>wrote:

Would be great to merge this in and publish a new crate!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hwchen/secret-service-rs/pull/21#issuecomment-682411063,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA43JC7AYQ6LWHKR53HDOKTSC5WKRANCNFSM4QLBFELA
.

@hwchen sorry to nag, but any update on this? Anything we (Embark) can help with? we use this crate through keyring that I noticed you just released an update for (thanks!).

oh, thanks for the ping. I had lost track of this.

I'll be updating keyring deps shortly, just need to figure out if an issue with the latest release is in CI or otherwise.

Thanks!

keyring v0.10.1 is out with new secret-service version. Ended up mucking about with CI and tests, and that took up more time than expected.

Thanks!


English -> French Translation Phrase Errors

Please look through the app and change any English you see to French. If you're not sure about a replacement word, feel free to reach out to me or Salomon!

Rename "Normal" to "utilisateur" for types of users


unable to connect

when I try to connect mij KM2 the following messages appears in the log:
homeassistant.exceptions.IntegrationError: Error detecting Resol product - HTTPConnectionPool(host='http', port=80): Max retries exceeded with url: //<IP_ADDRESS>/ (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f205cb4e4d0>: Failed to establish a new
Thanx for your help!!

Please post your configuration.yaml (remove the password)

sensor:

platform: deltasol
host: http://<IP_ADDRESS>/#/
username: admin
password: your_password

Change it to
host: <IP_ADDRESS>

Thanx it works now!


Add the ability to work with the data allocated on the device into dal::csr_table

Add constructor and wrap() method that work with the data allocated on the device.
Move validate_input_dimensions() method from a homogen_table to base table class to make it available for both homogeneous and CSR tables.
Add tests for those methods.
Extend the functionality of host_csr_table_datapter class to work correctly with zero-indexed CSR tables.

http://intel-ci.intel.com/ede8bfec-6a99-f1ae-a99c-a4bf010d0e2e

/intelci: run

By the way - please consider moving kerners implementations into a separate *_dpc.cpp file. Imho the less code exposed to in headers - the better.

I've moved the implementation into csr_kernels.cpp. Is it better, or do I need a separate _dpc.cpp file?

http://intel-ci.intel.com/edffa20f-dead-f1f5-a1ff-a4bf010d0e2e

http://intel-ci.intel.com/ee0065eb-40bf-f1b1-b2ea-a4bf010d0e2e

http://intel-ci.intel.com/ee011eb3-6596-f196-aeed-a4bf010d0e2e

/inteci: run

/intelci: run

/intelci: run

/intelci: run

/intelci: run


a small fix for the geometry update

temp solution before we discuss more about the needsStyleUpdate && needsGeometryUpdate
has a fix for the bubbling
i like the idea of doing the checks with the returns and possibly just no longer needing the needs...Update functions at all

but i also like the idea in future if we add a 'predetermine' system that goes through all the system entities beforehand and determines what actually needs to update and which functions within the update for that system that it actually needs to remove the use of so many if/else branchings within the style/geometry/other systems
too high level for right now but it's a noodling thought

since this is a small fix and we'll be going over a better cleanup starting next week - just going to get this in
cleanup/refactor later will simplify this / mrapp / other systems more cleanly

after prs like this we can probably remove the entire need for needsUpdate type of checking, but that's something to be discussed next week - not priority


Detection Backend not starting

Hi,
I have had a really good time using YeastMate thus far for a range of segmentation problems but recently, my Mac OS standalone app is throwing this error when I start the backends:
AssertionError: Config file '/private/var/folders/ms/myv17t0x3y59jn4d2y_07szm0000gn/T/AppTranslocation/1685EE52-7BAA-4206-842A-E3F1D8F556F3/d/YeastMate.app/Contents/Resources/python/YeastMate/models/yeastmate.yaml' does not exist!
[2264] Failed to execute script 'yeastmate_server' due to unhandled exception!
This prevents the detection backend from initializing. Any clue on how I could potentially solve this issue?
Thanks in advance!

I just figured it out - resetting the paths to model and weight files in Backend Settings seemed to resolve the issue!


tests: Extract GetCertsForPods (and related functions) from utils

What this PR does
Extract functions from utils, to reduce utils size.
Fix linter problems (since we moved the function to a new file, which is now scanned).

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

None

/hold
until https://github.com/kubevirt/kubevirt/pull/11763 is merged

/sig code-quality

/hold cancel
PR was merged

/test pull-kubevirt-e2e-k8s-1.30-sig-compute
not sure what happened here (it doesnt show log at all)

@brianmcarey
no logs problem happens here as well
prow was updated lately ?
example
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/11823/pull-kubevirt-e2e-k8s-1.30-sig-compute/1786018760813973504

/approve

Thanks
/test pull-kubevirt-e2e-k8s-1.30-sig-compute

/test pull-kubevirt-fossa


[Request] Visualize when user tries to move/scale brush in direction of locked axis

Right now when an axis is locked and you try to scale/move over that axis, there's no feedback why it's not working, and this is often confusing

In version 1.317 there is better visualization in object mode

This version is now available on the asset store, so closing ticket


Removed TODO from Feedback section. Changed wording slightly.

As title

would close #91

Fix is too small and too close to hackathon. Closing without merging.


GROBID 0.7.0 100% CPU loop/hang/timeout with some PDFs

In our production systems at archive.org, I upgraded from GROBID ~0.5.5 to ~0.7.0 (git commit beebd9a6b to be exact) a few weeks ago. Since then, when processing hundreds of thousands of PDFs, I have regularly experienced GROBID "looping" with a couple threads consuming 100% CPU on individual cores. The symptoms are consistent with a small fraction of PDFs causing this behavior repeatably, while most PDFs continue to processed successfully. If we push a large number of PDFs through in parallel, eventually GROBID ends up spinning all the cores. The mitigation has been to restart GROBID every few hours.
It has been a struggle to get this issue to reproduce reliably in a minimum test case, even after a few hours debugging, and I apologize for any mistakes I have in debugging, or for lack of clarity in this issue write-up.
My best hypothesis right now is that there is an issue with a specific regex, when running GROBID with openjdk-8-jre (JVM 8). With openjdk-11-jre (JVM 11), the issue does not reproduce.
I have used a couple different clients and PDFs. A simple combination that has been reproducing the problem for me is the file sha1:5fa184d7eee96a504bae646e6c045699530bc023, which you can find an exact copy of at https://web.archive.org/web/20180719070056_/https://www.dovepress.com/getfile.php?fileID=14985. The API endpoint is processFulltextDocument, with consolidation disabled, raw citations and affiliations included, a number of TEI coordinates enabled, and sentance segmentation on. I haven't experimented with removing most of these options. Here is an example command using the httpie CLI client:
http --form --timeout 120 post http://localhost:8070/api/processFulltextDocument consolidateHeader=0 consolidateCitations=0 includeRawCitations=1 includeRawAffiliations=1 segmentSentences=1 teiCoordinates=ref teiCoordinates=figure teiCoordinates=biblStruct<EMAIL_ADDRESS>
This command times out after two minutes, and the threads continue to spin for at least 10 minutes on the server. In other cases the CPU seems to continue to spin for hours, though I haven't isolated and reproduced exactly that behavior.
The specific regex is PARENTHESIS_NUMBER_PATTERN, which is called on line 66 of CalloutAnalyzer.java: https://github.com/kermitt2/grobid/blob/beebd9a6b7847565fac86c680919aaacfbc9ad14/grobid-core/src/main/java/org/grobid/core/engines/citations/CalloutAnalyzer.java#L65-L68
To debug, I submit a couple parallel requests of the same PDF file, then send signal 3 to a high-CPU process, which causes java to dump a thread trace. These are long, and include many threads, but a common pattern is a trace like:
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: "dw-35 - POST /api/processFulltextDocument" #35 prio=5 os_prio=0 tid=0x00007f534c001000 nid=0xc239e runnable [0x00007f53b828e000]
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]:    java.lang.Thread.State: RUNNABLE
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Curly.match(Pattern.java:4241)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Branch.match(Pattern.java:4618)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Loop.match(Pattern.java:4799)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$BranchConn.match(Pattern.java:4582)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupTail.match(Pattern.java:4731)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Ques.match(Pattern.java:4196)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Curly.match0(Pattern.java:4286)

[... many java.util.regex lines ...]

Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Curly.match0(Pattern.java:4286)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Curly.match(Pattern.java:4248)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Branch.match(Pattern.java:4618)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$GroupHead.match(Pattern.java:4672)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4815)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Prolog.match(Pattern.java:4755)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3812)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Pattern$Start.match(Pattern.java:3475)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Matcher.search(Matcher.java:1248)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.util.regex.Matcher.find(Matcher.java:637)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.citations.CalloutAnalyzer.getCalloutType(CalloutAnalyzer.java:66)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.FullTextParser.postProcessCallout(FullTextParser.java:2359)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.FullTextParser.processing(FullTextParser.java:298)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.FullTextParser.processing(FullTextParser.java:110)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.Engine.fullTextToTEIDoc(Engine.java:507)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.core.engines.Engine.fullTextToTEI(Engine.java:497)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.service.process.GrobidRestProcessFiles.processFulltextDocument(GrobidRestProcessFiles.java:207)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.service.GrobidRestService.processFulltext(GrobidRestService.java:268)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.grobid.service.GrobidRestService.processFulltextDocument_post(GrobidRestService.java:220)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

[... many service lines ...]

Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.eclipse.jetty.io.ManagedSelector$$Lambda$101/448084064.run(Unknown Source)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:698)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:804)
Dec  4 02:18:11 wbgrp-svc096.us.archive.org GROBID[795471]: #011at java.lang.Thread.run(Thread.java:748)

The org.grobid.core.engines.citations.CalloutAnalyzer.getCalloutType(CalloutAnalyzer.java:66) is common across a few repeats with different files, different requests, and multiple threads stuck in the same regex at the same point in time. This is what makes me suspect the regex linked above.
When I run GROBID on my laptop, using the same artifacts and configuration, except lower concurrency, I can not reproduce the issue. I noted that my laptop (running Debian Linux, on an intel processor) has JDK 11, while the server (Ubuntu focal on intel processor) has JDK 8 (which is what GROBID supports, as per documentation). I tried installing JDK 11 on the server instead, and could no longer reproduce the problem.
I haven't really worked through what the specific root cause is... difficult regex for some body text on some platforms in a specific version of the JVM? But figured I would share what I have found so far here.
Thanks, as always, for maintaining GROBID, and apologies this bug report runs so long.

Here is a reference to regex implementation changes in Java 9, related to slow patterns and the "regex denial of service" issue. I'm not sure if they apply here or not.

https://bugs.openjdk.java.net/browse/JDK-8140212
http://hg.openjdk.java.net/shenandoah/jdk9/jdk/rev/d0c319c32334

Here is the PARENTHESIS_NUMBER_PATTERN regex itself: \(((\d+[a-f]?)|[,-;•])+\).

Hi @bnewbold !
Thank you so much for the detailed issue with the example document, this is super clear and helpful.
So as you have found, this is a catastrophic backtracking problem with this regex (and another one similar). The fact that it works with JDK 11 is related to their new safety feature for regex, which cancels suspicious regex applications to improve stability (this is a very nice circuit breaker feature !). With JDK 8, the regex will run as long as necessary, so 10 minutes or a few years :)
This part is indeed something I changed with 0.7.0 to improve citation callout recognition (and it improved it ! despite this bug :) ). It seems that there are always possible pathological input strings that can cause this kind of problem for non trivial regex. Here we are not in the easy case of nested regex expression:

input string (callout candidate) from the example: (1915-1919,1920-1924,1925-1929,1930-1934,and1935-1939)  (the space character is removed before applying the regex)

the regex you pointed will cause catastrophic backtracking in this case. Even a simpler, well-bounded, nothing nested, regex like this:
\((\d{1,4}[a-f]?[\-;•,]?)+\)
will cause a catastrophic backtracking with this input string !

After reading some more regex doc, it appears that this can be fixed (without the JDK 11 solution) using atomic grouping in the regex: \((?>[0-9]{1,4}[a-f]?[\-;•,]?)+\). The ?> indicates that no backtracking should take place for the defined token in this group, so we will save a few century of computation in the pathological cases.
PR to follow.

Great!
I gave the PR #868 a try with several dozen PDFs which were causing problems before, and all were processed successfully.

Thanks a lot for the feedback !
I merge the PR.


improve errorhandling for lndrest #252

improve on lndrest errorhandling
https://github.com/lnbits/lnbits/issues/252

Codecov Report

Merging #1631 (fb18751) into main (d82118d) will decrease coverage by 0.16%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1631      +/-   ##
==========================================
- Coverage   46.33%   46.18%   -0.16%
==========================================
  Files          47       47
  Lines        6874     6875       +1
==========================================
- Hits         3185     3175      -10
- Misses       3689     3700      +11

Impacted Files
Coverage Δ

lnbits/wallets/lndrest.py
15.12% <0.00%> (-0.13%)
:arrow_down:

... and 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


I HAVE A PROBLEM

when i set as follow:
Please enter OVH target id: 5
Please enter OVH organ id: 6
select PTV Heart and Organs Lt Lung
Traceback (most recent call last):
File "d:/dicom_read/OVH-master/ovhcalc.py", line 176, in
main()
File "d:/dicom_read/OVH-master/ovhcalc.py", line 174, in main
ovhc=calculate_ovh(rtssfile, int(var1), int(var2), True)
File "d:/dicom_read/OVH-master/ovhcalc.py", line 68, in calculate_ovh
for k in range(0,len(ss['planes'][keyss[find_nearest_index([float(jss) for jss in keyss],z)]][0]['data'])):
TypeError: 'dict_keys' object is not subscriptable

This script is tested in Python 2. Please check.


fix(applyPushRange): Apply the pushRange with maxRange

Apply the pushRange when the difference is greater than the maxRange set
Close issue #453
Fixed demo: http://jsfiddle.net/nx7yqqa5

Current coverage is 100% (diff: 100%)

Merging #456 into master will not change coverage

@@           master   #456   diff @@
====================================
  Files           1      1
  Lines         912    921     +9
  Methods         0      0
  Messages        0      0
  Branches        0      0
====================================
+ Hits          912    921     +9
  Misses          0      0
  Partials        0      0

Powered by Codecov. Last update 3e83a1a...bcd36f9

Thanks for this PR, it is just perfect! It feels good to have such a nice contribution with tests and everything ;)
Actually your solution is better than the one I suggested in the issue because mine would have just blocked the slider when maxRange would be reached while your "pull" behavior is neat!

Released under 5.8.6

Thank you ! Glad to help…


services/horizon: duplicate key violation of unique constraint

What version are you using?
user@stellar:~/stellar$ ./stellar-core version
v18.0.3
user@stellar:~/stellar$ horizon version
2.11.0-07dcbb1e43d9ee991461e1284af1d11dcae645d7
go1.17.3

PostgreSQL 14.0 (Ubuntu 14.0-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit

What did you do?
I was running horizon for a few months and everything were ok. But on 18 November 2021 horizon failed to ingest new blocks because of violating unique constraint liquidity_pools_pkey.
I just dropped the database and reingested blocks, it was ok until today, the error happened again.
Here is a part of horizon logs and postgres logs:
#HORIZON
[2021-12-01T04:21:27.839Z] Error in ingestion state machine current_state="resume(latestSuccessfullyProcessedLedger=38503090)" error="Error running processors on ledger: Error commiting changes from processor: error in *processors.LiquidityPoolsChangeProcessor.Commit: error upserting liquidity pools: exec failed:
 pq: duplicate key value violates unique constraint \"liquidity_pools_pkey\"" next_state="resume(latestSuccessfullyProcessedLedger=38503090)" pid=22569 service=ingest
#POSTGRES
2021-11-23 06:08:39.843 UTC [11804] user@horizon ERROR:  duplicate key value violates unique constraint "liquidity_pools_pkey"
2021-11-23 06:08:39.843 UTC [11804] user@horizon DETAIL:  Key (id)=(f7283cebce7c75aba5366e8e2e553d8236323a9d060120426d842e52ae226ba6) already exists.
2021-11-23 06:08:39.843 UTC [11804] user@horizon STATEMENT:
                WITH r AS
                        (SELECT unnest($1::text[]) /* id */,unnest($2::smallint[]) /* type */,unnest($3::integer[]) /* fee */,unnest($4::bigint[]) /* trustline_count */,unnest($5::bigint[]) /* share_count */,unnest($6::jsonb[]) /* asset_r
eserves */,unnest($7::integer[]) /* last_modified_ledger */,unnest($8::boolean[]) /* deleted */)
                INSERT INTO liquidity_pools
                        (id,type,fee,trustline_count,share_count,asset_reserves,last_modified_ledger,deleted)
                SELECT * from r
                ON CONFLICT (id) DO UPDATE SET
                        id = excluded.id,type = excluded.type,fee = excluded.fee,trustline_count = excluded.trustline_count,share_count = excluded.share_count,asset_reserves = excluded.asset_reserves,last_modified_ledger = excluded.last_modified_ledger,deleted = excluded.deleted
2021-11-23 06:08:40.946 UTC [11804] user@horizon ERROR:  duplicate key value violates unique constraint "liquidity_pools_pkey"
2021-11-23 06:08:40.946 UTC [11804] user@horizon DETAIL:  Key (id)=(f844e4109338e59c5005d60e7377aa7f0518553fb75763e702c467de70575847) already exists.

I didn't saved the logs from 18th November, but I have a query screenshots that I made on that day. And it seems that the violation of unique constraint happens with the same key  f7283cebce7c75aba5366e8e2e553d8236323a9d060120426d842e52ae226ba6
Screenshots of the query

After executing VACUUM FULL ANALYZE:

I thought that the error can be related to the postgresql issue and also asked about it in postgresql community chat, and received a link on postgresql issue.
Anyway want to be sure that this is not a buggy code in horizon, as the problem occurs while processing the same pool f7283cebce7c75aba5366e8e2e553d8236323a9d060120426d842e52ae226ba6 as far as I understood.

Possible related to #4110

Thanks for reporting this. Indeed, this is strange because nobody reported anything similar and also SDF haven't experienced this issue. Also we have explicit ON CONFLICT (id) DO UPDATE SET clause so the really looks like Postgres bug.

It seems that the problem was with PostgreSQL 14.0 version. Horizon has been running for 21 days without any problem using  PostgreSQL 14.1 (Ubuntu 14.1-1.pgdg18.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit.
I'm closing the issue as the problem solved.


fix: Correct casing of default PostgreSQL collation

References:

https://github.com/hashicorp/terraform-provider-azurerm/issues/22936
https://github.com/hashicorp/terraform-provider-azurerm/pull/22928

Fixes

#3

@Shr3ps Good catch. I should have thought of that, obvious. Fixed.


fix RngCore Sized

fix #13

Could you please squash these commits together?

I don't see any necessity to manually squash them, you can just squash merge

Oh right, I forgot that option exists in the GitHub UI (I literally never use it).

PR contents LGTM once squashed. I still need to confirm that this is a backwards-compatible change.

Have you confirmed it? ?Sized should be more permissive here

I'm sufficiently convinced this is backwards-compatible.

It is not, this is breaking various builds of ours :(

@str4d
Can you check this https://github.com/zkcrypto/pairing/pull/108 ?


returning a reference to input object

This has been discussed in #1018 and elsewhere. Let's continue the discussion here.
The question is whether it's okay for a function which usually returns a new object to return the input object in certain cases. Is it okay for R.slice(0, Infinity, xs) to return xs, for example, or should it return a shallow clone of xs?

I agree with @megawac. A function that sometimes returns a new object and sometimes returns the passed object seems inconsistent to me. Then I suddenly can't rely on it to return a new object anymore.
In the cases where the difference matters I'll have a harder time reasoning about what might happen. I'll have to ask myself "could this code in any circumstances call slice with the specific arguments for which it won't clone it's input?" and if I conclude that the answer is "yes" I'll have to clone manually. And if I mistakenly conclude that the answer is "no" I've just introduced a bug in my program.
This is slightly similar to how functions that are sometimes synchronous and sometimes asynchronous are a disaster. Imagine if Array.prototype.slice had returned the exact array when passed with 0. As in arr === arr.slice(0). That would have been bad right?
I think this introduces a lot of uncertainty to the API. Does R.sort return the passed in list if it is already sorted? I no longer know.

still mulling it over, but i'm pretty sure i'm on the other side. IMO we shouldn't be in the business of enforcing behavior. If you want to mutate your objects, then caveat emptor.

A function that sometimes returns a new object and sometimes returns the passed object seems inconsistent to me.

only if you are relying on reference equality, and that seems a bit weird. As far as I can see, what you are recommending is:
var p = {x: 1};
var q = R.identity(p);
p === q; //=> false, since q is a clone

and that would be very surprising to me.

I'm done arguing this but it seems like a new user trap; consider someone
who decides to convert a codebase. This one may be minor but I hope no
others follow suit
On Tue, Apr 14, 2015 at 9:52 AM, Michael Hurley<EMAIL_ADDRESS>wrote:

still mulling it over, but i'm pretty sure i'm on the other side. IMO we
shouldn't be in the business of enforcing behavior. If you want to
mutate your objects, then caveat emptor.
A function that sometimes returns a new object and sometimes returns the
passed object seems inconsistent to me.
only if you are relying on reference equality, and that seems a bit weird.
As far as I can see, what you are recommending is:
var p = {x: 1}; var q = R.identity(p);
p === q; //=> false, since q is a clone
and that would be very surprising to me.
—
Reply to this email directly or view it on GitHub
https://github.com/ramda/ramda/issues/1025#issuecomment-92856889.

only if you are relying on reference equality, and that seems a bit weird.

No. The function is inconsistent because is sometimes does one thing and sometimes does another thing. A function that returns a new object provides two guarantees:
1/ You can modify the returned object without affecting anybody.
2/ Nobody except you can modify this object.
Both of these stems from the fact that you are the only one with a reference to the object. You own the object. If the function sometimes returns a new object and sometimes the input object then you can't rely on those guarantees at all. Someone else could have a reference to the object and they could modify it.

As far as I can see, what you are recommending is: [...] and that would be very surprising to me.

No. R.identity is consistent because it always returns the input object. R.identity provides the guarantee that obj === R.identity(obj) for any obj and thus you can easily reason about it.
What I don't like is functions that switch between the two types of behavior. They're hard to reason about. Just like functions that are sometimes synchronous and sometimes asynchronous are hard (impossible actually) to reason about.
Consider this example:
var list = [1,2,3,4,5];
var list2 = R.drop(n, [1, 2, 3, 4, 5]);
console.log(list === list2);

Tell me, does this code log true or false? The answer is: it depends on n. So you don't know because you don't know what n is. I.e. you can't reason about the result of this code in isolation! That's bad. A proper implementation of drop would guarantee that the result would always be true (in case of a mutating function) or false (a pure function). The current implementation doesn't guarantee anything.
Now, consider this code:
function dropAndDoSomething(n, list) {
  var clone = R.clone(list);
  var list2 = R.drop(n, [1, 2, 3, 4, 5]);
  return someAsynOperation.then(function() {
    return R.eqDeep(clone, list2);
  });
};

Does this function resolve to true or false? Again, you don't know. It depends on n and on whether or not some other code modified the list that was passed in. Since drop doesn't guarantee anything we can't reason about the code.
Ramda will never optimal performance and that is not why people use it. I use it because I'd like my code to be easy to reason about and I think these negligible performance optimizations partly destroys that.

I was going to try to write up some examples, but they would probably just duplicate the points made by @paldepind.  While it would be nice not to have to care ever about reference equality, we are still trying to be a library for Javascript programmers.  Those who are working on systems not totally converted to immutability could get in real trouble if our API is inconsistent in this matter.

If you want to mutate your objects, then caveat emptor.

Sure, but what if the guy down the hall does it six months from now?  Or even better, it's in the codebase now, not causing an issue because n has always been much smaller than the list length, until one day...  If for no other reason, then just to enforce a consistency, and to be able to document with things like, "returns a new collections that...", I think it's a good idea to reverse what we've done lately on this issue.

if someone can point me to a reliable way to determine equality for objects maybe i'll agree.
var list = [1,2,3,4,5];
var list2 = R.drop(n, list); //=> this must be what you meant
console.log(list === list2);

fair :point_right:
but primitives are easy.
var list = [Just(1), Nothing, Just(3), Just(4), Just(5)];
var list2 = R.drop(n, [Just(1), Nothing, Just(3), Just(4), Just(5)]);
typeof list[0].map //=> 'function'
typeof list2[0].map //=> 'undefined'

Yes, indeed. That was what I meant to type in my example.
I don't follow your last example :confused:

what i'm trying to say is if you have a list of constructed objects with prototypes, what happens when you clone that?

I don't understand that example either.  drop was recently updated.  We could do something similar with slice, perhaps changing from this:
function slice(fromIndex, toIndex, xs) {
  return Array.prototype.slice.call(xs, fromIndex, toIndex);
}

to this:
function slice(fromIndex, toIndex, xs) {
  return (fromIndex === 0 > toIndex >= xs.length) ?
             xs:
             Array.prototype.slice.call(xs, fromIndex, toIndex);
}

If we do that, then it becomes unclear when R.slice returns a shallow clone versus the original list.

@buzzdecafe: We're only talking about shallow clones.

var clone = R.clone(list); is a deep clone

I don't think anyone is talking about doing that, though.  I'm certainly not.  _slice would be fine.

I'd definitely be surprised by a deep clone - I'd expect a new list for all
cases though
On Tue, Apr 14, 2015 at 2:18 PM, Scott Sauyet<EMAIL_ADDRESS>wrote:

I don't think anyone is talking about doing that, though. I'm certainly
not. _slice would be fine.
—
Reply to this email directly or view it on GitHub
https://github.com/ramda/ramda/issues/1025#issuecomment-93006311.

This is the sort of example we're talking about:
var a = {}, b = {}, c = {};
var x = [a, b, c];
drop(0, x) === x; //=> used to be false, now is true.  I think it should be false

Yeah, that would take the smallest change to drop

return n <= 0 ? list : _slice(list, n);

return _slice(list, Math.max(0, n));

On Tue, Apr 14, 2015 at 2:24 PM, Scott Sauyet<EMAIL_ADDRESS>wrote:

This is the sort of example we're talking about:
var a = {}, b = {}, c = {};
var x = [a, b, c];
drop(0, x) === x; //=> used to be false, now is true.  I think it should be false
—
Reply to this email directly or view it on GitHub
https://github.com/ramda/ramda/issues/1025#issuecomment-93007680.

var clone = R.clone(list); is a deep clone

I used R.clone in my example because I don't know of a Ramda shallow clone function. I'm not saying the list functions should do a deep clone. But they should return a new lists. Similar to Array.prototype.slice.

I'm not saying the list functions should do a deep clone. But they should return a new list

in that case i think i am with you.
that'll teach me to pay attention to the examples.

I was originally in favour of returning the same object instance to simplify checking large state objects for changes by only having to compare the instance of the root, however I concede that others likely have to deal with external code that mutates instances and I would much prefer to offer safety over convenience.
And if I really want the identity behaviour, I can still do so explicitly with something like:
dropIdentity = R.cond([R.eq(0), R.nthArg(1)], [R.T, R.drop]);

list = [1, 2, 3];
list === dropIdentity(0, list); //=> true
dropIdentity(1, list); //=> [2, 3]

@davidchambers, what say you?

I don't have a strong opinion on this matter. I believe the onus is on the mutator to clone, but I'm just one Ramda user. Several people have stated a preference for ensuring functions which usually return a new object always do so. I'm willing to accommodate these wishes. :)
We should add assert.notStrictEqual assertions to the test suite where appropriate and update the implementations as necessary.

Drop 0 seems like a no-op to me. Should logically no-op things just act as identity?

@jethrolarson: But that leads to this rather surprising behavior:
var nbrs = R.range(1, 11);
R.map(R.drop(R.__, nbrs), [8, 6, 7, 5, 3, 0, 9]); //=> [
//   [9,10],  <-- new list
//   [7,8,9,10], <-- new list
//   [8,9,10], <-- new list
//   [6,7,8,9,10], <-- new list
//   [4,5,6,7,8,9,10], <-- new list
//   [1,2,3,4,5,6,7,8,9,10], <-- reference to `nbrs`
//   [10] <-- new list
// ]

That sort of inconsistency from the library is what some of us are objecting to.

I can see that. I actually don't have strong feelings either way
On 5:58PM, Sat, May 2, 2015 Scott Sauyet<EMAIL_ADDRESS>wrote:

@jethrolarson https://github.com/jethrolarson: But that leads to this
rather surprising behavior:
var nbrs = R.range(1, 11);
R.map(R.drop(R.__, nbrs), [8, 6, 7, 5, 3, 0, 9]); //=> [//   [9,10],  <-- new list//   [7,8,9,10], <-- new list//   [8,9,10], <-- new list//   [6,7,8,9,10], <-- new list//   [4,5,6,7,8,9,10], <-- new list//   [1,2,3,4,5,6,7,8,9,10], <-- reference to nbrs//   [10] <-- new list// ]
That sort of inconsistency from the library is what some of us are
objecting to.
—
Reply to this email directly or view it on GitHub
https://github.com/ramda/ramda/issues/1025#issuecomment-98422936.

That sort of inconsistency from the library is what some of us are objecting to.

Yes, @paldepind made a good case. Still feels weird to me that we should care about reference equality. Seems to me we should be concerned with the values. But I think his case is stronger than my queasy feeling.

i think this is pretty much settled in favor of the arguments of @paldepind and @megawac. Therefore, this one is closed.

We should add assert.notStrictEqual assertions

Will make a separate issue for this.


3D Touch not working?

Is this a bug report?
Yes
Environment
Environment:
OS:  macOS Sierra 10.12.6
Node:  7.6.0
Yarn:  0.27.5
npm:  4.1.2
Watchman:  4.7.0
Xcode:  Xcode 8.3.2
Packages: (wanted => installed)
react-native: 0.43.4
react: 16.0.0-alpha.6
Target Platform: iOS (10.3)
Steps to Reproduce

build a new component, add force: 0 to the component's state
Make a view, give it these attributes:

onStartShouldSetResponder={() => true}
onResponderMove={(event) => {
     this.setState({force: event.nativeEvent.force})
 }}
onResponderRelease={(event) => this.setState({force: 0})}

Style the view to be visible, and large enough to tap
Place a  element in the view, with {this.state.force.toFixed(3)}
Build on an iOS device (6 or greater)
Try to force touch the View

Expected Behavior
I followed the documentation in this commit. I haven't been able to find anything else with my google-fu about 3d touch or force touch with ReactNative: https://github.com/facebook/react-native/commit/f685878938b59f858dc65b8e5e873045a25ccf79
Actual Behavior
Force stays at 0.000

Can you check this is still the case on a more recent RN version?

Dang, you're right @hramos — it does work with the latest version of RN


Newspaper logo

Can you please also include a way to get the image file(url) of newspapers logo? Just like description.

@vintageshinpads not sure what you mean, can you explain further?

I think he meant every news site has an official logo, he wants newpaper3k
to get it as well.
In my personal opinion, I think it will be pretty hard because there is no
standard
On Monday, 18 April 2016, Yuri Prezument<EMAIL_ADDRESS>wrote:

@vintageshinpads https://github.com/vintageshinpads not sure what you
mean, can you explain further?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/codelucas/newspaper/issues/236#issuecomment-211504719

Oh, yeah, if that's the case I agree... it'll be very hard to get the site's logo...
The top_image parameter is the closest thing I can think of - it's (almost) the same thing most social networks are getting the image from when posting.


Taxes

First, thanks for a great lib!
It would be useful to have a tax field that could hold the tax rate %, and some helpers to show price with or without tax, also total price with/without tax.
I'm in need of this feature and are thinking if i could extend this cart, or if it would be possible to improve on the lib to add this functionality. What do you think?

I've been thinking about this.
I'm thinking about adding 'tax' and 'weight' (for shipping) in version 2, but still not sure how to implement it. It just feels wrong to me to keep adding extra parameters.
I'll keep this open for now.

While I solved my need for now, I'm still interested in this feature. And weight would also be very nice to have.
Some other laravel-related lib have this notion of extending models with traits and extra properties, like EloquentSluggable does.
In the Shoppingcart case, one would normally have a Model that one wants to stick in the shopping cart, and by letting the model use a Shoppingcart trait and declare some mapping between columns and intention, it could be made quite clear.
Perhaps something like (just making stuff up)
class Product extends Model {
    use ShoppingcartTrait;   // trait that adds some methods, for example ::addToCart()

    protected $cartMapping = [
        'price'  => 'price_excluding_taxes',
        'vat'     => 'tax_percentage',
        'wgt'     => 'weight',
        'count'  => 'stock',
    ];

   ...

I've been thinking about using traits for these kinds of things.
I hope to find some time in the next few days to work on some ideas I have.
Thanks for the input!

sounds good :-) thanks

Any ideas on this?

I am looking for something similar. I am currently extending the Cart class with my own and added new attributes (like paymentmethod, shippingmethod, appliedTax,...)
However, the updateCart method doens't seem to store these extra attributes on the session.
Any help would be greatly appreciated!

What about implementing discount? Would be very nice to have the option to add only a single discount percentage.

@gjportegies Wondering if you were able to implement discounts?

That would be just awesome! I'm a junior developer working on my first project with laravel and just got @Crinsane 's cart integrated. I am building e-commerce website / app for a friend who wants discounts functionality integrated. As you might guess I got stuck and now I am researching all possibilities. All suggestions, links to useful resources to read / watch and ideas are deeply appreciated. (:

I have been working on a laravel 5.1 cart that I just started working on that has taxes. Soon it will be receiving bunch of updates related to discounts, promotions ect. If your interested in testing let me know<EMAIL_ADDRESS>and I would be more than willing to help Crinsane to implement these after I've tested them

Tax is integrated in the new version which is currently in the master branch.


fix php 8.4 deprecation notice

PHP Deprecated:  ShiftOneLabs\LaravelCascadeDeletes\CascadesDeletes::getInvalidCascadeDeletesRelations(): Implicitly marking parameter $relations as nullable is deprecated, the explicit nullable type must be used instead

Thank you for the PR @tomschlick !
I've updated and tagged a new patch release (2.0.2).
If anyone is curious, I didn't consider this a breaking change (BC) requiring a new major version because the default for the parameter is null. If the default had been non-null, then it would have been a BC, since the change would then throw an error for anyone that had overridden the method in their own code. However, since the default is null, PHP won't throw an error for this signature difference.
Thanks again!
Patrick