[GUI] Installer - Add Electrum node option

This is for the installer part of #1223.
For now, I simply disable editing Bitcoin Core settings and performing rescans if there is no bitcoind config (i.e. if Electrum is used instead).
Remaining tasks:

[ ] Revert Cargo.toml once #1222 is merged.
[x] Update wording as per https://github.com/wizardsardine/liana/issues/1223#issuecomment-2286483134.

I made a further change to the behaviour while checking the connection. It's safer to prevent the user editing config values until the connection check completes to ensure the values don't change in the meanwhile, which could mean the connection status applies to the wrong values.
I think this was already an issue with the current installer but I guess connection checks are usually quicker with a local bitcoind and so it was less likely to cause problems.

I updated the liana dependency commit.

For the first page, I was proposing to take the opportunity to make the text simpler and more understandable (at least in my view):

I already have a node
Select this option if you already have a bitcoin node running locally or remotely. Liana will connect to it.
I want Liana to automatically install a Bitcoin node on my device
Liana will install a pruned (i.e. "compressed") node on your computer. You won't need to do anything except having some disk space available (~25GB required) and waiting for the initial synchronization with the network (it can take some days according to your internet connection speed).
[the two parenthesis with the estimation space and time possibly should be shown only if the network chosen is mainnet]

If there is no consensus with this, we can also leave it as you did (i.e. adding the Electrum mentions) and discuss the general wording for another time.
The second page was exactly what I had in mind. Thanks!

I've updated the wording as suggested with some minor changes:

I felt "truncated" might be more accurate than "compressed", but probably pruned already conveys this so didn't include that part.
I added "on mainnet" after ~25 GB. We don't currently have the network selection available in the view. It should be simple to add as a follow-up commit if required and only display the additional info for mainnet.
I used "depending on" instead of "according to" as I think it's more common this way but either should be fine.

I removed "full" from the title:

