Question: how to limit the number of lines on an axis?

Hi,
I would like to know if there is an option to show only specific number of lines on an axis. e.g. if I have the values [1, 2, 3, 4, 5, 6, 7, 8] for x, I want to show guides at [2, 4, 6] only, something like the attached screen.

Have you looked at the StockLineChartStaticTickLabels chart in the example app? I believe that is what you are trying to achieve above.

Yeah, I have tried this example, but the example shows how to set custom labels but does not show how to show only some lines e.g. out of 100 point show only 4

The number of tickValues specified in options drives the number of gridlines shown. For example, if I take the StockLineChartStaticTickLabels example and I remove the last 4 tickValues, I will see a chart with all the data points represented but only the first 3 tickValues show on the x-axis.
However, based on your screenshot and example above, I don't think thats what you are looking for - there's no way to use static tickLabel values and have them distributed evenly across the axis like you want.
Another option that I think achieves what you want is to use the undocumented tickCount attribute for the options property. For example if I take the StockLineChartDynamicTickLabels example chart and instead of wanting to display 7 tick labels/gridlines and want to only show 4 instead, I can do this:
let options = {
    axisX: {
    ...
        tickCount: 4,
...

The tickCount attribute has no effect when combined with static labels but it does take effect when using dynamic labels. So, you should be able to combine those techniques (dynamic labels and adding the tickCount option) as necessary to achieve what you want.

@pahmed Did the above suggestions above help? I'm closing this issue since I haven't heard any more about it for awhile but if you think there's a specific enhancement you think will handle this issue better, feel free to reopen and provide that feedback.

Yeah it worked, but I noticed that when I set the tickCount to 4, it draws only three, when 5 it shows 5 (as expected), and when 6 it shows only 5

Yeah it worked, but I noticed that when I set the tickCount to 4, it draws only three, when 5 it shows 5 (as expected), and when 6 it shows only 5

After looking at this more, it seems the original author's intent for the tickCount option setting was meant more to be a "target # of ticks" and so the behavior you describe above means that things are working as designed.
However, this really doesn't solve your original problem.
Ultimately, I think you want to be able to use the concept of "dynamic labels" via the labelFunction option to solve this using something like this:
labelFunction: ((v) => { return (v % 2 === 0) ? v.toString() : null }),

However, this produces an error like this:
null is not an object (evaluating 'children.length')

So, I'm working on addressing this bug in a new PR soon.


Admin should be able to filter visits by establishment, date and time

Admin should be able to enter an establishment name, a particular date and time and receive filtered details on users who have been in and out during the particular time period.

API endpoint: https://github.com/coronasafe/journal/blob/develop/doc/api.md#visits-filter

Ref https://github.com/coronasafe/journal/pull/79
@agneym


✨ feat(event): add model wildcard trigger

Add the ability to include wildcards (*) in the event trigger model in the plugin config. This can be achieved using the following format in the plugin config...
      trigger: {
        type: 'event',
        events: [
          {
            model: '*',
            types: ['create', 'update', 'delete', 'publish', 'unpublish'],
          }
        ]
      }

Resolves #24

Closing as this is now possible in v3


Fix Caret Navigation

Use updated position and previous position to find out whether to speak a character, word or line.
The algorithm is:

If the caret has moved by one space, read the charactee between the previous and current character.
If the caret has moved more than one space, but the words reported from Text::get_text(old_position, Granularity::Word), and Text::get_text(new_position, Granularity::Word) are detirmined to be the same word (note: NOT the same value), or exactly one word away from eachother (may need TextExt impls), then once again, read the text between the old and mew position.
Finally, check if the Text::get_text(new_position, Granulsrity::Line) is different from Text::get_text(old_position, Granulsrity::Line) are different, if they are, speak the entire line.

I think this should work for most cases. The second case may meed to use positions of various words to figute it out, but this is fairly close.
Also make sure to check is_tab_navigation()

Fixed by #88ca6f


Hyperparameter setting of GMM

Hello, thanks for your excellent work!
Can two input losses be entered in the fit() of GMM?
For example, gmm.fit(input_loss1, input_loss2)?
I am curious and want to try to use two losses to model GMM.

Hi, thanks for your interest in our method!
You can concatenate the two losses and pass into fit(), please see here for how to use gmm.fit():
https://scikit-learn.org/stable/modules/generated/sklearn.mixture.GaussianMixture.html#sklearn.mixture.GaussianMixture.fit

Thank you very much! Could you please provide the reproduced code of F-correction?

Hi, you can check out the author's implementation here: https://github.com/giorgiop/loss-correction


Update Bootstrap to latest

We are behind Bootstrap by a couple of releases. We currently use v3.0.2. We can upgrade to v3.3.2

Addressed in v2.0


identify mailbox by full email, including domain

(continued from  #31)

you cant search for<EMAIL_ADDRESS>mailbox is identified only by username, but not domain, so mail to<EMAIL_ADDRESS>and<EMAIL_ADDRESS>will go to one mailbox 'user'

So i think it would be better to identify mailbox by complete email, and get rid of '@inbucket' by the 'View' button.

This would probably be best as an opt-in feature, as it would significantly impact existing users.  I imagine it having 3 modes:

Hard Mailbox Only - Domain information is ignored on the SMTP side, and flagged as an error in Web UI and REST API. (Matching functionality in 1.0, 1.1)
Soft Mailbox Only - Domain information is ignored on the SMTP side, and also ignored in Web UI and REST API<EMAIL_ADDRESS>==<EMAIL_ADDRESS>Mailbox & Domain - Domain information is normalized and respected in SMTP, Web UI and REST API.

Merged into develop branch; is working for all the tests I can think of.  Since Inbucket doesn't have an integration test suite, there are problem some bugs somewhere.


Migrate Identity to Test Proxy

Contributes to https://github.com/Azure/azure-sdk-for-net/issues/24167

It looks like the cookie headers are not being set when using WebRequestTransport. This may be something we need to fix in HttpWebRequestTransport.
/cc @pakrym @christothes


db update failed,but save() method return true

Laravel Version
10.13.5
PHP Version
8.1.18
Database Driver & Version
MySQL 5.7.22 for centos 7.8 on x86
Description

$res is true , but this sql run error.

So :
Although this SQL statement executed an error, the save method of the model returned true and no exception was thrown
Steps To Reproduce
mysql table structure :

TINYINT accept value between 0 and 255, so 3+5000 is out of range.


Implement WRR in MOSN

The New Feature
Implement WRR in MOSN with the weight config from Istio
Your scenes
MOSN Istio WG roadmap
Your advice
plug smooth WRR route implementation into route filter chain. When doing route, return cluster if the condiction of using WRR is matched: weight config is set and not equal between clusters
Environment

MOSN v0.10.0

I found that cluster-wide WRR is done in here, and endpoint-wide WRR can not yet be configured by Isito, so this may be a finished issue


add wrapper scope van

Add scope for van
Example: https://github.com/vanjs-org/van/pull/333

I was trying to understand what this PR tries to do. If I understand correctly, the purpose of this PR is to avoid passing around the van object while building components shared between SSR and CSR. The PR introduced the notion of van object context so that we can call getVan function to get the van object instead of having to pass it around.
Sample code with the feature in this PR will look like that:
In shared components:
const Component = props => {
  const van = getVan()
  const {div, span} = van.tags
  return div(
    span(...)
    span(...)
  )
}

In the main file:
van.add(document.body, withVan(van, () => div(
  Component(...),
  Component(...),
))

My personal take about this approach:

The support of van object context doesn't need to be implemented in the core library. I think this can be achieved in a standalone VanJS add-on.
The idea of context can be even more generalized. We can leverage the notion of context to pass around any global object, not just the van object. There is a relevant discussion about general-purpose context in the past. I didn't follow through the entire thread, but this could be something interesting to read: https://github.com/vanjs-org/van/discussions/173.

I thought that one of the goals of this repository is to provide a better experience for SSRs and this WP allows us to improve the experience of building components shared between SSRs and CSRs
that's why I thought I would add it here.
I agree that the proposed context is similar to VanJS add-on but wrapping each function to store the context looks very complicated
The main goal of this PR is to allow components to be shared between SSR and CSR with minimal changes

I agree with you that this feature provides better developer experience for some people and some use cases. Appreciate it. Are you comfortable to implement the feature as a standalone add-on of VanJS? This way it will be easier for the author to manage the documentation and future evolution of the add-on.

I'm afraid that hundreds of libraries that will add one feature at a time that helps to better interact with this particular library may discourage future developers
and I doubt that any improvements will be needed, this feature looks complete
the only thing that will be possible is to expand the SSR documentation page

My view is: using context instead of parameter passing is an opinionated approach. Objectively speaking, there are pros and cons for each approach, either context or parameter passing.
The general philosophy is: if some people prefer one programming flavor over the other, they can extend VanJS with add-ons. I understand people's preferences and appreciate their contribution to VanJS, but the core library of VanJS is kept neutral over different programming flavors.
There are already add-ons for that exact purpose: van-jsx (JSX flavor for DOM tree composition), van_dml (DML flavor for DOM tree composition).

Thanks for tagging me in.
@sirenkovladd perhaps updating the examples for us mortals without bun would do to understand and hopefully make time to test :biting_lip:
I really think both context API and this wrapper scope are essential for application development. Context API is always useful for all scopes from global application scope down to the smallest component, while the wrapper makes sure all components are reliably and easily rendered without too much hustle for your regular Joe.
Guys, the surprise I had for you was an SSR example I was working on, perhaps for create-vite-extra, but as explained above I find it a bit frustrating NGL.
Just my 2cents.

Hi @sirenkovladd / @thednp,
Mini-Van 0.6.0 was just released, which improves the developer experience of fullstack rendering. Among other things, it allows van object to be registered via registerEnv so that the van object doesn't need to be passed around shared components via parameters. Thus with Mini-Van 0.6.0, we now have a solution for the problem this PR tries to solve.


Coco Amber on Stampede....

I got this:
2015-10-15 16:38:02,535: radical.enmd.simulation_analysis_loop.static.default: MainProcess                     : Thread-3       : ERROR   : ComputeUnit error: STDERR: [... CONTENT SHORTENED ...]
DAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/core/AtomGroup.py", line 3094, in __init__
    self.load_new(coordinatefile, **kwargs)
  File "/work/02998/ardi/coco-0.21_installation/lib/python2.7/site-packages/MDAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/core/AtomGroup.py", line 3623, in load_new
    self.trajectory = reader(filename, **kwargs)    # unified trajectory API
  File "/work/02998/ardi/coco-0.21_installation/lib/python2.7/site-packages/MDAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/coordinates/TRJ.py", line 527, in __init__
    raise ImportError("netCDF4 package missing.\n"
ImportError: netCDF4 package missing.
netcdf4-python with the netCDF and HDF5 libraries must be installed for the AMBER ncdf Reader.
See installation instructions at https://code.google.com/p/mdanalysis/wiki/netcdf
Exception AttributeError: "'NCDFReader' object has no attribute 'trjfile'" in  ignored
[c559-902.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process (rank: 0, pid: 69298) exited with status 1
, STDOUT: [... CONTENT SHORTENED ...]
DAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/core/AtomGroup.py", line 3094, in __init__
    self.load_new(coordinatefile, **kwargs)
  File "/work/02998/ardi/coco-0.21_installation/lib/python2.7/site-packages/MDAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/core/AtomGroup.py", line 3623, in load_new
    self.trajectory = reader(filename, **kwargs)    # unified trajectory API
  File "/work/02998/ardi/coco-0.21_installation/lib/python2.7/site-packages/MDAnalysis-0.9.0-py2.7-linux-x86_64.egg/MDAnalysis/coordinates/TRJ.py", line 527, in __init__
    raise ImportError("netCDF4 package missing.\n"
ImportError: netCDF4 package missing.
netcdf4-python with the netCDF and HDF5 libraries must be installed for the AMBER ncdf Reader.
See installation instructions at https://code.google.com/p/mdanalysis/wiki/netcdf
Exception AttributeError: "'NCDFReader' object has no attribute 'trjfile'" in  ignored
[c559-902.stampede.tacc.utexas.edu:mpispawn_0][child_handler] MPI process (rank: 0, pid: 69298) exited with status 1

2015-10-15 16:38:02,536: radical.enmd.simulation_analysis_loop.static.default: MainProcess                     : Thread-3       : ERROR   : Pattern execution FAILED.

Thanks Giannis. I think this could be permission issue;
At /work/02998/ardi/coco-0.21_installation/lib/python2.7/site-packages/:
-rwxr-xr-x 1 ardi G-801782  1775 Sep 30 03:55 site.pyc
-rwxr-xr-x 1 ardi G-801782  2389 Sep 30 03:55 site.py
drwxr-xr-x 4 ardi G-801782  4096 Sep 30 03:55 extasy.coco-0.21-py2.7.egg
drwxr-xr-x 4 ardi G-801782  4096 Sep 30 03:56 MDAnalysis-0.9.0-py2.7-linux-x86_64.egg
-rwxr-xr-x 1 ardi G-801782 60581 Sep 30 03:56 GridDataFormats-0.3.0-py2.7.egg
drwxr-xr-x 5 ardi G-801782  4096 Sep 30 03:56 networkx-1.10-py2.7.egg
drwxr-xr-x 5 ardi G-801782  4096 Sep 30 03:56 biopython-1.65-py2.7-linux-x86_64.egg
-rwxr-xr-x 1 ardi G-801782   384 Sep 30 03:57 easy-install.pth
drwxr-xr-x 3 ardi G-801782  4096 Sep 30 03:57 decorator-4.0.4-py2.7.egg
drwx------ 2 ardi G-801782  4096 Sep 30 04:01 netcdftime
drwx------ 2 ardi G-801782  4096 Sep 30 04:01 netCDF4-1.2.0-py2.7.egg-info
drwx------ 2 ardi G-801782  4096 Sep 30 04:01 netCDF4

so you don't see the netCDF4 package there. It works for the rest(in extasy team), because they probably have it in $HOME/.local. I will ask ardita to change the permissions.

Sorry, I was not aware of this just changed permissions, hope this solves the problem.
login3.stampede(16)$ ls -l coco-0.21_installation/lib/python2.7/site-packages/
total 104
drwxr-xr-x 5 ardi G-801782  4096 Sep 30 03:56 biopython-1.65-py2.7-linux-x86_64.egg
drwxr-xr-x 3 ardi G-801782  4096 Sep 30 03:57 decorator-4.0.4-py2.7.egg
-rwxr-xr-x 1 ardi G-801782   384 Sep 30 03:57 easy-install.pth
drwxr-xr-x 4 ardi G-801782  4096 Sep 30 03:55 extasy.coco-0.21-py2.7.egg
-rwxr-xr-x 1 ardi G-801782 60581 Sep 30 03:56 GridDataFormats-0.3.0-py2.7.egg
drwxr-xr-x 4 ardi G-801782  4096 Sep 30 03:56 MDAnalysis-0.9.0-py2.7-linux-x86_64.egg
drwxr-xr-x 2 ardi G-801782  4096 Sep 30 04:01 netCDF4
drwxr-xr-x 2 ardi G-801782  4096 Sep 30 04:01 netCDF4-1.2.0-py2.7.egg-info
drwxr-xr-x 2 ardi G-801782  4096 Sep 30 04:01 netcdftime
drwxr-xr-x 5 ardi G-801782  4096 Sep 30 03:56 networkx-1.10-py2.7.egg
-rwxr-xr-x 1 ardi G-801782  2389 Sep 30 03:55 site.py
-rwxr-xr-x 1 ardi G-801782  1775 Sep 30 03:55 site.pyc

Thanks Ardita. Giannis, please give it another try.

Thank you, it worked!
I am closing the ticket

Thanks Giannis !
On Fri, Oct 16, 2015 at 11:15 AM, Ioannis Paraskevakos <
<EMAIL_ADDRESS>wrote:

Thank you, it worked!
I am closing the ticket
—
Reply to this email directly or view it on GitHub
https://github.com/radical-cybertools/radical.ensemblemd/issues/94#issuecomment-148743604
.


Mockito should support mocking new instances

From<EMAIL_ADDRESS>on September 11, 2009 12:03:44
it should
Original issue: http://code.google.com/p/powermock/issues/detail?id=157

From<EMAIL_ADDRESS>on September 11, 2009 08:04:50
Status: Fixed


New release needs to be published

The currently published version of this package is broken with Neutrino v5. It would be great if the fixes in master would be rolled into a new release.

https://github.com/theodesp/neutrino-preset-typescript/pull/6


Support SKIP_VAR_SET in Makefile

In case a non empty SKIP_VAR_SET is exported,
Makefile would respect it and not install skopeo
in case skopeo doesn't exists.
This will allow to use the sriov-operator with non root users.
See please https://github.com/openshift/sriov-network-operator/blob/52480752f6582cf2829845f291a147d75c23756e/hack/env.sh#L1
for more details about SKIP_VAR_SET and its purpose to allow
running without skopeo installed, when env vars are overridden by the user.
Signed-off-by: Or Shoval<EMAIL_ADDRESS>

/cc @zshi-redhat

/lgtm

Thanks @zshi-redhat
Looks like this repo dont have bots of lgtm and hold (as i tried on other PR)


Use channels here ?

how about using channels to take care of removals and waitgroup on all ? overkill probably ?
https://github.com/tj/node-prune/blob/03dd2717c9a27cc08fe86a5b0bae8654f403b464/prune.go#L163

suuure why not :D might as well speed it up, as-is it seemed to be around ~400-500ms for a pretty big project but they certainly get much bigger


200 item max in the autoindexing?

Hi I am having trouble with the new list constructor when the list already exist it only store the first 200 items... is it possible to store more?

@jsalamin  there is a new settings option non-intuitively named 'page' that is now auto default to 200.  Set this page to the upper limit you think you will need in the options json blob when you initialize a List.
Recommend the author clearly note this several places in the documentation and rename the setting to something more intuitive like maxPageItems or pageItemLimit or something more accurately describing what the setting actually does.

:+1:
I'll give the name and default setting a thought!

Hi there,
Is there any functionality for lazy loading of Json data where we could have images and can loaded on demand?

@chand3040 Nja, not really! But you can implement it yourself and use the .add() method.

@javve  Thanks for the reply.
But I was looking if that could be available as a functionality.
Anyways thanks for the reply.

Hi folks,
Thank you for these comments.
           var options = {
              valueNames: ['day','date','location'],
              plugins: [ ListFuzzySearch() ],
              page:1000
            };
            var userList = new List('list-js',options);

By setting the "page" option to 1000, I was able to do everything I need.
I would hate for my list to grow and not realise this! Might this 200 limit be made more explicit?


Reproducible integration testing with simulated time

@xosmig @matejpavlovic I think you could already look into this draft PR. I just need to rebase and adjust it accordingly.

Summary of changes: addressing review comments.


workspace.onDidCloseNotebookDocument no longer getting fired when closing notebooks

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: Insiders
OS Version: Mac

Steps to Reproduce:

Add an event handler to workspace.onDidCloseNotebookDocument
Open a Jupyter notebook document
Then close it,
the above event handler is never invoked.

I tried to find the cause, but have no idea where the issue is.
@rebornix @bpasero  /cc

It's very likely memory leak where the notebook document is ref'ed and never released.

Caused by https://github.com/microsoft/vscode/blob/4665ce61312f31f22607b5c72a4492b5ecaf7a98/src/vs/workbench/contrib/notebook/browser/view/cellParts/codeCell.ts#L149-L161

There are two this.viewCell.resolveTextModel() runs at the same time, so the text model is resolved twice, and BaseCellViewModel.textModelRefis also set twice (the later one overrides the former one). Thus we have a zombie model ref. Should be fixed via https://github.com/microsoft/vscode/pull/205921 .
cc @Yoyokrazy


Update iothub.json

ARM API Information (Control Plane)
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
By default, Azure SDKs of all languages (.NET/Python/Java/JavaScript for both management-plane SDK and data-plane SDK, Go for management-plane SDK only ) MUST be refreshed with/after swagger of new version is published. If you prefer NOT to refresh any specific SDK language upon swagger updates in the current PR, please leave details with justification here.

Contribution checklist (MS Employees Only):

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you copy the existing version into the new directory structure for first commit and then push new changes, including version updates, in separate commits. You can use OpenAPIHub to initialize the PR for adding a new version. For more details refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If you have any breaking changes as defined in the Breaking Change Policy, request approval from the Breaking Change Review Board.
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.
NOTE: To update API(s) in public preview for over 1 year (refer to Retirement of Previews)
Please follow the link to find more details on PR review process.

@rkmanda and @haolingdong-msft , Just to call out that the existing documentation had two mistakes:

Description of the fallbackroute was incorrect. This has been corrected.
Fallbackroute "IsEnabled" property - This is not a required property. If this property is not present in the ARM template, the template still runs successfully, and it has been this way since the last 3 years. So, this is not a breaking change in the existing behaviour, but a correction to reflect the correct way of working.

@rkmanda @haolingdong-msft This PR has been pending for more than a week now. Request your help in merging this one. Please let me know in case of any queries or further updates that you want me to make. Thanks!

@kgremban @rkmanda is this something that you can help with in approving? Please let me know if there is anything more I could do to expedite.

@rkmanda @kgremban @haolingdong-msft reminder ping here to help merge this changes.

@lirenhe tagging you here for visibility, as I am unable to reach to @rkmanda for closure on this request. Please help merge this pull request into the main branch. Thanks!

Please follow the below action for breaking change review:
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Additional details on the process and office hours are on the Breaking Change Wiki.

@lirenhe This is not exactly a breaking change, please see the details below:

Description of the fallbackroute was incorrect. This has been corrected.

Fallbackroute "IsEnabled" property - This is not a required property. If this property is not present in the ARM template, the template still runs successfully, and it has been this way since the last 3 years. So, this is NOT a breaking change in the existing behaviour, but a correction in documentation to reflect the correct way of working.

Would we still need to follow the breaking change review process for this? Please let me know, I will raise accordingly. Thanks!

@lirenhe This is not exactly a breaking change, please see the details below:

Description of the fallbackroute was incorrect. This has been corrected.
Fallbackroute "IsEnabled" property - This is not a required property. If this property is not present in the ARM template, the template still runs successfully, and it has been this way since the last 3 years. So, this is NOT a breaking change in the existing behaviour, but a correction in documentation to reflect the correct way of working.

Would we still need to follow the breaking change review process for this? Please let me know, I will raise accordingly. Thanks!

Thanks for providing this.
Yes, breakingChange review board will decide whether this is really a breaking change based on your justification.  So please raise a review request and discuss with them.


More safeguards

Add more safeguards when wrappers are called from within another container
so that we can fail gracefully.

Solved by #14


Character eye customization, scroll bar in appearance tab character setup. Fixes #2946

About the PR
Requires space-wizards/RobustToolbox#1595
Fixes #2946
This adds a set of color bars in the character customization screen that lets you adjust the eye colors of your character. It also adds a scroll bar for the appearance tab on the character setup screen, since the colors bars could not fit on the UI otherwise.
Screenshots

Reviews applied, this should be mergeable?


services: Make it easier to add/extend services

Signed-off-by: Ryan Northey<EMAIL_ADDRESS>Fix #3

Codecov Report

Merging #141 (8231aa7) into main (d4be700) will decrease coverage by 2.18%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #141      +/-   ##
==========================================
- Coverage   43.16%   40.97%   -2.19%
==========================================
  Files          89       82       -7
  Lines        2347     2260      -87
==========================================
- Hits         1013      926      -87
  Misses       1334     1334

Impacted Files
Coverage Δ

playground/control/api/listener.py
82.97% <100.00%> (ø)

tests/py/connectors/docker/base.py

tests/py/command.py

tests/py/request.py

tests/py/run.py

tests/py/validators.py

tests/py/runner.py

tests/py/event.py

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 d4be700...8231aa7. Read the comment docs.


[Tooltip] Left/right tooltips in RTL have incorrect tip placements

Description

Steps to reproduce

Go to here
Switch to RTL
Scroll down to "Directions"
See the left/right tooltips
They don't touch the container and get larger as they move away from the container

Expected behavior
Tips should touch the container on their wide edge and get smaller
Screenshots

Tracking this in Jira via CSS-748

@Westbrook this fix is available in<EMAIL_ADDRESS>https://github.com/adobe/spectrum-css/commit/f487f473cf39cd6ec8a8646e6671391985e955f1


RTE on startup

I'm update plugin from Jetbrains repository and can't open haxe module.
full log: https://gist.github.com/silvertoad/0038af853aab778d7bb2

@silvertoad IntelliJ 14.0.3 is not yet support, per #139 - it's frustrating, especially given no release notes regarding it combined with its destructive force on IntelliJ IDEA.

His log clearly shows "Unsupported major.minor version 51.0", which means he is running IDEA under Java 6, and the one in JetBrains repository had been recompiled using Java 1.7.  That has been updated this morning, so it should run.
That said, don't run it with IDEA 14.  That it was picked up automatically by IDEA 14 should be fixed this morning also: according to Boyan, he marked the new release as 13-only so that IDEA 14 users pick up the old one from the JetBrains IDEA repository.
@jasonSturges - As for the plugin's "destructive force," it would be great if you could tell us what happened to your projects (in Issue #18, or a new issue, if you prefer)  when you installed it.  I expected that it wouldn't run correctly, but I did NOT expect it to corrupt projects, sources, etc..

@jasonsturges -
When I first installed the incorrectly built plugin yesterday, I experienced similar stuff other users complained i.e. cannot see my modules or project hierarchy. I was concerned as well, if I lost any files or project definition / meta files.
But I realized that everything was in-tact, like EBatTiVo mentioned. Because plugin could not be loaded, I was not seeing the contents of any 'haxe' project or 'haxe' sdk. I uninstalled that incorrect version.
Once I installed correct version of intellij-haxe plugin, 0.9, released earlier today - everything is normal.

@sganapavarapu1 @EBatTiVo Thanks, I'll check out 0.9 released today; however, my interest is waning until IntelliJ IDEA 14 is supported.
Since IntelliJ IDEA 14 is not yet supported, I presume development will expose the current issues.  There are tickets I've logged and participated in, such as #67 in which the plugin froze IntelliJ to an unusable state, which has been labeled an enhancement for some reason.  Many tickets here could probably be closed per #18.
Definitely appreciate your extending use of Haxe plugin beyond TiVo to the community.

@jasonsturges I released alpha for IntelliJ IDEA 14

@as3boyan Thanks for letting me know - is that under the ClassHierarchy branch?  I don't see a prerelease.

@jasonsturges - He released it on the JetBrains repository: http://plugins.jetbrains.com/plugin/6873?pr=idea
It isn't fully checked into any of the TiVo trees or the JetBrains github repo yet.

@jasonsturges https://twitter.com/As3Boyan/status/576068981699772416/photo/1

@as3boyan @EBatTiVo Cool - it installed, and looks good at first glance although I can't compile or run.  Thanks for the heads up - I will continue to monitor the alpha releases from JetBrains repositories.

@jasonsturges It compiles flixel project for me.

Starts flash player fine if run without debug.

Flash target: Debugger never attaches. Plugin and projector content debugger is installed. Maybe I have the wrong port (6972). Also OpenFL argument never persist - when I close the Project Structure dialog and reopen it, my previously entered values are lost. I've added argument -debug.

This is still happens, the only workaround for it I know is enabling separate compilation in project options.
I also tested on Haxe/Neko project - compiles fine, runs in terminal.
Please specify your project type/configuration.
Also, it's wierd that IDEA/plugin copies source files to production folder

OpenFL project, which compiles / runs from the command line; however, plugin 0.9.2 gives me:

Since IntelliJ IDEA 14 support is alpha, I'll try to do some rounds of testing if I get some time.  Thanks.

I think warnings should be replaced with real command if possible

@as3boyan I don't understand what you mean by the previous comment.
The fake warning has nothing to do with the error that @jasonsturges is seeing.  The real error is showing up properly.
That said, the error seems to be that haxelib (or whatever is actually executing) doesn't support the "run" command.  That makes me think that the command we're trying to execute isn't formatted correctly.  Perhaps we should always echo the command we're running as an information line to the compile output.


style: Animated docs

Related Issue
closed #1903

Description
Animated the docs section

Screenshots

@priyankarpal Done Bro. It was really a needle in the husk.

@Souravvmishra For secure collaboration, remember to check out GitHub's commit signature verification feature. It helps ensure the authenticity of commits and prevents tampering.
Learn how it works: GitHub Docs
Happy coding! 😄

That sounds interesting. TBH I never heard about that. Thanks For The Suggestions Bro. I'll make sure I follow it for next PRs


Saved Notes presented/New Note title + text field

GIVEN a note-taking application
WHEN I click on the link to the notes page
THEN I am presented with a page with existing notes listed in the left-hand column, plus empty fields to enter a new note title and the note’s text in the right-hand column

All issues have now been resolved and the webpage is able to successfully load all the save note data from 'db.json' on the left-hand side of the page when clicking on the blue icon from the homepage!


How to retrieve the rendering given by HasShadow and Elevation?

Hello,
I've launched a Xamarin.Forms sample that use PancakeView with elevation, but without shadow.
The style of the PancakeView is defined like this:
<Style x:Key="FrameTotal" TargetType="pancake:PancakeView">
    <Setter Property="BackgroundColor" Value="#FFFFFF" />
    <Setter Property="CornerRadius" Value="10" />
    <Setter Property="Elevation" Value="4" />
    <Setter Property="HasShadow" Value="False" />
    <Setter Property="Padding" Value="0" />
</Style>

Here is the default result screenshot: there is a light border and a very light shadow.
However, after having updated the packages Xamarin.Forms to <IP_ADDRESS>1 and Xamarin.Forms.PancakeView to <IP_ADDRESS>4, the borders are no longer visible.
Here is the new result screenshot. The result is the same on iOS and Android.
I've tried to play with the <Shadow/>, but I didn't found how to reproduce the initial rendering. T
<pancake:PancakeView
    Grid.Row="1"
    Grid.Column="2"
    Style="{DynamicResource FrameTotal}">
    <pancake:PancakeView.Shadow>
        <pancake:DropShadow Offset="0,0" />
    </pancake:PancakeView.Shadow>

he shadow is bigger as we can see on this screenshot.
Is there a way to retrieve the previous rendering with the latest packages?

The HasShadow and Elevation properties were deprecated in favor of using Shadow.
For iOS, the shadow from HasShadow was:
Radius = 10;
Color = Black;
Opacity = 0.4f;
Offset = 0,0;

If you used Elevation:
Radius = elevation;
Color = Black;
Opacity = 0.24f;
Offset = 0, elevation;

For Android, it pretty much comes down to BlurRadius = Elevation. Not sure if there's an easy way to reproduce what it was except for playing with the BlurRadius.

Thanks for your feedback.
I've applied the values that you've given for Elevation, but I don't get the expected result, as we can see on this screenshot.
So I will keep this approach, but it's too bad that we can't longer reproduce a "Material" rendering...
In add, is there a way to apply styles to PancakeView.Shadow and PancakeView.Border? I use PancakeView in different places, and it seems that I have to duplicate all this styles. This is a little tricky, as I need additionally to applied some values per platform (for the opacity for example).

I'm pretty sure that with some tinkering a similar result can be achieved. Regarding styling, yes, you can definitely set these in a style. Something along these lines should be possible:
<Style>
   <Setter Property="Shadow">
      <Setter.Value>
         <yummy:Shadow />
      </Setter.Value>
   </Setter>
</Style

Or alternatively:
<yummy:Shadow x:Key="SpecificShadowType" />
<Style TargetType="yummy:PancakeView">
    <Setter Property="Shadow" Value="{StaticResource SpecificShadowType}">
</Style>

Needs some more work, but you get the idea :)

Hi @sthewissen, thanks again for your feedback.
Finally, I found a solution that satisfies me to have a Material rendering:
<yummy:PancakeView CornerRadius="8" BackgroundColor="White">
    <yummy:PancakeView.Shadow>
        <yummy:DropShadow Offset="1,2" Color="Black">
            <yummy:DropShadow.BlurRadius>
                <OnPlatform x:TypeArguments="x:Single">
                    <On Platform="Android" Value="2" />
                    <On Platform="iOS" Value="2" />
                </OnPlatform>
            </yummy:DropShadow.BlurRadius>
            <yummy:DropShadow.Opacity>
                <OnPlatform x:TypeArguments="x:Single">
                    <On Platform="Android" Value="1" />
                    <On Platform="iOS" Value="0.2" />
                </OnPlatform>
            </yummy:DropShadow.Opacity>
        </yummy:DropShadow>
    </yummy:PancakeView.Shadow>
</yummy:PancakeView>

However, I didn't yet found a way to apply the Shadow as a style.
I've created a new styles like this:
<Style x:Key="YummyShadowFrame" TargetType="yummy:DropShadow">
    <Setter Property="Offset" Value="1,2" />
    <Setter Property="Color" Value="Black" />
    <Setter Property="BlurRadius" Value="{OnPlatform Android=1, iOS=4}"/>
    <Setter Property="Opacity" Value="{OnPlatform Android=1, iOS=0.2}"/>
</Style>
<Style x:Key="YummyFrame" TargetType="yummy:PancakeView">
    <Setter Property="BackgroundColor" Value="White" />
    <Setter Property="CornerRadius" Value="8" />
    <Setter Property="Shadow" Value="{StaticResource YummyShadowFrame}" />
</Style>

But there is no way to apply the Shadow: only the PancakeView style is applied, not the DropShadow style...

Oddly enough, this version does seem to work:
            <Style x:Key="YummyFrame" TargetType="yummy:PancakeView">
                <Setter Property="BackgroundColor" Value="White" />
                <Setter Property="CornerRadius" Value="8" />
                <Setter Property="Shadow">
                    <yummy:DropShadow Offset="1,2" Color="Black"
                                      BlurRadius="{OnPlatform Android=1, iOS=4}"
                                      Opacity="{OnPlatform Android=1, iOS=0.2}" />
                </Setter>
            </Style>

Not quite sure why that would but the static resource route doesn't.

@sthewissen yes you're right, thank you again!


Fix gradle for up-to-date build version

I checked out your project yesterday, and I couldn't compile it in Android Studio 1.5.1.
I modified it like this.

Thanks @BattleShipPark , this change is necessary. I did it in one branch but forgot to merge into master. Glad you found it :)


Information - SDCard initialization can correctly drive FlashAir Wifi SD Card

This is not really an issue, its just a piece of information.
Unlike marlin, grbl-Mega seems to correctly enable the SD Crad in such a way that the Toshiba FlashAir Wifi SD card works correctly and can be connected to: This works for most 3d Printers but for some reason has never worked correctly with Marlin.
See the article i wrote on the subject of setting it up for a 3d printer on:
http://microfabricator.com/blogs/view/id/54e438e56983c5316480205e/using-a-flashair-wifi-enabled-sdcard-with-your-3d-printer

This is not really an issue, its just a piece of information.

All Bugs are Issues, but not all Issues are Bugs... 😏
In the credit-where-it's-due department... I did not write the SD library that I used myself; I just ported it to run in the Grbl-mega environment. Parts of it came from the Arduino project; parts of it were contributed by SparkFun. I did not intend for this to work... but since it does... BONUS! 😄
From your article:

By contrast sending that amount of data across a USB 2.0 link to an Arduino or other 3D printer controller can take up to 30 minutes.

That's because most 3D printer controllers are based on AVRs that lack a native USB interface... there's some USB to serial port chip sitting in the middle, and those are comparatively slow... even cranked up to the max baud rate that they support. The ARM port of Grbl that Chamnit is working on should help with this issue; should one wish to have their CNC tethered to a PC/Mac (I don't - which is why I have it reading from an SD card).
Hmm... Amazon also lists a bunch of other SD/WIFI cards, some for about half of the price of a Toshiba.... do you know if any of those work also?

I have not had any experience with anything other than a FlashAir, i managed to het two of the version 2 cards for next to nothing,  i have heard stories about other cards that indicate they may have reliability issues, the FlashAir is rock solid.  I have one in my 3d Printer and now one in my CNC rig, i live in a condo and space is at a premium, so my machines live on a workbench on my balcony, so getting connections to them is tricky, the wifi cards make that simple, and allow me to send files from any .
Im thinking of adding a Raspberry PI instead of the FlashAIR running OctoPI with the gerb CNC plugin, that way i can remote control the machine via Wifi, and have it stream video from a cheap camera back to me.
 Here, I'd be worried about them getting ruined during a winter storm...

Im thinking of adding a Raspberry PI instead of the FlashAIR

Should work... I deliberately left the serial IO system intact... If you find any problems, please let me know about it so I can fix them.

There are combo boards ARDUINO MEGA2560 R3 ATmega328 + WiFi ESP8266 on single PCB - pin layout in Mega compatible. This could add simple way to use WiFI with grbl.
I currently use ESP32 for my PID controller for kilns - with full HTTP server - and it works quite well (it's much more powerful then Atmega in any way - just doesn't have as many pins as 2560 :) )

I should probably order one for testing... I should be able to set it up so that you can send a file over the ESP8266 - perhaps via wget or curl, as the last step in a postprocessor script - and cache the file on the local SD card (this would eliminate any timing 'hiccups' in reading the file over the WiFi link). Hmm....

ESP has plenty of RAM and cpu power (2 cores) + local memory/disk (up to 4MiB) called SPIFFS. So you/we can easily use it to prepare webserver with webpage to all uploading/setup changes etc. Store in on local SPIFFS and then in background feed it to sdcard - or perhaps even dirrectly from SPIFFS to Atmega for process (I don't know how exactly this board is constructed).
I'm up2date with webserver and/on esp - so I can help/write this part.

Hmm... I don't think we should be storing g-code files on the SPIFFS. It's only 32MB; and I wouldn't want to wear it out (I'm not sure how good the flash is that ships on those cards, but I suspect it will die long before a good SD card will). Also, a SD card is easy to replace - in practice, for most users, fixing the soldered-down flash is going to mean replacing the whole board; and re-doing the configuration for the machine.

Well it's something to consider - but I've been also worrying about wear out of this flash and Espressif claims it's using chips that will withstand at least 100 000 writes. So this is a lot, for this type of usage - don't believe singe user can wear it out.
Probably the same chips are used for PSRAM (pseudo ram) - this can be also next 4-16GiB to malloc data (depending on used board) - but I guess this Mega+ESP8266 combo won't be so generous in flash.
Also SPIFF is directly accessible from ESP - SDCard isn't - at least with current MEGA configuration. So this makes it good intermediate storage, and in my opinion, better storage because I do not like to swap sdcards in my printers anyway (this is my experience - I've been driving my CNC router directly from computer). So uploading with http seems to me much more flexible. There is nothing against using both storages ... as raid :D - kidding, just two storages :)


mkShellMinimal: Create an ultra minimal nix-shell

Motivation for this change
This shell is inspired some investigation I did
and a follow-up example that demonstrated starting a nix-shell with a minimal builder.sh.
The goal is to provide the facility to create an ultra-lightweight nix-shell that only has bash as the direct dependency. Users can set environment variables and add packages but the feature-set is purposely minimal.

The following Nix expression works and is pointing to the latest commit of this PR

let
  nixpkgs = import (builtins.fetchTarball {
    name = "nixpkgs-fzakaria-fork-2021-08-03";
    url =
      "https://github.com/fzakaria/nixpkgs/archive/refs/heads/faridzakaria/pure-mkShell.tar.gz";
    sha256 = "1h7aqlivq2hax7k7a612mffpfkawn1mfd3jfszzpx19i2fxwmqp2";
  }) { };
in
with nixpkgs;
mkShellMinimal {
  name = "my-test-shell";
  packages = [ ripgrep ];
  FOO = bar;
}

This minimal nix-shell has effectively a 0 (1.4 KiB) size closure.
❯ nix path-info -rSsh $(nix-build -I nixpkgs=/home/fmzakari/code/github.com/NixOS/nixpkgs test-shell-local.nix)
these derivations will be built:
  /nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv
  /nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv
building '/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv'...
building '/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv'...

This derivation is not meant to be built, unless you want to capture the dependency closure.

/nix/store/8ka1hnlf06z3h2rpd00b4d9w5yxh0n39-setup        	 376.0 	 376.0
/nix/store/nprykggfqhdkn4r5lxxknjvlqc4qm1yl-builder.sh   	 280.0 	 280.0
/nix/store/xd8d72ccrxhaz3sxlmiqjnn1z0zwfhm8-my-test-shell	 744.0 	   1.4K

Things TODO

[x] I am still missing the necessary hook to clear $PATH when nix-shell is started pure. This exercise has actually shown how tied the nix-shell and stdenv concepts are.
[x] Add support for inputDerivation similar to what @Infinisil added for mkDerivation
[x] calculate the new closure-size (should be 0?) for the minimal shell.

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

There is a section for special builders in nixpkgs doc nixpkgs/doc/builders/special/mkshell.section.md
This one could be added as well.

What is the goal? If to be minimal is there a path to use busybox instead of bash?

In practice I found we were using nix-shell to have a reproducible environment, but stdenv was bringing and doing a lot of stuff.  I just wanted the ability to declare environment variables & a list of packages.
(Might need to expand slightly to setup-hooks for setting stuff like language paths like bundler or Java's classpath)
I want to showcase an ultra-minimal mkShell (in fact the real mkShell should probably be built on-top of this), where one lists only a set of packages.
The whole notion of buildInputs vs. propagatedBuildInputs is unnecessary is you are writing a shell. You are never planning to build the derivation.

There is a section for special builders in nixpkgs doc nixpkgs/doc/builders/special/mkshell.section.md
This one could be added as well.

I will work on documentation once I get a few more :eyes:  on this. I have a few TODOS I added to the description that I still need to solve (if you have hints please share).

@fzakaria thanks for working on this!
@tomberek a more minimal shell would be good for packages that don't need the full closure of stdenv, which has occurred for me while working on #123095. Maybe one based on busybox instead of bash would be even more minimal indeed. See #116274 for an stdenv based on uutils-coreutils.

@siraben since there's no dependency on coreutils (merely bash); I like that this in spirit allows the user to choose busybos or coreutils.
I think keeping the sole dependency to bash more in spirit to this minimalism otherwise the choice will no longer be possible?
There might be an opportunity to remove bash completely and solely rely on /bin/sh which must exist on the system ?

@roberth makes sense.
Looks like the size of bash vs. busybox is the same mostly due to the size of glibc's locales.
There's an opportunity to use a version of bash with an overridden glibc that only has UTF8 as the supported LOCALE.
(should dramatically reduce the minimal size)

The user should choose their own bash implementation if they don't want to use the impure PATH's bash, so optimizing it is another topic.
Did you mean to use /bin/sh in the builder? That's not so bad, because that's not used for the actual shell and the builder logic is, well, super simple.

@roberth i did mean it for the builder since the expectation is that it's run on a POSIX compliant machine and for the purpose of having a development environment.

Woot!
New closure size is merely 1.4KiB
❯ nix path-info -rSsh $(nix-build -I nixpkgs=/home/fmzakari/code/github.com/NixOS/nixpkgs test-shell-local.nix)
these derivations will be built:
  /nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv
  /nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv
building '/nix/store/xaqxyk1y3zjk0qwpxkm0n3n6c05bj6fn-setup.drv'...
building '/nix/store/rxrbwvk7rjvknil7ns1ki00n4vfqcs8h-my-test-shell.drv'...

This derivation is not meant to be built, unless you want to capture the dependency closure.

/nix/store/8ka1hnlf06z3h2rpd00b4d9w5yxh0n39-setup        	 376.0 	 376.0
/nix/store/nprykggfqhdkn4r5lxxknjvlqc4qm1yl-builder.sh   	 280.0 	 280.0
/nix/store/xd8d72ccrxhaz3sxlmiqjnn1z0zwfhm8-my-test-shell	 744.0 	   1.4K

Do you also plan to support inputsFrom (and potential other features that I am unaware of) from mkShell?

I've opened the following bug to track how to fix --pure
https://github.com/NixOS/nix/issues/5092

Do you also plan to support inputsFrom (and potential other features that I am unaware of) from mkShell?

No. I'd like the feature set to be very minimal. I think expanding out a dependency list from a given package can be handled by a library function instead.
I see the necessary support: $PATH, environment variables and maybe hooks.
Other support should be composable ontop of this minimal shell implementation.

@roberth  et. all -- this is looking much better. All major issues look to be resolved.
Please give it a whirl.
I resolved some of the issues on comments; I think i can address it in follow-up PR.
If you disagree we can do it here but I would like to work on the markdown documentation + nits in subsequent PR.

If you disagree we can do it here but I would like to work on the markdown documentation + nits in subsequent PR.

Incremental improvements can be delayed, no problem, but I see no reason why we should merge bad documentation.
Now that we're talking about docs, could you add it to the manual?
In my experience, writing docs is a good activity because you're reprocessing the design. This can lead to simplifications and improvements that you didn't think of before. Same goes for tests, but in this case docs are more important.

I should really find how to do EditorConfig test locally :(

Please don't use /bin/sh. It's only intended for programs that make calls to the C system function and such.

@roberth
Do you have a source for this? I use sh when I don't need the extra power of bash
Or is that just the general position of nixos?

I should really find how to do EditorConfig test locally :(

@fzakaria
From GH Actions: echo "$PR_DIFF" | xargs editorconfig-checker -disable-indent-size, I guess in your case you could adapt this to do a diff on your master or just run it on individual files you know you changed

You might want to take a look at https://github.com/numtide/devshell/blob/master/nix/mkNakedShell.nix
It goes a step further by removing unnecessary noise in the environment, and also allows to nix-build the shell. Right now it expects to take a script that defines the rest of the environment, but it could be modified to use a buildEnv.

@zimbatm any interest in contributing to this or merging the two into nixpkgs?
I think there's room here to make progress.
We can chat over Matrix or something. Cheers.

Ping for others here.

Looks like you missed this review item https://github.com/NixOS/nixpkgs/pull/132617/files#r682575668

This is nice to see, I just recently copied a version of this into my repo after reading the related blog post. A thought, related to some open questions:
Could this either be (1) more flexible, allowing the user to opt-in to things like completions, or (2) be the basis of a number of functions, similar to some of the pkgs/trivial functions that often minimally build upon each other?
Along those lines, if this is added to nixpkgs, the API sort of immediately becomes somewhat frozen. Not sure if @zimbatm and @fzakaria chatted? Is there a ton of benefit to this being in nixpkgs vs outside? With flakes and an external repo, one would be free to alter the API, basically at any time.

I'd love to collaborate to continue to make this composable.
I envision a way where you "stack" features onto the minimalShell setup for various features you want.
(Stdenv.mkDerivation would be just a prebuilt stack)
Didn't get a chance to chat more with @zimbatm more about it.

I'd like to see this included in nixpkgs. mkShell is not fit to use as a general purpose env builder due to the number of irrelevant env vars. @zimbatm, would you join this effort?

@fzakaria are you still planning on working on this? I would be interested in seeing it land in nixpkgs.

I'm increasingly convinced that development shells should be started through nix run, giving complete control to expressions that can be pinned, rather than relying on fragile, complicated built-in behavior that is inherently hard to improve upon.
It's a technically and organizationally superior solution, but the hacky nix-shell solution has a dedicated subcommand and a decade of usage :'(

@roberth do I understand correctly that your
concern is about how this is run, rather than how it’s implemented? If so, it should be orthogonal to this PR?

@roberth do I understand correctly that your concern is about how this is run, rather than how it’s implemented? If so, it should be orthogonal to this PR?

My concern is that this PR uses the wrong tool to achieve its goal, as nix-shell is too complicated to host a minimal shell. Note that nix-shell is a hack of all trades but master of none, as evidenced by the many nix issues that want to pull it either in the direction of nix run or the actual real build sandbox.
It is certainly not orthogonal, but I won't oppose incremental changes like this PR, as long as you're making the conscious choice to go for a messy local optimum rather than a principled solution.

I'm not sure how to make sense of these thoughts given that I use mkMinimalShell with nix develop (I don't really know the internal differences between nix-shell/nix run/nix develop. How does that compare to nix run?

I'm not sure how to make sense of these thoughts given that I use mkMinimalShell with nix develop (I don't really know the internal differences between nix-shell/nix run/nix develop. How does that compare to nix run?

Roughly:

nix run: just run the installable using an absolute path.
nix shell: set the PATH to the "bin" of the installable (and from /nix-support/propagated-user-env-packages) and start a sub-shell with "$SHELL" or "bash" using normal /etc/profile or bashrc or zshrc initialization.
nix develop: set a ton of variables that would be present during a build. start a sub-shell using a bootstrap rcfile that calls the setupHook for the derivation you are using.
nix-shell: various things

nix run can simulate the others as it can run some arbitrary script

The discussion and PR i would like to continue to push forward is breaking down mkShell in composable units.
I was trying to setup the barest (smallest) unit first to start and everything else should compose on top of it.
@roberth I don’t think anything in mkMinimalShell goes against what you are saying. It’s creating a shell to inherit all environment variables. I agree I would like to see less specified in nix Itself for defining this stuff.
Thoughts?

@roberth I don’t think anything in mkMinimalShell goes against what you are saying.

My only concern is that it may not achieve its end goal, but that doesn't mean that it doesn't have value. As I said, I won't oppose incremental changes like this PR.

barest (smallest) unit first to start and everything else should compose on top of it.

This is a good goal, but you'll be duplicating significant parts of "stdenv". We already have a NixOS way of configuring the environment and a stdenv/setup/mkDerivation way of configuring environments. Will this create a third way of doing things?
Perhaps a better angle for implementing this is to modularize stdenv. We have stdenvNoCC which, as the name suggests, does not include the C compiler. Similarly, you could define more minimal "env"s. I'd stay away from negations like "NoCC" and construct ones that are minimal with respect to some goal. Maybe you could have setupenv which relies on an impure environment, but runs setup.sh; shenv which builds on that but makes the shell pure; unixenv which adds a small number of programs used in scripts; busyboxenv, etc.
This feels like bootstrapping, but I don't know if these distinctions/layers are useful for that. As far as I'm concerned, these envs' dependencies should all be built with the usual stdenv, to keep things simple.
By using those minimal envs, you can modularize shells using the same functionality that is used for builds, such as the setup hooks, and you don't have to introduce a third way of doing things.

I see a long term goal of rebuilding stdenv or stdenvNoCC using a new
modular format.
Right now it's subtractive rather than additive which makes it difficult to
think through.
On Tue, Mar 8, 2022, 1:26 AM Robert Hensing @.***>
wrote:

@roberth https://github.com/roberth I don’t think anything in
mkMinimalShell goes against what you are saying.
My only concern is that it may not achieve its end goal, but that doesn't
mean that it doesn't have value. As I said, I won't oppose incremental
changes like this PR.
barest (smallest) unit first to start and everything else should compose
on top of it.
This is a good goal, but you'll be duplicating significant parts of
"stdenv". We already have a NixOS way of configuring the environment and a
stdenv/setup/mkDerivation way of configuring environments. Will this create
a third way of doing things?
Perhaps a better angle for implementing this is to modularize stdenv. We
have stdenvNoCC which, as the name suggests, does not include the C
compiler. Similarly, you could define more minimal "env"s. I'd stay away
from negations like "NoCC" and construct ones that are minimal with respect
to some goal. Maybe you could have setupenv which relies on an impure
environment, but runs setup.sh; shenv which builds on that but makes the
shell pure; unixenv which adds a small number of programs used in
scripts; busyboxenv, etc.
This feels like bootstrapping, but I don't know if these
distinctions/layers are useful for that. As far as I'm concerned, these
envs' dependencies should all be built with the usual stdenv, to keep
things simple.
By using those minimal envs, you can modularize shells using the same
functionality that is used for builds, such as the setup hooks, and you
don't have to introduce a third way of doing things.
—
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nixpkgs/pull/132617#issuecomment-1061574060,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAETXDTCPV7SR57ISBXSKH3U64MOFANCNFSM5BQG55SA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

@asymmetric Are you still requesting changes? I'd like @fzakaria to be able to merge this, if possible.

@johnrichardrinehart I don't think my review is the main thing blocking this (but @fzakaria please do let me know if that's the case). There are conflicts that must be resolved.
But on the topic of my review: I especially think we shouldn't advocate the "global" with in the manual. There were some issues explaining its problems but I can't find them now.

A truly minimal shell would not have the form of a derivation, however this requires changes in the Nix CLI.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/make-shell-a-modular-replacement-for-mkshell/48509/12


Fixes auto_error for optional authentication #10

Tested this in my project and it works for both authenticated and public

Release as 0.2.1


Optional Shadow DOM

Hello! Great job!
Is it possible not to use shadow dom at the moment? Perhaps by overriding properties or methods?
Motivation:

Not all browsers support Shadow DOM well

Difficult to reuse common styles between custom elements

Other use cases where the developer can decide whether to use Shadow DOM or not

This is not possible with this library, and also not planed.
ShadowDom is in all the major browsers since 2016 ( https://caniuse.com/shadowdomv1 , okay FireFox 2018).
If open styleable shadowroots will we a thing, then we will support it.


Most sensors unavailable

Not sure if the dependencies need bumping or if there is currently an issue with the Glow API but most of the sensors are unavailable most of the time recently.
All seemed to be working fine before but the last week sees very intermittent availability of the sensors.

This also seems to be the error that is happening more regularly than it did before a week ago....

Just found the same problem. I can't see any changes to the API on the Glowmarkt website, hopefully just an outage on the API?

Working OK for me.   I suggest it the “usual” glow server instability.

I'm getting the same issue.

If the API server is known to be unstable, should the data collectors be made more robust and keep trying until they get a response? If the data is only changing every 30 mins then the value isn't actually changing.
Once one value is missed then the next value plotted is also incorrect because it's the delta from last good reading.
e.g. in the graph the 6:00 reading is double what it really was.

Here's the data that Bright app shows

But I also see missing data in Bright app - here's the data before

I can see Loop app and Octopus have data - but they're dallied by 24hrs.
Do these issues go away if you buy the hardware?

With the way HA works, there is nothing more you can do on the client side.  Once data is missed, when you eventually get a new reading it will show as spike.
Sorry, I don’t know about the hardware, I’ve learnt to live with the free data - accepting it has bugs and there in nothing more HA can do, the issues are server capacity related.
@HandyHat did hint at a complete re-write of the integration to reduce server load, with might make a small improvement in reliability.

Isn’t it possible with HA not to render sensor unavailable when a reading is missed but rather stay as it used to be before a failed reading?

Isn’t it possible with HA not to render sensor unavailable when a reading is missed but rather stay as it used to be before a failed reading?

If you want to track the last valid values, you can make template sensors like these:
template:
  - sensor:
      - name: "Electric Consumption (Today, Valid)"
        icon: mdi:flash
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >-
          {% if states('sensor.electric_consumption_today') == 'unavailable' %}
            {{ states('sensor.electric_consumption_today_valid') }}
          {% else %}
            {{ states('sensor.electric_consumption_today') }}
          {% endif %}
  - sensor:
      - name: "Gas Consumption (Today, Valid)"
        icon: mdi:fire
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >-
          {% if states('sensor.gas_consumption_today') == 'unavailable' %}
            {{ states('sensor.gas_consumption_today_valid') }}
          {% else %}
            {{ states('sensor.gas_consumption_today') }}
          {% endif %}

I'm sure this has been talked about before - but I'm just getting started in HA.
The issue here isn't the "unavailable" state itself, because even if you ignore it and set it to the last reading, it will still appear as an empty column on the energy dashboard - which tracks the delta from the last value.
If we accept that the GLOW API isn't stable (in my case it fails about 10%) then the other approach is to make the integration more robust and so when it gets 200 response off the API it scans back over the previous missing readings and gets them too.
At the moment the current usage params are from midnight 00:00:00 to end of day 23:59:59, but it could be modified to pick up previous values e.g. 00:00:00 to 13:59:59 in order to pick up a missed value for 13:00
My python is a bit rusty, so will take me some time to do this, but if anyone else is up to it, it doesn't seem like a major change.
Another factor might be that all HA integrations are hitting the API at the same time - I don't see where that's done though.

The challenge with the HA integration model, is you cannot add historic data.
Once a reading is missed, you can't add it later.    All you can do is give a current total meter reading when the API is up.
HA will take this, and add it into the current hour.    You can't tell HA to "back date" some of it.
No data is lost - its just accounted for in the wrong hour.
So even if you read the missed intermediate value from HA- you would not be able to get HA to do anything sensible with it.
Another suggestion higher up is to not report "unavailable" and give the value from the previous sucessful attempt.   Again this will not help, as the delta will be zero, until you get a new reading.
Yes a factor is all HA integration hitting the API at the same time.   That is a Glow issue.  The Glow API updates the data on the hour, and (if you are lucky) 30 minutes past.   The HA integration will attempt a read between 00 and 05 minutes, to provide some randomisation.
There are improvements that the HA integration can make (with a breaking change) to reduce the number and types of sensors, so reduce the number of calls on the Glow API.   I.e., reduce flexibilty to gain reliabilty.  @HandyHat was looking at this, but is a lot of work.

I've disabled the sensors I don't use, so I'm left with just day use and day cost. I've not had a drop out for 2 days. Might be worth a try.

Sounds good. Even if it only reduces it it’s worth it. Can you say what you did?

This should no longer be an issue as of v1.0.0. If this issue persists, please say!

@HandyHat yes, fixed. removed old version and reinstalled v1.0 through HACS and no error. thanks.
BTW - I opened a new discussions on some anomalies I'm seeing in V1, which I think is the underlying data and not the integration.


fix EOP Error

I merge a branch last year for skipping extra EOP event, but I found there may be errors some times.When the buffer need receive a EOP event and the buffer size is not enough, the eop event may be retry next time,but I filter the retry event with local variable preEndPeriodEvent has been set to true. I fix the bug by this branch.

Thanks for the fix, and apologies for the lengthy delay in getting it merged!


commit: init at 3.2.0

Description of changes
Commit is a handy commit message editor for git.
https://github.com/sonnyp/Commit

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[X] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[X] Fits CONTRIBUTING.md.

Thanks for the review, wrapGAppsHook4 gets me every time :D
I don't mind renaming this, do you have suggestions? I don't really want to move this to gnome. since it's not a core application

Commit as a package sounds okay to me. Looking at other distros, only AUR appears to ship it and they use the name as well.
So I would say linux_testing_bcachefs needs to be fixed.
cc @Madouura who last touched linux_testing_bcachefs in https://github.com/NixOS/nixpkgs/pull/171347

Commit as a package sounds okay to me. Looking at other distros, only AUR appears to ship it and they use the name as well.
So I would say linux_testing_bcachefs needs to be fixed.
cc @Madouura who last touched linux_testing_bcachefs in #171347

See #179396


ucc-gen is creating a package which is not working in Splunk

I used 2 different globalConfig.json files to generate add-on. I've uploaded them here (Github does not allow to upload JSON files, so they are in .txt format).
Steps to reproduce:

ucc-gen
slim package output/Splunk_TA_mysql
upload archive to Splunk
go to app

When using globalConfig_1 - it gives the first error.
When using globalConfig_2 - it gives the second error.
Expectations:

ucc-gen reports that the config is invalid and does not create a package
TA UI shows more information about the error so developers can debug it

globalConfig_1.txt
globalConfig_2.txt

Are you using ucc 4.x or 5.x?

5.0.0

There are multiple issues:

The first one is something that can be fixed  in UCC UI because it is caused by the fact that the globalConfig only has configuration page and not inputs page.
The second issue might be caused by resthandler and globalConfig schema mismatch. But you can check and attach splunkd.log error to check whats the underlying cause.

We have a globalConfig.json schema validation here: https://github.com/splunk/addonfactory-ucc-generator/blob/b7cd16eac33c3048ab7c7dbcb2365ff95ba534e1/splunk_add_on_ucc_framework/init.py#L645-L654
And it is being used here: https://github.com/splunk/addonfactory-ucc-generator/blob/b7cd16eac33c3048ab7c7dbcb2365ff95ba534e1/splunk_add_on_ucc_framework/init.py#L707-L715
So, if I provide globalConfig.json without inputs page I expect schema to be invalid and it seems that the schema that we are using does not do that validation. I created https://github.com/splunk/addonfactory-ucc-base-ui/issues/37 so we can track progress.

To avoid this situation I started working on unit tests for schema validation (https://github.com/splunk/addonfactory-ucc-generator/tree/main/tests/unit) but after 5.0.0 release they are not working.

@arys-splunk I think they are not configured properly in CI since version 4.5.0 (https://app.circleci.com/pipelines/github/splunk/addonfactory-ucc-generator/719/workflows/97fab64f-1a2c-4ab9-a2a7-d110b5903ad6/jobs/1782/steps). Will need to add an execution step for it in circle ci config.

First issue was resolved by patching ucc-base-ui repository.
And I found a root cause for the second one: restmap.conf was not in the proper state.
Closing this issue.


Potential Incompatibility with Epic Fight mod on Forge 1.18.2

I'm assuming this is caused by Epic Fight, but I'm unsure.
Halfway through the Adjudicator boss fight, the server crashed.
Here's the server log:
biomemakeoverepicfightcrash.log

Yeah this is epic fight's crash. You should report it to them. Should be a fairly easy fix on their end.


[WARN ][com.floragunn.searchguard.filter.SearchGuardActionFilter] Cannot determine types for indices:data/write/bulk[s] (class org.elasticsearch.action.bulk.BulkShardRequest) due to types method not found

This error message is generating over 60mb worth of logs in a development/testing environment with a fraction of the transactions of production; I need to find a way to get rid of this error since it's logged so many times per second.
You mentioned a possible solution here, https://github.com/floragunncom/search-guard/issues/16#issuecomment-115269045 however I cannot seem to move forward from there.

Will fix it in the next version, for now you can try this:
In logging.yml:
es.logger.level: INFO
rootLogger: ${es.logger.level}, console, file
logger:
...
com.floragunn.searchguard.filter.SearchGuardActionFilter: ERROR
...

Appreciate it; I was hoping to continue logging other warnings but this can work until the patch comes in.
Thanks.

Auto close this issue because it refers to Search Guard 1 which is decommissioned now. For details pls. see https://github.com/floragunncom/search-guard-attic/wiki . If this issue is still valid for Search Guard 2 (for elasticsearch 2.x) feel free to reopen it (or to file a new one). Pls. do not longer report issues for Search Guard 1 (for elasticsearch 1.x). We sincerely apologize for the inconvenience this may have caused. Thanks for contributing!


stricter lint checks

Copy the lint rules from juttle/juttle and fix up the missing use strict and semicolons as needed.

@rlgomes

+1

In the interest of not adding more delay, I'm going to wait to merge until after we release.


Support for query specific attributes in latency histogram

Problem Statement
Hi! thanks for the awesome pkg. It has been quite useful for instrumenting sql calls.
We want to start leveraging metrics more instead of traces for creating our internal dashboards, given that traces may need to be sampled at some point.
There's a db.sql.latency histogram metric which would work. But it's missing a few attributes: database name, query operation name, table name etc.
The semantic conventions for database metrics have the attributes documented but status is still "Experimental"
For traces, we have been able to reformat the span name using SpanNameFormatter and set more attributes using AttributesGetter. I was wondering if you'd open to supporting a similar AttributesGetter for metrics till status for metrics semconv is still Experimental? Happy to open a PR if this seems okay!
Proposed Solution
Similar to AttributesGetter for adding more attributes in span based on query context here: https://github.com/XSAM/otelsql/blob/de82710d7a7913cae38a261b656ba68b5b9e59b4/utils.go#L96-L98
same or another attributes getter for metrics to append attributes to metrics here https://github.com/XSAM/otelsql/blob/de82710d7a7913cae38a261b656ba68b5b9e59b4/utils.go#L67
Alternatives
otelsql could add all the attributes documented here by parsing queries, but:

the spec is still experimental - attribute name can change till the spec becomes "Stable"
otesql would need a lot of database specific query parsing logic which may not be right

Prior Art
Although not the same area, otelgrpc appends parsed rpc/context specific attributes to both spans & metrics:
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/3fab5f5f20fb7f8ee7e33172fd129d336cd5640d/instrumentation/google.golang.org/grpc/otelgrpc/interceptor.go#L452-L462
https://github.com/open-telemetry/opentelemetry-go-contrib/blob/3fab5f5f20fb7f8ee7e33172fd129d336cd5640d/instrumentation/google.golang.org/grpc/otelgrpc/interceptor.go#L336-L337
Additional Context
NA

Hi, @krantideep95, thanks for raising this issue!
This looks like a good feature to have. We might need a new getter, InstrumentAttributesGetter. I prefer not to reuse AttributesGetter for metrics, as metrics storage is usually more sensitive than tracing storage in the cardinality of attributes.
Feel free to open a PR to implement this. You might need to extend recordMetric to include args []driver.NamedValue.


tracing: Use 'operation_name' to determine whether client or server s…

…pan and remove annotations from propagated OtSpanContext
This is a purely internal change that should not affect any users. It is primarily to localise the decision regarding whether a client or server span should be created based on the tracing configuration associated with the filter - i.e. ingress = server span, egress = client span.
Currently this decision is based on what annotations have previously been set and passed with the OtSpanContext header.

@rshriram Last time I chatted with you about this, you seemed to think that the Envoy configuration generated by Istio uses the operation_name correctly, that is, "ingress" and "egress" as expected. Are you sure?
I am little nervous about this change.

@objectiser Please, see my questions above.

@RomanDzhabarov  The changes look good to me, too. My only remaining concern is with the Istio-generated  Envoy configuration. I need to check with @rshriram, as I am not yet convinced it is compatible with this change.

@rshriram Could you provide a concrete example of whether a single listener would be used both for ingress and egress? As I think this would be a challenge for tracing with or without this change.

On Wed, Aug 30, 2017 at 4:53 AM Gary Brown<EMAIL_ADDRESS>wrote:

@objectiser commented on this pull request.
In examples/zipkin-tracing/front-envoy-zipkin.json
https://github.com/lyft/envoy/pull/1565#discussion_r136009335:

@@ -9,7 +9,7 @@
"config": {
"generate_request_id": true,
"tracing": {

         "operation_name": "ingress"

         "operation_name": "egress"
       },

Prior to this change, the front-envoy generated a client span which
indicates an outbound request - which is egress.
I guess I view the front-envoy as being a proxy for the user (i.e. an api
gateway) - so in that respect it is representing the egress from that user
app.
If we wanted the front-envoy to be reflected as a separate (api gateway)
service in its own right, then possibly we need a different operation name
that represents both the receiving of the request (ingress) and the routing
of that request to the actual service (egress) - but from the "application"
level I think this front-envoy is just acting as a 'proxy' for the user app.

From an end user perspective, front Envoy is as much a part of the mesh as
service envoys (same as kube ingress or API gateway). So, it receives
requests from users. (Server receive). Agree that there are multiple
perspectives but what's the default one that a "non expert" user  expect?
I believe that generating a client send span from front Envoy is incorrect.
It needs to be server receive. And your pr is the opportune moment to fix
this imo. i.e keep this as ingress.
Thoughts ?
—

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/pull/1565#discussion_r136009335, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qd3ko0RQzT0Bhy4IznlRpHOWH5Watks5sdSL8gaJpZM4PGR6N
.

--
~shriram

I was viewing the situation from the perspective of what users would see if there was no service mesh, and therefore the application was directly instrumented. In this case, they would just see 'service1' and 'service2' - so the first (root) span would be the server span for service1.
I see the service mesh as an enabler, a way to remove the tracing from the application itself, but still providing the same results. So possibly the change that needs to happen is not to include the tracing from the front-envoy, as it is only effectively an extension of the network carrying the request from the actual client application to the actual service?

On Wed, Aug 30, 2017 at 4:54 AM Gary Brown<EMAIL_ADDRESS>wrote:

@rshriram https://github.com/rshriram Could you provide a concrete
example of whether a single listener would be used both for ingress and
egress? As I think this would be a challenge for tracing with or without
this change.

Won't the annotations or tags help here?
A simple example is one where I deploy Envoy in all my VMs listening on
port 80. I use virtual hosts to route requests to service in local VM or
services in other VMs. Inbound requests hit vm on port 80, get routed to
local app. Outbound requests from app go to local Envoy port 80 (imagine
HTTP_PROXY), and get routed appropriately.
What I am trying to ask is if we can use a combination of annotations and
the operation names to generate the right span ? In Envoy terms, this
translates to using the annotations if the x-ot-.. header indicates
cs/cr/ss/sr. If it's absent, derive the span type from the operation name
(ingress or egress).
Will this be too complicated? There is always a workaround where we force
people to use distinct listeners (and hence ports) for ingress and egress,
as lyft is doing today. I am totally okay if you think this will result in
complicated implementation. :)
Extending this concept, you could potentially use the x-ot-... header as an
optional hint to Envoy to generate the right type of span. If clients omit
it, we derive based on operation name or some sensible defaults.
@adriancole/@fabolive thoughts ?

--

~shriram

There is always a workaround where we force people to use distinct listeners (and hence ports) for ingress and egress, as lyft is doing today. I am totally okay if you think this will result in complicated implementation. :)

+1 would prefer this distinct listener approach - as otherwise I think it does get too complicated.

@rshriram Out of curiosity I changed the front-envoy back to ingress and ran a test on zipkin and jaeger and here is the results:

So as you can see there are two sets of server spans - and the timeline view shows front-envoy instead of service1 - I guess the name is based on the first server annotation it finds.

The Jaeger UI misses out the service1 server span.
So I think the options currently are:

Within front-envoy, use the "operation_name" with "egress" which generates tracing emulating the client application (i.e. a "client span").

Within front-envoy, use the "operation_name" with "ingress" which essentially generates a double server span - one at the front-envoy and the other at the service.

Don't add tracing to front-envoy, so the tracing only begins (assuming that tracing context is not passed in from the client) when the request is received at the service (proxy).

The above three options are possible now without any code change - only config change - so the user could decide which strategy they want.

Variation of (2) - instead of just creating server span at the front-envoy, also create a client span for the request going from the front-envoy to the service proxy. However this then introduces tracing of the infrastructure, which may or may not be what a user (who is primarily interested in their application) is interested in.

Yikes. If you change to egress, do you see a full cycle ?
On Wed, Aug 30, 2017 at 9:43 AM Gary Brown<EMAIL_ADDRESS>wrote:

@rshriram https://github.com/rshriram Out of curiosity I changed the
front-envoy back to ingress and ran a test on zipkin and jaeger and here is
the results:
[image: envoy-ingress-zipkin]
https://user-images.githubusercontent.com/164562/29874718-8c398a22-8d8f-11e7-88f9-837c138c99e3.png
So as you can see there are two sets of server spans - and the timeline
view shows front-envoy instead of service1 - I guess the name is based on
the first server annotation it finds.
[image: envoy-ingress-jaeger]
https://user-images.githubusercontent.com/164562/29874721-901586a0-8d8f-11e7-8047-9c07a664bf15.png
The Jaeger UI misses out the service1 server span.
So I think the options currently are:

Within front-envoy, use the "operation_name" with "egress" which
generates tracing emulating the client application (i.e. a "client span").
2.
Within front-envoy, use the "operation_name" with "ingress" which
essentially generates a double server span - one at the front-envoy and the
other at the service.
3.
Don't add tracing to front-envoy, so the tracing only begins (assuming
that tracing context is not passed in from the client) when the request is
received at the service (proxy).
The above three options are possible now without any code change - only
config change - so the user could decide which strategy they want.

Variation of (2) - instead of just creating server span at the
front-envoy, also create a client span for the request going from the
front-envoy to the service proxy. However this then introduces tracing of
the infrastructure, which may or may not be what a user (who is primarily
interested in their application) is interested in.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lyft/envoy/pull/1565#issuecomment-325994010, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0qd0AEFYQzeg1iJd-yH4O2Ueb4kPuLks5sdWbkgaJpZM4PGR6N
.

--
~shriram

Yes, when set to "egress" it acts as before, creating a "client span" for the front-envoy.


compatibility docs: remove actively maintained star

You can rebase once https://github.com/commaai/openpilot/pull/25193 is merged


Predicted entities don't sync hierarchy

Predicted entities on clients do not sync their hierarchies with their confirmed counterparts after the ReplicateHierarchy { recursive: true } component is inserted into the parent entity on the server. The predicted entities exist but the predicted parent entities have no children and the predicted children have no parent. Meanwhile, the confirmed parent entities and confirmed child entities have their hierarchy correctly synced and the children have the ParentSync component. I expect that the predicted entities would sync their hierarchy with their confirmed counterparts.

Thanks for the report. I guess the replication_groups doesn't trigger this because it uses a custom PlayerParent component instead of going through the ParentSync machinery

Closing because this is a duplicate of https://github.com/cBournhonesque/lightyear/issues/545


Fix getTypeFromJSDocValueReference

When using {import('./b').FOO} which is defined as a string literal,
valueType doesn't have a symbol.
This was exposed in 8223c0752.
Fixes #34869.

@typescript-bot cherry-pick this to release-3.7

@typescript-bot cherry-pick this to release-3.7


Add package summary for drivers/gl package.

Also, fix minor golint issues inside the package:
$ golint drivers/gl
drivers/gl/driver.go:37:1: exported function StartDriver should have comment or be unexported
drivers/gl/driver.go:127:9: if block ends with a return statement, so drop this else and outdent its block
drivers/gl/polygon.go:215:9: if block ends with a return statement, so drop this else and outdent its block
drivers/gl/viewport.go:21:7: don't use leading k in Go names; const kClearColorR should be clearColorR
drivers/gl/viewport.go:22:7: don't use leading k in Go names; const kClearColorG should be clearColorG
drivers/gl/viewport.go:23:7: don't use leading k in Go names; const kClearColorB should be clearColorB

Much appreciated @shurcooL.

No problem! I wanted https://godoc.org/github.com/goxjs/gl?importers to look a little more pretty. :)


Error compiling template, even though one root element

Version
2.4.1
Reproduction link
https://jsfiddle.net/k5h2fvqh/
Steps to reproduce

 tag as Root element
put
 tag as child element

What is expected?
Render template correctly
What is actually happening?
Error compiling template with message "Component template should contain exactly one root element"

Here's minimal repro: https://jsfiddle.net/gq2ckLLf/

That is exected behaviour,
 tag can not have child
 (and others too) so

 is parsed as

 and as you can see it's more than one root element. That's HTML limitations.

Complete list of elements that "close"
 is available here

https://jsfiddle.net/k5h2fvqh/50/


Few small issues with new packaging

I tried to install this in a Docker container on a server. A few things I noticed:

[ ] I needed to modify the Makefile and a few headers to get it to compile in the container (see branch: https://github.com/quantumjot/btrack/tree/fix-makefile)
[ ] If the user clones the repo, runs build.sh then pip install . then the newly created shared libraries are not part of the manifest. It needs to be installed in editable mode.

I'll add any others that I notice.

Binaries are now included as of 0.5.2

Fixed with #309


Add compatibility with lhf's lmd5 module.

Monkey-patch the module table of lhf's lmd5 module to add the sumhexa function, the only md5-related function LuaRocks currently uses.

Thank you


Fixed issue that caused memory leak in website

Thanks, reviewed the code.
Looks like I forgot to dispose off some controllers.
Thanks for the help


[VC] Add kubecon talk to README.md

This change revises the README page to include the kubecon talk.

/lgtm
/approve


Translate /en/Meist.md from Estonian into English

@maarjatoots is helping me with that. We do it one time atm but we should figure out how we implement 100% translation in good quality next years.


🛠  DB config refactor - env vars & deployment config & 🔨 Security vuln fixes

Motivation and Context

Won't only run this locally, env variables are convenient when deploying to fly.io
Code has vulnerabilities and other coding best practice issues caught by static analysis tools

Description

Replaces db name, those references of feathers
Makes use of env variables for DB URL
Make model IDs types and default value consistent
Fixes vulnerability in minimist and uglifyjs
Fixes the privilege escalation potential and writing to root fs in Docker containers
Adds clean script, fixes the CI job
Adds fly.toml. and cleans up Docker
-Adds dockerignore
Updates README and remove redundant steps

this PR is enormous and is a good example of PR to not create. will keep things smaller next time.

Awesome!
Thanks for going through it.
Let's let the author of PRs to merge them :)


[Android][iOS][Dev-tool] stream.fetch无法调用https接口 0.16.0

在使用stream.fetch模块的时候，有的https接口能调用，如 https://login.gpocn.com/config ，有的无法调用，如 https://tradecenter_api.gpocn.com/config ，具体什么原因，能帮我看一下吗

感谢你的反馈，Weex目前是隶属于Apache Software Foundation的项目，因此在Gtihub渠道我们鼓励使用英文反馈问题。下面我将使用Google Trasnlate将你的问题翻译成英语，并以英语回答。

When using the stream.fetch module, some https interfaces can be called, such as https://login.gpocn.com/config, some can't be called, such as https://tradecenter_api.gpocn.com/config, what is the reason? Can you help me see it?

Please follow the issue template on Github and give a demo on dot.we, which will make life so much easier

http://dotwe.org/vue/a087c2b81d8d083ee4a104265d8e980e
stream.fetch(
      {
              timeout: 5000,
              method:'GET',
              url: 'https://trade_api.qywgpo.com/config',
              type: 'json',
              headers: {
                Accept: 'application/json, text/plain, */*',
                'Content-Type': 'application/json;charset=UTF-8',
              },
    },(res)=> {
      this.text = res
    })

in web ,it is work , but in android, it don't work, such as

Try use weex-toolkit, you will get all the Android/iOS log.
I have captured the Android log ,which is java.lang.IllegalArgumentException: Invalid input to toASCII: trade_api.qywgpo.com, Google search it, you will find the answer.
_ is illegal when using https in Android network library. Try the following approach:

Use http instead of https.
Avoid _ if you assist on https.


Unicode range

The unicode-range property (https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/unicode-range) is currently not supported. This PR adds support for that.

I’m not quite on board with parsing these as literals. I guess a custom Value subclass UnicodeRange would be more appropriate. It could then also provide methods to check if a code point is included in the range…

Hm, I thought these were supposed to always be literals. Having a separate Value subclass sounds good, but honestly I am not sure when will I have time to do it. I was able to update this PR since the old code was reusable. As of now, this PR at least helps to keep the unicode ranges in the rendered CSS, otherwise these rules get removed.
It would be great if you(or anybody) can add the UnicodeRange type and complete the implementation, if not I will ask you to at least merge this PR as is and open an issue for the suggested improvements.
Thanks!

I’ll merge it as-is, thanks.


Add Documentation Section Development

How can users substitute or add features to the citation model?
How can users add a different language model? => tokenizer + embedder
How can users use a different metric to evaluate the results?

Some components such as the features and metrics of the citation recommender are fixed on purpose to keep the code lean and avoid boilerplate code.
Other components are designed to be easily extendable in a 'plugin' fashion.
For example, tokenizers, language models and recommendation evaluation metrics all follow a common interface: Using the strategy pattern, new tokenizers, models and metrics can be added by implementing this interface. Then only minor code changes in the main/script files are necessary.


Add support to run connector examples on the same Ballerina version used by the Ballerina gradle plugin

Description:
When running the gradle build of a particular Ballerina connector, currently there's no proper way to build/run the connector examples (usually a collection of Ballerina packages) on the same Ballerina version and the docker image used by the Ballerina gradle plugin.
This may result in build failures (specially the Github workflow runs) because the module and its examples are getting built on top of 2 different Ballerina versions.
Therefore better to work on a proper resolution to support the same Ballerina docker image for the example build process as well.
Describe your problem(s)
Describe your solution(s)
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

With this improvement [1] for Ballerina gradle plugin the above limitation has been resolved.
[1] - https://github.com/ballerina-platform/plugin-gradle/pull/167