EDSScript.js StartEDS()  updateBasket(jbib_list.length-1) uses string instead of array

As I mentioned on wizzyrea's issue, "updateBasket(jbib_list.length-1)" is actually using the length of the "bib_list" string coming from local storage rather than the length of the array created by splitting that string on the slash.
https://github.com/ebsco/edsapi-koha-plugin/blob/master/Koha/Plugin/EDS/js/EDSScript.js#L102

The plot thickens!
Sometimes the bib_list in jStorage is a string and sometimes it's an array!
If you add/remove on the search result page (opac-search.pl), it'll add/remove as strings.
However, if you add 2 records to the cart, open the cart, and remove one item, the "bib_list" value in local storage will now be an array!!!

Four examples of "bib_list" being set:

$.jStorage.set("bib_list",QueryString('bib_list'),{TTL:edsConfig.cookieexpiry601000});
$.jStorage.set("bib_list","",{TTL:edsConfig.cookieexpiry601000}); // added this line
$.jStorage.set("bib_list",$.cookie("bib_list"),{TTL:edsConfig.cookieexpiry601000});
$.jStorage.set("bib_list",$.cookie("bib_list"),{TTL:edsConfig.cookieexpiry601000});

2-4 treat "bib_list" as a string, but 1 treats it as an array. Of course, it's worth noting that it puts the whole querystring in as a single array element.

It looks like "document.cookie = 'bib_list='+jbib_list;" works with jbib_list as a string or an array, because the interpreter coerces the array into a string when concatenating the values.
But naturally "jbib_list.split" will work on a string but not an array...
And "basketcount" will be defined in opac-search.pl because the jquery populates that variable with an HTML object, whereas in opac-basket.pl, it's undefined.,, so the cookie will be reset on opac-search.pl regardless of whether or not "bib_list" is a string or an array... but the updateBasket in that block will never work... because jbib_list.split will fail for an array... and if a string is used it will update the basket count with the length of the string because of "updateBasket(jbib_list.length-1);"
I figure it makes more sense to just handle bib_list as a string.
Of course, since the local storage never expires, it's probably necessary to include some data type detection when doing $.jStorage.get("bib_list")....

Thanks for looking into this.
These 2 lines are now commented out in the latest version which fixed cart count.
//if (basketcount != jbib_list.split('/').length - 1)
//updateBasket(jbib_list.length -1);
bib_list is stored in jStorage because the cookie path/scope is /cgi-bin/koha/ but the plugin path/scope is plugin/Koha/Plugin/EDS/opac/ so the cart values are not accessible.
Wanted to avoid changing the path of bib_list to / as it could have unintended consequences.


Add support for external file config

Is your feature request related to a problem? Please describe.
There are several cases when several schema documentations need to be generated.
The current workaround is to use CLI parameters, however this can quickly become tedious to maintain.
Describe the solution you'd like
Using external config file will make easier to maintain several configurations. And supporting JS files would even allow sharing configuration between config.
The config resolution will be prioritized as following (starting by highest priority):

CLI parameters
CLI parameter config referring to external config file 🆕
Plugin options in Docusaurus config file
config plugin option in Docusaurus config file 🆕

The config file will respect the current plugin config structure.

Not required. This can be done out of the box using JS, see demo: https://github.com/edno/graphql-markdown-demo/blob/main/docusaurus.config.js#L4

I'm trying to use the custom cli commend graphql-to-doc but it doesn't seem to have the --config file argument. I'm calling the command from the root of a monorepo, but need to use a project config file (inside apps/docs). How can I do that with the JS out-of-the-box?

Hi @Jacse
I took some liberty with that one, but this is very close to out-of-the box as with JS you can require any JS/JSON file
And example is given in the demo project: https://github.com/edno/graphql-markdown-demo/blob/main/docusaurus.config.js#L4
If you want to support a command line, you should then replace the same line by a value coming from an environment variable:
// this is a simplified code
// production code should have error handling with fallback
graphqlMarkdownConfigFile = process.env["GQL_MD_CONFIG"];
const graphqlMarkdownConfig = require(graphqlMarkdownConfigFile);

You would then call it like:
GQL_MD_CONFIG="./graphql-markdown.config.js" graphql-to-doc


Fixes the path to jquery.min.js

jquery.min.js, if installed through bower, is now located in bower_components/jquery/dist/
this commit changes the path in example/index.html

I took all the time needed to review this...
:clock1: :clock2: :clock3: :clock4: :clock5: :clock6: :clock7: :clock8: :clock9: :clock10: :clock11: :clock12:
I can now say it's good! Thanks!


Allow auto-accessor inference from constructor/static-block

This removes check that prevented type inference for auto-accessors when they were missing in initializer so that auto-accessors may also have their types inferred from the body of the constructor (for instance auto-accessors) or static {} block (for static auto-accessors).
Fixes #59728

Does this need more checking like in #59732?

Does this need more checking like in https://github.com/microsoft/TypeScript/pull/59732 (which also targets this issue?) Or is this a dupe?

Essentially this PR here is a duplicate of mine. Both pass the same tests. My fix was slightly more complex as I didn't realize I could just call getWidenedTypeForVariableLikeDeclaration to get the same effect so I reused some other piece of logic by wrapping it in a helper.

Does this need more checking like in #59732 (which also targets this issue?) Or is this a dupe?

Essentially this PR here is a duplicate of mine. Both pass the same tests. My fix was slightly more complex as I didn't realize I could just call getWidenedTypeForVariableLikeDeclaration to get the same effect so I reused some other piece of logic by wrapping it in a helper.

Ah, I'd missed that there was an existing PR for this. Closing in favor of #59732


It doesn't work on iOS

After update to
"react": "^15.2.0",
"react-native": "^0.28.0"
it shows empty datepicker on iOS.

I have the same issue on the simulator. But it is working fine on the actual device.. 😕

#13. Because DatePickerIOS didn't have specific width(Removed hard-coded DatePicker width
).
You can use customStyles to overwrite the align styles:
customStyles={{
  datePicker: {
    alignItems: 'stretch'
  }
}}

And will resolve it in v1.3 this week.


[ISSUE] Databricks Python SDK Group API always returns None as members in Azure Account

Description
Databricks Python SDK Group API always returns zero members in Azure Account. No issues in AWS.
Reproduction
AWS returns normal results
aws_account_client = AccountClient(
    host="https://accounts.cloud.databricks.com/",
    account_id="[REDACTED]",
    client_id="[REDACTED]",
    client_secret=dbutils.secrets.get(scope="[REDACTED]", key="[REDACTED]"),
)
aws_account_client.groups.list()

[
Group(display_name='[REDACTED]', entitlements=None, external_id=None, groups=None, id='[REDACTED]', members=[ComplexValue(display='[REDACTED]', primary=None, type=None, value='[REDACTED]'), ComplexValue(display='[REDACTED]', primary=None, type=None, value='[REDACTED]'), ...], meta=None, roles=None),
...
]

What Azure returns has always None as members.
azure_account_client = AccountClient(
    host="https://accounts.azuredatabricks.net/",
    account_id="[REDACTED]",
    azure_tenant_id="[REDACTED]",
    azure_client_id="[REDACTED]",
    azure_client_secret=dbutils.secrets.get(scope="[REDACTED]", key="[REDACTED]"),
)
azure_account_client.groups.list()

[
Group(display_name='[REDACTED]', entitlements=None, external_id=None, groups=None, id='[REDACTED]', members=None, meta=None, roles=None),
...
]

We keep the AWS Databricks account and Azure Databricks account in the same group membership (pushed and synced from one identity provider), which I have verified multiple times.
However, it always returns None as members. And if the target group really has zero members, it should return an empty list, not None, right? It makes me think that this is a bug.
Expected behavior

Groups API should return non-None members at least for a non-empty group

Is it a regression?

Tested it in both v0.6.0 and v.0.13.0

Debug Logs
After setting logging to DEBUG
logging.basicConfig(level=logging.DEBUG)
azure_account_client = AccountClient(
    host="https://accounts.azuredatabricks.net/",
    account_id="[REDACTED]",
    azure_tenant_id="[REDACTED]",
    azure_client_id="[REDACTED]",
    azure_client_secret=dbutils.secrets.get(scope="[REDACTED]", key="[REDACTED]"),
)
azure_account_client.groups.list()

outputs
2023-11-21 20:14:17 INFO [databricks.sdk] Configured AAD token for Service Principal ([REDACTED])

Other Information

OS: from DBR 11.3 LTS
Version: databricks-sdk 0.13.0

Additional context
Add any other context about the problem here.

that's exactly why https://github.com/databricks/databricks-sdk-py/pull/361 exists


Render pipeline metrics in the new Dashboard

Preview:

Are the metrics in the left panel clickable as well?

Thanks for the reminder. I added it in the new iteration now.


fix(commons): rename and deprecate mods referencing global tokens

Description
Some mod properties had been misnamed with reference to the global tokens. This adds the renamed mods to the commons styles, with the old mods as a fallback, and adds deprecation notice comments.

--mod-animation-duration-100 is now --mod-button-animation-duration
--mod-sans-font-family-stack is now --mod-button-font-family
--mod-line-height-100 is now --mod-button-line-height
--mod-focus-indicator-gap is now --mod-button-focus-indicator-gap

CSS-651
How and where has this been tested?
Please tag yourself on the tests you've marked complete to confirm the tests have been run by someone other than the author.
Validation steps @jenndiaz

[x] The mods listed in the description have the new mod name first in the fallback chain

Regression testing
Validate:

The documentation pages for at least two other components are still loading, including:

[x] The pages render correctly, are accessible, and are responsive.

If components have been modified, VRTs have been run on this branch:

[ ] VRTs have been run and looked at.
[ ] Any VRT changes have been accepted (by reviewer and/or PR author), or there are no changes.

To-do list

[x] I have read the contribution guidelines.
[x] If my change impacts documentation, I have updated the documentation accordingly.
[ ] ✨ This pull request is ready to merge. ✨

I was torn between prefixing the new names with --mod-button or --mod-basebutton. It would be even better if these commons mods within a placeholder would be replaced by the component name on build. For example, --mod-COMPONENTNAME-animation-duration would be replaced on build and in say Picker, that inherits it, this would become --mod-picker-animation-duration. Is that something worth pursuing?