30 GB looks more correct (signet chain included but it's only 2.2GB):
~/.liana/bitcoind ❯ sudo du datadir -sh
29G     datadir

can we add <IP_ADDRESS>:50001 as placeholder here?
even if it's not likely the electrum server is on localhost, it indicate the user it should specify the port, and indicate 50001 is the default port.

i'm wondering about one thing here, did the address still only accept ip addresses?
i think the default config on umbrel is to give access via umbrel.local instead of an ip as (i guess) almost user do not configure a static ip for their node.

i'm wondering about one thing here, did the address still only accept ip addresses? i think the default config on umbrel is to give access via umbrel.local instead of an ip as (i guess) almost user do not configure a static ip for their node. cf this comment

tested on linux adding <IP_ADDRESS> electrum.local to /etc/hosts:

I've made the suggested changes.
I now need to rebase on master as there's a conflict.

Rebased on master.

Sorry, I made a further change to the Electrum address validation.

testing w/ several remote servers:

seems ok w/ both ssl/tcp

Here we should rename "Bitcoin Core" into "Electrum server":

Here we should also remove the rescan feature if electrum, but we should keep the block height, i often use it for know if liana is sync w/ the backend:

I'm actually trying electrum (on an other machine on my local network) on regtest w/ 550 coins:

for every sync (so every 30 seconds) electrs needs around 10 seconds to answer the gui request.
if i click on Receive menu during this 10 seconds i got not address util all the requests done:

i wonder about 2 things:

do we make some call to te electrum server for generate address? or it's the iced "event loop" that became overloaded?

why we still make so much requests to electrum server after we are sync?

trying to connect a mainnet wallet on regtest electrum fail as expected:

maybe we can try to detect network by genesis hash and display a more explicit message to the user?
(i don't think this should be tackle in this PR but rather in a follow up)

Updated liana dependency commit hash.

Added a couple of commits to update the Settings and allow to view & edit Electrum settings.
It's NOT possible to switch from one node type to another. This will require more changes and we'll probably need to leave that for a follow-up.
I've renamed the Settings page to "Node":

We can view the Electrum settings (and some chain info):

We can edit the address:

TODO: Update comment in installer about rescan after importing wallet.

TODO: Update comment in installer about rescan after importing wallet.

Updated the wording.

Updated liana dependency commit hash.

we do not ping the electrum server before let user save settings, so if the address is wrong ElectrumSettings.processing is still true and we cannot edit the address anymore

if we conect to a wrong network electrum server we should have a clearer message

Connecting to the node only after saving the changes is also done for bitcoind. Ideally, we would ping the server and check the network before saving, which could avoid that error about hash mismatch. Or perhaps I can add something to display that error differently in the GUI. Probably in a follow-up.
For Electrum, it's using a timeout of 180 seconds but I checked that it eventually gives a daemon error. I'll see if I can use a shorter timeout in #1222.

For Electrum, it's using a timeout of 180 seconds but I checked that it eventually gives a daemon error. I'll see if I can use a shorter timeout in #1222.

Hmm don't think I can change it just for the initial connection. I think better to add the pre-save ping on the GUI settings page for both bitcoind and Electrum, reusing what's already done in the installer.

The loader still refers to Bitcoin Core syncing. We can change that depending on node type in a follow-up.

Created https://github.com/wizardsardine/liana/issues/1256.

For Electrum, it's using a timeout of 180 seconds but I checked that it eventually gives a daemon error. I'll see if I can use a shorter timeout in #1222.

Hmm don't think I can change it just for the initial connection. I think better to add the pre-save ping on the GUI settings page for both bitcoind and Electrum, reusing what's already done in the installer.

maybe we can just disable edit for now (or keep the bug) and doing it in a follow up

maybe we can just disable edit for now (or keep the bug) and doing it in a follow up

I'll create a follow-up issue. I think this is the same as current behaviour for bitcoind, just that Electrum takes longer to fail.

Rebased on master and updated liana dependency commit hash.
TODO: incorporate daemon changes related to rescan logic in #1222.

Maybe we can add (in a follow up) the name/type of the electrum server (by sending a server.banner request

Updated liana dependency commit hash.
Changed DaemonControl to mutable following changes to start_rescan in #1222.
Allow to start rescan also for Electrum.

Added a commit to enable changing from one node type to another in the settings.
Note that in its current form, it'll be possible for someone who's using managed bitcoind to switch to Electrum in the settings. In this case, the GUI will not try to start the managed bitcoind the next time they launch the GUI. I could also prevent such a user from switching node type (indeed, they cannot edit the bitcoind settings currently).
I also made a fix to a previous commit so that we take into account whether a rescan is in progress in order to determine whether the Electrum settings can be edited.

ACK 819eb920c0210b9d95689f40cfbeba65c03280af


Include website to "backend" container

Hi,
I was about to create something similar when I discovered this project, which aligns closely with my plans.
I've identified three minor improvements and submitted a PR for them. I apologize for the multiple submissions; it simplifies the merging or rejection process.
I noticed that the website isn't included in the container, and I think a brief message on the root path would be helpful. 😄
Additionally, I suggest serving a prebuilt version of the Vite app within the container as static content. I can submit a PR for that as well, but given the scope of the change, I’d prefer to discuss it first before investing too much time.

Hi @mms-gianni,
Thank you so much for your feedback and contributions!
I'm really glad to hear that you find the project interesting. As you might have noticed, this began as a personal project, and I haven’t had much time recently to work on it. Both the server-side code and especially the frontend could benefit from some refactoring and cleanup.
I really appreciate your suggestions, at some point I wanted to write some instructions so people can self-host it and provide their own GH PAT.
Feel free to share any ideas or suggestions in the GitHub Discussions section. I’d love to hear your thoughts!

Additionally, I suggest serving a prebuilt version of the Vite app within the container as static content. I can submit a PR for that as well, but given the scope of the change, I’d prefer to discuss it first before investing too much time.

Definitely something that would be super useful.
The hosted version is using my PAT and some people would like to self-host.

It was simpler as expected.

Fantastic! Closing this Issue following the merging of https://github.com/emanuelef/daily-stars-explorer/pull/195

@emanuelef had a quick dive into image details.
The image grew by ~4MB from 36MB to 40MB


Update for Swift 2.0

Small fixes to make it Swift 2.0 compatible

Thanks for the pull request.
I'm going to keep any Swift 2.0 changes out of the master branch until Xcode 7 comes out of beta. I will accept your Swift 2.0 specific changes on a swift-2.0 branch.
Are the public modifiers on the class something with Swift 2.0, or is that just something I missed? If the modifiers are not related to Swift 2.0 I would rather have them in a different commit.
Thanks again!

It might not entirely be related to swift-2.0, but the changes were necessary to use the cocoapods version in combination with the use_frameworks! setting in the Podfile.
Without specifying the public access modifier, the DBAlertController is not visible.

Makes sense.
Would you mind creating a separate pull request for the public modifiers? I can merge that one into master and then create a branch for the Swift 2.0 pull request.
Just want to keep the commits/branches accurate and make sure you get the credit.

 I don't have time at the moment to split the commit. You can just close this pull request.

Ok. Thank you for the changes. I appreciate it.


Column resizing

Closes #2555
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

storybook tests with 'allowsResizing' prop in TableView
npm run test Table.test.js

🧢 Your Project:
Adobe Analytics (Analysis Workspace)

In response to your comment above, @snowystinger which for some reason I can't reply to directly...

I think the only usage note I have right now is that while expanding a column, the horizontal scroll bar sometimes appears, and this makes tons of sense.

Yes, and we actually just pushed out a fixed to a bug with this where if you resize when there's a scrollbar in the overflow area, it was acting strange. I'm not sure if you ever tried that, but if you did it should be fixed now.

When shrinking columns though, it's possible to make the table take up less space than is allocated for it which leaves a blank area on the far right in LTR.

Yes that is very true! This is intentional but I can see why someone might think it's strange. We actually explored examples of how this behavior would work and a popular paid-for table view, ag-grid, does this same behavior (https://ag-grid.com/javascript-data-grid/column-sizing/)

Some questions about resize behavior: Should the last column be resizable? If the combined widths of columns is less than the width of the table, should the last column snap to the edge of the table area? Should you be able to resize a column by dragging off the table?

These are some good questions and I do think that the way we have it built now feels good and works well. We did talk extensively with Alan Wilson about the different behaviors of the table, including the questions you have above, and he didn't have any concerns with the way we were building it. That being said, something like "don't allow the last column to be resized" isn't a very hard thing to change so if we decide we want to change it then we can have more discussion about it in the future.

I noticed that if I drag back onto the table it'll stop the resizing even if I haven't let off the mouse.

This was the bug I referenced above which should be fixed now. Looks like you did see it.

Some general questions: How big of a hit area should the resizer have? it can be a bit tricky to grab.

We may have to go back and look at this. I THINK it's supposed to be 4px to the left and 4px to the right, making an 8px range. However because of how the boundaries of CSS work in RSP - I think making the 4px to the right isn't something we did. We may need help with that part of it if we want to make it bigger.

Can we have some stories with the prop showDivider?

We can definitely add a showDivider story, that's a good idea. Or at least add it as a prop to some of the tests.

I think the whole column divider is supposed to become blue? should it all be grabbable for resizing?

This is one thing we will want to work with your team about, since you probably have better knowledge of the codebase. You're right in saying that the design spec has the whole column divider becoming blue, but with how the contains boundaries for CSS work in RSP, we decided to keep it just at the header level for now and work with your team about what it would take to make it go across everything. It's possible you have a good idea here.

Before we added to this codebase, @marshallpete and I created multiple artifacts to help define the functionality of the column resizing and prototype it out to understand all the nuances of the problem. Since you're looking over this now @snowystinger , it may be helpful for you to look through our documents to understand how some of these pieces are meant to work. We created these artifacts a few months ago, so it's possible that they are somewhat out of date now, but I think it will still be useful for you and anyone else seeing this.
Column Resizing Recommendation Document:
Column resizing recommendations.docx
Column Resizing Flow-chart:
Columns Flow.pdf
(Less useful now that this is in the codebase itself but here are prototypes)
Codesandbox - shows the algorithm we used for handling DYNAMIC column resizing. Assumes there are no STATIC widths. This also includes all the test-cases we thought relevant to the algorithm. These test cases are currently being covered in Table.test.js
https://codesandbox.io/s/column-width-resizer-final-jo4rr?file=/src/column-utils.spec.js
Codepen - This code snippet and demonstration shows the basic behavior of how the columns should resize following the rules defined in the first document. It's probably not as helpful now since you can play with the full behavior in the RSP codebase itself.
https://codepen.io/mpeterson/pen/VwzRQJo

Hey @snowystinger - I made changes that I believe addresses all of your comments/recommendations.
As far as this PR the only thing I think that's left (from my understanding) is to make is so that the allowsResizing prop goes down the new code path and that if it's not provided then it goes down the old code path; like we talked about last week.
Are there any other things besides that, that you think needs to be changed?

As of now we've completed everything we talked about and made changes based on every question/concern that @snowystinger had.
As such, i'm changing this from a draft to an official PR to be reviewed for merging.
Our latest commit includes the code "feature flag" based on the allowsResizing prop.


Support W3C Recommendation

List of attributes defined by ARIA.

ARIA link is a Working Draft, not a final Recommendation like WAI-ARIA. I don't know if this is an issue for you.

Your two links are the same?

Sorry, this is the link for ARIA, as it's written in the README: https://www.w3.org/TR/aria-in-html/

I think what @jorgesumle is saying is that there are a lot more attributes here than here, and that you might want to add the "missing" ones to your repo.

To get a list of every aria-* attribute you can use GNU grep: grep -o aria-[[:alpha:]]*[^\'\.,\"\<\/=[:alnum:]-] https://www.w3.org/TR/wai-aria/ | sort -u

Thanks both! I fixed the build script.


Actually implement the interactables

If Interact with the door, you are going to a new room

This requires your ticket to already be finished :)
Its just appling evetything you have done on to the door, and replacing the Oncolissing effect of the door with your cool new interactable stuff


Issue 43, Left click also opens name menu

Found this solution, and it seems like you used it as well for the clickable name at the top of the screen.

Awesome!
Hopefully this didn't take you a lot of research time, realizing I probably should have posted the solution once I figured it out for the top menu.


Remove serialize_as_future and invoke_when_ready

The serialize_as_future and invoke_when_ready facilities which are currently being used to make sure that all futures which have to be serialized have become ready before the actual serialization operation is performed are obsolete. It is now safe to just wait for a future to become ready during serialization.

This commit (09e83a4f1a7874d43b6fe156dd5c7972771527c1) removes the facilities. This however causes applications to hang (for instance stencil_8).

This has been fixed by merging #1728


History manipulation

I'd like to revamp the datastar-redirect event so it allows us to interact with the History api.
I'd rename datastar-redirect to datastar-history with the following possible options:
data: method pushState | replaceState
data: url string
data state json

data: method go back | forward | number

data: method redirect
data: url string

Any thougths on this ? I'll start working on a pr for this pretty soon.

We are discussing on Discord, but for posterity.  I'm super wary of interacting with the History API as it break core tenants of HATEOAS.  Cookie/flashes is the best approach in most situations.  I think hx-push and its support attributes is a major place where HTMX jump the shark.  Will be looking for more info before accepting a PR in this vein.

So I was able to do exactly what I needed without needing the history API.

The client initiates a datastar post request to the server
The server sets some state in a cookie, then starts to stream sse to the client. During the stream it creates a new ressource from the post data and then redirects the client to the page that corresponds to that ressource.
The client receives the redirect and issues a get request for the new ressource.
The server receives the get request, gets some state from the previously set cookie and sends the html page, prepopulating one of it's elements with data-on-load="$signal = 'some state'; $$post('/somepostrequest')"
The client renders the page and initiates a new post request on load
The servers receives the request, deletes the cookie then starts streaming sse to the client

Now step 6 could of just read the cookie and I did not need to set a signal in step 4 before the on load, but the element also has an on click for the same route and I didnt want to have to change much code in the route.
I'll close this issue to be reopened if somebody sees the need for this kind of api.

I'm super wary of interacting with the History API as it break core tenants of HATEOAS. Cookie/flashes is the best approach in most situations.

Could you expand on the reasoning here? Wanting to utilize URLs for client navigation/permalinks without completely reinitializing the client doesn't seem like an unreasonable desire, and I'd think the data store approach taken by datastar would lend itself pretty neatly to interacting with History.


Stop centering clicked suggestions in the autocomplete popup

Fixes #67690.

LGTM.
Wouldn't it be more straightforward to use a bool that prevents setting the offset itself?

Wouldn't it be more straightforward to use a bool that prevents setting the offset itself?

I don't see how that could be done, it needs to keep track of both the centered item and the selected one.


[WR] remove timestampe from the zip filename

Pivotal Card Removes the timestamp from the generated zips filename.

Mmmmmmyup. LGTM.


Issue related to Spring Boot WebFlux and micrometer while the system uses different executors

We tried to use micrometer tracing with WebFlux gRPC and, it looks like, the context doesn't populate between executors during the one request.
public Flux<AuthorityDto> getAuthority(@NonNull Long accountId){
        return Mono.just(accountId)
                .doOnNext(ignore -> log.info("========== Message 1 =========="))
                .flatMapMany(authorityRepository::getAuthority) <=== Request to DB to select a flux of authorities
                .take(1) // just for sample
                .doOnNext(ignore -> log.info("========== Message 2 =========="))
                ...;
 }

Result
INFO [6603fd55c4be0cc0d99287a970446e4a] --- [ault-executor-0] AuthorityService    : ========== Message 1 ==========
INFO [] --- [actor-tcp-nio-2] AuthorityService    : ========== Message 2 ==========

We can see that before DB-operation the log has a trace ID and executor ault-executor-0 but after selection, the race ID is empty and, as expected, we have another executor actor-tcp-nio-2.
There are dependencies which are used:
implementation 'org.springframework.boot:spring-boot-starter-actuator:3.2.4'
implementation 'io.micrometer:micrometer-tracing-bridge-brave:1.2.4'
implementation 'io.micrometer:context-propagation:1.1.1'

Spring Boot 3.1.5
The main method also has Hooks.enableAutomaticContextPropagation
public static void main(String[] args) {
        Hooks.enableAutomaticContextPropagation();
        SpringApplication.run(AuthorityServiceApplication.class, args);
}

I have found that it should be propagated by hand like in this tutorial https://www.youtube.com/watch?v=6OKS36PSpho
Thank you.

The final solution if you want to use WebFlux gRPC and tracing:
You have to create beans of ObservationGrpcServerInterceptor and ObservationGrpcClientInterceptor
Also, you have to add .contextCapture() to the end of the gRPC chain.

cc @chemicL

AFAIK, Spring has no official gRPC support. Whichever community supported project that the GrpcGlobalServerInterceptor comes from would need to support Observation just like Spring does for this to work without user configuration.
Some remarks regarding the code above:

spring.reactor.context-propagation=auto Boot config can be used instead of directly calling Hooks.enableAutomaticContextPropagation()
You should register a ThreadLocalAccessor once per app lifecycle instead of registering one on every call.
I don't know about reactive support in your gRPC integration library but in reactive endpoints you should avoid directly writing to MDC and using contextCapture() afterwards, but instead write directly to the Reactor Context.
Now you can use a dedicated ThreadLocalAccessor for such a use case.


add examples for euclidean division

https://oi-wiki.org/math/crt/
help me, my math sucks

Thanks a lot for the new example!
I think Chinese Remainder Theorem is the same as 大衍求一術? @YuRen-tw already contributed an example for that: https://github.com/LingDong-/wenyan-lang/blob/master/examples/modinv.wy
鬼谷算、大衍求一、韓信點兵、隔牆算⋯⋯ I never figured out the difference. Perhaps they're just variations of CRT. However if you have an alternative version of CRT I'd gladly put it into the example, more examples is always better. Thanks.

秦九韶's 大衍求一術 is just a subprogram of the 大衍術 and is for computing the modular multiplicative inverse.

A modular multiplicative inverse of an integer a is an integer x such that ax is congruent to 1 with respect to the modulus m, i.e., ax ≡ 1 (mod m).

And yes, 大衍術、鬼谷算、韓信點兵、隔牆算 are variations of the CRT.
The 大衍求一術 is very similar to the Euclidean algorithm, but it seems to me that the Euclidean algorithm is for computing the greatest common divisor.


tests: test Line API with nested mixed objects indent

@Conchylicultor We should probably test the indent functionality against nested mixed objects.
Signed-off-by: Ayush Joshi<EMAIL_ADDRESS>

  assert text == epy.dedent("""
      [
        a,
        b,
        [
          c,
          d,  # I was curious to see if this context will repeat itself after exiting
        ],
      ]
      """)

def test_lines_with_nested_object_indent():
  ...
    with lines.indent():
      for submodule in submodules:
        for k, v in submodule.items():
          lines += '{'
          with lines.indent():  # next iteration will test if this context will produce expected result or not
            lines += f'\'{k}\': \'{v}\','
          lines += '},'
    lines += '],'
  ...
  text = lines.join()

  assert text == epy.dedent("""
        ...
        submodules: [
          {
            'epath': 'Path utils',  # I was curious to see if this context will repeat itself after exiting
          },
          {
            'epy': 'Python utils',  # it repeats itself
          },
          {
            'ejax': 'Jax utils',  # it repeats itself
          },
        ],
        ...
        """)

@Conchylicultor You are the Google engineer here :), I might not make any sense but this is how I learnt testing 😂. Should I update the PR to only fix the typo?

@Conchylicultor You are the Google engineer here :), I might not make any sense but this is how I learnt testing 😂. Should I update the PR to only fix the typo?

Yes, thank you for fixing the typo. Let's revert the test and only submit that.

@Conchylicultor Done.


Supports pretrained res101 and x101 models for detectors

This PR enhances #4345, provides pretrained models for detectors_r101 and detectors_x101_32x4d.

Any progress?

Any progress?


Benchmarking Package

This PR contains the following:

A Benchmarker class that runs different loops with different initial data sets.
A BenchmarkPlot class that plots the results of the benchmarking
A Metrics interface and implementations of some common metrics. These metrics are evaluated on every iteration of every loop and results stored so they can be plotted later.
A BenchmarkResult class which stores the metrics.

Questions:

Are the metrics more general? Would we want to collect metrics about all loops, not just when we are benchmarking?
Should a loop return some results? loop.run_loop() currently doesn't return anything which is a bit weird. If there were a LoopResult object, we could reuse it here.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

This is great Mark. I think that in the loop state we can save other metrics that can be queried by the Benchmarker.
I agree with the point that the loops should return something. This may depends on the loop itself. In BO for instance, a user will expect at least the optimum (and  it value) and the current model). In BQ the value of the integral, etc.

