simplify auth mechanism; refactor and clean up code a bit

Description

refactor/unify/clean-up code after migration
decrease gocyclo limit
fix mistakes in pr_check made during copy pasting
remove dead code, remove duplicate import

Fixes # (issue)
Type of change
Please delete options that are not relevant.

Refactor (refactoring code, removing useless files)

Testing steps
stage and prod tokens
Checklist

[x] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report
Base: 60.07% // Head: 60.08% // Increases project coverage by +0.00% :tada:

Coverage data is based on head (e0cb678) compared to base (e61597c).
Patch coverage: 36.84% of modified lines in pull request are covered.

:exclamation: Current head e0cb678 differs from pull request most recent head bb56d0a. Consider uploading reports for the commit bb56d0a to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #928   +/-   ##
=======================================
  Coverage   60.07%   60.08%
=======================================
  Files          22       22
  Lines        3191     3164   -27
=======================================
- Hits         1917     1901   -16
+ Misses       1054     1048    -6
+ Partials      220      215    -5

Impacted Files
Coverage Δ

server/acks_handlers.go
4.90% <0.00%> (-0.16%)
:arrow_down:

server/acks_utils.go
23.27% <0.00%> (-0.54%)
:arrow_down:

server/auth.go
65.00% <50.00%> (+6.02%)
:arrow_up:

server/handlers_v2.go
63.56% <50.00%> (-0.32%)
:arrow_down:

server/rating.go
48.71% <50.00%> (-0.64%)
:arrow_down:

server/router_utils.go
70.58% <50.00%> (-1.06%)
:arrow_down:

server/server.go
58.59% <55.55%> (+<0.01%)
:arrow_up:

server/handlers_v1.go
59.48% <66.66%> (-0.26%)
:arrow_down:

content/content.go
76.95% <0.00%> (-0.83%)
:arrow_down:

... and 1 more

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Consider "automated" PRs for upstreaming data to projects

We likely don't want this to be fully automated as in use of a bot or something, but once we have had discussions with a project about the curated data we have and they have agreed they want that data upstreamed to them, we may want to consider having "standard" PRs that we use for upstreaming that data back to the project.
These contributions upstream will likely grow over time and can't scale if they are completely manual every time. We should explore options to see how we can make some of them templatized or otherwise "automated" while still maintaining the personal, respectful, tasteful approach we want to emphasize in our interactions with these communities.

Closing for now, I'll reopen if we want to explore this later.


golang based PGP

THis is not a bug but a architecture suggestion
ProtonMail has an open pgp lib:
https://github.com/ProtonMail/gopenpgp
It works well and also works on gomobile.
SO i was thinking that we could use this for Desktop and Mobile, so that its possible to make gopass GUI's easily.
There is also a CLI  here:
https://github.com/ProtonMail/gosop
This CLI implements this proposed standard for PGP:
https://tools.ietf.org/html/draft-dkg-openpgp-stateless-cli-01

Thanks for recommending a native OpenPGP library @gedw99.
Just so you are aware of it, there is a discussion ongoing in https://github.com/gopasspw/gopass/issues/1365 to remove GPG support from gopass.
What are the core features from OpenPGP that you would like to see in gopass?
Feel free to provide your feedback in the linked issue.

Thanks for the suggestion. It's actually an interesting project and I did look at this before.
However back then it had at least one show stopper. Either depending on shelling out to the gpg CLI or not working with recent gnupg releases (agent support?). I don't remember exactly, but if these were resolved this might be a very viable option in case we want to keep supporting GPG.
However as @Pharb mentioned we're discussing eventually removing GPG support - the data model is just too overwhelming for average users.

I just read the Issue. I think your right. Quality over quantity.
People can always pipeline into other systems is needed.
PGP  - I can live without PGP.
Git as the store is pretty damn useful.

THat guy that suggested using the golang git pakcage is right imho. Make it trival.

About the GUI....
I think it would be very easy to make a mobile app in flutter that creats git PR's back to your git repo store.
Take for instance this:https://github.com/git-touch/git-touch

talks to all git repos

https://github.com/authpass/authpass

this uses keypass

For my use cases i would appreciate following:

PGP is quite handy as I use it for other things like ssh authentication and email encryption, but I could live without support
Git is very handy, as I have my own git server or could just use ssh to synchronize my secrets over many devices
And now to the big fish: Mobile Support - specifically Android. I really like the simple concepts of gopass and would like to replace my bitwarden with it. At the moment the passwordstore app and my git server will do, but with these proposals it would be impossible to do that

Notice we do no plan anymore to remove GPG now.
To me the biggest blocker here to migrate to a fully Go based GPG lib would be the support for hardware tokens.
Is anyone aware of a lib supporting hardware PGP tokens? Or of a way to get openpgp to work with hardware tokens ?

Notice we do no plan anymore to remove GPG now.
To me the biggest blocker here to migrate to a fully Go based GPG lib would be the support for hardware tokens.
Is anyone aware of a lib supporting hardware PGP tokens? Or of a way to get openpgp to work with hardware tokens ?

I don't think this is feasible at the moment. There are just too many ways people extend or customize GnuPG.
We will likely keep supporting the gpg CLI for the foressable future.
But for anyone who doesn't want that we do offer proper support for age since a while.


Programming Principles

Nice overview. I saw The Principles of Good Programming. Based on this, I once did Programming Principles (or http://webpro.github.io/programming-principles/). It isn't original, but people may find it a bit easier to scan, there is more structure and other resources. Up to you: ignore/replace/add. Anything goes!

Hey !
You can make a PR if you think some changes need to be made;

ok


(#320) Fix ''Build of whole project is broken."

Lines covered ratio increased to 0.67.

Fixes #320
DyNumTest.java and PagesTest.java added to increase lines covered ratio

@paulodamaso this PR contains commits from the fix of #268 because there was a test which also increased lines covered ratio.

Job #321 is now in scope, role is REV

Codecov Report

Merging #321 into master will increase coverage by 0.85%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master     #321      +/-   ##
============================================
+ Coverage     75.58%   76.44%   +0.85%
- Complexity      184      192       +8
============================================
  Files            34       34
  Lines          1102     1108       +6
  Branches         88       88
============================================
+ Hits            833      847      +14
+ Misses          238      231       -7
+ Partials         31       30       -1

Impacted Files
Coverage Δ
Complexity Δ

src/main/java/org/jpeek/Main.java
80.48% <100%> (+11.91%)
9 <4> (+5)
:arrow_up:

src/main/java/org/jpeek/web/DyNum.java
100% <0%> (+10%)
11% <0%> (+2%)
:arrow_up:

src/main/java/org/jpeek/web/Pages.java
100% <0%> (+50%)
2% <0%> (+1%)
:arrow_up:

Continue to review full report at Codecov.

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

Job gh:yegor256/jpeek#321 already assigned to @ilyakharlamov, can't assign to @ilyakharlamov

This pull request #321 is assigned to @ilyakharlamov/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @paulodamaso/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be no monetary reward for this job

@humb1t

In DyNumTest, replace the lambdas with method references, remove all the unboxings number.floatValue, number.longValue, number.intValue etc
after that you will no longer need single-use variables like final Double number and final DyNum dynum you can inline that into, for example testUpdateDyNum() {      new Assertion<>(          "Result should not be null",          new DyNum(2.0d)::update,          new IsNot<>(              new IsNull<>()          )      ).affirm();  }

@humb1t fix We are close, just four DyNumTest changes + PagesTest

@humb1t
fix the broken test, change PagesTest and rebase into a single nice looking commit and we are good to go

@rultor help

@rultor help

@humb1t Thanks for your request. @paulodamaso Please confirm this.

I will try to retrigger the build by amending the commit.

@ilyakharlamov please check one more time :-)

@humb1t rebase all the changes into a single commit and we are good to go

@ilyakharlamov I made a todo about tests without assertions and squashed commits into one.

@paulodamaso the PR is OK, the only thing I am not sure of is PagesTest.

@paulodamaso please check this PR, there are some issues blocked by it.

@ilyakharlamov/z this job was assigned to you 5days ago. It will be taken away from you soon, unless you close it, see §8. Read this and this, please.

@paulodamaso please check this PR, there are some issues blocked by it.

@paulodamaso the time has come :-)

