Nested Fields

I would like to know if there is any plans to support nested fields like some other tools that now support this like elasticsearch/kibana.
I use Superset against a Spark SQL HiveServer2 compatible JDBC query engine that reads data from Hive tables that support nested data but in Superset I cannot selected the nested fields independently.
I spend a lot of time flattening fields for new projects.
Also, for users, referencing the fields with dot notation would be much more intuitive.
A lot of modern data arrives in json with nested struct fields and is stored on an object store like S3. Since there are more and more data lakes or lakehouses front-ended with query engines like Presto and Spark with this type of nested data, users/developers want a simple way of querying this data with minimal change. So it would be very strategic and beneficial to Superset to support such a capability.

@saultawil thanks for posting this enhancement request. sorry that we couldn't answer your questing in the meetup on Wednesday. I don't think we currently has the ability of running independent query on nested data, there might be work around that I don't know though.
Tableau offers something similar to your request - after user connect to a JSON file, it prompts users to select the schema levels. Is this what you are looking for?

@villebro @zhaoyongjie

Thanks for the response Junlin...I suppose Tableau may offer access to nested fields but the above example is more complex because it involves arrays which can be repeatable sets of nested data. I am looking for support for something much simpler - simple struct fields where one struct field is made of multiple nested fields that occur exactly once. An example that I have seen in a similar tool called Kibana (see below image attached) - I did not set up this data source but I do not think it required any special input from the user regarding levels. The tool simply recognizes the nested fields and treats them like separate fields that can be accessed with dot notation not matter the level:


[TRY] Use karma-parallel for running tests on CI

Context

Summary

Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:

Reviews
Does this PR have a security-related impact?

Does this PR change what data or activity we track or use?

Does this PR have a legal-related impact?

Checklist

[ ] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[ ] I have tested this code to the best of my abilities
[ ] I have verified accessibility to the best of my abilities (docs)
[ ] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[ ] This code is covered by automated tests (unit, integration, and/or e2e) to verify it works as intended (docs)
[ ] I have added documentation where necessary
[ ] I have added a matching Type: XYZ label to the PR

Fixes #

Unfortunately all but the first shard currently fail with some unexpected errors like this:
	TypeError: expectAsync(...).toHaveNoViolations is not a function

Also surprised to suddenly see these warnings:
Warning: react-modal: App element is not defined. Please use `Modal.setAppElement(el)` or set `appElement={el}`. This is needed so screen readers don't see main content when modal is opened. It is not recommended, but you can opt-out by setting `ariaHideApp={false}

I think the reason is that with the current logic here the beforeAll() packages/karma-fixture/src/init.js somehow is lost.
Maybe because it's a top-level beforeAll() without a describe(), and karma-parallel shards tests by describe

Along with improving the stability of the tests I was also thinking about total CI time improvements of this solution.
karma-parallel says something about "speed up the time it takes to run unit tests by taking advantage of multiple cores" - I didn't saw the code responsible for that part yet, but in the best case it will utilize 2 cores of the GHA runner.
An alternative approach would be to use GHA matrix and create something like this:

full example here
WDYT?

This is awesome! I was worried initially that doing it with karma-parallel would prevent us from running tests in different vms but this looks perfect. Really really nice how individual sets of tests can fail and we can get quicker actionable feedback.

Thanks for the reviews!
Yeah I think I‘m going to remove it again from the dashboard so that there‘s one less GHA job in the queue


fix fix bitmap_count errors to set nullable to non-nullable bitmap col

Proposed changes
Issue Number: close #17841
Problem summary
Describe your changes.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.01 seconds
stream load tsv:          433 seconds loaded<PHONE_NUMBER>9 Bytes, about 164 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          60 seconds loaded<PHONE_NUMBER> Bytes, about 17 MB/s
stream load parquet:          30 seconds loaded 861443392 Bytes, about 27 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230414142553_clickbench_pr_129271.html


Pacify clippy

cargo clippy had some complaints.  I think I pacified them.  There are other complaints, but my instincts tell me that "solving" those would break APIs.

I see in the commits for the PR that you originally had a new example included here: 53f594d  This example doesn't show up in the final diff, however?  If your intention was to also submit that example, maybe send a new PR with just that?

Ah, right, that example is already upstream as of #267 so ignore my previous comment.  I just got confused by seeing the commit here.

Rebased ontop of latest main.


[SPARK-7850][BUILD] Hive 0.12.0 profile in POM should be removed

I grep'ed hive-0.12.0 in the source code and removed all the profiles and doc references.

Can one of the admins verify this patch?

ok to test

I'm OK with that if this is true and the intent, but then do we need hive-0.13.1 anymore either?

Merged build triggered.

Merged build started.

Test build #33461 has started for   PR 6393 at commit d5342cd.

I think this is the intent - but I will let @marmbrus confirm.

The code is useless ?
https://github.com/apache/spark/tree/master/sql/hive

Test build #33461 has finished for   PR 6393 at commit d5342cd.

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

Merged build finished. Test PASSed.

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

We probably also need to get rid of the HiveShim code as well in hive/hive-thriftserver modules.

@chenghao-intel thank you for pointing it out. I deleted 0.12 shim code.

Merged build triggered.

Merged build started.

Test build #33491 has started for   PR 6393 at commit 54d8dee.

Test build #33491 has finished for   PR 6393 at commit 54d8dee.

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

Merged build finished. Test PASSed.

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

@srowen, we should get rid of -Phive-0.13.1 too.  The build should only ever need to support one version of hive from now on.  Another part of this task (would be nice to do now, but does not have to happen in this PR) is to inline the Hive13 shim, so we don't have this extra indirection anymore SPARK-6909.

Merged build triggered.

Merged build started.

@marmbrus thanks for the confirmation. I removed -Phive-0.13.1 now.
Regarding SPARK-6909, can we do it in a separate PR? I'm happy to do it if no one is planning to do it.

Test build #33556 has started for   PR 6393 at commit fb429ce.

Test build #33556 timed out     for PR 6393 at commit fb429ce     after a configured wait of 150m.

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

Merged build finished. Test FAILed.

Jenkins, retest this please.

@piaozhexiu looks good. I will merge once tests come back positive. It'd be great if you have some cycles to help out with SPARK-6909 to inline the Hive 13 stuff.

Merged build triggered.

Merged build started.

@rxin thank you! I'll look into SPARK-6909 this week.

Test build #33563 has started for   PR 6393 at commit fb429ce.

Test build #33563 has finished for   PR 6393 at commit fb429ce.

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

Merged build finished. Test PASSed.

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

Thanks. I've merged this in master & 1.4.


Feat/eslint config graphql

With Stylelint, we store multiple configs in a single package:
  extends: [
    '@lmc-eu/stylelint-config',
    '@lmc-eu/stylelint-config/optional',
  ],

Would this approach be relevant also for ESlint configs?

With Stylelint, we store multiple configs in a single package:
  extends: [
    '@lmc-eu/stylelint-config',
    '@lmc-eu/stylelint-config/optional',
  ],

Would this approach be relevant also for ESlint configs?

Yes, there will be optional ruleset on configs. But my approach is to have multiple configs divided into technology platform and extending the base config. Eg.:
extends: [
  '@lmc-eu/eslint-config-react,' // or   '@lmc-eu/eslint-config-node,' - based on target platform
  '@lmc-eu/eslint-config-react/optional,' // or   '@lmc-eu/eslint-config-node/v16,'
  '@lmc-eu/eslint-config-react/style,'
  '@lmc-eu/eslint-config-typescript',
  '@lmc-eu/eslint-config-typescript/react,'
]

It seems to me that is better to have multiple configs which you can extends and update separately (less dependency mess when updating) than have a big one.
I am also thinking about eslint-config-lmc which will integrate most common usecase like react + typescript + prettier (maybe you know https://github.com/wesbos/eslint-config-wesbos which behave the same) alltogether.
What is your opinion?


Exception in UpdateManager when Domain- and Scenereload is disabled

Hello,
we have Domainreload and Scenereload disabled in our project and got a problem with the Update-Manager. Problem is, the UpdateManager gets destroy on [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.SubsystemRegistration)] but the bool in ApplicationUtils.IsQuitting is still true so the RegisterInManager throws an Exception that the UpdaterManager is destroyed but i try to access it.
Problem is that our scripts try to register into the manager before the ApplicationUtils resets the IsQuitting bool to false from the last playmode session.
I fixed the problem by adding the RuntimeInitializeLoadType.SubsystemRegistration to the RuntimeInitializeOnLoadMethod in the ApplicationUtils class, so the bool is false when the next scripts Register during OnEnable.
Maybe it would be a good change for people who have Domain and SceneReload disabled.
Cheers,
Johannes

Hey @HanHangit, thanks for the report!
Oh my, sorry about that. I've never disabled Domain Reload nor Scene Reload, so I hadn't tested this scenario.

I fixed the problem by adding the RuntimeInitializeLoadType.SubsystemRegistration to the RuntimeInitializeOnLoadMethod in the ApplicationUtils class, so the bool is false when the next scripts Register during OnEnable.

Seems like a good solution, I see no concerns there.
If you want, create a PR with your fix, I'll be glad to merge it =]
Otherwise, I can fix here. Either way, next version should have this problem fixed!


Add support for Sunrise Calendar - Toggl button

This is my submission to the Toggl Button Challenge with Sunrise Calendar integration.

