Get clock from pump when offline

Another snippet from my "towards long term offline looping"-project. I had the issue when the rig was down for more than a few minutes, the missaligned clockes prevented the loop from running. Therefore I take the clock from the pump when the rig boots and is offline. That does not effect online operation as this script does nothing when wifi is connected. Also when the rig comes online again, the rig clock gets ntp syncronized and updates the pump clock at some point.
Tested on my PI+HAT rig but should work for every pi based and edison based rig

Does this pose a race condition with oref0-pump-loop using the radio?  Your sleep 60 would allow the pump-loop to start, at which point the radio would be locked, right?
I know we originally put similar logic to this into oref0-pump-loop itself: not sure if that isn't working, or ?
https://github.com/openaps/oref0/blob/dev/bin/oref0-pump-loop.sh#L387

Hi - while backpacking for a week offline the last few days, I ran into the chip clock issue big time when rig lost power and when I had to swap batteries. I am looking forward to see what you are doing! And I can confirm that this is an issue at least with the chip I was using, which was up-to-date in dev last week (there have been two new commits since then.)

Actually, looking into this further, this shouldn't be able to do any harm, since setting the system clock just reads a file, and doesn't actually talk to the pump.  I'm also attempting to fix this with https://github.com/openaps/oref0/tree/offline-clock-set and will let you know if that works.

@juehv would you care to test out https://github.com/openaps/oref0/pull/1290 and see if that fixes offline looping for you without the new cron job?

@scottleibrand Yes of course. I'll install it tomorrow evening.

Thanks.  LMK (preferably by commenting on #1290) when you've had a chance to confirm that it helps and doesn't break anything.

#1290 works better


RuntimeException not found in transliterator

On line 46 of release 0.7.0, if this exception needs to be thrown, RuntimeException is not found.
Resolution:
Ensure use RuntimeException is added to the top of the file.

Hi @tdondich
You are refering to this line right? https://github.com/mbilbille/jpnforphp/blob/5623468503cc2941f4656b0ee1a58b939d263453/src/JpnForPhp/Transliterator/Transliterator.php#L46
I need to check this. Thanks for bringing this.

Yep, that's the line. Just never brought in RuntimeException as a use


Update VRControls from three.js dev

Fixes support for Firefox Nightly.

Please update gh-pages as well.


api: add total_{active,new,fail}_connections to UpstreamLocalityStats

The new fields are marked with [#not-implemented-hide:] and work_in_progress per the guide.
Implementation will be added later in a separate PR.
Rationale: Current version of LRS protocol uses requests as a unit of load. L4 load balancers don't have information on the number of requests, but they can approximate it by the number of new and active connections.
Envoy already collects and exposes some of the statistics that can be used for the implementation of the new fields:

total_new_connections ~ upstream_cx_total(now) - upstream_cx_total(now - load_report_interval)
total_active_connections ~ upstream_cx_active
total_fail_connections ~ upstream_cx_connect_fail(now) - upstream_cx_connect_fail(now - load_report_interval)

Please note that the linked stats are aggregated per cluster, while the new fields will correspond to UpstreamLocality, so the actual implementation will be more nuanced.
Commit Message: api: add total_{active,new,fail}_connections to UpstreamLocalityStats
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

this should also make sense for TCP proxy in Envoy right? The motivation comes from non-Envoy xDS use cases I believe, but thsi should be implementable and usable for our own L4 LB needs ideally.

Yes, I think it should work as expected; the stats in question are on the cluster, and I believe they're all set correctly in the tcp-proxy case.

Note that when implementing this, because the stats need to be per-locality, I think you'll be limited to "host stats", and won't be able to use the cluster-wide stats.
#define ALL_HOST_STATS(COUNTER, GAUGE)                                                             \
  COUNTER(cx_connect_fail)                                                                         \
  COUNTER(cx_total)                                                                                \
  COUNTER(rq_error)                                                                                \
  COUNTER(rq_success)                                                                              \
  COUNTER(rq_timeout)                                                                              \
  COUNTER(rq_total)                                                                                \
  GAUGE(cx_active)                                                                                \
  GAUGE(rq_active)

But I think these cover what you need, so it should be fine. If you don't think these stats will be sufficient, we should discuss up front, because the memory-use impact of adding host stats is very high.

/wait

@abeyad are comments addressed or should this be tagged as waiting?

@AwesomePatrol I think we decided on:
Rename this field to total_connect_fail and/or point out in the comment that this is similar to cx_connect_fail metric

But the PR hasn't been updated accordingly.  Tagging as waiting until it's addressed.  Thanks!

/wait

@AwesomePatrol I think we decided on:
Rename this field to total_connect_fail and/or point out in the comment that this is similar to cx_connect_fail metric

But the PR hasn't been updated accordingly. Tagging as waiting until it's addressed. Thanks!

The field was renamed to total_fail_connections (for consistency with total_{active,new}_connections). Should I change it again?
The description of PR (which I assume will become the commit description) was also updated to reflect that the field corresponds to cx_connect_fail metric now.

The field was renamed to total_fail_connections (for consistency with total_{active,new}_connections). Should I change it again?

No that's fine, consistency is better.

The description of PR (which I assume will become the commit description) was also updated to reflect that the field corresponds to cx_connect_fail metric now.

Ah ok I missed the PR description change.  Those comments on each field would actually be better as comments in the proto file, if you could kindly add it to the PR, thanks!
Also, I suggest merging main, as there are some failing CI jobs, not sure if merging main will resolve it.

/retest


Student finance forms yearly document update

https://govuk.zendesk.com/agent/tickets/972939
2015 to 2016 forms for continuing EU full-time students will be available from Monday 16 March.
This path:
https://www.gov.uk/student-finance-forms/y/eu-full-time/year-1516/continuing-student
needs to lead to this outcome:
https://github.com/alphagov/smart-answers/blob/master/lib/smartdown_flows/student-finance-forms/outcomes/outcome_eu_ft_1516_continuing.txt
and the file size for the first file needs to change from 109 to 107KB

:+1:


EHealth-1225 - get system user from config

Changes Unknown when pulling 389713c88aa91a8b517bbc75ff312fcb321d60e5 on system_user into ** on master**.


Userinfo not updated on dev branch

Describe the bug
https://github.com/zerinho6bot/Zerinho6-Bot/blob/dev/src/commands/userinfo.js#L8
Since dev branch will get rid of variables with underlines, I changed all utils files variables to "filenameUtils", so this line will be undefined.

To be fixed close to 16:00(Brasilia time zone)

Fixed in https://github.com/zerinho6bot/Zerinho6-Bot/commit/885e391d344204b4a84c7201f82a2e6a2c95179b


zgui: Possible issue tied to dawn memory leak on macOS

Issue backstory here: https://github.com/foxnne/pixi/issues/9
I haven't been able to repro this outside of my project yet, but I also haven't had much time to investigate. Just creating this issue from what we talked about on Discord.
I'm using this zip library, and if I use zgui and load a zip file triggered from a selectable, 9/10 times it works fine, but sometimes the program freezes and begins flashing a magenta screen. If I resize the window during this, the magenta screen stays on screen with no flashing. The program cannot recover and will stay magenta until it is closed. No errors are reported. This only occurs on macOS.
Googling around for similar issues doesn't turn up much, but I did see a couple mentions that sometimes shader errors are presented with a magenta screen using Dear Imgui, but its fully possible this is an issue popping up from something else and just presenting as a shader error through zgui.

Note that Image.initFromData() do not copy the data but keeps a reference to it. My guess - below code allocates the data and then releases it with defer code but image still keeps a reference to it. What do you think?
     _ = zip.zip_entry_open(pixi_file, layer_image_name.ptr);
     _ = zip.zip_entry_read(pixi_file, &img_buf, &img_len);
     defer _ = zip.zip_entry_close(pixi_file);

Thanks! I just modified my code to use allocator.dupe() and store the raw data rather than letting it release at the end of the load scope, I'll try this out for a while and see if it remedies the bug.

Looks like this change fixed the issue, thank you so much for your help and apologies for the false alarm!

Great to here that! Happy I could help.


Pollset & pollset-set implementation firewalls

Looks tantalizingly green so far.

The one failure in the tests is one of the timer flakes that we know about, and which will hopefully be cleared up by #5434 .

Let's add "ready to merge" label next time instead of merging directly.

? This was merged a long time ago (in a galaxy far far away)

ah, sorry, perhaps I clicked on a wrong pull request link.


[17.06.1] Swagger and API docs cherry-picks

Cherry-picks of:

[ ] https://github.com/moby/moby/pull/33423 https://github.com/moby/moby/commit/56da4f2fb2509f9b2c2bc1c1c609c1dabeaec07d ("Fix typo in swagger doc")
[ ] https://github.com/moby/moby/pull/34002 https://github.com/moby/moby/commit/d0a8e73e7b60f61db0c3799643aaccbbf33f3601 ("Service privileges: API docs")
[ ] https://github.com/moby/moby/pull/34035 https://github.com/moby/moby/commit/f596fb7683227021b74d299ad1613a1e3263cf30 ("add cluster events details in swagger.yml")
[ ] https://github.com/moby/moby/pull/34065 https://github.com/moby/moby/commit/e9da15a6603f288a4c0005fc8f4161b45390e26b ("add cluster events change in version_history.md")
[ ] https://github.com/moby/moby/pull/34171 https://github.com/moby/moby/commit/f6954bea9f28c62c50b88c895968045cf801aa81 ("Fix API docs for GET /secrets/{id}, GET /secrets")
[ ] https://github.com/moby/moby/pull/34172 https://github.com/moby/moby/commit/ea1d14a189d62df34427b037a6d043ae3028760b ("api: Update swagger.yaml for configs")
[ ] https://github.com/moby/moby/pull/34186 https://github.com/moby/moby/commit/194f635ce7d097f550986bc3169ab59158f5aa68 ("Improve API docs for UsageData")

ping @aaronlehmann @andrewhsu @tiborvass PTAL

LGTM

LGTM


Nodepool limit could exceed 100 nodes

Per test, nodepool could exceed 100 nodes limit by scaling from the VMSS nodepool level directly. And AKS could recognize these nodes properly, I could see one nodepool count reached 200 . Could you please confirm what should be the maximum size of a nodepool and cluster?

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

ID: 18e73ba6-a06d-9bc4-fef6-6ece8a166e84
Version Independent ID: a9efcfab-f4c5-969b-4cd4-aa86ebd80534
Content: Limits for resources, SKUs, regions - Azure Kubernetes Service
Content Source: articles/aks/quotas-skus-regions.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@gsxmax Thank you for sharing your query! We are currently investigating and will get back to you shortly on this.

@gsxmax I had discussion internally and got below response from our Product group team:
The supported maximum is the documented one. It’s not supported to use the VMSS API directly. If they have specific needs on pool size, we can talk with them.
Do let me know if you have any further queries on this.
Thanks

Currently we have confirmed the limitation has changed, hopefully we could modify the document accordingly to avoid confusion.

@gsxmax Hope the provided information is helpful.
We will now close this issue. If there are further questions regarding this, please tag me in a comment. I will reopen it and we will continue the discussion.


ENG-1909 - fix: tokenize types

Description
Fixes /tokenize types

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

[x] Not Applicable

Rollback / Rollforward Procedure

[x] Roll Forward
[ ] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

:tada: This PR is included in version 1.13.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Distinguish between no_soma_found and disconnected_neurite

Currently a dendrite without soma throws both warnings, and disconnected_neurite is the first to throw. It must be made to throw only no_soma_found.

Solved in #296


Refactor memory management types

The memory manager works with: vaddr, mfn, pfn, pageTableEntry, and others. There are some sections that play a bit fast-and-loose with conversions between these types, as well as using generic types like uintptr.
We should make sure the existing types and methods make sense, and that they're used consistently.

I'm now less concerned with this, particularly outside the context of any feature development. Closing.


Disable Input Mode

Hi!
I’m using your RichText Editor and it is beautiful!
Please I have a question: is it possible to disable the input mode? I would like to present the page as read-only and the user has to unlock the page to edit it.
Thanks in advance,
Fabio.

Hey!
Did you manage to get the disable part working?

I've had luck disabling input using 'editor.setFocusable(false);'

I used a simple webview in case of readonly, but I think that @swilkinson1 suggest should works.


test(filterWIT-board): WIT board filters initial tests

This  PR contains

couple of verification tests for Filter by WIT on board view page
modification in schema mock generator
Note( Pending cases due to fix  required in mock services ) : https://github.com/fabric8io/fabric8-planner/issues/1254

@ldimaggi  / @nimishamukherjee ,
can you please review this !

Oh sorry, I was too fast, did not see the comment :-)


Using existing Azure MySQL instance as a parent instance in OSBA

Align with https://github.com/Azure/open-service-broker-azure/issues/585.

Is there any update/timeline on this enhancement? Would need it for a project where there already is a mysql instance deployed so we wouldn't need to migrate DB's.


Migrate Gradle plugin application from deprecated imperative method to new declarative approach

Describe the bug
On building application, the following warning is shown.
You are applying Flutter's app_plugin_loader Gradle plugin imperatively using the apply script method, which is deprecated and will be removed in a future release. Migrate to applying Gradle plugins with the declarative plugins block: https://flutter.dev/go/flutter-gradle-plugin-apply.
To build a Flutter app for Android, Flutter's Gradle plugins must be applied. Historically, this was done imperatively with Gradle's legacy, imperative apply script method.
In Flutter 3.16, support was added for applying these plugins with Gradle's declarative plugins {} block (also called the Plugin DSL) and it is now the recommended approach. Since Flutter 3.16, projects generated with flutter create use the Plugin DSL to apply Gradle plugins. Projects created with versions of Flutter prior to 3.16 need to be migrated manually.
Make necessary changes to required files using the documentation here.
.

Hello,
I would like to work on this issue.

Hi @RotRot-pi , thank you for showing interest in contributing to our repository. You are welcome to make changes here. I would recommend forking from 'release' branch since that is the most updated at this point.

Hello, I would like to work on this issue.
Hi @RotRot-pi , thank you for showing interest in contributing to our repository. You are welcome to make changes here. I would recommend forking from 'release' branch since that is the most updated at this point.


Update metrics template to include DEI header

Signed-off-by: Matt Germonprez<EMAIL_ADDRESS>Proposed new header as to how the metric could relate to issues of diversity, equity, and/or inclusion

I think we've been covering this information in the Description or Objective sections.
I wasn't in the discussion and have two questions:

Why add a new sub-heading?
Why under Implementation and not Description?

I would be okay with having this under description. No problem :)
I think a heading would be nice as a way to be explicit about any DEI connection.

