Start of second syncpulse is off(~17ms).

So i used the sensor board as shown, but wanted to process the signal by myself (via a esp32 DevKit v1).
Now when i read the time, the second syncpulse starts to late:

1->0:    97us      (97)  (SyncPulse 1)
0->1:  416us    (319) (Time between Pulse 1&2)
1->0:  532us    (116) (SyncPulse 2)
0->1: 4218us (3686) (LaserSweep)
1->0: 4226us       (8)      (...)
0->1: 8332us (4106) (Begining of next Cycle/end of this Cycle)

in this example, the second pulse start 16 ms to late, and i get this for every cycle (always off by around 17us), But the overalltime with 8332us is always on spott (within a 1us margin). Also processing the the pulse lenght of the two syncpulses, they are often off.
In this example, SP1: 1,0,0 SP2: 1,1,0 (skip, data, axis). This eror happens every 4-6 cycles in addition i occasionally get pulses which are longer than 135us(136-139).
Now coupled with the still correctly overall lenght, i am at a loss as to how to correct the SyncPulses, or where my Error lies. (If this does matter, Lighthouses Sync via cable(A, B).).
Edit: I still have no idea, why my data is off, but after if i correct the pulses which are a bit longer down to 135us, transfer this to bits (skip data axis), and substract 1 from this bits, i get correct Skip / Axis bit for 99% of the time

can you post the code? are you using interrupts?

My approach was to not assume there's exactly 400µs between the pulses and
just calculate distance from the laser pulse to the sync pulse of the same
station. That worked pretty well.
--
Alexander Shtuchkin
On Sat, May 26, 2018 at 5:00 PM, modulab<EMAIL_ADDRESS>wrote:

can you post the code? are you using interrupts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ashtuchkin/vive-diy-position-sensor/issues/46#issuecomment-392295560,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAmVHcH1ZVmTLZX2RWtmlq_wNfYCA7gBks5t2eyxgaJpZM4So4zA
.

@modulab I checked everything thought, and also found another issue #34 there its stated that the problem lies in the sensorboard.
@ashtuchkin The Problem is rather which Station(the shorter Syncpulse), and which Axis is sending right now, but i changed it now with two simple tricks:
The longer syncpulse is the one which signals skip,
and by collecting 4 cycles(2 Syncs + Lasersweep), i can say first cycle for station 1 is hor and second cycle is vert (dont exactly remember which one comes first right now).
With that i think i consider this topic as closed? Its not exactly the solution but the workaround worked perfect.


After a restart the node was incapable syncing to the LMI

Describe the bug
I let the node synchronize until it was solid and then shutdown cleanly. After the restart, the node was busy trying to get the missing transactions it needed to solidify the milestone 2 steps away: https://ybin.me/p/4145451fa46d278f#qjAZwap39dEVsraPZ8ZMDAReimpeSf8Po1udyCx9GgI=
To Reproduce
Steps to reproduce the behavior:

Shutdown cleanly
Wait for some milestones to be issued
Restart
See the solidifier getting kicked on multiple times and not being able to solidify

Only happens rarely (otherwise another issue report would already have been written)
Expected behavior
Given the small delta of only 2 milestones the node had from the LMI, syncing up should have taken less than 5 seconds after the restart.
Environment information:

OS: Windows 10
RAM: 32 GB
Cores: 16 cores
Type: Custom
HORNET version 0.2.7

@luca-moser is this still a problem with latest dev?


Standard deviation computation incorrect?

It looks like the standard deviation calculation is not yielding the correct results. Using the test data of [10, 20, 30], the STD comes out to ≈8.16, but the test has a value of ≈21.[...], which looks wrong.
Looking at the code, it seems like the library only computes the square root of the squared sum divided by the number of elements, whereas it should be the square root of the variance of the sample, the sum of the squared differences from the mean value.

Fixed and published:
statistics: ^1.0.21

https://pub.dev/packages/statistics


The selected filter does not filter the model in the admin panel

The selected filter does not filter the model in the admin panel
I migrated DAL==3.5.1 for django 4 (replace ugettext to gettext)
I did this because the dropdown with the autocomplete did not work and there was ----
Now I select an entry from the dropdown, but the model in the admin panel is not filtered - what could be the matter?
class OfferFilter(AutocompleteFilter):
    title = _('Оффер')
    field_name = 'name'
    autocomplete_url = 'admin:offer-search-select'

    def get_queryset_for_field(self, model, name):
        return Offer.objects.all()

    def queryset(self, request, queryset):
        if self.value() and self.value().isdigit():
            return queryset.filter(id=int(self.value()))
        return queryset

@admin.register(Offer)
class OfferAdmin(ExportMixinAdmin, ArchiveMixin, TabbedTranslationAdmin, NestedModelAdmin, AdminConfirmMixin):
    inlines = [OfferSourceTypeNoteInline, OfferPageInline, OfferTargetInline, OfferContestConfigInline]
    filter_horizontal = ['countries', 'custom_webmasters', 'offer_source_types']
    list_display = (
        'id', 'name', 'advertiser_link', 'offer_manager', 'publish_dt', 'offer_type', 'is_hidden', 'status',
        'last_start', 'stat_refresh_info', 'integration_method', 'is_sponsor_display', 'get_sponsor_position'
    )
    search_fields = ['name', 'search_options', '=id']

    list_filter = (
        OfferFilter, )

Please help me.
I am migrating a very large project from django version 1.9 to >4
I want to cry

Did you solved it?
Im trying make it work with list_filter but without success until now.

@paulocoutinhox I have solved this
It's time to write your own class derived from Autocomplet Filter From the admin_auto_filters library
class SelfAutocompleteFilter(AutocompleteFilter):

    def __init__(self, request, params, model, model_admin):
        if self.parameter_name is None:
            self.parameter_name = self.field_name
            if self.use_pk_exact:
                self.parameter_name += '__{}__exact'.format(self.field_pk)
        super(AutocompleteFilter, self).__init__(request, params, model, model_admin)

        if self.rel_model:
            model = self.rel_model
        remote_field = model._meta.get_field(self.field_name)
        if not isinstance(remote_field, ForeignKey) and not isinstance(remote_field, ManyToManyField):
            remote_field = model._meta.get_field('id')

        widget = AutocompleteSelect(remote_field,
                                    model_admin.admin_site,
                                    custom_url=self.get_autocomplete_url(request, model_admin), )
        form_field = self.get_form_field()
        field = form_field(
            queryset=self.get_queryset_for_field(model, self.field_name),
            widget=widget,
            required=False,
        )
        self._add_media(model_admin, widget)

        attrs = self.widget_attrs.copy()
        attrs['id'] = 'id-%s-dal-filter' % self.parameter_name
        if self.is_placeholder_title:
            attrs['data-Placeholder'] = self.title
        self.rendered_widget = field.widget.render(
            name=self.parameter_name,
            value=self.used_parameters.get(self.parameter_name, ''),
            attrs=attrs
        )

class OfferFilter(SelfAutocompleteFilter):
    title = _('Оффер')
    field_name = 'name'
    rel_model = Offer

    @staticmethod
    def get_queryset_for_field(model, name):
        return Offer.objects.all()

    def queryset(self, request, queryset):
        if self.value() and self.value().isdigit():
            return queryset.filter(id=int(self.value()))
        return queryset

    def get_autocomplete_url(self, request, model_admin):
        return reverse('admin:offer-search')
list_filter = (
        OfferFilter,)

Hi,
Im already using admin_auto_filters. It is working with that.
I think that i can solve only with django-autocomplete-light library.
Thanks.


Embeddable IPFS database?

Hi there, this project looks amazing! I've been looking for a rust IPFS implementation for a while, and was getting worried that rust-ifps was becoming stale. Since two weeks ago, it is officially no longer maintained.
Having said that, I was wondering if iroh will be usable as an embeddable solution. You've already registered a crate name, anyways!
My Usecase
I'm working on a Notion alternative / graph database / knowledge management system called Atomic-Server. It's designed to be highly decentralized, allowing users to re-use schema definitions from other users. However, as it uses HTTP for resolving these schema definitions, the system is reliant on the servers to stay online. Currently, all servers cache all schema definitions. But if a new server joins, and the original host is offline, the HTTP identifiers will not resolve. This is where IPFS comes in! I'd like schema definitions for Properties and Classes to be referred to by IPFS identifiers.  But I also want to prevent having any runtime dependencies. I want my users to run the entire application using one single binary. I guess you understand why I'd like to have a rust IPFS crate then! Currently, my implementation is using actix_web, although I've been considering switching to axum (like you are using).
What embeddable iroh might work
I'm not entirely sure how an embeddable version of iroh would work, but maybe something like this:
fn main() {
   let config = iroh::Config::default();
   // Starts a server, perhaps at some subdomain or a specific path
   let ipfs_instance = iroh::Server::start(config).await;
   // Allow users to write / read from the IPFS universe
   ipfs_instance::add("hello world");
}

Would love to hear your thoughts on this!

apologies for the delay @joepio, we're absolutely planning on supporting a use case like yours. I'm in the process of working up the required changes, and we should have an example that looks a lot like your code sketch above this month.
I'll leave this issue open, and let you know once we can do embedded iroh here!

That's great, thanks @b5! Let me know if I can help with this.

I am also interested.

Features and Usecase I am interested in
I am interested in building a desktop application which uses IPFS as a backend. The features I am especially interested in are DAG access, gossipsub support (high level, I don't want to care about the details) and storage. I want to be able to push JSON/etc into IPFS and access it via IPLD. IPNS would also be of interest.

I want the high level APIs : https://github.com/ipfs/js-ipfs/blob/master/docs/core-api/FILES.md


Fix typo for event trigger

Why:
Closes: Typo in docs

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[x] I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).

For content changes, you will also see an automatically generated comment with links directly to pages you've modified. The comment won't appear if your PR only edits files in the data directory.

[x] For content changes, I have completed the self-review checklist.

@dariocurr Thanks so much for opening a PR with this fix! I'll update the branch and get this merged once tests are passing 🍏


Enable incremental installation by default on iOS

Per discussion in https://github.com/FirebaseExtended/flutterfire/issues/349, we can improve build times for flutter create devs by enabling incremental installation in the template Podfile.
install! 'cocoapods',
   generate_multiple_pod_projects: true,
   incremental_installation: true

Benefits:

Subsequent builds are much faster when using plugins like cloud_firestore.

Drawbacks:

Requires CocoaPods 1.7.0 (if this is an issue we could use cocoapods-binary but then that would have to be installed as well)
Possibly slightly longer initial build times

/cc @jmagman

What's the advantage of the generate_multiple_pod_projects in terms of build time? I've seen nested xcprojects cause search path issues and weird build order problems where subprojects have to be re-built before the super projects, and assets in DerivedData getting out of sync.

What's the advantage of the generate_multiple_pod_projects in terms of build time? I've seen nested xcprojects cause search path issues and weird build order problems where subprojects have to be re-built before the super projects, and assets in DerivedData getting out of sync.

I just included that because the installation instructions told me to:
http://blog.cocoapods.org/CocoaPods-1.7.0-beta/

I can leave it out if you want, it doesn't seem to make a difference either way.

I can leave it out if you want, it doesn't seem to make a difference either way.

Leaving it out results in a build error:
    Analyzing dependencies
    [!] The installation option `incremental_installation` requires the option `generate_multiple_pod_projects` to also be enabled.