Just for information. The pull request will be evaluated and merged after the end of the toggl developer challenge (https://toggl.com/toggl-developer-challenge) on February 14th. Thank you for your contribution.

Merged with rebase. Thank you for your contribution.


Updated resultsdb tutorial

Summary
Updated tutorial with new syntax and screenshots. Also changed the name to experiment_cloud_service.ipynb since resultsdb is an internal name.
Closes #233.

Ready for review.

@chriseclectic Oops, done.


2.0.0 pod status check

Hey, please review and provide any feedback.  I still need to add onto the readme and improve on comments if the logic looks ok.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.3 out of 5 committers have signed the CLA.:white_check_mark: integrii:white_check_mark: joshulyne:white_check_mark: jonnydawg:x: rukatm:x: Michael KurashimaMichael Kurashima seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


[Automation] Generate Fluent Lite from dnc#package-2021-03-15

[Automation] Generate Fluent Lite from dnc#package-2021-03-15

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-delegatednetwork


Fix pylint warning on Matrix4.to_look_at() usage in vulk.graphic.camera

************* Module vulk.graphic.camera
E: 38, 8: Too many positional arguments for method call (too-many-function-args)

Thanks,
Matrix4 and Vector class need to be refactored by using numpy. I am currently working hard on the Vulkan part!


Platform shrinks to minimum size on MacOS

Problem:
On MacOS, Workcraft is minimized and located on the bottom left of the screen after starting.
There is a warning message in the Terminal.
...
Switching to GUI mode...
WARNING: GL pipe is running in software mode (Renderer ID=0x1020400)
Now in GUI mode.

This issue was imported from Launchpad bug.

date created: 2014-12-15T15:17:49Z
date closed: 2015-04-14T13:14:24Z
owner: libowen96
assignee: jonathan-r-beaumont
the launchpad url was https://bugs.launchpad.net/bugs/1402711

libowen96 at 2014-12-15T15:21:36Z:

danilovesky at 2015-02-17T13:04:04Z:
Jonny,if you can reproduce, could we debug this on your Macbook please?

jonathan-r-beaumont at 2015-02-18T12:49:46Z:
I cannot reproduce this bug on my MacBook air.
After starting, it produces the Workcraft window as expected in the top left corner, without any errors in the terminal.


Does MQBench supports Advanced PTQ on the transformer model?

The transformer model seems not to support layer-wisely finetuning on the calibration dataset. Will this feature be supported？

How about this https://github.com/ModelTC/MQBench/tree/main/application/nlp_example

I'm sorry I didn't make it clear. Can the transformer model be finetuned using the AdaRound-like algorithm?


chore: update README for installation instructions

This PR proposes updating the readme file for installation instructions

Sure, the PR has been updated to add R package versions :+1:


apache.org should use tag-based navigation

With more than 200 pages and a suboptimal organization, it's often hard to find pages on the apache.org website.
I think adding tag-based navigation, like we have on the Sling website (see https://sling.apache.org/tags/community.html for example) would help a lot, and gradually tagging pages would help find duplicates and redundancies.
I know little about Pelican, I tried adding tags with the below patch but that didn't work, I suspect that the custom GFM Markdown parser that's used doesn't support lists of tags in page metadata (front matter).
Maybe someone who's better at Python than myself can find out more details and improve that parser if my assumption is correct?
See the below example for what doesn't work.
Patch that adds tags and doesn't work.
We'd need more than that of course, but it looks like Pelican takes care of tag-based navigation out of the box. Adding tags in a similar way to the pelican-quickstart example site articles does provide tag-based navigation with the default theme.
With the below patch, the tags are output as

TESTING TAGS

p

m

c

,

p

o

l

i

c

y

with each character considered a separate element in the list, instead of the expected
pmc

policy

Here's the patch that I tried:
diff --git a/content/dev/pmc.md b/content/dev/pmc.md
index 1f6eb4a4c..909681f87 100644
--- a/content/dev/pmc.md
+++ b/content/dev/pmc.md
@@ -1,7 +1,8 @@
 Title: Project Management Committee Guide
 license: https://www.apache.org/licenses/LICENSE-2.0
+Tags: pmc, policy

-# Project Management Committee Guide
+# Project Management Committee Guide #3

 This guide outlines the general responsibilities
 of [Project Management Committee](/foundation/how-it-works.html#pmc) (PMC) members in managing their projects and common how-to procedures for
diff --git a/theme/apache/templates/base.html b/theme/apache/templates/base.html
index 87f3cf2bc..3e1a61f07 100644
--- a/theme/apache/templates/base.html
+++ b/theme/apache/templates/base.html
@@ -41,6 +41,12 @@

+
TESTING TAGS

+    {% for tag in page.tags %}
+
{{ tag }}

+    {% endfor %}
+
+

the tags in the example are treated as a string, not a list. so when you iterate, you get one character at a time.
You may want to do something like:
  {% if page.tags %}
    {% for tag in page.tags.split(",") %}

{{ tag.strip() }}

    {% endfor %}
  {% endif %}

Makes sense, thank you, and I think this splitting can later by done in the gfm.py plugin so that Pelican gets a proper list of tags.
Howewer, enabling the Pelican TAGS_SAVE_AS option for tag-based navigation doesn't currently work in the infrastructure-pelican module, I've created a separate issue for that, https://github.com/apache/www-site/issues/196

Just to let you know, while I am very intrigued by the idea of this kind of navigation, I want to put a pin in it for now. The M&P team is currently working on addressing the navigation issues (and other content-related issues), and we would like to get those done before implementing a change like this.

Ok, noted. I might start adding tag-based navigation to https://community.apache.org/ which is built on Hugo which I know better, if I do that I'll mention it here for review.

A recent discussion on members@ makes me think that it would be useful to add a policy tag to pages that contain ASF policy information, as opposed to just being informative. That content must be handled with special care and changes might require Board approval in some cases.
Even if such a tag is not used right now in the website publication, I think having it in the content can help.
I think a good number of the pages linked from https://www.apache.org/dev/ fall into this "policy" category, as well as a lot of what's under https://www.apache.org/legal/ and https://www.apache.org/foundation/marks/

@bdelacretaz Please hold off on this, I have not decided if we are using tagged-based navigation yet.

Hi @bdelacretaz, I completely agree that the site needs better discoverability. Having pored over sitemap data to update the navigation, here's my perspective. The TL;DR is that implementing better categorization (rather than tags) would improve discoverability in addition to improving new contributor onboarding (which tags would do a poor job of).
The Sling website uses categorization well and is more akin to docs. When looking at Sling’s analytics, one doesn't see visitors using tags to find content; rather they appear to navigate directly to the pages they are looking for because the site implements categorization well.
The downside of tags is that they are unstructured and unlimited, which means that if we don’t define a set of tags at the beginning - we could quickly see “tag sprawl” that begins to make tags meaningless. (You see this a lot on blog tags - it can start to have the opposite effect of what was intended - by adding too many tags for every page.)
The other downside is that tags aren’t helpful for people new to ASF. How do they know where to start? Tags are non-linear nor progressive. For example, there are currently 20 obvious pages in the sitemap that could be tagged with “trademark" (and probably many more). If a newbie saw a list of 20+ pages, they’re less likely to know where to start. On the other hand, categorization creates a more linear path with pages visible in the recommended order. They provide a more structured approach that provides flexibility as ASF continues to grow and adapt.
To resolve the issue of dense content, my suggestion is to create a more docs-like site for the ASF. This requires a centralized effort to understand the content, categorize it, and develop an appropriate IA. It’s categorization that the ASF site sorely lacks today that we could only partially solve with the new website top-level navigation.
I'd love to hear your thoughts.

Okay, with no further discussion, closing.

Sorry that I didn't reply earlier. I understand your reasons for not adding tags at this point, but I also think the website redesign has made some pages harder to find from the navigation. It seems to be targeted to non-ASF audiences which is great, but we also have a lot of internal information, under /dev and /legal for example, that our PMC members must be able to find, for reference.
However, given the size of the website, creating a navigation that works for all cases is probably hopeless, so the focus (IIUC) on external audiences makes sense.
Covering those parts which are not easily reachable by navigation is where I think tags might help, if I'm looking for PMC reporting guidelines for examples, looking for pmc + report tags would feel natural, and tags are also a great to way find similar pages on multiple axes. But I agree that defining a meaningful taxonomy is a challenge.
One major thing that changed since I opened this ticket is that the website search works very well now, so for this example, searching for "pmc report" does bring me to the right page fairly easily.
So I guess we need to emphasize that and make sure the search continues to work well, and if people still have problems finding things I'd come back with the tags suggestion.

my suggestion is to create a more docs-like site for the ASF...

Do you mean moving the current internal-facing content to a different website? I think that would be great, as long as redirects from existing "important" URLs are added.


chore(main): release 2.5.0

:robot: I have created a release beep boop
2.5.0 (2024-07-21)
Features

pressing tab in yazi jumps to dir of next open split (#232) (3cbc40c)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v2.5.0
:sunflower:


Review "KI Kompakt"

Spotify: https://open.spotify.com/show/6vsXhZW5oSL0U6hL1g1ZTu

I listened to a couple of episodes of this podcast.
Most of the topics have been high-level. I could not find a dedicated or deep tech focus, but often about the business, ethics and society.
Hence, we don't add KI Kompakt to the list of german tech podcasts yet.


Use of dict leads to rendering errors

Passing a dict into a named helm include or template fails.
Failure example:
{{- define "exploder" }}
{{ include "takes_a_map" dict "A" "eh" "B" "bee" }}
{{- end }}

{{- define "takes_a_map" }}
A: {{ .A }}
B: {{ .B }}
{{- end }}

Produces the following render error:
wrong number of args for include: want 2 got 6

However, passing a dict via pipe works just fine.
Successful example:
{{- define "works_fine" }}
{{ dict "A" "eh" "B" "bee" | include "takes_a_map" }}
{{- end }}

{{- define "takes_a_map" }}
A: {{ .A }}
B: {{ .B }}
{{- end }}

Failing test case
If you paste this test into pkg/engine.go:
func TestRenderInternalsDicts(t *testing.T) {
	// Test the internals of the rendering tool.
	e := New()

	vals := chartutil.Values{"Name": "one", "Value": "two"}
	tpls := map[string]renderable{
		"hello": {tpl: `hello .A={{.A}} .B={{.B}}`, vals: chartutil.Values{"A": "1", "B": "2"}},
		"four":  {tpl: `{{include "hello" dict "A" "1" "B" "2"}}`, vals: chartutil.Values{}},
		"five":  {tpl: `{{dict "A" "1" "B" "2" | include "hello"}}`, vals: chartutil.Values{}},
	}

	if _, err := e.render(tpls); err != nil {
		t.Fatalf("Failed template rendering: %s", err)
	}
}

Running the test yields the following output:
~/go/src/k8s.io/helm/pkg/engine$ go test -run TestRenderInternals -v ./... ; echo $?
=== RUN   TestRenderInternalsDicts
--- FAIL: TestRenderInternalsDicts (0.00s)
	engine_test.go:162: Failed template rendering: render error in "four": template: four:1:2: executing "four" at <include>: wrong number of args for include: want 2 got 6
FAIL
exit status 1
FAIL	k8s.io/helm/pkg/engine	0.009s
1

This is actually how text/template works, though I understand it can be confusing at first. A template pipeline takes every argument as an argument to the function. In your case, dict was passed as an argument to include instead of the output of dict being the argument supplied, which is how the pipe works. If you want the output of dict to be the input of include, you'll want to wrap the arguments in parentheses. Think back to Order of Operations in high school :)
{{- define "exploder" }}
{{ include "takes_a_map" (dict "A" "eh" "B" "bee") }}
{{- end }}

pkg text/template is finicky at times with parsing function arguments. Wrapping arguments in parentheses helps in situations like this. :)
As far as to why the second example works as intended, it's because dict is in its own pipeline, so its arguments will be parsed in the proper order.
So, in terms of Order of Operations for text/template, it's

parentheses (())
the pipe (|)
the template ({{}})

Afterwards, everything is an argument to the function.
Does that help make sense?

Ah!  I thought I had tried wrapping it in parenthesis yesterday, however I just tested now and it works!
Thank you for your help @bacongobbler!!!  And for helm, it's super cool and useful imho.


Add replay rating to the replay search

There is no way to search for replays which have a rating except by looking at the most highly rated games. This is not really a search though, simply a list of replays.
I hope that if this were implemented the replay rating feature would be used more, it is not used very often at the moment.

This is a bit more of an api issue, because at the moment there is no way to search by number of stars which is the expected behavior


clean up unused test classes and fixtures

There are a lot of unused fixtures and functions in test_channel_validator.py which makes it difficult to navigate and work with.

Testing PR #56 solved this issue. Closing now.


Send correct Content-Type header

urlopen defaults to application/x-www-form-urlencoded.

Content-Type is now set to "application/jose+json" for ACME v2.


could JS template grammar extensions be styled as "dark block"

I find the JS template grammar extensions feature awesome, thanks for this :)
I think it would be interesting to emphasis a bit more the fact it's another language in your JS
and here is my proposal:

Do you know if it's possible to do this?
I think it have a great value because it's very confusing for my eye to see the highlighting of different collocated languages like that:

The problem it it seems there is still the "host language class" in the editor, so i'm not sure if it's easy to do.

Thanks

I've just pushed a mod to the master branch that adds a class to the inner content of a tagged template string. The inside should now be marked meta.ttl-grammar.js, which should allow you to customise your Atoms styles.less to colour the background how you choose.
Until I publish this you can apm uninstall language-babel and apm install gandm/language-babel to get the mod.

cool :)
atom-text-editor::shadow .line .ttl-grammar {
  background-color: rgba(0,0,0,0.2);
}
atom-text-editor::shadow .line .ttl-grammar:first-child:last-child {
  display: block; // if ttl-grammar is alone in the line, we display block to force the background to take full width
}

produces

I have this hack to use display:block ONLY if the line only contains this ttl-grammar (otherwise it would create create misalignement).
if it isn't "alone" in the line, it won't display as block:

I wish I could also find a way to do padding around this block, but it is probably too much to ask without Atom to provide ways to do this^^

my approach don't support empty line though:

Probably impossible without resorting to coding and using decoration markers and marker layers. https://atom.io/docs/api/v1.11.2/Decoration
https://atom.io/docs/api/v1.11.2/DisplayMarkerLayer

I think I'll close this as coding seems a bit heavy handed to achieve this.

arf... now ::shadow is no more supported.
Any way to achieve this ? i agree gre, background highlighting is really convenient to read files containing more than one language (JS + GLSL)


Add theming system

It should be easy to add new tile themes in a non-destructive manner, removing the need for adding the "user_*.bmp" files by hand. There are two parts to this:

Add an ability to choose which tile override to use for a character/item/etc out of multiple. This is because there are already a lot of different variations of each one, from numerous different theme packs from vanilla. You should also be able to select any arbitrary tile as the replacement, and not just the recommended ones.
Allow saving "sets" of changed tiles somehow.
Expose the sets of changed tiles through mods, so you could have a "beautify" mod you can toggle on and off at will.

Of course, this should all be possible to do without the need to modify anything on the filesystem. It should be as easy as a config change.

Completed in e4645ba7e6ffec076c987ec44bc051c2c72beebe.


Impossible to declare custom iterable objects

When I try to define an iterable object, flow complains twice :
When I try to delcare my object as iterable:
*[Symbol.iterator] () {
         ^ computed property keys not supported

And when I try to spread over this object
[...myObject]
    ^^^^^^^^ MyClass. This type is incompatible with spread operand

Yes, I have the same issue and found no solution ATM.

Closing in favour of https://github.com/facebook/flow/issues/1163


Compose Web: Missing support for SVG elements

I'd like to use Web Compose to generate something like https://www.w3schools.com/html/html5_svg.asp:
<!DOCTYPE html>
<html>
<body>

<svg width="100" height="100">
  <circle cx="50" cy="50" r="40" stroke="green" stroke-width="4" fill="yellow" />
</svg>

</body>
</html>

but it's not working.

I tried creating my own composables (forking code from Elements.kt), but am ending up with  tags in my final html that for some reason don't work right.
I found these two links promising, they seem like what I'm dealing with:
https://stackoverflow.com/questions/24961151/svg-wont-show-until-i-edit-the-element-in-chrome-developer-tools
https://stackoverflow.com/questions/3492322/javascript-createelementns-and-svg
but the answers seem to point to using createElementNs, which I tried doing, but that's not even rendering my tag at all (I'm getting a class cast exception). I think it's time to give up for the night :)

Here's my code, maybe someone with more experience will spot the flaw right away:
import androidx.compose.runtime.Composable
import kotlinx.browser.document
import org.jetbrains.compose.web.dom.AttrBuilderContext
import org.jetbrains.compose.web.dom.ContentBuilder
import org.jetbrains.compose.web.dom.ElementBuilder
import org.jetbrains.compose.web.dom.TagElement
import org.w3c.dom.Element
import org.w3c.dom.svg.SVGElement
import org.w3c.dom.svg.SVGRectElement

private class SVGElementBuilderImplementation<TElement : SVGElement>(private val tagName: String) : ElementBuilder<TElement> {
    private val el: Element by lazy { document.createElement(tagName) }
//    Also tried:
//    private val el: Element by lazy { document.createElementNS("http://www.w3.org/2000/svg", tagName) }

    @Suppress("UNCHECKED_CAST")
    override fun create(): TElement = el.cloneNode() as TElement
}

private val Rect: ElementBuilder<SVGRectElement> = SVGElementBuilderImplementation("rect")
private val Svg: ElementBuilder<SVGElement> = SVGElementBuilderImplementation("svg")

@Composable
fun Rect(
    attrs: AttrBuilderContext<SVGRectElement>? = null,
    content: ContentBuilder<SVGRectElement>? = null
) {
    TagElement(
        elementBuilder = Rect,
        applyAttrs = attrs,
        content = content
    )
}

@Composable
fun Svg(
    attrs: AttrBuilderContext<SVGElement>? = null,
    content: ContentBuilder<SVGElement>? = null
) {
    TagElement(
        elementBuilder = Svg,
        applyAttrs = attrs,
        content = content
    )
}

Ah, probably traces to TagElement itself:
@Composable
fun <TElement : Element> TagElement(...) {
    ...
    ComposeDomNode<ElementScope<TElement>, DomElementWrapper, DomApplier>(
        factory = {
            DomElementWrapper(elementBuilder.create() as HTMLElement)...

 is not an HTMLElement, so this is throwing a cast exception

@Schahen Could you please link your PR with SVG support here once its merged?

SVG elements are supported in beta.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Number Check & Profile Photo Get Added

Rationale
There is no endpoint in the API to check the number before sending & to get the profile photo which is not have any sense but added😅 . I hope it is relevant to you!
Endpoint
Profile URL Get
http://<IP_ADDRESS>:8000/check/photo/{sessionID}/{phoneNumber}

{
	success: true|false, // bool
	message: "" | "Account Image not set", // string
	data: { img : "URL"} | {} // string
}

WA Number Check
http://<IP_ADDRESS>:8000/check/number/{sessionID}/{phoneNumber}

{
	success: true|false, // bool
	message: "Number found" | "The whatsapp number is not exists.", // string
	data: {} // string
}

Changes:
controllers/checkController.js -> Add new Controller.
routes/checkRoute.js -> Add new GET method for check number & to get photo.
whatsapp.js -> I have no idea. In fact, it is my first node project, and I tried to code according to the general structure😅.
Notes
Please help me improve this PR.

That's absolutely okay, i'll review it later when i'm free.

That's absolutely okay, i'll review it later when i'm free.

any help bro?

seems very good

I'm sorry but since i've started a complete rewrite of this repo, this PR is definitely gonna conflict with that. I will close this PR, but don't worry, i'll add this feature in the rewritten version.

Ok no problem 🤗


[ML][Pipelines] Copy early available property for pipeline component output

Description
This PR targets to support the following scenario: consume component with early available output and return it as pipeline component output. Now the pipeline component output will also hold the early available property.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

Close this PR for not considering pipeline component scenario for streaming for now.


Can not install it in El-Capitan!!

aclocal: warning: couldn't open directory ' /usr/local/share/aclocal': No such file or directory
aclocal: error: aclocal: file '/usr/local/share/aclocal/lt~obsolete.m4' does not exist

Have you built ag from source on earlier versions of OS X? It looks like you don't have dependencies installed.

I had the same problem and solved it.
I find the files under /usr/local/share/aclocal are dead links. I tried first:
brew install libtool intltool freetype
then brew install ag succeeds.
After that, even if I uninstalled libtool intltool freetype, ag can successfully install.

I'll look into this when 10.11 gets closer to release. Right now, tons of things are broken in it, including homebrew.

It's working a while ago, BTW.
You can just do this:
sudo chown $(whoami):admin /usr/local

you might also use the "-R" flag.

because before most of the file there used to owned by the: "wheel" group. or some by the root user as I remeber...
You can do the same with some other files or directories in the home dir. like rubies...
That's all, I  think.


Update index.html to serve demo content over https

Fixes:
Mixed Content: The page at 'https://leaflet.github.io/Leaflet.heat/demo/' was loaded over HTTPS, but requested an insecure script 'http://leaflet.github.io/Leaflet.markercluster/example/realworld.10000.js'. This request has been blocked; the content must be served over HTTPS.

I initially thought the demo wasn't working. The link in the readme points to HTTP instead of HTTPS but something in my browser (Edge) caused it to redirect to HTTPS and error out.
Related: https://github.com/Leaflet/Leaflet.heat/pull/9

Oh sorry I see this is a dupe of #133


feat(wip): add oversea server enums

This PR tries to add support for Genshin Impact global servers, namely: NA, EU, Asia, and SAR servers:

[x] Append server enums to SERVER_LIST

[ ] Change API root based on server. For global servers, the URL should be:
- https://api-takumi-record.mihoyo.com/game_record/app/genshin/api/dailyNote
+ https://bbs-api-os.hoyolab.com/game_record/app/genshin/api/dailyNote

[ ] Change the salt used in creating DS. For global servers:
- salt=xV8v4Qu54lUKrEYFZkJhB8cuOh9Asafs
+ salt=okr4obncj8bw5a65hbnn5oo6ixjc3l9w

I've added the enums but have not yet addressed the latter two modifications. Let me know if you are willing to add these changes (and in what manner) ;)

👍 The v3 standard for chrome extensions has many changes and is currently maintained separately in the refactor/v3, also I'm currently trying to get the uid and server automatically by cookies (and multiple account support), which may refactor quite heavily in code?


Building @mui/base breaks due to deprecated csstype.Property.ColorAdjust

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
When running ttsc -b I am seeing the following errors:
node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:146:54 - error TS2694: Namespace '"/Users/william.pengc3.ai/Projects/c3vsce/c3vsce/extension/node_modules/csstype/index".Property' has no exported member 'ColorAdjust'.

146             colorAdjust?: import("csstype").Property.ColorAdjust | undefined;
                                                         ~~~~~~~~~~~

node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:651:65 - error TS2694: Namespace '"/Users/william.pengc3.ai/Projects/c3vsce/c3vsce/extension/node_modules/csstype/index".Property' has no exported member 'ColorAdjust'.

651             WebkitPrintColorAdjust?: import("csstype").Property.ColorAdjust | undefined;
                                                                    ~~~~~~~~~~~

Found 2 errors.

Looking into csstype I see that they released a new version today from MDN data, which does not have the color-adjust property anymore.
MDN docs also suggest that color-adjust is gone, as the page redirects instead to print-color-adjust.
The solution is probably to update import("csstype").Property.ColorAdjust to import("csstype").Property.PrintColorAdjust, but in any case, this is breaking our builds.
Expected behavior 🤔
No errors should be outputted
Steps to reproduce 🕹
Steps:

Include @mui/base in dependencies
Run ttsc -b

Context 🔦
We are trying to build our project with ttsc -b which has an indirect dependency on @mui/base
Your environment 🌎

`npx @mui/envinfo`
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Facing this issue on Vite Build too when running npm run build that executes tsc && vite build.
Interestingly I cannot reproduce the same when using yarn as yarn build works just fine.

Facing same issue on VITE BUILD here...

same here

Facing this issue on Vite Build too when running npm run build that executes tsc && vite build.
Interestingly I cannot reproduce the same when using yarn as yarn build works just fine.

UPDATE: yarn build works on my local windows system but when deploying it gives the above mentioned error

Any workarounds known?

Any workarounds known?

not sure. i can say that the previous version also has it 5.4.3

found a workaround and added
"resolutions": {
    "csstype": "3.0.10"
  }

to the package.json, now it builds again

found a workaround and added
"resolutions": {
    "csstype": "3.0.10"
  }

to the package.json, now it builds again

Confirmed, good looking out.

found a workaround and added
"resolutions": {
    "csstype": "3.0.10"
  }

to the package.json, now it builds again

I tried this with the csstype package as a dev dependency and the preinstall script in my package.json "npx npm-force-resolutions" to no avail. Anything obvious I might be missing?

Same here.
@mui/base/SliderUnstyled/useSlider.d.ts:146:54
error TS2694:
Namespace 'project_dir/node_modules/csstype/index".Property' has no exported member 'ColorAdjust'.

146: colorAdjust?: import("csstype").Property.ColorAdjust | undefined;

Environment:
OS: macOS
Package manager<EMAIL_ADDRESS>Runtime<EMAIL_ADDRESS>Package versions:
"@mui/lab": "^5.0.0-alpha.70",
"@mui/material": "^5.4.3",
"@mui/styled-engine-sc": "^5.4.2",
"@mui/styles": "^5.4.2",

Same thing here, with different dockerized versisn of node:
node:14.15-alpine3.10
node:17.5-alpine3.14 +<EMAIL_ADDRESS>Packages:
    "@mui/icons-material": "^5.0.0",
    "@mui/lab": "^5.0.0-alpha.47",
    "@mui/material": "^5.0.0",
    "@mui/styles": "^5.0.0",

Using vite, I'm getting the following Typescript errors:
[TypeScript] Namespace '"/app/node_modules/csstype/index".Property' has no exported member 'ColorAdjust'.

[/app/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:146:54]()

    144 |             clipPath?: import("csstype").Property.ClipPath | undefined;
    145 |             color?: import("csstype").Property.Color | undefined;
  > 146 |             colorAdjust?: import("csstype").Property.ColorAdjust | undefined;
        |                                                      ^^^^^^^^^^^
    147 |             colorScheme?: import("csstype").Property.ColorScheme | undefined;
    148 |             columnCount?: import("csstype").Property.ColumnCount | undefined;
    149 |             columnFill?: import("csstype").Property.ColumnFill | undefined;

[TypeScript] Namespace '"/app/node_modules/csstype/index".Property' has no exported member 'ColorAdjust'.

[/app/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:651:65]()

    649 |             WebkitPerspective?: import("csstype").Property.Perspective<string | number> | undefined;
    650 |             WebkitPerspectiveOrigin?: import("csstype").Property.PerspectiveOrigin<string | number> | undefined;
  > 651 |             WebkitPrintColorAdjust?: import("csstype").Property.ColorAdjust | undefined;
        |                                                                 ^^^^^^^^^^^
    652 |             WebkitRubyPosition?: import("csstype").Property.RubyPosition | undefined;
    653 |             WebkitScrollSnapType?: import("csstype").Property.ScrollSnapType | undefined;
    654 |             WebkitShapeMargin?: import("csstype").Property.ShapeMargin<string | number> | undefined;

Adding @Anubiso workaround didn't solve the issue, at least not in development.

Those using npm instead of yarn may want to try this instead:
"overrides": {
"csstype": "3.0.10"
}
Unfortunately for me, this breaks other dependencies.

found a workaround and added
"resolutions": {
    "csstype": "3.0.10"
  }

to the package.json, now it builds again

This works for me with @mui/base, but I'm still seeing this issue with @mui/x-data-grid. Anyone else experiencing that?

ata-grid. Anyone else experiencing that?

ugh i need that repo for the other repo i need to migrate

Same issue here with Vite. I tried the resolutions above, but that made things worse and added 7 more has no exported member errors.

I think I'm seeing those as well
node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:72:60 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'AnimationTimeline'.

72             animationTimeline?: import("csstype").Property.AnimationTimeline | undefined;
                                                              ~~~~~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:147:54 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'PrintColorAdjust'.

147             colorAdjust?: import("csstype").Property.PrintColorAdjust | undefined;
                                                         ~~~~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:205:61 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'HyphenateCharacter'.

205             hyphenateCharacter?: import("csstype").Property.HyphenateCharacter | undefined;
                                                                ~~~~~~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:212:56 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'InputSecurity'.

212             inputSecurity?: import("csstype").Property.InputSecurity | undefined;
                                                           ~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:317:59 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'PrintColorAdjust'.

317             printColorAdjust?: import("csstype").Property.PrintColorAdjust | undefined;
                                                              ~~~~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:625:67 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'HyphenateCharacter'.

625             WebkitHyphenateCharacter?: import("csstype").Property.HyphenateCharacter | undefined;
                                                                      ~~~~~~~~~~~~~~~~~~

node_modules/@mui/material/node_modules/@mui/base/SliderUnstyled/useSlider.d.ts:657:65 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'PrintColorAdjust'.

657             WebkitPrintColorAdjust?: import("csstype").Property.PrintColorAdjust | undefined;

I just used skipLibCheck in the TS compiler settings (tsconfig.json) for now. BTW we're waiting for a real patch.

After updating my packages to the latest versions, the problem was resolved.

found a workaround and added
"resolutions": {
    "csstype": "3.0.10"
  }

to the package.json, now it builds again

added
"resolutions": {
    "csstype": "3.0.11"
 }

to the package.json and remove yarn.lock
and yarn install, the problem was resolved.

Yup, after upgrading @mui/material and @mui/icons-material to ^5.5.0 the issues were resolved. Closing this issue as the upgraded versions have resolved this.

I'm still having this issue with @mui/x-data-grid, although skipping lib check is a stopgap solution. Shall I open a separate issue?
node_modules/@mui/x-data-grid/hooks/features/virtualization/useGridVirtualScroller.d.ts:117:54 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'ColorAdjust'.

117             colorAdjust?: import("csstype").Property.ColorAdjust | undefined;
                                                         ~~~~~~~~~~~

node_modules/@mui/x-data-grid/hooks/features/virtualization/useGridVirtualScroller.d.ts:625:65 - error TS2694: Namespace<EMAIL_ADDRESS>has no exported member 'ColorAdjust'.

625             WebkitPrintColorAdjust?: import("csstype").Property.ColorAdjust | undefined;

My MUI versions:
"@emotion/react": "^11.7.1",
"@emotion/styled": "^11.6.0",
"@material-ui/core": "^4.11.3",
"@material-ui/icons": "^4.11.2",
"@mui/icons-material": "^5.5.0",
"@mui/lab": "^5.0.0-alpha.68",
"@mui/material": "^5.5.0",
"@mui/x-data-grid": "^5.6.0",
"@mui/x-data-grid-generator": "^5.5.1",
"@mui/x-data-grid-pro": "^5.6.0",

Resolutions:
"resolutions": {
    "csstype": "^3.0.11"
}

@victor-grajski Seems like @mui/x-data-grid hasn't updated their libraries, probably should open an issue with them here: https://github.com/mui/mui-x

It looks like @mui/base v5.0.0-alpha.80 isn't including csstype as a dependency, which is breaking the build.


Debt in report and documentation

As mentioned in #776 detekt should include the debt sum in the report as well as the debt values for each rule in the documentation.

If we want to sum up the debt for each rule set, the logic should be added to FindingsReport.
If we want just the whole sum of all rule sets, a new ConsoleReport with priority after FindingsReport should be chosen.
I would say, lets go for both options :) ?
Ruleset: complexity - 1d8h20m debt
- finding 1
- finding 2
- etc
RuleSet 2 ...
- etc

Overall debt: 5d20h40m


Magics in cl-jupyter

Frederic,
Do you know about magics in iPython?   Would it be difficult to add them to the cl-jupyter kernel?
It looks like it would give us access to a lot of widget functionality without porting widgets like we have been.
Check out:
github.com/clasp-developers/cl-jupyter-widgets.git
github.com/clasp-developers/cl-nglview.git
github.com/clasp-developers/cl-bqplot.git
These are some of the widgets that we have been translating from Python to Common Lisp.

I am aware of the magics and I think a similar feature should be a great addition to cl-jupyter. I will soon start to think about this (after integrating all your contributions to the master branch ...).


Feature(Nuxt): Pass components.json options to the module

Describe the feature
Hello 👋
I'd like to suggest reading the components options in the nuxt module from shadcn.components. Making all shadcn-vue options in one place.
export default defineNuxtConfig({
  modules: ['@nuxtjs/tailwindcss', 'shadcn-nuxt'],
  shadcn: {
    /**
     * Prefix for all the imported component
     */
    prefix: '',
    /**
     * Directory that the component lives in.
     * @default "./components/ui"
     */
    componentDir: './components/ui',

    // same values as `components.json`
    components: {
    //
    }
  }
})

Additional information

[x] I intend to submit a PR for this feature.
[ ] I have already implemented and/or tested this feature.

I would also like a components.json path option like
configPath: './configs/components.json'

or similar :)


Does it support python3.8 or python 3.9?

Thanks！I use Python3.9.
ModuleNotFoundError: No module named 'hok.lib.interface'

Python3.8/3.9 are not supported now.


Add multiple swagger json file

How can we add more than one swagger JSON file into ReDoc?

ou can add them using javascript like this:
<!DOCTYPE html>
<html>
<head>
<title>ReDoc APIs</title>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<link href="https://fonts.googleapis.com/css?family=Montserrat:300,400,700|Roboto:300,400,700" rel="stylesheet">

  <style>
    body {
      margin: 0;
      padding-top: 40px;
    }
  </style>
</head>
<body>

<!-- Top navigation placeholder -->
<nav>
  <ul id="links_container">
  </ul>
</nav>

<redoc scroll-y-offset="body > nav"></redoc>

<script src="https://cdn.jsdelivr.net/npm/redoc/bundles/redoc.standalone.js"></script>
<script>
    // list of APIs
    var apis = [
        {
            name: 'First API',
            url: 'http://domain/swagger.json'
        },
        {
            name: 'Second API',
            url: 'http://domain/swagger2.json'
        }
    ];

    // initially render first API
    Redoc.init(apis[0].url);

    function onClick() {
        var url = this.getAttribute('data-link');
        Redoc.init(url);
    }

    // dynamically building navigation items
    var $list = document.getElementById('links_container');
    apis.forEach(function(api) {
        var $listitem = document.createElement('li');
        $listitem.setAttribute('data-link', api.url);
        $listitem.innerText = api.name;
        $listitem.addEventListener('click', onClick);
        $list.appendChild($listitem);
    });
</script>
</body>
</html>

It would be better if it could merge the two TBH :O

@Dalabad's solution is one of the possible ones.
Another solution is to merge your specs yourself (using some scripts) before passing it to ReDoc.
Anyway, multiple specs support is out of scope for ReDoc.

When using multiple APIs with ReDoc in the fashion that @Dalabad suggested above, is there any way to also use the theme option to style each API tab? Now that I've got the theme initializing properly (thanks @RomanGotsiy for your help in the other thread!), I'd like to take it to the next step and apply it to this scenario; but, each tab pulls its own spec url, so replacing that somehow with the Redoc.init script is beyond my ability here. Is it even possible, within the context above? Thanks!

@RomanGotsiy is there an example that shows how to do a script https://stackoverflow.com/questions/54663148/how-do-you-use-redoc-with-multiple-files

Have you tried: https://github.com/Rebilly/ReDoc/issues/442#issuecomment-376917569?

That does not work with the CLI as is.
What I ended up doing was
  "scripts": {
    "build": "mkdirp web_deploy && speccy resolve swagger.yaml > web_deploy/swagger.yaml && redoc-cli bundle -o web_deploy/index.html --cdn web_deploy/swagger.yaml",
    "test": "speccy lint swagger.yaml",
    "start": "redoc-cli serve -w swagger.yaml"
  },

redoc-cli serve works with the refs I just used speccy to lint and resolve to a single one for release.


feat: add drop_null_keys argument to group_by

closes #1256

What type of PR is this? (check all applicable)

[ ] 💾 Refactor
[ ] ✨ Feature
[ ] 🐛 Bug Fix
[ ] 🔧 Optimization
[ ] 📝 Documentation
[ ] ✅ Test
[ ] 🐳 Other

Related issues

Related issue #
Closes #

Checklist

[ ] Code follows style guide (ruff)
[ ] Tests added
[ ] Documented the changes

If you have comments or can explain your changes, please do so below.

thanks for your review! 🙏


remote() can now accept JSON or a simple boolean as the response

I modified the success callback of the remote method to test whether the response is a boolean value or whether it's something different (JSON). This will allow developers to pack other things (if necessary) into the response of their server-side script and access that data in an overridden success callback provided by jQuery.validate's constructor options. It greatly expands the scope of what the remote method can do.
The JSON response must be valid, but can contain any data as long as the key "valid" is filled out, as shown:
{ "valid": true }

This generic key "valid" is the replacement for the simple boolean value that was the entire contents of the response.
By the way, both this plugin and require.js are SUPER useful on a daily basis. Thank you so much for making them!!

Both of these are too restrictive.  Why not just add customizable callbacks to the success/failure test, and while we're at it, add a callback to retrieve the error message.
https://gist.github.com/1535894
I'll submit a pull request when I'm done.

@krishardy what's successTest? why not just keep the same syntax as jQuery.ajax so the object can be injected directly into an Ajax call?

successTest provides the interface for the valid/invalid test.  Currently, jquery-validation tests to see whether a response was returned by the remote ajax call, and if the response is empty it is considered as "valid".  If the response contains data, then it is "invalid", and the full response is set as the invalid message.
My implementation is a perfectly fine way to prepare the ajax call, so I'm not sure what you mean by the keeping the same syntax as jQuery.ajax.
The whole point to this is to allow a developer to define the two following functions if their app validation code to change the default behavior:

successTest(response): Returns boolean.  True if the response indicates that the value is valid.  Returns false if the response indicates that the value is invalid.  (Thinking about it, maybe isValid or validTest is a more descriptive function name.)

getInvalidMessage(response): Returns string.  The error message, parsed from a response.  The default implementation just returns the entire response.  By overriding this message in your validation code, you can do any sort of parsing/processing needed.

For example, I use a single restful JSON server api for both web apps, console apps, and integration middleware.  I need my responses to be complex at times, but I don't want to special-case my validation responses, so here is what I am doing:
My server returns a JSON structure similar to the following when the any data submission or validation finds invalid data.  The actual request below is against the log-in form:
{"success": false, "reason": "validation failed", "validation": {"valid": false, "messages": {"username": "The username must be 6 or more characters", "password": "You must supply a password"}}}

Here's the test I used in my client-side form validator:
$("#myform").validate({
  rules: {
    email: {
      required: true,
      email: true,
      remote: {
        url: "check-email",
        type: "post",
        dataType: "json",
        successTest: function(response) {
            return response['validation']['valid'];
        },
        getInvalidMessage: function(response) {
            return response['validation']['messages']['email'];
        }
      }
    }
  }
});

Thanks for the kudos.  I'll be sending the pull request soon.  I would like to extend the test suite, but I need to find the location of the User.php and User2.php files that the test suite references.


Eslint moving to 1-based columns

ESLint 1.0 will switch to 1-based columns, so syntastic needs to get rid of the workaround, or add a check for ESLint's version and only use the workaround on v0.x.

Thank you for letting me know.  Please see bfc5579.
While you are at this: "semi": [2, "never"] produces column numbers off by 1.  There might be other similar problems, this is just from a quick look.

Thanks for pointing this out, it's been fixed in ESLint for the semi rule!


Set angle programmatically.

Add setter for angle.
Update lib version in readme.

Your lib is awesome, but I missed funcionality of setting angle programmatically.
The use case I needed for: GIF
Angle changing relatively to scroll position.

thanks !


feature request: ":has()" and ">"

Hello.
It would nice to be able to use "has:()" with ">".
So query like "div:has(> a)" will select all "div" elements that have at lease one direct child "a" element.
Or, for example, add selector like ":hasChild(..)".
Thanks.

Thanks, merged in #1214


WIP: EDK2, OVMF.fd: fixes for cross-compilation + dependencies + armv7l

THIS NEEDS FIXES CURRENTLY IN STAGING TO BUILD. It is why this is based on staging.
This also needs a good review by the peeps that know more about cross-compilation. Some of the fixes, especially the python-touching fixes, may not be optimal.
Motivation for this change
Well, get the OVMF EFI "floppy disks" (that's what .fd stands for?) for aarch64 and armv7l buildable with cross-compilation. Furthermore, get the armv7l build going too.
This is prep work for personal stuff, but hey, nixpkgs gets better here!
This was verified to work using qemu-system-* and the x86_64, aarch64 and armv7l NixOS iso. (The NixOS armv7l iso is another WIP thing, but it's really not good now.)
Things done

✔ Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
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 nox --run "nox-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)
✔ Assured whether relevant documentation is up to date
✔ Fits CONTRIBUTING.md.

In general, getting this stuff right because as far as I can tell from a cursory look at the docs, the "EDK" is trying to do it's own cross-compilation stuff---poorly.

In another branch, building-up from the cross-compilation branch, I'm working on making the EDK2 stuff more re-usable through making use of it to build a Raspberry Pi 3 UEFI implementation. I don't think I'm going as far as you're suggesting, but I think the end-result is better and easier to follow along. Though, this makes fixing things here annoying as some of the things are going to be removed :).
Thanks for the review, it really helps get those things together.

OK great! Happy to help with that one too.

I've taken some of your Python-related changes and fixed cross-compilation of Python packages in https://github.com/NixOS/nixpkgs/pull/53123. At least, it mostly seems to work. numpy not yet.

@samueldr are you still working on this? If so, please rebase.

I intend to work on this, haven't for a while, will rebase at that moment.
If others are interested in working on this be my guest!

I converted it to a draft.

I'm not coming back to this exact PR ever again, so I'm closing it.


docs: initial UTXO design documentation

#45  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @L8D and the rest of your teammates on  Graphite

Merge activity

Nov 10, 6:46 PM EST: A user merged this pull request with Graphite.


[Flow] Add options for targeted tracing/breaking on dispatches

Opening a PR to see if this or something similar would be wanted in core IREE. Essentially this enables cropping the input program at a specified dispatch. We have been using this in SHARK-Runtime as a debugging tool.
For example, for certain backends and/or large models, --iree-flow-trace-dispatch-tensors is far too slow and produces too much output to easily iterate with so being able to quickly "binary search" can enable much faster isolation of correctness issues. This also has proven useful for isolating "soft" crashes/unwanted behavior like codegen blowing up (happens sometimes in SPIR-V).
The current implementation here is a bit hacky (and assumes single output everywhere) so feedback on a "correct" way to implement this is welcome.

I love this idea!! I'm a big fan of this style of approach when bisecting (back in the days before asan https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtsetbreakalloc?view=msvc-170 saved me many times) and often do this workflow by hand. Usually I'll use iree-compile --convert-to=flow to get the IR at the flow level and then bisect by dropping the uses of certain tensors and returning what I want like you do here. Then I can pass my modified form back in to iree-compile and it'll complete compilation (running dce/symbol dce to clean up the unused stuff). Having a flag that effectively does the same thing would be much easier than that and way easier to communicate to people trying to debug stuff :)
There's a few different workflows that are useful with something like this - it'd be interesting to gather them so we can see if there's one approach that generalizes or if there will need to be a few variants of this pass. I'm thinking specifically around how to identify dispatches. I believe most people are anchoring on named dispatches - this is what codegen sees and at runtime/in performance tooling what will be displayed. It's also the output of iree-compile --convert-to=flow. I also think like you have here if you're a user coming from the frontend and trying to track things in your program it may be easier to do things by execution order on the inlined dispatches, the best way of getting that being iree-compile --print-ir-before=iree-flow-outline-dispatch-regions. There's probably others too we could think of, like passing in a source location and having it break on the first dispatch containing that location as you could find your lines of python, etc.
To start at least then there's two specification methods we could use: function + dispatch ordinal in region op order and dispatch symbol (@executable::@dispatch). Dispatch ordinal is what you have here if it were fixed to walk the function instead of go through its dispatches (that way nested control flow regions like scf are supported). The symbol is useful for anyone doing codegen or runtime performance work as it's what all the rest of the tooling uses. Neither is super stable, though, and if you change your input program or anything that may impact dispatch region formation (linalg, etc) you'll have to re-find your dispatch. That's easier to do with symbols as generally their name stays the same and it's just their ordinal that changes.
I think there's also two modes: one like you have here which breaks execution and returns the values that you can then dump those to a .npy file or whatnot and do lots of analysis, and another where it just traces out the dispatches but continues execution. I'll call these "break" or "trace" mode.
The break mode is really useful if trying to isolate crashes or wanting programmatic access to the resulting values but has the limitation that it is changing control flow (the return values of all ops in the tree).  Tricky but not super hard, and a fun way to play with IR walking :)
The trace mode is useful when when trying to find a particular dispatch producing bad results or to track the results of what the dispatch is doing even if the program is changing. It'd allow a user to say "show me the result of all dispatches to the name @simple_mul_dispatch_0_generic_16384" and other fun stuff. This also helps if there's any control flow in the program (while loop, if, etc) - we could add some more complex break modes like "break on this dispatch ordinal's 8th hit" but that gets super complex to correctly rewrite in the IR. Tracing everything would always just be inserting the flow.tensor.trace op and not having to break up IR.
I suspect having pass options for break/trace strings that get interpreted as either ordinals or symbol names would let you share the same pass implementation of the actual return value munging and tracing logic as well as how to walk the IR to find each dispatch category. You'd then run the pass both immediately before OutlineDispatchRegionsPass for the ordinal form and immediately after DeduplicateExecutablesPass for the dispatch name form.
So that'd give us two flags that cover a lot of the above:
--iree-flow-break-dispatch=@main:8: break and return on the dispatch at region op order 8 in function @main
--iree-flow-break-dispatch=simple_mul_dispatch_0_generic_16384: break and return on every dispatch of this symbol
--iree-flow-trace-dispatch=@main:8: trace the result of the dispatch at region op order 8 in function @main
--iree-flow-trace-dispatch=simple_mul_dispatch_0_generic_16384: trace the result of all dispatches of this symbol
and in the future we could add more for things like specifying source locations and stuff (loc:foo.py:23 or whatever).
I think this would stand to be the easiest way to debug both correctness and execution issues and make testing tweaks in-situ much easier, and it'd be awesome if you wanted to see it through. It'd also help with helping users do their own bisection without needing to edit IR :)

I love this idea!! I'm a big fan of this style of approach when bisecting (back in the days before asan https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtsetbreakalloc?view=msvc-170 saved me many times) and often do this workflow by hand.

Woah quite the response, thanks for the positive feedback :D
I found myself doing the same enough times where I decided it was worth hacking together this pass. SHARK-Runtime is easy because we can try out super informal/unstable solutions to stuff like this but that only works when I'm the only one using it. Now that it has shown up in an issue #12193 I figured it would be worth sharing.

There's a few different workflows that are useful with something like this - it'd be interesting to gather them so we can see if there's one approach that generalizes or if there will need to be a few variants of this pass.

For sure, coming from SHARK we probably see a good chunk of that spectrum. Perhap worth compiling in an issue?

I suspect having pass options for break/trace strings that get interpreted as either ordinals or symbol names would let you share the same pass implementation of the actual return value munging and tracing logic as well as how to walk the IR to find each dispatch category. You'd then run the pass both immediately before OutlineDispatchRegionsPass for the ordinal form and immediately after DeduplicateExecutablesPass for the dispatch name form.

Makes sense, the quick and dirty way of just counting the dispatches works for most models, but there's no consideration for control flow. This sounds like a nice way to hit most of the immediate use cases I can think of with one implementation.

So that'd give us two flags that cover a lot of the above: --iree-flow-break-dispatch=@main:8: break and return on the dispatch at region op order 8 in function @main --iree-flow-break-dispatch=simple_mul_dispatch_0_generic_16384: break and return on every dispatch of this symbol --iree-flow-trace-dispatch=@main:8: trace the result of the dispatch at region op order 8 in function @main --iree-flow-trace-dispatch=simple_mul_dispatch_0_generic_16384: trace the result of all dispatches of this symbol and in the future we could add more for things like specifying source locations and stuff (loc:foo.py:23 or whatever).
I think this would stand to be the easiest way to debug both correctness and execution issues and make testing tweaks in-situ much easier, and it'd be awesome if you wanted to see it through. It'd also help with helping users do their own bisection without needing to edit IR :)