https://github.com/llorllale/cactoos-matchers/issues/122

@ilyakharlamov Do we have some resolution on this one?

@paulodamaso Didn't get that. Which one?

@ilyakharlamov Sorry, wrong recipient :D

@humb1t Any resolution on this one?

@paulodamaso no, will fix it tomorrow

@paulodamaso/z everybody who has role REV is banned at #321; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)

@paulodamaso/z everybody who has role REV is banned at #321; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)

@paulodamaso/z everybody who has role REV is banned at #321; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)

@humb1t Ping

@paulodamaso - hi, I missed the notification. Will fix it.

@paulodamaso/z everybody who has role REV is banned at #321; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)

This pull request #321 is assigned to @nermeen78/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @paulodamaso/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be no monetary reward for this job

@nermeen78/z this job was assigned to you 5days ago. It will be taken away from you soon, unless you close it, see §8. Read this and this, please.

@paulodamaso/z everybody who has role REV is banned at #321; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)

@rultor merge

@rultor merge

@paulodamaso OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@paulodamaso Done! FYI, the full log is here (took me 21min)

Job gh:yegor256/jpeek#321 is not assigned, can't get performer

The job #321 is now out of scope

Payment to ARC for a closed pull request, as in §28: +10 point(s) just awarded to @paulodamaso/z


Update title for "View on GITHUB"

The node and Link views have a link to the appropriate github location.  This is very handy, but the casual observer might not understand that this is direct access to the raw data.  So instead lets say
"Table Data Access (GitHub)"
unless there's a better name for that. Still keep the octocat though :)

The 'action' buttons are all icons now.


feature: allow definining env variables to be set on each lambda

The goal of this feature is to ease the continuous deployment process by allowing the secret values to be set as environment variables per lambda. This will allow the component's users to not have to rely on building the env variables (stored in .env files) into the app bundle which may encourage storing API secrets in repos.
Example:
Secret keys are set to environment variables TOP_SECRET_KEY1 and TOP_SECRET_KEY2 respectively.
serverless.yml
myComponent:
  component<EMAIL_ADDRESS>  env:
    defaultLambda: {
      MY_SECRET: ${env.TOP_SECRET_KEY1}
    }
    apiLambda: {
      API_SECRET: ${env.TOP_SECRET_KEY2}
    }

The MY_SECRET and API_SECRET env vars will now be set per lambda and will not need to exist in an .env file.
The implementation should handle the env: {...} case to set for both lambdas.
Should be a copy/paste implementation of the existing description/memory/name inputs.
@danielcondemarin Sounds good?

As I look into it further, I believe build.env was used to provide this functionality in the past. Do envs get built into your bundle if you provide them in the next.config.js? This is not the recommended way to handle things anymore according the docs.

@lone-cloud Unfortunately Lambda@Edge does not support environment variables. This will probably change in future as AWS should add support for it at some point.

As I look into it further, I believe build.env was used to provide this functionality in the past. Do envs get built into your bundle if you provide them in the next.config.js? I don't believe this is the way to define env vars in the latest versions of Next.js and it's no longer listed in the docs.

That's exactly the case. That's why we added support for build-time Next.js env. configuration using build.env.
There may be some work to be done to better support the next 9.4 env release using dotenv but not sure what that would look like right now.