I can leave it out if you want, it doesn't seem to make a difference either way.

Leaving it out results in a build error:
    Analyzing dependencies
    [!] The installation option `incremental_installation` requires the option `generate_multiple_pod_projects` to also be enabled.

@collinjackson
I'm worried about this caveat:

Warning: Switching your project to use multiple .xcodeproj may result in some compiler errors if your pods have relied on importing headers using the quote syntax for its dependencies. For example #import "PDDebugger.h" will no longer work in a pod that depends on PonyDebugger. Instead, we highly suggest you update your headers to correctly import the framework and its associated header: #import <PonyDebugger/PDDebugger.h>. This is intentional since this feature is currently opt-in.

http://blog.cocoapods.org/CocoaPods-1.7.0-beta/
I suspect many pods use the project #import "PDDebugger.h instead of the correct system #import <PonyDebugger/PDDebugger.h> and in fact our own registration template did this up until https://github.com/flutter/flutter/pull/10259/files#diff-fb912d7008f6a340a5c4584a6ee1ae85L130


Exception when using ZfcUserDb Identity provider

I had a problem with this module when using default zend db identity provider
got an exception as Role with id 'xx' is not found. This happened after trying to login
by digging the code, I've come to this piece of code to be the culprit
found in ZfcUserZendDb provider, in getIdentityRoles method
it returns a list of role ids as found in the link table
but the ids are the integers and it seems it should be the actual role names as found in user_role table
so I created a module to overwrite this class and related factory and config key
what I'm doing is join the user_role table and return the list of actual user role_id(guest, user, admin etc.)
here is the change in the method, so you may check if this is really an issue and correct it in the future
public function getIdentityRoles()
    {
        $authService = $this->userService->getAuthService();

        if (! $authService->hasIdentity()) {
            return array($this->getDefaultRole());
        }

        // get roles associated with the logged in user
        $sql    = new Sql($this->adapter);
        $select = $sql->select()->from(array('a' => $this->linkTable));
        $select->join($this->roleTable, 'id = a.role_id', array('role_id'));
        $where  = new Where();

        $where->equalTo('a.user_id', $authService->getIdentity()->getId());

        $results = $sql->prepareStatementForSqlObject($select->where($where))->execute();
        $roles     = array();

        foreach ($results as $i) {
            $roles[] = $i['role_id'];
        }
        return $roles;
    }

Hi!
I've started with this plugin and I found the same problem. For me this code works!
public function getIdentityRoles()
    {
        $authService = $this->userService->getAuthService();

        if (! $authService->hasIdentity()) {
            return array($this->getDefaultRole());
        }

        // get roles associated with the logged in user
        $sql    = new Sql($this->adapter);
        $select = $sql->select()->from($this->tableName);
        $select->join($this->roleTable, 'id = '. $this->tableName .'.role_id');
        $where  = new Where();

        $where->equalTo($this->tableName .'.user_id', $authService->getIdentity()->getId());

        $results = $sql->prepareStatementForSqlObject($select->where($where))->execute();
        $roles     = array();
        foreach ($results as $i) {
            $roles[] = $i['roleId'];
        }

        return $roles;
    }

Hope to be usefull

Thanks @danitome24 worked great. I used your code for ZfcUserZendDb.php.  In addition to your change, I also had to modify
vendor/bjyoungblood/bjy-authorize/src/BjyAuthorize/Provider/Role/ZendDb.php
`public function getRoles()
{
/* @var $adapter \Zend\Db\Adapter\Adapter */
$adapter      = $this->serviceLocator->get($this->adapterName);
$tableGateway = new TableGateway($this->tableName, $adapter);
$sql          = new Select;
    $sql->from($this->tableName);

    $rowset = $tableGateway->selectWith($sql);
    $roles  = array();
    $roles2 = array();
    $count  = 1;

    // Pass One: Build each object
    foreach ($rowset as $row) {
        $roleId = $row[$this->roleIdFieldName];

        $roles[$roleId] = new Role($roleId, $row[$this->parentRoleFieldName]);
        $roles2[$count] = $roleId;
        $count++;
    }

    // Pass Two: Re-inject parent objects to preserve hierarchy
    /* @var $roleObj Role */
    foreach ($roles as $roleObj) {
        $parentRoleObj = $roleObj->getParent();

        if ($parentRoleObj && $parentRoleObj->getRoleId()) {

            $parent = $parentRoleObj->getRoleId();

            $parentRoleId = $roles2[(int)$parent];

            $roleObj->setParent($parentRoleId);
        }
    }

    return array_values($roles);
}`


Reducing precision doesn't update price scale width

Lightweight Charts Version: 3.1.5
Steps/code to reproduce:
series.applyOptions({
    priceFormat: {
        precision: 6,
        minMove: 0.000001,
    },
});

and after a while, run
series.applyOptions({
    priceFormat: {
        precision: 2,
        minMove: 0.01
    }
});

Actual behavior:
Price scale width doesn't adapt to new width.
Expected behavior:
Price scale width should adapt to new width
Screenshots:

CodeSandbox/JSFiddle/etc link:
Repo link https://github.com/SuperPenguin/lightweight-charts-example/tree/master/src/charts-button
Current workaround is to resize chart using applyOptions to fix price scale width

I believe it's done somewhere here...
I think that it's done to avoid "infinite loop" of changing price scale width from smaller to bigger and back: let's say we have a price scale with 100px width, then you move visible range for 1 bar to the history which might lead to recalculate the price range (due auto scaling), the new data might increase count of visible digits by 1 so now width of the price scale should be 120px but this forces to recalculate with of the pane which changes the visible range and hides the bar you just scrolled to, then the price scale width change back to 100px which leads changing visible range and here we have a loop 🙂 That's why we didn't change the width back to smaller one.
If you have any ideas how it could be fixed in other way and decreasing width as well - please let us know :)

Was this ever fixed? Im also applying this applyOptions  command dynamically but the chart won't update. I'm working vith version 3.3
Here's the full command. The chart doesn't respond.

@timocov Could we run the set axis width 2 times? Based on your example, on the first time it set the width to 100px. Then we check again if the new optimal width is bigger than 100px, then we set it to the new width, if not, just let it be

https://jsfiddle.net/em8hz9xd/


KAFKA-16822: Abstract consumer group to share functionality with share group (KIP-932)

Abstracted code for 2 classes ConsumerGroup and ConsumerGroupMember to AbstractGroup and GroupMember respectively. The new abstract classes are created to share common functionality with ShareGroup and ShareGroupMember which are being introduced with KIP-932.
The PR is majorly code refactoring from existing classes to abstract classes. Also created a new package called common where MemberState class is moved, in upcoming PRs will move common classes for Share and Consumer Group in common package itself.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@dajac @omkreddy @AndrewJSchofield Please review, we can merge post 3.8 branch cut.

@dajac @lianetm @AndrewJSchofield Can I please get a review again, have addressed the comments.

@dajac I have rebased the branch with latest changes. Note: This PR introduces modern package and abstract classes ModernGroup and ModernGroupMember.
I have limited changes in this PR, for efficient review and minmal conflicts with upstream. The next PR will move consumer and share package inside modern. Also couple of common classes from consumer (Assignment, TargetAssignmentBuilder, etc.) will be moved to modern package.

@apoorvmittal10 Thanks for the update and sorry for the delay. I left a few more comments for consideration.
Overall, I really wonder whether going with the abstract class (vs an interface) what the right choice. It seems to me that share and consumer groups do not share that much in the end. An interface could have made it too. Looking at the abstract class, I also believe that future group types (e.g. streams, connect) won't use it because they are not going to assign the same resources. However, keeping it is fine, I suppose.

Thanks for the review. The common functionality is more around the usage when it comes to computing target assignment, subscribe topic metadata, etc. Hence I prefer it to have Abstract class rather separate interface which was complicating things further.


Add DestroyRange interface to TiKV

Signed-off-by: MyonKeminta<EMAIL_ADDRESS>

@siddontang @zhangjinpeng1987 @BusyJay PTAL

It seems that if we do not include a Context in the request it might be a little difficult to implement on TiDB side

@MyonKeminta
what is context?

@siddontang kvrpcpb::Context, which exists in all kv request bodies.

In current design the procedure of a DestroyRange is as following:

Receive DestroyRange request
delete_files_in_range
Scan and delete all remaining keys in the range
Return the response
However when the range is extremely large, it may still take very long time to finish the step 3 above.
Should we keep on going to do it or schedule it and do it later?
If we schedule it and finish the request just after executing delete_files_in_range, we may need to persistent the task to disk, which make it more complicated to implement.

@MyonKeminta Please test how long it will take for step 3, don't assume it.

@MyonKeminta
Please add how are you going to test this feature. E.g, create a 1 TB table, drop it, and to see how long the data will be deleted, how to evaluate the effects.

I've tested dropping a table whose size is about 100+GB. Here are the steps.

Prepare a large table
Table generated by go-ycsb:
mysql> select count(*) from usertable;
+-----------+
| count(*)  |
+-----------+
| 568945951 |
+-----------+
1 row in set (32.32 sec)

Store size:

Run sysbench oltp script. Keep it running and record it's log.
(started at 17:02:50)

Drop the large table.
mysql> drop table usertable;
Query OK, 0 rows affected (1.12 sec)

mysql> select * from mysql.gc_delete_range;
+--------+------------+--------------------+--------------------+--------------------+
| job_id | element_id | start_key          | end_key            | ts                 |
+--------+------------+--------------------+--------------------+--------------------+
|    115 |         81 |<PHONE_NUMBER>00000051 |<PHONE_NUMBER>00000052 |<PHONE_NUMBER>51662668 |
+--------+------------+--------------------+--------------------+--------------------+
1 row in set (0.04 sec)

Timestamp:
$ pd-ctl -d tso<PHONE_NUMBER>51662668
system:  2018-09-05 17:04:23 +0800 CST
logic:  76

Wait for deleteRanges happens.
Metrics:

Store size:

Calculate the approximate space cleanup rate just after destroying range:
((140.1 + 149.2 + 136.6 + 140.8) - (14.5 + 7.7 + 8.8 + 8.8))/(132.1 + 141.5 + 126.9 + 133.3) * 100%
≈ 98.71%

TiKV's logs:
(tikv-0.log)
2018/09/05 09:20:17.553 INFO gc_worker.rs:258: destroying range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370
2018/09/05 09:20:19.649 INFO gc_worker.rs:290: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/05 09:20:48.326 INFO gc_worker.rs:306: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished cleaning up all

(tikv-1.log)
2018/09/05 09:20:07.976 INFO gc_worker.rs:258: destroying range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370
2018/09/05 09:20:07.988 INFO gc_worker.rs:290: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/05 09:20:08.109 INFO gc_worker.rs:306: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished cleaning up all

(tikv-2.log)
2018/09/05 09:20:06.973 INFO gc_worker.rs:258: destroying range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370
2018/09/05 09:20:06.996 INFO gc_worker.rs:290: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/05 09:20:07.976 INFO gc_worker.rs:306: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished cleaning up all

(tikv-3.log)
2018/09/05 09:20:08.065 INFO gc_worker.rs:258: destroying range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370
2018/09/05 09:20:17.192 INFO gc_worker.rs:290: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/05 09:20:17.537 INFO gc_worker.rs:306: destroy range start_key: t\200\000\000\000\000\000\000\377Q\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377R\000\000\000\000\000\000\000\370 finished cleaning up all