Adding it to the template makes the DEI connection available for all metrics.
Are we elevating DEI over other working groups or creating subheadings for Risk, Value, and Evolution as well?

It would be subheadings. Let me provide an example. For the metric time to
first response, how might this connect to DEI? If we look at time to first
response and see that issues or PRs from particular demographics are
significantly longer, this may tell us something about DEI with a project.
On Wed, Jun 30, 2021 at 11:05 AM Georg J.P. Link @.***>
wrote:

Adding it to the template makes the DEI connection available for all
metrics.
Are we elevating DEI over other working groups or creating subheadings for
Risk, Value, and Evolution as well?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/metrics/pull/192#issuecomment-871532781, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFAGUDQMIWWLCT2LYMCSODTVM6DNANCNFSM47SQMBMA
.

--
Mutual of Omaha Distinguished Chair of Information Science & Technology
Professor of Information Systems and Quantitative Analysis
College of Information Science & Technology
University of Nebraska Omaha
CV: https://bit.ly/2kftONr
Vice President
Omaha Parks Foundation
CHAOSS Board Member
https://chaoss.community/
@.***
he / him / his

Thanks for the example. That's what I imagined as well.
Maybe I'm blowing this proposal out of proportions to think that we could have similar (optional) subheadings for Risk, Value, and Evolution -- metrics could inform each area and we might encourage explicit descriptions beyond the WG that created a metric.

In the reflection group, we have been thinking through all metrics and how they could relate to DEI so we could provide baseline text for many of the working groups.

We should definitely be connecting and referencing other metrics in the descriptions but I don't think we need to force the DEI connection if the metrics don't exist. Yes to explicitly referencing related metrics that we have defined.
Regarding the header, I think this is similar to the Data Ethics header discussion. We could have a header called something like "DEI Considerations in Practice"  and we could add a short disclaimer text in the template about DEI in general. If the metric has specific or explicit implications for DEI, metric-specific text can be added following the disclaimer.
I like the placement in implementation but dont like the current header title.

I'm certainly not suggesting that we force anything that doesn't exist.
This is why I had marked it as optional.
What would a disclaimer about DEI look like?
On Thu, Jul 1, 2021 at 9:26 AM Kevin Lumbard @.***>
wrote:

We should definitely be connecting and referencing other metrics in the
descriptions but I don't think we need to force the DEI connection if the
metrics don't exist. Yes to explicitly referencing related metrics that we
have defined.
Regarding the header, I think this is similar to the Data Ethics header
discussion. We could have a header called something like "DEI
Considerations in Practice" and we could add a short disclaimer text in the
template about DEI in general. If the metric has specific or explicit
implications for DEI, metric-specific text can be added following the
disclaimer.
I like the placement in implementation but dont like the current header
title.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/chaoss/metrics/pull/192#issuecomment-872293371, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFAGUD7B7M7DDTU6PZB5D3TVR3KDANCNFSM47SQMBMA
.

--
Mutual of Omaha Distinguished Chair of Information Science & Technology
Professor of Information Systems and Quantitative Analysis
College of Information Science & Technology
University of Nebraska Omaha
CV: https://bit.ly/2kftONr
Vice President
Omaha Parks Foundation
CHAOSS Board Member
https://chaoss.community/
@.***
he / him / his

Just to be clear, I do believe that DEI can and should be reflected on for most things. When I say metrics that don't exist I am referring to explicitly mentioning metrics work that CHAOSS has done.
I think broader DEI generalizations and implications should be included and does need it's own header section but much like an essay or academic paper, I think they belong at the end (and using a similar structure to our proposed data ethics section).
I would go a step further and make the section and disclaimer part of the full template but adding specific implications would be metric specific and optional
I am reflecting on what a disclaimer would look like

How about something like this:
Implications for Diversity, Equity, and Inclusion
Issues related to Diversity, Equity and Inclusion (DEI) have important and broad ranging implications for open source project health. Many metrics based on project activity have explicit and/or implicit connections to DEI. While CHAOSS does not always specify DEI connections in metrics definitions, DEI should be considered in the use of all CHAOSS metrics.
[add metric specific DEI issues (optional)]
Data Ethics
The CHAOSS project recognizes that there are ethical and legal challenges when using the metrics and software provided by the CHAOSS community. Ethical challenges exist around protecting community members and empowering them with their personal information. Legal challenges exist around GDPR and similar laws or regulations that protect personal information of community members. Challenges may arise in the use of metrics that are specific to your context.
[add metric specific data ethics issues (optional)]

In the reflection group, we have been thinking through all metrics and how they could relate to DEI so we could provide baseline text for many of the working groups.

Thank you for the context. Now that I understand that there is a need for a DEI heading, I'm okay with moving forward.
Once someone does similar work for Risk, Value, and Evolution, we can add those headings as well.

I am reflecting on what a disclaimer would look like

Thank you for your draft @klumb!

much like an essay or academic paper, I think they belong at the end

I think we're more creating a resource than an argument. I believe a reader would evaluate whether a metric is important to their use case before reading the implementation.
The nature of the DEI Implications section is that it's very similar to the Description and Objective of a metric, only focused on DEI. Therefore, I think the DEI Implications section belongs within Description or Objective or in their proximity and before Implementation.
I agree that the Data Ethics section should live at the end of a metric, especially since it'll be very similar across metrics.