Very interesting. I did not realize that was a limitation.
I think the best course of action now is to have more documentation in the README to outline the next.config.js requirement as it is no longer standard. Next 9.4 revamped the way that env variables (https://nextjs.org/blog/next-9-4#new-environment-variables-support) should be provided and this was a big source of confusion for me when integrating with this component.


Provide a method to split inline elements at line breaks

@tsiegleauq Could you confirm this is what we talked about?
(Wrapping each line in an own element is probably more complex... msg me if needed)

What are the exact calls you make to get that result? When I call
const inHtml = '
One Two Three Four Five Six Seven Eight Nine Ten One Two Three Four Five Six Seven Eight Nine Ten
';
const numbered = service.insertLineNumbers(inHtml, 20);
const stripped = service.splitInlineElementsAtLineBreaks(numbered);

, the result is:

    One Two Three Four

    Five Six Seven Eight

    Nine Ten One Two

    Three Four Five Six

    Seven Eight Nine Ten

Looks better. I get the motion-html-text the same way the detail view is getting it. What am I supposed to use?
motionRepo.formatMotion(motion.id, crMode, changes, lineLength);

It's the createText-method in motion-pdf-service.ts, right? I think, just an additional
motionText = this.linenumberingService.splitInlineElementsAtLineBreaks(motionText);

should suffice (after importing the LinenumberingService, of cause)


Backpressure is not probagated to StreamEmitter

I am not sure if this is a bug, so I was very unsure if I should post it here or on Stackoverflow. I decided to do it here.
Example application: https://github.com/Skatteetaten/scs-bakcpressure-example
I have a made up scenario

A StreamEmitter emits persons once every 100 ms.
A StreamListener can process 5 entries every second.

What I am seeing is that the StreamEmitter is emiting entries even though the Listener has not signaled request.
Am I starting this in the wrong order so that the StreamEmitter gets unbounded request and will never stop?
Part of log from a run:
08:18:26.774 [artedMain] INFO  n.s.a.r.BackpressureApplication:48 - Starting BackpressureApplication on ubuntu1604-0159 with PID 3429 (/home/m89870/dev/openshift-reference-springboot-eventdriven/target/classes started by m89870 in /home/m89870/dev/openshift-reference-springboot-eventdriven)  08:18:26.775 [artedMain] DEBUG n.s.a.r.BackpressureApplication:51 - Running with Spring Boot v1.5.6.RELEASE, Spring v4.3.10.RELEASE  08:18:26.778 [artedMain] INFO  n.s.a.r.BackpressureApplication:597 - The following profiles are active: local  08:18:29.326 [artedMain] INFO  dnum1             :147 - onSubscribe(FluxPublish.PublishInner)  08:18:29.333 [artedMain] INFO  dnum2             :147 - onSubscribe(FluxFlatMap.FlatMapMain)  08:18:29.334 [artedMain] INFO  dnum2             :147 - request(unbounded)  08:18:29.334 [artedMain] INFO  dnum1             :147 - request(1280)  08:18:30.332 [arallel-1] INFO  dnum1             :147 - request(5)  08:18:31.042 [artedMain] INFO  n.s.a.r.BackpressureApplication:597 - The following profiles are active: local  08:18:31.142 [artedMain] INFO  n.s.a.r.BackpressureApplication:57 - Started BackpressureApplication in 0.16 seconds (JVM running for 5.551)  08:18:31.332 [arallel-1] INFO  dnum1             :147 - request(5)  08:18:31.772 [artedMain] INFO  name              :147 - onSubscribe(FluxMap.MapSubscriber)  08:18:31.772 [artedMain] INFO  name              :147 - request(unbounded)
The last line here says that the "name" category gets unbounded requests. This is not what i Intend. Also I see that dnum1 requests 1280 entries first and then 5? These are added together or does 5 replace 1280?

Hi @bjartek ,
Based on what I see your example,  the reason you get request(unbounded) under name categatory is because the StreamEmitter's actual subscriber is Spring Cloud Stream's internal PublisherToMessageChannelResultAdapter's adapt method which takes care of sending the Flux out to the message channel. This method has a LambdaSubscriber on the same thread the Publisher is publishing and hence unbounded request (synchronous)
The StreamListener isn't directly subscribed to the StreamEmitter. Instead, it is bound to the message channel (in your case @Input("dnumIn")) and uses Spring Cloud Stream internal MessageChannelToInputFluxParameterAdapter's adapt method to convert the inbound message channel message into Flux.

Also I see that dnum1 requests 1280 entries first and then 5?

That's because of the way  FluxWindowTimeOrSize works at the first time request. Here, the prefetch value is set to default 256 and the batchsize is 5.

Thanks for a nice explanation. So is it possible to get backpressure working in the way I intend. That is i have one application publishing something to a topic that I want to slow down if nothing is consuming them.

@bjartek Not at the right now, we would need two important features to enable that:

The binder implementation would need to support backpressure. Most binders right now do not have that native support
Internally SCSt would need to adapt to those reactive binders and expose the configurations as explained by @ilayaperumalg

A challenge here, is that the nature of MOM is that there's a third entity between producers/consumers. Backpressure is usually well defined when it comes RPC calls between direct consumer/producers. That's why the binder and the upstream middleware would need to support this feature in order for us to enable it.
One thing you may try to do, is slow down your producer via some logic that checks the kafka offset and see if the consumer group you are targeting (you could have more than one) are pulling messages at the same rate that you expect to produce.


docs: add new read-only states pattern

Closes #3248
Add a new pattern for read-only states with written guidance and images.
Changelog
New

Content
Images

Looks great! Do we want to index this for Platform?

@aagonzales Okay, all feedback has been added! Thank you.
— I update the read-only state colors with the latest spec for all images.
— I updated the do/don't image with a new UI.
— I also added the fluid variant in images when I am using the tab component for comparisons between the read-only/enabled states since they have some differences. Let me know what you think about that.

— Added a notification for fluid components.


CS crash when inject

Hello, every time I inject osiris using csghost it always crash and show this message when I press debug. I need help. Thank you.

Are u sure its osiris fault?

release not debug

build as release profile, not debug

I built osiris in release and did everything but when inject with csghost, csgo crashed and I press debug then that error window opens up not that I built osiris in debug mode. Need help

you may be injecting too early. ive had this problem with some injectors, wait for csgo to fully start up and get you onto the loading screen before injecting.


Add menu for single-page importers

[x] Add a "Syncing..." notification
[x] Clean up UI for syncing, remove the drop down menu and just have a small element (a-la Omnivore) that indicates syncing has begun & that we're redirecting.
[x] Redirect to the page Raindrop page by default when syncing begins.

TODO:

Remove the unused component that has errors

Screenies

Current dependencies on/for this PR:

main

PR #50

PR #60

PR #61   👈

This comment was auto-generated by Graphite.

@phildenhoff started a stack merge that includes this pull request via Graphite.

Graphite couldn't merge this pull request because a downstack PR #60 failed to merge.


Fixed bug in marginal grouping

@shakiba-shb some of the flex changes have gotten mixed in here, i'm assuming they will not break anything?

They should not be breaking anything.


Ranking IK Solutions

This PR introduces ranker for IK solutions.
Looking for discussion on:

Should we make it more general to also be able to rank TSRs with the same (templated) classes?
I prefer having them separate to make it simple and free of potential errors.

Decided to keep them separate

Where do we have the files? It seemed constraint/dart/ might be a good place since it's still a constraint over the IKs which by itself is a constraint. Can also be under planner.

Decided to have them under distance

Naming convention for the classes.
Efficiency and implementation details.

~WIP: Tests. I started a test for FIFO (which is more or less a random IK ranker like in prpy).~

Before creating a pull request

[x] Document new methods and classes
[x] Format code with make format

Before merging a pull request

[x] Set version target by selecting a milestone on the right side
[x] Summarize this change in CHANGELOG.md
[x] Add unit test(s) for this change

Should we make it more general to also be able to rank TSRs with the same (templated) classes? I prefer having them separate to make it simple and free of potential errors.

Separate sounds fine for me. If we implement both and find that they're more similar than we thought, maybe we can merge them then.

Where do we have the files? It seemed constraint/dart/ might be a good place since it's still a constraint over the IKs which by itself is a constraint. Can also be under planner.

I don't really consider this ranking a constraint. Maybe aikido::distance?

Cleaned up! Should be good to go (I think). Will follow up with updates to planToTSR methods once this gets merged :)
The tests are failing for reasons that don't have to do with the code itself.

This looks pretty good overall! Thanks for the changes.
@jslee02 would you mind looking over the State stuff to make sure we're using them correctly? Thanks!

Addressed the comments except for the State-handling. I'll wait for @jslee02 before modifications. I assumed that the way we'd be using the ranker we wouldn't be destroying the input states but that's a possibility in any case that needs taken care of.

I think it's reasonable to do something like return ranker.rankConfigurations(states);, which I think would lose the states.

I'm not sure if I can review this PR soon (hopefully late this week?). Please go ahead if this is blocked by me. :sweat_smile:

Hm, for some reason, test_NominalConfigurationRanker fails on macOS.


RFC for removal of managed zone

https://github.com/Kuadrant/architecture/pull/93

duplicate https://github.com/Kuadrant/architecture/pull/70


SSLError

import ssl
from wxpy import *
鈻>>> bot = Bot()
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/itchat/utils.py", line 124, in test_connect
r = requests.get(config.BASE_URL)
File "/usr/lib/python2.7/site-packages/requests/api.py", line 72, in get
return request('get', url, params=params, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/api.py", line 58, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 502, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python2.7/site-packages/requests/sessions.py", line 612, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python2.7/site-packages/requests/adapters.py", line 514, in send
raise SSLError(e, request=request)
SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)

You can't get access to internet or wechat domain, so exit.

https://github.com/littlecodersh/ItChat/issues/386#issuecomment-307317306


[REPO] build basic tooling: core dependencies switch

