Support for Supermium in older versions of Android

Is your feature request related to a problem? Please describe.
Android 8.0 is the minimum version Chrome needs to run, but there are still many users with older versions of Android (7.0 Nougat, 6.0 Marshmallow, 5.0 Lollipop and even 4.4 KitKat). Google ended support after Chrome versions 119, 106, 95 and 81 respectively, which was released in 2023, 2022, 2021 and 2020 reapectively. Many websites have glitches in these older versions of Chrome. At worst sites show unsupported browser prompt or do not work at all.
As of 2024 there are over 3.3 billion Android users worldwide, and around 8% of users (250 million) run Android versions earlier than 8.0.
Describe the solution you'd like
Backport Supermium 126 to older Android versions (including API level 19, 4.4 KitKat and later) and add code necessary for support.
Additional context

Although not on chart, there are around 10 million active users using Android 4.4 KitKat.

Sorry, I physically can't use a smartphone for web browsing.


When opening the xlsx written by a reader containing Nan, it will prompt that there is a problem with the content

static async Task Main(string[] args)
    {
        var path = Path.Combine("D:\\Document\\errorCSV", $"{Guid.NewGuid()}.xlsx");
        var table = new DataTable();
        {
            table.Columns.Add("Column1", typeof(double));
            table.Columns.Add("Column2", typeof(double));
            table.Rows.Add(1.0, double.NaN);
        }
        MiniExcel.SaveAs(path, table);

For this reason I am using version 1.30.3, and cannot upgrade it.


DBZ-3839 Correctly skip tests with minor/patch not specified

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

Applied; thx, @Naros!


ENH: Add msg_hook

:+1:
This also gives a path to do things like

def hook(msg):
    if msg.obj is not None and msg.obj.name == 'forbidden':
        raise NO()

Maybe too cute

[Current coverage][cc-pull] is 74.25%

Merging [#434][cc-pull] into [master][cc-base-branch] will decrease coverage by -<.01%

@@             master       #434   diff @@
==========================================
  Files            17         17
  Lines          3278       3281     +3
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2434       2436     +2
- Misses          844        845     +1
  Partials          0          0

Powered by Codecov. Last updated by [c51b945...916e080][cc-compare]
[cc-base-branch]: https://codecov.io/gh/NSLS-II/bluesky/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/NSLS-II/bluesky/compare/c51b945b8a9fd518a8f66cfe62f8e60716320c2c...916e0802de26c44998686f5907960eda5a7112a5
[cc-pull]: https://codecov.io/gh/NSLS-II/bluesky/pull/434?src=pr

@klauer and @tacaswell are here, self-merging

nevermind; @tacaswell is a purist :-P


Change "praser" to "parser" in "About" section on Github Page

Done. Thanks for the find :)

Done. Thanks for the find :)


Add stats of commit waysome/e3eb9a65619289fbfd684721ca434daf27ffed62

File names should be self-explanatory here.
Generated using the scripts from
https://github.com/matthiasbeyer/git-analyze

commit dba7c771fd4157dfbcedd988865af2418e582772

Unfortunately, the last one looks not that nice (x-bar). Feel free send patches to my git-analyze repo fixing this.
These are the stats I think are worth mentioning in the talk. More can be generated by using either the git-analyze scripts or the github-analyze scripts (ruby) on my github page.
@neithernut what do you think?

Updated with fixed todos-per-merge graphic.


Added note about potential race condition in Client#publish.

We decided to leave this out for now.


fix: fatal error reported when run make build in release src

Please answer these questions before submitting a pull request

Why submit this pull request?

[x] Bugfix

[ ] New feature provided

[ ] Improve performance

[ ] Backport patches

Related issues

Bugfix

Description
#447

Codecov Report

Merging #485 (e67f5fb) into master (bc71e3e) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #485      +/-   ##
==========================================
- Coverage   37.00%   36.99%   -0.02%
==========================================
  Files          47       46       -1
  Lines        3845     3844       -1
==========================================
- Hits         1423     1422       -1
  Misses       2237     2237
  Partials      185      185

Impacted Files
Coverage Δ

test/e2e/e2e.go

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 bc71e3e...e67f5fb. Read the comment docs.


fix: Use SVGs for built-up stretchy delimiters

This PR will eventually write a single SVG for a built-up delimiter, replacing the current stack of glyphs and thereby evading browser imprecision of glyph location. I have not yet got very far with this PR because I cannot get anything to run in my local repository. Even the main branch is inoperative.
If I try to run yarn start, the error message is:
(node:7640) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

Error [ERR_LOADER_CHAIN_INCOMPLETE]: "file:///C:/Users/Ronal/OneDrive/Documents/GitHub/KaTeX/.pnp.loader.mjs 'resolve'" did not call the next hook in its chain and did not explicitly signal a short circuit. If this is intentional, include `shortCircuit: true` in the hook's return.
    at new NodeError (node:internal/errors:387:5)
    at ESMLoader.resolve (node:internal/modules/esm/loader:860:13)
    at async ESMLoader.getModuleJob (node:internal/modules/esm/loader:439:7)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:541:24)
    at async loadESM (node:internal/process/esm_loader:91:5)
    at async handleMainPromise (node:internal/modules/run_main:65:12) {
  code: 'ERR_LOADER_CHAIN_INCOMPLETE'
}

I have no idea how to overcome this. Any help would be appreciated. @edemaine? @ylemkimon? Help?

I have no idea how to overcome this. Any help would be appreciated.

The issue you're running into was fixed in Yarn v3.2.2, try updating.
yarn set version stable && yarn install

I'm closing this PR and will re-create it from scratch.


problem with set_radio function

Hi, this is a problem that appears in CI 3. When I fill and submit a form, and the validation fails, the form is repopulated properly with set_value, set_select and set_radio functions. But when I'm filling the form programatically set_radio fails. Let me explain myself by telling you what happens in my application.
Suppose I have an "update person's data" link in my application. When the user opens the link he receives a form with a list of people to choose from. His option is sent through POST, and then he gets a second form populated with person's data. In this form all the fields are populated properly, except the radio fields. This happens only if I'm coming from a POST request. If I change the application so the first form uses GET method, it works fine.
I'm attaching two files showing the first and the second form.

Sorry, but this is very unclear. And we're talking about code, so screenshots are useless ... You need to clarify with a short code example.

Ok, I made a short code example. The example is about adding and editing data about a person. There is a controller, Person, and three views. The first view is insert_form.php, where the user is able to add data into the database. The second view, list_records.php, shows a list of people and the user choose a person to edit it's data. After that, he gets the third view, update_form, where the user gets a form populated with the person's data he choose. Here the user is able to make changes to a person.
For the update form, I'm using set_value and set_radio with the DEFAULT parameter to show the form populated with data. The function set_radio is not working.
set_radio-5436.zip

A short example doesn't need 3 views, lenghty explanations or be zipped ... This is a short example:
$_SERVER['REQUEST_METHOD'] = 'POST';
$_POST['field'] = 'value';

// Return expected: ' checked="checked"'
// Return actual: ''
set_radio('field', 'value');

Your file update_form.php is incorrect.
Add form_close() and use form_radio() helper and works!
<?php
echo validation_errors();
echo form_open('person/event_update_person');
?>
<input type="hidden" name="personId" value="<?= $person[0]->id?>">

Name
<input type="text" name="name" value="<?= set_value('name', $person[0]->name);?>">

Size
	<?php echo form_radio('size','s',$person[0]->size == 's'); ?> S
	<?php echo form_radio('size','m',$person[0]->size == 'm'); ?> M
	<?php echo form_radio('size','l',$person[0]->size == 'l'); ?> L

<input type="submit" value="Save">
<?php echo form_close(); ?>

@narfbg fixed


Add circuit_evolution_batch to run circuit evolution in batch mode

This PR adds a thin wrapper around circuit_evolution so it can be run in batch mode, i.e. run multiple times to generate multiple plausible candidate circuits in parallel. We need this in AutoEIS, where we want to generate multiple potential candidates and then rank them based on some statistical criteria. We originally tried to use Python multiprocessing to do this on our side, but it turned out to be quite fragile especially for macOS.
The wrapper accepts two keyword arguments in addition to the ones accepted by circuit_evolution:

iters: Defines how many candidate circuits to generate
numprocs: Number of workers to use; Defaults to the number of physical cores.

@MaximeVH I'd really appreciate it if you could review this PR and let me know what you think.

I think this is indeed a useful addition to the package


generic proxy: split the upstream to different module to simply test and mock

Commit Message: generic proxy: split the upstream to different module to simply test and mock
Additional Description:

Splited current upstream to DecoderEncoder and GenericUpstream. All make all these modules depend others by interfaces. This make it's possible to do flexible mock.
Now the client DecoderEncoder has same lifetime with the client connection (upstream connection).

Risk Level: low. Contrib only change.
Testing: unit.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.

Friendly ping for blind approve for this contrib only change. cc @jmarantz


New Overview Table & Chart UI Improvement

Can't display complete Trial metric chart in low-resolution environment as below:

New design
Combine chart and table together on the right side.

New design

Optimization of the section alignment:

Direct to the trial in the table when pressing the dot in the chart

Optimization of the information layout in the tooltip

@kvartet This issue had been done on v2.x, could you help close this issue?


Intro to backcountry

Description:
Backcountry will be the first thing we can look at when thinking about enhancing a future reservation system.
Acceptance Criteria:

[x] - determine initial approach on repository management
[x] - determine initial approach on hosting set up
[x] - Meet with reservation service team (may 1)
[x] - Collect questions from team in advance of reservation service team meetup
[ ] - continue wardley mapping to help with approach (could be related to repos?) (Jess + Diana)
[x] - Create super basic flow (one goal of next sprint = want to prototype a payment component of that)
[x] - Determine privacy protocols/confidentiality

Dependencies

Blocked by
Blocking

Relevant documentation as reference
Definition of Ready

[ ] Acceptance criteria are included
[ ] Wireframes are included (if applicable)
[ ] Design / Solution is accepted by Product Owner (if applicable)
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Notes:

@JLWade we're going to close this but will follow up with you about wardley mapping. cc @meyerdarcie


