formatToParts output

Intl.DurationFormat is interesting in the sense that it composes multiple types of fields (number fields and list element fields).  @FrankYFTang says that the current spec requires outputting only the list fields, but not the number fields.  I wondered if we should also output the number fields in some form.  Doing so would require more changes to ICU.
Related: https://unicode-org.atlassian.net/browse/ICU-21547

could you add an example, please?

Shane, I have hard time to understand what could be possible put into formatToParts
Let's say we have the following
let d = {days: 1, hours:2, minutes:3, seconds: 4}
let df = new Intl.DurationFormat("en")
df.format(d)
// "1 day, 2 hours, 3 minutes, 4 seconds"
df.formatToPart(d)
// output from the current spect text
[ {type: "element", value: "1 day"},
  {type: "literal", value: ", "},
  {type: "element", value: "2 hours"},
  {type: "literal", value: ", "},
  {type: "element", value: "3 minutes"},
  {type: "literal", value: ", "},
  {type: "element", value: "4 seconds"}
]

What do you mean "also output the number fields in some form" in ECMA402 ? (I am not talking about about should we implement it, but how the output could possible be)
Could you write down the possible output of your  "also output the number fields in some form" in term of js array of object?

Sure.
[
  {type: "integer", value: "1", unit: "day"},
  {type: "literal", value: " "},
  {type: "unit", value: "day", unit: "day"},
  {type: "literal", value: ", "},
  {type: "integer", value: "2", unit: "hour"},
  {type: "literal", value: " "},
  {type: "unit", value: "hours", unit: "hour"},
  {type: "literal", value: ", "},
  {type: "integer", value: "3", unit: "minute"},
  {type: "literal", value: " "},
  {type: "unit", value: "minutes", unit: "minute"},
  {type: "literal", value: ", "},
  {type: "integer", value: "4", unit: "second"}
  {type: "literal", value: " "},
  {type: "unit", value: "seconds", unit: "second"},
]

Looking at what Shane suggest, if we use what the Intl.RelativeTimeFormat currently output, it will be slightly different as
[
  {type: "integer", value: "1", unit: "day"},
  {type: "literal", value: " "},
  {type: "unit", value: "day"}, // no  unit: "day" here
  {type: "literal", value: ", "},
  {type: "integer", value: "2", unit: "hour"},
  {type: "literal", value: " "},
  {type: "unit", value: "hours"}, // no unit: "hour" here
  {type: "literal", value: ", "},
  {type: "integer", value: "3", unit: "minute"},
  {type: "literal", value: " "},
  {type: "unit", value: "minutes"}, //  unit: "minute" here
  {type: "literal", value: ", "},
  {type: "integer", value: "4", unit: "second"}
  {type: "literal", value: " "},
  {type: "unit", value: "seconds"}, // no  unit: "second" here
]

of course, the other option is we can change the Intl.RelativeFormat to output unit attribute also for type:"unit"
The other possibility is
[
  {type: "integer", value: "1", unit: "day"},
  {type: "literal", value: " ", unit: "day"}, // add unit: "day" here too
  {type: "unit", value: "day", unit: "day"},
  {type: "literal", value: ", "},  // but not here
  {type: "integer", value: "2", unit: "hour"},
  {type: "literal", value: " "}, // add unit: "hour" here too
  {type: "unit", value: "hours", unit: "hour"},
  {type: "literal", value: ", "}, // but not here
  {type: "integer", value: "3", unit: "minute"},
  {type: "literal", value: " "}, // add unit: "minute" here too
  {type: "unit", value: "minutes", unit: "minute"},
  {type: "literal", value: ", "}, // but not here
  {type: "integer", value: "4", unit: "second"}
  {type: "literal", value: " "}, // add unit: "second" here too
  {type: "unit", value: "seconds", unit: "second"},
]

Also... would the unit be in singular form to match other Intl api or plural form to match the value in smallestUnit / largestUnit ?

so.... should it be unit: "day" or unit: "days"?

@sffc @FrankYFTang both the formats suggested here sound fine to me, I'd be happy changing the spec to either, just let me know if you folks have a preference here.

Also... would the unit be in singular form to match other Intl api or plural form to match the value in smallestUnit / largestUnit ?

Regarding this, @FrankYFTang I would personally prefer the plural form, so "days" and "seconds". Do you have feel strongly otherwise?

According to https://tc39.es/proposal-temporal/#sec-temporal-tosmallesttemporalunit

Temporal will take both singular or plural form in the option
All other ECMA402 use singular form

What is pros/cons of using  plural form?
What is pros/cons of using  singular form?

Also see https://github.com/tc39/proposal-temporal/issues/1469 The Temporal spec text is just strange....

I would personally prefer the plural form, so "days" and "seconds".

Why? what is the reason for you personally prefer plural form?

@FrankYFTang I prefer the plural forms since they map better to the mental model I have for durations. Durations have "x days", "y weeks", "z years" and so on... Date/times, on the other hand, have a specific value (not quantities) "xth day of yth month of zth year".

I search the net and here is what I found
https://www.aqua-calc.com/what-is/time/day
"The day is a unit of measurement of time"
notice it is NOT "The days is a unit of measurement of time"
https://en.wikipedia.org/wiki/Metric_time
"Other units of time: minute, hour, and day, are accepted for use with SI,...."
notice it is NOT
"Other units of time: minutes, hours, and days, are accepted for use with SI,...."
https://www.math-only-math.com/units-of-time.html
"There are different units of time.
Second, minute, hour, day, week, month and year are the units of time."
Notice it is NOT
"There are different units of time.
Seconds, minutes, hours, days, weeks, months and years are the units of time."
http://www.exactlywhatistime.com/measurement-of-time/units-of-measurement/
"Other Units
Time Units
Flowchart illustrating interrelationships among the major units of time
More commonly, outside of purely scientific usage, other units are used for longer periods of time. Although technically “non-SI” units, because they do not use the decimal system, these units are officially accepted for use with the International System.
minute (60 seconds)
hour (60 minutes, or 3,600 seconds)
day (24 hours, or 86,400 seconds)
week (7 days, or 604,800 seconds)
month (28-31 days, or 2,419,200-2,678.400 seconds)
year (about 365.25 days, or about 31,557,600 seconds)
"
Notice when the units are mentioned, they are  in SINGULAR form not in PLURAL form.
https://physics.nist.gov/cuu/Units/outside.html
same
so... what make us think the units are "years, months, days" but not "year, month day"?

