Bug: Home button always disabled

overview
The Home button is always disabled.

current behavior
I cannot home robot because the button is always disabled.

steps to reproduce
Version: 3.2.0-beta.3 for Linux
Firmware: edge-6168d32
I first noticed after quitting an unsuccessful calibration (#1849), but I can't be sure that that was the cause. This is also not reproducible on the Windows version of the app. Rebooting the robot and the app has no effect, it is disabled from the start.

expected behavior
Home button should almost never be disabled. If it is disabled for a legitimate reason, an explanation of the reason would be a nice feature.

@rvinzent to prevent problems, the "Home" button is disabled if either:
a) You are not connected to the robot (i.e. you have not yet clicked "Connect")
b) You are connected but the robot is currently running a protocol
I cannot reproduce the Home button being improperly disabled on v3.2.0-beta.3. Can you please confirm that the Home button in your app works if you click "Connect" first?
We just started work on (finally) integrating instructional tooltips into the app, so if you can confirm there isn't a bug, I'll rework this ticket into a feature request for a tooltip on this button

I clicked Disconnect and Connect again, and the Home button is still disabled. There is no protocol attached. I can confirm it's connected because I can turn the lights on and off. I'm not sure if it's relevant that our connection is over USB, but maybe that can help reproduce the problem.
It's almost as if I'm in a perpetual state of running a protocol, which might have something to do with the way I abruptly cancelled the calibration after the crash, but unfortunately I don't remember exactly what I did to cancel.
I was going to try to reupload the protocol and quit again to see if that triggers the "not running a protocol" state, and that made me realize that there is no way to detach you protocol or to quit everything related to that protocol on the calibration or run page. Even restarting the app doesn't remove my protocol. Rebooting the robot, however, does remove the protocol and disables the calibration pages, but it does not enable the Home button.
Here is a screenshot of my app view (the protocol page shows nothing attached):

Thanks for the screenshot, that's helpful. I will investigate further and continue to try to reproduce

Hey @rvinzent, we're still unable to reproduce over here. Tried every combination of OS (Mac, Linux, Win 10, Win 7) and connectivity (WiFi, wired) we have. Could you do me a favor and click the "More" button in the bottom left and send me a screenshot of the "App" page?
I can see that your robot is up to date (3.2.0-beta.3, which we re-released yesterday as v3.2.0 stable), but the only thing I can think of is that your app might not be up to date. I definitely think there's a mismatch, because if you app and robot are on the same version, that "Update" button on the "Information" card should read "Updated"

That seems to be the most likely cause. The app version appears to still be on v3.2.0-beta.1. Unfortunately, due to #1574 I cannot update the app. The latest package in the Ubuntu (16.04) archive is still v3.2.0-beta.1  as well.

@rvinzent sorry about the confusion there! Yes, unlike the OT-1, the app and the API are separate entities with the OT-2. For simplicity we version them together, and generally you're going to want to make sure their versions are lined up. Latest download link is now live on the on our download page as of today: http://opentrons.com/ot-app
I'm going to prioritize #1574 because we don't post beta versions anywhere public. I'll also look into starting to post them to GitHub releases, as well.
Closing because home button always disabled is expected in v3.2.0-beta.1 (actual home functionality was added in beta.2)


Add architectural support for shared interrupts

Problem description
Currently, there seems to be no architectural support for shared interrupts. As such, in the following sequence:

irq_connect_dynamic(33, INTID_33_PRIO, some_handler, some_argument);
irq_connect_dynamic(33, INTID_33_PRIO, some_other_handler, some_other_argument);

some_other_handler would overwrite some_handler. Currently there seem to be 2 ways to solve this:

Make use of the intc_shared_irq.c interrupt controller => doesn't scale very well, seems to require a DT node per shared IRQ. Problematic on platforms which have multiple shared IRQs (e.g: i.MX8QM which has the same INTID for groups of x channels)
Handle this yourself in your driver/application => somewhat difficult and annoying in situations such as the one described above. Needs to be done per module which uses a shared IRQ.

Proposed change
As as a way to solve the problem described above, we could add architectural support for shared interrupts. This could be achieved by simply registering a "dummy" ISR for an INTID and calling all registered ISRs for that INTID.
Detailed RFC
More specifically, if the SHARED_IRQ feature is enabled, we could overwrite z_isr_install() such that instead of registering the passed routine and argument in the ISR table, we could register our own "dummy" ISR and pass it a list of routine/arg pairs that it needs to invoke.
The following is a draft of how this could be achieved:
struct shared_irq_client {
    void (*routine)(const void *arg);
    const void *arg;
};

struct shared_irq_data {
    bool enabled;
    struct shared_irq_client clients[CONFIG_SHARED_IRQ_MAX_NUM_CLIENTS];
    uint32_t client_num;
};

static struct shared_irq_data shared_irq_table[CONFIG_NUM_IRQS];

void shared_irq_isr(const void *data)
{
    struct shared_irq_data *irq_data = data;
    int i;

    for (i = 0; i < irq_data->client_num; i++)
        irq_data->clients[i].routine(irq_data->clients[i].arg);
}

/* note: this definition of z_isr_install would overwrite the definition from sw_isr_common.c */
void z_isr_install(unsigned int irq, void (*routine)(const void *), const void *param)
{
    ... some code goes here ...
    /* note: this is only done once per INTID, upon enabling it for the first time */
    _sw_isr_table[table_idx].arg = irq_data;
    _sw_isr_table[table_idx].isr = shared_irq_isr;

    ... some code goes here ...
    /* irq_data points to the entry in shared_irq_table corresponding to passed IRQ */
    irq_data->clients[irq_data->client_num].routine = routine;
    irq_data->clients[irq_data->client_num].arg = param;
    irq_data->client_num++;
}

Dependencies
This feature would be something one can enable/disable with a configuration. As such, if CONFIG_SHARED_INTERRUPTS=y, z_isr_install would have the above definition. Otherwise, the default definition from sw_isr_common.c will be used. In theory there should be no dependencies.
Would this change be something desired by the community? If so, I can submit a PR after I have something functional.

With my current project I actually have a real world usecase for this. I need 3 i2c ports on the STM32G0B1, and ports 2 and 3 share IRQs. Using non-IRQ mode is not possible because port 2 needs to run in slave mode (which forces the needs for IRQs). Also I'll need the two CAN ports, and they also shared IRQ's.
So I hope the PR #61422 to this issue lands in main soon :-)

@lowlander yes, this should land in zephyr once Laurentiu gets back from vacation next week. I wonder if you could do some testing and provide your feedback.

Feature was addressed in https://github.com/zephyrproject-rtos/zephyr/pull/61422, closing.


No compatible version error when buildpack doesn't contain the newest available version

What happened?

What were you attempting to do?

Building and running an app image (console app) that contains a console.csproj file with <RuntimeFrameworkVersion>2.1.*</RuntimeFrameworkVersion> in it.

What did you expect to happen?

The container to successfully run, using the versions specified by the buildpacks.

What was the actual behavior? Please provide log output, if possible.

I used the dotnet-core v0.1.3 language family buildpack  to build the app image. It selected dotnet-runtime version (using console.csproj): 2.1.25, the latest 2.1 version supported in the buildpack as expected.
Then, I ran docker run -it -p 8080:8080 console and it errored with:
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.1.26' was not found.
  - Check application dependencies and target a framework version installed at:
      /workspace/.dotnet_root/
  - Installing .NET Core prerequisites might help resolve this problem:
      https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.25 at [/workspace/.dotnet_root/shared/Microsoft.NETCore.App]

When running the container, the error message shows that 2.1.26 is pulled in. This is pulled in by the .NET CLI itself, since that is the most current version available. When using the buildpacks, I would expect that the version the buildpack is pulling in would be the one that ends up on the image. We should find a way to avoid having the .NET CLI overruling the version selection.
Build Configuration

What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
using? Please include a version.

pack 0.17.0

What buildpacks are you using? Please include versions.

dotnet-core v0.1.3
Checklist

[X] I have included log output.
[X] The log output includes an error message.
[X] I have included steps for reproduction.

.NET 2.1 is no longer supported in the buildpack, and so this buildpack always builds a framework-dependent executable by default (see Microsoft docs for explanation of different dotnet CLI behaviour for different .NET Core SDK versions). Since framework-dependent executables can be invoked directly, without the dotnet CLI, this problem no longer crops up for the provided sample app.


Break RPC interface

Maybe cli reckless install summary is better than cli install_plugin summary ?

Hmm but it would breaks all those nice descriptions...


Scoreboard editor

Your Mod is Great But it doesn't have this feature
scoreboard editor with:
resizing feature
red numbers remover
background remover
and more related to scoreboard

This Seems out of Scope for this project, but maybe in the future, right now this mod and many others exist https://modrinth.com/mod/ugly-scoreboard-fix

Nvm, their mods kinda annoying, ill see what I can do about coding similar features


Text overlaps other text

On the docs.html page, some of the paragraphs overlap each other.
Display Resolution:
1366x768

Ah, I love that resolution, reminds me of my old laptop 🙃
Anyways yeah, I will get to this when I have time, thank you for reporting this!

If I get the chance, I'll see if I can fix it, but last time I tried to fix something, it broke a bunch of other stuff so...

You can always try if you want to, however I will look into this when I can for sure. Just busy with work and stuff sadly, so that is why I have been unable to right now.

Pushed a fix, should be better but not perfect, will look to better alternatives later :)

Ooopsies, my bad. When creating the website I ignorantly forgot to try other screen sizes...


Fail to connect with Netezza database when using virtualenv to include the python package

Environment details:
Mac OS: 10.12.3 , docker version: 17.03.1-ce-mac5, python3, virtualenv
Steps to reproduce the issue:

Including jaydebeapi, Jpype packages and jar-file of driver required for connecting netezza database in virtualenv site package
Uploading the zip file as a python3 action

Provide the expected results and outputs:
Connect to Netezza database successfully

Provide the actual results and outputs:
Fail to compile the included packages

Additional information you deem important:

issue happens only occasionally or under certain circumstances
changes you did or observed in the environment