As a networking developer, I can rely on basic tooling for dev work so that I don't get annoyed with wasting time doing mundane things over and over (and over).

[ ] SPIKE: Easily switch core dependencies back and forth between crates.io and local path refs

(… would be nice if we had https://github.com/rust-lang/rfcs/pull/2678)

https://hackmd.io/eGD2oR6ZSLCBJa7e_uWvPA

Waiting on review: https://github.com/holochain/holochain-rust/pull/1442

recommendation documented. Please see https://github.com/holochain/holochain-rust/blob/develop/doc/dependency_dev_pattern.md for procedure.


Add optional TLS client certificate authentication.

Refactor the way the TLS trust anchors are configured in preparation
for the client and server authenticating each others' certificates.
Make the use of client certificates optional pending the implementation
of authorization policy.
Signed-off-by: Brian Smith<EMAIL_ADDRESS>

The tests for this will come after we add more of the client-side (connect) TLS logic.

@olix0r

what's the semantic difference between trust anchors and a cert store?

It seems like the RootCertStore is a container of multiple trust anchors. The rustls documentation says it's

A container for root certificates able to provide a root-of-trust for connection authentication.

I'm sure @briansmith can explain in much greater detail!

for my own edification, what's the semantic difference between trust anchors and a cert store? I take it that a cert store is a superset? What else might it contain?

"Trust anchor" refers to the CAs that are inherently trusted, i.e. root CAs. Most software we're familiar with represents trust anchors as self-signed X.509 certificates, usually in a file of concatenated PEM encodings of them.
Much (usually most) of the information in an X.509 certificate is irrelevant for a trust anchor (a.k.a. root CA). For example, tie signature is irrelevant because the certificate is signed with its own key.
In webpki the TrustAnchor type models precisely what is useful to know about a trust anchor. If one is so inclined, one could extract the useful information out of a self-signed root CA certificate and throw away the unuseful information. This is what the webpki-roots crate does, which is why it is less than half the size of Mozilla root CA store (which stores the entire self-signed certificate for each trust anchor).
The webpki crate and ring were originally written and optimized for applications running on small embedded devices where such things mattered. (That's why they spend the effort to minimize the size of the trust anchors, why they allow for the trust anchors to be embedded statically in the application, and why they they're designed to minimize code size.)


Ridge regression

Another classical type of linear regression that includes a L2 penalty.
Requirements are summarized in #23
Some resources to understand the code better:

https://ncss-wpengine.netdna-ssl.com/wp-content/themes/ncss/pdf/Procedures/NCSS/Ridge_Regression.pdf
https://www.statisticshowto.com/ridge-regression/
https://www.cs.ubc.ca/~schmidtm/Courses/540-F14/leastSquares.pdf
http://faculty.cas.usf.edu/mbrannick/regression/regma.htm

@VolodymyrOrlov Could you ensure that the changes made in this PR would not create new clippy errors if we rebase this changes on https://github.com/smartcorelib/smartcore/pull/24? Or maybe we just need to merge that PR and rebase this one and see if there are errors?

@VolodymyrOrlov Could you ensure that the changes made in this PR won't create new clippy errors if we rebase this changes on #24? Or maybe we just need to merge that PR and rebase this one and see if there are errors?

This is a good idea. Shell we merge #24 if you don't plan any more changes to it?

No

@VolodymyrOrlov Could you ensure that the changes made in this PR won't create new clippy errors if we rebase this changes on #24? Or maybe we just need to merge that PR and rebase this one and see if there are errors?

This is a good idea. Shell we merge #24 if you don't plan any more changes to it?

Yes, I am going to merge that. I plan to fix the other warnings in  a follow up PR


[Feature Request]: Add a repo docs

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
As adding a "repo docs" will be great feature, in this we have a category wise doc that includes some great github repository related to that topic.
Use Case
Example: let's say we have a web-dev category so, this page contains a list of some awesome github repo on web-dev and so on.
Benefits
No response
Add ScreenShots
No response
Priority
High
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@root-0101, we would prefer not to include it. However, if you decide to share repos, please ensure it focuses on the best practices for learning purposes and maintaining high standards.


Improved 60hz testing

We currently have a transitions test for the gallery:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/test_driver/transitions_perf_test.dart
Which currently tracks the duration of the first frame after a transition is started:
https://github.com/flutter/flutter/blob/master/examples/flutter_gallery/lib/gallery/item.dart#L34
To better know "are we 60hz" I'd like us to track slightly different metrics.  Specifically:

Time from Start Transition (user interaction) to completion of first frame.  (Target: <150ms)
Duration of second frame (we do heros here and should track it separately). (Target: <15ms)
Max duration of all subsequent frames during transition. (Target: <15ms)

@abarth @HansMuller @yjbanov

Is it possible to identify key frames in hero transitions, such as "hero departed", "hero arrived"? We could then mark and measure these frames separately from others. We could also test that such frames happen at the right time (e.g. that frame number 2 is really a "hero departed" frame).

Heroes use the same AnimationController as page transitions, so there's no special frames. In frame 0 they render with an offset of zero, in frame 1 they render with an offset of x%, in frame N they render with an offset of 100%. where the offset is the distance from the start to the end.
The only thing that's special about frame 0 vs frame 1 is that in frame 0 we render the target page in its final state (but invisibly) so that we can measure the hero target locations. (We should probably change how we do this to handle things like moving targets when scrolling.)
But I disagree that the first frame (frame 0) can be more than 16ms (even if less than 150ms). Any jank on that frame is still visible if the page has any ongoing animations. We have to hit <16ms on every single frame, even the first frame of a transition, if we're to have 60Hz animations.

It's not clear that tracking these separately will actually be particularly useful. We are tracking the transition perf for the gallery and have an outstanding work item to address perf issues there, at which point we can write special benchmarks as we deem necessary.


Tensorflow 2.13.1 not detecting GPU on Jetson Orin, not built with CUDA

Issue type
Bug
Have you reproduced the bug with TensorFlow Nightly?
No
Source
source
TensorFlow version
2.13.1
Custom code
No
OS platform and distribution
Ubuntu 20.04
Mobile device
NVIDIA Jetson AGX Orin
Python version
3.8
Bazel version
NA
GCC/compiler version
NA
CUDA/cuDNN version
CUDA 11.8/cuDNN <IP_ADDRESS>
GPU model and memory
NA
Current behavior?
I am working on an object detection project and am ready to train my model, but Tensorflow does not recognize my GPU. Looking into it further, I found that my Tensorflow had been without GPU or CUDA support, just XLA support.
I had installed Tensorflow with pip.
I know that Tensorflow 2.13.1 does not have the "and-cuda" extra, so how can I specify through pip installation that Tensorflow be installed with GPU and CUDA support?
P.S. I want to avoid switching to Tensorflow 2.14.* because I am using python 3.8 which Tensorflow 2.13.1 is the last supporting version of.
Standalone code to reproduce the issue
import tensorflow as tf

print(tf.config.list_logical_devices())
print(tf.config.list_physical_devices())
print(tf.test.is_built_with_cuda())
print(tf.test.is_built_with_gpu_support())
print(tf.test.is_built_with_rocm())
print(tf.test.is_built_with_xla())
print(tf.version.GIT_VERSION)
print(tf.version.VERSION)

Relevant log output
[LogicalDevice(name='/device:CPU:0', device_type='CPU')]
[PhysicalDevice(name='/physical_device:CPU:0', device_type='CPU')]
False
False
False
True
v2.13.1-0-gf841394b
2.13.1

Hi @Paul-Mick ,
Please find the installation instructions for Tf2.13v from the history of pip.md file.
In Tf2.13v you need to install CUDA toolkit manually using the instructions in the attached link.

Thanks for the reply.
The instructions in the pip.md file did not resolve my issue.
Luckily I found the solution elsewhere: the NVIDIA Jetson Framework Installation Page
Apparently there is a special version of Tensorflow for Jetson devices, the newest of which is 2.14.0+nv23.11.
Installing this with pip install --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v60dp tensorflow==2.14.0+nv23.11 has Tensorflow recognizing my GPU properly.
Just wanted to post this incase others have the same issue.

@Paul-Mick ,
Tensorflow officially provides installation instructions for Ubuntu only. Your comment can help others who uses the Jetson device. Just curious to mention that in above comment you installed TF2.14v which you are not intending to earlier?

@SuryanarayanaY
You are correct, I did end up installing Tensorflow 2.14 which I was not intending to. I had run into a weird issue on my AGX Orin where the ethernet adapter would go down every once in a while, and I was unable able to fix it directly.
I ended up re-flashing the Orin to JetPack 6.0DP, which supports CUDA 12.2 and cuDNN 8.9. When looking into installing Tensorflow on Jetson devices deeper I found NVIDIA's index of Tensorflow builds for Jetson, and decided to use the newest of those, which is 2.14.0+nv23.11.
I did not want to upgrade Tensorflow originally because it would have required completely restarting my project, but since that was going to happen anyhow when re-flashing my Orin upgrading became less troublesome. And using the version of Tensorflow built for Jetson fixed my original issue.


Hi, I run the train.py and get the error:

raise SameFileError("{!r} and {!r} are the same file".format(src, dst))

shutil.SameFileError: './mnt/mercury-fast/datasets/esad/cache/FPN600x1080-0-esad-resnet50-hl4s0-bn1f1b1-bs16-SGD-lr010000-mbox/source/detectionDatasets.py' and './mnt/mercury-fast/datasets/esad/cache/FPN600x1080-0-esad-resnet50-hl4s0-bn1f1b1-bs16-SGD-lr010000-mbox//source/detectionDatasets.py' are the same file
Please send help, thank you

Your working directories are ./mnt/mercury-fast/datasets/ ./mnt/mercury-fast/datasets/
Traceback (most recent call last):
File "train.py", line 438, in
main()
File "train.py", line 139, in main
utils.copy_source(source_dir) # make a copy of source files used for training as a snapshot
File "/media/H/zhangliuqing/baseline/SARAS-ESAD-Baseline-master/modules/utils.py", line 22, in copy_source
shutil.copy2(os.path.join(dirpath, file), source_dir )
File "/home/yons/anaconda3/lib/python3.8/shutil.py", line 432, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/home/yons/anaconda3/lib/python3.8/shutil.py", line 241, in copyfile
raise SameFileError("{!r} and {!r} are the same file".format(src, dst))
shutil.SameFileError: './mnt/mercury-fast/datasets/esad/cache/FPN600x1080-0-esad-resnet50-hl4s0-bn1f1b1-bs16-SGD-lr010000-mbox/source/detectionDatasets.py' and './mnt/mercury-fast/datasets/esad/cache/FPN600x1080-0-esad-resnet50-hl4s0-bn1f1b1-bs16-SGD-lr010000-mbox//source/detectionDatasets.py' are the same file

It seems like you haven't change the directories.  "./mnt/mercury-fast/datasets" is only valid on my machine you need to specify data_root and save_root in arguments based on your directory structure.


Ensure config data is within hard limits

Subtask of #58
Needs further explanation. How are these limits defined? Can we link to a specs document?
And most importantly, is this critical for Alpha?
@lee-matthews @neelfirst

It looks like #58 is beta so this should be beta as well. I'm not really sure what this means anyways.

These are to validation check input values to be sure that they're within
safe limits. It's to stop someone inadvertently setting the respiration
rate to 1000 breaths/minute for example.
On Tue, 14 Apr 2020, 19:17 neelfirst<EMAIL_ADDRESS>wrote:

It looks like #58
https://github.com/RespiraWorks/VentilatorSoftware/issues/58 is beta so
this should be beta as well. I'm not really sure what this means anyways.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/RespiraWorks/VentilatorSoftware/issues/83#issuecomment-613570261,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEXLVLGUT7S4IMPXFWY5BG3RMSLDPANCNFSM4MHQN4JA
.

Implemented by having limits on GUI input widgets.


cursor disappears in code block under certain instances

I thought you may want to know that people using obsidian's core vim mode along with the Editor Syntax Highlighting Plugin lose their cursor when navigating inside code blocks; the cursor blocks and the code background color match. This happens in both light and dark mode.
Probably a tiny cross-section of users, but thought I'd let you know anyway.
Wonderful theme, thank you!

Thanks for letting me know, I'm working on the theme every now and then (more like on the side) and changing something when something bothers me. Basically syntax highlighting in code blocks is already a built-in feature in Obsidian, and firefly Theme will add its own syntax-highlighting flavour in the future. Anyways, when I get a chance I'll take a closer look at the problem. : )
I'm glad you like the theme - so thank you for thank you! : )