I was torn between prefixing the new names with --mod-button or --mod-basebutton. It would be even better if these commons mods within a placeholder would be replaced by the component name on build. For example, --mod-COMPONENTNAME-animation-duration would be replaced on build and in say Picker, that inherits it, this would become --mod-picker-animation-duration. Is that something worth pursuing?

We can evaluate using a function at some point in the future.  Want to add a backlog story for that work?


feat: add parle 0.8.4 release

update parle with release 0.8.4

:tada: This PR is included in version 1.130.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


time estimates for plans

This is part of a system that allows for time estimation for plans. It implements a telemetry and time estimation process at the ophyd object level (NSLS-II/Ophyd PR # 567) to estimate the time to make a 'cmd' on an object. 'cmd' is the commands past in the plan messages.
An est_time('plan') function, similar to summarise_plans('plan'), then steps through each message in order to estimate the time to perform each step and hence the entire plan.
This fixes issue #713 when combined with NSLS-II / Ophyd PR # 567

@danielballan, relating to your big picture thoughts.

I am happy to move the smaller function from the larger one, however I wanted to avoid polluting the namespace with a bunch of smaller functions. What do you think of _function to prevent this instead?

I agree we should look into this, but leave it for a future PR.

Each ophyd obj now already has an attribute function that provides this tuple for a given command, so I don't see the benefit of this approach. The 'granularity' you are requesting will then be provided by all the sub-functions that I will pull out.

No Problem, on any of these points. I will make the changes. For number 3 I will think about the best way to approach this. Due to the complications of 'groups' which are performed in parallel I am not sure it is a simple as you predict. If you send in a series of msgs with a 'group' in the middle do you want it to return the time for each msg or 1 for the group and 1 for each msg inside the group? I am guessing the later but am not totally sure how you plan to arrange the progress bar for groups.

Codecov Report

Merging #1048 into master will decrease coverage by 0.85%.
The diff coverage is 1.21%.

@@            Coverage Diff             @@
##           master    #1048      +/-   ##
==========================================
- Coverage   89.57%   88.72%   -0.86%
==========================================
  Files          50       50
  Lines        8367     8449      +82
==========================================
+ Hits         7495     7496       +1
- Misses        872      953      +81

Impacted Files
Coverage Δ

bluesky/simulators.py
40.14% <1.21%> (-58.04%)
:arrow_down:

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 e4793fe...3cd8160. Read the comment docs.

I have pushed a number of commits related to the issues described above. I think I have got all of the requests, with the exception of the move to put the telemetry recording on status objects. This is because I am having some issues understanding how status objects work from the code, I do intend to make this change once that is clearer to me however. Notes on the changes are below, each numbered item should have a corresponding commit for ease of following.

I turned the simulator est_time into a class 'EstTimeSimulator' and an instantiation 'est_time' because:

This allows easy access to the sub functions as requested by @danielballan
This allows for a class definition of val_dict, which no longer has to be passed in and out of sub
classes, as requested by @danielballan  and @tacaswell

Modifed EstTimeSimulator (bluesky), sim.py (ophyd), device.py (ophyd) and  EstTime (ophyd) to change how val_dict is used and its name.

in EstTimeSimulator (bluesky) it is a class attribtue self._plan_history.
This means it is not longer passed into and returned from functions as requested by
@danielballan  and @tacaswell  and has a new name as requested by @danielballan and @prjemian.
in EstTime (ophyd), device.py (ophyd), sim.py (ophyd) it is an input only variable called
plan_history.

Changed the stats and est_time to namedtuples

Also updated some of the names for these to make it clearer.

remove telemetry and est_time on read.

At the request of @danielballan

changed the method for combining std_dev's.

At  the request of @danielballan

Added a new function obj.est_time.msg_est(plan)

This was done at the request of @danielballan  to help with a plan progress bar.
Contrary to @danielballan's request I have not made this a 'base' function of the main
obj.est_time(plan) simulator function as I think this would add a second iteration through
the list of messages which will add an undue processing time burden on obj.est_time(plan).

Description looks good. Will dig into code as soon as I can. Happy to help walk through the Status code (and document it better in the process!)

Thanks @Daniel Allan , I will take you up on the offer of a discussion of status objects. Perhaps next week when you aren’t in Chicago.

For number 3 I will think about the best way to approach this. Due to the complications of 'groups' which are performed in parallel I am not sure it is a simple as you predict. If you send in a series of msgs with a 'group' in the middle do you want it to return the time for each msg or 1 for the group and 1 for each msg inside the group? I am guessing the later but am not totally sure how you plan to arrange the progress bar for groups.

I think that it should work like this:
# msg ->  est_time
Msg('set', motor1, ..., group='A')  -> 0
Msg('set', motor2, ..., group='A')  -> 0
Msg('set', motor3, ..., group='B')  -> 0
Msg('wait', 'A')  -> max(motor1.est_time.set(...), motor2.est_time.set(...))
Msg('wait', 'B')  -> motor3.est_time.set(...)

This is an accurate representation of how long each message will take to process: 'set' messages are instantaneous for RE; only the 'wait' messages take time.

Thanks @d
at present I do the former not the later, very similar to what you suggest, without separating by 'groups'. I will work on changing this.

I have updated this so that the est_time.group_eta function can handle multiple parallel 'groups'.

This class has "two methods one of which is __init__" -- plus some utility methods that are tucked into the class for scoping / namespace-decluttering reasons. Let's refactor it as a function plus utility functions. The scoping / namespace-decluttering is already provided by the module itself:
from bluesky import est_time
est_time.some_function(...)

Have made the change requested by @danielballan (removing EstTimeSimulator class) and tested.
Sorry for forgetting we had discussed this earlier, for posterity I am still not sure why this is better than the class structure. However as it doesn't prevent any of the aims of this PR being realized I ahve made the change.

I disagree @danielballan , they way it is written it absolutely takes into account sets/groups that occur outside of runs. I have chosen to also provide the time for the 'runs', as a separate list to the total time, to give the users a better understanding of which part of the plan might be taking to long and to help them organise the plans easier as the 'macro' type plans that most users will write will contain several 'runs' as their basic building block. I have treated 'runs' in the same way as 'groups', in that the times are separated out and added to the total time for the plan once the end of the 'run'/'group' has been found.
To clarify the total 'plan' time is not just the sum of the times for each 'run' but the sum of everything that occurs inside 'runs' AND everything that occurs between 'runs' and so can be longer than the sum of all 'runs'. I have tested the code to make sure this works by adding 'yield from mv....' and 'yield from wait..' lines between 'yield from scan......' lines to a test plan I was using.
I have specifically NOT written the code so that it first runs 'msg_est' and then go back through this and sort into 'runs', 'groups' etc. because this means counting through the messages more than once, and hence doubles the time overhead of calling est_time.

I have specifically NOT written the code so that it first runs 'msg_est' and then go back through this and sort into 'runs', 'groups' etc. because this means counting through the messages more than once, and hence doubles the time overhead of calling est_time.

Agreed that needing to iterate through the plan twice would be a bad design. I think this can be done in a single pass. Let me sketch out a little more specifically the design I had in mind with this comment.
# These constants should be revised using the test stand.
COMMUNICATION_TIME = (0.1, 0.1)  # It takes 0.1 +/- 0.1 to send a command to the IOC.
INTERNAL_STATE_TIME = (3e-5, 3e-5)  # It takes ~3e-5 seconds to process msgs like 'checkpoint'.

def est_time(plan):
    "Takes in a plan and yields out (time, std_err) per message."
    history = {}
    groups = defaultdict(list)
    for msg in plan:
        command = msg.command
        # Case 1: commands that generate a status object
        if command in ('set', 'trigger', 'kickoff', 'complete'):
            # TODO something involving history here...
            t = getattr(msg.obj.est_time, command)(...)
            groups[msg.kwargs.get('group')].append(t)
            yield COMMUNICATION TIME
        # Case 2: waiting on a status object cached by Case 1
        elif msg.command == 'wait':
            times = groups.pop(msg.kwargs.get('group'))
            t, std_err = combine(times, 'max')
            # TODO Update other groups (subtract t).
            yield t, std_err
        # Case 3: commands that communicate with the IOC but are quick
        elif msg.command in ('read', 'describe'):
            yield COMMUNICATION_TIME
        # Case 4: TODO 'collect' -- should scale with number of data points
        # Case 5: temporary special-case: these _should_ return a status object but don't yet
        elif command in ('stage', 'unstage'):
            yield (0, 0)  # temporary, unrealistic
        # Case 6: all other commands that do not involve network communication, are fast
        else:
            yield INTERNAL_STATE_TIME

def est_time_per_run(plan):
    "Takes a plan and yields out total (time, std_err) per run."
    times = []  # Accumulate times in current run.
    in_run = False  # Tracks whether we are currently inside a run.
    a, b = itertools.tee(plan)
    for msg, est in zip(a, est_time(b)):
        if msg == 'open_run':
            in_run = True
        if msg == 'close_run':
            in_run = False
            yield combine(times, 'max')
        if in_run:
            times.append(est)

Things I like about this general design:

We obviate the discussion cited above about a global dict passing around mutable state. The state lives as a local var inside est_time. It is not shared between functions.
We can imagine several reductions/aggregations following the pattern of est_time_per_run. Someone could write est_time_total, est_time_per_sample or est_time_per_point using the same pattern, and all the "tricky" logic is safely contained in est_time.

One clarification that occurred to me I should state: Note that because est_time is a generator, we aren't looping through the messages twice. We're capturing output as it comes out and tallying. It's layered, but it's not doubling the loop.

OK so I am slowly becoming convinced, I see two issues to be resolved first however:
ISSUE 1.
It would need another function on top of this to return the times in a useful way for users (e.g. a 'print_summary' style wrapper for printing or some other method for exporting the data to a GUI).

This may not be a major issue but want to get feedback on what people think regarding this as the API.
What do people think of a single API with boolean keywords used to determine what is printed?

eg. est_time_plan(plan, total = true, runs = true, .......)
**NOTE: I am using the 'summarize_plan' naming convention here, what do people think about this?

ISSUE 2
I think that 95% of the time the users will want both the total estimated time AND the time per run. In your setup this would still require stepping through the message list twice, once when running est_time_per_run(plan) and once when running est_time_total(plan).

I see two options to get around this:

both would require the 'yields' to give 3 values 'name', est_time and std_dev with 'name' being
something like 'msg x', 'group y' or 'run z' which can be used in the 'print' wrapper described above.

Make est_time_per_run also yield the time estimate for msg's between the runs, including the
'name' parameter described above. Then we can simply pass est_time_per_run(est_time(plan)) as
the argument of est_time_total to output both. This relies on the fact that both est_time and
est_time_per_run are generators with the same structure for the output and so either can be the
input of est_time_total. The 'name' can then be used to distinguish what type of 'thing' the time
estimate relates too.

we could make est_time_per_run(plan) also return the total time for the plan as the last 'yield'. If
we gave it the name 'total' we could distinguish it from those with the name 'run'.

FURTHER THOUGHTS
In principal I like number 2 as it is explicit, but not strongly enough to insist. Number 1 has the benefit that it is easy to nest any future reductions in which could be useful.
I think that adding the 'name' as part of each yield would make a generic 'print' wrapper easy (the first issue I mentioned). It would just need to print the following on each yield:
print (f.'{name}: est time = {est_time}, std_dev = {std_dev}')

What do people think of a single API with boolean keywords used to determine what is printed?
eg. est_time_plan(plan, total = true, runs = true, .......)
**NOTE: I am using the 'summarize_plan' naming convention here, what do people think about this?

The job of summarize_plan is to remove information. That is, whenlist(plan) is too much information, summarize_plan is there to construct an incomplete but often sufficient and nicer-to-read representation. It does not add any new information, so there is not much need to access its output programmatically -- might as well just dump to the screen.
The job of est_time, in contrast, is to provide additional information. That information should be programmatically accessible so that it can be reused by other components (GUIs, user-defined functions, etc).
This usage seems user-friendly to me, and unlike prints it is also programmatically useful:
>>> est_time_per_run(plan)
[EstTime(time=10, std_err=1), EstTime(time=5, std_err=0.3), EstTime(time=10, std_err=1)]

If I want the total I can do this:
>>> est_time_total(plan)
EstTime(time=20, std_err=2.3)

or this:
>>> sum([item.item for item in est_time_per_run(plan)])
20

or this:
>>> combine(est_time_per_run(plan))
EstTime(time=20, std_err=2.3)

As an additional convenience, I would not object to some high-level function that prints something like:
Total Estimated time: 20 +/ 2.3
Per run breakdown:
(etc.)

I think that 95% of the time the users will want both the total estimated time AND the time per run. In your setup this would still require stepping through the message list twice, once when running est_time_per_run(plan) and once when running est_time_total(plan).

I think you are right that that is the common case and that we need a robust solution for it that ideally does not require iterating through the messages twice.
It just occurred to me that, when we extend the RunEngine to make it possible to have multiple runs open concurrently as we plan to do someday, the relationship between total time and time during and between runs will not be straightforward. Runs can overlap. We should try to avoid making the 'one run at a time' assumption in here to avoid future pain. Nonetheless the time 'per run' will remain a useful concept for the common case of non-overlapping runs.
Here's a proposal that solves your problem ("Users commonly want time per run and total time") and the problem I foresee ("Time per run is ill-defined.") I think est_time_per_run -- or whatever we call it -- should report the cumulative EstTime each time a run is closed. This is well-defined even if runs overlap, it incorporates any time spent between runs, and tells the user what they probably want to know: "How long until I can see all of dataset X?" If we want to include the time spent after the last run closes, we can issue one last message at the end.

So I want to push back a little here, and it is something that I was also considering for the group_est time as well as the potentially overlapping 'runs'.
I think the idea of a 'cumulative est_time' is a really good idea, but I think it would be beneficial if we extended the output tuple to include it AND the time for the run/group defined by 'name'. This would result in a named tuple with the values ('name', 'cumulative estimate', 'section?? estimate'). In this case I imagine that 'cumulative estimate' and 'section?? estimate' are themselves named tuples with the values ('est_time', 'std_dev'). (I am not convinced of the name 'section' to relate to the 'group', 'run' or 'non-groupable action' that is referenced by name but don't have a better option).
The reason I like this is, as you say, cumulative est_time outputs when a particular part of the scan is done and by default provides the total est_time at the end. However there is still some information that is lost. By also including the total time for a 'group'/'run' or 'non-groupable action' then we are not losing any time information.
As a use case I could imagine the extra info of the total 'plan'/ 'group' or 'non-groupable action' times would be useful for a user trying to determine which part of a 'macro-like plan' is taking the longest and where the best point to change things to reduce the time is. I could also imagine using this extra info to make a 'visual representation', similar to a schedule bar-graph, showing when different 'sections' start and stop throughout the plan which would be a neat and useful GUI addition that can help with scheduling 'macro-like plans' with many runs inside.
What are everyones thoughts?

I think the idea of a 'cumulative est_time' is a really good idea, but I think it would be beneficial if we extended the output tuple to include it AND the time for the run/group defined by 'name'.

Can you give an example of what this would look like? I'm not clear on where the 'name' come from.

The 'name' is really just to distinguish between like actions/groups/runs. For example a run might be
for a run:
('run_1', (cumulative_est_time, cumulative_std_dev), (section_est_time, section_std_dev))
for a group:
('group_'+msg.group, (cumulative_est_time, cumulative_std_dev), (section_est_time, section_std_dev))
for a non-groupable action:
(msg.cmd+'_1', (cumulative_est_time, cumulative_std_dev), (section_est_time, section_std_dev))
The aim of this is to produce an output something like:
$ list[est_time_per_run(plan)] [('group_A', ........), ('run_1', .......), ('sleep_1', ........), ('group_B', .........), ('run_2',........), .................
Does this make it a little clearer?

I think we agree on:

We need the low-level generator (along the lines of my est_time sketch) to provide maximally-granular information -- time per Msg -- such as would be suitable to support a progress bar.
We need a high-level generator (cumulative, perhaps) to provide a reduced/simplified view for human consumption.

I think you are proposal an intermediate variant, which includes a level of detail somewhere between these two. I think at this point we should consider moving to a visual representation rather than a text-based one -- as you proposed above. A intermediate text-based representation looks like it will be quite verbose and hard to parse for realistic plans. But a visualization, whether a simple static plot or an interactive GUI, can be derived from the low-level generator, and this lets us avoid trying to mind-read which things the user doesn't want to see ("details") and which things are important for them to see that day. It also avoids the need to try to infer "sections" from what is technically a flat list.

I do think it's useful to consider other reduced representations. I mentioned est_time_per_point above -- having in mind the time per Event.

Another thought, lifted from early conversations on this topic -- Should we add Msg('section', ...) which plans can use to declare sections useful for progress bars and other consumers? One path might be to say, "This is a thing we know can do and probably want to do someday," but leave it out of scope for this PR.
Apologies for the stream-of-consciousness posts.

But a visualization, whether a simple static plot or an interactive GUI, can be derived from the low-level generator

I am not sure this is true, as I can see that it would also want to include 'runs', or other possible 'arrangments' and so to properly produce the visualization I mentioned above we would need to run through the messages twice, once in est_time and once in est_time_per_run. As this information already exists from the est_time call inside est_time_per_run then I am thinking we should output it as well. I think this approach makes the visualization much easier, as one call gives all of the required information in a list where the positions corresponds to the completion order.

A intermediate text-based representation looks like it will be quite verbose and hard to parse for realistic plans

I don't think I agree with this, I see the parsing to be quite simple. For example to parse out the cumulative estimate from the yielded value, val, from est_time_per_run I would use:
val.cumulative.est_time or val.cumulative.std_dev
val.name would then be an identifying string that can be used in visualizations/ prints and val.section.est_time/val.section.std_dev could be used to get the total time for the visualizations/ prints or for further processing.
To be clear, I don't think we should be providing 'every' group and action time in est_time_per_run, just those that occur between runs. Everything inside the runs will be contained within the 'run' time, as is proposed to be done for groups in est_time.  I think that this resolves the issue of the verbosity of this 'intermediate' approach. We could also limit it to 'actions' that we know take significant time and leave out those that are essentially instantaneous.

I do think it's useful to consider other reduced representations. I mentioned est_time_per_point  above -- having in mind the time per Event.

As an example I would think that this kind of plan would provide the above mentioned tuples for each Event and for each 'action' that occurs between events, following the same pattern as for my description of est_time_per_run.

I don't think I agree with this, I see the parsing to be quite simple. For example to parse out the cumulative estimate from the yielded value, val, from est_time_per_run I would use:
val.cumulative.est_time or val.cumulative.std_dev [...]

Oh, I didn't mean hard to parse programmatically, I meant hard to visually read on the screen.

To be clear, I don't think we should be providing 'every' group and action time in est_time_per_run, just those that occur between runs. Everything inside the runs will be contained within the 'run' time, as is proposed to be done for groups in est_time. I think that this resolves the issue of the verbosity of this 'intermediate' approach.

I strongly dislike the shift in granularity depending on whether we are in a run.
...But I actually think we don't need to settle those discussions in order to proceed.
In order to un-block progress here, how about this: can you get to an implementation of something like est_time in this comment but with two revisions derived from our subsequent conversation:

The output EstTime should always be in cumulative terms.
Yield out msg, est_time_tuple instead of just est_time_tuple.

That would give us all the information, unfiltered, and enable us to write many variations with just one pass through he plan. Observe how est_time_per_run becomes simpler to do:
def est_time_per_run(plan):
    "Takes a plan and yields out total (time, std_err) per run."
    for msg, est in est_time(plan):
        if msg.command == 'close_run':
            yield est

Your preferred variation is also easy to implement:
def est_time_per_run(plan):
    "Takes a plan and yields out (label, (time, std_err)) per run."
    runs_open = 0
    group_counter = 0
    run_counter = 0
    for msg, est in est_time(b):
        if msg.command == 'open_run':
            runs_open +=1
        elif msg.command == 'close_run':
            runs_open -= 1
            run_counter += 1
            yield f'run_{run_counter}', est
        elif not runs_open and msg.command == 'wait':
            group_counter += 1
            yield f'group_{group_counter}', est

Are you satisfied that that implementation for est_time is sufficient to support the high-level APIs we need? If so, should we table the discussion of which high-level APIs are useful until we have the low-level est_time fully sorted out?

I am now seeing your point of view regarding having only msg's and groups included in the base est_time function. I think our differences now occur in the output structure.

In order to un-block progress here, how about this: can you get to an implementation of something like est_time in this comment but with two revisions derived from our subsequent conversation:

The output EstTime should always be in cumulative terms.
Yield out msg, est_time_tuple instead of just est_time_tuple

That would give us all the information, unfiltered, and enable us to write many variations with just one pass through he plan.

So this does not solve the main problem that we are disagreeing on (at least from what I understand), which is that we are losing information by not also returning the estimated time (or start time) for each part as well as the cumulative stop time. For example:

without the est_time for each part we could not make the 'schedule bar-graph' visual representation I mentioned earlier as we would need both start and stop times for each element, not just the stop readout given by cumulative time. This information is, in particular, lost for 'groups' in your proposed structure, but is also not 100% extractable from the proposed output for 'runs' (particularly if we have multiple overlapping 'runs').

I see having both as also being useful for de-bugging, in that it will be very easy to determine if an action is being missed (by the large difference between stop time of one action and the start time of the next). This indicates that we have an action that is clearly missed in the output of either the base est_time function or a higher level function.

So the question that is holding up the progress at present is what output structure do we need/want? As the proposed base est_time function also includes 'groups' then we will need to resolve this before working on that. In order to ensure that no information is lost I see two options (I am happy to consider others):

We output both the cumulative stop time and the time to complete each element (msg, group, run).
We output a cumulative start as well as stop time for each element (msg, group, run).

In terms of making it easier to read and understand the output perhaps 2. is better but I don't have a huge preference either way.

I'm not completely following. Let's focus on (1).

We output both the cumulative stop time and the time to complete each element (msg, group, run).

Help me understand what this means.

Time per msg: I think you can get this by comparing (subtracting) two subsequent items.
Time per group: I guess you could say that "time per group" is the time elapsed from the first 'set'/'trigger'/'kickoff'/'complete' that uses a given group label to the time that that group is waited on. This is easy to compute by, again, subtracting the cumulative time of that first labeled message from the time of the wait message. Any consumer of est_time can cache that info and compute on the fly, in one pass.
Time per run: Similarly, I can watch 'open_run' go back, note the cumulative time, and subtract that from the matching 'close_run'.

What information are we missing?

Time per msg: I think you can get this by comparing (subtracting) two subsequent items.

Agreed we do not have issues with time per msg.

Time per group: I guess you could say that "time per group" is the time elapsed from the first 'set'/'trigger'/'kickoff'/'complete' that uses a given group label to the time that that group is waited on. This is easy to compute by, again, subtracting the cumulative time of that first labeled message from the time of the wait message. Any consumer of est_time can cache that info and compute on the fly, in one pass.

Your version of est_time only outputs the cumulative stop time on the 'wait' messages not on every 'set'/'trigger'/'kickoff'/'complete' message. It also does not output this on the first such message, and so this information is lost based on the current structure. We could have it 'yield' on the first message, but then we are confusing the output by saying that 'if it is  a 'set'....... type message it is a 'start time' otherwise it is a 'stop time'. I prefer to include a cumulative start and stop time on each yield to avoid this confusion.

Time per run: Similarly, I can watch 'open_run' go back by, note the cumulative time, and subtract that from the matching 'close_run'.

In principle this can be done for runs, however I could imagine a version of est_time_run where we only output info on each run element. While the msgs and groups that occur between runs would be included in the cumulative stop time of est_time, your output of only cumulative time for such a higher level function would loose the information regarding times between runs.
Is this clearer?

Your version of est_time only outputs the cumulative stop time on the 'wait' messages not on every 'set'/'trigger'/'kickoff'/'complete' message.

I don't understand this. The proposed est_time would output this:
...  # assume we are showing the middle of some long est_time output
(Msg('close_run'), EstTime(100, 0.001))
(Msg('set', motor1, 3, group='A'), EstTime(100.1, 100.1))  # first usage of group 'A'
(Msg('set', motor2, 3, group='A'), EstTime(100.2, 100.141))
(Msg('wait', None, group='A'), EstTime(113, 3))  # for some slow motor
...

So the "group time" for 'A' would be 113 - 100.

So for those playing at home, there was a long discussion between @danielballan and myself this morning trying to resolve the differences of opinions we have on this. We have come up with the following path forward:

est_time will follow the structure that @danielballan suggested above.

The output will be a named tuple following the structure (msg, cumulative_time, time_for_msg) with cumulative_time and time_for_msg also being named tuples with the structure (est_time, std_dev). Due to the structure of est_time a wait message returns the time for the group it waits on in time_for_msg.

All higher level est_time_.... functions will have the same output structure.

I will make these changes in due course.

Per our chat, @awalter-bnl means time_for_msg to be time_for_this_unit (run, wait group, etc.). I have said I still wonder if that aggregation would be better done one layer up, as different consumers of this information might be interested in different aggregates (by sample instead of by run, for example).
I am also not sure that "higher level est_time_.... functions will have the same output structure," as this seems like a good application for low-level and high-level APIs that may have different return types.
But we have better alignment than we did before, and I reiterate these concerns here only to flag points of future discussion. I think @awalter-bnl should implement exactly what he specified above without regard to my tentative concerns, and then we can resume the discussion from there.

The latest commit represents a major change in the structure/ API, this has not been tested or been checked for PEP8, this will be done once we have agreement that this is the structure/ API we want to use.
Notes on the new structure/API

Basic output structure is now a named tuple of the form (message, stop_time, start_time) where.
o	message is the full message yielded by plan
o	 stop_time and start_time are named tuples of the form (est_time, std_dev)
A base level function, with maximum granularity, is now provided via est_time(plan)
•	This yields for each message, with the yield for wait messages being the times for the associated group as a whole
Higher level functions reduce the verbosity of est_time(plan)
o	Examples:
•	est_time_run(plan) which modifies the start_time in the close_run yield of est_time(plan) to be the start of the associated run.
•	est_time_per_run(plan) which takes est_time_run(plan) and removes the yields between open_run and close_run messages.
•	est_time_per_group(plan) which takes est_time(plan) and removes the yields for ‘groupable’ messages.
•	Many others that have not been thought of yet !-)
Output functions take these ‘times’ and do something with them.
o	Examples:
•	print_est_time(plan, est_time_func) which takes the yields from est_time_func(plan) and prints them in a human readable format.
•	I would like to make plot_est_time which is like print_est_time but makes a ‘schedule bar graph’ plot out of them.
o	Getting the exact ouput that Dan wants could also be done using an output function, this is not true in the other direction.
•	Example. >set(motor1, x , ‘groupA’), set(motor2, y, ‘groupB’), wait( ‘groupB’), set(motor3, z, ‘groupA’) is a valid construct but in it would not be possible to ‘locate’ the motor3 move inside groupA without having the start and stop time for the third set yielded, particularly if it finishes before the motor1 move.

A few points to discuss:

Looking at the structure here I am wondering if it is worth removing the start and stop time for the group (yielded on the wait msg) from est_time.
o	It could then be done in  a higher level function est_time_group, in the same way it is done for runs in est_time_run, this would be more consistent.
I like this structure (with both low level and high level functions having the same API) because it makes the ‘Output functions’ generic, giving the user the ability to ‘select’ the verbosity level for a given function.
I am still not convinced that ‘communication time’ and ‘internal_state_time’ can be accurately provided.
o	I don’t think they are ‘static’ and they will change from beamline to beamline and day to day (perhaps even hour to hour).
o	They have been included in case someone comes up with a good solution for estimating them.
If we want to include ‘communication_time’ independently into the times defined for messages that are estimated from telemetry (which they are in this draft) then we will need to make significant changes to the status_objects.
o	This is because at present this time is not accounted for in the estimation of the time for the move that is stored in the telemetry. As a result including it again here will mean it is counted twice.

@danielballan all 3 of your comments are valid, however before we get into these 'details' I want to agree that the overall structure and API are what we want. This will avoid me spending a lot of time resolving these small issues only to have to rewrite large portions of the code later anyway when it is decided that the structure and API are not what we want (as happened last time).
Can I please get feedback on the structure and API first, once this is done we can go over the the details.

I have cleaned up the code with flake8

Yes. @tacaswell and I had a thought about how to resolve this at SciPy but need some time to write it up. Maybe @tacaswell can get to it before I get back from vacation?

Notes from call with @awalter-bnl:
We will go with this API: est_time(plan) -> yields (processing_time, action_time) where processing_time is always an EstTime representing that time it takes to process a given msg and action_time is None for synchronous messages (open_run, checkpoint, etc.) or another EstTime for any messages that return status objects, representing their time to complete
I am bothered by the return type instability of this design --- some message types return (EstTime, None) while others return (EstTime, EstTime) --- but this is a reflection of the return type instability of what RE sends back to the plan for a given Msg (status object or not status object).
Higher level consumers have all the information they need to produce aggregates like "time per run", "time per group," or "which was the slow motor in this group.
It will eventually be important for the various constant times (internal state update time, communication time, document emitting time) to be configurable somehow in case the caller knows things about local configuration, such as how time-costly the callbacks are, that it wants to incorporate. For now we can use guesses --- 0 is a good zeroth-order approximation. Down the road, maybe we can get some data on communication time by doing spot checks with EchoRequest.

Latest commits, updated the API as described above. Also added tests for each of the est_time functions. In progress new commits to the ophyd (https://github.com/NSLS-II/ophyd/pull/567/files) in order to remove the 'communication time' from the current status object telemetry estimates.
A few important points:

I have 'renamed' est_time to est_delta_time (if this is not liked then I can change it again suggestions).
I have written a new ''est_time' which uses 'est_delta_time' and converts to a cumulative start/stop time (as was the previous outputting.
This allows the rest of the est_time functions and the print_est_time function to remain unchanged.

FYI looking into why the tests are failing on Travis when they work fine locally !!

OK so the error for all Travis builds relates to the lack of the related ophyd PR (https://github.com/NSLS-II/ophyd/pull/567/files). This should work once that PR is merged.

This should work once that PR is merged.

To test this against the corresponding ophyd changes, you can add a line to .travis.yml to install ophyd specifically from that git branch. We will then revert the change before finally merging. We don't do this often, but it is appropriate for large coordinated changes like this one. For example, the last time I recall doing it was for the "asset refactor" work.

@danielballan I am reluctant to do this because:

The ophyd branch work will need to be merged first anyway (this does the telemetry side of things so I think we should aim for that to be merged, deployed and generating data prior to merging this side of things so we can get some more test data).
Given the timeline for how often this is revisited I will definitely forget to undo this change prior to merging and who knows when it will then be noticed.

Fine by me.

Based on a discussion with @danielballan, and the issues found trying to rebase the ophyd counterpart to the current master, I am closing this off. Potentially a new PR may be opened in the future.


Feature/parallel loading

Just for review, not intended to be merged.

Commit to remote.h seems to have removed that branch you wanted. Pressed the restore button on it.


Refactor GitGud.Web.CodebaseController

Currently, the controller actions partially fetch necessary Git and Ecto related data and leave the rest to the view.
The view has helper functions such as batch_branches/2, batch_commits/2, and batch_tags/2 which involve fetching data from both the Git repository and the database. It also provides a lot of helper for fetching Git related information (author, committer, message, GPG-key, etc.). We should try to move these functions into the controller instead...
We should try to keep things separated:

[x] The controller fetch and prepare all the necessary Git objects upfront.
[x] Batching and pagination are meant to be executed in the controller actions.
[x] Enhance performance by caching things with GitAgent.transaction/3.

End goal here is to only provide a few helper functions in the view which only transform data. All the fetching, batching, paginating and sorting is done upfront by the controller.

See commit e8397e2 for more details about the new caching mechanism in GitAgent and how it affects transactions.

Every DB or Git function has been moved from GitGud.Web.CodebaseView to GitGud.Web.CodebaseController.
GitGud.Web.PaginationHelpers is imported automatically when using controllers.
Controller actions use GitRekt.GitAgent.transaction/3 for requesting all informations about a Git commit.
Assign commit_info is available in templates/codebase/_tree_table.html.eex when tree_path is empty.


Player scrolls page a second after pausing the video

Scenario:
User pauses video and starts scrolling page.
Within seconds the entire page scroll backs to the top of the video.
User is really annoyed that the whole page scrolled for no reason, back to content they seen already and were trying to ignore.
They leave the website.
Example:
https://youtu.be/NQYjaC0NeFY

Can this issue be fixed please?
It happens on the main afterglow website as well, on all major browsers we tested with.
It's a really nice video player, but this weird bug causing the entire page to jank after pausing the video is disconcerting to the users' experience.

Hi there!
Just tested that out. Played the video on the afterglow website, then paused it and immediately scrolled down. No strange behaviour, no scrolling back. Tested on chrome and firefox and on several websites.
Do you have a video or could you screencast the behaviour? We are not able to reproduce this bug.

Sorry, just saw the screencast. I'll look into it.

Seems to happen only when explicitly using the pause button (not pausing when clicking elsewhere on the player). Can you confirm that, @Martin-Pitt?

@moay  Yep, doesn't trigger on ending of video or when clicking the video itself. Seems only via the pause button in the player bar.

Fixed with the latest commits, new release 0.4.1 is available and will be pushed to the CDN within a few hours.


make wrong db_constraint setting an error in checks

@codingjoe thanks for the suggestions on this draft :)

What wasn't clear to me: Are you deprecating W1? If so, maybe make a note in the W1 documentation.

Yes, I'm deprecating it.
There is no documentation on W001 yet :)
But I'll add it and deprecate it directly

@amureki you think you can review/approve this? then I'll prep a new release


On the same server，jmeter can run 20000rps，but locust only 5000rps

Description of issue / feature request
On a same server，as a loader，jmeter can run 20000rps，but locust(Distributed in use) only 5000rps ，why？with locust CPU is in high load，but jmeter is not
Expected behavior
no so bad rps with locust
Actual behavior
so bad rps with locust
Environment settings (for bug reports)

OS:Ubuntu14.04
Python version:2.7.6
Locust version:0.8.1

Steps to reproduce (for bug reports)
TBD - example code appreciated

I have the same problem:
on the same machine, jmeter can run 4000+ rps, but locust only 2000+. I'm using FastHttpUser and 3 workers. the bottleneck is CPU. The CPU is pretty high (100%). But Jmeter only require about 40% CPU. The advantage of locust is that it use much less memory than Jmeter.

@tobeczm Locust and JMeter are two different programs with quite different feature sets. If you've identified that the bottleneck is CPU, you could add more machines/workers.

i have a query iam using amazon instance windows
32 GB Ram
2.4GHZ CPU
locust webView
iam testing my team's server i have been trying to reach maximum RPS i always try 10000 users and 1000 users/s in locust settings in webview but i can hardly reach upto 1000rps iam using fastHTTP class don't know how to maximize RPS

https://github.com/locustio/locust/wiki/FAQ#increase-my-request-raterps


fail install cilium

If my development environment is a virtual machine and my network card is virtual. Can I install the cilium ?

why the cilium show install successful ?
But run " cilium connectivity test " show fail.
Where should I look for errors?

If my development environment is a virtual machine and my network card is virtual. Can I install the cilium ?

Yes, that's how we test Cilium in CI.
Please fill out the issue template properly and we'll be happy to help.


Accept different mod requests in beatmap parser

Currently we can add +HDHR to beatmap requests.
We need to allow different combinations such as:

<beatmap_link>+HD+HR
<beatmap_link>+ HD + HR
<beatmap_link>+HD +HR etc..

Closed with #16


No docs on custom flaky test detection in Azure Pipelines

Custom detection - You can integrate your own flaky detection mechanism with Azure Pipelines and utilize the reporting capability.

How?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a8dfb3bf-8cce-7ad8-b2c6-40d6c2b9d441
Version Independent ID: 53e2d39d-6808-70d5-9c26-bc4c5bb109e3
Content: Manage flaky tests - Azure Pipelines
Content Source: docs/pipelines/test/flaky-test-management.md
Product: devops
Technology: devops-cicd-test
GitHub Login: @KathrynEE
Microsoft Alias: kaelli

@letmaik - This is a known issue and we are working with the feature PMs to get the content documented. Am closing this issue as we are tracking it with this one: https://github.com/MicrosoftDocs/azure-devops-docs/issues/6700.


How can we help?
I would like someone else to build the manifest.
Please read and ensure the following

[X] The installer meets the above requirements

Please provide the following information
Download Page Url: https://natrongithub.github.io/#download
Publisher: https://natrongithub.github.io
Package Name: Natron
Description: Open-Source Compositing Software
Package Version: 2.5.0
Installer URL: https://github.com/NatronGitHub/Natron/releases/download/v2.5.0/Natron-2.5.0-Windows-x86_64.zip

#112002

This issue is resoved and should be closed as "Completed".


Closes #172 Can't access Menu when font increased

This PR closes #172.

This was as close as I could get to matching the bottom of the title bar on fonts 10px - 24px


Typescript - Typography interface not correct?

Using TypeScript, I create my custom theme with createMuiTheme and typings seem wrong.
export const theme = createMuiTheme({
    palette: {
        primary: {
            main: '#144954',
        },
        secondary: {
            main: '#0ec782',
        },
    },
    typography: {
        fontFamily: '"Poppins", sans-serif', // error here
    },
});

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior
theme.typography.fontFamily should be existing in interface and expect string
Current Behavior
I get an error:

Steps to Reproduce

Use MUI with Typescript and use provided snippet
Context

Creating custom theme
Your Environment

Tech
Version

Material-UI
v3.0.3

React
16.5.1

Browser
Chrome 69

TypeScript
3.0.3

I can't reproduce your issue. Using your snippet locally I get no errors with your ts and mui version and the codesandbox works as well.
Could you include your lockfile? This may be an issue with a conflicting csstype package.

Thanks for answer, here is the yarn lock
https://gist.github.com/lkostrowski/3f7d4877c8bfa6573a13f229b17d3537

I've just deleted yarn lock and reinstalled with npm. It solved the problem...
If youre curious, here is the package lock file, I have no idea whats the problem
https://gist.github.com/lkostrowski/09e7f90e40679fbb396be765fc233fb8
Closing, thanks for help


ValueError in Render

Hi there,
I am trying to run the tutorial and am running into the following error:
>>> import torch
>>> from lucent.optvis import render, param, transform, objectives
>>> from lucent.modelzoo import inceptionv1
>>> device = torch.device("cuda:0" if torch.cuda.is_available() else "cpu")
>>> model = inceptionv1(pretrained=True)
>>> _ = model.to(device).eval()
>>> _ = render.render_vis(model, "mixed4a:476", show_inline=True)

  0%|                                                                                | 0/512 [00:00<?, ?it/s]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/tatekeller/opt/anaconda3/envs/spec/lib/python3.8/site-packages/lucent/optvis/render.py", line 113, in render_vis
    optimizer.step(closure)
  File "/Users/tatekeller/.local/lib/python3.8/site-packages/torch/autograd/grad_mode.py", line 26, in decorate_context
    return func(*args, **kwargs)
  File "/Users/tatekeller/.local/lib/python3.8/site-packages/torch/optim/adam.py", line 66, in step
    loss = closure()
  File "/Users/tatekeller/opt/anaconda3/envs/spec/lib/python3.8/site-packages/lucent/optvis/render.py", line 97, in closure
    model(transform_f(image_f()))
  File "/Users/tatekeller/opt/anaconda3/envs/spec/lib/python3.8/site-packages/lucent/optvis/transform.py", line 85, in inner
    x = transform(x)
  File "/Users/tatekeller/opt/anaconda3/envs/spec/lib/python3.8/site-packages/lucent/optvis/transform.py", line 75, in inner
    M = kornia.get_rotation_matrix2d(center, angle, scale).to(device)
  File "/Users/tatekeller/opt/anaconda3/envs/spec/lib/python3.8/site-packages/kornia/geometry/transform/imgwarp.py", line 347, in get_rotation_matrix2d
    raise ValueError("Input scale must be a B tensor. Got {}"
ValueError: Input scale must be a B tensor. Got torch.Size([1, 2])

I am using a conda environment with Python 3.8.5 and pytorch=1.7.0.
Any help regarding this error would be much appreciated!

Hey @tatkeller thanks for checking out Lucent! Can I just check what version of kornia you're using?

Thanks for the quick response! I'm using kornia=0.3.0.

There was a breaking change between kornia 0.4.0 and previous versions of kornia. I just updated lucent to be backward compatible with older version of kornia as well. If you run pip3 install --upgrade torch-lucent that should install the latest. Alternatively, upgrading kornia will help too!

Works now! Thanks so much!


GH-44846: [C++] Fix thread-unsafe access in ConcurrentQueue::UnsyncFront

Rationale for this change
The UnsyncFront method claims that it can access a std::deque's front element without synchronizing with another thread that would call std::deque::push_back, but std::deque::front can actually be implemented in terms of std::deque::begin while std::deque::push_back is specified to invalidate iterators.
In the end, UnsyncFront is concretely thread-unsafe even though it might ideally be thread-safe. This shows up as occasional Thread Sanitizer failures.
What changes are included in this PR?
Replace UnsyncFront with a thread-safe Front method.
Are these changes tested?
Yes.
Are there any user-facing changes?
No.

GitHub Issue: #44846

@github-actions crossbow submit test-ubuntu-24.04-cpp-thread-sanitizer

@github-actions crossbow submit -g cpp

🤔 would std::list be ok here? Should we merge this or trying list since it would not invalidate anything ( but has less cache locality and requires more spaces)

std::list will perform much more poorly. My intuition is that locking the front() access is better.


add type conversion for boolean values

In types.js.
In the future, this will probably come up when it becomes easy to let XLSForm create a calculation of type=boolean. I think we should convert to 0 and 1.

never mind. I don't think it serves any purpose because boolean('0') is also true!


Remove domain federation limit - Update direct-federation.md

domain federation limit is not exist anymore.

@msmimart
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


workload report error “Check snap != nullptr failed: Can not find disaggregated task” when run ch

Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
1、run ch q7
2、workload report error
2. What did you expect to see? (Required)
no error
3. What did you see instead (Required)
workload report error
[2024-10-28 21:11:43] execute run failed, err execute query q7 failed Error 1105: other error for mpp stream: Code: 11004, e.displayText() = DB::Exception: Check snap != nullptr failed: Can not find disaggregated task, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:4>,executor=TableFullScan_78> (from s1006_t2737_4307_1_36486282018035081_360582), e.what() = DB::Exception,\r\n"]
4. What is your TiFlash version? (Required)
/tiflash/tiflash version
TiFlash
Release Version: v8.4.0-alpha-80-g08535236b
Edition:         Community
Git Commit Hash: 08535236b8f3d6d41656f22ebb8c2334f3081d86
Git Branch:      HEAD
UTC Build Time:  2024-10-28 11:09:41
Enable Features: jemalloc sm4(GmSSL) mem-profiling avx2 avx512 unwind thinlto hnsw.l2=skylake hnsw.cosine=skylake vec.l2=skylake vec.cos=skylake
Profile:         RELWITHDEBINFO
Compiler:        clang++ 17.0.6
Raft Proxy
Git Commit Hash:   c3bedc86b1470ceacd15dfb19fa7bfa94e8ab49d
Git Commit Branch: HEAD
UTC Build Time:    ""
Rust Version:      rustc 1.77.0-nightly (89e2160c4 2023-12-27)
Storage Engine:    tiflash
Prometheus Prefix: tiflash_proxy_
Profile:           release
Enable Features:   external-jemalloc portable sse test-engine-kv-rocksdb test-engine-raft-raft-engine openssl-vendored

/type bug
/severity major
/assign Lloyd-Pottiger

[2024/10/29 05:05:36.656 +08:00] [INFO] [WNDisaggSnapshotManager.h:56] ["Register Disaggregated Snapshot, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:3>,executor=TableFullScan_78>"] [thread_id=219]
[2024/10/29 05:05:36.671 +08:00] [INFO] [WNDisaggSnapshotManager.h:56] ["Register Disaggregated Snapshot, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:4>,executor=TableFullScan_78>"] [thread_id=288]
......
[2024/10/29 05:10:36.695 +08:00] [INFO] [WNDisaggSnapshotManager.cpp:61] ["Remove expired Disaggregated Snapshot, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:4>,executor=TableFullScan_78> expired_at=2024-10-28 21:10:36.671471"] [thread_id=413]
[2024/10/29 05:10:36.704 +08:00] [INFO] [WNDisaggSnapshotManager.cpp:61] ["Remove expired Disaggregated Snapshot, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:3>,executor=TableFullScan_78> expired_at=2024-10-28 21:10:36.656404"] [thread_id=413]
......
[2024/10/29 05:10:46.131 +08:00] [ERROR] [FlashService.cpp:1146] ["FetchDisaggPages meet exception: Check snap != nullptr failed: Can not find disaggregated task, task_id=DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:4>,executor=TableFullScan_78>\n\n       0x1f55969\tDB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, int) [tiflash+32856425]\n                \tdbms/src/Common/Exception.h:46\n       0x8728a3f\tDB::FlashService::FetchDisaggPages(grpc::ServerContext*, disaggregated::FetchDisaggPagesRequest const*, grpc::ServerWriter<disaggregated::PagesPacket>*) [tiflash+141724223]\n                \tdbms/src/Flash/FlashService.cpp:1114\n       0x9bc14e1\tgrpc::internal::ServerStreamingHandler<tikvpb::Tikv::Service, disaggregated::FetchDisaggPagesRequest, disaggregated::PagesPacket>::RunHandler(grpc::internal::MethodHandler::HandlerParameter const&) [tiflash+163321057]\n                \tcontrib/grpc/include/grpcpp/impl/codegen/method_handler.h:206\n       0x94c53bb\tgrpc::Server::SyncRequest::ContinueRunAfterInterception() [tiflash+155997115]\n                \tcontrib/grpc/src/cpp/server/server_cc.cc:433\n       0x94c5225\tgrpc::Server::SyncRequest::Run(std::__1::shared_ptr<grpc::Server::GlobalCallbacks> const&, bool) [tiflash+155996709]\n                \tcontrib/grpc/src/cpp/server/server_cc.cc:421\n       0x94d5d41\tgrpc::ThreadManager::WorkerThread::WorkerThread(grpc::ThreadManager*)::$_0::__invoke(void*) [tiflash+156065089]\n                \tcontrib/grpc/src/cpp/thread_manager/thread_manager.cc:36\n       0x989edd6\tgrpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::'lambda'(void*)::__invoke(void*) [tiflash+160034262]\n                \tcontrib/grpc/src/core/lib/gprpp/thd_posix.cc:110\n  0x7f36af496c02\tstart_thread [libc.so.6+564226]\n  0x7f36af51aed4\t__GI___clone [libc.so.6+1105620]"] [source="DisTaskId<MPP<gather_id:1, query_ts:1730149536627187623, local_query_id:5634, server_id:316, start_ts:453548320125354066,task_id:4>,executor=TableFullScan_78>"] [thread_id=445]


Adds GET Status on DKG

updates the GetElectionInfo to contain the roster
updates the DKG interface to have a Status() function
adds a proxy call to get the status of an actor
refactors the HTTP error function

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

26 of 46 (56.52%)  changed or added relevant lines in 2 files are covered.
5 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.04%) to 64.095%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

services/dkg/pedersen/controller/action.go
0
2
0.0%

services/dkg/pedersen/mod.go
26
44
59.09%

Files with Coverage Reduction
New Missed Lines
%

services/dkg/pedersen/mod.go
5
85.45%

Totals

Change from base Build<PHONE_NUMBER>:
-0.04%

Covered Lines:
3099

Relevant Lines:
4835

💛  - Coveralls


Update ctagsrc to work with export class

See the title.

actually this code doesn't work, because I'm not good with regex at all, but if you can make it work that'd be nice.


add key binding for commenting code

This PR adds a bindig to <leader> c / for comment/uncommenting code. I use this quite frequently so I thought it can be beneficial to others too.

Evil users can already use evil-nerd-commentary to do this, it's mapped on gc <motion> or gc if a region is selected or gcc to comment one line

Wow, didn't know that.
@hlissner Please close this if this PR does not provide any values in your eyes. :grin:


HuBERT pre-training for streaming ASR, ngram LM biasing of streaming ASR

Hello,
in a project, I am focusing on a streaming ASR (currently working with pruned_transducer_stateless7),
and we were asked to use Self-supervised pre-training for it.
And, I'd like to deploy the model in Sherpa, or sherpa-onnx afterwards.
I am thinking of taking the zipformer encoder from Librispeech recipe.
And add it as another encoder implementation for HuBERT training in ESPnet
or some other toolkit (fairseq, torchaudio).
But there might be some other possibility i am not aware of.
Would you have some suggestion?
Is the pruned_transducer_stateless7 recipe the closest fit for streaming ASR with HuBERT pre-training?
Would it also be possible to use an ngram LM to bias the ASR system with in-domain text data?
Thank you,
Karel

Is the pruned_transducer_stateless7 recipe the closest fit for streaming ASR with HuBERT pre-training?

pruned_transducer_stateless7 is a non-streaming recipe, its streaming version is pruned_transducer_stateless7_streaming. We also publish the latest version of zipformer (see here), which is currently our best streaming model.
Yes, you can use the encoder structure from the aforementioned recipes for HuBERT-style pre-training. Unfortunately, we don't have recipes for pre-training, you will need to implement it by yourself. I recommend to set up the pre-training pipeline in icefall, as this would make exporting the model easier.

Would it also be possible to use an ngram LM to bias the ASR system with in-domain text data?

Yes, we have various decoding methods with ngram LM based on rescoring/shallow fusion. For transducer-based models, we have fast_beam_search_* and modified_beam_search_ngram_rescoring  link here. For CTC-based model, we have normal ngram rescoring methods, see here

If you want to make use of a Hubert-type model, one way to do it is to dump feature embeddings from Hubert and use them as an auxiliary loss.  I believe it was giving us an improvement, I'll ask Liyong to comment on where / details.
If there is plenty of data, I doubt pre-training would help much or make that much sense; I think it would be better to do self-supervised by getting a transcript.  Amounts to the same thing because of SpecAugment.

If you want to make use of a Hubert-type model, one way to do it is to dump feature embeddings from Hubert and use them as an auxiliary loss.

Currently, we dump code_book_indexes extracted from hubert embeddings.  https://github.com/k2-fsa/icefall/blob/03853f1ee5bc71b7ff5e36289682a430a196f75e/egs/librispeech/ASR/distillation_with_hubert.sh#L180
It's quite easy to modify it if you want to save hubert embeddings.
As for the WER improvements see Table 4 from our mvq paper


HW 05.10.2016 Activities

Maksim Zakharenka
https://github.com/maxcriser/EpamTrainingProject/tree/master/HW_Activities

bad solution mark that login flow finished every time when MainActivity started;
better do that once when user finish login flow;
use java style for methods naming;
reuse one constant for putting and getting value from preferences

https://github.com/maxcriser/EpamTrainingProject/commit/a067600220fe9477d00e26592d9fa6273080744f

ok


Model X type missmatch

My car is identified as P90D ( I wish! :) ) instead of 90D.
The code for correct option codes is there:
defp get_efficiency("MX", "BTX4", true, _), do: {"X 90D", 0.208},
but the log says:
17:16:03.548 [info] Found Model X P90D:
My option codes:
"option_codes":"REEU,AD15,AF02,AH01,APF1,APH2,APPB,AU01,BC0B,BP00,BR00,BS00,BTX4,CC03,CDM0,CF01,CH04,COGB,PMBL,CW02,DRRH,DSH7,DV4W,FG02,FR02,GLTL,HP00,IDCF,IX01,LP01,LT3W,ME01,MI00,OSSW,PA00,PF00,PI01,PK00,PS00,QLEW,RFPX,S06W,SC01,SP01,SR01,ST02,SU01,TIM7,TM00,TP03,TR01,TRA1,TW00,UM01,UTAB,WT20,X001,X003,X007,X011,X014,X021,X025,X026,X028,X031,X037,X039,X042,X044,YFCC,MDLX"
Thanks!

Oh, good catch! It will be fixed soon.

Maybe relevant: my 3 Performance is identified as 3 LR. I can dig out the full option code list if needed, though I see you're fixing Performance identification across the board anyway :)

git pull https://github.com/adriankumpf/teslamate.git master
From https://github.com/adriankumpf/teslamate

branch            master     -> FETCH_HEAD
Updating 1676a89..b4bd1f2
Fast-forward
README.md                                |  5 +++++
lib/teslamate/vehicles.ex                |  3 ++-
lib/teslamate/vehicles/identification.ex | 60 +++++++++++++++++++++++++++++++++++-------------------------
3 files changed, 42 insertions(+), 26 deletions(-)

It works:
22:53:50.468 [info] Found Model X 90D:
Thanks!
Best regards,
Mihai

Oh, you're quick. It's not even released :) Thanks for testing!


