test(dtslint): add timeoutWith

Description:
This PR adds dtslint tests for timeoutWith.
Related issue (if exists): #4093

Pull Request Test Coverage Report for Build 7341

0 of 0   changed or added relevant lines in 0 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage increased (+0.2%) to 96.967%

Files with Coverage Reduction
New Missed Lines
%

src/internal/observable/fromPromise.ts
1
87.5%

src/internal/observable/fromIterable.ts
2
95.24%

src/internal/observable/fromObservable.ts
2
83.33%

Totals

Change from base Build 7318:
0.2%

Covered Lines:
5786

Relevant Lines:
5967

💛  - Coveralls


Rails/SkipsModelValidations detection not limited to ActiveRecord::Persistence

When naming any method upsert and calling it, rubocop-rails throws a warning. It's not limited to ActiveRecord::Base descendants.
Example:
class UpsertWorker
   def perform
     upsert('asdf') # ← RuboCop: Avoid using `upsert` because it skips validations. [Rails/SkipsModelValidations]
   end

   def upsert(something)
     puts something
   end
end

Expected behavior
rubocop-rails should validate that the the receiving class actually includes ActiveRecord::Persistence and allow arbitrary methods to be called upsert.
Actual behavior
It is assumes that every method named upsert is from ActiveRecord::Persistence
RuboCop version
1.26.1 (using Parser <IP_ADDRESS>, rubocop-ast 1.16.0, running on ruby 2.7.0 x86_64-darwin20)
  - rubocop-performance 1.8.1
  - rubocop-rails 2.14.2

rubocop-rails should validate that the the receiving class actually includes ActiveRecord::Persistence

That's the limitation of the static code analysis: you can analyze only the source code (as strings, AST etc) and can not do introspection of the code.
The improvements that can made in this case:

check that outside of model classes the upsert has a required caller
allow the caller to be nil only inside of model classes (and probably only inside class-level methods)

Got bitten by that today when using Appsignal:
Appsignal.increment_counter(...)

It would be nice to have a allow list of classes so I could skip the Appsignal class from that cop.


Test on sprockets-rails 2.2 and 3.x

More sprockets-rails test coverage.
/cc @rafaelfranca

Sometimes messed up here with asset-url helpers not being loaded. Still not sure why.

Ah, we're now generating digests in dev by default, so the test regexp is just busted.

:shipit:


Offline maps : Open relevant location when opened.

Describe the bug
On clicking of the offline maps, the downloaded offline map should open the map area, that was focused while the “save map for offline use” action is performed

Screen shot : Screen shots: Actual: Over zoomed to a user’s location, expected: Zoom to right level at the right area.

fixed with commit 93e552727f8f82ef213ff360f949c09e0acdf6be


IGNITE-7108 Apache Ignite 2.5 RPM and DEB packages

added package.sh script for automation DEB and RPM packages build
added DEB package build
updated RPM package version to 2.5.0
refactored RPM files layout for unification of build process
improved packages layout hierarchy

The ticket is resolved. Closing PR


config_dev_system: Add 7-Zip admin permission requirement.

The toolchain includes symbolic links. On Windows, this requires either a user with permission added or the ability to run programs as an administrator. Otherwise, the symbolic links are not created and the toolchain cannot find some utilities required for compilation.
AB#2377643

v2

Use .. note:: decorator.


Restrict event description length

If event descriptions are too long, they will cause us to hit slack's message limit
Truncate all message names and descriptions to 500 characters, adding "..." if it's too long

I did this already :stuck_out_tongue:


Shared: Slim 908 req without retry

SonarQube analysis reported 17 issues

 10 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L36: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L50: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L62: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L76: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L36: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L50: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 17 issues

 10 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L36: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L50: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L62: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L76: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L36: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L50: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L35: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L49: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L61: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L75: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L35: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L49: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L35: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L49: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L61: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L75: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L35: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L49: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L35: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L49: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L61: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L75: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L35: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L49: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L35: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L49: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L61: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L75: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L35: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L49: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L35: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L49: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L61: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L75: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L35: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L49: Do not forget to remove this deprecated code someday.

All is well.

SonarQube analysis reported 16 issues

 9 major
 7 info

Watch the comments in this conversation to review them.
Top 10 extra issues
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 ProtocolRequestMessage.java#L33: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L46: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L34: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L48: Constructor has 9 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L60: Constructor has 10 parameters, which is greater than 7 authorized.
 ProtocolResponseMessage.java#L74: Constructor has 11 parameters, which is greater than 7 authorized.
 ProtocolRequestMessage.java#L33: Do not forget to remove this deprecated code someday.
 ProtocolRequestMessage.java#L46: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L34: Do not forget to remove this deprecated code someday.
 ProtocolResponseMessage.java#L48: Do not forget to remove this deprecated code someday.

All is well.


Marketing the Beta App

The city's Information Department wanted to know if we were ready to market the Trolley Tracker beta app via the city's social media outlets.  We've already posted a short article on the Greenlink website (http://www.ridegreenlink.com/CivicAlerts.aspx?AID=392) and I saw that the Greenville News prepared a story, as well.
Anyway, given the spotty signals over the last few weekends I was wondering if you guys wanted to hold off on any additional marketing until we get to the root of the problem.  Let me know what you think.

I would ordinarily say "move forward", but based on the problem level over the weekend, I would say that it's not useful to publicize it at this time.
I would like to meet to explore ways of moving forward with the integrated tablet Internet solution (Wednesday?).

I'm free in the morning on Wednesday (until 11AM) but will be tied up after that.

And just a heads up....I mentioned the internet issues to our IT department and here's the response I received....

Those units aren't really tied to the craddle point. They are the same modems that are used for route match.
Have the modems and tablets been rebooted? From my understanding, the tracker app will cache the data if the cell service is unavailable. Do you know if there is an update for the tracker app on the tablet? Is there a weekend support number for the app?
Mike Blizzard
Technical Services Manager | IT Department
City of Greenville, SC
864-467-5707
On Oct 31, 2015 9:14 PM, Grant Sparks<EMAIL_ADDRESS>wrote:
Hey Mike,
The Trolley Tracker app has been relaying spotty locations this weekend. Yesterday both trolleys were relaying their locations for the first couple hours of service and then both went down.  Today, we started off seeing both trolleys but now Trolley 1 is showing and Trolley 2 is not.
I was wondering if you could take a look at the wifi activity and see if we're being throttled down by Cradlepoint? I'm having a difficult time diagnosing the problem since it seems fairly random. We had the same issues last weekend.
Anyway, please let me know.
Thanks,
Grant

Writer of the trolley app here - the app does not cache data if service is
unavailable. However it may be that our connections might not be
immediately timing out when there is a loss of connectivity. That would
explain the "superspeed" trolley behavior that we sometimes see when a
trolley comes back online, but it would not explain the loss of
connectivity. I have been planning on debugging/fixing the slow timeouts,
but when that is fixed we will have even more connectivity issues, because
that issue is probably actually masking a lot of smaller outages.
The app is functionally pretty simple, it requests location updates from
the Android API and then sends HTTP POST requests to our REST API. It does
not save any updates or anything. So (outside of the timeout issue or some
other bug we haven't noticed yet), if the trolley is not getting location
updates it's almost certainly due to a network connectivity issue
(slow/intermittent service) or a power issue. I'm willing to work with your
IT team to debug these issues!
On Mon, Nov 2, 2015 at 11:11 AM, greenlinktransit<EMAIL_ADDRESS>wrote:

And just a heads up....I mentioned the internet issues to our IT
department and here's the response I received....
Those units aren't really tied to the craddle point. They are the same
modems that are used for route match.
Have the modems and tablets been rebooted? From my understanding, the
tracker app will cache the data if the cell service is unavailable. Do you
know if there is an update for the tracker app on the tablet? Is there a
weekend support number for the app?
Mike Blizzard
Technical Services Manager | IT Department
City of Greenville, SC
864-467-5707
On Oct 31, 2015 9:14 PM, Grant Sparks<EMAIL_ADDRESS>wrote:
Hey Mike,
The Trolley Tracker app has been relaying spotty locations this weekend.
Yesterday both trolleys were relaying their locations for the first couple
hours of service and then both went down. Today, we started off seeing both
trolleys but now Trolley 1 is showing and Trolley 2 is not.
I was wondering if you could take a look at the wifi activity and see if
we're being throttled down by Cradlepoint? I'm having a difficult time
diagnosing the problem since it seems fairly random. We had the same issues
last weekend.
Anyway, please let me know.
Thanks,
Grant
—
Reply to this email directly or view it on GitHub
https://github.com/codeforgreenville/trolley-tracker-ios-client/issues/11#issuecomment-153067741
.

I'm pretty sure that the equipment is powered down each day.   We had issues last weekend from Thursday through Sunday with both trolleys going up and down - sometimes going down in the middle of a run, then coming back.   So it will take more than a reboot to work around the problem.

I'm with Mike ( @bikeoid ) Until we get trolleys staying connected for an entire weekend or two we shouldn't push it more marketing than we already have running.
I could meet Wednesday at 9am if that works for others.

I'm good for a meeting on Wednesday at 9am.

Do you guys want to meet at Greenlink or a coffee shop?

Let's do Methodical.
On Tue, Nov 3, 2015 at 8:53 AM, greenlinktransit<EMAIL_ADDRESS>wrote:

Do you guys want to meet at Greenlink or a coffee shop?
—
Reply to this email directly or view it on GitHub
https://github.com/codeforgreenville/trolley-tracker-ios-client/issues/11#issuecomment-153361082
.

--
Adam Gautsch
OrangeCoat.com
800-890-1702 x0
http://www.orangecoat.com/people/adam

Of course, the other thing we could do is meet on the other side of Main near the trolleys (say Spill the Beans). After we meet we could head over to the trolleys and work on the wi-fi settings a little bit.

I want in! Although if we are going to go tinker with the tablets
afterwards, I suggest somewhere a little closer like eggs up grill. Up to
yall!
On Tue, Nov 3, 2015 at 11:25 AM, Adam Gautsch<EMAIL_ADDRESS>wrote:

Of course, the other thing we could do is meet on the other side of Main
near the trolleys (say Spill the Beans). After we meet we could head over
to the trolleys and work on the wi-fi settings a little bit.
—
Reply to this email directly or view it on GitHub
https://github.com/codeforgreenville/trolley-tracker-ios-client/issues/11#issuecomment-153404956
.

:egg: :+1: 9am.
See y'all there.

Eggs Up at 9AM works for me.  I'll touch base with Maintenance to make sure someone can help us get the Trolleys started (it's harder than you think).

