http-api-ng - Make the HTTP API great and offer a mechanism to upgrade alongside it

We've been bitten many times by http-api changes, nuances that are only caught after release  and it is hard to migrate every single API client(i.e, every single time.
There are some things we should do, as we talked about it, to mitigate some of these problems, like: run every api client tests against a new version of go-ipfs in pre-release, however that is not enough, as there is currently no way for an API client to tell if a go-ipfs version has changed and to notify the user that they should also upgrade their api-client. One more thing is that the http-api is consumable by itself, so any breaking change, even if the api clients are updated, is still a breaking change in user-space.
My proposal to solve this issue comes in the form of:

We have to start using semver for the API - currently we have v0 on the api, but that is completely ignored
We have to have http-api tests and make them run over the several versions of the http-api
Have a way to support describe an API endpoint as 'stable', 'not stable' and deprecated.
Have a way to phase out old versions of the http-api.

Let's chat about this Monday.

I agree with much of what you say above.
The one thing I disagree with is the approach to semver -- I am strongly opposed to getting semver-major-upgrade-happy with the api. The reason the api is at v0 is that it is still getting figured out, it is NOT our v1.0.0 api, which should ship with ipfs v1.0 and should be dependable by our users, for years without any breaking change. If the intention here is to start bumping major, no, i am strongly opposed to that. That's a recipe for a mess of versions.
When people start bumping semver majors, they get super break-happy. We don't want to end up with api v41.1.2 soon and force people to deal with 40 different major versions, the ridiculous madness that would be in clients, bindings, scripts, and so on. Debugging will be a nightmare for users. Contrast this with Github itself, the inventors of semver, who are at their API's v3, have changed it only twice, and both of those times were serious upgrade moments with tons of effort and care to make sure no one was caught by surprise.
As Tom Preston-Warner says in the semver spec: be responsible about versions:

This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

I predict right now that if we just add semver into APIs without a significant and strong rejection of userland breaking changes, then we will end up with huge major version numbers in no time.
My basic statement in all of this is, again: don't break user space. Just don't do it. Sometimes it is absolutely necessary, but those cases are very, very rare, and i want to hear about each of them personally and be involved in that decision. (Most of the time i will say no).

That the API is in a very messy state now is orthogonal to the approach here. You can introduce new routes and deprecate older ways of doing things without breaking user space (bumping major).

I'm also from the school of thought that 1.0.0 is when something is defined as 'stable', which is not the case right now (first we would have to get to go-ipfs 1.0.0).
Right now, since we only have one version number (v0), we are unable to denote a sign of API change and also, let client libraries understand which path they can request that will be compatible with their implementation. I proposed semver so that we have the nice things of minor versions for breaking changes pre 1.0.0, but also be able to add new features or make small fixes that a previous api client can still work (patch versions)

Okay, let's do semver like that then. i just dont want to have an api with 40 versions. 😄


T09: reset Loader Problem onResume _TodoListApp

There is a problem with onResume at Todo_listApp
when we are going to rotate our device . loader is going to reset itself and this is bad becuase we dont change anything and this is better to Loader just Load exist data and avoid to use our resource and memory
i think its better to add a static boolean with false default value and check if we added new data recently then loader is going to reset but if just a rotate on our device . Load data from last query
this is udacity Code
@Override
protected void onResume() {         super.onResume();         Log.i(TAG,"onResume");               getSupportLoaderManager().restartLoader(TASK_LOADER_ID, null, this);  }}
and this is my offer
`public class MainActivity extends AppCompatActivity implements`
        `LoaderManager.LoaderCallbacks<Cursor> {`
    `private static final String TAG = MainActivity.class.getSimpleName();`

//at top of class a public global boolean
`public static boolean sItemChanged=false;`

.
.
.
//at onResume in MainAcitivty
@Override
   protected void onResume() {
       super.onResume();
       Log.i(TAG,"onResume");

       // re-queries for all tasks
       if (sItemChanged){
       getSupportLoaderManager().restartLoader(TASK_LOADER_ID, null, this);
       sItemChanged=false;
   }}

at AddTaskActivity

    public void onClickAddTask(View view) {

        String describeTask=((EditText)findViewById(R.id.editTextTaskDescription)).getText().toString();

        ContentValues contentValues=new ContentValues();
        contentValues.put(TaskContract.TaskEntry.COLUMN_DESCRIPTION,describeTask);
        contentValues.put(TaskContract.TaskEntry.COLUMN_PRIORITY,mPriority);

        Uri uriReturn=getContentResolver().insert(TaskContract.TaskEntry.CONTENT_URI,contentValues);

        Toast.makeText(this, "insert was successfull: "+uriReturn.toString(), Toast.LENGTH_SHORT).show();

//set boolean true from AddTaskACtivity
       MainActivity.sItemChanged=true;

        finish();}

Closing this issue as it is not an issue but a proposal for a different coding design choice.


Add qTESLA

