Handle serving gzipped resources

Courtesy #18 , we will have a gzipped bundle which won't get resolved on the client side. Make appropriate response header changes to accommodate this functionality.
Feedback would be wonderful if you think things are working fine already.

Did we resolve this @ayushgarg1804 ?

Not yet, will do it soon

@ayushgarg1804 , @mananpal1997 will be working on repro of this issue and come up with a strategy on how to proceed

Haha, I told you before just wasn't sure about it.

@mbad0la I was trying to tell same thing the other day, couldn't figure out properly though. 😄


Implement applySpec

Closes #1591

By the way, I must say that this line is confusing:
https://github.com/ramda/ramda/blob/master/src/apply.js#L24
If it's intentionally trying to support mapping this to the global object, I guess that's fine*, but it better be documented (in the code), because it's easy to overlook that.

That's not it.  Most of our functions that manipulate functions use a similar technique to make it easier to use the generated functions in an OO context.  It's pretty difficult right now to come up with a good example of why someone would want to do that with apply, but the point is that if the function supplied uses 'this' and the function generated ends up being used as an Object method, then because of this technique, we properly keep track of the this being used when calling the function.
This has always been more of a nice-to-have feature than something driving our API.  But if it doesn't get in our way, it helps smooth the way for this library to interact with other JS code the user may have to work with.

@CrossEye I see, I think it's broken though: http://bit.ly/1ZpEC37

Sure enough.  I imagine some change to curry2 has caused this.
When I have some time, I'll try to dig into it and see if I can see why.

Yep, it doesn't call .apply:
https://github.com/ramda/ramda/blob/master/src/internal/_curry2.js#L25

The same issue applies to _curry3.

Feedback would be nice ;)

Feedback would be nice ;)

Thanks for the poke.  Behind, as ususal.
:herb:  I really like this.  I see it as quite useful, and not easily achievable with anything else we have.
I'm not sure I like the implicit recursion.  It might be better to make it explicit:
R.applySpec({ unnested: R.always(0), nested: R.applySpec({ sum: R.add }) })(1, 2);
//=> {unnested: 0, nested: {sum: 3}}

But I'm not certain about this, mostly thinking aloud.

The library is not consistent elsewhere:
R.evolve({ a: { b: R.inc } }, { a: { b: 1 } }) // => {"a": {"b": 2}}
R.where({ a: { b: R.gt(R.__, 0 ) } }, { a: { b: 0 } }) // throws "spec[prop] is not a function"

Practically speaking, it's been quite a few times where({ currentBehavior: { where: disappointedMe } }) (and somewhat surprised me, given how evolve works); On the other hand, I do find the recursive behavior of evolve very powerful.
As for our own implementation of applySpec: initially it wasn't recursive, but it quickly became clear that the recursive use case is very sound. Not exactly our use case, but consider a function that constructs a nicely nested object out of a flat DB-row result, something like this:
  const getUserInfo = pipeP(
    ...,
    applySpec({
      credentials: {
        userName: prop("user_name"),
        passowrd: pipe(prop("passowrd_enc"), ...)
      },
      lastActive: pipe(prop("last_active"), toDate),
      stats: {
         accessCount: pipe(...),
         ....
      },
      ...
    })
  );

If the "sub-specs" for credentials, stats and other properties aren't reusable (i.e. those objects don't stand by themselves), a non-recursive implementation would just add some unnecessary noise, somewhat hiding the author's intentions.

It was that inconsistency I knew we already had that was bothering me, although I hadn't yet tried to figure out exactly where each style was used.
I believe you're right.  The recursive one is much more powerful for a spec, so long as we're only passing functions.  where evolved from a different direction, and we couldn't have done this before #1036.  But I would be in favor of making where recursive as well.
:herb:
Any objections, anyone?


Gridster is not initialize with typescript?

I made simple working demo using Angularjs + typescript..I am trying to load gridster but gridster is not working...

Maybe try https://github.com/ManifestWebDesign/angular-gridster


[bug] [macOS]: Creates duplicate entries when write with a key is used

With the current version (8.0.0), and the initialisation is done as follows:
FlutterSecureStorage(
        iOptions: IOSOptions.defaultOptions.copyWith(
            accountName: '${env.appType} App Secure Storage',
            accessibility: KeychainAccessibility.unlocked_this_device,
            synchronizable: false),
        mOptions: MacOsOptions.defaultOptions.copyWith(
            accountName: '${env.appType} App Secure Storage',
            accessibility: KeychainAccessibility.unlocked_this_device,
            synchronizable: false));

The storage creates duplicate keychain entries. This results in the wrong value being read when accessing the values and thus creates issues with access/refresh tokens for OIDC.
Currently we use refresh tokens to fetch new access tokens for users. After the first write (which creates a keychain entry in the iCloud keychain), the correct value is read. When the refresh happens, the same method (write) is used. This creates a second entry in the "login" keychain on macOS which duplicates the value in the keychain. The read query then finds the iCloud one first and only ever returns this value. One does not get access to the correct access.

This results in weird behaviour during login sessions.
I tried to search for the code that is creating this issue but I do not get the concept of the macOS keychain in obj-c.
One workaround for now is: always delete the key first before writing.
await _secureStorage.delete(key: _accessTokenKey);
await _secureStorage.write(key: _accessTokenKey, value: accessToken);

However, according to the documentation, this should not be the case (as far as I know) ;-)
Can someone confirm this or point me into the right direction? :-)
Regards

I was wondering if you managed to get to the root cause of this. We're also experiencing duplicate entries in the keychain.

Sadly no, I have no to very little experience in macOS / iOS native coding. Since I wrote my own service around the secure storage, it was not a big issue, we just use the workaround.

I've noticed this too. Another workaround:
If you set synchronizable: true in the macOsOptions it will only write to either 'Local Items' or 'iCloud Items' if iCloud Keychain is enabled for your user.
MacOsOptions(
  accessibility: KeychainAccessibility.unlocked_this_device,
  groupId: null,
  // Note: This needs to be true in order for macOS to only write to the Local Items (or Cloud Items) keychain.
  synchronizable: true,
);

I am closing all older issues. If this issue still exists in the latest version, please let me know.


Add query arguments to simulators API to selectively return test log data

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


shortcode: add label to non-slider image compare

Closes #112

Hmm can't forget about some cases where it's not a before and after but can be an in-depth examination like in an earlier progress report:

Or in those cases that are comparisons they aren't labeled in legacy articles:

But doesn't mean it doesn't work properly in another legacy article:

Or in those cases that are comparisons they aren't labeled in legacy articles:
won't be handling this case, the image can be either split up or edited to have the labels.  Otherwise it will just make the normal img shortcode overly complicated.

Hmm can't forget about some cases where it's not a before and after but can be an in-depth examination like in an earlier progress report:

I made the labelling opt-in as to not accidentally mis-label situations like this.


Outstanding Work!

@adamschwartz Thanks for all of your work on this project!
FYI: I forked your project into a new variation of Chrome Tabs, and I built an  NPM module.

Thanks @jaswsinc! Love where you took it! Nice job. Anywhere I can see an Electron app using the tabs?

I'm glad to hear that. Thank you @adamschwartz.
Yes, take a look here: https://jaswsinc.github.io/slick/

Very cool! Looks native! I’m impressed :)

Thanks! Yes, it really does. Your work to mimic Chrome was really fantastic. That part was all you.

Thanks! :1st_place_medal:

@jaswrks
Is there a tutorial about how to use this npm module ?

@imac-beep  did you find a way to integrate it with react?


Feature 'resolver' is required

Trying to build a simple app with:
[dependencies]
egui = { version = "0.11.0" }

and getting:
Execution failed (exit code 101).
cargo.exe metadata --verbose --format-version 1 --all-features
stdout : error: failed to download `egui v0.11.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `C:\Users\cedri\.cargo\registry\src\github.com-1ecc6299db9ec823\egui-0.11.0\Cargo.toml`

Caused by:
  feature `resolver` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["resolver"]` to enable this feature

Not sure where to specify this cargo-features line...

What is your cargo --version?
For me it shows
cargo 1.51.0 (43b129a20 2021-03-16)
and I do not get the error message you are reporting.

Yes, that was the problem, I was still on 1.50. Thanks!

I am havung cargo version : cargo 1.54.0 (5ae8d74b3 2021-06-22)
still getting the same error

I have same issue for cargo 1.52.0 (69767412a 2021-04-21)

Does removing the resolver = "2" line in Cargo.toml fix it for you all?


Support query cancellation

