Icons seem to "inherit" colors from previous icon on the same page

It seems like different icons refer to the same svg defs so they "inherit" the colors from each other. Here is an example with Black Nib and Smirk Face: https://codesandbox.io/p/devbox/d3rstk?migrateFrom=sxmsl2
I tried going through the source code and even wanted to contribute but unfortunately I wasn't able to figure out how the conversion exactly works in little time I had,  so I'm filing this in hopes someone can help.

Thanks for catching this! I'll check it out and get a fix out in the next version.


Implement mitigation for https://www.kb.cert.org/vuls/id/475445 as suggested by @jebeaudet

This supercedes https://github.com/coveo/saml-client/pull/4 with the fix that @jebeaudet suggested (sorry @dreisch-coveo this wasn't fast enough 😛). The UT checks that the original identity is returned even when a comment has been injected.

@jebeaudet @dreisch-coveo plz do a quick review, I'll issue a release right after.

Thanks. Releasing 1.4.0 as we speak.


Search traverser not constructed properly

Aws Connected Device Framework Affected Module(s):

assetlibrary
I'm submitting a ...

[x] bug report
[ ] feature request

Description:

A change in version 1.0.1 caused searches having multiple clauses, including a traversal to sometimes not find results, depending if the traversal comes first or second.
Current behavior:

Search for a group with the following conditions (note traversal first):
"type": ["firmware"]
"eq":[
  {
  "traversals":
    [
    {"relation":"installable_on","direction":"out"}
    ],
  "field":"name","value":"my_sku_name"
  },
  {"field":"name","value":"my_firmware_name"}
]

This will yield 0 results even if that firmware exists. But if you swap the order in the eq array, the search will find a result:
"type": ["firmware"]
"eq":[
  {"field":"name","value":"my_firmware_name"},
  {
  "traversals":
    [
    {"relation":"installable_on","direction":"out"}
    ],
  "field":"name","value":"my_sku_name"
  }
]

Expected behavior:

No matter the order in the eq array - the same search result should show.
Steps to reproduce:

See above
Additional Information:

I believe this is because of how the gremlin queries are generated. Looking at the assetlibrary logs, having the traversal first (generating no search results) generates a Search Traverser that looks like this:

search.full.dao search: traverser:
"[["V"],["as","a"],
["select","a"],
["hasLabel","firmware"],
["select","a"],
["out","installable_on"],["has","name","my_sku_name"],
["has","name","my_firmware_name"],
["select","a"],["dedup"],["fold"],["unfold"],["as","matched"],
["select","matched"],["dedup"],["range",0,200],["valueMap"],["with","~tinkerpop.valueMap.tokens"]]"

Having the traversal last yields a Search Traverser that looks like this:

search.full.dao search: traverser:
"[["V"],["as","a"],
["select","a"],["hasLabel","firmware"],["has","name","my_firmware_name"],
["select","a"],["out","installable_on"],["has","name","my_sku_name"],
["select","a"],["dedup"],["fold"],["unfold"],["as","matched"],["select","matched"],["dedup"],["range",0,200],["valueMap"],["with","~tinkerpop.valueMap.tokens"]]"

I think this is due to the addition of the "select" when the a traversal is present.
https://github.com/aws/aws-connected-device-framework/blob/1bd30255402e8dc00267d6c398da272f6191029e/source/packages/services/assetlibrary/src/search/search.full.dao.ts#L161
If you let me know the general idea you'd like to see for a fix, I'm happy to implement it.

Updated integration tests to test for this scenario. Confirmed happening on 1.0.3.

Fixed in https://github.com/aws/aws-connected-device-framework/releases/tag/1.0.4.


How many vertex & edges can be added into a graph?

Hi
When I try to use load_labels_from_file to import vertex from a csv file, I got an error said:
pq: entry_id must be 1 ..<PHONE_NUMBER>10655
the vertex's id in csv is a uint64_t integer value.
if I change the id to a uint32_t，then all vertex in csv can be loaded succedded.
Is this means the maximum vertex number is<PHONE_NUMBER>10655 ?

Is this means the maximum vertex number is<PHONE_NUMBER>10655 ?

Yes, and that is the maximum for edges too. Though, this limitation applies per graph.

OK,
Just worndering why not use 64 bits length

@wen-bing The actual ID is only 48 bit. Rest of the 16 bit is reserved for label ID to gain some performance benefits. Do you need to store more than<PHONE_NUMBER>10655 vertices?


API / Docs feedback

(as mentioned on discord) I've been working on migrating a project from some custom resolution logic to oxc-resolver. Here's some feedback about my experience so far:
path argument
There are no docs describing the public API of the crate - the page for the resolver just has a link to an example as the only documentation. The example includes a comment which says Path to directory, must be in absolute path.
The crate docs just say: Resolve specifier at an absolute path with no mention of the requirement that it be a folder.
I misread this in example and made the assumption that I was passing the "target" file path (the file that "owns" the dependencies) to the resolve function. This caused many resolutions to fail because the code assumes the path is a folder and does path.join(relative).
Suggestions:

Improve docs for the API
Add an error if the path passed to .resolve is a file instead of a folder

Alternately - take the .parent().unwrap() of a file automatically

extensions option
I had all my extensions configured without a leading .. This caused all my extensionless resolutions to fail because the code assumes the extension starts with a . and does concatenate(path, extension).
The docs allude to this expectation by showing the defaults as having a leading . but it does not state the requirement.
Suggestions:

Describe the assumptions in the docs
Add an error if any of the extensions passed to the config does not start with a .

Alternately - normalise the extensions to start with a .

Thank you for the feedback, there's too much assumed knowledge around these APIs. I'll fix these soon.

I'd like to add that the example shown in docs.rs isn't very beginner friendly.
It took me more than three reads to understand it, but it still confuses me when I read it after a while.
What I gathered is that the language used is very technical, and it uses terms without a glossary. A couple of things that we could improve:

a more beginner friendly introduction of the package and what it does
a small glossary that explains technical words and frames them in right context e.g. specifier, alias, etc.


Remove sri hashes

Motivation for this change
These break compatibility with nix 2.0, see #89275. Alternative would be to bump minvers.nix, but some of this might also be relevant for 20.03 and 19.09.
Things done
Validated using nix-env -qa --out-path -f. with new hash types disabled.

[ ] 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.

Lowest release with SRI support is 2.2 (Jan 2019), if I look right, which is not that long.  Perhaps minver.nix should contain some hint about the lag we'll maintain here, e.g. it might say that we want at least two years margin.
Another issue is how to maintain the state; my suggestion: https://github.com/NixOS/ofborg/issues/513

Would it be worth also removing these from the release-20.03 branch as well?

IMHO yes.

Yeah, but I'm working a followup for base64 hashes first.

@vcunat I disagree. I think in the past our rule was it should be possible to evaluate Nixpkgs using the Nix version from the previous NixOS release. So using SRI hashes is fine.

https://github.com/NixOS/nixpkgs/pull/89476

:thinking: oh, in terms of NixOS release support cycles it is a relatively long time.  Last default nix < 2.2 was in 18.09, which has been unsupported for over a year now.

What's the final takeaway here?  Should we allow SRI hashes in master now?  Base64?  And to clarify, the right format is this, right?
hash = "sha256-rJbpoPjNMlw4diWjwNQ/DPo3rltvISU4kuRqBbvlBZ0=";

Master requires nix 2.2 now so using SRI hashes there is fine.

Sounds good.  Should we revert your PR to get rid of base64 hashes?  I actually quite like them, as aside from being shorter they're also an external standard, unlike our homebrew base32 encoding scheme.


The root is not the root element?

While trying to work with a parsed document I found something strange and rather counter-intuitive: The root does not seem to be the root element of the parsed document so when I iterate over the children of the root I will actually see all top level elements of the document including the root element itself.
let package = parser::load_xml(file);
let doc = package.as_document();
println!("{:?}", doc.root ()); // Yields "Root"

for elem in doc.root().children() {
    println!("Got {:?}", elem);  // Prints 2 elements: A comment and the root element
}

Hmm, yes, it appears I've accidentally colluded some bits of terminology. You are correct that the result of Document::root is a node that corresponds to section 4.8 of the XML spec:

The document entity serves as the root of the entity tree

(emphasis mine). This is unfortunate as I've also already used "document" to mean something else; the entrypoint to the allocation functions and owner of the DOM...
I wonder if there's anything preventing combining Document and Root...

Actually a document is the whole shebang including all metadata like the XML version and encoding and may also contain comments while the root is supposed to be the only regular element directly in the document.
I also don't quite get why there's a distinction between Root and Element in the code as they're exactly the same with the only exception being that a document must have exactly one Root. ChildOfRoot kind of seems superfluous as well (unless I'm missing something) because ChildOfRoot should not be any different than ChildOfElement.
I thought the easiest change would be to change:
    pub fn root(self) -> Root<'d> {
        self.wrap_root(self.connections.root())
    }

to return an Element instead but I failed miserably trying to implement that because a lot of code depends on the "root" being a Root.

ChildOfRoot should not be any different than ChildOfElement.

You'll note that ChildOfElement allows a Text element, which ChildOfRoot does not. That is, this text is not valid XML:
<?xml version="1.0">
hello
<thing />
world

True, but Root at the moment is not actually the root element but what the Document should be so I was trying to change the root fn to actually return the real root element.


Specifying a grader causes assertions to fail with the error message "Could not extract JSON from llm-rubric response"

Describe the bug
When a provider is explicitly set on defaultTest or through the command using --grader, some random assertions are failing with the error message "Could not extract JSON from llm-rubric response".  If we don't pin a grader and let promptfoo use the default one, the problem doesn't occur.
To Reproduce
Steps to reproduce the behavior, including example Promptfoo configurations if applicable:

Either specify a model in the cmd through --grader or in the config through

defaultTest:
  options:
    provider: openai:gpt-4

Run promptfoo eval
Check the results and look for "Could not extract JSON from llm-rubric response"

Expected behavior
We expect not to see random assertion failures due to this bug.
Screenshots
If applicable, add screenshots to help explain your problem.
System information (please complete the following information):

Promptfoo version: 0.95.0

Additional context
Add any other context about the problem here.

The root cause here is that the model you're using to override the grader isn't producing valid JSON.

@mouhcinetao Were you able to resolve your issue?


bugfix for displaying payouts with no funding limit

Fix for https://github.com/jbx-protocol/juicehouse/issues/41

👏


Docs: Example coverage - powertools-large-messages missing

What were you searching in the docs?
The powertools-large-messages module is missing a SAM example.
Is this related to an existing documentation section?
No response
How can we improve?
Following the pattern of the existing powertools examples, introduce one for powertools-large-messages. The documentation (which is currently unpublished, waiting for next release, but available in source) should be helpful, as well as the existing deprecated example from powertools-sqs.
Got a suggestion in mind?
No response
Acknowledgment

[X] I understand the final update might be different from my proposed suggestion, or refused.

@saurabhsharma001 interested in this one?

Yes, I can work on this.


Not changing size?

Hey having some trouble, doesn't seem to be changing my file size, original is 761kb and fixed is still 761kb
On one of my controllers:
use Spatie\ImageOptimizer\OptimizerChainFactory;
$pathToOptimizedImage = 'images/uploads/fixed.png';         $pathToImage = 'images/uploads/download.png';         $optimizerChain = OptimizerChainFactory::create();         $optimizerChain             ->optimize($pathToImage, $pathToOptimizedImage);

Make sure the necessary binaries (described in the readme) are present on your system.
You can add some logging to check what the package is doing.

Thank you, slight question, are there no binaries for windows? Currently hosting it locally atm and I often switch between my mac and pc

I'm not a windows user, so can't help you there 😄


ci: fix clustermesh worfklows on stable branches

The clustermesh workflows currently fail on stable branches as they expect .github/kind-config.yaml.tmpl to be present, but this file is only present on main.
It seems the template file is the only reason we need to checkout the repository, as we do not use any other file from the repository in subsequent steps, so we fix this by removing the checkout of the current branch since we already checkout the main branch in a prior step.
Thus, the template file on main is used for all worfkows.

My fault, sorry for the inconvenience. The checkout step is required to retrieve the helm chart used during installation, but it can be moved after cluster creation.


Encap public fields in cirq.sim

More public field and mutability removal

@95-martin-orion does this work?


WSK commands to be updated

WSK commands have to be updated  to bx $WSK….  in all the scripts below
https://github.com/IBM/IBM-function-webapp/blob/master/openwhisk-oauth/init.sh
https://github.com/IBM/IBM-function-webapp/blob/master/openwhisk-protected/init.sh

ill take on this


Spectrogram 2.0 using SkiaSharp

Spectrogram 1.x uses System.Drawing (GDI+) to create graphics, but this will no longer be supported cross-platform starting with .NET 7.  This PR explores using SkiaSharp to create graphics instead, and aims to simplify the API in the process.

Hi @vadd98, thanks for raising this issue! I'm very interested in finishing this soon, and I recognize that progress here has been halted for several months.
I'm currently prioritizing work on ScottPlot 5 (https://scottplot.net), but improving this library is my second highest priority, so hopefully this will be finished soon. In both cases the major goal is swapping System.Drawing.Common with SkiaSharp

Thanks a lot for your amazing work, I'll keep waiting!

Effort on this PR stalled, but I'll pick it up again before long


How to training the module with my own dataset

Thanks for your great work!This project is very innovative! I am currently replicating your work, and I would like to try to train my own dataset with your model. I have tried to modify the dataset num_classes in the config file, but there still seems to be other changes that need to be adjust.Could you please tell me where else in the code I need to modify my parameters?
At the same time, I also want to ask whether I have to cut the image in the code of data preparation. If I convert the image directly into coco format without cutting it, will it affect the running of my code?
I look forward to your reply. Thank you very much. I will continue to follow your great work!

have u solve that?

You may need to understand the DatasetCatalog.register()


Literal strings aren't highlighted correctly when using [=[ ... ]=] syntax

When writing a literal string using angle brackets with equals signs in between, it gets incorrectly highlighted, as shown in the screenshot below.

This can be fixed by adding a capture for =* in the definition of multiline strings:
// file: /syntaxes/yuescript.tmLanguage.json
// line: 72
{
	"begin": "\\[(=*)\\[",
	"beginCaptures": {
		"0": {
			"name": "punctuation.definition.string.begin.yue"
		}
	},
	"end": "\\]\\1\\]",
	"endCaptures": {
		"0": {
			"name": "punctuation.definition.string.end.yue"
		}
	},
	"name": "string.quoted.other.multiline.yue"
},

Thanks for your fix! Got vsc plugin fixed and updated!


NetMetrix removal

NetMetrix analytics must be sent until 2021, at which point NetMetrix will be removed. The next version of SRG Analytics delivered in 2021 can therefore remove the associated network call.

Available on feature/netmetrix-removal


TEAD-YAP cc terms too specific?

There are four cell component terms, GO:0071148, 49, 50, and 51 for complexes of the transcription co-activator YAP1 (yorkie) with each of the transcription factor family members TEAD1, 2, 3, and 4. These look to me like complexes of specific proteins, not a complex involving a protein family. Am I missing something or should these terms be handed over to PRO and replaced in GO by a more generic one?
Alternatively, if indeed these terms are within the scope of GO, could I have a grouping term for a complex on any TEAD protein with YAP1, and also one for a complex of any TEAD protein with WWTR1 (TAZ), to annotate some work that describes circumstances under which all TEAD proteins interact interchangeably with YAP (and with WWTR1(TAZ)) to form complexes that activate transcription of target genes (PMID: 19324876 and PMID: 18579750). Or, perhaps, if the current term is indeed too specific these four should be retired in favor of the single all-TEAD one?
Also, while these papers describe the pairwise interaction between YAP and a TEAD protein, that looks like a limitation of the experimental methods used, not evidence that the complex formed in vivo is a heterodimer as opposed to a larger complex whose members include these two proteins, so perhaps the definition should be changed from "A transcription factor complex that is composed of the DNA biding protein TEAD-n and the transcriptional coactivator YAP" to "A transcription factor complex that includes the DNA binding protein TEAD-n and the transcriptional coactivator YAP"?
Thanks.
Peter
Reported by: deustp01
Original Ticket: geneontology/ontology-requests/9091