Codecov Report

Merging #94 into develop will decrease coverage by 7.12%.
The diff coverage is 16.47%.

@@             Coverage Diff             @@
##           develop      #94      +/-   ##
===========================================
- Coverage    89.92%   82.79%   -7.13%
===========================================
  Files           65       69       +4
  Lines         1637     1813     +176
  Branches       171      201      +30
===========================================
+ Hits          1472     1501      +29
- Misses         124      270     +146
- Partials        41       42       +1

Impacted Files
Coverage Δ

emukit/benchmarking/benchmark_plot.py
0% <0%> (ø)

emukit/benchmarking/benchmark_result.py
0% <0%> (ø)

emukit/benchmarking/benchmarker.py
0% <0%> (ø)

emukit/core/loop/outer_loop.py
87.5% <100%> (+0.54%)
:arrow_up:

emukit/benchmarking/metrics.py
75% <75%> (ø)

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 251d027...3d502f1. Read the comment docs.

Addressed most of the comment but I'm goign to work on making the metrics a more integral part of the OuterLoop


Fix USDT run_time test targeting all pids

This creates a new pid namespace (and mounts proc) to run bpftrace inside of this namespace.
Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc and if needed in docs/reference_guide.md
[ ] User-visible and non-trivial changes updated in CHANGELOG.md
[ ] The new behaviour is covered by tests

@danobi Let me know what you think of this first draft

Should AFTER scripts run in the pid ns too? Might be ok to omit until actually necessary.

That's a good call. I think they should. I'll make that update.

Ah didn't notice PR was in draft. Feel free to ignore comments while you debug

Ah didn't notice PR was in draft. Feel free to ignore comments while you debug

No, please continue. These comments are helpful. I also still can't figure out why the Embedded builds are failing.

@danobi This is ready for a proper review

Ah I see. It's assuming there are no arguments passed to the BEFORE program. For example with this diff things break:

Good catch. Will fix.


Simplify config for common cases

Currently the config for formatters is an array-like table of functions, but for most filetypes I only use a single formatter and for most formatters the function just returns a static table. I think it would be more ergonomic to make it so that

Formatters can be optionally specified by tables instead of functions if they don't need anything dynamic.
The array-like table of formatters can be optionally replaced with a single formatter value (that is a function or also a formatter table if 1 is implemented too).

So for example with both of these implemented, I could do this to a snippet of my config.
-- Old
require("formatter").setup {
  filetype = {
    python = {
      function()
        return {exe = "black", args = {"-"}, stdin = true}
      end,
    },
    rust = {
      function()
        return {
          exe = "rustfmt",
          args = {"--edition=2018", "--emit=stdout"},
          stdin = true,
        }
      end,
    },
  },
}

-- Simplified
require("formatter").setup {
  filetype = {
    python = {exe = "black", args = {"-"}, stdin = true},
    rust = {
      exe = "rustfmt",
      args = {"--edition=2018", "--emit=stdout"},
      stdin = true,
    },
  },
}

I've skimmed the codebase and I'm pretty confident I could implement this if there's interest.

I had originally thought about doing static tables, but to keep it consistent for users/maintainers, a function is required. Some formatters require that a file name be passed in, which cannot be derived from a function
local prettierConfig = function()
  return {
    exe = "prettier",
    args = {"--stdin-filepath", vim.api.nvim_buf_get_name(0), "--single-quote"},
    stdin = true
  }
end

And so far, that's worked really well. I'm not really thinking about changing it

I had originally thought about doing static tables, but to keep it consistent for users/maintainers, a function is required. Some formatters require that a file name be passed in, which cannot be derived from a function
local prettierConfig = function()
  return {
    exe = "prettier",
    args = {"--stdin-filepath", vim.api.nvim_buf_get_name(0), "--single-quote"},
    stdin = true
  }
end

And so far, that's worked really well. I'm not really thinking about changing it

That's fair enough. Any thoughts on 2? So you wouldn't have to specify a table if you only have one formatter?

That's fair enough. Any thoughts on 2? So you wouldn't have to specify a table if you only have one formatter?

I mean, it could work, but I don't really see the benefit. Since it's again having to type check if something is a table vs a function internally. The way it is now provides a consistent experience. Thanks for the idea, but I like the way things are currently.

I mean, it could work, but I don't really see the benefit. Since it's again having to type check if something is a table vs a function internally. The way it is now provides a consistent experience. Thanks for the idea, but I like the way things are currently.


feat: slack integration for SQL-based alerts

SUMMARY

Implements slack support for SQL-based alerts
Form:

Slack:

TEST PLAN

[x] local test
[ ] dropbox staging
[ ] dropbox prob

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[x] Requires DB Migration.
[x] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

couple nits, but overall looks quite good
qq - is it possible to make slack alert in red / make it more visible that it is an alert?

I couldnt find that many formatting options for emphasis in https://api.slack.com/reference/surfaces/formatting#basics I opted to have the flashing emoji to make the message visible as an alert


fix(antd theme)

Description
Fixed issue where theme overrides were not working
Type

[x] This is a bugfix.
[ ] This is a new feature.
[ ] This is part of a feature.

Organization

[x] Have you linked this pull request to a Trello card?
[x] Have you named the branch in the format of feature/describe_feature_or_change OR bug/describe_bug_this_is_fixing

Review

[ ] Is this a work in progress?
[x] Is this ready to be reviewed?
[x] Have you added two reviewers to this pull request?

 Bug: fix ant design theme overrides not working

 Bug: fix ant design theme overrides not working


luci-app-uhttpd: migrate to JavaScript-based implementation

Dear maintainers of OpenWrt,
I am submitting this pull request to migrate luci-app-uhttpd to a JavaScript-based implementation. The old system involves rendering pages on the router and delivering them as HTML to the browser, which results in a higher load on the embedded devices. To address this issue, the LuCI applications must be migrated to a JavaScript-based framework, which will reduce the load on embedded devices and improve performance.
https://forum.openwrt.org/t/luci-migrate-to-js-based-framework-gsoc-2023-project/155719
Screencast from 2023-04-15 03-23-09.webm
Actually I can't upload the ipk file that I created using the OpenWrt build system using the same implementation as in the pull request. As shown in the attached screencast, the ipk file was successfully tested on a live OpenWrt system.

Hi! I have fixed the Test Formalities, and you can now try rerunning the workflows. Thank you!


Distance - android - Creating distance expense with big distance rate, invalid amount error shown

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.28
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team
Action Performed:
Pre: condition : 1. Open account with workspace created and distance rate enabled
2. Open rate and change it to big amount eg: 88888888.888 and save

Launch app
Open workspace chat
Create distance request
Enter start & stop points and tap next
Tap submit

Expected Result:
When distance rate is set as big number, on creating distance expense, invalid amount must not be shown
Actual Result:
When distance rate is set as big number, on creating distance expense, invalid amount is shown
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence

https://github.com/user-attachments/assets/ac2f8be9-4f89-4328-9ff6-25f7fc5ab645
View all open jobs on GitHub

This honestly seems ridiculous to me. Distance expenses will never be hundreds of thousands of dollars IMO.
Asking here - https://expensify.slack.com/archives/C036QM0SLJK/p1725411079643849

Confirmed, going to close this one - it's not likely anyone will create such a large mileage rate.

@abzokhattab this issue applies to the rate, correct? Why I don't think this will be an issue is that, usually, rates will never be that high. Mileage is usually a couple of dollars at the most.


Fix aggregation of samples in the SpeedScope/Chromium exporter

Sort samples not only by time but also by depth to safely deal with recursive invocation of methods
Prevent overlapping of adjacent samples caused by imprecise conversion of floating point numbers

Fixes #1178.
The result from the sample nettrace file in https://github.com/jlfwong/speedscope/issues/272:

Format
Before
After

SpeedScope

Chromium

Somehow I cannot run tests locally on my machine. Maybe the CI will do it?
@brianrob @adamsitnik Please take a look.
Thanks!

Hi @swift-kim
Thank you for a very elegant fix! The attached screenshots look great!
I am going to clone your fork right now and test few traces manually.

@swift-kim the latest speedscope version is giving me an error:

