NEXT-00000 - Move ProductReviewLoader logic to core

1. Why is this change necessary?

Currently the ProductReviewLoader is in the Storefront package, but we also need the functionality in the core (for example for the ProductDescriptionReviewsCmsElementResolver).
The logic in both classes is nearly (will be explained below) the same, so we should bring the ProductReviewLoader to the Core and remove the duplicate code with this step
I also added the missing core.listing.reviewsPerPage config option, which allows the administration user to change the size of the review section

Logic-Fixes:

Currently there are two small things different from the Core ProductDescriptionReviewsCmsElementResolver logic and the Storefront ProductReviewLoader
Because of this there are differences the logic of the initial review load and the refetch on a filter change!
The ProductReviewsLoadedEvent is currently only in the Storefront package, because of this on the initial review load by the cms there is no ProductReviewsLoadedEvent fired
The logic of createReviewCriteria is slightly different. In the Core ProductDescriptionReviewsCmsElementResolver the TOTAL_COUNT_MODE_EXACT is missing, because of this missing Criteria setting the initial review total count is wrong
With this PR both logics use the same ProductReviewLoader

Initial page load review total count problem
Before:

After:

The ProductReviewsLoadedEvent & ReviewLoaderResult in the Core already had deprecated code, but with this PR we can fully depreciate this classes

2. What does this change do, exactly?

Changed ProductDescriptionReviewsCmsElementResolver to use the AbstractProductReviewLoader and removed the duplicate functions
Changed ProductDescriptionReviewsCmsElementResolver to now execute the Core ProductReviewsWidgetLoadedHook hook
Added AbstractProductReviewLoader to allow overwriting product review load logic
Added ProductReviewLoader based on the Storefront ProductReviewLoader
Changed ProductReviewResult to include the totalNativeReviews field
Added ProductReviewsWidgetLoadedHook based on the Storefront ProductReviewsWidgetLoadedHook
Added ProductReviewsLoadedEvent based on the Storefront ProductReviewsLoadedEvent
Added Migration1711461585AddDefaultSettingConfigValueForReviewListingPerPage to include the new config option
Added core.listing.reviewsPerPage to config listing with default value 10
Changed ProductDescriptionReviewsTypeDataResolverTest to match Core changes
Added ProductReviewLoaderTest to match core changes
Changed CmsController to use AbstractProductReviewLoader
Changed ProductController to use AbstractProductReviewLoader
Changed ProductReviewLoader to @deprecated and copy logic from Core ProductReviewLoader
Changed ProductReviewsLoadedEvent to @deprecated
Changed ProductReviewsWidgetLoadedHook to @deprecated
Changed ReviewLoaderResult to @deprecated
Changed review.html.twig template to include the new core.listing.reviewsPerPage to config
Changed review.html.twig template to include missing nativeReviewsCount and foreignReviewsCount variables
Changed review.html.twig by including additional component_review_list_action_filters and component_review_list_counter blocks
Changed CmsControllerTest to match Storefront changes
Changed ProductControllerTest to match Storefront changes
Changed ProductReviewLoaderTest to match Storefront changes

3. Describe each step to reproduce the issue or behaviour.

(For the wrong total, just visit a product with more than 10 reviews)

4. Please link to the relevant issues (if any).

Fix NEXT-34000
Fix NEXT-16994

5. Checklist

[X] I have rebased my changes to remove merge conflicts
[X] I have written tests and verified that they fail without my change
[X] I have created a changelog file with all necessary information about my changes
[X] I have written or adjusted the documentation according to my changes
[X] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

Hey @akf-bw thanks for your contribution!
There was already a similiar PR here: https://github.com/shopware/shopware/pull/2389
However deprecation and break strategy can be a hassle when we want to move code from the storefront to the core, please follow up on the discussion in the previous PR and adjust the breaking changes here accordingly.

However deprecation and break strategy can be a hassle when we want to move code from the storefront to the core, please follow up on the discussion in the previous PR and adjust the breaking changes here accordingly.

Most of the changes only affect internal functions/classes and therefore can be easily changed. Except ProductReviewsLoadedEvent & ReviewLoaderResult, but this classes are marked as deprecated.

@mitelg Tests are now all going through. All other checks that currently fail are not related to this PR.
Except PHP Lint which fails on the backwards compatibility of the ReviewLoaderResult, ProductReviewsLoadedEvent but this are false detections.
I'm not sure about ProductReviewsWidgetLoadedHook. Is this the right way to change the type or do I have to change something else here?

What I am not sure, if one wants to have public methods like: AbstractProductReviewLoader::getReviewRatingMatrix and AbstractProductReviewLoader::createReviewCriteria, which are only public due to compatibility reasons.

What I am not sure, if one wants to have public methods like: AbstractProductReviewLoader::getReviewRatingMatrix and AbstractProductReviewLoader::createReviewCriteria, which are only public due to compatibility reasons.

I also added the AbstractProductReviewLoader to give developers the opportunity to override the ProductReviewLoader behavior much more easily. This can be very helpful if you want to implement your own product review logic.

I also added the long time missing features from the TODO's of NEXT-16994 to the review template

@aragon999 I changed it.

I now included all features of the long time missing NEXT-16994 changes in review.html.twig releated to the nativeReviewsCount & foreignReviewsCount variables.
I also added 2 new non-breaking additional template blocks to review.html.twig, which can also be used by SwagCommercial to better override the template.

@mitelg PR should be finished now.

@akf-bw thank you, I did not find time to respond, but I think in particular when you can decorate such services, this makes working in (store)-plugins quite difficult, as there can be so many moving parts.

I just rebased to the latest trunk changes.
@keulinho This PR should be ready for review.

For a better deprecation strategy, I just re-added the old storefront events and hooks back to the controllers so that they are additionally called when the 6.7 flag is inactive. The change also now allows developers to already fully switch over to the new events & hooks before waiting for the removable switch of the old ones.

@keulinho is there an update on the merge process? It's been over a month since this PR was imported in the issue tracker.

@keulinho I rebased again to the latest trunk state. Any updates on the review process?

And I rebased again because there were changes in the review classes in the trunk branch...

@mitelg @keulinho Any news here?

hey @akf-bw
sorry for the delay! we will finally take care :grimacing:

thanks for your contribution @akf-bw 👍🎉💙
it is finally merged


Avoid usage of deprecated ioutil Go package

replace deprecated ioutil functions (ioutil is deprecated since Go 1.16)
fix variable names that collide with imported package name
fix typos

Also update Go version specified by Go modules to ensure a Go version is used in which ioutil is deprecated and replacement functions are available in os and io packages.
Signed-off-by: Tommy TIAN<EMAIL_ADDRESS>Co-authored-by: Mark S. Lewis<EMAIL_ADDRESS>

@bestbeforetoday this looks like a good update. The only question I had about this PR was the use of golang 1.19 for the application-go. Should this be pinned to 1.18?

I just picked 1.19 since it's the current Go version. If you prefer to ensure the application samples can be run using Go 1.18 then I can change the Go version and re-tidy the dependencies.

@jkneubuh I've downgraded the go.mod files from go 1.19 to go 1.18, as suggeted


SqlServer: Scaffold Identity appropriately

After #8680 , scaffolding code will do nothing about identity column,

It should put annotation appropriately on DatabaseModel.
It should print out appropriate fluent API for column which gets identity by convention but is not actually identity.
It should print out fluent API for column which will not get identity by convention but is identity column.
Log warning for identity appearing on invalid property type. (if any)

Also do this for SQLite auto-increment.

See also #8140

Clearing up milestone. I would like to understand the impact of this better before we punt.

From what I understand of current codebase,
When scaffolding db, if the column is identity, we scaffold ValueGenerated.OnAdd. Which SqlServer by convention setups with identity. If column is not identity then ValueGenerated.OnAdd is not put and using key convention, we make ValueGeneratedNever() (unless some other code like Sequence marks it otherwise. So identity should just work fine (as @bricelam found during verification of preview2 packages).
@bricelam can provide more info on his testing.

Yes, the reverse engineered model is fully compatible with the database. The minor improvement would be to generate .UseSqlServerIdentityColumn() in the C# for non-key columns. This would make the model round-trip-able with Migrations.

This is working as expected. It generates .ValueGeneratedOnAdd() which, by convention, leverages the IDENTITY column.


Worker only node with dqlite

microk8s join command has an additional --worker option to add the node as a worker node not running the control plane.
Kubelet and kube-proxy contact a Traefik loadbalancer running locally on port 16443 (same as the API server) and Traefik forwards the requests towards a set of configured API servers.
Kubelet and kube-proxy are authenticated based on x509 certificates so it does not matter which master node they contact.
Nodes running the control plane are labeled with node.kubernetes.io/microk8s-controlplane=microk8s-controlplane, worker nodes are labeled with node.kubernetes.io/microk8s-worker=microk8s-worker.
Nodes labeled with node.kubernetes.io/microk8s-controlplane=microk8s-controlplane at the time of the joining operation will be added to the Traefik loadbalancer.
The leave, join and reset operations were refactored to use click.
This PR is available in the channel branch latest/edge/worker.

@ktsakalozos all looks good to me.  I have seen a couple of things that I'm not sure will work under strict.  Has this been borne in mind at all?

@ktsakalozos all looks good to me. I have seen a couple of things that I'm not sure will work under strict. Has this been borne in mind at all?

@joedborg could you point me to parts of code that would become an issue in strict confinement? I do not think we will have problems porting this work to strict but I might have missed something.

Thank you for the reviews. I am going to merge this so we get it into the 1.23 rc. Bug fixes from now on.


Improve CI workflow for Droplet test

Only calculate the IP once.
Do not include the configuration inside the Debian package but modify it directly inside the droplet.

Self proofreading checklist

[x] The new code clear, easy to read and well commented.
[x] New code does not duplicate the functions of builtin or popular libraries.
[N/A] An LLM was used to review the new code and look for simplifications.
[N/A] New classes and functions contain docstrings explaining what they provide.
[of course] All new code is covered by relevant tests.
[x] Documentation has been updated regarding these changes.

Tests on droplets were cancelled, restarted them ;-)


Upgrade Lucene to 9.8.0

Description
9.8.0 was officially released this morning:
https://lucene.apache.org/core/9_8_0/changes/Changes.html
Related Issues
N/A
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed per the DCO using --signoff
[ ] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Hi, want to have a double check. This won't be backport to 2.x before 2.11 release, right?