I talked to Steve and apparently one of our Trolleys just went to the body shop.  It should be back for Thursday's evening service.  If you guys want to look at both of them at the same time, let's try to reschedule for Thursday afternoon/early evening.  I'm out of town Friday - Sunday.  Otherwise, if you're okay looking at just one trolley, let's continue with the original plan.  Let me know what you prefer.

I'd prefer Wednesday at 9am to see what we can learn and come up with a more advanced troubleshooting plan for the weekend if necessary.

How about we do this. Meet tomorrow as planned and go work with the tablet on the trolley that is there. That way we can have an A/B test of tablets to see if anything we did helped keep one up and running or not.

Works for me.

Do you guys still want us (Greenlink) to embed a Trolley Tracker map on our website?  Also, do you guys have a logo that we could post on our website?

Yeah that would be great! The sites have been updated. Here is a link to the icons:
https://app.box.com/s/ntfu86u3sycw0fa9s1514m6tzvwh38xo
https://app.box.com/s/zwc1rvmrkriya1n1lzrb52tiotnj4fbq
On Jan 6, 2016, at 9:36 AM, greenlinktransit<EMAIL_ADDRESS>wrote:

Do you guys still want us (Greenlink) to embed a Trolley Tracker map on our website? Also, do you guys have a logo that we could post on our website?
—
Reply to this email directly or view it on GitHub.

I'm unable to access those links without paying.

Give this link https://drive.google.com/drive/folders/0B1Wxj_5D6dLNQldIWnZ3c1RHbjQ a shot.

Got it -- thanks! What about the embedded trolley tracker map? Does someone have the HTML code for that?

   <iframe src="http://linktheorigi.webfactional.com/trolley/" class="shrink" width="100%" seamless></iframe>
Give this a shot.

Adam -- the code worked, but the map is quite narrow (see screen shot attached).  Any way the dimensions can be enlarged?

You're going to need to add a height, unless @Linktheoriginal knows a better way. Next to the width="100%" try something like height="500px"

You could do a height of 450px. I have it set via CSS so that it is larger
on the desktop (600px) vs mobile (450px) so that people can still scroll
down on the mobile device.
On Fri, Jan 8, 2016 at 2:09 PM, Adam Gautsch<EMAIL_ADDRESS>wrote:

You're going to need to add a height, unless @Linktheoriginal
https://github.com/Linktheoriginal knows a better way. Next to the
width="100%" try something like height="500px"
—
Reply to this email directly or view it on GitHub
https://github.com/codeforgreenville/trolley-tracker-ios-client/issues/11#issuecomment-170095812
.


dig is not able to resolve .

Rancher Version: Build from master
Docker Version:1.10.2
OS: Ubuntu 14.04 hosts
Steps to Reproduce:
Create service "test2" in stack "hello".
Create service "test1" in stack "hello2".
From within container of service "test2" in stack "hello" , I am not able to use dig to resolve cross stack services by attempting dig on test1.hello2 .
But dig on   test1.hello2.rancher.internal works as expected.
Note - ping on test1.hello2 resolves to correct ip address.

Tested with server version - v0.63.0-rc3
dig is able to resolve . as expected.


Revert "Do not print package-name in non-package interface by default."

rdar://135388095
Reverts swiftlang/swift#76244

@swift-ci please smoke test


Workflow - Allow users to send back a workflow if they accidently sign something out

Expected outcome

someone can sign something out by accident, but cant send the workflow back to them. e.g., circuit isolation. Hence RC - Coordinator should always be after
Business Value / Developer Experience

Acceptance Criteria

[ ] when selecting
[ ] items which covers
[ ] the expected outcome

Reintroduce unsign concept. Ignore email problems for now


Do not link against CUDA driver when building

Description
It is bad practice to link against the CUDA driver library (libcuda.so.1 on Linux) at build time because it may differ from the library at run time. In particular, the CUDA Toolkit provides stubs in case CUDA code is being compiled on a system without GPUs. TE already has infrastructure to access with CUDA driver library indirectly via cudaGetDriverEntryPoint (see https://github.com/NVIDIA/TransformerEngine/pull/970 and https://github.com/NVIDIA/TransformerEngine/pull/138). However, we should avoid explicitly linking against the CUDA driver to reduce the risk of linker snafus in the future.
Type of change

[ ] Documentation change (change only to the documentation, either a fix or a new content)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Infra/Build change
[ ] Code refractor

Changes

Do not link against CUDA driver when building

Checklist:

[x] I have read and followed the contributing guidelines
[x] The functionality is complete
[ ] 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

/te-ci


docs: update sample, regenerate README

@sofisl looks like this breaks the sample tests, might need to do some digging.

@sofisl it looks like the reference to @google-cloud/functions is missing from samples/package.json, I believe is the issue here.

@bcoe, thanks for the debugging 👍  saved me a bunch of time!


Mime-type Error

Hey there...
Couldn't figure out why the module doesn't work on my Mirror. WARNING! Could not load config file. Starting with default configuration. Error found: Error: Cannot find module 'mime-types'
is all I get by trying to install it. I already tried to install mime, mime-type and its dependencies...
Still the same

What version of MagicMirror are you using?

I just downloaded it from github,I guess the latest

just noticed: v2.6.0

Help me if you can I’m feeling down


Use GHA env file to set output in CI

This should fix the issue with this
Relevent GH Issue

This has been done for the code in #360. In the field there may be action runners that still support only the set-output, so the action has to work with both. The mentioned suite tests that fallback.
I completely forgot about the CI, thanks for fixing this.

Tested in https://github.com/EnricoMi/publish-unit-test-result-action/actions/runs/3291306902.


Typo

it's not a typo, ap is:
Array.prototype.ap = function(xs){
    return this.reduce((acc, f) => acc.concat(xs.map(f)), []);
};

Oh I have miss taken , thanks


AbortController support for Typescript fetch (and probably other templates)

Hello, please consider an option to add an optional parameter of type https://developer.mozilla.org/en-US/docs/Web/API/AbortController to every client method when generating typescript clients with "Fetch" template.
I guess a workaround is possible using Extended classes or something to add a property of type AbortController which is later passed to fetch options using UseTransformOptionsMethod, but it looks more like a crutch than a reliable method.
The goal is to cancel a request from the client side if the user is no longer interested in a result.

This is one of the reasons I stick with Axios rather than Fetch, I just want a simple way to timing out the http request.

I'm not sure if AbortController would be appropriate for every template, but I would really like to have one in Fetch template
I've made a draft PR which adds support

Already implemented in swagger2tsclient.
Parameter: /UseAbortSignal: "true"

Already implemented in swagger2tsclient.
Parameter: /UseAbortSignal: "true"

@ritterzk  Thanks for the /UseAbortSignal option! I tried this out. One issue I see is that the signal argument gets added to the methods in the client, but not in the interface. Note: I am using /GenerateClientInterfaces:true which generates the interface version of the client, and rest of my code base uses this interface.


BUG: Footer in Contact us page is not responsive for smaller width

Is there an existing issue for this?

[X] I have searched the existing issues

What went down?
Currently the footer in Contact us page is not responsive like some text is breaking

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

@upsaurav12 Issue assigned to you


enhancement Output column info when size invalid in block data convertor

Proposed changes
As title.

run buildall

run buildall

run buildall


Use embedding instead of embedding function in ElasticVectorStore

While it might be a bit more restrictive, I find that using the Embedding interface as an input for the vector store creation is better than an embedding function because we can use bulk requests and possibly the retry logic if needed.
I have seen that some vector store implementations use Embedding while others use embedding function so I don't know what is the criteria to have one or the other, in my opinion they should all just be Embedding or have a way more complex embedding function that accepts multiple texts instead of one by one.

agree - thanks!


Add source-version argument to the build queue command

Whenever my company increments the version of our app, we trigger a build on AppCenter which works great. The issue this PR aims to solve is that once the build is complete, the notification we get in Slack does not include the version notes that are in the commit message. I've asked about getting this fixed on the AppCenter Intercom for a while now but was told that its unfortunately not a priority. Jihye did mention there is a temporary fix possible by manually making the API POST to AppCenter's API and including the sourceVersion argument  as seen here: https://openapi.appcenter.ms/#/build/builds_create
This works great so this PR adds the sourceVersion argument to the build queue command so it is possible as a workaround for now until AppCenter is able to pick up the commit message that triggered the build automatically.
Thanks and let me know if there are any required changes to this PR!
Cody Brouwers

We should be releasing latest cli in a few days (all being well) so this will be rolled in to that release.

Sound good @owenniblock , thanks! 😁


Added Arch installation package

I enjoyed your Hope workshop, so I made an Arch AUR package for Huhnitor & included the command in your README. Enjoy :)

Huzzah! The first PR!
Thanks a bunch, this will make it more accessible. I use Arch myself btw but wasn't sure how to make an AUR package. Thanks for the contribution!

That's awesome, thank you!


Enum names