Thank you once more for reaching out - I had a look at the plugin! : )
Since time is rare I will not work on that one - Obsidian already supports syntax highlighting within the document preview, hopefully they'll do so for the editor soon as well.


Mito analysis - methods text

Write methods text for the mito analysis.

As discussed, suggest to postpone working on methods until a first pass on all results text and main artwork is done, but adding this issue for completeness.


[az bot]: prepare-deploy does not output a success message or return any values

Information:

Tools Libraries: az bot  v2.0.61

Issue Description:
az bot prepare-deploy does not follow Azure CLI guidellines in returning output for the command. We can also log a success message that is only triggered when --verbose is added to the command.
For the command output, we would return a dict:
# For C# csproj_file is the absolute path to the .deployment file
return {"is_success": True, "file_path": csproj_file}

# For Node.js we would return the absolute path to the web.config file
return {"is_success": True, "file_path": os.path.join(code_dir, "web.config")}

Commands Example:
az bot prepare-deploy --lang Node --code-dir "."
# Receive no output

@scheyal FYI

Closing via stevengum/Azure-cli#a7b5baf6d9a10a64c6cd2d788ace8b7aad84631a


Signed version of SQLitePCL.bundle_green

We have recently updated https://github.com/Azure/azure-mobile-apps-net-client to take dependency on SQLitePCL.bundle_green 0.9.3. Loading SQLitePCL.raw fails at runtime:
Could not load file or assembly 'SQLitePCL.raw, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
All the assemblies in Microsoft.Azure.Mobile.Client are signed. Is it possible to publish a nuget package with signed assemblies?

For context, this looks like a new form of issue #53.  Same reply:  Yes, I will make this happen, and quickly as I can, but strong-naming has been a can of worms.  I need to re-open the can, remember the issues, and push through them.