The time cost of destroy_range's execution varies. But we can see it took less than 10s to delete all files and less than 30s to scan and delete all remaining keys.
TiDB's log:
(tidb-0 is not gc leader)
(tidb-1.log)
2018/09/05 09:19:43.379 gc_worker.go:244: [info] [gc worker] 596a279ed480004 starts the whole job, safePoint:<PHONE_NUMBER>72206592
2018/09/05 09:19:43.379 gc_worker.go:502: [info] [gc worker] 596a279ed480004 start resolve locks, safePoint:<PHONE_NUMBER>72206592.
2018/09/05 09:20:06.922 gc_worker.go:574: [info] [gc worker] 596a279ed480004 finish resolve locks, safePoint:<PHONE_NUMBER>72206592, regions: 2665, total resolved: 0, cost time: 23.543050428s
2018/09/05 09:20:06.928 gc_worker.go:370: [info] [gc worker] 596a279ed480004 start delete 1 ranges
2018/09/05 09:20:48.379 gc_worker.go:387: [info] [gc worker] 596a279ed480004 finish delete 1 ranges, cost time: 41.450526154s
018/09/05 09:20:48.385 gc_worker.go:406: [info] [gc worker] 596a279ed480004 start re-delete 0 ranges
018/09/05 09:20:48.385 gc_worker.go:423: [info] [gc worker] 596a279ed480004 finish re-delete 0 ranges, cost time: 297ns
2018/09/05 09:22:28.430 gc_worker.go:730: [info] [gc worker] 596a279ed480004 start gc, concurrency 2, safePoint:<PHONE_NUMBER>72206592.
2018/09/05 09:29:02.244 gc_worker.go:751: [info] [gc worker] 596a279ed480004 finish gc, safePoint:<PHONE_NUMBER>72206592, successful regions: 2665, failed regions: 0, total cost time: 6m33.814440687s

In the test implementation, TiDB sends destroy-range request to all TiKVs and wait for response respectively. It took less than a minute in total to do DestroyRange on all 4 TiKVs.
Sysbench:
Unfortunately an bug of prevote happened while destroying range, making the sysbench's result of nonsense. Maybe we'll test again later.

can you show the gRPC QPS metrics?
so we can know the influence caused by delete range.

@siddontang delete range?

@siddontang In my previous test QPS is full of sysbench requests. DestroyRange request was sent exactly 4 times because there are exactly 4 TiKVs.

I tested it again with large table.
Note that the times in images is UTC+8 and those in logs is UTC time.
Test2
There's two large tables of the same size, so the store size is expected to drop by half.

It took about 20 seconds to delete the table in all 4 TiKVs.
The QPS shows a little drop during DestroyRange, but it's not confirmed to be caused by destroying range. It might be caused by other interference.
Part of sysbench's log:
[ 658s ] thds: 256 tps: 2169.01 qps: 43531.67 (r/w/o: 30439.12/8749.53/4343.02) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 660s ] thds: 256 tps: 2352.50 qps: 47041.49 (r/w/o: 32933.49/9402.50/4705.50) lat (ms,95%): 173.58 err/s: 0.00 reconn/s: 0.00
[ 662s ] thds: 256 tps: 2116.51 qps: 42428.60 (r/w/o: 29681.07/8510.02/4237.51) lat (ms,95%): 272.27 err/s: 0.00 reconn/s: 0.00
[ 664s ] thds: 256 tps: 2234.48 qps: 44749.09 (r/w/o: 31310.71/8968.42/4469.96) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 666s ] thds: 256 tps: 2298.40 qps: 45706.59 (r/w/o: 32030.16/9077.62/4598.81) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 668s ] thds: 256 tps: 2274.11 qps: 45567.27 (r/w/o: 31884.59/9130.95/4551.73) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 670s ] thds: 256 tps: 2322.51 qps: 46479.20 (r/w/o: 32559.64/9270.04/4649.52) lat (ms,95%): 215.44 err/s: 0.00 reconn/s: 0.00
[ 672s ] thds: 256 tps: 2272.77 qps: 45160.89 (r/w/o: 31574.78/9038.08/4548.04) lat (ms,95%): 189.93 err/s: 0.00 reconn/s: 0.00
[ 674s ] thds: 256 tps: 2198.70 qps: 44596.04 (r/w/o: 31203.33/8992.31/4400.40) lat (ms,95%): 207.82 err/s: 0.00 reconn/s: 0.00
[ 676s ] thds: 256 tps: 2268.01 qps: 44813.76 (r/w/o: 31426.68/8850.55/4536.53) lat (ms,95%): 193.38 err/s: 0.00 reconn/s: 0.00
[ 678s ] thds: 256 tps: 2187.36 qps: 43562.66 (r/w/o: 30485.52/8700.93/4376.22) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00
[ 680s ] thds: 256 tps: 2188.65 qps: 44260.04 (r/w/o: 30965.13/8914.11/4380.80) lat (ms,95%): 223.34 err/s: 0.00 reconn/s: 0.00
[ 682s ] thds: 256 tps: 2178.79 qps: 44067.82 (r/w/o: 30798.08/8909.65/4360.09) lat (ms,95%): 183.21 err/s: 0.00 reconn/s: 0.00
[ 684s ] thds: 256 tps: 2068.66 qps: 41180.27 (r/w/o: 28877.79/8162.65/4139.83) lat (ms,95%): 223.34 err/s: 0.00 reconn/s: 0.00
[ 686s ] thds: 256 tps: 2084.59 qps: 41105.75 (r/w/o: 28730.72/8202.35/4172.68) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 688s ] thds: 256 tps: 1755.00 qps: 35331.52 (r/w/o: 24716.52/7104.51/3510.50) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
[ 690s ] thds: 256 tps: 1935.89 qps: 39195.76 (r/w/o: 27476.93/7843.55/3875.28) lat (ms,95%): 223.34 err/s: 0.00 reconn/s: 0.00
[ 692s ] thds: 256 tps: 1903.06 qps: 37978.70 (r/w/o: 26565.34/7608.24/3805.12) lat (ms,95%): 240.02 err/s: 0.00 reconn/s: 0.00
[ 694s ] thds: 256 tps: 1761.35 qps: 35402.87 (r/w/o: 24766.33/7107.34/3529.20) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00
[ 696s ] thds: 256 tps: 444.04 qps: 7851.09 (r/w/o: 5584.32/1377.68/889.09) lat (ms,95%): 2120.76 err/s: 0.00 reconn/s: 0.00
[ 698s ] thds: 256 tps: 2045.89 qps: 41613.68 (r/w/o: 29122.87/8396.53/4094.27) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 700s ] thds: 256 tps: 1789.58 qps: 35604.52 (r/w/o: 24921.56/7101.80/3581.15) lat (ms,95%): 530.08 err/s: 0.00 reconn/s: 0.00
[ 702s ] thds: 256 tps: 2204.04 qps: 43813.83 (r/w/o: 30641.08/8769.67/4403.08) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00

TiDB and TiKV's logs:
(tidb-1.log)
2018/09/06 07:04:43.318 gc_worker.go:244: [info] [gc worker] 596a279ed480004 starts the whole job, safePoint:<PHONE_NUMBER>38231552
2018/09/06 07:04:43.318 gc_worker.go:502: [info] [gc worker] 596a279ed480004 start resolve locks, safePoint:<PHONE_NUMBER>38231552.
2018/09/06 07:06:16.601 gc_worker.go:574: [info] [gc worker] 596a279ed480004 finish resolve locks, safePoint:<PHONE_NUMBER>38231552, regions: 7929, total resolved: 0, cost time: 1m33.282656071s
2018/09/06 07:06:16.635 gc_worker.go:370: [info] [gc worker] 596a279ed480004 start delete 1 ranges
2018/09/06 07:06:38.341 gc_worker.go:387: [info] [gc worker] 596a279ed480004 finish delete 1 ranges, cost time: 21.705436474s
2018/09/06 07:06:38.344 gc_worker.go:406: [info] [gc worker] 596a279ed480004 start re-delete 0 ranges
2018/09/06 07:06:38.344 gc_worker.go:423: [info] [gc worker] 596a279ed480004 finish re-delete 0 ranges, cost time: 211ns
2018/09/06 07:08:18.351 gc_worker.go:730: [info] [gc worker] 596a279ed480004 start gc, concurrency 2, safePoint:<PHONE_NUMBER>38231552.

(tikv-0.log)
2018/09/06 07:06:30.582 INFO gc_worker.rs:259: destroying range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370
2018/09/06 07:06:30.647 INFO gc_worker.rs:291: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/06 07:06:33.514 INFO gc_worker.rs:307: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished cleaning up all
(tikv-1.log)
2018/09/06 07:06:16.688 INFO gc_worker.rs:259: destroying range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370
2018/09/06 07:06:21.074 INFO gc_worker.rs:291: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/06 07:06:25.519 INFO gc_worker.rs:307: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished cleaning up all
(tikv-2.log)
2018/09/06 07:06:33.544 INFO gc_worker.rs:259: destroying range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370
2018/09/06 07:06:33.598 INFO gc_worker.rs:291: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/06 07:06:38.213 INFO gc_worker.rs:307: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished cleaning up all
(tikv-3.log)
2018/09/06 07:06:25.470 INFO gc_worker.rs:259: destroying range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370
2018/09/06 07:06:25.508 INFO gc_worker.rs:291: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished deleting files in range
2018/09/06 07:06:30.557 INFO gc_worker.rs:307: destroy range start_key: t\200\000\000\000\000\000\000\377x\000\000\000\000\000\000\000\370, end_key: t\200\000\000\000\000\000\000\377y\000\000\000\000\000\000\000\370 finished cleaning up all

Test3
Seems to be interfered by something else, I tested again.

It took about 40 seconds to delete the table in all 4 TiKVs.
tidb:
2018/09/06 09:44:43.282 gc_worker.go:244: [info] [gc worker] 596a279ed480004 starts the whole job, safePoint:<PHONE_NUMBER>21111552
2018/09/06 09:44:43.282 gc_worker.go:502: [info] [gc worker] 596a279ed480004 start resolve locks, safePoint:<PHONE_NUMBER>21111552.
2018/09/06 09:45:45.757 gc_worker.go:574: [info] [gc worker] 596a279ed480004 finish resolve locks, safePoint:<PHONE_NUMBER>21111552, regions: 6752, total resolved: 0, cost time: 1m2.474641358s
2018/09/06 09:45:45.768 gc_worker.go:370: [info] [gc worker] 596a279ed480004 start delete 1 ranges
2018/09/06 09:46:28.440 gc_worker.go:387: [info] [gc worker] 596a279ed480004 finish delete 1 ranges, cost time: 42.671516051s
2018/09/06 09:46:28.441 gc_worker.go:406: [info] [gc worker] 596a279ed480004 start re-delete 0 ranges
2018/09/06 09:46:28.441 gc_worker.go:423: [info] [gc worker] 596a279ed480004 finish re-delete 0 ranges, cost time: 239ns
2018/09/06 09:48:08.458 gc_worker.go:730: [info] [gc worker] 596a279ed480004 start gc, concurrency 2, safePoint:<PHONE_NUMBER>21111552.
2018/09/06 09:49:53.127 gc_worker.go:751: [info] [gc worker] 596a279ed480004 finish gc, safePoint:<PHONE_NUMBER>21111552, successful regions: 6752, failed regions: 0, total cost time: 1m44.668958855s