This won't be backport to 2.x before 2.11 release, right?

I don't know. For now, I'm just focused on applying the change to main.
We can theoretically backport to 2.x before the start of the release window.

@CEHENKLE please let us know if you are OK making 2.11 release with Apache Lucene 9.8.0, AFAIK there are no regressions we are aware of, the changes we know about were integrated (https://github.com/opensearch-project/OpenSearch/pull/8668, https://github.com/opensearch-project/OpenSearch/pull/10031)

+1 with backporting to 2.11.
With Lucene 9.8.0, https://github.com/opensearch-project/OpenSearch/pull/10246, and https://github.com/opensearch-project/k-NN/pull/1181 together, a user can have parent join feature in nested query for vector search in OpenSearch 2.11.

It’s cutting it a little short for 2.11 but it looks like the performance improvements are compelling.

@CEHENKLE please let us know if you are OK making 2.11 release with Apache Lucene 9.8.0, AFAIK there are no regressions we are aware of, the changes we know about were integrated (#8668, #10031)

Is there a backport PR ready? What are the reasons other than “it’s a little short before a code freeze” not to take it?

Is there a backport PR ready? What are the reasons other than “it’s a little short before a code freeze” not to take it?

I could make one tomorrow morning (essentially bundling 2 PRs).

I've had some folks approach me around the office about this with similar concerns to those voiced by @model-collapse in https://github.com/opensearch-project/OpenSearch/pull/8668:

Before OpenSearch 2.11, the main branch of ml-commons is behind 2.x on some commits. Although this has fixed at the moment, we still suspect that some other repos may have the same kind of problems. The main branch should catch up with 2.x with the latest features & implementations before we back-port Lucene 9.8 to 2.x, otherwise, there will be endless conflicts to deal with.
We believe that all repos have done their functional tests as well as some benchmarkings to their main branch with Lucene 9.8 snapshot and so far there was no negative feedback. But as a rigorous procedure, we suggest all the repo to reproduce their tests with the formal release artifacts of Luence 9.8 (not snapshot version) so as to validate whether there's some negative impact from the Lucene upgrade to OpenSearch. The neural search plugin is absorbing the performance improvement, we also want to see others' feedback.
We'd like to see whether the change of APIs or runtime behavior will have impact to AWS hosted search service which will subscribe this upgrade in the feature. That is another topic. We shall be aware but not discuss it on github.

Based on our "release window" model where we have two weeks to produce a working distribution build from tomorrow's code freeze and the fact that we nearly missed it for 2.10, I'm starting to appreciate the risk that we could end up "just not releasing" 2.11. (Frankly, it is a time of year when people at AWS are particularly concerned about missing releases.)

Would it make sense to do a fast-follow 2.12 release with only Lucene 9.8?

Hi @msfroh , do we have any plan on releasing a new version with this fix any time soon?

Hi @msfroh , do we have any plan on releasing a new version with this fix any time soon?

@LiuCao0614 2.12 as per https://github.com/orgs/opensearch-project/projects/1

Cool thanks @reta .


Fixes #47: Use index correct to find author

Fixes #47: Use index correct to find author
Check whether the .Params.author exists in .Site.Data.authors before calling index on the data object.

Thanks


Enable CodeQL

I think the build won't work until vcpkg is being used as a git submodule rather than assumed to be installed separately on the system.


Axon.Display.as_graph breaks when updating axon from 0.5 to 0.6

Hey there 👋
First of all, thanks again for all the work and effort you all are putting into the Nx libraries, i'm truly amazed by your results.
Then, I was updating the Nx dependencies in a Livebook of mine and I spotted an issue when using Axon.Display.as_graph.
Here the snippet to reproduce it:
Mix.install(
  [
    {:nx, "~> 0.6.1", override: true},
    {:axon, "~> 0.6"},
    {:exla, "~> 0.6.0"},
    {:kino, "~> 0.14"}
  ],
  config: [nx: [default_backend: EXLA.Backend]]
)

batch_size = 4
block_size = 8
shape = {batch_size, block_size}

bigram_model =
  Axon.input("sequence", shape: shape)
  |> Axon.embedding(65, 65)

Axon.Display.as_graph(bigram_model, Nx.template(shape, :f32),
  direction: :top_down
)

It fails with the following error:
** (Axon.CompileError) exception found when compiling layer Axon.Layers.embedding/3 named embedding_0:

    ** (ArgumentError) indices must be an integer tensor, got {:f, 32}
        (nx 0.6.4) lib/nx.ex:14150: Nx.take/3

(pass debug: true to build/compile see where the layer was defined)

Compiling of the model was initiated at:

    (axon 0.6.1) lib/axon.ex:3406: anonymous fn/3 in Axon.get_output_shape/3
    (nx 0.6.4) lib/nx/defn/compiler.ex:158: Nx.Defn.Compiler.runtime_fun/3
    (axon 0.6.1) lib/axon/defn.ex:14: Axon.Defn.__jit__/5
    (nx 0.6.4) lib/nx/defn.ex:443: Nx.Defn.do_jit_apply/3
    (axon 0.6.1) lib/axon.ex:3409: Axon.get_output_shape/3
    #cell:5i2jifureixx5mee:11: (file)

I tried to debug it further, but I couldn't discover much.
I think the Nx.take/3 that is raising the exception is probably called here in Axon.Layers.embedding/3, which it is maybe called here in Axon.embedding/4.... 🤔
☝ the same snippet used to work correctly with Axon v0.5.1 (see screenshot)
Mix.install(
  [
    {:nx, "~> 0.6.1", override: true},
    {:axon, "~> 0.5.1"},
    {:exla, "~> 0.6.0"},
    {:kino, "~> 0.14"}
  ],
  config: [nx: [default_backend: EXLA.Backend]]
)

Let me know if I can help in any way, cheers ✌

Can you try from the main branch?

Hey @seanmor5
I just tried, but no luck. I got the same error
Mix.install(
  [
    {:nx, "~> 0.6.1", override: true},
    {:axon, git: "git@github.com:elixir-nx/axon.git", ref: "main"},
    {:exla, "~> 0.6.0"},
    {:kino, "~> 0.14"}
  ],
  config: [nx: [default_backend: EXLA.Backend]]
)

# ....

Error:
** (Axon.CompileError) exception found when compiling layer Axon.Layers.embedding/3 named embedding_0:

    ** (ArgumentError) indices must be an integer tensor, got {:f, 32}
        (nx 0.6.4) lib/nx.ex:14150: Nx.take/3

(pass debug: true to build/compile to see where the layer was defined)

Compiling of the model was initiated at:

    (axon 0.6.1) lib/axon.ex:3650: anonymous fn/3 in Axon.get_output_shape/3
    (nx 0.6.4) lib/nx/defn/compiler.ex:158: Nx.Defn.Compiler.runtime_fun/3
    (axon 0.6.1) lib/axon/defn.ex:14: Axon.Defn.__jit__/5
    (nx 0.6.4) lib/nx/defn.ex:443: Nx.Defn.do_jit_apply/3
    (axon 0.6.1) lib/axon.ex:3655: Axon.get_output_shape/3
    #cell:gef2wlvqmz5hlji6:10: (file)

@nickgnd I just looked again, and I think the issue is that you are passing an :f32 template tensor as input. When using the embedding layer, the inputs need to be an integer type. If you change Nx.template(shape, :f32) to Nx.template(shape, :u32) can you let me know if it works?

@seanmor5 you're totally right and it makes a lot of sense! It works indeed 🎉

And sorry, I should pay more attention to error message 🙈


Refactor testutil package and its dependencies

Fixes #203
This is a draft PR for refactoring the test classes since the main code is still being refactored.
Current changes are :

CommandTestUtil class :

Added static field VALID_MODULENAME_CS2103T
Added static field VALID_ZOOMLINK

ModelManagerTest class :

Commented out the whole code for the moment

ModuleListTest class :

Has been refactored
all test, except "resetData_withDuplicateModules_throwsDuplicateModuleException()" can now function properly

AddressBookBuilder class :

Renamed to -> ModuleListBuilder
Has been refactored

Added new files :

EditModuleDescriptorBuilder class
TypicalModules class

Codecov Report

Merging #209 into master will increase coverage by 1.98%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #209      +/-   ##
============================================
+ Coverage     19.63%   21.62%   +1.98%
- Complexity      269      299      +30
============================================
  Files           177      177
  Lines          2715     2715
  Branches        224      224
============================================
+ Hits            533      587      +54
+ Misses         2147     2092      -55
- Partials         35       36       +1

Impacted Files
Coverage Δ
Complexity Δ

...seedu/address/model/module/grade/GradeTracker.java
19.04% <0.00%> (+19.04%)
1.00% <0.00%> (+1.00%)

src/main/java/seedu/address/model/ModuleList.java
70.83% <0.00%> (+20.83%)
10.00% <0.00%> (+3.00%)

...rc/main/java/seedu/address/model/ModelManager.java
87.23% <0.00%> (+21.27%)
20.00% <0.00%> (+5.00%)

...c/main/java/seedu/address/model/module/Module.java
22.50% <0.00%> (+22.50%)
6.00% <0.00%> (+6.00%)

...a/seedu/address/model/module/UniqueModuleList.java
51.21% <0.00%> (+29.26%)
12.00% <0.00%> (+7.00%)

...main/java/seedu/address/model/module/ZoomLink.java
54.54% <0.00%> (+54.54%)
2.00% <0.00%> (+2.00%)

...in/java/seedu/address/model/module/ModuleName.java
60.00% <0.00%> (+60.00%)
4.00% <0.00%> (+4.00%)

src/main/java/seedu/address/model/Model.java
100.00% <0.00%> (+100.00%)
2.00% <0.00%> (+2.00%)

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 b31a771...a192395. Read the comment docs.


Probably better show full event in before_time instead a part of event in all_day

Why?

Sorry my fault, probably this would preferable just in my case.
Otherwise it`s hard to determine if there are any events which starts before time_start and wont able to resize calendar times automatically to show this event as full.

The point is to show all events that are within given period or end of event or start of event within the period too. So we do not see when it starts maybe but we see that it ends here.
What do you think?

Yes you absolutely right.
In my case i need somehow determine if all events fits inside time range. If not i resize time range to display all events properly.
I`ll already find solution to fix this with small extension.

Yuo can extend it with parameter if you want. Create a special parameter to show events that only fit the day or all that cross the day. I can accept that PR.


Trying to Download Firmware Results in a weird Error(?)

Samsung isn't hosting the firmware for that device and CSC. Try XFA.

Ah I see. Btw did you mean XDA? Thank you.

No, XFA is the South Africa CSC, which does have firmware available.
Zachary Wander
On Dec 28, 2021, 1:46 AM -0500, adikpb @.***>, wrote:

Ah I see. Btw did you mean XDA? Thank you.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>

Ah thank you.


Adds how to author libraries

@SpaceK33z - Made the requested changes!

Thank you for the feedback! Have made some of the suggested changes.

Thanks, I think this reached a level where we can merge it. It still need some minor fixes and additions, but this can be done in separate PRs.

Thanks!


Horizontal Level always displayed as "Max" - again

Hi,
until yesterday I was using node-red-contrib-ui-level without any trouble with an older version. Yesterday I updated to the latest version 0.1.27. After the update a new deployment was urged by all my ui-level nodes.
After having done so, I experienced, that depending on the browser type the level display worked correctly or not:
Firefox browser on my PC: Level display ok
Firefox browser on Android smartphone and tablet: Only "Max" is displayed on all level meters
Chrome browser on Andoid tablet: Level display ok.
Who has an idea how to eliminate the dependency of browser types?
Best regards
Gerhard

I have no problems with Android smartphone (Chrome, Brave, Firefox)
It may be needs some kind of cache clearing. (Clear private data)

Unfortunately, cache (and other private data) clearing didn´t help.
Other ideas?

Sorry, I closed the issue unintentionally instead of sending a comment.
Clearing the cache (and other private data) did not help.
Other ideas?

No currently. Can you debug the firefox on mobile device for any possible errors?
I know it is painfull and not always successful but if can try ..
https://developer.mozilla.org/en-US/docs/Tools/about:debugging

Also, as it probably will take some more investigations:
How do you run the node red. (locally, cloud, docker ... )?
Do you remember what was previous (working) version of ui_level?
What is the versions of node red and the dashboard you are using?

Debugging will need some time, but concerning your other questions.:

Node Red runs in a Raspbery Pi 3+

I cannot remember the old version of ui_level, but I loaded it into the palette on May 2019. Since this date I never made an update (because everything worked fine)

Node red versions:

15 May 14:13:38 - [info] Node-RED Version: v0.20.6

15 May 14:13:38 - [info] Node.js  Version: v10.20.1

15 May 14:13:38 - [info] Linux 4.19.97-v7+ arm LE

15 May 14:13:40 - [info] Paletten-Nodes werden geladen

15 May 14:13:47 - [info] Dashboard version 2.22.1 started at /ui

15 May 14:13:51 - [info] Einstellungsdatei: /home/pi/.node-red/settings.js

15 May 14:13:51 - [info] Kontextspeicher: 'default' [ module=memory]

15 May 14:13:51 - [info] Benutzerverzeichnis: /home/pi/.node-red

15 May 14:13:51 - [warn] Projekte inaktiviert: editorTheme.projects.enabled=false

Von: hotNipi<EMAIL_ADDRESS>Gesendet: Freitag, 15. Mai 2020 14:05
An: hotNipi/node-red-contrib-ui-level<EMAIL_ADDRESS>Cc: gerhard1951<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Betreff: Re: [hotNipi/node-red-contrib-ui-level] Horizontal Level always displayed as "Max" - again (#23)
Also, as it probably will take some more investigations:
How do you run the node red. (locally, cloud, docker ... )?
Do you remember what was previous (working) version of ui_level?
What is the versions of node red and the dashboard you are using?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/hotNipi/node-red-contrib-ui-level/issues/23#issuecomment-629197103 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AL435QXLJPD7M2UKBXRR533RRUVWVANCNFSM4NBOS4XA .

Any good reason why not to update node-red to latest version?
v0.20.6 seems kind of old. Can't say if makes any difference according to current issue but ...

Ok, I did one update blindly. 0.1.28 will be shortly available..
Try and let me know..

Sorry, it took me some time to update.
I updated node-red and nodejs as you recommended. After the update, version ui_level 0.0.24 was installed. With this version, the bars worked correctly. Then I updated ui_level to version 0.1.28 - and  everything works also fine with all output devices and browsers. Unfortunately I cannot say if the nodered-update or ui_level version 0.1.28 were responsible for the improvement.
Nevertheless, thanks for your immediate help and recommendations.
Best regards
Gerhard

Nice. But with your help I managed to ui_level also work again with the Edge browser.
Thanks a lot :). Case closed

Just for your information: I tested the dual level mode.  Now, the top bar shows always full length independent of the actual value, the bottom bar shows the right value. But only on my Android devices with Firefox.
On an Android device  with Chrome browser and on my Windows PC with Firefox it works correctly.
Best regards
Gerhard
Von: hotNipi<EMAIL_ADDRESS>Gesendet: Freitag, 15. Mai 2020 18:54
An: hotNipi/node-red-contrib-ui-level<EMAIL_ADDRESS>Cc: gerhard1951<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Betreff: Re: [hotNipi/node-red-contrib-ui-level] Horizontal Level always displayed as "Max" - again (#23)
Closed #23 https://github.com/hotNipi/node-red-contrib-ui-level/issues/23 .
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/hotNipi/node-red-contrib-ui-level/issues/23#event-3341759596 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AL435QQ7HXIDH5KTXWGB533RRVXT5ANCNFSM4NBOS4XA .

v0.1.29 has fix for dual mode. It was me not testing all layouts after previous fix was applied.


Any plans for schema update

Do you have any plans for the next version with the newest schemas? It's been quite a while since the last update, and there are quite a lot resources for azurerm provider missing.

I'm going to release new plugin version before May

Released 0.6.14


ntopng

Hi,
had a first look at ntopng, seems very easy, but the command args are hardcoded in the init script.
@fichtner with OpenConnect plugin you told me templating init script is not allowed.
Can you push me in a direction how to build a plugin via rc vars?
# Add the following lines to /etc/rc.conf to enable ntopng:
#
# ntopng_enable (bool):         Set it to "YES" to enable ntopng
#                               Default is "NO".
# ntopng_flags (flags):         Set extra flags to ntopng
#                               Empty by default.
# ntopng_pidfile (path):        Path to the pidfile
#                               Default /var/run/ntopng/ntopng.pid
#

. /etc/rc.subr

name=ntopng
desc="Monitors network traffic in realtime"
rcvar=ntopng_enable

load_rc_config $name

: ${ntopng_enable:=NO}
: ${ntopng_pidfile:=/var/run/ntopng/ntopng.pid}

httpdocs_path=/usr/local/share/ntopng/httpdocs
scripts_path=/usr/local/share/ntopng/scripts
callbacks_path=/usr/local/share/ntopng/scripts/callbacks
user_path=/usr/local/etc/ntopng-users.conf

start_precmd=ntopng_precmd
command=/usr/local/bin/ntopng
command_args="-U ntopng -G ${ntopng_pidfile} -1 ${httpdocs_path} -2 ${scripts_path} -3 ${callbacks_path} -e"

ntopng_precmd()
{
        local rundir=${ntopng_pidfile%/*}
        if [ ! -d $rundir ] ; then
                install -d -m 0755 -o ntopng -g ntopng $rundir
        fi
}

run_rc_command "$1"

I can load it via ntopng_flags .. plugin will follow soon :)
Execpt additional config args it's finished.

Nice, correct solution. Got to catch a flight. Der you in two weeks 😊

On 18. Aug 2018, at 07:31, Michael<EMAIL_ADDRESS>wrote:
Closed #793.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Adding latch tests for shift&mask AST dynamic part-select enhancements

Enhancing tests as per  #2112 request. This PR is mainly #2079 with test for latch detection mechanism.
This test is already enabled and passing
make -j$(nproc) test | tee log && grep -e "dynamic" log && grep -e "make test" log

Running dynamic_part_select.ys..   Passed "make test".

Can we merge this? This PR only adds tests and they pass.


Spotifybeta cask is broken

Spotifybeta cask is broken.
Now, I typed
$ brew cask install spotifybeta

to result,
==> Downloading http://download.spotify.com/beta/spotify-app-<IP_ADDRESS>9.ge4845795-1223.dmg
######################################################################## 100.0%
==> This subcommand requires root privileges: bsexec
Error: Empty plist input

What's happend ?
I think the error is to blame for this line.
https://github.com/caskroom/homebrew-versions/blob/master/Casks/spotifybeta.rb#L13
But, I do not know how to fix.

No, that’s unrelated. It seems you might be experiencing a recent issue, fixed in https://github.com/caskroom/homebrew-cask/pull/9491. Please brew update && brew upgrade brew-cask && brew cleanup && brew cask cleanup and try again.

This issue already answered phinze on IRC.
brew upgrade was after install passed.
thanks.


As a project data user, I can retrieve a time series of a gridded product through the Unity shared data catalog endpoints (DAPA).

integrate Time Series calls through DAPA endpoints. high level architecture for this can be found here: https://lucid.app/lucidchart/538bc24b-24de-4717-98bc-3e1f52a331f8/edit?invitationId=inv_0daa327b-ab9e-4e74-8361-6fce97569421&page=MgBFQgTIbtBp#

@zx128 (Zhangfan) will be the lead for this feature (I don't have permissions to add assignees).  He will implement the Process Mapper component to interface between DAPA clients and SDAP running in MCP/EKS.

SDAP DAPA API implemented and deployed to Unity-Dev, Unity-Test, and Unity-Prod.


enhancement(model): CommandInteractionDataResolved HashMap fields.

This lines up our implementation with Discord's and simplifies our serde implementation
breaking changes:

CommandInteractionDataResolved's fields are HashMap
Removed InteractionMember's ID field

closes: #1141

Is the order in which discord sends the users consistent? Then this can break cases where you rely on that.

@Erk- How so?

@Erk- How so?

Because the order of iteration of a HashMap is not in any way consistent, it is not consistent with the insertion order, and it may change between two runs as hashes are randomized in Rust.
So if for example Discord sends the resolved members in the order they are in the message that information will be lost.

Nothing about this is marked on the Discord documentation to my knowledge. Without stability guarantees of the fields order from the Discord API, It's unreliable to rely on that, and thus unnecessary to store it.

Codecov Report

Merging #1225 (e4d188d) into next (8019885) will decrease coverage by 0.27%.
The diff coverage is 85.71%.

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

@@            Coverage Diff             @@
##             next    #1225      +/-   ##
==========================================
- Coverage   30.87%   30.60%   -0.28%
==========================================
  Files         362      360       -2
  Lines       14307    14192     -115
==========================================
- Hits         4418     4343      -75
+ Misses       9889     9849      -40

Impacted Files
Coverage Δ

model/src/application/interaction/mod.rs
50.00% <ø> (ø)

cache/in-memory/src/event/member.rs
82.71% <50.00%> (-1.44%)
:arrow_down:

cache/in-memory/src/event/interaction.rs
95.65% <100.00%> (+0.19%)
:arrow_up:

http/src/routing/route_display.rs
9.59% <0.00%> (-0.77%)
:arrow_down:

http/src/request/mod.rs
78.57% <0.00%> (ø)

model/src/user/flags.rs
80.00% <0.00%> (ø)

http/src/request/channel/thread/mod.rs
0.00% <0.00%> (ø)

model/src/guild/system_channel_flags.rs
80.00% <0.00%> (ø)

model/src/gateway/presence/activity_flags.rs
0.00% <0.00%> (ø)

http/src/request/channel/thread/create_thread.rs
0.00% <0.00%> (ø)

... and 5 more

Continue to review full report at Codecov.

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


treewide: Get rid of go 1.13

Kubernetes builds with go1.14.
Terraform has an upstream patch which fixes the macos mojave issues -
it's a bug in terraform, not go.

Motivation for this change
Only building a single version of go makes everything simpler. Additionally, when go 1.15 lands, we won't have to deal with go1.13 which will become unsupported.
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

thanks!

Any reason to remove 1.13 when it is still supported?

In addition to remove a still supported version that might be used downstream, this change does not even fits CONTRIBUTING.md as it mentions in the pull request description. Yikes.

nixpkgs doesn't need to include all versions of everything. Go 1.13 should still be available in the nixos-20.03 channel.

There are packages, like https://github.com/NixOS/nixpkgs/pull/86957, which, although they build, won't work on 1.14 (just yet). We should give the developers time to adapt to these changes as long as 1.13 is supported. There's no point in having broken packages in nixpkgs.
From https://golang.org/doc/devel/release.html:
Each major Go release is supported until there are two newer major releases.
From https://golang.org/project/:
Go 1.14 (February 2020)
Go 1.13 (September 2019)
Go release cycle is 6 months so that gives us plenty of time for dropping the support sometime before 20.09, but it was rather hasty to remove it so early before EOS.

I'll take a look at that pr tonight - if something doesn't work on go 1.14
we should ensure that we have an updated bug report to go :). Do you happen
to know how to repro the failure? Just run it?
Historically, we haven't done a good job of keeping up to date on go (we
migrated off 1.12 last week, 3 months after it was deprecated), so I'm
trying to move everything forward onto the latest release as much as
possible.
If we need to add go 1.13 back it's a pretty simple diff, but we should
only do it if it's actually an upstream bug :).
On Tue, May 5, 2020, 15:51 1000101<EMAIL_ADDRESS>wrote:

There are packages, like #86957
https://github.com/NixOS/nixpkgs/pull/86957, which, although they
build, won't work on 1.14 (just yet). We should give the developers time to
adapt to these changes as long as 1.13 is supported. There's no point in
having broken packages in nixpkgs.
From https://golang.org/doc/devel/release.html:
Each major Go release is supported until there are two newer major
releases.
From https://golang.org/project/:
Go 1.14 (February 2020)
Go 1.13 (September 2019)
Go release cycle is 6 months so that gives us plenty of time for dropping
the support sometime before 20.09, but it was rather hasty to remove it so
early before EOS.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/86036#issuecomment-624270993, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADWWN3WO2AQBINX4REJNZTRQBU4RANCNFSM4MRCCPTA
.

I'll take a look at that pr tonight - if something doesn't work on go 1.14
we should ensure that we have an updated bug report to go :). Do you happen
to know how to repro the failure? Just run it?

@c00w yes, just run it, but you'd have to provide configuration files and a backend to run it with. I'm trying to push this forward so we could implement it a module, package was just the first, intermediary, step.
FYI this is how the incompatibility "bug" looks like:
blockbook -blockchaincfg=/root/blockchaincfg.json -datadir=/opt/blockbook/data/db -sync -internal=:9030 -public=:9130 -explorer= -dbcache=1073741824

E0505 21:01:46.455691    1140 blockbook.go:369] rpc: json: invalid number literal, trying to unmarshal "\"/Satoshi:<IP_ADDRESS>/\"" into Number Retrying...

The problem, with a lengthy discussion, is described here: https://github.com/golang/go/issues/37308

Historically, we haven't done a good job of keeping up to date on go (we
migrated off 1.12 last week, 3 months after it was deprecated), so I'm
trying to move everything forward onto the latest release as much as
possible.
I understand and totally agree. You did a great job cleaning up 1.12 since it reached EOS but removing 1.13 seems to be a bit rushed.

If we need to add go 1.13 back it's a pretty simple diff, but we should
only do it if it's actually an upstream bug :).
I've already reported it to upstream, they are aware of it and said they make sure the app is rewritten until 1.13 reaches EOS but until then, I'd like to keep the package working.

Sweet - thanks for the info :) reading the go issue issue, it looks like
upstream has decided not to fix it. I'll poke the code tonight to see if I
can get a patch for it to work on 1.14. I'm thinking about changing the
decoder to an empty interface, checking if it's an empty strong, if not
decoding it as a number. Or maybe seeing if a pointer to a number can
decode "" as nil.
Re: right speed - I think it's good to not keep old versions of software
around if they're not needed for a build purpose. If we need them to build
we need them to build, but if we don't it's not worth having Hydra build it
even if it is technically within the support window.
On Tue, May 5, 2020, 17:11 1000101<EMAIL_ADDRESS>wrote:

I'll take a look at that pr tonight - if something doesn't work on go 1.14
we should ensure that we have an updated bug report to go :). Do you happen
to know how to repro the failure? Just run it?
@c00w https://github.com/c00w yes, just run it, but you'd have to
provide configuration files and a backend to run it with. I'm trying to
push this forward so we could implement it a module, package was just the
first, intermediary, step.
FYI this is how the incompatibility "bug" looks like:
blockbook -blockchaincfg=/root/blockchaincfg.json -datadir=/opt/blockbook/data/db -sync -internal=:9030 -public=:9130 -explorer= -dbcache=1073741824
E0505 21:01:46.455691    1140 blockbook.go:369] rpc: json: invalid number literal, trying to unmarshal ""/Satoshi:<IP_ADDRESS>/\ http://<IP_ADDRESS>/\"" into Number Retrying...
The problem, with a lengthy discussion, is described here: golang/go#37308
https://github.com/golang/go/issues/37308
Historically, we haven't done a good job of keeping up to date on go (we
migrated off 1.12 last week, 3 months after it was deprecated), so I'm
trying to move everything forward onto the latest release as much as
possible.
I understand and totally agree. You did a great job cleaning up 1.12 since
it reached EOS but removing 1.13 seems to be a bit rushed.
If we need to add go 1.13 back it's a pretty simple diff, but we should
only do it if it's actually an upstream bug :).
I've already reported it to upstream, they are aware of it and said they
make sure the app is rewritten until 1.13 reaches EOS but until then, I'd
like to keep the package working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/86036#issuecomment-624308435, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AADWWN3YDZ77VF3KVGXNEUTRQB6IDANCNFSM4MRCCPTA
.

Re: right speed - I think it's good to not keep old versions of software
around if they're not needed for a build purpose. If we need them to build
we need them to build, but if we don't it's not worth having Hydra build it
even if it is technically within the support window.

Right, and I admire your determination, but maybe it would be wiser not to waste your precious time on something that will eventually get fixed in a few week's time. And what if there are other packages (which we do not know of yet) affected by this change?
Anyway, let me know how you decided :). Cheers!

Right, and I admire your determination, but maybe it would be better not to waste your precious time on something that will eventually get fixed in a few week's time

Wait - I thought you were registering a complaint. If you're just looking for how to patch go1.13 back in, just rebase on master, then running
git revert --edit 3e0aa4af2da4e4010cd9011aaa125fed7ca220e6

should add it back for you, just drop the terraform fixes and everything should be g2g.

And what if there are other packages (which we do not know of yet) affected by this change?
Thankfully grep works pretty well to verify this :)

Sent patch + commented on the PR.

I didn't expect Go 1.14 to have as many regressions. Usually Go is pretty good about keeping back-compat compared to other languages. For other languages, we usually keep a few versions around as well.
@c00w can you link to the revert PR?

Right, and I admire your determination, but maybe it would be better not to waste your precious time on something that will eventually get fixed in a few week's time

Wait - I thought you were registering a complaint. If you're just looking for how to patch go1.13 back in, just rebase on master, then running
git revert --edit 3e0aa4af2da4e4010cd9011aaa125fed7ca220e6

should add it back for you, just drop the terraform fixes and everything should be g2g.

I was :) - I'd like to have this working in master, too. But that would mean reintroducing go1.13 i.e. reverting this MR.

And what if there are other packages (which we do not know of yet) affected by this change?

Thankfully grep works pretty well to verify this :)

There could be packages that do build but won't work (same as blockbook package).

I was :) - I'd like to have this working in master, too. But that would mean reintroducing go1.13 i.e. reverting this MR.

I was what? I have 0 objections to adding go1.13 back in if we need it for packages - let me know if that revert command doesn't work. I feel strongly if we don't need it to build something we shouldn't keep it around.

There could be packages that do build but don't work (same as it's with blockbook).

Yeah but we're only humans and robots. There is a limited amount of verification the current tooling can do - everything builds is a pretty good sign, everything builds, every binary executes + all configured tests pass is the best we can do (and is I believe what happened in this PR) :). If we refuse to change anything in the build system because we fear we might cause undetectable regression in runtime behaviour, then we'd never update anything.

@c00w can you link to the revert PR?

Sorry? I don't follow what you're asking?

@c00w I've managed to convince upstream to fix it on their end, so disregard my complaint :). Thanks for your help.

We do keep a go_1_12 in pkgs/top-level/aliases.nix which returns a throw "go_1_12 has been removed"; - if we decide to keep go_1_13 removed, it should probably still be in there for consistency.

re-added Go 1.13. Sorry for the delay.
I did a partial revert, just to re-add Go 1.13 and left the accompanying fixed in the tree.


Bug: Exported notes do not preserve last modification timestamp

Exported note files do not preserve the last modification timestamp.
It seems a regression https://github.com/farmerbb/Notepad/issues/67
Steps to reproduce

Export an existing note
Import the exported note
The imported note's timestamp changes to the current time

Information
Android version: 8.0
Device:
App Version: 3.0.4

You're right, the app currently only imports notes using the current date time, which is not ideal
I just made a PR that fixes this.
Note that for your steps you need to also make sure that the setting for Exported filename is set to either Timestamp + first line or First line + timestamp. Using First line of text will lose the modified date in the export:

I see, thanks for your fix! @samontab


Add angular velocity and torque calculation in the ControlledAttitude

Overview
Add angular velocity and torque calculation in the ControlledAttitude.
Issue

#110

Details
Angular velocity and torque calculation features are added in the controlled attitude mode.
The torque calculation will be validated after merging this PR.
Validation results

The angular velocity calculation result

Conditions

ControlledAttitude mode
Main: Body +X points to the earth's center
Sub: Body +Z points to the velocity direction

Result

The angular velocity in the Y-axis is compatible with the orbital period.
0.00112 rad/s = 92.8 min/rev

Scope of influence
Only for controlled attitude users.
Supplement
NA
Note
NA

コメントもらった部分は修正したのでマージします。


Update vLLM dependency to 0.5.3.post1

What does this PR do?
CI test run, not for review yet.

Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a Github issue or the forum? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines, and
here are tips on formatting docstrings.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

Dropping this PR as we droped paged and use moe-kernels directly instead.


Example for Ethereum Name Service

[x] Get address
[x] Get multihash
[x] Get resolver

Added in #17


ttf-tw-moe: first version

Motivation for this change
Add a pack of 2 fonts used as referenced for teaching in Taiwan.
Things done

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

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

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

Thank you @Jiehong


ticdc: unstable uts TestRemoveExpiredFilesWithoutPartition

What did you do?
TZ="America/New_York" go test -run ^TestRemoveExpiredFilesWithoutPartition$ github.com/pingcap/tiflow/pkg/sink/cloudstorage -v
What did you expect to see?
The test pass.
What did you see instead?
=== RUN   TestRemoveExpiredFilesWithoutPartition
=== PAUSE TestRemoveExpiredFilesWithoutPartition
=== CONT  TestRemoveExpiredFilesWithoutPartition
[2024/03/19 03:15:35.891 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/5/2021-01-01]
[2024/03/19 03:15:35.892 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/5/2021-01-01/meta]
[2024/03/19 03:15:35.893 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/meta]
[2024/03/19 03:15:35.893 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table2/5/2021-01-01]
[2024/03/19 03:15:35.894 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table2/5/2021-01-01/meta]
[2024/03/19 03:15:35.895 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table2/meta]
[2024/03/19 03:15:35.895 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/400200133/12/2021-01-01/20210101]
[2024/03/19 03:15:35.896 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/400200133/12/2021-01-01/20210101/meta]
[2024/03/19 03:15:35.897 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema2/table1/400200150/12/2021-01-01/20210101]
[2024/03/19 03:15:35.898 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema2/table1/400200150/12/2021-01-01/20210101/meta]
[2024/03/19 03:15:35.898 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema2/table1/meta]
[2024/03/19 03:15:35.899 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/5/2021-01-02]
[2024/03/19 03:15:35.900 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table1/5/2021-01-02/meta]
[2024/03/19 03:15:35.900 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table2/5/2021-01-02]
[2024/03/19 03:15:35.901 -04:00] [INFO] [local.go:57] ["failed to write file, try to mkdir the path"] [path=/var/folders/7k/4g8s_f9d64xftf1277sk3d0h0000gn/T/TestRemoveExpiredFilesWithoutPartition1580636193/001/schema1/table2/5/2021-01-02/meta]
[2024/03/19 03:15:35.901 -04:00] [INFO] [path.go:452] ["removing expired files"] [expiredDate=2021-01-01]
path_test.go:437:
Error Trace:	/Users/linkmyth/workspace/tiflow/pkg/sink/cloudstorage/path_test.go:437
Error:      	Not equal:
expected: 0x10
actual  : 0x0
Test:       	TestRemoveExpiredFilesWithoutPartition
--- FAIL: TestRemoveExpiredFilesWithoutPartition (0.02s)
FAIL
FAIL	github.com/pingcap/tiflow/pkg/sink/cloudstorage	0.682s
FAIL
Versions of the cluster
Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):
(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):
(paste TiKV version here)

TiCDC version (execute cdc version):
(paste TiCDC version here)

/severity moderate


[SPARK-42898][SQL] Mark that string/date casts do not need time zone id

What changes were proposed in this pull request?
This removes the need for a time zone id when casting from StringType -> DateType and DateType -> StringType.
Why are the changes needed?
It is mostly for consistency with what the code is actually doing.  Marking it as needing A time zone id has no real impact to the actual execution.
Does this PR introduce any user-facing change?
No
How was this patch tested?
I just compiled it for now. I assume that the existing tests will cover it.

LGTM, I would just add a unit test to CastSuite to prevent regressions

@MaxGekk This might take a little while. I don't want to delete the test, but I also cannot just switch the data types over to Timestamp because the partition string is not always stored in a format that is compatible with TimestampType. So I ma going to have to spend some more time understanding the test to see if there is a good way to update it for TimestampType.

@revans2 IMO the test failure makes sense, we just need to change it to another timezone-aware type to save the UT coverage.

Hi @revans2, is there any update on this issue?

@yaooqinn Sorry I keep meaning to get back to this, but it is not high up on my priority list. If someone else wants to take it across the finish line I am happy to let them. If not I'll see when I can find some time to do it.

cc @ulysses-you who is the last one to touch this part

After offline discussion, @pan3793 will try to take over this pr. Thank you all!


Autocomplete onInputChange does not work with Debounce

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
When I do something like this...
const debouncedOnQueryChange = debounce(
    q => setQuery && setQuery(q),
    500,
  )

  const handleLocalQuery = async (e, val, reason) => {
    setLocalQuery(val)
    debouncedOnQueryChange(val)
  }

the debounce setQuery gets called immediately without debouncing.
Expected Behavior 🤔
It should debounce.
Steps to Reproduce 🕹
Steps:

add debouncing to ur onInputChange autocomplete
watch it not debounce

Your Environment 🌎
System:
    OS: macOS 11.5.2
    CPU: x64 Intel(R) Core(TM) M-5Y51 CPU @ 1.10GHz
    Memory: 302.28 MB / 8.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.4.0 - ~/.nvm/versions/node/v14.4.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.5.3 - ~/.nvm/versions/node/v14.4.0/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Utilities:
    CMake: 3.13.4 - /usr/local/bin/cmake
    Make: 3.81 - /usr/bin/make
    GCC: 4.2.1 - /usr/bin/gcc
    Git: 2.25.0 - /usr/local/bin/git
  Servers:
    Apache: 2.4.46 - /usr/sbin/apachectl
  SDKs:
    iOS SDK:
      Platforms: iOS 13.4, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
    Android SDK:
      Build Tools: 25.0.2, 30.0.2
      API Levels: 25
  IDEs:
    Emacs: 26.1 - /usr/local/bin/emacs
    Nano: 2.0.6 - /usr/bin/nano
    VSCode: 1.59.0 - /usr/local/bin/code
    Vim: 8.2 - /usr/bin/vim
    Xcode: 11.4.1/11E503a - /usr/bin/xcodebuild
  Languages:
    Bash: 3.2.57 - /bin/bash
    Go: 1.11.5 - /usr/local/bin/go
    Elixir: 1.11.3 - /usr/local/bin/elixir
    Java: 1.8.0 - /usr/bin/javac
    Perl: 5.30.2 - /usr/bin/perl
    PHP: 7.3.24 - /usr/bin/php
    Python: 2.7.16 - /usr/bin/python
    Ruby: 3.0.0 - /Users/NAME/.rvm/rubies/ruby-3.0.0/bin/ruby
  Databases:
    MongoDB: 4.0.3 - /usr/local/bin/mongo
    PostgreSQL: 12.7 - /usr/local/bin/postgres
    SQLite: 3.32.2 - /Users/NAME/Library/Android/sdk/platform-tools/sqlite3

It doesn't look like this bug report has enough info for one of us to reproduce it.
Please provide a CodeSandbox (https://material-ui.com/r/issue-template-next), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve

Closing since no reproduction was provided within 14 days.


Friendship v2

This PR includes:

Improvement of the performance of queries by Implementing friendship with 2 rows for mutual friendship.

Closes #3

Hello @Oluwadamilareolusakin :wave:
Thanks for all your feedback :pray: it was really interesting finding another way to implement those associations. :eyes:
The only funny thing is we end up with the same associations we have once asked to change but with scope inside the association that we didn't know it can be there. :dango: :raised_hands:


fix(types): fix types for useFieldAtom

In the last PR I forgot to change the types for useFieldAtom, sorry

The types for useFieldAtom are correct


gopls: fix privacy breach

Motivation for this change
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

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

Result of nixpkgs-review pr 119861 at 2796cfa5 run on x86_64-linux 1

2 packages built successfully:

gopls
vimPlugins.vim-go

Do you have an upstream commit for this change?

https://github.com/golang/tools/commit/9712d02be394497cca363d5276a3cb7236d39984

Do you have an upstream commit for this change?

golang/tools@9712d02

That... does the opposite of this though? It's not really clear to me if we want to diverge from upstream in this way for non-packaging reasons - this can be done by end-users in their system configs, for example.

I also don't see the privacy breach here. This is the same level of information one would expose when having a http useragent set. There is no other private information leaked.


Add popup display for diff

If there were no diff files you selected, and push Ctrl+A , the display will popup.

Sorry for so many comments, but let's learn together. :sweat_smile:


fix(alarms): Fix alarm dimensions to respect case

Goal
Fix alarm dimensions to respect case. This is related to CDK bug hashicorp/terraform-cdk#235

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


LICENSE for NuGet packages

Hi,
Do you intend for these NuGet packages to also be under the MIT license - https://www.nuget.org/packages/Xrm.Crm.WebApi/?
Thanks,
Ariel

Hi @ariel11 !
Yes I do! Fell free to use as you like.


Roll Flutter from 25e0e290e6a4 to d8783ff4c2d5 (24 revisions)

https://github.com/flutter/flutter/compare/25e0e290e6a4...d8783ff4c2d5
2022-06-10<EMAIL_ADDRESS>Reland Added MaterialStatesController, updated InkWell et al. #103167 (flutter/flutter#105656)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from e6bb4982e7a2 to 63845d96054b (1 revision) (flutter/flutter#105776)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 40ee4d540791 to e6bb4982e7a2 (1 revision) (flutter/flutter#105775)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 367e938449d4 to 40ee4d540791 (1 revision) (flutter/flutter#105765)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from b0b1f240555c to 367e938449d4 (1 revision) (flutter/flutter#105761)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from a4cdb1e232ed to b0b1f240555c (1 revision) (flutter/flutter#105757)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 6142374fb732 to a4cdb1e232ed (2 revisions) (flutter/flutter#105753)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 38c0a2fb5c06 to 6142374fb732 (1 revision) (flutter/flutter#105749)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 612c8be59d64 to 38c0a2fb5c06 (3 revisions) (flutter/flutter#105748)
2022-06-10<EMAIL_ADDRESS>Roll Flutter Engine from 51dc995186fe to 612c8be59d64 (4 revisions) (flutter/flutter#105746)
2022-06-09<EMAIL_ADDRESS>Enable arm64 module_test_ios and plugin_lint_mac in prod (flutter/flutter#105744)
2022-06-09<EMAIL_ADDRESS>Roll Flutter Engine from fc8cdcf4e9dd to 51dc995186fe (2 revisions) (flutter/flutter#105741)
2022-06-09<EMAIL_ADDRESS>exports public API types from scheduler/.dart (flutter/flutter#105737)
2022-06-09 she/her Enable skipped test for Dart URI logs from DWDS (flutter/flutter#105274)
2022-06-09<EMAIL_ADDRESS>Updating PrimaryScrollController for Desktop (flutter/flutter#102099)
2022-06-09<EMAIL_ADDRESS>Roll Flutter Engine from 9ca483101b6d to fc8cdcf4e9dd (4 revisions) (flutter/flutter#105726)
2022-06-09<EMAIL_ADDRESS>Make flutter attach respect the --dds-port flag. (flutter/flutter#105560)
2022-06-09<EMAIL_ADDRESS>Roll Flutter Engine from 250cf343d2b5 to 9ca483101b6d (2 revisions) (flutter/flutter#105720)
2022-06-09<EMAIL_ADDRESS>[flutter_tools] add shuffle to hermetic run_tests (flutter/flutter#105462)
2022-06-09<EMAIL_ADDRESS>Export public API types from foundation/.dart library. (flutter/flutter#105648)
2022-06-09<EMAIL_ADDRESS>Roll Flutter Engine from 9cda78030a1b to 250cf343d2b5 (1 revision) (flutter/flutter#105713)
2022-06-09<EMAIL_ADDRESS>Enable two new arm64 ios tests (flutter/flutter#105636)
2022-06-09<EMAIL_ADDRESS>Roll Flutter Engine from 080f810cb96a to 9cda78030a1b (1 revision) (flutter/flutter#105710)
2022-06-09<EMAIL_ADDRESS>Roll Plugins from f7d99fa5dbac to aa6c864d2acb (9 revisions) (flutter/flutter#105707)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-plugins
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Plugins: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


No global gulp

Global gulp is an anti-pattern.
This file is only ever run in a gulp context, gulp will [now] immediately throw as undefined when run.
npm will throw a warning if gulp is missing as a peerDependency.

:+1:


Roll Engine from bde97299d4fa to 845a259a18de (1 revision)

https://github.com/flutter/engine/compare/bde97299d4fa...845a259a18de
2022-04-16<EMAIL_ADDRESS>Roll Dart SDK from 1f7ca11878fc to 0a3c40c7860e (1 revision) (flutter/engine#32720)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Thisis asom


Open note in new-window

Open notes in new window on desktop.

Yes please! Open as a floating window option would be so good!!
Thank you for your hard work on this plugin

Update 0.0.11 includes this feature.

Thank you @karstenpedersen - you are amazing. Will share this with the guys


Add Win32_Service collector

Fixes #55

AppVeyor failed, I'm not 100% it is related to this PR, or some random AppVeyor issue?
Exception calling ".ctor" with "3" argument(s): "End of Central Directory record could not be found."
https://ci.appveyor.com/project/martinlindhe/wmi-exporter/build/job/ah1eyp67r4arwccq

Weird, but yeah, looks like AppVeyor. All the steps work out fine locally, including the 7z invocation.

I posted the issue over here: http://help.appveyor.com/discussions/problems/6200-merge-build-failed-where-pr-build-succeded-2-hours-ago

The build still fails. But I got a reply from them:

Hi Martin,

Problem is that PR (and normal build as well) does not go to this code path. Only tagged build does.
I did small research and I see that it is Expand-Archive throws insde build.ps1. Probably because wix-binaries.zi did not download properly.
I believe you can debug from here. Useful tool is RDP. However note that RDP session does not contain the same environment variables as build session so you may need to enter some absolute values or set $Version and $env:MSI_ARCH to debug.
Please let us know if you need more help.


Reduced CPU and memory used by formatPrometheusTags function.

Coverage decreased (-1.6%) to 95.756% when pulling 33a3203554401722f643066e16a1c1381fedf1e8 on prometheus-stats-opti into 963ce5826331e508e944a2945b6bcb036209e0c5 on master.


build electron project for arm target

I am beginner in electron packager. i want to build my project for target arch arm v7. what should i do?
running this:

electron-packager . MYPROJECT --platform=linux --arch=armhf --overwrite --prune
will cause in:
Unsupported arch armhf; must be one of: ia32, x64

my host machine is windows. does electron packager add support for arm build?

electron-packager does not currently support armhf mostly because we've been waiting for Electron upstream to update their build system to say precisely which ARM architecture they support (for example, what happens when they add support for ARM v8?). This has been tracked in #107 and https://github.com/electron/electron/issues/2343


CGO Meeting 3 - Agenda & Notes

CGO Meeting 3 - Agenda & Notes

So is this where you'd like suggestions for the meeting to be posted?

So is this where you'd like suggestions for the meeting to be posted?

No - I have posted a link to the Agenda in Discord and updated permissions as well. Could you amend your section if you have time ? - S


Failed to load plugin react: Cannot find module 'eslint-plugin-react'

I'm running Atom 1.20.0 and have Standard installed in a local project.
Every time I open a .js file I get:

Something bad happened
Failed to load plugin react: Cannot find module 'eslint-plugin-react'
Referenced from: C:\node\sandbox\aws\node_modules\standard\eslintrc.json

The contents of C:\node\sandbox\aws\node_modules\standard\eslintrc.json:
{
  "extends": ["standard", "standard-jsx"]
}

This project doesn't use React at all, however the page type in the bottom right-hand corner of Atom says JavaScript (JSX).
This hasn't been a problem before, and I certainly don't want to have to change all my React projects to .jsx rather than .js to avoid this error.
How do I make this error go away..?

I suggest re-installing a fresh copy standard. It looks like there may have been an issue pulling down some dependencies.
Hope this helps! I'm going to close this issue, but feel free to comment if you're still seeing problems,


Hydra Agent Console Implementation

Related to:  https://github.com/HTTP-APIs/hydra-python-agent/issues/124
Draft pull request that will continuously be updated along the next days

Can you share some rough mockups first

@xadahiya Sure, today I'll share here where I am/next steps

Here's a picture of the current state:
(Click to expand)

This is the developed static version, with some small differences to the Mockup. I've added @xadahiya's suggestion, which is an input field that will contain the raw command. The first icon on the upper toolbar is to hide the HydraGraph(so I can focus only on the right as Chris suggested), the second leads to our home page. I've made one big design change from the mockup that was to use our yellow to match Hydra Eco's colors. The overall aspect should be this with some modifications to functionality as I progress with the actual coding.
I uploaded  a small video so you can see everything: https://youtu.be/qiXgwdAltJE

Next steps
As for the next steps I plan to start to port each of the logic into modular dynamic pieces for it to be built based on the ApiDoc. For that, I'll create a Mock Flask backend(The Agent layer that will forward the commands) which will just return the Mocked processed object that the Frontend needs for now. Later when Vishal is able to join, I think implementing the Flask Endpoints with the actual processing replacing the Mocks would be a good task.

I've created the Flask backend with five endpoints:

serve(react app)
start-agent(receives hydrus url)
hydra-doc(sends hydra doc to frontend).

There are two endpoints I've created but the functionality is yet to be developed:

apidoc_graph(send a formatted representation of the api doc), I've already written the format there.
send_command(communication endpoint to forward messages to hydrus)

With that, I started implementing the dynamic components and the Collection Buttons are already generated based on the ApiDoc.

Next steps
Will finish up the Collection buttons componentand proceed with the operations component and properties component, so they also are generated according to the ApiDoc. After that, I will code the interactions of building the request combining these three components.

Porting the UI https://github.com/HTTP-APIs/hydra-python-agent-gui

Finished Dynamic buttons and ported it to a modular component. I was having some context problems but everything is ok now, the Console component can already receive the collection component clicked according to the apidoc:

Porting the UI https://github.com/HTTP-APIs/hydra-python-agent-gui
As we've settled on our last call Friday I'll port this GUI to another repo soon.

One observation @vddesai1871 asked me to raise about the api_doc endpoint on the Flask backend. We have one endpoint for a raw Hydra Doc(used to build the UI) and one for a processed Hydra Doc in Visjs's format(used to build the Graph). The second one could be done both front end and backend. I decided it would be better to do it backend for two reasons:

It's really likely that changes in Hydra/Core will be made in the future, and this processing might have to be updated. And as our codebase is mostly in Python, I think having it on the Flask Python Backend side than having it in jsx/React would make it much easier for future contributors to interact when it's necessary.
If we want to modify and extend the visualization to show some resources or some other information as a summary or connection to other servers in the future, this could be done only backend side and the Ui doesn't have to be modified and will already be compatible (

This PR was ported to a new repo as commented above.
A small PR was merged(https://github.com/HTTP-APIs/hydra-python-agent/pull/126) related to a small functionality here in the agent that is important for the GUI.


LaTeX issues

Hello,
I hope you don't mind me reaching out here. I was trying an example which I believe used to work with 4.2.4c:
size 10 7
set font texcmss hei 0.35

begin texpreamble
  \usepackage[T1]{fontenc}
  \usepackage{amssymb}
end texpreamble

set texlabels 1
set texscale scale

begin graph
   title   "\tex{Plot $f(x)$}"
   ytitle  "y-label"
   x0title "x-label"
   xaxis min 0 max 5 dticks 1 offset 0 symticks
   yaxis min -6 max 6
   let d1 = (x-sqrt(5))/((x-1)*(x-4)) from 0 to 5
   d1 line color red
   xlabels off
   x0labels on
   x0axis on symticks off
   x2axis on symticks off
end graph

calling gle -d pdf -tex texgraph.gle 3 times in a row shows
GLE 4.3.2[texgraph.gle]-C-R-
Error running:  "texpreamble.tex"
/bin/sh: texpreamble.tex: command not found

>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
>>> error: did not get size for TeX font!
[texgraph][.eps]
Error running:  "texgraph_tex.tex"
/bin/sh: texgraph_tex.tex: command not found

then
GLE 4.3.2[texgraph.gle]-C-R-[texgraph][.eps]
Error running:  "texgraph_tex.tex"
/bin/sh: texgraph_tex.tex: command not found

then
GLE 4.3.2[texgraph.gle]-C-R-[texgraph][.eps][.pdf]
Error running: pdflatex "texgraph.tex"
>> LaTeX error:
! Missing number, treated as zero.
<to be read again>
                   i
l.20 ...ebox(0,0)[lb]{\scalebox{inf}{{\Huge -6}}}}

>> LaTeX error:
!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on texgraph.log.

This is on Mac (intel chip) with GLE 4.3.2, with pdfTex from texlive 2021
Any clue what might be going on? thanks!

Additional pointers: when trying this example I get:
1st try
gle -d pdf -tex bar.gle
GLE 4.3.2[bar.gle]-C-R-[bar][.eps]
Error running:  "bar_tex.tex"
/bin/sh: bar_tex.tex: command not found

2nd try
gle -d pdf -tex bar.gle
GLE 4.3.2[bar.gle]-C-R-[bar][.eps][.pdf]

which produces an output but not quite right


Insert with select subquery

Is your feature request related to a problem? Please describe.
I'm trying to insert an entity with one column having a subquery (select max(column) from table where foreign_key=some_id) + 1. As far as I could see this is not currently possible, the only way to do this currently is by using the defaultRaw property config option, which does not allow a where clause with a dynamic value.
Describe the solution you'd like
Changing defaultRaw to allow a function which gets called with the entity as a paramer would probably work fine. Maybe allowing a QueryBuilder instance as return value would be nice too to prevent raw sql when not needed
Describe alternatives you've considered
Using the QueryBuilder to insert instead of the usual em.create() em.persistAndFlush(). This gets ugly quick though as you're basically rewriting a lot of functionality already in the ORM.
Additional context
N/A
If this is already possible, please let me know!
If not, I'd be happy to try and make a PR myself if needed.

Changing defaultRaw to allow a function which gets called with the entity as a paramer would probably work fine. Maybe allowing a QueryBuilder instance as return value would be nice too to prevent raw sql when not needed

I am not sure what you mean by that. Can you provide some examples around it?
Note that defaultRaw needs to be a string, it can't be anything dynamic, it is literally what gets used in the database schema as the column default -> it needs to be an SQL fragment. And I doubt you can use subqueries in schema definition, although I might be wrong.
Note there is onCreate property option which might be something similar to what you want.

It seems I have made some incorrect assumptions about defaultRaw. I assumed it was a sql statement that was used as a default for inserts when the column/property had no value provided, instead of a default in schema definition.
onCreate would not work due to concurrency issues I'm afraid.
What I'm trying to do, is get this query working without using the QueryBuilder, as I'd like to avoid it when possible.
INSERT INTO table (col1, col2, anumbercol, aforeignkeycol)
VALUES ("X", "Y", (SELECT MAX(anumbercol) FROM table WHERE aforeignkeycol = 12345 FOR UPDATE) + 1)

This will lock records and execute queries in proper order, and won't result in duplicate anumbercol values even when executing 30+ queries at the same  time.
So some possible solutions I can think of:

@Formula but for inserts instead of selects?
Support for triggers. I have not tested if this will work regarding the concurrency issues with this query though.
Or just allowing raw sql inside of em.create(), but this might be an ugly solution

Let me know if you need any further context!

I would say this is quite an edge case and you should use QB here. Also making multiple queries in one transaction with explicit isolation level set might work, I dont think you need a subquery at all.

You were right, a transaction with LockMode.PESSIMISTIC_WRITE worked fine. I thought I had tried this before but probably forgot the lockmode or something, thanks for your time!


TextEdit Cleanup

Continuation of #31739
Builds on #50122

This PR seems larger then it is, mainly moving around code and renames, rather then any changes.
The main aim of this PR is to cleanup after extracting features into CodeEdit and to prepare the API going forward.  Will do EditorSettings as a separate PR.
Given TextEdit has organically grown rather large it became a bit of mess, so I took the time here to reorganise the methods; hopefully will made it easier to browse.
With that said, the three main API changes are:

Block caret no longer exists and is now an enum CaretType, currently with Line and Block as the options. The methods have been renamed appropriately:

cursor_set_block_mode --> set_caret_type
cursor_is_block_mode --> get_caret_type

Line wrapping has now been changed from enable / disable to  an enum LineWrappingMode, with None and Boundary meaning the control boundary as it currently works. Similarly the methods have been renamed:

set_wrap_enabled --> set_line_wrapping_mode
is_wrap_enabled  --> get_line_wrapping_mode

Cut, copy and paste are now overrideable with:

_cut
_copy
_paste

Otherwise bedsides exposing many new methods, the following renames have taken place:
Caret:

cursor_get_blink_enabled --> set_caret_blink_enabled
cursor_set_blink_enabled --> is_caret_blink_enabled
cursor_set_blink_speed --> set_caret_blink_speed
cursor_get_blink_speed --> get_caret_blink_speed
set_right_click_moves_caret --> set_move_caret_on_right_click_enabled
is_right_click_moving_caret --> is_move_caret_on_right_click_enabled
set_mid_grapheme_caret_enabled --> set_caret_mid_grapheme_enabled
get_mid_grapheme_caret_enabled --> is_caret_mid_grapheme_enabled
cursor_set_line --> set_caret_line
cursor_get_line --> get_caret_line
cursor_set_column --> set_caret_column
cursor_get_column --> get_caret_column
adjust_viewport_to_cursor --> adjust_viewport_to_caret
insert_text_at_cursor --> insert_text_at_caret
get_word_under_cursor --> get_word_under_caret

Selection:

is_selection_active --> has_selection
get_selection_text --> get_selected_text

Insert Mode:

set_insert_mode --> set_overtype_mode_enabled
is_insert_mode --> is_overtype_mode_enabled

Read only:

set_readonly --> set_editable
is_readonly --> is_editable

Signals:

cursor_changed --> caret_changed

Properties:

caret_block_mode --> caret_type
caret_enabled --> wrap_mode
caret_moving_by_right_click --> caret_move_on_right_click

Supersedes #47548
Apart from the couple features that need a little more work, after this I'm happy to close #31739

Lots of documentation mistakes, but the code looks ok at a glance.
I noticed that you remove cache. in lots of places. What was it and why is being removed?

cache was a struct that mainly held theme data. It wasn't really useful as a "cache" and contained some useless/duplicate properties. Removed it as it didn't really add anything apart from extra complexity and to clean up the properties.

Thanks!


Raven DB Support

There are I think two issue still open....

we need to reconfigure the tests so that we only use one container
we need to ensure that the async session is consequently used.


Hi there is a bug

Microsoft PowerToys version
<IP_ADDRESS>
Running as admin

[ ] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
2022-03-14.txt
✔ Expected Behavior
No response
❌ Actual Behavior
No response
Other Software
No response

/dup #16975

This is a duplicate, Could you please go in the original issue and look at the conversation to add some more information about your case? This seems to be caused by some remote connection with stylus devices connected.


Dact 417

Change to add firstName and lastName to the filing as that is what chips filing consumer is looking for, rather than name.

more of a question  - if it's a corporate director, does the company name come from name?
If so, should this code set the relevant fields in the OfficerFiling, or is it simpler just to leave like this, and let the chips-filing-consumer extract what it requires?

more of a question - if it's a corporate director, does the company name come from name? If so, should this code set the relevant fields in the OfficerFiling, or is it simpler just to leave like this, and let the chips-filing-consumer extract what it requires?

good question,  i believe corporate is in name,  but what I am not sure is how chips-filing-consumer / CHIPS expects to receive it.  If its in name then i think we will need to make a change in chips filing consumer,  if in first name lastName, then we will need to split it out from name into those 2.
I will ask that question to Mike and Craig and Leslie.


How to generate ca cert file.

Hi,
bosh.ca-cert-file is required, but can you advise how to generate this file?

It's likely the same ca cert from creds.yml you use with bosh alias-env - https://bosh.io/docs/cli-v2/#alias-env

@MatthewPJ @gordcorp is correct, that is the same ca_cert you use for alias-env


Improve save_as_json

Could you please change line 602 in text_output.py to "result = json.dumps(result, allow_nan=True, indent=4, ensure_ascii=False)"?  It currently stores the json output without indentation and not allowing non-ascii characters.

ensure_ascii=False was made default in 738fd98490584c492cf2f7873bdddaf7a0ec9d40, but indent will remain optional because it increases the final size. You can pass it in as a argument when saving result.save_as_json(..., indent=4).


GraphQL throws TypeError: Cannot read property 'startToken' of undefined

What version of OpenTelemetry are you using?
0.12.1-alpha.7
What version of Node are you using?
14.10.0
What did you do?
Followed the GraphQL example, and applied it to our project.
What did you expect to see?
I expected that my requests to our GraphQL server would work as before (and perhaps with slightly added delay due to tracing).
What did you see instead?
{
  "errors": [
    {
      "message": "Cannot read property 'startToken' of undefined",
      "locations": [
        {
          "line": 3,
          "column": 5
        }
      ],
      "path": [
        "infoItem",
        "title"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "exception": {
          "stacktrace": [
            "TypeError: Cannot read property 'startToken' of undefined",
            "    at getSourceFromLocation (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:229:5)",
            "    at addSpanSource (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:47:18)",
            "    at createResolverSpan (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:113:5)",
            "    at createFieldIfNotExists (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:71:13)",
            "    at wrappedFieldResolver (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:355:6)",
            "    at field.resolve (/Users/multiply/work/graph-api/node_modules/graphql-extensions/src/index.ts:274:18)",
            "    at field.resolve (/Users/multiply/work/graph-api/node_modules/apollo-server-core/src/utils/schemaInstrumentation.ts:103:18)",
            "    at resolveFieldValueOrError (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:502:18)",
            "    at resolveField (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:460:16)",
            "    at executeFields (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:297:18)"
          ]
        }
      }
    },
    {
      "message": "Cannot read property 'startToken' of undefined",
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "infoItem",
        "section"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "exception": {
          "stacktrace": [
            "TypeError: Cannot read property 'startToken' of undefined",
            "    at getSourceFromLocation (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:229:5)",
            "    at addSpanSource (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:47:18)",
            "    at createResolverSpan (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:113:5)",
            "    at createFieldIfNotExists (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:71:13)",
            "    at wrappedFieldResolver (/Users/multiply/work/graph-api/node_modules/@opentelemetry/instrumentation-graphql/src/utils.ts:355:6)",
            "    at field.resolve (/Users/multiply/work/graph-api/node_modules/graphql-extensions/src/index.ts:274:18)",
            "    at field.resolve (/Users/multiply/work/graph-api/node_modules/apollo-server-core/src/utils/schemaInstrumentation.ts:103:18)",
            "    at resolveFieldValueOrError (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:502:18)",
            "    at resolveField (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:460:16)",
            "    at executeFields (/Users/multiply/work/graph-api/node_modules/graphql/execution/execute.js:297:18)"
          ]
        }
      }
    }
  ],
  "data": {
    "infoItem": {
      "title": null,
      "section": null
    }
  }
}

Additional context

We're using Apollo Server

We're also using federation

loc can be undefined in the following bit of code:
https://github.com/open-telemetry/opentelemetry-js-contrib/blob/4de41c8f8dbc7b9c8d5bb75a99d7afad6d1001f7/plugins/node/opentelemetry-instrumentation-graphql/src/utils.ts#L226
I fixed it locally by adding the following code before checking for startToken:
if (!loc) {
    return source;
}

If it matters at least the first field type that fails, seems to be of type Document, when debugging further up the callstack

@Multiply please provide how can I reproduce it.

@Multiply please provide how can I reproduce it.

@obecny I'll see if I can make a tiny reproducible example for you.

@obecny I'll see if I can make a tiny reproducible example for you.

Here's a hack of a repro I threw together as I've bumped up against this issue as well.  I'm not sure it's an issue with the instrumentation or how Apollo federation composing it's calls to graphql execute.  Regardless, this seems to work for me:
Set up a sample federation example:
git clone https://github.com/patrick91/apollo-federation-local-services.git
cd apollo-federation-local-services/
npm install
npm install @opentelemetry/api @opentelemetry/instrumentation-graphql @opentelemetry/tracing @opentelemetry/node @opentelemetry/exporter-collector
node server.js

Test via curl:
curl -s -X POST  -H "content-type: application/json; charset=utf-8" --data '{"operationName":null,"variables":{},"query":"{continents {code,name}}"}' http://localhost:4000/graphql | jq

That should return:
{
  "data": {
    "continents": [
      {
        "code": "AF",
        "name": "Africa"
      },
      {
        "code": "AN",
        "name": "Antarctica"
      },
      {
        "code": "AS",
        "name": "Asia"
      },
      {
        "code": "EU",
        "name": "Europe"
      },
      {
        "code": "NA",
        "name": "North America"
      },
      {
        "code": "OC",
        "name": "Oceania"
      },
      {
        "code": "SA",
        "name": "South America"
      }
    ]
  }
}

To repro the error, prepend the following:
const opentelemetry = require('@opentelemetry/api');
const { GraphQLInstrumentation } = require('@opentelemetry/instrumentation-graphql');

const { ConsoleSpanExporter, SimpleSpanProcessor } = require('@opentelemetry/tracing');
const { NodeTracerProvider } = require('@opentelemetry/node');
const { CollectorTraceExporter } = require('@opentelemetry/exporter-collector');

const exporter = new CollectorTraceExporter({ serviceName: 'countries' });
const provider = new NodeTracerProvider({
    plugins: {
      http: { enabled: false, path: '@opentelemetry/plugin-http' },
      https: { enabled: false, path: '@opentelemetry/plugin-https' },
      express: { enabled: false, path: '@opentelemetry/plugin-express' },
    },
});

const graphQLInstrumentation = new GraphQLInstrumentation({});
graphQLInstrumentation.setTracerProvider(provider);
graphQLInstrumentation.enable();

provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));

to the top of server.js (before anything else).
Then run server.js:
node server.js

And hit the local service again via curl:
curl -s -X POST  -H "content-type: application/json; charset=utf-8" --data '{"operationName":null,"variables":{},"query":"{continents {code,name}}"}' http://localhost:4000/graphql | jq

Which now returns:
{
  "data": null
}

The null is because the exception the original report cites is caught but not surfaced.
This comes down to @apollo/gateway executeQueryPlan.executeQueryPlan function calling graphql.execute with an explict document structure that lacks the loc attribute (see<EMAIL_ADDRESS>around line 81).  Adding in the loc attribute either from the requestContext or operationContext also resolves the issue, but I'm not familiar enough with either graphql or apollo implementation to know if either of those are correct or if patching the instrumentation is the correct answer.
In my casual testing, both solutions produced pretty similar output in Zipkin but nothing about my testing was particularly scientific.

thx @gitelr will check it soon

Hi @obecny  @gitelr
The same issue can be reproduced on my program. Only applications with a build-in federation gateway and a LocalDataSource will be affected. So, a better (or worse) workaround to this problem is split gateway and microservices into different node applications, and stop instrumentation on the gateway (which applies to our architecture).
I think the re-execute on gateway-js/src/executeQueryPlan.ts:81 may not need document.loc attribute, since the resolvers for all fields have already been called at this time, and this re-execute seems only for lexical reasons. So maybe allowing spans without document.loc is reasonable.
Here is a example from our application, and you can see this second execution happens after all real resolvers are called.

I'm getting this error with api v 1.0.1 and graphql intrumentation 0.23.0

Any update on this issue?
We're facing the same issue.

Possible solution:
https://github.com/apollographql/federation/pull/836/files#diff-78d9cdce9772008eebb17d78e4d4ea82cc446bb7ed0cf32b31963b766a7f496dR26-R51
Documentation states that federate should not have the instrumentation-graphql as pacakge

this should be fixed now -> https://github.com/open-telemetry/opentelemetry-js-contrib/pull/619
Updated also the example to use the federation too for easier verification of the fix.


Sockets build up during large project builds

It has been observed that running getop or the System Manager Fusion UI while gesystemmanager is mapping out very large builds can lead to an accumulation of sockets in the CLOSE_WAIT state.  For very large builds this socket buildup can result in fusion crashes due to resource exhaustion.
The half closed sockets are caused by System Manager holding a mutex for the duration of build planning which is also needed for reporting task status to both getop and the System Manager UI.  By default getop will close its side of a socket ~60 seconds after no response but System Manager waits until the mutex is available before realizing it should close its side.  Both getop and the Fusion UI will repeatedly query for task status until they are closed.
Workaround:
For very large builds close the System Manager Fusion UI and do not run getop.
Reproduction steps:

Set up and kick off a very large build (~6000 imagery resources should work)
Run getop --timeout 1
While system manager is planning the build repeatedly run sudo lsof | grep CLOSE | wc -l and observe the number of sockets in close wait state is increasing (sockets will be closed once system manager finishes build planning and releases the mutex)

Fixed by PR #1204.


Help needed around custom functions

Hello,
I've stumbled upon this repository and was wondering if you could clarify some of the code there?
At first it was complicated for me to understand how custom built-in functions work, but then I figured that the capabilities.json played a role to declare a function structure for the build -t wasm to recognize it. Also with the help of the field _registeredBuiltins we declare a callback function that's purely c#.
The question that is bugging me is how in general wasmtime work.  For example:
_linker.Define(OpaConstants.Module, OpaConstants.Builtin4, Function.FromCallback(_store, 				(Caller caller, int builtinId, int opaCtxReserved, int addr1, int addr2, int addr3, int addr4) => 				{ 					return CallBuiltin(builtinId, opaCtxReserved, addr1, addr2, addr3, addr4); 				}) 			);
here we define an item to the linker (still hard to grasp this), but

why do we use those constants opa_builtin0 - opa_builtin4?
CallBuiltin(int builtinId, int opaCtxReserved, int addr1, int addr2, int addr3, int addr4) - what are those arguments and how do you understand addresses?
does private string DumpJson(int addrResult) reads a c++ string starting from that addrResult in memory?
same for private int LoadJson(string json) - do I understand it correctly - we write another c++ string into memory, take that address and pass it to Policy_opa_json_parse which uses it to give us evaluation?

Great comment on this link https://webassembly.github.io/wabt/demo/wasm2wat/ it allowed me to see those

but I lack understanding from the documentation what are they needed for.
Hope this question might help others who are trying to figure things out.
Cheers

A good primer is reading https://github.com/open-policy-agent/opa/blob/main/docs/content/wasm.md - but there is no C++ anywhere (malloc could give the wrong impression though)
Now as for the builtins - all callbacks from Wasm redirect to one of the CallBuiltin C# overloads (that's what the Linker is used for). Say you have a builtin called "mybuiltinfunc": yes, you need to provide it for rego compilation via capabilities.json to the OPA executable. The resulting Web Assembly module is loaded by this library, and on execution will call into the library's callback based on parameters. Now, if you as caller didn't provide the "mybuiltinfunc" Func, it will throw - you will have needed to provided it beforehand via RegisterBuiltin - please see https://github.com/christophwille/dotnet-opa-wasm/blob/master/src/Opa.Wasm.UnitTests/BuiltinTests.cs for a couple samples.


add rat plugin to check licenses in examples

Changes proposed in this pull request:

add rat plugin to check licenses

Pull Request Test Coverage Report for Build 37

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 58.151%

Totals

Change from base Build 967:
0.006%

Covered Lines:
10534

Relevant Lines:
18115

💛  - Coveralls

Codecov Report

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

@@            Coverage Diff            @@
##             master    #4552   +/-   ##
=========================================
  Coverage     54.56%   54.56%
  Complexity      327      327
=========================================
  Files           971      971
  Lines         18115    18115
  Branches       3445     3445
=========================================
  Hits           9884     9884
  Misses         7595     7595
  Partials        636      636

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 9099e34...ee6987c. Read the comment docs.