@ericsink Thanks for the quick follow up!
FYI: @paulbatum,  @fabiocav

If I am looking at the correct packages on nuget, it looks like you have not yet pushed packages with the SQLitePCL.raw dep.  Is that right?
In other words, the urgency on the strong-naming issue for you may be "high", but it is not "urgent crisis because everything is broken".  Is that right?

We need to release ASAP as our current SDK will not work with Android N. Our current release is blocked until Strong Name issue is fixed. Let me know if there is anything I can help with.

Understood.  And also:
I have been working on my 0.9.4 release, which contains a pretty significant number of changes since 0.9.3.  I assume those changes represent risk to you, and you would prefer something closer to just "0.9.3 + strong naming"?

Let me test our bits with 0.9.4-pre1 nuget package as we would prefer depending on latest nuget packages.

Er, actually...
0.9.4-pre1 does not contain most of the changes that I've been planning to be in 0.9.4.  So that testing won't help you.
Roughly speaking, 0.9.4 contains:
fix for certain cases where UWP apps fail validation
support for custom sqlite3 builds
support for using the winsqlite3 built-in to Windows 10
refactor and rename some things that where the need to deal with Android N has broken old assumptions
Bottom line:  I would like you guys to end up on 0.9.4.  I'll try to get at least a pre-release build pushed as soon as possible so you can be heading in that direction.

Ok. Thanks.  0.9.4 + Strong Name should work for us. I can work on updating out SDK if there are any breaking changes.

I have two options here:

Become confident that I can add strong naming for all SQLitePCL.raw users without causing difficulties for those who do not need it.

Begin publishing two parallel sets of packages, one with strong naming (for those who need it), and one without.

I do not know how much time option 1 will take.
Option 2 is relatively easy.  My build system is entirely build around automatic generation of code and project files, so the SN packages and the non-SN packages will always be identical except for the strong naming.
How do you feel about option 2?

Yes. Option 2 sounds good. Thanks!

I've implemented the changes to the build system to create two parallel sets of packages.
The ones starting with "SQLitePCL." are the regular ones.
The ones starting with "SQLitePCL_sn." are the ones with strong names.
After some more testing and fixes, I will push a prerelease of 0.9.4, hopefully later today or tomorrow.

Ok. Thanks for the update.

Could the Azure SDK just use: https://github.com/dsplaisted/strongnamer

I'll let @pragnagopa say whether the @dplaisted strongnamer tool would meet their requirements or not.
But if it would, I would be delighted to remove all the SN stuff I've added to my build system in the last couple days.  :-)

Will look into it and get back to you soon.

Discussed with my team. Looks like we have already looked into strongnamer but are reluctant to add another dependency as this would force our customers to take a dependency on it as well.

But if the technique works...
Where does the extra dep become a problem?
What if I had implemented compatibility with strongnames by simply adding that dep to bundle_green?
What if I extra the concept or technique from strongnamer and put it into a bundle_green_sn?
I intend to do whatever is needed to make sure my lib is compatible with your situation, but I'd rather add 1 new package than 56.

Thank you for raising your concerns.
Where does the extra dep become a problem?

Once we package Azure Mobile Apps nuget with strongnamer, it will be part of customer's application and will affect all the assemblies that are part of the application as we cannot restrict strong naming to just the assemblies we depend on.
For any additional dependency we add, we will have an added maintenance cost as we need to thoroughly test before any release/upgrade to make sure we don't break our customers.

What if I had implemented compatibility with strongnames by simply adding that dep to bundle_green?
If bundle_green adds strongnamer and if that means all the assemblies in the application will be affected, then we will have to re-evaluate our dependency bundle_green as it will require a security review.
What if I extra the concept or technique from strongnamer and put it into a bundle_green_sn?
If bundle_green_sn uses the same technique as strongnamer, this would be fine assuming only assemblies in bundle_green_sn will be affected.
Hope I answered all your questions!

This is a thorny issue. Please consider discussing it with @terrajobst and @davkean from the .NET team (and feel free to include me too if you can wait until Thursday or later when I’m back from vacation).
Having separate signed and unsigned versions of SQLitePCL.raw is highly undesirable, as it means that all libraries that depend on SQLitePCL.raw would also have to have separate signed and unsigned versions, otherwise they would be incompatible with each other.  For example, if sqlite-net-pcl only has an unsigned version, and Microsoft.Azure.Mobile.Client only has a signed version, then it won't be possible to use both of the packages together in an app.
There's not too much of a downside to strong naming an assembly, so it would probably be OK to just switch over to strong naming SQLitePCL.raw for everyone.  However, adding (or removing) a strong name is a breaking change that would require all existing libraries (and NuGet packages) that depend on it to be recompiled with the newly strong named version.
There's also not a strong reason for a library to be strong named.  Even for a library shipped by Microsoft, I think we could consider whether it's actually the right thing to do to strong name it.  However, since removing a strong name is a breaking change, this may not be an option for the Microsoft.Azure.Mobile.Client package.
Another option might be to use something like strong namer to sign and then ILMerge SQLitePCL.raw into Microsoft.Azure.Mobile.Client.  That would mean instead of having a package dependency on it, that the Azure library would include a copy of the SQL library merged into its own assembly.

If bundle_green adds strongnamer and if that means all the assemblies in the application will be affected, then we will have to re-evaluate our dependency bundle_green as it will require a security review.

@pragnagopa Strong naming should not be used for security, so your statement makes me slightly worried that strong naming is being used incorrectly somewhere.

Sorry! I just found that we have a requirement on assemblies being strongly named at compile time as we are part of visual studio. So including strongnamer will not work for us.
@dsplaisted, including sqlpcl.raw libraries directly in our package will restrict customers from upgrading to any other version of bundle-green

Yep, issues don't come much thornier than this one.  I've taken a lap around this track once before, about a year ago, in issue #53.

There's not too much of a downside to strong naming an assembly,

The prevailing sentiment in the OSS community would seem to disagree with this.  Vehemently.  But I can't really know how much the pain is being exaggerated, because I haven't experienced it myself.
I've also heard lots from some in the "strongnames are the best thing ever" camp.  The exaggeration from that side comes in the form of denying that tradeoffs exist.  (There are no problems with strongnaming.  The coin has only one side.)  I haven't found those arguments helpful.
I consider it essential that I find a way to make sure that people who need to use strong names (like @pragnagopa and his team) can use SQLitePCL.raw.
But forcing strong names on all my users seems unthinkable, given (1) the huge tide of opposing sentiment, and (2) my lack of experiential knowledge on how to minimize the pain.
So I had really convinced myself that having a parallel set of packages would be the least bad option.  Still dreadful, but less so than anything else.
But I do want to explore the idea of building one of my "bundle" packages which simply brings in the deps it needs and uses the same technique as strongnamer to present them as strongnamed assemblies even though they are not.  If I understand the concern from @pragnagopa it is simply that he wants the black magic confined to the SQLitePCL.raw packages, with no chance of other assemblies getting affected.  In other words, the scary thing about strongnamer is that you drop it in and it (apparently) just looks at all the references and possible does its magic on all of them, whereas he and his team want its possible affects to be strictly limited.  Correct me if I'm wrong.