Part of sysbench's log: (sysbench is running oltp script, started at 09:42:57)
[ 116s ] thds: 256 tps: 2296.03 qps: 45965.58 (r/w/o: 32203.89/9168.63/4593.06) lat (ms,95%): 231.53 err/s: 0.00 reconn/s: 0.00
[ 118s ] thds: 256 tps: 2315.36 qps: 46230.67 (r/w/o: 32358.52/9237.43/4634.73) lat (ms,95%): 223.34 err/s: 0.00 reconn/s: 0.00
[ 120s ] thds: 256 tps: 2309.98 qps: 45932.74 (r/w/o: 32161.32/9148.96/4622.47) lat (ms,95%): 231.53 err/s: 0.00 reconn/s: 0.00
[ 122s ] thds: 256 tps: 2312.86 qps: 46498.79 (r/w/o: 32538.60/9332.46/4627.73) lat (ms,95%): 215.44 err/s: 0.00 reconn/s: 0.00
[ 124s ] thds: 256 tps: 2189.77 qps: 44111.38 (r/w/o: 30841.26/8888.58/4381.53) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00
[ 126s ] thds: 256 tps: 2337.83 qps: 46401.21 (r/w/o: 32520.70/9203.85/4676.67) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 128s ] thds: 256 tps: 2184.36 qps: 43693.79 (r/w/o: 30570.60/8751.46/4371.73) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00
[ 130s ] thds: 256 tps: 2194.78 qps: 43601.57 (r/w/o: 30566.40/8643.60/4391.56) lat (ms,95%): 227.40 err/s: 0.00 reconn/s: 0.00
[ 132s ] thds: 256 tps: 2149.13 qps: 43510.13 (r/w/o: 30395.84/8815.03/4299.26) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 134s ] thds: 256 tps: 2241.18 qps: 44684.05 (r/w/o: 31291.98/8908.21/4483.86) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 136s ] thds: 256 tps: 2321.75 qps: 46584.05 (r/w/o: 32600.04/9335.51/4648.51) lat (ms,95%): 196.89 err/s: 0.00 reconn/s: 0.00
[ 138s ] thds: 256 tps: 2220.47 qps: 44433.87 (r/w/o: 31101.56/8893.87/4438.44) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00
[ 140s ] thds: 256 tps: 2354.55 qps: 46714.00 (r/w/o: 32746.71/9252.68/4714.61) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 142s ] thds: 256 tps: 2162.75 qps: 43527.06 (r/w/o: 30435.54/8762.52/4329.00) lat (ms,95%): 248.83 err/s: 0.00 reconn/s: 0.00
[ 144s ] thds: 256 tps: 2197.25 qps: 43690.59 (r/w/o: 30575.57/8718.02/4397.01) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 146s ] thds: 256 tps: 2114.96 qps: 42756.70 (r/w/o: 29925.44/8599.34/4231.92) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00
[ 148s ] thds: 256 tps: 2195.08 qps: 43736.67 (r/w/o: 30629.17/8714.33/4393.17) lat (ms,95%): 267.41 err/s: 0.00 reconn/s: 0.00
[ 150s ] thds: 256 tps: 2265.74 qps: 45218.28 (r/w/o: 31650.35/9035.46/4532.48) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
[ 152s ] thds: 256 tps: 2259.66 qps: 44944.14 (r/w/o: 31488.20/8937.14/4518.81) lat (ms,95%): 244.38 err/s: 0.00 reconn/s: 0.00
[ 154s ] thds: 256 tps: 2336.48 qps: 47109.58 (r/w/o: 32940.21/9492.42/4676.96) lat (ms,95%): 196.89 err/s: 0.00 reconn/s: 0.00
[ 156s ] thds: 256 tps: 2226.58 qps: 44590.54 (r/w/o: 31212.58/8922.31/4455.65) lat (ms,95%): 215.44 err/s: 0.00 reconn/s: 0.00
[ 158s ] thds: 256 tps: 2295.51 qps: 45518.77 (r/w/o: 31883.69/9041.55/4593.53) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 160s ] thds: 256 tps: 2128.96 qps: 42574.25 (r/w/o: 29823.47/8492.85/4257.92) lat (ms,95%): 253.35 err/s: 0.00 reconn/s: 0.00
[ 162s ] thds: 256 tps: 2016.30 qps: 40736.56 (r/w/o: 28471.74/8227.20/4037.61) lat (ms,95%): 248.83 err/s: 0.00 reconn/s: 0.00
[ 164s ] thds: 256 tps: 2059.70 qps: 41203.05 (r/w/o: 28841.34/8240.31/4121.40) lat (ms,95%): 297.92 err/s: 0.00 reconn/s: 0.00
[ 166s ] thds: 256 tps: 2135.98 qps: 42447.01 (r/w/o: 29715.66/8457.39/4273.96) lat (ms,95%): 272.27 err/s: 0.00 reconn/s: 0.00
[ 168s ] thds: 256 tps: 2328.63 qps: 46398.60 (r/w/o: 32502.31/9236.03/4660.26) lat (ms,95%): 196.89 err/s: 0.00 reconn/s: 0.00
[ 170s ] thds: 256 tps: 2225.55 qps: 44876.10 (r/w/o: 31393.77/9028.22/4454.11) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 172s ] thds: 256 tps: 2250.82 qps: 44533.93 (r/w/o: 31231.51/8797.77/4504.65) lat (ms,95%): 292.60 err/s: 0.00 reconn/s: 0.00
[ 174s ] thds: 256 tps: 2195.70 qps: 43862.58 (r/w/o: 30677.86/8790.82/4393.91) lat (ms,95%): 267.41 err/s: 0.00 reconn/s: 0.00
[ 176s ] thds: 256 tps: 2240.84 qps: 45312.16 (r/w/o: 31729.66/9099.83/4482.67) lat (ms,95%): 196.89 err/s: 0.00 reconn/s: 0.00
[ 178s ] thds: 256 tps: 2100.02 qps: 41944.90 (r/w/o: 29335.28/8408.08/4201.54) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 180s ] thds: 256 tps: 2234.92 qps: 44728.48 (r/w/o: 31290.93/8966.69/4470.85) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 182s ] thds: 256 tps: 2155.03 qps: 43117.13 (r/w/o: 30197.94/8606.63/4312.56) lat (ms,95%): 331.91 err/s: 0.00 reconn/s: 0.00
[ 184s ] thds: 256 tps: 2067.97 qps: 41493.35 (r/w/o: 29026.54/8327.37/4139.43) lat (ms,95%): 244.38 err/s: 0.00 reconn/s: 0.00
[ 186s ] thds: 256 tps: 2131.22 qps: 42337.37 (r/w/o: 29691.55/8381.39/4264.43) lat (ms,95%): 320.17 err/s: 0.00 reconn/s: 0.00
[ 188s ] thds: 256 tps: 2200.12 qps: 43673.35 (r/w/o: 30503.62/8768.48/4401.24) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 190s ] thds: 256 tps: 2030.48 qps: 40909.68 (r/w/o: 28633.28/8214.94/4061.47) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 192s ] thds: 256 tps: 1974.76 qps: 39439.74 (r/w/o: 27667.66/7819.56/3952.52) lat (ms,95%): 277.21 err/s: 0.00 reconn/s: 0.00
[ 194s ] thds: 256 tps: 2332.74 qps: 46580.28 (r/w/o: 32608.35/9305.45/4666.48) lat (ms,95%): 193.38 err/s: 0.00 reconn/s: 0.00
[ 196s ] thds: 256 tps: 2109.92 qps: 41997.44 (r/w/o: 29406.40/8370.70/4220.34) lat (ms,95%): 297.92 err/s: 0.00 reconn/s: 0.00
[ 198s ] thds: 256 tps: 2321.90 qps: 46687.00 (r/w/o: 32638.09/9403.11/4645.80) lat (ms,95%): 173.58 err/s: 0.00 reconn/s: 0.00
[ 200s ] thds: 256 tps: 2232.12 qps: 44668.33 (r/w/o: 31265.13/8942.47/4460.73) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 202s ] thds: 256 tps: 2216.03 qps: 44559.50 (r/w/o: 31181.85/8938.59/4439.05) lat (ms,95%): 248.83 err/s: 0.00 reconn/s: 0.00
[ 204s ] thds: 256 tps: 1934.73 qps: 38592.12 (r/w/o: 27025.23/7695.92/3870.96) lat (ms,95%): 356.70 err/s: 0.00 reconn/s: 0.00
[ 206s ] thds: 256 tps: 2408.55 qps: 47780.09 (r/w/o: 33539.76/9422.21/4818.11) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 208s ] thds: 256 tps: 2092.32 qps: 42201.04 (r/w/o: 29440.57/8573.33/4187.15) lat (ms,95%): 287.38 err/s: 0.00 reconn/s: 0.00
[ 210s ] thds: 256 tps: 1978.75 qps: 39802.39 (r/w/o: 27908.92/7932.98/3960.49) lat (ms,95%): 272.27 err/s: 0.00 reconn/s: 0.00
[ 212s ] thds: 256 tps: 2168.96 qps: 43080.25 (r/w/o: 30191.48/8549.85/4338.92) lat (ms,95%): 219.36 err/s: 0.00 reconn/s: 0.00
[ 214s ] thds: 256 tps: 2263.44 qps: 45147.73 (r/w/o: 31540.11/9077.74/4529.87) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00
[ 216s ] thds: 256 tps: 1990.81 qps: 39793.21 (r/w/o: 27903.36/7908.23/3981.62) lat (ms,95%): 320.17 err/s: 0.00 reconn/s: 0.00
[ 218s ] thds: 256 tps: 2108.46 qps: 42164.13 (r/w/o: 29474.40/8468.82/4220.91) lat (ms,95%): 262.64 err/s: 0.00 reconn/s: 0.00
[ 220s ] thds: 256 tps: 2314.76 qps: 46500.75 (r/w/o: 32560.68/9307.05/4633.02) lat (ms,95%): 196.89 err/s: 0.00 reconn/s: 0.00
[ 222s ] thds: 256 tps: 2087.53 qps: 41906.12 (r/w/o: 29305.93/8423.62/4176.56) lat (ms,95%): 248.83 err/s: 0.00 reconn/s: 0.00
[ 224s ] thds: 256 tps: 2157.02 qps: 42466.84 (r/w/o: 29745.74/8406.07/4315.03) lat (ms,95%): 308.84 err/s: 0.00 reconn/s: 0.00
[ 226s ] thds: 256 tps: 2355.76 qps: 47377.72 (r/w/o: 33170.15/9495.05/4712.52) lat (ms,95%): 204.11 err/s: 0.00 reconn/s: 0.00
[ 228s ] thds: 256 tps: 2247.07 qps: 44913.88 (r/w/o: 31470.97/8944.27/4498.64) lat (ms,95%): 211.60 err/s: 0.00 reconn/s: 0.00
[ 230s ] thds: 256 tps: 2165.84 qps: 43628.22 (r/w/o: 30485.72/8808.82/4333.68) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00
[ 232s ] thds: 256 tps: 2176.83 qps: 43436.59 (r/w/o: 30409.61/8675.32/4351.66) lat (ms,95%): 257.95 err/s: 0.00 reconn/s: 0.00
[ 234s ] thds: 256 tps: 2216.52 qps: 44337.39 (r/w/o: 31072.77/8826.58/4438.04) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00
[ 236s ] thds: 256 tps: 2189.93 qps: 43702.70 (r/w/o: 30572.09/8747.24/4383.37) lat (ms,95%): 244.38 err/s: 0.00 reconn/s: 0.00
[ 238s ] thds: 256 tps: 2297.40 qps: 46045.53 (r/w/o: 32197.12/9252.61/4595.80) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 240s ] thds: 256 tps: 2333.48 qps: 46520.06 (r/w/o: 32626.69/9224.91/4668.46) lat (ms,95%): 207.82 err/s: 0.00 reconn/s: 0.00
[ 242s ] thds: 256 tps: 2157.95 qps: 43404.09 (r/w/o: 30338.37/8747.32/4318.41) lat (ms,95%): 248.83 err/s: 0.00 reconn/s: 0.00
[ 244s ] thds: 256 tps: 2298.14 qps: 45943.81 (r/w/o: 32163.46/9180.06/4600.28) lat (ms,95%): 200.47 err/s: 0.00 reconn/s: 0.00
[ 246s ] thds: 256 tps: 2270.88 qps: 45132.21 (r/w/o: 31594.89/8992.04/4545.27) lat (ms,95%): 235.74 err/s: 0.00 reconn/s: 0.00