I'd love to make progress here, although it isn't top priority for me so if others are eager to get something like this up and running then by all means. I don't want to lay blanket claim to this. Otherwise I'll try and carve out some time to refactor this PR based on the symbol/ordinal + break/trace breakdown to act as a starting point.

This looks fantastic! Very sorry about the delay - if you'd like I can make the changes/rebase/land since it's been so long.

Thanks for the review :D I don't mind the changes/rebase but won't get to it until tomorrow so you're welcome to if you want this urgently for some reason.

ah will take a look - when ready for review you need to click the refresh button in order for the PR to show back up in the reviewer's todo list:

when ready for review you need to click the refresh button in order for the PR to show back up in the reviewer's todo list

Ah I see, didn't realize that updated the reviewer's queue. I appreciate the graphic :)

This is great!


Send mouse wheel commands only if they're supported

This seems to work for me. However should other mouse modes also be checked?
Fixes #48

Thanks for adding this!
I think this implementation is fine for now. We can always fix it later if there's fallout. Not blindly sending motion events is already a huge win.

Oh, I misread slightly. This should probably check mode::SGR_MOUSE as well

I've updated my commit. Some more testing with vim's ttymouse reveals that mode::MOUSE_REPORT_CLICK works with xterm, mode::MOUSE_MOTION with xterm2 and mode::SGR_MOUSE with sgr. So supporting them all should provide good compability.