@vanaukenk  @bmeldal  Does this fit in the Protein Complex working group discussion ?

Maybe, but looks to me - without reading the paper as well - that @hdrabkin and @krchristie already made a very sensible decision or merging all 4 terms into one parent term. I had a few similar situation where I've requested a merge in the past. I certainly no longer request composition-specific complexes for each compositional iteration of functionally identical complexes. It would be different if the variants have experimentally different functions but then they should still be grouped by that function.
Going further, Harold says these are all complexes "that activate transcription of target genes", so shouldn't they all be GO:NEW "transcription activation complex", rather than making lots of compositional-specific terms?
It could be the complex term to go with GO:0140110 transcription regulator activity
https://github.com/geneontology/go-ontology/issues/13588

Do we need a label < complex working group >???

I have a few comments.

Considering that the parent term of these 4 TEAD-YAP complexes is "RNA polymerase II transcription factor complex", it seems that if use a more general term, that it should still be specific to RNAP II.

Regarding the suggested "GO:NEW "transcription activation complex", the idea of coding the direction of regulation, e.g. activation or repression, in CC terms concerns me. MANY TF complexes act as either activators or repressors depending on the location of the binding site. It seems like it would be cleaner to separate the direction of regulation from the CC terms.

If we are going to use a very general term instead of creating a CC term for all of the multitudinous DNA binding TFs for RNAP II, are we also going to consider obsoleting the majority of child terms currently under "RNA polymerase II transcription factor complex"?  If I recall correctly @ukemi and I proposed deleting a number of these very specific terms in 2010, but it was decided to keep the ones we have, but not add any more. Note: We would probably still want to keep the terms for the "general transcription factors", e.g. TFIIA, TFII_, etc, since these very general to much of RNAP II transcription and are limited in number.

@bmeldal
Isn't the 'protein complex' label sufficient? How would you tell which issues go where ?
One alternative approach to consider is a 'Project' where you can link tickets from any tracker to follow the progress of a project. What do you think ?
Thanks, Pascale

Add @krchristie

Considering that the parent term of these 4 TEAD-YAP complexes is "RNA polymerase II transcription factor complex", it seems that if use a more general term, that it should still be specific to RNAP II.

Sorry, failed to check current hierarchy!

Regarding the suggested "GO:NEW "transcription activation complex", the idea of coding the direction of regulation, e.g. activation or repression, in CC terms concerns me. MANY TF complexes act as either activators or repressors depending on the location of the binding site. It seems like it would be cleaner to separate the direction of regulation from the CC terms.

Fair point. Let's not go down that route. I've had other situations, too, where activation or repression was situation dependent.

If we are going to use a very general term instead of creating a CC term for all of the multitudinous DNA binding TFs for RNAP II, are we also going to consider obsoleting the majority of child terms currently under "RNA polymerase II transcription factor complex"? If I recall correctly @ukemi and I proposed deleting a number of these very specific terms in 2010, but it was decided to keep the ones we have, but not add any more. Note: We would probably still want to keep the terms for the "general transcription factors", e.g. TFIIA, TFII_, etc, since these very general to much of RNAP II transcription and are limited in number.

Yes, systematic obsoletion of specific terms has been discussed several times and always abandoned due to a multitude of issues.

[ ] So, should we just merge the 4 composition-specific terms into one parent for this term?

@pgaudet

[ ] I think a "Project" would a excellent, then I can find related tickets much easier and also work on the project in fits and starts without having to keep track of numerous tickets. I've never created a Project, is it easy? Shall I start it? I see, there's a tab on the top!

Hi @bmeldal
I created your project
https://github.com/geneontology/go-ontology/projects/8
Skype me if you want a little overview of how to use this.
Thanks, Pascale

Thanks, Pascale. I'll let you know if I need help. Only working 2 days this week and that includes a training course. Will get to it next week.

@bmeldal

So, should we just merge the 4 composition-specific terms into one parent for this term?

Seems like a reasonable immediate action.

Yes, please, @krchristie

As I have mentioned earlier in this ticket, David H and I proposed eliminating all of these specific complex terms, during the 2010 transcription overhaul, and there was significant resistance to the idea from Ruth, and possibly others, that they would lose information that they have already annotated if these terms are removed. I am not sure we have yet gotten to the stage where there is a good way to capture the more detailed info as an extension, or via Noctua, that people will be happy to eliminate all of these.

It was discussed again 2-ish years ago with David OS and again Val was opposed as they'd loose a tonne of annotations to these leave terms.

it might be worth considering merging this additional term "TEAD-2 multiprotein complex" (GO:0071147) into a single TEAD-YAP complex term also.

According to review PMID:20439427
http://genesdev.cshlp.org/content/24/9/862.full
the transcription factor is the dimer but YAP interacts with other proteins in the Hippo signalling pathway (see F2).

@ValWood @bmeldal @krchristie
Can I go ahead and merge
GO:0071148 TEAD-1-YAP complex
GO:0071149 TEAD-2-YAP complex
GO:0071150 TEAD-3-YAP complex
GO:0071151 TEAD-4-YAP complex
GO:0071147 TEAD-2 multiprotein complex
into a single TEAD-YAP complex term ?

Yeast don't have these, I guess so...

OK by me - seems like the summary of what was agreed in this ticket.


Dynamically populated classic ui with options path is not converted

Quite often, we have dialogs like:
<some-node
    xtype="selection"
    type="select"
    options="$PATH.some-selector.json"/>

Is there a recommended way to get this automatically converted, or should we manually create datasources for all these components?
Right now the result would be like this:
<some-node
        jcr:primaryType="nt:unstructured"
        sling:resourceType="granite/ui/components/coral/foundation/form/select">
    <items jcr:primaryType="nt:unstructured"/>
</some-node>

Dialog conversion is being removed in v2.0.  I am tracking these issues for remedying via other means.


Empty Result[] array should be rejected by QIR codegen

Empty arrays can cause problems in processing for providers and tools. Compilation analysis doesn't always know the size of an array, but QIR codegen can catch this at "runtime" when generating the QIR. We'll need to add a new error case to catch this and fail codegen when it is detected.

This is valid QIR. If hardware can't support this, it should fail in validation for that specific hardware.


Add a widget with the withdrawal and Claim tokens on Overview page

From usability study:

We do not use the Overview space at all to address features other than staking.

Adding pending withdrawal to the Overview page:


Ensure resourceUri is mandatory

This makes the resourceUri mandatory, if its optional, we might not pass it.
If its mandatory we have to think about what we're passing into this, (i.e. it forces the user of the API to think about what we're passing)

Codecov Report

Merging #6703 (cbdbbc0) into main (2004ee9) will decrease coverage by 0%.
The diff coverage is n/a.

@@          Coverage Diff           @@
##            main   #6703    +/-   ##
======================================
- Coverage     69%     68%    -1%
======================================
  Files        412     412
  Lines      28599   28599
  Branches    4269    4269
======================================
- Hits       19841   19730   -111
- Misses      7071    7198   +127
+ Partials    1687    1671    -16

Impacted Files
Coverage Δ

...ent/datascience/jupyter/kernels/kernelExecution.ts
67% <ø> (ø)

src/client/datascience/jupyter/kernels/types.ts
100% <ø> (ø)

...t/datascience/notebook/vscodeNotebookController.ts
77% <ø> (+<1%)
:arrow_up:

src/client/debugger/jupyter/debuggingManager.ts
31% <ø> (ø)

...ience/variablesView/variableViewMessageListener.ts
22% <0%> (-78%)
:arrow_down:

...ent/common/application/webviewViews/webviewView.ts
14% <0%> (-72%)
:arrow_down:

...c/client/datascience/variablesView/variableView.ts
18% <0%> (-62%)
:arrow_down:

src/client/datascience/webviews/webviewViewHost.ts
19% <0%> (-53%)
:arrow_down:

...on/application/webviewViews/webviewViewProvider.ts
80% <0%> (-20%)
:arrow_down:

.../datascience/variablesView/variableViewProvider.ts
65% <0%> (-16%)
:arrow_down:

... and 17 more


Use async logging in MLflowLogger

What does this PR do?
Use async logging in MLflowLogger
What issue(s) does this change relate to?