We don't compile C enums to Dart enums, because in Dart we cannot define the integer value of enum items.
However, with our current compilation scheme we don't have access to the string enum names.

abstract class Cronet_RESULT {
  static const int Cronet_RESULT_SUCCESS = 0;
  static const int Cronet_RESULT_ILLEGAL_ARGUMENT = -100;
  // etc.
}

How about we add:
abstract class Cronet_RESULT {
  // <what we are already generating>

  // Supports having duplicate integers with the same key.
  static const Map<String, int> _nameToValue = {
    'Cronet_RESULT_SUCCESS': 0,
    'Cronet_RESULT_ILLEGAL_ARGUMENT': -100,
    // etc.
  };

  // Does not support having duplicate integers with the same key, picks the (first? last?) name.
  static final Map<int, String> _valueToName = Map.fromEntries(
      _nameToValue.entries.map((e) => MapEntry(e.value, e.key)));

  static String toEnumName(int enumValue) {
    return _valueToName[enumValue]!;
  }

  static int toEnumValue(String enumName) {
    return _nameToValue[enumName]!;
  }
}

Any preference on what the static methods should be named?
And of course they should have proper documentation. 😄
We could make it optional behind a flag (some libraries like sqlite have an API that you pass in the integer and it gives you a full string sentence explaining what's going on, so you might not want to generate the String enum names for that library). But maybe it should be enabled by default.
cc @mannprerak2 @unsuitable001
Context: https://github.com/google/cronet.dart/pull/2/files
More background: toString() on enum values in Dart gives you access to the programmatic name: https://stackoverflow.com/questions/29567236/dart-how-to-get-the-value-of-an-enum/29567669

Closed by #1198?

Closed by #1198?

Yep!
Thanks @Levi-Lesches! 🔥


Garage Door Opener is showing as cover instead of switch and missing binary sensor

Describe the bug
Garage Door Opener is showing as cover instead of switch and missing binary sensor
Expected behavior
Garage Door Open is meant to have a switch and binary sensor
Screenshots

Home Assistant Version

e.g. 2021.11.0

Same as #659?

Same case, my Lomota Garage Door Opener is showed as cover and no binary sensor. It opens (down arrow) but don't close (up arrow) :( (Core 2021.11.0 but also on 2021.11.1)

I experience this same issue, my Lomota Garage Door Opener (Smart WiFi Garage Door Opener) is showed as cover and no binary sensor. It opens (down arrow) but doesn't close (up arrow) :( (Core 2021.11.0 but also on 2021.11.1)

I too have the same behaviour as @Xwandroid

Same exact issue as above. Wofea garage door controller

@sambarlick raised a feature request. Go vote: https://community.home-assistant.io/t/tuya-garage-door-opener-kogan-smart-wireless-garage-door-opener/355905

I can confirm that this is still an issue with HA 2022.3.8 for Smart Garage Door Opener using Tuya category=ckmkzq.  According to Supported Tuya Device Category that category is supported by Tuya integration (through Tuya IoT Platform).  The symptom is different in that the device is detected in HA but no entities are created.
  "home_assistant": {
    "installation_type": "Home Assistant OS",
    "version": "2022.3.8",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.9.9",
    "docker": true,
    "arch": "x86_64",
    "timezone": "America/Chicago",
    "os_name": "Linux",
    "os_version": "5.10.108",
    "supervisor": "2022.03.5",
    "host_os": "Home Assistant OS 7.6",
    "docker_version": "20.10.9",
    "chassis": "vm",
    "run_as_root": true
  },
  "custom_components": {},
  "integration_manifest": {
    "domain": "tuya",
    "name": "Tuya",
    "documentation": "https://www.home-assistant.io/integrations/tuya",
    "requirements": [
      "tuya-iot-py-sdk==0.6.6"
    ],
...
  "data": {
    "endpoint": "https://openapi.tuyaus.com",
    "auth_type": 0,
    "country_code": "1",
    "app_type": "smartlife",
    "mqtt_connected": true,
    "disabled_by": null,
    "disabled_polling": false,
    "name": "Main Garage Door",
    "model": "GD801",
    "category": "ckmkzq",
    "product_id": "vPxZSdMT8rtymUjf",
    "product_name": "Smart Wi-Fi Garage Door Opener",
    "online": true,
    "sub": false,
    "time_zone": "-06:00",
    "active_time": "2022-03-26T19:08:46+00:00",
    "create_time": "2022-03-26T19:08:46+00:00",
    "update_time": "2022-03-26T19:09:44+00:00",
    "function": {},
    "status_range": {},
    "status": {},
    "home_assistant": {
      "name": "Main Garage Door",
      "name_by_user": null,
      "disabled": false,
      "disabled_by": null,
      "entities": []
    }
  }

Side note for @cralwalker : the feature request linked above IMO is not relevant to this bug because that is for Tuya product category "mc" which is clearly NOT listed on Supported Tuya Device Category .


Filters example not working correctly

Using React Table v7
Describe the bug
Filters are not working correctly in your own example, not sure if the bug is in the library or just the example. After trying to filter the Status column, you are unable to filter it again, since it only shows the All option. After applying the filter, preFilteredRows argument in SelectColumnFilter function returns an empty array.
Also the slider component cannot be moved, but filters the value once.
UPDATE:
I suspect the empty array from preFilteredRows going into useMemo is the problem and it triggers an infinite loop (at least on my end). Removing the variable from the 2nd useMemo argument makes the filter work correctly.
To Reproduce
Steps to reproduce the behavior:

Go to https://codesandbox.io/s/github/tannerlinsley/react-table/tree/master/examples/filtering
Click on the Status filter, or try to move the Age slider
Try to change the Status again, or move the Age slider again

Expected behavior
Filter should still be populated with all Status options, including All. It should be possible to move Age slider left & right.
Screenshots

Desktop (please complete the following information):

Any

I'll investigate this next. Thanks for your help!

This should be fixed in d9a4b6b


fix(components): correct footer closing tags

Fixes closing tags for some footer components.

Great spot! Thanks for this @Blaconix


Does the SSH work?

@shadowwalkersb does it works?
In circleCI I see the following:
-- Looking for libssh2_userauth_publickey_frommemory in ssh2
-- Looking for libssh2_userauth_publickey_frommemory in ssh2 - not found

Also programatically libgit2 doesn't have the feature:
git_libgit2_features() & GIT_FEATURE_SSH -> 0
Also conda install libgit2 doesn't install libssh2
The following NEW packages will be INSTALLED:

    curl:    7.52.1-0 conda-forge
    libgit2: 0.25.0-0 conda-forge

Proceed ([y]/n)?

https://github.com/libgit2/libgit2/issues/4120 and https://github.com/libgit2/libgit2/pull/4036 might be related
also ccing @carlosmn and @ethomson

@shadowwalkersb @ethomson How should I investigate this issue?

After conda install libssh2:
/opt/conda/lib # nm -g libssh2.so | grep libssh2_userauth_publickey_frommemory
000000000002d33f T libssh2_userauth_publickey_frommemory
/opt/conda/lib #

So the symbol is there, but cmake cant detect it.

The same build.sh in a reproduced environment based on continuumio/miniconda3 docker image seems to work just fine:
$PREFIX is /opt/conda
root@2b0b0a94c0f6:/libgit2-0.25.1/build# cmake .. -DCMAKE_INSTALL_PREFIX=$PREFIX \
>          -DCMAKE_PREFIX_PATH=$PREFIX \
>          -DCMAKE_FIND_ROOT_PATH=$PREFIX \
>          -DCMAKE_BUILD_TYPE=Release \
> -DCMAKE_C_FLAGS=-L$PREFIX/lib
-- The C compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found PkgConfig: /opt/conda/bin/pkg-config (found version "0.29.1")
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM
-- Performing Test HAVE_STRUCT_STAT_ST_MTIM - Success
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC
-- Performing Test HAVE_STRUCT_STAT_ST_MTIMESPEC - Failed
-- Performing Test HAVE_STRUCT_STAT_MTIME_NSEC
-- Performing Test HAVE_STRUCT_STAT_MTIME_NSEC - Failed
-- Performing Test HAVE_STRUCT_STAT_NSEC
-- Performing Test HAVE_STRUCT_STAT_NSEC - Success
-- Checking for module 'libcurl'
--   Found libcurl, version 7.52.1
-- Found OpenSSL: /opt/conda/lib/libssl.so (found version "1.0.2k")
-- Could NOT find HTTP_Parser (missing:  HTTP_PARSER_INCLUDE_DIR HTTP_PARSER_LIBRARY)
-- http-parser was not found or is too old; using bundled 3rd-party sources.
-- Found ZLIB: /opt/conda/lib/libz.so (found version "1.2.8")
-- Checking for module 'libssh2'
--   Found libssh2, version 1.8.0
-- Looking for libssh2_userauth_publickey_frommemory in ssh2
-- Looking for libssh2_userauth_publickey_frommemory in ssh2 - found
-- Performing Test IS_FVISIBILITY=HIDDEN_SUPPORTED
-- Performing Test IS_FVISIBILITY=HIDDEN_SUPPORTED - Success
-- Performing Test IS_WDOCUMENTATION_SUPPORTED
-- Performing Test IS_WDOCUMENTATION_SUPPORTED - Failed
-- Performing Test IS_WNO-MISSING-FIELD-INITIALIZERS_SUPPORTED
-- Performing Test IS_WNO-MISSING-FIELD-INITIALIZERS_SUPPORTED - Success

I've created a working docker image based on debian, using conda dependencies https://github.com/kszucs/dockers/blob/master/libgit2.debian
I don't see why can't cmake find libssh2_userauth_publickey_frommemory in the conda build.

I've created a working docker image based on debian, using conda dependencies https://github.com/kszucs/dockers/blob/master/libgit2.debian
I don't understand why can't cmake find libssh2_userauth_publickey_frommemory in the conda build.

In the most recent Linux build on master, am seeing the following. Same story with macOS.
-- Checking for module 'libssh2'
--   Found libssh2, version 1.8.0
--   Resolved libraries: $PREFIX/lib/libssh2.so
-- Looking for libssh2_userauth_publickey_frommemory in $PREFIX/lib/libssh2.so
-- Looking for libssh2_userauth_publickey_frommemory in $PREFIX/lib/libssh2.so - found

However for Windows am seeing the following.
-- LIBSSH2 not found. Set CMAKE_PREFIX_PATH if it is installed outside of the default search path.

IOW looks like this got fixed at some point. Windows has some sort of issue though.

I bumped into this issue on an ARM Mac. Any idea how to fix this?
Ref: bool(pygit2.features & pygit2.GIT_FEATURE_SSH) comes out as false.
I have 1.6.4 so newest version.


Fix total entries errors for queries with group by clause

fixes #35

Thanks for this, much appreciated.


[msal-node][msal-common] Client applications, authorization code and device code implementation

Adds implementation public APIs and implementation for authorization code flow and device code flow. Will add a separate PR for unit tests- won't merge this until that is out and reviewed.
Adds to msal-common:

AuthorizationCodeClient - creating authorization endpoint URI and then making token request
DeviceCodeClient - device code flow
BaseClient - will be extended by all oauth clients (refresh token and silent coming next)
Configuration - configuration of for oauth clients

response:

DeviceCodeResponse - response from first step of device code flow. Returned to user via callback.
AuthenticationResult - value returned to the user after a successful token acquisition. Have not finalized if this will be added.

request:

AuthorizationCodeRequest - ClientApp.acquireTokenByAuthCode(AuthorizationCodeRequest)
AuthorizationCodeUrlRequest - ClientApp.getAuthCodeUrl(AuthorizationCodeUrlRequest)
DeviceCodeRequest - PublicClientApp.acquireTokenByDeviceCode(DeviceCodeRequest)
RequestValidator - validation utils for requests
RequestUtils - utils for constructing requests
CancellationToken - for cancelling polling in device code flow

Add to msal-node:

ClientApplication - abstract base class for PublicClientApp and ConfidentialClientApp. Contains APIs shared by both. Not exported.
PublicClientApplication - public client flows.
ConfidentialClientApplication - confidential client flows.
ClientConfiguration - configuration for PublicClientApplication and ConfidentialClientApplication.
HeaderUtils - Injecting node default headers into msal-common

Adds to samples:

msal-node-auth-code: express app showing authorization code flow
msal-node-device-code: console app showing device code flow

made lots of comments, but overall looking good.  It is definitely a challenge to review in totality with the number of changes.  In the future I would encourage thinking through how to do this in say 10 smaller prs.
Maybe something like

stub apis
implement request utils
implement http client for device code and auth code
implement pol for device code
etc....

That way you can add tests as you go for each stage and the mental over head of each pr is fairly small. Even if you end up altering previous pieces as you go its no big deal because the number of changes is fairly low.
I also find that it helps me high level plan out my design better to do smaller prs.


Powertoys Run seems to crash daily

Microsoft PowerToys version
0.76.2
Installation method
PowerToys auto-update
Running as admin
Yes
Area(s) with issue?
PowerToys Run
Steps to reproduce
Not sure as it crashed without even trying to run
✔ Expected Behavior
Not crash
❌ Actual Behavior
2024-01-05.txt
2024-01-04.txt
2024-01-03.txt
Other Software
No response

/reportbug

looks like the bot didn't post the msg.
Hi there!We need a bit more information to really debug this issue. Can you add a "Report Bug" zip file here?    Then drag the zipfile from your desktop onto the GitHub comment box in this issue.  Thanks!

/needinfo


multiple requirements.txt files

Describe your changes
The changes will allow users to declare multiple task specific requirements..lock.txt / environment..lock.txt files. Multiple images are being built with different dependency files for different task patterns like fit-__, etc. Scripts which do not need separate requirements file will use the image corresponding to the default requirements.lock.txt file. As of now scheduling jobs as per this change will occur only in the AWS batch exporter.
Issue ticket number and link
Closes #77
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I have added thorough tests (when necessary).
[x] I have added the right documentation (when needed). Product update? If yes, write one line about this update.

I would need some help here. I'm almost done with the code and test cases. There are some existing test cases which are failing and I cannot get to the root cause even after debugging.

            Only valid when capture_output=True

        error_message: str, default=None
            Error to display when expected_output does not match. If None,
            a generic message is shown

        hint: str, default=None
            An optional string to show when at the end of the error when
            the expected_output does not match. Used to hint the user how
            to fix the problem

        show_cmd : bool, default=True
            Whether to display the command next to the description
            (and error message if it fails) or not. Only valid when
            description is not None
        """
        cmd_str = ' '.join(cmd)

        if expected_output is not None and not capture_output:
            raise RuntimeError('capture_output must be True when '
                               'expected_output is not None')

        if description:
            header = f'{description}: {cmd_str}' if show_cmd else description
            self.tw.sep('=', header, blue=True)

        error = None

        # py 3.6 compatibility: cannot use subprocess.run directly
        # because the check_output arg was included until version 3.7
        if not capture_output:
            try:
                result = subprocess.check_call(cmd)
            except Exception as e:
                error = e
        # capture outpuut
        else:
            try:
                result = subprocess.check_output(cmd)
            except Exception as e:
                error = e
            else:
>               result = result.decode(sys.stdout.encoding)
E               AttributeError: 'NoneType' object has no attribute 'decode'

/Users/neelashasen/miniconda3/envs/soopervisor/lib/python3.9/site-packages/ploomber/io/_commander.py:132: AttributeError

This test probably needs some fix in the conftest.py file but I'm not able to figure out what exactly.

I also see this error in the Windows CI:
Checking out the ref
  "C:\Program Files\Git\bin\git.exe" checkout --progress --force refs/remotes/pull/86/merge
  Error: error: invalid path 'tests/assets/multiple_requirements_project/requirements.clean-*.lock.txt'
  Error: The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128

The repo checkout itself is failing because of this file tests/assets/multiple_requirements_project/requirements.clean-*.lock.txt. Probably because we can't have * in filename on Windows?

@neelasha23 Maybe we can try double underscore as well for windows? __

There is an issue that I'm facing with the airflow tests. The tests/airflow/test_airflow_export.py  cases kept failing because the mock was expecting pkg-name.json file inside env-name folder for non bash presets (I'm not sure why this happened because I have hardly changed anything in the conftest). So just to see if the test case is passing I changed this line
https://github.com/ploomber/soopervisor/blob/81d0bda8879980b86c75aafcd4d68facf2130423/src/soopervisor/airflow/export.py#L98
However now the current CI error comes up FAILED tests/test_export.py::test_checks_the_right_spec_pkg[AirflowExporter] - FileNotFoundError: [Errno 2] No such file or directory: 'serve/my_project.json' .
I would need some help in understanding this functionality.

@neelasha23 this code takes the final Airflow dag and saving it into the file the users can deploy with.
We're opening and writing into the json file, I don't think removing this line will suffice since the whole test is checking this export functionality. @edublancas thoughts?

Just to clarify, I haven't removed that line. Previously it was writing to pkgname.json I have only modified it to write to envname/ pkgname.json, because that's what the test case is suddenly expecting.  I'm not sure how this happened because I haven't made any major changes in the airflow pipeline.

ok, I found the issue. I pushed a commit changing this line:
https://github.com/ploomber/soopervisor/blob/81d0bda8879980b86c75aafcd4d68facf2130423/src/soopervisor/airflow/export.py#L98
to:
path_dag_dict_out = Path(pkg_name + '.json')

since that's what I saw in the master branch.
then I saw a bunch of tests fail.
the problem is here:
https://github.com/ploomber/soopervisor/blob/81d0bda8879980b86c75aafcd4d68facf2130423/src/soopervisor/commons/docker.py#L245
this line will behave differently depending on what happens with the for loop. If lock_paths is empty, it will never execute, if there are 1,2,3 items, it'll execute that number of times. This will cause the function to end up in a different working directory, which is causing the issue. These internal functions should be deterministic, Ideally, they should not change the working directory. and if they do, they should always revert to the original working directory where they were executed

Got it. I will need to go the parent directory of dist before start of every loop otherwise it fails. I will try to think of a way around.
What about the the issue with windows? Doesn't look like filenames can have * in them on Windows. So should I change the naming convention of the requirements.task-*.lock.txt files? Maybe have __ like Ido suggested?

yeah, I think double underscore makes sense, we already have something similar for the SLURM exporter: https://github.com/ploomber/soopervisor/blob/566d7773a3af408046d0efbdbd80ad10f77bb620/src/soopervisor/shell/export.py#L33

The CI is passing now for all the platforms. I have also submitted a pipeline to AWS batch and verified that the tasks are getting scheduled in the corresponding image. Had to use args = ['docker', 'buildx', 'build', '--platform=linux/amd64', '.', '--tag', image_local] for the jobs to run successfully.

@neelasha23 I ran it and looked on the code build for this user: 95de7987, with the sample pipeline - multiple_requirements_project. Where can I see the 2 images creation? I didn't see it in the build. Also, I saw the batch tasks are failing (sent you the links).

have sent you some links of job run in us-west-2 (that's where I set up AWS Batch initially). Let me know if I should repeat the same in prod

Have added seaborn dependency for the plot task in multiple_requirements_project in test/assets. While testing it i found a bug. The docker build command was installing dependencies from the env folder whereas the correct task specific file was present in the /project folder.  So i have created a Dockerfile specific to aws-batch : https://github.com/ploomber/soopervisor/blob/789f6087a8ec375c79ea97bc8037d8c38636513a/src/soopervisor/assets/aws-batch/Dockerfile and changed the sequence of instalment command to be after RUN tar --strip-components=1 -zxvf *.tar.gz.

@neelasha23 Is it now batch-specific? Since it wasn't the initial intention.

No it's not aws batch specific. Since aws batch is the priority right now, I have only modified the Dockerfile  for the same. To be on the safe side I haven't modified the common Dockerfile. I did test with Argo and it seemed to be fine, but still once all the exporters are properly tested with this Dockerfile change maybe we can have just one Dockerfile.

Got it! Let's finish testing on the rest of the backs, generalize this Dockerfile and merge

@edublancas ?
I think it's residues from the run?

@neelasha23 how much time do you think it'll take you including the rest of them?
@edublancas thoughts on including the rest of the backends in? If it's ~2-3 days extra dev work I think we should add it, there's no pressing deadline currently.

I had initially started with Airflow and Kubeflow. And i remember the environment was breaking. So would to figure those out first and then check the code changes. All the exporters have different logic for the export.

Sure. Any other reviews for this PR?


Jazzy harmonic devel

Changes for Ros-Jazzy and Gazebo Harmonic
alongside https://github.com/AndrejOrsula/panda_ign_moveit2/pull/34

This is basically working together with the mentioned PR in the panda_ign_moveit2 repo.
See Issue #28 though, but that is outside of the port here i fear


Could SCOSSL_set_trace_level be exported by e_scossl.h?

We have found in our testing on Azure Linux 3.0, using SymCrypt-OpenSSL, that failed signature verification produced verbose logging that we do not wish to emit (https://github.com/microsoft/CCF/issues/6593).
Inlined for convenience:
[ERROR] error:41080106:SCOSSL::passed invalid argument:Decoded content length does not fit in derField buffer. pbDerField [0x55ebfc892490, 0x55ebfc8924f8), pbContent [0x55ebfc892492, 0x55ebfc8924f9) at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 285
[ERROR] error:410C0107:SCOSSL::operation fail:scossl_ecdsa_remove_der failed at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 586
[ERROR] error:41080106:SCOSSL::passed invalid argument:Decoded content length does not fit in derField buffer. pbDerField [0x55ebfc85cc30, 0x55ebfc85cc77), pbContent [0x55ebfc85cc32, 0x55ebfc85cc78) at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 285
[ERROR] error:410C0107:SCOSSL::operation fail:scossl_ecdsa_remove_der failed at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 586
[ERROR] error:41080106:SCOSSL::passed invalid argument:cbR (48) or cbS (48) too big for cbSymCryptSignature (64) at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 400
[ERROR] error:410C0107:SCOSSL::operation fail:scossl_ecdsa_remove_der failed at /usr/src/azl/BUILD/SymCrypt-OpenSSL-1.5.1/ScosslCommon/src/scossl_ecc.c, line 586

It looks like we could control that with SCOSSL_set_trace_level(), but the public headers are unfortunately very restricted (https://github.com/microsoft/SymCrypt-OpenSSL/blob/main/SymCryptEngine/inc/e_scossl.h) and do not include it.
Could that call be exposed, or the logging level for those messages revised?

I can add this to the existing PR for logging updates. The PR currently exposes this functionality for the provider but not the engine. By default, logging level will be off.
https://github.com/microsoft/SymCrypt-OpenSSL/pull/92

@mamckee changing the default to off would solve our problem, and having this functionality on the provider sounds perfect, thank you! What's the header/call to set the log level on the provider? Do we need to do anything special to make sure the Azure Linux package exposes the header?

The logging level will be settable from the config (/etc/pki/tls/symcrypt_prov.cnf on AZL3). These values can be set under symcrypt_prov_sect: https://github.com/microsoft/SymCrypt-OpenSSL/blob/8578c5954d0f15b11d4f88a30d2658fb9958ec88/SymCryptProvider/src/p_scossl_base.c#L18C1-L21C39

@mamckee that's perfect, do you have a sense of when this might land in Azure Linux? If not, would you mind giving us a heads up when it does?


Add centos ci integration

Filed bug for an account for the project: https://bugs.centos.org/view.php?id=16024

Closed via #114


Very nice library - thank you very much! Please now some docs...

I just wanted to say thank you very much for this very nice library!
Now it would be even more nice to read some documentation... just a few basic things that are not immediately clear by the demos. Thanks!

Please, can you add to Readme the documentation and ISO that you have followed to implement the code? It would be interesting if you implement ISO ISO /IEC 18004:2015  that you add it information to documentation. Project will gain a lot of interest for commercial uses.

@jmjurado23
My implementations are based on JIS X 0510:1999.
I attached this comment to readme.
It seems neary equals to ISO/IEC 18004:2000.

Thanks a lot!!! 😊
El jue., 29 ago. 2019 18:16, kazuhiko arase<EMAIL_ADDRESS>escribió:

@jmjurado23 https://github.com/jmjurado23
My implementations are based on JIS X 0510:1999.
I attached this comment to readme.
It seems neary equals to ISO/IEC 18004:2000.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kazuhikoarase/qrcode-generator/issues/57?email_source=notifications&email_token=AAQBXHCLHFNI2YIG3H2QRPLQG7Y5TA5CNFSM4FPQ7RFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5PBBUY#issuecomment-526258387,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQBXHAH2JJS6ZAPDQD6L4DQG7Y5TANCNFSM4FPQ7RFA
.


fix(ENG-884): removing sonar from semantic release since irrelevant

Description

Removing feature branch from semantic release
Removing sonar from release file as not needed

Issue(s)
ENG-884
How to test

Merge, re-run pipeline

Checklist

[ ] Something that needs doing

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[needs-design]Can we let macro generate function to append module to init table?

Hi,
In order to debug module sometimes we need to run a python script inside the rust environment. One way to do this is through calling function PyImport_AppendInittab before pyo3::prepare_freethreaded_python(). We don't have this in pyo3 directly but one workaround would be adding such piece of code
pub extern "C" fn pyinit() -> *mut ::pyo3::ffi::PyObject {
	unsafe { PyInit_module() }
}
pub fn append_inittab(){
	unsafe {
		pyo3::ffi::PyImport_AppendInittab("module\0".as_ptr() as *const std::os::raw::c_char, Option::Some(pyinit));
	}
}

And I'm thinking of adding such support in macro pymodule with similar code like
pub fn append_inittab_wrapper(){
    unsafe {
        #krate::ffi::PyImport_AppendInittab(concat!(stringify!(#name), "\0").as_ptr() as *const std::os::raw::c_char, Option::Some(pyinit));
    }
}

Meanwhile make sure PyImport_AppendInittab contains unsafe so this function can be reused. One thing I'm not sure is how to let the rust project that uses pyo3 recognize the append_inittab_wrapper  without guessing the function name.
Please let me know if there is any concern for this or if there is any better idea?

I would be ok with having a safe function PyModule::append_to_inittab(). It would probably make sense for it to panic if Py_IsInitialized() returns true.

Actually maybe this would need to a a macro pyo3::append_to_inittab!(my_module) which uses the same kind of tricks done in wrap_pymodule. PRs to experiment with this is welcome!


Replace development-cycle with canister-lifecycle

This removes development-specific text from the page and leaves
only the canister lifecycle specific concepts.
The development-specific text (e.g. how to install code) will be
moved to another page in the Deploy section.

@jessiemongeon1 ptal


chore(*): ot3 protocol execution

This PR is a catchall for fundamental changes to the hardware control layer of API to allow the OT3 to execute protocols and generally move around correctly.
It is targeted on https://github.com/Opentrons/opentrons/tree/ot3-protocol-base which is a synthetic branch formed by merging https://github.com/Opentrons/opentrons/pull/9201, https://github.com/Opentrons/opentrons/pull/9207, and https://github.com/Opentrons/opentrons/pull/9207 into edge; it shouldn't be merged until all those are and should be changed to merge into edge at that time.
While the code here currently works, it's also extremely hacky and actively breaks OT-2 protocol execution; this is therefore a working branch to get the code to actually be good and not break anything as well as "work".

this is raaaad! we'll need to add these new pipettes to the block lists for pipette dropdowns in PD + the app so they don't show up. I can do that if you want!
See the PipetteSelect in shared components, it takes a nameBlocklist prop that consuming components in PD + the app should now be utilizing.

This code moved to https://github.com/Opentrons/opentrons/pull/9207

this is raaaad! we'll need to add these new pipettes to the block lists for pipette dropdowns in PD + the app so they don't show up. I can do that if you want!
See the PipetteSelect in shared components, it takes a nameBlocklist prop that consuming components in PD + the app should now be utilizing.

This code moved to https://github.com/Opentrons/opentrons/pull/9209


Gender fixes: Replace underscore with doubledot, replace string

Replaced gender underscore with double dots to make it more accessible for screen readers. I doubt they can read the underscore correctly, the colon promises more success as colons are well established in sentences (some thoughts on this (German))
Replaced an insult with a bitter question to circumvent reading flow blockage caused by gendered spelling

Thanks


【Discuss】About NexRv Tool

Hi All，
When I Use the NexRv Tool，I found it expect the first “ProgTraceSync” msg’s “full addr” field match the code’s first PC.
But I think when I enable the trace encoder, the Hart may not start yet.
I wonder if I used the tool wrong ?
Any help would be greatly appreciated!
Best regards,
Micreven

NexRv tool is based on sequence of PCs which retired. First PC is reported in very first message. Again all retired instructions are reported on ingress port, so if hart is not started yet, there is nothing to report.

Hi Robert，
Thanks for your explanation.
But as the SPEC said，the “ProgTraceSync” message should be generated when 'trTeInstTracing' changed from 0 to 1, whenever the hart is start or not.
How could the trace encoder generate the "full-addr" field for the "ProgTraceSync" msg, when hart not start and 'trTeInstTracing' changed from 0 to 1. I think this moment, the ingress port can't give any information for Trace Encoder.
Best regards,
Micreven

Obviously trace cannot be reported if ingress port is not providing any retired instructions. But it should report message at nearest opportunity. Technically you may have a hart being held in reset (for long time) and enable trace while hart is held in reset. Nothing is reported until hart will retire instruction.

Hi Robert,
Thanks for your explanation.
Now I got it.
And do you prepare to release the next version of NexRv Tool ? It seems like cant match the newest SPEC.
Thanks
Best regards,
Micreven

Now the spec is officially Frozen. I will wait for end of public review (30 days from today).


We could not load resource configuration. Refresh page to try again. See GitHub issuesfor help resolving the issue

If your issue relates to the Discovery Process, please first follow the steps described in the implementation guide Debugging the Discovery Component

Describe the bug
I get this everytime I go into the Perspective.  I don't have anything defined in my region -- and I've taken the defaults when configuring AWS Perspective
To Reproduce
Take AWS perspective defaults.  Always comes up with this message.
1
Screenshots
Chrome
Additional context
Add any other context about the problem here.

Have you imported any accounts?

I have clicked on "import account" -- and put in my account number.  However..... I have never "exported" anything to "import"

I ask this because this sounds like an issue when you have lots of resources in your account as mentioned in #27 so I was wondering if that might be what's happening in your case.

I don't have any resources in my account. -- And I have selected my account in the import option.  I believe #27 had a different problem because he could narrow down his selection.    I have installed the perspective in mutliple accounts (both work and personal account) and have always gotten this message.   I will create an EC2 image to see if it is a problem with an empty account.

Can you try just importing the Perspective account? It should be the first option when you log in to Perspective for the first time. That doesn't require any CloudFormation so it should import a bunch of stuff so we can see if that's working.

Right now deleting stacks... Will recreate aws-perspective stacks in a region where I have a small setup... and then try importing the perspective account as you;'ve indicated.

Wow Cool!  I was able to see my region diagrammed nicely after 1)  waiting for all components to complete in CF and 2) specifying the account when I first logged into the CF distribution URL.  So problem solved.  I have many questions but in respect to not convoluting this issue, I will go into research mode.  Thanks.

Great! If you've not seen it to the Import an account section here in the Implementation Guide (https://docs.aws.amazon.com/solutions/latest/aws-perspective/automated-deployment.html) for steps on how to import other accounts.

succesfully resolved.


output to a raw L4 socket

Hi! I accidentally created a regular syslog message out of my json using "text" processor and some hardcore magic like that:
  - text:
      operator: set
      value: "${!timestamp_utc} ${!json_field:Hostname}: ${!content}"

But now I have a great desire to feed such log to my perfect system which, alas, understands only syslog messages (hence my magic tricks).
Is it possible at the moment to perform so with some already written output module or my need is completely out of order and I should immediately cease such nonsense?

Hey @DpoBoceka, not currently unless you pipe Benthos stdout output to something like netcat. However, I'm definitely not opposed to adding tcp and udp inputs and outputs to Benthos.

Work in progress but I've added tcp and tcp_server inputs: https://github.com/Jeffail/benthos/commit/b09155a64f6dc32e2b5ea3a97ca611fe6418373a

Hey @DpoBoceka, in v2.14.0 I've added a bunch of tcp and udp inputs and outputs. I'll probably stop there unless you have a specific need that isn't yet met, in which case feel free to reopen this ticket.


After upgrading to Prisma 3.10 from 3.9, remix site crashes on connection (Codesigning issue on M1 Macs)

Bug description
In a Remix.run site I'm developing, I updated Prisma from 3.9.1 to 3.10. This made the server crash with the following message.
Downgrading to Prisma 3.9.2 worked again. Tested multiple times to switch version with consistent behaviour.
Watching Remix app in development mode...
💿 Built in 228ms
Remix App Server started at http://localhost:3000
fatal error: all goroutines are asleep - deadlock!
[1]    26432 killed     npx remix dev --debug

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0x1400001ad28)
        runtime/sema.go:56 +0x38
sync.(*WaitGroup).Wait(0x1400001ad20)
        sync/waitgroup.go:130 +0xa4
main.runService(0x1)
        github.com/evanw/esbuild/cmd/esbuild/service.go:138 +0x494
main.main()
        github.com/evanw/esbuild/cmd/esbuild/main.go:203 +0x1f0

goroutine 6 [chan receive]:
main.runService.func1(0x140000261e0, 0x1400001ad20)
        github.com/evanw/esbuild/cmd/esbuild/service.go:66 +0x3c
created by main.runService
        github.com/evanw/esbuild/cmd/esbuild/service.go:64 +0x1a8

goroutine 7 [chan receive]:
main.(*serviceType).sendRequest(0x140000261e0, {0x1029e7320, 0x14003885ce0})
        github.com/evanw/esbuild/cmd/esbuild/service.go:163 +0x104
main.runService.func2(0x140000261e0)
        github.com/evanw/esbuild/cmd/esbuild/service.go:92 +0x40
created by main.runService
        github.com/evanw/esbuild/cmd/esbuild/service.go:89 +0x2b8

Note that Prisma studio works in both versions.
How to reproduce
Unclear. Similar issues have been discussed in the Remix discord (https://discord.com/channels/770287896669978684/938793097414975528/938795339757010964)
See also https://github.com/prisma/prisma/issues/11995
Expected behavior
No response
Prisma information
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

System seems to crash on connection to the database.
Environment & setup
Computer: MacBook Pro 14 inch, M1 Max, macOS Monterey 12.2
Database: Postgresql 14.1 installed from homebrew
Node: v17.6.0
Remix: 1.2.2 (also tested 1.2.1)
Prisma Version
Non-working version
Environment variables loaded from .env
prisma                  : 3.10.0
@prisma/client          : 3.10.0
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt 73e60b76d394f8d37d8ebd1f8918c79029f0db86 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : 73e60b76d394f8d37d8ebd1f8918c79029f0db86
Studio                  : 0.458.0

Working version
Environment variables loaded from .env
prisma                  : 3.9.2
@prisma/client          : 3.9.2
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at<EMAIL_ADDRESS>Migration Engine        : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio                  : 0.457.0

What does npx remix dev --debug with Prisma under the hood?
Is there a way to create a minimal project that shows this behavior so we have an easier time reproducing?

Remix builds the site, and starts an express server. The Prisma connection is managed through this code
export { PrismaClient as DbClient } from "@prisma/client";

let db: DbClient;

declare global {
    // eslint-disable-next-line no-var
    var __db: DbClient | undefined;
}

// this is needed because in development we don't want to restart
// the server with every change, but we want to make sure we don't
// create a new connection to the DB with every change either.
if (process.env.NODE_ENV === "production") {
    db = new DbClient();
    db.$connect();
} else {
    if (!global.__db) {
        global.__db = new DbClient();
        global.__db.$connect();
    }
    db = global.__db;
}

export { db };

which is form the Remix documentation (https://remix.run/docs/en/v1/tutorials/jokes#connect-to-the-database). As far as I can tell, it deadlocks when trying to connect to the database.
I have unfortunately not had the time to attempt a reproducing example, but I hope to do so. I wanted to create a bug before I had a reproduction with enough description that others could find it if they encounter the same issue.

I experienced something similar though with a Next.js application - I wasn't able to put together a reproduction as my clean repo didn't crash the process, so I decided to try deleting all .prisma generated directories before running prisma generate again, and that worked!
I have a monorepo, so I located all .prisma directories with find . -name .prisma, then deleted each one.
So at least for me, the issue manifested when I already had a generated client from 3.9, and cleaning up the old version before running generate again appears to have fixed it.

Thanks, that solved my issue! Wouldn't have occured to me, since otherwise the watcher I have regenerating prisma files has worked without a hitch.

Can you still follow which .prisma folder maybe was in an unexpected location?

The repository I work in is not a monorepo yet, so for me it was the standard node_modules/.prisma location.

Interesting. Upgrading the package should also prisma generate again. Something must have gone wrong there. Super weird.

@janpio fascinating, this is an interesting one, I was able to reproduce! For extra context, I did run prisma generate after upgrading to 3.10, which did not fix the issue until I deleted the .prisma/client directory.
So the issue is macOS code signing on M1 Macs!
Specifically, code signing breaks when replacing a binary with the contents of a new binary, for example you can reproduce this via the following:
$ cp /bin/false ./example
$ ./example # works
$ cp /bin/true example
$ ./example # killed by the kernel

By creating the example binary as a copy of the first binary, the binary is considered safe, but when replacing it with the copy of a different binary, it's considered unsafe.
I believe that's what is happening here, when upgrading from 3.9 to 3.10, the file node_modules/.prisma/client/libquery_engine-darwin-arm64.dylib.node is replaced with the 3.10 version, but since its path / inode is the same as before, it is considered no longer code signed by the macOS sandbox.
This manifests as the following log lines in Console:
default	22:54:01.120624+0000	kernel	CODE SIGNING: cs_invalid_page(0x118000000): p=70474[node] final status 0x23010204, denying page sending SIGKILL
default	22:54:01.120635+0000	kernel	CODE SIGNING: process 70474[node]: rejecting invalid page at address 0x118000000 from offset 0x0 in file "/Users/jacobwgillespie/Code/jacobwgillespie/primsa-3-10-issue/3-9-then-3-10/node_modules/.prisma/client/libquery_engine-darwin-arm64.dylib.node" (cs_mtime:1645742717.771967254 != mtime:1645742737.976117428) (signed:1 validated:1 tainted:1 nx:0 wpmapped:0 dirty:0 depth:0)
default	22:54:01.120702+0000	kernel	node[70474] Corpse allowed 1 of 5
default	22:54:01.169387+0000	ReportCrash	Formulating fatal 309 report for corpse[70474] node
default	22:54:01.171430+0000	ReportCrash	no MetricKit for process node type 309 bundleId (null)
default	22:54:01.171521+0000	ReportCrash	Sending event: com.apple.stability.crash {"exceptionCodes":"0x0000000000000032, 0x0000000118000000(\n    50,\n<PHONE_NUMBER>\n)EXC_BAD_ACCESSSIGKILL (Code Signature Invalid)UNKNOWN_0x32 at 0x0000000118000000","incidentID":"15D796F0-C20F-41A4-92A4-69DA30481984","logwritten":0,"process":"node","responsibleApp":"iTerm2","terminationReasonExceptionCode":"0x2","terminationReasonNamespace":"CODESIGNING"}

Note the cs_mtime:1645742717.771967254 != mtime:1645742737.976117428 on the rejection, the file mtime at initial creation (v3.9) no longer matches the current mtime after upgrade (v3.10)
I think the potential fixes would be:

Delete the .dylib.node file in prisma generate before generating the new client (or delete the whole .prisma/client for that matter)
Put the Prisma version in the filename, so that on version upgrade, you're guaranteed to get a new inode for the binary (libquery_...3.10.0.dylib.node, etc)

Another benefit to (1) is it would clean up old files, I also discovered that after upgrading from 3.9 to 3.10 a leftover .prisma/client/runtime/esm directory was still present from 3.9, but that turned out to be a red herring. But if Prisma cleaned its client directory before generate, that would potentially also clean up leftovers like esm.
Credit to https://openradar.appspot.com/FB8914243 for the simple reproduction of the issue above.

Might be superfluous since the cause seem to have been found by @jacobwgillespie above, but can confirm the issue also happens with SvelteKit (so not only Remix) after updating Prisma to 3.10.
Attempting to connect after starting a dev server ends the process with SIGKILL.
I am also on M1 and I did run prisma generate after update. Removing ./node-modules/.prisma and rerunning prisma generate solved the issue.

If anyone is in the position to do this, a copy of the node_modules/.prisma copy before and after removing and regenerating it would be helpful for us just to make sure it is not something else than what @jacobwgillespie described.

I still have a copy of my test files, here's some zips:

Installing 3.9.x first, then 3.10.x: https://drive.google.com/file/d/1lAQbSArGgQAiGdHD5QXRqo9aGZCSoalX/view?usp=sharing
Only installing 3.10.x: https://drive.google.com/file/d/1WOoxtjxdQrYcNjLKRsj6VtwjmX7LjJiG/view?usp=sharing

You can see the leftover esm directory in the first zip...
One of the things that lead to the finding above was that if I made a copy of the project the copy worked. As in, if I upgraded from 3.9 to 3.10, the project was broken, but if I cp -r node_modules to another directory it worked. That seemed to imply that it wasn't actually the contents of the files, but something about their metadata instead, which lead to investigating the kernel error messages.

I did try this on my machine and wasn't able to reproduce. Looks like we will require more information here.

@pantharshit00 do you have an M1 Mac? From my understanding this specifically triggers on darwin-arm64.
The steps to reproduce that work for me, if useful:

Create a package.json with the following:{
  "dependencies": {
    "@prisma/client": "3.9.x",
    "prisma": "3.9.x"
  }
}

Run yarn install && yarn prisma generate
Try using Prisma and notice that it works
Modify the package.json to the following:{
  "dependencies": {
    "@prisma/client": "3.10.x",
    "prisma": "3.10.x"
  }
}

Run yarn install && yarn prisma generate
Try using Prisma and notice that the kernel immediately kills the node process

Got the same issue when upgrading Prisma from version 3.14 to 3.15. I'm on a MacBook Pro (14-inch, 2021) with an M1 Pro chip.

Same here on M1 MacBook Pro.
Removing node_modules/.prisma and running prisma generate again helped.

I experienced the same problem when upgrading to 4.0.0. Completely uninstalling prisma, @prisma/client, and removing node_modules/.prisma and then reinstalling everything and running prisma generate fixed the problem.
Here's first part of the node crash report that led me to this GitHub issue:
Process:               node [70784]
Path:                  /Users/USER/*/node
Identifier:            node
Version:               ???
Code Type:             ARM-64 (Native)
Parent Process:        Exited process [70616]
Responsible:           iTerm2 [47725]
User ID:               501

Date/Time:             2022-07-04 20:04:29.8249 -0400
OS Version:            macOS 12.4 (21F79)
Report Version:        12
Anonymous UUID:        6BF0DEE2-D7C2-1131-726F-27072A3AE4AA

Sleep/Wake UUID:       2E147BFE-8172-4B9A-BE71-32032B4A0532

Time Awake Since Boot: 700000 seconds
Time Since Wake:       2987 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes:       UNKNOWN_0x32 at 0x000000014db90000
Exception Codes:       0x0000000000000032, 0x000000014db90000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace CODESIGNING, Code 2

Related: https://github.com/prisma/prisma/issues/14058

A fix for the codesigning problem (or rather a workaround since it seems to be a macOS issue) is included in 4.1.0 and later, so this should be resolved now. I'm going to go ahead and close this issue, please feel free to reopen or create a new issue if you still run into this.


The implementation of LogValuesFormatter.Format will consume a data reader

There is a problem in LogValuesFormatter.Format:
    // if the value implements IEnumerable, build a comma separated string.
    var enumerable = value as IEnumerable;
    if (enumerable != null)
    {
        values[i] = string.Join(", ", enumerable.Cast<object>().Select(o => o ?? NullValue));
    }

if the value is a data reader, it will be consumed by the Select method and return nothing when the program reads records from it after logging.

Can you show your logging code, please? What are you intending to get logged when passing data reader to a .Log call?

The code comes from nhibernate example:
https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate.Example.Web/Infrastructure/NHibernateToMicrosoftLogger.cs
please look at line 30, it constructs a FormattedLogValues and the second can be a data reader. the data  will be eaten by the logger, nhibernate will fail to get data from it.

Any data structure that doesn't support reenumeration or enumeration of which has side effect should not be passed as logging parameter.

Hi. We're closing this issue as no response or updates have been provided in a timely manner and we have been unable to reproduce it. If you have more details and are encountering this issue please add a new reply and re-open the issue.


create:contract should automatically add to the deploy list

or perhaps add a --deploy flag? Please weigh in with comments on what the default behavior should be.

I think it should automatically add to the deploy list.

First things first: great job @tcoulter, truffle is a big step towards making Ethereum and its whole ecosystem accessible by anyone.
I'd ask how often does one create contracts that shouldn't be added to the deploy list?
If I find myself creating contracts and manually adding them to the deploy list very often then @christianlundkvist's suggestion makes a lot of sense.

This is no longer valid in Truffle 2.0. You now have way more control of your deployment. Try it out!


Challenge1-Dreidel

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

We checked out your repository. We're thrilled to say your solution is now listed in our Hall of Fame
Thank you for your contributions!
This PR is now closed! 🎉


Built in function gen improve

Summary
This is a draft PR used to get feedback on approaches.
In this PR the types were improved, Im looking for feedback on wether the functions payload mapped to FunctionsPayload type should be mapped to the ManifestFunctionSchema type and then translated to proper typescript files
In short payload -> FunctionsPayload  -> ManifestFunctionSchema -> typescript string
Alternatively the FunctionsPayload would be directly mapped to the typescript string. The advantage I saw in using the ManifestFunctionSchema is that the typescript string creates a file that defines a ManifestFunctionSchema. I am still unsure if this additional complexity will benefit us in the long run.
alternative: payload -> FunctionsPayload -> typescript string
Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

Is it correct to assume that the various generated function and test files in this PR come from running the new generation script?

Is it correct to assume that the various generated function and test files in this PR come from running the new generation script?

Yess exactly, still not sure if we want to include the changes in this PR or not, I might ask for the original function.json file in order to only generate the test of the existing functions

order to only generate the test of the existing functions

I think this makes sense, also easier to review this PR as it is only focussed on the generation (and not on the new additions)


Builder: Can't edit block when empty

CURRENTLY
When emptying a "block" inside an intent input or output, cursor disappear and it's not possible to edit the block.
SHOULD BE
Editing an empty block should be possible

done ?


Documentation:  contain_vars is in need of roxygen documentation

Please select a category the issue is focused on?
Function Documentation
Let us know where something needs a refresh or put your idea here!
contain_vars within the dev_utils.R file is in need of roxygen documentation

@bms63  I'm having trouble finding contain_vars in admiraldev


Add project schema to main

Add updates from new-project-schema to main
Change nwb NotImplementedError to logger.warning
Add docstrings to project schema
Version bump

Whoever merges this can you ping me? I'll update the workflow to use main.

Thanks @CBroz1! Please see my suggestions above.

Thanks for your review @kabilar. I've committed your suggestions


[FEATURE] make it easier to see what was committed vs what was selected

right now we already get the list of changed files that made it into the commit.
however, we might want to also see what the user selected to confirm that there were no changes (or mistakes) made)

now this object is pushed into the result field:
{
    "committed": [
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/block/copado-text.asset-block-meta.html",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/block/copado-text.asset-block-meta.json",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/cfa9a130-b1d7-4983-a45a-2cd25bc2528d/blocks/views.html.slots.[banner-8k6ramrq4nm].asset-message-meta.html",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/cfa9a130-b1d7-4983-a45a-2cd25bc2528d/cfa9a130-b1d7-4983-a45a-2cd25bc2528d.asset-message-meta.json",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/cfa9a130-b1d7-4983-a45a-2cd25bc2528d/index.asset-message-meta.html",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/script/copado-script.script-meta.json",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/script/copado-script.script-meta.ssjs"
    ],
    "noChangesFound": [
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/dataExtension/Daniel Ventura.dataExtension-meta.json",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/dataExtension/Daniel Ventura.dataExtension-doc.md",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/89506407-8021-4e9a-9a39-e89ef0223df9/89506407-8021-4e9a-9a39-e89ef0223df9.asset-message-meta.json",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/89506407-8021-4e9a-9a39-e89ef0223df9/index.asset-message-meta.html",
        "retrieve/Copado-MarkClDevOps/MCDEV_Training_Source/asset/message/89506407-8021-4e9a-9a39-e89ef0223df9/blocks/views.html.slots.[main-1g3ipxuqupn].asset-message-meta.html"
    ]
}


display supervisors and authors together

Coverage increased (+0.3%) to 67.045% when pulling 4ddbf2b9ddb56d354118ba11866ae9c1b596a037 on harunurhan:supervisor-authors-together into 49b0ea6edc57fe8263efe5a6e73cce3a6a6c4687 on inspirehep:master.


Use string formatter for Currency where appropriate

Fixes #2794

Coverage remained the same at 68.495% when pulling dab05aeafddeef9458bc927b586c168c6bd00cd4 on asauber:fix-object-prices into 74228f0d7f6b00a65b265fc312ff72dbb001fb63 on linode:develop.


SolrDoc should have a "property" class method

This would look like:
   property :title, 'title_tesim'

https://github.com/projectblacklight/blacklight/pull/1659


Speedup by parsing models smarter, not harder

We have one namespace with Very Large entities in its responses, and that swagger doc endpoint began timing out behind our gateway, breaking Swagger UI.
I tracked it down to one line being run in a loop that (seemingly) didn't need to be. Moving it to after the loop brought it down from ~49 sec to ~4 sec on my laptop. Changing the models array from an Array to a Set brought it down to ~3 sec.
Existing tests pass, but I'm not sure of a great way to write one for this since the behavior remains the same. Well, functionally the same. The resulting JSON has the models in a different order, but I don't think that matters.

Very good, merging.


Expose flags for max-pods-calculator to set ceiling for low/high cpu nodes

Issue #, if available:
N/A
Description of changes:
Provide 3 flags that allow configuration of max-pods for low/high cpu nodes.
--max-pods-ceiling-low-cpu specify the ceiling value of max-pods for nodes with low CPU (default - 110).
--max-pods-ceiling-high-cpu specify the ceiling value of max-pods for nodes with high CPU (default - 250).
--high-cpu-threshold specify the threshold of CPU cores that determine if a node is considered a high CPU (default - 30).

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

Closing in favor of #759


chore: Place types first in exports

As recommended by https://publint.dev/rules#exports_types_should_be_first

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@a95bb87). Click here to learn what that means.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff            @@
##             main       #43   +/-   ##
========================================
  Coverage        ?   100.00%
========================================
  Files           ?         1
  Lines           ?         9
  Branches        ?         2
========================================
  Hits            ?         9
  Misses          ?         0
  Partials        ?         0

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


Support for Audio in Chat Completions API

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 74.02597% with 20 lines in your changes missing coverage. Please review.

Project coverage is 92.24%. Comparing base (f46c7c1) to head (bc876f3).

Files with missing lines
Patch %
Lines

...github/sashirestela/openai/support/Base64Util.java
39.13%
13 Missing and 1 partial :warning:

...ashirestela/openai/common/content/ContentPart.java
70.58%
5 Missing :warning:

...b/sashirestela/openai/domain/chat/ChatMessage.java
87.50%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##               main     #202      +/-   ##
============================================
- Coverage     94.51%   92.24%   -2.28%
- Complexity      144      149       +5
============================================
  Files            54       58       +4
  Lines           638      696      +58
  Branches         30       31       +1
============================================
+ Hits            603      642      +39
- Misses           22       40      +18
- Partials         13       14       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


#101 bump version of swagger-parser, fix and kotlinize test

Closes #101

Great @mkulak
Can you shortly point out what you've changed to fix the test?
And kudos for Kotlin :)

@fmueller
Initial version of this test had strong dependency on ordering of Swagger.paths (which has type Map). I just replaced it with order-independent assertion.

👍

👍

👍

👍

👍


Update Kitefaster Blog links

Thanks for this. I see that the old links no longer work but the new links include both iOS and Android posts. I've merged this as it's better to have working links, but are there URLs you have that limit the posts to just iOS related ones like the last ones did?
Thanks
Dave


No sane way to handle closed InputStream with Observable.fromInputStream

I am attempting to use Observable to handle InputStream's which are the result of java.lang.Process. Java's Process exposes two streams, the STDOUT stream and the STDERR stream. If the process is running successfully then the InputStream for STDERR will already be closed (and vice versa)
The problem is that appears Monix Observable is unable to properly handle a closed stream. When you try to read from a closed stream that is already closed you get a java.io.IOException: Stream closed however there is no way to catch this error. Functions such as onErrorRecover or onErrorHandle (or their variants) don't work.
The intention is to do something like this
val inputStreamObservable =
  Observable
    .fromInputStream(processTask.map(_.getInputStream))
    .map(bytes => Right(new String(bytes)): Either[String, String]).onErrorRecoverWith {
    case _: IOException => Observable.never
  }

val errorStreamObservable =
  Observable
    .fromInputStream(processTask.map(_.getErrorStream))
    .map(bytes => Left(new String(bytes)): Either[String, String]).onErrorRecoverWith {
    case _: IOException => Observable.never
  }

Observable
  // We want to get either the error if it exists on STDERR otherwise we just want STDIN
  .firstStartedOf(inputStreamObservable, errorStreamObservable)

Basically I want to have an Observable which holds an Either, if its a Left then we have a STDERR and if its right then we have STDOUT

I haven't implemented something like this myself, but if I was I would use nuprocess instead of java.lang.Process because it heavily simplifies the handling of process output streams. You can just implement your own NuAbstractProcessHandler and have onStdout and onStderr push the contents to your own observer and then consume it with observable.

I am having issues replicating this outside of the context of work project, so I need to investigate it.
@jvican Thanks for the tip, will look into https://github.com/brettwooldridge/NuProcess

I'm going to close this since I can't sanely reproduce, will reopen if I discover something new


Seeking Maintainers

Bug description
I no longer have time to maintain Tom Select
Expected behavior
We need one (or more) experienced TS developers with spare time to take over
Steps to reproduce
Start open source project, invest time, work/life take over, os project suffers...
Additional context
Who made this issue tracker anyways!

👋 I use this library and IMO it's the best option for someone not looking to drag in React/etc. While I candidly can't commit huge amounts of time (so I definitely won't be doing wholesale refactors/rewrites), I'd love to help fix up small bugs.
I'm currently facing https://github.com/orchidjs/unicode-variants/issues/2, which is a blocker for me since it's a transitive dependency of tom-select. That's a separate project, but still under the same org, so I'm hopeful that I could contribute fixes there as well.
Could you clarify what level of involvement you're looking for in a maintainer? That is, if I can submit PRs, test my own code, prove that it's working as intended, and so on, are you willing to rubber-stamp, merge, and publish to npm? Or are you looking for someone to take full repo/npm permissions? I'd prefer the former, but would be willing to do the latter if required.

Looking for the latter. There are quite a few existing pull requests and issues that need attention.

Gotcha. It looks like the existing PRs aren't horribly complex. I'd like to volunteer, though hopefully some others can chip in to share the load as well.

@oyejorge I got the org invite - thanks! How do you want to handle npm publishes?

Perfect, thank you. I accepted it. How about for other packages like https://github.com/orchidjs/unicode-variants?

Many thanks! I should be good now. Assuming there's no one else to review my own changes, I'll go ahead and start doing things, sound good? Hopefully I manage to not break anything 🙂

This is awesome. I use tom-select and its one of the best libraries out there. I am not a js/ts expert but will keep an eye on issues and see if I can contribute. Thanks for taking this on @nwalters512

I agree, from my point of view it is one of the best libraries for fancy selects. Thanks @nwalters512 for taking over and thanks @oyejorge for all the effort you put into it.

@oyejorge Thank you for creating this library! I've enjoyed using it in my projects for nearly 2 years ❤
@nwalters512 Thank you for taking this on! I am glad we can continue using Tom Select 😊


Set up docs

Set up docs.
TODO:

[x] Get secret tokens
[ ] Add library to Hub docs
[x] Add library version to hf-doc-build/doc-build

https://huggingface.co/datasets/hf-doc-build/doc-build/discussions/28

[ ] Add library crawler in docs
[ ] Add thumbnail

@clefourrier I do not have write access permission.
Could you please merge this PR? We need the GH Action to upload the docs to be in the main branch for it to work (in the following PRs).
Reply by @regisss:

The doc is actually built but not uploaded. That happens because the doc upload workflow is not part of the main branch (yet).
So, if you merge PR #403, PR docs should be uploaded properly once they are built.

Alternatively, we could merge the GH Actions in a separate PR and check the resulting docs in this PR before merging it.
Thanks again @regisss for the advice.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Yes, but the docs will not be deployed to the prod docs yet. The PRs on the Hub backend need to be merged first.

Docs in production: https://huggingface.co/docs/lighteval/index
No link to them yet from: https://huggingface.co/docs

The PRs on the Hub backend need to be merged

Haaaa :disappointed:
Still quite good though!

If you have a min (tmr ofc), it would be great to check how we can get the cool autodocs from the docstrings, I think there's a lib to run/add somewhere

Sure, @clefourrier! It was in my TODO list. Indeed, I was looking for these class/function docs when I started using lighteval and suggested to set up its docs.


Update README.md

Expanding on the package installation instructions and adding a troubleshooting solution for Rust installation.

Closing this since there hasn't been activity for a while. Feel free to reopen if needed.