I suppose I could see it as a third-level header in objectives (but not description).
In that scenario, I think that would align with optional risk, evolution, or value headers as well.
However, @georg I think these are really two different narratives we are talking about. Are we talking about motivation for using DEI metrics or are we talking about Implementation and context?
If it is motivation than it fits with objectives.
If it is how metrics relate to DEI and project context than it is better at the end in the implementation section

Are we talking about motivation for using DEI metrics or are we talking about Implementation and context? If it is motivation than it fits with objectives. If it is how metrics relate to DEI and project context than it is better at the end in the implementation section.

The example @germonprez provided shows how the metric can be interpreted (Objective). It includes a hint about how the data can be looked at to make sense in the DEI context (Implementation). -- In my reading, the sense-making outweighs the metric-creation in this. Maybe we need to see more examples to determine the best location. Or, maybe we're interpreting the sections and the examples differently?

I would also caution against making big lists in these metrics docs of the ways the metric can be used or should be used or how it relates to other focus areas ( i think initiatives, badging and software tooling is where this discussion best fits). These metrics docs should be simple 2 page specification documents. We can't think of all the possible use cases - nor should we. I think our primary purpose for these documents is to create the metric description and provide example implementations. The motivation or objective for use and context are generally on the user. That is why I primarily see it as a disclaimer section in the implementation section. "oh you came here for the contributors metric for some unknown objective, here are some other things you should consider when implementing contributors - DEI and Ethics"

How about, instead of adding a new section, we add guidance to the template that asks authors to think about DEI related objectives for metrics?
Goal: Include DEI related uses like @germonprez originally proposed, but without the bloating of additional (albeit optional) headings.
(Off-topic for this PR) The Data Ethics disclaimer would be great on the /metrics page where it applies to all metrics rather than duplicating the same text 60x across all metrics.

I agree with this, the ethics and DEI disclaimer can live on the website page.
No header for DEI but we should provide guidance in the objectives section (and possibly other sections) about linking content and use cases for DEI and other focus areas

Updated the file to reflect these changes.

LGTM


refactor: webhooks-based approach

Previously, newly created OAuth users weren't registered as Stripe customers, so their subscriptions couldn't be managed.
This change adds a webhook endpoint for Stripe. When a user's subscription is renewed or cancelled, /api/subscription is called, making a corresponding change to the status of the subscription in the customers table in Supabase.
This PR also includes other minor cleanups, fixes and tweaks.
#19 is a prerequisite for this PR.

@thorwebdev, is there any chance you'd be able to have a quick look over this? Is this an improvement in design?

Changes made. PTAL, @thorwebdev.

I think there'd be fewer moving parts if stripe_customer_id and is_subscribed were stored in the user's metadata object rather than a customers table. WDYT?

I'll go ahead and merge for now. We can evolve on these ideas later.

Sorry for the delay. Yes, LGTM 👍 just added one note above regarding using createOrGetCustomer in the middleware.


Update to latest bevy main branch

This is long overdue, and I believe that I will simply just follow Bevy on this branch, unless something on the base branch needs updating as well. It takes too much time to maintain two branches right now.
Anyways, no functional changes here.

... Why is the CI not kicking into gear?


Parameter and Signal classes

In terms of overall design I think that we should have a Parameter class similar to PINT Parameters with priors attached as they do there. We should then have a Signal class, again similar to PINT models which will have a setup method that reads in Pulsar class instances, or at least attributes. This way we can make a collection of signals independent of the pulsars. It is only when the signals are evaluated (or setup) that they interact with the pulsar.
In terms of the model, I think we should have a PulsarModel and a PTAModel where the pulsar model is for single pulsars (i.e., noise, timing model, etc.) and the PTA model is for common signals (i.e., GWs, ephemeris, clocks). We should probably focus on the PulsarModel first as a PTAModel would just be a collection of PulsarModel instances + some methods to compute PTA covariances and such.
For the PulsarModel class I think it should read in the Pulsar object and  a collection of Signal objects similar to the PINT residual class. I haven't fully thought through how likelihoods would be incorporated into this. Of course they should be part of the PulsarModel but maybe that should be sub-classed for different kinds of likelihood (i.e., marginalized vs fully hierarchical).
For now I'm attaching a Milestone to have a basic working version of PulsarModel finished by the beginning of the busy week.

The way PINT does it's parameter class is pretty cool.
As for the priors, I think we need to have a few primitive choices.  We absolutely need a Gaussian prior with the mean and variance or standard deviation defining it and a uniform prior with a two parameter min/max.  We might also want to include a log-Gaussian prior, a sum of Gaussians for multimodal distributions, and an empirical prior that's just the binned output of a previous run.
PINT defines a few special cases then relies on SciPy.stats to handle other cases.  I think we can mimic what they do and add in our special cases.

OK, since starting this issue we have changed the way we are doing things. Originally we were aiming for a PINT-like multiple inheritance signal builder. We have since moved to a class factory structure that allows us to create signal classes on the fly through clever use of meta classes. I really like this structure and we are able to do the standard noise analysis already as seen in my notebook. However there are still several outstanding issues and design choices that we have to make:

Add support for "delay" type signals like wavelets or continuous or burst GWs. This should be pretty easy to do as it is similar to how we are doing ndiag or phivec now.

Address Issue #30. I like this idea but we will still need a T or df in the free-spectral model PSD to get it to s^3. This also messes a bit with the idea that all gaussian process signals have unitless basis functions and amplitudes in seconds. Although the timing model doesn't follow this unless we do an SVD so we need to think about how we are going to put all of this together.

Make parameters more flexible to be able to accept a Parameter into a new Parameter class. For instance, if we want to model Fourier amplitudes with a Gaussian prior with the parameter rho as the variance. The Parameters need to know that rho is also a parameter.

Do we want certain signal methods to be classes themselves. For example, if Fmat were an object then we could easily set it on the fly, that way a DM GP signal would just be a FourierBasisGP with a different Fmat implementation. This is nice but the problem is that we would then need a way to re-name the parameters o the fly as well...

How do we do multiple pulsar signals? Right now we can do this if there are no spatial correlations and the signals do not share an Fmat with any other signals; however, for something like a common red process we need the code to know how to share the Fmat from the red noise instead of creating a new Fmat. We could do this with some kind of registry but I'm not quite sure how to do it. We could also make a multi-pulsar signal class but then we still have the problem of how the common signals know about the individual signal Fmats.

I've been thinking about these things but don't have a good answer to any at the moment. I think until we can answer most of these questions we should just keep sandboxing in the dev branch.
Any ideas?

This has basically been solved in PRs #89 and #54. I'm closing the issue.


Updating deprecated 'bindings' to 'providers'

Fix for #205

lgtm. @mgechev In future, if you wouldn't mind me merging PR's in that are pretty clear and cut like this I can.

@JakePartusch thanks! @NathanWalker sure!


Two error responses on bad HTTP request

Steps to reproduce the problem:

Start mitmdump or mitmproxy
$ echo "GET bad request HTTP/1.1" | nc <IP_ADDRESS> 8080

This would produce two errors in the response:
HTTP/1.1 400 Bad Request
Server: mitmproxy 5.0.0.dev
Connection: close
Content-Length: 290
Content-Type: text/html

                <title>400 Bad Request</title>

400 Bad Request

HttpSyntaxException("Bad HTTP request line: b'GET test me HTTP'",)

        HTTP/1.1 502 Bad Gateway
Server: mitmproxy 5.0.0.dev
Connection: close
Content-Length: 327
Content-Type: text/html

                <title>502 Bad Gateway</title>

502 Bad Gateway

ProtocolException("HTTP protocol error in client request: Bad HTTP request line: b'GET test me HTTP'",)

Expected behaivor - only one error.
Any other comments? What have you tried so far?
Happens due to propagating of ProtocolException from protocol/http.py:292 to server.py:143
System information

Oops. Well I guess two is better than none. Thanks for the report and the easy repro!
refs #1775

We just merged a brand new protocol implementation - if you can repeat the problem with the latest version from git-master, please re-open this issue.


Feature Request - Controller Input Events similar to keyboard

It would be nice to have continuous input events while an Axis or Button is held in, similar to the case of what is done on holding down a key

Yes, very important to know if a button is being held. Not sure if you saw, but I recently added a "pressed" callback parameter, so it's easy to tell what state the button is in. For axes, they don't really have a pressed state, but rather on_controller is called whenever the value of an axis changes.
If you haven't yet, give the controller.c test a try (it's not yet in a release, so you'll have to pull the latest changes from master and make rebuild && make controller. I'd be interested to hear if this meets your needs.


Adapt project to release/versioning guidelines agreed in Commonalities

Adapt project to release/versioning guidelines agreed in Commonalities.
https://github.com/camaraproject/WorkingGroups/pull/123
The next steps are expected to be

PR to merge v0.1.0 changelog into the main branch.
The merge commit from PR will be tagged as v0.1.0, and will get the v0.1.0 release branch.
Merge the dev-v0.2.0 branch into main, so that it contains the latest stable API definition state as agreed (i.e. the ongoing status for API v0.2.0)
Update README.md accordingly.

PR to merge v0.1.0 changelog into the main branch. >> DONE. PRs https://github.com/camaraproject/HomeDevicesQoD/pull/28 (added CHANGELOG) and https://github.com/camaraproject/HomeDevicesQoD/pull/29 (typo fix)
The merge commit from PR will be tagged as v0.1.0, and will get the v0.1.0 release branch. >> DONE https://github.com/camaraproject/HomeDevicesQoD/releases
Merge the dev-v0.2.0 branch into main, so that it contains the latest stable API definition state as agreed. >> DONE. PR https://github.com/camaraproject/HomeDevicesQoD/pull/30
Update README.md accordingly.. >> DONE. PR https://github.com/camaraproject/HomeDevicesQoD/pull/31


Allow specifying runOrder and roleArn for CodePipeline Actions

Hello,
I was reading #265 and #642 to figure out what's the current support for CodePipeline, CodeBuild etc...
I have understood that:

There's no support for specifying the RunOrder property. Is there a specific reason? Seems to be supported at a Stage level (https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-codepipeline/lib/stage.ts#L113) but not passed down from the BuildAction, DeployAction classes (https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-codepipeline-api/lib/build-action.ts#L47)