Before submitting

[x] Have you read the contributor guidelines?
[ ] Is this change a documentation change or typo fix? If so, skip the rest of this checklist.
[ ] Was this change discussed/approved in a GitHub issue first? It is much more likely to be merged if so.
[ ] Did you update any related docs and document your change?
[ ] Did you update any related tests and add any new tests related to your change? (see testing)
[ ] Did you run the tests locally to make sure they pass?
[x] Did you run pre-commit on your change? (see the pre-commit section of prerequisites)

Benchmarking results available in, will need Databricks account to access:

benchmark stats
mlflow experiment view

Hi @chenmoneygithub, there are some failing tests. DM me if you have questions on how to get those to pass. For the code quality checks, can you run pre-commit run -a in your local repo?

Do we need to update the minimum pin of mlflow to support this?
Yes, I believe >=2.8.1 (async logging added in 2.8.0, but we added a bug fix in 2.8.1) cc @chenmoneygithub to confirm

@prithvikannan Thanks Prithvi! Yes, that's correct.


Feature Add memory tracker for orc reader and writer.


'/usr/bin/mono' could not be spawned.

When using mono installed by homebrew the wrong path is used for mono.
Expected: '/usr/bin/mono'
Actual: '/usr/local/bin/mono'

You can change the path to use in the settings.


Deploy a updated version of PAC on cluster

Currently this works on temporary cluster,
We can reuse the PSI clusters.
Until we get pipeline on push, we can reuse quay.io github webhook image building facility to generate image on commit.

[x] Add Dockerfile
[x] Add generate release.yaml
[x] Point pipelines-as-code app https://github.com/apps/pipelines-as-code to PAAC Cluster.
[x] reinstalled automatically on paac cluster https://console-openshift-console.apps.paac.devcluster.openshift.com/

It's deployed! 🥳 and can be added to any repository


What do fit in BucketedRandomProjectionLSH in spark?

In the spark there is an LSH function that use for KNN or search similarity; BucketedRandomProjectionLSH. The usage of it is:
    from pyspark.ml.feature import BucketedRandomProjectionLSH

    brp = BucketedRandomProjectionLSH(
        inputCol="features", outputCol="hashes", seed=12345, bucketLength=1.0
    )
    model = brp.fit(df)
    model.approxSimilarityJoin(df, df1, 3.0, distCol="EuclideanDistance")

But I don't understand what is the usage of fit in this method. In this example BucketedRandomProjectionLSH fit with df and approxSimilarityJoin measures the distance between df and df1, that df1 can be df too. what happend if we use df2 (other data frame) inested of df, that BucketedRandomProjectionLSH fitted with that data frame?

@MammadTavakoli Let's either file a JIRA in https://issues.apache.org/jira/projects/SPARK/issues or ask<EMAIL_ADDRESS>


[Concurrency Control] Support concurrent append-only writes

This is the official issue to track the support of concurrent append-only writes, or appends.
A common workload patten is to have multiple writers concurrently appending data to the table. A writer is considered append-only or an append if they only add data without reading or modifying existing data of the Delta Lake table in any way. Concurrent reads and appends should be allowed to operate on the table partitions and get snapshot isolation.

This is resolved by c3805a8fed12544c8450928ce839c84b0091306a


Update SDelete usage instructions to v2.02

The current instructions are outdated and incorrect, e.g. they suggest using the "-r" argument for recursion whereas that argument SDelete v2.02 removes the read-only attribute. This pull request updates them with the instructions shown when invoking sdelete -h.

Docs Build status updates of commit ed778f0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/sdelete.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 21ac847:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/sdelete.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 5537133:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sysinternals/downloads/sdelete.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Fix the discrepancy on "mIdentityProvider" caused in adal v1.15.1

There is a discrepancy on "mIdentityProvider" of Account object between v1.14.1 and v1.15.1

The identity provider is returned by V1. So mIdentityProvider should be a property of AzureActiveDirectoryAccount object instead of MicrosoftAccount.
The identity provider should be valued with idp idtoken claim instead of iss claim.

Close #343

Teams said they were not going to verify this fix.


Trump plans to "See them in court" after the 9th circuit upholding overruling travel ban

Trump plans to "See them in court" after the 9th circuit appeals court upheld the overruling of the travel ban.

https://www.aol.com/article/news/2017/02/09/see-you-in-court-defiant-trump-rails-against-appeals-court-ru/21711097/

http://www.nbcnews.com/video/president-trump-appeals-court-ruling-a-political-decision-873915459528

http://www.foxnews.com/politics/2017/02/09/appeals-court-upholds-ruling-blocking-trumps-immigration-order.html

Submitted by - Nathan

I wouldn't consider this a substantial promise to the American people (rather a juvenile tweet in response to the denial of his appeal by the 9th circuit court). Anyways, Trump said he would instead issue a new executive order altogether.

Do you think we should restructure that into a new promise altogether?

Well he already did issue the second executive order. But it, too, has been (at least temporarily) thwarted by the judicial branch...
I think that "Suspend immigration from terror-prone regions where vetting cannot safely occur. All vetting of people coming into our country will be considered extreme vetting" should be marked as in progress as debated in #109.


⚠ Samsung has degraded performance

In fab004e, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2769 ms

Resolved: Samsung performance has improved in 2ad1722.


(a) Nat <: Int, (b) (Nat|Int)N <: (Nat|Int)M where N < M, and (c) text format should use smallest necessary type

Right now, if you pass in 0 as a number as is, the textual parser turns it into an Int.
A better experience would be to have the textual parser uses the smallest type that can represent the number (e.g. 0-255 uses Nat8, -257 - -65536 use Int16, etc.
Then, have the candid values officially support Nat8 <: Nat16 <: Nat32 <: Nat64 <: Nat and Int8 <: Int16 <: Int32 <: Int64 <: Int then NatN <: IntN and Nat <: Int, thus removing any forced typings when entering numbers through the textual parser.

Actually, Nat8 <: Int16 would also be okay.

Actually, Nat8 <: Int16 would also be okay.

With the system level support for fetching did file, textual values will be annotated with the method signature automatically.

This doesn't work in many cases, in particular when you don't have access to the network but still want to sign messages locally (which is a very valid use case for NNS).
I don't want a system-dependent workaround for this issue. This is a real problem and dismissing it just causes MORE user pain. There's currently pain from developers both internally and externally (when, e.g. using the wallet).

I see the pain, but I don't think subtyping is the solution. Without did files, you cannot accurately know the number type, e.g. for wallet canister, one of the field is nat64, if we follow the smallest type rule, it's still wrong. The real solution is to get the did file somewhere, either from the canister, or package with dfx. We already package the wallet canister with dfx, why not adding the did file as well? The same argument goes to NNS canisters.

why not adding the did file as well

Because we have some control over our own canisters, we don't have control over users canisters.
You're asking for purity, I'm asking for pragmatism and putting the user first. We all know that 12345 can be represented by all of Int, Nat, Int16, Nat16, Int32, Nat32, Int64, Nat64 then why does it has to be a pain for the user?
Put yourself in the user shoes. You get a Expected Nat, found Int when you passed 10. What does that mean? How do you fix it? Why is Nat not an Int?  My 1 year old figured it already. How hard is it to add an if X can be a Nat, then Nat it?

I see several problems here:

Textual representation is not optimized for writing. I don't think inputing number is the only pain here. Nested records, variants, recursive values are all verbose to type. I think this is the real problem we try to solve.
did file is an inherent part of Candid, dfx or the network needs to provide this. Without knowing the type, how can a user even send a record? You don't even know the field name. Given the did file, we can greatly improve UX by providing auto-completion while typing the textual value, see my ic-repl experiment: https://dfinity.slack.com/archives/CGA566TPV/p1614233910046000
Bad error message for decoding. Sure, we definitely need to improve on this.
Parsing numbers. The subtyping rules you proposed basically means we only need one number type in Candid, which I agree. And it's actually recommended to use Nat or Int whenever possible as method signatures. We do support Nat <: Int. So it is seamless when the canister uses Nat and Int. The trouble mostly comes from Rust canisters, where they don't have native Int/Nat types and people are not using the Candid::Int or i128 as method types. This is against the best practice, and we recommend to use IntX/NatX only when you are very conscious about space.

Textual representation is not optimized for writing.

There's no better way right now. So let's add shorthands for record, tuples, vectors and optional and make it a good one.

did file is an inherent part of Candid

That's misleading. Candid itself does not require schemas, as you also encode the type in the serialization. If Candid wasn't built for this, it will definitely be used like this.

see my ic-repl experiment

AFAICT, that REPL does not improve in any way the UX of entering candid text format.

Parsing numbers

I think you're, again, pushing the problem to developers but it's really the Candid text format and the Candid spec that's at fault. The parser is overly strict and non-intuitive. There's no reason 0 cannot be ANY numbers.

 This is a plus for the users that can be implemented using toolings available today, and make the experience a lot better. But you think there's a better way, so good luck. It's your project. I'll just refer to this issue when developers ask me why they keep seeing "Got Int, expected Nat" when they pass in cycles.

@hansl, I think what you have in mind would essentially turn Candid into an untyped language, with all sorts of implicit conversions being made on the receiving end. That would have all the problems of untyped languages with implicit conversions, which are even worse when applied across app boundaries.
In particular, Candid's notion of upgrade compatibility is inherently tied to types. We would not be able to check or guarantee anything otherwise. If we allowed clients to get loose on typing, all bets would probably be off with not breaking anybody when you evolve an interface.
That said, we could add certain "safe" subtype relations. But as @chenyan-dfinity points out, that would not help in other cases. Overall, I'd argue that it would rather be counterproductive, by furthering potential misconceptions in that regard.
Perhaps the real problem is the text format? It is not self-describing by default in terms of types, especially when it comes to numbers. If we e.g. changed the syntax of text literals to require some form of type suffix, then there might be fewer surprises and pitfalls. But I'm not sure that works for all types and values. Worth thinking about?

@rossberg

would essentially turn Candid into an untyped language

I don't think so. If anything, I'm advocating for a properly typed integer, where 0 <: 1 and 0 <: -1. If anything, it follows Peano's axiom; there's a superset/class of ALL integers instances and a class of integers instances that can be converted to its superclass. It's not untyped, it's just polymorphism. There are also the example of tuples not being their own types that's kind of weird in a different way.

In particular, Candid's notion of upgrade compatibility is inherently tied to types.

Are you saying that if I pick a number to be nat16, I will never be able to upgrade it to nat32 without breaking backward compatibility? To me, that's the part that doesn't make sense.

That said, we could add certain "safe" subtype relations.

Yes. To me 0 being both a Nat8 and a Nat is not coercion; it's subtyping.

Perhaps the real problem is the text format?

Definitely lots of improvements could be made there. But I think this particular issue covers more a design space than an implementation problem.

require some form of type suffix

Adding burden to the end user will not help them, us, or anyone.

Are you saying that if I pick a number to be nat16, I will never be able to upgrade it to nat32 without breaking backward compatibility? To me, that's the part that doesn't make sense.

blob is vec nat8, do you expect it to be upgrade to vec nat64 at some point?

Perhaps the real problem is the text format?
Definitely lots of improvements could be made there. But I think this particular issue covers more a design space than an implementation problem.

I'm open to make the parser more liberal. But coercive subtyping breaks type safety when programmatically calling canisters: you don't expect an i8 to implicitly become an i64 in Rust.
I don't see why having the did file around is not an option to you. Even if we make your proposed change, without the did file, the returned record field will be hashes, which is really bad for UX.

blob is vec nat8, do you expect it to be upgrade to vec nat64 at some point?

blob being vec nat8 is an implementation detail; from a typing standpoint it should be seen as a series of bytes or a chunk of memory.
If I have an actual vec nat8 (for say, a list of spaces in a parking lot). It is possible that I want to upgrade to vec nat16 (added a new floor). This use case is currently impossible.

But coercive subtyping breaks type safety when programmatically calling canisters: you don't expect an i8 to implicitly become an i64 in Rust.

Rust is stricter than Candid already on subtyping though (e.g. ). Up to the point of being painful. But there are proper Into trait implementations that make the code let x: i64 = 10i8.into(); possible.

I don't see why having the did file around is not an option to you.

Airtight machine, Ledger and other crazy canisters who build their candid interface dynamically from a database, canisters that are during an upgrade might have a different candid interface than any DID we would download... Canisters that don't implement the tmp_hack hack.
I love to have the DID files, but I don't think it's realistic to just say we REQUIRE it.

If I have an actual vec nat8 (for say, a list of spaces in a parking lot). It is possible that I want to upgrade to vec nat16 (added a new floor).

Great example! In this case, the type should be vec nat. Using nat8 means you are sure the number won't go beyond the range, for example, in case of blob or age. When I see vec nat8, how do I know it's used for a parking lot or a series of bytes?

10i8

If you are fine with i8 suffix, sure. I'm onboard with anything on purely the parsing side.

Airtight machine, Ledger and other crazy canisters who build their candid interface dynamically from a database,

This seems orthogonal which doesn't prevent the developer from generating a did file dynamically.

canisters that are during an upgrade might have a different candid interface than any DID we would download...

dfx install should definitely check for subtyping during an upgrade. So I would say did file is required for upgrade.

Canisters that don't implement the tmp_hack hack.

There's going to be system-level support, see https://github.com/dfinity-lab/ic-ref/issues/279

I love to have the DID files, but I don't think it's realistic to just say we REQUIRE it.

Yes, we make a best effort when the did file is not around. The UX is never going to be perfect in this case, e.g. the hash in record field.

In this case, the type should be vec nat.

Theory != reality. Not every developers are omniscient on the API and best practices.

suffix

Nah this was Rust code.

So I would say did file is required for upgrade

For the person doing the upgrade. The person using the canister might be in a state where they download a Candid file but that file is now invalid.

system-level support

Only for opt-in canisters.

The UX is never going to be perfect in this case

And this issue is about making it better for integers and naturals.


Upgrade timex and tzdata to latest versions

This PR upgrades timex and tzdata to their latest versions.

Coverage remained the same at 85.135% when pulling 26b5754547bed18b128cf27ead2819a9700efda6 on marceldegraaf:master into 2d37b913ac55b28bece4c4b3a470cc4607490716 on smeevil:master.


Adding new tables to the database, user profile ,updating editing, creation, and viewing of hackathons.

NEW FEATURES
Creating tables for team requests to validate whether requests are accepted or not,
Creating the table for members linked to a team,
Changing the forms to add a text editor,
Altering the way rules and benefits are saved and displayed in the hackathon details section,
Adding the user profile with the teams they belong to.
DEMO

We are still working on the team members section, that's why the form doesn't display any input

NEW FEATURES
-Creating the API to add and visualize data from the new tables teamRequest and teamMembers,
-Creating a new page to insert new users into the group.
-Fetching the data from the database to show the users who accept the team (in progress)
DEMO
https://www.loom.com/share/6cd7cc30937f40d281d32fd49f8b5b2f


user-friendlier printing of missing var info

Instead of referring to DWARF and/or DWARF.jl types, we should print things like variable not found, variable present but cannot determine value etc.

Much better now, but I still see e.g.
[4] eval_user_input(ast, backend) at REPL.jl:50
  | bt::DWARF.Expressions.MemoryLocation{UInt64} = DWARF.Expressions.MemoryLocation{UInt64}(0x00007fffc9fee928)
  | err = <optimized out>
  | ast::DWARF.Expressions.MemoryLocation{UInt64} = DWARF.Expressions.MemoryLocation{UInt64}(0x00007fffc9fee818)

That should only happen now if the DWARF is invalid and those aren't actually julia objects. If they are, there's a bug somewhere.

Try making sure DWARF.jl is up to date, there was a bug fix in the expression evaluator.


[DataCollator] Add warning for out-of-vocabulary token IDs

What does this PR do?

This PR adds a patch for #2293 adding a validation check in DataCollatorForCompletionOnlyLM to warn users when token IDs exceed the tokenizer's vocabulary size. This is a common issue that can occur when:

Using incorrect pad tokens (especially with LLaMA models)
Modifying tokenizer vocabulary without updating the model
Adding custom tokens without proper model resizing

The warning provides possible fixes, making debugging easier for users.
Before submitting

[x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[x] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a GitHub issue? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines.
[x] Did you write any new necessary tests?

Who can review?
@qgallouedec

I understand the motivation behind this proposal, but I feel that warning would make more sense directly in the tokenizer. At least, that's where I'd look for it. What's more, this data collator is only used in specific cases. Having it in a collator (which is initially designed to collate data, not process it) seems strange to me.

Hey @qgallouedec ,
Thanks and yeah that totally make sense, I can instead try to put this in tokenizer or as a check before starting training with Trainer.
Feel free to close it here

Good. Please link this PR if you push this elsewhere


fix: typo in chat panel component

Hey @miurla, hat's off to you and thank you for your incredible contributions. I noticed this and believe it should be updated to fixed bottom-8 -ml-6 at your convenience.
https://github.com/miurla/morphic/blob/59139820e5031e6030ba0cd32463e144ab3a6601/components/chat-panel.tsx#L88C10-L88C29

Thank you for pointing that out. I've removed it since it was unnecessary code.


[FEAT]: Add error handling for asynchronous calls

Description
Add proper error handling on all asynchronous calls, as later calls may return previous calls' errors. See the first bullet points in the second Notes section here: https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__MEMORY__POOLS.html#group__CUDART__MEMORY__POOLS_1gbbf70065888d61853c047513baa14081
Motivation
Proper error handling is necessary to report errors to the caller and/or to terminate early to prevent incorrect results

Please reopen if I'm wrong but I think this is solved in v1.0.0 by checking for errors at the start of functions


 It fell asleep after 30 min during competition. Find a camera that will work for our competition that has enough zoom or resolution to clearly see the odlc zone. Higher resolution would mean we would have to take less photos and be over the zone for less time, but the cameras are usually much more expensive. Higher zoom would mean we would have to fly over the location multiple more times, but generally cost a bit less. We have also talked about gimbal vs. non gimbal cams, so look into both.
Go ahead and start looking on the ardupilot documentation.
Solution
Find a few options for cameras, document their stats, and determine how our procedure to find all odlcs would change.
Additional Information
section 5.8.1

Current plan is to use this camera or the upgraded version that is around $1000 that has optical zoom instead of digital. We can interact with this through ardupilot firmware, dronekit-python wrapper, or with python code.


Rules within CSS calc() are compressed incorrectly.

Description
Using arithmetic in CSS calc (through SCSS) results in incorrect output. It appears to remove spaces and sometimes remove some of the division rules.
Steps to reproduce
Raw SCSS:
$clip-rule: "(var(--button-size) / 2) + (var(--spacing-unit) / 2)";
clip-path: circle(calc(var(--button-size) / 2) at calc(#{$clip-rule}) calc(#{$clip-rule}));

Expected result
npm run develop (correct output)
clip-path: circle(calc(var(--button-size) / 2) at calc((var(--button-size) / 2) + (var(--spacing-unit) / 2)) calc((var(--button-size) / 2) + (var(--spacing-unit) / 2)));
Actual result
npm run build (incorrect output)
clip-path: circle(calc(var(--button-size)/2) at calc(var(--button-size) + var(--spacing-unit)) calc(var(--button-size) + var(--spacing-unit)));
Spaces are removed (which is invalid in calc()) and some divison is removed.
Could this be related to a compression of the CSS in the production build https://github.com/yui/yuicompressor/issues/59
Environment
  System:
    OS: macOS 10.15.3
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Binaries:
    Node: 10.16.3 - /usr/local/bin/node
    Yarn: 1.21.1 - /usr/local/bin/yarn
    npm: 6.13.7 - /usr/local/bin/npm
  Browsers:
    Chrome: 80.0.3987.116
    Firefox: 72.0.2
    Safari: 13.0.5
  npmPackages:
    @gridsome/source-graphql: ^0.1.0 => 0.1.0
    gridsome: ^0.7.13 => 0.7.13
    gridsome-source-graphql-prismic: ^0.1.6 => 0.1.6
  npmGlobalPackages:
    @gridsome/cli: 0.3.1

Further to this, I managed to get it to work by fixing a * 1 in the end of the calc() function.
Instead of this:
$clip-rule: "(var(--button-size) / 2) + (var(--spacing-unit) / 2)";
clip-path: circle(calc(var(--button-size) / 2) at calc(#{$clip-rule}) calc(#{$clip-rule}));

Do this:
$clip-rule: "(var(--button-size) / 2) + (var(--spacing-unit) / 2) * 1"; // See the * 1 here.
clip-path: circle(calc(var(--button-size) / 2) at calc(#{$clip-rule}) calc(#{$clip-rule}));

I have no idea why this fixes it but either way, it's dirty and something is definitely going wrong with how Gridsome handles calc() in production build of SCSS.
There is something up with using the + character.

Weird bug 😅 But glad you found a workaround

Why has this issue been closed though? I found a work-around but this is still an issue with the build process of Gridsome?

I'm pretty sure it's not a Gridsome issue, but might be the the sass loader?  Gridsome does not do anything with the CSS.

Does Gridsome do anything to the assets after the fact though? Like any optimisations on the compiled CSS such as minification / compression etc (regardless of pre-processor used)?
All I have running is node-sass and sass-loader and I do not see this behaviour in any of my Vue.js or Nuxt.js sites (so far as I can tell).

Not sure where this problem happens, but I'm pretty sure it's not on Gridsome's end. Gatsby community has been writing about the same issue. There are some issues with + like you mentioned.
This is how I fixed my function:
// From
--grid-two: calc((100vw - (var(--outer-padding) * 2)) / 2 + (var(--grid-gap) / 2));
// To
--grid-two: calc((100vw - (var(--outer-padding) * 2)) / 2 - (var(--grid-gap) * -1 / 2) * 1);

I think the last * 1 is redundant, but I basically used minus instead of plus and flipped the variable value.


Missing http headers binary annotations in newer verstions

using Sleuth verstion 1.0.0.RELEASE everything works fine:

while using Sleuth versions 1.0.1.RELEASE or 1.0.3.RELEASE the binary annotation that should contain those tags is empty and Zipkin looks like this:

Zipkin's version is the same, the public image openzipkin/zipkin:1.6.0

This is deliberate - https://github.com/spring-cloud/spring-cloud-sleuth/pull/292 . Since all the tracing information is on the client side, we didn't want to duplicate this data on the server side.


Give contributors more visibility

Similar as in https://github.com/lab-cosmo/equistore/pull/157 we can give contributors more visibility by adding a section to the README and adding images and also introduce a code of conduct

Yes, very good idea! After we merged #179 my plan was to revise the README.rst to avoid duplication. When we do this we can introduce a section for the contributors.


Docs: remove numbers and add titles to TOC

This PR removes the numbers in the table of contents, e.g. "1.2 Overview" becomes simple "Overview".
Additionally, it splits the main index in three sections: "For all users", "For GPU users", "For advanced users and developers". The main effect is to add coloured titles in the TOC, splitting it in three parts and making it easier to read.
I would also split the user manual in two parts, since it has two many subitems. However, I haven't been able to think of a meaningful way to split it into clearly defined parts.

@seibert @sklam @esc @gmarkall, you all commented on the original doc theme change. Any views on the above? I think it's a further improvement and perhaps a candidate for the 0.49.0 release branch.

Sounds good, I am 👍 to backport.

I'll add it to the 0.49 milestone, we should take this along for the ride.

Looks good to me - I was a little surprised by how much more pleasant it is to read the docs without tons of numbers everywhere. On my system "For advanced users and developers" did fit in the sidebar... just - but I see the need to shorten it a little.

/AzurePipelines run

I built it locally and it looks awesome! I have one small request, I just noticed, that the docs at:
http://numba.pydata.org/numba-doc/latest/user/installing.html#dependency-list
still reference sphin-bootstap but what is needed now is sphinx_rtd_theme. Could you sneak that change into this PR?

@esc I don't think sphinx-bootstap here: http://numba.pydata.org/numba-doc/dev/user/installing.html#dependency-list
I think this change was taken care of in the original PR.

@esc I don't think sphinx-bootstap here: http://numba.pydata.org/numba-doc/dev/user/installing.html#dependency-list
I think this change was taken care of in the original PR.

Oh, nevermind the noise then.

It looks good from my side also. @stuartarchibald what next, wait to merge this and then backport shortly before 0.49.0? I've added a needs-backport label to track these.

It looks good from my side also. @stuartarchibald what next, wait to merge this and then backport shortly before 0.49.0? I've added a needs-backport label to track these.

We'll just cherry-pick everything on the 0.49.0 milestone into the 0.49.0 release branch, don't think there's a backport need as we've not released a final 0.49.0, these are just fixes against an RC?

o.k. just want to make sure we don't miss anything. Closed issues in the Milestone will suffice.

No comments made otherwise so I think this is good to merge. Thanks all!


Minor fixes on constraint names upgrade guide

I also noticed part of the guide is missing, investigating that soon.

Nice! Ive got a PR open which is adding stuff to this section and moving some stuff about: https://github.com/prisma/docs/pull/2263

Oh I hadn't seen that. I'll re-start from the update guide when it hits preview.


Idea: melange init

It'd be cool to have a command to scaffold out a basic melange.yaml file. As a strawman, a basic melange init could emit a file containing:
package:
  name: TODO
  version: TODO
  epoch: 0
  description: TODO
  target-architecture:
    - all
  copyright:
    - paths:
      - "*"
      attestation: TODO
      license: TODO
  dependencies:
    runtime:
     # - TODO

environment:
  contents:
    repositories:
     # - TODO
    keyring:
     # - TODO
    packages:
     # - TODO

pipeline:
 # - name: TODO
 #   runs: TODO

This could be expanded with options like melange init --package-repo=alpine or wolfi, which would populate the .environment.contents.repositories and keyring with those values.
(If this sounds good we could also consider an apko init, with similar --package-repo flag, and a --nonroot flag to spit out the nonroot user boilerplate)
cc @eddiezane who actually had this idea

Hi @imjasonh , I think I have worked on something similar earlier for another project and have an idea on how we can do this, so if this is not being worked on by someone else, I will try to do this as I myself am playing with melange and wolfi these days and I have to copy some or the other yaml to get boilerplate ready, would love to do this! thanks!

I think it's still worth doing! We also now have a lot more examples in the Wolfi repo, and wolfictl as a sandbox for features like this.
It might make sense to have wolfictl init <package> that sets up this boilerplate.
We could also do some Charm magic to build the YAML from common questions (source repo, language ecosystem to choose a template, etc)
cc @luhring whos

Sounds great and interesting only, so probably we should do this for wolfictl itself? I will love to do that but Since melange’s one of the primary use cases are covered by Wolfi only should we implement here in melange too or just in wolfictl it should be good?
thanks a lot!


Issue release that includes PR 224

This issue is merely to request a new release that includes the recent bug fix of font problems that happened in https://github.com/pandas-dev/pydata-sphinx-theme/pull/224.
I have an online book going live for incoming students this coming week, so if that release happened, I could make sure the text looked correctly before they began using it.
See also https://github.com/executablebooks/jupyter-book/issues/751.
Thank you!

@jorisvandenbossche any reason not to cut a new release?

I actually did one today (for numpy) -> https://github.com/pandas-dev/pydata-sphinx-theme/releases/tag/v0.3.2, but that only included two small (and safe I think) bug fixes.
My idea was to do a new 0.4 release once https://github.com/pandas-dev/pydata-sphinx-theme/pull/190 is in (I have been actively working on the last week), because that requires a major release I think.
But can of course also cut master as 0.4, and then include #190 in 0.5.
No problem, releasing is not much work!

@nathancarter do you mind waiting a few days before we issue a release so we can get #190 in as well? @jorisvandenbossche are you thinking to have this done soon?

Well, my request is not exactly an emergency. :)
But I'm aiming to start sharing my work to students on 9/3/2020, so if it's before then, that'd be great.

@nathancarter sounds good - if we don't make it by that time, perhaps you can mention that there's a known bug and share a link to the issue in case you wanna make it a teachable moment about how open source works :-)

If I don't make it to finish #190 the coming days, I can certainly cut a release from master, no problem!

I was thinking: even if I finish #190 the coming days, ideally we let it sit a couple of days extra in master. So let me just quickly cut a 0.4 release from master now! ;)

I had a small complication with the black linting that was still failing (and then the workflow to push to pypi is not run). But released now!

-> https://github.com/pandas-dev/pydata-sphinx-theme/releases/tag/v0.4.0

Awesome, I just upgraded and got bold fonts in my built HTML.  Thanks very much!!


Add Ubuntu 20.04 (Focal Fossa) into supported OS

Confirmed by multiple people, that installed works on Ubuntu 20.04, I have added this OS into supported OS releases by PIVPN.
This will fix the https://github.com/pivpn/pivpn/issues/1005.

@omgapuppy Right, you need to add the arm64  dpkg architecture, however I think we should use a more generic approach based on https://github.com/pivpn/pivpn/issues/1005#issuecomment-650781452

the little hack I mentioned might work for the time being https://github.com/pivpn/pivpn/issues/1005#issuecomment-685817147

@omgapuppy so you are using armbian (not raspbian)?
if yes, it will be make sence add support for armbian instead of all arm64 OS?

@stevoh6 nope, it's Ubuntu 20.04.1 server for arm:
ubuntu@ubuntu
-------------
OS: Ubuntu 20.04.1 LTS aarch64
Host: Raspberry Pi 3 Model B Rev 1.2
Kernel: 5.4.0-1016-raspi
Uptime: 18 hours, 35 mins
Packages: 689 (dpkg), 4 (snap)
Shell: bash 5.0.17
Terminal: /dev/pts/0
CPU: BCM2835 (4) @ 1.200GHz
Memory: 268MiB / 908MiB

I will accept this pull request as a convenience for those running the arm64 Ubuntu version for now.
Thanks for testing.


Can't add edge to a non existing node

When I try to run a simple example on PyCG, it always raises exception pycg.machinery.imports.ImportManagerError.
My setting is as follow:
python version: 3.6.9
pycg commit: 99c991
I setup test directory like
mypkg/
  __init__.py
  main.py

and main.py contains
def foo():
    bar()
def bar():
    print('bar')

Running pycg --package mypkg mypkg/main.py -o cg.json raises an exception as follow:
Traceback (most recent call last):
  File "/home/jwhur/.pyenv/versions/3.6.9/bin/pycg", line 11, in <module>
    sys.exit(main())
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/__main__.py", line 79, in main
    cg.analyze()
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/pycg.py", line 157, in analyze
    self.class_manager, self.module_manager)
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/pycg.py", line 147, in do_pass
    modules_analyzed=modules_analyzed, *args, **kwargs)
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/processing/preprocessor.py", line 33, in __init__
    super().__init__(filename, modname, modules_analyzed)
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/processing/base.py", line 36, in __init__
    with open(filename, "rt") as f:
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 951, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 894, in _find_spec
  File "<frozen importlib._bootstrap_external>", line 1157, in find_spec
  File "<frozen importlib._bootstrap_external>", line 1129, in _get_spec
  File "<frozen importlib._bootstrap_external>", line 1273, in find_spec
  File "<frozen importlib._bootstrap_external>", line 1229, in _get_spec
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/machinery/imports.py", line 39, in __init__
    ig_obj.create_edge(self.fullname)
  File "/home/jwhur/.pyenv/versions/3.6.9/lib/python3.6/site-packages/pycg/machinery/imports.py", line 87, in create_edge
    raise ImportManagerError("Can't add edge to a non existing node")
pycg.machinery.imports.ImportManagerError: Can't add edge to a non existing node

Hey @JaewonHur,
I had the same problem and updating python to version 3.10.5 helped me solve it.
Not sure if it will in your case though.


use modularized lodash packages

w00t first PR!

!!!
On Jul 7, 2015 3:41 PM, "Mike Reinstein"<EMAIL_ADDRESS>wrote:

w00t first PR!
—
Reply to this email directly or view it on GitHub
https://github.com/Famous/framework/pull/55#issuecomment-119364913.


Pass epoch and block number in phase shift event

A phase shift handler currently only receives a signal without any information. We could pass the old epoch number and block number to the handler as an
interface PhaseShiftEvent {
  epoch: number; // just passed epoch
  blockNumber: number;
}

blockNumber still missing. Have to look in core to see if this is still viable.

Bumping this issue up again. It is small and came up recently when grooming our backlog.

Epochs are now based on timestamps.


Introduce PHPStan

And fixing some errors.

I am not able to understand the remaining 17 errors https://travis-ci.org/swoft-cloud/swoft/jobs/565805282

hi @szepeviktor, thanks you PR. 👍


Noise removal vs concentric zone model conversion question

Hello @seungjae24
After diving in your patchwork implementation, I found some inconsistencies that make me wonder whether in some scenario swe can get duplicated point in the output point cloud.
I see at first the reflected_noise_removal is adding noisy points to cloud_non_ground_
Then in a second time the pc2czm is pushing points outside of zones to cloud_non_ground_.
How you can be sure that noisy points will not be duplicated with zone model conversion ? 🤔
Thanks again for you great work.
Cheers ! 😄

Hi @GMahmoud, thank you for interest on our work.
Actually, the z component of noisy points, which are filtered out at the reflected_noise_removal function, are manually set to the value of std::numeric_limits::min(), which is not expected in usual point cloud data. Then, in the concentric zone model division, there is a conditioned part for points with the value std::numeric_limits::min() to skip the for loop, which guarantee noisy points are neglected in further procedures.
Honestly, the code looks somewhat weakly constrained and needs some tight prohibition for noisy points instead of using the specific value as std::numeric_limits::min(). But, it is true that the original code was also designed to skip noisy points in further procedures without any duplication.
Thank you :)


site is timing out

just wanted to let you know your site[1] is timing out for me.

https://robert.kra.hn/posts/2022-04-03_rust-web-wasm/

Thanks for letting me know. Mishap on my side. Should work again.


Doesn't work

I followed 5. Define a card-formatted response, but it didn't work.

Can you provide some more information? Did you see an error?

I followed the instruction on Codelab, but the bot's response is only
"Attendance Bot not responding". From step 1 to 4, it worked fine. But
after step 5, it doesn't work. I just copied and paste by following
instruction of this codelab.
On 2 March 2018 at 00:13, Eric Koleda<EMAIL_ADDRESS>wrote:

Can you provide some more information? Did you see an error?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/googlecodelabs/hangouts-chat-apps-script/issues/1#issuecomment-369643117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjP8pQt9kVaCysFnt77PZcANtzJMS924ks5taB42gaJpZM4SYcis
.

--
Yoshiki Sato

If you go back to the script editor and click "View > Stack Driver Error Reporting" you should be able to see what the error was.

I have the same issue.
onCardClick method isn't called. It even isn't logged in calls

Its because the method name given in the code tutorial for card click is a typo.
Correct method name: function onCardClick(event)
In your code you have probably given the name as "onCardClicked"


Updating Titanium Connection Request to test for Platform 4.0 links

adding process end statement so process will be ended and not hang until it finished
updating with links for the Platform 4.0

I would keep all the servers for now. @jamilhassanspain can you add platform.appcelerator.com?

ok, I'll make these updates.

Approved. Merging.


Mouse selection does not work on iPadOS 14.5

See https://github.com/microsoft/vscode/issues/122653.

Temporary fix in https://github.com/thebaselab/codeapp-source/commit/b860d201d5f1573781bbf8316eb5830caa7bce57


Create file with deprecation message for deprecated runbooks

What this PR does / why we need it:
the sync runbooks automation should update a deprecated runbook content to state that the runbook is deprecated but keep it in the same folder as the others instead of moving it to a deprecated/ directory
https://issues.redhat.com/browse/CNV-45512
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
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

/lgtm


Transactions not shown correctly

My Defi app does show some transactions wrong.
I have recognized, that there was a change in how LM transactions are shown. My earlier transactions are shown separately, for example in the BTC wallet - BTC, in the DFI wallet - DFI and in the BTC-DFI Poolwallet +BTC-DFI all with the same transaction ID and correct amount.
Since a few day newer LM transactions are showing with pairs in the different wallets, but only showing 2 instead of all three involved tokens. For example I see in my BTC wallet a removal of LM fund like - BTC-DFI pool token and + BTC token (both in the BTC wallet) and a corresponding DFI +  and - BTC-DFI transaction in the DFI wallet. So all good but still not ideal (would be showing all involved tokens).
Unfortunately I have two transactions where I don't see the one of the involved tokens at all. The BTC wallet shows + BTC-DFI and - DFI, the DFI wallet shows the same. So I don't see how much BTC was transferred in the transaction at all.
I did reindex the my wallet but this doesn't seem to solve the problem.

Hi @AndErazor , apologies for the delayed reply. You may try to click on Include Rewards to provide more insights to your transaction.

Update v2.1.6 is out https://defichain.com/downloads/.
Do give a thumbs up to this comment if your issue has been resolved, otherwise, you may reopen this issue w new information (include screenshots) and your app logs. Thank you.

Hi @AndErazor , apologies for the delayed reply. You may try to click on Include Rewards to provide more insights to your transaction.

Update v2.1.6 is out https://defichain.com/downloads/.
Do give a thumbs up to this comment if your issue has been resolved, otherwise, you may reopen this issue w new information (include screenshots) and your app logs. Thank you.


Fix retriever

It's weird to have topk in both the init and the methods. Should be one or the other.

@hbertrand agreed, but if we leave it out of the config, then it's up to the front-end to define what that value should be, which is also weird?


[Bug]: Cant get custom dashboard to display

What happened?
Followed the documentation to setup a custom dashboard:

MainDashboard.tsx

ComponentConfig.ts

Application.ts
Log output:

It all seems to be setup correctly but all i see if the default dashboard.
Bug prevalence
Always
AdminJS dependencies version
"dependencies": {
"@adminjs/express": "^6.1.0",
"@adminjs/prisma": "^5.0.1",
"@adminjs/themes": "^1.0.1",
"@types/express": "^4.17.21",
"adminjs": "^7.4.2",
"express": "^4.18.2",
"express-formidable": "^1.2.0",
"express-session": "^1.17.3",
"nodemon": "^3.0.2",
"prisma": "^5.6.0",
"tslib": "^2.6.2"
},
"devDependencies": {
"tsx": "^4.6.2"
},
What browsers do you see the problem on?
No response
Relevant log output
ComponentLoader {
  components: {
    Dashboard: {
      overrides: false,
      filePath: 'g:\\workspace\\REDACTED\\view\\MainDashboard''
    }
  }
}
{ Dashboard: 'Dashboard' }

Relevant code that's giving you issues
const adminOptions: AdminJSOptions = {
            componentLoader,
            resources: ResourceConfig.buildResourceList(prisma),
            rootPath: "/app",
            defaultTheme: dark.id,
            availableThemes: [dark, light, noSidebar],
            locale: ResourceConfig.buildNavList(),
            dashboard: {
                component: Components.Dashboard,
            },
        }

        const admin = new AdminJS(adminOptions);

Can you check if components.bundle.js appears in your browser's Network tab and if there're any contents?
Can you check if the file actually exists at:'g:\\workspace\\REDACTED\\view\\MainDashboard'' (to make sure the resolved path is correct)? You can try to use path.join to provide an absolute path in case it works incorrectly with relative path.

It exists and is loaded, but appears empty

The file definitely exists and its resolved by the path resolver

Solved it! Thanks so much


Cocoapods support

This pull request adds cocoapods support to this library. In contrast to this pull request it also supports Watch OS and fixes a problem where the javascript-library can't be found.

Any particular reason why this PR hasn't been merged in yet?

Can this PR be merged? Looking to use this instead of the fork that has cocoapods integration.

Is there someone who can approve this MR and merge it into master? I would really like to use the cocoapods intergration. Thank you!


Menu bug - clicking white space should make the menu disappear. It does not.

Is the behavior the same as https://www.canada.ca/en.html ?

well look at that.  The behaviour for Canada.ca is that to get the menu to disappear, you have to click on the menu button again (not whitespace).  This was a request from a user in UX testing but since we are using the Canada.ca theme, I think this is not actually a bug for us to fix.  We can close this issue. @ElminaIusifova do you agree?