@peterfoldes I'm specifically interested in your opinion on the protocol versioning aspect here. Note that we're not actually yet putting out a 1.1.0 protocol version on the backend side, so 🤷🏻
Technically, as long as we deploy the support for cancellation on the backend (and don't revert it), we can release the SDK change at any time, all in the same negotiated protocol version.

Confirmed this works and cancels the query/Spark job behind the scenes:
INFO:        src.modules.sql.sql_service_impl:sql_service_impl.py:204 | Query 73f45c99-4a70-4180-95ec-92514300ed81 is running; cancelling...


Inclusion of a zero sized template node in a group alters its size.

Current Behavior
Initially found this bug when constructing a sub flow with a gauge and a template node. White space appeared above the gauge when displayed on the dashboard. Removing the template node removed the whitespace. The template node size was set to width 0 and height 0. The same behaviour was observed when the gauge and template nodes were removed from the subflow and placed in a flow (although in this case the white space was below the gauge). The template node size is set to auto as zero size is not an available option. This behaviour is observed even when the template node is empty, with no code in it.

Expected Behavior
Inclusion of a zero sized template node in a group should not alter its size.
Steps To Reproduce
flows-2.json
Environment

Dashboard version: 1.13.0
Node-RED version: 4.0.0.
Node.js version: v18.20.3
npm version: 10.7.0
Platform/OS: Raspberry Pi Debian version: 12 (bookworm)
Browser: Safari and Chrome

Have you provided an initial effort estimate for this issue?
I am not a FlowFuse team member

So, auto will automatically fill the width of the group, and it's height will just fit to it's content, but with a minimum height of 1 "row".
What's the use case here out of interest? Do you want the ui-template hidden under some circumstances?

In the subflow, the height is set to zero, yet still appears as 1 row high. I am using the template node to alter the CSS of another node in the same group. So the template node does not produce any "output" itself. In my case it is altering some of the properties of the node-red-dashboard-2-ui-gauge-classic (colouring the hub and the displayed temperature). If "Hidden" is the way to go, then that is fine.

Have you set the template to type CSS?

That fixed it! I hadn't tried that as I had assumed by the name of the option "CSS (Single Page)" that the CSS commands would affect all the groups on the page, but it works! Also I have javascript to set the CSS and I had wrongly assumed that option was for CSS only.


[FLINK-31319][connectors/kafka] Fix kafka new source partitionDiscoveryIntervalMs=0 cause bounded source can not quit

What is the purpose of the change
Fix error kafka partitionDiscoveryIntervalMs checking for noMoreNewSplits. This PR has been approved in PR-22901  just because kafka connector will be migrated from Flink main repo to here, so recreate it and close previous one in flink repo.
Brief change log
Correct partitionDiscoveryIntervalMs checking for noMoreNewSplits with <=0
Verifying this change
Add KafkaEnumeratorTest
#testRunWithDiscoverPartitionsOnceWithZeroMsToCheckNoMoreSplit,
#testRunWithDiscoverPartitionsToCheckNoMoreSplitOnce
#testRunWithPeriodicPartitionDiscoveryToCheckNoMoreSplitOnce
new cases and refine existed cases.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature?  no
If yes, how is the feature documented? docs

@PatrickRen @MartijnVisser PTAL~


Polymer.dom(...).observeNodes does not notify for some DOM removal

Please see the contrived test case here: http://jsbin.com/dajife/2
Removing nodes from the example element (notably, an element without a shadow root), fails to cause an expected notification from observeNodes.

Confirmed. The issue is that we're only notifying if we have an existing logical parent for the node that's added somewhere else. This is not a sufficient check and we'll need to fallback to using composed parent.

This issue supports https://github.com/PolymerElements/iron-selector/pull/73.


Allow revisions of 2 or more digits for yocto-based-OS-image

We also need to account for ESR versions, so the initial fix was reverted here: https://github.com/product-os/balena-versionist/pull/63

Resolved by https://github.com/product-os/balena-versionist/pull/61


crypto/x509/x509_cmp.c: return value of i2d_X509_NAME is not checked

OpenSSL 3.0, 3.1, master
Function i2d_X509_NAME() is called in functions X509_NAME_hash_old, X509_NAME_hash_ex (file crypto/x509/x509_cmp.c, lines 297, 328 ) and its return value isn't checked in these 2 instances, but checked in others.
Per documentation, i2d_TYPE() returns negative value if an error has occurred. Should I submit a PR to add checks of return value of  i2d_X509_NAME() for these 2 instances?

Yes, a PR is definitely welcome!

Thank you for a timely response!


Error when compiling compute shaders

Slang strips all declarations from the GLSL before sending it to glslang.
I send
#extension GL_ARB_compute_shader : require

layout(set = 0, binding = 1, rgba32) uniform image2D gOutput;
layout(local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

void main()
{
    imageStore(gOutput, ivec2(0,0), float4(1,1,1,1));
}

slang sends
#version 420
#extension GL_ARB_compute_shader : require

#line 33 0
void main_(){
{
    imageStore(gOutput, ivec2(0,0), float4(1,1,1,1));}
}
void main(){
main_();
}

Closing. This turned out to be "user error" in a very technical sense:

The file in question had a .hlsl extension, and Slang was being told it was HLSL code
Because the file had no __imports, the compielr went in "full rewriter" mode and turne the body of main() into an UnparsedStmt (no semantic info)
Because the target was GLSL (not the same as the source language) Slang tried to cross-compile, and when cross-compiling it only emits declarations that it seems get used
Because the function body was unparsed, it appeared that nothing was used, so nothing got output (other than main())

While this is technically a user error, there are two issues that should probably be fixed:

We should do a better job of error'ing out on obviously invalid code. The file obviously wasn't valid HLSL, but we parsed it anyway because our parser is so lenient
We shouldn't allow "rewriter" mode to be used together with whole-file cross-compilation (in fact, we should allow cross-compilation for source languages others than Slang...)

Those are separate issues, though, so I'm closing this one.


KAFKA-14382: wait for current rebalance to complete before triggering followup

Fix for the subtle bug described in KAFKA-14382 that was causing rebalancing loops. If we trigger a new rebalance while the current one is still ongoing, it may cause some members to fail the first rebalance if they weren't able to send the SyncGroup request in time (for example due to processing records during the rebalance). This means those consumers never receive their assignment from the original rebalance, and won't revoke any partitions they might have needed to. This can send the group into a loop as each rebalance schedules a new followup cooperative rebalance due to partitions that need to be revoked, and each followup rebalance causes some consumer(s) to miss the SyncGroup and never revoke those partitions.

Test failures are all unrelated -- merging this now

Cherrypicked all the way back to 3.0...whew!
Had to resolve a few minor merge conflicts along the way but it was generally smooth (I did make a small mistake on the 3.3 resolution so I pushed a quick hotfix to re-add a line I had accidentally removed)


model: Consolidated self.location as a property of baseclass

Fixes:#1260
Ready for review

Tests / lint (changelog, 3.7, 12.x) is failing because I haven't added anything in it as this is a refactor and not something that should go on changelog.

Is this still WIP?

Is this still WIP?

Yes, actually It was messed up by mistake when I re-based it with master last time and now I have rolled it back to the initial commit on this PR, have to make a few more replacements and then it would be good to go. I will try to get it merged in next weekly meet.

Codecov Report

Merging #1265 (cef865a) into master (7ef0808) will increase coverage by 0.01%.
The diff coverage is 83.33%.

:exclamation: Current head cef865a differs from pull request most recent head 8511a4f. Consider uploading reports for the commit 8511a4f to get more accurate results

@@            Coverage Diff             @@
##           master    #1265      +/-   ##
==========================================
+ Coverage   84.96%   84.98%   +0.01%
==========================================
  Files         174      174
  Lines       10977    10978       +1
  Branches     1822     1822
==========================================
+ Hits         9327     9330       +3
+ Misses       1280     1278       -2
  Partials      370      370

Impacted Files
Coverage Δ

dffml/model/model.py
68.50% <83.33%> (+1.28%)
:arrow_up:

Continue to review full report at Codecov.

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


fix api reference docs images

plots were not showing

Codecov Report

Merging #550 (b082e02) into main (f25515f) will decrease coverage by 0.21%.
The diff coverage is n/a.

:exclamation: Current head b082e02 differs from pull request most recent head 9595c32. Consider uploading reports for the commit 9595c32 to get more accurate results

@@            Coverage Diff             @@
##             main     #550      +/-   ##
==========================================
- Coverage   80.61%   80.40%   -0.21%
==========================================
  Files          57       57
  Lines        4127     4119       -8
==========================================
- Hits         3327     3312      -15
- Misses        800      807       +7

Files
Coverage Δ

src/methods/aggregate.jl
93.28% <ø> (ø)

src/methods/classify.jl
98.55% <ø> (ø)

src/methods/crop_extend.jl
89.13% <ø> (ø)

src/methods/mask.jl
90.00% <ø> (ø)

src/methods/mosaic.jl
89.02% <ø> (-1.22%)
:arrow_down:

src/methods/rasterize.jl
89.46% <ø> (-0.45%)
:arrow_down:

src/methods/trim.jl
95.65% <ø> (ø)

... and 7 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Constant "Invalid bearer token" error messages seen in Kubernetes container after K8s upgrade

Rancher versions:
rancher/server:v1.6.6-rc5
**Docker version: (docker version,docker info preferred)**v1.12.6
**Operating system and kernel: (cat /etc/os-release, uname -r preferred)**Ubuntu
**Type/provider of hosts: (VirtualBox/Bare-metal/AWS/GCE/DO)**DO
**Setup details: (single node rancher vs. HA rancher, internal DB vs. external DB)**Single node
**Environment Template: (Cattle/Kubernetes/Swarm/Mesos)**Kubernetes
Kubernetes version : v1.7.2
Steps to Reproduce:

Create a Kubernetes setup in rancher v1.5.7 with Kubernetes v1.5.4
Upgrade to v1.6.6-rc5 and upgrade all the infra stacks.
Upgrade Kubernetes to v1.7.2
After Kubernetes upgrade, the following logs are seen in the Kubernetes system container

7/28/2017 10:49:57 AME0728 17:49:57.689726       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:02 AME0728 17:50:02.301758       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:03 AME0728 17:50:03.363587       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:07 AME0728 17:50:07.819415       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:09 AME0728 17:50:09.158002       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:13 AME0728 17:50:13.417460       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:14 AME0728 17:50:14.820881       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:18 AME0728 17:50:18.955695       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:20 AME0728 17:50:20.517262       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:24 AME0728 17:50:24.303228       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:26 AME0728 17:50:26.106003       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:29 AME0728 17:50:29.865332       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:31 AME0728 17:50:31.738074       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
7/28/2017 10:50:35 AME0728 17:50:35.684330       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [Token has been invalidated, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]

Similar error seen here too: https://github.com/rancher/rancher/issues/9508

@leodotcloud the reason seems to be different. In 9508 it is a connectivity issue

I think we have the same problem in a fresh installation of Rancher v1.6.10.
kube-dns is unavailable, and logs in the kubernetes container are full of these:
E1031 16:35:56.664114       1 authentication.go:58] Unable to authenticate the request due to an error: [invalid bearer token, [invalid bearer token, [crypto/rsa: verification error, an error on the server ("illegal base64 data at input byte 36") has prevented the request from succeeding]]]
Hosts are Ubuntu Server 16.04, with Docker 1.12.6. I'm using a custom kubernetes template with portainer and with vxlan instead of ipsec.


textTransform ignored for Android TabView items

From @BeMor81 on May 16, 2018 10:33

Did you verify this is a real problem by searching the NativeScript Forum and the other open issues in this repo?
Yes
Tell us about the problem
Please, ensure your title is less than 63 characters long and starts with a capital
letter.
Which platform(s) does your issue occur on?
iOS/Android/Both
Android
Please provide the following version numbers that your issue occurs with:

CLI: (run tns --version to fetch it) 4.0.0
Cross-platform modules: (check the 'version' attribute in the
node_modules/tns-core-modules/package.json file in your project) 4.0.0
Runtime(s): (look for the "tns-android" and "tns-ios" properties in the
package.json file of your project) 4.0.1
Plugin(s): (look for the version number in the package.json file of your
project)N/A

Please tell us how to recreate the issue in as much detail as possible.
The best approach would be to get your code running in the NativeScript Playground and share the link with us, along with any additional details or steps to reproduce needed for examining the issue there.
Using angular NativeScript setting the textTransform to none has no effect on the tab's title text and still shows all uppercase as per default.
Is there code involved? If so, please share the minimal amount of code needed to recreate the problem.
All the below ways seem to not work

<StackLayout *tabItem="{textTransform: 'none', title: 'Favourites', iconSource: ios ? 'res://heart' : '', cssClasses: ['tabItem']}">
TabViewItem, .tabItem, tabItem {
text-transform: none;
}
Copied from original issue: NativeScript/NativeScript#5826

there is already an issue for this here #1312  and #1315 fixes this and added to 6.0 milestone.

Closing via  https://github.com/NativeScript/nativescript-angular/pull/1315


200608

Please make sure to check the following boxes creating your pull request, thank you very much!

[x] Add Blog Header, including title, author, image, categories, tags, etc.
For example:
---
title: Your Great Blog Title
author: your_github_id
categories: project
tags:
  - python
  - padlocal
image: /assets/2021/02-your-blog-slug/teaser.jpg
---

One line bio

Your blog post content Your blog post content
Your blog post content Your blog post content
Your blog post content Your blog post content

It will be easier to start drafting your post by using a existing post file as your template, for example, this one

[x] Keep all filenames lowercase, and use - to connect words instead of space. e.g. 2017-10-06-wechat-pc-impactor.md instead of 2017-10-06-WeChat PC Impactor.md

[x] Embed video/pdf from YouTube/Bilibili/local (if there's any) by using {% include iframe.html src="URL_or_PATH" %}. (Learn more about how to embed file/url in the post by reading this blog post

[x] Save photo to local before publishing, to a folder named by ${MONTH}-${YOUR_BLOG_SLUG}/ under /assets/2021/ directory.

[x] Select a beautiful and meaningful teaser image for your blog

[x] Create your contributor profile (if you are a first time contributor)
For excample:

jekyll/_contributors/lijiarui.md

---
name: Jiarui LI (李佳芮)
site: https://lijiarui.github.io
bio: 句子互动创始人 & CEO，微软人工智能最具价值专家 (AI MVP)
avatar: /jekyll/assets/contributors/lijiarui/avatar.png
email<EMAIL_ADDRESS>twitter: https://weibo.com/u/2175505900
---

Here is the example file:

lijiarui.md: https://github.com/wechaty/wechaty.js.org/blob/master/jekyll/_contributors/lijiarui.md
It will shown like this on wechaty website: https://wechaty.js.org/contributors/lijiarui/

To learn more about the contribute guideline, visit: https://wechaty.js.org/docs/contributor-program/

OK，I got it.

------------------ Original ------------------
From: "Huan (李卓桓)";
Date: 2021年8月3日(星期二) 中午11:58
To: "wechaty/wechaty.js.org";
Cc: "gangena"; "Author";
Subject: Re: [wechaty/wechaty.js.org] 200608 (#1157)

@huan requested changes on this pull request.
Please always specify a meaningful subject for your pull request.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


Fix repeated key assign_xor

Summary

Fixed repeated key in dictionary
Related Issue

closes #234
Changes

removed extra key in crosstl/translator/codegen/metal_codegen.py
Shader Sample (Optional)

Testing

No extra tests added, not required
Checklist

[x] Tests cover new or changed code (or reason why not)
[x] Linked the issue with a closing keyword (if applicable)
[x] Only touched files related to the issue
[x] Everything builds and runs locally

@NripeshN PTAL

Closing as duplicate of #232. Please join us there. Thanks!


Text highlighting after edit does not work

When adding new text, it is not styled. It will still get styled if the scrollview is resized. It looks like commit 45d3d62 is the last with working styling after typing. This issue also occurs in the demo project

Here's what happened. Previously, the various components were automatically validating any invalid visible regions after a change. This does work, but has timing issues. I changed things to make validation an explicit operation. If you want to synchronously apply styling on a change, it must happen after the layout has been updated.
With TextKit 1, that's not possible (as far as I know) without making a custom NSTextStorage subclass.
With TextKit 2, the layout process itself is asynchronous. I don't believe their are any hooks to know when the system has completed a particular section of layout.
You can also just do the styling on the next runloop turn. This is very easy, but can result in a flicker where text was rendered without styling and then immediately gets styled after. This is what I've done to fix TextViewHighlighter with 33476191bfaf6750c1de8061ebd7ba0bfd89d09c. Because TK2 is fully async, it could be this technique will not always work...


win8 x64 on subl init error

reloading plugin SublimeAStyleFormatter.AStyleFormat
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 2, in
import sublime
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._local_arch.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 6, in
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._linux_libcpp6_x86_64.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 10, in
HTML                      = 'text.html - source'
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._linux_libcpp6_x86.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 14, in
HTML_INSIDE_TAG           = ( 'text.html meta.tag - string - '
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._win64.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 18, in
HTML_INSIDE_TAG_ATTRIBUTE = 'text.html meta.tag string'
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._win32.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 22, in
NO_PLUG = sublime.INHIBIT_EXPLICIT_COMPLETIONS
ImportError: No module named 'SublimeAStyleFormatter.pyastyle.python3._macosx_universal.pyastyle'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\sublime_plugin.py", line 72, in reload_plugin
m = importlib.import_module(modulename)
File "X/importlib/init.py", line 88, in import_module
File "", line 1577, in _gcd_import
File "", line 1558, in _find_and_load
File "", line 1525, in find_and_load_unlocked
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\AStyleFormat.py", line 34, in
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle_init.py", line 6, in
File "C:\Documents\Software\Programming\IDE\SublimeText\SublimeText3\Data\Installed Packages\SublimeAStyleFormatter.sublime-package\pyastyle\python3_init_.py", line 25, in
EMMET_SCOPE = ', '.join([HTML, XML])
ImportError: Could not find a suitable pyastyle binary for your platform and architecture.

#61


Route 'key0' should declare a screen. For example

Version

react-native-router-flux v4.0.0-beta.28
react-native v0.52.1

Actual behaviour
throw error like below:
Unhandled JS Exception: Error: Route 'key0' should declare a screen. For example:

    import MyScreen from './MyScreen';
    ...
    key0: {
        screen: MyScreen,
    }
    ...

Expected behaviour
then I import all business components into the entry file, and combine them into  wrap, it works, but I want organize my route in each business module, and export some module files, combine them in entry file finally.
sorry i'm not good at English.
please give me a hand, I can't thank you any more
Steps to reproduce
I export some Components from my business modules like below:
mm01.js
(...some imports gose here)
export default class MM01 extends Component{
  render(){
    return (
      <Scene key="myModule01" initial tabs>
          <Scene key="myModule010" initial component={MM010}>
          <Scene key="myModule011" component={MM011}>
          <Scene key="myModule012" component={MM012}>
          <Scene key="myModule013" component={MM013}>
      </Scene>
    );
  }
}

mm02.js
(...some imports gose here)
export default class MM02 extends Component{
  render(){
    return (
      <Scene key="myModule02">
          <Scene key="myModule020" initial component={MM020}>
          <Scene key="myModule021" component={MM021}>
      </Scene>
    );
  }
}

entry.js like below:
(...some imports gose here)
class App extends Component {
    return (
      <Router>
          <Scene key="root">
              <MM01 />
              <MM02 />
          </Scene>
      </Router>
    );
}
AppRegistry.registerComponent('rnMbox', () => App);

@wulala 谢谢

@felixzxk Did you find a fix? Please help i'm having the same problem.

@isaackdamian
@wulala told the fix, Split your scenes to smaller parts if needed
https://github.com/aksonov/react-native-router-flux/blob/v4/docs/OTHER_INFO.md#split-your-scenes-to-smaller-parts-if-needed

How to use Component to divide routers?

Getting the same error as well with beta 31, the v3 method no longer works and the link above throws a  404 error

is this problem still going on ?

seriously ! please don't write packages if you can't maintain them, fix the issues

v3 and beta are not supported.


How to trigger scrolling when the page isn't scrollable, but there's still content to load

Hi,
When prefill: false, and the page isn't scrollable there's no way to trigger the plugin to load the next set of items.
Thanks!

You can use loadNextPage


the list api on Aegis Sentinel is difficult to use; you end up having to specify dummy parameters for workload and secret. -- also the output could be prettefied at least, since it has potential to be a long list: a single line JSON is not quite human-readable.

Done.


add cloudflare options

Hi @chadgeary,
I looked at the Network graph (below Insights - >Network) to see if anyone made any further updates and found that https://github.com/chadgeary/cloudblock has a newer commit which says it add cloudflare options:
https://github.com/barlevalon/cloudblock/commit/803be5008db176c0b59d3d24fb041774ebd15d28
I don't know anything about, just wanted to make you and people looking at the Pull requests aware this commit,
and give you the easy opportunity to merge it.
PS: This repo as a few changes forked from an older commit: https://github.com/michaeldeggers/cloudblock

This looks just fine to add, thank you


Update demo dockerfile for latest Genie client. Remove iPython

Coverage decreased (-0.1%) to 88.703% when pulling 87a471d91d0c69518e91be805b0b7fcd9a2272a0 on tgianos:master into 7b1bf26a9ed38f85247fa60bc79eff284a8dd3f4 on Netflix:master.


Upgrade environment scripts and dependencies

This PR addresses the issues I found while trying to debug the extension myself on different machines. It also "modernizes" some of the tooling like the dependencies, launch scripts & tasks, package.json, etc. This does not add any "new" functionality but this-
> git clone git://github.com/codegard1/vscode-dylan
> cd vscode-dylan
> npm i

should produce something like this:
> npm i
><EMAIL_ADDRESS>postinstall C:\Users\...\vscode-dylan
> node ./node_modules/vscode/bin/install

Detected VS Code engine version: ^1.0.0
Found minimal version that qualifies engine range: 1.0.0
Fetching vscode.d.ts from: https://raw.githubusercontent.com/Microsoft/vscode/fa6d0f03813dfb9df4589c30121e9fcffa8a8ec8/src/vs/vscode.d.ts
vscode.d.ts successfully installed!

added 96 packages from 357 contributors, removed 8 packages, updated 16 packages and audited 902 packages in 5.533s

Additionally, you should then be able to run the extension in a Debug Host by pressing F5 or selecting Debug >  Start Debugging from the top menu.
The machines I used for testing were running Mac OS, Windows 10 or WinServer 2k12, with<EMAIL_ADDRESS><EMAIL_ADDRESS>@8.12.0, and ^10.0.0 and VS Code 1.3.0.

I tested this PR by merging it onto the current dylan-lang/vscode-dylan master and it works fine.

@pedro-w feel free to merge these in the future if they look good to you!


Ensure all jobset attributes evaluate, and check that in CT

Description
aka "eval checks go brrrr"
Please review the commits individually.  Produced as part of the non-Hydra tooling used to validate

https://github.com/NixOS/nixpkgs/pull/268097

Description of changes
This PR adds release-attrpaths-superset.nix, which walks the entire nixpkgs tree and emits a superset of all release attrnames in only 44 seconds on a 3ghz CPU, using less than 5 gbytes of memory.  By comparison, on the same CPU the nix-env -qaP hack used by ofborg on every PR submission requires waiting 25 minutes and peaks at 58 gbytes, even with checkMeta turned off.  Full details below.  This is:

33x faster (or 2.9% of the elapsed time)
12.5x less memory (or 8.0% of the peak memory usage)

If all you need is the attrnames -- for example to launch a mass rebuild -- then you're done.  If you want to replace the ofborg outpaths.nix step, see the follow-up PR:

https://github.com/NixOS/nixpkgs/pull/269403

Validation
To confirm that the release-attrpaths-superset.nix really are a superset of the slower method, run
nix-build pkgs/test/release/release-attrpaths-superset.nix -A failures

Additional CT (Continuous Testing) check
This PR adds recurseForRelease=false where necessary within nixpkgs in order to make this possible -- it screens out infinite recursions and several non-tryEval-catchable failures (for example, passing a mistyped argument to a builtin, which is an uncatchable error) and infinite recursions.
Finding all the places where it was necessary to add this was a lot of tedious work, so to make sure that work is not undone, lib/tests/release.nix now verifies that release-attrpaths-superset.nix evaluates successfully.
Although it doesn't really fit in lib/tests, there isn't anywhere else it can be placed and still be run by ofborg on every commit.  If some other such place materializes in the future I would be happy to relocate it, but since ofborg is out-of-tree this PR should not block on that happening.
Fixes

https://github.com/NixOS/nixpkgs/issues/269357

Measurements
According to GNU Time release-attrpaths-superset.nix consumes:,
Command being timed: "nix-instantiate --eval --strict --json pkgs/top-level/release-attrpaths-superset.nix -A names"
User time (seconds): 44.88
System time (seconds): 8.09
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:53.20
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 4823028
Average resident set size (kbytes): 0

Compared to release-outpaths.nix:
Command being timed: "nix-env -qaP --no-name --out-path --arg checkMeta false --argstr path /git/work/pr/release-outpaths -f pkgs/top-level/release-outpaths.nix"
User time (seconds): 1294.48
System time (seconds): 224.37
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 25:25.01
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 58336672
Average resident set size (kbytes): 0

If I understand it correctly, this injects a magic attribute recurseForRelease into all package sets, similarly to recurseIntoAttrs. I already dislike recurseIntoAttrs for many reasons, so I'd like to know if there are other solutions to achieve the same goal. For example, could this be merged with recurseIntoAttrs by making the latter more than just a boolean?

I too dislike recurseForAttrs, particularly because it has magical effects on nix-env (i.e. the interpreter).
recurseForRelease is temporary; I would like to see it removed after the following events happen:

It becomes possible to walk all-packages.nix tree without eval failing (this PR)
We add CI which prevents people from merging changes that break #1 (also this PR)
We encourage package maintainers to fix their broken eval and remove recurseForRelease={true,false} flags from their packages.
We deprecate recurseForRelease
We remove recurseForRelease

Essentially recurseForRelease was a way for me to do #1 and #2 possible without deep invasive changes into other peoples' packages, like totally restructuring them.
The intended semantics of recurseForRelease are that release-attrpaths-superset.nix walks the attrset tree, starting at pkgs, and:

Stops if it encounters recurseForRelease=false
Stops at any value for which isDerivation is true unless that derivation has recurseForRelease=true

This is, unfortunately, necessary because there are Hydra release jobnames which have proper prefixes which are attrnames of derivations (wtf).

I will add a comment with the above semantics.

Thank you. One thing I still don't understand (but probably simply because I don't understand release job sets yet) is, why this would be necessary on package sets which don't have recurseIntoAttrs? Why would it recurse into them at all in the first place?
Also if your hope is that Nixpkgs one day fully evaluates without errors, I fear that this might never happen. A more realistic approach would be to have a catch function truly worthy of its name. (Or a more lazy package system so that we don't have to drag tons of stuff through mkDerivation)

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-11-28-nixpkgs-architecture-team-meeting-46/36171/1

I will add a comment with the above semantics.

I have done this (commit XXXX) <- will edit when I push it

is, why this would be necessary on package sets which don't have recurseIntoAttrs? Why would it recurse into them at all in the first place?

recurseIntoAttrs is magical, and affects nix-env in ways that are not expressed in Nix code.  nix-env contains an attrset-walking routine written in C++ which checks for recurseIntoAttrs.  Its semantics are poorly-defined.
The new release-attrpaths-superset.nix contains an attrset-walker which is written entirely in Nix.  It does not use the C++ attrset walker, and therefore totally ignores recurseIntoAttrs.

Also if your hope is that Nixpkgs one day fully evaluates without errors,

I do.  In fact, that day is today.  Go ahead, check out this PR and run the command at the top of release-attrpaths-superset.nix.

@piegamesde everything in this comment by @infinisil is correct and does a much better job of answering your question than I did.

@infinisil thank you for the incredibly detailed review!  I believe I have addressed all of your requests except:

[ ] https://github.com/NixOS/nixpkgs/pull/269356#discussion_r1406958278 (still working on this)
[ ] https://github.com/NixOS/nixpkgs/pull/269356#discussion_r1406967782 where I would ask that you reconsider having this PR block on changes to ofborg, since it's out-of-tree and this is a fairly large and fragile-while-unmerged PR.  I think we agree on the end goal, I just want to get there by letting the nixpkgs and ofborg PRs be processed concurrently rather than sequentially.

Also I need to address this comment by @piegamesde

[ ] https://github.com/NixOS/nixpkgs/pull/269356#discussion_r1409136391

Let me make sure CI still passes and then I will wrap up these last few changes.

Okay, the latest push squashes and does major cleanup to the version history.
I believe it addresses all of the issues raised, except for the one listed below.  @infinisil @piegamesde would you mind taking one more look at this?
The only unresolved issue is the question of whether to:

Block this PR on waiting for changes to ofborg or
Temporarily place the release-attrpaths-superset.nix test in a suboptimal location (lib/tests) until ofborg gets around to adding a non-lib test entry point (maybe pkgs/test/release/default.nix).  As soon as ofborg does that, we can move the test to its final resting location.

Obviously I think we should go with (2).  But not only because this is my PR.  In general, forcing certain changes to jump through more artificial hoops than other changes is a dangerous path to head down.  Nixpkgs is like wikipedia -- anybody can edit anything, subject only to the review process, CI, and a committer merging it.  On an emotional level nobody really likes other people editing what they've written, but we all have to put that aside in order to produce excellent software.
If we allow there to exist mechanisms (like ofborg being randomly in another repo with a smaller and less-responsive committer group) by which people can artificially make it more difficult to change certain pieces of code, there will be a creeping temptation for people to apply those mechanisms to their own changes.  In effect, a way of making their own work "more permanent" than other peoples'.  This is really bad, and we should resist it on principle.
I think it's bonkers that ofborg isn't in the monorepo, but I accept that that isn't going to change anytime soon.  Until it does change, I feel very strongly that ofborg's separate-repo-ness must never be an additional impediment, no matter how small, to any change being made.

Second round of cherry-picks: https://github.com/NixOS/nixpkgs/pull/271123

Having the actual code that ofborg uses in nixpkgs certainly makes it easier to reproduce evaluation errors locally. My plan is to use pkgs/top-level/release-outpaths.nix in nixpkgs-review soon.

Oh there is something else to consider here: ofborg also fails if the evaluation outputs anything on stderr (aka builtins.trace). This is generally a good thing, since it prevents Nixpkgs from using deprecated functions (that use e.g. lib.warn).
We should have the same thing with the new CI check introduced here.

Rebased.

Then how about using GitHub Actions to test this instead for now?

So, there are really two problems with ofborg:

You can't run it locally
It's out-of-tree

Your idea solves the second problem, so it's definitely an improvement, but we still have the first problem.
Could we have one, single "run all the CI checks" entrypoint from githubland into nixpkgs, and then fan out to the various checks using Nix code?  Then we could add the github magic for that single entry point once and never touch it again.  As long as it's a single command it'll be locally reproducible.
I just don't want to see more and more weird YAML machinery accumulating.  We should keep all the logic in Nix, not github-YAML.

We should have the same behavior with the new CI check introduced here.

Okay, see latest push, which adds enableWarnings?true; it can be set to false for the CI run.
I'd like to leave the default as true in order to nag people to work on fixing the eval failures that are currently being dealt with by tryEval.  There are only 153 of them and most of those come from big blocks with a common cause (cough cough freebsd cough cough).
If that number ever drops to zero then we can switch on enableWarnings=true in CI and it will stay at zero (hooray!) and we can even remove the builtins.tryEval!

@infinisil please see in particular the last two commits.

Ensure all jobset attributes evaluate, and check that in CT

Do you mean "CI" here?

Ensure all jobset attributes evaluate, and check that in CT

Do you mean "CI" here?

https://en.wikipedia.org/wiki/Continuous_testing is indeed a thing but also I didn't know what ct was standing for until I saw it written out in the test file. For clarity we should probably stick to ci as it's way more known abbreviation.

https://en.wikipedia.org/wiki/Continuous_testing is indeed a thing

It always has been :smile:

For clarity we should probably stick to

Alright, fixing the acronym can wait until another day.  I've pushed 1f8232eb1e35b64ec2562cae2c147164e74652d0 which changes <nixpkgs/ct> to <nixpkgs/tests>.

I'd think it should be <nixpkgs/ci>. Seeing a toplevel tests would make me think all of Nixpkgs tests are in there.

Btw this PR has gotten bigger in scope now (also adding a general CI task specification), which makes reviewing and merging this even harder. Generally I'd really prefer to keep PRs as small as possible.

Seeing a toplevel tests would make me think all of Nixpkgs tests are in there.

That's the point: all tests should be accessed via that entry point, and only that entry point.
Of course tests can pull in things that aren't under that directory, just like lib/tests and pkgs/test already pull in things that aren't under those directories.

Needs a rebase.

Rebased.


Feature request: Add support for the private git hub

Would it be possible to support this action for the private git hub? It looks like now it has support only for the public GitHub repository.
As per my understanding, the possible option is to take the URL as a parameter and overwrite the value here

created a PR https://github.com/TriPSs/conventional-changelog-action/pull/154


Improved comment for DateOnly.

As this comment appears in the generated documentation, I would prefer to keep it short (I find it already too long, btw).
Also, the additional text does not really add information because the example date is already giving the same information.

If you want to refer to a point in time, you use date-time which is millisecond accurate and timezone dependent.
When you refer to a day, you use a yyyy-mm-dd date.

If you want to refer to a point in time, you use date-time which is millisecond accurate and timezone dependent. When you refer to a day, you use a yyyy-mm-dd date.

If I have an entity with a validity from 1.1.2022 to 31.1.2022 in CET, I will always use datatype DateTime. Even if I do not use the time information. With the data type DateOnly, I cannot create a java.sql.Date in Java until I know a time zone.

If you want to map to a java.util.Date, then you need a timezone information yes. By definition, with a date it is the local timezone.

If I run my application in the cloud, then the local time zone is UTC, but on my notebook it is CET. Generally, from a technical point of view, I prefer UTC, but the business partly demands CET. How can I distinguish what applies?


Splits installation parts

This PR separates out the different parts of the installation process to make it easier to follow the path of each aspect of installation. This allows us to easily also include the support for npm package installation, as part of #21, easily by following a standard.
Changes

Creates a standard interface for the installation of addons, bower packages and files.

This interface includes:

askForAll

Asks if we want to install all packages that have been defined

ask

Asks for permission to install a dependency, if autoinstall is set - we automatically call install

install

Does the actual installation of the dependency

Separates out the installation of dependencies by installation type in the utils directory

API Updates
New Features
No new features  with this refactor.
Deprecations
There are no deprecations.
Enhancements
Splits the code out in order to provide and easier context of what is being installed. Implements the above API, under the changes section, making it easier to implement future dependency installation.
Checklist

[x] Unit tests
[x] Documentation

Fixes #22

@cball Would you mind reviewing this for me? Would love to get your preliminary input on this.


Add utils for downloading and extracting archives

Description
This PR adds functionality for downloading, decompressing and extracting archives.
This is needed for issue #83
Implemented changes

[x] add utils.archives for archive extraction and file decompression
[x] add utils.downloads for downloading files

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change is or requires a documentation update

How Has This Been Tested?
Right now tests are missing for this branch as I am unsure what the best way for testing would be.
Testing should be done as unit tests, so I tend to use some mock objects?
I have to dig deeper for this.
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules
[x] I have checked my code and corrected any misspellings

This PR depends on merging #89 first

We decided to add the test for this very basic functionality later on and focus on the more important stuff first.
I will create an issue for this tomorrow.


快速切换的bug;The problem of switching videos quickly

当我正在加一个网络视频的时候(还没有完成Initialize)，反复切换视频源，让它重新加载播放。导致多个视频一起播放。
When I was adding a net video (I haven't finished Initialize yet), I switched the video source repeatedly and let it reload and play. Cause multiple videos to play together.

make sure you've handled your videocontroller states correctly in flutter.

I'm very sorry to reply to you now, but I still don't know how to modify it. My current code is as follows, this method "_initVideo()" will be called when switching alternately：
Future _initVideo({bool isAutoPlay = true}) async {
final videoPlayerController = VideoPlayerController.network(videoUrl);
final old = _videoPlayerController;
_videoPlayerController = videoPlayerController;
if (old != null) {
old.removeListener(_playerPositionListener);
await old.pause();
}
setState(() {
  _initChewie(isAutoPlay: isAutoPlay);
  _videoPlayerController.addListener(_playerPositionListener);
});

}
void _initChewie({bool isAutoPlay = true}) {
_chewieController = ChewieController(
videoPlayerController: _videoPlayerController,
aspectRatio: 16 / 9,
autoPlay: isAutoPlay,
looping: false,
showControls: true,
allowedScreenSleep: false,
startAt: Duration(microseconds: _lastInMilliseconds),
customControls: CustomControls(
title: widget.model.videoName + " " + widget.model.videoLevel),
materialProgressColors: ChewieProgressColors(
playedColor: AppColor.icon_yellow,
handleColor: AppColor.icon_yellow,
backgroundColor: Colors.grey,
bufferedColor: AppColor.icon_yellow.withOpacity(.5),
),
placeholder: Container(
color: Colors.black,
),
errorBuilder: (context, error) {
return CustomChewieOverlayWidget(
onTap: () {
setState(() {
_initVideo();
});
},
tapMsg: "点击重试",
tipsMsg: "视频加载失败， 请稍后再试",
);
},
autoInitialize: true,
);
}


UserErrorRpCollectionLimitReached

In Azure backup service error message like OperationNotAllowed : The number of restore points across restore point collections and resource groups for a VM cannot exceed 18. To create a new restore point, please delete existing restore points.

@bollineni36 Thanks for the feedback! I have assigned the issue to the content author to evaluate and update as appropriate.

#reassign:GeethalakshmiG

Thanks for your feedback. We've updated this document.

#please-close


Make prior an optional argument for SNPE

In SNPE, the prior is only used to reject simulations if they are outside of the prior support. If this is not required (e.g. prior has no bounds, or user does not care as much about exactness), one would not need the prior.
In addition, in some cases, users do not have a closed-form prior. They might construct their prior only from samples. It adds overhead having to define a prior that has log_prob() and sample() methods. In addition, when one runs simulations e.g. in matlab, one would have to reimplement the prior in python.
I therefore say that, for SNPE, we make the prior optional. When multi-round is called, we throw an error and say that the user has to specify a prior.

#409 ?

#409 ?

whoops, I had gotten an error when submitting this. Let's stick to #409

whoops, I had gotten an error when submitting this. Let's stick to #409


Transformer fix

Proposed changes
Changes

Changed order of layernorm and ffn according to tensorflow and pytorch implementations. (norm_first=False is default in pytroch as well as transformer)

Added Encoder, Decoder with Dropout

Parts want to discuss

Do you want to use Transformer with Dropout as main class?

Do you like to add ffn as function or classes?

Do you like to add norm_first parameter so that you could choose to do layer_norm first or later?

Tensorflow do not do dropout with ffn while pytorch do. Which one should I refer to?

I guess you did not add dropout since you would like to benchmark transformer without dropout for all jax, torch, tensorflow, mlx. I also had trouble adding dropout for jax.

Testing

All Encoder, Decoder (w and w/o dropout) are tested with mlx-exmaples/transformer_lm

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING document
[x] I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have updated the necessary documentation (if needed)

Do you want to use Transformer with Dropout as main class?

Let's just make dropout a kwarg parameter to the Transformer* which defaults to 0. Don't need to implement seperate classes.

Do you like to add ffn as function or classes?

Let's keep it the way it is implemented in __call__

Do you like to add norm_first parameter so that you could choose to do layer_norm first or later?

I think we should have this. And maybe default it to True as that seems to be a more common setup?

Tensorflow do not do dropout with ffn while pytorch do. Which one should I refer to?

Seems reasonable to follow PyTorch in that case. Add a comment about it when describing the dropout argument.

Also do you mind adding a docstring to the Transformer class?

@Jyun1998 are you still planning on updating this?

@Jyun1998 are you still planning on updating this?

Yes! I will finish it within this week with your comments :)

Hi @awni ! Merry Chirstmas :)
Added docstring, norm_first, and also activation to replace mx.maximum at ffn layer.
There are few points to further discuss.

I have setted norm_first=False, which is common according to pytorch_docstring

by adding norm_first, codes got way extensive long. according to pytorch_implementation, they further break down encoder/decoer_layer with private function _sa_block, _ff_block. Do you want to keep it lastest commit or use _sa_block, _ff_block?

default dropout ratio is 0 where Dropout call is implemented with self._p_1 == 1, so Dropout(0) will do nothing.

I have setted norm_first=False, which is common according to pytorch_docstring

Ok with me

by adding norm_first, codes got way extensive long.

I left a comment that might work for shortening this. I don't think you need separate modules for these.

default dropout ratio is 0 where Dropout call is implemented with self._p_1 == 1, so Dropout(0) will do nothing.

👍

Also could you rebase? There is a merge conflict

@awni Thanks for the review!

I added defaults to doctring.

for the shortening the code, below will do the same but the code become quite not straight forward, so better left it as it is.

def __call__(self, x, mask):
    y = self.ln1(x) if self.norm_first else x
    y = self.attention(y, y, y, mask)
    y = self.dropout1(y)
    x = x + y  # Residual connection
    x = self.ln1(x) if not self.norm_first else x  # Apply LayerNorm if not norm_first

    y = self.ln2(x) if self.norm_first else x
    y = self.linear1(y)  # Corrected to linear1
    y = self.activation(y)
    y = self.dropout2(y)
    y = self.linear2(y)
    x = x + y  # Residual connection
    x = self.ln2(x) if not self.norm_first else x  # Apply LayerNorm if not norm_first

    return x

Also rebased :)

Looks great, thanks for adding!! I pushed a few changes to the doc strings and included stuff in the docs as well!

Thanks for the review :)


Request: include at:// URI in rel=alternate link header/tag

Described here and in https://github.com/likeandscribe/frontpage/pull/172
This is already supported in Bluesky, Frontpage, WhiteWind, and several blogs that use atproto as the storage layer. Adding in this extra piece of information greatly increases the connectivity of the atproto ecosystem as it allows tooling to pick up on the content in a semantic way.
The implementation is quite minimal and involves including the at:// URI in either a <link> tag or Link header in the initial server response.
Happy to open a PR to contribute this change, but let me know if you don't want to accept it of course

It's actually totally doable. The problem is that the at-uri would be the one the user submitted, which might not be the root of the thread. Getting to root of the thread would require lots of requests on the server side to the Bluesky servers, which I currently don't want to do. I'm also not sure if this would make semantic sense.


unsatisfiable class OBI:comment on investigation

Greetings OBI team, while building an application ontology which imports form a variety of OBO ontologies, I've run across the following issue (see it in PMO here) with the class OBI:comment on investigation which when reasoned upon with ELK 0.4.3 becomes inferred as owl:Nothing.

@cmungall pointed out that this issue stems from the combination of a continuant and a process with an AND in the axiom.

Discussed on OBI Dev call 08/19/2019.  Assigned to Jie

The logical definition should probably be changed to:
'textual entity' and ('is about' some (investigation or ('part of' some investigation' or 'participates in' some 'investigation'))
Will comment on the disjoints separately.

The term was added for NIAID BRC standards with description: "Any additional information about the initial specimen collection event, the sample preparation process, or any other aspect of the project worth noting."
The logical definition proposed by @bpeters42 looks good and fits what NIAID BRC needs. Will update the logical axioms in the OBI.

curious as to how this passed robot checks.
On Thu, Aug 22, 2019 at 1:46 PM jie zheng<EMAIL_ADDRESS>wrote:

The term was added for NIAID BRC standards with description: "Any
additional information about the initial specimen collection event, the
sample preparation process, or any other aspect of the project worth
noting."
The logical definition proposed by @bpeters42
https://github.com/bpeters42 looks good and fits what NIAID BRC needs.
Will update the logical axioms in the OBI.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/obi-ontology/obi/issues/1050?email_source=notifications&email_token=AAAMMONIHLCFCGV3WRI4YR3QF33IZA5CNFSM4IMZ7TM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD46K5BA#issuecomment-524070532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAMMOOAR64YCP5IQIF275TQF33IZANCNFSM4IMZ7TMQ
.

@cmungall Not ROBOT's fault. We haven't been asserting BFO disjoints when building OBI. PMO is getting "continuant DisjointWith 'part of' some occurrent" from somewhere else. I made a separate OBI issue for this #1051.


Remove Redundant Directories - Issue#15

Deleted the following files:
./public/
./video_chat.html
./js/app.js
./now.sh

If there's no issues with the app running on the server then you should do a Rebase and merge instead of a Merge pull request. Reason we used the merge pull request last time was because of the commit issues. Using the rebase option this time won't add a "merge commit" onto the branch.

Added the "delete the /public directory" on accident. We need to keep that one to maintain the video chat portion. Also, I still see the ./js/app.js and ./now.sh files in the #15 branch? So the others are okay to remove just not the /public directory. Make sense? Sorry, I am going on negative sleep and brain is fuzzy.

Closed pull request with merge due to deleted ./public folder. Will resubmit request.


[BUG]: Link form validation skipped after logout

What happened?
Link form on the payment elements don't validated during elements.submit() after logout previous account with "Link with card integrations"

Expected result:

Actual result:
No validation errors contains submit result.

Environment
No response
Reproduction
No response

I don't understand the steps you took to encounter the expected vs actual result. Can you please explain the specific steps involved to observe the two different results you shared?

Hi @brendanm-stripe
Steps to reproduce:

Set defaultValue during elements initialization with customer email that already registered in link
Fill 00000 for the phone verification
You should see form with logged in customer (image 1)
Click 3 dot's and click "Log out of Link"
Fill card data
Check "Save your info for secure 1-click checkout with Link" checkbox
Submit elements

Expected validation of link email and phone fields but for not validated.


Rework CA certificate support to allow rootless containers

This PR includes several improvements and simplifications in CA certificate handling.
Support for CA certificates in containers running as a non-root user
After this PR, CA certificates can get applied even if the container is run as an arbitrary user. This helps usage in restricted environments like Red Hat OpenShift and follows best practices for Kubernetes deployments. When running an Adoptium container as non-root user with USE_SYSTEM_CA_CERTS=1, only the JVM truststore will get updated (or more correctly: re-created), while system CA store will not get updated.
Support for CA certificates in containers running with read-only root filesystem
After this PR, CA certificates can get applied even if the container is run with a read-only root filesystem. Running containers with read-only root filesystem is a recommended best practice for Kubernetes. When running an Adoptium container with read-only root filesystem, the same restrictions apply as with non-root users. In addition, /tmp must be mounted as an EmptyDir volume, to allow JVM trust store to get updated.
Unification of Docker entrypoint scripts into one
Since we can't rely on system tools in non-root or read-only root filesystem mode, the certificate procedure has been unified between all Linux platforms and therefore there is now only one entrypoint script left. As a consequence, a conditional has been added in Dockerfile generation script to exclude Windows platforms, which currently do not support CA certificates.
Entrypoint script now exports CACERT environment variable to point to the used truststore file
Since the JVM truststore can't be overwritten, it needs to be recreated on a different path. This path is automatically provided via JAVA_TOOL_OPTIONS by the container entrypoint script, however it's also exported via the environment variable CACERT to facilitate re-use of that truststore in local scripts.
NB: Dockerfile updates are not included in this PR, since they will get updated by the script after the merge.
Docs updates at https://github.com/docker-library/official-images/ pending.
Possibly fixes: https://github.com/adoptium/containers/issues/464

It seems some tests are failing, which didn't fail locally. Let me look at it.
EDIT: Possibly the same problem as in the last PR on this topic: Dockerfiles are not current, so that the tests fail in the PR. Should I include the Dockerfile updates?

I think you need to rebase in that case?

It seems some tests are failing, which didn't fail locally. Let me look at it.
EDIT: Possibly the same problem as in the last PR on this topic: Dockerfiles are not current, so that the tests fail in the PR. Should I include the Dockerfile updates?

I think you need to rebase in that case?

That's no problem normally. I can try including them.

@rassie Are you able to address the feedback from @tianon (he's our partner from DockerHub :-)) in a separate PR?

@rassie Are you able to address the feedback from @tianon (he's our partner from DockerHub :-)) in a separate PR?

Yes, sure, should be possible in the next 24 hours or so.

@tianon @karianna I've been writing a comment addressing @tianon's point about scope creep and might have found a way to keep multiple sides happy, while reducing pain points, in particular:

People feeling the scope creep and maintenance burden
People not liking the entrypoint requirement
People wanting to inject CA certificates into JRE trust stores.

I'm thinking about using a companion container image, maintained either inside or outside or Adoptium project, which would contain most of the logic in the current entrypoint and could be used as an init container.
It would work somewhat like this:

Freeze and deprecate current entrypoint-based certificate implementation, add a deprecation warning
Document the following recommended process:

First init-container: your eclipse-temurin-based target container; copy the cacerts file from it to a temporary volume
Second init-container: this new companion container, with your custom certificates and temporary volume mounted, which would combine both to a new cacerts using the logic in this PR
Main container: your eclipse-temurin-based target container with added volume mount containing the new cacerts file and an added environment variable JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStore=/volume/cacerts -Djavax.net.ssl.trustStorePassword=changeit.

At some point in the future: remove current certificate functionality, possibly remove the entrypoint altogether.

This would probably make the Kubernetes camp happy, since it directly maps onto Kubernetes proceedings. Docker camp would need something like docker compose with service_completed_successfully, but this is probably manageable.
Should I try and implement this before this PR is included in a released image?

Thinking further: if this companion image were to be maintained inside the Adoptium project, we might get away with just including the default cacerts and thus only needing one init container instead of two. No idea how dependant this is on the actual JRE version, maybe there is some common source for the cacerts file?

@tianon @karianna I've been writing a comment addressing @tianon's point about scope creep and might have found a way to keep multiple sides happy, while reducing pain points, in particular:

People feeling the scope creep and maintenance burden
People not liking the entrypoint requirement
People wanting to inject CA certificates into JRE trust stores.

I'm thinking about using a companion container image, maintained either inside or outside or Adoptium project, which would contain most of the logic in the current entrypoint and could be used as an init container.
It would work somewhat like this:

Freeze and deprecate current entrypoint-based certificate implementation, add a deprecation warning

Document the following recommended process:

First init-container: your eclipse-temurin-based target container; copy the cacerts file from it to a temporary volume
Second init-container: this new companion container, with your custom certificates and temporary volume mounted, which would combine both to a new cacerts using the logic in this PR
Main container: your eclipse-temurin-based target container with added volume mount containing the new cacerts file and an added environment variable JAVA_TOOL_OPTIONS=-Djavax.net.ssl.trustStore=/volume/cacerts -Djavax.net.ssl.trustStorePassword=changeit.

At some point in the future: remove current certificate functionality, possibly remove the entrypoint altogether.

This would probably make the Kubernetes camp happy, since it directly maps onto Kubernetes proceedings. Docker camp would need something like docker compose with service_completed_successfully, but this is probably manageable.
Should I try and implement this before this PR is included in a released image?

I'd probably split this into it's own issue and we can build ontop of what we've already merged here.


Revisit the Stats hook to ensure that we're correctly representing operations

Right now we just track get/set and a couple of other things. It would be better if the Stats hook were modified into tracking all CRUD groups (at least).
Perhaps it would be nice to track the count of results in some form. We could keep track of results on a per-action basis (this is just noted for my memory).
%{
  "clear" => 500,
  "exists?" => %{
    "true" => 10,
    "false" => 20
  },
  "get" => %{
    "ok" => 10,
    "missing" => 20,
    "loaded" => 15
  }
}

Maybe then we could support stats retrieval on a per-command basis which allows us to provide additional info about that stat.
Cachex.stats(:my_cache)                 # very high level stats (op count, etc)
Cachex.stats(:my_cache, :get)           # include things like hit rate using info in the `:get` key
Cachex.stats(:my_cache, [ :get, :set ]) # same as above but for both actions
Cachex.stats(:my_cache, :raw)           # everything we have collected (the struct above)

Been thinking on this more and I like the above. Although I think there should also be a :global entry which is very general statistics (similar to those tracked currently). Easy to get a high-level overview of your cache usage that way.

Slight tweaks to the initial notes on how to specify different stat retrieval.
It would become the below instead. This is to avoid any change in the public API, and because it's just an option rather than a requirement.
Cachex.stats(:my_cache, for: :get)


📝 [DOCS]: REMOVE MANUALLY UPDATED OLD CONTRIBUTERS TABLE

Description

This issue is about removing the old contributors table, because since it's not automatically updated and the table is also not properly structured so that the part looks worse and creates a bad impression on the readme file
There is already a contributors graph on the below of readme which generates dynamic images for the contributors so we don't want to the old manually updated contributors table

Screenshots

Code of Conduct

[X] I have checked the existing issues
[X] I agree to follow this project's Code of Conduct
[X] I am willing to work on this issue
[X] I am a GSSoC'23 contributor

@0xabdulkhalid It is resolved now! Thanks  for your suggestion btw.


Ignore secret in ZoneConnection keys when stringifying

Motivation
Sensitive connection information should be masked in the logs. Currently ZoneConnection doesn't have an override toString method to encrypt the connection information, so printing either the ZoneConnection or Zone in logs will store the keys.
Scope of change
One approach could be to associate a cryptography with the ZoneConnection and override the toString method.
Another, simpler approach, is to just remove the key information.

Edit: Should override toString in ZoneConnection to print name/keyName/primaryServer. Omit key. See toString override in Zone for example. Validate that Zone toString has the connection in this format.

Is this still an issue?  If so, this is a fast one to implement.  Look at ZoneConnection and make sure that we have an override on toString sounds simple enough to prevent accidental logging of sensitive info


Plans for API clients in Python

What kind of request is this (question/bug/enhancement/feature request):
A question.
Steps to reproduce (least amount of steps as possible):
No steps per se, unless you try running the example in this issue.
Result:
NA
Other details that may be helpful:
While Rancher's Golang type definitions could theoretically be used to build a bare-bones Golang client, I'm wondering if there are plans to either extend and support the client-python package, or perhaps create a new client. To that end, I've seen threads about the possibility of an OpenAPI spec - I'm wondering if that's on the cards too.
While the Rancher API is a beauty to look at - I suppose the ease and convenience of a native wrapper library always does end up sounding far more attractive. If there are no existing plans for such a client(atleast in Python), then I'd definitely like to give it a stab.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): NA
Installation option (single install/HA): NA

https://github.com/rancher/client-python ?

I've mentioned client-python above. Sadly it doesn't seem like it's maintained.

Sorry, late.. it's a completely dynamic client that works with any of our APIs; there's little to nothing to "maintain".  We use python and that client for automated testing ourselves.

Ah, I see. That’s beautiful. Thanks for clearing this up! Closing this issue now.


Not working with Perl script

Hi
I wrote perl with Bracket-Pair-Colorizer and found a bug.
When I make hash with curly brackets and use m as a key of it, didn't colorize properly.
I show an example below.
code
my $hash = {
    s => {hoge => 'huga'},
    v => {huga => 'hoge'},
    o => {fizz => 'buzz'},
    m => {buzz => 'fizz'}
}

screen shot

I don't have any idea but somehow related to regular expression?

Getting something similar
Perl regex
sorts itself out again when at the end of the function


WIP: MNT: Re-render the feedstock

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (0.10.3) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Selectors are suggested to take a <two spaces>#<one space>[<expression>] form.

Linter error here is the same as in this issue ( https://github.com/conda-forge/glpk-feedstock/issues/6 ). Will ignore for now to get this updated.

This cannot be merged yet. I have pointed out the problem above. I doubt this is related to the selector, but if it is we need to fix that first.

Agreed, this should not be merged. The Python selectors are needed to produce the three vc variants of the library.  Is the lint the reason why smithy is trying to remove the selectors?

Nope, the even correcting the lint, conda smithy rerender still removes the Python selectors.

After looking at the recipe closer, I believe the problem is we are not including python as a build dependency on Windows.

I seem to recall there was some reason for not including python as a build dependency on Windows when the recipe was in staged-recipes but I can't recall the reason now.  Let me try adding that to the recipe and see what happens.

Not seeing a problem with including Python as a build dependency on Windows (PR #9) so might as well include it.

Yay! This is the usecase I have wanted to solve for some time now. Basically, I'm inclined to add vc knowledge to the build matrix, make vc a build dependency (on windows), and remove the features noise that comes with all of these compiled C packages on Windows.
I'd merge #9, close this, then we can see how the new scheme would look in a few days.


how do we convert thermal.json file to train.txt file for training?

I pass the arguments with folder path and output path. but it says invalid argument. it is like this.
python3 convert_coco_yolo.py --path gu (gu = folder name that contains .json file)  --output_path out_p (out_p is the output folder name)

Hi,
Try this way as those arguments aren't optional.
python3 convert_coco_yolo.py gu  out_p

@enesozi sure. so the 'gu' folder has 'annotated_thermal.json' file. I want to convert it to .txt to train it on YOLO.

I tried with the command you mentioned. it gave me an error saying
Traceback (most recent call last):
File "convert_coco_yolo.py", line 25, in
image = data['image']
KeyError: 'image'


remove broken link under Examples

remove 'Starter Application with JWT Auth + sample backend API in Laravel'

@talkor thanks, but this fixed in https://github.com/vuejs/awesome-vue/pull/2943


adding ManagedAvailability Troubleshooter

Hi @jcoiffin. We do not declare any authors in the script. Please remove. You should also add comment-based help keywords at the beginning of the script.
More information: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comment_based_help?view=powershell-7.1#comment-based-help-keywords

And you should also create a documentation of the script and place it under docs https://github.com/microsoft/CSS-Exchange/tree/main/docs

I updated the comments.
the documentation will come in a later PR.


Test runner

Overview
Initial work on a browser based test runner. (From discussion in #81)

Adds a grunt test task, which is like grunt dev but for the test runner. The build target is build/test.
Adds the following directories:

src/js/test is where the code for running the tests goes
src/js/test/views/html/main.js is the view for the test runner app
src/js/test/tests is where we should put tests
src/js/test/tests/operations is where we should put tests for different operations (mimicking src/js/operations

Adds src/html/test.html which is built into build/test/index.html.

Demo
Clone this repo, run grunt test, navigate to build/test/index.html, you should see this:

Test structure
A sample example test that just checks input/output and does not expect an error is:
    {
        name:"Fork & Merge nothing",
        input: "",
        expectedOutput: "",
        recipeConfig: [
            {
                op: "Fork",
                args: ["\n", "\n", false],
            },
            {
                op: "Merge",
                args: [],
            },
        ]
    }

It checks if expectedOutput === result.
A sample example test that expects an error is:
    {
        name:"To Base (error)",
        input: "a",
        expectedError: true,
        recipeConfig: [
            {
                op: "To Base",
                args: [16],
            },
        ]
    }

If it runs this and gets an error, it passes. If it runs it and doesn't get an error, it fails.
HTML app structure
I have added VueJS as a dependency but only for the test runner, not for the built app. This explains the changes of var jsFiles = [... in Gruntfile.js. VueJS is a pretty useful but minimal piece of kit that has reduced the # of LOCs required to build this prototype considerably.
For now all of the component templates (3 of them) are just kept in src/html/test.html as well as the main app template. I don't foresee us needing too many additional components and this simplifies the build process considerably.
A potential downside of adding VueJS is that it is adding a new framework into the mix and it is yet another thing for people to learn before being able to contribute. The counterargument to this is that no knowledge of the inner workings of the test runner is necessary to add a test.
(We could even add a task to the Gruntfile to generate the boilerplate code necessary for adding an operation: it would create an operation file and a test file with a sample test inside.)
If VueJS is unnecessary then I can remove it, but given that is only in the test runner I don't think that constitutes a violation of "Design Principles 3/4". I think it is more akin to using Grunt, it is a tool that few people will need to touch, but speeds up a core part of the development process without affecting the finished CyberChef app.
Possibility for headless
All the arguments in favour of VueJS are equally applicable to PhantomJS or a similar headless solution. It wouldn't be any easier or more difficult to make this a purely headless grunt test task with terminal output rather than an in-browser solution. If consensus is in favour of headless rather than browser then I am confident I can rework it quickly.

Hi @tlwr,
This looks really great and I'm glad you're thinking carefully about the design principals as you write it. I've chatted this over with a colleague and we have some thoughts - I'd be interested to hear your opinions too.

We think this might work better as a headless service running in node. The HTML interface you've written for it looks really good, however it might be more functional to run a console version which can be integrated into the grunt prod build process. I don't think this would require PhantomJS as that seems to focus on emulating browser interactions and all we're trying to achieve at the moment is the testing of operation outputs. Most of the code you've written could remain unchanged - the HTML would just be replaced with a simple node app running each test in turn, which could be called by Grunt.
I'd prefer the src/js/test/ directory to be moved up to the project root, i.e. just test/ so that we don't end up nesting too far. It seems that this is the convention used by several other large JS projects.
Your idea for a Grunt task which creates a new operation template complete with tests is really good.

I'm not at all against using Vue.js or PhantomJS on the grounds that they add bloat - if they are the best solution, we'll use them. However in this case I think we can keep it quite lightweight and just use the TestRegister you have already built. It doesn't need to be complicated, it just needs to run recipes over inputs, which you've already implemented. Thoughts?

The more I turn it over in my head the better a headless option sounds.
Completely agree about moving the test directory into the project root, and integrating the test runner into grunt prod would be very useful.
A headless service running in node seems like a simple and pragmatic solution, my only concern is the case where operations (or the libraries that they depend on) use Browser APIs that are not supported in node. The solution here would be to use a headless browser.
Also while we're at it, it might be worth considering a fully fledged JS test runner (either node or headless browser).

In 3a90244 I have quickly prototyped out a headless test runner using PhantomJS:

Moved all the tests to test/tests/.
Moved all the testing code to test/.
Added test/TestRunner.js.
Added test/PhantomRunner.js.
Added test/NodeRunner.js.
Modified grunt prod task to run the test task.
Added dev dependency phantomjs-prebuilt.

Tests are done exactly the same as before, they are registered into TestRegister. I have moved the functionality from the test running view into test/TestRunner.js (it runs the tests using TestRegister.runTests(), and reports them to PhantomJS.
The file in src/html/test.html is built into build/test/index.html is the actual HTML file viewed by PhantomJS, (it imports the concated JS files).
test/PhantomRunner.js navigates to the built test file, formats, and then reports the test results.
test/NodeRunner.js is the actual node entrypoint. It finds the PhantomJS path (from dev dependency phantomjs-prebuilt) and runs test/PhantomRunner.js.
The grunt test task runs the tests:
No errors:

Example errors:

Great work once again. I've made some small changes but it's largely as you wrote it. Over time this will  be expanded and possibly replaced by something more comprehensive, but for the moment we're really only interested in operation testing so it will serve us well.


Slurp profile

The other goal that can be started is the experimentation of a get_profile function or similar in fileutils that would slurp the entire profile into memory. I'm sick of not being able to have direct access to the data in memory if I'm sure it will fit, and having a function like this would be helpful for experimentation with the similarity metrics.

The rarefaction branch completely addresses the use case of reading entire profiles into memory. The .slurp() method now returns the profile as well as sets it (on first run, additional runs are untested but possible if the pointer is set correctly.

The rarefaction branch completely addresses the use case of reading entire profiles into memory. The .slurp() method now returns the profile as well as sets it (on first run, additional runs are untested but possible if the pointer is set correctly.


BUILD(shell script) files misclassified as Python

The files named "BUILD", which are shell script, are misclassified as python.
link:https://github.com/eltanin-os/port

Is that a private repository? We can't access private repositories. Do you have a public example?

It's a typo... it should be https://github.com/eltanin-os/ports
The reason this is happening is because the Filename classifier, which takes specific filenames directly associated with a language in languages.yml, takes precedence over the Shebang classifier at https://github.com/github/linguist/blob/d968b0e9ee5cc0c1dcbb181a3f139bd43751b658/lib/linguist.rb#L60-L67
As a result the BUILD filename which is associated with Python at https://github.com/github/linguist/blob/d968b0e9ee5cc0c1dcbb181a3f139bd43751b658/lib/linguist/languages.yml#L3594 is being used to classify the file.
To get these files identified as shell you can either add a modeline entry to each file (PITA) or set a language override in your .gitattributes.

I tried first to write: BUILD linguist-language=Shell in .gitattributes as i thought it would classify any file with that name as a shell script. I may have missed something, but i did not understand how to set the language with the .gitattributes.


Inform of dup challenge name immediately when creating challenge

When creating or editing a challenge, the user isn't informed until the end of the process if the challenge name is a duplicate of one that already exists. It'd be nice to be informed of that up front when the challenge name is entered.

Closing due to age.


Add changes for 0.1.1 and 0.1.2 to CHANGELOG

Current coverage is 94.32%

Merging #18 into master will not affect coverage as of abe58c3

@@            master     #18   diff @@
======================================
  Files           57      57
  Stmts         1586    1586
  Branches         0       0
  Methods          0       0
======================================
  Hit           1496    1496
  Partial          0       0
  Missed          90      90

Review entire Coverage Diff as of abe58c3

Powered by Codecov. Updated on successful CI builds.


Monitor can't get mining status 3 days ago

Hello Jonian,
I like this AWmonitor page, because it's best of displaying the mining status. But 3 days ago until this present, the monitoring can't get update anything. Can you check or fix it?
Regards,
Tivgnos

Hi @tivgnos, there were some api issues with AtomicHub. They are fixed now. Do you still have problems.

Hi @jonian, Yes, can't retrive data.

AtomicHub

Hi @jonian How can i do? I try to cleared cache and add .wam again. But still can't get update anything.


t.resolve to assert resolved promise

Ok so we have t.reject to assert that a promise (or promise-returning function) rejects, but no t.resolve.
Is there already a preferred way to assert that a promise resolves?

I'd be fine with adding a t.resolves, but in the mean time, you can either just await the promise (in node 8 and above) or return it from a subtest.
const p = somePromise()
t.test('resolves', t => p)

Added in v11 branch, t.resolves(promise) and t.resolveMatch(promise, pattern) landing in the next major.

Awesome that was quick!

Well, it'll be a while before v11 is done, but sure, you're welcome, glad you're happy about it :)


Setting valid on control using mask

Hi all. I have a mask now working on an input control which is using an NG_VALIDATOR but if the input does not match the mask the valid/invalid options not being set in the form control. Thus;
public validate(c: FormControl): any
c return that the input field is valid.

Could you post an example plunkr so we could have a look?

I'm gonna close this, as it is old/stale..


Hotfix oauth defaults

Another excellent PR... You're on fire. I almost feel bad about asking this, but could you add tests to prove this works?

tricky. becomes apparent when first linking google and the facebook. google options added 'scopePrefix' to the default which carried over to facebook lets it fail. but i'll try to think of something

there is no authorize test of sorts yet as i see it. i guess it'll need a dummy provider to test authorization. that's slightly over my head. while eager to learn, i think i'll have to leave that to you (unless you give my very good starting instructions)

maybe we can copy some from https://github.com/sahat/satellizer/tree/master/test

That might be a good idea. We can also set up a test server in the test setup (like I did with ORM).

already had a look there. would be nice though if we could connect to facebook / google itself for realy proper testing. i googled for some public facebook account we could use, but seems there isn't any. maybe set up facebook/google accounts for testing?

a spoonx test app or so?

fyi: didn't have much time, but i'm still on adding tests

No worries. I appreciate all your help.


Site recovery on-premises hardware requisites

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-azure-deploy-configuration-server
i dont fully understand what are the requirement for the configuration server or process server
firs there are some prerequisites and then some Sizing and capacity requirements which one to follow?
first on prerequisites section  seems need three disks but not mentioned OS disk size
later on Sizing and capacity requirements section need only cache disk

@paulfinol Thanks for your comment! We will review and provide an update as appropriate.

@paulfinol Answered your queries here - https://docs.microsoft.com/en-us/answers/questions/299403/site-recovery-process-server-configuration-require.html?childToView=301099#comment-301099
Feel free to ping with further question. If none, we should be good to close this issue.