Handling of automatic sizing for figures. text and lines

We have some functionality to automatically set the size of the generated figure as well as plot properties like the linewidth or the fontsize. However, I am not sure it is worth the problems and complexity it introduces.
First and foremost, as all the code is common among all backends (save for what is in the backend/xyz folder) that means each backend needs to implement the functions used for setting these properties.
In matplotlib it is relatively straightforward, as we can get most everything either from rcParams or from figure/axes methods. It is also deciptively straightforward though because for fontsize for example, there is a base property (which we currently use) but then each element has its own default fontsize (titles, ticklabels, axis labels, annotation, legend entries...) and those can be set relative to the base property, or they can be set as absolute values. Thus, we are adapting some properties to the size of the generated figure, but we are also ignoring/breaking all these specific defaults that the theme being used by the user or the user themself might have set expecting it to be used yet it it completely ignored.
In bokeh it is a bit harder because most of these properties are not set. The current implementation/workaround is going over each plot and adding their widths/heights to get the total chart size. Thus, what was one line in matplotlib becomes 17 lines: https://github.com/arviz-devs/arviz-plots/blob/main/src/arviz_plots/backend/bokeh/init.py#L100. And that already is ignoring the spacing between plots. Other related methods have similar issues.
In #61 I am doing some tests with plotly, and it seems even harder to do because as far as I can tell, there are chart level width and height properties, but unless they are set explicitly by the user when creating the object, they are None until the visualization is rendered. If we wanted to support user generated objects (which I think we'd want to) then we would need a failsafe for cases when those properties have not been set at creation time. And given in that situation there is no information available the failsafe would have to be don't set/scale any of these properties or use hardcoded values.

One possible alternative to this would be making it easy/easier for users to define these properties so if they generate a plot and it is too small, or the text is too big they can easily generate it again updating those properties. Then getting rid of this functionality.
Another alternative would be to try and define an "effort threshold" so that if implementing these methods requires too much work (which long term will probably mean more maintenance too) we instead use functions that return hardcoded values to use as defaults.

I agree this can be problematic, it is probably better to remove it, at least until we think of a better alternative.

I think the best way to go is probably to size charts (matplotlib figures) automatically, but don't try to rescale the text/lines in either case which is what gets more complicated.
For chart sizing we only need number of rows and columns, then we define a "good looking" chart size. Sizing charts at creation time works quite well and is quite consistent across backends already. So I don't think we need to find a better alternative for that.
However, for the rest, we need to first get the chart size (which is problematic), then get the library (or theme) default textsize and linewidth (also problematic) and finally rescale those textsizes and linewidth so they are a better match for the chart. Later on, if we find good ways to overcome these two main issues consistenly across backends, we can add the text/line sizing back.
What do you think? There will probably be cases where for large charts the text is to small and/or the lines too thin, but both should be quite straightforward to change. Moreover, both those properties are part of the common interface and changing them using plot_kwargs would be independent of the backend. We could add a "Customizing charts" page or something like that covering this to the docs, similar to https://python.arviz.org/en/stable/user_guide/plotting_with_matplotlib.html and https://python.arviz.org/en/stable/user_guide/plotting_with_bokeh.html but backend agnostic.


Final Group Fullstack Capstone Project - Book an Appointment

Wheels-4-Rent
Team Members

Binyam Tegene
Emmanuel Kipngeno

Wheels-4-Rent Backend
Description
Wheels-4-Rent An application programming interface (API) tailored for car rental services streamlines the integration of rental functionalities into various applications or systems. It empowers users to execute essential tasks associated with vehicle rental, including reservation and inventory management.
Features In the App
1 Registration and Login

A new user has to register by submitting a username, email, and password on the registration page.
If a user is registered then he can login to the app using the username and password they registered with.

2 Main Page

Top Navbar - accessible in every page and contains the current username and logout button.
Navigation Panel - is accessible in every page, and it contains Links for

Latest Models
Reserve
My Reservation
Add Car
Remove Car
Pages

3 Admin prvilage to Add Car and Remove Car.

The Add Car and Remove Car links in the main page are only accessible for the admin user. thus you have to use the
default admin Credentials set in the database to login as an admin user
- ADMIN Credentials:   username: admin,   password: 123456789

4 Details Page

When you click the image in the main page it will take you to the details page where you can see the the selected car name, model, seating capacity, description  and price per day of the car.
there is also a reserve button to make reservation of this car which redirect you to the reservation page.

5 Reservation Page

can be accessed from the navigation panel or the details page reserve button.
contains a form with start date and end date input as well as selector for car and date.

6 My Reservations Page

displays all the reservation made by the user. It displays the information in a table with date, city, selected car, Total cost and an option to cancel a reservation
if user wants to cancel the reservation,  it can be done by clicking the cancel button in the changes column and the specific reservation will be removed from the table as well as the database.

7 Add Car Page

can be accessed from the navigation panel  and contains a form to add a car in the database
the form has name, model, image, description, seating capacity, and price per day input fields.
Note: Only admin can access this feature thus you have to login with the above admin credential to see this

8 Remove Car Page

can be accessed from the navigation panel  and contains a table with all the cars available in the database.
there is a remove button in every row to delete the specific car on that row from the table as well as the database.

9 Responsive App

The application is responsive and works seamlessly on both mobile and desktop devices.

Additional Note

Currently this app is not deployed thus to see the app functionality there is ONE MANDATORY REQUIRMENT

run the backend server on localhost:3000

API Doc is avilable once the backed end server is opened  Wheels-4-Rent
Testes are written in the backend you can run rspec  rails command to check them.

Wheels-4-Rent App Screenshot

Dear Reviewer

The functionality for adding and removing cars is already implemented in the code, however, only ADMIN has the privilege to add and remove a car and the credentials for the admin user are
1 username:    admin
2 password:    123456789

If you are logged in with a different user (not admin) the Add Car and Remove Car Buttons will not work


No "spotify_appkey.key"

Hello, since I have never done something with spotify on Linux before...
I started your Bot and got the Error:
 File "bot.py", line 33, in <module>     session = spotify.Session()   File "/home/mining/.local/lib/python3.5/site-packages/spotify/__init__.py", line 58, in wrapper     return f(*args, **kwargs)   File "/home/mining/.local/lib/python3.5/site-packages/spotify/session.py", line 55, in __init__     self.config.load_application_key_file()   File "/home/mining/.local/lib/python3.5/site-packages/spotify/config.py", line 130, in load_application_key_file     with open(filename, 'rb') as fh: FileNotFoundError: [Errno 2] No such file or directory: b'spotify_appkey.key' ERROR:asyncio:Unclosed client session client_session: <aiohttp.client.ClientSession object at 0x7f59f0717cf8>
My config.py looks like this:
token='This is my Discord Bot token, not gonna show it in public' user='the Spotify user not the email right?' secret='Not gonna show my Spotify Password here' prefix='!'
Any solutions on how to fix that?

Well, after doing some research I came to the conclusion, that libspotify is deprecated and you need an application key. But getting hold of one of them is really hard atm, because libspotify will be shut down in 2017


Update README.md

Connecting github do edge domain with developer zone.

This seems like spam

Not I was practicing.

Sorry, this repo isn't good for practicing. it's use for scripts and other automation practices related to working on GitHub.
i'd recommend looking at https://skills.github.com/ to do more practicing @109-999

I am sorry but my solution is data code to generate software solution

this isn't the right repository for this. I don't know what your solution is, but this is not the repository for connecting something business related to your personal site for personal gain/investment.


[Data Mapper] Show expand button on collapsed links in Data mapper

Description:
$Subject

Closing since this is already fixed


writing to blobfuse has stopped working in 0.19.2

Environment
Deltalake python 0.19.2:
Python:
Environment:

Fabric Onelake:

this code works fine in 0.18.2
import pandas as pd
from deltalake.writer import write_deltalake
df =pd.DataFrame({'x':[1,2,4]})
write_deltalake("/lakehouse/default/Files/dbo/test",df,mode="append",engine ='rust',storage_options={"allow_unsafe_rename":"true"})

but does not work with 0.19.2
OSError: Generic LocalFileSystem error: Unable to rename file: Function not implemented (os error 38)

@djouallah can you try this fix: https://github.com/delta-io/delta-rs/pull/2861

sorry, i don't know how to test it ?

sorry, i don't know how to test it ?

You will have to build your own wheel with that branch for your platform

hahaha, that will be a task for @RobinLin666  :)


Random test segfaults in Linux Debug CI

floatarray
struct1
foldConsts

I executed struct1 with debug build and valgrind. Valgrind did not report any problems. BTW, I had to compile Lean using g++. It seems there is some compatibility issue with clang. I got the following error messages when using clang.
~/projects/lean4/build/debug (master) $ valgrind stage1/bin/lean ../../tests/lean/run/struct1.lean
==252223== Memcheck, a memory error detector
==252223== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==252223== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==252223== Command: stage1/bin/lean ../../tests/lean/run/struct1.lean
==252223==
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x1b
get_Form_szB: unhandled 27 (DW_FORM_addrx)
--252223-- WARNING: Serious error when reading debug info
--252223-- When reading debug info from /home/leodemoura/projects/lean4/build/debug/stage1/bin/lean:
--252223-- get_Form_contents: unhandled DW_FORM
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x1b
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x25
### unhandled dwarf2 abbrev form code 0x1b
==252223== Valgrind: debuginfo reader: ensure_valid failed:
==252223== Valgrind:   during call to ML_(img_get)
==252223== Valgrind:   request for range [149281984, +4) exceeds
==252223== Valgrind:   valid image size of 138890064 for image:
==252223== Valgrind:   "/home/leodemoura/projects/lean4/build/debug/stage1/lib/lean/libleanshared.so"
==252223==
==252223== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==252223== Valgrind: I can't recover.  Giving up.  Sorry.
==252223==

Found this link, but did not explore it.
https://bugzilla.mozilla.org/show_bug.cgi?id=1758782

Valgrind also did not report any issues for floatarray.lean

Yet another segfault yesterday: foldConsts

@gebner Have you managed to reproduce the failure on your machine?

I believe this might be triggered by the recent upgrade of ubuntu-latest to Ubuntu 22.04.
We've had a similar issue in Lean 3: https://github.com/leanprover-community/lean/pull/791  I've managed to set up the coredumps in github actions, but the backtrace didn't point to an obvious fix.  Downgrading to ubuntu-20.04 seemed to fix the issue though.

And yet another one: calcInType, now in Linux release!

And stage3, wow https://github.com/leanprover/lean4/actions/runs/3647478628/jobs/6159757243#step:17:916

And Linux aarch64 as well
https://github.com/leanprover/lean4/actions/runs/3673519105/jobs/6210733920
And of course it happens in the configuration where I didn't set up the coredumps...

I've managed to set up the coredumps in github actions, but the backtrace didn't point to an obvious fix. Downgrading to ubuntu-20.04 seemed to fix the issue though.

So do we expect this to be different here or should we just downgrade?

I've managed to set up the coredumps in github actions, but the backtrace didn't point to an obvious fix. Downgrading to ubuntu-20.04 seemed to fix the issue though.

So do we expect this to be different here or should we just downgrade?

Downgrading doesn't seem like a sustainable solution.  For Lean 3 it makes sense, since Lean 3 is hopefully EOL before Ubuntu 20.04.  But I'm keeping my fingers crossed that Lean 4 will survive a bit longer.

but the backtrace didn't point to an obvious fix.

In Lean 3, the backtrace showed a crash in std::condition_variable while initializing the options (which are guarded by a shared_mutex which is implemented using condition variables).  I didn't see anything obviously wrong in the shared_mutex code.
We don't have the shared_mutex code in Lean 4 anymore, so the core dumps should show a different issue, which would ideally allow us to figure out what's going on with the Ubuntu 22.04 upgrade.

By the way, given the solution, it probably wasn't the Ubuntu upgrade but the switch to murmurhash, which simply happened to result in one particularly unfortunate new hash for a module name.

Like, extremely unfortunate: out of 920 module names, we happened to hash one into the top 0.008% of the address space


Update .gitignore

prevent pushing the result log of project 1.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

closed as stale


feat: Generate relay pagination types

The purpose of this PR is to support the generation of pagination connection types in accordance with the DGS Relay Pagination documentation. Currently, combining dgs-codegen with dgs-pagination results in compilation errors as the pagination plugin only adjusts the schema at runtime. This new feature is opinionated about types with the *Connection suffix and directives named @connection and is therefore turned off by default
Handles #93

@berngp have you had a chance to take a look at this?

@aovens-coursera - what errors do you see when using codegen with the pagination module? There shouldn't be any issues with using them together. Since the framework handles the @connection directive and generates the connection and edge types dynamically in the schema, the corresponding POJOs can be accessed using  graphql.relay types: https://www.javadoc.io/doc/com.graphql-java/graphql-java/16.2/graphql/relay/package-summary.html. This is mainly why the dgs-codegen module does not generate any POJOs for the pagination related types.
I'd like to understand better what issues you are running into that requires the PR chages you proposed. Could you provide a sample repo or code snippet to illustrate that? Thanks!


Flatten Documentation

Could you release a version of the documentation on a single page? Its a bit difficult to navigate as is without a time-consuming exhaustive search. Google site: helps, but returns many false positives. IMO a single page with ctrl+f would also greatly increase feature discovery.

@laxatives I use a chrome extension that enables me to search through any github repository's entire wiki: https://chrome.google.com/webstore/detail/github-wiki-search/gdifdhnjmjaidbajhapmbcbnoocoeooc?hl=en
This may be of use for you.

careful....Titan doesn't publish to the wiki anymore though.  All the current documentation is in asciidoc and published to html.

Titan is already capable of generating a one-page manual.  I configured that back when we moved to an AsciiDoc + DocBook toolchain.  It still pops out in titan-doc/target/docs/single/index.html during the build process, but it's not uploaded anywhere.
My browser has a mini-stroke when opening it (the markup alone is 1.4 MB), but it's still essentially usable.

ha - tinkerpop's single page reference docs with images and all seems to come in around 16MB - going to choke the life out these browsers - for realz.

@laxatives Did the responses here resolve your question ?  Can this issue be closed now ?

i don't think we should upload (mostly for the @dalaro reasoning) - folks can generate locally if needed.


fix validation length

i opened pull request #30
you not trigger the validation when the input length is 1,
and its save the state of valid for it when its invalid

fixed in v1.2.1


The first image is very slow to generate.

When I try to create an image with MotionDiff installed, it works very slowly. From the second time, it works fine again.
MotionDiff installed

Without ModtionDiff

Fixed in this commit: https://github.com/Fannovel16/ComfyUI-MotionDiff/pull/25


Implement From instead of Into in the HTTP API request types

This PR fixes Clippy a warning introduced in rust v1.51.1.
This is what's making #32 fail.

Btw, I don't see 1.51.1 published anywhere :confused:

Sorry, I meant 1.51.0


Update design-segmentation.md

Fix up spelling grammar and clarity

@TristankMS : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@TristankMS : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@PageWriter-MSFT Could you review the proposed changes to your article? Thanks.

@PageWriter-MSFT Could you review the proposed changes to your article? Thanks.

@doodlemania2 Could you review the proposed edits to the article? Thanks!

@doodlemania2 Could you review the proposed edits to the article? Thanks!

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@TristankMS @doodlemania2 - The meaning of "Isolating sensitive workloads from compromise of other assets" is unclear. Which would be accurate:
A) Isolating sensitive workloads from compromising other assets
B) Isolating sensitive workloads from being compromised by other assets
Thanks.

@TristankMS @doodlemania2 - The meaning of "Isolating sensitive workloads from compromise of other assets" is unclear. Which would be accurate:
A) Isolating sensitive workloads from compromising other assets
B) Isolating sensitive workloads from being compromised by other assets
Thanks.

The proposed change is to "Isolating sensitive workloads from compromise by other assets." If a sensitive workload is compromised, it's less important that it compromises other assets, it's the sensitive workload which is important.

The proposed change is to "Isolating sensitive workloads from compromise by other assets." If a sensitive workload is compromised, it's less important that it compromises other assets, it's the sensitive workload which is important.

@TristankMS Thanks--I made that edit and will merge the pull request now.

@TristankMS Thanks--I made that edit and will merge the pull request now.


chore(coverage): Fix file filtering

Currently coverage is low because all dependencies are included in the report. Add .luacov config leaving coverage related to sailor modules.

AWESOME <3
Thanks for that :dancers:

:smile:


vRP tables not found HELP

You need to set your database details in vrp/cfg/base.lua and in the server.cfg mysqlconnectionstring (at the top)

Issues are not for help.


[windows] Add specific check for elevation for integration command.

Add notification about the difference in user context to the check
command

@derekwbrown When do you need this review by?

@derekwbrown When do you need this review by?

@trishankatdatadog it's not for 6.8, so as soon as convenient

ok, just tag me on a FreshService ticket, please, so we can better track this, thanks :)


bluetooth: host: add ability to load CCC settings on demand

This commits adds a BT_SETTINGS_CCC_LOAD_ON_DEMAND option to allow for CCC settings to be loaded on demand when a peer device connects in order to reduce memory usage.

@fnde-ot Is there any advantage in keeping the old method? Maybe we could skip kconfig option and always do this?

@fnde-ot Is there any advantage in keeping the old method? Maybe we could skip kconfig option and always do this?

I think it could end up being very inefficient with some settings backends that have to go through the entire file to find a specific setting. Maybe we could have input from @nvlsianpu!

1. I can see that CCC is loaded - when it is saved?

This commit does not change the way CCC settings are saved, it works the same as it used to (the settings are either saved when a device disconnects, or after a small delay if CONFIG_BT_SETTINGS_CCC_STORE_ON_WRITE is selected)

2. If we remove bond - what happens with CCC saved?

This also does not change in this commit, bt_gatt_clear will be called when unpairing a device or when removing a local identity, which in turn will call bt_gatt_clear_ccc.

@rakons Thanks for looking into this, do you think we should enable this feature by default? Will loading single setting whenever a device connects work efficiently with existing backends (FCB, FILE and NVS)?

Will loading single setting whenever a device connects work efficiently with existing backends (FCB, FILE and NVS)?

I think it might be enabled by default. In the end - how offten do you connect to a new device? In very specific devices that connects and disconnects a lot, you may wish to disable this feature.

Note: Just pushed an update that changes #if defined to #if IS_ENABLED, and enables the Kconfig option by default.

@joerchan @jhedberg @Vudentz @nvlsianpu Just a time check, as we are approaching freeze tomorrow

@joerchan

@fnde-ot Is there any advantage in keeping the old method? Maybe we could skip kconfig option and always do this?

I think it could end up being very inefficient with some settings backends that have to go through the entire file to find a specific setting. Maybe we could have input from @nvlsianpu!

Unfortunately this will be case for FCB-backend, for NVS-backend should be less affected, but still need to process up to all entries.
What i see here is need for NVS record cache for reference a few nvs-entry needed to be accessed fast. << @Laczen FYI
I would no bother about FCB - NVS is better in all respect
This issue shouldn't be a case for FS-backend (just normal FS access processing addition).

^^ worth to emphasize the fact that if a settings constrained beckend is used (either FCB or NVS) most probably it uses quite small flash area, so browsing it should`t be extremely long.

@fnde-ot Ok. I see the value in keeping the Kconfig then. Seems sensible to have the option.

@fnde-ot would it possible to make the refactor of moving the static functions as it's own commit. So that it is easier to see the functional change in isolation?

@fnde-ot would it possible to make the refactor of moving the static functions as it's own commit. So that it is easier to see the functional change in isolation?

I did that in latest push, hopefully it makes it easier to review!


Automatic multi-platform Docker image build

Uses QEMU and Buildx to make the Docker image available on ARM platforms (can be extended to linux/amd64,linux/arm64,linux/riscv64,linux/ppc64le,linux/s390x,linux/386,linux/mips64le,linux/mips64,linux/arm/v7,linux/arm/v6).
ARM is a must for the convenience of Raspberry Pis :)

Would have to revert this as there is no image for arm/v7 on playwright, and as a result the docker builds are failing. :( Will update once there is a update to the image upstream.


pagemeta keepalive and page key

Environment
node lts
newest nuxt3
centos
Reproduction
https://stackblitz.com/edit/github-fnupnd?file=pages/index.vue
Describe the bug
I'm not sure if it's a bug or my lack of understanding,

I have a page where I list photos with infinite scroll
it also needs to be filtered by query parameters
watch query parameters, when changed, navigateTo('/list', {query})
but I want to make sure scroll position stays and data fetch doesn't fire again while navigating back and forth to detail pages and different query pages
so I keepalive: true for "keeping it alive" and set page key for differentiating pages with differnt queries.
then reproduction happens.
It only happens if both keepalive and page key is set, and also page transition is set.

Additional context
thanks for any advice in advance
Logs
No response

Setting a page key forces a full refresh when the key changes (that's the purpose of it). This will mean the component will not be kept alive. The two are not compatible with each other. You can handle this with a custom scrollBehavior, though there are already a couple of issues to improve things with the default scrollBehavior.


Import branch develop #c63845d

Reduced memory consumption on large content download for Google Drive - see https://github.com/viciousviper/DokanCloudFS/issues/29
Implemented additional unit tests
Updated .NET Framework to version 4.6.2
Updated various dependencies

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@11bbc99). Click here to learn what that means.
The diff coverage is 93.66%.

@@            Coverage Diff            @@
##             master      #19   +/-   ##
=========================================
  Coverage          ?   74.88%
=========================================
  Files             ?       41
  Lines             ?     1469
  Branches          ?        0
=========================================
  Hits              ?     1100
  Misses            ?      369
  Partials          ?        0

Impacted Files
Coverage Δ

CloudFS.Authentication/UIThread.cs
0% <ø> (ø)

CloudFS.Interface/IO/FileSize.cs
100% <ø> (ø)

CloudFS.Authentication/LogOnBase.cs
0% <0%> (ø)

...position/AttributeBasedCompositionTests.Fixture.cs
100% <100%> (ø)

...S.InterfaceTests/IO/ProgressStreamTests.Fixture.cs
100% <100%> (ø)

...aceTests/IO/ProducerConsumerStreamTests.Fixture.cs
100% <100%> (ø)

CloudFS.InterfaceTests/RetryPolicyTests.Fixture.cs
100% <100%> (ø)

CloudFS.Interface/IO/ProgressStream.cs
100% <100%> (ø)

CloudFS.AuthenticationTests/StringCipherTests.cs
94.54% <100%> (ø)

CloudFS.InterfaceTests/RetryPolicyTests.cs
100% <100%> (ø)

... and 5 more

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 11bbc99...c63845d. Read the comment docs.


[HUDI-7777] Allow HoodieTableMetaClient to build with HoodieStorage instance directly

Change Logs
This PR adds a new API #setStorage to the HoodieTableMetaClient builder so the builder can take HoodieStorage instance directly to build the meta client.  The HoodieTableMetaClient can still be built through the storage configuration.  The instantiation of the meta client on the the read path in the hudi-common module has been replaced with the usage of HoodieStorage instance.
Impact
Simplifies Trino Hudi connector integration.
Risk level
none
Documentation Update
none
Contributor's checklist

[ ] Read through contributor's guide
[ ] Change Logs and Impact were stated clearly
[ ] Adequate tests were added if applicable
[ ] CI passed

Azure CI is green.


Option to control the sort order of custom statuses in the group-by display command

⚠ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.

🔖 Feature description
First of, the ability to define custom statuses for tasks has to be one of the most exciting features I have seen in a long time. The applications are literally endless. THANK YOU!
With the current build (3.10.0) we have the option to group by custom statuses, which gives us some really cool outputs, e.g.
Gardening

[G] water the plants

In Progress

[/] task in progress

To Do

[ ] various todos

The problem is that some statuses (like Gardening) shouldn't really be at the top of the menu. From what I have gathered, the group by behaviour sorts on the alphabet of custom status names - rather than what I (as the user) think is most important.
✔ Solution
It would be really great if we could prioritise the sort order of the group by behaviour in the custom status settings, e.g. by doing something like:
- [/] => [x], name: 'In Progress', type: 'IN_PROGRESS', sort-order: '0' <= pushes this to the top
- [ ] => [x], name: 'To Do', type: 'TODO', sort-order: '1' <= pushes this below In Progress
- [G] => [g], name: 'Gardening', type: 'TODO', sort-order: '3' <= pushes this below To Do
Output:
In Progress

[/] task in progress

To Do

[ ] various todos

Gardening

[G] water the plants

In the event that gardening is more important than regular todo's, a user might set:
- [/] => [x], name: 'In Progress', type: 'IN_PROGRESS', sort-order: '0' <= pushes this to the top
- [ ] => [x], name: 'To Do', type: 'TODO', sort-order: '2' <= pushes this below Gardening
- [G] => [g], name: 'Gardening', type: 'TODO', sort-order: '1' <= pushes this above To Do
Output:
In Progress

[/] task in progress

Gardening

[G] water the plants

To Do

[ ] various todos

If the sort priority of two fields conflict, the system applies sort priority first and then alphabetises second, i.e.
- [/] => [x], name: 'In Progress', type: 'IN_PROGRESS', sort-order: '0'
- [ ] => [x], name: 'To Do', type: 'TODO', sort-order: '2'
- [G] => [g], name: 'Gardening', type: 'TODO', sort-order: '1'
- [C] => [c], name: 'Gardening', type: 'TODO', sort-order: '1'
Becomes:
In Progress

[/] task in progress

Cleaning

[C] do a chore

Gardening

[G] water the plants

To Do

[ ] various todos

❓ Alternatives
For now, I am using numbers 01 - 09 in my naming conventions to artificially create this behaviour, i.e.
- [/] => [x], name: '00 In Progress', type: 'IN_PROGRESS'
- [ ] => [x], name: '01 To Do', type: 'TODO'
- [G] => [g], name: '02 Gardening', type: 'TODO'
Outputs to:
00 In Progress

[/] stuff

01 To Do

[ ] more stuff

02 Gardening

[G] water the plants

📝 Additional Context
No response

With the current build (2.0.1)

I’m curious, the current is 3.10.0.

Thanks @claremacrae, when I first crafted the post this morning I had build 2.0.1 and was using _ to push things down to the bottom. I have since updated to 3.10.0 and changed to numbers (01, 02, etc.) to do the same. I'll amend my original post to clarify this.

✔ Solution
It would be really great if we could prioritise the sort order of the group by behaviour in the custom status settings, e.g. by doing something like:
- [/] => [x], name: 'In Progress', type: 'IN_PROGRESS', sort-order: '0' <= pushes this to the top - [ ] => [x], name: 'To Do', type: 'TODO', sort-order: '1' <= pushes this below In Progress - [G] => [g], name: 'Gardening', type: 'TODO', sort-order: '3' <= pushes this below To Do

An alternative implementation would be to allow users to re-order their custom statuses, by dragging them up and down.
I like idea, although it doesn't allow control over the order of the two statuses that are 'core' and always present.

@claremacrae your alternative approach (clicking and dragging) would be even more intuitive than what I suggested. I'm not sure if it is harder to implement, however.
RE: 'core' statuses, perhaps one option would be to include the core statuses in the custom status list (once the first custom status has been created) and disable certain options for these statuses?


show mobile view earlier instead of horizontal scrolling

Coverage remained the same at 56.212% when pulling dd6f27702b19cec1bc59a2b160d25c7e529755a4 on show-mobile-soonee into 821674fac7f739b23b27be4650805501a0744cd6 on master.

Coverage remained the same at 56.212% when pulling dd6f27702b19cec1bc59a2b160d25c7e529755a4 on show-mobile-soonee into 821674fac7f739b23b27be4650805501a0744cd6 on master.


further clarification to the legal questions around the AGPLv3

@karlitschek quick check pls

Yes, this was another

moment reading the forums ;-)

looks good :+1:


rustup

Sorry for the bustage in the parser. I'm afraid there might be more - we want to make the parser able to recover from errors, which is going to mean a lot of changes. I'll try and make the commit messages more informative, but ping me if you need help.

@nrc My hero! Thank you! :D More informative commit messages would be much appreciated. :-)

There is an error, but I think that is because your CI is running Rust 1.1 instead of 1.5 for stable. The change which causes this error was just fixing a deprecation warning, so if you want to support 1.1, you could revert it.

@nrc Yeah we can probably drop 1.1 at this point. Thanks!


Allow comparing different things

It seems compare tracks changes over time. I want to show a stacked chart to compare benchmarks of different tools.

Should be closed with #18


Validate phatcrack windows agent

Done, also thanks to you 😎
Windows agent support is now "best effort" and seems to mostly work.
Unfortunately my "best" effort is going to be fairly low ongoing, and it won't be 'officially' supported


Process stderr might be undefined

After spawning a process, you access output.stderr, but without checking if it exists.
https://github.com/mike-lischke/antlr-tgen/blob/95e0cd25790d95038c0da696a9275c7db75d0277/src/Generator.ts#L219
Without an additional check, e.g., if (output.stderr && ...), I get
TypeError: Cannot read properties of null (reading 'length')
    at C.generateANTLRFilesInWorkDir

There was no need to check. According to the typings this member cannot be null. I guess the type definitions need to be updated.

Probably it also depends on the version of Node.js, but not sure. An additional check is never bad tho.

Also fixed by 9f8c32a.


[ListItemText] Repurpose text class

After running into an issue similar to #7067 I discovered that the text class is only applied to the Typography component when the List is dense. Ideally, there would be two classes:

text, applied to the inner Typography component
textDense, applied to the Typography component when the list is dense

There may be an argument for breaking it into classes for primary, secondary, but this would be a simple and clear offering. At this point, the text class is confusing, but the other classes make sense:

root, applied to the root element
dense, applied to the root element when the list is dense
inset, applied to the root element when the list item text is inset

This PR:

Is a reference to closed issue #7067
Exposes text as a class that can be used to style the inner Typography component, whether the List is dense or not.
Adds new textDense class that can be used to specifically style the Typography component when the list is dense

This will introduce a breaking change for users who expect the text class to apply when the containing list is dense.

[X] PR has tests / docs demo, and is linted.
[X] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[X] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

@kgregory Thanks

@oliviertassinari thank you for making the changes.


<EMAIL_ADDRESS>Hash check failed

Hash check failed!
App:         naderi_scoop-bucket/openwebstart
URL:         https://github.com/karakun/OpenWebStart/releases/download/v1.7.0/OpenWebStart_windows-x64_1_7_0.exe
First bytes: 77 90 144 0 3 0 0 0
Expected:    c5e9499f211ee477428677cf4b61da013944dc3de60119253b30d1ba0e529717
Actual:      592ec684878149a04e9c435444fd1ff49255cc98a0191f88d66ac2b2e49ae68a

scoop install openwebstart
Installing 'openwebstart' (1.7.0) [64bit] [naderi_scoop-bucket]
WARN  By installing you accept following licenses:
GNU General Public License (https://spdx.org/licenses/GNU General Public License.html)
version 2 (https://spdx.org/licenses/ version 2.html)
Starting download with aria2 ...
Download: Download Results:
Download: gid   |stat|avg speed  |path/URI
Download: ======+====+===========+=======================================================
Download: 88bafe|OK  |   7.9MiB/s|C:/Users/0/scoop//cache/openwebstart#1.7.0#https_github.com_karakun_OpenWebStart_releases_download_v1.7.0_OpenWebStart_windows-x64_1_7_0.exe
Download: Status Legend:
Download: (OK):download completed.
Checking hash of OpenWebStart_windows-x64_1_7_0.exe ... ERROR Hash check failed!
App:         naderi_scoop-bucket/openwebstart
URL:         https://github.com/karakun/OpenWebStart/releases/download/v1.7.0/OpenWebStart_windows-x64_1_7_0.exe
First bytes: 77 90 144 0 3 0 0 0
Expected:    c5e9499f211ee477428677cf4b61da013944dc3de60119253b30d1ba0e529717
Actual:      592ec684878149a04e9c435444fd1ff49255cc98a0191f88d66ac2b2e49ae68a

Please try again or create a new issue by using the following link and paste your console output:
https://github.com/naderi/scoop-bucket/issues/new?title=openwebstart%401.7.0%3A+Hash+check+failed&body=Hash+check+failed!
App%3A+++++++++naderi_scoop-bucket%2Fopenwebstart
URL%3A+++++++++https%3A%2F%2Fgithub.com%2Fkarakun%2FOpenWebStart%2Freleases%2Fdownload%2Fv1.7.0%2FOpenWebStart_windows-x64_1_7_0.exe
First+bytes%3A+77+90+144+0+3+0+0+0
Expected%3A++++c5e9499f211ee477428677cf4b61da013944dc3de60119253b30d1ba0e529717
Actual%3A++++++592ec684878149a04e9c435444fd1ff49255cc98a0191f88d66ac2b2e49ae68a
ERROR This application failed to install: naderi_scoop-bucket/openwebstart

Hi @gemwrt,
Thank you for reporting.
The hash problem is fixed now, but the installer does not work properly on my system. Please don't install/upgrade, I'm working on solution.

Installer problem is also fixed 🙂


Add missing env var for idpartner-hosted trust-platform

Add missing env var for idpartner-hosted trust-platform

This won't work


Label Examples need to be Updated

Origin: https://github.com/radiantearth/stac-spec/issues/870 @notthatbreezy

Some of the examples in the label extension are outdated and could use updating.
For instance, in the spacenet roads example label:assets should be an array. The item linked to and the asset key referenced in the example are not actually the source that the labels apply to either.
Similar issues apply to the other examples in the label extension as well.

I added JSON Schema validator for label:assets in links and made the label:assets field an array in all examples, but I did not further verify that the values make sense ("the asset key referenced in the example are not actually the source that the labels apply to either."). So still some work to do here.


Type validation for merging structured conf into non-structured conf

Normally, adding a new field to a structured config causes a ConfigAttributeError:
$ cat tmp.py
from omegaconf import OmegaConf
from dataclasses import dataclass

@dataclass
class User:
    name: str = "bond"
    age: int = 7

if __name__ == "__main__":
    user = OmegaConf.structured(User)
    user.bla = 456

$ python tmp.py
Traceback (most recent call last):
    ...
omegaconf.errors.ConfigAttributeError: Key 'bla' not in 'User'
    full_key: bla
    object_type=User

And merging the new field into a structured config also causes an error:
...
if __name__ == "__main__":
    user = OmegaConf.structured(User)
    other = {"bla": 456}
    OmegaConf.merge(User, other)

$ python tmp.py
Traceback (most recent call last):
    ...
omegaconf.errors.ConfigAttributeError: Key 'bla' not in 'User'
    full_key: bla
    object_type=User

But if the order of merge is reversed, the type validation is skipped:
...
if __name__ == "__main__":
    user = OmegaConf.structured(User)
    other = {"bla": 456}
    cfg = OmegaConf.merge(other, user)
    print("OBJECT_TYPE:", cfg._metadata.object_type)
    print("CONFIG:\n" + OmegaConf.to_yaml(cfg))

$ python tmp.py
OBJECT_TYPE: <class '__main__.User'>
CONFIG:
bla: 456
name: bond
age: 7

No error has been raised, and a new field (outside of the User schema) has been added to the structured config.
Expected behavior
Type validation of structured configs should not depend on the order of merging.
Additional context

OmegaConf version: 2.1.0dev20
Python version: CPython 3.9.1
Operating system : MacOS

This has implications for using a schema in a Hydra defaults list. For example, in Validating against a schema in the same config group, there is the following example:
# config.yaml
defaults:
  - base_config
  - db: mysql

If the order is reversed like this:
defaults:
  - db: mysql
  - base_config

then there will not be proper type validation.

I think we have a separate discussion about this topic again recently and we decided that this as intended.
Closing, let me know if you disagree.


Check record was successfully

Check if the record was recorded successfully before moving/removing the folder with the images sent.
Methods:

upload()

Files

app/Http/Controllers/Admin/Blog/PostsController.php
app/Http/Controllers/Admin/Gallerys/GallerysController.php
app/Http/Controllers/Admin/Products/ContentsController.php

@odirleiborgert mind if i take this one?

@runz0rd
Feel free to improve the project and finalize the issue.

@odirleiborgert
Could you be more specific about "moving/removing the folder with the images sent"
I can see that files get deleted if they already exist, and thats being done before saving the upload


Update create.js

Allow pass undefined properties and get the correct defaultTo

@marsanla are you going to try to address this? or should I close

Just close from now, if i will have time i will came back to this issue. :)


Added own implementation of MediaType and removed spring lib

Functional thing to review:
An exception is thrown when a mediatype has multiple slashes, so "application/this/will/not/work".
Are we too strict? Or is this okay?

It's okay that media types with multiple slashes are rejected, they're invalid.


Make the "seconds" field for Toleration optional.

omc 1.9.7

If I specify seconds, we get the following error
create Pod test-master-0 in StatefulSet test-master failed error: Pod "test-master-0" is invalid: spec.tolerations[0].effect: Invalid value: "NoSchedule": effect must be 'NoExecute' when tolerationSeconds is set

Hey @yolkov
Thanks for the issue, it is a bug
we are working on new version that solved that one, will update you here when it will be released

Closing as issue is not relevant for the operator itself.


Dymension League: Add serial minting

5 tests are breaking because of new mint
for style formatting use forge fmt
in order to be accessible the mint function from outside, there should be a function that will return the next tokenId to mint
tokenId is not a clear name on what it represents


Feature request: (fill in) - test

Prerequisites

[X] I have searched the repository’s issues and Kinde community to ensure my feature request isn’t a duplicate
[X] I have read the contributing guidelines
[X] I agree to the terms in the code of conduct

What is the problem you’re trying to solve?
test
What solution would you like to see?
test
Additional information
No response

Testing if a comment on an issue comes through as a notification


Fixes double border in justified button groups.

Uses :before to create a 1px-wide strip of same background color as the button to cover the extra border. Modification added to .button-variant mixin to handle hover/focus/active states, i.e. match the colors of other states.
Not really in the same spirit as negative margins but definitely closer to it than nuking borders.

Refs #11964.


ENSEMBL (Human) gene reference must be downloaded and prepared

The following gene annotation dependency is pinned for this version of the schema.

Organism
Required version
Download

ENSEMBL (Human)
Human reference GRCh38 (GENCODE v32/Ensembl 98)] matching [cellranger 2020-A (July 7, 2020) release]
gencode.v32.primary_assembly.annotation.gtf

Parsing requirement:

Extract the ENSEMBL gene identifier and its human-readable label

Implemented in cellxgene-schema v2.0.0


Fix Carousel Overflow Bug

Removed CSS that was causing overflowed cards to show up in the carousel at 1400px+ width.
Formatted index.scss

Before:

After:

The overflowing blurry cards are actually part of the design spec for these components however you mentioned a separate bug regarding horizontal scroll lets get that one resolved
Thanks for diving in 💪

Any update on this or should we close this PR

Yes @comountainclimber planning to circle back on this one this week.

This one is ready for review @comountainclimber There is no longer an unnecessary horizontal scroll.

Thanks again for taking the initiative on this! Looks good to me @sfreeman422


Make sure when --es.num-replicas=0, ES indices have number_of_replica=0 not 1

Resolves #369
ES number of replicas was getting set to 1 even when specifying --es.num-replicas=0 when starting collector and query.
Before fix:
output of localhost:9200/_cluster/health?pretty
{
  "cluster_name" : "jaeger-cluster",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 4,
  "active_shards" : 4,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 4,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

ES cluster health check shows status 'yellow' and you will notice active_primary_shards=4 and unassigned_shards=4, which means some indexes are configured with value replicas=1, this can be confirmed by checking output of :
http://localhost:9200/jaeger-span-2017-09-02/_settings?pretty
{
  "jaeger-span-2017-09-02" : {
    "settings" : {
      "index" : {
        "mapping" : {
          "nested_fields" : {
            "limit" : "50"
          }
        },
        "number_of_shards" : "1",
        "provided_name" : "jaeger-span-2017-09-02",
        "mapper" : {
          "dynamic" : "false"
        },
        "creation_date" : "1504368267533",
        "requests" : {
          "cache" : {
            "enable" : "true"
          }
        },
        "number_of_replicas" : "1",
        "uuid" : "AkWNKfQSRlCa9pIoxilj5g",
        "version" : {
          "created" : "5050299"
        }
      }
    }
  }
}

Verified after fix:
output of http://localhost:9200/_cluster/health?pretty
{
  "cluster_name" : "jaeger-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 10,
  "active_shards" : 10,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

After fix output of http://localhost:9200/jaeger-span-2017-09-02/_settings?pretty
{
  "jaeger-span-2017-09-02" : {
    "settings" : {
      "index" : {
        "mapping" : {
          "nested_fields" : {
            "limit" : "50"
          }
        },
        "number_of_shards" : "5",
        "provided_name" : "jaeger-span-2017-09-02",
        "mapper" : {
          "dynamic" : "false"
        },
        "creation_date" : "1504369115915",
        "requests" : {
          "cache" : {
            "enable" : "true"
          }
        },
        "number_of_replicas" : "0",
        "uuid" : "Ou2TIOavSCyIDDqlj_4Gxg",
        "version" : {
          "created" : "5050299"
        }
      }
    }
  }
}

Personally I would rather have a parameter called "replication factor" that defines the total number of copies of the data, similar to Cassandra. Then the setting es.numReplicas = replicationFactor-1 could be done internally, which would allow RF=0 to be treated as empty value and overwritten by a default, since RF=0 is never valid (while NumReplicas=0 is valid).
I know that this would go against the nomenclature of ES configuration, thus a bit controversial.

@yurishkuro that should be ok, but as you already pointed out it goes against ES' nomenclature and might be confusing to ES users, also will cause issue with folks who are already relying on this parameter.

Coverage remained the same at 100.0% when pulling 9984acd9061ae0000c71a907a0d2c482b105ff9c on bharat-p:es-replica-fix-#369 into 413942a087934711620cc1e15ea72886eebadffd on uber:master.

maybe we can keep the command line switch name & meaning the same but default it to something like -1 if not specified, and handle the rest internally (like converting internal option to "rf" instead of "numReplicas"). My main concern with this change is that it breaks the convention in Jaeger codebase (and in Go language in general) that empty value (0) can/will be replaced by a default. After this change the value of 0 starts having a meaning rather than being an empty value.

Another option is we change default value for es.num-replicas to 0 instead of current 1.
cc @mh-park as he is the original author of ES storage plugin for his opinion.

There's a new PR #754, but the discussion above was left unresolved.
@pavolloffay Since you were doing work with ES and its configuration, do you have an opinion?
cc @manannayak


Full framework abstraction

This has been on our roadmap from the beginning, but it's time to make it happen for real!
Everything framework specific should be abstracted to remain framework agnostic to the developer.
Lets do our best to accomplish this without considering any specific frameworks. Each framework will have some unique considerations and we'll need to continue to extend this pattern as gracefully as we can as we learn more.

Resolved in #97


Feedback: --addr is very confusing

One of the first steps to set up a cluster is to run swarm join --addr=<address> <discovery>.
Many people mistake --addr for the manager address instead of the docker address.
We should find an alternative name, perhaps:

--cluster-addr
--peer-addr
--my-addr
--engine-addr
--docker-addr

Additionally, perhaps it would help if we'd pre-fill that option. In order to do that, we'd need to run swarm join with --net=host and grab the default interface's IP address.
Thoughts?

See also #741

See also #437. :-)

@squillace Thanks! Re-opening that, we should fix the docs.

My first idea was -H, like the regular flag to specify the docker host, but that's confusing, because swarm manage uses that. I like --docker-addr, --docker-address or perhaps --docker-host.

I like --node-addr since isn't that the offical term when running info and all in the docs?

@UserTaken That's another thing - I'm unsure about the term node, wondering if it should be engine. Thoughts?

Engine, without the "docker" context ("Docker Engine") ... not sure. Daemon might ring more bells on the command line.

I think node is fitting as it is a de facto term used in explaining a distributed systems such as Consul, Etcd, Fleet, Kubernetes, cryptocurrency, etc.

While I agree that node is used as the "official" term; the example, as mentioned in https://github.com/docker/swarm/issues/741 shows $ swarm join --addr=node_ip:2375 consul://consul_addr/path
The node_ip apparently wasn't enough to clarify what had to be entered;

what is the "node_ip" and what is the 2375 port? and can it be changed?

For consistency, --node-addr / --node-address sounds good, but it still needs a good explanation around that in the docs. I don't think this can be solved by only renaming the option.

I agree with @thaJeztah and @UserTaken for the node term.
In comparison:

docker-addr/engine-addr: too much bound to docker notions. Someone could get to know Swarm but still don't know anything about what docker exactly is (Although I agree that if they land on that github page that's very unlikely but still :)
cluster-addr: Too broad, what is a cluster in the context of swarm? Should I point this IP to the manager because this is the entity managing our cluster? etc.
peer-addr: Swarm agents are not directly communicating with each other, peer-addr refers to the notion of clustering machines together in a stronger sense, while Swarm takes a set of loosely coupled nodes to offer this vision of a cluster. peer-addr is more adequate for distributed K/Vs for example.

So I would say either my-addr or node-addr and I lean towards node-addr with a good explanation in the doc ;)

I'm only one voice, but as a relative newbie to docker-things, I like the node-addr idea but as @abronan and others mention, what you are doing here is completely unclear. what IS the port number we are putting there, conceptually? Is it the open VM port to the docker daemon on that machine? Is it a random SSH port? What IS the thing?
if you documented quickly what that thing is here, you'd solve the entire issue. It's the "node" address plus a port on which the node's docker daemon is listening, yes? In which case, just expressing it that way -- along with node-addr -- should be entirely and completely sufficient even for newbies.
Or do I continue to misunderstand what that endpoint actually represents? If so, you can see the problem. :-)

It's the "node" address plus a port on which the node's docker daemon is listening, yes?

You are right :) but I agree it's not clear in the doc yet.
A quick attempt here:
Before

Register the Swarm agents to the discovery service. The node's IP must be accessible from the Swarm Manager. Use the following command and replace with the proper node_ip and cluster_id to start an agent.
docker run -d swarm join --addr=<node_ip:2375> token://<cluster_id>

After

Register the Swarm agents in the cluster:
docker run -d swarm join --node-addr=<ip:2375> token://<cluster_id>

Where ip is the ip address of the current node and 2375 is the port where the docker daemon is running on that machine (2375 is the default port on which the docker daemon is listening to client's requests, but it may vary according to your setup).
Replace cluster_id with the token you generated using the swarm create command in step [include-step-number]

Or something like this?

@abronan looking good. I know I mentioned it in other places, but 2375 is the non-secure port, should the examples use 2376 secure/TLS?

IMHO, you should never document insecure ports without noting the fact and pointing to the secure instructions right there.
@abronan : yes, you're on the right track I think. Here's my take for your consideration:

Register the Swarm agents in the cluster:

docker run -d swarm join --node-addr=<node_ip>:<node-docker-port> token://<cluster_id>

Where node_ip is the ip address of the current node computer and node-docker-port is the port at which this node's docker daemon is listening. (Remember that 2375 is the default port on which the docker daemon listens to client requests, but it may vary according to how you set up your docker daemon. If you're trying to configure swarm for TLS-secured communication, 2376 is the default docker daemon port for that).

Replace cluster_id with the token you generated using the swarm create command in step [include-step-number]

my quick version for you.....???

Missing, still, is the stronger sense of the fact that WHATEVER port you configured docker to use on that node, THAT is the port value you need to put there. You're telling swarm that's here this node's docker endpoint is. It needs to know that. :-)

+1 to @abronan I think --node-addr fits well. In addition, it will be nice to document about default port 2375/2376 as part of the README and highlight to use the secure option.
@aluzzardi regarding pre-fill the address with --net-host, i believe we might have multiple interface choices in the host and hence might have to pick the right iface.

I agree with emphasizing security as I've noticed an abundance of unencrypted Docker ports when scanning the Internet, up to a dozen on a single IP range. Most are VPS' ranging from single core and 512MB RAM to
Containers: 13
Images: 242
Storage Driver: devicemapper
 Pool Name: docker-253:2-4298645046-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: xfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 6.493 GB
 Data Space Total: 107.4 GB
 Data Space Available: 100.9 GB
 Metadata Space Used: 11.72 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.136 GB
 Udev Sync Supported: true
 Data loop file: /home/dpeterson/docker_storage/devicemapper/devicemapper/data
 Metadata loop file: /home/dpeterson/docker_storage/devicemapper/devicemapper/metadata
 Library Version: 1.02.93-RHEL7 (2015-01-28)
Execution Driver: native-0.2
Kernel Version: 3.10.0-229.1.2.el7.x86_64
Operating System: Boss
CPUs: 8
Total Memory: 62.73 GiB
ID: K6H4:AZEN:RR4F:XF4A:BTGQ:ZJQR:MEIT:VFSR:WG26:C7PD:WXLS:SZEK

@UserTaken Geebers!!

Thanks for the great feedback!
/cc @moxiegirl
To sum up the conversation:

Change the flag --addr into --node-addr, as everyone seems to agree
Add a good explanation in the docs  of what node-addr is - everyone is agreeing as well
Explain what the port number is conceptually as @squillace mentioned
Emphasize security, as @UserTaken suggested

One think I might add as well, related to the port discussion: step 2 of Set up Swarm nodes says to run:
docker -H tcp://<IP_ADDRESS>:2375 -d

That is utterly confusing. It hardcodes the port with no explanation and worst of all people end up running (and failing at doing so) a second instance of docker rather than updating their system configuration to change to start up flags (we simply need them to add -H tcp://<IP_ADDRESS>:<whatever port they like>). This is tough to document since it's linux distribution specific.

@aluzzardi Sure thing. A few questions.
-- Must the --node-addr be an actual IP or can I use a named value that resolves like localhost or my-computer-name  If the option requires an actual IP I would rename it --node-ip to be exact.
-- Are IPV6 addresses supported? (I really should check the code but I'm trying to be quick.)
-- In this statement "This is tough to document since it's linux distribution specific." the antecedent to it's is unclear.  Do you meant the ip? the port? or the command configuration is distribution specific?

Thanks @moxiegirl
1/ It can be something that resolves but it must be reachable by Swarm so localhost won't work. To put it in other words, Swarm will connect to node-addr in order to talk to the Docker Engine running on that machine. If it's localhost, then Swarm will attempt to connect to itself.
2/ I believe it does support IPv6. Under the hood we use Go's net/http package which does support IPv6 but since we've never tested with IPv6, perhaps it's broken in some way so I wouldn't advertise it unless we have tests backing that up.
3/ The command configuration. Basically, you have to change the Docker daemon startup flags. The location of those options depends on how the user installed Docker. For instance, on Debian and Ubuntu it's going to be /etc/default/docker. This issue is not really Swarm specific: the Docker docs are missing that bit of information as well: docker/docker#3630. The latest Ubuntu release (15.04) switched to systemd and the way to set Docker flags changed as well: docker/docker#12926

@aluzzardi: re: 1, above, are we saying something like, "any address form that can be reached by the swarm master that is not the swarm master's address"? I'm assuming that, although it makes little sense, you could be testing out swarm on your local machine and in that case, localhost would work? But it's unlikely to be useful in other cases....??

@squillace: I was just implying we shouldn't mention localhost as an example in the docs - there are valid use cases for using localhost (I use it all the time), but I think we should just explain that the address must be reachable by Swarm and that's it (as in, not mention not the swarm master's address).
This might help: In order to check if the address is correct, the user could run docker -H <node-addr> info from the Swarm machine. If he gets the info back, then Swarm can talk to node-addr. If not, the address is wrong. @moxiegirl @squillace Thoughts?
@ehazlett @nathanleclaire: We are going to change --addr to --node-addr in swarm join. This would break machine - how should we handle this?

@aluzzardi: yes, agreed on no specific mention of localhost. agreed that a note indicating your test for the address value would be useful; everything else seems just peachy to me....

If the new --node-addr will be in 0.3.0 we will get it updated in master.
Along with that I will get the ability to use a different swarm image so we
can test the provisioning process.
Thanks for the heads up!
On Wednesday, May 20, 2015, Andrea Luzzardi<EMAIL_ADDRESS>wrote:

@squillace https://github.com/squillace: I was just implying we
shouldn't mention localhost as an example in the docs - there are valid
use cases for using localhost (I use it all the time), but I think we
should just explain that the address must be reachable by Swarm and that's
it (as in, not mention not the swarm master's address).
This might help: In order to check if the address is correct, the user
could run docker -H  info from the Swarm machine. If he gets
the info back, then Swarm can talk to node-addr. If not, the address is
wrong. @moxiegirl https://github.com/moxiegirl @squillace
https://github.com/squillace Thoughts?
@ehazlett https://github.com/ehazlett @nathanleclaire
https://github.com/nathanleclaire: We are going to change --addr to
--node-addr in swarm join. This would break machine - how should we
handle this?
—
Reply to this email directly or view it on GitHub
https://github.com/docker/swarm/issues/817#issuecomment-104040402.

Alternative: How about --public-addr? @squillace @thaJeztah @UserTaken @snrism

Good one. Clear, descriptive.
Only worry I have is that "public" doesn't need to be "public". Haven't actually checked if this is possible yet, but multiple nodes (in the same datacenter) will probably use the internal/private network.

I'm a cloud guy: node means "this machine, here". That could easily be in a private cluster, accessible through no public interface directly, as @thaJeztah suggests. At least, I believe so. The result is that --public-addr sounds like it's slightly wrong. Public to the VM, sure, but....  am I off base? I could easily be....

Confirmed. Toughest thing in development is naming things. Just call it --opt-817

Okay so, let's keep it --node-addr.
One last thought:
From our docs:
docker run -d -p <swarm_port>:2375 swarm manage token://<cluster_id>

How about this instead:
docker run --net=host -d swarm manage token://<cluster_id>

Then explain that Swarm will listen by default to 2375 and that can be changed (in the same way as Docker) with:
docker run --net=host -d swarm manage -H <IP_ADDRESS>:<whateverport> token://<cluster_id>

Is it more obvious?

Port 2375/2376 are the default ports for Docker daemon so shouldn't Swarm master default 3375/3376?

Afaik, we discourage using --net=host out of security considerations. Using it purely for convenience doesn't sound right, especially when targeting "newbies" that might not be aware of that. See https://docs.docker.com/reference/run/#mode-host

@aluzzardi +1 for @thaJeztah. I feel.... qualified as a newbieish person... to say that I prefer explicit in basic documentation to "this easy shorthand", whether it's --net=host or anything else. I'm likely to set up the swarm my own way; if the docs do anything that is default, I'm hosed if I've never used the default or the shorthand. And unhosing unknown defaults is kinda hard sometimes.
And after reading the host mode doc, I'd say no, please, let's skip that idea. Explicit about addresses and ports is not hard for newbies; stating the defaults to use them if you want is not hard for newbies. Give them the happy path to professional success. :-)

Another day another flag.
I just realized Consul uses --advertise - what do you think of that?

I think I'm going to go with --advertise - it kinda speaks to me.
Thoughts? @thaJeztah @squillace @UserTaken

@aluzzardi +1 I was torn between using it for Leader Election or for regular machines joining the cluster, but it makes more sense for swarm join I guess. You advertise your address through the discovery service. Makes sense to me.

Can I buy you a strong Long Island Iced Tea? I'm questioning your judgment. :-)
so, the command is something like,
docker run -d swarm join --advertise=<node_ip>:<node-docker-port> token://<cluster_id>
??? So, the command says, "have this node ADVERTISE it's docker endpoint to the swarm with "?

that sounds redundant to me, looking at it. The join command says, "JOIN", not "please may I join if you notice that I'm here?" which was what "advertise" feels like. Why isn't the command swarm advertise <ip>:<port> then? Why not ditch the whole named argument issue?
BTW: at this point, I am just responding honestly. I think really so long as you dock it properly, you can use --opt-817 as @UserTaken has already suggested. :-) I am, however, impressed you're thinking about it so intently.

Can I buy you a strong Long Island Iced Tea? I'm questioning your judgment. :-)

Please :-)

that sounds redundant to me, looking at it. The join command says, "JOIN", not "please may I join if you notice that I'm here?" which was what "advertise" feels like.

For me, it means join this cluster and --advertise this as my address. The flag doesn't control if join should advertise, it sets what it should advertise.

Why isn't the command swarm advertise : then? Why not ditch the whole named argument issue?

Because:

It feels strange to pass both token://foo <ip:port> to join (or advertise)
--advertise can be optional. Consul uses the bind address if --advertise is not provided
There are some ways to set sensible defaults for the address to advertise (we could look at the network interfaces, we could change docker to return the address, or some stores such as Consul can actually tell you the address you are communicating with). Settings that as an arg rather than a flag removes the sensible default option from the table.

BTW: at this point, I am just responding honestly.

I appreciate that :)

I think really so long as you dock it properly, you can use --opt-817 as @UserTaken has already suggested. :-) I am, however, impressed you're thinking about it so intently.

I've seen so many people get --addr wrong and spend a long time debugging the issue. Those people include @samalba and @jpetazzo who have been using Docker since before it was even called Docker, so it's an alarming issue.
The project can only be as good as its getting started process.

@aluzzardi OK, this we can work with. So, if we were being honest, we'd say something like, swarm join --advertisement-address=<ipOrDnsNameForVM>:<dockerPort> token://<clusterId>.
How does that feel? swarm join is the command. the <ip>:<port> portion is the advertised, announced, publicized, or published location of the node computer and it's docker daemon listening port. Advertised seems to me the least of the problem. I think if you have : there, then you really can use any of these names. It was the values that ; represented and could be that threw me for the week I struggled with this. as a result, I would argue for something like this, because it's not the --advertise part that was strange for me, it was the values of the address and of the port. So:

docker run -d swarm join --advertise=<node_ip_or_addr>:<node-docker-port> token://<cluster_id>

Give that a try, if you like advertise. How does that feel?

How's that different from --node-addr or even --addr?

@aluzzardi bingo, I would say. From my newbie point of view, the problem for me -- and so therefore your mileage may vary -- was that the argument possibilities weren't clear. --addr said to me, "ok, this is supposed to be an address... but of what?". So it's the "of what" part that needs to be clear in my view. "advertise" doesn't change that one iota, to me.
Certainly, I thought that --node-addr was better, in that it sorta made it clear what the address was supposed to be for. But I still would never have guessed -- as others didn't -- whether I could change the address, what port I was specifying there -- was it the docker port, or was that some swarm port I just missed in the docs somewhere? -- that kind of thing.
The result is for me that, whatever you do in this name, make sure the following are clear:

The ip OR resolveable dns name (or "localhost") of the docker host's computer are the obvious first portion of that address.
That the port portion of that address is the port on which the docker daemon on that computer is listening, that it can be whatever port you configured your docker host to use (though the default is 2375 and the secured default is 3370 or whatever).

If you do those things, it'll be obvious to the naive user that what swarm join does is take a docker host's address and docker port and sends that to the discovery service along with the cluster id that the docker host would like to be a part of. You know that, then you completely understand this command and what the parameters must be.
That is the entire logical flow that I missed when we went through this, not knowing enough as I did then. I'm good with --advertise in the abstract, but it doesn't address the heart of the misunderstanding for newbies. I don't care whether it's really "joining" or whether it's merely "advertising it's ability to join" -- I just want to know what I put there, and what I CAN put there. :-)
And by the way, I sure hope thNot the e feedback helps, even if you decide to go a different direction.

Does that help?
$ swarm join --help | grep advertise
   --advertise, --addr 	Address of the Docker Engine joining the cluster. Swarm managers MUST be able to reach Docker at this address. [$SWARM_ADVERTISE]

Reacts to random GH ping
Much ♥ to --advertise, or --my-addr, or --this-node-addr ... :-)
Also, inferring the value automatically would be super nice, but risk-prone:

when using the local interface address, on EC2, we'll get an internal address, which is cool if the whole cluster is internal, not so cool if the cluster spans multiple subnets;
when using the public address seen by the discovery mechanism, we get something that is more likely to work, except for an entire cluster masqueraded behind a single node.

¯_(ツ)_/¯

@aluzzardi YES, that is absolutely fine. Go for it. IMHO, that was nexus of the problem. :-)
@jpetazzo: yes, agreed. I have swarms crossing subnets, clouds, and flowing onto the premise, too. Let ME tell swarm what that address should be. :-)

Actually I dont have any problem as we are doing the whole setting up thing via docker-machine, but let me be able to tell it too.

Fixed in #858


Create Feature Init Stubs

[x] HTML view for each feature

[x] Controller for each feature

[x] HTML element passed to controller
[x] corresponding dom passed to controller

Done as of 8473ce59437


TIC's r-w directory requires root to edit and view on Android.

/data/data
Requires root permissions on Android.
/Android/data/ does not. It'd be nice to access my .tic without rooting my tablet or phone.

I made a fix and now files are in /Android/data/com.nesbox.tic/files
Pls check it
tic-fixed-folder.zip

That works! Perfect!

ok, fixed on .18
closing

I had an issue where my saved file was not in the specified location of /Android/data/com.nesbox.tic/files
I had an older .tic file which was in this location, however, and I overwrote that file with my newer file and it DID save to that same file. Thus I was able to retrieve my file from /files, however I suspect my file originally saved to the hidden location...


Add middleware to Customize Script

This is a customize script for the middleware. It does not include any nginx configurations yet and still statically chooses the rpc password and username. @hkjn gave me a tour of the cookie auth today, once that is merged, I'd like to include it as well.

utACK https://github.com/digitalbitbox/bitbox-base/pull/10/commits/9cfb2e53c24cc66cbcb900f27f1ae5fbf1869dcf

tACK https://github.com/digitalbitbox/bitbox-base/commit/aa36849ea8efbf34286f52641348964d49df9cd3, built image, middleware starts

Thanks a lot @Stadicus! I rebased on master to adapt the script to the new cookie auth.

I just noticed that I set the port in the avahi config to 8845. I did this without giving any consideration if this port is reserved for something else. Most servers allow to specify a custom port, so it should not be a problem for us to assign it something else, in case we hit a problem. It would be nice to have a document show all the services/servers we are running and their corresponding ports though.

I just noticed that I set the port in the avahi config to 8845. I did this without giving any consideration if this port is reserved for something else.

It doesn't look likely that other services using tcp/8845 are likely to need to run on our device:

https://www.adminsub.net/tcp-udp-port-finder/8845

It would be nice to have a document show all the services/servers we are running and their corresponding ports though.

Would the /etc/services config we write to work for this purpose? See customize-armbian-rockpro64.sh#L173.

Using code as documentation is fine by me, as long as there is some visibility on where to read the code about ports and their rules.

Using code as documentation is fine by me, as long as there is some visibility on where to read the code about ports and their rules.

Sounds good. So we're saying we also should have something under docs/ that mentions where to find the /etc/services config to review which tcp/udp ports we use for different services?


Allow custom volume mount path for consul-template

Is your feature request related to a problem? Please describe.
For some applications, it is necessary to expose secret files at a specific path (in my case, I'm trying to use consul-template to inject certificates into an OpenLDAP deployment)
Describe the solution you'd like
The webhook should allow specification of a custom secrets volume mount path via an annotation such as vault.security.banzaicloud.io/vault-ct-mount-path
Describe alternatives you've considered
I'm attempting to work around this issue by setting a symlink in the entrypoint of my container, but this has some limitations and requires baking a custom image with a modified entrypoint
Additional context
Per the conversation on the original PR adding support for consul-template, this feature was already identified as nice to have by @marcoreni https://github.com/banzaicloud/bank-vaults/issues/403#issuecomment-492165976

Nevermind, it looks like support for this was merged last week https://github.com/banzaicloud/bank-vaults/pull/669


fix: Fix build when using use_frameworks

For some reason, Folly seems to spazz out when building the iOS app with use_frameworks / ENV['USE_FRAMEWORKS'] enabled.
Frameworks are a relict of the past anyways and are not really recommended to be used because they're dynamically linked instead of statically compiled modules, which is what Swift supports now.
But Firebase still seems to use Frameworks and for some reason STILL haven't migrated away from it.
People complained to me that Nitro doesn't build with Firebase, instead of telling Firebase to migrate away from Frameworks.
Anyways.. This now adds support for Frameworks.
For this to work, we have to disable the Folly configuration (FOLLY_NO_CONFIG) and coroutines, and import the -Swift.h header using the fully qualified name.
I have no idea why Folly seems to fail to build with frameworks, but whatever.
Since this is not really part of Nitro or Nitrogen, users are expected to add this to their .podspec files.
This PR is based off of https://github.com/mrousavy/nitro/pull/333 (so huge thanks to the author!), but with a few changes. Also it is formatted properly. And instead of just removing the NitroLogger import (which breaks the build), I exposed NitroLogger as a public header. Also I added deps on JSI and CallInvoker.

Bravo, Let's go.... 🚀🚀🚀🚀


chore: add custom typings for examples

Currently component-style is broken because it can't find the module thing.
I added a custom.d.ts that will be added to typings and then it will be available everywhere.

As @chalin pointed out, this won't work on the live plunker, so I am open to ideas here.

I thought I HAD added this typings file (as typings.d.ts rather than custom.d.ts) but somehow failed to commit it. Could have been impeded by the .gitignore.
Thanks for figuring this out. But I took a different approach to the problem and described it in the documentation.
See PR #1355.
We are TOTALLY HOSED in plunkers for the moment because CLI and Style Guide are committed to the commonjs module.id and I can't find any transpile options that will make it work in plunker.
I tried the following and it doesn't work:
  typescriptOptions: {
      emitDecoratorMetadata: true,
      module: 'commonjs' // should have done the trick!
    },
``


Add minimum version

This new version of teku contains a new env that required the next version of dappmanager

Missing context


Add Link to Slack at the Bottom

Can you please add a icon and link to the slack channel (with the same style)?

Can you share the link? I don't have the current one as I don't use slack anymore. This one doesn't work anymore.

Got it from the docs.


check key values

Key values must be checked:

permit doublicate key values while editing
check existing key values in database table before saving

done with todays change (2019-10-25).
But highlight of line with duplicate key does not work properly.
User gets info about "duplicate key" and the duplicate line should be coloured RED.
But this happens only after the second check... :/

error due to an error message send LIKE 'I'.


Milestone 1: Project Setup

Milestone 1: Project Setup
In this milestone we:

Added the option of adding a new book
Added a list for displaying the books
Added a feature of removing a book from the list

Hi @MarwanDev and @joyapisi,
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
Invalid Code Review Request
You have submitted a project, that is invalid because the README file is missing relevant headers like the key features.Also, do not leave the future features blank, put something there while thinking about the app
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.


Feature Request: Increase deferral options by more than 1 day

It would be nice to increase the number of deferral days, 2 or 5 days, or add a calendar for choosing days.

Might be worth noting this is was a feature request with IBM Notifier as well, I guess once that's done it could be implemented into Super?
https://github.com/IBM/mac-ibm-notifications/issues/119

I'm aware... the issue is that there is (currently) still no way in IBM Notifier to limit which calendar days are allowed for selection.

https://github.com/Macjutsu/super/releases/tag/v4.0.0-beta1


Subtract newline from column count when calculating end position

This PR fixes a bug that caused the end position column to be one larger than it should be in cases where the node metadata contains newline information.
This is best seen by example:
iex(1)> string = """
...(1)> foo 1
...(1)> bar 2
...(1)> baz 3
...(1)> """
"foo 1\nbar 2\nbaz 3\n"
iex(2)> {_, _, [foo, bar, baz]} = Sourceror.parse_string!(string)
{:__block__, [trailing_comments: [], leading_comments: []],
 [
   {:foo,
    [
      trailing_comments: [],
      leading_comments: [],
      end_of_expression: [newlines: 1, line: 1, column: 6],
      line: 1,
      column: 1
    ],
    [
      {:__block__, [trailing_comments: [], leading_comments: [], token: "1", line: 1, column: 5],
       [1]}
    ]},
   {:bar,
    [
      trailing_comments: [],
      leading_comments: [],
      end_of_expression: [newlines: 1, line: 2, column: 6],
      line: 2,
      column: 1
    ],
    [
      {:__block__, [trailing_comments: [], leading_comments: [], token: "2", line: 2, column: 5],
       [2]}
    ]},
   {:baz, [trailing_comments: [], leading_comments: [], line: 3, column: 1],
    [
      {:__block__, [trailing_comments: [], leading_comments: [], token: "3", line: 3, column: 5],
       [3]}
    ]}
 ]}
iex(3)> Sourceror.get_end_position(foo)
[line: 1, column: 6]
iex(4)> Sourceror.get_end_position(bar)
[line: 2, column: 6]
iex(5)> Sourceror.get_end_position(baz)
[line: 3, column: 5]

The foo and bar expressions report the column of the trailing newline, while the last baz expression does not. This becomes problematic in conjunction with get_range, which increments the end column by 1 so that it's exclusive -- this causes the range to report the column as 7 for the examples above.
I found this bug due to the new way that newlines are handled in patch_string -- they remain at the end of each line, whereas previously they were stripped and re-added later. So when get_range returned a column that was 1 larger than it should be, the newline would be included in the range to be replaced, causing newlines to be dropped.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


fix:  handle non-existing files in sourcemap

Description
If a source map contains a file in source section without uploading the referenced file, Vite will complain about ENOENT.
This fix makes Vite more lenient with npm ecosystem's misdemeanor.
Additional context
When a npm package's source map has a source field, Vite will resolve the referenced file. However, not all packages will upload the source to npm registry, which makes such error. For example, the package compute-scroll-into-view does have such sources field.

And vite throws an error.

Instead of throwing an error, this fix makes Vite ignore the missing source file.
To make the output less noisy and make the build successful, a comment is added for possible suggestion in the emitted source map. This supersedes #2904.

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the Commit Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

Thanks, but I'd rather the devtools show the compiled code instead of a mostly useless comment.
I've updated #2904 to warn just once per sourcemap instead of throwing an error. Let me know if that approach is good enough for you.

Thanks.

Thanks, but I'd rather the devtools show the compiled code instead of a mostly useless comment.

But I'd rather argue warning in devtools is, well, equally useless and a debugging log is too hard to find after a flag.(finding th flag is not discoverable unless one reads the source).
But whatever, no blocking the build is enough for most devs and hope #2904 gets merged soon.


custom trading_calendar issue

Dear Zipline Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment
Python 3.5.2,  zipline1.3.0

Operating System: (Windows Version or $ uname --all)
Python Version: $ python --3.5.2 version
Python Bitness: $ python -c 'import math, sys;print(int(math.log(sys.maxsize + 1, 2) + 1))'
How did you install Zipline: (pip, conda, or other (please explain)) pip install zipline
Now that you know a little about me, let me tell you about the issue I am
having:

** TwentyFourHR class ＊＊

from datetime import time
# for setting our start and end sessions
import pandas as pd
# for setting which days of the week we trade on
from pandas.tseries.offsets import CustomBusinessDay
# for setting our timezone
from pytz import timezone
# for creating and registering our calendar
from trading_calendars import register_calendar, TradingCalendar
from zipline.utils.memoize import lazyval

class TwentyFourHR(TradingCalendar):
    """
    Exchange calendar for 24/7 trading.

    Open Time: 12am, UTC
    Close Time: 11:59pm, UTC

    """
    @property
    def name(self):
        return "twentyfourhr"

    @property
    def tz(self):
        return timezone("UTC")

    @property
    def open_time(self):
        return time(0, 0)

    @property
    def close_time(self):
        return time(23, 59)

    @lazyval
    def day(self):
        return CustomBusinessDay(
            weekmask='Mon Tue Wed Thu Fri Sat Sun',
        )

panel =  open_pickle('bitmex_panel.pkl')

start = pd.Timestamp('2018-08-20', tz='utc')
end= pd.Timestamp('2018-08-21', tz='utc')

perf,perf_daily  = zipline.run_algorithm(start=start,
                          end=end,
                          initialize=initialize,
                          trading_calendar=TwentyFourHR,
                          capital_base=20000,
                          handle_data=handle_data,
                          data_frequency ='minute',
                          data=panel)

**Error message **

  File "<ipython-input-11-292a8c87aebd>", line 1, in <module>

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\spyder\utils\site\sitecustomize.py", line 710, in runfile
    execfile(filename, namespace)

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\spyder\utils\site\sitecustomize.py", line 101, in execfile
    exec(compile(f.read(), filename, 'exec'), namespace)

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\zipline\utils\run_algo.py", line 430, in run_algorithm
    blotter=blotter,

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\zipline\utils\run_algo.py", line 129, in _run
    if trading_calendar.session_distance(start, end) < 1:

TypeError: session_distance() missing 1 required positional argument: 'end_session_label'

Description of Issue

What did you expect to happen?
What happened instead?

Here is how you can reproduce this issue on your machine:
Reproduction Steps

...
What steps have you taken to resolve this already?
...
Anything else?
...
Sincerely,
$ whoami

Hello, also , I encounter a problem.
from trading_calendars import get_calendar
ImportError: cannot import name 'get_calendar'

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\spyder\utils\site\sitecustomize.py", line 710, in runfile
    execfile(filename, namespace)

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\spyder\utils\site\sitecustomize.py", line 101, in execfile
    exec(compile(f.read(), filename, 'exec'), namespace)

  File "E:/区块链工作/notebook/趋势策略/20180912/MACD和均线.py", line 20, in <module>
    from time_setting import TwentyFourHR  #时间包裹

  File "E:\区块链工作\notebook\数据和功能代码\zipline功能代码\time_setting.py", line 142, in <module>
    from trading_calendars import register_calendar, TradingCalendar

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\trading_calendars\__init__.py", line 17, in <module>
    from .calendar_utils import (

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\trading_calendars\calendar_utils.py", line 1, in <module>
    from .always_open import AlwaysOpenCalendar

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\trading_calendars\always_open.py", line 16, in <module>
    from zipline.utils.memoize import lazyval

  File "C:\path\to\directory\containing\other\environments\zipline3.5.2\lib\site-packages\zipline\__init__.py", line 21, in <module>
    from trading_calendars import get_calendar

ImportError: cannot import name 'get_calendar'

Just use parenthesis..
trading_calendar=TwentyFourHR()


when host is in "Disconnected" state , there is a constant attempt made to start "healthcheck" container that keeps failing.

Rancher Version: v1.3.0-rc1
Steps to reproduce the problem:
Deploy a global health check enabled services.
Deploy a global services with no health check enabled.
power down one of the hosts.
Wait for the host to go from Active->Reconnecting->Disconnected.
Even after the host is in "Disconnected" state , there is a constant attempt made to start "healthcheck" container in this that keeps failing.
I see lot of volumestoragepoolmap.remove process timing out during this time.
We should to be trying to start healthcheck containers on the host that is in "Disconnected" state.
| 2091 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:43:13 | 2016-12-19 01:43:19 |
| 2092 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:43:27 | 2016-12-19 01:43:34 |
| 2093 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:43:43 | 2016-12-19 01:43:51 |
| 2094 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:43:59 | 2016-12-19 01:44:03 |
| 2095 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:44:13 | 2016-12-19 01:44:21 |
| 2096 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:44:29 | 2016-12-19 01:44:34 |
| 2097 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:44:44 | 2016-12-19 01:45:31 |
| 2098 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:45:33 | 2016-12-19 01:46:22 |
| 2099 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:46:23 | 2016-12-19 01:47:24 |
| 2100 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:47:25 | 2016-12-19 01:49:10 |
| 2101 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:49:11 | 2016-12-19 01:49:29 |
| 2102 | healthcheck-healthcheck-3           | purging | 2016-12-19 01:49:44 | 2016-12-19 01:49:45 |
| 2103 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:49:52 | 2016-12-19 01:49:54 |
| 2104 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:00 | 2016-12-19 01:50:02 |
| 2105 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:14 | 2016-12-19 01:50:16 |
| 2106 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:22 | 2016-12-19 01:50:24 |
| 2107 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:30 | 2016-12-19 01:50:32 |
| 2108 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:44 | 2016-12-19 01:50:46 |
| 2109 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:50:52 | 2016-12-19 01:50:54 |
| 2110 | healthcheck-healthcheck-3           | purged  | 2016-12-19 01:51:00 | 2016-12-19 01:51:02 |
| 2111 | healthcheck-healthcheck-3           | purging | 2016-12-19 01:51:14 | 2016-12-19 01:51:16 |
| 2112 | healthcheck-healthcheck-3           | purging | 2016-12-19 01:51:19 | 2016-12-19 01:51:21 |

This issue is also seen with any global health check enabled services.

@sangeethah the fix for it is in master

Tested with rancher-server version - v1.3.0-rc2 .
When host go to "Disconnected" state , there is no constant attempt made to start "healthcheck" containers anymore.


Storybook console warning: Each child in DatagridSimpleBody should have a unique "key" prop

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)

Detailed description

Describe in detail the issue you're having.

When running Storybook locally, I see console warnings across many stories.
http://localhost:3000/?path=/story/ibm-products-components-datagrid-datagrid-canary--basic-usage
Warning: Each child in a list should have a unique "key" prop.
Check the render method of `DatagridSimpleBody`...

Is this issue related to a specific component?

Yes: packages/ibm-products/src/components/Datagrid/Datagrid/DatagridSimpleBody.js

What did you expect to happen? What happened instead? What would you like to see changed?

We should not see these console warnings at all.

What browser are you working in?

Chrome, latest.

What version of the @carbon/ibm-products (or @carbon/ibm-cloud-cognitive) package are you using?

v2.12

Any pressing ship or release dates we should be aware of?

No.
Steps to reproduce the issue

Fork and clone @carbon/ibm-products to your local machine.
yarn to install packages.
yarn storybook to run Storybook.
Open the browser to each of the URLs listed above.
Open the browser's dev tools.
Select the "Console" tab to view the console warnings.

After some research, this may not be fixable.
The render function of DatagridSimpleBody is mapping through object-oriented code instead of a React/JSX/DOM element node. This is where a "key" property would normally be applied.
(Example code simplified for clarity)
const DatagridSimpleBody = () => {
  return (
    <TableBody ... >
      {rows.map((row) => {
        prepareRow(row);
        return row.RowRenderer({ row });
      })}
    </TableBody>
  );
};

I believe we just needed to add the key to fragment in DatagridRow which is the component that row.RowRenderer renders. https://github.com/carbon-design-system/ibm-products/pull/3772


Statically verify input types and permit nested JSON types

Addresses issues 19 and 20.

Thanks for the PR. I've implemented it differently though with the help of Luc.


Add proxy http port for metrics

Depends on https://github.com/zenithdb/zenith/pull/1093
TODO:

learn and apply helm best practices

have added small fix in deployment.yaml template but merge will be possible when proxy will accept --http command line option (chart tests fails now)