merge from arlac77/template-github,arlac77/template-kronos-module

package.json

chore(package): add ^3.8.2 remove ^3.8.1 (devDependencies.ava)

Codecov Report

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

@@            Coverage Diff            @@
##            master     #1316   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           28        28
  Branches         1         1
=========================================
  Hits            28        28

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 811e444...74101af. Read the comment docs.


Add deviation for Decap NH with NextHopNetworkInstance

Pull Request Functional Test Report for #3406 / 02c35b355509035caa13ff65c492a3e79aa6ae9d
Virtual Devices

Device
Test
Test Documentation
Job
Raw Log

Arista cEOS

TE-14.2: encap and decap scale
19d6b0a2
Log

Cisco 8000E

TE-14.2: encap and decap scale
342c9c3d
Log

Cisco XRd

TE-14.2: encap and decap scale
a05f7530
Log

Juniper ncPTX

TE-14.2: encap and decap scale
0b93cdb9
Log

Nokia SR Linux

TE-14.2: encap and decap scale
12a07982
Log

Openconfig Lemming

TE-14.2: encap and decap scale
8b6f9fd4
Log

Hardware Devices

Device
Test
Test Documentation
Raw Log

Arista 7808

TE-14.2: encap and decap scale

Cisco 8808

TE-14.2: encap and decap scale

Juniper PTX10008

TE-14.2: encap and decap scale

Nokia 7250 IXR-10e

TE-14.2: encap and decap scale

Help

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.252%

Totals

Change from base Build<PHONE_NUMBER>6:
0.0%

Covered Lines:
1983

Relevant Lines:
3589

💛  - Coveralls


New interpretation type for events: Captioned

We have a new interpretation type for events: Captioned.
Alice has set up the eventPolicy in Prismic, but we need to add the closedCaptioning icon to the policy, so she can then use it the same as BSL, STT and AD.

closedCaptioning icon is at https://cardigan.wellcomecollection.org/?path=/story/global--icons


【beginner question】The loss should get larger or smaller? Thank you.

@lucidrains Thank you!

smaller, if x and y is same, the cosine similarity x*y is 1


Link header

Enhancemet #760  Add simple link header with URI-reference only for now. Add test with such header.

This is a good start.
I don't know much about the Link header, but from skimming the RFC linked to in the issue, it seems the parser is a bit too simplistic, and will fail on most of the examples from the RFC.

sure, I have to put WIP status
Also I am going to add a few link params within the current PR, using the RFC what you mentioned
Link           = "Link" ":" #link-value
  link-value     = "<" URI-Reference ">" *( ";" link-param )
  link-param     = ( ( "rel" "=" relation-types )
                 | ( "anchor" "=" <"> URI-Reference <"> )
                 | ( "rev" "=" relation-types )
                 | ( "hreflang" "=" Language-Tag )
                 | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )
                 | ( "title" "=" quoted-string )
                 | ( "title*" "=" ext-value )
                 | ( "type" "=" ( media-type | quoted-mt ) )
                 | ( link-extension ) )

Sorry, now it was my turn to miss a notification.
This failure is not obvious to me, but I strongly suspect it's related to the problem described in #1651.  If a URI doesn't round trip through the parser as the same structure, then the header containing them will also have problems.  I think if we fix that, this will also begin to work.
Yet another reason we need to fix our Uri type. :(

_Sent from my Galaxy Tab A (2016) using FastHub

Wow, this one fell off the radar.  I'm so sorry.
The proper fix depends on fixing our Uri, but we've been busy with fs2 and cats-effect.  Is this something that we could mark the tests pending and get the header?


Adding preconditioner to idrs

Here I added Pl preconditioner to idrs add tested it with IncompleteLU preconditioner.

Nice! Did you follow literature or is it just clear how to add the preconditioner here? Pinging @astudillor, can you also have a cursory look?

Nice! Did you follow literature or is it just clear how to add the preconditioner here? Pinging @astudillor, can you also have a cursory look?

hahaha
I followed the Matlab Code referred in the docs because I found idrs performs better  than gmres in my work~

Haha, you can also compare with https://github.com/astudillor/idrs/blob/master/idrs/idrs.py

Haha, you can also compare with https://github.com/astudillor/idrs/blob/master/idrs/idrs.py

Thank you for your help~
I think they are the same after checked the idrs.py~
I'm so happy since it's my first time to do a little work on git~

Great. Can I ask on what type of problem you are working such that IDR(s) beats GMRES?

Great. Can I ask on what type of problem you are working such that IDR(s) beats GMRES?

It's a badly conditioned matrix equation on Computational Electromagneticcalled EFIE~

Pull Request Test Coverage Report for Build 842243156

0 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.2%) to 96.29%

Totals

Change from base Build 669197700:
-1.2%

Covered Lines:
1713

Relevant Lines:
1779

💛  - Coveralls

Pull Request Test Coverage Report for Build 842243156

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-1.2%) to 96.29%

Totals

Change from base Build 669197700:
-1.2%

Covered Lines:
1713

Relevant Lines:
1779

💛  - Coveralls

Great. Can I ask on what type of problem you are working such that IDR(s) beats GMRES?

It's a badly conditioned matrix equation on Computational Electromagneticcalled EFIE~

Well it seems to be a problem of problem of setting on preconditioner. GMRES is still the best solver after I corrected it.


seems google broke this(kinda)

only works sometimes here is my code
`import googletrans
from googletrans import Translator
translator = Translator()
langs = translator.detect(['한국어', '日本語', 'English', 'le français'])
for lang in langs:
print(lang.lang, lang.confidence)`
output

Duplicate of #234

Glad I'm not the only one who's experiencing this.. Found any fixes or alternatives? :/


Suggestion: Config to disable the enabled / disabled popup

Everytime I load into a world this popup shows and it is irritating, the mod is very cool but I do not wish for this tooltip to show everytime someone loads into a world.

Yeah, I think I can do that.


Fix Scala ArrayBuffer cast to Spark ArrayData for Scala 2.13

Closes #688
Fix problem with cast scala.collection.mutable.ArrayBuffer to org.apache.spark.sql.catalyst.util.ArrayData

Hm, I don't think it's quite that simple unfortunately - it causes some test to fail.
I'm not totally sure why. It seems like building an Array this way doesn't quite work, ends up with 1 element not 3 for some reason, when 3 should be the result of the array xs_any column.
It may be that you have to try returning an array later somewhere, I'm not sure.
We'd also have to make a change in spark to match this, as the code really lives there now, but that's for later.

Hm, I don't think it's quite that simple unfortunately - it causes some test to fail. I'm not totally sure why. It seems like building an Array this way doesn't quite work, ends up with 1 element not 3 for some reason, when 3 should be the result of the array xs_any column.
It may be that you have to try returning an array later somewhere, I'm not sure.
We'd also have to make a change in spark to match this, as the code really lives there now, but that's for later.

Okay) I really bad in Scala. After that errors I know my target on future :) I think problem in immutability Array type. I think that problem need harder solution, but we can try start tests and dream about success)

@srowen Hello! Can you run tests, please? Thank you in advance!


Can't run any Mac releases after 0.10.4, Mac OS X says "app is damaged"