QPS keeps stable during DestroyRange.

@zhangjinpeng1987 @BusyJay @siddontang PTAL

@BusyJay @siddontang PTAL

PTAL @CaitinChen

@CaitinChen PTAL again thanks!


Error reading concept in Tesla Q10 2023 July 24th

Hi, I just found a bug with this document:
https://www.sec.gov/Archives/edgar/data/1318605/000095017023033872/0000950170-23-033872-xbrl.zip
The system finds all kind of HREF and the keyConceptMap contains ~20k of them.
But if you put a breakpoint with the condition concept == null in DiscoverableTaxonomySet:462 you will see which href makes it fail.
Maybe it could be enough to just ignore with a try-catch and log the href causing the error, not sure.

Thanks for raising this issue. The core issue seems to be that the XBRL
imports the ecd sub taxonomy but does not include the ecd taxonomy that it
depends on. This seems to be a new taxonomy for 2023. I have committed a
fix to forcefully import the ecd taxonomy when the ecd sub taxonomy is
imported. The logic already has defensive measures in place to not revisit
a taxonomy multiple times. Treat this as a short-term fix but it does
resolve the issue you are running into. Using a try-catch to handle the
case when the concept is null is ok but it will make the XBRL incomplete.
On Wed, Aug 2, 2023 at 11:14 AM gmconte @.***> wrote:

Hi, I just found a bug with this document:
https://www.sec.gov/Archives/edgar/data/1318605/000095017023033872/0000950170-23-033872-xbrl.zip
The system finds all kind of HREF and the keyConceptMap contains ~20k of
them.
But if you put a breakpoint with the condition concept == null in
DiscoverableTaxonomySet:462 you will see which href makes it fail.
Maybe it could be enough to just ignore with a try-catch and log the href
causing the error, not sure.
—
Reply to this email directly, view it on GitHub
https://github.com/ammasjk/xbrlj/issues/3, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQ5U2XG546K6OX7UY4OE2TXTKKI3ANCNFSM6AAAAAA3BUX5LU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thanks for fixing it so quickly. it works well now!


Section Based Audience Placements

This is showing fallback behavior for sections not mapped:

Otherwise this will be empty until the appropriate ad units in Mindful have things trafficked against them.

 Add "Recommended" content below Leaders on Article Pages


My mother still cannot use it

Please fix this!

Hmm, I think it needs NoOS version N0, maybe she has the N-1


Used MSRNeutronicsFluidCoupling syntax

Closes #410

Job VTB Documentation on 83aa68e wanted to post the following:
View the site here
This comment will be updated on new commits.

Fails tests due to a different time step history. See https://github.com/idaholab/moose/pull/27257 for when the time step history started to be tougher to keep being the same

Doco failure is due to the use of !include in the input file.
we already merged a fix in moose, but something doco-related is actually split-off from moose now (moose-pyhit? @milljm knows) so it's not updated

Thanks, the documentation failures make sense and I think I've fixed them now. I didn't see anything about !include but I could be blind. The failures were because documentation was trying to list now-nonexistent blocks in the input file. I'll look into the diff.

oh ok maybe i misdiagnosed the doco failure

I'm running the tests locally with VTB's current BC (9674843ae7bc24d3ea9ae86bcb09fb526c0fad9b), and I'm getting segmentation faults. No stop triggered in LLDB with dbg, so I'm unsure what to do next. It seems to occur only for MSFR inputs with fluids, after the initial fluids residual evaluation. I see it even on tests where I did not use my new syntax, like msr/msfr/plant/steady.core_fluids_only. I'm looking into it.

Tried it on my laptop too. Same result.

@GiudGiud Do you mind trying testing it on your machine when you get a chance?

will take a me a bit.
one machine is locked out, the other one is hosed, and the last is a personal one and I dont install BC on it. I ll HPC this

What I've tried:

Mac Pro, VTB BC version : segfault
MacBook Pro, VTB BC version : segfault
MacBook Pro, devel BC version: segfault
current HPC binary: no segfault (fail due to other reasons)

Versions:

VTB BC version is 9674843ae7bc24d3ea9ae86bcb09fb526c0fad9b (July 17)
current HPC BC version is 5bf7cd8 (June 28)
devel BC version is d938bde4a40e46d6bd678c5f07c6b1139181f968 (Aug 8)

I'll try building VTB BC version on HPC.

Updated list in previous comment: no failure with BC I compiled on HPC, just on Macs.

BC is running fine for me on my mac too. I think this might be tied to my post in dev-ops in #moose.
anyway, I m updating the submodules and the MSFR failures. This should be good to go after

BC is running fine for me on my mac too

Thanks for checking.  The rest of the stack will be ready.
imo the failure is the thing I mentioned early still but happy to be proven wrong

Yeah I'll push up the doc fix now.

imo the failure is the thing I mentioned early

Which failure are you talking about? doc? Or diffs? Or segfault?
If diffs, I guess you mean

Fails tests due to a different time step history. See https://github.com/idaholab/moose/pull/27257 for when the time step history started to be tougher to keep being the same

Which failure are you talking about? doc? Or diffs? Or segfault?

I mean the doco failure