There's no support for specifying an Action RoleArn, which is essential for Cross-account deployments using a CloudFormation Action. What's missing here is the support for a roleArn property in https://github.com/awslabs/aws-cdk/blob/master/packages/%40aws-cdk/aws-cloudformation/lib/pipeline-actions.ts. (This RoleArn property is different from the one that we can specify inside the configuration object, which is the CloudFormation Execution Role)

I have some time that I could spend on implementing these two points, as they would be really useful for a SAM project I'm porting to CDK. Let me know if I can help and submit a PR.
Thanks! :tada:

Great, thanks for the hint on runOrder!
I'll follow #49 then. I'll be the first one to test new suff there :smile:


inlay-hints for generic arguments

We should offer the ability to show inlay hints for generic arguments, just like we do for function arguments already.
fn foo<'a, T, const C: usize>() {}
foo::<'b, u32, 0>()
// should render as something like
foo::<'a: 'b, T: u32, C: 0>()

Each of these 3 should have a config flag, with only the const generics one being enabled by default I'd say.

I think
foo::<'a = 'b, T = u32, C = 0>()

would be nicer.

Generic parameter names usually aren't that helpful though :grimacing:

Not for lifetimes and type parameters probably, but they can be quite nice for const generics as you just pass them random values sometimes.


activation of networkpolicys for managed EKS addons

Description
Please provide a clear and concise description of the issue you are encountering, and a reproduction of your configuration (see the examples/* directory for references that you can copy+paste and tailor to match your configs if you are unable to copy your exact configuration). The reproduction MUST be executable by running terraform init && terraform apply without any further changes.

[x] ✋ I have searched the open/closed issues and my issue is not listed.

Versions

Module version [Required]: v19.21.0

Terraform version: 1.4.2

Reproduction Code [Required]
cluster_addons = {
    vpc-cni = {
    version        = "v1.15.5-eksbuild.1"
    before_compute = true
    configuration_values = jsonencode({
      env = {
        ENABLE_PREFIX_DELEGATION = "true",
        AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = "true",
        ENI_CONFIG_LABEL_DEF = "topology.kubernetes.io/zone",
        WARM_PREFIX_TARGET = "1",
      },
      VpcCni = {
        properties = {
          enableNetworkPolicy = "true",
          nodeAgent = {
            enablePolicyEventLogs = "true"
          }
        }
      }
    })
  }
 }

Expected behavior
The EKS Addon VPC-CNI is being created and the enableNetworkPolicy and enablePolicyEventLogs value is set to true.
Actual behavior
Error message:  Error: updating EKS Add-On (infrastructure-dev:vpc-cni): operation error EKS: UpdateAddon, https response error StatusCode: 400, RequestID: xxxy-xxxxy-xxxxy, InvalidParameterException: ConfigurationValue provided in request is not supported: Json schema validation failed with error: [$.vpc: is not defined in the schema and the schema does not allow additional properties]
Additional context
I also tried it with the following input:
jsonencode({
      env = {
        ENABLE_PREFIX_DELEGATION = "true",
        AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = "true",
        ENI_CONFIG_LABEL_DEF = "topology.kubernetes.io/zone",
        WARM_PREFIX_TARGET = "1",
      },
      enableNetworkPolicy = "true",
      nodeAgent = {
        enablePolicyEventLogs = "true"
      }
      })

jsonencode({
      env = {
        ENABLE_PREFIX_DELEGATION = "true",
        AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG = "true",
        ENI_CONFIG_LABEL_DEF = "topology.kubernetes.io/zone",
        WARM_PREFIX_TARGET = "1",
      },
      vpc = {
        cni = {
          properties = {
            enableNetworkPolicy = "true",
            nodeAgent = {
              enablePolicyEventLogs = "true"
            }
          }
        }
      }
    })

We have the same issue, need a fix, fast please.

This is not an issue with the module - you will need to follow the directions here https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html

I have now tested it with the following json configuration:
configuration_values = jsonencode({
      enableNetworkPolicy = "true"
    })

But I get the same error:
│ Error: updating EKS Add-On (infrastructure-dev:vpc-cni): operation error EKS: UpdateAddon, https response error StatusCode: 400, RequestID: xxxx-xxxx-xxxx-xxxx, InvalidParameterException: ConfigurationValue provided in request is not supported: Json schema validation failed with error: [$.enableNetworkPolicy: is not defined in the schema and the schema does not allow additional properties]
Does anyone have any idea what it might be?


npm start does not work on Windows: 'cross-env' is not recognized as an internal or external command

What I'm trying to achieve
Run the storefront in Windows 10
Steps to reproduce the problem

Download either the latest release or the current master
Start either Powershell or Cmder
Set an API_URI environment variable with set API_URI=http://localhost:8000/graphql/ (windows)
Run npm install
Run npm start

What I expected to happen
The storefront server to start
What actually happens
λ npm start

><EMAIL_ADDRESS>start C:\Users\Peter\Documents\projects\saleor-storefront
> cross-env NODE_ENV=develop webpack-dev-server --history-api-fallback --watch --port 3000 --mode development --hotOnly

'cross-env' is not recognized as an internal or external command,
operable program or batch file.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>start: `cross-env NODE_ENV=develop webpack-dev-server --history-api-fallback --watch --port 3000 --mode development --hotOnly`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!      C:\Users\Peter\AppData\Roaming\npm-cache\_logs\2019-11-06T15_12_41_972Z-debug.log

System information
Operating system: Windows 10 Pro Version 10.0.18362 Build 18362
Node: v12.8.1
NPM: v10.6.2
Browser: Firefox 70.0.1

Works flawlessly on my machine with exactly same version of node and npm

try removing the node-modules or reinstalling node.js as this seems it might be connected with windows PATH not appended correctly.

use this command npm install -global cross-env


Best way for a custom Themes

Select one ...  (check one with "x")
[ ] bug
[ ] feature request
[x] enhancement

Expected behavior
I would like to find Information in form of a tutorial on how to create a custom theme.
Actual behavior
There is no such information or any kind of reference how to accomplish this.

Note
Are you planning to release such information or is it not planned?

Yes we were planning to add Documentation to the website to outline these steps. I checked github, however, and found we don't yet have an issue open for it.
Thanks for opening one.

Marking this as a duplicate of #268


example templates: describe why the volume mounts (/dev, /lib/firmware) are required

The examples (e.g. ubuntu or windows) should describe why they use the following volume mounts:
    volumes:
      - /dev:/dev
      - /dev/console:/dev/console
      - /lib/firmware:/lib/firmware:ro

Maybe at https://docs.tinkerbell.org/deploying-operating-systems/the-deployment/

Thanks for the feedback @rgl - if you are up for attempting to document this, please let me know. I'd be happy to review a PR that does this.
@thebsdbox - do you have any insight into who/what uses these volume mounts?

@tstromberg, I'm only sure about /dev, which is needed when the action needs to write to a physical device like a disk.


Fix a few more case sensitivity issues

Fix a few more case sensitivity issues for Linux.

I don't see the changes for the empty template

you need a hand with the empty template?


backend error calling simple generic function

Range seems special here, somehow:
    Tuple<Integer,Integer,[]|Range<Integer>> x = [1];
    identity(x);    // compiler bug: union types don't have well-defined equality
    print(type(x)); // same

Fixed.


Update dependencies

Coverage remained the same at 91.628% when pulling db9e19094be577bfbac0a8127820fee9bdfe5f34 on rel_branch into 8a8a42680cce0fc19998e140837e1422d00cf9f3 on master.


chore: Adding cypress tags to all spec files

Description
This PR adds Cypress tags to (almost) all spec files in the cypress/ folder in order to leverage the library cypress-grep. Using tags, a contributor can run specific integration tests for areas of the product that they have modified. Will speed up development and also help improve reliability by reducing the chances of flaky test scenarios being encountered.
The relevant tags for a run can be chosen from app/client/cypress/tags.ts.
TODOs:

[x] Add import statement to all spec files to import tags.ts.
[ ] Remove cypress-tags from the code base in favour of cypress-grep.
[ ] Add tags to remaining spec files. Details of this progress can be found here.
[ ] Modify the CI workflow files for the following:

[ ] ok-to-test
[ ] airgap testing
[ ] Test build and push docker image

Future work (out of scope of this PR):

Sync Github labels with tags.ts to choose the relevant tags automatically.

PR fixes following issue(s)
Fixes # (issue number)
Media
Type of change

Chore (housekeeping or task changes that don't impact user perception)
This change requires a documentation update

How Has This Been Tested?

[x] Manual
[ ] JUnit
[ ] Jest
[x] Cypress

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[x] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test tags=Git

/ok-to-test

/ok-to-test

/ok-to-test

/ci-test-limit

/ok-to-test

/ci-test-limit runId=700214043

/ok-to-test

Letting this PR close because the POC on this branch has been implemented in other branches.


Migration to fuel-core v0.10+ is blocked

While trying to make the switch tofuel-core v0.10` I'm encountering a number of issues.
Context
I'm working on this PR here: https://github.com/FuelLabs/sway/pull/2482
The changeset is fairly large; multiple dependencies are being bumped, opcodes have been removed and added, and a big chunk of the stdlib has been refactored. These have to happen together in 1 PR to make it all work.
Current Issues

Multiple failing stdlib tests using the SDK

The current released SDK version doesn't currently support fuel-core v0.10` so I'm using a patched version of the SDK for the stdlib tests with this patch:
[patch.crates-io]
fuels = { git = "https://github.com/FuelLabs/fuels-rs", branch = "hal3e/bump-fuel-core"}

Among other things, the failing tests indicate that the number of inputs returned by the input_amount() getter == 0.
More discussion here: https://fuellabs.slack.com/archives/C02CX4JVCSJ/p1661344259170089

Apparent bug in the __gtf intrinsic
If I log out the value returned by the intrinsic for a specific field, and then get that same field using raw asm + the gtf opcode I get different values.  For example:

    let type_1 = __gtf::<u8>(0, GTF_TYPE);
    let type_2 = asm(r1, r2: 0) {
        gtf r1 r2 i1;
        r1: u8
    };
    log(type_1); // 10376
    log(type_2); // 0 (the expected value

I've not tested extensively so I don't know if this is the case for more than 1 field.

While trying to produce a minimal repro of the above (WIP can be found on the furnic/gtf-intrinsic-bug branch), I started hitting this new error:

Error: Response errors; TransactionCreateBytecodeWitnessIndex

More discussion here: https://fuellabs.slack.com/archives/C01KBNGSWGJ/p1661440389568419

and finally, some strange behavior around logging values in sway apparently affecting control flow?
More discussion here: https://fuellabs.slack.com/archives/C01KBNGSWGJ/p1661430694033159

@nfurfaro now that we're done with the migration to fuel-core 0.10.1, most of the items above are resolved. Do you mind creating separate descriptive issues of the remaining problems?

All sub-issue in this have been resolved, closing.


Purchase order prepayment functionality

Hi,
Enabling purchase order prepayment functionality functionality is also for Russian localization. But it's not written on list.
When I search for the label "Use prepayment invoice" on Development environment it is only referenced to VendParameters UseVendAdvanceInvoice_RU  field.

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

ID: 53aade45-7eb6-5af4-6c85-a09b26908ff6
Version Independent ID: 53aade45-7eb6-5af4-6c85-a09b26908ff6
Content: What's new or changed in Dynamics 365 Finance 10.0.28 (August 2022) - Finance | Dynamics 365
Content Source: articles/finance/get-started/whats-new-changed-10-0-28.md
Service: dynamics-365-finance
Product: ****
Technology: ****
GitHub Login: @kfend
Microsoft Alias: kfend

Bug 747998 has been logged to address this issue.

@brkyyldz , Could you please be more specific what information in what's new is incorrect or insufficient? What do you expect to be changed? _RU suffix is often used for Eastern Europe shared functionality. Here, in your screenshot the parameter is for Russia, Czech Republic, Hungary, Estonia, Latvia, Lithuania and Poland. The article does not contain information about any countries\regions.

Closing as we haven't received clarification regarding the question. Please reopen if you have more information.


File issues here 🚀

We're opening up GitHub issues as of 1/28!
This is the right place for feature requests and bug reports regarding both the open source and hosted versions of Deviceplane.
Let's build something awesome together!

Y do u get to play both sides Gregarious style input can't just play one side. The trust agent lost a lot of trust, and the opposite side is still remaining getting punished. It's all good tho. I'll figure it all out soon enough.


JWTAuthToken.decodeToken() should return None in Exception

JWTAuthToken.decodeToken() should return None in Exception, not an empty dict. This is because the calling method, JWTAuthBearer.validateToken(), will end up returning an empty dict instead of None, which would allow the request to proceed (which is undesirable).
https://github.com/rcsb/py-rcsb_app_file/blob/8ad98b27aeb4de0fa9996a2b3be7cb74bcbc4150/rcsb/app/file/JWTAuthToken.py#L34

Resolved with https://github.com/rcsb/py-rcsb_app_file/commit/7586c7991172d4dbecd85cfdc0e83e5679b9be4f


Fix early cyclic include issue

When a build is included early (i.e. in pluginManagement {}) the the scoped visibility requires us to walk down the tree of builds which might lead to fully configuring other builds. This in turn can lead to an attempt to configure a build for which configuration has already started. In these cases, starting the configuration anew should just be skipped.
Which just means: You can't apply a pre-compiled script plugin to the build that is defining it.
The (indirect) include cycle could still make sense and thus we skip instead of giving an error.

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.


Adding fixes and limitations to contest view

What's done:

new logo animation
new checks for NotNull field

@akuleshov7 you must've accidentally referenced holder.js in some places, see this thread https://github.com/saveourtool/save-cloud/pull/1121/files#r959234562

@akuleshov7 you must've accidentally referenced holder.js in some places, see this thread https://github.com/saveourtool/save-cloud/pull/1121/files#r959234562

fixed


Non-bots can't talk to non-bots

Hi,
I need starting a conversation but I receive exception 'Non-bots can't talk to non-bots'
          var connectionCLient = new ConnectorClient("appId", "appSecret");

            Message message = new Message();
            message.From = new ChannelAccount
            {
                Name = "appId",
                ChannelId = "emulator",
                Address = "appId",
                Id = "appId",
                IsBot = true
            };
            message.To = new ChannelAccount()
            {

                Name = "User1",
                ChannelId = "emulator",
                Address = "User1",
                Id = "2c1c7fa3",
                IsBot = false
            };
            message.Text = "Hey, what up homey";
            message.Language = "en";

           await connectionCLient.Messages.SendMessageAsync(message);

Contains another way to do this?

You are talking to the production environment instead of the emulator
If you are trying to talk to the emulator you need to do:
var connectionClient = new ConnectorClient(new Uri(http://localhost:9000), new ClientCredentials("appId", "appSecret"));
If you are trying to talk to the prod environment then your channelId is wrong

You are talking to the production environment instead of the emulator
If you are trying to talk to the emulator you need to do:
      var connectionClient = new ConnectorClient(new Uri(http://localhost:9000), new ClientCredentials("appId", "appSecret"));

If you are trying to talk to the prod environment then your channelId is wrong


Julia 1.0 support

I'd love to have this working in 1.0!

I started to port it to 1.0 locally. However, there are one or two places where I'm not sure what to do. Should I make a WIP PR (and hopefully get some Input from you @ararslan ?)

You're welcome to pick up where I left off with those changes; I have no plans to revisit that PR.

Note, btw, that one can currently add this package on 1.0 although it's not working at all.

Fixed by #21.


MSID: 92275 Version: 1 DOI: 2<IP_ADDRESS>0052

"msas": "Medicine"
"msid": "92275"
"preprintDoi": "10.1101/2<IP_ADDRESS>0052"
"Reviewed Preprint posted": "2023-10-24"
"Sent for peer review": "2023-09-14"
"Posted to bioRxiv": "2023-09-29" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>0052v1/")
[PLACE PDF URL HERE WHEN AVAILABLE] See step 7
Step 1. Inform bioRxiv
Who can help: @QueenKraken, @nlisgo, @scottaubrey

[x] Manuscript is in data hub index (https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=92275)

Step 2. Create preview of manuscript
Who can help: @fred-atherden, @nlisgo, @scottaubrey

[ ] Manuscript is available for preview (https://prod--epp.elifesciences.org/preview/92275/v1)

[ ] Trigger import for staging: https://prod--epp.elifesciences.org/import
[ ] Sync data folder with s3://prod-elife-epp-data/data
[ ] Trigger import for staging: https://staging--epp.elifesciences.org/import
[ ] Sync data folder with s3://staging-elife-epp-data/data
[ ] Pull request created to enhanced-preprint-data
[ ] Post link to pull request below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-manuscript
Step 3: Awaiting public reviews and QC
Who can help: Production team

[ ] QC passed or QC not needed

Who can help: Editorial team

[x] Public reviews available on sciety (https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>0052)
[x] Manuscript and editor details at the top of this issue (Supplied by Editorial team)
[ ] Reviews returned by EPP - https://prod--epp.elifesciences.org/api/reviewed-preprints/92275/v1/reviews

Example
"msas": "Genetics and Genomics", "Neuroscience"
"msid": "84628"
"version": "1"
"preprintDoi": "10.1101/2<IP_ADDRESS>4241"
"articleType": "Reviewed Preprint"
"status": "Published from the original preprint after peer review and assessment by eLife."

"Reviewed Preprint posted": "2023-01-02"
"Sent for peer review": "2022-10-28"
"Posted to bioRxiv": "2022-11-21" (link: "Go to bioRxiv": "https://www.biorxiv.org/content/10.1101/2<IP_ADDRESS>4241v1")

Editors:
Reviewing Editor
Michael B Eisen
University of California, Berkeley, United States
Senior Editor
Michael B Eisen
University of California, Berkeley, United States

Step 4: Modify manuscripts.json (no PDF)

[ ] Reviewed preprint is published to EPP (https://elifesciences.org/reviewed-preprints/92275)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[ ] Request that a doi be registered

[ ] Post link to #enhanced-preprint comment below

Pull request: [PLACE LINK TO PULL REQUEST HERE]
#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]

Instructions to modify manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/publish-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/334/files
Once the pull request is merged in it should be available a few minutes later.

Request that a doi
Post the following in #enhanced-preprint:
@Fred can you register a doi for https://elifesciences.org/reviewed-preprints/92275

Step 5: Awaiting search reindex

[ ] Reviewed preprint is avaliable on journal homepage (https://elifesciences.org)

The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.

Additional info
If needed, the jenkins pipeline to reindex search can be triggered sooner.
https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 6: Published! Request PDF generation

[ ] Post the link to the PDF url at the top of the issue

[ ] Post link to #enhanced-preprint comment below

#enhanced-preprint comment thread: [PLACE LINK TO COMMENT HERE]
Post the following to the #enhanced-preprint on slack:
@Ryan Dix-Peek please can you generate a PDF for https://elifesciences.org/reviewed-preprints/92275

Step 7: Introduce PDF to data folder and git repo

[ ] PDF is avaliable at https://github.com/elifesciences/enhanced-preprints-data/raw/master/data/92275/v1/92275-v1.pdf

Detailed instructions: https://github.com/elifesciences/enhanced-preprints-data#add-a-pdf
Step 8: Add PDF url to manuscripts.json

[ ] Reviewed preprint PDF is available for download (https://prod--epp.elifesciences.org/reviewed-preprints/92275)

[ ] Pull request created to enhanced-preprint-client
[ ] Pull request switched to "Ready for review"
[ ] Post link to pull request below

[PLACE LINK TO PULL REQUEST HERE]

Instructions to add PDF url to manuscripts.json

Visit: https://github.com/elifesciences/enhanced-preprints-client/actions/workflows/add-pdf-url-to-manuscript.yaml
Click: Run workflow
Complete the form and click "Run workflow"
A successful run should result in a new pull request at https://github.com/elifesciences/enhanced-preprints-client/pulls
Open the pull request and click the "Ready for review" button to trigger tests
Once the tests pass and you are happy with the changes the PR can be merged

Example pull request: https://github.com/elifesciences/enhanced-preprints-client/pull/397/files
Once the pull request is merged in it should be available a few minutes later.

Step 9: Done!

[ ] Kettle is on!

elocations missing from references


fix test/index.html

There's a missing div in the index.html
which one of the tests is looking for. When I run the test
before, they fail, whereas afterwards, I get a success (in Chrome).

Maybe this is due to a change in QUnit or something. In qunit-git.js, I see:
	if ( tests ) {
		id( "qunit-testresult" ).innerHTML = html;
	}

which is where the error comes from.

Thanks for the heads up! I ended up locking qunit to a specific version to avoid issues in the future and fixed the HTML.


ngf-thumbnail Hyperlink

would ya'll add something for hyperlink so that it populates "href" with the thumbnail link.  I am previewing the uploaded files, but also want to include lightbox, which seems to require a link.   Pretty much all I did for now is check if the element is a hyperlink, and set the href.  There is probably a better solution, but it is late.  Then I can use ngf-thumbnail on the hyperlink.

function linkFileDirective(Upload, $timeout, scope, elem, attr, directiveName, resizeParams, isBackground) {
function constructDataUrl(file) {
var disallowObjectUrl = Upload.attrGetter('ngfNoObjectUrl', attr, scope);
Upload.dataUrl(file, disallowObjectUrl)['finally'](function () {
$timeout(function () {
var src = (disallowObjectUrl ? file.$ngfDataUrl : file.$ngfBlobUrl) || file.$ngfDataUrl;
if (isBackground) {
elem.css('background-image', 'url('' + (src || '') + '')');
} else {
if (elem.is("a")) {
elem.attr('href', src)
}
else {
elem.attr('src', src);
}
elem.attr('src', src);
}
if (src) {
elem.removeClass('ng-hide');
} else {
elem.addClass('ng-hide');
}
});
});
}

You can use Upload.dataUrl(file).then() for now to get the url of the file and set it to a model for href.

I suppose that would work, but what I failed to mention is that I am updating all the files at once on submit button, so the success event won't be fired until after it has returned from that call, but by then I will have moved to another page.  The preview and lightbox is for reviewing the images before they have been submitted.  I also looked at the progress event, but the dataurl looks to be the base64 representation.

You can use Upload.dataUrl before uploading the file, right after file selection or on model change.

Thanks!  I used ng-href and grabbed the ngfDataUrl.  I was also mistaken that the lightbox didn't do base64 rep., but I guess that was my fault and bad copy/paste when testing it.  Thanks for the help and advice.

$ngfDataUrl is just for internal use and might be removed in later versions.

You can use ngfDataUrl filter though.

The way to go about this is to use the filter  <a href="files | ngfDataUrl">...


Cleanup Optimizer

I wonder if FlatList should be removed completely!?

ready for review

looks good to me.

One timeout failure on AppVeyor, unrelated to PR:
[00:45:27] 1) Failed : FSharp.Core.Unittests.FSharp_Core.Microsoft_FSharp_Control.AsyncModule.AwaitWaitHandle.Timeout
[00:45:27]   Delta is too big 969
[00:45:27]   Expected: True
[00:45:27]   But was:  False

This looks OK
Re FlatList - yes, it's just alias for List.  The belief once upon-a-time was that the pervasive use of linked lists (List) instead of flatter data structures (Array, ImmutableArray etc.) was hurting.  So we added an alias FlatList for certain use of Lists where it felt there would be a perf gain for switching to a flat data structure.  However when switching to a flat data structure we didn't see any real perf gains.  However we left FlatList in just in case we wanted to try again. So it's still unclear if we should rip it out for simplicity, or try to resurrect the experiment.  I'm OK with ripping it out at this stage I suppose since the experiment has been dormant so long.


Bad quality of medium size images generated for organization profiles

For instance, the image uploaded for https://landportal.org/organization/columbia-center-sustainable-investment has a quite good resolution, but the medium size image generated for the organization profile has very poor quality

review image styles settings
check if this happens with ANY or some image types.
do we need additional libraries to improve image resizing quality?


negative values with irate for CPU usage

Hi All,
I use this query to get the CPU utilization:
100 - (irate(node_cpu{mode="idle", instance=~"Web:9100"}[5m])) * 100
With this query, I got negative values in my graphs

scrape_interval for this metric is:   15s
Please find below the raw values and timestamps around the artifact:
cpu_minus.zip
I'm using Prometheus version: 2.0.0-rc.1
why is this happening?

It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.


Refactor streams support

Currently an operator must list all streams config files in values.yaml like this:
streams: enabled
  streamsConfigMap: benthos-streams
  streamsConfigFilenames:
    - hello.yaml
    - aaaaa.yaml

Benthos has support for globs in filenames specified after the streams subcommand committed, so the next tagged build should include the changes.  Refactor the chart afterwards so that the filenames will be pulled in automatically.

Resolved by #10. streamsConfigFilenames has been removed for 0.4.0.


Update LAB[PL-200]_M00L00_Validate_Lab_Environment.md

Fixed > Note indent syntax.  The [!NOTE] is Skillable specific while the > Note: syntax is generic markdown and works on GitHub pages etc.
Module: 00
Lab/Demo: 00
Fixes # .
Changes proposed in this pull request:

Oops, can we try this way please @chandlersyal the [!NOTE] syntax is Skillable specific, and I've been advised it is now preferred to use generic syntax wherever possible.


Device parameter is not processed in TensorFlow tutorials

Bug description
Interactive API Task Interface provides users with device parameter, but we do not use it in TensorFlow tutorials.
To Reproduce
Prerequisites:
Both types of CPU and CUDA devices working for your version of TensorFlow.
You can check this condition with: tf.config.get_physical_devices().
Steps to reproduce the behavior:

Open any TensorFlow Interactive API tutorial (e.g., openfl-tutorials/interactive_api/TensorFlow_MNIST)
Open a notebook in workspace folder.
Run all cells.
All tasks execution device is based on the TensorFlow device selection policy.

Expected behavior
Execution device is device from task parameters.
Environment

OS: Ubuntu 18.04
Python: 3.8
TensorFlow: 2.7
CUDA: 11.2

Hi my name is Aarushi Soni . I want to contribute to this issue . Is this issue still open ? I am first time contributor . Please guide me through this process.

OpenFL_Team3 will attempt

Closing as the Interactive API has been deprecated.


Nodepools created with spot instances fail to register in cluster.

The new method of getting the KUBE_AWS_STACK_NAME from aws:cloudformation:stack-name tag  doesn't work with Spot Instances because these instances are not tagged by Cloudformation.
cfn-etcd-environment.service fails to start without KUBE_AWS_STACK_NAME value in /etc/environment

@camilb Thanks for the good catch 👍
As we need to tag spot instances manually, relying on aws:cloudformation:stack-name wouldn't be an universal option as it does result in the chicken-and-the-egg problem.
We need to somehow pass the stack name from {"Ref":"AWS::StackName"} to the userdata...

I have considered to use multi-part cloud-config so that we can use the first part to populate the env var with the stack name as the value. However, unfortunately, coreos-cloudinit doesn't support it.
https://github.com/coreos/bugs/issues/912

A possible solution(which doesn't need to revert the recent improvements on userdata made by @redbaron) came up in my mind is to utilizing ignition with:
"UserData": {{ .UserDataWorker.Parts.instance.Base64 true | checkSizeLessThan 16384 | quote }}

modified to:
"UserData": {{ .UserDataWorker.Parts.instance.IgnitionConfigRef }}

where the IgnitionConfig func is:
func quoteForCfn(jsonLike string) string {
  return strings.Replace(strings.Replace(jsonLike, "\n", "\\n", -1), ```"```, ```\"```, -1)
}

func (self UserDataPart) IgnitionConfigRef() string {
  splits := []string{
    quoteForCfn(```{
  "ignition": {
    "version": "2.0.0"
  },
  "storage": {
    "files": [
      {
        "filesystem": "root",
        "path": "/var/run/coreos/kube-aws-stack-name",
        "contents": {
          "source": "data:,```),
    base64StackNameRef,
    quoteForCfn(fmt.Sprintf(```"
        }
      },
      {
        "filesystem": "root",
        "path": "/opt/bin/bootstrap-worker-node",
        "contents": {
          "source": "data:,%s"
        }
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "name": "bootstrap-worker-node",
        "enable": true,
        "contents": "#!/bin/bash -xe\n/opt/bin/bootstrap-worker-node"
      }
    ]
  }
}```,
  self.Base64(false))

  // TODO should emit a validation error when sum(sizeOf(split in splits)) > 16384

  return fmt.Sprintf(```{"Fn::Join": ["", [%s]]}```, strings.Join(splits, ","))
}

@redbaron Could I have your comments on this?

that manual escaping looks crufty, encoding given string into a json string should be enough.
config data in kube-aws binary goes against flexibility of having all configs in a text form
Stack name passing can be achieved in a much simpler way, just just instance userdata to CF Json function calls

{ "Fn::Base64": [ {"Fn::Join": [ "",
"!#/bin/bash\n"
"echo ", {"Ref": "AWS::Stack::Name" }
....

and then
"UserData": {{ .UserDataWorker.Parts.instance.Template | quote }}

in your stack config json.
You'll lose  checkSizeLessThan, but that is not  a big deal. You might also want to introduce validateJSON function for this instance userdata part to be a bit more robust.

@redbaron Thanks 👍

I imagined that we'd better have something like CloudConfigRef which "injects" {"Ref": "AWS::Stack::Name" } to the instance part of a cloud-config. Would you agree?
The only problem in my proposed solution with ignition is that it is just too much for the job for now, right? (The simpler way you've suggested still require us to embed a very small part of cloud-config to the kube-aws binary?

Fix I propose can be implemented even by an end user in his userdata/cloud-config-worker and sta-template.json

@redbaron Thanks!
I thought so too at first but wouldn't "UserData": {{ .UserDataWorker.Parts.instance.Template | quote }} you've suggested transforms {"Ref": "AWS::Stack::Name" } to a plain string in a json string without resulting to an actual stack name?

@camilb I've submitted the PR #732 to demonstrate a possible fix for this. I don't know whether we're going to merge it as-is - but could you verify that the change introduced in the PR fix your problem anyway?

Thanks @mumoshu , I'll test it today and let you know of any issue.

@mumoshu I can confirm that #732  works fine. Thanks!

@mumoshu
sorry, was in  a rush, yes you are right, quote isn't what we want, there, so it would be:
"UserData": {{ .UserDataWorker.Parts.instance.Template  }}

@redbaron I've tried my best to make an implementation of your suggestion in #732 👍 Would you mind reviewing it?

A less elegant method, but that also works:
echo KUBE_AWS_STACK_NAME=$(curl http://<IP_ADDRESS>/latest/meta-data/iam/info | jq .InstanceProfileArn | cut -d ":" -f 6 | cut -d "/" -f 2 | cut -d "-" -f 1-3) >> /etc/environment

My take on it is in #735, code changes are purely to make it more ergonomic and avoid manually escaping all strings in a script.
I didn't try to create cluster with it though, we don't use SpotFleet

@redbaron I'll test it

Just finished to create a cluster based on #735 with  SpotFleet. Works fine.


As an Inventory Manager, I need to be able to transfer inventory from one warehouse/location to another so that stock levels can be balanced and meet demand across different locations.

Test Case Link: Test Case #26


Type inference for query responses with multiple entities

If a query response contains multiple entity types, is there any way to infer the type of each returned item? Things work perfectly if a string constant is added with the entity name:
const FooEntity = new Entity({
    name: 'Foo',
    table: FooOrBarTable,
    schema: schema({
        pk: attribute.string().key(),
        sk: attribute.string().key(),
        entityType: attribute.string().const('Foo'),
        someValue: attribute.number()
    })
});

const BarEntity = new Entity({
    name: 'Bar',
    table: FooOrBarTable,
    schema: schema({
        pk: attribute.string().key(),
        sk: attribute.string().key(),
        entityType: attribute.string().const('Bar'),
        anotherValue: attribute.string()
    })
});

interface TypedItemList {
    foos: FormattedItem<typeof FooEntity>[];
    bars: FormattedItem<typeof BarEntity>[];
}

function needANumber(n: number) {}
function needAString(s: string) {}

async function listItems(pk: string): Promise<TypedItemList> {
    const { Items } = await FooOrBarTable
        .build(QueryCommand)
        .entities(FooEntity, BarEntity)
        .query({ partition: pk })
        .send()
    ;

    const result: TypedItemList = {
        foos: [],
        bars: []
    };

    for (const item of (Items ?? [])) {
        if (item.entityType === 'Foo') {
            // Compiler is happy, correct entity type is inferred
            needANumber(item.someValue);
            result.foos.push(item);
        }
        else {
            // Also works
            needAString(item.anotherValue);
            result.bars.push(item);
        }

        // Won't compile, entity is hidden
        if (item.entity === 'Foo') {}
    }

    return result;
}

So passing the saved entity attribute through in responses would be enough, but it seems like it's hardcoded to hidden. Is there a way to set hidden to false for that attribute or another way to get at its value?

Hello @mjahns ! You are right, the entity attribute is hidden and this cannot be modified for now.
I see your point though, so I'll add a entityAttributeHidden option (true by defalut) in the next releases to resolve this issue 👍

@mjahns entityAttributeHidden is now available in Entity constructor to display the entity attribute while formatting. Check the docs here: https://www.dynamodbtoolbox.com/docs/entities/internal-attributes#entity

Awesome thanks, updated and it's working perfectly. Makes things a lot easier!


Incorrect Dimension Order for Image Poisoning Perturbations

Describe the bug
For all functions in adversarial-robustness-toolbox/blob/main/art/attacks/poisoning/perturbations/image_perturbations.py, the height and width dimensions are swapped. For Numpy, TensorFlow, and PyTorch the dimension order is height x width. However, for Pillow images, the order is width x height.
This causes a bug when using the insert_image function in ART as this will cause the height and width to be swapped. Since examples have only used square images, this bug was never found before.
To Reproduce
When attempting to insert an image trigger for non-square images using the insert_image function, the height and width become flipped. Here is a simple example that can be run from the console.
>>> import numpy as np
>>> from art.attacks.poisoning.perturbations import insert_image
>>> x1 = np.random.rand(100, 50, 3)
>>> x2 = insert_image(x, backdoor_path='./utils/data/backdoors/alert.png', size=(8, 8), mode='RGB')
>>> x1.shape
(100, 50, 3)
>>> x2.shape
(50, 100, 3)

Additionally, here is further proof that Pillow uses a different dimension order.
>>> import numpy as np
>>> from PIL import Image
>>> x = Image.new("RGB", (100, 50))
>>> x.size
(100, 50)
>>> np.asarray(x).shape
(50, 100, 3)

Expected behavior
In adversarial-robustness-toolbox/blob/main/art/attacks/poisoning/perturbations/image_perturbations.py, all instances of height and width should be swapped to the correct numpy order.
Screenshots
N/A
System information (please complete the following information):

OS
Python version
ART version or commit number
TensorFlow / Keras / PyTorch / MXNet version

Hi @f4str Thank you for catching and fixing this bug!


added surrogate key to incremental logic and changelog updates

Are you a current Fivetran customer?

Fivetran created PR
What change(s) does this PR introduce?

This PR introduces a surrogate key to the unique_key incremental logic in the int_klaviyo__event_attribution and klaviyo__events models. This is needed as the previous event_id was not truly unique with the addition of the source_relation field in the source.
This PR is dependent on the merge and release of the dbt_klaviyo_source release/v0.4.0 PR
Does this PR introduce a breaking change?

[X] Yes (please provide breaking change details below.)
[ ] No  (please provide explanation how the change is non breaking below.)

Since this is making a change to the incremental logic, it will require a dbt run --full-refresh after installing the new version to capture the changes. As such, it will be a breaking change.
Is this PR in response to a previously created Issue

[X] Yes, Issue #13
[ ] No

How did you test the PR changes?

[X] CircleCi
[ ] Other (please provide additional testing details below)

Select which warehouse(s) were used to test the PR

[X] BigQuery
[X] Redshift
[X] Snowflake
[X] Postgres
[ ] Databricks
[ ] Other (provide details below)

Provide an emoji that best describes your current mood

🥘
Feedback
We are so excited you decided to contribute to the Fivetran community dbt package! We continue to work to improve the packages and would greatly appreciate your feedback on our existing dbt packages or what you'd like to see next.

Do we want to update the ymls with unique_event_id? In klaviyo.yml since klaviyo__events has this field now, same with int_klaviyo.yml under int_klaviyo__event_attribution

Great call out! Just updated.


Whole-program-wrapping macros are awkward to use

The eslisp-camelify macro makes sense to wrap around your whole program if you like to use this-kind-of-variable-names and have them converted to thisKindOfVariableNames. Likewise, eslisp-propertify lets you use a.b.1 as shorthand for property access, instead of (. a b 1).
Such global transform macros could in the future include e.g. accessor function sugar for turning (.name) into (function (x) (return (. x name))) like LiveScript's accessor shorthand, et cetera.
However, using them is currently cumbersome, requiring e.g. piping eslisp files through sed as a build step, wrapping the entire contents in appropriate macro calls before passing to eslc, which feels like a hack.

Ideas:

Document and recommend the sed hack.  Dirty, but then it's the users' problem. ;)

Provide a --wrap compiler flag. Something like—
eslc --wrap="eslisp-propertify,eslisp-camelify" < index.esl > index.js

Write a separate module/program eslisp-wrap which job is to wrap its input file in a list of macros.  This separates concerns better, but is a tiny bit less convenient.

Serious problem with keeping this separate in an eslisp-wrap program or sed script is that they can only do string concatenation, without regard for what the code actually means. Since an outer macro's aggressive transform can also transform the macro definitions and calls that it wraps, the abstraction would leak.
For example, assume eslisp-wrap has been instructed to wrap some program code in a call to module x and module y:
(macro $asdf1 (require ("x"))
(macro $asdf1
 (macro $asdf2 (require ("y"))
 (macro $asdf2
 ... input program code here ...
 )
)

Say $asdf1 (module x) transforms all identifiers in its arguments to all-caps. This means the inner macro ($asdf2) is transformed too, and no longer recognised as a macro, meaning it's compiled into a function call. The result is a confusing disaster.

In contrast, eslc given a --wrap flag could be smart about it: Compile each macro module in isolation, then pass the code through each of them.

Option ② (the compiler flag) is in! It ended up being more descriptively called --transform/-t (not --wrap) and being specifiable multiple times instead of taking a comma-separated list.
Here's how much cleaner this is than a sed-hack: https://github.com/anko/eslisp-fancy-function/commit/37e51ca8cd1ec36bd5c7942a902038fab1130184


Issue with enabling inlay hints

What I expect to happen:
I set up the plugin with the following commands:
require("typescript-tools").setup({
    settings = {
        -- spawn additional tsserver instance to calculate diagnostics on it
        separate_diagnostic_server = true,
        -- "change"|"insert_leave" determine when the client asks the server about diagnostic
        publish_diagnostic_on = "change",
        tsserver_file_preferences = {
            includeInlayParameterNameHints = "all",
            includeInlayEnumMemberValueHints = true,
            includeInlayFunctionLikeReturnTypeHints = true,
            includeInlayFunctionParameterTypeHints = true,
            includeInlayPropertyDeclarationTypeHints = true,
            includeInlayVariableTypeHints = true
        },
        tsserver_format_options = {
            allowIncompleteCompletions = false,
            allowRenameOfImportPath = false
        }
    }
})

and there should be inlay hints according to the docs. I also checked the source code to see if I have all inlay preferences enabled.
Instead I get the following:

Also I would like to add, that the code actions work just fine.
Setup:
I use lsp-zero as a base for my lsp configuration.
Here is also the link for my current config: https://github.com/raphaelluethy/nvim
Do you have any idea what the issue could be?

This enable server capability to support for inlay hints in  tsserver but client support is up to you - if you on stable neovim you need additional plugin to show inlay hints or in nightly you can use build in implementation.

ah okay, I missunderstood, thank you very much!

@pmizio neovim recently added support for inlay hints in neovim 0.10. However, I still don't seem to see any inlay hints showing up (despite having the README configuration copied letter for letter). Should these features work on the new neovim release (granted, it has only been a few days since)?

@barrett-ruth Yes inlay hints from nightly work but you need in plugin config:
        tsserver_file_preferences = {
            includeInlayParameterNameHints = "all",
            includeInlayEnumMemberValueHints = true,
            includeInlayFunctionLikeReturnTypeHints = true,
            includeInlayFunctionParameterTypeHints = true,
            includeInlayPropertyDeclarationTypeHints = true,
            includeInlayVariableTypeHints = true
        },

For now I wont add docs for it because it isn't in stable anyway.

@barrett-ruth Yes inlay hints from nightly work but you need in plugin config:
        tsserver_file_preferences = {
            includeInlayParameterNameHints = "all",
            includeInlayEnumMemberValueHints = true,
            includeInlayFunctionLikeReturnTypeHints = true,
            includeInlayFunctionParameterTypeHints = true,
            includeInlayPropertyDeclarationTypeHints = true,
            includeInlayVariableTypeHints = true
        },

For now I wont add docs for it because it isn't in stable anyway.

This is how I got it to work for now 👍

This still does not work for me.

@pmizio I'm able to get inline hints to work when I use lspconfig directly with tsserver but not when I use this plugin. Any guidance on what to do?

To enable inlay hints, vim.lsp.inlay_hint.enable(true) should exist within the on_attach function.
My lazy.nvim configuration:
{
  'pmizio/typescript-tools.nvim',
  dependencies = { 'nvim-lua/plenary.nvim', 'neovim/nvim-lspconfig' },
  opts = {
    expose_as_code_action = 'all',
    settings = {
      tsserver_file_preferences = {
        includeInlayParameterNameHints = 'literals',
        includeInlayParameterNameHintsWhenArgumentMatchesName = false,
        includeInlayFunctionParameterTypeHints = true,
        includeInlayVariableTypeHints = false,
        includeInlayVariableTypeHintsWhenTypeMatchesName = false,
        includeInlayPropertyDeclarationTypeHints = true,
        includeInlayFunctionLikeReturnTypeHints = false,
        includeInlayEnumMemberValueHints = true,
      },
    },
    on_attach = function(client, bufnr)
      -- stylua: ignore
      if client.server_capabilities.inlayHintProvider then vim.lsp.inlay_hint.enable(true) end
      -- stylua: ignore
      local function map(mode, lhs, rhs, desc) vim.keymap.set(mode, lhs, rhs, { desc = desc, buffer = bufnr }) end
      map('n', '<Leader>ci', '<Cmd>TSToolsAddMissingImports<CR>', 'Add Missing Imports')
      map('n', '<Leader>co', '<Cmd>TSToolsOrganizeImports<CR>', 'Organize Imports')
      map('n', '<Leader>cR', '<Cmd>TSToolsFileReferences<CR>', 'File References')
    end,
  },
}


Documentation uses payload when it should be claim

The JWT spec calls this "payload" a "claim". You're documentation should use this convention to not confuse the subject.

Correct, the body consists of one or multiple claims.
However, since - beside the registered claim names - you can add any claim (JSON property) you want, it does make sense to name it 'payload'.
Most JWT packages I've used name it 'payload', some use 'claims'. It's up for discussion.


First Hotbar is copied if used with Norcs Custom hotbar and no token selected.

If used with Norcs Custom Hotbar and no token selected, the custom hotbar is a copy of the first hotbar. There seesm to be no way to change it then as removing macros from the custom hotbar will instead remove them from the core hotbar.

Thanks for reporting this issue! Do you have the option enabled to use Norc's Custom Hotbar with Token Hotbar? Or is it also removing macro's from the regular hotbar when this option is not enabled?

I had this same problem! I was able to find a roundabout fix for it, though.
Create a new macro - even one with nothing in it - and drag it from the Macro Library onto the token hotbar, replacing the 'stuck' macros. I did this for each macro that was stuck on the custom hotbar when I had no token selected. Once all the stuck macros have been replaced with the new blank macro, go to the Macro Library and delete that macro. This should clear the stuck macros from the token hotbar.


Customize smtp traffic log format

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
pass a format string and logging with the format.
Describe alternatives you've considered
fork and chang the log message in forked repo
Additional context
No response

Hi @Dennis-Zhang-SH, thanks for opening this issue. Can you elaborate a bit more what you are actually requesting? The standard logger we ship with go-mail does support formatted logging already - in fact it's even required by the interface that Debugf, Infof, Warnf and Errorf are satisfied.

Hi @Dennis-Zhang-SH, thanks for opening this issue. Can you elaborate a bit more what you are actually requesting? The standard logger we ship with go-mail does support formatted logging already - in fact it's even required by the interface that Debugf, Infof, Warnf and Errorf are satisfied.

Hi I mean the hard coded "C <-- S:" and "C --> S:", it would be nice to have self defined format, say "Sent: msg" and "Reply (code): msg"

Thanks for clarifying. I'll see what would be the best approach for this

So I see two possible options here:

We can add a new option to the Client for you to provide the In- and Out logging strings. But that would require adding new fields to the Client and smtp.Client structs, which might be not favourable.
Since this is very much an edge case, we can check the ENV variables for the in- and out strings directly in the method in the smtp client and if set, we could override the defaults. This would be the most favourable option but might not work in every edge case, neither.

What are your thoughts?

So I see two possible options here:

We can add a new option to the Client for you to provide the In- and Out logging strings. But that would require adding new fields to the Client and smtp.Client structs, which might be not favourable.
Since this is very much an edge case, we can check the ENV variables for the in- and out strings directly in the method in the smtp client and if set, we could override the defaults. This would be the most favourable option but might not work in every edge case, neither.

What are your thoughts?

I think maybe providing the raw logs would be better? people can manipulate the logs by themselves.

That's an option, but the communication is two-way. How would we differentiate between message sent by the client or by the server without making the logging interface much more complex?

That's an option, but the communication is two-way. How would we differentiate between message sent by the client or by the server without making the logging interface much more complex?

something like this?
type Logs struct {
	Recv []RecvLog
	Sent []string
}

type RecvLog struct {
	Code int
	Msg  string
}

func (l *Logs) Debug() {
	for _, m := l.Recv {
		logger.Debug("s ---> c", m)
	}
}

then you can setup a new Debug func to overwrite the default debug func.

I've proposed a change to the log.Logger interface as well as to the Stdlog logger. It breaks the old interface but allows the logging interface to be much more flexible and should allow you to use your own formatting. Feedback is welcome.
If we accept this change, we need to mark it as breaking, even though I don't think that many users are actually using their own logging interface in their implementations.

the default log format should be "C ---> S:" and it should be able to overwrite, but now it's like "C ---> S: myformat", if you don't mind,  I can work on this later and try to find a better way to solve this, and probably won't be a breanking change,

The default format for the StdLoggerwas not changed. It was C --> S: <format> <message> before this change. It was only moved from the smtp package to the log package. For you to not use the C --> S syntax, all you need to do is implement your own Debugf() function that satisfies the log.Logger interface and then you can completely skip the C --> S part or format it in the way you want.

The default format for the StdLoggerwas not changed. It was C --> S: <format> <message> before this change. It was only moved from the smtp package to the log package. For you to not use the C --> S syntax, all you need to do is implement your own Debugf() function that satisfies the log.Logger interface and then you can completely skip the C --> S part or format it in the way you want.

Oh okay, that should fix it, thanks for your work and appologize for my late reply.

Are you ok with the proposal? In that case i would merge it to main then.

Are you ok with the proposal? In that case i would merge it to main then.

Yes I am fine with it, you can close this issue after merged.


[VM] speed up BER decoding

The general case will only decode a single byte. Delay the right shift until we actually need it.

Also: #1500 :partying_face:


Missing Fix For #3120

Discussion and suggestion as in here: https://www.elkarte.net/community/index.php?topic=5091.0
But as noted, this was left out / missed in 1.1.3 both patch and install packages.
So, I am PRing this again.

Please reject and delete this PR.


[WIP] More channels! Refactor Session!

This refactors the IOPubSession into just being a Session, since we already have the heartbeat channel. Additionally, I added in the shell channel. Haven't been able to send anything across it though. I'm only getting a response with the delimiter (<IDS|MSG>).

Closing, bringing this in through libraries upstream.


Autorest Regen Preview to 3.0.0-alpha.20230712.2 by Dapeng Zhang from refs/pull/3373/merge

Triggered from https://github.com/Azure/autorest.csharp/pull/3373

API change check
API changes are not detected in this pull request.

Close in favor of https://github.com/Azure/azure-sdk-for-net/pull/37768


Facing Issue While Running

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':flutter_fgbg:parseDebugLocalResources'.
> Could not resolve all files for configuration ':flutter_fgbg:androidApis'.
   > Failed to transform android.jar to match attributes {artifactType=android-platform-attr, org.gradle.libraryelements=jar, org.gradle.usage=java-runtime}.
      > Execution failed for PlatformAttrTransform: C:\Users\prate\AppData\Local\Android\sdk\platforms\android-28\android.jar.
         > C:\Users\prate\AppData\Local\Android\sdk\platforms\android-28\android.jar

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s
Running Gradle task 'assembleDebug'...                              3.0s
Exception: Gradle task assembleDebug failed with exit code 1

can anyone help with it ? or resolve


[libredwg] Add new port

Fixes https://github.com/microsoft/vcpkg/issues/29980

[x] Changes comply with the maintainer guide
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

@Adela0814 requires approval

Because some formating changes, and requre reiview agiain. @Adela0814