Expected behavior
Application runs.
Actual behavior
Mac OS shows message box
“Kitematic (Beta).app” is damaged and can’t be opened. You should move it to the Trash.
and offers to move app to Trash
Information about the Issue
I've tried 0.12.0, 0.10.5 and 0.10.4 from https://github.com/docker/kitematic/releases , *-Mac.zip
Tried to re-download few times, tried built-in unarchiver, 3rd party archive manager, WinRAR in Windows VM. Same result.
OS X El Capitan, 10.11.3
Steps to reproduce the behavior

Download https://github.com/docker/kitematic/releases/download/v0.12.0/Kitematic-0.12.0-Mac.zip from https://github.com/docker/kitematic/releases
Unpack it to get "Kitematic (Beta).app"
(optional, doesn't affect result) Move app to Applications
Double click app OR Right click - Open OR Launch from Spotlight
OS shows "app is damaged" window

This is a duplicate of a previous issue.
https://github.com/docker/kitematic/issues/1637#issuecomment-210924052
For unknown reason, OSX attrs are added to certain downloads, see:
http://apple.stackexchange.com/questions/129966/files-wrongly-considered-as-damaged-in-encfs-volume
To solve it, run:
xattr -rc /Applications/Kitematic\ \(Beta\).app

A reboot and re-download can show a clean download as well.


Add on_linux_and wrapper to OnSystem

As discussed in https://github.com/Homebrew/homebrew-core/pull/105149#discussion_r914939560, we need an OnSystem wrapper to handle the case of "do this thing on Linux and also on these macOS versions." Before, this was handled because MacOS.version <= :sierra was always true on Linux. Now, to avoid duplicating parts of formulae, we need a way to express this condition.
There were several ideas on how to represent this:
on_linux_and :sierra_or_older # This is the one I chose to start off with in this PR
on_linux_and sierra: :or_older
on_os :linux, :sierra_or_older
on_os :linux, sierra: :or_older
on_os :linux, macos: :sierra_or_older
on_system :linux, macos: :sierra_or_older

For now, I chose the first one since it is both similar to the existing on_{system} block style while not requiring too many parameters/symbols. However, I'm definitely open to implementing other options if those are preferred.

Review period skipped due to critical label.

Thanks for the PR @Rylan12!

on_os :linux, :sierra_or_older
on_os :linux, sierra: :or_older
on_os :linux, macos: :sierra_or_older
on_system :linux, macos: :sierra_or_older

My preference would be any of these with a mild preference for the fourth.

on_linux_and :sierra_or_older # This is the one I chose to start off with in this PR

What I don't like about this is the syntax highlighting makes it look like the linux is somehow "more important" than the sierra_or_older.

Other options (in case people like them more) would be on_multiple_systems, on_multiple_os (to make clear it's multiple), on_all_system, on_all_os (to make clear it's all and not or), on_platform etc.
CC @carlocab for thoughts on original proposals and above names.

When it comes to things I like this. I always think: what would be best if we were to theoretically add a 3rd OS tomorrow?
Not that it would necessarily ever happen, but it generally makes the semantics better or more "correct" if consider it that way.

I prefer on_system the most.
Compared to on_linux_and:

it's much nicer to read (and, as Mike points out, the syntax highlighting is better)
the method name just makes "more sense" -- a method name that ends in and feels a bit confusing. It also seems to require retaining on_macos and on_linux, when I think what we really should have is a generic interface to avoid having developers confused about whether they need a single on_linux_and or two separate on_linux and on_macos blocks.

Compared to on_os:

on_system will help us avoid/minimise future refactorings in case we find we need an on_* block for Intel/ARM too. We might not need this yet, so we don't necessarily need for on_system to understand arch arguments, but I suspect we will at some point.

Thanks, good points by everyone. If there are no objections, I think I'll go with on_system:
on_system :linux, macos: :catalina_or_older do
  ...
end

on_system :linux, macos: :mojave do
  ...
end


[azeventhubs,azservicebus] More recovery fixes

Fixes for both EH and SB
For EH:

SB was already recovering the connection, even on cancellation. When cancelled it closes the connection, which is great since that sets up the next call to recover it. Ported that in here as well.

For SB, bringing in some fixes to match azeventhubs:

NegotiateClaim has a timeout when closing and handles returning the right kind of error from the underlying link
amqpLinks now sets an overall maximum timeout for recovering a link and connection. It also handles "upgrading" to a connection level recovery if we fail to cleanly close a Receiver or Sender.

/azp run go - azservicebus

/azp run go - azeventhubs


Hacktoberfest Examples: Updating Documents Stored In Redis

Updating Documents within Redis with Redis OM .NET is something that comes up a lot. There are two basic ways to do this, with Update and with Save methods of RedisCollection. Examples for each of these methods I think would be quite helpful for folks.
See #217 before Starting.
If you’d like to work on this please mention me @slorello89 or @SuzeShardlow in a comment and we’ll assign this issue to you.
This is part of our participation in Hacktoberfest 2022. Learn how to complete this issue here: https://redis.io/community/hacktoberfest/
Need help or want to talk to us? Join us on Discord where we have a dedicated Hacktoberfest channel

Hey there @slorello89 and @SuzeShardlow - I'd love to work on this if it is still available. Thanks in advance!

Hi @atrievel, I've assigned this to you, looking forward to seeing your PR in the next couple of days. Have fun and please check out our guidelines:
https://redis.io/community/hacktoberfest/
#217

Hi @SuzeShardlow / @slorello89  if possible I would like to work on this. Is it ok for @atrievel ?

@atrievel how are you getting on with this?

Hey @SuzeShardlow, I didn't see the original notification that assigned me. Should be done shortly now that I know I can work on it


New function for slug flow bubbles.

bubble_velocity_free could be used to calculate velocity of bubbles rising through a fluid, where the fluid properties are given. This function can also handle slug flow bubbles which the previous bubble_velocity function lacked.
Never written in .rst before so that may require further review.
Table below highlights the basis of calculation.

If anything is missing please let me know.

Woo hoo! You're the first person to make a Pull Request! I was starting to wonder if anyone would ever contribute to the project. Thank you. Now back to your Pull Request...
In your image of equations there's a range of applicable Reynolds numbers (Reb) but in the terminal velocity column I only see Rb. Is Rb supposed to be Reynolds number Reb?

Hi, thanks getting back so fast. I hope the changes are useful.
In the terminal velocity equations we use R_b which is the bubble radius; Re_b is the Reynolds number which is only used to define the flow regime (region) and as such doesn't appear in the terminal velocity equations.
To avoid confusion it might be worth changing some of the nomenclature of radius from R_b to r_b?

Ok, I see now. If this is the same nomenclature as used in the original reference then I would not make any changes to it.

I'm happy to leave it as written then.
I'm happy with the python code so far but have you had the chance to review the docs file also?

I haven't run the code or looked at the documentation yet. I'll do that tonight.

That's sounds great. This is my first time contributing here on github so I'll gladly receive any feedback!

Do you have a link to the article that you reference in the docstring? I would like to read the article to get a better understanding of your code.
    References
    ----------
    [1] Peebles, Fred N. ; and Garber, Harold J. : Studies on the Motion of
    Gas Bubbles in Liquids. Chem. Eng. Progr., vol. 49, no. 2, Feb. 1953,
    pp. 88-97.

I'm currently seeing some technical difficulties in accessing my online library. The primary source is from the AiChE "Chemical engineering progress" which is not fully digitised and as such access to the original paper may be somewhat limited.
As soon as I get access to my library resources again I'll try and find the original article, or failing that I'll point you towards a suitable secondary source.

Sorry to be so picky about this but I want to make sure the equations in the original article match your code (especially for such an old article).
Did the table of equations you provided above come from the original article? In that table, why is ub labeled as terminal velocity but you refer to ub in your code as bubble velocity?

I completely understand your worries, I'll sort out the source material for you.
In my code bubble velocity and terminal velocity have been used synonymously, where u_b is the terminal velocity of the bubble. I will change this so that it remains consistent throughout.
So I have a few actions to work on, to summarise:

Forward the original article to you.
Change the terminology used for u_b to make it consistent

Anything else you have picked up on?

I may have found someone with a copy of the article. They said they'll let me know later this week.
An issue I found with the code is that the ubrf() function needs to be added to __init__.py so it can be properly used with the Chemics package. Here's some background on packages in Python: https://docs.python.org/3.8/tutorial/modules.html#packages

That sounds like a good lead, I will contact the professor who delivered those slides and try gt a copy of the article.
Thanks for the notice on the that second point. I'll put it in.

Hi, I've reviewed my old fluid mechanics books and found a reference to the original source. It was found in "Fluid flow for chemical engineers" 1995 by Holland and Bragg, Chapter 7, p234.
It appears the correlations for the regions 1-4 was taken from Peebles and Garber whilst Region 5 was later added by Wallis (1969). I will update the docs accordingly.
I will gladly forward the whole chapter to your email address if you want to read further on the subject.

I have access to the "Fluid flow for chemical engineers" book. I'll look at it tonight and give you another update once I've read the chapter 7.

So I read the section in Chapter 7 related to this pull request. What I'll do is incorporate your work into the bubble_velocity module that is currently in Chemics. The module will have two functions ubr_kunii and ubr_holland. The ubr_kunii will be what is currently named ubr and the ubr_holland will be what's in this pull request. To do this I'll need to make even more changes to Chemics so I created a new branch in the repository called bubble-velocity. Please update your pull request to merge into the bubble-velocity branch instead of master branch. Here's a short demo of how to do this:
https://github.blog/2016-08-15-change-the-base-branch-of-a-pull-request/

That sounds excellent, I'll work towards finishing that.

This looks good. Thank you for the contribution. I'll merge this request into the bubble-velocity branch and continue working on it. I will merge everything into the master branch later this month as part of v20.5 of the package. If I have any more questions I'll create an Issue and tag you in the conversation.

That's great! Thank you for your help in getting it implemented.

@Norvell-git Just want to mention that your first table of equations has a typo. The ub for Region 4 should start with 1.18 not 1.53.

Oh wow, well caught on that one. I'll make changes to it today

I already fixed it in the bubble-velocity branch.

That's great, thank you!


Syntactic sugar for retries.

Thanks for a great library!
Would you be open to a PR that allowed policies to take Future[T]s by-name? This would be in addition to the () => Future[T] option offered now.
This would let clients write:
retry.Directly(3) { attemptSomething() }

instead of
retry.Directly(3) { () => {
  attemptSomething()
}}

I believe I can do this with a small addition to the Policy trait and with no breaking changes.

Went ahead and played with it, turns out a bit of a hack is required to preserve backcompat given the way type erasure works. My attempt here: #12.

Fixed with #12.


Update 04-create-schema.md

Addressing proposed changes in #41
Cherry picking changes from #42

@ymgan do these changes look right?
https://github.com/ioos/bio_mobilization_workshop/pull/43/files

Thanks Mathew! The changes look right! I spotted 2 more outdated links and commented at that line~
Thanks a lot for your hard work!


⚠ Nextcloud has degraded performance

In f93bd10, Nextcloud ($URL_NEXTCLOUD) experienced degraded performance:

HTTP code: 502
Response time: 6646 ms

Resolved: Nextcloud performance has improved in f2765c2.


Added the Antman rebus

Summary of Changes

Added Rebus: Antman

Pull Request Test Coverage Report for Build 1006

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 87.143%

Totals

Change from base Build 937:
0.0%

Covered Lines:
158

Relevant Lines:
180

💛  - Coveralls


[BUG] A very strange and hard to reproduce bug about 'fltk::app::Screen::num_at'

Hello, I'm here to ask a question again, I've searched for some keywords (screen/number/screen num etc) but can't seem to find relevant discussions.
I am currently working on a small tool for screenshots, but I found that sometimes (very rarely) the position of the mouse click does not match the actual drawn area, and then I found this strange situation.
The following is the scene where I found this problem. I don’t know if you can reproduce it, because the abnormal points seem to be relatively small

I have three monitors arranged as follows

screen1: 1920x1080 (150%)
screen2: 2560x1440 (100%) primary
screen3: 1920x1080 (100%)

// I use the following code to get the `xywh` of the screen list:
for count in 0..fltk::app::screen_count() {
    println!("{count}: {:?}", fltk::app::screen_xywh(count));
}

// and get:
// 0: (424, 960, 1280, 720)    => screen1
// 1: (0, 0, 2560, 1440)       => screen2
// 2: (2560, 352, 1920, 1080)  => screen3

When I used fltk::app::Screen::num_at, I found it very strange. I used the following points to test, and found that some were normal and some were not.
// All points are on the screen with screen_num=1
let points = vec![
    (0, 0),
    (0, 1439),
    (2559, 0),
    (2559, 1439),
    (1450, 933),
    (1357, 1099),  // x
    (1357, 331),
    (1323, 1241),  // x
    (23, 234),
    (23, 1099),
];

for point in points {
    println!("point: {point:?} => screen_num: {}", fltk::app::screen_num(point.0, point.1));
}

I don't know why some points get screen_num = 0 but most of them are correct. These points are all in the bounding box (0, 0, 2560, 1440), so it should be 1.

I don't have a multi-screen setup, but I've created a repro of your code here in C++:
https://github.com/MoAlyousef/screen_rep
Can you git clone it and run the build instructions in the README.
If you get the same error, can you report it to https://github.com/fltk/fltk

Hi
I wanted to check in on this issue, Were you able to reproduce using the repro code?

Hi I wanted to check in on this issue, Were you able to reproduce using the repro code?

Sorry, last week I was a little busy at work and rushed to the product launch and almost forgot about it, but luckily you reminded me!
I don't know much about c++ (even cmake is installed according to online tutorials), I think the third item here should be to execute main.exe in the Debug directory on the left.
The output of the program is shown in the figure, it seems that this is a problem with fltk rather than fltk-rs. In this way, should I copy the content of this issue to the fltk project?

If you have any further testing needs, you can contact me at any time, sorry for forgetting this before. /(ㄒoㄒ)/~~

Hi I wanted to check in on this issue, Were you able to reproduce using the repro code?

Sorry, last week I was a little busy at work and rushed to the product launch and almost forgot about it, but luckily you reminded me!
I don't know much about c++ (even cmake is installed according to online tutorials), I think the third item here should be to execute main.exe in the Debug directory on the left.
The output of the program is shown in the figure, it seems that this is a problem with fltk rather than fltk-rs. In this way, should I copy the content of this issue to the fltk project?

If you have any further testing needs, you can contact me at any time, sorry for forgetting this before. /(ㄒoㄒ)/~~

I noticed that it forgot to use the count here, and it got all the parameters of the same screen (but this has no effect on the current discussion issue)

Yeah it would be better to open an issue in the FLTK repo with the C++ repro code in hand, also explaining your setup. The devs there will probably ask you more questions on your setup or your system to understand where the issue lies.


make the width of the tip border customizable

What's Changed
Tip Border Size
Before you could only customize the color of the border of the tip. Now you can control the width of the border as well.

Coverage remained the same at 72.609% when pulling 8445c177c9231bb26a2620d2840ac8d2e6df84f0 on tip-theming-bug into 33bc1487a3f8d6948c160b1c986e3e5e9542df95 on master.


Adding LogDNA

Adding LogDNA to the lists.

@QuinnyPig, @maishsk, @silviabotros, @M1ke, can you please take a look at this Pull Request? Thanks in advance!


archive.txt src and filtering

Hi @benjamonnguyen,
And thanks for your work with this plugin, it's really great.

Can we define source/src for the archive.txt file? Not sure if I'm doing it wrong, but it seems it gets created to the root Obsidian folder and there's no way to define the source. I'd like to "hide" it under certain subfolder e.g., the same where my todo.txt file is.

Any ETA for the filtering option? I would like to use only one todo.txt and using this todotxt-codeblock on a project page where I would only like to display "+ProjectX" shows all the contents. Collapsing is an option but when I introduce new projects I would need to collapse everytime.

many thanks for you work

@krisudo thanks for the suggestions!
I'll get right to adding configurable archive.txt path.
As for the filter option, can you give me a concrete example of your usage?
The way I'm understanding it is that you have a single todo.txt file that you link to all your codeblocks, and you'd like to filter specific projects per codeblock.

Hi @benjamonnguyen,
Archive.txt src- If possible, It would be great if the filename doesn't matter e.g, I could use archive file with filename "done.txt".
And the filter - exactly that. I have a single todo.txt I use in multiple codeblocks all over the vault. In certain notes would like to filter the codeblock to only show "+ProjectX" for example (this could be a project note). My own use case revolves around syncing the todo.txt via the Obsidian vault to mobile (iOS), and then using the same file with 2do.txt app. This app has filtering options also so I'm able to lookup tasks only to "ProjectX" for example. Again, you said it right and sorry for the messy request.
Thank you!


Add YAML-docs generation

This is a very quick 'n dirty implementation of the YAML docs generation;
copied from the docker/cli repository with some minor modifications and a
new Makefile target.
I'll open a PR in the documentation repository to verify if the output all works (similar to https://github.com/docker/docker.github.io/pull/8759); we should also

have a look at making the generating code generic enough so that we can just vendor it (instead of copying)
have a way to automate the yaml files in the documentation repository (perhaps be by pushing the docker image to hub)?

Example of the generated YAML files;
yamldocs.zip

/cc @bermudezmt

ping @chris-crone @silvin-lubecki PTAL; this is green now

Hmm what is this docs/reference/.keep file? 🤔

Right, so Git only stores files, not directories; the generator expects a directory containing Markdown files for the extended descriptions, which we currently don't have; we can remove that .keep file once there's some Markdown files in the directory

@usha-mandya as we've discussed previously, the extended descriptions and examples (when we have them) should live in the reference folder. @silvin-lubecki this is an example Markdown addition from @thaJeztah : https://github.com/docker/registry-cli/pull/47/files :wave:


Release 1.8.13

Add 'copy link' button to share the current AWS console page (thanks @mbourgeois-fetch)

Thx for accepting.  This feature release a couple weeks ago from AWS + this plugin fixes one of my major pain points with the identity center product.  I very much missed this when moving from a different AWS account management product at a former employer.


Charm builds broken on BG/Q with XLC

Original author: Nikhil Jain
Original issue: https://charm.cs.illinois.edu/redmine/issues/675

Compilation fails with following error:
../../../../bin/charmc -optimize -production   -I../../.. -c -o CkCache.o CkCache.C
"CkCache.h", line 371.5: 1540-0274 (S) The name lookup for "PUParray" did not find a declaration.
"CkCache.h", line 371.5: 1540-1226 (I) Declarations for non-dependent names are resolved in the template definition.
"CkCache.h", line 371.5: 1540-1227 (I) "PUParray" does not depend on a template argument.
"CkCache.h", line 374.5: 1540-0274 (S) The name lookup for "PUParray" did not find a declaration.
"CkCache.h", line 374.5: 1540-1226 (I) Declarations for non-dependent names are resolved in the template definition.
"CkCache.h", line 374.5: 1540-1227 (I) "PUParray" does not depend on a template argument.

Original author: Nikhil Jain
Original date: 2015-02-24 17:16:34

Needed explicit PUP namespace. http://charm.cs.uiuc.edu/gerrit/#/c/562/


Some known issues

I use this library, but

Search feature not working
autoSpacing also not workig
onError unable to catch protected file e.g. if (t is PdfPasswordException){}
Display page not fitted in centered

Please take a look these issue

This lib is still in development.
About search feature... If you want to highlight text on the page, use pdfView.setSearchQuery("Google");. If you want to parse text from the page, use pdfView.parseText(arr, new PDFView.OnTextParseListener(){}); where arr is array of int page indexes for parse text
autoSpacing is a development of the author of pdfView and I did not develop it. I don't use it. I am quite satisfied with spacing.

onError unable to catch protected.

What is happening at this moment? App crashes?

Display page not fitted in centered

Please, attach screenshot.

App not crashes, but before I catch protected file using onError this code if (t is PdfPasswordException){showDialogPassword()}.
Suggestion to you that please use CoroutineScope in DecodingRunner

Sorry for taking so long to reply, I have a lot of work to do...
Regarding the password, please send an example pdf with a password. I'll try to figure it out in my spare time.
I also updated the repository. Take a look at sample app. I made some changes and now everything should work. At the moment, in order to get page previews for your custom list, you need to add PdfView to your layout and call the desired callback.
For a full-fledged text search, you need to save all the text in the database using the pdfView.parseText method, then perform a search in the database. You can get the content using the getTableOfContents method. After that, you will have a good structure of the book in the database.
To highlight text, you must first assign a highlight color during pdfView initialization with the setTextHighlightColor method, after which you can call pdfView.setSearchQuery("Bla-bla-bla");

App not crashes, but before I catch protected file using onError this code if (t is PdfPasswordException){showDialogPassword()}. Suggestion to you that please use CoroutineScope in DecodingRunner

Sorry for taking so long to reply, I have a lot of work to do...
Regarding the password, please send an example pdf with a password. I'll try to figure it out in my spare time.
I also updated the repository. Take a look at sample app. I made some changes and now everything should work. At the moment, in order to get page previews for your custom list, you need to add PdfView to your layout and call the desired callback.
For a full-fledged text search, you need to save all the text in the database using the pdfView.parseText method, then perform a search in the database. You can get the content using the getTableOfContents method. After that, you will have a good structure of the book in the database.
To highlight text, you must first assign a highlight color during pdfView initialization with the setTextHighlightColor method, after which you can call pdfView.setSearchQuery("Bla-bla-bla");

I tested your code but pdfView.setSearchQuery("quisque"); is not highlight proper, screenshot is attached.
Please take a look this library. Selection text and search text working, but not like charm.

I tested your code but pdfView.setSearchQuery("quisque"); is not highlight proper, screenshot is attached. Please take a look this library. Selection text and search text working, but not like charm.

Yes, there are and will be problems, because it works like this:
pdfium gives us only the square of the first character of the line it found. I don't know why it's so idiotically done, but it's not up to me. It worked fine on other search queries, but something seems to be wrong with this one... I don't know the solution. If you find it, please make a request.

Last time I used this library, Selection Text and Search Text worked fine, but it requires more concentration. I would be proud to help you add things to this great library. But I go abroad for a job. So I probably won't be able to spend much time with programming until I'm fully settled there. But I will check GitHub regularly to see the issues.


Add custom account details title and instructions

Changes proposed in this Pull Request:

Add custom account details page title and instructions

Custom account registration details are passed into a <pxb-create-account> component through the accountDetails prop.   I've added pageTitle and pageInstructions onto this customization object.  If no title/instructions are provided, we default to the text found in the translations file.

do we have the ability to add an additional page to account details like we do with react workflow. Also wondering if we can match what we have in react and have a company field also...?

Code looks good. If you want to match the example fields from React as Jeff is suggesting that's cool, but we comment it all out before we merge it in anyway.

I've updated the 2nd page of the account details page to include the formfields from react.
The updated example can be seen here; https://pxblue-temp.web.app/auth/register/create-account


SSDO-0000 these should not be repo-ed event though have resources not…

… accessed in the past 6 months. The corresponding prod roles show them as used

 All committers have signed the CLA.


allow rspec 3

modified gem to support rspec 3:

changed gemspec dependency
updated spec tests : remove deprecated warnings by using the  new 'expect' syntax instead of 'should'

TODO : current HTML formatter should be converted to new rspec 3 syntax  ; For now added warning on installing rspec-legacy_formatters (https://github.com/rspec/rspec-legacy_formatters)

Coverage decreased (-2.59%) to 82.52% when pulling 6e1d487d44cf595fb305f2281999a16d1fa31090 on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-3.44%) to 81.67% when pulling 4ef042d52454d07e3c56d1d6338d2a0c203260fb on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-2.53%) to 82.58% when pulling 92cacfe2f8cde73aac2740b8f88f909b09322f0f on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-2.8%) to 82.32% when pulling 995ea9ef45731ea5367e3aa6068249a2f763ae3b on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-3.12%) to 81.99% when pulling df784e57d459fbcda531a722151c2fa98abd66b4 on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-3.12%) to 81.99% when pulling df784e57d459fbcda531a722151c2fa98abd66b4 on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-3.06%) to 82.05% when pulling 0a966b1f00287db4e372efa415de201cef4ada51 on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Coverage decreased (-3.06%) to 82.05% when pulling 8b11d9956f0d4f6b4f0e488b27968d2125b2b3b6 on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