Ah ok, yep, I believe you are right about the doc. I had tested locally and after fixing the doc errors I mentioned, it built fine, but I guess a more recent MOOSE (environment? since there's no executable in VTB?) was used locally or something.

Thanks for doing all of the support work!


why number of classes are not the same in train and test?

I used to believe in k-way-n-shot few-shot learning, k and n (number of classes and samples from each class respectively) must be the same in train and test phases. But you uses different numbers in the train and test phase  (60 for train and 5 for test):
parser.add_argument('--dataset')
parser.add_argument('--distance', default='l2')
parser.add_argument('--n-train', default=1, type=int)
parser.add_argument('--n-test', default=1, type=int)
parser.add_argument('--k-train', default=60, type=int)
parser.add_argument('--k-test', default=5, type=int)
parser.add_argument('--q-train', default=5, type=int)
parser.add_argument('--q-test', default=1, type=int)

Are we allowed to do so?

you can see the article“https://arxiv.org/pdf/1703.05175.pdf”，
Section 2.6，it said：

Episode composition A straightforward way to construct episodes, used in Vinyals et al. [29] and
Ravi and Larochelle [22], is to choose Nc classes and NS support points per class in order to match
the expected situation at test-time. That is, if we expect at test-time to perform 5-way classification
and 1-shot learning, then training episodes could be comprised of Nc = 5, NS = 1. We have found,
however, that it can be extremely beneficial to train with a higher Nc, or “way”, than will be used
at test-time. In our experiments, we tune the training Nc on a held-out validation set. Another
consideration is whether to match NS, or “shot”, at train and test-time. For prototypical networks,
we found that it is usually best to train and test with the same “shot” number.
I also don't understand the principle。。


Check mlbench works on Google Cloud

Everyhing works, installation docs updated accordingly

nice! did you commit the installation docs?

Yes, here: https://github.com/mlbench/mlbench/blob/refactor/controlflow/docs/installation.rst
Note: ReadTheDocs formatting looks a lot nicer, a large part of the guide is how to host your own image in googles docker registry, but Note's are not formatted nicely with github's .rst parser, so the guide for a default install is less than 50% of all the instructions there. I.e. if you look at it on github, it looks way more complicated at a first glance than it actually is.


how can I capture a photo with gpuimage in Swift?

when I use gpuimage in Swift,I want to capture a photo with code like this:`
        stillcamera.capturePhotoAsImageProcessedUpToFilter(GPUImageSketchFilter()) { (processedImage, error) in
        var paths = NSSearchPathForDirectoriesInDomains(.DocumentDirectory,.UserDomainMask, true)
        let documentsDirectory = paths[0]
        if let dataForJPEGFile = UIImageJPEGRepresentation(processedImage, 0.8){
            dataForJPEGFile.writeToFile(documentsDirectory, atomically: true)
        }
    }

`
but it is crash，because the "processedImage" is always nil.I try to fix it many times,but it still crash.Please HELP

I did it using different calls. For example:
let documentsDir = try FileManager.default.url(for:.documentDirectory, in:.userDomainMask, appropriateFor:nil, create:true)
let url = URL(string:"savedImage.png", relativeTo:documentsDir)!
filter?.saveNextFrameToURL(url, format:.png)
DispatchQueue.main.asyncAfter(deadline: .now() + 0.2) {
let image = UIImage(contentsOfFile: url.path)
UIImageWriteToSavedPhotosAlbum(image!, nil, nil, nil)
}
Where 'filter' is the GPUImage filter that is active in your processing chain (the Sketch filter in your case), and the code in the DispatchQueue section saves the image to the Photos album so that you can see it (which doesn't always work without a little delay in there).
Note that you have to have a filter chain set up somewhere, i.e. you need code such as:
camera! --> sketchFilter! --> renderView!
Which tells the GPU to pass data from the camera to the Sketch Filter and then to the RenderView for display.
Your code looks like it is passing in a new instance of a SketchFilter object so it will not be part of any processing chain. You should probably do it something like this:
let sketchFilter = SketchFilter()
stillcamera.addTarget(sketchFilter)
stillcamera.capturePhotoAsImageProcessedUpToFilter(sketchFilter){...}
Also, I see that you are using GPUImageSketchFilter, which is the Objective-C version. Have you tried using the native Swift version of GPUImage (GPUImage2)?


File explorer widget needs confirm when renaming to existing file

From<EMAIL_ADDRESS>on 2011-09-15T15:15:51Z
What steps will reproduce the problem?

Right click a file in the file explorer, and rename it to the same name as another file in the same directory 2. 3. What is the expected output? What do you see instead? It would be nice if some confirmation dialog appeared in this situation, instead of the old file being obliviously overwritten. What version of the product are you using? On what operating system? 2.1.0beta1, Arch Linux x86_64

Please provide any additional information below
.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=759

From pierre.raybaut on 2011-09-15T13:32:25Z
Status: Accepted
Labels: Milestone-Release2.1

From pierre.raybaut on 2011-09-24T06:24:48Z
This issue was closed by revision 6b6e9ac59435 .
Status: Fixed


QXcbConnection: Could not connect to display

Which version of PhantomJS are you using? Tip: run phantomjs --version.
2.1.1
What steps will reproduce the problem?

Take a working javascript file (e.g. rasterize.js)
Call the file from a script file (e.g. executable file, #!/bin/sh at the start)
Now execute the script file as a cron job

Which operating system are you using?
Ubuntu 16.04 LTS
Did you use binary PhantomJS or did you compile it from source?
Binary - installed it as part of Ubuntu (using apt).
Please provide any additional information below.
This is very similar to https://github.com/ariya/phantomjs/issues/14240, but I am using the stock version of PhantomJS (with Ubuntu). Below is the output from running the cron job (which calls the script file, to generate a pdf file once a day) ...

QXcbConnection: Could not connect to display
PhantomJS has crashed. Please read the bug reporting guide at
http://phantomjs.org/bug-reporting.html and file a bug report.
Aborted (core dumped)

Thanks!

Please check your environment variable QT_QPA_PLATFORM. It must be empty.

Yep, it is - in both cases. Does this need to be manually forced for some reason?
Thanks!

I would send a patch to reset all the troublesome environment variables before initializing Qt ... if I could find a list of them anywhere.
But it sounds like this isn't actually the problem?

It doesn't sound like it, but I could definitely be wrong.

Trying different things, no luck. Is there a setting of QT_QPA_PLATFORM that you believe may help?
Thanks!

Hi,
Having same issue here.
Working with 1.9 on my dev machine, works fine.
But on the live server I can't even download 1.9.x so I'm stuck now.
Where can I find this settings of QT? How to get there. So I can check that on my side.
Thanks!

The offscreen platform is a usable workaround for me with the stock Ubuntu package.  This works for me:
QT_QPA_PLATFORM=offscreen phantomjs rasterize.js 2i8zaNg04d9B41Zir2kT3J/output.html  2i8zaNg04d9B41Zir2kT3J.png

can confirm export QT_QPA_PLATFORM=offscreen before selenium scripts work's well.

We finally got things working by downloading the binary at  https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-2.1.1-linux-x86_64.tar.bz2 and extracting the phantomjs to /usr/bin

I had hard times with ubuntu 16.04 they basically distribute half finished system with lots of broken packages.

I'm running on 16.04 too, but the problem with the repo's is that they deliver with x11, which fails. So with the binary I don't have that issue and it works perfectly now.

Works here now also - thanks!!!

Debian/Ubuntu has a modified version of PhantomJS that can work headlessly, hence the problem with QXcb. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817277 for details.
Unfortunately, this is not something that we (=PhantomJS team) can fix.

@ricohumme Can you provide the steps (commands) to install it? I tried:
export PHANTOM_JS_VERSION=2.1.1
wget "https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-$PHANTOM_JS_VERSION-linux-x86_64.tar.bz2"
tar xvfj "./phantomjs-$PHANTOM_JS_VERSION-linux-x86_64.tar.bz2"
ln -sf "./phantomjs-$PHANTOM_JS_VERSION-linux-x86_64/bin/phantomjs" "/usr/bin"

but still couldn't get it working

@3zzy the steps I used are as follows:
wget https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-2.1.1-linux-x86_64.tar.bz2
bzip2 -d phantomjs-2.1.1-linux-x86_64.tar.bz2
tar -xvf phantomjs-2.1.1-linux-x86_64.tar
cp phantomjs-2.1.1-linux-x86_64/bin/phantomjs /usr/bin/phantomjs
Does this help your case?

Thanks for help, solution above works well :)

I'm the same error but in Odoo

xvfb-run worked best for me, from Ariya's link posted 8/2016.
xvfb is "providing an unobtrusive way to run applications that don’t really need an X server but insist on having one anyway."

@jglogan Thank you for solution with QT_QPA_PLATFORM=offscreen. It let me run phantomjs itself, but it was failing for me with EOFError: end of file reached message on certain pages.
After some experiments with different platforms I found out that it works like a charm with QT_QPA_PLATFORM=minimal.
Hope this will help someone.

Thanks a lot, guys! QT_QPA_PLATFORM=offscreen works great on Debian 8 jessie amd64 with PhantomJS 2.1.1
# QT_QPA_PLATFORM=offscreen phantomjs --version
2.1.1

Debian/Ubuntu has a modified version of PhantomJS that can work headlessly, hence the problem with QXcb. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817277 for details.

This is quite the opposite:

Unfortunately it can not be fixed in Debian. To achieve headless-ness
upstream statically link with customised QT + Webkit. We don't want to ship
forks of those projects. It would be great to eventually convince upstream to
use standard libraries.

There is also a suggestion to use xvfb-run, which is right.

Every time I try to plot anything with RStudio Cloud using the webshot package I obtain an error. An example:
#install webshot
library(webshot)
webshot::install_phantomjs()
# Make the graph
my_graph=wordcloud2(demoFreq, size=1.5)
# save it in html
library("htmlwidgets")
saveWidget(my_graph,"tmp.html",selfcontained = F)
# and in png
webshot("tmp.html","fig_1.png", delay =5, vwidth = 480, vheight=480)

The error says:
QXcbConnection: Could not connect to display :0
PhantomJS has crashed. Please read the bug reporting guide at
<http://phantomjs.org/bug-reporting.html> and file a bug report.
Error in webshot("tmp.html", "fig_1.png", delay = 5, vwidth = 480, vheight = 480) :
  webshot.js returned failure value: -6

Any thoughts?


DBZ-1773 Process TINYINT(1) as number

https://issues.redhat.com/browse/DBZ-1773

Test failure looks related.

@gunnarmorling Fixed, looks like another JDBC driver quirk

@jpechane, how does this impact BOOLEAN columns? Will there values be exported as 0/1 now instead of false/true?

@gunnarmorling There are alread exported as 0/1, see https://issues.redhat.com/browse/DBZ-1074

Ah, yes. Remembering now. It seems then the docs need an update, as they claim, as they claim that boolean columns would be exported as BOOLEAN field.

@gunnarmorling I don't thinks that's that easy, it is sometimes BOOLEAN - when read from binlog and sometimes INT16 - when read from snapshot so I'd rather handle it in a separate PR

@gunnarmorling https://issues.redhat.com/browse/DBZ-1801

Applied, thanks!


Sensible alias

Heh. I got so used to my lam snippet that I forgot that that macro was difficult to type! Thanks!


Problem with a huge amount of users

I dont know if it is a bug or not, but im testing this package with a huge amount of users (100K) and when i tried to open the roles Dashboard it crashes, even increasing the memory limit to 1GB and the execution time to 300 seconds
When i check the logs, i see there are as many queries to the database as users, so with 100K users, i should get 100K queries
Am i doing something wrong?

Optimization is definitely needed the handle that amount of data across the wire as well as on render. The package can handle that amount of users but I would think the management GUI might not as it currently stands.

Related to issue: https://github.com/jeremykenedy/laravel-roles/issues/175

Closing at this seems to be solved, if its still an issue let me know and I will re-open.


Call invite when app is killed

My issue is that when caller send the call invite and if callee had already killed the app then it is not triggering the callback. Can you guide me on how can I notify callee when call notification received when app is killed?
Thanks

not support it. maybe you can use FCM


Scheduled Jobs not running

I have installed Seat-Groups and I have a few groups setup, I've noticed that I need to manually go to the about tab and press the "SeAT Groups Users Update" button in order to have users placed into appropriate groups.
I have scheduled tasks to do this automatically, however I'm not receiving any updates. I'm not sure if I set up something incorrectly.

If there's more information needed please let me know.

Wild guess, your workers are not running. Check the Horizon Dashboard and check the status. If contrairy to my guess horizon is running, check the error section and see for any seat-groups error

I had an error, but it was only when I manually run the group update. I have deleted the user triggering the error. There were no errors during the time when the job would normally run.
My workers are running also

You setup the schedule to only run every hrs so that might be a reason. If not check with core as the cain does simply the same as the button you press. If the button works the job works.


On utilizing current thread with ThreadPool

I'd like to utilize current thread while using a ThreadPool, how shall I do that? Consider this example:
let do_some_work = ...;

let output = ThreadPoolBuilder::new()
    // ...
    .build()
    .unwrap()
    .install(|| do_some_work());

This code will block main thread until do_some_work is completed. But the problem is that the execution is performed in newly created pool without utilizing current running thread (it just waits for result).
One may think about overriding spawn_handler with using the current thread instead of first thread spawn:
let do_some_work = ...;

let (tx, rx) = mpsc::sync_channel(1);
let tx = Mutex::new(Some(tx));

let (tx_res, rx_res) = mpsc::sync_channel(1);

ThreadPoolBuilder::new()
    .spawn_handler(|t| {
        // Steal the work from the pool to run it on main thread
        if let Some(tx) = tx.lock().unwrap().take() {
            tx.send(t);
            return Ok(());
        }

        thread::spawn(move || t.run());
        Ok(())
    })
    // ...
    .build()
    .unwrap()
    .spawn(move || {
        let output = do_some_work();
        tx_res.send(output);
    });

let t = rx.try_recv().unwrap();
t.run();

let output = rx_res.recv().unwrap();

Which is great and works for do_some_work: 'static && do_some_work::Output: 'static. But these are actually redundant requirements for this particular case (i.e do_some_work overlives ThreadPool).
Probably related:

https://github.com/rayon-rs/rayon/issues/547
https://github.com/rayon-rs/rayon/issues/650
https://github.com/rayon-rs/rayon/issues/688
https://github.com/rayon-rs/rayon/issues/781

Huh, that's pretty clever! I will caution one caveat that the current thread must not be a part of a pool already, or else t.run() will fail an assertion when it tries to set its thread-local WorkerThread pointer.

But the problem is that the execution is performed in newly created pool without utilizing current running thread (it just waits for result).

I generally wouldn't worry about that though -- it should sleep with no overhead, apart from the memory use of the thread stack. Is there something that makes this more of a concern for you?

Which is great and works for do_some_work: 'static && do_some_work::Output: 'static. But these are actually redundant requirements for this particular case (i.e do_some_work overlives ThreadPool).

That's a requirement of spawn, and the usual fix is to use scope or in_place_scope, but I think that won't help your case. Scopes are blocking to enforce their lifetime, and while you could do your sneaky t.run() within, it would never be allowed to return because the scope would be holding the pool open too.

apart from the memory use of the thread stack. Is there something that makes this more of a concern for you?

Yeah, exactly. The real example actually utilizes an external pool (i.e just sends ThreadBuilder over channel at spawn_handler) and ThreadPoolBuilder is created quite frequently. Besides, I set a fixed core per each thread (sched_setaffinity) so main thread in that case just wastes entire core.
Wouldn't it be possible to link newly created ThreadPool lifetime to some kind spawn_scoped function?

How would you do that, when there is no lifetime parameter on ThreadPool?
Note that the problem is not really about keeping the pool alive, but rather how to ensure that it executes the spawn while its borrows are still alive. When the spawn is 'static we don't have to worry about it, just get around to it eventually. But if the spawn is tied to some local lifetime 'a, we have to block on that lifetime somehow.
The scope API does this with a callback, blocking before it returns. Once upon a time, the standard library tried to have thread::scoped with a JoinGuard, but that was found to be unsound, described here and here.

Yeah, I was thinking about API similar to JoinGuard, that's an interesting case, thanks for links. Tried to think about other ways but it seems either vulnerable to the JoinGuard issue or need to block similarly to install.
Moreover I'm not sure it's even possible to get it around for a generic case (i.e fn in_pool<R: Send>(f: impl FnOnce() -> R + Send) -> R { /* build & run thread pool there */ }) with unsafe user code if there's some kind of ThreadPool::finish. Because there's no way to transmute R: 'a -> R: 'static.


GEODE-9968: Fix new attrs in PdxSerializable

Solved addition of attributes for previously defined PdxSerializable
implementations, which was not working before.
Added a new IT to verify that it's possible to add a new attribute
under all scenarios.

Closing this PR as the fix is already covered in GEODE-10276


Add flexjobs

Added FlexJobs to list

@ecmeeker I actually got this in a previous PR, but I'm going to take yours too, I like the description better. Thanks for the contribution :)


Prohibitively slow render performance with large select elements

I've found that the render performance of this library tends to be prohibitively slow for select elements with large numbers of options. From my tests, the "setSelected" and "setDisabled" functions contribute to over 90% of the render time.
Current tests show that rendering takes 40ms per select tag on average, but often takes 250ms+ to render when using larger select elements (196 options for a country dialog).

Just a question about this issue, why this awesome from @pembo13 hasn't been integrated into the master, I tried it and it worked very well on my test, saved a lot of loading time !! Still not enough but good enough for the first 2 selects used on a single page.
I am loading more than 10 selects of 1600 items on one page, We should think about something lighter :)

+1

@cifren It was implemented...back in January of 2014.

Sorry, maybe I am wrong but I tried to find this in the master branch source and nothing than I could see was there. I had to change the code with the one given above and it changed completely the behaviour, not enough but faster.
Anyway, I am sorry I went to the enemy... I used Select2... But thanks for your work and the sharing of this tool :)