https://www.speedscope.app/#profileURL=https://gist.githubusercontent.com/adamsitnik/252468dff5c2b82cab913dce8f4b1d94/raw/fa46a2795965b727af7ca4eaa996b67e08980589/1184.speedscope.json
an older version of speedscope can open it:

I've analyzed the produced json file and it looks that it's my fault and the aggregation of samples is simply too aggressive or even invalid:
https://github.com/microsoft/perfview/blob/3aae482871d7c3c369e9733a31cdca975126c32a/src/TraceEvent/Stacks/StackSourceWriterHelper.cs#L186
If I remove the magic 1.2 multiplier:
- return left.RelativeTime + (left.Metric * 1.2) < right.RelativeTime;
+ return (left.RelativeTime + left.Metric) < right.RelativeTime

both speedscope and chromium open it.
The problem is that the size is growing (even up to +30%) and method names are not displayed (there is a lot of small boxes):
After:

Before:

I'll try to experiment with the aggregation and see if I can find a solution that would work fine for all scenarios.

Ok, I think I've found the source of the problem.
To repro, we need to set the time range of the provided trace file to <1,243.000, 1,250.369>

In the exported JSON file, frames from 0 to 14 are opened, and then 14, 13 and 8 are closed. So we are not closing 12-9
"events": [
{ "type": "O", "frame": 0, "at": 1242.9994 },
{ "type": "O", "frame": 1, "at": 1242.9994 },
{ "type": "O", "frame": 2, "at": 1242.9994 },
{ "type": "O", "frame": 3, "at": 1242.9994 },
{ "type": "O", "frame": 4, "at": 1242.9994 },
{ "type": "O", "frame": 5, "at": 1242.9994 },
{ "type": "O", "frame": 6, "at": 1242.9994 },
{ "type": "O", "frame": 7, "at": 1242.9994 },
{ "type": "O", "frame": 8, "at": 1242.9994 },
{ "type": "O", "frame": 9, "at": 1242.9994 },
{ "type": "O", "frame": 10, "at": 1242.9994 },
{ "type": "O", "frame": 11, "at": 1242.9994 },
{ "type": "O", "frame": 12, "at": 1242.9994 },
{ "type": "O", "frame": 13, "at": 1242.9994 },
{ "type": "O", "frame": 14, "at": 1242.9994 },
// now we begin closing
{ "type": "C", "frame": 14, "at": 1248.8973839278624 },
{ "type": "C", "frame": 13, "at": 1248.8973839278624 },
// jump from 13 to 8, what about closing 12, 11, 10 and 9?
{ "type": "C", "frame": 8,  "at": 1248.8973839278624 }

This is because the following condition returns true for System.Private.CoreLib!System.Reflection.RuntimeAssembly.GetCustomAttributes(class System.Type,bool)
https://github.com/microsoft/perfview/blob/3aae482871d7c3c369e9733a31cdca975126c32a/src/TraceEvent/Stacks/StackSourceWriterHelper.cs#L182-L183
Because it's called by two different methods:

xamarin.forms.core!Xamarin.Forms.Internals.Registrar.RegisterStylesheets()
xamarin.forms.core!Xamarin.Forms.DependencyService.Initialize(class System.Reflection.Assembly[])

but all other methods have the same caller and depthL
A() => B() => X() => C() => D()
A() => B() => Y() => C() => D()

I'll try to come up with some way to recognize this situation (difference somewhere in the callstack)

@adamsitnik Thank you for the detailed analysis!
Let's continue the discussion in the new PR.


Fixed/added support for inline playback support on Android

The prop playsInline doesn't work on Android. After inspecting I found that it is removed entirely from the props in YouYube.android.js (at the bottom). After further investigation I found that inline playback support is working very poorly. This pull requests adds proper inline playback handling for Android. It addresses the following issues:

fix full-screen mode always started on load when play is false
cue video when play is false so you can tap it to start the video
start full-screen mode when video starts playing and inline is not enabled
exit full-screen mode when video is ended and inline is enabled
stop video from playing when exiting full-screen and inline is not enabled
pause video playback when videoId prop is reset
fix, don't start playback of video when videoId is changed but play is false
start full-screen when setting play to true and inline is not enabled
emit 'loaded' event when video has loaded
emit 'fullscreenMode' and 'windowMode' events when entering/leaving fullscreen

This should fix the following error (which I was experiencing as well): #82
Also, I noticed that because of the full-screen mode it often showed the dreaded "YouTube video playback stopped due to unauthorized overlay on top of player" bug. This is also fixed now, so should very likely fix #83 as well.
Example of inline video playback on Android:

Let me know if I can do anything to speed up the process of getting this accepted.
cheers, Hein

Sounds good but your code leads to a black screen for the YouTube component for me when I use playInline = true ... any idea ?
(I used to use the trick of fullscreen, no fullscreen to avoid this problem of "YouTube video playback stopped due to unauthorized overlay on top of player." until now)

So I've been seeing that problem as well. It's quite reproducible on release builds for me and a lot harder on debug builds. It seems that the component sometimes needs an extra layout.. I found one workaround which consistently fixes the problem. What I do is, after the video has been loaded (loaded event was added in this PR), I force a relayout of the YouTube component, by changing the width by 1 pixel. It's a dirty hack really, but you don't see it visually and it fixes it. I've described the workaround code here:
https://github.com/inProgress-team/react-native-youtube/issues/74#issuecomment-265847311
I've tried for two days for creating a solution in the native code (e.g. by forcing a re-layout on the RelativeLayout) but was unable to find any solutions there.

Hey guys. So I'd really love to see this get pulled in the main branch. Is there anything I can help with to make that happen? I know there is the black screen/no controls/layout messed up issue. But frankly I can also make that happen when not using inline (by exiting fullscreen).
Also shall I resolve the merge conflicts? Let me know.
cheers, Hein

We still need to find a way to avoid this black screen problem to add the inline option. I will take time to work on it in the next few days.

Awesome! If I can be of any help let me know.

any news?

Hi, I've fixed the conflicts, really hoping this can get accepted.
Best regards

Awesome, thanks!

@IjzerenHein I'm still facing the same issue on Android. Switched to master repo after this merge, rn version: 0.40

@edencakir Which issue is that?

@IjzerenHein Inline playback  - video stops playing after 1 second or so, and works only when its fullscreen

@edencakir Thanks for elaborating. Was asking because there were multiple issues addressed in this PR. Could you try the workaround I described in #74 and see whether that works for you?

@edencakir Also, have you checked the log output in Android studio? What error are you seeing there?

@IjzerenHein I haven't done any logging in Android studio ever, only chrome and ios. react-native log-android is this what you're recommending?
I'll try the workaround in #74 tomorrow.

@edencakir I'm not sure if that command logs all the native logs and exceptions (which is what you want in this case). I just launch Android studio after putting the debug version of my app on the Android phone, and select the device and the views logs in the bottom part of the Android studio UI.

Alright thank you a lot, I'll let you know my progress.

W/YouTubeAndroidPlayerAPI: YouTube video playback stopped due to the player's view being too small. The YouTubePlayerView is 0dp wide (minimum is 200dp) and 0dp high (minimum is 110dp).

This is what I get from Android Studio logging. @IjzerenHein

@IjzerenHein I implemented your #74 solution, however YouTube player doesn't render, except hot reloading changes. Can you share the code where you call

And this is what I get from your implementation #74 @IjzerenHein
W/YouTubeAndroidPlayerAPI: YouTube video playback stopped due to unauthorized overlay on top of player. The YouTubePlayerView is obscured by
com.facebook.react.views.view.ReactViewGroup{3714d026 V.E..... ........ 0,0-1080,1701 #39}.
YouTubePlayerView is completely covered, with the distance in px between each edge of the obscuring view and the YouTubePlayerView being: left: 0, top: 162, right: 0, bottom: 769..

@edencakir These are the styles (nothing special..):
const styles = StyleSheet.create({
	container: {
		justifyContent: 'center',
		alignItems: 'center'
	}
});

The containing Component does pass in additional styles to the VideoPlayer component. What happens if you pass in a fixed width and height?

I encountered the same problem also
02-20 13:53:29.538 15801-15801/com.testproj W/YouTubeAndroidPlayerAPI: YouTube video playback stopped due to unauthorized overlay on top of player. The YouTubePlayerView is not contained inside its ancestor android.widget.FrameLayout{cc74690 V.E...... ......I. 0,0-0,0}. The distances between the ancestor's edges and that of the YouTubePlayerView is: left: 0, top: 0, right: 0, bottom: 0 (these should all be positive).

I can see there's a spinner circle. But after that, just a black screen. It's not even able to display a thumbnail or other controls
Demo: https://youtu.be/o2-085JX20g
Here is my code, RN 0.41
/**
 * Sample React Native App
 * https://github.com/facebook/react-native
 * @flow
 */

import React, { Component } from 'react';
import {
  AppRegistry,
  StyleSheet,
  Text,
  View
} from 'react-native';
import YouTube from 'react-native-youtube'

export default class TestProj extends Component {
  render() {
    return (
      <View style={styles.container}>
        <YouTube
          ref="youtubePlayer"
          videoId="KVZ-P-ZI6W4"
          apiKey={'MY_API_KEY'}
          play={true}
          hidden={false}
          playsInline={true}
          loop={false}

          onReady={(e)=>{this.setState({isReady: true})}}
          onChangeState={(e)=>{this.setState({status: e.state})}}
          onChangeQuality={(e)=>{this.setState({quality: e.quality})}}
          onError={(e)=>{this.setState({error: e.error})}}
          onProgress={(e)=>{this.setState({currentTime: e.currentTime, duration: e.duration})}}

          style={{alignSelf: 'stretch', height: 300, backgroundColor: 'black'}}
        />
      </View>

    );
  }
}

const styles = StyleSheet.create({
  container: {
    justifyContent: 'center',
    alignItems: 'center'
  },
  welcome: {
    fontSize: 20,
    textAlign: 'center',
    margin: 10,
  },
  instructions: {
    textAlign: 'center',
    color: '#333333',
    marginBottom: 5,
  },
});

AppRegistry.registerComponent('TestProj', () => TestProj);

I'll try to repro

Update: I just found an interesting fact is that after I rotate the device and the YouTube player loaded properly with the code above.  No idea why 😐

I fixed "unauthorized overlay" issue by making changes for drawer code which is using https://github.com/root-two/react-native-drawer. Added the below parameter for drawer component
styles={{   mainOverlay: {     height: 0,     width: 0   } }}

@jayprakash1 wow that's a weird but somehow attractive theory. I'll be trying this in a week

@jayprakash1 Your solution works really well, thanks !


tests: fix problem with running tests when not root

In cli.spec.ts, it was doing an npm link even though in the docs is says not to do that.  This means the tests were failing if you weren't running as an account that could modify the global node_modules.  I've changed this to use npx link instead.

Closing PR and trying again with a new one to trigger the EasyCLA to reevaluate.


Externalise properties of deletion messages

The message is static, I think that is a good idea, I send a language file. en-US.json, es-ES.json ...

removeCollection() {
      if (!confirm("Are you sure you want to remove this Collection?")) return
      this.$store.commit("postwoman/removeCollection", {
        collectionIndex: this.collectionIndex,
      })
      this.syncCollections()
    },

The same happened in other collections, folders, requests and environments.
New developments:

[x]  Collection
[x]  Folder
[x]  Request
[x]  Environment

Good observation. Hoping for a PR soon.

Done PR :ok_hand:

Will get to it in a jiffy.

Fixed in #1079


Update form.vue

控制台抛出Promise异常
Please make sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's contributing guide (中文 | English | Español).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

能否提供一个「抛出Promise异常」的 demo？


Error: Cannot clear timer: timer created with setInterval() but cleared with clearTimeout()

FakeTimers version : latest release
Environment   : NodeJS 12.13.0

fake-timers should not assert that calls to clearTimer() be passed only timers created by createTimer() and that calls to clearInterval() be passed only timers created by createInterval() because the HTML Living Standard indicates that:

Because clearTimeout() and clearInterval() clear entries from the same list, either method can be used to clear timers created by setTimeout() or setInterval().

The assertion in fake-timer should probably be relaxed.

Love a bug report with a WHATWG link to the reference ❤

Hey everyone, I'm taking a look at this :)

A question :) This clearTimer() function appears in 2 different files, why is that? Should I change it in both files? I would love for some help.

First location: https://github.com/sinonjs/fake-timers/blob/7f8322effa73a94dc43896cdfb49d63e821b32d1/fake-timers.js#L1733
Second location: https://github.com/sinonjs/fake-timers/blob/7f8322effa73a94dc43896cdfb49d63e821b32d1/src/fake-timers-src.js#L429

@itayperry fake-timers is generated from fake-timers-src through bundling it: https://github.com/sinonjs/fake-timers/blob/7f8322effa73a94dc43896cdfb49d63e821b32d1/package.json#L24 - you should generally only need to edit fake-timers-src.

All ready and tested :)
I hope this solves the issue properly.
#324