I just had a quick look and it seems to me you mixed up the flavors and the parameter sets:
$ ack name: qTESLA-p-*/param/*
qTESLA-p-III/param/150.yaml
1:name: qTESLA.qTESLA-p-I

qTESLA-p-I/param/95.yaml
1:name: qTESLA.qTESLA-p-III

Besides that, I wonder if p-I  and p-III are really different flavors (we introduced them to be able to store different variants that differ in more than just the numbers (such as an actively vs passively secure encryption scheme), however it seems to me that those two only differ in the numbers, which means they could be different parameter sets of the same flavor. (But as I said I just had a quick look I might just as well be wrong)

I was confused, to group them in one flavor or in separated ones.
Thdifference is only in the parameter. I think  you are right, I will group
them in one flavor.
Am Di., 24. März 2020 um 18:52 Uhr schrieb Marian<EMAIL_ADDRESS>
:

I just had a quick look and it seems to me you mixed up the flavors and
the parameter sets:
$ ack name: qTESLA-p-/param/
qTESLA-p-III/param/150.yaml
1:name: qTESLA.qTESLA-p-I
qTESLA-p-I/param/95.yaml
1:name: qTESLA.qTESLA-p-III
Besides that, I wonder if p-I and p-III are really different flavors
(we introduced them to be able to store different variants that differ in
more than just the numbers (such as an actively vs passively secure
encryption scheme), however it seems to me that those two only differ in
the numbers, which means they could be different parameter sets of the
same flavor. (But as I said I just had a quick look I might just as well be
wrong)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cryptoeng/pqdb/pull/24#issuecomment-603406640, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQNZOOSFCM3NTF4JBX43C3RJDXOFANCNFSM4LOTDPCA
.

--
Regards,

btw I did not consider eliminated flavors from the first round of NIST.
Am Di., 24. März 2020 um 19:03 Uhr schrieb Soundes Marzougui <
<EMAIL_ADDRESS>
I was confused, to group them in one flavor or in separated ones.
Thdifference is only in the parameter. I think  you are right, I will group
them in one flavor.
Am Di., 24. März 2020 um 18:52 Uhr schrieb Marian <
<EMAIL_ADDRESS>
I just had a quick look and it seems to me you mixed up the flavors and
the parameter sets:
$ ack name: qTESLA-p-/param/
qTESLA-p-III/param/150.yaml
1:name: qTESLA.qTESLA-p-I
qTESLA-p-I/param/95.yaml
1:name: qTESLA.qTESLA-p-III
Besides that, I wonder if p-I and p-III are really different flavors
(we introduced them to be able to store different variants that differ in
more than just the numbers (such as an actively vs passively secure
encryption scheme), however it seems to me that those two only differ in
the numbers, which means they could be different parameter sets of the
same flavor. (But as I said I just had a quick look I might just as well be
wrong)
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cryptoeng/pqdb/pull/24#issuecomment-603406640, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQNZOOSFCM3NTF4JBX43C3RJDXOFANCNFSM4LOTDPCA
.

--
Regards,

--
Regards,

I was confused, to group them in one flavor or in separated ones.
Thdifference is only in the parameter. I think  you are right, I will group
them in one flavor.
ok!

btw I did not consider eliminated flavors from the first round of NIST.
Yeah that make complete sense. If they decided to remove them, then we won't list them.

Anyone have an idea what is meant by failure probability in param folder?
Also I ll start FALCON signature, anyone is currently working on that?
Am Di., 24. März 2020 um 19:13 Uhr schrieb Marian<EMAIL_ADDRESS>
:

I was confused, to group them in one flavor or in separated ones.
Thdifference is only in the parameter. I think you are right, I will group
them in one flavor.
ok!
btw I did not consider eliminated flavors from the first round of NIST.
Yeah that make complete sense. If they decided to remove them, then we
won't list them.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/cryptoeng/pqdb/pull/24#issuecomment-603421121, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQNZONPWJWFCILMFSVGGQTRJDZ4RANCNFSM4LOTDPCA
.

--
Regards,

Anyone have an idea what is meant by failure probability in param folder?
It's the probability that encryption or verification fails even for a correctly generated encryption/signature.  Unfortunately, many of the lattice based encryption schemes do have that property.  If qTESLA has a 100% correctness, just add 0 here.

Also I ll start FALCON signature, anyone is currently working on that?
We use issues to track this. Please create one and assign it to yourself!


schedule.Next(): hourly schedules for IST times

Added a few test cases that fail for hourly schedules in Asia/Calcutta time zone (+0530):
https://github.com/robfig/cron/pull/41

Looks like its failing for all half hour time zones (ending in non-00)

This has since been fixed


Routes not being created with the new OpenVPN server instance

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
OPNsense 23.7 introduced the new Instances improvement with OpenVPN; however, it appears that after migrating the configuration from the old Servers section to the Instances section, the routes aren't getting initialized properly with a site-to-site setup. The handshake and connection between two sites does get established, but the routes don't get added at all.
I may be missing something and it's possible that this may be caused by a misconfiguration; however, everything does seem to be in order.
The following steps assume that an existing site-to-site setup already exists and describe the process for migrating to the new Instances section. This also assumes that the Client Settings > Topology setting is checked with the old setup.
To Reproduce
Steps to reproduce the behavior:

In a browser tab, which we'll refer to as Tab 1, go to VPN > OpenVPN > Connection Status > Sessions and confirm that a connection has been established
Go to VPN > OpenVPN > Connection Status > Routes and take note of the routes that currently exist
Go to VPN > OpenVPN > Servers and click the Edit button for the server that's going to be migrated
Copy the contents of the TLS Shared Key field in the Cryptographic Settings section
In a new browser tab, which we'll refer to as Tab 2, go to VPN > OpenVPN > Instances [new] > Static Keys
Click the Add button
Paste the shared key into the Static Key field, set the Mode to auth, fill in the Description field, then click Save
While still on Tab 2, go to VPN > OpenVPN > Instances [new] > Instances
Click the Add button
Fill in the following fields, copying the information from Tab 1 to Tab 2 using the following mapping, leaving anything not mentioned at their defaults:

Old Field (Tab 1)
New Field (Tab 2)
Notes

General Information > Description
General Settings > Description

General Information > Local Port
General Settings > Port Number

Tunnel Settings > IPv4 Tunnel Network
General Settings > Server (IPv4)

Cryptographic Settings > Server Certificate
Trust > Certificate

Cryptographic Settings > Certificate Depth
Trust > Certificate Depth

Trust > TLS static key
Set to the static key that was added at Step 4 above

Authentication > Authentication
Click Clear All

Tunnel Settings > IPv4 Local Network
Routing > Local Network
Copy and paste the comma-delimited list; each item will automatically render as individual tokens

Tunnel Settings > IPv4 Remote Network
Routing > Remote Network
Same note as above

Close Tab 1, then click Save on Tab 2
Go to VPN > OpenVPN > Servers and disable the old server
At the other site, disconnect then reconnect the client
Back at the server, go to VPN > OpenVPN > Connection Status > Sessions and confirm a successful connection
Go to VPN > OpenVPN > Connection Status > Routes and confirm that the list doesn't match what was seen in Step 2 above

Expected behavior
A connection must be established between the two sites with the appropriate routes being added to the routing table. Without the routes, it won't be possible to communicate from one site to the other.
Describe alternatives you considered
N/A
Screenshots
OLD SETUP > SESSIONS

OLD SETUP > ROUTES

NEW SETUP > SESSIONS

NEW SETUP > ROUTES

OPENVPN LOG

Relevant log files
See OPENVPN LOG screenshot above.
Additional context
I've also tried manually adding each route one by one instead of using the copy-and-paste approach, but that made no difference. I wanted to see if maybe there was some white-space or the comma somehow saving on the back-end since what's seen on the front-end doesn't always necessarily reflect what's actually saved on the back-end.
I also tried deleting the old server and establishing a connection after, but end up with the same results.
I left the Client Specific Overrides as-is and enabled, which appeared to be needed still.

Environment
OPNsense 23.7.1_3 (amd64, OpenSSL).
Intel Celeron J4125 2.00GHz Quad Core

best compare the contents of the generated instances configuration and the one generate by the legacy module, both are being written to /var/etc/openvpn/

@AdSchellevis, will do. Thanks for the tip. That lead helps. I'll perform a diff and report back.

Most of these are changes for valid reasons (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/), please stick to the problem in question, the aim of instances isn't to deliver the exact same config, but if you do miss something, checking under the hood might help identify the related difference.

I get that the changes are necessary; however, don't you find it odd that when attempting to have the client connect while having the new Instance version enabled and the old Server version disabled, the Server config is what gets processed? Well, that's what it seems like.
I am trying to stick to the problem in question. There just seems to be some type of conflict or overlap between the two configs (or the processing of thereof) that could be contributing to the problem in question.
I'd tried to do my own troubleshooting earlier in attempt to help out with this potential bug, but I kept running into a brick wall with "socket bind" failures, which forced me to have to reboot OPNsense a few times. Regardless, I've pointed out discrepancies with the old config and the new config. Two keys that seem to stand out and that are missing from the new config are tls-server and ifconfig. When reading the document you linked to, it appears that the topology that should be used with my setup should be p2p instead of subnet. That doesn't seem to make a difference, nor doesn't change the topology to p2p cause the ifconfig key to show up in the config.
So have I checked under the hood? Yes, I've tried to no avail. I couldn't even find documentation or a migration guide anywhere to help transition to the new Instance setup. If there is one written up, I'd appreciate a link to that.

I get that the changes are necessary; however, don't you find it odd that when attempting to have the client connect while having the new Instance version enabled and the old Server version disabled, the Server config is what gets processed? Well, that's what it seems like.

I don't think that's possible as they both use a different execution path, but ps -afx will show you what's running.

I am trying to stick to the problem in question. There just seems to be some type of conflict or overlap between the two configs (or the processing of thereof) that could be contributing to the problem in question.

Maybe trying to bind to the same port, after which one fails, but hard to assess from here.

I'd tried to do my own troubleshooting earlier in attempt to help out with this potential bug, but I kept running into a brick wall with "socket bind" failures, which forced me to have to reboot OPNsense a few times.

hmm, sounds like the problem I've just described. My advice would be to bind both servers to a different port so in theory you could start both at the same time.

Regardless, I've pointed out discrepancies with the old config and the new config. Two keys that seem to stand out and that are missing from the new config are tls-server and ifconfig. When reading the document you linked to, it appears that the topology that should be used with my setup should be p2p instead of subnet. That doesn't seem to make a difference, nor doesn't change the topology to p2p cause the ifconfig key to show up in the config.

Debugging specific setups doesn't fit community support scope, if there is a clear pointer of a setting that is missing which could be related to any issue you might have, I don't mind having a quick look.

So have I checked under the hood? Yes, I've tried to no avail. I couldn't even find documentation or a migration guide anywhere to help transition to the new Instance setup. If there is one written up, I'd appreciate a link to that.

The examples we offer are available for both (https://docs.opnsense.org/manual/vpnet.html#id3), other (special) uses cases are way easier to investigate in term of migration by reading the config file from the old file and checking the options in the new as these match the upstream documentation (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/).
Our goal with the new instances module is to lean as close as we can towards the terminology used by the application in question (openvpn), the same we done in 23.1 for IPsec by the way. Upstream documentation is often better in explain all options that are available. It is likely that some scenario's that were supported earlier, are not possible to configure now, in which case if it's a safe to use option (according to upstream documentation), we will likely aim for inclusion at some point.

EDIT: I'm just trying to provide as much details as possible. Most people who report bugs generally don't do that because they aren't developers or testers. I know how things go and know that it's often better to over communicate than to under communicate. I was trying to provide as much information as possible that I thought was relevant to help troubleshoot the "problem in question".

This is always difficult, you're really trying to be thorough on your reports, which is a good thing, but is also quite a read and if one would try to reproduce your issue quite time consuming. I'm merely trying to skim through the highlights to identify what would be needed to explain any differences. Please remember I'm spending my limited free time here.

I figured out the problem. The issue had to do with the Client Specific Override. The Servers dropdown doesn't list the servers created in Instances, only in Servers:

Per the docs, I should be able to select the Instance server:

However, I just learned that I could have nothing selected at all. So once I realized that selecting nothing would cause the overrides to apply to all servers, I figured I'd give that a try.
Sure enough, my routes got built as expected.
So the bug in this case wasn't the configurations all along. The issue has to do with the CSO not allowing users to select the server created from the Instances screen.
I'm going to leave the Servers option empty since I'm only planning on running one server. However, this bug could impact others who are running multiple OpenVPN servers and require CSO on a per-server basis.

Also, if you prefer I create a separate issue specific to the CSO screen, I can do that and close this one to keep the issue more targeted and focused. Just let me know how you'd like me to proceed.

It's fine to close this one, @fichtner already fixed the issue you found last week https://github.com/opnsense/core/commit/ee4496702d0dd2ec312d45d459f16d90cf4ba2d4 https://github.com/opnsense/core/commit/42e06c5daf1689fe6ff9e91fdb6511d138989507 , it should be in the next release.

Thanks, @AdSchellevis. Closing...


run.cmd - support explicit exec form

At the moment it is not possible to run a more complicated command on a container start, e.g. docker run -it --rm busybox /bin/sh -c "while true; do echo Hello world; sleep 1; done" as the cmd is split by spaces at  ContainerCreateConfig.command, and the following configuration:
              <image>
                  <name>busybox</name>
                  <run>
                      <cmd>/bin/sh -c "while true; do echo Hello world; sleep 1; done"</cmd>
                      <wait>
                          <log>Hello world</log>
                      </wait>
                  </run>
              </image>

produces container startup error true;: line 1: syntax error: unterminated quoted string.
It would be nice to have an ability to specify the exec form of the command explicitly, e.g.
              <image>
                  <name>busybox</name>
                  <run>
                      <cmd>
                          <params>
                              <param>/bin/sh</param>
                              <param>-c</param>
                              <param>while true; do echo Hello world; sleep 1; done</param>
                          </params>
                      </cmd>
                      <wait>
                          <log>Hello world</log>
                      </wait>
                  </run>
              </image>

in line with recent changes to ENTRYPOINT/CMD

You are right, the command specified for <run> should support the same capabilities like in <build> i.e. specifying the shell and exec forms explicitely.
We will include this in one of the next section, if you like to speed this up you could help us with a PR: Starting point is the RunConfiguration where the command should be switched over to Arguments, similar as in BuildImageConfiguration for entryPoint and cmd. It is used here.

I have created a branch with a draft implementation. Specifying arguments explicitly works like a charm:
                <env>
                  <BLAH>FOOE</BLAH>
                </env>
                <cmd>
                  <exec>
                    <arg>sh</arg>
                    <arg>-c</arg>
                    <arg>echo $BLAH</arg>
                  </exec>
                </cmd>

but switching the <shell> from array to simple string in API json didn't work as I expected. I kept getting System error: exec:...stat...no such file or directory. Fell back on splitting by spaces. The following configuration will produce cmd json ["the", "shell", "way"]
            <image>
              <name>debian:jessie</name>
              <run>
                <entrypoint>
                  <shell>/bin/echo</shell>
                </entrypoint>
                <cmd><shell>the shell way</shell></cmd>
                <log>
                  <prefix>keep splitting by the spaces</prefix>
                </log>
              </run>
            </image>

I suggest decreasing the configuration clutter by allowing the "Inlined collection" notation for the explicit arguments:
              <run>
                <entrypoint>
                  <arg>echo</arg>
                </entrypoint>
                <cmd>
                  <arg>inlined args</arg>
                  <arg>mean less clutter</arg>
                </cmd>
              </run>

and default property for the Arguments bean to be the shell form:
              <run>
                <entrypoint>echo</entrypoint>
                <cmd>default string for simple commands</cmd>
              </run>

I plan to ponder bit more on why doesn't plain string cmd/entrypoint work against the docker API, will then polish the branch (validation/tests) and create a pull request in a week time at worst.

Pull request sent: #269


Privacy Browser

Privacy Browser - https://github.com/WhichBrowser/Parser-PHP/issues/177

Coverage remained the same at 100.0% when pulling a3b72af6611aab4ea31cd13b0f60c1174fff07ff on ayumi-cloud:Privacy into 4899110cd2f87b01e04ced62dbb9dec541031dee on WhichBrowser:master.


Small issue in ReadMe example code

This is a tiny thing, but in your ReadMe file, your example code doesn't close the Label, so UI Toolkit complains.
Thank you for making this. I look forward to using it!
– Jeremy

This is a tiny thing, but in your ReadMe file, your example code doesn't close the Label, so UI Toolkit complains.
Thank you for making this. I look forward to using it!
– Jeremy

Good catch, just updated the readme. Thanks!


c7000: Add support to add users to all blade ILOs through chassis

Its possible to add/modify/delete a user on all blade ILOs hooked up in the chassis,
this will make it easier to configure ILOs,

If they have unknown passwords.
Without hassel of logging into to each ILO to configure it.

OA-3863BB3189E1> HPONCFG all  << end_marker
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="foo" PASSWORD="foobar">
 <USER_INFO MODE="write">
   <ADD_USER
     USER_NAME="foo"
     USER_LOGIN="foo"
     PASSWORD="foobar">
     <ADMIN_PRIV value ="Yes"/>
     <REMOTE_CONS_PRIV value ="Yes"/>
     <RESET_SERVER_PRIV value ="Yes"/>
     <VIRTUAL_MEDIA_PRIV value ="Yes"/>
     <CONFIG_ILO_PRIV value="Yes"/>
   </ADD_USER>
 </USER_INFO>
 </LOGIN>
</RIBCL>
end_marker

Support added in https://github.com/bmc-toolbox/bmclib/commit/ab0a3a4571d68b907b3dae68b1789d190706d718


Finish facades for AuthModule

Follow instructions from #6 and see example/spike in #140.
If you have a question, post in team slack with @tobias and @wei.

@WeizhengSap You have the wrong Tobias.

In this ticket, only auth module itself is switched to using the facade. For the other modules, see #276

All facades work will be tested with one ticket, #6.


calling setProps causes "this.updater.enqueueCallback is not a function"

Enzyme version: 3.0.0
React version: 16.0.0
Test
import Enzyme, { mount } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
Enzyme.configure({ adapter: new Adapter() });

test('Drop updates', () => {
  const onClose = jest.fn();
  const component = mount(<FakeInput onClose={onClose} />);
  component.setProps({ onClose: undefined });
  expect(component.getDOMNode()).toMatchSnapshot();
});

Error
TypeError: this.updater.enqueueCallback is not a function

      at WrapperComponent.Object.<anonymous>.ReactComponent.setState (node_modules/enzyme-adapter-utils/node_modules/react/lib/ReactBaseClasses.js:64:18)
      at WrapperComponent.setChildProps (node_modules/enzyme-adapter-utils/build/createMountWrapper.js:72:16)
      at Object.render (node_modules/enzyme-adapter-react-16/build/ReactSixteenAdapter.js:217:26)
      at ReactWrapper.setProps (node_modules/enzyme/build/ReactWrapper.js:418:24)
      at Object.<anonymous> (src/js/components/Drop/__tests__/Drop-test.js:114:13)
      at Promise.resolve.then.el (node_modules/p-map/index.js:46:16)
      at process._tickCallback (internal/process/next_tick.js:109:7)

Any ideas what could be causing this?

FYI, by investigating this further I noticed that node_modules/enzyme-adapter-utils has a react 15 version inside node_modules/enzyme-adapter-utils/node_modules.
As a test, I manually deleted that React folder and the issue goes away.
I tried to analyze the package.json for enzyme-adapter-utils and I could not find anything wrong (it correctly uses a peer dependency). So I have no idea why it still has a react 15 copy. 😢

super weird. This problem seems to be with Yarn and the way they are handling peerDependencies.
If I use npm install it does not get the extra copy of React. I'm closing down this issue since I believe there is nothing to be fixed in your end.

If you file an issue on yarn, please link it here for posterity - thanks!

https://github.com/yarnpkg/yarn/issues/4590

Upgrading from yarn v1.1.0 to v1.2.1 fixed issue for me 👍

I had the same issue while upgrading an app from react 15 to 16.
Upgrading yarn (to the latest version which is now 1.3.2) did do the trick :(
I had to manually override the transitive dependency in package.json like this

@javierfernandes that doesn't sound like the right solution. You might not have the right dependency versions set up; overriding dependencies should never be required.


(ADP-644) Withdraw rewards from hardware wallet reward account

Context

(public exposure of ADP-644)
Story

As a hardware wallet user
I want to withdraw my rewards from my rewards accounts
So that I can spend my rewards

Acceptance Criteria

Given I have a hardware wallet
And I have accumulated rewards
And I have it connected to Daedalus
Then I can create a transaction, withdrawing my reward from my reward account
To some payment address

Additional Information / Description
In the API, we have the option to provide an extra "withdrawal" parameters when constructing payments. The result allows user to selectively include rewards (if eligible) as part of the transaction. This query parameter does not however exists for the /coin-selections API which is used by hardware wallets. There's therefore no way to include rewards in transactions constructed from hardware devices.
More context here: https://github.com/input-output-hk/daedalus/issues/2274

Bump.
hi guys is this scheduled to be fixed? I can’t withdraw 000s of my rewards on my Nano Ledger X because of this issue

I would also like to know about the progress of this fix. I set up a hardware wallet and would like to send the rewards from my previous wallet but I am unable to send from a wallet only containing rewards.

This is now being addressed by #2528


add the first components with an example how to use

Following on the issue https://github.com/ABRG-Models/morphologica/issues/167, I created the first aggregation of visuals into classes. I called them components for now.
But all the naming should be reviewed to make sure it is scalable and understandable by the user.
I created a first example that show up what the output could be.
What is left to be done for this PR to be merged:

validate the name
validate the namespace for these "components", should it stay in morph or be morph_?
write up the documentation

I am submitting this PR for now mainly to discuss naming and how we should arrange things in the repo

Thanks Fabien, plenty to think about on this. A couple of quick things first though: Make sure indentation is 4 spaces to match the rest of the code and see if you can ensure there is never whitespace at the end of lines.
The important thing with this one, as you've already said, is to get the naming conventions correct.

@optseb Thanks for your feedback. I'll try to correct for the indentations and whitespaces over the weekend or next week.
I think the documentation in code style might need update as well

Naming suggestions, for the new items:

Component
Module
VisualAggregate
Collection

I've just finished some work that has been preoccupying me for the last week and finally had the headspace to take a look at this PR. There's lots to digest, but the first thing that comes to mind is whether we can define a base class for SimpleGridVisual and ConstantAbscissaGraphVisual so that these can be added to a morph::Visual and so we don't have to pass a Visual into the constructors for these objects. It would be nice to be able to do:

There are 2 things that needs to be accounted for in the case we inherit the Visual class.

It is the fact that the bindmodel function is used before and needs the reference to the visual object
There are multiple objects to add so the default function in class Visual might need to be amended, (not too sure how this could work actually)

Also a point which I find interesting in the current approach is the ownership is transparent to the user. He doesn't have to understand that the first pointer is provided to the Visual object and a non-owning pointer is sent back. Then the update_graph should be called from the same pointer of the object that has been created. There are maybe pros and cons to that but from a user perspective it gives some sort of abstraction to what's below.
I think we enter in the realm of what the user should know and what we think is not worth knowing, where it might be difficult to draw a clear line...

There are 2 things that needs to be accounted for in the case we inherit the Visual class.

I'm not thinking of inheriting the class morph::Visual. Not sure what you mean. I was thinking of  having an interface class - something like morph::vmgroup::vmgroupbase from which to derive a 'VisualModel group' which could be composed, and added to your morph::Visual scene. If it can be made easy to make a new class from vmgroupbase by composing existing VisualModels, I think we provide a benefit to the user.

1. It is the fact that the `bindmodel` function is used before and needs the reference to the visual object

2. There are multiple objects to add so the default function in `class Visual` might need to be amended, (not too sure how this could work actually)

Also a point which I find interesting in the current approach is the ownership is transparent to the user. He doesn't have to understand that the first pointer is provided to the Visual object and a non-owning pointer is sent back. Then the update_graph should be called from the same pointer of the object that has been created. There are maybe pros and cons to that but from a user perspective it gives some sort of abstraction to what's below. I think we enter in the realm of what the user should know and what we think is not worth knowing, where it might be difficult to draw a clear line...

This is the essence of software architecture!

I've started doing some work on this on a local branch in your fork of the repo. I split out the "GridVisual plus ColourBar" class and made an example that just displays that. It's a starting point for getting the architecture right. We could have an in person meeting to discuss at some point.

https://github.com/ABRG-Models/morphologica/pull/276#issuecomment-2485286030


add command line switch for turning on unstable features

This adds a switch, -u/--unstable-feature, for turning on #![feature] declarations in the expr/loop. This can't be done normally because they have to be at the top of the crate.
Example usage: cargo script -u braced_empty_structs -e 'struct X {}'

I'm a little leery of dedicating a short option for something that's just a tad obscure... but, eh, it's not like we're hurting for them.

Note to self: here's a justification for the short option.
Fundamentally, any script using unstable features isn't going to remain useful for very long; the feature might be stabilised or removed at any time.  As such, this is only really useful for short-lived scripts and expressions, where a short syntax is preferable to a more long-winded one.
Still not entirely convinced that this deserves a short option, but this is why I'm currently going to keep it.


QCoreApplication, Nuget, Other Changes

Until now, apps had to create a QCoreApplication object for the network calls in the SDK to work. This change fixes that by wrapping the respective APIs with a temporary QCoreApplication instance when needed.

Added .nuspec, .targets files for creating Nugets.

Added a Visual Studio sample app.

@aragun,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Closes #868: Share images with Open Food Facts

Description
Screen shots are mentioned in #868
Will add unit tests to the pr.
Localization for the added strings is not present, looking for inputs on how to add them.
Describe the changes made and why they were made instead of how they were made.
Did the changes and workflow as mentioned in #868
Related issues and discussion
#868
Make sure you've done all the following (You can delete the checklist before submitting)

[ ] Apply the AndroidStyle.xml style template to your code in Android Studio.
[ ] Code is well documented
[ ] Include unit tests for new functionality
[ ] All user-visible strings are made translatable
[ ] Code passes Travis builds in your branch
[ ] If you have multiple commits please combine them into one commit by squashing them.
[ ] Read and understood the contribution guidelines .

@sowmya9029 Tiny conflict. Can you fix it ?
Also, can you tweak the strings as requested ?
Also, can you share screenshots with the latest tweaks here (especially when no barcode is detected)

Here are the screenshots

Maybe for the dialog were the barcode is found it should be the barcode as the title and the message should be something like A barcode was detected. Do you want to add photos?

@sowmya9029 @Karljoones:
for unrecognized picture, we should display it:

So we should even show the selected image in the alert box if there is no barcode. Am I correct?

@sowmya9029 @teolemon I agree, we should display the image in the dialog even if there is no barcode detected. Since the system may not detect the barcode 100% of the time, the user can read the barcode off the image if it is there but the system has not detected it. There should be a bit more padding around the edit text too

@Karljoones  I agree. Working on the change.

Merge conflict to solve.
This one would be nice to merge asap, since it's very useful.

Conflicts resolved

Hey @sowmya9029,
Your changes looks good to me!

Merged, thanks @sowmya9029

Thanks @Karljoones for resolving this. I was on vacation and dint see this comment.


Multiuser (liveshare) autosaves makes editing incredibly frustrating

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

VS Code Version:

Version: 1.81.0
Commit: 6445d93c81ebe42c4cbd7a60712e0b17d9463e97
Date: 2023-08-02T12:40:02.782Z
Electron: 22.3.18
ElectronBuildId: 22689846
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 22.4.0

I'm working in a liveshare, editing as guest. Host has autosave to "after-delay", I have autosave "onFocusChange".
If I type a space, then pause (eg to think, or let copilot generate code), the host's machine autosaves, removing the space(s), and resetting my cursor to a different position.
This causes me to type two words without a space, or moves my cursor to the start of a line. Often it will imply to copilot to stop inferring as well. It even pops me out of Vim mode's insert mode.
It makes VSCode basically unusable.
It would seem that VSCode should only autosave for the author of an edit perhaps?

Please report this to the LiveShare extension to get their opinion and weather this is something they can control. I do not fully see how VS Code could change this.

My bad, I thought LiveShare was part of the core product. Sorry for the noise!


Bug: file save but restored to a previous state (git enable)

I made changed to a  file and save it, use git to stage the change and closed VS Code. When I reopen Vs Code, and modified another file and I open a new window. Usually the new window opens with a untitlled file but that time one  of my file where there (the one mentionned earlier). I close the window, it asked me to save the change. I didn't made change to the file and it appears as the last save but I press by error  yes (save the change). VS code freezed for 30 sec, the new window closed and my file appear in the first window but in a earlier version (of more than 24h ago )
(I could get the lastest version of my file in thanks to my last stage)

CPUs
Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz (8 x 2395)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_softwarevideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
7.90GB (2.07GB free)

Process Argv

Screen Reader
no

VM
0%

Extension
Author (truncated)
Version

Bookmarks
ale
9.1.0

project-manager
ale
9.0.1

transformer
dak
1.6.0

auto-close-tag
for
0.5.6

macros
ged
1.2.1

gc-excelviewer
Gra
2.1.26

vscode-opn
lfu
1.1.2

python
ms-
2018.9.0

debugger-for-chrome
msj
4.10.2

vscode-fileutils
sle
2.11.0

vscode-autohotkey
sle
0.2.2

It's not super clear what's happening, the hot exit feature may be behaving as expected. Can you please read https://code.visualstudio.com/docs/editor/codebasics#_hot-exit and clarify the expected behavior vs actual?

I have hot exit activated but that's not what is happening here.
Step 1) I edited a file (file.html), saved it, staged it to git and then I close VS Code.
Step 2) Sometimes later I reopened VS Code. While I was editing another file, I opened a new VS Code window by mistake. In this new windows I didn't have an "untitled file" (as usual) but "file.html" in its latest version. When I closed this new VS Code window, a pop up asked me if I wanted to save the changes (i don't know what changes because file.html was its latest version). I pressed yes by mistake. The new VS Code windows froze for 30 sec, I waited and then it closed itself. So I was back in the "first" VS Code window. There, I had  "file.html" but in an earlier version (more than 24h ago - so VS Code lost all the edits that I saved in step 1)

@Gettyk if you staged the file to git you should still have that copy unless you told git to clear the staged files? Also did some other source change the file between then and now?
I can't reproduce the problem locally by doing the following:

Create a new folder and open VS Code in it
git init in the folder
Create a file.html, add content
git add .
Close the window
Open the window

Thanks for your time @Tyriar.  Yes I was able to get my file back, thanks to git. I don't really understand what happened. I just posted it here in case someone already had something similar.

@Gettyk good to hear, let us know if you see something like this happen again.


Error messages should show Type|Nil instead of Type?

I think that the more verbose Type|Nil syntax is better for error messages than the easilly misread Type?. Retain Type? as a shortcut in code, but I think Type|Nil is much clearer and visible in error messages.

I like your idea. Sugar for expressing is good. When reporting a less ambiguous syntax makes more sense. +1

Got this for triage.
Not sure about this change. Type? is used in code, so if it appears in errors you should know what it means. It also appears in docs and pretty much everywhere. Should we also show Foo | Nil in docs? Maybe it's too verbose, and nilable types are very common.
This also applies to methods returning a tuple. I think it's easier to read this, in docs (and code too):
def foo : {Int32, Int32}
end

than this:
def foo : Tuple(Int32, Int32)
end

So unless others have a very strong vote for this, I'd close this.

+1 for verbose reporting.

The point is that Type? is easily misread as Type in error messages, where Type | Nil is not. I would imagine the same applies for docs.
In code, I don't think it's as hard to misread somehow...

The Type? idiom is very common in the language, either in code and documentation. I'm in favor to keep it for error reporting too.

Error output is a completely different context.

The code isn't highlighted.
The code-structure is broken up
There's no formatting like in docs, making distinctions
There are English language phrases surrounding the error where the question mark is used with English semantics.

Code + Docs => Type? is Neat, Errors => Type|Nil is better. Because it can be confusing with Type? (punctual pun intended)

Let's do this. My argument for docs isn't a good one, it's actually better to show Int32 | Nil because then one can click on Nil too. In fact, I'll change all to_s methods to show the full type, like showing Pointer(Int32) instead of Int32* and so on.

and the ? can be passed un-noticed very easily


Maatian Maps

Flood forecasting
We would like to add your Geospatial dataset to our Google Earth Engine project to work with us we're introducing a new paradigm.
We would like to share this paradigm, (vertical datum) and (vertical data projections) considering dam removals in hopes we can work together in a collaborative effort with Google Earth Engine.
Your data may need to be converted to json in order to be compatible with the Google Earth Engine.
I'm adding a link to this correspondence that has art and research I put together with some facts but there are more reasons to be found all around on this domain. https://superspacefaith.tumblr.com/post/180256186893/hydropower-reached-its-peak-in-the-1940s-forty

Hi Xavier,
Thanks for the issue, I am sorry I wasn't watching the repo. Are you still interested in this?
Mike


Concurrent token refreshes

Are there plans to handle concurrent token refreshes? For example, when multiple independent actions are executed at the same time and the access token expires, each action will attempt to refresh using the same refresh token. Since refresh tokens are single-use, only one refresh succeeds while others fail.
(I already posted this in the SST Discord but wanted to bring it up here as well so it won't get lost)

this is a good question let me do some research into how best to handle this
i could update the TTL on use to be like 60s so it allows for a window of this

Some providers like Auth0 re-use the returned access token when refreshing it, so if you send the same refresh token to get a new access token in a short period of time instead of each one returning a different access token you get the same one.
This way if the user opens to tabs of the web app and each one tries to refresh it both get the same time and there's no race condition on which access token is saved in the cookie.
This is also useful for frameworks like Remix that don't have middlewares, you can do the refresh token flow in any loader or action and just save the new access token without thinking race conditions.

I would avoid changing the TTL on the refresh token, and instead store alongside the refresh token when it was first used.  Eventually you will want to add reuse detection, which will require persisting those refresh tokens.
Producing the same access token is a good idea, but I would avoid putting access tokens themselves in data storage.  You don't want to reveal access tokens if your database is compromised.  Instead, I'd store everything needed to reproduce the same access token, and re-sign it (hash should be the same.)

@thdxr this is a significant issue when the access token is stored in memory like in the openauth react example. for instance, refreshing the browser tab twice will get you logged out (depending on how you deal with invalid refresh tokens obviously).

@sergiodxa  I've been thinking more about this idea of returning the same access token for a given refresh token.
If you return multiple different access tokens, what's the actual negative impact on the application?  You mention race conditions, but it's not clear why this would be a problem.  If the first response sets an access token, and the second response overwrites it, does that actually matter?  All subsequent requests will be using the same access token, and either one can be used, since access tokens are stateless and can't be revoked.
I only ask because returning the same access token has its own race condition on the backend.  If the first request writes its access token to storage, the second request may attempt to read it before it's been written.  Solving this is not a trivial task, given the wide variety of infra this project aims to support.  It may be more effort than it's worth.

access tokens are stateless and can't be revoked

This doesn't need to be the case, you can and most likely will need to store the access tokens somewhere so you can revoke them, in that case the refresh token will overwrite the previous access token.
The problem is what happens if you send two refresh tokens attempts, so you get two new tokens, if we suppose the second will overwrite the first we need the second to be saved by the client app, but if the client app keeps the first one it will lose the correct access token.
So you either solve this in every client app or in the IdP, I think solving it once for all apps is better.

Another case which is mentioned on the first comment, is that a refresh token can be single use, if a client app sends two refresh tokens requests one will fail, solving this in the client app will mean you have to ensure you only use a refresh token once
Imagine if you have a client web SPA, a user can open it many times using the same tokens (e.g. multiple tabs), if each tab sends a refresh token request one will fail and the other won't
Another case is if you have a client web app that keeps the token in a cookie/session and refresh it server-side (e.g. Remix/React Router, Next, Nuxt, Rails, any frameworks with SSR), again the user could have two opens tabs or even the app could send two requests for more data to the API (imagine you render two React components and each one request more data), since requests are independent of each other the server would have to somehow queue refresh attempt to ensure only one is processed and the new access token is shared between requests.
Again in this scenario it's simpler for the IdP to solve it once than make every client app solve it.

Thanks for the reply, that's helpful context.
I do think the race condition within the authorizer service is something that needs to be solved for, but I think I have an idea on how to deal with this.  Will post a draft PR when I get the chance.

have you guys found a temporary workaround for this issue? this is kind of a blocker for me right now. i might just get started working on a draft pr to get this going. don't think i can push my SPA with openauth to prod yet because it's so easy for my users to get kicked out of the app which is not great ux wise.

@beeirl I added what I have so far in #117 - note that I've only tested locally with the memory adapter so far, so use at your own risk.

@pverheggen nice! going to check it out asap


Consider adding socketopt const "IPV6_BOUND_IF" as we need to set/get bound interface on macOS

Consider add this to bsd/apple/mod.rs:
pub const IPV6_BOUND_IF: ::c_int = 125;

We really need this constant to perform modification on socket options(to bind socket to an interface, more specifically). Though we can temporarily define this on our own, but since IP_BOUND_IF is already defined in libc crate, we'd like to keep consistency.
I can make a simple PR if you agree to add this.
Thanks for your hard work.

5 days passed. Any feedback?

If it's in the headers I don't see a reason why a PR wouldn't be accepted.

@KyleRicardo for next time, you do not need "permission" if you think you can do a PR.

@devnexen Ok, next time I'll do a PR directly. BTW thanks for your PR. Hopefully it will be merged soon.


[BUG] API lookup failing

Describe the bug

Steam API lookup always failed

To Reproduce

I'm not sure, I have a valid API key

Expected behavior

Steam API lookup should succeed

Logs

WorldState.cpp(983):GetTF2Playtime: class tf2_bot_detector::http_error: Failed to HTTP GET https://api.steampowered.com:443/IPlayerService/GetOwnedGames/v0001/?key=<STEAM_API_KEY:32>&input_json=%7B%22appids_filter%22%3A%5B440%5D,%22include_played_free_games%22%3Atrue,%22steamid%22%3A76561199048445793%7D: SSL connection error

Screenshots

https://imgur.com/a/AdbPJ7W

Desktop (please complete the following information):

OS: Windows 10
Version of bot detector <IP_ADDRESS>8

Additional context

Doesn't seem to alter function, just spams the log in the bottom right

Try updating to the latest nightly. Some api stuff has been changed since 798

@Dr-n00dle are you still having this issue?


LineWiseCopyCut: Make this function usefully

See https://github.com/codemirror/CodeMirror/issues/3983 for complaints,
this change makes it so that if the user only has empty selections and does a paste after a line-wise copy or cut, the line will be pasted at the beginning of current line instead of at the actual cursor position.  This makes the line-wise copy/cut feature way more convenient and useful.  E.g. user can simply do ctrl+C and then ctrl+V to duplicate a line quickly and keep the cursor in the same position.

Thanks. Merged as 981217306, slightly updated in 889098f123
Pro tip: Next time, don't complain and whine in issue reports. You didn't pay for this software, and being rude and entitled about it does not put me into a mood where I want to collaborate with you.

I am very sorry my issue report came across as "whiny".  For future
reference, are you mostly referring to the first line, which I could
understand may have come across that way?  I realize that I was a bit
frustrated at the moment, and was trying to express that to some extent as
a user to justify the issue report -- I imagine there are others that have
used the feature have had similar experiences.  Prior to familiarizing
myself with this code I had no real experience with text editor code, so I
was just trying to explain my experience as a user in as much detail as
possible.  Someone had suggested to me that this may not be possible in a
browser environment so I tried to do a little research (without
familiarizing myself with all the code) to ensure it was possible.  I'm not
sure why exactly the rest of the report besides that first line would come
off as "rude and entitled", as I am pleasantly asking and thanking for any
help received?  I just had a feeling that this would have taken ~5 minutes
to fix for anyone that was already familiar with the code.
Sorry, again, I did not mean to offend anyone.  Thank you so much for all
your help with the pull request and cleanup!
Matt
On Tue, May 17, 2016 at 7:03 AM, Marijn Haverbeke<EMAIL_ADDRESS>wrote:

Thanks. Merged as 9812173
https://github.com/codemirror/CodeMirror/commit/981217306a2a1250a95d5ca8a829b5380f7a618b,
slightly updated in 889098f
https://github.com/codemirror/CodeMirror/commit/889098f1232a1223c52d5f0bbf1631b24b66e79f
Pro tip: Next time, don't complain and whine in issue reports. You didn't
pay for this software, and being rude and entitled about it does not put me
into a mood where I want to collaborate with you.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/codemirror/CodeMirror/pull/4028#issuecomment-219727152

Re-reading the original issue, it isn't as bad as I remembered it. The subject commanding me to make the feature 'function properly' grated. I get a lot of email, most of which are requests for unpaid assistance, and that can get on one's nerves when there's other things to do. But since you submitted a solid implementation yourself, we're definitely good here.


Better instructions on how to download new version of CLI to do a keptn upgrade

As the Keptn team is constantly putting out new cool features and with that also an updated version of the CLI which is needed to upgrade to the latest Keptn I suggest some user experience improvements in that process.
#1: keptn version should give me the command to update my CLI
Currently when doing keptn version I get this
Keptn CLI version: 0.7.1

keptn version 0.7.2 is available! Please visit https://keptn.sh for more information.
Daily version check is enabled.
Keptn will collect statistical data and will notify about new versions and security patches for Keptn. Details can be found at: https://keptn.sh/docs/0.7.x/reference/version_check
---------------------------------------------------
* To disable the daily version check, please execute:
 - keptn set config AutomaticVersionCheck false

I suggest to provide an easy - here is how you upgrade your CLI command. So - instead of just saying "please visit the keptn website" - I suggest to also add the following:
To update to the latest CLI run this command: curl -sL https://get.keptn.sh | sudo -E bash

Another option would be to point the user to a site that shows the user how to download the latest CLI depending on the target OS!
#2: Do a version check with keptn upgrade
Right now when doing a keptn upgrade and the CLI version is not on the latest available keptn version we get the following error message which is not that descriptive to the end user on what to do next:
$ keptn upgrade
Error: No upgrade path exists from Keptn version 0.7.1 to 0.7.1

I suggest that keptn upgrade should also highlight that there is a new keptn version available but first the user has to upgrade to the latest CLI in order to perform that updgrade

Hey! I would like to work on this issue, could you please assign it to me?

Sure!
Please take a look at the instructions provided here: https://keptn.sh/docs/quickstart/#2-1-install-keptn-cli


Get http headers

Please answer these questions before submitting your issue.

Why do you submit this issue?
[x] Question or discussion

Question

What do you want to know?

Hi, does anyone know how to check http headers on skywalking?  I can see those data but no headers.

Because the plugin doesn't collect them.


Error uploading signature and attestation

I upgraded from v0.5.0 today and I'm getting a getting signed image: open containers/auth.json: permission denied in the logs. This seems to be happening while the "Starting attestation upload to OCI " is attempted. Seems to me that the signature isn't getting pushed to OCI for the same reason.

Major changes post v0.5.x include https://github.com/tektoncd/chains/pull/284
The error message appeared in https://github.com/tektoncd/chains/pull/291/commits/07c1b5ffb72c5474c86dbbdccbcb49aa7a7f98b5

Expected Behavior
Upload of signature & attestation with tekton-provenance should succeed in chains v0.6.x, since it had worked in 0.5.x ( I'm aware tekton-provenance has been deprecated, that shouldn't impact this 🤔  )
Actual Behavior
Signing fails.
{"level":"info","ts":"2022-01-10T00:23:58.771Z","logger":"watcher","caller":"chains/signing.go:185","msg":"Signing object with x509","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7"}
{"level":"info","ts":"2022-01-10T00:23:58.771Z","logger":"watcher","caller":"oci/oci.go:71","msg":"Storing payload on TaskRun tekton-chains/new-pipeline-sye5yl-buildah-2gms7","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7"}
{"level":"info","ts":"2022-01-10T00:23:58.771Z","logger":"watcher","caller":"oci/oci.go:147","msg":"Starting to upload attestations to OCI ...","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7"}
{"level":"info","ts":"2022-01-10T00:23:58.771Z","logger":"watcher","caller":"oci/oci.go:150","msg":"Starting attestation upload to OCI for index.docker.io/sbose78/foobar@sha256:ca76bc767e181c4a2a03413fe84bd7608a969a2fdd9646b0c262dc82149ec06f...","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7"}
{"level":"error","ts":"2022-01-10T00:23:58.772Z","logger":"watcher","caller":"chains/signing.go:207","msg":"getting signed image: open containers/auth.json: permission denied","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7","stacktrace":"github.com/tektoncd/chains/pkg/chains.(*TaskRunSigner).SignTaskRun\n\tgithub.com/tektoncd/chains/pkg/chains/signing.go:207\ngithub.com/tektoncd/chains/pkg/reconciler/taskrun.(*Reconciler).FinalizeKind\n\tgithub.com/tektoncd/chains/pkg/reconciler/taskrun/taskrun.go:61\ngithub.com/tektoncd/chains/pkg/reconciler/taskrun.(*Reconciler).ReconcileKind\n\tgithub.com/tektoncd/chains/pkg/reconciler/taskrun/taskrun.go:42\ngithub.com/tektoncd/chains/vendor/github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun.(*reconcilerImpl).Re...
{"level":"info","ts":"2022-01-10T00:23:59.126Z","logger":"watcher","caller":"chains/signing.go:217","msg":"Uploaded entry to https://rekor.sigstore.dev with index 1042420","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7"}
{"level":"error","ts":"2022-01-10T00:23:59.145Z","logger":"watcher","caller":"taskrun/reconciler.go:308","msg":"Returned an error","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7","targetMethod":"ReconcileKind","error":"1 error occurred:\n\t* getting signed image: open containers/auth.json: permission denied\n\n","stacktrace":"github.com/tektoncd/chains/vendor/github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun.(*reconcilerImpl).Reconcile\n\tgithub.com/tektoncd/chains/vendor/github.com/tektoncd/pipeline/pkg/client/injection/reconciler/pipeline/v1beta1/taskrun/reconciler.go:308\ngithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tgithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller/controller.go:542\ngit...
{"level":"error","ts":"2022-01-10T00:23:59.145Z","logger":"watcher","caller":"controller/controller.go:566","msg":"Reconcile error","commit":"48a85c4","knative.dev/controller":"github.com.tektoncd.chains.pkg.reconciler.taskrun.Reconciler","knative.dev/kind":"tekton.dev.TaskRun","knative.dev/traceid":"fb99b1f9-acdf-434a-87eb-1787388908c5","knative.dev/key":"tekton-chains/new-pipeline-sye5yl-buildah-2gms7","duration":1.368152566,"error":"1 error occurred:\n\t* getting signed image: open containers/auth.json: permission denied\n\n","stacktrace":"github.com/tektoncd/chains/vendor/knative.dev/pkg/controller.(*Impl).handleErr\n\tgithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller/controller.go:566\ngithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller.(*Impl).processNextWorkItem\n\tgithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller/controller.go:543\ngithub.com/tektoncd/chains/vendor/knative.dev/pkg/controller.(*Impl).RunContext.func3\n\tgithub.com/tektoncd/chains/vendor/knative.dev/pkg...
{"l

Steps to Reproduce the Problem
With the following config,
  artifacts.taskrun.format: tekton-provenance
  artifacts.taskrun.storage: oci
  transparency.enabled: 'true'

Install chains v0.5.0 and create a Task/TaskRun for https://gist.github.com/sbose78/1e348752bd2de0e528d953f896f89d13 , ensure signature upload succeeds. This includes setting up of auth as per the docs https://github.com/tektoncd/chains/blob/main/docs/authentication.md
Upgrade from chains 0.5.0 to 0.6.1
Re-run the Task that had worked before.

Additional Info

Kubernetes version:
Output of kubectl version:

kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5", GitCommit:"aea7bbadd2fc0cd689de94a54e5b7b758869d691", GitTreeState:"clean", BuildDate:"2021-09-15T21:10:45Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3+e790d7f", GitCommit:"3a0f2c90b43e6cffd07f57b5b78dd9f083e47ee2", GitTreeState:"clean", BuildDate:"2021-12-14T02:10:38Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

Tekton Pipeline version:
v0.28.2

I'm pushing to Dockerhub.

@sbose78 surprisingly, I saw something like this some time back on OpenShift and oc adm policy add-scc-to-user anyuid -n tekton-chains -z tekton-chains-controller fixed it for me. Not sure if this helps though 😅

Hey @sbose78 so I tried to repro this @ HEAD with our kaniko task and pushing to DockerHub. It worked as expected for me, so I looked into the error.
We use the go-containerregistry library for registry auth in k8s and based on their auth doc:

The DefaultKeychain will use credentials as described in your Docker config file -- usually ~/.docker/config.json, or %USERPROFILE%.docker\config.json on Windows -- or the location described by the DOCKER_CONFIG environment variable, if set.

If those are not found, DefaultKeychain will look for credentials configured using Podman's expectation that these are found in ${XDG_RUNTIME_DIR}/containers/auth.json.

Seems like the Chains controller isn't finding any Docker auth. How are you passing it in?

@priyawadhwa I've been associating the Secret to the service account that's running the TaskRun.

@sbose78 surprisingly, I saw something like this some time back on OpenShift and oc adm policy add-scc-to-user anyuid -n tekton-chains -z tekton-chains-controller fixed it for me. Not sure if this helps though 😅

😮 I think that will work, let me try. I think that's what I had done a while ago as well.

@sbose78 cool, let us know if that fixes it!

@sbose78 cool, let us know if that fixes it!

That fixes it but that shouldn't be necessary though. I think if there is no $XDG_RUNTIME_DIR set in the image, and thus it makes it look at /containers/auth.json, which.. is probably why the failure. I wonder why is this returned as an error though, in those case we should probably consider "not found" and "no permission" similarily, we couldn't get auth, let's move on. @imjasonh wdyt ?

https://github.com/google/go-containerregistry/blob/c6366444aa46d4d05854960485646f5d7a2bcd09/pkg/authn/keychain.go#L103 would probably need a better handling, using the XDG_RUNTIME_DIR default instead of nothing if the env is not there.
$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

From https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html.
We should either set it in the chains controller image or update go-containerregistry that would default it to something that is 99% of the case user readable (by anybody).

I think between #342 and #346 this should be fixed?

Well, #342 should fix this particular error, I tried and it's working fine but I'd defer to @sbose78 for closing this.
Note: on OpenShift, due to #346 anyuid scc is still going to be required.

I think this is done. @sbose78 feel free to reopen if it's still not working.
/close


Add colors when style is forced

(@see: https://github.com/JakubOnderka/PHP-Parallel-Lint/issues/78)

I now think this change is not needed. Sorry.


Publishing release as single file does not include all libraries (libgssapi_krb5)

I'm trying to create a single-file binary to run on Linux; however, it does not include all libraries.  I'm unclear why the Kerberos library is needed.
To reproduce:
➜  dotnet --version
5.0.100
➜  dotnet new console -o single-file
The template "Console Application" was created successfully.

Processing post-creation actions...
Running 'dotnet restore' on single-file/single-file.csproj...
  Determining projects to restore...
  Restored /Users/thfalgou/tmp/dotnet/single-file/single-file.csproj (in 64 ms).
Restore succeeded.
➜  cd single-file
➜  dotnet publish -r linux-x64 -p:PublishSingleFile=true -c Release
Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored /Users/thfalgou/tmp/dotnet/single-file/single-file.csproj (in 89 ms).
  single-file -> /Users/thfalgou/tmp/dotnet/single-file/bin/Release/net5.0/linux-x64/single-file.dll
  single-file -> /Users/thfalgou/tmp/dotnet/single-file/bin/Release/net5.0/linux-x64/publish/
➜  file bin/Release/net5.0/linux-x64/publish/single-file
bin/Release/net5.0/linux-x64/publish/single-file: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4, stripped, too many notes (256)

Start an Ubuntu instance via docker
➜  docker run -it -v $PWD/bin/Release/net5.0/linux-x64/publish:/tmp/single-file ubuntu bash
root@e91793747e67:/# cd /tmp/single-file/
root@e91793747e67:/tmp/single-file# ls
single-file  single-file.pdb
root@e91793747e67:/tmp/single-file# ./single-file
./single-file: error while loading shared libraries: libgssapi_krb5.so.2: cannot open shared object file: No such file or directory
root@e91793747e67:/tmp/single-file# ldd ./single-file
	linux-vdso.so.1 (0x00007ffc371c4000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1b744cd000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1b744c7000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1b744ab000)
	libgssapi_krb5.so.2 => not found
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1b744a0000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1b742bf000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1b7416e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1b74153000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b73f61000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1b75126000)

As you can see, libgssapi_krb5.so.2 was not included.
Due to -p:PublishSingleFile=true, I would expect the application to be a statically linked library instead of a dynamically linked one.

This issue was moved to dotnet/runtime#45720


can't download channels anymore

Single videos are still working, wohle channels aren't.
G:>youtube-dl --cookies cookies.txt --username PRIVATE --pas
sword PRIVATE -f 140/m4a -i -o F:\yt/%(uploader)s/%(title)s_%(upload_date)s_%
(autonumber)s.%(ext)s -a you.txt --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--cookies', 'cookies.txt', '--username', 'PRIVATE',
'--password', 'PRIVATE', '-f', '140/m4a', '-i', '-o', 'F:\yt/%(uploader)s/%(ti
tle)s_%(upload_date)s_%(autonumber)s.%(ext)s', '-a', 'you.txt', '--verbose']
[debug] Batch file urls: ['https://www.youtube.com/channel/UCJLlzmRbgBvi7sDtv1Wk
wXg']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2<IP_ADDRESS>
[debug] Python version 3.4.4 - Windows-7-6.1.7601-SP1
[debug] exe versions: none
[debug] Proxy map: {}
[youtube:channel] Downloading login page
[youtube:channel] Looking up account info
[youtube:channel] Logging in
[youtube:channel] Checking cookie
[youtube:channel] UCJLlzmRbgBvi7sDtv1WkwXg: Downloading channel page
[youtube:channel] UCJLlzmRbgBvi7sDtv1WkwXg: Downloading page #1
[download] Downloading playlist: UCJLlzmRbgBvi7sDtv1WkwXg
[youtube:channel] playlist UCJLlzmRbgBvi7sDtv1WkwXg: Downloading 0 videos
[download] Finished downloading playlist: UCJLlzmRbgBvi7sDtv1WkwXg
Hope this helps, thanks.

I have the same problem

Bump. Actually 1 out of 100 times it may still work.

I have the same problem

I have been able to replicate this problem on Ubuntu 16.04 LTS.

Duplicate of #14083


datable formwidget within a translatable repeater clears values on locale switch

If there is a datatable formwidget within a mlrepeater it does not send it's values over POST when switching locale.
The reason is that the table widget listens to a postback handler with the name onSave by default and only attaches the table values to the request if this ajax handler is used.
The solution is to temporary set the handler to the onSwitchItemLocale when the locale is beeing changed.

@der-On TBH, I would rather a fix that changes the Table widget to provide its data at all times, not just on a specific AJAX callback. The callback is more for tables that use server side data storage, essentially operating independently from the form. When the table is used normally (entirely client side), its data should be sent through the POST like any other field.
This particular change is probably a little too abstract and "hacky" to accept as it is.

No problem. Then I'll wait for the fix in the Table widget and use my fork until then.

@der-On if you could provide a PR for that then that would be the best way forward; we're currently very busy on a number of complex projects (Laravel 9 finalizations, static analysis, search plugin, tailwind UI skin, new website / marketplace, etc - all in addition to our regular day jobs) so the best we could do for you is provide code review on your requested changes.

@LukeTowers Sure no problem. Thank for your faith. Happy to help.

@bennothommo @LukeTowers Where exactly can I provide a PR for the backend module? The repository on github says it's a "read only mirror".

@der-On You need to clone winter/winter into your repo, then create a branch in your repo for this PR.
Once this is done, you need to create a PR from github to Winter's repo against your repo.

@der-On the wintercms/winter repository.

@LukeTowers @bennothommo PR is now here: https://github.com/wintercms/winter/pull/560


MLJ 0.17 update for tutorial 03: .jl, .ipynb (new), .unexecuted.ipynb

This includes the refactoring for non-macro pipelines, and using the new TransformedTargetModel wrapper.
It also adds an executed version of the jupyter notebook.

Codecov Report

Merging #26 (2e0ea1c) into dev (3fc1834) will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##             dev     #26   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files          1       1
  Lines          4       4
=====================================
  Misses         4       4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3fc1834...2e0ea1c. Read the comment docs.


Feat timeseries carbon charts - issues fixes

Change List (commits, features, bugs, etc)

Console error about missing width/height prop

Locale set default to en

Tooltip formatter when high numbers and when unit  prop provided

:tada: This PR is included in version 1.71.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.0.0-beta.9 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.71.3 :tada:
The release is available on npm package (@release-1.x dist-tag)
Your semantic-release bot :package::rocket:


PLAT-53627: Consolidate ProgressBarTooltip positioning props

Issue Resolved / Feature Added
We have two props to control positioning a ProgressBarTooltip which could be consolidated into one.
Resolution

Consolidated into side which supports before, after, left, and right
Converted tooltip to be either bool/element/func for consistency with the new Slider rewrite

Enact-DCO-1.0-Signed-off-by: Ryan Duffy<EMAIL_ADDRESS>

Looking awesome but a few loose ends:
Currently tooltip positions outside of the ProgressBar when progress is out of range; should we handle the tooltip position when progress is less than min and larger than max?
Not sure if the off by one error is in this PR or another one but I noticed that IncrementSlider skips 29% and 58%; and repeats 56% twice

About the IncrementSlider, it only reproduces in sampler for me 🤔

Not too worried about progress being out of bounds. We already have dev mode warnings for the range in ui/ProgressBar and that's probably sufficient for now

Rebased this on develop since it previously included all the slider refactor commits.


Still need help with developing for OS X?

I'd love to help!

After downloading it and running make it would appear so... I'll poke around some more in the morning. It's getting late where I live.

Running make fails because the file system layout on OS X unlike to those on other Unix-like systems.  Also, I think it would be better to package Syncplay as an .app on that system, rather than copying files to where they belong.

changing it to use /usr/local as the prefix seems to work as /usr is owned
by root. /usr/local is used by homebrew so it's not an uncommon pattern as
far as I know to use that directory. packaging it as an app is definitely
something to consider. the issue with that is you'll run into problems with
OS X's security settings if you aren't a verified publisher. I'm not quite
sure what the workflow is for that if you want to distribute the app
outside the App Store.
On Mon, Dec 7, 2015 at 01:29 Georg G<EMAIL_ADDRESS>wrote:

Running make fails because the file system layout on OS X unlike to those
on other Unix-like systems. Also, I think it would be better to package
Syncplay as an .app on that system, rather than copying files to where they
belong.
—
Reply to this email directly or view it on GitHub
https://github.com/Syncplay/syncplay/issues/81#issuecomment-162461618.

It seems that most people usually create a disk image (i.e. .dmg) big enough to hold the .app directory and a symlink to the /Applications directory.  Regarding OS X's security settings, depending on your setting, it will display a warning on the first start and you have to open the System Preferences app to allow the system to run it.
Also, for packaging Python applications as an .app there is a tool/library/whatever similar to py2exe, namely py2app.  Let's see if this thing works.

Yes, we certainly still need help getting Syncplay to work properly on OS X. The ones that I am aware of are:
1.  A way to generate a native package for Mac that "just works".
I don't know the terminology (.app files?), but if we can make some sort of installer which people can use to run Syncplay on Mac without Miniconda, command line, etc then that'd be great. Ideally it would be easily generated on a Windows or Linux machine, so we can make a new package/installer whenever a new version of Syncplay is out.
2. Double check installation instructions
If the above is not possible, review the instructions at http://syncplay.pl/guide/install/#OSX and suggest any changes if they are necessary.
3. Fix the menu bar in OS X
At present the  PySide menu bar works on Windows and Linux, but not OS X. Possibly running it natively will fix that, but whatever the case we want it to show up.
4. Fix VLC/mpv on OSX
Some people have reported Syncplay making erroneous jumps/seeks, primarily in relation to VLC but also in relation to mpv. I'm not 100% sure if this is due to those programmes freezing, them mis-reporting an old position, or a combination of the above. Hopefully this will be fixed by making Syncplay run natively, but either way it wants to be fixed if possible. If it is detected that the problem is VLC/mpv's, we need enough evidence for a bug report.
5. Fix closing on VLC
It'd be nice if, when you closed via VLC, it closed Syncplay. This works fine on all OSes except OS X, where it only works half the time. This might be fixed by running Syncplay natively, but might not. I'm not sure if there is anything that can be done from our side to fix this. This is a minor issue compared to the others, and it might be fixed in the latest version of VLC.

This looks promising for building cross platform packages: http://docs.python-guide.org/en/latest/shipping/freezing/

I'll be looking into the other issues you brought up as well.

I've been thinking about building a seperate frontend for Syncplay, which would be used on systems running OS X.
It could even be written in Python, since it seems that OS X comes with Cocoa/Foundation/AppKit bindings for Python preinstalled.  On my system these are located at /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC.
Also, many other projects seem to do this (e.g. VLC, Handbrake to name a few)
Thoughts on that?

Hey, I have used the Mac version so I know all about the bugs.
I currently run the app through the CrossOver app for Mac without issues (although it is not ideal).

@kylestev It'd be great if someone could test some of the potential freezing solutions to see if they worked with VLC and mpv without the skipping bugs that seem to occur on some versions of OS X when running Syncplay via miniconda. Once we have a winner I need to be explained how to roll it out. Also, it'd be interesting to know if they resolve the menu bar issue and are easy to install.
@nilsding Great to hear that you have so much energy for OS X UI development. I assume having a Mac-based interface will allow for a better experience for OS X users. My main concern is that not only will it be a lot of work to do, but it will be a lot of work to maintain. At present Syncplay does not always properly separate between UI code and system logic, and more UI updates will be needed for the upcoming shared playlists feature.
@es0phagus It'd be useful if you could write a short guide on running Syncplay on Mac via CrossOver app. CrossOver is not an ideal solution as the software is not free, but if it actually works without issues then it's worth letting people know about.

@Et0h Well, I guess we should focus to seperate UI code and system logic after the implemention of the shared playlist feature is done (i.e. merged to the master branch).  Once that's done, we can (hopefully) easily implement other interfaces without any problems.
Yes, it's going to be a lot of work to do, but I'm sure it will be worth it in the end.  I think that maintaining the seperate UI won't be that much of a problem once it's implemented, the maintainer(s) of that part would have to communicate with the other Syncplay developers about the changes (or just read the diffs of the PySide UI) and then implement them in the Cocoa UI.

I have to agree with @Et0h in that it would seem to me like an unnecessary duplication of work. You do seem eager to help out with this which is great, but what if that interest passes? Who will remain to keep it maintained? The core team would want to make changes to the gui, but they may be hampered by the recognition that no one will be there to replicate the changes in the OS X code, causing divergence.
I'm under the impression that some of those applications that have native OS X gui code probably do it because they are more complex in nature---VLC certainly is---and more low-level, which might require them to access more low-level GUI functionality from the host system. I don't think syncplay requires that much complexity yet.
That said, I think your idea of at least for now focusing on decoupling the UI from the logic is definitely a worthwhile one.
I do wonder though, it was my understanding that Qt applications were supposedly basically-indistinguishable from native apps nowadays on OS X, is this not the case? Would a separate UI mainly be from a design language perspective? Would these not be changes that would possibly benefit the other platforms?
My recommendation would be to see if we can work out some of your proposed UI changes within the current Qt UI code. It would allow us to maintain a single code base without duplicating work, and I think the design changes could benefit all of the other platforms. If over the course of this we identify certain aspects that can't be done without diving deeper to Cocoa/etc., we could revisit this. Currently, however, I'm not sure what the reasons would be for keeping two separate code bases.

nilsding's #86 appears to have resolved the menu bar issue. Onwards!

Related OS X Issue: https://github.com/Syncplay/syncplay/issues/83

Another thing I've noticed while using Syncplay on OS X is that it seems to lose the connection to the server (and player) every minute or so for no apparent reason.  Interestingly enough, it's only when the GUI is active and a file is playing.  Starting Syncplay without a GUI seems to work.

@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.
Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a  bash script to retrieve and install the necessary stuff(or both).
I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.

Hey, I ignored this by accident for a long time now. Err, my workaround with Crossover is behaving like the native install now -- it keeps dropping the connection to the server and reconnecting every few mins. Perhaps upgrading to the latest OS X El Capitan broke it, I do not know.

On 5 Jun 2016, at 06:26, vladashram<EMAIL_ADDRESS>wrote:
@Et0h Interesting, what @es0phagus suggested got me thinking. I did some testing and discovered it works well in WINE(even works with native MPV, VLC is untested), which is what programs that run Windows software on OS X and Linux use.
Also I can help you with revising the OS X installation. The Native installation instructions are a bit convoluted. I could either write better instructions, or try to write a bash script to retrieve and install the necessary stuff(or both).
I don't know too much python, I took a very small intro class a few years ago, but if you were interested I might be able to assist you with getting it running in an App package.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?

Yes, but now I use a virtual stimulation program called Veertu, in which I installed windows 8 and I use Syncplay via that.

On 3 Jul 2016, at 15:46, Etoh<EMAIL_ADDRESS>wrote:
I'm guessing it was the upgrading to El Captain that did it. Don't know how to resolve, but hopefully a fellow Mac user will be able to help. Is the only way to get it to work properly to use WINE?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

It would be great if you could work on https://github.com/Syncplay/syncplay/issues/89 and https://github.com/Syncplay/syncplay/issues/87 and resolve the freezing issue or to create a guide to running Syncplay on OS X via emulation (Wine, Veertu, etc)


Changing 'touched' state to reflect the common notion of 'touched'

@tannerlinsley want to get your thoughts on this. Generally, touched in other frameworks, libraries, etc. represents a field that has been focused/blurred. The touched state in react-form seems to represent dirty, but without the touched state, it's difficult to have a UX that needs to show validation on blur. Currently, with touched representing dirty, validation messaging will immediately populate as soon as a user types one character. For things like email fields this isn't great, as the user likely hasn't finished typing. I understand there is a concept of debounce, but I feel like that is solving something different.

Agreed. This is good. What if the user wants to actually validate as you type tho?

Thinking we’ll need to add a “dirty” state. I can add it to this PR, just wanted to make sure you agreed first 👍

Sounds good to me. Try to keep it all non breaking?
Tanner Linsley
On Nov 3, 2019, 8:35 AM -0700, cpepin<EMAIL_ADDRESS>wrote:

Thinking we’ll need to add a “dirty” state. I can add it to this PR, just wanted to make sure you agreed first 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Btw, really dig the approach you took with all of this.

For sure 👍

Aww thanks man!
Tanner Linsley
On Nov 3, 2019, 8:36 AM -0700, cpepin<EMAIL_ADDRESS>wrote:

Btw, really dig the approach you took with all of this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

I just wanted to bump this as it would be incredibly helpful to our team. Thanks all!

@tmilewski I definitely don't mind pitching in, the more I think about it though - I'm not sure we can do this without a breaking change. It fundamentally changes how touched is working.

@cpepin No worries, I appreciate all the work! I agree. I don't think that there is a way this pans out without a breaking change.
That said, I feel that as long as there's a different way to identify touched it as people have come to expect, doing that and bumping a major version number should be okay.

Tossing in another opinion/bump here - It seems appropriate to bump the major version with this change. I've also struggled with this usage of touched vs dirty where my forms are showing errors earlier than i want them to, but i have no way to defer the showing of errors until a blur occurs

@tannerlinsley what are your thoughts on a major release for this? I don’t mind contributing the code but I’ve been avoiding jumping on it, as I didn’t want to introduce any breaking changes.

anything new about this topic? do you have any workaround for this one?

It's the biggest problem of the lib, dosn't has dirty, because the error is showing earlier... so make the libary useless

Closing this PR for now, as we're working on a substantial rework of the codebase that's expected to undergo more rapid changes as I work on stabilizing things.
Rest assured that we'll have isDirty and isTouched as two distinct items :)
If you'd like to get involved in the rework, join our Discord and reach out in the #form channel


Update README.md

Modified Login Redirect URI section as per report from support case 00570237.

Thanks! I'll have to check and see if there are other repos with the same mistake.

@dragosgaftoneanu-okta Does the blog post need to be updated too? I'm not sure if there's a companion blog post since this repo doesn't link back to it.

Hi @mraible
I did not find any blogs linked to this repository.

It appears to be a Scotch.io article: https://scotch.io/tutorials/build-simple-authentication-in-express-in-15-minutes

I'll try to get access and fix it. Note that there's a comment pointing out additional issues.


Ability to stop/cancel a query

I'm not sure what I'm trying to achieve is possible, it can also depend on mysql protocol. Imagine I'm looking for something on a table, but I'm not sure where it is (because I have to analyse the records), so I make a query (possibly with some conditions and an order, but still.. too many records) and I start listening on the row event. Is it possible to, if I find what I'm looking for, stop or destroy the query and ignore future results (and possibly tell mysql server to stop streaming more stuff..) ?

Cancel would be a plus but not really crucial. What I wanted was to call something like Query.cancel() and be able to ensure no more row events would trigger. That would be nice.. if not I'll have to do it myself :p


Fix typo in README.md

I've filed a bug about this if you don't want to use Gerrit. We can take care of it. Thanks!

Cool, sounds good. I'll move onto to looking at bigger things than minor typos in a readme then. :-)


Size based rollover logging broken in 1.0.0

We use size based rollover logging in DW. After upgrading to 1.0.0, no log files are produced at all. I have recreated the problem with a completely basic app (pretty much from the Getting Started example).
The following configuration file will result in NO logging whatsoever:
server:
  type: simple
  connector:
    type: http
    port: 9090

logging:
  level: TRACE
  appenders:
    - type: file
      currentLogFilename: ./logs/example.log
      archivedLogFilenamePattern: ./logs/example.%i.log.gz
      archivedFileCount: 5
      maxFileSize: 1KB

I have found that changing the archivedLogFilenamePattern to the following will cause logging to work again: archivedLogFilenamePattern: ./logs/example.%d.%i.log.gz
So adding a size and time based rolling policy works, but it is not exactly what we wanted. A purely time based rolling policy also works fine.
I attempted to recreate the problem with logback only, but was not able to. So I suspect the problem lies in io.dropwizard.logging.FileAppenderFactory.buildAppender.

This was addressed with #1660


There was a joke I had in mind but I don't think it worked. Oh well.


Can't build with Carthage

Getting this error:
*** Building scheme "ReactiveHeimdallr-iOS" in Heimdallr.xcworkspace
The following build commands failed:
	Check dependencies
(1 failure)
** BUILD FAILED **

The following build commands failed:
	Check dependencies
(1 failure)
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later

for targets which use Swift. Use the [Edit > Convert > To Current Swift Syntax…] menu to choose a
Swift version or use the Build Settings editor to configure the build setting directly.```

Edit: Using Swift 3. There's a PR from @marcelofabri here: https://github.com/trivago/Heimdallr.swift/pull/94, but it seems there's issues with RAC.

hello @dccarmo, as mentioned in #94 we are currently waiting for RAC swift 3.0 support before we can release heimdallr with swift 3.0.. Until then we have to stick to the latest rc which supports swift 2.3.

Yeah, I'll just close this for now.


fix(engine-core): Use commit hash as an engine version

Actual package version is always 0.1.0, so not very useful.
Fix #10125

@danstarns I'd like to do it, but i don't see good way, unfortunately. There are number of problems with testing this:

To really be safe against re-introduction we'd have to run against real engine, mock probably won't be helpful, since person re-introducing the bug will just update mock value.
This code path is executed only in case of rust panic, which ideally should never happen. So, if we are running against real engine, we'll have to crash it somehow during the test. I suppose engine people could've added a special method which will panic every time it's called specially for testing this kinds of things, but:
Hash is compiled into the dynamic library on rust side, not read from any external sources. Since we have to be running against real engine, hash will always update with the new engine version. So, we'll have to resort to mocking again

Hash is compiled into the dynamic library on rust side, not read from any external sources. Since we have to be running against real engine, hash will always update with the new engine version. So, we'll have to resort to mocking again

Alternatively, it should be possible to check the properties of this string instead of comparing it with a fixed value, i.e., check that it looks like a hash using a regex.

You could also compare the string returned by the engine with what we expect the Engine version to be via @prisma/engine-version.


named UOp class "NOP"

https://github.com/tinygrad/tinygrad/pull/5444#issuecomment-2227150287

can you remove UOp.VAR as part of this?

Also, run process replay. Otherwise looking good!

process replay has run https://github.com/tinygrad/tinygrad/actions/runs/10111497854/job/27963562272?pr=5728

done. reused NOOP not sure if this is cool

Cool!


running update should also run setup:local?

Or:
setup:remote => setup
setup:local + update => update... or apply?


[Gally]: master <- dev

Automatically created by Git-Ally

:tada: This PR is included in version 3.0.44 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket: