lldb_{10, 11}: polish the cmakeFlags

Motivation for this change

pass CXXFLAGS directly, not as environment variable
LLDB_CODESIGN_IDENTITY, is ignored on Darwin

Caveat: the commits before c19b4f6 are needed to compile llvmPackages_11 on Darwin, please ignore. They are part of #99984.
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.

@GrahamcOfBorg build lldb_10 lldb_11

Diff makes sense to me. Not realistically going to build/test this any time soon.

@primeos what about these? Let me squash, quick.

Why do you disable RTTI for lldb? I think it would make more sense to enable it, since it is enabled for llvm/clang.

It was disabled before, I didn't change that. What would enabling buy us? LLVM has its own RTTI-ish scheme, and it doesn't need all the features of the C++ RTTI. Or am I missing a detail?

It is set for llvm, because some packages seem to need it (4731485ca2edefcb95f5512907c1b90adafc1eb3)and it is set on clang, because a mismatch can lead to problems with clang-plugins.
I don't know if it changes something for lldb, I just think it makes sense to keep it the same everywhere (at least where it is needed/given).

I know a (Rust) program that uses lldb.so, but it will never care. If other C++ programs want to link against it that in a way that RTTI would become advantageous, I would say let's enable. Otherwise it just increases .so sizes.

I don't know of any programs using lldb in this way, but it leads to linking errors that are hard to track.
I only asked, because it is different from llvm. I'll have another look at it later, maybe RTTI isn't needed anymore, quite some time has passed since it was enabled :)


Restyle table row actions dropdown

This PR restyles the actions dropdown for service collection rows and moves it to the right.
Why? We want a consistent style and location for row actions throughout DC/OS. Using the ellipsis and positioning it to the right will keep us consistent and also keeps us open to adding more actions here. A tooltip has also been added for extra clarity.
Before

After

Haha! Double review 😝

@leemunroe @mlunoe @jfurrow - I applied the requested changes on behalf of @leemunroe. Nice work @leemunroe!

We have some legit integration tests failing:

@mlunoe @jfurrow @MatApple Failing because I removed the dropdown-toggle class (which added a dropdown caret to the icon).
What's the protocol for this situation and tests? e.g. I could change the test and add a class with a js- prefix so the class is only for JS and not styling. Or add a custom data attribute?

@leemunroe We'll change the test to check for the dropdown in the proper position in the DOM. I'll help you out with getting the tests set up today and then we can quickly adjust this test.

retest this please

Can one of the admins verify this patch?

Since this has 2 reviewers approving and my label, I added an extra label for admin tracking.


Problem in uploading file from google collab.

Hi, when I uploaded the file from google collab, it appears like this. The figure is overlapping with the code. How can I resolve it?

@WildJimmy @JustinJaniszewski any solution will be highly appreciated.

I have never experienced such things but why don't you just keep .py file rather that ipyn?

if the file is from a github repository you may just be able to import it

oh sorry, i misunderstood the problem. looking at your repository, the file appears fine to me.

I somehow managed to solve the problem, now it's fine. Thankyou all for your effort.

From: JustinJaniszewski @.>
Sent: Wednesday, November 22, 2023 12:18 AM
To: ubsuny/23-Homework6G1 @.>
Cc: Pooja Shrestha @.>; Author @.>
Subject: Re: [ubsuny/23-Homework6G1] Problem in uploading file from google collab. (Issue #61)
oh sorry, i misunderstood the problem. looking at your repository, the file appears fine to me.
—
Reply to this email directly, view it on GitHubhttps://github.com/ubsuny/23-Homework6G1/issues/61#issuecomment-1822299044, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BCIY2CNUINODEDJUQN24K23YFWYM3AVCNFSM6AAAAAA7VN7UFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGI4TSMBUGQ.
You are receiving this because you authored the thread.Message ID: @.***>

Glad to hear it.

I was here to see if its resolved. Do you care if you share how was it resolved, just for future?

I agree, I would like to know the solution


The wallet list commands should not prompt for a wallet address

All the wallet list commands always refer to the current logged in account so there is no need to prompt for the wallet address. It can just use ldposClient.getWalletAddress() to find out what the current wallet address is.
The functionality to see transactions for a different account should already already provided by account list commands such as account list outbound-transactions commands.

fixed in cli-builder


Fix font artifacts

This fixes #365 by merging the 3 fonts from quran/quran.com-images#7,
quran/quran.com-images#8, and quran/quran.com-images#9.

Deployed to: http://staging.quran.com:32786

i've re-deployed to staging pointing to the updated fonts - i think we should go ahead and push this (we'll also have to push to cdn). please compare:

http://quran.com/4/171 with http://staging.quran.com:32789/4/171 (mouse over the word wa7id in line 4 (the 3rd word) and notice the highlighted portion under the word sub7anah (the 5th word)).
http://quran.com/61/14 with http://staging.quran.com:32789/61/14 (mouse over the ayah number in both to see the difference - it's a line in the original one that this removes).
http://quran.com/63/4 with http://staging.quran.com:32789/63/4 (mouse over the ayah number in both to see the difference - it's a very minor different)

+1 !!


Control what mixer attributes Envoy uses to cache its Mixer responses

Describe the feature request
We would like a way to control what mixer attributes Envoy uses to cache its Mixer responses.
Describe alternatives you've considered
We've already implemented a cache in our MixerAdapter, that has a very high cache hit rate. However, even on cache hits we're seeing 4-5ms of latency added purely on the Mixer grpc call. This seems to be in line with Istio's publisher performance numbers, found here: https://istio.io/docs/concepts/performance-and-scalability/. Seemingly the only way to cut that out is by improving the cache hit ratio in Envoy itself.
Affected product area (please put an X in all that apply)
[ X ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ X ] Performance and Scalability
[ X ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Additional context
We use an internal service to manage/store authorization data controlling which services can talk to each other. To enforce that, we added a MixerAdapter that calls out to our service for this authZ check. That works, but is not performant enough for our use case. So, we'd like to bypass the Mixer grpc call as often as possible.
Looking at Envoy debug logs from istio-proxy, we see the cache key being made up of context.protocol, context.reporter.kind, destination.namespace, destination.port, destination.principal, destination.uid, request.method, source.uid
As the authZ is static within environments, our ideal cache would be limited to exclusively the destination.principal and destination.namespace.
As per the Mixer docs (https://github.com/istio/proxy/blob/master/src/envoy/http/mixer/README.md) Mixer server controls which attributes to use for cache keys. It also controls the cache expiration.
So mixer appears to be the proper place for this enhancement.

CC @aattuluri @jwebb49

Does your mixer rule or instance reference those attributes? Mixer should already construct cache key from attributes that are actually being looked up. Also by principal namespace do you mean namespace from source.principal? It so it is weird why that attribute does not show up in your cache key.

I edited my description to be a little more specific. It's not that the attributes we care about are missing from the cache key, it's that we would like to exclude the rest. Both the principal and namespace are being incorporated into the existing cache key. But additional cache misses are being triggered by (for example) requests with different methods, although we know a different method will never impact the authorization decision.

Yes, mixer should not include attributes into cache key if it is not used by rule/instance. So you are saying other attributes like destination.port, request.method are not used anywhere in your config but show up in cache key? That sounds like a bug to me...

The short answer is that we do have rules/instances that use these attributes.
But I think this is where my understanding breaks down. I think my core question is how does the Proxy determine which mixer calls to make synchronously, and which to make asynchronously? I read this in the docs: The Envoy sidecar logically calls Mixer before each request to perform precondition checks, and after each request to report telemetry. I don't understand how Envoy knows which adapters to call before and after. My understanding from a big picture suggests that Authorization should be a precondition, and metrics a telemetry. But yet I see the context.reporter.kind  attribute (which seems to be only in the accesslog instance, used by the stdio rule) in the cache key for the precondition call, although that strikes me as something that would be a metric. Are you able to shed any light on that?
My expectation would be the cache keys for precondition checks would consist only of attributes included in the params object of the required instances. Instead, it seems as if all of the attributes used for all of the rules are being combined in the cache key. Perhaps the issue would have been better worded to request an explicit way to exclude attributes from the cache key, or to override the dynamically created cache key in some static way.

Thanks for that pointer. I'm doing a little digging on my end as well based on that.
Here's our config: https://gist.github.com/josephpeacock/6490d6f78f50499c514f6fb36a4400c6
Based on our conversation and looking more closely, my original example of method was a poor one, as request.method is used for the registry-auth instance. But I'm still concerned that we see the context.protocol and context.reporter.kind attributes for the precondition mixer call.
Also, if the cache key is generated based on all of the referenced attributes, I'm confused as to how request.path is not included in the cache key, as it is referenced by the registry instance.

After some testing on my end, I suspect there may be a bug somewhere in the cache key creation logic. I set up two test services within the mesh, let's call them inbound and backend. I SSH'd into the inbound pod, and curled the backend, measuring the time taken (round-trip) per call. For each new path attempted, the first call would take 11ms, and subsequent calls would take 8-9ms. In addition, I'd see logs on the Policy pod showing a precondition call for the 11ms ones but not the 8-9ms ones.
curl backend.global/d -w %{time_total} &&  echo \n
0.011n
curl backend.global/e -w %{time_total} &&  echo \n
0.011n
curl backend.global/e -w %{time_total} &&  echo \n
0.009n
curl backend.global/e -w %{time_total} &&  echo \n
0.011n
curl backend.global/f -w %{time_total} &&  echo \n
0.011n
curl backend.global/f -w %{time_total} &&  echo \n
0.009n
curl backend.global/f -w %{time_total} &&  echo \n
0.009n

The 11ms calls corresponded with logs looking like this on Policy:
adapters	Registry Handler Invoked	{"adapter": "registry-auth-handler.istio-system"}
During this time, here was my list of rules:
kubeattrgenrulerule      66m
registry-rule            66m
tcpkubeattrgenrulerule   66m

To try to isolate the impact, I deleted the Registry rule (our custom authorization check), and discovered that the pattern was no longer present, all requests took 8-9ms and no logging was showing up in Mixer.
I then restored the Registry rule, but deleted the two attrgenrulerules (So our authorization rule is the only one present), and once again saw that all requests took 8-9ms and no logging was showing up in Mixer.
In other words, a combination of the attribute generation rules and the authorization rule combines to trigger cache misses on a path change. Both of the attribute generation rules point to the following instance (note compiledType kubernetes):
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  annotations:
  creationTimestamp: "2019-11-01T21:46:49Z"
  generation: 1
  labels:
    app: mixer
    chart: mixer
    heritage: Tiller
    release: istio
  name: attributes
  namespace: istio-system
spec:
  attributeBindings:
    destination.container.name: $out.destination_container_name | "unknown"
    destination.ip: $out.destination_pod_ip | ip("<IP_ADDRESS>")
    destination.labels: $out.destination_labels | emptyStringMap()
    destination.name: $out.destination_pod_name | "unknown"
    destination.namespace: $out.destination_namespace | "default"
    destination.owner: $out.destination_owner | "unknown"
    destination.serviceAccount: $out.destination_service_account_name | "unknown"
    destination.uid: $out.destination_pod_uid | "unknown"
    destination.workload.name: $out.destination_workload_name | "unknown"
    destination.workload.namespace: $out.destination_workload_namespace | "unknown"
    destination.workload.uid: $out.destination_workload_uid | "unknown"
    source.ip: $out.source_pod_ip | ip("<IP_ADDRESS>")
    source.labels: $out.source_labels | emptyStringMap()
    source.name: $out.source_pod_name | "unknown"
    source.namespace: $out.source_namespace | "default"
    source.owner: $out.source_owner | "unknown"
    source.serviceAccount: $out.source_service_account_name | "unknown"
    source.uid: $out.source_pod_uid | "unknown"
    source.workload.name: $out.source_workload_name | "unknown"
    source.workload.namespace: $out.source_workload_namespace | "unknown"
    source.workload.uid: $out.source_workload_uid | "unknown"
  compiledTemplate: kubernetes
  params:
    destination_port: destination.port | 0
    destination_uid: destination.uid | ""
    source_ip: source.ip | ip("<IP_ADDRESS>")
    source_uid: source.uid | ""

I plan to dive a little deeper to try to figure out why we may be paying this performance penalty. In the meantime, I have two main questions:

What's the downside to removing these attribute generation rules? Are they crucial for metrics or authorization rules to work?
Is this expected behavior? If not could we change this issue into a bug?

What's the downside to removing these attribute generation rules? Are they crucial for metrics or authorization rules to work?

k8s adapter is mostly for telemetry purpose and if you don't need the generated extra k8s attributes, it does no harm to remove it:
https://github.com/istio/istio/blob/f8149a108b613994be519b42a96e671f303ec80f/install/kubernetes/helm/istio/charts/mixer/values.yaml#L86

Is this expected behavior? If not could we change this issue into a bug?

I think this is actually expected, as attr gen adapter runs as precondition adapter for both policy check and telemetry, though I don't think we have a way to selectively apply it only for policy or telemetry, that could be a possible enhancement.

Do you need more help on this topic? If not could we close this issue? Thanks!

Yeah, we can close this. Thanks so much for all of your help!
We've bumped our cache hit rate from <20% to >60% by tuning some of the attributes on our precondition checks and the attribute generation, and are seeing a 1.2ms(average)-3ms(p99) performance improvement per avoided Policy call.
I think being able to define attribute generation to be selectively used for telemetry or policy would be a very useful enhancement, but it probably doesn't fit in the scope of this issue.


Add EBS storage to reports

Adds report for EBS storage per volume type.
Also showing snapshot storage. See attached image.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@Till--H, thanks for the contribution. This doesn't seem to match all volumes. Here are usage types that don't show up for me:

line_item_usage_type
line_item_line_item_description

EUC1-EBS:VolumeUsage.gp2
$0.119 per GB-month of General Purpose SSD (gp2) provisioned storage - EU  (Frankfurt)

EU-EBS:VolumeUsage.gp2
$0.11 per GB-month of General Purpose SSD (gp2) provisioned storage - EU  (Ireland)

EBS:VolumeUsage.gp2
$0.10 per GB-month of General Purpose SSD (gp2) provisioned storage - US  East (Northern Virginia)

Can you please check again - and also pay attention to the same issue with snapshots as I don't have examples for that?


ios problem: cannot open my app

I am using flutter 2.0.3 and receive_sharing_intent 1.4.5.
For the demo case, I can receive a picture, but JSON file failed.
then, I tried to use it in my own project, the app is shown on the list, but cannot open my app. both picture and JSON file failed.
I don't know the reason and hope someone can help me. Thanks.

I met the same problem, can you solve it？

@llyl Hey Bro，Have you solved this problem? If so is it convenient to share? Thank you very much!

Yes, I solved it and it's very convenient. But I don't know the reason, I just create a new project and copy everything, and then it works.


Remove anyhow from signatures.

This removes anyhow::Error from the future signatures. That way it's easier for people to integrate this crate without having to bring anyhow as a dependency.
I've updated all the examples.
Signed-off-by: David Calavera<EMAIL_ADDRESS>

Thanks for your pull request!
I think having an internal error type is a good idea, but I'd keep the examples unchanged, as anyhow was the main use case I'm developing for, and to ensure this is not a breaking change. An example without anyhow is already there as 15_without_anyhow, to ensure the crate is compatible with non-anyhow examples.
Further, the only place I left over where we use anyhow now is anyhow::anyhow!("Subsytem errors occurred.").into().
Therefore, would it be benefitial to remove it completely (from lib/) and instead write our own error type? (for example using the thiserror crate)
The main goal if possible in all of this is to leave the examples untouched. Changes that require adjustments to the examples are breaking changes and would need a new major version. As I just released a major version for anyhow, I'd like to avoid that. (maybe, in hindsight, i should have released a beta until we are done, I just didn't realize yet that there will be further proposed changes :) )

Coverage remained the same at 100.0% when pulling fdb1ed37128ee68932b588e757e9e84729e47220 on calavera:remove_anyhow into 0080fec18d18c0ec1fc10653009ec0fba69e98f4 on Finomnis:main.

I'm not 100% sure to the reasoning behind this change. You write "without having to bring anyhow as a dependency", but you don't have to, as far as I can tell. Or am I wrong?

Would you mind sharing your usecase in a minimal example, so I could understand what the issue with the current API is?
(if I understood it correctly you use snafu for error handling, so would you mind providing a minimal snafu example that is incompatible with the current API?)

I'm using a different crate to do error handling, miette. It becomes inconvenient when I have to mix both, so I thought that returning an abstract type would be more generally convenient for people that use this library. Feel free to close this PR if you don't want to change the API, I totally understand it. I'll find a different way to deal with my problems.

No no, don't misunderstand me, I'm not trying to dismiss your point, I'm trying to understand it :)
I'll attempt to write a minimal example that uses miette for error handling and see into which problems I run.

Even with your change, I seem to be unable to implement a miette based subsystem. It says that it cannot convert ErrReport into Box<dyn Error + Send + Sync> because neither a From or an Into exists. Were you able to use your change with a miette subsystem?

I'm slowly at the point where I'm ready to transition to using Box<dyn Error> in all interfaces.
I seem to be unable, though, to get an anyhow based example running with the Box<dyn Error> mode. Neither am I able to implement a miette example.
The main problem I keep stumbling over is that in order to use anyhow::Result or miette::Result as the return value of main(), you need to somehow convert Box<dyn Error> into anyhow::Error or miette::Report. Both of them implement From<std::error::Error>, or at least a way to convert from std::error::Error.
Now here comes the problem I keep stumbling over: Box<dyn Error> does not implement std::error::Error. (Discussion here).
I'm kind of stumped how to solve this Problem. Sadly, your pull request also doesn't address this issue, as you rewrote all examples to now use Box. Did you manage to get your pull request running with miette::Report or anyhow::Error?
More discussion here:

https://github.com/dtolnay/anyhow/issues/83

I attempted to solve it similar to this:
https://stackoverflow.com/questions/65151237/why-doesnt-boxdyn-error-implement-error
The problem here is that we now have to manually add every error type we want to support, removing the possibility to support a generic Into<std::error::Error> or Into<Box<dyn Error>>.
This all would be solved by template specialization, which would be an awesome feature to have in Rust in general.
Sadly, the corresponding RFC is not through yet.
I do have some more ideas left still, but I'll be on vacation next week. But from my current train of thought it becomes more and more likely that I might actually merge your pull request as-is and then write some specific examples for anyhow and miette.
Would it be fine for you if I made some minor modifications to your change? (Uncertain if I should do that directly on your change or merge it into a local experimental branch first)

@Finomnis by all means. Don't hesitate if you want to rewrite all my code. I really appreciate your thoroughness with it. I'm slowly realizing too how challenging error handling is with all those crates that are mostly similar, but not the same 🤦

-> Merged into my own branch, so I could take over development without losing the fact that you contributed (so your name is shown in the 'contributors' section of my repository)


Enforce collection run time limit.

30 seconds? This will help to guard against infinite loops, etc.
Should be configurable.

related to #22


Transition on load

Is it possible to add transition to first image which show after load? Fade for example.

It's possible if you do it with a simple trick.
Set the image with opacity 0 and set the transition, then when the ready event is fired set the opacity to 1.
By default it is not possible because all transitions are defined to go, not to come. I am not sure if you understand what I mean, but all transitions have a required image from but the image destination is optional dpending on the transition, and that is the opposite of what you want, that is why I recommend you to use CSS and after all is not a big deal, isn't it?

Right, thank you once again and great progress with your component. Regards:)


chrysalis: 0.7.9 -> 0.8.4

Motivation for this change
Update to latest Chrysalis v0.8.4
Things done

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

[x] 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"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@herrwiese, can you take a look? This should be a quick review.


Even with resolver=2 features are unified when starting from project root

Problem
Different features of the crate a used depending on how what is the directory we start compilation from.
Steps
Full code is in this repository https://github.com/stepancheg/cargo-features-bug
What it has:

three crates: a, b, common
crate common defines two features x and y and has a function which prints the features
crate a depends on common with feature x
crate b depends on common with feature y
crate a has a binary which prints features of common
there is not package in the workspace root

Steps

clone the repository
cargo run --bin a from the repository root:

feature = "x"
feature = "y"

but cargo run -p a from the repository root:

feature = "x"

and from directory a, cargo run -p a or cargo run --bin a

feature = "x"

Which means feature y of crate common is activated depending on what is the directory we start compilation from.
I don't know if that's expected behavior but it is very unintuitive.
Cargo tree
Additionally, cargo tree does not help to debug it. From the repository root if I do cargo tree -p a -e features (which is what I do when I see misbehaving cargo run --bin a):
a v0.1.0 (/Users/nga/devel/cargo-features-bug/a)
├── common feature "default"
│   └── common v0.1.0 (/Users/nga/devel/cargo-features-bug/common)
└── common feature "x"
    └── common v0.1.0 (/Users/nga/devel/cargo-features-bug/common)

It does not give any hint that cargo run --bin a would enable feature y.
There's no option cargo tree --bin a.
Possible Solution(s)
Do not use command without explicit -p flags from the repository root.
Version
cargo 1.68.0-nightly (d992ab4e9 2023-01-10)
release: 1.68.0-nightly
commit-hash: d992ab4e9034930e7809749f04077045af8f4d79
commit-date: 2023-01-10
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.87.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.3.1 [64-bit]

Which means feature y of crate common is activated depending on what is the directory we start compilation from.

Unless I'm misreading something, that is an incomplete statement.  What matters is what package is selected and not just the directory

in the root the default selection is all
in a/ the default selection is a
with -p a, a is explicitly selected

The features are then unified across all selected packages.  This is behaving as intended and resolver=2 was not intended to change this behavior.

From the repository root if I do cargo tree -p a -e features (which is what I do when I see misbehaving cargo run --bin a):
...
It does not give any hint that cargo run --bin a would enable feature y.

Sounds like cargo tree is correctly reporting what happens when you do cargo run -p a and it shouldn't be giving you a hint for cargo run --bin a .

There's no option cargo tree --bin a.

That would just be cargo tree.  --bin does not do package selection but runs the specified target among the selected packages.

Do not use command without explicit -p flags from the repository root.

I'm not quite sure what you mean here.  Are you suggesting we error instead?  Unfortunately, that is not likely to happen as that would be a breaking change.

Are you suggesting we error instead? Unfortunately, that is not likely to happen as that would be a breaking change.

If there was a warning, that would have saved me an hour of debugging. Something like this:

building crate common with features x and y instead of just x because package a is not selected explicitly, so all workspace features are used. Consider re-running the command with a flag -p a.

A warning would only help a fraction of users and would likely not be able to report the difference in features.
We are also very judicious in producing warnings because there is no way to control them.  With #12115, we might start introducing more cargo warnings.

Also, it looks like this is a duplicate of #8157, closing in favor of it.  If I missed an aspect that is different, let us kow.


Fixed offset for years view

Q
A

Bug fix?
yes

New feature?
no

BC breaks?
no

Related tickets

License
MIT

Thanks @TorbenHedstrom for the PR! Can you provide a jsfiddle to show the original problem?