What's the state of this PR? I've added some additional comments, but can see that you've made additional commits as well. Please, if adding other commits not directly related with RSpec 3, use a different branch or make a PR with a separate branch and close this one.

sorry jarmo, I did not see your comment from 5 days ago & already made additional changes/comments. I updated the original the original PR description to include all changes made.
IMHO all your change requests are done   +  everything seems to be working now (spec tests are green + then  new version works in my environment)
So I'm done  unless you have additional change requests

Coverage decreased (-2.95%) to 82.17% when pulling 4236e36fc17917c0ddefec276272aa659eb42dcb on pvmeerbe:master into 6d6aabbfa7e748c73ed1d8c8eefb0bbf7fd4d79e on watir:master.

Ran specs on my machine and still having two deprecation warnings:
Deprecation Warnings:

Using `should` from rspec-expectations' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` with `config.expect_with(:rspec) { |c| c.syntax = :should }` instead. Called from watir-rspec/spec/watir/rspec_spec.rb:18:in `block (3 levels) in <top (required)>'.

Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from watir-rspec/spec/watir/rspec_spec.rb:15:in `block (3 levels) in <top (required)>'.

If you need more of the backtrace for any of these deprecations to
identify where to make the necessary changes, you can configure
`config.raise_errors_for_deprecations!`, and it will turn the
deprecation warnings into errors, giving you the full backtrace.

2 deprecation warnings total

Also, does this code work with RSpec 3 as well? https://github.com/watir/watir-rspec/blob/master/lib/watir/rspec.rb#L24-L39
I'm not sure if it's being hit by specs because it would need specs to actually load that HtmlFormatter.

Coverage decreased (-2.9%) to 83.13% when pulling 7185bfb8ee83418b7c16b99553941abc45398ccd on pvmeerbe:master into 84355463e3dbf40b4b49e5d411f6a15a7e843095 on watir:master.

The 2 deprecation warnings come from this commit https://github.com/watir/watir-rspec/commit/d7272c6d9a6fa269019ae2611eb05cee2ddc8e10#diff-c35e68030088f30c29b8ccccc114c0de added after my fork.
I rebased my fork & converted the feature.
Regarding https://github.com/watir/watir-rspec/blob/master/lib/watir/rspec.rb#L24-L39 code:  I tried calling Watir::RSpec.file_path("foobar")  when formatter is configured in the spec_helper.rb file & without configuring it (in which case the error is raised). Both scenarios seem to work.

Sorry about that.
Finally merged. Thanks!
One thing i'm still missing is a spec for functionality created at https://github.com/watir/watir-rspec/blob/master/lib/watir/rspec/helper.rb#L32-L34 - i bet that's the reason why code coverage decreased as well.
Also, could you show some real-life code which uses that feature, since i can't recall any Watir::Browser methods right now, which might take a block as an argument.

I'm using a custom layer around Watir with several block methods for example to run a code block after visiting a page.
But a quick look at the API of watir shows http://www.rubydoc.info/gems/watir-webdriver/Watir/AlertHelper which has several block methods. Or the use method of Window : http://www.rubydoc.info/gems/watir-webdriver/Watir/Window:use
Thanks for merging & releasing!

AlertHelper seems to be a deprecated API as written in the docs.
Window#use does indeed accept block, but not Browser#window, which means that everything would have worked without the changes related to blocks.
But reading at your original problem then did you know that Watir::Browser has an API for that - http://www.rubydoc.info/gems/watir-webdriver/Watir/Browser#add_checker-instance_method and by looking at that you might need to provide a block.


Typo in docs

What does this PR do?
Fixes a typo found here
AuthenticatedType to AuthenticationType
What issues does this PR fix or reference?
@W-10060931@

Adding ?w=1 removes whitesspace changes.
https://github.com/salesforcecli/plugin-community/pull/37/files?w=1


Added toast message for LEDs in PCIe topology

For the LEDs in the PCIe hardware topology page, the toast message was not present. Added them in this change.
Defect: https://jazz07.rchland.ibm.com:13443/jazz/web/projects/CSSD#action=com.ibm.team.workitem.viewWorkItem&id=557571


Support providing serializing context to response models

Context
https://github.com/pydantic/pydantic/pull/9495 introduces passing context to TypeAdapter models.
Problem
Some fastapi based projects use model definitions that have multiple uses, and serializing for an API response is only one.
Up until now, fastapi/pydantic has supported exclusion of fields through the use of exclude keyword (example from sentry).
If however, a model needs to be serialized in different contexts - for example to be saved to dynamodb as well as to return via the API - it becomes limiting to have to opt in for inclusion/exclusion once and for all.
Solution
Pydantic Serialization Contexts provide a means to tell pydantic models the context of the serialization, and then they can act on that.
This PR makes it possible to reuse model definitions within a fastapi project for multiple purposes, and then simply state during route definition the context you want to be included when rendering.
Example
Simple example

class SerializedContext(StrEnum):
    DYNAMODB = "dynamodb"
    FASTAPI = "fastapi"

class Item(BaseModel):
    name: str = Field(alias="aliased_name")
    price: Optional[float] = None
    owner_ids: Optional[List[int]] = None

    @model_serializer(mode="wrap")
    def _serialize(self, handler, info: SerializationInfo | None = None):
        data = handler(self)
        if info.context and info.context.get("mode") == SerializedContext.FASTAPI:
            if "price" in data:
                data.pop("price")
        return data

@app.get(
    "/items/validdict-with-context",
    response_model=Dict[str, Item],
    response_model_context={"mode": SerializedContext.FASTAPI},
)
async def get_validdict_with_context():

    return {
        "k1": Item(aliased_name="foo"),
        "k2": Item(aliased_name="bar", price=1.0),
        "k3": Item(aliased_name="baz", price=2.0, owner_ids=[1, 2, 3]),
    }

And this model definition can be made more generalized like so:
class ContextSerializable(BaseModel):
    @model_serializer(mode="wrap")
    def _serialize(self, handler, info: SerializationInfo):
        d = handler(self)

        serialize_context = info.context.get("mode")
        if not serialize_context:
            return d
        for k, v in self.model_fields.items():
            contexts = (
                v.json_schema_extra.get("serialized_contexts", [])
                if v.json_schema_extra
                else []
            )
            if contexts and serialize_context not in contexts:
                d.pop(k)

        return d

class Item(ContextSerializable):
    name: str = Field(alias="aliased_name")
    price: Optional[float] = Field(serialized_contexts={SerializedContext.DYNAMODB})
    owner_ids: Optional[List[int]] = None

TODO:

[x] Wait for https://github.com/pydantic/pydantic/pull/9495 to be merged
[ ] Wait for https://github.com/pydantic/pydantic/pull/9495 to be released (pydantic 2.8)
[ ] Update version specification in this PR

Hi @alexcouper :wave:,
I'm wondering if your proposal can be used to handle my use-case: I'd like a parameter passed to an endpoint to expand some datamodels. By default I want one property being serialized with exclude_unset=True, but in case expansion is required, I want to turn it to False.
At first I though pydantic's serialization context would fix my issue, but I realize that without fastAPI integration of this to drive the context injection, it becomes yet another ugly hack.
class CustomObjectRead(SQLModel):
    identifier: int
    description: str | None = None
    config: Config

    @field_serializer('config')
    def expand_config(self, config: Config, info: SerializationInfo):
        """
        Expand the configuration to include defaults as well as computed fields
        """
        context = info.context
        expand_config = context and context.get('expanded')
        return config.model_dump(exclude_unset=not expand_config)

@myrouter.get("")
async def customobject_get_all(
   expanded: bool = Query(default=False, description="Expand the frontends configurations"),
) -> list[CustomObjectRead]:
     (...)
     # Find a way to pass expanded to the serialization context
     return [my_object_collection]

The specifics here compared to your example is the fact the context should be hinted by the call itself.
Maybe I just lost myself and there's another elegant way to do it?

@pierrecdn
If you want the behaviour to be determined by a query param flag then I'm not sure this will help you -at least you won't be able to make use of the response_model_context parameter as in the example.
One way round this would be to have 2 route endpoints dependent on expansion that use the same underlying function to get the objects. If you do that you can use the response_model_exclude_unset flag already present in a route to determine behaviour.

One way round this would be to have 2 route endpoints dependent on expansion that use the same underlying function to get the objects. If you do that you can use the response_model_exclude_unset flag already present in a route to determine behaviour.

Yeah, but the "2 route endpoint" is not something I'd consider. Basically I want the behavior to be driven by query, such as /api/resource?expanded=true.
I guess it's worth logging an issue at that point.

Hi @alexcouper, thanks for the PR! We'll get this reviewed by the team and get back to you 🙏

@svlandeg should I be regularly rebasing this PR, as conflicts come in, or is it OK to wait until a first review is done.


Recurrent Dropout

Hi there,
I have a question about your implementation on recurrent dropout:
https://github.com/awslabs/sockeye/blob/ad990095a2fe84dbf84b72b886a4c7f66d31f648/sockeye/rnn.py#L341
It seems that you defined recurrent dropout as the dropout performed on in_transform, but should it be performed on h2h? Because in my opinion, recurrent dropout corresponds exactly to input dropout, which performs on i2h.
Thank you.

Hi,
the implementation is based on Semeniuta et al, Recurrent Dropout without Memory Loss (https://aclanthology.coli.uni-saarland.de/pdf/C/C16/C16-1165.pdf). If you look at Equation 9 in the paper, you see that they apply dropout on g_t, which corresponds to in_transform in the code.


Added chat example written in polymer

I'll do a checklist one too if you guys want.
Not quite sure how to deal with the whole /dist directory thing. Do you guys expect me to write a build pipeline? It's a pretty simple app.

This change is

Hey @BLamy I'd like to get this added, would you mind sharing your Blamy/horizon repo?

@dalanmiller I made the repo public. I'll resolve merge conflicts later.


After every pr merge, please update your project in jwoc branch

📚 Documentation
This is not an issue. But important note for all of you.
Add relevant screenshot or video (if any)
No response
Additional context
No response

@wasimreja sir which JWOC branch you are talking about

go through this https://mvthanoshan.medium.com/how-to-update-your-pull-requested-branch-with-original-repositorys-master-80eea0d2d795

@wasimreja sir which JWOC branch you are talking about and how to update

so basically before doing any pull request we have to sync our fork so that pr should be up-to-date right?


Problem with moment 2.25.0 and node 14.1.0

I have recently update node version and upgrade packages and get this error when run project:
Node: v14.1.0
OS: macOS 10.15.3
Browser: Google Chrome 81.0.4044.129
Uncaught TypeError: moment.localeData is not a function
    at eval (jalali-moment.js?042b:225)
    at Object../node_modules/jalali-moment/jalali-moment.js (vendors.app.js:3616)
    at __webpack_require__ (runtime.js:854)
    at fn (runtime.js:151)
    at eval (Model.js:18)
    at Module../models/Model.js (app.js:978)
    at __webpack_require__ (runtime.js:854)
    at fn (runtime.js:151)
    at eval (AttributeGroup.js:16)
    at Module../models/AttributeGroup.js (app.js:930)

I have same issue
node version: 10.15.3

Uncaught TypeError: moment.localeData is not a function
at Object.../../node_modules/jalali-moment/jalali-moment.js (jalali-moment.js:224)
at webpack_require (bootstrap:78)
at Module../src/app/shared/material.persian-date.adapter.ts (applicant-excel-dialog.component.ts:10)
at webpack_require (bootstrap:78)
at Module../src/app/app.module.ts (app.component.ts:21)
at webpack_require (bootstrap:78)
at Module../src/main.ts (main.ts:1)
at webpack_require (bootstrap:78)
at Object.0 (main.ts:17)
at webpack_require (bootstrap:78)

localeData is a method of moment instance you have to use it as the following code
moment().localeData()


Unable to use backslash in upload spec regular expression

The pull request at https://github.com/JFrogDev/build-info/pull/100 broke the regular expression matching feature of the plugin. Specifically, it is now impossible to include a backslash character in the regular expression because they are all replaced with forward-slashes. For example, when I uploaded with v2.7.2 of the plugin (which did not have this change) with this upload spec:
"pattern": "pom\\.xml"
I received this output as expected:
For pattern: pom\.xml 1 artifacts were found
But in v2.8.0 of the plugin (which has that change) it fails to match and find the file; I get this message instead (note the backslash has been converted to a forward slash):
For pattern: pom/.xml 0 artifacts were found.

Thank you for reporting this issue.
A fix for this issue can be found at our latest Artifactory plugin, version 2.8.1.


Settings.bundle on iOS not updated from app-settings.json, Android works

Initially preferences are ok, steps:

adding the plugin
ionic build ios
open XCode
run app
-> OK

Then changing some settings in app-settings.json:

ionic build ios
open XCode
run app
-> Settings are updated but again in the "wrong" Settings.bundle in the platform root as in https://github.com/apla/me.apla.cordova.app-preferences/issues/60

You have to copy the updated Settings.bundle to /MYPROJECT/Resources manually to get the updated settings.

Just tested it, works fine. Sometimes after cordova run ios app preferences is empty, in this case just remove app and run again.


testing-library/react: cleanup not called automatically with threads: false

Describe the bug
Using @testing-library/react with threads set to false in my vite.config.ts, some of my tests are failing with "Found multiple elements" errors.
After some digging, I found I just had to run RTL's cleanup function manually to get things to work. However, I don't have to do this if I set threads to true. Also, on RTL's docs for cleanup, it says:

Please note that this [running cleanup] is done automatically if the testing framework you're using supports the afterEach global and it is injected to your testing environment (like mocha, Jest, and Jasmine). If not, you will need to do manual cleanups after each test.

I have globals enabled, so the conditions for running cleanup automatically should be met. 🤔 So it seems like threads: false is interfering with something, perhaps.
Here's full output from running my tests. 👇 The output shows the JSX from the several cases having run, but the element structure shouldn't all be there at the same time.
 RUN  v0.13.1 C:/[REDACTED]/vitest-rtl-cleanup-bug

 √ src/components/Counter.test.tsx (2) 395ms
 ❯ src/components/DarkMode.test.tsx (3)
   ❯ displays current dark mode (2)
     √ light
     × dark
   × toggles dark mode

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯ Failed Tests 2 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
 FAIL  src/components/DarkMode.test.tsx > displays current dark mode > dark
AssertionError: expected

 to be null
 ❯ src/components/DarkMode.test.tsx:42:40
     40|     renderWithContext(<DarkMode />);
     41|     expect(screen.getByText(/dark/)).toBeInTheDocument();
     42|     expect(screen.queryByText(/light/)).toBeNull();
       |                                        ^
     43|   });
     44| });

⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯[1/2]⎯

 FAIL  src/components/DarkMode.test.tsx > toggles dark mode
TestingLibraryElementError: Found multiple elements with the text: /light/

Here are the matching elements:

Ignored nodes: comments,


Add login and logout events

That way, components can just listen in order to update their state.
Right now, they have no way of knowing when another components started a login.

Implemented in #57.


update v8 binaries

exposed internal v8 function

Could you please update the NativeScript extension header, too?

Works quite, well 👍


Public page inside private page tree

Is your proposal related to a problem?
As explained in the documentation here it is currently not possible to set differents permissions for pages within a private page tree. All pages inside a private tree inherit the permissions of the parent private page.
Describe the solution you'd like
In some cases specific child pages might need to be accessible to certain user groups or individuals, while others remain restricted
Currently, this use case cannot be accommodated due to inherited permissions across the tree.
Could this feature be considered for a future release? What is your opinion on this feature? Do you think it would be useful?

Hi @matteonext - thanks for the suggestion.
I'll move this to a discussion for now, as we'd really need to get some consensus about how such a feature would behave and how it can be made as useful as possible to the most users, before it's possible to be picked up as an issue.
Opinions welcome. Perhaps this calls for a new option in the 'set page privacy' dialog, to be shown as a checkbox whenever a restriction already exists on the parent, something like:


[07/28/2020, 02:02:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:02:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:02:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:02:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:03:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:03:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:03:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:04:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:04:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:04:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:05:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:05:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:05:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:06:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:06:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:06:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:07:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:07:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:07:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:08:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:08:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:08:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:36 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:36 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:36 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:41 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:41 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:41 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:46 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:46 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:46 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:51 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:51 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:51 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:09:56 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:09:56 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:09:56 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:01 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:01 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:01 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:06 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:06 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:06 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:11 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:11 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:11 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:16 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:16 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:16 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:21 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:21 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:21 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:26 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:26 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:26 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:31 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'PI00000000000000']
[07/28/2020, 02:10:31 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:31 PM] DEBUG (nni.msg_dispatcher_base/Thread-1) process_command: command: [CommandType.Ping], data: []
[07/28/2020, 02:10:35 PM] DEBUG (nni.protocol/MainThread) Received command, header: [b'TE00000000000000']
[07/28/2020, 02:10:35 PM] DEBUG (nni.protocol/MainThread) Received command, data: []
[07/28/2020, 02:10:35 PM] INFO (nni.msg_dispatcher_base/MainThread) Dispatcher exiting...
[07/28/2020, 02:10:37 PM] INFO (nni.msg_dispatcher_base/MainThread) Terminated by NNI manager

Dear @Goldgaruda , can you display some trial logs, e.g., ~/nni-experiment/[experiment_id]/trials/[trial_id]/trial.log and ~/nni-experiment/[experiment_id]/trials/[trial_id]/stderr ? It seems that your experiment is good, but trials failed.

I have solved this problem already. The cause is the environment variable setting in windows which is written in configure file. Thanks, everyone.

@Goldgaruda Great! Feel free to ask if you have any further questions.


Main window for all (minus coming soon content, tbd)

[x] General cleanup of nav and old tabs
[x] Feature flags for each tab / search
[x] Split more/ into dev/ and settings/
[x] Only allow one instance of electron

:mag_right: No visual changes found as a result of these commits.

:mag_right: :zap: These commits introduced some visual changes:

Changed: Menubar-Truncated (before) (after)

Changed: Menubar-Normal (before) (after)

Changed: Folders_TLF-Normal (before) (after)

:mag_right: :zap: These commits introduced some visual changes:

Changed: Folders_TLF-Normal (before) (after)

:mag_right: No visual changes found as a result of these commits.

@keybase/react-hackers take a look. i made a sep. ticket for the coming soon messaging as i'm meeting w/ design in an hour

@chrisnojima CI is green now, okay to merge.

@keybase/react-hackers bump

:+1:

👍 % feature flag logic moving

:mag_right: These commits introduced some visual changes:

Added: Folders_TLF-Coming_Soon

:mag_right: These commits introduced some visual changes:

Added: Folders_TLF-Coming_Soon

:mag_right: These commits introduced some visual changes:

Added: Folders_TLF-Coming_Soon

:mag_right: These commits introduced some visual changes:

Added: Folders_TLF-Coming_Soon

(Some Flow errors.)

:mag_right: These commits introduced some visual changes:

Added: Folders_TLF-Coming_Soon


[38_wald_friedman]_repharse

Hi @jstac , this PR rephrases a word in lecture wald_friedman:

Increased cost per draw has induced the decision-maker to take less draws before deciding. -->> Increased cost per draw has induced the decision-maker to take fewer draws before deciding.

It might be better to use fewer, instead of less here, because the following word draws is plural.

Good idea @shlff

Good idea @shlff


[BUG] - twix_object read only - io_loadspec_twix - Alex Gussew

Describe the bug
Twix loader is not working for XA data as the twix_object is read-only.
Additional context
MRShub.org post (https://forum.mrshub.org/t/issue-on-ospreyprocess-in-siemens-megapress-twix-data/1955/3) continued.

Solved in #741


BF: use snapshots.debian.org instead of mirrors.kernel.org for guaranteed availability

of elderly libpng12-0 pkg
atm old link is a bust
$> wget -O- http://mirrors.kernel.org/debian/pool/main/libp/libpng/libpng12-0_1.2.49-1%2Bdeb7u2_amd64.deb | head
--2019-04-10 13:15:56--  http://mirrors.kernel.org/debian/pool/main/libp/libpng/libpng12-0_1.2.49-1%2Bdeb7u2_amd64.deb
Resolving mirrors.kernel.org (mirrors.kernel.org)... <IP_ADDRESS>, 2001:19d0:306:6:0:1994:3:14
Connecting to mirrors.kernel.org (mirrors.kernel.org)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://mirrors.edge.kernel.org/debian/pool/main/libp/libpng/libpng12-0_1.2.49-1%2Bdeb7u2_amd64.deb [following]
--2019-04-10 13:15:56--  http://mirrors.edge.kernel.org/debian/pool/main/libp/libpng/libpng12-0_1.2.49-1%2Bdeb7u2_amd64.deb
Resolving mirrors.edge.kernel.org (mirrors.edge.kernel.org)... <IP_ADDRESS>, 2604:1380:1:3600::1
Connecting to mirrors.edge.kernel.org (mirrors.edge.kernel.org)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-04-10 13:15:56 ERROR 404: Not Found.

which is not unexpected since that debian release is gone, so might only be present in archives or snapshots

smth odd  test_others seems to be ok: https://circleci.com/gh/kaczmarj/neurodocker/890?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

Codecov Report

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

@@           Coverage Diff           @@
##           master     #278   +/-   ##
=======================================
  Coverage   80.86%   80.86%
=======================================
  Files          33       33
  Lines        1568     1568
  Branches      170      170
=======================================
  Hits         1268     1268
  Misses        219      219
  Partials       81       81

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 21e55b3...1f22f60. Read the comment docs.

thanks @yarikoptic


Marker size

Hello,
Is there a way to specify the marker size in a pointplot ?
keith

Keyword arguments not captured by pointplot are forwarded to matplotlib.pyplot.scatter, which includes a parameter for marker size: s. So, do e.g. gplt.pointplot(..., s=100).


Limit samples for training

is there any way to make the training stop after N samples/iterations?

That's not implemented at the moment. But it should be pretty easy to just modify the done here:
https://github.com/xbpeng/DeepMimic/blob/c0731625e72c96a3f758def75f5e4ecbf60e8ca1/DeepMimic_Optimizer.py#L16
To check if the total number of samples exceeds some limit.

Thanks! I will try to take a look. So right now what's the criterion for done?

done is just always false right now.


Deprecated field in path parameter needs to be set to false by default

The deprecated field in schema object set to false by Default and can the same be set on path parameter level ?.

All deprecated fields in the latest version of OAS default to false.


[SPARK-19709][SQL] Read empty file with CSV data source

What changes were proposed in this pull request?
Bugfix for reading empty file with CSV data source. Instead of throwing NoSuchElementException, an empty data frame is returned.
How was this patch tested?
Added new unit test in org.apache.spark.sql.execution.datasources.csv.CSVSuite

Can one of the admins verify this patch?

@HyukjinKwon can somebody allow to test this PR as there are no more comments?

Hi @wojtek-szymanski, these are all from me. Let me cc @cloud-fan as my PRs related with this were reviewed by him and I guess I can't trigger the test.

ok to test

Test build #73950 has started for PR 17068 at commit b9e9a84.

Test build #73950 has finished for PR 17068 at commit b9e9a84.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Test build #73970 has started for PR 17068 at commit e7faa80.

Merged build finished. Test FAILed.

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

retest this please

Test build #73983 has started for PR 17068 at commit e7faa80.

Test build #73983 has finished for PR 17068 at commit e7faa80.

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

Merged build finished. Test PASSed.

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

thanks, merging to master!


Create Chapter 7: Fetching Data

[ ] Add "https://www.learn-qwik.com/metaChapter7.png",

Looking forward to Chapter 7.

Looking forward to Chapter 7.

It won't be long...


set default value to table.json

hi,
i was trying to set default value to my table.json. the code is something like this:
table.json('notification')
.notNullable
.defaultTo({
buySell: true,
sendReceive: true,
});
however, i have error that says i cannot set default value to table.json. i already include this line in my model, still, its not working:
static get jsonAttributes() {
return ['notification'];
}
i also added this is my model:
static get jsonSchema() {
return {
type: 'object',
properties: {
notification: {
type: 'boolean',
default: false,
},
},
};
}
and i get error message: "error": "insert into setting (notification, userId) values (false, 4) - Invalid JSON text: "not a JSON text, may need CAST" at position 0 in value for column 'setting.notification'.",
is there any other way can i add default value to the attributes?
thank you so much in advace

Wrap the default value in JSON.stringifu.

Hi koskimas,
Thank you :)

On 6 Sep 2019, at 2:54 AM, Sami Koskimäki<EMAIL_ADDRESS>wrote:
Wrap the default value in JSON.stringifu.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/Vincit/objection.js/issues/1463?email_source=notifications&email_token=ALW3XJ4WSC4GI2S3XUOP7QLQIFIXTA5CNFSM4IT3DHNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6AKM7Y#issuecomment-528524927, or mute the thread https://github.com/notifications/unsubscribe-auth/ALW3XJ52GIRIDRTV3JVZNVDQIFIXTANCNFSM4IT3DHNA.


test issue please ignore - lurch test

This is just a test to make sure that lurch is attached to my account

**lurch: add

Tracking W-034971