Device files in privileged mode are not updated automatically

Introduction
When you run a container in --privileged mode, the device files are created as expected in /dev. However, if udev adds / removes device files in the host system while the container is running, these changes do not propagate into the container. Thus, connecting a device which adds ttyACM0 to /dev/ does not work with a container, because the container will not see the new device file.
Reproduce

Run a container with `--privileged`` mode.
Connect a device that results in a new block device file
Check if the new block device file is visible in the container.

Or vise versa, any removed device files still exist within the container.

This is by design. Options for users include bind-mounting /dev into a container or running udev inside the container.

Why is this by design? It doesn't make too much sense to snapshot /dev/ at the start. I think if anything it is the way it is because it's more complex to make something that watches for changes in that tree.

As @ewindisch mentions, this is intentionally caused by the way we create the rootfs for the container. If you want to get /dev updated when a new device is added to the host, you can mount it into the container with --volume /dev:/dev.
Thanks for your report. Closing since it's not an issue.


Sharepoint integration

Description
What is the current behavior?

close: #1553

What is the new behavior?

Does this introduce a breaking change?
Checklist

[ ] Created tests which fail without the change (if possible)
[ ] Extended the README / documentation, if necessary

Hi @Lee-W, can you please provide more information on this PR's description? The issue request is a bit convoluted so it would be great to see a description that tells us
a) what sharepoint is
b) how we're integrating it
c) if there are any caveats or limitations to this integration
Thank you!

Blocked on sharepoint access

@Lee-W whats the latest on the sharepoint access? Have you been able to talk to IT and get it resolved?

You've got access to Sharepoint now @Lee-W , lets move forward on this based on priority

@Lee-W any timeline with respect to this issue?

I'm still focused on auto switch deferrable. Will be able to work on it after that


README.md with Godot 3.1 interface screenshot

An up-to date image, with the good looking TPS demo is probably now a good choice.

I think the orange bar should be removed, it takes too much attention.

Also, I think the image should be hosted elsewhere, as I am not sure github usercontents may least if the associated comment gets deleted.

Also, I think the image should be hosted elsewhere, as I am not sure github usercontents may least if the associated comment gets deleted.

I totally agree, should that be on tuxfamiliy.org, or even in the code repository, so that in the future would be even easier to update eventual screenshots.

Also, to bit a little bit picky, I think it would be better to use the default theme for the screenshot. Otherwise it might disturb people.
And finally, you will have to rebase your branch and merge your commits together. See the PR woprkflow documentation

Oh, I forgot my theming thing..

Is this the default theme? (apart from the top bar accent that is my windows config)

Yes it is :) The central picture likely needs to be a little less cluttered, like the first you proposed, but else it's good (if you remove the top bar :) )

Ok, still,
I believe that even for future updates, would be much easier to keep all the screenshots in the repository, in a specific folder.
But I'm guessing that also some build scripts will need to be updated in order to ignore the new folder.

I finally solved the multiple commits, dang, I can't really use git.. thanks tortoise.

@Toshiwoz See the screenshot I posted at https://github.com/godotengine/godot/issues/27324#issuecomment-475693107. I'd give it a try as it looks less cluttered.

Looks nice to me

Superseded by e40aea7f, but thanks for the proposal!


Create GLJPanel demo and fix dependencies for Netbeans 8.1.

The two existing demos weren't working for NetBeans 8.x, I created a third demo which is working.
This resolves issue #1

In netbeans 8.2 the org.netbeans.api.progress.ProgressHandleFactory no longer exists, and as of now there is yet another netbeans release 9.0.  Rather than integrating these demos into netbeans it would be more useful and ragmatic if they existed as stand-alone applications.


fix: add support for multi-line import extension normalization

Fixes #45 and https://github.com/unjs/unbuild/issues/83.
The change essentially does the following:

One-line imports are handled as they were before
Multi-line imports are handled only if brackets are present, allowing full control over the multi-line capture group, so that we don't mistakenly capture functions and objects that use brackets.

The simplest solution of using [\s\S] instead of .* will spill over to export function() {} and export {};, therefore it's not feasible.

Thanks for the fix and sorry for delay. Later, we might change this to mlly utils for more stable impl.


macro_module_names false-positive

I use macroses to hide internal exception data structure.
I have .hrl file like
-define(MATCH_MY_ERROR, {my_error, _, _}).
-define(MATCH_MY_ERROR(ErrorTag), {my_error, ErrorTag, _}).

And inside my code I use constructions like
-include_lib("my_app/include/error.hrl").

try my_logick()
catch
    throw:?MATCH_MY_ERROR(bad_auth) ->
        % handle auth error
    throw:?MATCH_MY_ERROR(input_validation) ->
        % handle validation error
    throw:?MATCH_MY_ERROR ->
        % handle other application errors
end.

And elvis thinks that I use macros as function name placeholder, but that's not true.

awesome catch, @seriyps !!


Help beta-testing ThirdStats

Hey there stats loving folks!
Due to several reasons ThirdStats got much less attention from me than I would have liked in the last months and in general I could use some help testing the ThirdStats nightly builds. So if you want to support this project and don't want to donate money or contribute code - testing and reporting bugs is a great way to help! Here's how it works:

Download the latest nightly build from the ThirdStats CDN (XPI file)
Start Thunderbird and install the XPI file by going to Settings > Add-ons and Themes > Extensions > Gear Button > Install Add-on from file > Choose the downloaded XPI file
Now start using ThirdStats and check if...

ThirdStats logo appears in the menu and the popup shows all active accounts
add-on options page displays properly, alle options can be changed, options can be reset
stats page display properly, data is shown correctly, processing works, all filter work as expected

If anything doesn't work, file a bug report or start a discussion about it.
Thanks a lot for your support 💚

@devmount Anyway we can get nightly builds to auto update? In the event that's not possiblem idea:

In-extension version check, reports out of date / new available build in some manner (toolbar icon? notification?)

An auto update would indeed make the testing of the current build much easier. Unfortunately there is no such mechanism for no-ATN add-ons (at least not known to me). So if some day TB implements something like that, I will adapt it right away.
The in-extension version check is a great idea. But that would require making calls either to GitHub or the ThirdStats CDN which I would like to avoid for privacy reasons. Currently ThirdStats works without any external calls.

An auto update would indeed make the testing of the current build much easier. Unfortunately there is no such mechanism for no-ATN add-ons (at least not known to me). So if some day TB implements something like that, I will adapt it right away.
The in-extension version check is a great idea. But that would require making calls either to GitHub or the ThirdStats CDN which I would like to avoid for privacy reasons. Currently ThirdStats works without any external calls.

Understood. How about

[ ] Check and notify me of updated development versions

Opt-in only :)

Yes, opt-in would be a possibility. If I receive feedback from some more people who are using/testing nightly builds, I'll implement it.


[NOTE] Notes on "POST /policies/replication" API

This is a very complicated API.
by swagger file

The content body of this API consist of so many parameters. But which of them is required?
by Harbor UI

It seems that only three of them are really required

Name
Source project
Endpoint

Case 1

{
  "name": "sync-to-somewhere",
  "description": "",
  "trigger": {
    "kind": "Manual"
  },
  "replicate_existing_image_now": true,
  "replicate_deletion": false,
  "filters": [],
  "projects": [
    {
      "project_id": 10,
      "owner_id": 1,
      "name": "temp_9",
      "creation_time": "2018-11-02T06:58:29Z",
      "update_time": "2018-11-02T06:58:29Z",
      "deleted": false,
      "owner_name": "",
      "togglable": true,
      "current_user_role_id": 1,
      "repo_count": 1,
      "metadata": {
        "public": "true"
      }
    }
  ],
  "targets": [
    {
      "id": 1,
      "endpoint": "http://<IP_ADDRESS>",
      "name": "fake endpoint",
      "username": "admin",
      "password": "",
      "type": 0,
      "insecure": true,
      "creation_time": "2018-11-07T14:42:31.876842Z",
      "update_time": "2018-11-07T14:42:31.876842Z"
    }
  ]
}

Case 2

{
  "name": "sync-again",
  "description": "",
  "trigger": {
    "kind": "Immediate"
  },
  "replicate_existing_image_now": true,
  "replicate_deletion": false,
  "filters": [],
  "projects": [
    {
      "project_id": 9,
      "owner_id": 1,
      "name": "temp_8",
      "creation_time": "2018-11-02T06:58:25Z",
      "update_time": "2018-11-02T06:58:25Z",
      "deleted": false,
      "owner_name": "",
      "togglable": true,
      "current_user_role_id": 1,
      "repo_count": 1,
      "metadata": {
        "public": "true"
      }
    }
  ],
  "targets": [
    {
      "id": 2,
      "endpoint": "https://<IP_ADDRESS>",
      "name": "fake again",
      "username": "admin",
      "password": "",
      "type": 0,
      "insecure": false,
      "creation_time": "2018-11-07T14:46:34.752062Z",
      "update_time": "2018-11-07T14:46:34.752062Z"
    }
  ]
}

Case 3

{
  "name": "sync-third",
  "description": "",
  "trigger": {
    "kind": "Scheduled",
    "schedule_param": {
      "type": "Daily",
      "offtime": 68400
    }
  },
  "replicate_existing_image_now": true,
  "replicate_deletion": false,
  "filters": [],
  "projects": [
    {
      "project_id": 8,
      "owner_id": 1,
      "name": "temp_7",
      "creation_time": "2018-11-02T06:58:22Z",
      "update_time": "2018-11-02T06:58:22Z",
      "deleted": false,
      "owner_name": "",
      "togglable": true,
      "current_user_role_id": 1,
      "repo_count": 1,
      "metadata": {
        "public": "true"
      }
    }
  ],
  "targets": [
    {
      "id": 3,
      "endpoint": "http://<IP_ADDRESS>",
      "name": "fake third",
      "username": "moooofly",
      "password": "",
      "type": 0,
      "insecure": true,
      "creation_time": "2018-11-07T15:15:35.87736Z",
      "update_time": "2018-11-07T15:15:35.87736Z"
    }
  ]
}

Conclusion
Here are the major steps that Harbor UI does

By "GET /api/policies/replication?name=<xxx>" to check if the replication rule with name  already exists.
By "GET /api/projects?name=<yyy>" to get source project info to be replicated.
By "GET /api/targets?name=<zzz>" to get the endpoint info to replicate to.
By "POST /api/policies/replication" to create the replication rule based on above info and some other info.

Case 4

{
  "name": "sync-fourth",
  "description": "444",
  "trigger": {
    "kind": "Manual"
  },
  "replicate_existing_image_now": true,
  "replicate_deletion": false,
  "filters": [
    {
      "kind": "repository",
      "value": "repo"
    },
    {
      "kind": "tag",
      "value": "v10086"
    },
    {
      "kind": "label",
      "value": 33
    },
    {
      "kind": "label",
      "value": 30
    },
    {
      "kind": "label",
      "value": 27
    }
  ],
  "projects": [
    {
      "project_id": 7,
      "owner_id": 1,
      "name": "temp_6",
      "creation_time": "2018-11-02T06:58:22Z",
      "update_time": "2018-11-02T06:58:22Z",
      "deleted": false,
      "owner_name": "",
      "togglable": true,
      "current_user_role_id": 1,
      "repo_count": 0,
      "metadata": {
        "public": "true"
      }
    }
  ],
  "targets": [
    {
      "id": 1,
      "endpoint": "http://<IP_ADDRESS>",
      "name": "fake endpoint",
      "username": "admin",
      "password": "",
      "type": 0,
      "insecure": true,
      "creation_time": "2018-11-07T14:42:31.876842Z",
      "update_time": "2018-11-07T14:42:31.876842Z"
    }
  ]
}

Conclusion
Here are the major steps that Harbor UI does

By "GET /api/policies/replication?name=<xxx>" to check if the replication rule with name  already exists.
By "GET /api/projects?name=<yyy>" to get source project info to be replicated.
By "GET /api/labels?scope=g" to get all global labels.
By "GET /api/labels?scope=p&project_id=" to get labels from source project.
By "GET /api/targets?name=<zzz>" to get the endpoint info to replicate to.
By "POST /api/policies/replication" to create the replication rule based on above info and some other info.

Case 5

{
  "name": "sync-fifth",
  "description": "fifth",
  "trigger": {
    "kind": "Scheduled",
    "schedule_param": {
      "type": "Weekly",
      "weekday": 1,
      "offtime": 0
    }
  },
  "replicate_existing_image_now": true,
  "replicate_deletion": false,
  "filters": [],
  "projects": [
    {
      "project_id": 6,
      "owner_id": 1,
      "name": "temp_5",
      "creation_time": "2018-11-02T06:58:11Z",
      "update_time": "2018-11-02T06:58:11Z",
      "deleted": false,
      "owner_name": "",
      "togglable": true,
      "current_user_role_id": 1,
      "repo_count": 1,
      "metadata": {
        "public": "true"
      }
    }
  ],
  "targets": [
    {
      "id": 1,
      "endpoint": "http://<IP_ADDRESS>",
      "name": "fake endpoint",
      "username": "admin",
      "password": "",
      "type": 0,
      "insecure": true,
      "creation_time": "2018-11-07T14:42:31.876842Z",
      "update_time": "2018-11-07T14:42:31.876842Z"
    }
  ]
}

Conclusion
Here are the major steps that Harbor UI does

By "GET /api/policies/replication?name=<xxx>" to check if the replication rule with name  already exists.
By "GET /api/projects?name=<yyy>" to get source project info to be replicated.
By "GET /api/labels?scope=g" to get all global labels.
By "GET /api/labels?scope=p&project_id=" to get labels from source project.
By "GET /api/targets?name=<zzz>" to get the endpoint info to replicate to.
By "POST /api/policies/replication" to create the replication rule based on above info and some other info.

As you can see:

the offtime of "8:00 AM" is 0
the offtime of "3:00 AM" is 68400

by https://github.com/moooofly/harborctl/issues/30#issuecomment-436667550, you can see that
"filters": [
    {
      "kind": "repository",
      "value": "repo"
    },
    {
      "kind": "tag",
      "value": "v10086"
    },
    {
      "kind": "label",
      "value": 33
    },
    {
      "kind": "label",
      "value": 30
    },
    {
      "kind": "label",
      "value": 27
    }
  ],

the type of "value" can be of either string type or int type. This makes codes for json.Marshal a little bit inconvenient.
Currently, when setting label IDs with harborctl, you will get
$./harborctl replication policy create -e fake-remote -r sync-test -s test-1 -d "from cli" --label_ids_as_filter "1,2,3"
==> GET (with struct) https://localhost/api/projects?name=test-1
==> GET (with struct) https://localhost/api/targets?name=fake-remote

----- just for debug -----

===> {"name":"sync-test","description":"from cli","projects":[{"project_id":4,"owner_id":1,"name":"test-1","creation_time":"2019-02-10T04:48:17Z","update_time":"2019-02-10T04:48:17Z","deleted":false,"owner_name":"","togglable":true,"current_user_role_id":1,"repo_count":0,"chart_count":0,"metadata":{"public":"true","enable_content_trust":"","prevent_vul":"","severity":"","auto_scan":""}}],"targets":[{"id":1,"endpoint":"https://<IP_ADDRESS>","name":"fake-remote","username":"admin","password":"","type":0,"insecure":true,"creation_time":"2019-02-10T04:49:41.041147Z","update_time":"2019-02-10T04:49:41.041147Z"}],"trigger":{"kind":"Manual","schedule_param":{"type":"","weekday":0,"offtime":0}},"filters":[{"kind":"label","value":"1"},{"kind":"label","value":"2"},{"kind":"label","value":"3"}],"replicate_existing_image_now":true,"replicate_deletion":false}

----- just for debug -----

==> POST https://localhost/api/policies/replication
<==
<== Rsp Status: 400 Bad Request
<== Rsp Body: value the type of value should be integer for label filter
value the type of value should be integer for label filter
value the type of value should be integer for label filter

[#225#root@ubuntu-1604 /go/src/github.com/moooofly/harborctl]$

I think, making some adjustments from server side will be more reasonable.


Fix hooks processing

This fixes a regression where Helm Hooks were not included in the release.Manifests YAML-encoded string, and were therefore missing in the rendered files.

LGTM 👍


fix_typo

fixed typo assuming "chrome" is not intentional ;)

@yeongbin-jo : Please suggest if there are any conventions need to be followed for branching, PR and/or naming

@yeongbin-jo : Please suggest if there are any conventions need to be followed for branching, PR and/or naming

@Ka55i0peia @yeongbin-jo Could you review this ?

I am not the author and "product owner". But sounds reasonable. @yeongbin-jo ?


Questions

I have some questions about the arbitrage script.

Are the arbitrages continous?

What combinations does it run? Lets say looking to my log here it sems it ony makes them towards XYZ/bitfinex:

OKCoin/Bitfinex:     -5.47% [target  0.80%, min -5.47%, max -5.47%]
Bitstamp/Bitfinex:    1.33% [target  0.80%, min  1.33%, max  1.33%]
Gemini/Bitfinex:      0.22% [target  0.80%, min  0.22%, max  0.22%]
Kraken/Bitfinex:     -0.00% [target  0.80%, min -0.00%, max -0.00%]
ItBit/Bitfinex:       0.14% [target  0.80%, min  0.14%, max  0.14%]

Does is also make other permutations like:

OKCoin/Bitstamp
Gemini/Kraken
ItBit/Bitsamp
...
All of permutations?

1.What do you mean?
2.What I understood from Blackbird is that it is market-neutral (making money out of the spread, independently the rise of fall of BTC over USD). To do this, it need a short position and a long one. Bitfinex is the only implemented exchange with short selling enabled over an API for Bitcoin.
So the only opportunities Blackbird can catch is when the Bitfinex price is above another exchange price, and that's why you only see XYZ/Bitfinex. Blackbird will never make a trade Gemini/Kraken because Kraken does not enable short selling.
To better understand why Blackbird needs shortselling to be market neutral, see issue #100.

thank oyu!


Plugin not loading? #314

[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null
[5/17/2015 2:19:11 PM] [Error] Could not find dependency: RocketAPI, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null

Pretty much everything in rocket mod has been refactored, as such, all of the plugins would have to update to the new versions of rocket to run.

Real, I thought it was fixed? Those plugins just updated to Rocket version 4.0

It may be possible that some plugin developers forgot to remove the reference to the old library. It's either that or the plugin you are trying to use is still out of date.

This is usually cause by either too many reference or their version is different.

Is anyone facing this similar problem as me?

Well, its the plugins that cause this...

I'm using build 314 on my server, and don't have the error on any of the plugins that I use on it, but most of them that I'm using on the server at the moment are ones that I coded, or have built myself. I've made sure that there's is no reference to the old RocketAPI.dll file in my own plugins, and have also have deleted the old file from the server's too.

I just installed build 317 and restarted my test server.  No errors with any of my plugins or fr34ky's plugins.  So this must be an issue with another plugin.  Cartman is right that all reference to the old Rocket code has to be removed by the developer as RocketAPI no longer exists.

Update the plugin.

Okay, I redownload the whole plugins and tested it. It's working fine now. Thanks everyone!


Added prepare-release.sh

Added prepare-release.sh, which was used to generate this commit and PR: https://github.com/medplum/medplum/pull/2284
This should make it easier for Medplum team members to prepare releases.  You can prepare a new release like so:
./scripts/prepare-release.sh 2.0.24

The script automates the following steps:

Use the Github gh tool to make sure the user is logged in
Start a new branch
Set version in sonar-project.properties
Set version in package.json
Set version in all examples/*/package.json files
Run npm version $version --workspaces
Generate release notes
Add changes to the staging area
Commit the changes with the release notes
Push the changes to the remote branch
Create pull request
Create draft release

Bonus: Set the +x executable flag on all .sh scripts

coverage: 94.128%. remained the same when pulling 4bc36da8cfdc6203ee25613b60ee915dc1a654bf on cody-prepare-release-script into 6e00c78769c7f173330be439b4e213fec482440f on main.


hive_generator dartx

Hi, guys any news about this aside for using dependencies override?
I have this issue after upgrading the flutter today.
Because hive_generator >=0.6.0 depends on dartx ^0.2.0 which depends on quiver >=2.0.3 <2.1.0, hive_generator >=0.6.0 requires quiver >=2.0.3 <2.1.0.
And because every version of flutter_test from sdk depends on quiver 2.1.3, hive_generator >=0.6.0 is incompatible with flutter_test from sdk.
So, because psb_mobile_agent depends on both flutter_test any from sdk and hive_generator ^0.7.0, version solving failed.

Please use the latest version from Git.
dependencies:
  hive:
  hive_flutter:
    git:
      url: git://github.com/hivedb/hive.git
      path: hive_flutter

dev_dependencies:
  hive_generator:
    git:
      url: git://github.com/hivedb/hive.git
      path: hive_generator

This works for you?
I get an error
[just_audio_service] flutter pub get
Running "flutter pub get" in just_audio_service...
Because every version of hive_generator from git depends on hive from hosted and just_audio_service depends on hive from git, hive_generator from git is forbidden.

So, because just_audio_service depends on hive_generator from git, version solving failed.
pub get failed (1; So, because just_audio_service depends on hive_generator from git, version solving failed.)
exit code 1

@yringler
It's not going to work with every dependency, just use dependency_overrides.
https://dart.dev/tools/pub/dependencies#dependency-overrides

Very cool, I didn't know about that. Thank you!
For the curious, here's a sample. Note that I specify a commit (the ref lines) to make sure there aren't any surprises, but those lines are optional. If you drop them, it'll pull from the latest changes on master.
dependency_overrides:
    hive:
      git:
        url: https://github.com/hivedb/hive
        path: hive
        ref: d7ee72537a3b7ce1284bcbf5ee5f86e617a4f6fc
    hive_generator:
      git:
        url: https://github.com/hivedb/hive
        path: hive_generator
        ref: d7ee72537a3b7ce1284bcbf5ee5f86e617a4f6fc

I've had the same problem! Thank you for this solution, it works.

Very cool, I didn't know about that. Thank you!
For the curious, here's a sample. Note that I specify a commit (the ref lines) to make sure there aren't any surprises, but those lines are optional. If you drop them, it'll pull from the latest changes on master.
dependency_overrides:
    hive:
      git:
        url: https://github.com/hivedb/hive
        path: hive
        ref: d7ee72537a3b7ce1284bcbf5ee5f86e617a4f6fc
    hive_generator:
      git:
        url: https://github.com/hivedb/hive
        path: hive_generator
        ref: d7ee72537a3b7ce1284bcbf5ee5f86e617a4f6fc
    hive_flutter:
      git:
        url: https://github.com/hivedb/hive
        path: hive_flutter
        ref: d7ee72537a3b7ce1284bcbf5ee5f86e617a4f6fc

This was super helpful ... thank you !

This issue should be fixed with v1.4.2 update.


Tag tab ,basic user manage his own badges , user not mandatory in badges anymore

@mahdibenromdhane Why the name of your branch is daf28b1 !? :-)

@mahdibenromdhane Why the name of your branch is daf28b1 !? :-)
I Had the same problem with git push that we faced yesterday in the server, so I generated a branch from a previous commit and the branch took the commit id as a name

What happens if an active unassigned badge is used to start a transaction?

If not Assigned to a User you cannot set the Default flag (UI + backend) -> Force default to false

For Basic user rename the Assign/Unassign (only i18n):

Assign -> Register
Unassign -> Delete

Unassign in table row -> Use the same icon and color as in the toolbar button

When basic user 'deletes' the tag, it should be marked as inactive

Basic user cannot assign an inactive badge to himself

He cannot change the status of the badge either

an error occur if an active unassigned badge is used to start a transaction

Done for the rest of remarks


Select box with focusCleanup doesn't hide error

I am using the latest jquery & jquery.validation plugin.
My Javascript code looks like this
$(function() {
	$("#signup").validate({
		onkeyup: false,
		errorElement: "span",
		errorPlacement: function(error, element) {
			error.insertAfter(element);
		},
		rules: {
			// ...
			card_exp_year: {
				required: true,
				hasselected: true
			}
			// ...
		},
		submitHandler: function(form) {
			form.submit();
		}
		debug: true,
		ignore: "",
		focusCleanup: true
	});
});

jQuery.validator.addMethod("hasselected", function(value, element) {
  return this.optional(element) || value != "0";
}, "Please select an item.");

My html code looks like this
<form id="signup" action="next_page.html" method="post">
	<select name="card_exp_year" class="full" title="Please select an experation year.">
		<option value="0">YYYY</option>
		<option value="2012">2012</option>
		<option value="2013">2013</option>
		<option value="2014">2014</option>
		<!-- ... -->
	</select>
	<input type="submit" class="button blue" value="Next">
</form>

My problem is that when selecting an option that is to throw an error, when I go to click on the select box again, the error is supposed to hide like all other form elements. I have "focusCleanup: true" set.
Steps to take to replicate my problem:
Click Select box
Select 2012
Click outside box
Click select box
Select YYYY
Click outside box
Error message shows
Click select box
*Error message disappears and then reappears right away.

I'm sorry for the lack of activity on this issue. Instead of leaving it open any longer, I decided to close old issues without trying to address them, to longer give the false impression that it will get addressed eventually.
To the reporter (or anyone else interested in this issue): If you're affected by the same issue, consider opening a new issue, with a testpage that shows the issue. Even better, try to fix the issue yourself, and improve the project by sending a pull request. This may seem daunting at first, but you'll likely learn some useful skills that you can apply elsewhere as well. And you can help keep this project alive. We've documented how to do these things, too. A patch is worth a thousand issues!


Using subprocess macros

I just stumbled across this package. I don't know if this is possible. But here is an idea of using subprocess macros to identify the shell language.
So something like
bash! export var=12
zsh! export var=12

would become possible.

Hi @jnoortheen!
Yes you can do bash -c! ls to run the another shell command.
But there are two issues around this approach:

You can't paste the multiline piece of script::

bash -c! for i in 1 2 3
do
   echo $i
done
# Syntax error

! for i in 1 2 3
do
   echo $i
done

#1
#2
#3

You should write bash -c! command that has more keystrokes than just !  :)

Yes thanks, I got here after checking out the ergopack. I currently don't have use for shell specific snippets, so a PR wouldn't be possible. Just wanted to see how this can be handled.


Standardize facelift dbus communication

[WIP] Standardize facelift dbus communication
Change-Id: Ifd09ce0e4b16a6a060d2a2634adc614f56b3a139

We went away from using the "native" DBus serialization a while ago, for 2 reasons:

Performance
We have reached the maximum number of arguments which can be written in a message.

AFAIU, your commit reverts that change, which is a bad idea.

This commit is PoC for further discussion.
If what you say is true, then we should probably drop DBus and use other standard. Either we should use common standards or different tool/protocol.
I don't really believe in performance argument. Benchmarks to be done (I was not aware of this argument up to now).
If we have to drop native DBus then we should probably use some existing tool that allows us to communicate with other languages/systems, e.g. flatbuffers. But then we should probably use sockets directly.

I could only find the following limitations:

The maximum length of a signature is 255.
The maximum depth of container type nesting is 32 array type codes and 32 open parentheses. This implies that the maximum total depth of recursion is 64, for an "array of array of array of ... struct of struct of struct of ..." where there are 32 array and 32 struct.
Are you referring to those limitations or others? Because IMHO those are generous limits!

We have reached the maximum number of arguments which can be written in a message.

as noticed this was most probably due to incorrect serialization of lists of structures, so if done properly it should not be the case

We went away from using the "native" DBus serialization a while ago, for 2 reasons:

Performance
We have reached the maximum number of arguments which can be written in a message.

AFAIU, your commit reverts that change, which is a bad idea.

This commit is PoC for further discussion and testing.
If what you say is true, then we should probably drop DBus and use other standard. Either we should use common standards or different tool/protocol.
Only the serialization part of DBus is not used in a classical manner. We need an IPC to deliver our messages, which is where DBus useful for us.

I don't really believe in performance argument. Benchmarks to be done (I was not aware of this argument up to now).
Feel free to write a benchmark if you really need that in order to be convinced.

If we have to drop native DBus then we should probably use some existing tool that allows us to communicate with other languages/systems, e.g. flatbuffers. But then we should probably use sockets directly.
flatbuffers is a serialization library, it provides no IPC.

We have reached the maximum number of arguments which can be written in a message.

as noticed this was most probably due to incorrect serialization of lists of structures, so if done properly it should not be the case

We have reached the maximum number of arguments which can be written in a message.

as noticed this was most probably due to incorrect serialization of lists of structures, so if done properly it should not be the case

The problem is that Qt is missing an API which would be needed to serialize structures "properly". I have spent a lot of time trying to find a workaround. Maybe that API is available in a more recent version of Qt though.

IDK about the time of facelift initial implementation but as Qt5.12 the API covers all requirements.
My initial benchmarking doesn't show any regression (as I suspected the overhead in dbus is communication not the property marshal/unmarshalling).

What kind of data did you use in your benchmark ? The overhead introduced by the serialisation is not significant if only a small amount of data is being transferred, so please adjust your benchmark to include large data such as long lists. Also, the registration of all those types in QDBus type system probably has a signification performance cost at startup.
Your change introduces a dependency to DBus into the "local" and "common" IPC components, which is not acceptable.
I did not dig into the details of your changes but I would not be surprised if the support for sub-interfaces over IPC was lost (especially sub-interfaces in structures).
Also, Facelift enables the change of multiple properties at once in an atomic way, which can be important if the values of those properties are related and should be consistent when being exposed. When exposed over IPC, the consistency should be kept. I suspect your change to break that consistency.
If you resolve the merge conflict, we can see if some tests fail, but keep in mind that our test coverage is still incomplete.

We are doing further benchmarking and will include the QDbus type registerations as well.
I tried not to break the "interfaces", even though the whole encapsulation is disaster, especially there are many inconsistency between list, map of "interfaces" and stand-alone ones. We need to follow up on that in some other effort.
The simultaneous change of multiple properties doesn't make sense to me at all. If a set of properties are dependent and represent state of any object, following Object-Oriented design, they should be packed into a struct, beside nobody expects this as well and it is not dbus conformant.

Also, the registration of all those types in QDBus type system probably has a signification performance cost at startup.

Could you explain better what you mean?

I did not dig into the details of your changes but I would not be surprised if the support for sub-interfaces over IPC was lost (especially sub-interfaces in structures).

To be verified. Please ask for checking instead of personal comments in the future.

Facelift enables the change of multiple properties at once in an atomic way,

yeah... atomic... right... I have never seen any kind of mutex, etc. in facelift. Not even saying about std::atomic.

Also, the registration of all those types in QDBus type system probably has a signification performance cost at startup.

Could you explain better what you mean?

Just look at the amount of additional code for type registrations. The registration template methods typically expands into large portions of binary code.

I did not dig into the details of your changes but I would not be surprised if the support for sub-interfaces over IPC was lost (especially sub-interfaces in structures).

To be verified. Please ask for checking instead of personal comments in the future.

There is nothing personal in my comment ! I noticed large portions of code being removed/replaced, including the code which is responsible for the registration of sub-interfaces. This stuff can be broken without noticing at first. This needs to be checked, ideally with a new test case, if this feature is not covered yet.

Facelift enables the change of multiple properties at once in an atomic way,

yeah... atomic... right... I have never seen any kind of mutex, etc. in facelift. Not even saying about std::atomic.

We are doing further benchmarking and will include the QDbus type registerations as well.
I tried not to break the "interfaces", even though the whole encapsulation is disaster, especially there are many inconsistency between list, map of "interfaces" and stand-alone ones. We need to follow up on that in some other effort.
The simultaneous change of multiple properties doesn't make sense to me at all. If a set of properties are dependent and represent state of any object, following Object-Oriented design, they should be packed into a struct, beside nobody expects this as well and it is not dbus conformant.

To make sure we are on the same page, let's consider that example:
interface TunerService {
int currentFrequency;
int maximumFrequency;
int minimumFrequency;
}
Now, please consider the "AM to FM band switching" use case, where those 3 properties are changed. If you first change the currentFrequency and issue the "currentFrequency changed" signal, you possibly expose an inconsistent state to the slots, since the value of the currentFrequency property is possibly outside of the validity range.
A correct way to address this issue is to change all property values first, and then start triggering the corresponding change signals. By doing so, no inconsistent state is exposed to any slot. Facelift's IPC layer preserves that consistency, by making a distinction between those 2 events: "property X changed" and "XChanged signal is triggered".
I agree that moving all those "related properties" into a single structure property would be a way to ensure that the consistency is preserved whatever happens, but this is a workaround which has the following problems:
- It results in a weird interface definition since the fields are not grouped in a natural or logical way, but rather in such a way that the consistency is insured.
- When a single value has changed, multiple additional fields are also sent over IPC, if they belong to the same structure, even if only one field has changed. This can be an issue with large properties (bitmap or long lists).

interface TunerInterface {
int currentFrequency;
int maximumFrequency;
int minimumFrequency;
}
Now, please consider the "AM to FM band switching" use case, where those 3 properties are changed. If you first change the currentFrequency and issue the "currentFrequency changed" signal, you possibly expose an inconsistent state to the slots, since the value of the currentFrequency property is possibly outside of the validity range, since the latter has not been changed yet.
A correct way to address this issue is to change all property values first, and then start triggering the corresponding change signals. By doing so, no inconsistent state is exposed to any slot. Facelift's IPC layer preserves that consistency, by making a distinction between those 2 events: "property X changed" and "XChanged signal is triggered".

I think this is wrong already on the concept level. At first, the interface itself should be stateless, so it should have no properties. At second, these should be grouped into a structure. The biggest benefit of grouping them into the structure is that we start following the object oriented programming paradigm. Even C language provided structures for the inseparable data, so why do we?

I agree that moving all those "related properties" into a single structure property would be a way to ensure that the consistency is preserved whatever happens, but this is a workaround which has the following problems:

It results in a weird interface definition since the fields are not grouped in a natural or logical way, but rather in such a way that the consistency is insured.

If we have the proper (stateless) interface, it is not a workaround. If the fields are not grouped in the natural or logical way (structured), then this is the project design problem, not the RPC framework that project uses.

When a single value has changed, multiple additional fields are also sent over IPC, if they belong to the same structure, even if only one field has changed. This can be an issue with large properties (bitmap or long lists).

If this is a problem, I would suggest to refine the design of the "interface" or structures from project side, because something is wrong at this level.
If something is unclear about grouping: imagine that you have to send Point2D. What is the proper way:
interface Point {
int x;
int y;
}
or
interface Point {
Point2D getPoint();
void setPoint(Point2D p);
}
struct Point2D {
int x;
int y;
}
Even if only single field has changed, this is now completely different point.

@jacky309 We were following up on dbus limit and for some huge structure the 255 character limit of the signature could be an issue. Although we can switching to old binary data transfer for those structs when annotated with "@serializable:true", I am not fully sure what is the main purpose of that annonation but since previously all structs were send like it is no backward compatibility issue.
Please have a look at:
https://github.com/Pelagicore/facelift/pull/303/commits/c1ad3438471f9250ccf8afe5cfe901efd34d540b

@jacky309 We were following up on dbus limit and for some huge structure the 255 character limit of the signature could be an issue. Although we can switching to old binary data transfer for those structs when annotated with "@serializable:true", I am not fully sure what is the main purpose of that annonation but since previously all structs were send like it is no backward compatibility issue.
Please have a look at:
c1ad343

That annotation is documented in the annotations page. It adds the serialize/deserialize methods to the structure API, which is completely unrelated to the IPC layer. Reusing that annotation to specify how the structure is serialized over DBus-IPC sounds like a misuse.
I would rather introduce a new annotation to enable an interface to be exposed in a "native DBus" way and I would keep the current serialization approach as default. I still do not know exactly what concrete problem you are trying to solve with that pull request, TBH. Maybe you can clarify that ? If the goal is to improve the interoperability issues, I assume that only some specific interfaces are concerned.

Well as you put it the issue is interoperability, we would like to use facelift in combination with other dbus frameworks in other languages.
With this PR it is possible to use other frameworks as well (godbus), idk what do you mean by some specific interfaces.
We can introduce a new annotation should not be hard. But I see the default behaviour otherway around, all communication should be in "native dbus" (since facelift used dbus and intuitively everybody expects that) unless the user defined it otherwise (due to huge structure signature or otherwise).

interface TunerInterface {
int currentFrequency;
int maximumFrequency;
int minimumFrequency;
}
Now, please consider the "AM to FM band switching" use case, where those 3 properties are changed. If you first change the currentFrequency and issue the "currentFrequency changed" signal, you possibly expose an inconsistent state to the slots, since the value of the currentFrequency property is possibly outside of the validity range, since the latter has not been changed yet.
A correct way to address this issue is to change all property values first, and then start triggering the corresponding change signals. By doing so, no inconsistent state is exposed to any slot. Facelift's IPC layer preserves that consistency, by making a distinction between those 2 events: "property X changed" and "XChanged signal is triggered".

I think this is wrong already on the concept level. .....

Why not sticking to the example which I suggested ? :
Again, I have a radio tuner device, which is a stateful device. Its state is made of 2 things:

a selected frequency
a selected wave band
Now, if I want to use Facelift to expose an interface which enables someone to interact with my device, I would likely come up with the following QFace definition, which provides some additional properties for maximum and minimum frequencies:

enum WaveBand {
AM,
FM
}
interface TunerInterface {
int currentFrequency;
readonly int maximumFrequency;
readonly int minimumFrequency;
WaveBand waveband;
}
What is fundamentally wrong with that interface ? Why ? What is not object-oriented here, if all the properties belong to an object (the interface) ?
How would your QFace interface look like, for the same tuner, with the same feature set ?
It is important that we have a common understanding of what a good interface looks like, to understand what Facelift should provide.

Well as you put it the issue is interoperability, we would like to use facelift in combination with other dbus frameworks in other languages.
With this PR it is possible to use other frameworks as well (godbus). IDK what do you mean by some specific interfaces is only needed to enable interoperability!

I assume that most QFace interfaces defined in a product using facelift do not require the interoperability feature. Typically, only a couple of them would really require the interoperability annotation.

We can introduce a new annotation should not be hard. But I see the default behaviour otherway around, all communication should be in "native dbus" (since facelift used dbus and intuitively everybody expects that) unless the user defined it otherwise (due to huge structure signature or otherwise).

The current implementation does not have the limitations which your change introduces and I assume it is faster and generates a more compact code (to be confirmed). The current implementation can also easily be improved to get multiple consecutive property change signals to be squashed into a single dbus message. AFAIK, your approach does not allow that.
I understand that the interoperability feature is useful and I can appreciate the work you've done, but the price to pay should definitely be considered.

Why not sticking to the example which I suggested ? :
Again, I have a radio tuner device, which is a stateful device. Its state is made of 2 things:
* a selected frequency

* a selected wave band
  Now, if I want to use Facelift to expose an interface which enables someone to interact with my device, I would likely come up with the following QFace definition, which provides some additional properties for maximum and minimum frequencies:

enum WaveBand {
AM,
FM
}
interface TunerInterface {
int currentFrequency;
readonly int maximumFrequency;
readonly int minimumFrequency;
WaveBand waveband;
}
What is fundamentally wrong with that interface ? Why ? What is not object-oriented here, if all the properties belong to an object (the interface) ?

As mentioned before it created state of the interface. So this is not right, the proper interface is state agnostic (stateless). That is the first fail of this kind of "interface" - it has properties. You have created remote object instead of interface.
However this still would be acceptable if they were organized properly.

How would your QFace interface look like, for the same tuner, with the same feature set ?
It is important that we have a common understanding of what a good interface looks like, to understand what Facelift should provide.

Please consider this:
interface TunerInterface {
int currentFrequency;
BandInfo bandInfo;
}
struct BandInfo {
readonly int  maximumFrequency;
readonly int minimumFrequency;
WaveBand waveband;
}
The currentFrequency can change independently to other properties, but the other three are tightly coupled. If we change bandInfo now, we must probably change currentFrequency, but this is developer responsibility now to do it right, not the, so called, interface (remote object in fact).
But with further improvement I would suggest (BandInfo structure as above).
interface Tuner { // you do not have to tell it is interface in the name. Using Hungarian notation and its modifications is really bad idea
int getCurrentFrequency();
void setCurrentFrequency(int freq); // or bool, where bool is a success status
BandInfo getBandInfo();
void setWaveBand(WaveBand wb);
signal currentFrequencyChanged();
signal bandChanged();
}
This makes the interface design right, interface is stateless. Using polymorphism in this case makes sense. Also it could be generated to other programming languages as an interface.

The current implementation does not have the limitations which your change introduces and I assume it is faster and generates a more compact code (to be confirmed). The current implementation can also easily be improved to get multiple consecutive property change signals to be squashed into a single dbus message. AFAIK, your approach does not allow that.

This change actually removes limitation to facelift framework in DBus usage. Anyway there are other problems like service registry which is in fact useless and most probably can be removed with minimal effort.

I will try to summarize all points here:
Purpose of PR:
Facelift is not a standard dbus framework and hence not interoperable due to following reasons.

Signatures of properties/methods/signals are missing or are completely wrong
“org.freedesktop.Dbus.Properties interface” is not utilized
All signals are send via generic “SignalTriggered”
Methods doesn’t have right signature
All the above makes Facelift impossible to combine in form of server/client schema with other dbus tools/frameworks.

Approach: Refactor the ipc layer in following manner

Utilize QtDBus tools to generate right signature for structs
Utilize “org.freedesktop.Dbus.Properties interface” as the standard interface for property exchange
For each signal use the corresponding signal signature not the generic “SignalTriggered”

Concerns about the PR

DBus limitation:
• The struct in struct limitation of 32 by 32.
• The maximum length of a signature is 255.
Remedy: Annotation: @serializeOverIPC turns the struct into byte array form over the dbus interfaces. Similar to previous treatment of structs.

Default Behavior: Intuitively and obviously this is not the default behavior of struct, the struct needs to follow dbus standard.
If developer runs to such limitation in their code-base, they really need to rethink their design. 255 is really long signature (in whole carbon-ui two auto-generated if1qface structs run into this limit which IMHO are badly design as well).

Atomic PropertiesChanged of multiple properties:
Dbus standard allow sending a “PropertiesChanged” with multiple values as well.
Event though AFAIK facelift doesn’t support this feature as current status but anyhow PR does not block future features in this direction.

org.freedesktop.DBus.Properties.PropertiesChanged (STRING interface_name, DICT<STRING,VARIANT> changed_properties, ARRAY invalidated_properties);

Performance regression
Preliminary results show no regression in case of 10000 method calls of methods with different range of  method signature (input and output struct) from couple of fileds to ~200 fields in struct.

Please reachout for .pref files.

Why not sticking to the example which I suggested ? :
Again, I have a radio tuner device, which is a stateful device. Its state is made of 2 things:
* a selected frequency

* a selected wave band
  Now, if I want to use Facelift to expose an interface which enables someone to interact with my device, I would likely come up with the following QFace definition, which provides some additional properties for maximum and minimum frequencies:

enum WaveBand {
AM,
FM
}
interface TunerInterface {
int currentFrequency;
readonly int maximumFrequency;
readonly int minimumFrequency;
WaveBand waveband;
}
What is fundamentally wrong with that interface ? Why ? What is not object-oriented here, if all the properties belong to an object (the interface) ?

As mentioned before it created state of the interface. So this is not right, the proper interface is state agnostic (stateless). That is the first fail of this kind of "interface" - it has properties. You have created remote object instead of interface.
However this still would be acceptable if they were organized properly.

How would your QFace interface look like, for the same tuner, with the same feature set ?
It is important that we have a common understanding of what a good interface looks like, to understand what Facelift should provide.

Please consider this:
interface TunerInterface {
int currentFrequency;
BandInfo bandInfo;
}
struct BandInfo {
readonly int maximumFrequency;
readonly int minimumFrequency;
WaveBand waveband;
}
The currentFrequency can change independently to other properties, but the other three are tightly coupled. If we change bandInfo now, we must probably change currentFrequency, but this is developer responsibility now to do it right, not the, so called, interface (remote object in fact).
But with further improvement I would suggest (BandInfo structure as above).
interface Tuner { // you do not have to tell it is interface in the name. Using Hungarian notation and its modifications is really bad idea
int getCurrentFrequency();
void setCurrentFrequency(int freq); // or bool, where bool is a success status
BandInfo getBandInfo();
void setWaveBand(WaveBand wb);
signal currentFrequencyChanged();
signal bandChanged();
}
This makes the interface design right, interface is stateless. Using polymorphism in this case makes sense. Also it could be generated to other programming languages as an interface.

The current implementation does not have the limitations which your change introduces and I assume it is faster and generates a more compact code (to be confirmed). The current implementation can also easily be improved to get multiple consecutive property change signals to be squashed into a single dbus message. AFAIK, your approach does not allow that.

This change actually removes limitation to facelift framework in DBus usage. Anyway there are other problems like service registry which is in fact useless and most probably can be removed with minimal effort.

So you are suggesting that users of Facelift stop defining interfaces which contain properties. That would mean that :
- Interfaces are not QML-friendly anymore. QML shines at handling properties (especially property bindings). One of the primary goals of Facelift is to help exposing interfaces to QML.
- A major performance penalty is introduced. Property values now have to be requested one by one, by calling the property getters.
- Worst of all: by the time the property getters have returned, the values which have been received by the client are not guaranteed to be consistent, since it could be that the server side changed some properties in between. There is no reliable way, at any point time, for the client to know if the received values represent a state which ever existed on the server side.
Your interface is a perfect example of what NOT to do, especially as far as defining interfaces to be used over IPC.
Our RPC framework has to ensure that the state replicated on the client side is a state which existed on the server side and to minimize the replication time. We do not want any user code to be required to realize that reliable replication.
AFAIK, the only way to replicate the state reliably is to be able to transport multiple property updates together in a single IPC message, which is what facelift currently does, and we should not break that.
By turning formal properties into methods/signals, you are just hiding the real nature of the interface, which is stateful, and you simply introduce new problems.

As I pointed out in the last commit, this PR doesn't put any limit on how many properties can be changed atomically.
org.freedesktop.DBus.Properties.PropertiesChanged (STRING interface_name, DICT<STRING,VARIANT> changed_properties, ARRAY invalidated_properties);
So please let's discuss scope of the PR, we needs these changes ASAP.

Added new test : https://github.com/Pelagicore/facelift/pull/305
Could you please check that your change does not break that test ?
Could you please also squash your commits ?

"serializeOverIPC" is not a good name. Structures are always serialized to be sent over IPC...
I would rather have an annotation on an interface, rather than on the structure definition.

Added new test : #305
Could you please check that your change does not break that test ?
Could you please also squash your commits ?

The test passes.
I will squash commits for the last step.

"serializeOverIPC" is not a good name. Structures are always serialized to be sent over IPC...
I would rather have an annotation on an interface, rather than on the structure definition.

switch to "treatAsByteArray".
The annotation is about each single struct not the interface itself. So some structs in interface can be send as byte array while others are still in native signature.

@jacky309 Please have another look, all QtDBus stuff moved to DBus layer.

@jacky309 Please let me know if you have any further comments, I assume the current ones are all addressed.

@jacky309 Can you please let me know what is still blocking the merge?

@jacky309 Can you please let me know what is still blocking the merge?

Just check my latest comments.

@jacky309 Can you please let me know what is still blocking the merge?

Check the comments I made during the last days.

All of them are addressed.

@jacky309 Can you please let me know what is still blocking the merge?

Check the comments I made during the last days.

All of them are addressed.

Rejecting is not addressing.

@jacky309 Can you please let me know what is still blocking the merge?

Check the comments I made during the last days.

All of them are addressed.

Rejecting is not addressing.

Either you are having a dialogue about the review points which involves you delivering arguments against the latest comments or otherwise they are consider resolved. Or you consider this a one-way street which is not a open source culture and there is no point for either of us continue this.

Please remove "request a change", no points are open.

You mentioned a noticeable drop in performance. Could you please provide some details ?
Most people simply do not care about having a "native" DBus serialization but they do care about having an IPC layer which performs well with their use cases. I do not think it is reasonable to ask anyone to work around a performance drop introduced by a feature which they do not need.

I took a very extreme example where a IPC interface has methods with structs over hundreds of fields, making RPC calls hundreds of times in a row, to see how libdbus acts.
In real use-cases with moderate size structs and reasonable num of IPC calls, the overhead is not even measurable.
So "Nobody" won't feel any difference! We have a huge project with all possible use-cases and observed no difference.
Anyhow if for any reason such unrealistic use-case (hunders of fields in struct) is needed, "toByteArrayOverDBus" annotation for structs will relieve one from signature validation in libdbus and remove any possible overhead.
The annotation should be on struct level as they could cause overhead with their size not the interface.

I took a very extreme example where a IPC interface has methods with structs over hundreds of fields, making RPC calls hundreds of times in a row, to see how libdbus acts.
In real use-cases with moderate size structs and reasonable num of IPC calls, the overhead is not even measurable.
So "Nobody" won't feel any difference! We have a huge project with all possible use-cases and observed no difference.

Unless this has changed recently, your project is mostly single-process, so I understand that the difference can hardly be noticed... There was a noticeable performance improvement when switching to the QByteArray serialization when multi-process was used.

Anyhow if for any reason such unrealistic use-case (hunders of fields in struct) is needed, "toByteArrayOverDBus" annotation for structs will relieve one from signature validation in libdbus and remove any possible overhead.

Lists of reasonably large structs should be supported with reasonable performance. That kind of list can easily contain up to hundred fields.

The annotation should be on struct level as they could cause overhead with their size not the interface.

Either an interface requires the interoperability feature and it needs to be carefully designed to perform well over IPC, or it does not use need interoperability (which is probably the most common situation) and it should benefit from an optimal serialization performance and not have any limitation in terms of signature length. The decision is based on how the interface is used, so I strongly believe that the annotation should belong to the interface definition.
Additional reasons:
- Data types can be used in multiple interfaces. Enabling the "toByteArrayOverDBus" flag on a type could affect some interfaces which need the interoperability features, making them unusable (or partly usable).
- Whether the signature length limit is reached or not depends on what types are packed together in a single DBus message. It could be that an interface using a large struct does not reach the limit, while another interface using the same struct hits the limit because it is used in combination with other large types.

Obviously the Multi-process part is in focus. My benchmarks don't show any measurable performance change in realistic cases, we are talking about less than fractions of ms per calls.
I can't believe the improvement you observed by switching to QByteArray was relevant to scope of this change.

Unless this has changed recently, your project is mostly single-process, so I understand that the difference can hardly be noticed... There was a noticeable performance improvement when switching to the QByteArray serialization when multi-process was used.

Lists/Maps doesn't increase the libdbus overhead, signature is increased only by "a()".
Obviously more data is transferred in case of lists but the cost is constant in both current implementation and current PR.
i.e. for each additional entry in the list it takes the same exact amount of time longer.

Lists of reasonably large structs should be supported with reasonable performance. That kind of list can easily contain up to hundred fields.

It is not a feature to be conformant with the DBus rules, it is a bug not to be.
The question is what is the default behavior rather than where annotation should go.
My analysis shows the serialization to ByteArray over DBus has very very small advantage in real use-cases so that it should be used for very corner cases (if at all required). We should encourage developers to design the interfaces more modular rather than using huge structs.
I see pros/cons in both.

Either an interface requires the interoperability feature and it needs to be carefully designed to perform well over IPC, or it does not use need interoperability (which is probably the most common situation) and it should benefit from an optimal serialization performance and not have any limitation in terms of signature length. The decision is based on how the interface is used, so I strongly believe that the annotation should belong to the interface definition.
Additional reasons:

Data types can be used in multiple interfaces. Enabling the "toByteArrayOverDBus" flag on a type could affect some interfaces which need the interoperability features, making them unusable (or partly usable).
No it is not how it works, the limit is per method argument not the accumulation of them.
Whether the signature length limit is reached or not depends on what types are packed together in a single DBus message, which means it depends on the interface definition. It could be that an interface using a large struct does not reach the limit, while another interface using the same struct hits the limit because it is used in combination with other large types (think about multiple method arguments, or multiple properties).


Amlogic AMCODEC support

Hey guys, I've setup my amlogic S802 android M8 box with openelec with video capture enabled in the build.
( http://freaktab.com/forum/tv-player-support/amlogic-based-tv-players/eny-acemax-em8-square-em6q-etc-devices/491016-openelec-5-0-8-eny-m8-2g-square-with-amcodec-boblightd-support-updated )
I've talked to the developer of this rom and he mentioned that Hyperion would need to add the amcodec hardware acceleration to its code.. not sure if anyone here could maybe look into it.
This is what he said: "At the moment only boblight is supported because boblight has included the hardware amcodec. My build of Openelec has enabled the amcodec to output to /dev/videocap0 so that boblight can pick it up and do its thing.
If this is the official github of hyperion https://github.com/tvdzwan/hyperion you can open an issue and ask for them to add amcodec support. You are better off asking them due to you having all the hardware that is required for hyperion."

Is this possible to fix? i see the XBMC addon hasn't been updated in a long time

If someone could do it, yes

Please see the other issue


Allow custom handling of nulls

Currently the way Reader/Writer handle nulls is hardcoded: null is always converted to and from Js.Null, and corresponding methods are final so they can't be overridden. However, sometimes it makes sense to handle nulls differently, for example, when overriding [de]serialization of options.
Is it possible to allow custom handling of nulls?

Yeah it would be nice to do this. Maybe you could move the null handling into the individual Readers/Writers to make them do the right thing? Worth a discussion/prototype

@netvl You may find https://github.com/lihaoyi/upickle/pull/43 relevant in case you embark on dealing with this.

+1, I need this as well.
Would it be feasible to switch order of read0 and read, so that Js.Null is converted to null only if read0.isDefinedAt(Js.Null) is false?

Duplicate https://github.com/lihaoyi/upickle/issues/40

Can we re-open this?  #40 was recently closed but I don't believe it addresses this issue -- that null is picked off incredibly early in the deserialization process in a way that can't be overridden.
I'd like to use uPickle on the browser but need to interoperate with other json generators that represent None[String] as null and the Option[String] as the string itself.
#40 allows one to represent Option[T] differently from the default -- but not as null and the string itself.

I just forked upickle, cloned and tried to run the tests.  Many of the tests completed successfully, but in the end I received the following errors:
[error] (pprintJS/*:update) sbt.ResolveException: unresolved dependency: com.lihaoyi#derive_sjs0.6_2.11;0.3.7: configuration not public in com.lihaoyi#derive_sjs0.6_2.11;0.3.7: 'test'. It was required from com.lihaoyi#pprint_sjs0.6_2.11;0.3.7 test
[error] (upickleJS/*:update) sbt.ResolveException: unresolved dependency: com.lihaoyi#derive_sjs0.6_2.11;0.3.7: configuration not public in com.lihaoyi#derive_sjs0.6_2.11;0.3.7: 'test'. It was required from com.lihaoyi#upickle_sjs0.6_2.11;0.3.7 test

I don't see a "derive" project in lihaoyi's github.  I do note there is a derive package in upickle-pprint.
Suggestions on how to proceed would be welcome.

You might need to bump the version up to 0.3.8-SNAPSHOT; SBT sometimes gets confused if the project has the same version as a cached artifact


Error in dcpg_train.py

Hi Christof,
Fantastic looking piece of software, but unfortunately I've encountered an error when starting to train the data.
~/scratch/deepCpG$ dcpg_train.py c1_*.h5 c3_*.h5 c5_*.h5 --val_files c2_*.h5 --dna_model CnnL2h128 --cpg_model RnnL1 --out_dir models --nb_epoch 30
Using TensorFlow backend.
INFO (2018-07-23 12:21:21,556): Building model ...
INFO (2018-07-23 12:21:21,558): Building DNA model ...
Traceback (most recent call last):
  File "/usr/local/bin/dcpg_train.py", line 4, in <module>
    __import__('pkg_resources').run_script('deepcpg==1.0.6', 'dcpg_train.py')
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 719, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1511, in run_script
    exec(script_code, namespace, namespace)
  File "/usr/local/lib/python2.7/dist-packages/deepcpg-1.0.6-py2.7.egg/EGG-INFO/scripts/dcpg_train.py", line 836, in <module>

  File "/usr/local/lib/python2.7/dist-packages/deepcpg-1.0.6-py2.7.egg/EGG-INFO/scripts/dcpg_train.py", line 194, in run

  File "/usr/local/lib/python2.7/dist-packages/deepcpg-1.0.6-py2.7.egg/EGG-INFO/scripts/dcpg_train.py", line 705, in main

  File "/usr/local/lib/python2.7/dist-packages/deepcpg-1.0.6-py2.7.egg/EGG-INFO/scripts/dcpg_train.py", line 571, in build_model

  File "/usr/local/lib/python2.7/dist-packages/deepcpg-1.0.6-py2.7.egg/EGG-INFO/scripts/dcpg_train.py", line 508, in build_dna_model

  File "build/bdist.linux-x86_64/egg/deepcpg/models/dna.py", line 117, in __call__
  File "build/bdist.linux-x86_64/egg/deepcpg/models/utils.py", line 448, in _build
AttributeError: 'Model' object has no attribute 'input_layers'

Any ideas on how I can fix this? Any help would be much appreciated.
Best,
Tim

Also, here are my versions of Keras and Tensorflow:
~/scratch/deepCpG$ python -c 'import keras; print(keras.__version__)'
Using TensorFlow backend.
2.2.0
~/scratch/deepCpG$ python -c 'import tensorflow as tf; print(tf.__version__)'
1.9.0

DeepCpG does not support Keras 2.2.X yet. Please downgrade to Keras 2.1.X. I am about to fix this.

Thanks Christof, all working now with Keras 2.1.6.
Cheers,
Tim


initializer element is not constant

static_consts.c
#include <srt/srt.h>
int32_t SRTGROUP_MASK_ = (1 << 30);
int SRT_LIVE_DEF_PLSIZE_ = 1316;
int SRT_LIVE_MAX_PLSIZE_ = 1456;
int SRT_LIVE_DEF_LATENCY_MS_ = 120;
SRTSOCKET SRT_INVALID_SOCK_ = -1;
int SRT_ERROR_ = -1;
int32_t SRT_SEQNO_NONE_ = -1;
int32_t SRT_MSGNO_NONE_ = -1;
int32_t SRT_MSGNO_CONTROL_ = 0;
int SRT_MSGTTL_INF_ = -1;
uint32_t SRT_GFLAG_SYNCONMSG_ = 1;

@oldma3095 can you describe your problem? I'm not getting it. Are you getting an error message? If so which libsrt are you using? On which OS? Or is it something entirely different?


grok api

can you use grok api instead of open ai ?

Do you mean Groq? Groq is pretty compatible with the openai API, but one major thing is that it doesn't support any vision queries. https://console.groq.com/docs/openai

yes that what i mean, Groq is very fast and free if we found a free vision api or local vision that well be great

Potentially Groq running llama3 with Ollama running Llava locally


removing backfill is not production ready sentence from README

The issue seemed quite vague. Without altering the original author's writing too much, removing that sentence does not give the user the indication that backfill is not production-ready.

Closing since this is an old PR from a repo and user that's been deleted


ModuleNotFoundError: No module named 'jinja2' when importing graphql_server.aiohttp

After installation
pip install graphql-server[aiohttp]

with output
...
Successfully installed graphql-core-3.2.0 graphql-server-3.0.0b5 typing-extensions-4.0.1

then attempt to import
from graphql_server.aiohttp import GraphQLView

gives
Traceback (most recent call last):
  File ".../main.py", line 9, in <module>
    from graphql_server.aiohttp import GraphQLView
  File ".../venv/lib/python3.9/site-packages/graphql_server/aiohttp/__init__.py", line 1, in <module>
    from .graphqlview import GraphQLView
  File ".../venv/lib/python3.9/site-packages/graphql_server/aiohttp/graphqlview.py", line 19, in <module>
    from graphql_server.render_graphiql import (
  File ".../venv/lib/python3.9/site-packages/graphql_server/render_graphiql.py", line 7, in <module>
    from jinja2 import Environment
ModuleNotFoundError: No module named 'jinja2'

so it looks like it needs to be included in install_aiohttp_requires?

@lycantropos I think this does not happen only to aiohttp but all of the packages that use GraphQLView:
❯ pip install graphql-server[sanic]

>>> from graphql_server.sanic import GraphQLView
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/theo.despoudis/Workspace/graphene/.venv/lib/python3.9/site-packages/graphql_server/sanic/__init__.py", line 1, in <module>
    from .graphqlview import GraphQLView
  File "/Users/theo.despoudis/Workspace/graphene/.venv/lib/python3.9/site-packages/graphql_server/sanic/graphqlview.py", line 21, in <module>
    from graphql_server.render_graphiql import (
  File "/Users/theo.despoudis/Workspace/graphene/.venv/lib/python3.9/site-packages/graphql_server/render_graphiql.py", line 7, in <module>
    from jinja2 import Environment
ModuleNotFoundError: No module named 'jinja2'


Rename cupy.core submodule to cupy._core

Rel #3420.
This PR renames cupy.core submodule to cupy._core to indicate it is CuPy's private submodule and not intended to be used by users.

@takagi This PR conflict with many on-going PRs each other. I will start reviewing after all v8 release blockers are resolved.

@takagi Could you resolve conflicts?

Discussed internally: we will be delaying this rename to v9 rc release because many PRs will start to conflict when this got merged.

Jenkins, test this please.

pfnCI, test this please.

Jenkins CI test (for commit ed53924999b7056f85764f6ea4388cada9e67d62, target branch master) failed with status FAILURE.

pfnCI, test this please.

Jenkins CI test (for commit ed53924999b7056f85764f6ea4388cada9e67d62, target branch master) succeeded!

@asi1024 Failed to backport automatically.

Not cleanly cherry-picked

Ignote the error above. This is because I added a label to run release note generator.


App Channels Test Cases (2.0)

all of this assumes using the 2.0 DesktopAgent API.  Changes from 1.2 are in bold
App Channels Broadcast (Basic)

App
Step
Details

A
1. getOrCreateChannel
const testChannel = await fdc3.getOrCreateChannel("test-channel")

A
2. addContextListener
Call const listener = await testChannel.addContextListener(null, handler)Check listener object returnedCheck that there is an unsubscribe function on the returned object

B
3. getOrCreateChannel
const testChannel = await fdc3. getOrCreateChannel("test-channel")

B
4. Broadcast
testChannel.broadcast(<some instrument>)

A
5. Receive Context
Instrument object matches the one broadcast in 2 above.

[ ] AC Basic Usage 1 Perform above test
[ ] AC Basic Usage 2 Perform above test, but perform steps in order 3,4,1,2,5

App Channels Broadcast (Filtered Context)

App
Step
Details

A
1. joinChannel
const testChannel = await fdc3.getOrCreateChannel("test-channel")

A
2. addContextListener
Call const listener = await testChannel.addContextListener("fdc3.instrument", handler)Check listener object returnedCheck that there is an unsubscribe function on the returned object

B
3. joinChannel
const testChannel = await fdc3. getOrCreateChannel("test-channel")

B
4. Broadcast
testChannel.broadcast() the instrument context.testChannel.broadcast() a contact context.

A
5. Receive Context
Instrument object matches the one broadcast in 2 above.Check that the contact is not received.

[ ] AC Filtered Context 1: Perform above test
[ ] AC Filtered Context 2: Perform above test, except B joins a different channel. Check that you don't receive anything.
[ ] AC Unsubscribe: Perform above test, except that after joining, A then calls listener.unsubscribe()s the channel. Check that A doesn't receive anything.
[ ] AC Filtered Context 3: Perform above test, except that after joining, A repeats steps 1 and 2, retrieving a second channel with a different name.  Check that A still receives context on the first channel (i.e. it is unaffected by retrieving a second channel).

App Channel History

App
Step
Details

A
1. joinChannel
const testChannel = await fdc3.getOrCreateChannel("test-channel")

B
2. joinChannel
const testChannel = await fdc3. getOrCreateChannel("test-channel")

B
3. Broadcast
testChannel.broadcast() the instrument context.testChannel.broadcast() a contact context.

A
4. Receive Context
const contextInst = await testChannel.getCurrentContext('fdc3.instrument') returns the last instrumentconst contextCont = await testChannel.getCurrentContext('fdc3.contact') returns the last contactconst contextLatest = await testChannel.getCurrentContext() returns the last broadcast chronologically (contact type)

[ ] AC Context History Typed: Perform above test.
[ ] AC Context History Multiple: B Broadcasts multiple history items of both types.  Only the last version of each type is received by A.

Ready for implementation @Joe-Dunleavy @ColinEberhardt

f.y.i AC Basic Usage 2 is not possible as 1 needs to happen before 2

@Joe-Dunleavy you are correct! It looks like it just didn't get deleted as it was redefined on the next line.

I've finished implementing these, they just need testing

I've created a draft PR for the app and user test cases: https://github.com/finos/FDC3-conformance-framework/pull/90

closing this.  Please refer to https://github.com/finos/FDC3/blob/conformance2.0/toolbox/fdc3-conformance/FDC3-2.0-Conformance-Test-Cases.md


Add some post deployment routing docs

Have rebased this, not sure whether it's still current, @rjw1? If so please click merge at your convenience


updated carapace

renamed C_CALLBACK to C_VALUE

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 45.2%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
339

Relevant Lines:
750

💛  - Coveralls


Question: mouse reference docs?

Hi,
Just curious, I'm new to variant calling and I'm not so familiar with some of the references (e.g. vcfindicies) or the specific index preparation preferred by GATK. The pipeline is extremely useful but it only points to a reference for human genomes. Is there somewhere mouse genomes are stored?
Thank you

Hi bkellman,
We don't provide support for non-human studies but perhaps you may get an answer from the gatk community by posting in the zoo and garden forum page.


fix #1284

local_ban is now required to see uncloaked IPs. Really, we should invent a new capability for this, but that's a more serious compatibility break because it would require adding the capability to existing operator blocks.


[terra-application-layout] Add EOL messaging and point to new nav

Feature Request
Add EOL messaging and point to new terra-application-navigation
Description
With the introduction of terra-application-navigation, we want to guide new consumers of terra application to the new component. With this we should add EOL messages and links to the new terra-applicaiton-navigation documentaion to the terra-application-layout and associated subcomponents.
Components:
terra-application-header-layout
terra-application-layout
terra-application-links
terra-application-menu-layout
terra-application-name
terra-application-utility
terra-navigation-layout
terra-navigation-side-menu
terra-layout
@ Mentions
@mjhenkes @tbiethman

To expand on dave's description, Lets limit this to adding warning text to the doc pages. Without secondary navigation we don't have a full on replacement for the existing nav but we do want to warn away any new consumers of these packages. At this time we shouldn't mark the npm packages as deprecated.


add support for icon packs in yubikey-code

Description
Adds support for using an icon pack with your accounts. When an icon pack is provided, the extension will try to find an icon automatically, but you can also manually select icons for each account.
Feature request: https://github.com/raycast/extensions/issues/10534
Screencast
https://github.com/raycast/extensions/assets/9059772/ef6cad57-693c-4c6c-b23b-54736ce840af
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

This is clean af! Thank you so much for this!


Fixed repetitive overridden styles caused by imports

Description
Fixed repetitive overridden styles caused by imports
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

@naimdanialjohar  The comments here are intentional

did not realise your comment before commenting to remove the commented code. approving this PR! 🚀


onlinemeetings link needs fixing in http area.

The http sample on this page states onlinemeeting which is not correct, its onlinemeetings. Should be fixed  I got stuck on this due to this doc issue...

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

ID: 13524c81-6f56-4a14-8c03-647a8baefb97
Version Independent ID: 58b1383d-86ed-c650-ebed-4d124a4cd9b1
Content: onlineMeeting: getAllTranscripts - Microsoft Graph beta
Content Source: api-reference/beta/api/onlinemeeting-getalltranscripts.md
Product: microsoft-teams
Technology: microsoft-graph
GitHub Login: @jacobsatora
Microsoft Alias: MSGraphDocsVteam

Exactly. Was super frustrating because that little typo there caused me much strife :)

Updated the doc through pull request https://github.com/microsoftgraph/microsoft-graph-docs/pull/23416

I cant view that, but Im sure someone can and will approve your pull :)

PR has been merged. So, closing the issue.


Hook the /nick command

Hook weechats' /nick command to set the discord nick

Thanks for opening the issue


⚠ Bofrost.de has degraded performance

In 7731d92, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1542 ms

Resolved: Bofrost.de performance has improved in a51c9bc after 38 minutes.


[WIP] Graphical styling

This makes the graphical print more pretty, and also cleans up a bit of the code. It's still WIP.

Actually, I'll merge this now to prevent conflicts with #44


Added fix for dynamic sessionServiceName

:+1: good catch @bmeyers22. I would love a test if you could add one (should be fairly easy to add).

@mixonic Won't the tests for the authenticatedRoute() DSL cover these changes?

As far as tests, I believe the correct place would be the configuration tests, which should already cover that configs defined can be read properly from the module

Seems like a basic test in https://github.com/Vestorly/torii/blob/master/test/tests/acceptance/routing-test.js would be appropriate, but with the session service name (like here) set to something other that session

@mixonic I wrote a test, let me know if this was the kind of thing you were looking for

@bmeyers22 perfect! Thank you. Can you rebase down to single squashed commit? I'd love to merge, I will push out beta.5 today and hopefully that is the last.

All set

:heart_eyes: thank you for the contribution!

In 0.6.0-beta.7


Fix kanister-operator helm release (#4328)

Fix kanister-operator helm release

@pavannd1 please try to merge after it gets approved to check if you can.