You are most welcome @acrobat - I am a bit of a JSFiddle noob, but the issue is also on the demo-site:
https://uxsolutions.github.io/bootstrap-datepicker/?markup=embedded&format=&weekStart=&startDate=&endDate=&startView=0&minViewMode=0&maxViewMode=4&todayBtn=false&clearBtn=false&language=en&orientation=auto&multidate=&multidateSeparator=&keyboardNavigation=on&forceParse=on#sandbox
Putting the date picker-component in year-mode (Like: {viewMode: 'years'}):
Headline is for example: 2000-2009
While the calendar shows: 1999, 2000, 2001, 2002, 2003... 2010.
So (even if it is intentional) the headline is not matching the component. Clicking the lowest/highest year (1999/2010) result in that year being filled into the text-field.
Config is:
  .datepicker(
    {
      format: ' yyyy',
      viewMode: 'years',
      minViewMode: 'years',
      endDate: '+0d',
      todayBtn: 'linked',
      language: 'da',
      maxViewMode: 1,
      weekStart: 1,
      autoclose: true
    }


Fixes #69583

FIxes #69583
This patch removes the need to use lsof on linux platforms and instead uses the default readlink function in fs. It then reads directly the symbolic link in /proc. For all Linux based systems this should be fine.
http://man7.org/linux/man-pages/man5/proc.5.html
This approach should also be a lot faster compared to the previous lsof command. It also seems to work even if the user has remounted proc to hidepids.
ie mount -o remount,rw,hidepid=2 /proc
This solution will solve the case when users don't have lsof installed.
For OS X, I have kept the old lsof mechanism as they don't have a /proc directory.
EDIT:
Sorry, just refactored the code to make a little more sense. In this case, only run the commands if it is known to work on the respective platforms, otherwise fallback to just return _initialCwd.

Hi, thanks for merging.

I made a change to handle err just to be safe (which I don't think should ever happen).

Would it make sense to do the same if lsof doesn't work for Mac users? At least that way we can be certain it returns something.

@Kedstar99 I'd say let's leave it as is unless someone complains on mac, seems like it's always built-in.


[help] How to wrap fragments with complex html (to display to users in a rails app)?

What problem are you trying to solve?

people can reply to my rails app via email (via an action mailbox facility).
The problem is that the email sent to the rails app contains previous replies - which clutter up the view. I wish to hide all the previous replies. See a picture below which demonstrates this issue:

The proposed solution
The solution proposed is to:

parse the email response, and then to
wrap the "replies" with a little bit of code to trigger a toggle functionality.

I was hoping someone could point me in the direction of the best way to wrap nokogiri fragments.
    body = "

"

    doc = Nokogiri::HTML.fragment(body, encoding = nil)
    table = doc.at("table")

    wrapped_table = ? # how can I wrap table in complex html? - erb is preferable

    # I would like to display `body` in a rails view AFTER it has been transformed:
    # `table` needs to be wrapped in some complex html and then replaced
    # with the original. How can I easily wrap the table in complex html.
    # the documentation suggests I wrap it like this - but it seems cumbersome:
    table.wrap("

")

   # it is preferable to do something like this
   # _wrapped_table.html.erb

           <--- some html that is cumbersome to type as a string ---->
                <%=  table.to_html %>

   # and to then simply replace `table` with the `wrapped_table`  and to then show that to users
    table.replace(wrapped_table)

Q: Is there an easy way to wrap nokogiri fragments (preferably via erb)?
any advice would be appreciated.
Environment

Rails
Erb
Ruby 2.7.2

Hi, @benkoshy! Thanks for asking this question.
One way to do this, if you have a single element that you want to wrap around table, is to use Node#wrap like this:
fragment = Nokogiri::HTML.fragment("

")
fragment.at_css("table").wrap("

")
puts fragment.to_html
#

#

#

#

#

For more complicated markup, you could add the new sub-tree to the DOM and then reparent the table, like this:
fragment = Nokogiri::HTML.fragment("

")
table = fragment.at_css("table")
table.add_next_sibling("

")
fragment.at_css(".final-destination").add_child(table)
puts fragment.to_html
#

#

#

#

#

#

#

#

#

Does that help?

@flavorjones thank you.
i appreciate the thoughtful response.
I have adopted a slightly different solution. The short version is noted below. Perhaps it could be helpful to someone in the future?

santizer is a helper function used to whitelist and sanitize the nokogiri fragments turned into html.
I have made use of a library: Github View Components - extensively.

# MessageComponent.rb
class MessageComponent < ViewComponent::Base
  def initialize(body:)
    @body = body
    @doc = Nokogiri::HTML.fragment(@body, encoding = nil)
    @reply = @doc.at("table[role=presentation]")
  end
end

<%# message_component.html.erb %>
<% if @reply %>
  <% wrapped_value = WrappedMessageComponent.new(reply: @reply)  %>
  <% @reply.replace(render(wrapped_value)) %>
  <%= sanitizer(@doc.to_html).html_safe  %>
<% else %>
  <%= sanitizer(@body).html_safe %>
<% end %>

And the wrapped component is where all the magic happens:

We get all the benefits of using erb i.e. adding complex ruby to our markup, and we can also make use of our text editors to bash out html elements in that regard.
testing is also straight forward.

# WrappedMessageComponent.rb
class WrappedMessageComponent < ViewComponent::Base
  def initialize(reply:)
    @reply = reply
  end
end

As soon as the html hits the dom, a stimulus controller is invoked and operates on the button, according to the markup:

  <button type="button" class="btn btn-light" data-action="toggle#toggle">
    <%=  ruby_code_here  %>
  </button>

    <%=  sanitizer(@reply.to_s).html_safe  %>

def sanitizer(fragment)
   # code to sanitize the fragment
end

And then in some rails view:
<%# @email.body contains the action mailbox reply. %>
<%= render MessageComponent.new(body: @email.body) %>

Overall, our goals have been acheived:

using erb to wrap html, which would otherwise have been cumbersome.
allows for very easy testability.

Awesome, thanks for sharing your solution!


CMake bug fixes and performance improvements.

Pin versions of Ceres and protobuf (Fixes #341).
Require Lua >= 5.2 (Fixes #629).
No longer run ceres tests in CI. We implicitly test Ceres through Cartographer's tests and this saves ~4 minutes on CI.

No longer run ceres tests in CI. We implicitly test Ceres through Cartographer's tests and this saves ~4 minutes on CI.
Wait, where has this been changed in this PR?

@ojura Ups, thanks for catching this merge-o.
@wally-the-cartographer merge

Merge requested by authorized user SirVer. Merge queue now has a length of 1.


Replaced address element with non-semantic markup

Regarding this issue: #87
The address element has been removed and replaced with a non-semantic element (div). Also, a address class was applied for address specific styles.
Styles can be found in this PR: #90

@fuhton This looks good to merge on my end. If this is good on your end as well, let's merge.


Modify distance tool interaction to avoid stuck state

This PR modifies the interaction of the distance-measuring tool to match the scheme described in #293. Now, the initial creation of the measuring line is done without dragging - after the tool has been activated, the first click places one endpoint of the line, and the line will follow the user's mouse until they make another click. If the user doesn't move between the first and second clicks, the second click is just ignored and the tool remains in the "drag to extend line" mode.
Note that the post-line creation interaction has not been modified - it's still the same grab-and-drag interaction.

In some circumstances we can't reproduce reliably, it is still possible to get the measuring tool into a state where the measured line disappears completely (presumably because we gave it a "zero" value), but the tool is still "active" and the user will be stuck.
Two ways I've been able to make this happen:

I double clicked on the same spot, or
I clicked for 1 endpoint, moved the mouse around, and brought the line back to the exact same endpoint and clicked again.

These actions don't consistently put the tool in the bad state. If we can't figure out how to reproduce or fix this, we'll make this its own issue and keep an eye on it.

@patudom My latest commit changes the updating portion of the interaction to also not require dragging. I think it's where we want it to be now - let me know if you notice any issues.


Build tool

Well It will be good to make small tool that will compare verisons and build the code for different target
Build now using command :
cargo build --target=arm-unknown-linux-gnueabihf

sudo -s nano ~/.cargo/config
Write via nano editor
[target.arm-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"
Save and exitsudo -s nano ~/.cargo/config
Write via nano editor
[target.arm-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"
Save and exit

cross is our savior


Arch Linux: target remote :3333 "Connection timed out"; needs IP address

In 2.2 Hardware, the following gdb command is listend to connect to openocd:
(gdb) target remote :3333

When I ran this on my machine, it consistently timed out:
:3333: Connection timed out.

The command I'm invoking for the gbd console is:
arm-none-eabi-gdb -q target/thumbv7em-none-eabihf/debug/examples/hello
For some more version info, here's the output of arm-non-eabi-gdb --version:
GNU gdb (GDB) 9.2
<snip>

And openocd --version:
Open On-Chip Debugger 0.10.0
<snip>

Openocd is indeed running and listening on the correct port,  as per netstat -tulpn | grep LISTEN:
tcp        0      0 <IP_ADDRESS>:3333            <IP_ADDRESS>:*               LISTEN      13303/openocd

Fix/workaround:
Seeing the <IP_ADDRESS> in there gave me the idea to try the following:
(gdp) target remote <IP_ADDRESS>:3333

This results in the output described in the book, and allows me to continue.
Perhaps it would help some if this solution was added as a note in the book.
A further note, the same applies to the gdb script openocd.gdb, changing the first line from target extended-remote :3333 to target extended-remote <IP_ADDRESS>:3333 fixes the later part that hit the same issue.

I ran into a similar problem with netstat -tulpn | grep LISTEN also showing:
tcp        0      0 <IP_ADDRESS>:3333            <IP_ADDRESS>:*               LISTEN
But with the following error:
(gdb) target remote :3333
:3333
: cannot resolve name: Servname not supported for ai_socktype
:3333
: No such file or directory.
(gdb)

I found a solution at https://elinux.org/OpenOCD_Ubuntu_Package:

The package installs config files to /usr/share/openocd/scripts, but OpenOCD looks for config files in /usr/local/share/openocd/scripts. Fix that now by creating a symbolic link in /usr/local/share to /usr/share/openocd. In the terminal window, type:

cd /usr/local/share
sudo ln -s /usr/share/openocd .

Hope that this works for you too!

I ran into a similar problem with netstat -tulpn | grep LISTEN also showing:
tcp        0      0 <IP_ADDRESS>:3333            <IP_ADDRESS>:*               LISTEN
But with the following error:
(gdb) target remote :3333
:3333
: cannot resolve name: Servname not supported for ai_socktype
:3333
: No such file or directory.
(gdb)

I found a solution at https://elinux.org/OpenOCD_Ubuntu_Package:

The package installs config files to /usr/share/openocd/scripts, but OpenOCD looks for config files in /usr/local/share/openocd/scripts. Fix that now by creating a symbolic link in /usr/local/share to /usr/share/openocd. In the terminal window, type:

cd /usr/local/share
sudo ln -s /usr/share/openocd .

Hope that this helps out anyone else who comes across this (or similar) error!

Had this happen to me - I was running in VIrtualbox and had not yet added the USB development board to the virtual machine... if you are not using a virtual machine, it may be the the hardware is not mounted.

Thank you for finding a fix for this. I would welcome a PR with it for a broader benefit.


fix: docs

fix: docs

 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.


Entire rule being overwritten

id: b73b3597-ee31-4629-aaa1-30a8d08a04f4
original ruleid: CG0437
new ruleid: CG0415
The original rule has yaml that is likely not able to be parsed. If a rule's yaml cannot be parsed, it should not be updated.
For some reason, the rule is being completely replaced by a new rule, CG0415.
This is probably because the CG0415 content is still in memory from the previous rule.
I would expect the original unparsable rule to be unchanged and a new rule CG0437 to be added.

OK. This rule has ":" in the text which causes the issue. I will create a special case for this.

How do you relate CG0437 with CG0415? I do not see what you described, i.e., CG0437 has CG0415 contents. BTW, CG0415 has two documents.

You shouldn't need a special case. In general, if a rule content cannot be converted to json, it should not be updated.
You can see the relationship by looking up the original (in prod) and updated rule (in dev) using the id b73b3597-ee31-4629-aaa1-30a8d08a04f4
There is 1 CG0415 input document and 2 CG0415 output documents. This is because the input document is being updated (correctly) AND an additional CG0437 is being replaced (incorrectly) by CG0415 from contents of the previous iteration of the loop.

Since Rule CG0437 has a problem, it did not get copied over and a new document is generated for it. So it is not overwritten since the new doc has a new GUID.
YAML Description: Verify that --SOCCD matches MedDRA primary system organ class code Sensitivity: Value Severity: Error                     : Scopes:   Standards:     - Name: SDTMIG       Version: "3.4"   Classes:     # {Source Class: EVT}     Include:       - Events   Domains:     # {Source Domains: AE, MH, CE}     Include:       - AE       - MH       - CE #need operator/function to cross check and verify dataset --SOCCD against MedDRA SOCCD (any dictionary #lookup) ,drafting using the logic of the cross dataset check for now

I am closing this one since this issue is due to the documents did not get copied over.


Add Change Background Color Option/Button

I'm thinking that we can add a option for changing the tan/yellow-ish background color to a preferred one. The option can be limited to around five options, or we can use the same/similar color file used for changing the graph line and point colors.

I would ask Dr. Ludi

Regarding the changing background color feature, Prof. Ludi replied:
"I think that is fine, but you will want to add in the ability to change the bg color of the graph too (it does not have to be the same as that of the text)."
So, as of now, I will try to work on making it while figuring out the right placement of the buttons and/or the option select along the way.

I think this issue can be closed?


rosidl_typesupport on Foxy: same file in two packages

Compilation of the whole repository is failing since to the two packages ship the same file and the compiler falls into a previous definition problem.
  // add includes
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/message_type_support_dispatch.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/service_type_support_dispatch.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/type_support_map.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/message_type_support_dispatch.hpp"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/service_type_support_dispatch.hpp"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/type_support_map.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/identifier.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/visibility_control.h"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/identifier.hpp"
  #include "/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/visibility_control.h"

  // add namespaces
  namespace rosidl_typesupport_cpp{typedef int tmp_add_type_1;}
  rosidl_typesupport_cpp::tmp_add_type_1 tmp_add_func_1(){return 0;};

  // add classes
  rosidl_message_type_support_t* tmp_add_class_0;
  rosidl_service_type_support_t* tmp_add_class_1;
  type_support_map_t* tmp_add_class_2;

The GCC parameters:
  /usr/bin/x86_64-linux-gnu-gcc-9 -fdump-lang-raw -fkeep-inline-functions -c -x c++ -fpermissive -w --std=c++17 -DBOOST_HAS_PTHREADS=1 -I/opt/ros/foxy/src/gtest_vendor/include -I/opt/ros/foxy/include "/tmp/JGxAGlGCBB/dump1.h"  -I/tmp/tmp2214w6b4/files/opt/ros/foxy/include

In file included from /tmp/JGxAGlGCBB/dump1.h:8:
/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/type_support_map.h:26:16: error: redefinition of ‘struct type_support_map_t’
   26 | typedef struct type_support_map_t
      |                ^~~~~~~~~~~~~~~~~~
In file included from /tmp/JGxAGlGCBB/dump1.h:5:
/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/type_support_map.h:26:16: note: previous definition of ‘struct type_support_map_t’
   26 | typedef struct type_support_map_t
      |                ^~~~~~~~~~~~~~~~~~
In file included from /tmp/JGxAGlGCBB/dump1.h:8:
/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_cpp/type_support_map.h:46:3: error: conflicting declaration ‘typedef int type_support_map_t’
   46 | } type_support_map_t;
      |   ^~~~~~~~~~~~~~~~~~
In file included from /tmp/JGxAGlGCBB/dump1.h:5:
/tmp/tmp2214w6b4/files/opt/ros/foxy/include/rosidl_typesupport_c/type_support_map.h:46:3: note: previous declaration as ‘typedef struct type_support_map_t type_support_map_t’
   46 | } type_support_map_t;

Ideally one of the files should be removed but the bug can point to problems in the way the auto-abi-checker is working: each package should be compiled in isolation, if possible.

Possible workaround https://github.com/ros2/rosidl_typesupport/issues/79


Disable missing CRDs in 2.x

What this PR does / why we need it:

Refactors the CRD detection utility to work with any CRD.
Disables the KongClusterPlugin controller if it is not present. We maybe need this less in 2.x given the explicit flag and that you have to intentionally remove the CRD when installing KIC, but it probably should be in still to smooth 1.x -> 2.x upgrades.
Updates defaults for Knative controller. Since it is automatically disabled if not present, we can enable it by default.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #1448
Special notes for your reviewer:
#1396 previously added a utility for this specific to Knative. This PR makes the utility generic and uses it for KongClusterPlugins also. This utility does differ from the 1.x utility (see the CRD detection function and example usage), though I don't think there's any reason we need to make the 2.x version match it--is anyone aware of a meaningful difference between the two strategies?
#1448 suggests there may be other CRDs we want to catch with this. Do we? There wasn't anything else like this in 1.x AFAIK. We may want to disable the apiextensions and/or networking v1beta1 Ingress controllers in the future for K8S versions that lack them, but I'm not sure we've committed to that yet.
PR Readiness Checklist:
Complete these before marking the PR as ready to review:

[ ] the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

@rainest non-blocker, but how would you feel about managing core ingresses with this update as well?

I think this is quite doable--I thought the Ingress version negotiation in 1.x was something different for some reason. I want to double-check what we did there for the different versions to be sure, but assuming it's not or it's close enough that it can be easily adapted, I'll add it to this.

b43acadc adds something similar to https://github.com/Kong/kubernetes-ingress-controller/blob/1.3.1/pkg/util/ingressapi.go for 2.x. The 2.x variant differs because we no longer use discovery clients. It's also explicitly for Ingress APIs only, whereas the original NegotiateResourceAPI() suggested generic API support, but was de facto Ingress-only because it used the IngressAPI type in its arguments and return values.
We will presumably need a generic API version negotiator in the future as we add new versions of our CRDs, which I expect will happen at some point. I didn't design for that in the proposed 2.x implementation because we don't yet have a use for anything other than Ingress and designing generic functions before you can actually use them for more than one type is hard.
I'm not immediately sure how to add unit tests for the new system for lack of client-go familiarity. Would anyone with more knowledge be able to assist me in setting up a mock environment similar to what we have in https://github.com/Kong/kubernetes-ingress-controller/blob/1.3.1/pkg/util/ingressapi_test.go but suitable for use with client.RESTMapper()?
Integration testing suggests the new negotiator does indeed work insofar as the manager doesn't spew errors about unsupported Ingress versions when the old versions are enabled (which it did if you enabled those along with the old non-negotiated controllers), but coverage parity with the old unit tests in this area would be good if possible.
Unrelated changes in the same commit include:

A corrected KongClusterPlugin version (it was just wrong, and integration tests failed because the manager would disable the KCP controller after not seeing a v1beta1 version of that CRD).
A change to the Knative test, loading Knative CRDs along with ours before starting the controller in suite_test.go. We need to load the Knative CRDs then so that manager doesn't auto-disable the Knative controller and break tests, though it does break with what we had before. This somewhat awkwardly loads the Knative CRDs after the cluster starts up, but doesn't load the Knative core until the Knative tests (which is where it was originally, and remains). We could move the Knative core install earlier also--it doesn't fit into the crds name we have for that variable, but we could reasonably rename that to something like preloads. Any opinions on what we should do there?


Idea: Align Terminal keymappings with VS Code conventions

Description of the new feature/enhancement
Would be great if we could align Terminal keybinding settings with the VS Code keybinding conventions (link below).
Currently, the shortcut keys abbreviations do not match and this makes it more difficult to get started with keybindings - requiring users to try to do tons of digging to find the right convention - for example, to know page down is 'pgdn' (Terminal) instead of 'pagedown' (VS Code).
Would be fantastic if we could memorize and use a single convention rather than inventing a new one and trying to remember which convention works in which tool.

Proposed technical implementation details (optional)
The Terminal shortcut key abbreviations are documented here:
(Couldn't find any reference docs. Eventually found examples by holding Ctr while selecting "Settings" in order to get to the defaults.json file.)
The VS Code shortcut key abbreviations are documented here:
https://code.visualstudio.com/docs/getstarted/keybindings#_accepted-keys
For example of the problem currently, "Page Up" is "pgup" in Terminal profiles.json and "pageup" in VS Code.

Hey, I was having the exact same problem when trying to configure keybindings using page-up and page-down; I couldn't find any documentation with all the valid keys and had to dig around in the source code.
If you'd like, I could update the documentation to list all possible keys and submit a PR.
My suggestion is to grab the keys from KeyChordSerialization.cpp
And include them in the Profiles.json Documentation file under the keybindings section.
Even if that doesn't create parity with VS Code keybindings, it would be helpful for users creating keybindings.


gapi.auth.authorize doesn't work in windows mobile IE  browsers

on Executing below code for google sign in in my website,
doLoginFromGoogle : function(cbk)
    {
        var _this = this; this.skAuthCbk = cbk;
        var handleAuthResult_cbk = function(authResult)
        {
            _this.handleAuthResult(authResult, cbk);
        };
        gapi.auth.authorize({client_id: _this.clientId, scope: _this.scopes, immediate: false}, handleAuthResult_cbk);
        return false;
    },

Google account's login screen is shownafter signing in with valid credentials, it returns to my webpage but login is not happening. It remains same as before clicking the login button? Need Help...! It works fine in all other browsers, also in IE in desktop only in IE mobile it is not working.

Mobile IE is not currently a supported browser for this project. I don't currently have access to a device that runs it nor any way to automate testing for it.
That said, does login finish if you then reload the page? Are you doing an immediate: true auth check prior to the one displayed in the pop-up window?
Also, does the pop-up window have an "opener" property which is a working reference to the app page and allows traversal of the app page's frame hierarchy and same-origin script execution between the pop-up and a same-origin-with-the-popup IFRAME? That capability is currently required for the pop-up authorization flow to succeed. See https://github.com/google/google-api-javascript-client/issues/222 for a slightly more detailed description of the issues in the context of a different unsupported browser.

Answers to your questions:
No login is not finished on reloading the page.
Yes we are doing an immediate true auth check.
Actually its a mobile website to which we have integrated the google sign in process.
Also in that browser we have already have a signed in google account user. So on clicking the signup with google button, URL is getting redirected as expected to google api URL(a blank window with google login URL appears, keeps on loading on refreshing it returns to our site and nothing happens). I think we don't receive any response back to our call back function from google api.

Any idea whether pop-up windows have a working window.opener reference to the page that opened them? Also, are third-party cookies blocked? That will likely prevent sign-in from working.

No third party cookies are not blocked and pop-windows have a working.opener reference

@karthikeyan-vk gapi.auth.authorize has been deprecated, please migrate to gapi.auth2. Doc: https://developers.google.com/identity/sign-in/web/sign-in. However, we do not officially support windows mobile so there's no guarantee it will work.

Hi @karthikeyan-vk , have you been able to migrate to GSI v2? Are you still experiencing the issue there?

Hi,
Yes was able to migrate to GSI v2 without any issues. And we discontinued our support for windows IE browsers, So haven't tested out there. Thanks!

Thanks @karthikeyan-vk for the update! Glad the migration went well.


Fix for "Cave Revamp" update

Fix object locations for new update

Now uses ZoneManagement and ZoneData to get the selectors
Code probably needs polish, but as of now all the selectors work fine and should work fine without CI


Remove all Scala 2.8-related code in soql-reference

soql-reference #96 SUCCESS
This pull request looks good

soql-reference #97 SUCCESS
This pull request looks good

awesome, this was a little painful last week

soql-reference #103 FAILURE
Looks like there's a problem with this pull request

soql-reference #104 SUCCESS
This pull request looks good


writing Prometheus exporter

Describe the feature
Application monitoring is essential for every production software system. Prometheus is an open-source monitoring system which was created in 2012 by Soundcloud.
The Prometheus server collects metrics from your servers and other monitoring targets by pulling their metric endpoints over HTTP at a predefined time interval. For ephemeral and batch jobs, for which metrics can't be scraped periodically due to their short-lived nature, Prometheus offers a Pushgateway. This is an intermediate server that monitoring targets can push their metrics to before exiting.
Adding Prometheus to the project can help monitor the health of the cluster. By adding custom metrics monitoring of the training process can be easily done.

Hi @SMesForoush ! Thank you for your feature request!
We are thinking over your idea, and would you bother telling us something about your usage scenario? It helps a lot.

We have updated a lot. This issue was closed due to inactivity. Thanks.


⚠ Bofrost.es has degraded performance

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

HTTP code: 200
Response time: 1634 ms

Resolved: Bofrost.es performance has improved in 33fe674 after 14 minutes.


fix: support arrow characters as CSS Entities (multi platform support)

Arrow symbols do not load properly on all platforms (i.e. raspberry pi).  Converting to CSS Entities (reference: https://oinam.github.io/entities/) to allow multi-platform support

Thanks, I'll adopt it in a few hours.


update to python 3.7 + add tests

Before branching out in a different direction, I thought I'd push some basic changes that allow testing & containers to work "out of the box" without nasty error messages.
Feel free to merge or ignore as needed...

And yes, there is a docker build image available from https://hub.docker.com/r/mikespub/python-github-webhooks :-)

outdated


Time Ahead

Hi,
Is there any way to do the same in future ? like this library in java
Eg 3 hours from now, In 30 minutes, etc
Or may be it is there and i missed it ??

@girishnair12345 maybe this library is something for you: https://github.com/bitomule/RelativeFormatter

Its ok I wrote my own 👍

@girishnair12345 Can you share it?


$100 Bounty OpenCsg port proof of concept

The bounty is posted on bountysource, if there will be serious interest I will put money on bounty source.
https://opencsg.org/ library uses opengl do preview boolean operations using shaders and z-buffer instead of actually doing the boolean operations. It is used by OpenScad.
It is ok if it is not perfect, especially sinc the base for this, OpenCsg, is not a perfect solution

there can be artefacts during rendering for coplanar operations
it still is needed to do the actual booleans if you want to export results of boolean operationa as OBJ,STL, or some mesh.

WASM is not allowed in this bounty, but could be considered as a separate bounty if there will be real interest.
The idea of this bounty is to jumpstart a pure JS port of OpenScad, it is not required to complete the port, but to produce code that can display substraction of 2 spheres for example.
License MIT.
bountysource link https://app.bountysource.com/issues/114315115-100-bounty-opencsg-port-proof-of-concept

How would you imagine that this is implemented?
The way I see it, this would require a webgl implementation of image-based csg rendering algorithms, such as the goldfeather algorithm for concave objects, and scs for convex objects.
Would that count as a "pure" JS implementation, like you mentioned? Or do you envision something else?
I personally don't have any experience yet with webgl. However, while I was reading about it, I found this blog post. Might give someone some more ideas.

I would expect it would port code from OpenCSG. pure JS version means it does not need WASM to work :)
if there would be a WASM variant, I could add a different bounty, and this one would sty for pure JS version.

bounty goes to @Loosetooth  https://github.com/Loosetooth/scs-csg-subtraction-webgl


SaltStack file missidentified as Scheme

This .sls file is being treated as Scheme, rather than SaltStack. All the other files in the repo (eg this one) are correctly identified as SaltStack.

Sorry about the delay in responding to this.
It looks like we've got .sls associated with both SaltStack and Scheme but without a heuristic to differentiate things. As a result, the analysis is falling through to the naïve bayesian classifier and it's getting it wrong for this file, but only just. It's very close.
We'd certainly welcome a PR to add a heuristic and maybe another sample to help improve the detection in future.
In the mean time you can force the correct classification using an override


Add an index.md to /docs of "released work"

Add an "index.md" file so that people can view
https://best.openssf.org and see all the released work from the OpenSSF Best Practices Working Group.
The goal is to make this more discoverable.
We separately need to create a "landing page" for developers, one that would cover all OpenSSF work (at least).
That is a separate idea, I currently expect that to be developed in ./developer.md. But let's quickly get this "general list" added, so it'll be easy to find this info!

@SecurityCRob - as Best Practices WG lead, this okay? I think it's important to have a "basic list" of the WG available at the "published" website.

Yes, I agree with this approach.
Cheers,
CRob
Director of Security Communications
Intel Product Assurance and Security
From: David A. Wheeler @.>
Sent: Thursday, June 8, 2023 5:29 PM
To: ossf/wg-best-practices-os-developers @.>
Cc: Robinson, Christopher @.>; Mention @.>
Subject: Re: [ossf/wg-best-practices-os-developers] Add an index.md to /docs of "released work" (PR #171)
@SecurityCRobhttps://github.com/SecurityCRob - as Best Practices WG lead, this okay? I think it's important to have a "basic list" of the WG available at the "published" website.
—
Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-best-practices-os-developers/pull/171#issuecomment-1583365998, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQRFDLFPETWIKMI4E3HLZBDXKI7X5ANCNFSM6AAAAAAY72OO6E.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>


'tensorflow' has no attribute 'set_random_seed

Hello all, I am trying to run my code and I am getting this error: I tried to modify it based on this stackoverflow post (https://stackoverflow.com/questions/59622277/attributeerror-module-object-has-no-attribute-set-random-seed-when-i) but it is still not working. Does anyone have a fix for this?
AttributeError: module 'tensorflow' has no attribute 'set_random_seed(a.seed)'

Replace 'import tensorflow as tf' with 'import tensorflow.compat.v1 as tf' and add 'tf.disable_v2_behavior()' at the start of main()

Replace 'import tensorflow as tf' with 'import tensorflow.compat.v1 as tf' and add 'tf.disable_v2_behavior()' at the start of main()

I solved it. Thank you so much!


RHBPMS-1289: Project with persistable data objects added to persistence descriptor cannot be deployed

- Controll added in order to generate the missing identifier when required

@manstis
Hello Mike would you mind review this PR. It should included for tomorrows 6.3.1 patch.
Thanks!
Walter.

@wmedvede I couple of minor comments.. the only troublesome one is possibly the id generator.. have a think, and fix if you agree.. otherwise +1 to merge.

+1 to merge (when green)


Cannot Set Workspace Tabsize to 4 - Only happens with 4

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.60.0
OS Version: Windows 10 21H1

Steps to Reproduce:

Set User tab size to 3.
Set Workspace tab size to 3. View the .code-workspace. The setting appears.
Set Workspace tab size to 4. The UI displays the setting is changed, but the workspace .code-workspace file shows no setting in it anymore.
Since user tab size is 3, and there is no entry in the .code-workspace, 3 is used.

I am assuming this is because there is an assumption that 4 is the default size, so no entry is made if you put 4 in the UI.
If you manually add it, it works fine.

@sandy081 This might be a corner case of the logic where updating a setting to its default value does not write the default value to workspace settings.

I think this is done by the settings editor @roblourens ??

@sandy081 That is correct. If you edit the text directly it works fine


CI: Update self-hosted runners to use the new infrastructure

Description
As part of the transition to the new infrastructure, the workflow definitions must be updated with a new runs-on clause and any additional fixes necessary.

@rbarkerSL , is this complete?

Duplicate of #483


swift code

i am trying to  golang and gomobile to write mobile apps.
Does this actually generate your Swift code ? Can see any Swift :)
https://github.com/brutella/hc/blob/master/cmd/swift_decl.go

Yes, if you run the program using go run cmd/swift_decl.go you will see Swift code.

Thank you !! Will try it
On Wed, 31 May 2017, 09:06 Matthias<EMAIL_ADDRESS>wrote:

Yes, if you run the program using go run cmd/swift_decl.go you will see
Swift code.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/brutella/hc/issues/81#issuecomment-305103810, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ATuCwr3JqLzCdjqEzICspNR8nP7BGOrfks5r_RFngaJpZM4Nq9AH
.


[DO NOT MERGE] Add test_workflow_secondary_labeling_two_channels

This PR is just to show a failing test that encodes issue #640

This fails as expected, with this relevant part of the traceback:
        if len(set(shapes)) > 1:
            raise ValueError(
                "Shape mismatch:\n"
                f"{current_label_region.shape=}\n"
                f"{masking_label_region.shape=}\n"
                f"{image_array.shape=}"
            )

        # Compute background mask
        background_3D = masking_label_region != label_value
        if (masking_label_region == label_value).sum() == 0:
            raise ValueError(
                f"Label {label_value} is not present in the extracted ROI"
            )

        # Set image background to zero
        background_4D = np.expand_dims(background_3D, axis=0)
>       image_array[background_4D] = 0
E       IndexError: boolean index did not match indexed array along dimension 0; dimension is 2 but corresponding boolean dimension is 1

fractal_tasks_core/masked_loading.py:174: IndexError


[JENKINS-36299] add empty state view handling for Icon types

any op to add some tests quality to this? otherwise 🐝

@michaelneale I did add a storybook entry for this, tests are pretty skimpy for this module

🐝

other then my comment :bee:

:bee:


After Upgrading a Workspace Containing Multiple Projects to Angular 11, Karma Refuses to Run

🐞 bug report
Affected Package

 The issue is caused by package @angular/....
Is this a regression?

Yes, the previous version in which this bug was not present was: 10.0
Description
I recently upgraded a multi-project workspace from Angular 10 to 11. I ran into some issues, which were resolved using the solution provided by a member of the Angular CLI team here: https://github.com/angular/angular/issues/39953. However, even though I can now build my app and its projects, when I try to run the tests, I get the following error:
ERROR [karma-server]: Server start failed on port 9876: TypeError: Cannot use 'in' operator to search for 'reporter:coverage' in karma-spec-reporter
I'm not sure why this is occurring, as it does not appear any of the Karma packages were changed, and my Karma configuration files have not changed either. The tests will run if I disable code coverage reports, but I need those. I've also tried removing my codeCoverageExclusions, to no effect.
🔬 Minimal Reproduction

I apologize that I'm unable to share the code behind this, but the scenario is:

Workspace containing 2 library projects and a main app
Problematic upgrade as described in https://github.com/angular/angular/issues/39953
Running ng test or ng test --project=(project) fails with the error mentioned above
Running ng test with --code-coverage=false, or codeCoverage=false in angular.json works as expected, no error
I do not have this problem on a smaller, simpler app which just contains the main app in the workspace

🔥 Exception or Error

ERROR [karma-server]: Server start failed on port 9876: TypeError: Cannot use 'in' operator to search for 'reporter:coverage' in karma-spec-reporter

🌍  Your Environment
Angular Version:

Angular CLI: 11.0.3
Node: 12.14.1
OS: win32 x64

Angular: 11.0.3
... animations, cli, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.3
@angular-devkit/build-angular   0.1100.3
@angular-devkit/core            11.0.3
@angular-devkit/schematics      11.0.3
@angular/cdk                    8.2.3
@angular/http                   7.2.16
@schematics/angular             11.0.3
@schematics/update              0.1100.3
ng-packagr                      11.0.3
rxjs                            6.6.3
typescript                      4.0.5

Anything else relevant?
A zip file containing my angular.json, and the karma.conf.js for my main app (but this has not changed), is attached.
KarmaNoLikey.zip

Added zip file contain package.json and package-lock.json files.
package.zip

In your karma.conf.js
    plugins: [
      require('karma-jasmine'),
      require('karma-chrome-launcher'),
      require('karma-jasmine-html-reporter'),
      require('karma-coverage-istanbul-reporter'),
      require('@angular-devkit/build-angular/plugins/karma'),
      'karma-spec-reporter' // <-- use require
    ],

try to require('karma-spec-reporter').
This is an oversight on our end too, we always expect the plugins array to contain objects only.
https://github.com/angular/angular-cli/blob/d3afdcc1b3e40736dab3ca7ae81c462747eb0ac9/packages/angular_devkit/build_angular/src/webpack/plugins/karma.ts#L96-L97

According to the Karma docs, the plugins array can contain either a string, an object (inlined plugin), or a required NodeModule. Example from the docs:
plugins: [
  // Karma will require() these plugins
  'karma-jasmine',
  'karma-chrome-launcher'

  // inlined plugins
  {'framework:xyz': ['factory', factoryFn]},
  require('./plugin-required-from-config')
]

Thanks @kyliau ! Adding the require call did the trick. I had thought about trying that, but decided not to because it had worked without it previously, and still works without it in a smaller project which I've also upgraded to Angular 11. But adding that fixed the problem. Thanks again!


event doesn't work

v-on:click="plotlyEvent"
This is not working. Please advise!

I'm stuck in the same situation... the events are not working

Yes, those events aren't working at all...

The events are not working. any one any advises?

This is working fine for me after the latest update:
    <vue-plotly :data="data" :layout="layout" :options="options" @click="handler"/>

methods: {
    handler(event) {
      console.log('handled')
      console.log(event)
    }
}

Let me know if you still have problems.


add options in pi3.sh

It is useful to create installer options. To be able to have an easy configuration and not have to edit the script every time (and look for the specific lines)
Advantages: it would be easier for automation with other scripts
example:
Usage: ./pi3.sh [-arg]

-h <hostname> (or help?)
-m minimal
-f full
-t tft
-d doom (If it is possible to implement it someday)
-r <package> (if u need remove a tool, example metasploit)
-a <package> (if u like add a tool)
-w <version> (I can not think what letter to assign)
-v verbose (it is necessary?)

Just an idea that came to mind (I remember the builder of nethunter) I do not know if it is very practical in this case.

I like the idea.


#53258 breaks ckeditor__ckeditor5-upload on DT

Here is a small repro based on that package:
export default class FileReader implements Observable {
    set(option: Record<string, unknown>): void;
    set(name: string, value: unknown): void;
}
export interface Observable {
    set(...args: [option: Record<string, unknown>] | [name: string, value: unknown] | [name: string]): void;
}

I might be wrong but the second overload is already an error in TS 5.0; is that intentional?

Oh, nevermind; it's missing declare.

I think I may just revert my PR and try and go for fixing #53398 instead.


Fix race condition on TestConnectionAllowsConcurrentWrites

This PR fixes a race condition on TestConnectionAllowsConcurrentWrites.
Before this change, the select case here was a no-op and would always fall through to the default case; using a channel allows proper synchronization.
To validate the before/after behavior, one can use the following command from the repo root.
$ go test -run=TestConnectionAllowsConcurrentWrites ./... -count=10000 -shuffle=on -race

Fixes #280

@evan-bradley can you review as the author of the test?

Thank you @tpaschalis!


Roundup database

Dear Todd,
Sorry to spam you here. I couldn't get any email from you in google.
I’m interested to have the Roundup database to get access to the phylogenetic profiles; however, the provided website in your publication is not available:
http://roundup.hms.harvard.edu
I would appreciate it a lot if you could please share with me the Roundup database, I’m interested in A. th. ’s phylogenetic profiles.
Thanks a lot in advance.
Kind regards,
Nooshin
--
Dr. Nooshin Omranian,
Systems Biology and Mathematical Modeling Max-Planck-Institute of Molecular Plant Physiology Am Mühlenberg 1
14476 Potsdam, Germany
phone +49 (0)331 567-8548

Dear Nooshin,
Thanks for reaching out! I'm sorry to say that Roundup is a dead project
and no longer available online.
The code for the website and computation pipeline is available at
https://github.com/walllab/roundup. Theoretically, it could be run on your
local computer or computational cluster, though it would probably be a bit
of work to get it running.
The code for the underlying orthology algorithm is available in this
repository.
Here is a list of some other orthology projects that might have what you
want: https://questfororthologs.org/orthology_databases.
Please reach out if you have any questions. I'm happy to help.
Best regards,
Todd
--
Todd DeLuca
PhD Student, Complex Systems and Data Science
University of Vermont
<EMAIL_ADDRESS>On Thu, Feb 28, 2019 at 7:21 AM Nooshin Omranian<EMAIL_ADDRESS>wrote:

Dear Todd,
Sorry to spam you here. I couldn't get any email from you in google.
I’m interested to have the Roundup database to get access to the
phylogenetic profiles; however, the provided website in your publication is
not available:
http://roundup.hms.harvard.edu
I would appreciate it a lot if you could please share with me the Roundup
database, I’m interested in A. th. ’s phylogenetic profiles.
Thanks a lot in advance.
Kind regards,
Nooshin
--
Dr. Nooshin Omranian,
Systems Biology and Mathematical Modeling Max-Planck-Institute of
Molecular Plant Physiology Am Mühlenberg 1
14476 Potsdam, Germany
phone +49 (0)331 567-8548
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/todddeluca/reciprocal_smallest_distance/issues/5, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AANKqUOeg0vCP52uzyUdU6xSKHryHEMHks5vR8m7gaJpZM4bWsYc
.


Add auth

Implement authorization and user creation.
Libraries are different from many other systems in that accounts cannot be created by just anybody. A librarian (or admin) needs to create user accounts for the patrons. Likewise, an admin creates librarian accounts (or rather, elevates the permissions of a patron).
But then where do admins come from?
My best idea so far is to have some config (.env file?) with an initial admin password. Somewhere on the site (probably root route or login page) we do the following:

If no admin accounts exist (or perhaps no accounts at all? there's pros and cons to each), show message to the effect of "This server isn't configured properly. Please contact your library. If you are the operator of this server, please add a SETUP_PASSWORD entry to the config file."
If no admin accounts exist and the initial password is configured, create a new admin account.
If an admin account does exist and the initial password is configured, give a warning similar to the one above, saying to remove the file. This is for security reasons (we don't want a situation where an account is being auto-created accidentally).

Problem is, the vast majority of the time will be the happy path, so how do we avoid unnecessary requests? Can we run the database query only on server startup?
It would be nice if this could just be prompted on server startup. However, some setups might not allow interaction with the command line of the deployment machine.

Eh, we could simplify that workflow: just refuse to start if no admin exists (or one does but the .env token is defined). We still need something for creating an actual account with the token, but it removes the need for an expensive query more often than I'd like.

So here's an idea: we create a "one-time token" credential.[^1] This can be used for user creations in general, but also to bootstrap the initial admin account.
Then we can just generate a token on startup if there isn't an admin, and hopefully figure out a clean way to close down the server and politely refuse regular user traffic with some awkward error page.
[^1]: See #153: auth methods are very flexible and it should (hopefully) be easy to wire up a new method like this. It will need some special logic though to delete itself after use.


Bug in Contributers page

Describe the bug
In contributors page, the followers and following is not correct.

@addisonhardley as you already contributed in the project is it okay with you if I assign this issue to @pratik1424 so he can make the necessary changes.

@addisonhardley true, scraping data from each of the contributor's account is taking too much time and making the page unresponsive. @Chaitalishetty what should we do, we can just keep contributions and followers or go with @addisonhardley 's solution.

@pratik1424 you can keep only the number of contributions

@pratik1424 Thanks :D.
@Chaitalishetty, Could you assign this issue to me? I'll create a PR after that.


Shopify wishlist implementation

Wishlist implementation for the Shopify provider. You can Add, Remove products to your customer wishlist as well as their variants. Also Added the possibility to add a specific product variant to your wishlist if its not available for sale (due to no stock etc)...

changed shopify fetch and graphQL fetch types and also the fetcher functions to include useAdminApiFlag in order to seperate graphql storefront API operations from Admin API ones,

generated shopify admin api schema(documentation for code generation is outdated and not working as per readme instructions - yarn generate:shopify script not present),

changed RemoveItemHook of commerce/types/wishlist,

created shopify wishlist api routes (addItem, removeItem, getWishlist),

added shopify api operation getCustomerWishlist,

updated index files of api/operations, utils and api/wishlist,

created shopify wishlist types ,

created getCustomerId function as a util in shopify ,

added customerUpdate mutation (Admin API operation),  customer query (Admin API operation),

added getCustomerId query,

modified commerce wishlist endpoint to extract item variable from req/body,

added useAdminApi flag to commerce fetcherOptions,

updated wishlist api constants,

modified shopify fetcher,

added wishlist handlers to shopify provider ,

Polished frontend UI so that you can now correctly add product to wishlist if variant is not available for sale

modified .env.template files to correctly refer that you also need shopify admin access token

Corrections Commit includes the following changes:
### Commerce API

reverted commerce/api/endpoints/wishlist & commerce/types/wishlist  to source implementation to avoid problems with other providers and major breaking changes

### Shopify provider

Modified shopify/api/endpoints/wishlist/add-item property destructuring to be compatible with the types used,
remove-item also has the same destructuring method plus new filtering method that correctly filters the wishlist by productId AND variantID
Modified shopify/types/wishlist. RemoveItemHook type now correctly extends the core type from commerce/types/wishlist  by adding an optional property itemVariantId, modified WishlistSchema type to be compatible with the new functions used in wishlist/endpoints (add-item, remove-item etc) by adding variables type property for the body.
minor changes to use-add-item specifically in the way properties are being handed to the fetcher.
use-remove-item hook now complies with the new types declared passing through itemId and itemVariantId
modified env.template and const files to "hide" admin access token variable.

Site Components

Modified WishlistButton removeItem function to be compatible across all providers
Modified WishlistCard removeItem function (same as above) and also added variant options labels for each product in your wishlist. This all summarizes my goal from the begining being a user should be able to add more variants of the same product in his wishlist and not just the main product. One, can desire both the blue and the red version of that T-Shirt that is currently out of stock in those colors.
Wishlist page midifications are mainly reverts to previous changes I have made. Now wishlist page should be the same as origin.

Thank you for your contribution. It looks awesome and is a lot of work. Please see my comments and requests for changes.
Additional notes:

we use yarn for this project, please remove package-lock.json
the main "local" build is failing

package lock removed.
local build was failing to me because it could not resolve the wishlist hooks from the "local" framework. wishlist folder of local package didn't have an index file with default exports. Should I add it and commit? adding the file to me, solves the problem.

now the main "local" build succeeds.

@chemmanouilidis thanks for this PR. Is there any progress here, did you ever use this in production?

@chemmanouilidis thanks for this PR. Is there any progress here, did you ever use this in production?

I don't think any further progress is required. I currently use it in production and it seems stable.

Hey there! Thank you for your contribution. We have decided to take Next.js Commerce in a new direction and will be closing out current PRs and issues due to this change. Please see this PR for more details: https://github.com/vercel/commerce/pull/966


Anoying popping on components/views with dynamic content (fetching) (spinner-> content).

Might move fetching to suspense and add some placeholders.

Needs investagtion on which views it occurs.


Custom Rotate Image

I would like to rotate the image slightly, through a custom angle (not just 90 degrees clockwise or counterclockwise). This is similar to #204 but without the need to use gestures, as I would put in a slider to change the angle.
How do I do this? I have tried EditActionDetails.rotate(...) but it does not give me the desired results as I don't have access to the private _layoutRect in that class.
Any pointers would be appreciated!

not support now

please update to lastest version


Write introductory page for documentation

The documentation has a lot of information on the methods in the Toolkit pages, but a short walkthrough based on an end to end analysis would be helpful.

This has been added with a tutorial on #116 along with other documentation improvements. Closing.


Welcome splash dialog does not work with short browsers

The welcome splash dialog isn't responsive and starts to exceed the browser height at around 575px.

We should probably just not display the dialog at all on browsers that short.

Fixed to be responsive.


Authorization Label link to input

Feature request: In the Authorization tab, right now you can't click on the label "GET", "POST" etc. You have to specifically hit the checkbox. Inputs should be wrapped in labels with the "for" property set.

Fixed with zfcampus/zf-apigility-admin-ui#38 and will release with 1.1.4.


docs: update repo name in dev environment setup instructions

- What I did
Update the repo name in the development environment setup instructions in CONTRIBUTING.md. It seems like the repo name changed from atsign.dev-3.0 to docs.atsign.com at some point, so the instructions were a bit surprising.
- How I did it
In the development environment setup instructions in CONTRIBUTING.md, replaced the string atsign.dev-3.0 with docs.atsign.com. I used the modified commands to set up this repo locally and they worked.
- How to verify it
Clone the repo and use the new commands to set it up locally.
- Description for the changelog
Update repo name in dev environment setup instructions in CONTRIBUTING.md

@drecali
Hey! Thank you for your Hacktoberfest contribution. You could be eligible for a prize.
To be eligible, please send an email to<EMAIL_ADDRESS>with a screenshot of the PR approval email (or just forward the PR approval email to us). This is to prove that your email corresponds to the correct GitHub account. Thank you!
When it comes time to distribute the prizes, we will look at all the emails we've received from that email so don't forget to do this!


a case in which infer fails to exploit the freshness of newly allocated objects

For the code
class Repro {
  void bad(Object x, Object y) {
    while (x == y);
  }

  void f(Object x) {
    Object y = new Object();
    bad(x, y);
  }

  void g() {
    Object x = new Object();
    f(x);
  }

  void h() {
    Object x = new Object();
    Object y = new Object();
    bad(x, y);
  }
}

running infer (version 6740689) with infer -g -- javac Repro.java, I get

The function bad gets the expected spec (x!=y). The function h also gets the expected spec (fine to call).
However, the function f does not get any spec, because Infer somehow fails to exploit the fact that the newly allocated object y is fresh.

The problem (with finding specs for f) seems to be that Infer abduces x != y but can't convince itself this is true. It should be true because either x==null or x|->{}. One can guide Infer towards this as follows:
  void f(Object x) {
    if (x == null) {
      Object y = new Object();
      bad(x, y);
    } else {
      x.hashCode();
      Object y = new Object();
      bad(x, y);
    }
  }


Generalize URL for downloading test data

This PR make the DEFAULT_URL, which is currently
DEFAULT_URL = "http://cccta-dataserver.in2p3.fr/data/ctapipe-extra/v0.3.3/"
really the default URL (and not the only choice like it is now) by adding url=DEFAULT_URL as a keyword default argument were necessary.
This PR should be complementary to #1638 .

Can you explain the use case for this that can't be solved using $CTAPIPE_SVC_PATH?

Can you explain the use case for this? It's fine to add, but I'm not sure we want people changing this ever.

It's not a change, it's an additional option.
My main drive for this PR was that to set up and execute the integration tests of protopipe (see cta-observatory/protopipe#70) I need to access http://cccta-dataserver.in2p3.fr/data/protopipe/[ecc...]
and I didn't want to re-invent the wheel (even though this means that I won't be able to test this until the next release anyway without some ugly copy&paste)


Move to preconfigured Resin-SDK

I approved, though I think you need to rebuild the CoffeeScript.

Ah, thanks. Now fixed, I'll merge once the build passes.

So I've seen a load of these PRs pop up, and it seems that this special version of the SDK is being used everywhere? Is there ever a case when we would use the "standard" SDK? In general does it make more sense to have the "standard" SDK match the standard usage instead of the more uncommon usage, or at least have it default to the standard usage (in order to make the common case easier for everyone)?

The SDK itself is a factory. This version is an instantiated version of the
factory, with all the params passed in.
The other use-case is the browser (UI / dashboard) where we (will)
initialize it a bit differently (specifically by first querying the API and
then passing the obtained params to the SDK).
There are plans to eventually encapsulate those params in the same
-preconfigured module, too, but for now it's just a thin wrapper for
Node-only projects.
On Tue, Jan 17, 2017 at 12:36 AM, Page-<EMAIL_ADDRESS>wrote:

So I've seen a load of these PRs pop up, and it seems that this special
version of the SDK is being used everywhere? Is there ever a case when we
would use the "standard" SDK? In general does it make more sense to have
the "standard" SDK match the standard usage instead of the more uncommon
usage, or at least have it default to the standard usage (in order to make
the common case easier for everyone)?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/resin-io/resin-cli-events/pull/9#issuecomment-272967474,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAgGCMT6M6ZyI32_LIyFoWyk9CnfAlbkks5rS-LIgaJpZM4LjCa9
.

--
Eugene Mirotin
Senior Frontend Engineer
site: Resin.io https://resin.io/, twitter: @resin_io
https://twitter.com/resin_io


Port Z-Algorithm

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

Original

ac-library/string.hpp at z_algorithm

Codecov Report

Merging #8 (4b9cff8) into master (d06a4a3) will increase coverage by 0.21%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
+ Coverage   85.90%   86.12%   +0.21%
==========================================
  Files          13       14       +1
  Lines         830      843      +13
==========================================
+ Hits          713      726      +13
  Misses        117      117

Impacted Files
Coverage Δ

src/string.cr
100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


add tree view option

This case looks good:
➜ ./plasmactl dependencies interaction/services/roles/mail_postfix
- Parent dependencies:
interaction/applications/roles/mail
- Child dependencies:
interaction/softwares/roles/postfix
interaction/softwares/roles/postfix_ldap
platform/softwares/roles/alpine

➜ ./plasmactl dependencies interaction/services/roles/mail_postfix --tree
- Parent dependencies:
interaction__services__mail_postfix
└── interaction/applications/roles/mail
- Child dependencies:
interaction__services__mail_postfix
└── interaction/softwares/roles/postfix_ldap
    └── interaction/softwares/roles/postfix
        └── platform/softwares/roles/alpine

But this case is listing itself only as parent dependency :
➜ ./plasmactl dependencies platform/libraries/roles/executor --tree
- Parent dependencies:
platform__libraries__executor
- Child dependencies:
platform__libraries__executor
├── integration/libraries/roles/errors
├── integration/libraries/roles/loopback
│   ├── integration/libraries/roles/metrics
│   │   ├── platform/libraries/roles/configuration
│   │   │   └── platform/libraries/roles/log
│   │   └── platform/libraries/roles/log
│   ├── platform/libraries/roles/event
│   │   ├── integration/libraries/roles/errors
│   │   └── platform/libraries/roles/log
...

whereas it does not appear without --tree option:
➜  build git:(master) ./plasmactl dependencies platform/libraries/roles/executor
- Child dependencies:
integration/libraries/roles/changelog
integration/libraries/roles/criteria
integration/libraries/roles/errors
integration/libraries/roles/loopback
integration/libraries/roles/metrics
integration/libraries/roles/revision
integration/libraries/roles/utils
platform/libraries/roles/configuration
platform/libraries/roles/event
platform/libraries/roles/flow
platform/libraries/roles/function
platform/libraries/roles/log
platform/libraries/roles/skill
platform/libraries/roles/transport


Type 'BottomNavigationProps' is not assignable to type 'HTMLAttributes'.

Expected Behavior
I would expect the npm start command to compile and load the site successfully
Steps to Reproduce
I decided to move from v1.0.0-beta.40 to v1.5.1 this evening and now I am failing to compile my site.
I have spent a few hours trying to resolve this but have not been successful and am now out of ideas.
The error I am seeing is:
<EMAIL_ADDRESS>(4,18): Interface 'BottomNavigationProps' incorrectly extends interface 'HTMLAttributes<HTMLDivElement> & StyledComponentProps<"root"> & { className?: string | undefined;...'.
  Type 'BottomNavigationProps' is not assignable to type 'HTMLAttributes<HTMLDivElement>'.
    Types of property 'onChange' are incompatible.
      Type '((event: ChangeEvent<{}>, value: any) => void) | undefined' is not assignable to type '((event: FormEvent<HTMLDivElement>) => void) | undefined'.
        Type '(event: ChangeEvent<{}>, value: any) => void' is not assignable to type '((event: FormEvent<HTMLDivElement>) => void) | undefined'.
          Type '(event: ChangeEvent<{}>, value: any) => void' is not assignable to type '(event: FormEvent<HTMLDivElement>) => void'.

Your Environment
I am using the react-starter-app ts.
I have inclued my full package file to see if there is something obvious.
I updated my global typescript to v3.0.1
{
  "name": "boom-web-app",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "@material-ui/core": "^1.5.1",
    "@material-ui/icons": "^2.0.3",
    "animate.css": "^3.7.0",
    "autosuggest-highlight": "^3.1.1",
    "axios": "^0.17.1",
    "bootstrap": "^3.3.7",
    "font-awesome": "^4.7.0",
    "jquery": "^3.3.1",
    "jquery-slimscroll": "^1.3.8",
    "node-sass-chokidar": "0.0.3",
    "npm-run-all": "^4.1.3",
    "prop-types": "^15.6.2",
    "pubnub-react": "^1.2.0",
    "qs": "^6.5.2",
    "react": "^15.6.1",
    "react-app-rewire-provide-plugin": "^1.0.0",
    "react-app-rewired": "^1.5.2",
    "react-autosuggest": "^9.4.0",
    "react-block-ui": "^1.1.2",
    "react-custom-scrollbars": "^4.2.1",
    "react-dom": "^15.6.1",
    "react-drag-sortable": "^1.0.6",
    "react-dropzone": "^4.3.0",
    "react-google-maps": "^9.4.5",
    "react-redux": "^3.1.0",
    "react-redux-toastr": "^7.4.0",
    "react-router": "^4.3.1",
    "react-router-bootstrap": "^0.24.2",
    "react-router-dom": "^4.3.1",
    "react-scripts-ts": "2.12.0",
    "react-scrollbar": "^0.5.4",
    "react-sortable-hoc": "^0.6.8",
    "react-spinkit": "^3.0.0",
    "react-stars": "^2.2.5",
    "react-swipeable-views": "^0.12.16",
    "react-typist": "^2.0.2",
    "react-virtualized": "^9.20.1",
    "reactstrap": "^5.0.0",
    "recharts": "^1.1.0",
    "redux": "^3.0.2",
    "redux-logger": "^3.0.6",
    "redux-thunk": "^2.3.0",
    "sweetalert-react": "^0.4.11",
    "typesafe-actions": "^1.1.3",
    "uuid": "^3.3.2"
  },
  "scripts": {
    "build-css": "node-sass-chokidar src/content/scss/main.scss -o src/content/css",
    "watch-css": "npm run build-css && node-sass-chokidar src/content/scss/main.scss -o src/content/css --watch --recursive",
    "start-js": "react-app-rewired start --scripts-version react-scripts-ts",
    "start": "npm-run-all -p watch-css start-js",
    "build-js": "react-app-rewired build --scripts-version react-scripts-ts",
    "build": "npm-run-all build-css build-js",
    "test": "react-scripts-ts test --env=jsdom",
    "unit": "set CI=true&&react-scripts-ts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "devDependencies": {
    "@types/jest": "^22.2.3",
    "@types/node": "^9.6.28",
    "@types/react": "^16.4.11",
    "@types/react-dom": "^16.0.7",
    "@types/react-redux": "^5.0.21"
  },
  "proxy": "http://localhost"
}

Ypur help is greatly appreciated and thanks for the superior library.

Please provide a full reproduction test case. This would help a lot 👷 .


updated copyright year

updated copyright and license year

It's usual practice to add the additional copyright year as the old copyright is still valid. Could you add a new line for 2018 but keeping the 2016 original copyright please?

It's usual practice to add the additional copyright year as the old copyright is still valid. Could you add a new line for 2018 but keeping the 2016 original copyright please?

Tried fixing it this way: https://github.com/Microsoft/malmo/pull/763

Now rolled up into prep37. Thanks,