@bigmianhua have you tried the following procedure by building the .zip in the target environment rather than on the client environment?
https://github.com/apache/incubator-openwhisk/blob/master/docs/actions.md#packaging-python-actions-with-a-virtual-environment-in-zip-files
especially using this command:
docker run --rm -v "$PWD:/tmp" openwhisk/python3action sh \
  -c "cd tmp; virtualenv virtualenv; source virtualenv/bin/activate; pip install -r requirements.txt;"


Increment version for monitor releases

Increment package version after release of azure-opentelemetry-exporter-azure-monitor

@deyaaeldeen I assume this is an automated process to increase the version for next release, azure pipelines have a requirement for new version to be in the CHANGELOG so this will never pass the checks, would be good to update the automated process used here.

@deyaaeldeen I assume this is an automated process to increase the version for next release, azure pipelines have a requirement for new version to be in the CHANGELOG so this will never pass the checks, would be good to update the automated process used here.

@deyaaeldeen I assume this is an automated process to increase the version for next release, azure pipelines have a requirement for new version to be in the CHANGELOG so this will never pass the checks, would be good to update the automated process used here.

@praveenkuttappan, to @hectorhdzg 's point above - I was pretty sure the auto-version-updater also inserted a new section into the changelog.md as well when it incremented the version. Is this something @hectorhdzg needs to opt into somehow?
(kind of like this one: https://github.com/Azure/azure-sdk-for-js/pull/13270)

@deyaaeldeen I assume this is an automated process to increase the version for next release, azure pipelines have a requirement for new version to be in the CHANGELOG so this will never pass the checks, would be good to update the automated process used here.

@praveenkuttappan, to @hectorhdzg 's point above - I was pretty sure the auto-version-updater also inserted a new section into the changelog.md as well when it incremented the version. Is this something @hectorhdzg needs to opt into somehow?
(kind of like this one: https://github.com/Azure/azure-sdk-for-js/pull/13270)

@richardpark-msft @hectorhdzg there is a problem with versioning here which might have to do with the CI failure. This package mixes preview and beta for some reason even though this is not allowed. We have this warning: Version [1.0.0-beta.3] is older than the latestversion [1.0.0-preview.6] in the changelog. Please use a more recent version in the release pipeline here: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=694567&view=logs&j=a1d9647f-8dc0-576b-b75e-f0d4533ebd0e&t=8edb2f73-5db6-5e76-274b-8d5087ebdf9c&l=15.

@richardpark-msft @hectorhdzg there is a problem with versioning here which might have to do with the CI failure. This package mixes preview and beta for some reason even though this is not allowed. We have this warning: Version [1.0.0-beta.3] is older than the latestversion [1.0.0-preview.6] in the changelog. Please use a more recent version in the release pipeline here: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=694567&view=logs&j=a1d9647f-8dc0-576b-b75e-f0d4533ebd0e&t=8edb2f73-5db6-5e76-274b-8d5087ebdf9c&l=15.

Related: #13210
cc @chidozieononiwu for changelog update question

Related: #13210
cc @chidozieononiwu for changelog update question

The changelog for this package is in an invalid state. There weren't even any preview.5/6 versions released and we should probably just remove those or merge them with the beta.1 change log. I suspect this might have happened because of the renaming of this package.

The changelog for this package is in an invalid state. There weren't even any preview.5/6 versions released and we should probably just remove those or merge them with the beta.1 change log. I suspect this might have happened because of the renaming of this package.

Manually fixing this with this PR. Am merging preview.5 and preview.6 release notes into beta.1 as @weshaggard  suggested. The bug that caused this will be resolved by this PR, there should be no subsequent issues. Apologies for the inconvenience.

Manually fixing this with this PR. Am merging preview.5 and preview.6 release notes into beta.1 as @weshaggard  suggested. The bug that caused this will be resolved by this PR, there should be no subsequent issues. Apologies for the inconvenience.


Monaco editor flickers while typing

This editor flavor has a really bad flickering problem that has appeared recently. I only noticed it the past few days, but @ChaiTRex on the Rust discord said that they saw it a few weeks ago.
Verified on both Windows and MacOS, both Chrome and Firefox.
(gif of the issue)

observed since the past couple days

That would have made sense as we upgraded dependencies a few days ago...

they saw it a few weeks ago

...but this indicates that it's something else.

Downgrading from react-monaco-editor 0.51.0 to 0.50.1 appears to fix the flicker, so I'm tagging this as an upstream issue.

Same issue. Version downgrade helped

This has theoretically been fixed upstream and I'm upgrading to that version in #906. That should be merged and deployed in the next few days. Let me know if you see unexpected behavior. I'm going to close this optimistically 🤞 .


PR for moving REST Device Service out of holding

This dummy PR is for capturing comment on moving the REST Device Service out of holding.
Please review the code/docs/configs on the master branch and add your comments to this PR.
https://github.com/edgexfoundry-holding/device-rest-go/tree/master

example endpoints in Testing/Simulation section should be http://localhost:59995/api/v1/resource/{deviceName}/{resourceName}

@hahattan , Good Catch! Thx

First, there's some misunderstanding about the PR for moving a repository from the edgex-holding organization to the edgexfoundry organization. Using a PR gives us to things:

it allows us to record comments and actual approval from one (or ideally more) project developers. Ideally once moved, the -holding repository is archived, but this review PR (and the reviewers's approval and comments are still available for historic purposes.

it allows the submitter to provide some basic information to the reviewers as described by our current process for moving a new device service out of holding. Think of this like a PR description that you'd like someone to return. The information asked for every new service includes:

What types of device are supported.
What protocol features are supported / likely to be supported in future.
What limitations does the existing implementation have.
What hardware and software has it been tested against.
What release of EdgeX is this intended for?

I also don't think this PR should be used to propose changes to the service either (i.e. there should be no commits associated with this PR).

I've assigned 49986 as the default port for device-rest

@tonyespy, see my responses below.

Here's my review, but I'm not explicitly approving until we have agreement on how and what needs to be resolved (and whether we just open issues for each). Without further adieu, here are my comments:

The first commit "Create README.md" lacks signoff

Not sure how this happened. Strange that it is verified, but not signed-off ... Not sure how to fix this since unable to use rebase due to this being the very first commit.

The code seems to be pretty light with respect to comments... [nit]

I feel the code is written in a way that it can be understood without a bunch of comments.

README.md

Runtime Requisite(s) should be Runtime Prequisites, although I question why you even need to include this, as every device service requires both Core Data and Core Metadata to function currently.

Ok, on the renaming. It is still useful for someone not as familiar with the project.

REST Endpoints

devices are not defined in device profiles and the configuration.toml. A device profile describes a class of devices. Also device is a standard model and can be added via REST calls to Core Metadata, via a go SDK function/method, or via configuration.

How about something like: _refers to the device name of the device profile to use.

I would suggest the following text for resourceName: refers to the device resource defined in the device profile associated with the given deviceName.

Ok

I thought we were trying to move away from sending or receiving just strings (or other types) and wanted to move towards have requests and responses. The endpoint here seems to just accept a string (any length restriction) or a binary blob. If we're not going to pass a request object, then I think at minimum we should require a Content-Header (e.g. image/jpeg).

There isn't a know request object. What would we do with the Content-Header if we required it. The main usage of this DS in our use cases is to send in JSON strings.

Configuration

This says you can send JSON data, binary data or number (numeric?) data. This seems confusing because the previous section says you can send text or binary data.

In the note just above Configuration it explains that The text is casted to the specific type of the specified device resource once it passes type validation.

Why does DeviceList.Protocols.other need to specified?

Because SDK is requiring something under DeviceList.Protocols. Gives an error if I don't have it.

Device Profile

do these device profiles work w/out Core Commands defined? I seem to recall a requirement that device profiles always include this section?

Yes. DeviceCommands is required, but CoreCommands is not.

In sample-binary, how come the PostBinary resource command only defines a "get" operation? I thought reads weren't supported?

This is how DeviceCommands work. It is getting the data from the device. It throw me off at first also. Same in the other device profiles.

Testing / Simulation - some sample POST bodies would be helpful in this section.

ok

Commanding - I would move this to the top, and drop the word "Commanding". Instead just describe the service as only supporting asynchronous readings, and state that the service doesn't support any commands (read or write).

ok

Attribution.txt doesn't seem to match up with the 3rd party packages used by this device service. Also while looking at this, it appears that the sample Attribution.txt in device-sdk-go hasn't been kept up to date, and I'm not sure how a device service developer is supposed to know they're required to ship this file with any binary distribution of a device service.

I reran the ./bin/test-attribution-txt.sh script and it doesn't identify anything missing. What to you see wrong? As for the SDK, there is an issue I created for this (https://github.com/edgexfoundry/device-sdk-go/issues/399) which has been addressed.

Dockerfile - doesn't include the LICENSE or Attribution.txt

Licence is in header and a lable on image:
LABEL license='SPDX-License-Identifier: Apache-2.0' \   copyright='Copyright (c) 2019: Intel'
What are you expecting for Attribution.txt?

cmd/main.go - use of bootstrap precludes usage of SetOverwriteConf method

This is how latest device-mqtt's & device-virtual's main work. How should it work? @cloudxxx8 ??

driver/restdriver.go

code lines are long, why wrap the godoc?

I have NP wrapping code. Wrapped comments for readability.

driver/resthandler_test.go

no copyright / license header!

Yep, missed that one.

First, there's some misunderstanding about the PR for moving a repository from the edgex-holding organization to the edgexfoundry organization. Using a PR gives us to things:

it allows us to record comments and actual approval from one (or ideally more) project developers. Ideally once moved, the -holding repository is archived, but this review PR (and the reviewers's approval and comments are still available for historic purposes.

it allows the submitter to provide some basic information to the reviewers as described by our current process for moving a new device service out of holding. Think of this like a PR description that you'd like someone to return. The information asked for every new service includes:

What types of device are supported.
What protocol features are supported / likely to be supported in future.
What limitations does the existing implementation have.
What hardware and software has it been tested against.
What release of EdgeX is this intended for?

I also don't think this PR should be used to propose changes to the service either (i.e. there should be no commits associated with this PR).

@tonyespy , Are you expecting separate PR(s) for addressing this PR's feedback? That seems a bit strange and disconnected to me... Also, current process is to move the repos from holding, not archive them. Thus once they are in the main org, the history from holding is retained.

@tonyespy, see my responses below.

Here's my review, but I'm not explicitly approving until we have agreement on how and what needs to be resolved (and whether we just open issues for each). Without further adieu, here are my comments:

The first commit "Create README.md" lacks signoff

Not sure how this happened. Strange that it is verified, but not signed-off ... Not sure how to fix this since unable to use rebase due to this being the very first commit.

$ git rebase -i --root

The code seems to be pretty light with respect to comments... [nit]

I feel the code is written in a way that it can be understood without a bunch of comments.

I think there are some parts of the code that aren't entirely obvious, but I'm not going to hold up the PR for this.

REST Endpoints

devices are not defined in device profiles and the configuration.toml. A device profile describes a class of devices. Also device is a standard model and can be added via REST calls to Core Metadata, via a go SDK function/method, or via configuration.

How about something like: _refers to the device name of the device profile to use.

That's still not quite right. In this case, deviceName simply refers to the device managed by this device service.

I thought we were trying to move away from sending or receiving just strings (or other types) and wanted to move towards have requests and responses. The endpoint here seems to just accept a string (any length restriction) or a binary blob. If we're not going to pass a request object, then I think at minimum we should require a Content-Header (e.g. image/jpeg).

There isn't a know request object. What would we do with the Content-Header if we required it. The main usage of this DS in our use cases is to send in JSON strings.

Sure, but you're also providing binary support, and I think having the incoming endpoint accept an arbitrary binary payload as a POST request without a Content-Header isn't especially wise (i.e. and would seem ripe for a targeted attack). As for what we could do with it? You could ensure that it matches the MediaType of the given device resource, and if not return an error.
For string POST requests, the Content-Header should probably be required to be set as "text/plain".

Configuration

This says you can send JSON data, binary data or number (numeric?) data. This seems confusing because the previous section says you can send text or binary data.

In the note just above Configuration it explains that The text is casted to the specific type of the specified device resource once it passes type validation.

I'm just saying there really are two data types supported for import using this endpoint, string and binary, with the former having support for casting to the native non-binary data types supported by EdgeX. In your configuration sample-json and sample-numbers, both are examples that support an POST specifying a string, which is cast to one of the native types, so that's why having three profiles is a slightly bit confusing. That said I'm willing to punt on this one. If you do keep them, I still would suggest re-naming sample-json to sample-string.

Why does DeviceList.Protocols.other need to specified?

Because SDK is requiring something under DeviceList.Protocols. Gives an error if I don't have it.

Ugh, OK. Does this end up generating the real string "other" in the ProtocolProperties map? If so, seems a bit superfluous (i.e. it's not really used for anything).

Device Profile

do these device profiles work w/out Core Commands defined? I seem to recall a requirement that device profiles always include this section?

Yes. DeviceCommands is required, but CoreCommands is not.

OK

In sample-binary, how come the PostBinary resource command only defines a "get" operation? I thought reads weren't supported?

This is how DeviceCommands work. It is getting the data from the device. It throw me off at first also. Same in the other device profiles.

Well you could re-name the device command to GetBinary. But when a new incoming value is pushed to the service via REST, the deviceResource name is what gets inserted into the new Reading right? In this case, the fact that there's a corresponding device command is not really accomplishing anything here... I know @iain-anderson had proposed some additional device profile simplifications, but I'm not sure we've committed to do these for Geneva. Let's bring this up at next week's WG meeting.

Attribution.txt doesn't seem to match up with the 3rd party packages used by this device service. Also while looking at this, it appears that the sample Attribution.txt in device-sdk-go hasn't been kept up to date, and I'm not sure how a device service developer is supposed to know they're required to ship this file with any binary distribution of a device service.

I reran the ./bin/test-attribution-txt.sh script and it doesn't identify anything missing. What to you see wrong? As for the SDK, there is an issue I created for this (edgexfoundry/device-sdk-go#399) which has been addressed.

I have to admit, I wasn't aware of the existence of test-attribution-txt.sh, so I didn't realize this file was auto-generated and in fact recursively walked all of the dependencies. I'll discuss @anonymouse64, as maybe it would be a good idea to add a "# auto-generated by test-attribution-txt.sh; DO NOT EDIT to the top of each auto-generated Attribution.txt file.

Dockerfile - doesn't include the LICENSE or Attribution.txt

Licence is in header and a lable on image: LABEL license='SPDX-License-Identifier: Apache-2.0' \ copyright='Copyright (c) 2019: Intel'
What are you expecting for Attribution.txt?

First, many license still require the license text to be included in any binary distribution, so while you've identified the docker image as containing software licensed under Apache 2.0, you haven't included the license file itself. This may not be required by Apache 2.0, but in general it's good practice. In the snaps, we always copy Attribution.txt and LICENSE to /usr/share/doc/<thing>/ similar to the way debian packages work.

cmd/main.go - use of bootstrap precludes usage of SetOverwriteConf method

This is how latest device-mqtt's & device-virtual's main work. How should it work? @cloudxxx8 ??

The SetOverwriteConf was just recently merged into device-sdk-go, and released as 1.1.1. For Geneva, in theory we have the freedom to break the API and will add an overwrite-conf parameter to NewService and maybe even startup.Bootstrap. @cloudxxx8 is there an issue to track this change for Geneva.

driver/restdriver.go

code lines are long, why wrap the godoc?

I have NP wrapping code. Wrapped comments for readability.

OK, looks a bit odd, which is why I mentioned it. It passes gofmt, so let's leave as is.

First, there's some misunderstanding about the PR for moving a repository from the edgex-holding organization to the edgexfoundry organization. Using a PR gives us to things:

it allows us to record comments and actual approval from one (or ideally more) project developers. Ideally once moved, the -holding repository is archived, but this review PR (and the reviewers's approval and comments are still available for historic purposes.

it allows the submitter to provide some basic information to the reviewers as described by our current process for moving a new device service out of holding. Think of this like a PR description that you'd like someone to return. The information asked for every new service includes:

What types of device are supported.
What protocol features are supported / likely to be supported in future.
What limitations does the existing implementation have.
What hardware and software has it been tested against.
What release of EdgeX is this intended for?

I also don't think this PR should be used to propose changes to the service either (i.e. there should be no commits associated with this PR).

@tonyespy , Are you expecting separate PR(s) for addressing this PR's feedback?

No, I think the review PR should have a single empty commit which just says something like:
Move repo to github.com/edgexfoundry
If you address comments in the PR review, just commit them to master, push them directly, then re-base this PR (which is easy as there no changes to the tree) and force-push it.

That seems a bit strange and disconnected to me... Also, current process is to move the repos from holding, not archive them. Thus once they are in the main org, the history from holding is retained.

Ah OK, I wasn't exactly sure that's what happened. If so, then it's ideal as the empty move commit will exist, and the PR history will be preserved too.


0.9.14-prerelease1

Prerelease 1 for version 0.9.14

Codecov Report

Merging #1595 (b9f2c8c) into main (3c6f6f8) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@          Coverage Diff          @@
##            main   #1595   +/-   ##
=====================================
  Coverage   7.27%   7.27%
=====================================
  Files         44      44
  Lines      15416   15416
=====================================
  Hits        1122    1122
  Misses     14235   14235
  Partials      59      59


Align review comments UX and diff buttons UX

See here:

Since both components are very similar, why not align them:

same border width for the vertical lines
same button feedback when you hover

@hediet I think the diff button looks a bit nicer, so I would change comments in the following ways:

animation
give "+" button a border

Per https://github.com/microsoft/vscode/issues/209627, I will not add a border to the comment buttons.

After spending the afternoon on this, I am stumped on how to do the animation of the comments button fading in and out. The situation:

As an editor gutter decoration, I can choose which css classes get added to the HTML element that gets added for my decoration.
My decoration doesn't use :hover, instead when the whole line is hovered it shows.
I can create a transition when the element is added to the dom using @starting-style ✅
I can't come up with a way to fade the element out when the line is un-hovered, as the dom element is simply removed.
Similarly, to make the fade in look nice the commenting range vertical line would also need to fade out when it's removed, which has the same problem.

For my own reference later, this is what I can do for the fade-in
.monaco-editor .comment-range-glyph.line-hover:before {
	background: var(--vscode-editorGutter-commentRangeForeground);
	opacity: 1;
	transition: opacity 0.3s;

	@starting-style {
		opacity: 0;
	}
}


added ky to Competition area

I added ky to the competition area

Thanks for the suggestion; I would add it but Sorhus and I don't seem to be on good terms for some reason so I'm avoiding using or linking to his projects for the time being.


Removed unused return from Cloudflare

Description:
https://github.com/home-assistant/home-assistant/pull/15388#discussion_r201280286

Removed this return based on this comment.

local testing indicates everyrhing works without this.
This is an addition to https://github.com/home-assistant/home-assistant/pull/15388
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[ ] The code change is tested and works locally.
[ ] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Can be merged when build passes.


Simulcast doesn't work in Chrome >= 60

Description
Simulcast doesn't work on Chrome >= 60.
Steps to reproduce the issue:

Install vanilla Licode
open basicexample in whatever chrome version and publish a stream with ?simulcast=true
open basicexample in another computer with chrome >= 60 (from current beta) with ?onlysubscribe=true

Describe the results you received:
opening basicexample/quality_layers.html we can see that estimated bandwidth is 0kb
Describe the results you expected:
we should see the black bar of the estimated bandwidth growing.
Additional information you deem important (e.g. issue happens only occasionally):
seems that Licode doesn't receive any REMB. They are correctly negotiated according to sdps but no REMB is received (or maybe we don't parse them correctly? (I don't think so)).
from SenderBandwidthEstimationHandler:
// TODO(pedro) Implement alternative when there are no REMBs
Licode commit/release where the issue is happening
78599cd53f8e90a2314b12f40344e513f49f914d
Additional environment details (Local, AWS, Docker, etc.):
AWS EC2

@jcague @lodoyun Do you think it's a Chrome or a Licode bug?
I'm starting thinking that it's a Chrome problem.
The fact is that the current beta will be released in 7 days so we might consider opening a ticket in monorail and / or  switch to another approach without the use of rembs.
At this purpose:

Can you suggest me some method to debug if chrome is correctly sending rembs? I tried wireshark but it cannot decode rembs or maybe I am using wrongly. (I only see RR and SR, even with chrome 59 that does work).
I also tried to enable webrtc logging in chrome but it doesn't tell me if is sending REMBS (tried with webrtc log level 5)
Why in SenderBandwidthEstimationHandler we call UpdateReceiverBlock only if we already have received rembs? cannot the algo works only with RR? I tried to force the update once every RR comes in, even without rembs, but seems that the estimation continues growing until reach the 100M limit. It reacts to fluctuation (it degrades on packet lost ) but grows faster than it decrease.

I was able to reproduce, thanks @kekkokk! seems like Chrome is actually sending REMB, but we don't handle them properly somehow. We'll investigate it further next week.

btw, I used the event log in webrtc-internals

which generates a file that can then be translated to a .pcap with Fippo's tool: https://github.com/fippo/dump-webrtc-event-log
And .pcap files can be read by Wireshark.
It's better than using Wireshark directly in the network interface because packets are decrypted.

precious information, thanks!


Rename the store: module to hist: or fold it into edit:?

I was working on a trivial documentation cleanup change and noticed the store: module reference. It seems to me it should be named hist: or history: to better reflect the purpose of the module. The current name appears to have been influenced by the choice to use Go package bbolt which implements a key/value "store" model.
On the other hand, note that edit:command-history exists as a means of enumerating the command history. The fact the example is no longer valid isn't the point. What is important is that the edit: namespace provides mechanisms for interacting with the interactive command history. So, should the facilities in the store: module be moved to the edit: module? Should the store: module be renamed and edit:command-history moved into it? Status quo? Something else?

From the 0.13 release notes:

The edit:history:list function has been removed. There is no replacement yet.

See also, issue #409 and #884 which suggests @xiaq is leaning towards a new module, separate from edit, for managing command history. So this might be a duplicate of #884. However, I'm not a fan of calling the new module fuser or fused :smile:

The intention is that it will eventually expose everything supported by the Elvish store but little work has been done.
I filed #1032 and am closing this.

Re folding into edit:: it is now only used by the editor, but it should be possible to use the store independently of the interactive editor.


Add Issues (Improve the Docs) to left panel

Issues is buried in the menu and not easy to find. Add the link to the menu.

done


if dropdown has typeahead directive, typeahead-template-url is working wrong.

I was found that if dropdown directive has typeahead directive, typeahead-template-url is working wrong.
so demo is here
http://plnkr.co/edit/8dvPHYP98YHulObIxdXd?p=preview
I was digging it. The problem is that typeahead popup template has ui.dropdown-menu element and dropDownMenu directive applied template-url instead of typeaheadMatch directive.
To solve the problem is, default 'template/typeahead/typeahead-popup.html' has wrapping dummy div
and I hope to support typeahead-popup-template-url like datepickerPopupConfig constants
here is PR
https://github.com/angular-ui/bootstrap/pull/4238

This should no longer be an issue in 1.0 with the non-prefixed directives removed.


Add files via upload

@mitalrs please add my profile card

@Swadeshit27
have you done proper work as instructed in README.md file
because I'm not able see your folder

@mitalrs I have update this. please check  #63


vue-remark remark plugin to preprocess frontmatter data

Hi there,
Thanks for the Gridsome project & vue-remark plugin, I'm enjoying it so far!
Now, I'm trying to preprocess the frontmatter data of my Markdown files before that data reach the GraphQL layer. Are any remark plugin supposed to work?
The plugins modifying the markdown / mdast work perfectly.
However, my plugin trying to modify the frontmatter data doesn't.
How can one achieve that?

More info :
Remark plugins receive 2 params :

tree the mdast tree
file the vfile

vue-remark seem to remove the frontmatter node and store 3 things in the file.data :

data the frontmatter data
layout the layout component infos
resourcePath the Markdown path

doing that before reaching plugins.

Can someone tell more about the vue-remark architecture and how to preprocess frontmatter data before it reaches the GraphQL layer?
Thanks a lot.

In that issue https://github.com/gridsome/gridsome/issues/707#issuecomment-535996112, someone pointed out :

It appears that markdown is being processed first, and then the remark plugins are running after the fact.

So maybe a better place to preprocess Markdown frontmatter data is in the gridsome.server.js eventually. With the Data Store API and manually using remark at that moment.
If so, it may be worth noting that in the documentation to save some time to other users :)

https://github.com/gridsome/gridsome.org/pull/448

can we have a more practical example please. I still didn't figure out how to add the frontmatter data to the Graphql layer

This caught me out as well. Would it make sense to add this comment directly to the vue-remark docs as well? (I didn't think to look in the server-api docs...)


Update config to include 3 builds

Since first merge there have been already few rebuilds, hence we can bring this back to three.

Part of #51


Remove <1.19.30 modules when 1.19.40 stable releases

Remove pre 1.19.40 modules such as mojang-minecraft, mojang-gametest, mojang-minecraft-ui, mojang-minecraft-server-admin and mojang-net from package.json because they won't work in script api.

NO

just move it to a branch 😡


The ListArgumentBuilder should be able to accept a list that uses Suggestion Info, not just a CommandSender

Description
We can currently create dynamic lists for the ListArgument using the supplier method:
public ListArgumentBuilder withList(Supplier<Collection<T>> list);

as well as using this function method that accepts a CommandSender:
public ListArgumentBuilder withList(Function<CommandSender, Collection<T>> list);

However, these two methods don't let you specify lists based on the current input. Since the list declarations are used directly by suggestions, there's no reason why the CommandAPI should be hiding this functionality away.
Expected code
In ListArgumentCommon, we'd have to change the supplier to use SuggestionInfo, and ensure this is applied:
private void applySuggestions() {
	this.replaceSuggestions((info, builder) -> {
		String currentArg = info.currentArg();
		if(text && currentArg.startsWith("\"")) {
			// Ignore initial " when suggesting for TextArgument
			currentArg = currentArg.substring(1);
			builder = builder.createOffset(builder.getStart() + 1);
		}

		// This need not be a sorted map because entries in suggestions are
		// automatically sorted anyway
		Set<IStringTooltip> values = new HashSet<>();
-		for (T object : supplier.apply(info.sender())) {
+		for (T object : supplier.apply(info)) {
			values.add(mapper.apply(object));
		}

Extra details
For 9.0.0, I think it's safe to hard-replace withList(Function<CommandSender, ...>) with withList(Function<SuggestionInfo, ...>). We'll include it in the upgrading guide with the relevant instructions for upgrading.

Implemented in 9.0.0.


Behaviour of Replication::aggregate

Describe the bug
Was a TODO in source code.
At least for now we will replicate the previous behaviour of
skipping automatic aggregation when using the redis-sentinel backend
because $nodes contains an array of sentinel servers instead of Redis
servers and SentinelReplication already gets the list of sentinels in
the first argument of its constructor. SentinelReplication::add()
actually knows how to handle connections marked with role=sentinel in
their parameters but relying on it would require an explicit role to
be set by the user and I would like to avoid enforcing that for now.
https://github.com/predis/predis/blob/c201af5ad308dd419ddc2494bb7fecaf8a8cd570/src/Configuration/Option/Replication.php#L109-L122

Can you describe how it affects you?


NotificationOptions.requireInteraction

Also moved the existing vibrate option sample with it. Not sure if this is acceptable given that it will break any incoming links, but I don't think that sample was ever linked to in the first place.
R: @jeffposnick @gauntface

Thanks, @wibblymat! Works as expected, and I agree that breaking out the existing sample (which I can't find any direct links to) from the vibration directory makes sense.
One thing that's missing is a top-level index.html like https://github.com/GoogleChrome/samples/blob/gh-pages/web-bluetooth/index.html
I'm just going to push a commit that adds it, and then merge in the interest of getting this published.


SimpleBlock::parse consumes blank lines that follow the block

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f197912) 90.79% compared to head (d06e84a) 90.79%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #12   +/-   ##
=======================================
  Coverage   90.79%   90.79%
=======================================
  Files           4        4
  Lines         163      163
=======================================
  Hits          148      148
  Misses         15       15

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


The model area should expand dynamically

From<EMAIL_ADDRESS>on March 18, 2010 17:32:30
What steps will reproduce the problem? 1. Add a lot of tables to the model.
2. Align them.
3. If there is not enough space in the default 2000x2000 area not all
relations are drawn. What is the expected output? What do you see instead? The area's size should be enlarged so that the relations can be drawn. What version of the product are you using? On what operating system? trunk / Chromium / XP Please provide any additional information below. I patched my version by editing the CSS and giving high values to
OZ.$('area'). This should be done automatically in the JS.
Original issue: http://code.google.com/p/wwwsqldesigner/issues/detail?id=89

From ondrej.zara on March 18, 2010 23:56:15
This makes some sense (although automatic size recomputation should be imho done only
after automatic alignment and in no other situations).
Prior to implementation, it might be wise to check what sizes of SVG "canvas" are
reasonable within a browser, with respect to performance.

From<EMAIL_ADDRESS>on March 19, 2010 03:47:31
Maybe a minimal size (2000x2000) should be kept, and enlarged only when a table (x,y)
is moved farther (x+w>2000 || y+h>2000) ?
This way the actual behavior is kept in most case, and when the model is too large
relations are still drawn. It so request more performance only when needed.

From ondrej.zara on March 19, 2010 04:11:12
Yes, I imagine this behavior. The question is whether larger SVG elements are
feasible / performant enough.

From<EMAIL_ADDRESS>on March 19, 2010 04:49:20
Tested by setting Area (so SVG) to 500 000 x 500 000
> SQL.Designer.tables[0].moveTo(499500,499500)
Moving the table, there is no performance issue with Chromium.
In fact that's not the size of the canvas, that's the number of objects and relations
that matters. This is not related to the SVG size.
Test case : build an XML that contains 10 000 tables and load it
=> Might take some seconds to load :)

From ondrej.zara on March 19, 2010 05:00:14
Nice :)
Status: Accepted
Owner: ondrej.zara

From ondrej.zara on March 22, 2010 06:48:23
Implemented in r95 .
Status: Fixed


SIGSEGV Segfault

Hi there,
I am running identical queries against node-sqlite3 and better-sqlite3 via an ORM and am seeing a segfault with the latter.
Is there anything i'm doing obviously wrong here:
Queries:
query: ATTACH "/Users/matt/dev/assorted/typeorm/temp/test" AS "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"
query: PRAGMA foreign_keys = OFF;
query: BEGIN TRANSACTION
query: SELECT 'DROP VIEW "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'view'
query: SELECT 'DROP TABLE "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'table' AND "name" != 'sqlite_sequence'
query: COMMIT
query: PRAGMA foreign_keys = ON;
query: BEGIN TRANSACTION
query: SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'table' AND "name" IN ('person')
query: SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'index' AND "tbl_name" IN ('person')
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".table_info("person")
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".index_list("person")
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".foreign_key_list("person")
query: PRAGMA index_info("IDX_e5f39165fe33e792ef72738328")
query: SELECT * FROM "sqlite_master" WHERE "type" = 'table' AND "name" = 'typeorm_metadata'
query: DROP INDEX "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."IDX_e5f39165fe33e792ef72738328"
query: CREATE INDEX IF NOT EXISTS "IDX_e5f39165fe33e792ef72738328" ON "person" ("type")
query: ROLLBACK
    1) "before each" hook for "should correctly inherit database option"
error Command failed with signal "SIGSEGV".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The schema is very simple with just 3 tables.
Is there a way to debug this more easily? Better-sqlite3 is being built via node-gyp and normal.

test

You can try if https://www.npmjs.com/package/segfault-handler gives you more insights.
It'd help a lot if you could create a minimal example that reproduces it using only better-sqlite3 (no ORM etc.).
Also:

OS version?
Node.js version?
better-sqlite3 version?

Here's a dump with some C vomit at the bottom:
$ mocha --file ./build/compiled/test/utils/test-setup.js --bail --recursive --timeout 60000 ./build/compiled/test --watch

  table-inheritance > single-table > database-option-inherited
query: ATTACH "/Users/matt/dev/assorted/typeorm/temp/test" AS "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"
query :>>  ATTACH "/Users/matt/dev/assorted/typeorm/temp/test" AS "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"
query: PRAGMA foreign_keys = OFF;
query :>>  PRAGMA foreign_keys = OFF;
query: BEGIN TRANSACTION
query :>>  BEGIN TRANSACTION
query: SELECT 'DROP VIEW "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'view'
query :>>  SELECT 'DROP VIEW "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'view'
query: SELECT 'DROP TABLE "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'table' AND "name" != 'sqlite_sequence'
query :>>  SELECT 'DROP TABLE "' || name || '";' as query FROM "sqlite_master" WHERE "type" = 'table' AND "name" != 'sqlite_sequence'
query: COMMIT
query :>>  COMMIT
query: PRAGMA foreign_keys = ON;
query :>>  PRAGMA foreign_keys = ON;
query: BEGIN TRANSACTION
query :>>  BEGIN TRANSACTION
query: SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'table' AND "name" IN ('person')
query :>>  SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'table' AND "name" IN ('person')
query: SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'index' AND "tbl_name" IN ('person')
query :>>  SELECT '9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0' as database, * FROM "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."sqlite_master" WHERE "type" = 'index' AND "tbl_name" IN ('person')
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".table_info("person")
query :>>  PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".table_info("person")
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".index_list("person")
query :>>  PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".index_list("person")
query: PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".foreign_key_list("person")
query :>>  PRAGMA "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0".foreign_key_list("person")
query: PRAGMA index_info("IDX_e5f39165fe33e792ef72738328")
query :>>  PRAGMA index_info("IDX_e5f39165fe33e792ef72738328")
query: SELECT * FROM "sqlite_master" WHERE "type" = 'table' AND "name" = 'typeorm_metadata'
query :>>  SELECT * FROM "sqlite_master" WHERE "type" = 'table' AND "name" = 'typeorm_metadata'
query: DROP INDEX "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."IDX_e5f39165fe33e792ef72738328"
query :>>  DROP INDEX "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a0"."IDX_e5f39165fe33e792ef72738328"
query: CREATE INDEX IF NOT EXISTS "IDX_e5f39165fe33e792ef72738328" ON "person" ("type")
query :>>  CREATE INDEX IF NOT EXISTS "IDX_e5f39165fe33e792ef72738328" ON "person" ("type")
query: ROLLBACK
query :>>  ROLLBACK
    1) "before each" hook for "should correctly inherit database option"
PID 9195 received SIGSEGV for address: 0x18
0   segfault-handler.node               0x00000001046ddfb0 _ZL16segfault_handleriP9__siginfoPv + 304
1   libsystem_platform.dylib            0x00007fff6d98c5fd _sigtramp + 29
2   ???                                 0x0000000000000000 0x0 + 0
3   node_sqlite3.node                   0x00000001055b7b25 _ZN12node_sqlite39Statement12Work_PrepareEP10napi_env__Pv + 37
4   node                                0x00000001009effaa worker + 394
5   libsystem_pthread.dylib             0x00007fff6d998109 _pthread_start + 148
6   libsystem_pthread.dylib             0x00007fff6d993b8b thread_start + 15

Interestingly, include that segfault handler has surfaced some additional logging so i have something to go on. If there's anything obvious in the C vomit let me know please.
MacOS Catalina 10.15.7
<EMAIL_ADDRESS>node v14.15.0

It seems to be some environmental problem because running both an sqlite + better-sqlite3 test in series when one fails (js error) seems to result in this 🤷
For posterity, the failing test can be seen here


[release-4.12] OCPBUGS-19306: Fix runaway allocation on /v2/_catalog

Introduced a Catalog entry in the configuration struct. With it, it's possible to control the maximum amount of entries returned by /v2/catalog (GetCatalog in registry/handlers/catalog.go).
It's set to a default value of 1000.
GetCatalog returns 100 entries by default if no n is provided. When provided it will be validated to be between 0 and MaxEntries defined in Configuration. When n is outside the aforementioned boundary, an error response is returned.
GetCatalog now handles n=0 gracefully with an empty response as well.

/jira refresh

the invalid bug label is a mistake, and has been fixed by https://github.com/openshift/release/pull/43497. I guess it's just a matter of propagation now.

/jira refresh

/lgtm

/jira refresh

/jira refresh

/cherry-pick release-4.11


propose to fix #266 by moving installed jar

This is essentially https://github.com/jMonkeyEngine/sdk/pull/417
I don't know enough about the installation process to know if it actually fixes the problem, but I noticed that if I used https://github.com/jMonkeyEngine/sdk/pull/417 and then moved the lib to the folder it actually points to, it worked.
Fixes #266

If it works after you do clean and build. Restart IDE and do it again. Then... it is maybe fine? We can also do a test release at some point to see if it worked or not. Some small fixes already accumulated after last release?

It didn't. Needs investigation... I'll keep trying though. Something made it work.

Yeah, for me it was like that too. Works when you do it. But.... somehow not permanently.

If it bleeds, we can kill it.

I did a little bit of further testing with the release/libs path, to no avail. I don't understand why this works but not the other. But unless there are objections, I'll probably merge this some time during the weekend.

If it works, I'm good with it. I suspect anyway if we get the Maven done. This is obsolete. Maybe.

Oh, did you by the way test the test project? Doesn't it use the test data as well on some of the tests?

Which project would that be?

Ah, the JmeTests project. No I didn't, and of course it didn't work when I did.

fix here: https://github.com/jMonkeyEngine/sdk/pull/440


Fix podman/docker container_ref trailing newline

Since docker and podman use AwesomeSpawn to run a command-line utility the result that we use to get the container_ref has a trailing newline.
This causes issues trying to match the container_ref with one coming from events.
   131:         result = docker!(*params)
   132:         require 'byebug'; byebug
=> 133:         result.output
   134:       end

(byebug) result.output
"7c640ef968d2ce923418a3de8eedae5a19c0a31f1264417b0088e0df57d0bac8\n"

Is it possible to add a spec for this?

Is it possible to add a spec for this?

Heh. this is totally why I wanted to add the AwesomeSpawn runner. So we could use that provider in tests.

@Fryguy @kbrock okay added tests covering this case


Support behat.dist.y[a]ml format

Many common tools (phpunit, phpstan, php-cs-fixer) use config files like <toolname>.<ext>. To ease collaboration, they and Behat support checking for and using <toolname>.<ext>.dist.
However, those tools also support the <toolname>.dist.<ext>, which is arguably superior when it comes to extension conventions (e.g. IDEs need to be taught that .<ext>.dist is really of type .<ext>). This PR adds support for that format to Behat too.

On a sidenote: none of those alternatives are mentioned in any Behat documentation - it seems to be limited to behat.yml.

don't hesitate to send a PR on https://github.com/Behat/docs to mention the alternate names


PMID:20144990

increased protein phosphorylation during glucose starvation

increased protein phosphorylation during glucose starvation FYPO:0005197

edit file: f191430d19d693ec371a2b0330cced7f2d5bf425
release: db425423f8f21ad50f84869137c08891dab53d80


[Bug] Domain search not working

Issue
Domains not resolving
Expectation
When  a real domain is entered, the LTC address should be loaded to the field
Screenshot

Twitter Complaint

Hey @kcw-grunt
Just tested our latest Internal release v2.0.0(635). UD Domain resolution works with paykerry.crypto
So we need more details on this user issue.

@mosadialiou   just tried paykerry.crypto ans mago.crypto on 2.0.0 and I saw nothing. I'll try to post a video

@mosadialiou I tested with J2 and UD worked...but Samsung S9 did not. This is v2.0.0

Wow it's weird. Make sure to have the latest version v2.0.0(635). If necessary do a clean/fresh install

Just tested with Oppo Reno2 running Android 10 and UD worked. paykerry.crypto resolved successful


Fix logfile path

The missing / results in the creation of log files named migration2018-06-16 21:34.log.txt etc. inside the files directory instead of log files labeled only with the timestamp inside files/migration.
Btw: the path mentioned in the documentation is completely wrong: https://community.shopware.com/_detail_1011_797.html#Debug-Modus

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/PT-9296
Please use this issue to track the state of your pull request.

thanks for your contribution @kielcoding :+1: :tada: :blue_heart:


ghc has a hidden run-time dependency on binutils

ghc won't work without binutils and currently users have to install that package to compile. This should be fixed or documented.

I assume it's just using tools from binutils based on $PATH? That seems easily fixable, if so, and seems better than documenting it :smile:

I'm not so sure it's that easy. Cabal searches for tools like ar during the configure phase. I'm not sure what it does with those paths, really, but chances are that wrapping ghc is not good enough to guarantee a working build.

Oh, I was expecting a (relatively minor) patch to be needed. Basically, tracking down where we use those tools and inserting hard references to store paths.

It's possible that it's that simple. I just don't know. Someone will have to try this and figure out whether it works or not. Maybe it's sufficient to patch the $out/bin/ghc script to add binutils to $PATH before executing the real ghc binary.

Does it really need binutils? What's the error without it?

@Fuuzetsu, http://permalink.gmane.org/gmane.linux.distributions.nixos/17337.

A fix is in staging: d3ac5c534de18caa487ab3ee341f24a452027294.


"TypeError: anymatch is not a function" after update from v2 -> v3+

I am updating my example setup to use that latest versions of cypress, tsify, typescript and your (nice) cypress-cucumber-preprocessor. Everything works fine until I update the cucumber-preprocessor from v2.5.5 to v3.0.0. Then I get the following error when trying to run a test (which did not occur in 2.5.5):
TypeError: anymatch is not a function

Current behavior

Desired behavior
No anymatch error, like when using 2.5.5
Test code to reproduce
Clone this repo:
https://gitlab.com/boterbram/cypress-setup
Then:
npm install
npm run cypress:open

# Start the example feature, everything OK, then close

npm install cypress-cucumber-preprocessor@3
npm run cypress:open

# Start example feature, now the opened browser window will close and the error shown.

Versions

Cypress version: 6.4.0
Preprocessor version: 3.0.0 or higher
Node version: 14.15.4
OSX version: 10.15.7

Thanks for the reproduction.
Interestingly enough using yarn seems to work.
This is caused by a mismatch of anymatch versions between what cypress browserify uses and our chokidar uses. one of those anymatches exposes itself as .default and another not :)
it should be fixed today by #505

Due to personal reasons, the previous maintainers of this package are stepping down and handing the reigns over to me, a long-time contributor to the project and a user of it myself. This is a responsibility I'm very excited about. Furthermore, I'd like to thank @lgandecki ++ for all the work that they've done so far.
Read more about the transfer of ownership here.
The repository has however moved and all outstanding issues are being closed. This is not a reflection of the perceived importance of your reported issue. However, if after upgrading to the new version, you still find there to be an issue, feel free to open up another ticket or comment below. Please make sure to read CONTRIBUTING.md before doing so.


the accuracy is bad, I mean it is useless

If you mean the example model shown in the repository, of course. It is a 2 layer model being applied on CIFAR 10. What did you expect from such a shallow (albeit wide) model ?
If you have any idea to improve it, do share.

got it

@titu1994 can you close this issue then?


Split Schedule into source and a ScheduleFields struct. Also remove Option from Schedule::source

It might be interesting to create a ScheduleFields struct like such:
pub struct ScheduleFields {
    years: Years,
    days_of_week: DaysOfWeek,
    months: Months,
    days_of_month: DaysOfMonth,
    hours: Hours,
    minutes: Minutes,
    seconds: Seconds,
}

And change the Schedule field to:
pub struct Schedule {
    source: String,
    fields: ScheduleFields
}

This means that you can change the FromStr implementation for Schedule to:
 fn from_str(expression: &str) -> Result<Self, Self::Err> {
    match schedule(Input(expression)) {
        Ok((_, schedule_fields)) => {
            Ok(Schedule::new(
                String::from(expression),
                schedule_fields)
            )
        },  // Extract from nom tuple
        Err(_) => Err(ErrorKind::Expression("Invalid cron expression.".to_owned()).into()), //TODO: Details
    }
}

And because of that, source doesn't need to be an Option anymore.
To prevent any breaking changes you can change the TimeSpec functions in Schedule to
pub fn years(&self) -> &impl TimeUnitSpec {
    &self.fields.years // NB: instead of &self.hours
}
// etc

Lastly If you expose ScheduleFields (and add a getter to Schedule), it can be used for equality. This means that you can use the Schedule::source for a quick equality check of Schedules, and if you have a use case where you need to check for equivalence, you can manually choose to use the more "expensive" ScheduleFields equality check. This might be useful for #61

I'm in favor of this change. 👍

Lastly If you expose ScheduleFields (and add a getter to Schedule), it can be used for equality. This means that you can use the Schedule::source for a quick equality check of Schedules, and if you have a use case where you need to check for equivalence, you can manually choose to use the more "expensive" ScheduleFields equality check.

I'd like to offer this functionality, but rather than exposing ScheduleFields I'd have something like a pub fn ordinals_eq(&self, other: Schedule) -> bool method. This keeps the ScheduleFields type internal, allowing us to do other refactoring in the future if we need to. The Schedule type already allows you to access the TimeUnitSpec of each field. Thoughts?

A use case to expose the fields would be that you can use them as a key for a map. See: https://github.com/zslayton/cron/pull/62#issuecomment-768425420

This may be a naming problem, but the distinction between a Schedule and a ScheduleFields isn't very useful to an end-user. The primary difference would be their definition of traits like PartialEq; there wouldn't be much reason for the user to request the ScheduleFields beyond that. They could achieve the same thing with a wrapper type, something like:
struct OrdinalsEqSchedule(Schedule);
//...impl PartialEq to use `ordinals_eq`

let my_schedule: Schedule = /*...*/;
let tasks: Vec<ExecuteOnSchedule> = /*...*/;
let mut tasks_to_execute: HashMap<OrdinalsEqSchedule, Vec<ExecuteOnSchedule>> = HashMap::new();
tasks_to_execute.insert(OrdinalsEqSchedule(my_schedule), tasks);

This makes me think that the comparatively expensive ordinals check should be Schedule's go-to definition of equality and that someone concerned with performance would instead do schedule1.expression() == schedule2.expression() or use schedule.expression() as their map key.

Checking only on the TimeSpecs checks for equivalence though, not complete equality. The less expensive check on only the string checks for complete equality of two Schedules. I can stand behind exposing a wrapper that checks equality on just the TimeSpecs, but I would keep Schedule's standard equality check as a check on just the string.


Add gitignore file

This PR adds a .gitignore that specifies build/ as intentionally untracked directory.

Thanks for the PR.  I went ahead and committed such a .gitignore file in a recent commit a few minutes ago.  I do appreciate your PR, but am trying to keep things squeaky clean on whose PRs are merged in until I understand whether our CLA checking scripts/etc. are correct.


Javadoc Changes Required for Java 18

Java 18 javadocs introduced a few new requirements for valid javadocs that will need to be supported in code generation for developers who wish to use Java 18 when developing Azure SDKs for Java.

[ ] Descriptions are always required

Can no longer generate javadocs like /** @return something */

[ ] Default constructors, or implicit constructions new Something(), are expected to have javadocs

Types that previously didn't declare a constructor will now need to declare a no-args constructor with javadocs.

I think I've done a PR to solve the 1st (or most of it)
2nd is news to me. Need some investigate (likely we need a default ctor just for Javadoc, for many Model?).

Yeah, in cases where we had a simple model like
``java
/**

Description about the model.
/
public class SimpleModel {
/

Description about the property.
*/
private String property;

/** @return The property  */
public String getProperty() {
return property;
}
/**
* Sets the property
*
* @param property The property
* @return The updated SimpleModel
*/
public SimpleModel setProperty(String property) {
this.property = property;
return this;
}
}

it would need to be generated as

``java
/**
  * Description about the model.
  */
public class SimpleModel {
  /*
    * Description about the property.
    */
  private String property;

  /**
    * Creates a new instance of SimpleModel.
    */
  public SimpleModel() {
  }

  /**
    * Gets the property.
    *
    * @return The property
    */
  public String getProperty() {
    return property;
  }

  /**
    * Sets the property.
    *
    * @param property The property
    * @return The updated SimpleModel
    */
    public SimpleModel setProperty(String property) {
      this.property = property;
      return this;
    }
}

Closing as these have been fixed


WIP: Draw backgrounds separately from foregrounds

This implements #6193. It's a WIP.
Summary of the Pull Request

Alright, I've got this down to a single function that takes each dirty region and produces...

A list of damaged backgrounds to repaint
A list of colored cluster lists to repaint

I don't like the number of vectors here, but... we're saving money by invalidating narrowly whenever possible.
Dirty Region [1..n]
- Origin (SCREEN CHAR COORDS)
- At line wrap point
- Region intersected right half of DBCS char (left trim)
- Background Run [1..n]
  - Attribute
  - Rect Covered (SCREEN CHAR COORDS)
- Colored Foreground Run [1..n]
  - Attribute
  - Columns
  - Cluster [1..n]

Right now, because of some minor issues (#2661), backgrounds are attributes and actual final colors. It's not pleasant!
To fix:

[ ] reverse is occasionally (!) broken
[x] render engines need flags to say "plz no background splitting" (vt engine needs to update drawing brushes per text run, foreground and background)
[ ] need to re-enable space optimization (if the cell is non-printing (and has no underline, etc.), no point in forwarding it to the cluster renderer!)

References

PR Checklist

[ ] Closes #xxx
[ ] CLA signed. If not, go over here and sign the CLA
[ ] Tests added/passed
[ ] Requires documentation to be updated
[ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

This will be cut deep by the 2661 fix.,

Merge in work from the #803 bugfix -- also, maybe we should generalize BackgroundRun to RenderableAttributeRun! This would let us katamari together runs line drawing characters and break them only when they change.
We want to consider how this interacts with underline (part of foreground).

reopening and assigning to myself, I might need this for perf.

Don't need to keep open, will post branch name in issue


does joker's context need to know mode or generator context?

I think both the mode and the generator context may be possible to encapsulate within the parser logic. If so, move them from joker::context to esprit::context.

This was fixed in #23. It turns out there's no need for a context data structure in joker at all; it only needs a single boolean indicating whether it's in operator position.


Add option to presign public S3 URL

This adds support for presigning public S3 URLs so that you can use the S3 redirect feature without having to make the entire bucket public. The expiry time is also configurable, between 1 minute (min for Amazon S3 I think?) and 7 days (max S3 value).

One thing to note, with the current design, this makes the browser/client caching useless. Each time the user tries to download an image, the URL will change and they will download it again. This should probably not be used if you are being charged by bandwidth.
This can be resolved by caching the URLs on the server side and returning the same URL if it's still valid for a while. Perhaps a min expiry config can be added to invalidate and recreate URLs that will expire too soon.

There we go. I'm not sure if there's any changes you'd like, but I tried to copy the existing media cache code, but modify it for URL caching instead. It feels a lot snappier to scroll up/down in Matrix now, because I don't need to constantly redownload everything, including the profile pictures.


marathon app json can't support dynamic values in double string

"parameters": [
      {
        "key": "add-host",
        "value": "localhost:$HOST"
      }
    ],

i need add a slave ip to docker daemon, but when i scaling the app instance, the ip is need dynamic ip. so how can i do that?anyone can do me a favor to answer the question?

currently marathon only accept $HOST as a literal string.

You can use the MARATHON_HOST env variable to get the slave's host name.


Fixed a few typos in the README

Hello !
This is a tiny PR that fixes a few typos and grammatical mistakes in the readme :)
Have a nice day :)

Not all of these are exactly errors but I'll look into it


Updgrade dependencies. Generalized library.

This PR:

Upgrades go-ipld-prime dependencies to use the latest linkSystem.
Refactors a bit the interface and other methods to add flexibility and allow user-defined logic in subscriber.
Adds SubFnHandler to configure subscriber logic. This handlers can be used to, for instance, select the IPLD selector to use for the exchange.

The reasoning behind this PR is to make it general enough to be able to use go-legs as the core for the indexer ingestion protocol.

@willscott, added PolicyHandler and a few things more. I did some tests and I think this is looking good for what we need in the indexer reference implementation. Thanks for the feedback.


Spinner needed for GPU check compatibility

Model Builder Version: In which Model Builder version was the bug encountered?
Visual Studion Version: In which Visual Studio version was the bug encountered?
Bug description
A clear and concise description of what the bug is.
Steps to Reproduce
1.Select Image classification
2. Select Local(GPU)
3. Click on Check compatibility button
Expected Experience
After  Check compatibility button clicked  spinner should be displayed until the result displayed
Actual Experience
Check compatibility button clicked  there is a delay to show the result without the spinner

Additional Context
Add any other context about the problem here, such as unusual system configurations, network restrictions, etc.

Check why RunningGPUCompatibilityCheck isn't working. It should show one spinner while all the values are being checked/loaded.

@zewditu Can you please add images ... I don't understand what is the expected/actual experience?

The GPU service throws an exception before the visibility of the spinner ON courses this. Set the visibility of the spinner visible outside of the try-catch block to fix this issue.


moveit_simple_actions: 0.0.4-0 in 'indigo/distribution.yaml' [bloom]

Increasing version of package(s) in repository moveit_simple_actions to 0.0.4-0:

upstream repository: https://github.com/nlyubova/moveit_simple_actions
release repository: https://github.com/nlyubova/moveit_simple_actions-release.git
distro file: indigo/distribution.yaml
bloom version: 0.5.20
previous version for package: 0.0.3-0

moveit_simple_actions
* fixing with changes in moveit visual tools
* Contributors: Natalia Lyubova

url of doc has to be a .git repo from which the doc job will be created.

Thanks! Fixed and Closed


⚠ Jenkins Plugins Artifactory has degraded performance

In 01adadc, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1341 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 490c00e after 12 minutes.


HI it seems that something wrong in the Windows Platform.

HI,Prof. bianjiang,
really thank you for your open sourse, firstly.
I test this program on the Mac Platform. It runs well.
However, I try to run it on the windows platform. It seems something wrong.
Here is the error log.
I tried many ways to fix it, but all failed.
Could you help me ? T.T
Thank you !!! :)
ERROR-[2017-04-05 06:30:42,088][scheduler][init][56]: Can't pickle <function  at 0x0000000003D7AB38>: it's not found as redis.client.
Traceback (most recent call last):
File "", line 1, in
File "C:\Python27\lib\multiprocessing\forking.py", line 381, in main
self = load(from_parent)
File "C:\Python27\lib\pickle.py", line 1384, in load
return Unpickler(file).load()
File "C:\Python27\lib\pickle.py", line 864, in load
dispatchkey
File "C:\Python27\lib\pickle.py", line 886, in load_eof
raise EOFError
EOFError

My python version is 2.7.13
Thank you :)

Not tested on Windows.


Modern icon scaling for packaged applications

Proposal: Modern icon scaling for packaged apps
Summary
A new icon and scaling system for packaged applications. Adding to the current system, this would use one SVG for each tile size instead of creating multiple images scaled at different sizes. SVGs are scalable by nature, and are a perfect alternative to the current method of asset scaling.
Additionally, the "recommended padding" that is used when Visual Studio is given an icon should be applied and managed by the system.
Rationale

Today, creating icon / tile assets for packaged applications means creating many images, often duplicated at different sizes. Any customization to this makes for a long and arduous process for developers.
Using a single, scalable image for app icons means the system can apply a consistent padding using the tile, rather than relying on the image itself. This has two advantages:

Consistency. The default padding is often overridden unnecessarily by the developer, creating minor inconsistencies in tiles across apps, and having the system add the padding fixes this.
Future customization. Having a full sized image as the source for a tile is not flexible, and is surely a blocker for even simple customization on the tiles themselves. This system *could* potentially open the door to a Windows flavor of the Adaptive Icons system found in Android.

For apps with a small codebase, assets can take up more space than the code. Using SVGs to scale a handful of icons is efficient and reduces bundle size.

Example output of the current asset system:

Scope

Capability
Priority

Developers can use a single SVG asset per tile size
Must

Work alongside the existing asset system for packaged apps
Should

Allow SVG asset padding to be controlled by the system
Could

Open Questions

If a system like this is implemented, should it really work alongside the old system? This was proposed to accommodate games that display very high details images instead of simple shapes in their tiles.

A single SVG may not be suitable as smaller icons often use altered designs to reduce detail and better suit the smaller rendering.
There should be a way to create a few SVGs or PNGs, and then apply them to multiple assets, where the SVG will scale, or the packaging process can auto-generate the smaller PNGs.
There should also be auto-generation of shadows to match the ThemeShadows used by WinUI and the Windows Shell

This seems to be covered (in spirit) by https://github.com/microsoft/microsoft-ui-xaml/issues/3561.

This seems to be covered (in spirit) by microsoft/microsoft-ui-xaml#3561.

I do believe it should be tackled at the Reunion level, so Win32/WPF/Winforms/WinUI can all have a single approach for handling this.
It may also require some backporting work for Windows 8, and maybe even an ICO generator for older Windows compatiblity.

That's why I added "in spirit" since in essence, both issues ask for SVG support to generate the required icons for (packaged) applications in the Windows Shell/app UI. Instead of having two such issues, ideally, we would consolidate both issues into one. And if that means https://github.com/microsoft/microsoft-ui-xaml/issues/3561 should be slightly edited (to cover more apps other than WinUI apps) and moved back into Project Reunion, then I'm all for it.

Personally, I only generate a huge PNG for 400% DPI and let the system downscale for the rest, because otherwise those assets are 90% of my package size, which is plain ridiculous.

I agree with @Felix-Dev . @Arlodotexe , can you take a look at microsoft/microsoft-ui-xaml#3561? If we need to broaden that issue, we can bring it back here.

I agree with @Felix-Dev . @Arlodotexe , can you take a look at microsoft/microsoft-ui-xaml#3561? If we need to broaden that issue, we can bring it back here.

SVG is a better approach than the MRT collection of PNG resources. Please incorporate this going forward, and don't drop it.


Keep a special process for Digital Order D paid with "Credit Audio"

But we need to keep a special process for Order paid with "Credit Audio"
Originally posted by @fbietlot in https://github.com/fbietlot/azad/issues/2#issuecomment-1253895670

this.payments_promise = new Promise<string[]>(
            (
                (
                    resolve: (payments: string[]) => void,
                    reject: (msg: string) => void
                ) => {
                    if ((this.id?.startsWith('D')) && (this.total==='1 crédit audio')) {


Add way to replace environment variable lookup.

Provide GetenvFunc which provides a way to override the mechanism for querying values from the environment.

@bigkevmcd Interesting.  What's the use case?

@joeshaw It means I can use either the environment, or something like Consul to fetch the config depending on the environment the app is running in...something like this...of course, it could try Consul, and fall back to the Environment or something.
	// This should probably be in a closure...
	client, err := api.NewClient(api.DefaultConfig())
	if err != nil {
		log.Fatal(err)
	}
	kv := client.KV()

	envdecode.GetenvFunc = func(key string) string {
		pair, _, err := kv.Get("web/"+key, nil)
		if err != nil || pair == nil {
			return ""
		}
		return string(pair.Value[:])
	}

So, with a command-line option, or something else, I can run the normal err = envdecode.Decode(&cfg) logic, and it does the right thing :-)


Switch to POST requests for everything

I am not doing this because apparently the servers don't like POST requests.


added better RHEL support & mock tests

LGTM :+1:

npm version patch && npm publish? (or npm version minor if you like)


[Optimization] Size of the current Docker Images

The Docker Images we create in particular for pyiron/potentialworkshop, pyiron/continuum and pyiron/pyiron are rather large >5GB:
pyiron/experimental        2023-11-14   8f3834de78a2   26 seconds ago   3.58GB
pyiron/experimental        latest       8f3834de78a2   26 seconds ago   3.58GB
pyiron/potentialworkshop   2023-11-14   929f5c149f76   3 minutes ago    7.51GB
pyiron/potentialworkshop   latest       929f5c149f76   3 minutes ago    7.51GB
pyiron/pyiron              2023-11-14   aa03d4dda95b   6 minutes ago    6.18GB
pyiron/pyiron              latest       aa03d4dda95b   6 minutes ago    6.18GB
pyiron/continuum           2023-11-14   74ca564c0563   12 minutes ago   6.5GB
pyiron/continuum           latest       74ca564c0563   12 minutes ago   6.5GB
pyiron/md                  2023-11-14   0c33e18a8724   16 minutes ago   3.96GB
pyiron/md                  latest       0c33e18a8724   16 minutes ago   3.96GB
pyiron/base                2023-11-14   e9f88a9cf943   18 minutes ago   1.91GB
pyiron/base                latest       e9f88a9cf943   18 minutes ago   1.91GB

In the case of pyiron/potentialworkshop and pyiron/pyiron this is most likely related to including the DFT simulation codes and in case of pyiron/continuum it is the continuum codes. I am not sure if we can improve the images in a reasonable time frame, still I thought it is interesting to share the size of the current images from time to time.

Just an update about the sizes:
REPOSITORY                 TAG          IMAGE ID       CREATED          SIZE
pyiron/mpie_cmti           2024-08-01   df9a35389aa1   23 seconds ago   9.01GB
pyiron/mpie_cmti           latest       df9a35389aa1   23 seconds ago   9.01GB
pyiron/experimental        2024-08-01   ebc7f24102db   2 minutes ago    3.62GB
pyiron/experimental        latest       ebc7f24102db   2 minutes ago    3.62GB
pyiron/potentialworkshop   2024-08-01   85587d74f936   3 minutes ago    7.98GB
pyiron/potentialworkshop   latest       85587d74f936   3 minutes ago    7.98GB
pyiron/pyiron              2024-08-01   b1e0b00cacae   4 minutes ago    6.19GB
pyiron/pyiron              latest       b1e0b00cacae   4 minutes ago    6.19GB
pyiron/continuum           2024-08-01   62a8dd6c0070   6 minutes ago    7.63GB
pyiron/continuum           latest       62a8dd6c0070   6 minutes ago    7.63GB
pyiron/md                  2024-08-01   a33f324a86d2   8 minutes ago    4.87GB
pyiron/md                  latest       a33f324a86d2   8 minutes ago    4.87GB
pyiron/base                2024-08-01   42f9343d2196   10 minutes ago   1.98GB
pyiron/base                latest       42f9343d2196   10 minutes ago   1.98GB
moby/buildkit              latest       1b090f7a4e0b   2 weeks ago      202MB
node                       18           687dbc8c3350   3 weeks ago      1.09GB
node                       20-alpine    3ef52eda8a70   3 weeks ago      133MB
node                       18-alpine    73088e107431   3 weeks ago      128MB
node                       20           f5e5f14fc86e   3 weeks ago      1.1GB
debian                     11           6f455d627454   4 weeks ago      124MB
ubuntu                     22.04        8a3cdc4d1ad3   4 weeks ago      77.9MB
alpine                     3.17         06929782def5   5 weeks ago      7.08MB
alpine                     3.18         8fd7cac70a4a   5 weeks ago      7.35MB
alpine                     3.19         12f2f991ada3   5 weeks ago      7.39MB
debian                     10           69530eaa9e7e   7 weeks ago      115MB
ubuntu                     20.04        5f5250218d28   8 weeks ago      72.8MB
alpine                     3.16         d49a5025be10   6 months ago     5.54MB
node                       16           1ddc7e4055fd   10 months ago    909MB
node                       16-alpine    2573171e0124   11 months ago    118MB


Add a cleanup script

A cleanup script (or even a text list of cleanup jobs) would be very useful too.

https://github.com/Seneliux/librephotos-linux/blob/temp/Cleanup.md


Instructions for generating certs equivalent to sample certs

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
In replicated control pane setup it's instructed to use self generated root-cert and intermediate ca cert/key.
Is it possible to provide/document generation steps for the same.
Describe alternatives you've considered
Tried this, but it sounds too complex.
https://roll.urown.net/ca/ca_root_setup.html
https://roll.urown.net/ca/ca_intermed_setup.html
Affected product area (please put an X in all that apply)
[X] Configuration Infrastructure
[ ] Docs
[X] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[X] Security
[ ] Test and Release
[X] User Experience
[ ] Developer Infrastructure
Affected features (please put an X in all that apply)
[X] Multi Cluster
[ ] Virtual Machine
[X] Multi Control Plane
Additional context

you can use step certificate for doing this
step certificate create istio-root-ca root-cert.pem root-key.pem --profile root-ca  --kty RSA --no-password --insecure --not-after 87600h
step certificate create istio-intermediate-ca ca-cert.pem ca-key.pem --profile intermediate-ca --kty RSA --ca ./root-cert.pem --ca-key ./root-key.pem --no-password --insecure --not-after 43800h
step certificate bundle ca-cert.pem root-cert.pem cert-chain.pem

nice this worked, thank you soo much.


Add wl-mirror

Screencasting: wl-mirror - A simple Wayland output mirror client

Looks good - thank you!


Great project.

Hey man,
This is a great project. I have tried other open source spiders but this is the best I have seen so far.
A great feature would be to get it working in a cluster. ie. have 10 servers run in parallel.
Anyhow, this is an awesome project. Big ups.

Thanks for the compliment. This would likely be another product if I were to implement it. Thanks for the suggestion.

This feature will likely end up in the AbotX project. Closing the issue here.


Read Service Implementation

Summary
Implement data logging for the OpcUA Read service
Motivation and context
Extend parser functionality to include details related to the Read service
Tasks:

[ ] Implement Binpac parsing logic
[ ] Implement Data Verification (debug) code
[ ] Implement Analyser code
[ ] Implement Zeek logging

References:

Developer Guide

This issue is blocked until the Read Service Test Data issue is completed.

Read Service Test Data completed.  Read service implementation moving forward.


More context on how this works.

Would be nice to have an overview in Readme on how C application is working, the init part in particular.

Hi! That's a nice idea. I've added a new section to the readme. Please comment if you would like a more thorough explanation of the method :)


Add /api/infill for fill-in-the-middle

This PR closes #3869
Adds /api/infill to leverage llama.cpp's POST /infill API for infilling / fill-in-the-middle / code-completion.
An example request looks like this:
POST /api/infill HTTP/1.1
Host: localhost:11434
Content-Type: application/json
Content-Length: 199
{
    "stream": false,
    "model": "codellama:7b-instruct-q3_K_M",
    "input_prefix": "public int gcd(int x, int y) {",
    "input_suffix": "\n}",
    "options": {
        "num_predict": 10
    }
}

Response:
{
    "model": "codellama:7b-instruct-q3_K_M",
    "created_at": "2024-04-25T11:09:06.691622744Z",
    "response": "\n    return y == 0 ? x :",
    "done": true,
    "total_duration":<PHONE_NUMBER>,
    "load_duration": 948913941,
    "prompt_eval_count": 18,
    "prompt_eval_duration":<PHONE_NUMBER>,
    "eval_count": 10,
    "eval_duration":<PHONE_NUMBER>
}

(Streaming is also available)
Note: could probably need more refactoring to cleanup duplicate code, I am very new to Golang programming, so feedback would be appreciated

Where is FIM actually implemented for each model?

Where is FIM actually implemented for each model?

The actual infilling / FIM prompt is already implemented in llama.cpp in https://github.com/ggerganov/llama.cpp/pull/3296, so we can simply leverage the /infill API.
Obviously FIM is not available for all models, but e.g. Codellama has been trained with the appropriate prompts/FIM-Tokens.
llama.cpp looks for the FIM-Tokens in the model's vocab (see e.g. tokenizer.json for CodeLlama).
It might be a good idea to check if the used model actually supports FIM, and if not immediately return an error:
https://github.com/ollama/ollama/blob/4aaa4f89beb1d151377bb1d93faa92c409f68d12/server/routes.go#L353

@PhilKes It'd be good if we could list all supported models, as well.
How does llama.cpp know the FIM prompt template? Is this info contained in the GGUF files? Or does it just assume the template FIM_START prefix FIM_SUFFIX suffix FIM_COMPLETE?

@PhilKes It'd be good if we could list all supported models, as well.
How does llama.cpp know the FIM prompt template? Is this info contained in the GGUF files? Or does it just assume the template FIM_START prefix FIM_SUFFIX suffix FIM_COMPLETE?

The prompt for infilling is created at:
https://github.com/ggerganov/llama.cpp/blob/e2764cd7ca1112d9303eba9e81c9935ee67352ff/examples/server/server.cpp#L1920-L1943
I believe all models supporting FIM use this kind of prompt template, just with different FIM tokens

Would love to hear some opinions on this @jmorganca 😀

I see we have https://github.com/ollama/ollama/pull/5207 merged, are there still plans to have a separate API endpoint for this?

I see we have #5207 merged, are there still plans to have a separate API endpoint for this?

I believe #5207 introduces a suffix to generate endpoint, but not sure about prefixes.

I see we have #5207 merged, are there still plans to have a separate API endpoint for this?

I believe #5207 introduces a suffix to generate endpoint, but not sure about prefixes.

As per the PR description, the prompt is the prefix, and suffix is the suffix.

Hi @PhilKes. Thank you so much for this PR. I'm sorry I didn't have a chance to review it sooner, and appreciate the time you've put into it. As a few people have mentioned, this was added to /api/generate (and the OpenAI-compatible /v1/completions) endpoints recently: https://github.com/ollama/ollama/pull/5207. This is the recommended way to do fill in the middle (by providing prompt and suffix fields).


Runtimes missing from some DS projects

It might be a timing issue. In case you create a Workbench without a RUNNING pipeline server it do not create a runtime configuration "in" your workbench.
Let's test it again AFTER the OpenShift AI Upgrade #93