Landed in 6cc6086


Not working at all

Describe the bug
The website isnt working
Console error
press F12 to open up javascript console. Provide errors shown there.
Desktop (please complete the following information):

OS: [e.g. macOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

use osu! instead.


test: add tests to travis

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Normalize AppURL according to RFC 3986

Fixes #21865.
Scheme-based normalization (RFC 3986, section 6.2.3) was already implemented, but only for defaultAppURL.
This PR implements the same for AppURL.

The log.Fatal will make process exit, so the else and indentation block can be avoided (just put code on the top level). Otherwise LGTM.

Thanks!


AAC: ADTS/ADIF duration in case of full parsing

AAC: ADTS/ADIF duration in case of full parsing and/or "risky bitrate estimation" option
and better support of non-48k frequencies

As i accidentally discovered this PR, i enjoyed tested it :wink:
It has worked on 4 files :-)
twist_shout_SBR_v4.aac.txt
RoxioMediaManager_test4_AAC-LC_v4_Stereo_CBR_64kbps_44100Hz.aac.txt
AAC_8khz_Mono_5.aac.txt
AAC_12khz_Mono_5.aac.txt
The problem is that the estimate duration is sligtly shorter than the real one, and the approximation should be superior to avoid playing issue with the renderers.
Because, as far as i tested, the renderers, over UPnP or DLNA, will play only until the duration sended if it is shorter than the media, or will stop when no audio is received, also if the duration is longer.
For a file of 30s, the duration is shorted of 1s, and for a file of 5'43 the estimate duration is shorter of 30s or 35s.
Though something weird seem to happen with the RoxioMediaManager_test4_AAC-LC_v4_Stereo_CBR_64kbps_44100Hz.aac file.
The estimate duration is more than 10 times superior !

the approximation should be superior to avoid playing issue with the renderers.

I disagree about what it should be in MediaInfo: I fully understand this criteria for your case, but MediaInfo has not this criteria.
And actually, as said explicitly, it is an estimation, you'll always have at least 1 file with a shorter duration than estimated, this is the risk of estimation.
MediaInfo policy is to display duration based on average bitrate of the first frames.
If you want "average bitrate of the first frames + 10%", this is you arbitrary choice and you do it after reading MediaInfo input (advantage: you change the delta you choose when you want :) ).

For a file of 30s, the duration is shorted of 1s, and for a file of 5'43 the estimate duration is shorter of 30s or 35s.

This is not the issue: bitrate computing is based on the first 5 seconds, whatever is the duration of the file. If this 5 seconds are not similar to the other parts of the file, you get wrong info, that's all, whatever is the duration (10 seconds or 10 hours).

The estimate duration is more than 10 times superior !

This is the reason this is said "risky" ;-).
This was wanted by a sponsor, I implement it (optional), with the risk due to estimation based on bitrate taken from only few seconds.
Do not use it if you don't accept this risk (in practice, sponsor's encoder uses "average bitrate" so it is fine for him, but in your case this is not usable)

Note that there are 2 cases handled in this PR: risky duration computed based on few first seconds bitrate, and full file parsing, I think the last one is more suitable for you but it is LONG parsing with long files (full parsing). Technically impossible to do differently, except some tweaking option (e.g. "OK,  seconds not good, maybe I check 10 seconds instead, of 1 minute, by option" (not yet done).

LC_v4_Stereo_CBR_64kbps_44100Hz.aac file.
The estimate duration is more than 10 times superior !

At the start you get lot of silence (17 bytes per frame), then "normal" 180 bytes per frame.
bitrate is based on the 17-byte frames --> bam.
BTW, that means this is not CBR despite the file name ;-)
Need of more frames parsed for a better estimation (10 seconds, maybe)
Note that a feature for displaying bitrate by time slice is planned, but not ETA.

MediaInfo policy is to display duration based on average bitrate of the first frames.
If you want "average bitrate of the first frames + 10%", this is you arbitrary choice and you do it after reading MediaInfo input (advantage: you change the delta you choose when you want :) ).

Cool, i didn't thought about that :+1:
I did understood the risky estimation, but do not evaluate how risky it could be LOL

Need of more frames parsed for a better estimation (10 seconds, maybe)

That's seem a good idea to me.

Note that a feature for displaying bitrate by time slice is planned, but not ETA.

I'll not throw you the stone, as i'm worst than you for "no ETA" :wink:
I still need to try with the full parsing option.
I guess that it have something to do with adts_buffer_fullness, but i'm not sure to understand why some ADTS files can be parsed that way and some not ?
id3v2_id3v1.aac.txt
nocturne.aac.txt
test6_AAC-LC_v2_Stereo_VBR_128kbps_44100Hz.aac.txt

I guess that it have something to do with adts_buffer_fullness, but i'm not sure to understand why some ADTS files can be parsed that way and some not ?

It depends of the encoder: some do CBR for sure, encoding with lot of bytes the silence (they store the "noise" more precisely, this is the case for the sponsor of this feature, designed for broadcast with a constant satellite bandwidth) and some other keep the same quality during encoding (so silence is 17 byte long, this is the case with your files, designed for storage so constant quality is optimal).
This is normal, expected, AAC is by design VBR. Note that this is same with MP3, this is not new, difference is that lot of encoders put stats in the ID3v2 tag or LAME puts stats in the first frame with "hidden" bytes (and LAME was a lot used). Ask to your encoder providers to put ID3v2 tags ;-).

