Single Item pages for Workflow | Process | Template | Document

Items in the above categories are increasingly becoming many, as our users are bound to create as many items as they want.
To enhance their experience of accessing the items. Make changes as per the requirement.

Build

The items in the sidebar should point to a single page.

If I click drafts under templates then it should take me to a draft templates page
if I click saved process under Processes then it should take me to saved process page

Please note that clicking every item in dropdown should take me to a page and not a section in an individual page.

This issue has been addressed in this commit: https://github.com/LL04-Finance-Dowell/100018-dowellWorkflowAi-testing/issues/49


drivers: regulator: add support for AXP2101 power management IC

Add initial support for the AXP2101 power management IC from X-powers

This is a duplicate of #78098?

This is a duplicate of #78098?

Indeed, sorry, didn't check before submitting this one.

@kartben @gmarull @soburi
I compared the drivers, they have similar functionality except that ranranff added the work mode setting.
Should I add the workmode setting here or fix ranranffs driver?
(why can't I mention @ranranff here?)

@lfelten
Your and Ranranff's codes are obviously similar because they are copied from regulator_axp192.c. Since the implementation is almost the same, and only the definition is different, I think it is preferable to support it as an extension of regulator_axp192.c.
I tried making something based on your code.
https://github.com/soburi/zephyr/commit/6c74c9dd58c320bae97c58415aee1402255f5b4e
(And one previous commit.)
I have yet to test it, but I hope it helps.

@soburi
Thanks!
I have a patch that adds the sets the workmode for this driver (#82474).
I can test it on one board, but that only uses some DC/DC and LDOs.

@lfelten
Your and Ranranff's codes are obviously similar because they are copied from regulator_axp192.c. Since the implementation is almost the same, and only the definition is different, I think it is preferable to support it as an extension of regulator_axp192.c.
I tried making something based on your code.
soburi@6c74c9d (And one previous commit.)
I have yet to test it, but I hope it helps.

@soburi
The logging was still per instance. @gmarull asked to remove this as usually there is only one PMIC on a board/design.
The tests on my board were successful.

LGTM.
It would help if you still addressed pointed by @gmarull #82474 (comment).

Thanks!
Sorry, that got lost while merging. I added a new version (this is the only change).

@gmarull
Could you take a look if you have a while, please?

x-powers,axp2101-regulator.yaml updated.

Rebased to main, the SMP related build failure was fixed (thanks @sylvioalves !)
Now there is a crypto related issue.


Negative BV literals?

When I write something like -1bv32, Boogie complains that I'm using the - operator with something that's not an int. I can express the same value by writing the positive signed number with the same bit-pattern and relying on wraparound, but is that the best way to write negative signed fixed-width integer literals in Boogie?

If unary negation is not natively supported on bitvectors, then I suppose you have to encode it yourself. You could try the binary negation 0 - 1bv32. Does that work?

Closing as resolved for now. Please reopen if you are still stuck.


Support preserving auto size

It enables a resizable box to keep a flexible dimension for width and height.
For example:
<Resizable
    width={100}
    height="auto"
    isResizable={ { right: true } }
/>

With this auto property, the box will preserve height: auto style after resizing its width.

@noradaiko thanks!!
It is great!! I confirmed that it is set to auto.
But can not resize box.  It work properly i your env?

In the example above, only width of the box can be resized.
The property set auto can't be resized and should be determined by its content and parent element(e.g., flexbox).
Isn't it working?

@noradaiko Oh. sorry. I misunderstood....
It looks good to me. thanks!!

released v1.4.1

thanks. love your work!


[BUG] Unnecessary WARN floods our logs when checking for an absent blob

Describe the bug
A clear and concise description of what the bug is.
When we call getProperties on an absent blob, the http response does not have content-type.
The serializerEncoding complains of the missing content-type and this floods our logs.
We cannot turn off WARN so this must be fixed on the azure-sdk side.
Exception or Stack Trace
Add the exception log and stack trace if available
2023/10/10 07:59:40.079 WARN [SerializerEncoding] [reactor-http-epoll-2] [ambry-vcr] [] 'Content-Type' not found. Returning default encoding: JSON
2023/10/10 07:59:40.079 ERROR [AzureCloudDestinationSync] [VcrReplicaThread-Intra-0-ei4] [ambry-vcr] [] Failed to get blob properties for (ambry-ei-1037/AAYQAwCLAAIAAQAAAAAAAAQN1bT-AAP7TRaeusluyYE8Fw) from Azure blob storage due to Status code 404, (BlobNotFound)

To Reproduce
Steps to reproduce the behavior:
Simply call getProperties on an absent blob like so
      return azureStorageClient.getBlobContainerClient(containerName).getBlobClient(blobFilePath).getProperties();\

Code Snippet
Add the code snippet that causes the issue.
    /**
     * Determines the serializer encoding to use based on the Content-Type header.
     *
     * @param headers the headers to check the encoding for.
     * @return the serializer encoding to use for the body. {@link #JSON} if there is no Content-Type header or an
     * unrecognized Content-Type encoding is returned.
     */
    public static SerializerEncoding fromHeaders(HttpHeaders headers) {
        final String mimeContentType = HttpHeadersHelper.getValueNoKeyFormatting(headers, "content-type");
        if (mimeContentType == null || mimeContentType.isEmpty()) {
            LOGGER.warning("'{}' not found. Returning default encoding: {}", CONTENT_TYPE, DEFAULT_ENCODING);
            return DEFAULT_ENCODING;
        }

Expected behavior
A clear and concise description of what you expected to happen.
No WARNINGS !
Screenshots
If applicable, add screenshots to help explain your problem.
Setup (please complete the following information):

OS: [e.g. iOS] CentOS 7
IDE: [e.g. IntelliJ]
Library/Libraries: [e.g. com.azure:azure-core:1.16.0 (groupId:artifactId:version)] azure-core-1.34.0.jar
Java version: [e.g. 8] JDK 11
App Server/Environment: [e.g. Tomcat, WildFly, Azure Function, Apache Spark, Databricks, IDE plugin or anything special]
Frameworks: [e.g. Spring Boot, Micronaut, Quarkus, etc]

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

verbose dependency tree (mvn dependency:tree -Dverbose)
exception message, full stack trace, and any available logs

Additional context
Add any other context about the problem here.
Similar ticket (not from me) https://github.com/Azure/Azurite/issues/2157
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x ] Bug Description Added
[ x] Repro Steps Added
[ x] Setup information Added

Thank you for filing this issue @snalli.
This should be fixed in a recent change (PR #37055) and should be available in an upcoming release of the Storage libraries.

@alzimmermsft i noticed the PR above doesn't update a CHANGELOG - it would be worth adding 1-line about this so it's more discoverable.

A Storage release should be done in the next week or so. In the meantime, another option, if you have access to the logging configurations, is excluding com.azure.core.util.serializer.SerializerEncoding from being able to log.

@alzimmermsft is there are new release of the storage sdk ?

@alzimmermsft is there are new release of the storage sdk ?

A new version of the Storage libraries shipped last night:
https://central.sonatype.com/artifact/com.azure/azure-storage-blob/12.24.1/dependencies


Price scaling in websocket API

The websocket docs say this, for the response structures where an order price is quoted:
"price is the price at which the order had offered to trade, scaled by a factor of 10000."
However in practice this is not the case. For XBT/GBP at least, the price is in fact scaled by a factor of 100. This is actually what is documented in the scale docs, so should I assume that it is 100 in all pairs? As you may appreciate, it is very difficult to test these things without risking money.

So in that vein, I definitely find the SCALES and websocket documents to be very confusing when taken together, as the former makes it sound like prices are encoded with a scale of 100 - which they are, but only when relative to the downscaled base currency. I think this needs to be cleared up.

Done in c71b34abe45d183e12cb20333341f5e224dfa993.


Docs unclear on which branch with config file is used for what

URL: https://packit.dev/docs/configuration/
I can read the following on this page:

Packit uses a configuration file in the upstream repository.

You should place the file in the root of your upstream repo.

When you open a pull request against your upstream repository, packit service picks up configuration file from your pull request, not from the branch against the PR is opened.

However, none of this tells me:

If any of the various jobs are used depending on the branch where the file is
Which parts of the config file are "taken from pull request" and used for things done with that pull request
Which parts of the file from which branch are used when I add a new release
If I can create a combination of some kind of job / defined on which branch / with whatever unknown keys under "job" ... to actually propose a downstream release, only to branched fedora

Based on irc conversation, my understanding is:

packit takes the config file from the commit/sha "associated" with the event that triggered packit
parts of config that aren't jobs are taken as is
the jobs are "filtered" according to the event type and branch (specified for each job in the config)
the remaining jobs (matching the event and branch) run

Why, thank you.

Sorry for the lack of response, we completely forgot to reply.
Sounds like it would be best to sit down and talk about how we should improve our documentation so it's more clear :)


2.x.x API Docs

Hi,
I am still using the 2.x version of swiper. Is there a copy of the old api docs somewhere?

It is the last topic of main Readme at https://github.com/nolimits4web/Swiper
https://github.com/nolimits4web/Swiper/blob/Swiper2/API.md

o weird, how did I miss that. thanks.


[WIP] Support Scout 9 and Laravel 9

@pmatseykanets any chance to merge this or https://github.com/pmatseykanets/laravel-scout-postgres/pull/47? 😊

@pmatseykanets any chance to merge this or #47? 😊

+1

I have just upgraded to scout 9 and it looks like it supports postgres straight out of the box. Seems this package is not needed anymore?


add starter of custom 404/422/500 routing

I rule and have completed some work on Case Manager that's ready for review!
Roughly following  https://westonganger.com/posts/creating-custom-error-pages-with-rails
This pull request makes the following changes:

removes stock rails error pages
adds custom error pages based on @emtot22 's mockups (thank you)

here's what they look like in practice, logged in and not:

You can try em out at localhost:3000/400, 422, 500
It relates to the following issue #s:

Fixes #2474

For reviewer:

Adjust the title to explain what it does for the notification email to the listserv.
Tag this PR:

feature if it contains a feature, fix, or similar. This is anything that contains a user-facing fix in some way, such as frontend changes, alterations to backend behavior, or bug fixes.
dependencies if it contains library upgrades or similar. This is anything that upgrades any dependency, such as a Gemfile update or npm package upgrade.

If it contains neither, no need to tag this PR.

Looks awesome!!


build: run browserstack on circleci

This is blocked for now because due to the GitHub issues, CircleCI is not able to run jobs for this PR.

CLA confirmed manually


test add integrate test

What this PR does:
test add integrate test
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report

Merging #183 (70e1c10) into develop (c01270e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #183   +/-   ##
========================================
  Coverage    43.19%   43.19%
========================================
  Files           33       33
  Lines         1755     1755
========================================
  Hits           758      758
  Misses         888      888
  Partials       109      109

Continue to review full report at Codecov.

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

pls fix the conflict.


[gobject-introspection] Fixed pkg-config file to follow vcpkg directory layout rule

Fixes #36275

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

@microsoft-github-policy-service agree

Usage test pass with following triplets:
x86-windows
x64-windows

Hey @iitaku, would you mind providing repro steps? Did cross compilation work before?

Hey @iitaku, would you mind providing repro steps? Did cross compilation work before?

No, because gobject-introspection currently does not support cross-builds

Approving since I've confirmed that before these changes the port is broken and afterwards it's fixed. Considering cross compilation didn't work before so this is a strict win for the port.

And still the proposed fixes were in the right direction, and the current fixes are just creating another bad example. Making it more work to eventually fix the port.


TLS termination doesn't pass valid ip address in forwardfor Headers.

Using ingress controller version 0.9.0.beta.5  TLS termination with a valid 3rd party certification correctly terminates the TLS connection and forwards HTTP to the client containers.  However when running an echo header container behind the service, I can see that the x-forwarded-for headers are not correct.
For example:
x-forwarded-for=<IP_ADDRESS>
x-forwarded-host=integration.foo.com
x-forwarded-port=443
x-forwarded-proto=https
x-original-uri=/
x-real-ip=<IP_ADDRESS>
x-scheme=https

Looking at the nginx.conf file that gets generated for this "server"
here is a snippet of that config:
https://gist.github.com/snoby/1da36de63972587b54dd7f77a6ae532b
My limited NGINX knowledge tells me that we have to use the line
listen 443 ssl proxy_protocol
I know that we are mapping 442 to 443 , but i don't see where we are doing the ssl proxy_protocol

I tried manually adding in the nginx config the proxy_protocol designation :
listen 442 ssl http2 proxy_protocol;
listen [::]:442  ssl http2 proxy_protocol;

However the server didn't pass the information correctly:
2017-05-04T14:26:56.741179954Z 2017/05/04 14:26:56 [warn] 185#185: *2316 using uninitialized "proxy_upstream_name" variable while logging request, client: <IP_ADDRESS>, server: integration.foo.com, request: "GET / HTTP/1.1", host: "integration.foo.com"
2017-05-04T14:26:56.741189161Z <IP_ADDRESS> - [<IP_ADDRESS>, <IP_ADDRESS>] - - [04/May/2017:14:26:56 +0000] "GET / HTTP/1.1" 301 186 "-" "curl/7.51.0" 210 0.000 [] - - - -
2017-05-04T14:27:28.704971806Z 2017/05/04 14:27:28 [warn] 182#182: *2311 using uninitialized "proxy_upstream_name" variable while logging request, client: <IP_ADDRESS>, server: integration.foo.com, request: "GET / HTTP/1.1", host: "integration.foo.com"

see #672, probably the same issue

Yes i agree it is #672

Could you please close this issue as a dup of #672?

Closing.


Update URLs in Readme

There is only one file changed, sorry for the long list of "merge"s

Thanks Jens! Cherry-picked and merged in https://github.com/fonttools/fonttools/commit/564b46000745f83b88ac1ff4a30e1afb67e45988.
You can avoid the many merge commits by having a clean branch which you rebase on fonttools/master instead of merging.

Thank you Denis, sometimes I feel like a git noob still ;)


[AST] Fix for SR-7: Inferring closure param type to inout crashes compiler

Diagnose a variable inferred to be inout, but without explicit ‘&’. This fixes https://bugs.swift.org/browse/SR-7.

Added a test, and ran all the tests.

Cool, thanks for tackling this.  That said, I don't think that this is the right solution.  It looks like the generated AST is:
   (closure_expr type='(inout Int) -> ()' location=t.swift:6:9 range=[t.swift:6:9 - line:6:22] discriminator=0 single-expression
      (call_expr type='()' location=t.swift:6:16 range=[t.swift:6:16 - line:6:20] nothrow
        (declref_expr type='(inout Int) -> ()' location=t.swift:6:16 range=[t.swift:6:16 - line:6:16] decl=t.(file).f0@t.swift:4:6 specialized=no)
        (paren_expr type='(inout Int)' location=t.swift:6:19 range=[t.swift:6:18 - line:6:20]
          (declref_expr type='inout Int' location=t.swift:6:19 range=[t.swift:6:19 - line:6:19] decl=t.(file).top-level code.explicit closure disarm

In this case, the better solution is to fix it so the DeclRefExpr isn't getting inout type in the first place.  Something in the formation of the CaptureExpr isn't properly converting the DRE's type to @lvalue Int.

btw, you can see this AST with: swiftc -parse -dump-ast t.swift

Yeah, I should've asked explicitly about that. Let me restate what I think you are saying: What is happening is that the constraint solver expects the argument to f() to be inout Int, so it matches the type variable for x to be inout Int. That looked dodgy to me, but I wasn't certain whether it ought to be expected or not, so the fix here looks at it after type solving is complete and then complains.
What ought to happen instead is that inout should never be part of the constraint in the first place, so x should be constrained to Int, and then it'll hit the existing missing ampersand check.
Which makes perfect sense and would be better, and is going to be harder for me to figure out how to do correctly. :-)

yep, exactly!  A DeclRefExpr should never have InOutType.  This would also be a great thing to add to the ASTVerifier if you're interested.

With this commit, this code:
func f(inout a: Int) {}
let g = { x in f(&x) }

...which previously compiled(!) with g typed as (inout Int) -> () now fails more correctly with an assertion:
Assertion failed: (E->getType()->isAssignableType() && "setting access kind on non-l-value"), function visit, file /Users/toon/GitHub/swift/lib/AST/Expr.cpp, line 207.

Okay, this looks better. All tests pass, with some changed error messages (as you can see in the test diffs). I think all are better except that it would be nice if expressions.swift:748 had the older error instead - now the compiler is thinking the result of the ternary ought to be Int and an ampersand is missing and complaining about that type mismatch instead of the old more direct errors.
You can see via the error messages, or via turning on -debug-constraints that the DeclRefs are getting the correct types now, and I've also added the never InOutType check to the verifier.

This sounds very promising, don't worry too much about diagnostics changes, I can improve them in a follow-up patch.  Can you please squash these patches into one diff I can review?  Thanks!

Oh never mind, I see how to see them as a unit...

Here are a couple nit-picky comments:

Please keep the indentation level at 2 spaces, in AST/Verifier.cpp
In a boolean context, please use "isa" instead of "dyn_cast".  If you are interested in these, their behavior is described here: http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates
Feel free to propose the verifier patch as a standalone patch separate from the other work.  Have you run the test suite to make sure it doesn't expose any other breakage?

More significantly, I'm not certain that the change you're proposing to the type checker is the right place to do it.  Instead of putting it in constraint inference, it seems more natural to go into the place which is assigning a type to the DeclRefExpr.  I will poke at this more to try to understand it better (I am not an expert on this part of the constraint solver) and get back to you.

Ok, after digging in a bit more, this is yet-another really unfortunate issue related to how we're modeling "&" in the AST.  IMO it shouldn't be an explicit expr, and we shouldn't have inout type at all, the & should be part of the ApplyExpr representation for the call.  However, that is a medium term rework of much of the compiler that is on my todo list, so not really relevant to getting this issue fixed :-)
I think the best and simplest place to enforce this is in CSApply.cpp, in buildDeclRef.  I think you should be able to add this check that "!type->is()" between these lines at the bottom:
  auto type = simplifyType(openedType);
  return new (ctx) DeclRefExpr(decl, loc, implicit, semantics, type);

And then have it produce an error message.  Getting a useful error message will be tricky, but the first order of business is to fix the crash.  Thank you for working on this!
-Chris

Thanks, I'll go take a look there! I agree, since the "&" explicitly can't be used anywhere besides directly at the call param site it seems like having inout as part of the type (anywhere besides Params) gets in the way a lot more than it helps.

Getting the diagnoses of the problem back out is a bit inelegant here, since the ExprRewriter gets run after a constraint solution has been chosen (and is const), so the existing mechanism of adding a Fix won't work by itself. So there's a manual call to diagnose() to emit the error, and then adding the Fix just serves as a signal back out to applySolution() that there was a problem after all. It could be a flag on ExprRewriter that gets set instead, if that seems cleaner.
What do you think? If this looks good to you, I'll clean up the commented out bits and a few of the test error results have slightly changed again, and resquash the commits.

Fixed and commits squashed and ran tests! This was definitely the right place to do it, thanks for the hint, and sorry for the false starts.

Fantastic, looks great.  Minor nit-picky stuff, we usually capitalize local variable contractions like "TC" for type checker.  I'll fix that in a followup patch, thank you for doing this!
-Chris

Please also close SR-7 when you have a chance, thanks again!

actually, I retract that, I see that file is using lowercase "tc" consistently.  Thank you for following its local policy.

Thanks for the fix! Nitpick: in the future, please make the "title" (first line) of your commit message stand on its own, so that others don't have to read the full message or go to the bug tracker to know what's going on.

Will do, thanks!


Is .container functional in v1?

I've been giving a try to the new version without any issue until .container.
It doesn't seem to work. Leaving empty stylesheet.

Hey @azdanov. Plugins are not supported, sorry. I’ll look at making that more clear in the readme.

@bradlc I'm curious what are the technical reason for this, and what other plugins Tailwind CSS has?

I should correct my previous comment: in more recent versions of Tailwind technically everything is a plugin. I guess what I really mean is that the babel plugin doesn’t support components (like .container) or third-party plugins
I don’t think this project will ever support components, but there might be a way to support utilities created by third-party plugins.

Any Update on Supporting third party/custom plugins of tailwind in macros.


Graph calculation crashes if not all cobra dependencies are listed in the root app's Gemfile

Gems that are only used for testing in certain gems might not be included in the main app's Gemfile. If this is the case the app crashes on trying to insert a node for that gem.
Could this apply in other situations as well?

This is fixed by 6470887e1b41a3eeb0d96d9d4dcd2221faf0dfa7 and gem version 0.2.1


[Bug]: Response Format selection section to stay for JSON & RAW when data is scrolled

Is there an existing issue for this?

[X] I have searched the existing issues

Description
https://user-images.githubusercontent.com/91450662/168021099-655c10b5-e561-4b83-b143-f51d5352099b.mov
Steps To Reproduce

Query an api which can give data in Table format
Observe: Different views are available for user to view the response - Table, Json, Raw
Scroll through the Table response - Observe View tabs stay intact
Scroll through JSON response - Observe - the View selection tabs also go out of view & user needs to scroll to top to switch view
Same observed for Raw format also
Expected: View tabs should be visible irrespective of scrolling of the long response & user should be seamlessly able to switch views at any point of time !

Public Sample App
No response
Version
Prod/Release v1.6.26

REST 6m usage: 4000
Applying 50% requirement: 2000
Stats

Stat
Values

Reach
2000

Effort (months)
0.25


Introduce a new 'bytes' form of the string_literal SIL instruction [upstream from TF]

Have it print and parse as a stable hexadecimal form that isn't interpreted as UTF8.
One use case is in representing serialized protobuf strings (as in the
tensorflow branch: https://github.com/apple/swift/blob/f7ed452ebaabb21c866b110a885f0d8afd280ee1/lib/SILOptimizer/Mandatory/TFPartition.cpp#L3875).
The original work was done by @lattner and merged into the tensorflow
branch (https://github.com/apple/swift/commit/190a94b5c78d5c9543eda05cd164f862e827bc03). This PR is to upstream those changes.

@lattner, who else should we loop in for review?
Also I'd be happy to add a test case if needed -- should it be at SIL level, and are there relevant existing tests that I can follow / adapt?

@swift-ci please test tensorflow

I haven't done a full review (and may not be the true reviewer)... but you need tests here.

It would be great for @jckarter or @rjmccall to give conceptual approval, I discussed this with them.

@swift-ci please smoke test

Patch LGTM, I agree with @gottesmm that this should have a .sil testcase to show round-tripping.
Thank you for upstreaming this!!

@lattner and I had discussed this briefly in person. It seems to me that there shouldn't need to be a difference at the SIL level between "bytes" and "UTF-8" string literals. SIL for the most part shouldn't care about the encoding of the string literal.

@jckarter there are two problems here:

The sil printer is broken, it doesn't print string literals in a round trippable way.
For non-string contents like protocol buffers, poor compiler engineers don't want to see random gibberish.  The hex format of this is a lot more compact and nicer to work with.

I agree that #1 should be fixed in principle, but it still doesn't take away from #2.  This is also a very small/simple/non-invasive patch.  What is your specific concern?

I'm generally concerned about adding complexity; most passes that look at string_literal instructions shouldn't have to care about the difference here. Both of your concerns seem to me like presentation issues. Could we add a separate "print as hex" representation bit that doesn't otherwise change the semantic meaning of the instruction, only the printing behavior, or use a heuristic in the printer to decide to print in hex if the literal contains bytes in the 0x01...0x1F range or invalid UTF-8?

Do we not have any interest in having the UTF-8 encoding maintain a rule that it's actually a valid UTF-8 encoding, at least at the simple, structural level?  That seems like a reasonable expectation to me and would justify having a separate bytes encoding.

@jckarter Thank you for being a rigorous gate-keeper on added complexity. I strive to do the same. In this case my sense is that the added complexity is fairly minimal, and with the existing set of string literal encodings, it is unlikely that we'll be adding a lot more in the future.
I agree that if we start from scratch, separating the underlying representation from printing/presentation matters would be useful.
I just updated this PR with a unit test. PTAL.

@swift-ci please smoke test

I think it would be a mistake to drop the utf-8 encoding.  I'm fine with this approach.

I understand the point about complexity, but it is worth pointing out that pretty much nothing in the compiler looks at the contents of string literals :-), just emission to IRGen and the sil printer.

Yeah, looks that way. UTF16 vs other encodings does affect the size of the null terminator we stick on the end, but I agree in principle it mostly makes sense to treat this as a bag of bytes. In that case, the encoding is already primarily a presentation flag, so I'm fine adding another presentation form.

Nice, thank you @gottesmm!

Thank you @gottesmm! Is there any additional feedback (from anyone) that I should address?

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - ba38bcb279696e0239c6f3c93980ba020888360c

Build failed
Swift Test OS X Platform
Git Sha - ba38bcb279696e0239c6f3c93980ba020888360c

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - e18fbd4c86affaa4b36d8f9f4f4f1735d50544e5

Build failed
Swift Test Linux Platform
Git Sha - e18fbd4c86affaa4b36d8f9f4f4f1735d50544e5

Thanks everyone! Looks like all feedback has been addressed. Please feel free to merge the PR, or I can do so on Monday.

@swift-ci please test and merge


serverless set up

Hey, I'm really interested in the serverless set up - do you think you could include the terraform scripts in the repo or a gist? I tried following the instructions but got lost - I think the script will be a bit more explicit.
Great boilerplate btw

I recommend preact-cli / PR #11, lots of work done for serverless
prerendering.
Am 01.06.2017 10:06 schrieb "Copple"<EMAIL_ADDRESS>
Hey, I'm really interested in the serverless set up - do you think you
could include the terraform scripts in the repo or a gist? I tried
following the instructions but got lost - I think the script will be a bit
more explicit.
Great boilerplate btw
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/BerndWessels/preact-redux-isomorphic/issues/3, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAepgoq3EnhV8GlviwsR_6jaxzZ4bO_7ks5r_nEHgaJpZM4NsoKJ
.

@kiwicopple You can find a complete example with terraform infrastructure here.
It automatically builds the domain and complete infrastructure for it and the preact website in a Lambda with SSR and static resources in S3. Its live at wessels.nz
Let me know what you think and if you have any more questions.

This is a really great set of scripts, thanks @BerndWessels !!
Perhaps one more question - I have the cloudfront distro set up, but I'm getting errors when I try to access it via my website. I have Route53 Record Set with an Alias target that is equal to the cloudfront URL, but I can't quite figure it out.
I'll drop the full set of steps I took below, since I figure someone else may find them useful. My first time with terraform, it was quite enjoyable
Prereq's

Make sure you have created an IAM role with AWSLambdaBasicExecutionRole and CloudWatchLogsFullAccess
Make sure you have added your ssh key to your github account (this is required for the terraform get command later)
Create a certificate for your domain if you don't already have one using AWS Certificate manager (this had to be in the us-east-1 region for some reason?)

Instructions

Fork repo - https://github.com/wessels-nz/infrastructure-modules (this is required for the terraform get command later)
clone the repo to local
cd platform-api - this is the "master" terraform
terraform get - this will pull down all the required submodules for the master terraform
Create a file in this folder that is called prod.tfvars that has the terraform vars (example below)
Run terraform apply -var-file="prod.tfvars"
upload /Path/to/preact-redux-isomorphic/dist/client/* into the newly created bucket in a subfolder _
wait for the cloudfront distro to populate completely
point your DNS to the new cloudfront distro's domain name
visit website (this is the part I am getting an error, could have something to do with Cert, but i'm not sure how to diagnose the problem yet)
send thanks to @BerndWessels

Example prod.tfvars
domain_certificate_arn = "arn:aws:acm:us-east-1:XXXX:certificate/XXX-XX-XXX-XXX"
domain_name = "app.yourdomain.com"
region = "ap-southeast-1"
stage_description = "Production website"
stage_name = "live"
website_lambda_filename = "/Path/to/preact-redux-isomorphic/dist/Archive.zip"
website_lambda_role_arn = "arn:aws:iam::XXXX:role/service-role/XXXXNAME"

Looks like it may have resolved itself. Perhaps just a propagation issue - feel free to close this one off


Trajectory class.

Trajectory class is added to read/write xyz trajectory files from Lammps simulations.

This closes #20

Codecov Report

Merging #21 into master will increase coverage by 8.27%.
The diff coverage is 98.65%.

@@            Coverage Diff             @@
##           master      #21      +/-   ##
==========================================
+ Coverage    49.1%   57.37%   +8.27%
==========================================
  Files          18       24       +6
  Lines        1000     1112     +112
==========================================
+ Hits          491      638     +147
+ Misses        509      474      -35

Impacted Files
Coverage Δ

thermof/trajectory/msd.py
0% <ø> (ø)

thermof/trajectory/__init__.py
100% <100%> (ø)

tests/test_trajectory_io.py
100% <100%> (ø)

tests/test_trajectory_change_atoms.py
100% <100%> (ø)

thermof/__init__.py
100% <100%> (ø)
:arrow_up:

thermof/trajectory/io.py
100% <100%> (ø)

tests/test_trajectory_stretch.py
100% <100%> (ø)

thermof/trajectory/trajectory.py
96.15% <96.15%> (ø)

... and 4 more

Continue to review full report at Codecov.

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

#26 is closed by 7163f3ff617d1b040145563f9bcd79b6df765a11
#25 is closed by adding subdivide method to Trajectory which can be used to create a new Trajectory object with selected atoms. Then the distances would only be calculated for the selected atoms.
#20, #22, #23 and #24 are also closed with this PR.


folding fails

In the following example there are two places where folding fails with esimp.
-- HoTT
open nat unit eq equiv

  definition code [reducible] [unfold 1 2] : ℕ → ℕ → Type₀
  | code 0 0               := unit
  | code (succ n) 0        := empty
  | code 0 (succ m)        := empty
  | code (succ n) (succ m) := code n m

  definition refl [unfold 1] : Πn, code n n
  | refl 0 := star
  | refl (succ n) := refl n

  definition encode [unfold 3] {n m : ℕ} (p : n = m) : code n m :=
  p ▸ refl n

  definition decode [unfold 1 2] : Π(n m : ℕ), code n m → n = m
  | decode 0 0               := λc, idp
  | decode 0 (succ l)        := λc, empty.elim c _
  | decode (succ k) 0        := λc, empty.elim c _
  | decode (succ k) (succ l) := λc, ap succ (decode k l c)

  definition nat_eq_equiv (n m : ℕ) : (n = m) ≃ code n m :=
  equiv.MK encode
           !decode
           begin
             revert m, induction n, all_goals (intro m;induction m;all_goals intro c),
               all_goals try contradiction,
               induction c, reflexivity,
               try (esimp; state; now), exact sorry
           end
           begin
             intro p, induction p, esimp [encode], induction n,
               reflexivity,
               esimp, state, exact sorry
           end

I get the expected output when I remove the unfold attribute from refl and decode and unfold them manually:
open nat unit eq equiv

  definition code [reducible] [unfold 1 2] : ℕ → ℕ → Type₀
  | code 0 0               := unit
  | code (succ n) 0        := empty
  | code 0 (succ m)        := empty
  | code (succ n) (succ m) := code n m

  definition refl : Πn, code n n
  | refl 0 := star
  | refl (succ n) := refl n

  definition encode [unfold 3] {n m : ℕ} (p : n = m) : code n m :=
  p ▸ refl n

  definition decode : Π(n m : ℕ), code n m → n = m
  | decode 0 0               := λc, idp
  | decode 0 (succ l)        := λc, empty.elim c _
  | decode (succ k) 0        := λc, empty.elim c _
  | decode (succ k) (succ l) := λc, ap succ (decode k l c)

  definition nat_eq_equiv (n m : ℕ) : (n = m) ≃ code n m :=
  equiv.MK encode
           !decode
           begin
             revert m, induction n, all_goals (intro m;induction m;all_goals intro c),
               all_goals try contradiction,
               induction c, reflexivity,
               try (state; unfold decode; state; now), exact sorry
           end
           begin
             intro p, induction p, esimp [encode], induction n,
               reflexivity,
               state, unfold [decode, refl], state, exact sorry
           end

The "automatic folding of nested recursive application" is only performed when we explicitly unfold functions using esimp [f] or unfold f.

Ah, I see. I misunderstood the feature. I thought that it also happened when we write esimp and functions were unfolded because they have the unfold attribute.
I think it would be nice if that feature was also added.

I'm closing this one. Reason: the esimp command will eventually be replaced by the simp tactic that only produces rfl proofs. It is more flexible and powerful than esimp. So, it doesn't make sense for us to invest energy in code that will become obsolete.
In the meantime, we should provide the functions explicitly.


Docker activity logs secrets

Question, Bug, or Feature?
Type: BUG
Enter Task Name: DOCKER
Environment
AZURE PIPELINES,
acct MSENG
project: SPACE
pipeline: https://dev.azure.com/mseng/1ES/_build?definitionId=10355&_a=summary
agent: ubuntu-20.04
Issue Description
I am looking into our docker command task is logging some secrets that are passed on the command line.
I am not sure if the issue is in the task or the task caller. The secret is fetched in a prior task and set like this:
echo "##vso[task.setvariable variable=secret.docDbKey;issecret=true]$docDbKey"

and it is passed to the Docker task in the Arguments field (UI pipeline, not yaml) as
-e docDbKey="$(secret.docDbKey)"

this is how the logging looks

The docker task doesn't explicitly handle the masking of secrets. The masking is taken care of by the agent while parsing the raw pipeline logs.
@damccorm could you take a look?

The docker task doesn't explicitly handle the masking of secrets. The masking is taken care of by the agent while parsing the raw pipeline logs.
@damccorm could you take a look?

@ds-ms my guess is that the secret is being modified somehow and isn't an exact match (e.g. some sort of escaping or whitespace is being injected). From the logging side we guarantee that the exact secret will be masked, but not modified variants - could you confirm that is the case?
In general, it is not a great idea to intentionally log secrets, I would consider not logging the value in this case regardless

@ds-ms my guess is that the secret is being modified somehow and isn't an exact match (e.g. some sort of escaping or whitespace is being injected). From the logging side we guarantee that the exact secret will be masked, but not modified variants - could you confirm that is the case?
In general, it is not a great idea to intentionally log secrets, I would consider not logging the value in this case regardless

Is it not matched because it is appended to docDbKey= and no longer whitespace delimited?
Also, would it be possible to surface a flag that pipeline authors could use to immediately suppress logging of the cmd string? This would allow a mitigation while the issue is being investigated. As it stands, I have no control over this at all. It would be great to treat this as high priority. Thanks!

Is it not matched because it is appended to docDbKey= and no longer whitespace delimited?
Also, would it be possible to surface a flag that pipeline authors could use to immediately suppress logging of the cmd string? This would allow a mitigation while the issue is being investigated. As it stands, I have no control over this at all. It would be great to treat this as high priority. Thanks!

I saw in debug logs (don't have the example any longer) where the secret WAS redacted in those logs but then not here. I have learned from that troubleshooting session that the args are converted into an array and I wonder if this text is built with something like array select so the secret-ness is lost? Please bump the priority, this is a serious leak and I have no mitigation.

@Ganeshrockz could you take a look at this?

Hi, is there any progress on this issue? Thanks!

@lygasch Apologies for the delay. Can you help me reproducing this one?
I tried with the following yaml
trigger:
- master

pool:
  vmImage: ubuntu-latest

steps:
- task: Bash@3
  inputs:
    targetType: 'inline'
    script: |
      docDbKey=Sample

      echo "##vso[task.setvariable variable=secret.docDbKey;issecret=true]$docDbKey"

- task: Docker@2
  inputs:
    containerRegistry: 'sample-acr'
    repository: 'sampleAcr'
    command: 'run'
    arguments: '-d key="$(secret.docDbKey)"'

The secret seems to be masked in this case. I believe your tasks also do something very similar right?

Perhaps it is working in that case because of the "key=" param name? (I am not sure how the secret detection works) Can you try with param name DocDbKey like we use?
I am not sure what you mean in your request about az cli logs. Feel free to ping me on Teams and we can chat. Thanks!


Distinguishing between a MAX6675 and a MAX31855 in a same circuit

Hello Mr. Tillaart,
"Pull a request" does not seems to work for me. So I am using "Issues" even though it is not an issues but a request. Thank you for your comprehension.
I have one (1) MAX6675 and one (1) MAX31855 in a same circuit. Is there a way, software wise, to peek at each of them and tell which is which ?
Thank you for you help.
Regards, R.J. Mercier

Thanks for the question.
Will come back to it later today.

There is one difference that come in my mind - (check the datasheet) -the MAX6675 does not do negative temperatures C.
in software you could write a function that uses the library to connect each of them and see if only one gives reasonable values.
Never tried, don't know if there are side effects - you need to check the datasheets for this.

Thank you Mr Tillaart. I will explore that avenue.
If other approach come to your mind, please do not hesitate to come back.
Regards,
René - Jean
Le mer. 2 août 2023 à 05:23, Rob Tillaart @.***> a
écrit :

There is one difference that come in my mind - (check the datasheet) -the
MAX6675 does not do negative temperatures C.
in software you could write a function that uses the library to connect
each of them and see if only one gives reasonable values.
Never tried, don't know if there are side effects - you need to check the
datasheets for this.
—
Reply to this email directly, view it on GitHub
https://github.com/RobTillaart/MAX6675/issues/5#issuecomment-1661853338,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVP34ETHGQHTKE6TF4N23XTIMALANCNFSM6AAAAAA3AOWJSY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi  René - Jean,
First please call me Rob,
I have thought about it and came up with the following code that might help / get you started.
Patch the libraries to make _read() public (.h file), so you can test with that too.

https://github.com/RobTillaart/MAX31855_RT
https://github.com/RobTillaart/MAX6675

The following code might give a clue due to differences in default status.
No hardware nearby to verify this idea, but the sketch compiles.
//    FILE: detect.ino
//  AUTHOR: Rob Tillaart
// PURPOSE:  detect TC type
//     URL:

#include "Arduino.h"

#include "MAX6675.h"
#include "MAX31855.h"

const int dataPin   = 7;
const int clockPin  = 6;
const int selectPin = 5;

void setup()
{
  Serial.begin(115200);
  Serial.println(__FILE__);

  Serial.println(is6675(), HEX);
  Serial.println(is31855(), HEX);
}

void loop()
{
}

uint32_t is6675()
{
  MAX6675 tc;
  tc.begin(clockPin, selectPin, dataPin);

  uint32_t stat = tc.read();       //  replace by _read()
  return stat;
}

uint32_t is31855()
{
  MAX31855 tc;
  tc.begin(clockPin, selectPin, dataPin);

  uint32_t stat = tc.read();       //  replace by _read()
  return stat;
}

// -- END OF FILE --

Hello Rob,
Unfortunately, I had dismantled my prototype board. I have to reassemble it
(give me a day or two) for that.
But I have a circuit already assembled with two (2) MAX31855. If I run the
following function (modified with the _read()), I get the following result
(see below the function and the results).
I will get back to you soon with the mix MAX6675 and MAX31855.
Thank you very much for your support.
Regards,
René-Jean
/****************************************************************************************/
/* PROBE THE THERMOCOUPLE(S) (2 MAX) (4 COMBINAISONS) AND LOG ITS/THEIR
PRESENCE        */
/****************************************************************************************/
void Hardware_Layer::checkThermocouplePresence() { // Establish
thermocouple presence. Up to 2 thermocouple via SPI-1
thermocoupleStatus.thermocoupleOneInstalled = (int)ThermocouplePresence
::thermocoupleNone;
thermocoupleStatus.thermocoupleTwoInstalled =
(int)ThermocouplePresence::thermocoupleNone;
int status;
for(;;) {
/*****************************************************/
thermocoupleOne_MAX31855.begin(THERMO_ONE_CS_PORT); // HW SPI initialization
status = thermocoupleOne_MAX31855._read();
DELAY_MS(1000);
Serial.print(F("Status of reading MAX31855 One is : ")); Serial.println(
status);
if (status == STATUS_OK && thermocoupleStatus.thermocoupleOneInstalled == (
int)ThermocouplePresence::thermocoupleNone) {
thermocoupleStatus.thermocoupleOneInstalled = (int)ThermocouplePresence
::thermocoupleOneMAX31855;
Serial.println(F("Thermocouple One is a MAX31855"));
DELAY_MS(2000);
}
/*****************************************************/
thermocoupleTwo_MAX31855.begin(THERMO_TWO_CS_PORT); // HW SPI
initialization
status = thermocoupleTwo_MAX31855._read();
DELAY_MS(1000);
Serial.print(F("Status of reading MAX31855 Two is : ")); Serial.println(
status);
if (status == STATUS_OK && thermocoupleStatus.thermocoupleTwoInstalled == (
int)ThermocouplePresence::thermocoupleNone) {
thermocoupleStatus.thermocoupleTwoInstalled = (int)ThermocouplePresence
::thermocoupleTwoMAX31855;
Serial.println(F("Thermocouple Two is a MAX6675"));
DELAY_MS(2000);
}
/*****************************************************/
thermocoupleOne_MAX6675.begin(THERMO_ONE_CS_PORT); // HW SPI initialization
status = thermocoupleOne_MAX6675._read();
DELAY_MS(1000);
Serial.print(F("Status of reading MAX6675 One is : ")); Serial.println(
status);
if (status == STATUS_OK && thermocoupleStatus.thermocoupleOneInstalled == (
int)ThermocouplePresence::thermocoupleNone) {
thermocoupleStatus.thermocoupleOneInstalled = (int)ThermocouplePresence
::thermocoupleOneMAX6675;
Serial.println(F("Thermocouple One is a MAX6675"));
DELAY_MS(2000);
}
/*****************************************************/
thermocoupleTwo_MAX6675.begin(THERMO_TWO_CS_PORT); // HW SPI initialization
status = thermocoupleTwo_MAX6675._read();
DELAY_MS(1000);
Serial.print(F("Status of reading MAX6675 Two is : ")); Serial.println(
status);
if (status == STATUS_OK && thermocoupleStatus.thermocoupleTwoInstalled == (
int)ThermocouplePresence::thermocoupleNone) {
thermocoupleStatus.thermocoupleTwoInstalled = (int)ThermocouplePresence
::thermocoupleTwoMAX6675;
Serial.println(F("Thermocouple Two is a MAX6675"));
DELAY_MS(2000);
}
Serial.print(F("\n"));
}
}
=============================
Result :
Status of reading MAX31855 One is : 30941904
Status of reading MAX31855 Two is : 31728640
Status of reading MAX6675 One is : 472
Status of reading MAX6675 Two is : 484
Status of reading MAX31855 One is : 30941888
Status of reading MAX31855 Two is : 31728640
Status of reading MAX6675 One is : 472
Status of reading MAX6675 Two is : 484
... and so on
Processor used STM32F401CE
Software tool : vsCode on PlatformIO.
Le mer. 2 août 2023, à 08 h 55, Rob Tillaart @.***> a
écrit :

Hi René - Jean,
First please call me Rob,
I have thought about it and came up with the following code that might
help / get you started.
Patch the libraries to make _read() public (.h file), so you can test with
that too.

https://github.com/RobTillaart/MAX31855_RT
https://github.com/RobTillaart/MAX6675

The following code might give a clue due to differences in default status.
No hardware nearby to verify this idea, but the sketch compiles.
//    FILE: detect.ino//  AUTHOR: Rob Tillaart// PURPOSE:  detect TC type//     URL:
#include "Arduino.h"
#include "MAX6675.h"
#include "MAX31855.h"
const int dataPin   = 7;const int clockPin  = 6;const int selectPin = 5;
void setup()
{
Serial.begin(115200);
Serial.println(FILE);
Serial.println(is6675(), HEX);
Serial.println(is31855(), HEX);
}
void loop()
{
}
uint32_t is6675()
{
MAX6675 tc;
tc.begin(clockPin, selectPin, dataPin);
uint32_t stat = tc.read();       //  replace by _read()
return stat;
}
uint32_t is31855()
{
MAX31855 tc;
tc.begin(clockPin, selectPin, dataPin);
uint32_t stat = tc.read();       //  replace by _read()
return stat;
}
// -- END OF FILE --
—
Reply to this email directly, view it on GitHub
https://github.com/RobTillaart/MAX6675/issues/5#issuecomment-1662162682,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVP34BVH52DCRSKMCKDG3XTJE3XANCNFSM6AAAAAA3AOWJSY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi Rob,
Here we are. Just a few modifications (see below).  I have used SPI
communication; I added function declarations and a delay (required for USB
serial communication settling). And, as per your request, _read() function.
MAX31855 is on port PB1 and MAX6675 is on port PB10 of and STM32F401CC
BlackPill.
Looking forward to your conclusions.
Regards,
René-Jean
====================================
// FILE: detect.ino
// AUTHOR: Rob Tillaart
// PURPOSE: detect TC type
// URL:
#include "Arduino.h"
#include "MAX6675.h"
#include "MAX31855.h"
/* Function Declaration */
uint32_t is6675();
uint32_t is31855();
// const int dataPin = 7;
// const int clockPin = 6;
// const int selectPin = 5;
void setup()
{
Serial.begin(115200);
delay(2000);
Serial.println(FILE);
Serial.println(is6675(), HEX);
Serial.println(is31855(), HEX);
}
void loop()
{
}
uint32_t is6675()
{
MAX6675 tc;
tc.begin(PB10);
uint32_t stat = tc._read(); // replace by _read()
return stat;
}
uint32_t is31855()
{
MAX31855 tc;
tc.begin(PB1);
uint32_t stat = tc._read(); // replace by _read()
return stat;
}
// -- END OF FILE --
=======================
Result of platformIO terminal :
--- Terminal on /dev/ttyACM0 | 230400 8-N-1
--- Available filters and text transformations: colorize, debug, default,
direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
Disconnected (device reports readiness to read but returned no data (device
disconnected or multiple access on port?))
Reconnecting to /dev/ttyACM0     Connected!
src/main.cpp
360
1941A50
Le mer. 2 août 2023, à 08 h 55, Rob Tillaart @.***> a
écrit :

Hi René - Jean,
First please call me Rob,
I have thought about it and came up with the following code that might
help / get you started.
Patch the libraries to make _read() public (.h file), so you can test with
that too.

https://github.com/RobTillaart/MAX31855_RT
https://github.com/RobTillaart/MAX6675

The following code might give a clue due to differences in default status.
No hardware nearby to verify this idea, but the sketch compiles.
//    FILE: detect.ino//  AUTHOR: Rob Tillaart// PURPOSE:  detect TC type//     URL:
#include "Arduino.h"
#include "MAX6675.h"
#include "MAX31855.h"
const int dataPin   = 7;const int clockPin  = 6;const int selectPin = 5;
void setup()
{
Serial.begin(115200);
Serial.println(FILE);
Serial.println(is6675(), HEX);
Serial.println(is31855(), HEX);
}
void loop()
{
}
uint32_t is6675()
{
MAX6675 tc;
tc.begin(clockPin, selectPin, dataPin);
uint32_t stat = tc.read();       //  replace by _read()
return stat;
}
uint32_t is31855()
{
MAX31855 tc;
tc.begin(clockPin, selectPin, dataPin);
uint32_t stat = tc.read();       //  replace by _read()
return stat;
}
// -- END OF FILE --
—
Reply to this email directly, view it on GitHub
https://github.com/RobTillaart/MAX6675/issues/5#issuecomment-1662162682,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVP34BVH52DCRSKMCKDG3XTJE3XANCNFSM6AAAAAA3AOWJSY
.
You are receiving this because you authored the thread.Message ID:
@.***>

so the output is
src/main.cpp
360
1941A50
looks different to me, however you only did half of the tests.
If you swap the devices (or the pins) and do the checks with the wrong device, what is the output then?

device
is6675
is31855

6675
360
?

31855
?
1941A50

And then you you should interpret the bit patterns

Hi Rob,
Of course! I should have known better.
Here is the program modified and the results with _read() and read()
functions.
Regards,
René-Jean
// FILE: detect.ino
// AUTHOR: Rob Tillaart
// PURPOSE: detect TC type
// URL:
#include "Arduino.h"
#include "MAX6675.h"
#include "MAX31855.h"
/* Function Declaration */
uint32_t is6675(uint32_t );
uint32_t is31855(uint32_t);
/* Macro substitutions */
const uint32_t MAX31855_PORT = PB1;
const uint32_t MAX6675_PORT = PB10;
/*********************************/
void setup()
{
Serial.begin(230400);
delay(2000);
Serial.println(FILE);
Serial.print(F("Peeking with _read() function :\n"));
Serial.print(F("MAX6675 with MAX6675 Dvr\t")); Serial.print(F("MAX6675 with
MAX31855 Dvr\t")); Serial.print(F("MAX31855 with MAX31855 Dvr\t")); Serial.
println(F("MAX31855 with MAX6675 Dvr"));
}
/*********************************/
void loop()
{
Serial.print(is6675(MAX6675_PORT), HEX); Serial.print(F("\t\t\t\t"));
delay(220);
Serial.print(is31855(MAX6675_PORT), HEX); Serial.print(F("\t\t\t\t"));
delay(220);
Serial.print(is31855(MAX31855_PORT), HEX); Serial.print(F("\t\t\t\t"));
delay(220);
Serial.print(is6675(MAX31855_PORT), HEX); Serial.print(F("\n"));
delay(1000);
}
/**********************************/
uint32_t is6675(uint32_t port)
{
MAX6675 tc;
tc.begin(port);
uint32_t stat = tc._read(); // replace by _read()
return stat;
}
/**********************************/
uint32_t is31855(uint32_t port)
{
MAX31855 tc;
tc.begin(port);
uint32_t stat = tc._read(); // replace by _read()
return stat;
}
// -- END OF FILE --
==================================================
src/main.cpp
Peeking with _read() function :
MAX6675 with MAX6675 Dvr        MAX6675 with MAX31855 Dvr       MAX31855
with MAX31855 Dvr      MAX31855 with MAX6675 Dvr
350                                               3500350
18C19D0                                        18C
350                                               3500350
19019D0                                        18C
348                                               3480348
18C19D0                                        18C
358                                               3300330
18C19D0                                        18C
358                                               3580358
18C19D0                                        18C
340                                               3480348
18C19C0                                        18C
350                                               3500350
18C19C0                                        18C
340                                               3400340
18C19C0                                        18C
350                                               3580358
18C19C0                                        18C
348                                               3500350
18C19C0                                        18C
350                                               3500350
18C19C0                                        18C
360                                               3400340
18C19C0                                        18C
==================================================
src/main.cpp
Peeking with read() function :
MAX6675 with MAX6675 Dvr        MAX6675 with MAX31855 Dvr       MAX31855
with MAX31855 Dvr      MAX31855 with MAX6675 Dvr
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
0                                                   0
0
4
==================================================
Le ven. 4 août 2023, à 06 h 25, Rob Tillaart @.***> a
écrit :

so the output is
src/main.cpp
360
1941A50
looks different to me, however you only did half of the tests.
If you swap the devices (or the pins) and do the checks with the wrong
device, what is the output then?
device is6675 is31855
6675 360 ?
31855 ? 1941A50
And then you you should interpret the bit patterns
—
Reply to this email directly, view it on GitHub
https://github.com/RobTillaart/MAX6675/issues/5#issuecomment-1665383873,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVP3ZRMX5I4KGYQQO2HK3XTTEYHANCNFSM6AAAAAA3AOWJSY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Seems that the values are distinct if you read 32 bits ==> is31855() test

Hi Rob,
Sorry for the delay in answering. This is summer in Québec/Canada ... and
summer is short to complete work outside while there is no rain.
That approach does the job!
Thank you so much for your support.
You might want to add to your MAX6675 and MAX31855 examples to help others
faced with the same question/problem.
Regards,
René-Jean
Le ven. 4 août 2023, à 11 h 49, Rob Tillaart @.***> a
écrit :

Seems that the values are distinct if you read 32 bits ==> is31855() test
—
Reply to this email directly, view it on GitHub
https://github.com/RobTillaart/MAX6675/issues/5#issuecomment-1665827136,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGFVP33F2PQTX6I23XNPOJ3XTUKXRANCNFSM6AAAAAA3AOWJSY
.
You are receiving this because you authored the thread.Message ID:
@.***>

For now I do not create a separate example for this as this issue stays archived, so people will find it.
When time permits (typical long winter evenings and nights) I might add it.
If your problem is solved, you may close the issue.

Thanh your for all you do for us, ...your users.
Regards,
René-Jean


.c file gets replaced by .h file

Type: Bug
When search- and replacing (globally) a variable in various files (including .h file where symbol is declared as extern), some files get completely overwritten with the content of the .h file. Basically destroys complete codebase. Name to be replaced was
ActModDrv with ActModDrv1
VS Code version: Code 1.84.2 (Universal) (1a5daa3a0231a0fbba4f14db7ec463cf99d7768e, 2023-11-09T10:52:33.687Z)
OS version: Darwin arm64 23.2.0
Modes:

System Info

Item
Value

CPUs
Apple M1 (8 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
3, 3, 3

Memory (System)
16.00GB (0.08GB free)

Process Argv
--crash-reporter-id 8b5aa74f-ed44-417c-93fe-c72126a03580

Screen Reader
no

VM
0%

Extensions (7)

Extension
Author (truncated)
Version

dart-code
Dar
3.82.0

flutter
Dar
3.82.0

git-graph
mhu
1.30.0

debugpy
ms-
2024.0.0

python
ms-
2024.0.1

vscode-pylance
ms-
2024.2.2

errorlens
use
3.15.0

(1 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:30899288
c4g48928:30535728
azure-dev_surveyone:30548225
2i9eh265:30646982
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
accentitlementst:30887150
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
pydisww1:30959800
7j2b6412:30964151
ccp1r6:30958156

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Issue remains on latest version, resp. was found on latest version. Was just reported with older version!

Can you show a screenshot of the behavior? Does this happen with all extension disabled?

I did not test with all extensions disabled. Unfortunately the code is confidential. I tried to simulate the situation on my private machine but of course I do not have the exact same files and setup available there.

I don't think I can reproduce the issue, as I don't see that behavior happening in my VS Code instance. Do you think you can try simulating it with example code on the original machine?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


UnicodeDecodeError

GAM 3.32 Windows x64
gam report users todrive
This report could not finish on a large database (almost 500.000 users). Always finished with this error message you can see on the attached screenshot.

Closing this issue as there have been numerous unicode fixes to GAM in past 2 years. if this can still be reproduced, please re-open.


Proposal: use slirp with unprivileged userns

(demo: https://github.com/AkihiroSuda/runrootless/tree/master/misc/vde)
Slirp is slow and exposing container ports is troublesome, but I think it is ok for image building.
Another idea is to use SUID binary as in lxc-user-net, but it is less secure.

yes that would be awesome!!!

I gave you push access too if you want it :)

Thank you for giving me the push access 😄

By the way, we really should have an OCI hook for slirp (like CNI or netns) so you don't have to run all the commands by a higher-level management process.

Yes, I think we can implement it using libslirp

ah yeah the netstack stuff is dope :) i know @crawshaw worked on that :)


Applying BigQuery labels through DBT

Describe the feature
I would like to be able to apply labels to BigQuery tables that are created during the DBT process.
BQ tables have the labels feature (see attached image):

The Label feature is very useful for version control and other desired attributes.
It would be extremely valuable to be able to control this feature by using Config in my DBT SQL files.
Who will this benefit?
Anyone using the BigQuery Label feature will benefit from the ability to control it using DBT.

I want this too!
I'm also interested in having config tags be the labels.
Example 1
dbt tag of 'nightly'
BigQuery label = 'nightly'
Example 2
dbt tag of 'schedule=nightly'
Bigquery label = 'schedule:nightly'
Additional thoughts:

Duplicate label keys are not allowed on both RedShift and BigQuery.
When updating existing tables and views would we want dbt to clear out existing labels first? What if there are labels not applied by DBT? Something to think about.

Here are the BigQuery label requirements: https://cloud.google.com/bigquery/docs/labels-intro#requirements
I also included the RedShift label requirements to preserve future compatibility: https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-tagging.html

See also https://github.com/fishtown-analytics/dbt/issues/1947
cool idea @talcherrehub! Let's do it :)
@ciscodebs I think the redshift tags are different -- those tags apply to redshift clusters, ie. they're something you'd set on the cluster itself, not on tables in the cluster. So, this is BQ-only functionality which actually makes this easier to implement :)
I think the idea of persisting dbt's tags as BQ tags is pretty elegant. You buy that @talcherrehub and @kconvey?

I tend to think using dbt tags for BigQuery labels is overly restrictive, and overloads the tag/label config option. BigQuery labels seem like they'd naturally support further processing post-dbt, which may not have anything to do with dbt labels. Putting BQ labels into dbt tags probably requires that all models wind up with their dbt tag as a label, which may have only existed as a tag for model selection in dbt, adding noise to BQ labels simply to avoid another config option in your dbt_project.yml. It makes more sense to me to be explicit in dbt_project.yml for what are two related, but ultimately different concepts. Where there is strong overlap, I would hope that yaml anchors and the like could potentially save you from repeating yourself.
There is also the issue that BQ labels are ultimately key-value pairs, where dbt tags currently are not. It would be a bit odd to add empty values for dbt tags just to meet a BQ syntax requirement, especially when dbt tags are used across adapters.
I am all in favor of a more elegant solution than this, but it still seems like a useful feature worth supporting even if there is some overlap between tag/label. Eager to hear some other thoughts!

yeah, i buy that, thanks for the cogent argument @kconvey :)

Sounds good to me. I also wanted to point out that BigQuery accepts label keys without values. These are referenced as tags in their docs which isn't confusing at all. I though this might be worth bringing up just in case...
https://cloud.google.com/bigquery/docs/adding-labels#adding_a_tag

good to know @ciscodebs - thanks for the additional info!


Bad state: Attempt to unprepare() an image that was not prepare()d

I have a SliverList.builder that's including ScalableImageWidget and I keep getting these errors:
════════ Exception caught by widgets library ═══════════════════════════════════
Bad state: Attempt to unprepare() an image that was not prepare()d
════════════════════════════════════════════════════════════════════════════════

When I resume the debugger, I can't see any visual issue, am I doing something wrong? If not can I surrpress these?
Thanks

actually I might have just fixed the issue by providing a key! 😅 will reopen if need...

So the keys have improved it, but I do keep occasionally getting this error.  Any pointers on how to avoid it would be great.
Thanks

Can you reproduce the problem with a small, stand-alone program?

I'd need program to reproduce the issue in order to diagnose this, and determine whether or not it's a bug.


Add unique query parameter to remove duplicate tracks

Hey @JeffreyCA,
I like this. Thank you. I add the ability to only show the unique tracks on the widget and some other changes :)

@setoelkahfi Unfortunately the env var changes aren't working. The environment variables are server-side only so when you click authorize (client-side process), client_id and redirect_uri are undefined.
If you take a look here, to expose the variables to the browser you'll need to append NEXT_PUBLIC_ to those variable names. Can you make those changes?
Deployment: https://spotify-recently-played-readme-jdyo4ecyn-jeffreyca.vercel.app/

@setoelkahfi Unfortunately the env var changes aren't working. The environment variables are server-side only so when you click authorize (client-side process), client_id and redirect_uri are undefined.
If you take a look here, to expose the variables to the browser you'll need to append NEXT_PUBLIC_ to those variable names. Can you make those changes?
Deployment: https://spotify-recently-played-readme-jdyo4ecyn-jeffreyca.vercel.app/

Yeah, that's what I said. I thought it's just me. I'll push the update.

@JeffreyCA I pushed the update. I think I tried it (prefix them with NEXT_PUBLIC_) before and had no luck. Haven't tried it again since then.

@JeffreyCA I pushed the update. I think I tried it (prefix them with NEXT_PUBLIC_) before and had no luck. Haven't tried it again since then.

Thanks, you'll need to update this too: https://github.com/JeffreyCA/spotify-recently-played-readme/blob/0235a5c05204aa3ac0c3f05fb4790e28e8d431a2/utils/SpotifyAuthUtil.ts#L14


Update README and improve jazzy docs

This PR contains documentation only changes including -
Description

modifying the README so it has our standard header
standardising the section headers within the README
updating the jazzy doc to include usage examples (mainly taken from the README)
cosmetic jazzy doc changes such as adding full stops etc.

Motivation and Context
The intention is to standardize README files across IBM-Swift and include usage examples within jazzy docs.
How Has This Been Tested?
Running jazzy and examining the rendered jazzy docs and README files locally.
Checklist:

[x] I have submitted a CLA form
[x] If applicable, I have updated the documentation accordingly.

LGTM other than the two lines above.

Codecov Report

Merging #52 into master will not change coverage.
The diff coverage is n/a.

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


Post release automated changes for newrelicobservability releases

Post release automated changes for azure-arm-newrelicobservability

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


Run path_helper On OS X To Patch The PATH

This makes the PATH a little bit better but is still not as good as getting the PATH (and entire environment) from the user's shell.
See also: https://github.com/joefitzgerald/go-plus/blob/78f59459b87476cb0f99f8b56f28e833d8d4547f/lib/environment.coffee#L13-L25

This package is deprecated; you should uninstall it. See https://github.com/atom/atom/pull/12562 for more information.


prometheus-blackbox-exporter: coercing cfg to path

Motivation for this change
This fixes an issue with a recent addition of a config file
check in c28ded36ef50cb80796c6bd946754abfb47ffa28.
Previously it was possible to supply a path as a string
to configFile. Now it will fail checking the config file
during evaluation of the module due to sandboxing.
When used with a path type it's working as intended.
There is a caveat with store-path paths, which can't be coerced
by prepending "/. +", so this case is handled explicitly.
View this as one possible suggestion. Alternatively we could also
just throw a sensible warning to save users time who might stumble
into this when upgrading to 19.09 with a previously working config.

Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
cc @WilliButz

I'd like to add, that I'm a bit torn about this workaround, as it's not overly idiomatic and it might not be obvious to the user that the file that is actually being run against is a copy in the store.
This could also lead to confusion when modifying the original out-of-store config file and restarting the service manually. Maybe there is some nifty way to get symlinks added to the sandbox that I'm not aware of yet.

@d-goldin fIrst of all, thank you for reporting this issue :+1:
I think that the main issue with silently adding the config to the nix store is when it's done in a scenario with basic auth credentials in the configuration, that should not happen without informing the user. Mentioning this in the option description and maybe even throwing a warning during eval would be enough for my taste.
Regarding the service reload on config change, where the config file is not copied to the store:
As I am not aware of any mechanism that solves this for us (restartTriggers would not pick up on changes here I guess) we might only be able to also mention that manual service restarts on config change are needed when using a config file outside the nix store. I would also prefer an automated solution here if there is any :)
I would therefore propose to do two things:

throw a warning when the config file is copied to the nix store and mentioning this behaviour in the option description for configFile with respect to any potential secrets and the need for rebuilding the system after config changes
add a switch to allow users to keep the specified configFile outside the nix store by disabling the check (e.g. enableConfigCheck with default true), mentioning the use case and the need for a manual service reload after config changes in its description

I'm happy to hear any suggestions on these proposed changes :)

@WilliButz: Agreed on the silently adding, this was the main reason why I was not a fan.
Regarding config out of store and reloading - I dont think this necessarily needs to be solved, I just thought that it was a bit incosnsitent behaviour between the two ways passing the config there.
I agree with the suggestions as improvement over the current state. It might be possibly more ideal to be able to define the whole config in nix itself, but I'm not sure if it's worth the effort and it would also still come with the usual issue of secrets management.
I'll update this PR a bit later.

I kept the commits separate for legibility. Will squash once reviewed.

@GrahamcOfBorg test prometheus-exporters.blackbox

backported in 3ddf0b3a72353c752cf700a9a0335ca68725abec


TypeError: init() got an unexpected keyword argument 'credentials'

I've been running into an issue using the S3 client on v0.5.0.
TypeError: __init__() got an unexpected keyword argument 'credentials'
  File "txaws/s3/client.py", line 445, in put_object
    d = self._submit(self._query_factory(details))
  File "txaws/s3/client.py", line 82, in _query_factory
    return self.query_factory(credentials=self.creds, details=details, **kw)
  File "txaws/s3/client.py", line 692, in __init__
    super(Query, self).__init__(*args, **kwargs)

It seems query_factory method in the client is attempting to pass a credentials kwarg to the BaseQuery object, however it expects a creds kwarg instead.
https://github.com/twisted/txaws/blob/5c3317376cd47e536625027e38c3b37840175ce0/txaws/s3/client.py#L81-L82
https://github.com/twisted/txaws/blob/5c3317376cd47e536625027e38c3b37840175ce0/txaws/client/base.py#L633-L635
PR here if it helps: https://github.com/twisted/txaws/pull/98

Actually I've run into another error where the details kwarg also isn't present on the BaseQuery.
Is there supposed to be another interface between these two?

Looks like we were using a custom Query object for the query_factory from an old version, all good!


First draft of the juttle tutorial with github data

@demmer this is still raw, want high level review. Missing:

join section that enriches the data with metadata
at some point, switch to use elastic for the data with big data set (ingest with read file | write elastic ?)
haven't validated all the juttles that run in outrigger

Ignore exact wording, not ready for review of that level yet. Mainly want review of "does this tutorial cover the right bits of juttle". Most of it came from the old tutorial, with some mods.

How about review by people who're here this week: @rlgomes @go-oleg @davidvgalbraith

Overall I think this does a great job of introducing juttle.
Some thoughts

Where will a reader typically be coming from when reading this tutorial? I think having a basic understanding of the anatomy of a juttle program shown here is prereq for going through this tutorial.
The to-be-added join example will also serve to demonstrate that a flowgraph can start with two sources. Perhaps it would be good to have an example in here that shows a flowgraph can end in two sinks as well (all the current examples branch and merge in the middle).
Weave more links to "advanced" features of juttle (e.g. features like functions, subs, and user defined reducers which allow for more modular programming).

Addressed the review comments (thanks guys) except these two:

[ ] add example that shows a flowgraph can end in two sinks - will think about where to fit it
[ ] Weave more links to "advanced" features of juttle (e.g. features like functions, subs, and user defined reducers which allow for more modular programming). - unclear on this one:

@go-oleg did you mean to just add them as "juttle has these features but tutorial doesn't cover them", or to actually include them in the tutorial? If the latter, i'm not coming up with useful places to put a function here, much less a reducer. There are places where I can utilize a sub.
Sections on join and ES are new and need review.
@henridf your review would be most welcome, as you fathered the first version of this tutorial (a lot of it stayed true to the original).

I was hoping throughout the tutorial, but you're right in that its going to be complicated. Maybe some links at the end of the tutorial along the lines of "go here next":

list of built in procs
subs and functions
custom reducers

A thought for further out - once there is a Google BigQuery adaptor, it would be compelling to use that to pull data rather than use a static file.

TODO:

[ ] change ES data to use single-index schema instead of daily
[ ] fix up the ending of tutorial with inputs as soon as they work in outrigger

As the tutorial work moved to Outrigger, I suppose this PR won’t ever get merged ⇒ closing.
@dmehra If I am mistaken, please reopen.

Will reopen because we still want the main tutorial doc merged into juttle for publishing as part of the docs site, I think, so all local docs links would work (and a big part of this doesn't use outrigger).


Issue:     from util import dataset, transform, config

hi
When i run train.py. Ihave an issue like this:
File "train.py", line 21, in
from util import dataset, transform, config
ModuleNotFoundError: No module named 'util'
best regards,
PeterPham

You can for example run export PYTHONPATH=./ beforehand like it is done in the script train.sh

You can for example run export PYTHONPATH=./ beforehand like it is done in the script train.sh


Is this project deprecated?

last release is 2 years ago, anyone maintaining this project?

does not look like it. and to be honest, the effort to update from Angular v7 to recent version is really huge.

The updates are relatively easy using ng update, but I think it's safe to say this project is not being maintained, there are two open pull requests to update to version 13 (I authored one of them two years ago!).
If anyone is interested, since this repository was deleted last year (and subsequently restored  several months later), I have been maintaining a detached fork which can be found here...
https://github.com/nodro7/angular-mydatepicker


[SPARK-34488][CORE] Support task Metrics Distributions and executor Metrics Distributions in the REST API call for a specified stage

What changes were proposed in this pull request?
For a specific stage, it is useful to show the task metrics in percentile distribution.  This information can help users know whether or not there is a skew/bottleneck among tasks in a given stage.  We list an example in taskMetricsDistributions.json
Similarly, it is useful to show the executor metrics in percentile distribution for a specific stage. This information can show whether or not there is a skewed load on some executors.  We list an example in executorMetricsDistributions.json
We define withSummaries query parameter in the REST API for a specific stage as:
applications/<application_id>/<application_attempt/stages/<stage_id>/<stage_attempt>?withSummaries=[true|false]
When withSummaries=true, both task metrics in percentile distribution and executor metrics in percentile distribution are included in the REST API output.  The default value of withSummaries is false, i.e. no metrics percentile distribution will be included in the REST API output.

Why are the changes needed?
For a specific stage, it is useful to show the task metrics in percentile distribution.  This information can help users know whether or not there is a skew/bottleneck among tasks in a given stage.  We list an example in taskMetricsDistributions.json
Does this PR introduce any user-facing change?
User can  use  below restful API to get task metrics distribution and executor metrics distribution for indivial stage
applications/<application_id>/<application_attempt/stages/<stage_id>/<stage_attempt>?withSummaries=[true|false]

How was this patch tested?
Added UT

Test build #135344 has started for PR 31611 at commit a8353f3.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39924/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39924/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135344/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39924/

retest this please

Test build #135359 has started for PR 31611 at commit a8353f3.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39939/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135359/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39939/

retest this please

Test build #135396 has started for PR 31611 at commit a8353f3.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39976/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/39976/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/39976/

Test build #135396 has finished for PR 31611 at commit a8353f3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135396/

Test build #135559 has started for PR 31611 at commit 8cf25d8.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40140/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40140/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40140/

Test build #135559 has finished for PR 31611 at commit 8cf25d8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135559/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40242/

Test build #135661 has started for PR 31611 at commit 4cd2bee.

Test build #135661 has finished for PR 31611 at commit 4cd2bee.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135661/

Test build #135687 has started for PR 31611 at commit 22f8500.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40269/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40269/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40269/

@sarutak  @gengliangwang @vanzin  I have been working closely with @AngersZhuuuu on extending REST API calls at stage level (part of SPARK-23206). Angers submitted this PR. It looks good to me. Also I have tested the code.
Can you help review this PR? Thanks.

Test build #135687 has finished for PR 31611 at commit 22f8500.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135687/

gentle ping @dongjoon-hyun @srowen @sarutak Could you help to review on this PR. Thanks

Jenkins retest this please

Test build #136351 has started for PR 31611 at commit 22f8500.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40935/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40935/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40935/

Test build #136351 has finished for PR 31611 at commit 22f8500.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/136351/

Merged to master


ARTEMIS-3484 flesh out Jakarta Messaging support

Back in version 2.17.0 we began to provide Maven artifacts for Jakarta
Messaging client resources. This commit expands that support in the
following ways:

Distribute a Jakarta Messaging 3.0 client with the broker (in the
'lib/client' directory alongside the JMS client.
Update documentation.
Add example using the Jakarta Messaging client.
Update Artemis CLI to use core instead of JMS as it was causing
conflicts with the new Jarkarta Messaging client.
Add example to build Jarkarta Messaging version of the JCA RA for
deployment into Jakarta EE 9 application servers.

just for a future reference.. no changes were made to the CLI plugin..
A change was made to the Maven CLI Plugin... on the validate started session... (the one that was creating a session to validate if the server was up.. but that's a different thing)..
not a big deal.. I'm just making this comment for future references if someone ever needs to read this PR

@clebertsuconic, thanks for the clarification. I got that mixed up in my commit message.


Add FERC1 validation tests

We've add
This lets us test things that aren't in PudlTabl.

Overview
@cmgosnell and I were working through some changes to the FERC1 machinery, related to the 714 work, and wanted to make sure things didn't break unexpectedly. This reminded us that only a small subset of our FERC tables are covered by row-count tests!
So I added those row-count tests. That required the following changes:

using Dagster's AssetValueLoader to pull the dataframes out of Parquet. This is more performant than defs.load_asset_value for loading multiple assets.
removing several database-access fixture references. Since these validation tests all check for --live-dbs I figured we didn't even need to keep those fixtures around to keep track of logical dependencies.
changing the short df_names that refer to PudlTabl methods to the asset keys we use everywhere else

A fun bonus is that using the AssetValueLoader decreased the runtime of this test suite from ~40s to ~8s on my machine. I then re-increased that to ~14s by adding a bunch more tests, but that is still much faster than before 🎉
Testing
How did you make sure this worked? How can a reviewer verify this?

downloaded the latest nightly build outputs
pytest test/validate/ferc1.py --live-dbs

# To-do list
- [x] Update the [release notes](https://catalystcoop-pudl.readthedocs.io/en/nightly/release_notes.html): reference the PR and related issues.
- [ ] Run `make pytest-coverage` locally to ensure that the merge queue will accept your PR.
- [x] Review the PR yourself and call out any questions or issues you have
- [x] For minor ETL changes or data additions, once `make pytest-coverage` passes, make sure you have a fresh full PUDL DB downloaded locally, materialize new/changed assets and all their downstream assets and [run relevant data validation tests](https://catalystcoop-pudl.readthedocs.io/en/nightly/dev/testing.html#data-validation) using `pytest` and `--live-dbs`.

Wasn’t there some issue with accessing Dagster assets via dagster in the tests because there’s no real $DAGSTER_HOME associated with the in-process executor? Does that not apply here or get around it somehow because the validation tests are only run with --live-dbs?
We have another pattern associated with some of our newer tables for verifying expected row counts of tables that aren’t part of PudlTabl using asset checks, with per-year row expectations so it can work on both the fast and full ETL and get run during the ETL instead of after the fact and only in the nightly builds, which would surface errors sooner in the development process. I had imagined we’d probably move in that direction as we rip out PudTabl.  E.g. in pudl.transform.ferc714 the spec_checks at the end of the module:

@dataclass
class Ferc714CheckSpec:
    """Define some simple checks that can run on FERC 714 assets."""

    name: str
    asset: str
    num_rows_by_report_year: dict[int, int]

check_specs = [
    Ferc714CheckSpec(
        name="yearly_planning_area_demand_forecast_check_spec",
        asset="core_ferc714__yearly_planning_area_demand_forecast",
        num_rows_by_report_year={
            2006: 1819,
            2007: 1570,
            2008: 1540,
            2009: 1269,
            2010: 1259,
            2011: 1210,
            2012: 1210,
            2013: 1192,
            2014: 1000,
            2015: 990,
            2016: 990,
            2017: 980,
            2018: 961,
            2019: 950,
            2020: 950,
        },
    )
]

def make_check(spec: Ferc714CheckSpec) -> AssetChecksDefinition:
    """Turn the Ferc714CheckSpec into an actual Dagster asset check."""

    @asset_check(asset=spec.asset, blocking=True)
    def _check(df):
        errors = []
        for year, expected_rows in spec.num_rows_by_report_year.items():
            if (num_rows := len(df.loc[df.report_year == year])) != expected_rows:
                errors.append(
                    f"Expected {expected_rows} for report year {year}, found {num_rows}"
                )

        if errors:
            return AssetCheckResult(passed=False, metadata={"errors": errors})

        return AssetCheckResult(passed=True)

    return _check

_checks = [make_check(spec) for spec in check_specs]

Ooh, I like the per-year checks, that's definitely more powerful! And being an asset check seems nice as well.

Wasn’t there some issue with accessing Dagster assets via dagster in the tests because there’s no real $DAGSTER_HOME associated with the in-process executor? Does that not apply here or get around it somehow because the validation tests are only run with --live-dbs?

Yeah, this gets around it with --live-dbs.
I think the next steps then are:

port the existing FERC1 minmax row asset checks to asset-check world
add the new FERC1 checks in asset-check world.

With maybe step 0 of turning Ferc714CheckSpec into MinMaxCheck or something. Is name just used for human identification when looking at the code? Seems a little redundant with the asset key.
Though if we want to merge these tests first to unblock the 714 work, that seems like it would be fine too.

Yeah, nothing wrong with the set up in this PR, more thinking about the future we want to migrate toward, and whether we want to start in that direction now.
My reading on the structure & naming was that there would be a variety of different asset checks parameterized within the Ferc714ChecSpec class -- e.g. no completely null columns, or the statistical distribution of coal heat contents or whatever flavors of checks we've got floating around in the pudl.validate module now -- in which case MinMaxCheck wouldn't make sense.

Yeah, nothing wrong with the set up in this PR, more thinking about the future we want to migrate toward, and whether we want to start in that direction now.

Agree. I think this is the shortest path to getting long overdue tests into the codebase and doesn't make the migration harder, so we should merge this roughly as-is.

My reading on the structure & naming was that there would be a variety of different asset checks parameterized within the Ferc714ChecSpec class -- e.g. no completely null columns, or the statistical distribution of coal heat contents or whatever flavors of checks we've got floating around in the pudl.validate module now -- in which case MinMaxCheck wouldn't make sense.

I think there are common building blocks like MinMaxRowsCheck or QuantilesCheck that we'd then want to bundle together in various Ferc714 or EiaAeo checks... though I think we should look closer into just using Great Expectations before rolling our own format for these.

And if I understand the way asset checks work, each one of the reads in the asset to do the check, so ideally there'd be some way to just read the parquet file once and do all the checks while it's in memory, rather than reading it repeatedly.

Yeah, that makes sense, doesn't seem like that would be hard to set up.


podman-inspect segfault on infra-container

Running podman-inspect on a Pods infra-container has some issues (see below).
podman inspect with useless output
[libpod (master)]$ ./bin/podman inspect a67b14bc75de
[
    null
]

podman inspect --type=container with segfault
[libpod (master)]$ ./bin/podman inspect --type=container a67b14bc75de
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2f3 pc=0x1339508]

goroutine 1 [running]:
github.com/containers/libpod/cmd/podman/shared.GetCtrInspectInfo(0xc000529c00, 0xc0000fd680, 0x0, 0xc00027e7e0, 0x0, 0x0)
        cmd/podman/shared/container_inspect.go:132 +0x5d8
main.iterateInput(0x1b9c840, 0xc0000d6018, 0x18cc900, 0xc000445b60, 0x1, 0x2, 0xc000023210, 0x7ffcfd7ada83, 0x9, 0x18d1e36, ...)
        cmd/podman/inspect.go:161 +0x5c0
main.inspectCmd(0x2bf0d00, 0x0, 0x0)
        cmd/podman/inspect.go:118 +0x347
main.glob..func8(0x2b84460, 0xc000445b60, 0x1, 0x2, 0x0, 0x0)
        cmd/podman/inspect.go:37 +0x86
github.com/containers/libpod/vendor/github.com/spf13/cobra.(*Command).execute(0x2b84460, 0xc0000de060, 0x2, 0x2, 0x2b84460, 0xc0000de060)
        vendor/github.com/spf13/cobra/command.go:826 +0x465
github.com/containers/libpod/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x2b8df60, 0xc0000c6cf0, 0x7ffcfd7ada67, 0xc)
        vendor/github.com/spf13/cobra/command.go:914 +0x2fc
github.com/containers/libpod/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        vendor/github.com/spf13/cobra/command.go:864
main.main()
        cmd/podman/main.go:146 +0x88

It's assuming the create artifact is there.
Unfortunately that is not a safe assumption.

Alright, I'm going to self-assign this.
It may be possible to completely eliminate the create artifact. It looks like most of what we use it for is stored in libpod's ContainerConfig and the OCI spec already (though not in a format we can directly use - we'd need to convert it). The few others, we can probably stick in spec annotations for...