@cifren https://github.com/silviomoreto/bootstrap-select/blob/master/js/bootstrap-select.js#L746-L758

Please try v1.7.0-rc2 and report back.

@caseyjhol : I have tried with the recent version but still facing the same issue as  what @loganfuller said.

Can you provide me with a JSFiddle or link to an example? What browser/OS are you using? I tested using nearly 1000 cities on Windows 8/Chrome/Firefox and it loads almost instantaneously.

@caseyjhol : http://jsfiddle.net/nr54vx7b/88/ , I am using Windows 7 / Chrome Version 43.0.2357.134m

That's because you're trying to call refresh() every time you add an option. You want to add all of the options first, and then call refresh once outside of the for loop.
http://jsfiddle.net/nr54vx7b/89/

Oh Ok Thanks for the help @caseyjhol . Code which you suggested works good .

https://github.com/silviomoreto/bootstrap-select/blob/master/js/bootstrap-select.js#L746-L758
this plugin is not working for updation or edit???
it doesnt select multiple options which we already selected while editing???

seems like this is an issue again in v1.14.0-beta3 for Bootstrap 5 if I follow the step to "Add the selectpicker class to your select elements to auto-initialize bootstrap-select."
If I have 10 options it's fine. If I have 10,000, the browser asks to kill the page.
version info


add endpoint that offers JSON by IRI

With serve-graphql visit http://localhost:9982/data/chronicle:agent:my-agent-id and see JSON summarizing it. (Pipe through jq . for prettiness.) Same for activities and entities. Resolves CHRON-277 and CHRON-280.
Substituting data with data/default works, one may use other namespace IDs for default.
Notice that the subcommand has now become serve-api with a new --offer-endpoints option.
I opted for fairly minimal adjustment of prov_model_for_namespace code.

Looks good but I missed a requirement here - for compact json ld we also need to have the context at an accessible url. So will need something like /context that serves our generated context, and the json-ld response will need to use a relative url to it rather than our current sort of symbolic one

Thank you, interesting, https://www.w3.org/TR/json-ld11/ confirms that,

A remote context may also be referenced using a relative URL, which is resolved relative to the location of the document containing the reference.


helm create: Remove dead ingress template code

What this PR does / why we need it:
The Kubernetes versions referenced are no longer supported as of Helm 3.8
https://helm.sh/docs/topics/version_skew/
Special notes for your reviewer:
If applicable:

[x] this PR contains documentation
[x] this PR contains unit tests
[x] this PR has been tested for backwards compatibility

ping @mattfarina @technosophos @adamreese

Thanks for sending this in. Apologies for taking time to get to review. I think we had had this change covered in https://github.com/helm/helm/commit/f9ba3c568b1d8b84bfe67c0b461a5340d58d5401
We can close this now?


How to handle two packages containing assemblies with the same name

Description
This issue is caused by an assembly, System.Collections.Immutable, being released under two different package IDs, Microsoft.Bcl.Immutable up to version v1.0.34, and System.Collections.Immutable thereafter.
When System.Collections.Immutable is a top-level dependency, and Microsoft.Bcl.Immutable is a transitive dependency, compile errors like the following occur:

The type 'ImmutableHashSet' exists in both 'System.Collections.Immutable, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Collections.Immutable, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'	AGS.Web.Services

Repro steps

add nuget System.Collections.Immutable to paket.dependencies

add nuget Shields.Graphviz to paket.dependencies (and the same project)

Sample VS2015 project - NewRepo.zip
Expected behavior
A way to instruct paket to use System.Collections.Immutable as the transitive dependency instead of Microsoft.Bcl.Immutable.
Actual behavior
I haven't found a way to achieve this.
Known workarounds
None that I know of.

This should be resolved once Shields.Graphviz makes a new release. It has already been updated in the source. The old BCL package has actually been unlisted.

@cdrnet Very nice. Thanks!


Update pluto-on-binder to Pluto.jl v0.12.11 (last version as today)

Thanks Fons, Mikołaj (and the Pluto.jl community), it is really a good tool 👍 :)

Thank youu!

Since I have you here, can I ask how you use pluto-on-binder? Do you use it every day?

You are welcome ;)
According to the Binder federation, you are a star 😎 : 229 launches last week or 1148 last month (both in the top 50 !)
Personally, I am not using a lot, but it's a good way to share a notebook for people without Julia or on mobile phone.
If you want some features requests (on your endless list ^^) : Dark mode and less important (and I think more difficult) : a easy way to launch a notebook without autosave (or stop/pause/restart it on demand)
If you want, you can test my Plutoku (draft for Sudoku) but it is... un petit peu en Français :)
Thanks again Fons ;)


IDA does not respect the maxiters option

I have set maxiters to 1, but clearly, IDA took more than 1 step here. :-)
julia> solve(prob,IDA(), maxiters=1).t |> length
145

It looks like the common interface code is correct,
https://github.com/SciML/Sundials.jl/blob/master/src/common_interface/solve.jl#L918
@jd-lara Do you know why this happens?

I am not aware of any heuristic to remove that. The documentation only mentions that if negative it disables the max limit. I would have to make a test with the direct API to confirm what is happening.


Creating an orderer using a remote CA

Hello,
I am working on a multi cluster setup using HLF Operator and Istio with 3 CAs - org1-ca (cluster1), orderer-ca (cluster1), org2-ca (cluster2).
So far deployment of peers on both clusters and an orderer on cluster1 was fine, I managed to join them in a channel and they seem to communicate just fine, but now I would like to create an orderer on cluster2, using the orderer-ca from cluster1, but I get an error that CA with given name is not found on the cluster.
Is that even possible to create a network like this with HLF Operator?

Hi @Wojciechowski-Marcin
Yes, CA needs to be exposed using Istio: https://labs.hyperledger.org/hlf-operator/docs/operator-guide/istio
After that, you'll need to manually modify the enrollment cahost and caport of the peer and orderer.

Thank you for the tip, it helped me solve the problem
For anyone with similar problem in the future, cahost should be the domain of the CA, caport should be port of the istio gateway (443 by default) and catls.cacert needs to be changed, it worked when I copied the value from orderer on cluster1.


chore: fixed legal headers to only tractus-x changes

Why we create this PR?
A mistake was made and now we need to revert the change.
What we want to achieve with this PR?
Reverted change to just tractus-x
What is new?
Added

Reverted change to just tractus-x in the licenses

As requested changed to "Tractus-X". Good 2 go.


chore(package): update kronos-interceptor to version 2.5.0

Codecov Report

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

@@           Coverage Diff           @@
##           master      #75   +/-   ##
=======================================
  Coverage   26.02%   26.02%
=======================================
  Files           1        1
  Lines          73       73
=======================================
  Hits           19       19
  Misses         54       54

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 988ca66...165aaa0. Read the comment docs.

Coverage remained the same at 21.348% when pulling 165aaa026cdd9e04cf19f0b4da1bd823c48a9611 on greenkeeper/kronos-interceptor-2.5.0 into 988ca66df6ed5400191a9e4ba18d8d2ef5811712 on master.


[WIP] [Feature] Schema aggregation

Requires https://github.com/CenterForOpenScience/exp-addons/pull/38


Implement Gaussian potential

This PR is an implementation of a Gaussian potential.
Todo

[x]  Add input manual entry (when we know where).
[x]  Add tests for lumol-input.

Edit: Sorry for the formatting changes, this is due to rustfmt on save.

There is both a check in the new function as well as the input parser for correct input. I also named the bad example for input test gaussian-... because I always have to go through multiple test cases to copy one I can reuse. We may want to give the test files more descriptive names 😄

Should I squash the commits?

Yes please =)

Le 26 oct. 2017 à 18:23, Gernot Bauer<EMAIL_ADDRESS>a écrit :
Should I squash the commits?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Only beta is failing, and I could not reproduce the failure locally, even with the official docker image from Travis. So I propose we merge this and other PR, and I'll try to debug the issue further this weekend.

Sure! Do you merge?


libpq error

I get the following error when building image myself using docker build --rm --build-arg AIRFLOW_DEPS="datadog,dask" --build-arg PYTHON_DEPS="flask_oauthlib>=0.9" -t agiz/docker-airflow:1.10.2 .:
ImportError: libpq.so.5: cannot open shared object file: No such file or directory

I can confirm this error.  When building an image with the provided Dockerfile I see the following error when the image is run:

airflow-worker   | [2019-04-08 21:18:19,697] {{settings.py:174}} INFO - settings.configure_orm(): Using pool settings. pool_size=5, pool_recycle=1800, pid=1
airflow-worker   | Traceback (most recent call last):
airflow-worker   |   File "/usr/local/bin/airflow", line 21, in
airflow-worker   |     from airflow import configuration
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/airflow/init.py", line 36, in
airflow-worker   |     from airflow import settings, configuration as conf
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/airflow/settings.py", line 266, in
airflow-worker   |     configure_orm()
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/airflow/settings.py", line 188, in configure_orm
airflow-worker   |     engine = create_engine(SQL_ALCHEMY_CONN, **engine_args)
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/engine/init.py", line 431, in create_engine
airflow-worker   |     return strategy.create(*args, **kwargs)
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/engine/strategies.py", line 87, in create
airflow-worker   |     dbapi = dialect_cls.dbapi(**dbapi_args)
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/dialects/postgresql/psycopg2.py", line 599, in dbapi
airflow-worker   |     import psycopg2
airflow-worker   |   File "/usr/local/lib/python3.7/site-packages/psycopg2/init.py", line 50, in
airflow-worker   |     from psycopg2._psycopg import (                     # noqa
airflow-worker   | ImportError: libpq.so.5: cannot open shared object file: No such file or directory

I am also getting the same error

I´ve just face of the same problem, I did not fix but i could workaround it.
I opened Dockerfile and change AIRFLOW_VERSION arguments from 1.10.2 to 1.10.1
ARG AIRFLOW_VERSION=1.10.1

I added libpq5, still getting same error

same problem here

Same problem here

By adding below two library problem is resolved on mac but still facing the issue on Linux
'pip install psycopg2
&& pip install psycopg2-binary '

I added libpq5 and the issue cleared up.  Be mindful not to add it to the buildDeps section, as all of those libraries are removed at the end of the build.

I've made a PR #349.

This worked for me: pip install psycopg2-binary redis>=3.2.0, which you can set with PYTHON_DEPS.

Wierd this issue just started for me today but not there yesterday....
What worked for me was to add 'psycopg2-binary redis>=3.2.0' to the PYTHON_DEPS in the Dockerfile.
Didnt have todo that yesterday with same source code.... very strange... clearly something outside my control has changed.... wish I knew what....grrrr and lol!

I had the same problem, it's related to the psycopg2 release. Created #370 for it.

The way I solved it is by removing the postgres reference in  the apache airflow line -- pip install apache-airflow[crypto,celery,hive,jdbc,password]==$AIRFLOW_VERSION , and just installed psycopg2-binary above it

Thanks all... does anybody know what changed yo cause this reconfiguration
to the dockerfile? Just curious...
On Sat, 25 May 2019, 04:03 Hayden Beadles<EMAIL_ADDRESS>wrote:

The way I solved it is by removing the postgres reference in the apache
airflow line -- pip install
apache-airflow[crypto,celery,hive,jdbc,password]==$AIRFLOW_VERSION , and
just installed psycopg2-binary above it
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/puckel/docker-airflow/issues/342?email_source=notifications&email_token=AESM3VGFYTTYTTGIM63NHU3PXCUBLA5CNFSM4HEJK6L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWG5MCY#issuecomment-495834635,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AESM3VGEX6HBKOFNSJHVOD3PXCUBLANCNFSM4HEJK6LQ
.

@paulforan I can take a shot at answering. So from version 2.8 forward, psycopg2 no longer bundles binary packages. It bundles those separately in a new packages - psycopg2-binary. More information on the change can be found here: http://initd.org/psycopg/articles/2018/02/08/psycopg-274-released/. If you included postgres in that apache-airflow pip install line, it installs the newest version of postgres, (2.8.2), which does not have the binary packages included anymore. So to get around that, just remove postgres from there and install psycopg2-binary separately to get those dependencies included. More information can be found here -- https://github.com/puckel/docker-airflow/pull/349

Yes, just like @hbeadles is saying. Also in Airflow in your task log you see: "The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: http://initd.org/psycopg/docs/install.html#binary-install-from-pypi."

Cool...
Nice answer guys...
So the moral of the story is to fix dependency versions within docker file
as much as possible to avoid stuff from breaking in the future.
Ie to productionize the container building process.
:-)
On Sun, 26 May 2019, 06:27 thierryturpin<EMAIL_ADDRESS>wrote:

Yes, just like @hbeadles https://github.com/hbeadles is saying. Also in
Airflow in your task log you see: "The psycopg2 wheel package will be
renamed from release 2.8; in order to keep installing from binary please
use "pip install psycopg2-binary" instead. For details see:
http://initd.org/psycopg/docs/install.html#binary-install-from-pypi."
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/puckel/docker-airflow/issues/342?email_source=notifications&email_token=AESM3VDKEX5YEF7YFDONUS3PXINSTA5CNFSM4HEJK6L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWH6SXQ#issuecomment-495970654,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AESM3VDLPCQDRDGDYC4UA4DPXINSTANCNFSM4HEJK6LQ
.

Adding the above suggestion of fixing psycopg2-binary==2.8.3 previously fixed this for me but I'm now seeing it happen again

Probably another version conflict. In fact on my side I specified all the package versions:
    && pip install -U pip==19.0.1 setuptools==40.7.0 wheel==0.32.3 \
    && pip install pytz==2018.9  \
    && pip install pyOpenSSL==19.0.0 \
    && pip install ndg-httpsclient==0.5.1 \
    && pip install pyasn1==0.4.5 \
    && pip install psycopg2==2.7.7 \

Same issue. Faced it today.
[2019-07-08 08:29:15,214] {{settings.py:174}} INFO - settings.configure_orm(): Using pool settings. pool_size=5, pool_recycle=1800, pid=1
Traceback (most recent call last):
File "/usr/local/bin/airflow", line 21, in
from airflow import configuration
File "/usr/local/lib/python3.6/site-packages/airflow/init.py", line 36, in
from airflow import settings, configuration as conf
File "/usr/local/lib/python3.6/site-packages/airflow/settings.py", line 266, in
configure_orm()
File "/usr/local/lib/python3.6/site-packages/airflow/settings.py", line 188, in configure_orm
engine = create_engine(SQL_ALCHEMY_CONN, **engine_args)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/init.py", line 443, in create_engine
return strategy.create(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/engine/strategies.py", line 87, in create
dbapi = dialect_cls.dbapi(**dbapi_args)
File "/usr/local/lib/python3.6/site-packages/sqlalchemy/dialects/postgresql/psycopg2.py", line 599, in dbapi
import psycopg2
File "/usr/local/lib/python3.6/site-packages/psycopg2/init.py", line 50, in
from psycopg2._psycopg import (                     # noqa
ImportError: libpq.so.5: cannot open shared object file: No such file or directory

I had a similar issues. I  updated the docker file in the airflow directory
FROM puckel/docker-airflow:1.10.2
to
FROM puckel/docker-airflow:1.10.3 ..
About psycopg, the system messages from ariflow worker_1 did complain
/usr/local/lib/python3.6/site-packages/psycopg2/init.py:144: UserWarning: The psycopg2 wheel package will be renamed from release 2.8; in order to keep installing from binary please use "pip install psycopg2-binary" instead. For details see: http://initd.org/psycopg/docs/install.html#binary-install-from-pypi.
Ignoring for now..

@paulforan I can take a shot at answering. So from version 2.8 forward, psycopg2 no longer bundles binary packages. It bundles those separately in a new packages - psycopg2-binary. More information on the change can be found here: http://initd.org/psycopg/articles/2018/02/08/psycopg-274-released/. If you included postgres in that apache-airflow pip install line, it installs the newest version of postgres, (2.8.2), which does not have the binary packages included anymore. So to get around that, just remove postgres from there and install psycopg2-binary separately to get those dependencies included. More information can be found here -- #349

Yes This worked in my case, Thanks

if some one is using kube-airflow. Use  imageTag as latest.  It solved me the issue.


Remove git submodules in favor of DVC

@nepoche any chance you can fix up the test script/fixtures issues? Seems a bunch of repos with this change need it also handled in the test CI script.

@drewstone @nepoche
The reason of CI failure is from that the name of original submodule dir(substrate-fixtures) does not match with new one(protocol-substrate-fixtures).
So, it should replace the lines which have the "../substrate-fixtures/..." with new name "../protocol-substrate-fixtures/...".
For example: In (this line)[https://github.com/webb-tools/protocol-cosmwasm/blob/nathan/use-dvc-fixtures/packages/protocol_cosmwasm/src/vanchor_verifier.rs#L26], it should be like
(2, 2, 2) =>  include_bytes!("../../../protocol-substrate-fixtures/vanchor/bn254/x5/2-2-2/verifying_key.bin"),


b3sum/hashsum lacks --no-names argument

The --no-names argument of the official b3sum utility is very handy for only returning the hashsum as output, without the filename.
$ echo | b3sum --no-names
295192ea1ec8566d563b1a7587e5f0198580cdbd043842f5090a4c197c20c67a

For the b3sum utility this argument should be supported. For hashum in general it would be quite useful as well.

Filed a PR

Thank you! It should be noted that b3sum is not part of GNU coreutils and hence there are only other implementations that fill that gap. They have slightly different options and --no-names does not appear in any of the GNU utils. However, I do think it might be nice to add this anyway.

Is there any coreutils implementation with this option?

I can't find any. But the b3sum util is from https://github.com/BLAKE3-team/BLAKE3 and is probably becoming the standard util, so it would be nice to have compatibility with that.

OK, sounds good :)
I will just add a comment that we should document it


remove some async state machines

AKA eliding https://blog.stephencleary.com/2016/12/eliding-async-await.html

I am testing these changes now.

I am testing these changes now.


Make .new and #action private to enforce API

All instance methods will be private, that is enforcing the API
defined by class method 'call'.
This changes was discussed in #6 .

@mbj let me know if some adjustments are needed.

Coverage remained the same at 100.0% when pulling f63ebe94abfffa5f754408e0cb39cc671bef87e5 on americodls:reinforce-the-api into 77e551468f4f42aee42a0619504e620ac04fe1ae on snusnu:master.

Coverage remained the same at 100.0% when pulling f63ebe94abfffa5f754408e0cb39cc671bef87e5 on americodls:reinforce-the-api into 77e551468f4f42aee42a0619504e620ac04fe1ae on snusnu:master.

Coverage remained the same at 100.0% when pulling f63ebe94abfffa5f754408e0cb39cc671bef87e5 on americodls:reinforce-the-api into 77e551468f4f42aee42a0619504e620ac04fe1ae on snusnu:master.

@americodls While I'm a collaborator on this repository, @snusnu should have the last call. I'll give this a review next week as I'm busy this week. Feel free to ping me if I forget it.


Add fxload to base.yaml

In general, it is easier to review these if you follow the contributing guidelines here.  We're usually looking to see the keys for Ubuntu, Debian, and Fedora (with extra points for Gentoo and Arch).
Here it looks like this is available:

Ubuntu - https://packages.ubuntu.com/search?keywords=fxload&searchon=names&suite=all&section=all
Debian - https://packages.debian.org/search?keywords=fxload&searchon=names&suite=all&section=all
Fedora - https://apps.fedoraproject.org/packages/fxload

So an update to this key for Debian and Fedora would be appreciated.  Thanks.

Thanks for your comments @clalancette. I think I have addressed them.

Thanks for your comments @clalancette. I think I have addressed them.

Perfect, thank you!


Dependency cycles are explicitly printed

About this PR
closes #1908.
Dependency cycles were detected but not explicitly printed.
With this PR, we are computing strongly connected components using Kosaraju's algorithm. If the resulting list of nodes has more than 1 element, they are members of a cycle in the graph.
Test

forc init --library dependency_a
forc init --library dependency_b
add dependency_b as a dependency for dependency_a
adddependency_a as a dependency for dependency_b
forc init --library dependency_c
forc init --library dependency_d
add dependency_c as a dependency for dependency_d
add dependency_d as a dependency for dependency_c
add dependency_c as a dependency for dependency_a
forc build in dependency_a

The resulting dependency graph would be something like the following:

Wicked stuff @kayagokalp :) Would be sweet to have a test, but we can get around to it.

Thanks, @mitchmindtree :), for testing, is addressing #1904 would be enough or should we have a dedicated test for this section of the code?


Operator can update the fee tokens and amount without a restart

As an operator,
I want to update the fee tokens and corresponding amount without restarting the service,
So that my users will not suffer from any downtime.

I'm fairly sure this is current behaviour. Would need to test.

I'm fairly sure this is current behaviour. Would need to test.

confirm, this should be the case. An update to the fee specs file should be digested by the Child Chain instance and it should continue with the new specs from then on.

I presume this is sorted by the fee service @Pongch @T-Dnzt ?
if not, pls reopen.