(Question) Do you plan to detect livelocks?

Hi @hardBSDk,
Thank you for your question.
I haven't looked at livelocks in detail. Stated simply, livelocks are more difficult to detect with this framework. The source code would be translated to a Petri net that always has transitions that can fire, i.e., the net does not deadlock. Therefore, the model checker would not detect a problem. For livelocks you would have to enhance the translation to convert the livelock to a deadlock in a certain way, embedding a notion of "progress" in the Petri net somehow.
Livelocks were out of scope of my master thesis and I do not remember reading papers that dicussed applying Petri net methods to livelock detection during the literature review.
Hope that helps! Feel free to contact me if you have any further questions.


Can't run dotnet ef migration add

Running dotnet ef migration add causes error
Exception message:
Stack trace:
System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Microsoft.EntityFrameworkCore.Infrastructure.RelationalServiceCollectionExtensions.AddRelational(IServiceCollection services)
   at Microsoft.Extensions.DependencyInjection.SqlServerServiceCollectionExtensions.AddEntityFrameworkSqlServer(IServiceCollection services)
   at Microsoft.EntityFrameworkCore.Internal.ServiceProviderCache.<>c__DisplayClass4_1.<GetOrAdd>b__2(Int64 k)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Microsoft.EntityFrameworkCore.DbContext.InitializeServices()
   at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()
   at Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions.GetService[TService](IInfrastructure`1 accessor)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(Func`1 factory)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(String contextType)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Further technical details