Fixed in https://github.com/sinonjs/fake-timers/pull/324/commits/1f83b99639f57a3980847da7aaddcf3d11308b5d

In the mean time, I've got my test working again by patching the code from the commit mentioned above using patch-package. Here is the instructions for anyone wants to do the same

Open this file<EMAIL_ADDRESS>and patch this code
Run the following command

npx patch-package @sinonjs/fake-timers

After that, there should be a new file at<EMAIL_ADDRESS>with the following content
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index f723db5..7cdd059 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -444,7 +444,11 @@ function withGlobal(_global) {
         if (clock.timers.hasOwnProperty(id)) {
             // check that the ID matches a timer of the correct type
             var timer = clock.timers[id];
-            if (timer.type === ttype) {
+            if (
+              timer.type === ttype ||
+              (timer.type === "Timeout" && ttype === "Interval") ||
+              (timer.type === "Interval" && ttype === "Timeout")
+            ) {
                 delete clock.timers[id];
             } else {
                 var clear =

How do I disable this functionality completely? I just want to mock dates and now face timers give an error with node pg, which is not my code. So I need to use something else than sinonjs because it has this kind of side effects.

How do I disable this functionality completely? I just want to mock dates and now face timers give an error with node pg, which is not my code. So I need to use something else than sinonjs because it has this kind of side effects.

@tapz Are you running 7.0.1? Cause this was released yesterday and includes the fix for this issue. Not sure how it applies to your case, as I have no idea what you are talking about (way too inspecific), but I would try to npm install @sinonjs/fake-timers@latest.

@tapz Are you running 7.0.1? Cause this was released yesterday and includes the fix for this issue. Not sure how it applies to your case, as I have no idea what you are talking about (way too inspecific), but I would try to npm install @sinonjs/fake-timers@latest.

@tapz you can .install with a parameter indicating what to fake - and you can just not mock timers and only mock date.

@tapz you can .install with a parameter indicating what to fake - and you can just not mock timers and only mock date.


add skipPackageNameForCaller

#898

Related: #867 #898 #972 #973

Any good reason why it was not merged? Well, before it got conflicts...

@dgsb could you possibly take a look on this?

@dgsb Would really appreicate if this could get merged!

@dgsb Would really appreicate if this could get merged!

+1


Use IO::DEFAULT_BUFFER_SIZE in Digest#update

Is about 20% faster when the io doesn't have read buffering enabled.

But where do you cross the line then? 😆

Ah, the dilemma! To follow the rules or to follow the heart?

But I don't think this is really urgent. If you really want the improved spead ahead of its release it's easy to patch this method in.


JBPM-5236 - EJB Migration service - transactions fixed

+1 to merge when build completes, test will follow after migrating jbpm-container test into 6.5.x, thanks @ibek


Fix name shadowing warnings; remove trailing whitespace

Sorry I somehow missed this one!

@garyb No worries! It was a pretty low-priority change, that I noticed in the course of fixing some warnings in SlamData.


Handle updates from dependabot for snowflake-connector-python

Merging changes from https://github.com/chanzuckerberg/napari-hub/pull/1002 cause the causes AttributeError: module 'lib' has no attribute 'OpenSSL_add_all_algorithms' error.

The cryptography version updates from the version bump could cause this.  Analyzing the version dependency on the cryptography package would help find a resolution to this.

Since the vulnerability this addresses requires that an "an attacker is able to supply arbitrary input to the get_file_transfer_type method", and we don't accept user input for our calls to Snowflake, I don't believe this would be a security issue, at the very least. Does that sound right to you, @manasaV3?


Non-total layered effects reifying as total?

I proved false, I think the reification into Tot is to blame (see the type of blah2). cc @aseemr
let repr (a:Type) (_:unit) = a

let return a (x:a) : repr a () = x

let bind a b (x: repr a _) (f:a-> repr b _) : repr b () = f x

let subcomp a (x : repr a _) : repr a () = x

let if_then_else (a:Type) (d1 d2 : unit) (f : repr a d1) (g : repr a d2) (p : Type0) : Type =
  repr a ()

reifiable
reflectable
layered_effect {
  ND : a:Type -> dummy:unit -> Effect
  with repr         = repr;
       return       = return;
       bind         = bind;
       subcomp      = subcomp;
       if_then_else = if_then_else
}

let monotonic #a (wp : pure_wp a) =
  forall p1 p2. (forall x. p1 x ==> p2 x) ==> wp p1 ==> wp p2

let lift_pure_nd (a:Type) (wp:pure_wp a{monotonic wp}) (f:(unit -> PURE a wp)) :
  Pure (repr a ()) (requires (wp (fun _ -> True))) // <--- This is a lift from Tot only
                   (ensures (fun _ -> True))
  = f ()

sub_effect PURE ~> ND = lift_pure_nd

let rec blah () : ND (squash False) () = blah ()

let blah2 () : Tot (squash False) = reify (blah ())

let falso () : Lemma False = let _ = blah2 () in ()

Thanks for the report @mtzguido, reification typechecking was always using Tot for layered effects, not sure why. Anyway, fixed it in master now.

Awesome! Thanks for the lightning fast fix Aseem.


Make WebActionException a RuntimeException

Is there a reason why we have WebActionException an Exception instead of a RuntimeException. This works okay in kotlin as all exceptions are treated by default as runtime exceptions. But the issue comes with the inter-op with java libraries.
For my specific case, when a checked exception is thrown inside a transaction in jooq, it gets wrapped into a DataAccessException whereas a RuntimeException is rethrown as is.

Will this break something?


get panelsets to work

https://pkg.garrickadenbuie.com/xaringanExtra/#/panelset

Need to adapt this CSS to use SCSS variables: https://github.com/gadenbuie/xaringanExtra/blob/master/inst/panelset/panelset.css
and include this dependency: https://github.com/gadenbuie/xaringanExtra/blob/master/inst/panelset/panelset.js

Need to adapt this CSS to use SCSS variables: https://github.com/gadenbuie/xaringanExtra/blob/master/inst/panelset/panelset.css
and include this dependency: https://github.com/gadenbuie/xaringanExtra/blob/master/inst/panelset/panelset.js

Done: https://github.com/apreshill/apero/pull/63

Done: https://github.com/apreshill/apero/pull/63


Sample  design integration into caravel

Hi,
could you please tell me the correctness of the following sample  inverter design and corresponding wrapper or suggest a forum where I can post similar queries?
I have tried to replace the caravel user project with a simple inverter design using only GPIO interface. Corresponding user project example is modified as below
module user_proj_example ( ifdef USE_POWER_PINS
inout vccd1,	// User area 1 1.8V supply
inout vssd1,	// User area 1 digital ground
`endif
// IOs
input  [`MPRJ_IO_PADS-1:0] io_in,
output [`MPRJ_IO_PADS-1:0] io_out,

);
wire [`MPRJ_IO_PADS-1:0] io_in;
wire [`MPRJ_IO_PADS-1:0] io_out;

wire [31:0] inv_in;
wire [31:0] inv_out;

// IO
assign inv_in = io_in;
assign io_out = inv_out;

inverter(
    .inv_in(inv_in),
    .inv_out(inv_out),

);

endmodule
module inverter (
input inv_in,
output inv_out
);
wire [31:0] inv_in;
wire [31:0] inv_out;
always @(inv_in)
begin
inv_out=~inv_in;
end
endmodule
`default_nettype wire
similarly the user_project_wrapper  is modified as below
`default_nettype none
module user_project_wrapper  (
ifdef USE_POWER_PINS     inout vdda1,	// User area 1 3.3V supply     inout vdda2,	// User area 2 3.3V supply     inout vssa1,	// User area 1 analog ground     inout vssa2,	// User area 2 analog ground     inout vccd1,	// User area 1 1.8V supply     inout vccd2,	// User area 2 1.8v supply     inout vssd1,	// User area 1 digital ground     inout vssd2,	// User area 2 digital ground endif
// IOs
input  [`MPRJ_IO_PADS-1:0] io_in,
output [`MPRJ_IO_PADS-1:0] io_out,

);
user_proj_example mprj (
ifdef USE_POWER_PINS 	.vccd1(vccd1),	// User area 1 1.8V power 	.vssd1(vssd1),	// User area 1 digital ground endif
// IO Pads

.io_in (io_in),
.io_out(io_out)

);
endmodule	// user_project_wrapper
`default_nettype wire

The user project wrapper needs to have all pins declared---you cannot change the pin information on the wrapper, since it has to connect to the same set of defined pins in the caravel chip.
If you are doing this outside of the openlane flow, I suggest using the caravan chip, as it is better suited for just dropping a custom circuit into the user project area and wiring it up to the wrapper pins.


slow connection

ADD ISSUE DESCRIPTION HERE
Version: 1.93.1
Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Embedder: codespaces

If you can give more details, what your steps where and what exactly you saw.


Setup initial cross compilation workflow

This is a PR to setup cross gem compilation. Right now, it just adds the ability to cross compile gems via Github UI. We'll figure out publishing later.

cha-ching!

@jbourassa I am very confused about this as well. Not sure where the bug is… Gonna contact rake-compiler team

The current error, I think, is because rake-compiler will put the cross-compiled shared object file into a subdirectory named after the ruby minor version (e.g., lib/wasmtime/3.1/ext.so instead of lib/wasmtime/ext.so).
You can see this in the build log: https://github.com/bytecodealliance/wasmtime-rb/actions/runs/3340442663/jobs/5530540697#step:4:280
You should look first for a ruby-specific precompiled .so, and fall back to lib/wasmtime/ext.so if you can't find it (which means the user compiled upon installation). A lot of this is explained in https://github.com/flavorjones/ruby-c-extensions-explained/tree/main/precompiled
An example of how to do this is
https://github.com/flavorjones/ruby-c-extensions-explained/tree/main/precompiled
also
https://github.com/sparklemotion/nokogiri/blob/main/lib/nokogiri/extension.rb
Hope this helps!


feat: added tuple mapping support

Description
Fixes #448 Added support for tuple mapping, supported mapping attributes and repeat member mappings are no longer created.

Class -> Tuple and Tuple -> Class will map via field names, or if a field doesn't have a name its default positional name is used.
Tuple to Tuple will try to map via field names, otherwise it will attempt to match fields by position.
Support for IgnoreSource, IgnoreProperty and MapProperty.

IgnoreSource and MapProperty will only use field names when available, otherwise if the field doesn't have a name it will use the default positional name.

Question: currently a simple tuple expression is used, should the targets field names be added?
public (int A, int B) Map((int C, int D) source)
{
  // current mapping
  return (source.C, source.D);

  // slightly verbose alternative mapping
  return (A: source.C, B: source.D);
}

I'll update the integration test when we decide on this behaviour

Thanks for the review 🙏
I've added the named fields, opting to not add the name colon when the mapping is positional so: (int, int A) -> (int, int A) becomes: return (source.Item1, A: source.A)
I'll squash the commits and faff around with the integration tests when you're happy with these changes 👍

Looks good for me 😊
Only open discussion to be resolved: https://github.com/riok/mapperly/pull/467#discussion_r1211783801

tuple expressions (eg. (A: 10, B: 20)) are not valid in expression trees (eg. this does not work: Expression<Func<(int, int)>> x = () => (10, 20);.

Interesting, I wonder why they enver added it.
I've partially added ValueTuple support although I haven't cleaned up or properly added the integration tests, so please don't review this.
I added ValueTuple by adding an isExpression bool in the constructor, this is used to determine whether a tuple expression or ValueTuple should be used. valueTupleSymbol is used to get the identifier for ValueTuple, I know passing ISymbol to a mapping is an anti pattern, should a constant string be used instead? Note isExpression could probably be removed with the nullability of valueTupleSymbol be used instead.
This is very hacky, should I create NewTupleExpressionMapping and VewValueTupleMapping instead and reuse the mapping logic?

@TimothyMakkison I think separating the two mappings makes the code easier to read, therefore I'd separate them as ValueTupleExpressionMapping ((A: 10, B: 20)) and ValueTupleConstructorMapping (new ValueTuple<int, int>(10, 10)).

Rebased, renamed files and updated tests.
I wonder if it's possible to configure Verify to show the line number and text diff of any issues. It might make updating the tests faster.

This PR is near completion.
I've added support for MapProperty making TupleExpression  a method mapping if thats okay. I've played around with making tuple methods either directly return the tuple if it doesn't map to any child members, otherwise it uses var target = (src.A, src.B); target.B.C = src.C; return target; syntax. Ideally I'd skip creating a method when it doesn't use MapProperty but doing it to mapperly feel a little hacky.

Added MappingConversionType.Tuple
Added full MapProperty support, including for nested properties. - The logic is a little hacky but could be reused for new instance initializers.
Tuple expression will either be a normal expression (target.T = (src.A, ...)) or generate a method if MapProperty is used on nested properties (target.T = MapToTuple(src)). I achieved this by making MethodDelcarationSyntax nullable, I suspect a neater api change could be done instead.

Thanks will make the changes later. 👍

Regarding the inlined method mapping: For now I'd keep it simple and always generate a method for a tuple expression mapping. The compiler will probably inline it anyway. If we come to the conclusion it is worth to inline these one-liner methods, IMO we should do so in a separate PR, which could probably also affect other method mappings and maybe even be handled on a MethodMapping level.

I already added a slightly hacky way of method inlining. Do you want me to remove it?

Thanks for the review, I've removed method inlining and resolved all your suggested changes.
I'm converting this pr to a draft until I proof read it.


Update office-365-management-activity-api-schema.md

Hi @lindalu-MSFT  Could you pls help to have a review? I only add one line in the doc.

@dingding2 Merged! Will publish to live docs in a moment.


Android cameraRoll gives: Error moving image to camera roll

On Android, cameraRoll option won't work, following error appears on console, the com.xxx is the name of my package:
ImagePicker Error: Error moving image to camera roll: /app_images/Android/data/com.xxxxx/files/Pictures/image-953bd538-17e5-4976-8a0e-c6146c099799.jpg: open failed: ENOENT (No such file or directory)
If i an pick option to load image from gallery everything works as expected. Here is how image picker is initiated:
import ImagePicker from 'react-native-image-picker';

...

var options = {
    title: 'Select image',
    noData: true,
    storageOptions: {
        skipBackup: true,
        cameraRoll: true,
    }
};

...

ImagePicker.showImagePicker( options, (response) => {
    console.log(response);   // response.error contains message above
});

In android manifest i have added following permissions
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

Android 6.0.1 CM13 (Samsung Galaxy S4)
RN v0.42.3
react-native-image-picker - develop with #516

@MilosR Could you describe algorithm for reproducing that bug?

Changing the line line of onActivityResult
final File oldFile = new File(uri.getPath());
to
final File oldFile = new File(getRealPathFromURI(uri));
fixes the problem for for me.
path with uri.getPath():
/app_images/Android/data/com.xxxxx/files/Pictures/image-953bd538-17e5-4976-8a0e-c6146c099799.jpg
path with getRealPathFromURI(uri):
/storage/emulated/0/Android/data/com.xxxxx/files/Pictures/image-953bd538-17e5-4976-8a0e-c6146c099799.jpg
So that was a cause of ENOENT (No such file or directory).
Also, uri returned in response object in case of library pick have content:// prefix, don't know why and now with cameraRoll  it will have file://, that should be uniformed, probably the better option is file://.
I saw that you are doing some refactoring, maybe you have already resolved this issues, but i wanted to mention just in case.

@MilosR I've pushed PR with fixing of current problem. You may check it.

Any update on this PR? Looking forward on implementing this fix on my code.


Open storage path prompt when it wasn’t explicitly set

I added a commit and tested that it works. Seems fine now.


Changing "common:learn.more" to "Learn more" on import cluster page

https://github.com/stolostron/backlog/issues/19371
Signed-off-by: Ella Juengst<EMAIL_ADDRESS>

/lgtm


Monorepo, Turborepo/Yarn Workspaces etc Support

Hi,
Would it be possible to use this plugin in a monorepo setup ?
Where we had an App containing graphql + Packages containing graphql ?
Regards

I haven't tried it yet, but it should work in theory.
If you start a new project, just be aware that the plugin currently doesn't support Vite 3. I have already created a PR to add support, but it has yet to be merged: https://github.com/oscartbeaumont/vite-plugin-relay/pull/424
If you want to go ahead with Vite 3, you can install the package from my branch directly for now:
yarn add vite-plugin-relay@https://github.com/tobias-tengler/vite-plugin-relay#tte/fix-plugin

https://github.com/mickdelaney/vite-relay-monorepo/blob/master/packages/ui/src/UserItem.tsx

@oscartbeaumont
i've added an example using turborepo + vite + relay + vite-plugin-relay
i've personally ended up (in a large monrepo) using tsup + babel for packages, but i've lost HMR as a result.
so would be great to get an idea how to make this work.

There's a vite 2x version here
https://github.com/mickdelaney/vite-relay-monorepo/pull/1
but i've not seen any difference

I am not using Relay in any projects currently so this plugin has been very low on my list of priorities. @tobias-tengler has done some great stuff to upgrade it which I just release to pnpm so give it a shot.

@oscartbeaumont thanks.
for anyone else coming here in a similar situation, this setup works by manually plugging in esbuild-babel into packages
https://github.com/mickdelaney/relay-recoil-post

@tobias-tengler if you have some time next week i'd love to know how I can help out here.
i'm also using this with Hotchocolate btw ;-)


Writer

This adds glyph range support to fea2fea for #772.
 Sorry this isn't such a clean PR :(

oh sorry the merge conflict is because we merged to master the whitespace/linting PR #777
You need to do this from your writer branch, provided that upstream is the name you gave to the fonttools/fonttools remote:
git fetch upstream
git rebase upstream/master
git push --force

Or I can fix it manually if you want.

Please can you fix it. It's giving me the run around. If I click resolve conflicts in this PR I just get a spinning wheel :(

sure no problem. Can you please confirm it is the last three commits which you'd like to add to master?

Yes last 3 commits (well commits -3, -2, since -1 should be no different)

Ok, i'll do that.

sorry about that. That'll teach me to tidy up!

merged manually #779


Not possible to supply a password when using the high level interfaces

When processing a password protected ZIP file using the high level IArchiveReader/Writer interfaces, it is not possible to supply the password as this functionality is only exposed by lower level interfaces.
Cheers,
Paul

Any plans on adding this functionality?

Its fairly easy to hack this. I just put a static string in the lower level class and a set method in the high level API. Not something I’m proud of though, so I didn’t check it in! :)
Cheers,
Paul
From: Sepehr Mohammad<EMAIL_ADDRESS>Sent: Sunday, May 31, 2015 10:49
To: adamhathcock/sharpcompress
Cc: ptallett
Subject: Re: [sharpcompress] Not possible to supply a password when using the high level interfaces (#37)
Any plans on adding this functionality?
—
Reply to this email directly or view it on GitHub https://github.com/adamhathcock/sharpcompress/issues/37#issuecomment-107150857 .  https://github.com/notifications/beacon/AJ1R_ZJ-1emnOasyNrm8k2yfHfDAOJbeks5oOtCRgaJpZM4DMah1.gif

Thanks @ptallett but in our situation, we don't know if the files are password protected beforehand. There needs to be an event which is raised on password protected archives to get the password and continue extracting.

Yes, that would be ideal, but you can workaround it by trying to open the ZIP file without a password, catching the exception, requesting a password, then retrying to open the ZIP file. Works a treat. You need to do something similar if the password is incorrect in any case.
The drawback with this approach is each file in a ZIP container can have a different password, but I just ignored that scenario as its rare.
Cheers,
Paul
From: Sepehr Mohammad<EMAIL_ADDRESS>Sent: Sunday, May 31, 2015 12:12
To: adamhathcock/sharpcompress
Cc: ptallett
Subject: Re: [sharpcompress] Not possible to supply a password when using the high level interfaces (#37)
Thanks @ptallett https://github.com/ptallett  but in our situation, we don't know if the files are password protected beforehand. There needs to be an event which is raised on password protected archives to get the password and continue extracting.
—
Reply to this email directly or view it on GitHub https://github.com/adamhathcock/sharpcompress/issues/37#issuecomment-107156870 .  https://github.com/notifications/beacon/AJ1R_cZI5fKKhyK6qAn62WW8EqO1AIr7ks5oOuPkgaJpZM4DMah1.gif


187434306 set up flow to create extension

General Info

Pivotal Tracker Story
[ ] Breaking?

Changes
Explain your changes here (in such a way that you would understand why you made them a year from now).
Set up the flow for creating extension along with rspec test coverage,

Added extensions controller
Added extensions controller spec.rb

Testing
Explain how you tested your changes.  If testing is not necessary, explain why.
Tested the changes:
spec/controllers/api/v1/extensions_controller_spec.rb
Documentation
Does this PR require documentation.  If so, explain where it can be found.
Documentation is in the group meeting documentation google doc.
Checklist

[x] Name of branch corresponds to story

Included in #47 with necessary fixes.


⚠ Node - us-2656834a.yalaso.top has degraded performance

In 4aff01b, Node - us-2656834a.yalaso.top (http://us-2656834a.yalaso.top/api/v1/ping) experienced degraded performance:

HTTP code: 200
Response time: 22522 ms

Resolved: Node - us-2656834a.yalaso.top performance has improved in baadb5a.


Make _.invoke support deep method paths

Fixes #2612

Coverage increased (+0.03%) to 96.755% when pulling 942ef738761a721edf811378654673f10fd6cac8 on captbaritone:deep-invoke into 817bceec3dd6c7dacb350c99e912e50750efdca0 on jashkenas:master.

Coverage increased (+0.03%) to 96.755% when pulling 942ef738761a721edf811378654673f10fd6cac8 on captbaritone:deep-invoke into 817bceec3dd6c7dacb350c99e912e50750efdca0 on jashkenas:master.

Review @jridgewell ?

Coverage increased (+0.04%) to 96.759% when pulling 97cfcbcbbcedf544a13127dcca3e0ddad94ff830 on captbaritone:deep-invoke into 817bceec3dd6c7dacb350c99e912e50750efdca0 on jashkenas:master.


fix: map empty asset name in order to work with rosetta-cli:check data

Description
rosetta-cli check:data was throwing an error when a token name was empty. This was due to the fact that Symbol is a required field.
Proposed Solution
Empty tokenName has been mapped to \\x to express the empty value
Important Changes Introduced
Some operations now require to understand and parse this new representation
Testing
yarn test

Merging as the error is not related with tests, it's seems hydra is having issues

Merging as the error is not related with tests, it's seems hydra is having issues


Widgets don't work if .NET 8 runtime is not installed

Dev Home version
0.1601.561.0
Windows build number
10.0.26257.0
Other software
No response
Steps to reproduce the bug

Install Dev Home
Have a system without global .NET 8 runtime installed (uninstall and reboot if installed already)
Open Windows Widgets view
Click "+ Add widget"
Choose any "Dev Home" widget (e.g. GPU widget) and click "+ Add widget"

Expected result
Widget is added to the view and fully usable (e.g. shows GPU information)
Actual result
The widget is not added to the view at all because the view freezes, or if it is added it is not working or interactive.

After installing the .NET 8 runtime, the widgets start to work immediately.
The reason is that Dev Home is a self contained .NET 8 app, that seems to use CsWinRT authored components for the widgets.
But these are framework dependant and require a global .NET runtime being installed.
The bug/"feature request" at CsWinRT is open since a long time without any fix being in sight. Would be great if you could help push this internally, as this is a big pain point for users of many WinAppSDK apps - as it's very hard to detect or debug. And rarely happens for .NET developers as they have the .NET SDK installed.
https://github.com/microsoft/CsWinRT/issues/1141
Included System Information
No response
Included Extensions Information
No response

Do you think this issue https://github.com/microsoft/devhome/issues/3599 is related to .NET 8 runtime missing too?

Do you think this issue #3599 is related to .NET 8 runtime missing too?

Do you have the runtime installed? You can check with dotnet --list-runtimes in the console/terminal. If it fails, or no Microsoft.WindowsDesktop.App 8.0.0 is listed, then it is the same issue


Particle System Screen Space and Local Space not rendered correctly

If you choose Screen Space for the particle system and put it under a Screen Entity, the particles will stretch and behave differently than if it was outside the Screen Entity and not using Screen Space. Furthermore, Local Space doesn't work in combination with Screen Space. If I create a group under the Screen Entity, anchor said group to the bottom of the screen, and place the particle system under the group, the particle system won't be anchored to the bottom of the screen, for example.
TL;DR

Particle System stretches and behaves differently under a Screen Entity and using Screen Space.
Local Space not working in conjunction with Screen Space. I can't anchor the particle system anywhere on the screen.

See these bubbles

Thery are stretched, this only happens if I use Screen Space.

If you have a public project example that showcases the issue, that will really help if you can link it here please

Well it's really simple to reproduce the issue. You just need to use the screenspace

ScreenSpaceIssue.zip
The sample project has 2 particle systems, one using screenspace and the other isn't, so you can see how the bubbles are stretched on screen space.

Project to reproduce the issue: https://playcanvas.com/editor/scene/1276844
https://user-images.githubusercontent.com/16639049/142775855-394ae5e9-4a70-4375-9cf4-883a76ec893c.mp4
There are issues/questions around how to control the bounds of the particle effects as it seems very small when a child of an element.
This issue is also reproducible in the engine examples when changing the rendering viewport size. The particles stretch based on the aspect ratio of the canvas.
https://user-images.githubusercontent.com/16639049/142775903-e38dc8a8-7255-470a-a09d-6a688ea5446d.mp4

I pray it's an easy fix! Thanks for looking into this @yaustar

Had a quick chat with the team and unfortunately it's not an easy fix unfortunately. In the short term, you would need to implement a workaround.

Had a quick chat with the team and unfortunately it's not an easy fix unfortunately. In the short term, you would need to implement a workaround. Eg animated UI sprite or a simple particle implementation in the UI space or mapping the UI position to a world space so that the 3D particle system can be moved so that it is always over/under an element

Do you have an ETA to fix this? It's ok if not, I'd just like to know if there is. It's not an easy fix, but there is a fix right?

Do you have an ETA to fix this? It's ok if not, I'd just like to know if there is. It's not an easy fix, but there is a fix right?

Afraid not. It's not a straight forward 'this is how we do it'. The solution for it is not yet known and in some ways, a new feature.
I can think of workarounds for this that involve layers and a little scripting that I hope to think about later this week

I can think of workarounds for this that involve layers and a little scripting that I hope to think about later this week

Thanks, I very much appreciate it.

The solution for it is not yet known and in some ways, a new feature.

A new feature? Interesting.

A new feature? Interesting.

The scope of work is 'large' and also undefined at the moment

Work around where the VFX follows the element entity and renders on type: https://playcanvas.com/editor/scene/1278415
https://user-images.githubusercontent.com/16639049/143048528-c68e7905-4408-445c-ac85-a42457dc9f99.mp4
It renders on top as it relies on the default UI layer clearing the depth buffer.
If you want to render under the UI layer, you will have create a layer for it that renders before the default UI layer but also has clearDepthBuffer enabled: https://developer.playcanvas.com/en/api/pc.Layer.html#clearDepthBuffer

@yaustar is there a workaround where I can dynamically set the scale of the particles based on the rendering viewport size? So basically I cancel out the scaling that is applied.

@yaustar is there a workaround where I can dynamically set the scale of the particles based on the rendering viewport size? So basically I cancel out the scaling that is applied.

Not easily, no. You would have to scale it according it based on the viewport size and how the UI screen scales the elements.
Or you could potentially get the canvas corners of the element that it is following and depending on the size of that, use that to scale the particles relatively: https://developer.playcanvas.com/en/api/pc.ElementComponent.html#canvasCorners

@yaustar is there a workaround where I can dynamically set the scale of the particles based on the rendering viewport size? So basically I cancel out the scaling that is applied.

Not easily, no. You would have to scale it according it based on the viewport size and how the UI screen scales the elements.
Or you could potentially get the canvas corners of the element that it is following and depending on the size of that, use that to scale the particles relatively: https://developer.playcanvas.com/en/api/pc.ElementComponent.html#canvasCorners

Sorry I'm a bit lost on this. As I understand the idea you are talking about is to check the original dimensions of the particles, then check the canvas corners to determine how much it was scaled?

I've updated the example above that scales based on the idea above. It's not perfect but gives an idea on the approach

I've made a fix that works perfectly well
var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {

    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onWindowResize, this);
    this.onWindowResize(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onWindowResize = function(w, h) {
    this.entity.setLocalScale(originalScale.x, (w/h) * originalScale.y, originalScale.z);

};

Just need to attach the script to the particle system.

@yaustar
I just noticed another problem with using the screen space. If you switch from portrait to landscape, and then from landscape to portrait, the particles start moving differently. This seems to be another issue entirely. Do you think this is worth another bug report?
Check it out: make some particles that goes from the bottom of the screen to the top using screen space. Then, switch screen orientation to landscape and back to portrait. See what happens.

No, not worth a new report as the particles screen space seems to be bugged generally

I've made a fix that works perfectly well
var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {

    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    this.entity.setLocalScale(originalScale.x, (w/h) * originalScale.y, originalScale.z);

};

Just need to attach the script to the particle system.

Does that work if the UI screen component blend value is not 0.5?

I've made a fix that works perfectly well
var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {

    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    this.entity.setLocalScale(originalScale.x, (w/h) * originalScale.y, originalScale.z);

};

Just need to attach the script to the particle system.

Does that work if the UI screen component blend value is not 0.5?

I'm using scale mode none

I'm using scale mode none. In fact the scale mode doesn't seem to make any difference. It's working perfectly now, except if the user switches the orientation of the phone, then it glitches a bit...but oh well. I think it's good enough now.

It probably looks a bit odd as you are only scaling along one axis (Y)

I'm using scale mode none. In fact the scale mode doesn't seem to make any difference. It's working perfectly now, except if the user switches the orientation of the phone, then it glitches a bit...but oh well. I think it's good enough now.

It probably looks a bit odd as you are only scaling along one axis (Y)

It doesn't look odd, it looks perfect. The scaling issue only happens on the Y axis. That is the formula to compensate for the stretch on the Y.

Are you using Screen Space and/or Local Space on the particle effect?

Just Screen Space

var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {
    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    this.entity.setLocalScale(originalScale.x, (w/h) * originalScale.y, originalScale.z);
    this.entity.particlesystem.reset();
};

Calling this.entity.particlesystem.reset(); fixes the issue of the particles behaving weird when switching the orientation of the phone. Now everything works perfectly.

Ok this is weird. I am using different particles now, and I noticed that the scaling can happen on the Y only, or the X and the Y. Probably only on the X as well. So I modified the script to let the user decide what axis he wants to apply the fix after testing.
var ParticleScalingFix = pc.createScript('particleScalingFix');

ParticleScalingFix.attributes.add('scaleY', { type: 'boolean' });
ParticleScalingFix.attributes.add('scaleX', { type: 'boolean' });

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {
    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    this.entity.setLocalScale(this.scaleX ? (w/h) * originalScale.x : originalScale.x, this.scaleY ? (w/h) * originalScale.y : originalScale.y, originalScale.z);
    this.entity.particlesystem.reset();
};

Fortunately, even though the scaling that needs to be applied is different for each image, it's always the same axis that needs to be fixed. For example, a certain image will always need to have the Y axis fixed, an other image will always be the X and Y, etc.

The reset trick doesn't work if I have a random scale. Does the reset not touch the scale of the particles? T_T.

Another bug, this one I couldn't fix. If you have random scales, and switch from potrait to landscape, and then back to portrait, the particles become super small.

Sounds like a separate issue with particles.  Can you please post in the engine repo with a example project and steps to reproduce the issue

I can't reproduce the issue without screen space mode. I don't think it's a completely unrelated issue. On another note, do you know how can I check the width and height of the image being used by the particle system? Something like particleSystem.image.width

You can get the texture that the particle system is using via https://developer.playcanvas.com/en/api/pc.ParticleSystemComponent.html#colorMap
However, I don't think it affects the render size and it's done via entity scale and particle scale graph

It does affect how the stretching happens. If the width is bigger than the height, it stretches on the x and y. Otherwise, it stretches only in the y axis. Here's the updated code:
var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
let originalScale;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {
    originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    if (this.entity.particlesystem.colorMap.width > this.entity.particlesystem.colorMap.height)
        this.entity.setLocalScale(h > w ? (h/w) * originalScale.x : (w/h) * originalScale.x, (w/h) * originalScale.y, originalScale.z);
    else {
        this.entity.setLocalScale(originalScale.x, (w/h) * originalScale.y, originalScale.z);
    }

    this.entity.particlesystem.reset();
};

@yaustar Hey yaustar nevermind. The bug of the particles getting super small was my fault. The originalScale variable needs to be in the prototype, otherwise it acts as a global variable that all particleScalingFix can access, instead of being a unique instance of the variable per script. Interesting. Here is the final script, this time I'm having no issues, tested with different particles of different heights and widths.
var ParticleScalingFix = pc.createScript('particleScalingFix');

/** @type {pc.Vec3}*/
ParticleScalingFix.prototype.originalScale = 0;

// initialize code called once per entity
ParticleScalingFix.prototype.initialize = function() {
    this.originalScale =  { ...this.entity.getLocalScale() };

    this.app.graphicsDevice.on('resizecanvas', this.onResizeCanvas, this);
    this.onResizeCanvas(this.app.graphicsDevice.width, this.app.graphicsDevice.height);
};

ParticleScalingFix.prototype.onResizeCanvas = function(w, h) {
    if (this.entity.particlesystem.colorMap.width > this.entity.particlesystem.colorMap.height) {
        this.entity.setLocalScale(h > w ? (h/w) * this.originalScale.x : (w/h) * this.originalScale.x, (w/h) * this.originalScale.y, this.originalScale.z);
    }
    else {
        this.entity.setLocalScale(this.originalScale.x, (w/h) * this.originalScale.y, this.originalScale.z);
    }

    this.entity.particlesystem.reset();
};

FYI, you don't need this line:
/** @type {pc.Vec3}*/
ParticleScalingFix.prototype.originalScale = 0;

You think you can take a look at my patch?  I wouldn't mind if this was used to fix screen space instead of a super complex solution.

It's all recorded here in the ticket so the engine team can consider it when it comes to working on this issue.


Maybe consider a new version instead of 2.0.0 limiting to 20240601

Hey there,
right now I have stopped automatic updates to ESPHome as 20240501 caused a lot of issues for me,
it would be nice if you do new changes and limiting to 20240601 in a new version as probably a lot more people haven´t updated to 20240601 / 20240501,02,03
Could you please explain why 20240601 would be the way to go?
Thanks a lot
B

The ota component requires the platform option since ESPHome 2024.6. If you try to compile the updated example YAML including the platform option the validation will throw an error on pre 2024.6 releases.
In other words: This component still works with previous ESPHome versions but the examples must be adapted a bit (platform: esphome line must be removed).
Do you still suggest a new major release? The breaking chance happened at ESPHome and this project is just affected slightly. ;-)


Add unit tests for DM notifications from Subscribe

Currently, there are server-side unit tests that test that the legacy webhooks post messages to channels, see https://github.com/mattermost/mattermost-plugin-jira/blob/f0cd373a5bcd8fba161f19b595bf574f10bd9294/server/webhook_http_test.go#L660.
We should add tests that similarly verify that direct post notifications are made.
Jira: https://mattermost.atlassian.net/browse/MM-18122

I can take a look at this

@dnguy078 Thank you for taking his on, let us know if you need help/pointers. The best forum is https://community-daily.mattermost.com/core/channels/jira-plugin

Hi @dnguy078, are you still interested in this ticket?

Hi, @levb I opened a pr https://github.com/mattermost/mattermost-plugin-jira/pull/363/files. I left a few outstanding questions in the pr.

Closing issues due to inactivity. This issue can be re-opened with more interest from our community.


Use production URL rather than cloudapps

A small URL update to prevent an unnecessary redirect for users.
https://govuk-design-system-production.cloudapps.digital/ redirects to https://design-system.service.gov.uk/
Not sure if this warrants a changelog entry or not.

thanks, Paul.
ideally we would modify the link in 'src/components/input/README.njk' and regenerate the markdown file with npm start We can ignore the markdown file  in /packages as they get copied over in the release process.


Support 'all fields are mandatory'

Currently, all fields are optional. You have to signal every required field using .isNotEmpty().
The inverse should be possible too: all fields are required, dev has to signal optional fields using .canBeEmpty() or .isOptional().
Comments on best API?

Seems like it should just work off the required attribute on an input field.

@chovy
I have a couple of doubts if that should be the only implementation
a) not all value bindings will come from an input field (rich text editors, drag & drop, etc)
b) it mixes the view-model first approach with the view approach. Your rules are in the view-model, but if a field is optional or required is based on the view that binds to it
We should definitely do that when we support pure view-first declaration though: https://github.com/aurelia/validation/issues/7

Fixed, see https://github.com/aurelia/validation/blob/master/doc/Intro.md#configtreatallpropertiesasmandatory


Feature/226 national downloads timestamps

Related Issues:

EQ-226

Main Changes:

Added columns for the "last refreshed date" and "number of row" to the National Downloads table.
Added a table to the ETL "logging" table that caches the current profile stats at the time of the ETL job.
Updated the table styles on the National Downloads page to accommodate the added rows.

Steps To Test:

Run the ETL while pointed at a local database. This will still cache the current profile stats provided by the attains_eq/profile_stats endpoint, but it will skip the check that uses the stats to certify ETL completion.
Run the client application, then navigate to localhost:3000/national-downloads. It may help to first replace line 16 of app/server/app/routes/api.js with const isLocal = false.
Confirm that the refresh date and the number of rows are displayed appropriately for each profile.
Resize the window and confirm that the table is adequately responsive.

I'm going to make an update to the ETL side of this, there's no need to log every insert when caching the profile stats.

Sounds good. I'll hold off on reviewing for now.

@cschwinderg That change has been made, review at will.