Need of more frames parsed for a better estimation (10 seconds, maybe)

That's seem a good idea to me.

https://github.com/MediaArea/MediaInfoLib/issues please

Ah OK, so that could be a good point for us.
As most of my test files seem to have used Nero, SUPER, MediaConvert...as encoders, the users commercial AAC files have a greater probability to have ID3v2 tag included.
But nocturne.aac seem to be CBR, and the bitrate is not estimate, so i've missed something.
EDIT: Aaah, i just used a russian tiny tool, and saw that it's not CBR file.
But MediaInfo don't say that it is VBR so i thought that it was a CBR file, by default deduction.

But nocturne.aac seem to be CBR, and the bitrate is not estimate, so i've missed something.

adts_buffer_fullness is 0x7FF (highest value) so expected to be VBR, but it is definitely CBR (frames are between 371 and 372 byte long).
Currently I put "VBR" when adts_buffer_fullness is 0x7FF, I have doubts now...

But MediaInfo don't say that it is VBR

Hum, weird, is "VBR" with " --ParseSpeed=1", but nothing by default. A bug.
Looks like there is some review to do about coherency!
Closed PR is not a good place for speaking about different issues, please open an issue ticket per issue (e.g. "missing bitrate mode info"...), so I can better track issues and answer.

i thought that it was a CBR file, by default deduction.

When nothing is display on this line, that means that MediaInfo does not know, no other deduction is possible.

the users commercial AAC files have a greater probability to have ID3v2 tag included.

id3v2_id3v1.aac has no bitrate / duration info, it does not count. Useful only if duration info is include.

Thank you for all these explanations :+1:
OK, i'll. But my purpose was to test and report only, not to discover bugs ;-)
I tried with ParseSpeed=1 and the bitrate look great, but i'm still struggling trying to understand which legacy fields Legacy=false disable ?


Documentation:  How and when to use the Test Addin

Please select a category the issue is focused on?
I have a new documentation idea! Yay!
Let us know where something needs a refresh or put your idea here!
once the testthat addin is finalized we need to provide a little bit of documentation on how to use it and what to watch out for.

Addressed in another PR #78


borders colors

I can't seem to find the color number for borders. Telegram default themes has borders in some parts whereas the 16 color palette I use doesn't have any colors for the borders. Is it not possible to change border colors? because without borders tiles look connected and it's doesn't look good.

Hum, which borders do you mean? Borders between conversations? Could you take a screenshot so it's a bit clearer?

Here is a screenshot from telegram's built-in night theme. There are very thin edges and borders in different places like the one separating chat title and pinned messages and a number of others.
Also As you can see the color of the wrapper (the outer border of the window) is different from the inner part. Can that also be changed using one of the colors? right now even in the screenshots in the README file the main color fills most of the sections and there is not much variety like the built-in themes and in makes the app look kinda ugly in my opinion

Well we are quite limited with 16 colors, I believe the original theme uses more than 16 colors... Furthermore depending on which wal you are using only 8 colors are generated and simply duplicated across the 16 colors so even less variety.
But I'll look into it, see if at least with the 16colors wal I can't get some better results. But I can't tell you how long that'll take I'm quite busy recently, you're very welcome to play with the themes yourself and tell me what you find.

Thanks for the issue, fixed in v0.6.0


Some questions about Vimeo-90K-T for 4×

Hello, thank your for your source code. I have a question on TABLE 3 in your paper.  The Vimeo-90K-T dataset is divied into 3 parts  according to the motion velocity, slow, medium and fast.  I have downloaded the file 'vimeo_super_resolution_test', in sep_testlist.txt, I want to konw a specific clip is corresponding to which groups (slow, medium and fast). Do you have a file which records the classification of each clip.

https://github.com/alterzero/RBPN-PyTorch/tree/master/vimeo90k
The group files can be downloaded from this link .

谢谢，我去年就在arxiv上看到这篇文章，我觉得这篇文章配得上cvpr的水平。我一直以为这是投了cvpr2020的文章，为什么投了IEEE ACCESS呢😌------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2020年1月6日(星期一) 晚上9:31
收件人<EMAIL_ADDRESS>抄送: "ZhangDY"1725375269<EMAIL_ADDRESS>主题: Re: [wh1h/DNLN] Some questions about Vimeo-90K-T for 4× (#1)
https://github.com/alterzero/RBPN-PyTorch/tree/master/vimeo90k
The group files can be downloaded from this link .
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


automated generation of random txplans for effecthash testing

#4613

This is ready for review: we now have the test utility generating all possible actions in a TransactionPlan, and to prevent regressions we test the EffectHash computation based on those tx plans in a new test

Merging this and adding #4947 in a followup


reduce docker image size

Dockerfile was not efficient.
This makes it smaller.
Tested to see the result is the same.
With original dockerfile, it would take about 600 seconds on M2.
With the new dockerfile, it takes about 70 seconds.

Thanks -- It conflicts with your other PR - could you resolve the conflict?

I'm supportive - do you want to send a PR ?

@LTS42 @sb2nov thoughts on using Alpine instead of Debian and Ubuntu? it's only 5 MB
https://hub.docker.com/_/alpine

alpine will end up taking more time because of how bare bone it is (I tried).
by using debian:stable-slim, we are effectively offloading essential build time to download time which in most cases will be faster.
if you are able to come up with a branch, I can test it on my machine how long it takes (or you can, with this branch and your new branch).
for now, I'm resolving and merging (with approval)

Merged this and we can try to move to alpine in a followup if we make it work but this is already way better


handling null

https://github.com/SoftwareBrothers/admin-bro/blob/b39ce5beb64ee69d5745c71ef7d5f783e6df3bec/src/frontend/components/actions/record-to-form-data.ts#L23
incase of NULL values from table will break this and stop submitting the form.
But i would like to keep them as null.

I've seen the #370 fix go in, but it changes all NULLs to be blank string.
I'm planning to have admin-bro working with an existing MSSQL DB via sequelize, and at the moment it will be changing pre-existing records replacing NULLs with ''. I can't afford to allow data changing unexpectedly. Is there a plan to have it handle NULLs or will it continue as its currently implemented?

hmm - atm I don't have a fix in admin-bro core for that. We are sending all the data from the frontend to the backend as a FormData. So it requires to have all the values as strings or File objects.
To fix your particular problem I would strip the request in before hook of edit action. Like this:
before: (request) => {
  if (request.method === 'post') {
    const { canBeNullProperty1, canBeNullProperty2, ...rest } = request.payload

    return {
      canBeNullProperty1: canBeNullProperty1 === '' ? null : canBeNullProperty1,
      ...rest
    }
  }
  return request
}

This is an example - probably in your case you can build more elegant code but you get the point.


Local variable highlighting

Also I've figured out that a in let mut a = ... is not highlighted properly (with light blue background) when I place the curet on some reference of a like in the next snippet
let mut a = 1;
let b = <caret>a;

The highlighting works for function arguments though.

Related #109 comment

it seems that the reference is correctly (?) resolved to the RustPatBinding node in any case, but somehow the highlighting is not applied to it if mut is included

another test case
type EventLoop = mio::EventLoop<Server>;

type T = EventLoop;

but that's not a local variable, right?!

Yep, changed the title ;)

#126 has a similar issue for mut vars btw. usages for let <caret>a = 1 and let <caret>mut a = 1 work but let mut <caret>a = 1 fails


Makefile need c99 support for inline for

Make fails as for loop declarations
dnsperf.c: In function ‘find_working_tcp_connection’:
dnsperf.c:608: error: ‘for’ loop initial declarations are only allowed in C99 mode
dnsperf.c:608: note: use option -std=c99 or -std=gnu99 to compile your code
make: *** [dnsperf.o] Error 1