EF Core version: 1.1.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Win 10
IDE: VS 2017

Possibly related to https://github.com/aspnet/EntityFramework/issues/7078.
@leolorenzoluis can you share a project that reproduces the issue

Work around is to use netcoreapp1.0 rather then netcoreapp1.1. The following config allowed me to create the migrations:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.0" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.0" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
  </ItemGroup>
  <ItemGroup>
    <None Update="Entities\ArtistSkills.d.ts">
      <DependentUpon>ArtistSkills.cs</DependentUpon>
    </None>
  </ItemGroup>

</Project>

External issue: dotnet/corefx#15031

@bricelam should this be closed on our side now?

I think so, but it's also another scenario we can use to verify #7078

I am still getting a similar issue.
Here is my .csjproj with all of my relevant version information.
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup Label="Configuration" Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <OutputType>Library</OutputType>
  </PropertyGroup>

  <PropertyGroup>
    <TargetFramework>netcoreapp1.1</TargetFramework>
    <ApplicationIcon />
    <OutputTypeEx>library</OutputTypeEx>
    <StartupObject />
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.2" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.1.2" />
    <PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="1.1.1" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0" />
  </ItemGroup>

</Project>

Here is the output from Package Manager Console.
PM> dotnet ef migrations add InitialCreate

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.31
System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at Microsoft.EntityFrameworkCore.Infrastructure.RelationalServiceCollectionExtensions.AddRelational(IServiceCollection services)
   at Microsoft.Extensions.DependencyInjection.SqlServerServiceCollectionExtensions.AddEntityFrameworkSqlServer(IServiceCollection services)
   at Microsoft.EntityFrameworkCore.Internal.ServiceProviderCache.<>c__DisplayClass4_1.<GetOrAdd>b__2(Int64 k)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at Microsoft.EntityFrameworkCore.DbContext.InitializeServices()
   at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()
   at Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions.GetService[TService](IInfrastructure`1 accessor)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(Func`1 factory)
   at Microsoft.EntityFrameworkCore.Design.Internal.DbContextOperations.CreateContext(String contextType)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.AddMigration(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.AddMigrationImpl(String name, String outputDir, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.<>c__DisplayClass3_0`1.<Execute>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
PM>

@agatlin Update the Microsoft.EntityFrameworkCore.Tools.DotNet package to version 1.0.1.

@bricelam Thank you Brice. I found the issue. When creating a .NET Core project in VS2017, the project is one directory lower than the solution. However, when you attempt to run any command in Package Manager Console, it runs those commands at the solution directory level. I just did a "cd  and then everything went fine. I think Microsoft should put this requirement in big bold letters everywhere they mention running anything with "dotnet ef ..." Thanks again for  your help.

Thank you very much bricelam!

@bricelam you've saved my day.

Updating the version of Microsoft.EntityFrameworkCore.Tools.DotNet to 1.0.1 didn't help until I changed the sdk in my *.csproj file from <Project Sdk="Microsoft.NET.Sdk"> to <Project Sdk="Microsoft.NET.Sdk.Web">

I'm getting this error for .NET Core 2.0

I was able to resolve this error by adding "GenerateRuntimeConfigurationFiles" to the csproj file.
`

netcoreapp1.1
true
`


K8SPXC-317 Made imagePullPolicy configurable

Test name
Status

recreate
passed

init-deploy
passed

storage
passed

scaling
passed

big-data
passed

self-healing
passed

restore-to-encrypted-cluster
passed

scaling-proxysql
passed

limits
passed

monitoring
passed

upgrade
passed

self-healing-advanced
passed

upgrade-consistency
passed

demand-backup
passed

security-context
passed

monitoring-2-0
passed

operator-self-healing
passed

affinity
passed

scheduled-backup
failed

one-pod
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

users
passed

demand-backup-encrypted-with-tls
failed

Test name
Status

scaling
passed

storage
passed

big-data
passed

recreate
passed

init-deploy
passed

scaling-proxysql
passed

self-healing
passed

limits
passed

restore-to-encrypted-cluster
passed

upgrade
passed

monitoring
passed

self-healing-advanced
passed

upgrade-consistency
passed

security-context
passed

demand-backup
passed

operator-self-healing
passed

monitoring-2-0
passed

affinity
passed

scheduled-backup
failed

one-pod
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

users
passed

demand-backup-encrypted-with-tls
failed

Test name
Status

storage
passed

big-data
passed

init-deploy
passed

recreate
passed

scaling
passed

self-healing
passed

scaling-proxysql
passed

limits
passed

restore-to-encrypted-cluster
passed

upgrade
passed

monitoring
passed

upgrade-consistency
passed

monitoring-2-0
passed

security-context
passed

demand-backup
passed

self-healing-advanced
passed

affinity
passed

one-pod
passed

scheduled-backup
failed

operator-self-healing
passed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

users
passed

demand-backup-encrypted-with-tls
passed

Test name
Status

storage
passed

recreate
passed

scaling
passed

init-deploy
passed

big-data
passed

self-healing
passed

limits
passed

restore-to-encrypted-cluster
passed

scaling-proxysql
passed

monitoring
passed

self-healing-advanced
passed

upgrade
passed

upgrade-consistency
passed

monitoring-2-0
passed

demand-backup
passed

security-context
passed

affinity
passed

one-pod
passed

operator-self-healing
passed

scheduled-backup
failed

auto-tuning
passed

proxysql-sidecar-res-limits
passed

users
passed

demand-backup-encrypted-with-tls
failed


Ensure output files from style-dictionary and build-tokens contain "Do not edit" messaging

By default, style-dictionary appears to include a file header at the top of its automatically generated output files to indicate to contributors that those output files are not intended to be manually edited.
Example:
// Do not edit directly
// Generated on Fri, 27 Jan 2023 16:54:59 GMT

:root {
  --pgn-color-primary-base: #FF0000FF;
}

Consider creating a custom file header with more details as well.
Without the file header, we run the risk of contributors wanting to manually edit the output files instead of editing the underlying design tokens instead.
The below config option may be related:
options: {
  showFileHeader: false,
},

Pull Request: https://github.com/openedx/paragon/pull/1985


Feature request: modsecurity WAF for reverse proxy and WebUI itself

Libmodsecurity (modsec 3) can be used with Apache or Nginx, and can be deployed embedded (in the target web server) or inline on the network as an HTTP reverse proxy.
HTTP endpoints being the primary target of choice these days, it seems like a useful tool to put on the belt, even in pure logging mode.

Hi there,
Recently we have had a release for ModSec v3. It is available here: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.0
It should work fine ;)

It's now in FreeBSD ports... www/mod_security3

Thank you!

@mimugmail If you want to get the ticket assigned, just let me know.

Yep, I'm way more comfortable with MS3, I'll start in April with this task :)

Thank you very much

AFAIK libmodsec can be used in nginx, but isn't quite up to feature parity with the apache module.

@fabianfrz created already a branch for nginx with Naxsi. When it's in master I'll try to add libmodsecurity .. which not depends on the webserver, so same features :)

For the brave :) https://forum.opnsense.org/index.php?topic=8877.0

@mimugmail the code is on the nginx branch of opnsense/plugins so it should be easy to contribute.

@mimugmail I built libmodsecurity 3.0.2 and it seems to be quite large:
% ls -lh src/.libs/libmodsecurity.so.3.0.2
-rwxr-xr-x 1 bonsai users 36M 16. Jun 08:43 src/.libs/libmodsecurity.so.3.0.2
% file src/.libs/libmodsecurity.so.3.0.2
src/.libs/libmodsecurity.so.3.0.2: ELF 64-bit LSB pie executable x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped

it may be better delivered as an extension since it is bigger than ruby ;)
I think we should see the nginx plugin as infrastructure for other plugins and allow plugins in a style like squid. @fichtner What do you think?

ok, 3M is small enough.

I think we should close this in favor of Nginx+Naxsi @fabianfrz already integrated. Would take too much work to offer both.

NAXSI is no longer maintained by NBS System. This renders Nginx+Naxsi obsolete. I kindly ask you to reopen this issue. @fabianfrz

@barti04  >> https://www.nginx.com/blog/f5-nginx-modsecurity-waf-transitioning-to-eol/

and https://github.com/opnsense/plugins/issues/3480

@AdSchellevis - just because SpiderLabs abandoned it doesn't mean its dead. @atomicturtle and his team maintain a commercial-grade fork of the code more than capable of meeting the need. Not having a WAF is sort of a no-go in the modern day and age, don't you think?

@sempervictus my personal opinion on the subject is not very relevant, I'm merely looking at upstream sources which look quite abandoned. (https://github.com/opnsense/ports/blob/master/security/modsecurity3-nginx/Makefile  and https://github.com/SpiderLabs/ModSecurity-nginx if I'm not mistaken).
Trading one dead project for another usually isn't the best plan in the world, but this isn't my plugin, so I won't hold anyone back from working on a replacement.

I dont get the point, isnt modsecurity available with OPNwaf plugin?
Naxsi has a new maintainer, should also be good to go?

@mimugmail yes, but we don't use Nginx (apache's binding seem to be more active, but maybe that doesn't make a difference).  Personally I don't mind what's being used in this plugin, just advice to investigate before choosing anything.


Improved rendering of arrays.

Composite arrays now render as a  list of composite data objects. Also, filter is now applied to all attribute values. Also fixed some bugs/inconsistencies in the templates.

Fixes #20.
Many thanks for this contribution!


Add Travis CI

https://travis-ci.org/

I've setup the job in Travis. Just need to:

[ ] Add .travis.yml
[ ] Add badge to README


RpcContext proxy

What is the purpose of the change
Brief changelog
Verifying this change

Checklist

[x] Make sure there is a GitHub_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GitHub issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Check if is necessary to patch to Dubbo 3 if you are work on Dubbo 2.7
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Add some description to dubbo-website project if you are requesting to add a feature.
[ ] GitHub Actions works fine on your own branch.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #12766 (b383d21) into 3.2 (848a577) will increase coverage by 0.70%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##                3.2   #12766       +/-   ##
=============================================
+ Coverage     68.66%   69.36%    +0.70%
+ Complexity      116        2      -114
=============================================
  Files          3653     1650     -2003
  Lines        170431    68384   -102047
  Branches      28021     9999    -18022
=============================================
- Hits         117021    47437    -69584
+ Misses        43284    16366    -26918
+ Partials      10126     4581     -5545

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

@CrazyHZM PTAL


Floyd Warshall Problem

Aim
The aim is to add the solution of the Floyd Warshall Problem using 4 different languages.
Details
This problem is very much useful for the interview purposes and I am going to provide the solution of this problem using 4 different languages and that will be great for any student and coder to understand the coding and the algorithms if they are not having good knowledge in a particular language.
Programming language

[x] C
[x] C++
[x] Java
[x] Python

you can work now @abhisheks008

@ravikr126 I have created the Pull Request for this problem. Can you please check it?

@Saurabh4626 Please check this PR

@Amit-45 I have created separate PRs for this issue. Please check that


fix:[#2398] Support Bots that use Single Tenant AAD Applications

Fixes # 2398
Description
This PR adds the support to use the tenant id value to authenticate Emulator into Single Tenant apps.
This feature requires bots with the las updates of botbuilder-dotnet and botbuilder-js:
PR # 321
PR # 123
Specific Changes

Added tenantId property to the classes involved in authentication.
Added support to obtain access token through Single Tenant login endpoint.
Added method to use tenant id value to create a dynamic issuer.

Testing
These images show the new field Tenant ID in the Open Bot and New Bot Configuration views.

This is the new message error related to authentication.

The following image shows the Emulator working with a bot using Single Tenant authentication.

@ceciliaavila @sw-joelmut
The feedback is applied
Tracy's answer about the gov auth with ST is pending

/promoted 2457


feat: auto load popups and auto populate help popup

This allows less locations to edit when adding a new popup

Figured when working on #599 that I'd make it such that the Help popup always reflects the popups available in the status buffer, and that they all work the same way.
This way it is easier to contribute new ones, as there were previously 3 different files oyu had to change to add one, now it is only one.
This is almost ready, just have to fix the lints.

Yeah, consolidating that is a great move.

Yes, the help buffer is a lot more useful now and is guaranteed to work the same (rather than error out as a popup required an argument when starting, but was supplied nil in the help buffer). A common example of this is the stash help which requires special feeding

It all works on my side, and the tests.
Though it is quite a large change as it touches the status buffer, so let me know if you find anything

Generally I really like this - hopefully I'll make some time later to look in more detail. Left some comments, I can definitely tell you're more at home with functional style stuff than I am - I dig that. Nice to learn new stuff

Everything looks great, except hitting ? pops up a notice saying there's no help popup :P
All the other popups seems to work though :)

That is strange. I am not getting that error, though it makes the popup close itself, likely a "race" between closing the previous popup and opening a new popup with the same name

This behavior can be seen on master as well

It can? The help popup comes up fine for me.
(also, this is why we need better test coverage)

Yes. What happens if you do ? and then a second later ?
For me that closes the help popup.
There are definitely a lot of the older parts of the neogit that need to be fixed and are quite buggy and magic.

How about we merge this for now, and then fix any outlying errors afterwards?
The contributing PR depends on this one, and having the contributing guide merged sooner than later would be preferred

Lemme just verify the help popup is working first

Ok, the problem was on my end: I had Toggle bound to both h and l (to work more like a file tree), and the help popup didn't like that. Unfortunately the error saying "popup not found" wasn't the most helpful, and I discovered this by adding error(value) to popups/init.lua.
So, everything looks good, but maybe we can improve the error handling?

Oh, great. I'll fix that then.
What did error(value) show, or in other words how does it fail to do pcall(require, "mod")?

Oh, great. I'll fix that then.
What did error(value) show, or in other words how does it fail to do pcall(require, "mod")?

If I add this to the setup(), the following error occurs
    mappings = {
      status = {
        ["l"] = "Toggle",
        ["h"] = "Toggle",
      },
    },

E5108: Error executing lua /Users/cameron/code/neogit/lua/neogit/popups/init.lua:20: vim/shared.lua:436:
The reverse lookup found an existing value for "Toggle" while processing key "<tab>"
stack traceback:
        [C]: in function 'error'
        /Users/cameron/code/neogit/lua/neogit/popups/init.lua:20: in function 'mapping'
        .../cameron/code/neogit/lua/neogit/lib/mappings_manager.lua:22: in function 'invoke'

        [string ":lua"]:1: in main chunk

Oh that's interesting, so the require fails because setup code is run when the module is loaded, and that fails.
I thought that require would only fail if not found, but I suppose it failing if anything errors makes sense, as lua allows generating modules entirely programmatically when loading instead of from a file (if you are crazy enough to do that and throw debuggabability out of the window)

Seems like one can no longer just do vim.keymap.set('n', '<leader>gc', neogit.popups.commit.create) - how can users invoke specific popups now?

vim.keymap.set('n', '<leader>gc', neogit.popups.open("commit"))

Would be enough if you do not want to pass extra data to the popup create function.


[Feature Request] Add option to hide specific devices

Hi,
I would like to have the functionality to only show the hot water switch as i find automations often fail with using homebridge to set states on the central heating.
Ideally there would be a line in the JSON variables to have hide-device = True / False
Is this something you can impliment

Came on here to ask the same.  I'd like to stick with the native HomeKit support for my Tado° system, except that doesn't expose the HW controls to Home/Siri, so was hoping I might be able to use this plug-in just for that (and exclude my other 15 Tado° devices!)

This feature gets a vote from me too. The Tado Platform plugin supports this capability, so it would be something else that would allow me to switch to this plugin.

Closed in favor of #31.

Closed in favor of #31.