I just found that we have a requirement on assemblies being strongly named at compile time as we are part of visual studio Which requires assemblies to be strongly named at compile time.

FWIW, here is part of how I talked myself into a parallel set of packages:
SQLitePCL.raw is open source.  Apache license.  Anybody can fork it and do what they want.
If somebody doesn't like the lack of strong names on the assemblies, they can fork SQLitePCL.raw, add strong names to everything, and re-release it.
Of course, they'll have to use separate package names.  So their forked version will be a completely different thing, with no expectation of compatibility or interop with SQLitePCL.raw.  People who need strong names would choose that other package.  Everybody else would choose SQLitePCL.raw.
Now what if that "somebody" was me?

One of the reasons we decided to take dependency on bundle_green instead of updating our current dependency: SQLitePCL to work with Android N, is that it simplifies our  build process and improves customer experience. Thanks @ericsink for considering our requirements!

I should also acknowledge that option 1 is still on the table.  From above, option 1:

Become confident that I can add strong naming for all SQLitePCL.raw users without causing difficulties for those who do not need it.

This is the path where I figure out exactly what @dsplaisted means when he says "There's not too much of a downside to strong naming an assembly".  Maybe strong names aren't that bad.  Maybe all the pain is exaggerated.  (Like I said, I wouldn't know.  I left the .NET community for a few years to go do something stupid, and now that I'm back, it looks like I missed a few things.)
But this path would probably take time.  And @pragnagopa is in a hurry, since Android N is shipping, and dealing with that mess is apparently part of their reason for taking a dep on SQLitePCL.raw.
So, I want to find the right answer here, but I also want to find it within the time constraints.
Anyway, perhaps I should stop adding comments on this item and go back to trying to find the right answer.

OK, I am trying to talk myself into just adding strong names to all SQLitePCL.raw assemblies.
My first high-level observation is that the strong name wars of 2012-2014 happened in a different context, one where the .NET open source community was mostly distinct from Microsoft.  That is no longer true.
For me, all the arguments about the benefits of strong naming as a feature are irrelevant.  The only benefit of strong naming that matters to me is that projects like Microsoft.Azure.Mobile.Client will be able to use my library.  To make that happen, I need to either strong name or I need to start convincing teams in Redmond to change their policy.  The latter path is absurd, so I will release a strong named version of SQLitePCL.raw.  The only question is whether it will be the only version.  Will I have one set of strong named packages, or two parallel sets, one with strong names and one without?
As I said above, to have one set, I need to:

Become confident that I can add strong naming for all SQLitePCL.raw users without causing difficulties for those who do not need it.

AFAICT, most of the pain of using strong names can be removed by never changing the assembly version again.  This would apparently mean that using SQLitePCL.raw with the GAC could be problematic, but I don't think anyone does that anyway.  And I also think that nobody uses SQLitePCL.raw assemblies apart from the nuget packages, so the notion of abandoning the lower-level versioning scheme in favor of nuget's versioning scheme is viable in my case.
Another common argument is that strong naming an open source package makes it harder for new contributors to get started.  That's a non-issue for SQLitePCL.raw as well.  Basically, if I were trying to make it easy for people to contribute to this project, strong naming would be the least of the problems.
I am a little bit concerned about whether problems are going to occur with oddball platforms.  Did the previous strong naming wars happen mostly in the context of the .NET platform?  I support stuff like net35, Windows Phone Silverlight, netstandard, UWP, Xamarin, and so on.  And in every case, the primary function of this library is to facilitate calling native code (sqlite3 itself).
But again, I only have two choices:  add strong names, or maintain my own strong-named fork.
As suggested by @dsplaisted above, I specifically invite feedback from @davkean and @terrajobst.
And also, since @davidfowl is an example of a notable Microsoft person who has taken the "just stop strong naming" stance in the past, I am curious about his current opinions on the matter.
Thanks to all for your patience with this "thorny issue".

@dsplaisted said:

However, adding (or removing) a strong name is a breaking change that would require all existing libraries (and NuGet packages) that depend on it to be recompiled with the newly strong named version.

@terrajobst has previously said that adding strong name signing to an assembly is not a breaking change. A binding redirect in the app can make it work. He has also indicated that removing a strong name signature is a breaking change as a binding redirect will not make that work.
@pragnagopa said:

I just found that we have a requirement on assemblies being strongly named at compile time as we are part of visual studio Which requires assemblies to be strongly named at compile time.

I don't think that's true. I used to think it was true, but it turns out only authenticode signing is required. Strong-name signing is not required to ship with VS. However, not strong-name signing in VS may be very problematic in practice if you expect anyone else to reference you, since almost everyone else is strong-name signed. But what you can do is strong-name sign your contract assemblies and avoid a reference to sqlitePCL in that contract assembly. Then do not strong name sign your implementation assembly and have that be what references SqlitePCL. That's how we've made do with sqlitePCL.raw so far (which already is in VS, BTW).
That said, I'm fully in favor of this project starting to strong-name sign its assemblies. I'm just volunteering that sometimes there's an acceptable workaround.

Adding a strong name is a breaking change - binding redirects will not help you here.

Good to know. Thanks.

Azure Mobile Apps is included as part of Visual Studio install and is used for connecting to Azure Mobile App runtime. Having a strong named assemblies is a requirement for us. My team and I greatly appreciate all the effort and time spent by @ericsink  and others to figure out the right solution. Unfortunately we are time constrained and we need to release ASAP.
@ericsink assuming you will be taking the route of maintaining signed and unsigned versions as adding SN is a breaking change,  can you please give me a tentative timeline on when can you can publish bundle_green_sn?

Hoping to publish a prerelease today (for your testing and integration purposes) and a final by the end of the week.

@pragnagopa Could I provide you those prerelease testing packages out-of-band instead of publishing them through nuget.org?

Yes. That will help to get started on the testing the new version. Please send them to<EMAIL_ADDRESS>It would be great if you can also publish prerelease to nuget once I am done testing so that we can release a prerelease version of Azure Mobile Apps while we wait for the final package.

OK, my current plan is:

One set of assemblies, with strong names
But this next release will be version 1.0, not 0.9.4.  The AssemblyVersion will be <IP_ADDRESS> and will (probably) never change.
And, in this release, all packages have names starting with SQLitePCLRaw.* instead of SQLitePCL.*

Background:  Actually this release had more breaking changes than just strong names.  Calling it 0.9.4 was always kind of a bad idea.  If I had pushed this as SQLitePCL.raw-0.9.4, and if Couchbase Lite users updated, things for them would break.  Bad idea.  So, giving everything a completely new name is more appropriate, and allows me to help migrate 0.9 users on whatever schedule makes sense for them.
And given that everything is new, this is the time to add strong names and support them going forward.
A zip file with all this has been sent to @pragnagopa.  Once I get basic feedback on that, I'll be pushing the prerelease packages to nuget.org, proceeding to 1.0 final as quickly as prudence permits.

But this next release will be version 1.0, not 0.9.4. The AssemblyVersion will be <IP_ADDRESS> and will (probably) never change.