line:
 for (int i = 0; i < tinfo->nsocks; i++, (*socknum)++) {

Out of interest what compiler/OS are you using?

I was using gcc in centos6 and centos7


Singledb does not drop schema objects

Describe the bug
The drop schema SQL is not produced while running the snowddl-singledb.
Expected behavior
It seems to be a bug, but I am not sure is this a feature.
Attach log
# snowddl -c sample02_01 --apply-unsafe --apply-masking-policy --apply-row-access-policy apply
# snowddl-singledb -c sample02_01 --config-db=TEST_DB --target-db=ANOTHER_DB --apply-unsafe --apply-masking-policy --apply-row-access-policy apply
# rm -rf snowddl/_config/sample02_01/test_db/test_schema
# snowddl-singledb -c sample02_01 --config-db=TEST_DB --target-db=ANOTHER_DB --apply-unsafe --apply-masking-policy --apply-row-access-policy plan
2024-10-31 16:23:26.944 - INFO - Snowflake version = 8.41.1 (ENTERPRISE), SnowDDL version = 0.34.3
2024-10-31 16:23:26.944 - INFO - Account =
2024-10-31 16:23:26.944 - INFO - Session =<PHONE_NUMBER>68150, User = SNOWDDL_TEST
2024-10-31 16:23:26.944 - INFO - Role = SNOWDDL_XL__SNOWDDL_ADMIN_TEST, Warehouse = SNOWDDL_WH
2024-10-31 16:23:26.945 - INFO - Roles in session = ACCOUNTADMIN,SYSADMIN,SECURITYADMIN
2024-10-31 16:23:26.945 - INFO - ---
2024-10-31 16:23:34.922 - INFO - Executed 0 DDL queries, Suggested 0 DDL queries

Should be fixed in 0.34.4
Commit: https://github.com/littleK0i/SnowDDL/commit/19e341f97c84aeca70140c8b723bcd15d49ac300
Thank you!

If the another_db is not exist, there would be an error for database not created while run singledb directly. Is this an issue?
snowddl-singledb -c sample02_01 --config-db=TEST_DB --target-db=ANOTHER_DB --apply-unsafe --apply-masking-policy --apply-row-access-policy apply

......

2024-11-06 09:42:55.615 - WARNING - Resolved SCHEMA [SNOWDDL_XL__ANOTHER_DB.TEST_SCHEMA]: ERROR
(
    message   =>  SQL compilation error:
Database 'SNOWDDL_XL__ANOTHER_DB' does not exist or not authorized.
    errno     =>  2003
    sqlstate  =>  02000
    sfqid     =>  01b831c6-0103-a1ab-0000-880d0e73332a
    sql       =>  CREATE SCHEMA "SNOWDDL_XL__ANOTHER_DB"."TEST_SCHEMA"
WITH MANAGED ACCESS
)

Should be alright, since SingleDB assumes DB already exists and was created by something or someone else. SingleDB starts with schemas.

Hello! I wanted to point out something that we ran in to. Not sure if this is a bug or is working as expected.
For context, we're using SnowDDL in single database mode as the DCM tool for multiple data sets. These data sets don't all exist in the same Git repository, but each data set contains separate schemas.
Example:
Repository 1:
config/
└── DATABASE/
    └── PRODUCT1_SCHEMA/
        └── table/
            └── PRODUCT1_TABLE_V1.yaml

Repository 2:
config/
└── DATABASE/
    └── PRODUCT2_SCHEMA/
        └── table/
            └── PRODUCT2_TABLE_V1.yaml

Before this change was implemented, only objects in Snowflake within the schema would be dropped rather than other schemas.
Repository 1 Plan (before change):
Context: PRODUCT1_TABLE_V1 was renamed to PRODUCT1_TABLE_V2.

Command snowddl-singledb -c ./config --config-db DATABASE plan

2024-11-07 11:05:16.594 - INFO - Resolved TABLE [DATABASE.PRODUCT1_SCHEMA.PRODUCT1_TABLE_V1]: DROP
2024-11-07 11:05:16.594 - INFO - Resolved TABLE [DATABASE.PRODUCT1_SCHEMA.PRODUCT1_TABLE_V2]: CREATE

With this change implemented, schemas that don't exist within the config for a repository will now be dropped when the params.yaml file for the database doesn't have is_sandbox enabled.
Repository 1 Plan (after change):
Context: PRODUCT1_TABLE_V1 was renamed to PRODUCT1_TABLE_V2.

Command snowddl-singledb -c ./config --config-db DATABASE plan

2024-11-07 11:05:15.171 - INFO - Resolved SCHEMA [DATABASE.PRODUCT2_SCHEMA]: DROP
2024-11-07 11:05:16.594 - INFO - Resolved TABLE [DATABASE.PRODUCT1_SCHEMA.PRODUCT1_TABLE_V1]: DROP
2024-11-07 11:05:16.594 - INFO - Resolved TABLE [DATABASE.PRODUCT1_SCHEMA.PRODUCT1_TABLE_V2]: CREATE

I thought the fix would be to add a params.yaml file with is_sandbox: true to the database, but that actually enables the schema to be in sandbox mode too.
Repository 1 (with params.yaml file):
config/
└── DATABASE/
    ├── PRODUCT1_SCHEMA/
    │   └── table/
    │       └── PRODUCT1_TABLE_V1.yaml
    └── params.yaml

Repository 1 params.yaml file:
is_sandbox: true

Repository 1 Plan (after change w/params.yaml file):
Context: PRODUCT1_TABLE_V1 was renamed to PRODUCT1_TABLE_V2.

Command snowddl-singledb -c ./config --config-db DATABASE plan

2024-11-07 11:05:15.171 - INFO - Resolved SCHEMA [DATABASE.PRODUCT2_SCHEMA]: DROP
2024-11-07 11:05:16.594 - INFO - Resolved TABLE [DATABASE.PRODUCT1_SCHEMA.PRODUCT1_TABLE_V2]: CREATE

I would expect that if is_sandbox is enabled at the database level it wouldn't be enabled at the schema level. We could solve this on our side by consolidating all of our data sets into one repository but that wouldn't be my preferred solution.
Apologies if this issue isn't clear, please let me know if there's any confusion and I'll create a reproducible example. Thanks again for all of your work!

@TedCha , in theory, we may now allow is_sandbox: false on schema level to override is_sandbox: true on database level, if specified explicitly.
The original implementation comes from very organized environment when all schemas are well-known in advanced and defined in the same config. But now we have permission models which potentially allow external scripts to create new schemas, so potentially this adjustment might be useful.
Naturally, I would also suggest to consolidate all schemas into one config, especially if objects in one schema may reference objects in another schema. And if these schemas have no references and should be managed separately, maybe they belong to different databases.

@littleK0i
Thanks for the quick response!

Naturally, I would also suggest to consolidate all schemas into one config, especially if objects in one schema may reference objects in another schema. And if these schemas have no references and should be managed separately, maybe they belong to different databases.

For the most part our schemas are separate from one another (if they're not, they under the same config in a repository). The reason why we use schemas to separate entities is because we only have permissions to act within one specified database. We might be using SnowDDL inappropriately, if that is the case, my apologies for the bother!
Otherwise, allowing is_sandbox: false at the schema level to override is_sandbox: true at the database level would work perfectly for us. From a broader perspective, I think it would be useful for other users as well because objects at the database level can be "external" to SnowDDL while objects at the schema level can be "internal" to SnowDDL if they explicitly define it that way. I'm not sure how widely used the feature would be but it offers a good amount of flexibility while still enabling default behavior.
I'd be happy to put in a PR if you agree. I think it would just be switching the logic here to check the schema params before checking the database params.

@TedCha , that's correct place. Please go ahead with PR, thank you!

@TedCha , should work in 0.35.0.

@littleK0i Just tested, works perfectly. Thank you very much!


FileExistsErrors when running the test suites.

I cannot run the test suite on my laptop for some reason:
To reproduce:
pip install -r requirements.txt
pytest

Error message:
self = <tests.conftest.MockGCSFileSystem object at 0x7ff978207f70>, path = '/vcm-fv3config/data/initial_conditions/gfs_c12_example/v1.0', create_parents = True, kwargs = {}

    def mkdir(self, path, create_parents=True, **kwargs):
        path = self._strip_protocol(path)
        if path in self.store or path in self.pseudo_dirs:
>           raise FileExistsError
E           FileExistsError

../../../miniconda3/envs/fv3net/lib/python3.8/site-packages/fsspec/implementations/memory.py:99: FileExistsError

Maybe some fsspec caches are  hitting us here? Do we need gcsfs specific tests? If there is no special handling of gcsfs in this package maybe we could just remove the mock.

Ok. It is a version specific issue. It only happens if the constraints file is not used. Here is the version it fails on:
$ pip freeze | grep fsspec                                                                                (fv3config2)
fsspec==2022.3.0

Sounds like the behavior of mkdir went from allow-existing to not. Also, it's using the in-memory cache, right? Hard to tell from what you posted, but it’s a MockGCS filesystem and the error is from implementations/memory.py. The test says “mock gcs” but I think really it’s just an fsspec compatibility test.
Ideally this can be fixed by passing some allow-existing flag or using a mkdirs function or something that allows existing directories.
If it's version-specific maybe we can ignore it, but this could reflect a change in the behavior of fsspec moving forward (meaning the test is giving us useful info here).

We do use fv3config frequently in practice with the newer fsspec versions.

Probably worth fixing the code for the failure then, unless we find this is actually a bug in fsspec (then we could fix it there).


Use serial communication for PWM control demo

We're having trouble using USB comms when connecting all the motors.

Just as a follow up, I was able to get the USB comms working but it required me to plug the Power Supply into a different power outlet and plug the Teensy USB into a different USB outlet on my PC....

Do we still require the ability to communicate over UART? With USB back up and running I don't have a need for it currently.

Closing for now


in IE8 cant use default as key

i found it cant use dafault as key in object when i set the type,like this:
'core': {
'animation': 0,
'check_callback': true,
'data': tdata,
'themes': {
'responsive': false,
'stripes': false
}
},
'contextmenu': {
'items': customMenu
},
'types': {
'default': {
'max_depth': 5,
'max_children': 5,
'icon': 'tree_empty'
}
},
'plugins': [
'contextmenu',
'search' ,
'types',
'wholerow'
]
if types set default when this code run in IE8,browser will say SCRIPT1028: 缺少标识符、字符串或数字,but i didnt find a way to make this key compatible,

This is an IE8 limitation and an unfortunate name choice on my end.
I believe it can be worked around using obj['default']. You could also make sure you do not use the default type.
Changing this now is not possible as it will require a major version bump, and v.4 will probably not support IE8 anyway.


Update rhel/centos/amazon URLs now that Bintray has been sunset

According to https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/, Bintray has been sunset. This PR updates the baseurl and gpgkey URLs for rhel/centos/amazon.

@tecracer-theinen Please review this, merge, and release a new cookbook to Supermarket?

@pschaumburg could you check why the linter is stuck or remove it for now? We should get this one out asap.
Guess v2.0.1 would be fitting here

Sadly still basing on circle-ci. Will update this one as well with GH workflows.

@jmaziarz Thank you for this PR.
I have merged it and created a new version for the Chef Supermarket.


Add support for different RTU protocol versions

MAX series, v3.0.5, v3.15.4

support is prototypically added and works for MIC 600TL-X inverters now.


Add Seagis  Campus domain

Request to add Seagis Campus domain

@SasankaArjuna Pull request merged. Thank you!