Here are some dictionary definition of the English word "unit"
https://www.merriam-webster.com/dictionary/unit
": a single quantity regarded as a whole in calculation"
": a single thing, person, or group that is a constituent of a whole"
(notice the word unit is referring to "A SINGLE quantity" not "multiple...."
https://dictionary.cambridge.org/us/dictionary/english/unit
"a single thing or a separate part of something larger:
"a standard measure that is used to express amounts:"
(notice it use "A standard measurement" (the word "A" is used here)
https://www.oxfordlearnersdictionaries.com/us/definition/american_english/unit#:~:text=%2Fˈyunət%2F,all living organisms are composed.
"measurement
unit (of something) a fixed quantity, etc. that is used as a standard measurement
a unit of time/length/weight
a unit of currency, such as the euro or the dollar"
While multiple amount of the unit is plural- the UNIT itself is singular here,

I believe in English, we would say,
A. "The time unit to express the duration of "4 years" is 'year'."
but NOT
B. "The time unit to express the duration of "4 years" is 'years'."
right?
A is proper English and B is not proper English, right?

@jhusain @sffc

Related: https://github.com/tc39/proposal-temporal/issues/1452
I tend to prefer singular forms, simply because any suffixes in English (like "s", "er", "ed", "ing") don't add a whole lot and take up space in a program file.  That's why we have DurationFormat instead of DurationFormatter.  We're not completely consistent (i.e. Segmenter), but in cases where there is ambiguity, I tend to prefer the shorter form.
However, in Temporal, according to https://github.com/tc39/proposal-temporal/issues/325#issuecomment-691249107, we decided to go with plurals, despite my weakly held objection to that.

I don't think it's possible to make an English grammar argument for having only singular or plural. English is too flexible :smile: It is correct to say both "the unit of length is the meter" and "Length is expressed in meters". I don't think it's helpful to flood the thread with examples of singular units.
The rationale for having plural field names in Temporal.Duration but not in other Temporal types was exactly what @ryzokuken said. In other words, because "a date in the year 2000" but "a duration of five years". I think it makes sense to be consistent with the field names for Temporal.Duration in this output from formatToParts.

meter or not have nothing to do with duration so your argument is irrelevant to this discussion.
Intl.NumberFormat in ECMA402 (Not Intl.DateTimeFormat) is using "day", "hour", "millisecond", "minute", "month", "second", "week", "year" as UNIT, NOT "days", "hours", "milliseconds", "minutes", "months", "seconds", "weeks", "years"
https://tc39.es/ecma402/#table-sanctioned-simple-unit-identifiers
We, ECMA402, should oppose to Temporal, a Stage 3 proposal, which disregard what is already agreed by TC39 to accept into ECMA402 Intl.NumberFormat to create inconsistency. Notice I am NOT using the argument of Intl.DateTimeFormat nor Intl.RelativeTimeFormat here- I am using Intl.NumberFormat here. All the argument of the "day" in Intl.DateTimeFormat is pointing a particular day is not related to the UNIT in Intl.NumberFormat.
If Temporal authors disregard what ECMA402 already accepted into ECMA402 standard, then we, as ECMA402 TG2 should at least keep the unit consistent WITHIN the ECMA402 specification and make the Intl.DurationFormat consistent with Intl.NumberFormat, instead of consistent with Temporal.

Temporal is in Stage 3 and not yet implemented by any VM as my understanding. We should push back to Temporal from ECMA402 to change it.

However, in Temporal, according to tc39/proposal-temporal#325 (comment), we decided to go with plurals,
tc39/proposal-temporal#325 said the following

Decision 2020-09-11:

Property Names

All methods in Temporal that accept a TimeLike or a DurationLike property bag must include at least one correctly-spelled property.
Empty objects will throw, as will objects that only contain the wrong pluralization and/or mis-spelling.
Cases like {years: 1, hour: 1} won't throw because it's obscure and obvious to solve via debugging.
Unit names in options values (e.g., smallestUnit)

Allow both variants.
Use JSDoc @deprecated for the "wrong" unit (the one differing from the type's field name) in TypeScript types.
Ideally, we'd have an ESLint rule to catch the "wrong" variant, but that's out of scope.

I saw nowhere in that decision said "decided to go with plurals".

"Length is expressed in meters"
But the argument in the Duration option is NOT smallestExpressedIn, BUT smallestUnit, right?
so "meters" in that sentence is what the length "expressed in", not what the  "unit" of that length is.

I think the plural vs singular discussion has been settled in favor of singular forms, right? cc @FrankYFTang @ptomato

Actually, based on the spec, I think everything works as expected except Shane's request of additionally exposing the number formatting. I don't believe it's particularly useful to be so low level and it's not precedented for existing APIs, but I could do it if you feel too strongly. The current result would be something like this according to my reading of the spec.
[
  { type: "element", value: { type: "day", value: "1" } },
  { type: "literal", value: ", " },
  { type: "element", value: { type: "hours", value: "2" } },
  { type: "literal", value: ", " },
  { type: "element", value: { type: "minutes", value: "3" } },
  { type: "literal", value: " and " },
  { type: "element", value: { type: "seconds", value: "4" } },
]

We never have nesting inside of formatToParts in ECMA-402. https://github.com/tc39/proposal-intl-duration-format/issues/55#issuecomment-1171486907 does not look correct to me.

My preference's 1  if it keeps consistency with the actual output of RelativeTimeFormat - users can reuse their code/understanding of the API for both use cases

But... apparently, we are introducing a new "type" called unit inexistent on RelativeTimeFormat

That's understandable since RelativeTimeFormat only supports a single unit, so it's easy to tell which unit is being talked about.

The current consensus for SerenityOS is option 1. We believe it strikes the best balance between the over-verbosity of option 2 and the limited information given by option 3.

Option 2 is additive over Option 1.
We should also be clear about the expected behavior when there are multiple parts of the number:
// Current behavior in Chrome
new Intl.RelativeTimeFormat("en").formatToParts(5555.5, "minutes")

(7) [{…}, {…}, {…}, {…}, {…}, {…}, {…}]
0: {type: 'literal', value: 'in '}
1: {type: 'integer', value: '5', unit: 'minute'}
2: {type: 'group', value: ',', unit: 'minute'}
3: {type: 'integer', value: '555', unit: 'minute'}
4: {type: 'decimal', value: '.', unit: 'minute'}
5: {type: 'fraction', value: '5', unit: 'minute'}
6: {type: 'literal', value: ' minutes'}
length: 7

In DurationFormat, if we are introducing a new type: "unit", then I think that is an improvement over RelativeTimeFormat, and we should tag it with the unit.
Option 4, which would be closest to RelativeTimeFormat, would be
[
  {type: "integer", value: "1", unit: "day"},
  {type: "literal", value: " day, "},
  {type: "integer", value: "2", unit: "hour"},
  {type: "literal", value: " hours, "},
  {type: "integer", value: "3", unit: "minute"},
  {type: "literal", value: " minutes, "},
  {type: "integer", value: "4", unit: "second"}
  {type: "literal", value: " seconds"},
]

I'm not advocating for that option, however. I still prefer option 2 since it has the most information. It's easy for developers to ignore information or merge adjacent parts into one, but it's much more difficult for them to add new information.

In the process of writing and fixing #126, I realized that the Option 3 is the only way formatToParts can work while still using ListFormat, since the current design of ListFormat only works with a list of strings. The following are our options:

Stick to option 3: The entire thread talks about potentially better alternatives, but if we go with Option 3, we can continue to use ListFormat this way.
Generalize ListFormat: ListFormat is a simple construction, which could be generalized to work with anything and not just lists of strings.
Not use a locale-sensitive list formatter: We can simplify the list formatting by using an ad-hoc operation, but I'd not recommend this because this would produce worse output in the common case (format).

1 is the easiest option, obviously, with the downside that the formatToParts result isn't as granular as one might want it to be. 2 would take more time and effort, and 3 in my opinion is not a viable route.
What do you folks think?

I had assumed we would make any potential editorial changes necessary in ListFormat to support the desired formatToParts output, which also lays the groundwork for similar things we'll need to do in MessageFormat.
We shouldn't flatten the output because it's "easier", especially since the alternative is just a little spec work (no more than an hour or two). We should only consider that option if it has a value proposition.
One potential value of it is that people can externally polyfill DurationFormat on top of ListFormat.

I think the key issue we need to decide is how would the user truely use the output of formatToParts for this DurationFormat. I feel right now we all are just guessing and that make it hard for us to decide what kind of details is appropriate to expose in the result.

@FrankYFTang I agree with you completely here. While I make progress in this direction, can we figure out a way to find this out? Perhaps via user research?

Perhaps we could identify some web sites that make use of formatToParts in pre-existing formatters, check what they do, and design DurationFormat's formatToParts based on that.

Short TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-11-03.md#formattoparts-output
I said: We have a Google use case involving different font sizes. For example, in "1:23.456", the minutes, seconds, and fractional seconds may want to be different font sizes. Similarly, in "1 hr 5 min", the units may have a different font size than the numerals.

@ben-allen

sorry I was wrong earlier. I think after DeconstructPattern take the subst as a List, it now work.


User guide

@ludwigschwardt it would be helpful if you could review the compiled docs rather than the raw sources, to catch any rendering issues. If you have trouble compiling on your machine (it requires tikz), the docs can be found on our Jenkins server.

@ludwigschwardt Somehow I'd missed that you'd reviewed this. I've fixed the typos.


Handle no connection error

Currently throws GraphError if "No such host is known" which results when no connection exists

Error: Request error:
reqwest::Error {
    kind: Request,
    url: Url {
        scheme: "https",
        cannot_be_a_base: false,
        username: "",
        password: None,
        host: Some(
            Domain(
                "graph.microsoft.com",
            ),
        ),
        port: None,
        path: "/v1.0/me",
        query: None,
        fragment: None,
    },
    source: hyper::Error(
        Connect,
        ConnectError(
            "dns error",
            Os {
                code: 11001,
                kind: Uncategorized,
                message: "No such host is known.",
            },
        ),
    ),
}


Add Athens Research

Closed
https://roamresearch.com/
https://twitter.com/RoamResearch
Open
https://www.athensresearch.org/
https://twitter.com/AthensResearch
https://github.com/athensresearch/athens
cc: @tangjeff0 @theianjones

Sorry, already there! 😬

b70273f8dc65f9c3e4bc5008d052fec36685f0cd ftr 😊


video writer open (sync vs async)

sync returns video Writer
https://github.com/rainyl/opencv_dart/blob/cb044565f983a51ce3ed4923b6298df38538c2d4/lib/src/video/videoio.dart#L174
async returns bool
https://github.com/rainyl/opencv_dart/blob/cb044565f983a51ce3ed4923b6298df38538c2d4/lib/src/video/videoio_async.dart#L102
cant figure which one is the correct api

Oh, it's redundant, https://github.com/rainyl/opencv_dart/blob/cb044565f983a51ce3ed4923b6298df38538c2d4/lib/src/video/videoio.dart#L174-L218
maybe we should rename factory open() to something like openFile

the open and openAsync should be class methods (wrapper for https://docs.opencv.org/4.x/dd/d9e/classcv_1_1VideoWriter.html#a8b44d21f9bb5a02f531b50bbb15b9527)


Salvage information module

Closes #1052

Stilll needs to figure the encrypted strings reverse lookup

Works with fully localized message


[ErrorNamesPropertyToConstantRector]  add new rule to fix #280

Im not sure what the best way to find if property $errorNames is used. I saw we have one rector rule (JMSInjectPropertyToConstructorInjectionRector) to change properties but dont think that is usefull for this case see the replace fixture for example.

I'd use Rector\Core\Reflection\ReflectionResolver to check if $node->class is a subclass of Symfony\Component\Validator\Constraint 🙂

I'd use Rector\Core\Reflection\ReflectionResolver to check if $node->class is a subclass of Symfony\Component\Validator\Constraint slightly_smiling_face

@stefantalen thanks that was very helpful

I dont know why https://github.com/rectorphp/rector-symfony/actions/runs/4281227323/jobs/7453990047 is failing. I did composer update and ran vendor/bin/rector --clear-cache so rector shouldn't be failing.
On the other hand the rector always fails with this message: Error: '{brancName}' branch not found. it would be nice to see the actual rector output is that possible? In this case i would then see what is wrong.

Try composer fix-cs 😉 (If you look at the action, the ECS check is failing because it wants to change your code)

Try composer fix-cs wink (If you look at the action, the ECS check is failing because it wants to change your code)

Yes thank you :) i now see i can also open the logs above.

@samsonasik  can you do a cr?

We'll need a rebase here.

@TomasVotruba and @samsonasik made the requested changes and pipeline passes can you cr again

Looks good to me 👍
@samsonasik Feel free to merge when ready for you 🙏

Thank you @johanadivare


Enable-PSRemoting and Disable-PSRemoting cmdlets should affect all remoting endpoints per documentation.

Per PowerShell documentation, Enable-PSRemoting and Disable-PSRemoting cmdlets enable and disable all remoting endpoints on the local machine.  But PSCore6 versions of these cmdlets affect only PSCore6 endpoints.  The problem with this is that users expect Disable-PSRemoting cmdlet to isolate the local machine from any WinRM/PowerShell connections, but this is no longer true when all Windows PowerShell endpoints remain enabled.
I feel these enable/disable cmdlets should affect all WinRM endpoints on the local machine.  The cmdlet behavior should only differ by what default endpoints they create.
Enable-PSSessionConfiguration/Disable-PSSessionConfiguration cmdlets can be used to enable/disable individual endpoints.
Steps to reproduce
# Create/register default PSCore6 remote endpoints
Enable-PSRemoting -Force

# Disable endpoints
Disable-PSRemoting -Force

# From Windows PowerShell check its remote endpoints
powershell.exe -c 'Get-PSSessionConfiguration'

Expected behavior
All PowerShell endpoints on local machine are disabled.

Actual behavior
Only PSCore6 endpoints on local machine are disabled.  Windows PowerShell endpoints remain enabled and so PSRemoting remains enabled.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.0-preview.2
PSEdition                      Core
GitCommitId                    6.2.0-preview.2-68-gc9fc4ef4ec1256ac7082f55c45d4e400cc642767
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

Can PowerShell Core use Windows PowerShell endpoints and vice verse? If yes I agree that the proposal make sense.

@iSazonov Sure, it can. That's how WindowsCompatibility module works--PowerShell Core on Windows connects to Windows PowerShell endpoint.

How about:

keeping the edition-scoped behavior for consistency.

issuing a warning if Disable-PSRemoting finds endpoints managed by the respective other edition.

updating the documentation accordingly.

That would avoid the awkwardness of introducing cross-edition functionality (as opposed to awareness).

If Disable-PSRemoting disable/warn endpoints in both editions then Enable-PSRemoting should works symmetrically.


how to remove infoWindow to maker

hello, it's possible remove infoWindow do marker ???

it's easy. Do not set title and snippet properties.

thanks!!, it's work for me :)


CDK-476 oozie UriHandler for Kite URIs

An Oozie URIHandler for KiteURIs. This allows KiteURIs to be used for data input events. Particularly when chaining together workflows based on the availability of an upstream dataset (a populated view in this case).
Uses the signal ready concept implemented in CDK-451 as an alternative to the traditional "_SUCCESS" file.

Created a PR to kite-examples showing a use case for the URIHandler, https://github.com/kite-sdk/kite-examples/pull/26

Hi @bbrownz, sorry it is taking me so long to get to this. I'm not very familiar with Oozie, but I talked with someone today that was interested and will probably have a look. Otherwise I'll follow up on this next week. Thanks for being patient!

No worries! The biggest questions I had posting this in were
*we build the project, since not all the profiles made a lot of sense with the URIHandler being in oozie 4, which we only get under the CDH5 profile now. Currently the oozie version is just always locked in.
*If we should support deleting the views through the LauncherURIHandler, that felt like something we wouldn't want for the first iteration though

I have a couple of minor comments, but this looks good to me overall. Have you tested this with a cluster?

@ben-roling, could you review this as well?

Have you tested this with a cluster?

So far we've tested this on 5.2 and 5.3 with quickstart VMs via the example (kite-sdk/kite-examples#26). We're in progress doing some testing now with one of our dev clusters that has Kerberos enabled.

Sounds good! I'd like someone more familiar with Oozie to take a look, but I'm happy with this going in. Since Ben is a committer, I think it makes sense to get his +1 before merging. Thanks for working on this, @bbrownz!

@bbrownz works with me and as such I had already reviewed most of this prior to the PR being posted.  I'll take another quick pass through and then I can formally document my +1.

I think there are just 3 things left with this:

exclude the package on the javadoc plugin config
possibly change the IOException handling for exists()
implement getContext()

Once @bbrownz implements the trivial javadoc plugin config change I am +1.
I don't care that much about the IOException handling thing.  It could be changed to rethrow as HadoopAccessorException or left alone and either way would be fine by me.
With CDK-1007 I have provided a sub-task to defer the getContext() change.  I think we could merge this without it.

Addressed @ben-roling's comments from above. I think it's best to leave the implementation of the getContext() method to the optimization in the CDK-1007 issue when the usage would really come into play.
I everything looks good here I can squash this down into a single change before the merge.

Squash away!

Rebased and squashed, should be ready after the travis build goes through.

Hi, I'm one of the Oozie devs.  I took a look at this, and it looks fine to me.  I made a minor comment about logging.  That said, the Yahoo! Oozie devs are more familiar with the URIHandler code; they're the ones who generalized it and added support for HCat URIs.
What do you think about including this directly in Oozie?  That would make things easier for users because they wouldn't have to add jars into the Oozie server.  And we can include the example Coordinator too.  I know that Ben was working on OOZIE-1829, though I guess that's no longer needed for now.  Anyway, I think putting this in Oozie would be a great integration story, and I can also ask one of the Yahoo! Oozie devs to review the code.

Thanks for taking a look @rkanter!
@bbrownz and @ben-roling, we should definitely decide if we want this to go in Oozie or Kite. I'd like to avoid adding it here only to deprecate it in favor of an Oozie version in a release or two. My vote is to get this into Oozie, since that seems like the right place for it to live, as with Flume and the DatasetSink. What do you guys think?

Thanks for the feedback @rkanter!
At first glance I thought it would be nice to have this included in Oozie itself as well but @bbrownz and I talked through it more and I'm not so sure.
The primary concern we had was with regard to the speed at which we could get changes pushed through the system.  For example, if a consumer needs a fix to Kite they need to wait for a Kite release, an Oozie release after that, and then finally a distro release before they finally have it in their environment.
If the handler is only included in Kite things can work much more quickly.  Once the new Kite version is released they just deploy it and it is done with no concern for when the next Oozie or distro release might happen.
All this said, there is nothing we could do to stop the Oozie devs from incorporating Kite URI support directly into their project if they wanted to.  If they did, it could be difficult for consumers to override the Kite version if they needed to pick up a newer Kite version more quickly than they could get a new Oozie version.
Assuming we continue down a path of keeping the packaging separate from Oozie their is also the possibility we could do a documentation patch to Oozie such that Oozie doc makes mention of the Kite integration, making the functionality easier for users to find.
Thoughts?

That's a good point.  We don't have a regular release schedule for Oozie; it's just sort of whenever someone feels like doing it.  And we don't have frequent releases.  If Kite wants to iterate faster on it, then it would make sense to put it in Kite.  If we do that, I do like the idea of mentioning it in the Oozie docs.

How much do we expect this component to evolve? It seems like we should be designing it so that it touches Kite's public API -- which I think is how it currently works -- and doesn't need to change much since it is just doing change detection based on URI and the signalling API. I know we've identified some improvements and opened issues for them, but shouldn't a short-term goal be to get this to the point where we don't need to change it often?
If we could just update the version of Kite on a cluster and have Oozie pick up the latest, then I think that would be preferable.

I'm not expecting this component specifically to change that much.  I was thinking more about Kite core changing.  Of course this component doesn't use the full surface area of the Kite API so there are only certain types of changes to Kite core that could affect the Oozie integration.  The change would have to be something that affects Datasets.load() or Signalable.isReady() - maybe a bug fix or an enhancement or optimization of some sort.

If we could just update the version of Kite on a cluster and have Oozie pick up the latest, then I think that would be preferable.

Per your suggestion, we could take a hybrid approach where we include the KiteURIHandler class in Kite itself and do an Oozie patch that adds configuration to pick it up.
More specifically, the Oozie patch would:

update oozie-default.xml to add the new URI schema to URIHandler class mapping
include a default Kite version in the Oozie dependencies so things work out of the box
include a configuration mechanism to point to an alternate Kite installation path as a mechanism to pick up a newer/different Kite install

I don't off the top of my head know exactly how that would be implemented on the Oozie side but we could look into it if that direction is desirable.

That is another option.  The code could live in Kite and Oozie just pulls it in like any other 3rd-party maven dependency during the build.  We already parameterize a number of dependencies in the pom, so we could just add a "kite.version".  Then, anyone who builds Oozie can easily switch versions by changing the pom, and anyone who already has Oozie can simply swap out the kite jar with a newer version.  That leaves all of the code in Kite, while still making it work in Oozie out-of-the-box.

My hope is to avoid a solution where when a consumer wants a new Kite version before an Oozie release it requires rebuilding Oozie or modifying the files provided by the existing Oozie deployment in their cluster.
@rkanter - the way you describe sounds to me like you are suggesting a solution that would require deleting JARs from the existing Oozie deployment to get the new Kite version to go into effect.
My thought was slightly different in that we would add some mechanism to Oozie where the Kite dependencies live in some specific directory and an environment variable or configuration key of some sort can be set to point to a non-default directory to override the Kite install.
Ideally the mechanism would be such that in the CDH world a parcel could be used to apply a new Kite version to Oozie.  If deleting files out of the original Oozie deployment is required I don't think a parcel would be able to do the job.

In CDH, all those jars would be symlinked.  So, if you update Kite and restart Oozie, Oozie should automatically pick the new jars up.  I was talking more from an Apache release perspective, with a tarball install.  i.e. You have Oozie 4.1.0, and you want to update the Kite jars, you can just add the new Kite jars and redeploy the Oozie server.  You'd have to do this anyway if Oozie didn't ship with any Kite jars, right?

In CDH, all those jars would be symlinked. So, if you update Kite and restart Oozie, Oozie should automatically pick the new jars up.

Yeah, but I'm not sure you follow what I mean.  What would your "update Kite" steps be?  Let's pretend we add kite-data as a dependency of Oozie and in CDH5.5 I get this new version of Oozie installed into my environment as part of the standard CDH5.5 parcel.  Now kite-data-1.1.jar is in /opt/cloudera/parcels/CDH-5.5.0/lib/oozie/libserver.  Now, kite-data-1.1.1 comes out with a critical (to me) bug fix and I want to get it into my environment.  Cloudera hasn't deemed this fix important enough so there is no CDH-5.5.1 parcel for me to pick it up from.  How do I incorporate it?
Sure, I suppose I could go manually muck with the /opt/cloudera/parcels/CDH-5.5.0/lib/oozie/libserver directory on my system but I don't want to do that.  What I was thinking was I wanted to create my own parcel that I can install with a fix.  I guess I could create my own CDH-5.5.0-myfix parcel that repackages the whole CDH5.5 distribution but I wasn't wanting to go there.  I want to be able to create a parcel that contains only the new Kite JARs and install that as an addition to the system on top of the CDH-5.5.0 parcel.  I can do that but the problem is there is no way that I am aware (via a parcel) of for me to take the original Kite JARs off the Oozie classpath without repackaging all of Oozie or all of CDH.  Even if I wanted (and I don't) to take the route of just repackaging all of Oozie I'm not yet familiar enough with the parcel system to know how I could do that either.

I was talking more from an Apache release perspective, with a tarball install. i.e. You have Oozie 4.1.0, and you want to update the Kite jars, you can just add the new Kite jars and redeploy the Oozie server. You'd have to do this anyway if Oozie didn't ship with any Kite jars, right?

Maybe it depends on what you mean by "redeploy the Oozie server".  If Oozie didn't ship any changes related to this feature what a user would do to use the feature is change their oozie-site.xml, add the necessary JARs to /var/lib/oozie, and restart Oozie.  They don't have to touch any of the content that was shipped by Oozie or in any way rebuild Oozie.  I wouldn't consider that "redeploying the Oozie server" but you could be using a different definition of the word "deploy".
In the model I just described If there was a new release of Kite you needed you would delete the Kite-related JARs from /var/lib/oozie, put the new ones in, and restart Oozie.
The direction I was trying to suggest is such that instead of dumping the Kite JARs in /var/lib/oozie you would dump them wherever you like (e.g. /my/kite/jar/path) and then update some Oozie config to add /my/kite/jar/path to the classpath.  When you want a new version of Kite you can either delete the old jars from /my/kite/jar/path and add the new ones or you can create a new /my/kite/jar/path/v2 folder and update the Oozie config to point to the new location.
With this model Oozie could ship default Kite JARs in some folder embedded in Oozie and add that directory to the classpath unless the configuration is overridden to point to another directory.
Am I starting to make more sense?

Cloudera hasn't deemed this fix important enough so there is no CDH-5.5.1 parcel for me to pick it up from. How do I incorporate it?
What I was thinking was I wanted to create my own parcel that I can install with a fix. I guess I could create my own CDH-5.5.0-myfix parcel that repackages the whole CDH5.5 distribution but I wasn't wanting to go there. I want to be able to create a parcel that contains only the new Kite JARs and install that as an addition to the system on top of the CDH-5.5.0 parcel.

I'm not familiar with the release process for Kite, but I was I don't know if we want to go down the rabbit-hole of specifically helping users doing custom things like patching and building their own version of Kite (unless that's common for Kite?).  And as far as I know, when you build a Parcel, you have to include every component, not just the updated jars; so I don't think you can do that.

Now kite-data-1.1.jar is in /opt/cloudera/parcels/CDH-5.5.0/lib/oozie/libserver. Now, kite-data-1.1.1 comes out with a critical (to me) bug fix and I want to get it into my environment.
For CDH components, /opt/cloudera/parcels/CDH-5.5.0/lib/oozie/libserver doesn't have version numbers in the jar names.  Instead, it uses symlinks to unversioned jars in that component's dir, which are actually symlinks that point to versioned jars.  So, /opt/cloudera/parcels/CDH-5.5.0/lib/oozie/libserver would have kite-data.jar which points to ../../../lib/kite/lib/kite-data.jar (or something similar), which in-turn points to kite-data-1.1.jar.  When you upgrade the Kite parcel, it should have a new unversioned symlink that points to kite-data-1.1.1.jar.

Maybe it depends on what you mean by "redeploy the Oozie server". If Oozie didn't ship any changes related to this feature what a user would do to use the feature is change their oozie-site.xml, add the necessary JARs to /var/lib/oozie, and restart Oozie.
Redeploying the Oozie server is only for tarball installs, which is what is done upstream.  And /var/lib/oozie only works for CDH package or parcel installs.  Upstream Oozie doesn't have a binary distribution.  When you want to install that Oozie, you download the source tarball and compile it.  There's then a setup script that you have to run, which lets you add additional jars to the WAR file before deploying it in Tomcat.  In upstream Oozie, if you want to change or add additional jars, you have to re-run the setup script to redeploy Oozie.  In CDH packages/parcels, we do some magic stuff with exploded WAR files where you don't have to do this, and /var/lib/oozie is symlinked into the deployed WAR "file" in Tomcat.

The direction I was trying to suggest is such that instead of dumping the Kite JARs in /var/lib/oozie you would dump them wherever you like (e.g. /my/kite/jar/path) and then update some Oozie config to add /my/kite/jar/path to the classpath.
Because of Tomcat, Oozie doesn't have lots of control over manipulating it's classpath.  Currently, we've only made classes configurable in oozie-site (e.g. Here's the list of classes to load on startup, here's the list of URIHandler classes, etc), and Oozie just assumes their already on the classpath.  And for that to happen, the jars have to be in the right place as I described in my previous paragraph.

Another option is to only include the Kite jar with the CDH version of Oozie, and require users of the upstream version of Oozie download it manually.  Mixing CDH versions is unsupported, so this shouldn't be a problem; and again, the unversioned symlinks help here anyway.  We currently do this with some of the optional dependencies in Oozie, so there's precedent for that.

By the way, I'll be on vacation until Tuesday with limited access, so you probably won't get another reply from me until then.

Thanks for all the feedback and extra information @rkanter. I guess my thoughts were probably mostly rooted in my organization's current usage of kite in a mentality where kite is not a distribution-provided library. We're still mostly on CDH4 where it seems to me kite is not distribution-provided. Now that I am looking more closely it seems that kite is a distribution-provided library in at least recent CDH5 parcels. For example, I have a Quickstart VM with a CDH5.3.3 parcel on it at the moment and I see Kite is included inside it.
In our non-distribution-provided usage so far we have just picked up Kite versions as Kite project releases them (independent from CDH releases). I have not even thought to look to see the relationship between Kite releases and CDH releases. For example, what is the average time between a Kite release and a CDH parcel release that follows it? If those generally happen in tandem then clearly my whole thinking was wrong as there would always be a CDH parcel release I could pick up to get the change.
To be clear, my goal wasn't to try to support use cases of users running forks of Kite. I was targeting use cases of official Kite releases that hadn't gotten into the distribution yet. Like I indicated in my previous paragraph, perhaps the idea of Kite releases that aren't in the distribution yet is fallacy? Maybe such things don't really exist or only exist for very short periods of time.
I should also note that I am not yet as familiar as I'd like to be with the parcel concepts in CDH. I understand there is a core CDH parcel and then there are some other additive parcels you can install on top (e.g. LZO support).
I was talking to a colleague yesterday and he pointed me to this thread that helped me understand things a bit better. Parcels are expected to be disjoint and there isn't really a reliable mechanism to override something in one parcel with something else in another parcel.
I guess the idea I had before was kind of like the idea of having a parcel that overrides the kite from the CDH parcel but not exactly. I was thinking more like it was something that adds an additional Kite version to the system and then allows an Oozie configuration option that allows the administrator to use it just for Oozie. That said, the idea doesn't really make sense when you think of kite as a distribution-provided dependency across the platform (not just in the context of Oozie). If I wanted Oozie to use a new Kite version I would most likely want the whole platform to use the new Kite version. At that point what I would want would be more directly like the idea of having a parcel that overrides the CDH provided cross-platform Kite library, which is something the current parcel system doesn't support.
In the end I guess it appears to me the correct way to get a new Kite version in the context of CDH is to get a whole new CDH parcel and presumably just to wait for Cloudera to release one. Again, I haven't yet checked the relationship between Kite releases and unsolicited CDH parcel releases but if there is too big of a gap there then of course the consumer would try to coerce Cloudera to perform and unscheduled parcel packaging. It's now my understanding that it isn't terribly uncommon for Cloudera to prepare an unscheduled parcel for a customer that needs some fix before the fix is scheduled to go in a regular CDH update release.
So, I’m giving up on the idea of the configuration option being added to Oozie.  We still have a choice to make about how to incorporate these changes into Oozie:

All the code goes into Kite and we add nothing except a documentation reference to Oozie
The kite-oozie module stays in Kite and we add Kite dependencies and ooze-default.xml update to Oozie
The kite-oozie module moves to oozie (likely named oozie-kite instead since now it is an oozie module instead of a kite module) such that there is nothing related to the URIHandler in Kite itself at all except maybe a documentation reference

I presume @rdblue and @rkanter you both prefer the 2nd or 3rd option over the 1st?  Which do you prefer of the 2nd and 3rd options?

@ben-roling, I'm inclined to keep this in Kite for now and update Oozie documentation. It looks like Oozie releases are rare and we'll be able to progress much more quickly with Kite's more regular release timeline. That said, if we end up not changing anything in this for a few months, I think we should revisit the issue and move it to Oozie because we will have confirmed that it won't change much as long as it uses Kite's public API.
As far as CDH releases go, we do keep up with Kite features in those releases. CDH 5.4.x has Kite 1.0.0. Since Kite is both a client library, you can either use it in your code (whatever version you like) or use it through components that aren't libraries. Kite shipped with CDH is primarily for components like Flume that use Kite internally, but also for customers that prefer to pick up changes more slowly and not have to update their software with the upstream project.
Next steps: let's get this merged! Is there anything that needs to be fixed before adding this to Kite?

I don't believe there is anything left to fix. I pushed up a new rebased version. Should be ready to go if everything looks good on the build.

Thanks for the feedback @rdblue - it will be nice to finally have a released form of this functionality!
We can certainly revisit the possibility of moving this over to the Oozie project in the future.

I've created https://issues.apache.org/jira/browse/OOZIE-2269 to add the docs to Oozie.
Given that CDH releases ship with a single version of Kite (and the user isn't expected to update it without updating CDH), I'll probably look into having the kite-oozie jars in Oozie automatically in just CDH; that will save those users some extra steps.

@rkanter, that sounds good to me.

@bbrownz: local tests are failing because the column projection API was merged before this. Sorry! Could you update?

Sure, pushed up a quick rebase against master. Local tests looked good on the default profile.

It looks like the CDH5 profile build failed on the kite-data-flume module with the native thread error. It's likely unrelated but it might be worth kicking off another travis build just to be sure.

java.lang.OutOfMemoryError: unable to create new native thread

@rkanter - thanks for logging OOZIE-2269 - I think @bbrownz or I could probably get something for you to review on that.
If you can also get the update into CDH to include kite-oozie automatically that sounds nice.

Merged as https://github.com/kite-sdk/kite/commit/d540ead0
It's great to add support for Oozie, thanks for making it happen @bbrownz and @ben-roling!


feat: LD index and block matrix extraction for a studyLocus

Adds get_gnomad_matrix() function to study_locus.py. This function takes a study locus, finds the relevant study ID, extracts the major ancestry, and then returns the ancestry specific hail ld index and block matrices for that window.

Codecov Report
Attention: 187 lines in your changes are missing coverage. Please review.

Comparison is base (42b366c) 85.67% compared to head (e24cac1) 85.83%.
Report is 97 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #463      +/-   ##
==========================================
+ Coverage   85.67%   85.83%   +0.16%
==========================================
  Files          89       97       +8
  Lines        2101     2669     +568
==========================================
+ Hits         1800     2291     +491
- Misses        301      378      +77

Files
Coverage Δ

src/airflow/dags/common_airflow.py
90.38% <100.00%> (ø)

src/airflow/dags/dag_preprocess.py
100.00% <ø> (ø)

src/airflow/dags/finngen_preprocess.py
100.00% <100.00%> (ø)

src/airflow/dags/gwas_curation_update.py
100.00% <100.00%> (ø)

src/gentropy/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/data/__init__.py
100.00% <ø> (ø)

src/gentropy/assets/schemas/__init__.py
100.00% <ø> (ø)

src/gentropy/cli.py
91.66% <100.00%> (ø)

src/gentropy/common/Liftover.py
80.64% <ø> (ø)

... and 82 more

... and 12 files with indirect coverage changes

Is it ready for the review?

@DSuveges  I've split the function and added some defaults to make the code clearer/nicer for when I write the wrapper function, and moved them to GnomADLDMatrix as you suggested. Also updated the get_major_population() function as you suggested.
To extract the square NumPy matrix for a random study locus (5_59546948_C_T) using a 1 mega-base window in non-finish European populations takes 1m 11.4s running on my laptop.

To extract the square NumPy matrix for a random study locus (5_59546948_C_T) using a 1 mega-base window in non-finish European populations takes about 40s running on my laptop.

Nice. I'll review this PR together with the Z-score one today.


feat: modern UI

Description

Deeper black in dark mode.
Remove color splits between sidebar and main area.

Linked Issues
N/A
Additional context


Tooltips Offset in Monobank Container

When used alongside Monobank and viewing the contents of a monobank, the index tooltips are strangely offset to the left.

latest.log

This would be something caused by Monobank's render state that EMI can't control, best to report on their repo.


Show the benchmark result with table?

Background
It would be nice if there is a table showing the result of the benchmark between each web framework.
Expectation
It is something like that:

framework
Latencies.Avg
...
Requests.Total
...
Transfer.Total
...
Maximum Memory Usage

actix-web
0.50ms
...
30178057
...
3.65 GB
..
13.7 MB

...

Anything else
I am willing to add this feature.

All pull requests are welcome.

Suggestion makes sense. I plan to add this if no one comes up with a pull request in few weeks.

Can you publish that table on Readme?

@frederikhors I'll put comparison table at the top of result md file.

Can you write here when done, please?

It is done.


WIDS: ValueError: signal only works in main thread

Just clicking the WIDS menu generates an error:
[2019-01-25 19:07:13,852] ERROR in app: Exception on /api/wids [GET]
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/flask/app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1815, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1718, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python2.7/site-packages/flask/app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "run.py", line 194, in wids
    self.wids_handle = Wireless_IDS('atear_wids')
  File "/usr/share/atear/module/wids.py", line 90, in __init__
    signal.signal(signal.SIGTERM, signal_handler)
ValueError: signal only works in main thread

And of course nothing appear.

If you have not solved the problem.
That is the solution.
Need flask version 0.12.
Command: pip install Flask==0.12


Fix CPU/Memory usage metrics when using prometheus operator.

According to those graphs https://github.com/coreos/kube-prometheus/tree/master/manifests POD cpu and memory should be calculated differently.
Fix #607

I have add additional fix to cluster graphs.

@nevalla PTAL


Dictionary Should Contain Sub Dictionary is missing ignore_order and ignore_key

Currently https://github.com/robotframework/robotframework/blob/master/src/robot/libraries/Collections.py#L839 we are missing out on ignore_order already done for
    def lists_should_be_equal(self, list1, list2, msg=None, values=True,
                              names=None, ignore_order=False, ignore_case=False):

Ref : https://github.com/ngoan1608/robotframework/commit/1d852208255d1245cce33a34c700478455cc7298#diff-0bb57664ba32d4e2b91c6435cf0b867d630c2db282af83004073303030775bd1
Adding as well ignore_key would be much appreciated since we might deal with ID's and timestamps, and in such cases those keys are to be ignored.

Although Python nowadays preserves dictionary order, the order doesn't generally affect equality and it shouldn't matter with this keyword either. Do you have a concrete example where ignore_order would be needed?
ignore_keys could be added for consistency with Dictionaries Should Be Equal. I consider it very low priority, though, because with Dictionary Should Contain Sub Dictionary the second dictionary doesn't need to contain all keys that the first dictionary contain in the first place. If there's a key you'd like to ignore, you can easily remove it from the second dictionary already now. Alternatively you can use Dictionaries Should Be Equal that already supports ignore_keys. Do you have examples where ignore_keys with Dictionary Should Contain Sub Dictionary would be convenient?
If we agree adding this functionality would be a good idea, can you provide a pull request implementing it?

In my case I'm querying an API (fastapi) where item order (in case of lists) and key order (in case of dictionaries)  is not enforced.
The DUT , after a reboot will give a different order making the test very brittle and causing it to fail.
Example :
Get the safesearch created profile by ID
    API GET dictionary request comparing the response  ${ROOT}    webfilter/api/v1/config/profiles/1    ${POST_PROFILE_SAFESEARCH_RESPONSE}

API GET dictionary request comparing the response
    [Documentation]       It makes a GET request to the specific baseurl and endpoint and compares the API response (should be a dictionary!)
    ...                   to another dictionary defined in (json_response).
    [Arguments]    ${baseurl}    ${endpoint}    ${json_response}
    ${url}=    Set Variable    ${baseurl}${endpoint}
    ${response}=    GET On Session   url=${url}    alias=get_login
    ${API_SERVER_RESPONSE_HEADERS}=    Create Dictionary    Server    uvicorn    content-type    application/json    X-Robots-Tag    noindex, nofollow    Connection    Keep-Alive
    Dictionary Should Contain Sub Dictionary    ${response.headers}    ${API_SERVER_RESPONSE_HEADERS}
    Should Be Equal As Strings    ${response.status_code}    200
    Run Keyword If    '${response.status_code}' != '200'    Log Variables
    ${evaluated_response}    Evaluate    json.loads('''${json_response}''')
    Dictionary Should Contain Sub Dictionary    ${response.json()}    ${evaluated_response}
    Should Be Equal As Strings    ${response.reason}    OK

This is the error that I'm getting :
Get the safesearch created profile by ID                              | FAIL |
Following keys have different values:
Key safesearch: ['DUCKDUCKGO', 'GOOGLE', 'BING'] != ['DUCKDUCKGO', 'BING', 'GOOGLE']

This is the request
 {"id":null,"antivirus":true,"blacklist":[],"allowed_domains":[],"blocked_domains":[],"safesearch":["GOOGLE","DUCKDUCKGO","BING"],"name":"safesearch"}

So basically the API might return different orders for the search engines.
In this case ignore_order would be needed.

If we agree adding this functionality would be a good idea, can you provide a pull request implementing it?
I would love to and would have already done it but I don't have the right confidence with python.

So you don't want to ignore order of dictionary keys but instead want to ignore order in their values? I guess something like ignore_value_order could be added, but I don't consider it too high priority. It should be added to Dictionaries Should Be Equal as well.
Is there a reason you couldn't get those values and use Lists Should Be Equal that already supports ignoring order?

So you don't want to ignore order of dictionary keys but instead want to ignore order in their values?

Exactly, and yes ignore_value_order would be appropriate.
As for Lists Should Be Equal  I can confirm that it works (even without adding ignore_order=True and it seems that by default it ignores the order of the values which in my case is appreciated.
Thanks allot for the quick replies and even more for providing a tool like Robot Framewok, I truly mean it.

We got PR #5220 implementing this. It looks good but I cannot review it properly now. I added this issue to RF 7.2 scope and review it later.

I finally got PR #5220 reviewed. It has an unrelated change to sorting unsortable items which should be removed (and possibly added as part of a separate issue and PR), but it looks very good otherwise.


New Error function overload. Error("Custom error message")

These changes were agreed along PA client team in advance.

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll


@liveblocks/react-tiptap: components not displaying when using React compiler and/or shouldRenderOnTransaction: false

Describe the bug
When using either or both React compiler or shouldRenderonTransaction: true on Tiptap's useEditor, the FloatingComposer fails to appear.
When re-running my dev server without reactCompiler and with shouldRerenderOnTransaction: true, the component works as expected.
To Reproduce
Steps to reproduce the behavior:
Just set  shouldRerenderOnTransaction: false when using Tiptap's useEditor,
  const editor = useEditor({
    extensions: [liveblocks, StarterKit],
    immediatelyRender: false,
    shouldRerenderOnTransaction: false,
  });

Issue is similar when setting
  experimental: {
    reactCompiler: true,
  },

in next.config.ts
/
Expected behavior
Floating composer should be displayed when triggering editor.chain().focus().addPendingComment().run()
Environment (please complete the following information):

@tiptap 2.9.1.
next 15.0.2
@liveblocks 2.11.0

Additional context
The issue spawns from using:
  const storage = editor?.storage.liveblocksComments as CommentsExtensionStorage | undefined;
  const showComposer = !!storage?.pendingCommentSelection;

in the FloatingComposer (lines 32-34).
Tiptap 2.5 introduced performance optimisations which requires the use of useEditorState() to get the latest editor state when shouldRenderTransaction is set to false (cf announcement  and doc))
Suggested fix:  in FloatingComposer replace showComposer by:
const currentEditorState = useEditorState({
    editor,
    selector: (ctx) => ({
      showComposer: !!ctx.editor?.storage.liveblocksComments?.pendingCommentSelection,
    }),
    equalityFn: (prev, next) => {
      if (!next) return false;
      return prev.showComposer === next.showComposer;
    },
  });
const showComposer = currentEditorState?.showComposer;

This fixed the issue for me and seems to work either with or without the react compiler and with shouldRerenderOnTransaction either true or false.
It may be something you would need to consider for the other components of the @liveblocks/react-tiptap package.
It may also be worthwhile mentionning in the documentation that when using TipTap's editor with shouldRerenderOnTransaction: false, things like editor.isActive("liveblocksCommentMark") won't work, and the user must use useEditorState(), as described above.
Cheers

Same issue with FloatingThreads
Managed to get it working using useEditorState to get the pluginState (line 64). There may be some way to improve performance and unncessary re-renders by modifying the equalityFn, but I'll leave it at that for now.
before
  const pluginState = editor ? THREADS_PLUGIN_KEY.getState(editor.state) as ThreadPluginState : null;

after
  const currentEditorState = useEditorState({
    editor,
    selector: (ctx) => {
      if (!ctx?.editor?.state) return null;
      //only necessary to get the plugin from the editor state because I don't have access to the plugin directly in my node_modules.
      //in the package use: const state = THREADS_PLUGIN_KEY.getState(ctx.editor.state) as ThreadPluginState
      const plugin = ctx.editor.state.plugins.find(
        //@ts-expect-error, this works but the type is not correct. Not sure why.
        (p) => p.key === "lb-threads-plugin$"
      );
      const state = plugin?.getState(ctx.editor.state);

      return {
        pluginState: state,
      };
    },
    equalityFn: (prev, next) => {
      if (!prev || !next) return false;
      return isEqual(prev.pluginState, next.pluginState);
    },
  });

  const pluginState = currentEditorState?.pluginState;

Thanks so much for the suggestion, we will likely implement the useEditorState. I had come across this bug while testing with Blocknote and tried solving it with useSyncExternalStore, but this is much better than that.

Fantastic, looking forward to it!
Also applied the same fix from FloatingThreads to AnchoredThreads and works like a charm.

The PR is up, the fix should go out in 2.11.1. Thanks again for the report.


Update istio.io/api dependency in vendor.

Run dep ensure -v -update istio.io/api to generate this PR.
#5059

@incfly: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
f92f05ab10531b30dc6cd569e793f3a8293f0c28
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@diemtvu I found the https://github.com/istio/api/pull/456 removes some types like EndUserAuthnSpec but they are still used in the mixer's code. This is why some tests failing above. Would you continue to remove istio/istio reference of those fields? Or any other suggestion to proceed?

@incfly Thanks for syncing the API repo.
I think you have to either wait for the cleaning of istio/api#456 is done or sync this PR to an earlier commit in istio/api. The latter doesn't make sense for your purpose of this PR, so probably just wait for some time.

You might have to wait until the mixer change that's breaking in istio/api is reverted..

api updated to master commit.


custom font not rendered

Hi everyone,
I have html template, like this
`

The way I do it is I install the fonts on the server running the app.
I use Times New Roman, Arial on an Ubuntu 18.04 server.
You can install these fonts with
sudo apt-get --reinstall install ttf-mscorefonts-installer


Functionize token verification

Please review my implementation of verify_token() as I currently have no way of testing it myself @ImShady

I moved the function to slack.py. Please review my changes @ImShady

I made the changes you suggested @ImShady


Extra setup keys and sub-requirement files for Ophys

A first step towards #94 specific to demonstrating the usage for the ophys interfaces.
The /datainterfaces/ophys level requirements specifies the roiextractors version needed, and each /ophys/<format name> specifies the specific requirements for each particular format.
The setup now includes the extra installation keys for each format name as they appear from the /ophys/ directory, as well as a general ophys key that installs everything you would need to use any Ophys interface.

@CodyCBakerPhD so you would prefer to have empty requirements.txt files to indicate that this data modality has no additional requirements? I take it you prefer this to just not having a requirements file for that data type

so you would prefer to have empty requirements.txt files to indicate that this data modality has no additional requirements

That does mimic the approach of leaving empty __init__.py files required of package setup tools... which I've maybe gotten used to...
The advantage is to avoid user confusion from being able to install with something like pip install neuroconv[pyopenephys] but not be able to make a call like pip install neuroconv[spikeglx]...
Of course to avoid that you could have simply defined the spikeglx key in the defaultdict in setup, but to do that for every interface that does not have extra requirements removes the benefit of this all being taken care of 'automatically' a the setup level...
So be defining an empty requirements.txt file there, the glob takes care of everything at the expense of having a bunch of empty files cluttering up each submodule...
Then again, at least then each submodule will have a very standard appearance (__init__.py + requirements.txt + <interface name>_utils.py + <interface name>.py)...
IDK what the best solution is, that's just my thought process right now

Of course to avoid that you could have simply defined the spikeglx key in the defaultdict in setup, but to do that for every interface that does not have extra requirements removes the benefit of this all being taken care of 'automatically' a the setup level...

I feel like you could find a way to do this automatically. Something like:

for modality in ['ecephys', 'ophys', 'icephys', 'behavior']:
    for data_type in os.listdir(datainterfaces_path / modality):
    modality_requirements = []
        requirements_path = datainterfaces_path / modality / data_type / 'requirements.txt'
        if os.isfile(requirements_path):
            requirements = read_requirements(requirements_path)
            extras_require.update({data_type: requirements})
            modality_requirements.extend(requirements)
        else:
            extras_require.update(data_type=[])
    extras_require.update({modality: list(set(modality_requirements))})
extras_require.update

That's an option, if you want it. It might be better than having a bunch of empty files.

That's an option, if you want it. It might be better than having a bunch of empty files.

Sure, but then we're not making full use of recursive globbing - instead, we structurally define the type of recursion to perform on the package.
I guess I don't really care either way - any thoughts from the rest of the team @h-mayorquin @weiglszonja @alejoe91 @luiztauffer ?

@CodyCBakerPhD I like this organization of dependencies a lot!
Maybe we should discourage the use of full, or even not have it at all? It would decrease the chances of incompatible dependencies, and make it easier to spot these incompatibilities once they occur within specific combinations of datainterfaces

Personally I think I'd be fine with just one of these steps per each modality.

I agree one step per modality sounds good enough for the CI tests

Sure, but then we're not making full use of recursive globbing - instead, we structurally define the type of recursion to perform on the package.

I don't see any clear objective advantage in either way, it looks like it will boil down to aesthetics feelings:
having a bunch of functionally useless empty files vs explicit organization consistency of data interfaces plugins
I slightly favor the latter.

I have some comments in #94 where I advocate for a more gradual approach to this changes that take into account recent developments in python packaging.

OK the minimized and modularized installation strategy is ready for review here...
requirements-minimal.txt is now scrapped down to the bare minimum of PyNWB/DANDI and higher version pins of their dependencies that we require (like scipy/h5py).
All other external dependencies are added to plug-in style individual requirements.txt files at the corresponding levels across the repo, but not including empty files if a given interface doesn't require anything extra.
Current strategy for how this affects testing is to...
Install bare minimum dependencies -> test bare minimum
Go through each modality and install according to modality key -> test everything that modality covers (not including actual data tests; mostly just SpikeInterface or ROIExtractors tools, or OpenCV stuff for behavior).
After those, everything in full should be installed, so run all data tests like usual.

Go through each modality and install according to modality key -> test everything that modality covers (not including actual data tests; mostly just SpikeInterface or ROIExtractors tools, or OpenCV stuff for behavior).

Aren't the data tests the most important ones as people install the modality to do conversions over there? Isn't that what we should guarantee? that the conversions in that modality work with the installation of that modality.

Aren't the data tests the most important ones as people install the modality to do conversions over there? Isn't that what we should guarantee? that the conversions in that modality work with the installation of that modality.

That's why I asked for a one-liner to use the doctests, which will run on actual data.
There's no way, currently, to use the full tests on data to only run a single format, but that could be something to think about. We've always liked the use of parametrized to reduce code there, however, but IDK ultimately we just have to do what we think is best for testing.
Going to transition the discussion of how to do this into https://github.com/catalystneuro/neuroconv/pull/115, though, since that's where it's best.


Is it possible to extract all the accounts that liked a Media?

Today it is possible to click on the Like count and see the accounts that liked a specific photo or video. Is it easy to scrape this info?

Yes, need this function too.


Pandoc and OPS custom markdown extensions

Hi,
I am using the Docs Authoring Pack for VS Code.
The extra functionality that is of greatest use to me is including files: [!INCLUDE[sample include file](sample.md)].
The preview works great, rendering the included files. How should I build? to HTML, or pdf, or LaTeX.. Neither markdown-it nor pandoc recognize the include syntax.
Thanks!
Related questions are:

Why are alerts not parsed/styled in preview? e.g.

> [!IMPORTANT]
> Essential information required for user success

shows up as [!IMPORTANT] Essential information required for user success indented.

How do I use TOC generators with includes? the Markdown TOC extension will produce a table of contents that does not include headings in included files.

* Why are alerts not parsed/styled in preview? e.g.

That was fixed in https://github.com/microsoft/vscode-docs-authoring/issues/200

* Why are alerts not parsed/styled in preview? e.g.

That was fixed in microsoft/vscode-docs-authoring#200

Thanks! I just needed to reload.

Hi @annedranowski
There is the Docfx system which is open source to build pages from markdown. https://dotnet.github.io/docfx/
What is your business goal? These tools are meant for publishing on docs.microsoft.com. So it may not be designed to accommodate custom publishing workflows.
I'm not familiar if includes and the other extensions like the Important boxes are part of that platform natively. I think the docs extensions go further than Pandoc would know, since its something above and beyond standard Markdown.
I don't think we have an open source build system for the current docs build platform. The Docs platform uses a different flavor of markdown now - Markdig.
Thanks, Jason


chaos classs middleware

For fun things like authors, version. etc.
Most of this stuff can be lifted from skydns

easy to add, will be fun

configure like:
chaos author1 author2 ...
author can be free form text. We be nice to do a version thing as well,
chaos version [author...]

Done with #43


Compile time property support validation of cascaded styles for UI element types vs use of "TargetType"

The following is a request for compile-time property support checking of predictor styles OR allow multiple target types to be specified for a style.
In an Avalonia Application, I have several general base styles that apply to most controls or UI elements (but not all, naturally)
In parts of the XAML I build new styles which inherit from one of these base styles which will apply to and are valid for a small subset of UI elements.  If I don't use "TargetType" I will not find out that a property of one of these styles is not supported by a UI element to which it has been applied through a runtime exception.  This is quite annoying.  I can use "TargetType" but only one UI element can be specified in a style specification.  This awkwardness has led to excessive duplication of otherwise virtually identical code just so that compile-time property support checking can occur.
Several approaches to this conundrum come to mind.
Currently general styles without "TargetType" are intended to apply broadly but not everywhere.  Subtypes styles also without "TargetType" can be derived from general styles.  This is all possible now but you only know if you mess up when a runtime error is thrown.
In segments of the XAML code I want one of these derived styles to apply to several UI elements which "should" support the cascaded style setter properties BUT I can specify only 1 "TargetType" at that point AND the compiler will ONLY" check that specific style definitions and overrides.
First. As far as I can determine is that, even though the compiler has likely walked back through the style tree, the  TargetType property support tests on the predecessor parent styles are not performed for the specified "TargetType" which forces a requirement to put "TargetType" in all of the predecessor styles which pretty well negates some of the usefulness of cascading styles.
What I would like to happen are two upgrades. These, in theory, do not affect any current implementation, but enhance the development by reducing significant XAML code bloat.
Change Request 1.  Add the capability to delay applying a "TargetType" to when you want to create a style for that target type AND then, during the style tree walk-back traversal verify that the properties visible at that point are supported by the UI element specified in the "TargetType".  This keeps the parent styles clean and reusable.
Change Request 2.  Allow enumeration of several "TargetType" to be applied to an intermediate inheritable style with the same visible property support checking being performed for each of the supplied TargetType"  The intent of this is that this intermediate style can only be applied to UI elements of the enumerated types.
Concept.   When applying style to a UI element the styles tree used must be general (without "TargetType") or the enumerated "TargetType" must exist in that UI element style parent branch or a compile-time error will be thrown.
Now, after writing this up and thinking about it, compile time intrinsic property support checking of the styles parent tree of a UI element should likely be the default thus totally obviating the need for "TargetType"

cc @grokys for better help here.
Styles don't have TargetType, I assume you mean ControlTheme. Or if you meant actual Style with Selector, then TargetType is retrieved from the Selector, everything else works pretty much the same:
Primarily TargetType is used for three cases.

Validate when it's applied on specific control (disallow applying Button theme on ListBox...).
And make Setters strongly typed. So, Setter with BorderBrush property can refer to specific TemplatedControl.BorderBrushProperty or Border.BorderBrushProperty (which are the same property).
Apply this TargetType on the ControlTemplate inside if present. It's needed there to make TemplatedBindings work with strongly typed properties (similarly to the previous case).

Meaning, you can define ControlTheme/Style with some abstract TargetType and use full property names in the setters:
<Style Selector=":is(Control).myStyle">
   <Setter Property="Border.BorderBrush" Value="Green" />
   <Setter Property="TextElement.Foreground" Value="Black" />
   <Setter Property="Button.IsDefault" Value="True" />
</Style>

This style can be applied on any control. And if this control has BorderBrush - this setter will work. If this control has Foreground - it also will work. And if this control has IsDefault (basically, only Button delivered) - last selector will also work.
So, this way you can create styles/controlthemes that can be applied on multiple control types. It just needs to be strongly typed in the end.
Not related to Styled, but related to ControlTheme, they are usually applied by ControlTheme resource key, like in WPF, which is unrelated to TargetType.

@maxkatz6 we need this in the docs explained as written above. Tbh I didn't knew this will work. I'll add it to our list of v11 docs.
Just wow.

The combination of cascading styles in Avalonia is "apparently" rich in capability and thus would be highly useful but, as you indicate, the documentation and examples are both incomplete and weak with respect to the developer.  Here I'm using the word styles and templates interchangeably even though they are not.  Learning CSS was not easy in part because of the syntax but also because of the cascading rules.  The same is true here.   but also Obviously you can place styles in one or more style folders.  App.xaml seems to be a root place for the styling cascade but I cannot find any concrete example.  As to examples, we need a couple of accurate examples of the various places you can define cascading styles, how to apply a parent style to a child then the myriad ways to apply that child to one or more compatible controls.  The richness of this UI paradigm is becoming more obvious the more I dig into the inadequately exampled documentation.  Consolidating the explanation of 'do this to do that and apply it in one of the following ways' is currently, at the level I've researched, seems to leave me hanging most of the time.  If I've overlooked something that I needed to study or relevant examples please feel free to whack my knuckles with a virtual ruler and tell me where to look to learn more.


Injection not reflecting in Simulator with no error in Logs

Hi, Please help,
I am trying injection in Xcode10 but its not reflecting in simulator.
Details:
Xcode: Version 10.0 (10A255)
Downloaded InjectionIII from App Store
Downloaded GettingStarted.zip ios project from http://johnholdsworth.com/injection.html
Using Bundle(path: "/Applications/InjectionIII.app/Contents/Resources/iOSInjection10.bundle")!.load()
What did I do:
Change background color from yellow to red
Logs:
Injection connected, watching /Users/vishun/Downloads/GettingStarted/**
*** Compiling /Users/vishun/Downloads/GettingStarted/GettingStarted/MasterViewController.swift ***
Loading .dylib - Ignore any duplicate class warning...
objc[40448]: Class _TtC14GettingStarted20MasterViewController is implemented in both /Users/vishun/Library/Developer/CoreSimulator/Devices/5B029176-5E19-4F0F-BBC6-1F1BDE0AB229/data/Containers/Bundle/Application/78A8E58F-DF21-4823-A66E-603EAEB93CD5/GettingStarted.app/GettingStarted (0x109bc8de0) and /Users/vishun/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval101.dylib (0x1285f56c8). One of the two will be used. Which one is undefined.
Injected 'GettingStarted.MasterViewController'
*** Compiling /Users/vishun/Downloads/GettingStarted/GettingStarted/AppDelegate.swift ***
Loading .dylib - Ignore any duplicate class warning...
objc[40448]: Class _TtC14GettingStarted11AppDelegate is implemented in both /Users/vishun/Library/Developer/CoreSimulator/Devices/5B029176-5E19-4F0F-BBC6-1F1BDE0AB229/data/Containers/Bundle/Application/78A8E58F-DF21-4823-A66E-603EAEB93CD5/GettingStarted.app/GettingStarted (0x109bc8ea8) and /Users/vishun/Library/Containers/com.johnholdsworth.InjectionIII/Data/eval102.dylib (0x12860b658). One of the two will be used. Which one is undefined.
Injected 'GettingStarted.AppDelegate'

Can anyone please help me on this?

@vishundayal did you manage to solve your issue ?

I had the same problem. @vishundayal Did you solve?


Object(...) is not a function

Bug report
What is the current behavior?
After receiving the update to 4.44.0 our application cannot start anymore. In one of our modules, we export a function as the default export. However, it seems webpack is now treating the default as an object, which then cannot be called.
If the current behavior is a bug, please provide the steps to reproduce.
I couldn't come up with a minimal repro example. However, this worked in 4.43.0 and stopped in 4.44.0 so I expect that it has something to do with the changes in that particular release.
What is the expected behavior?
Function default exports should work.
Other relevant information:
webpack version:  4.44.0
Node.js version: 12.x
Operating System: Whatever "Vercel" uses
Additional tools: -

Sorry without reproducible test repo we can't help

Apparently "fix bug in sideEffects optimization when using export * from "non-esm" and a default export." in the latest release was the culprit.


[SSR] Sharing Externals

Next.js in server builds make all node modules external modules to make the build smaller/faster
This presents a problem for module federation when sharing, if its external - its not added to share scope.
Theres a few options;
First we need to include any shared modules in webpack build for server.
In the past - ive done so like this
          // get share keys from user, filter out ones that need to be external
          const internalizableKeys = Object.keys(
            federationPluginOptions.shared
          ).filter((key) => {
            return key !== "react";
          });
          // take original externals regex
          const backupExternals = config.externals[0];
          // if externals is a function (like when you're not running in serverless mode or creating a single build)
          if (typeof backupExternals === "function") {
            // replace externals function with short-circuit, or fall back to original algo
            config.externals[0] = (mod, callback) => {
              if (!internalizableKeys.some((v) => mod.request.includes(v))) {
                return backupExternals(mod, callback);
              }
              return Promise.resolve();
            };
          }

However, next and react must remain external. This forced me to use a loader to patch share scope during runtime to include those keys
// language=JS
const shareNextInternals = `if (process.browser) {
  if(!__webpack_share_scopes__.default) {
     __webpack_init_sharing__('default');
  }
    window.__webpack_share_scopes__ = __webpack_share_scopes__
    if(!__webpack_share_scopes__.default.react) {
    Object.assign(__webpack_share_scopes__.default, {
      "react": {
        0: {
          loaded: true,
          get: () => Promise.resolve(() => require("react")),
        },
     },
    })
  }
  Object.assign(__webpack_share_scopes__.default, {
    "next/link": {
      [next.version]: {
        loaded: true,
        get: () => Promise.resolve(() => require("next/link")),
      },
    },
    "next/script": {
      [next.version]: {
        loaded: true,
        get: () => Promise.resolve(() => require("next/script")),
      },
    },
    "next/router": {
      [next.version]: {
        loaded: true,
        get: () => Promise.resolve(() => require("next/router")),
      },
    },
    "next/head": {
      [next.version]: {
        loaded: true,
        get: () => Promise.resolve(() => require("next/head")),
      },
    },
    "next/dynamic": {
      [next.version]: {
        loaded: true,
        get: () => Promise.resolve(() => require("next/dynamic")),
      },
    },
  });
} else {
  if(process.env.NEXT_PHASE !== 'phase-production-build') {
     __webpack_init_sharing__('default');
  }

  if(!__webpack_share_scopes__.default) {
      __webpack_share_scopes__.default = {}
  }
  global.__webpack_share_scopes__ = __webpack_share_scopes__
  const reactRequire = require("react");
  const nextLink = require("next/link");
  const nextScript = require("next/script");
  const nextRouter = require("next/router");
  const nextHead = require("next/head");
  const nextDynamic = require("next/dynamic");
  if(!__webpack_share_scopes__.default.react) {
    Object.assign(__webpack_share_scopes__.default, {
      "react": {
        0: {
          loaded: true,
          eager:true,
          get:()=> ()=> reactRequire,
        },
     },
    })
  }
  Object.assign(__webpack_share_scopes__.default, {
    "next/link": {
      0: {
        loaded: true,
        get: () => () => nextLink,
      },
    },
    "next/script": {
     0: {
        loaded: true,
        get: () => () => nextScript,
     },
    },
    "next/router": {
      0: {
        loaded: true,
        get: () => ()=> nextRouter,
      },
    },
    "next/head": {
      0: {
        loaded: true,
        get: () => ()=> nextHead,
      },
    },
    "next/dynamic": {
      0: {
        loaded: true,
        get: () => ()=> nextDynamic,
      },
    },
  })

  try {
    global.REMOTE_CONFIG = Object.assign(global.REMOTE_CONFIG || {},process.env.REMOTE_CONFIG)
  } catch(e) {
    // do nothing
  }
}
`;

module.exports = function (source) {
  const FederationPluginInstance = this._compiler.options.plugins.find(
    (plugin) => {
      if (
        plugin.constructor &&
        plugin.constructor.name === "ModuleFederationPlugin"
      ) {
        return true;
      }
    }
  );
  let manualInitializationString = [];
  if (FederationPluginInstance && FederationPluginInstance._options.remotes) {
    manualInitializationString.push("if (process.browser) {");
    Object.keys(FederationPluginInstance._options.remotes).forEach((remote) => {
      manualInitializationString.push(
        `window.${remote}?.init(__webpack_share_scopes__.default);`
      );
    });
    manualInitializationString.push("};");
  }
  manualInitializationString = manualInitializationString.join("\n");
  return shareNextInternals + manualInitializationString + source;
};

Im open to suggestions on how to solve or improve sharing of next internals when on server build.
One idea i had was to create a new runtimeRequirement, adding another webpack closure and function to the webpack runtime which assigns react,react-dom, and next internal packages to the object during startup.
The other possible option is to exclude these from share scope on the server which should make the remoteEntry use require(react) natively.
This would only be used for the react and next libraries themselves - everything else needs to be bundled as we cannot guarentee these packages will exist in the hosts node_modules

Resolved under SSR branch


changed kebabCase to kebab-case

I think it makes more sense to show visually what is actually created. In the current form, it is somewhat confusing.

Makes sense.


added while_inside_goto test

#66

@yegor256, does the new rules of merging violate on the other branches?
the same problem is here

WARNING! the last commit need to rollback


Send messages from DevTools to BG via one-time messages

This is one more step towards #44.
After this commit, extension sends info from DevTools to bachkround context via one-time messages, persistent ports are used only for sending data from background to DevTools. A follow-up PR will make those persistent ports semi-persistent.
This happens to fix #59.

Closing as obsolete.