I understand why people go for this approach, but I don't recommend it.  That's because although strong naming generally doesn't provide any technical advantage, in the cases where there is a legitimate technical reason to use strong naming, the strategy of not changing the AssemblyVersion defeats the reason you had to use strong naming in the first place.
The main technical reasons to use strong names are:

You need to put an assembly in the GAC, for whatever reason.
You support third-party extensions.

The GAC is machine-wide and .NET will prefer to load an assembly from the GAC over an assembly with the same version in the app folder.  So if one app installs the library in the GAC, and another app depends on a later version of the library that has the same AssemblyVersion, then the second app will load the previous version from the GAC, and will probably fail with MissingMethodException or similar.
In an app (for example, Visual Studio) that loads third-party extensions into the same AppDomain, it's a good idea for reusable libraries used by extensions to be strong named.  This lets different versions of a reusable library be loaded side-by-side.  If two extensions depend on different versions of a library that is not strong named, then the version of the library loaded will be from whichever extension happens to load first.  This means that the other extension is likely to get MissingMethodExceptions or similar.  The same behavior (first extension wins) also occurs if different versions of the library use the same AssemblyVersion.
So in both cases where you actually need strong naming, releasing different versions of a library with the same AssemblyVersion can result in unexpected errors happening as a result of an unrelated app or extension being installed on the machine.
The reason you would want to leave the AssemblyVersion constant is to avoid binding redirects.  However, I think Automatic Binding Redirects should make them a lot less painful than everyone remembers.

@AArnott

@terrajobst has previously said that adding strong name signing to an assembly is not a breaking change

As @davkean said: unfortunately that's not how it works.

Thanks to @dsplaisted for the comment starting with "I understand why people go for this approach, but I don't recommend it."  That's more to think about.
Going forward, I simply want to navigate this issue in whatever fashion causes the least pain.  I'll stay open minded about exactly how that is done.

Version 1.0 is released, with signed assemblies.


Improve legibility of computed props in the annotation pages

This is an issue from the PR that we decided to address later because of the upcoming demo and to proceed with the core functionality of the PR faster. Here are the comments @jarmoza made in the PR:

Complex return values (see examples filteredTable, uniqueValues, unique_table_data, applyTransform in annot-age-values.vue and filteredColumns in annot-columns.vue):

Though it's tempting to use this kind of syntax to produce a return value in one line, code like this becomes confusing for people who are approaching it. I would recommend breaking down this return value creation process into several lines before the final value is returned.

As I mention in one comment in annot-columns.vue, maybe we should institute some rule for the number of levels deep a (return) statement can be before it should be broken up into several distinct steps in our code.

Originally posted by @jarmoza in https://github.com/metaneuro/annotation_tool/pull/77#pullrequestreview-916367338

@jarmoza take a look and let me know if we should close this

It's good to close. This was handled in PR #108


Feature: Add Qwen/QwQ-32B-Preview Support

Is your feature request related to a problem? Please describe:
I tried out Qwen/QwQ-32B-Preview yesterday and I have to say as-is it's actually pretty good. It was able to one-shot something Qwen2.5-Coder-32B-Instruct had issues with. I was able to add it easily enough, but it wouldn't interact with the terminal or update files. I'm not sure why, but copying the code it generated worked (it's just an extra step).
Describe the solution you'd like:
My request is two fold, can Qwen/QwQ-32B-Preview be added to the official main branch, and maybe someone look into why it doesn't interact with the Terminal or project?
See: https://huggingface.co/Qwen/QwQ-32B-Preview
Describe alternatives you've considered:
Do nothing?
Additional context:
And also, maybe update the Provider List to remove duplicates.
If I knew that the changes would be welcomed and accepted, I can do these changes myself. I just wanted to confirm the interest or not. Thanks!

having the same problem with 7B qwen2.5

Why would you use Qwen2.5 7B? Any Qwen model below 14B are pretty much useless imo. Unless you're running it with Ollama or something locally (which could make sense)? I'd just sign up for a free HuggingFace account and use Coder-32B or QwQ (pretty good but you'd have to modify the code to use it). In my experience there's really not an API rate limit I can tell.

Why would you use Qwen2.5 7B? Any Qwen model below 14B are pretty much useless imo. Unless you're running it with Ollama or something locally (which could make sense)? I'd just sign up for a free HuggingFace account and use Coder-32B or QwQ (pretty good but you'd have to modify the code to use it). In my experience there's really not an API rate limit that I can tell.

im running ollama locally on my pc, i really dont wanna use tokens that might limit my usage

I mean it, sign up for a FREE HuggingFace account, grab an API, add that to it. I haven't run into a rate limit or cap (honestly) and I've made it run non-stop. Maybe there is one, but I can't find it... in which case it might be nice to add API_KEY load balancing. And I guess I'll have to start monitoring how many tokens I use. Use Qwen/Qwen2.5-Coder-32B-Instruct, Qwen/Qwen2.5-72B-Instruct, or Qwen/QwQ-32B-Preview (new but seems good but does not interact with the terminal yet).

Hello,
Thank you for your detailed feedback on using Qwen/QwQ-32B-Preview. We appreciate your comments and suggestions.
Issue Related to a Feature Request
It appears that Qwen/QwQ-32B-Preview has shown promising performance compared to Qwen2.5-Coder-32B-Instruct, successfully executing complex tasks in a single attempt. However, we understand there was an issue with interaction with the terminal and file updates, necessitating an extra step of manually copying the generated code.
Desired Solution
We have noted your request to integrate Qwen/QwQ-32B-Preview into the official main branch. We will review this proposal to determine if this integration is feasible. Regarding the issue with terminal interaction and file updates, we will investigate to understand why this occurs and seek a solution.
Considered Alternatives
We understand that you considered doing nothing as an alternative, but we believe your suggestions are worth exploring to enhance the user experience.
Additional Context
Regarding the correction of duplicate entries in the supplier list, this has already been done. You can refer to this update here: https://github.com/coleam00/bolt.new-any-llm/pull/499.
We appreciate your willingness to contribute directly to these changes. Your involvement is crucial to us. We will keep you informed of the progress of your request and the final decision regarding the integration of Qwen/QwQ-32B-Preview.
Thank you again for your suggestions and your engagement!
Best regards,
The Development Team

For free Hugging Face accounts, you get up to 1,000 API requests per day to use models via the Inference API. However, not all models have the Inference API enabled. Here's a breakdown:

Some models are inactive because their creators disabled the API.

Models can also have statuses like warm or cold:

Warm: The model is actively used and runs quickly because resources are allocated.
Cold: Usage has decreased, so it might take longer or fail since resources are deallocated.

If you’re using the free Inference API, stick to popular models with the API enabled (often warm-status). You can check this on the model's page under "Inference API" settings.
### Screenshot 1:
### Screenshot 2: Warm/Cold

Hugginface models dont work anymore if you use it for a while, at least thats what happens to me. but then when i open a new bolt chat it works again. using qwen coder 32b

Hugginface models dont work anymore if you use it for a while, at least thats what happens to me. but then when i open a new bolt chat it works again. using qwen coder 32b

I've noticed the same thing, maybe they are throttling requests, not sure. That's why I switched to using Openrouter. Might require additional exploration.