Update color 'primary' to 'pink' after redesign

Description

This PR updates the usages of the color primary to reference pink as it was planned to be done after the redesign launch.
Testing Instructions

Check out the PR and run the Storybook & dev server.
Search for the usages of color 'primary'.
The usages should all be pink.

Checklist

[x] My pull request has a descriptive title (not a vague title like Update index.md).
[x] My pull request targets the default branch of the repository (main) or a parent feature branch.
[x] My commit messages follow best practices.
[x] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[x] I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

I suppose any changes to the brand in the future will involve more than color. Currently the usage of 'pink' is much more prevalent as compared to 'primary' which is just used in 2 places.

Gotcha. I think we should re-evaluate this and think about how we use design tokens. You're right that a re-design would include more than color, but it could be "just color". Likewise, using a token like "primary" would make things like a dark-mode based on tokens easier to reason about instead of "pink" which would likely have a different color entirely under a dark-mode (maybe).
Either way, it's good to get rid of the two different names for the token, but I'd be interested in getting clearer decision making around whether to use generic token names or to use the color-names for the tokens.


Add title prefix on scaladoc

Addresses #1701
This PR adds "Scala.js" and version as title on scaladoc pages, so that developes can recognize pages are for what library and version.

Oops. I commited as wrong user.

Also, consider targeting 0.6.x for this change.

Should I create another PR with same changes against 0.6.x?

Should I create another PR with same changes against 0.6.x?

No, you can change the target branch of this PR (click on Edit next to the PR title), then rebase -i 0.6.x your branch locally and then force-push it. No need to have 2 PRs for the same stuff.

Target branch changed to 0.6.x


Update to context.tf

what

Update to context.tf

why

Standardization and interoperability
Keep the module up to date

/test all

/test all


License Information

Tom, could you provide license information for this repository. Thanks.

Hey @machbio here it is : https://github.com/thaume/s3-streaming/commit/ff175913a08666b85b46a67745f83a329e963343
I don't know what you intend on doing with this repo but the code is pretty old, careful using it ;)

Thank you - for the Blog post and Repo


Bad Request: can't parse entities: Unexpected end tag at byte offset XXX

Hey,
I do not get anymore notifications after a difference is detected over telegram. Pushing manually a notification is not a problem. Differences are visible too but it will not forward.
Notification body has a static URL and the token {diff}.
Notification format is at "HTML". Could it be that HTML format bring up the issue? I have over 20 entries which is growing at the moment.
Short output of logs which is growing at the moment.
b'{"ok":false,"error_code":400,"description":"Bad Request: can\'t parse entities: Unexpected end tag at byte offset 254"}'
2022-05-04 17:10:20,975 - DEBUG - Response Details:
2022-05-04 17:10:20,975 - WARNING - Failed to send Telegram notification to -XXXXXXXXX: Bad Request: can't parse entities: Unexpected end tag at byte offset 254, error=400.
2022-05-04 17:10:20,731 - DEBUG - Telegram Payload: {'disable_notification': False, 'disable_web_page_preview': True, 'parse_mode': 'HTML', 'text': 'Bauhilfe - Wohnen\r\nCheck -> https://www.bauhilfe.at/wp/angebote-sofort-wohnen\r\n(removed) * Referenzen\r\n(removed) + Karte\r\n(removed) + Liste\r\n(removed) * Wohnen
(removed)', 'chat_id': -XXXXXXXXX}
2022-05-04 17:10:20,725 - DEBUG - Telegram POST URL: https://api.telegram.org/bot5XXXXXXXXX7:AAE33D3gXXXXXXXXXTENyQtDE/sendMessage (cert_verify=True)
2022-05-04 17:10:20,667 - INFO - Notifying 1 service(s) asynchronously.
2022-05-04 17:10:20,589 - DEBUG - Loaded Telegram URL: tgram://5...E/%40-XXXXXXXXX/?image=False&detect=yes&silent=no&preview=no&format=html&overflow=upstream&rto=4.0&cto=4.0&verify=yes
b'{"ok":false,"error_code":400,"description":"Bad Request: can\'t parse entities: Unexpected end tag at byte offset 223"}'

duplicate https://github.com/dgtlmoon/changedetection.io/issues/555


[ vscode tunnel] After one session, it can't connect to "localhost:5500"

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

VS Code Version: 1.74.2-e8a3071ea4344d9d48ef8a4df2c097372b0c5161-x64
OS Version: Ubuntu Server 22.04.1 LTS

Steps to Reproduce:

Install VSCode from .deb package from: https://code.visualstudio.com/Download
Add a Code Tunnel as a .service so it starts on machine startup
Open a session and close the session
Try and connect to another session on the same machine
VScode can't connect to the code tunnel anymore
vscode tunnel outputted:

Dec 26 13:13:50 <hostname> code[4761]: [2022-12-26 13:13:50] info [tunnels::connections::relay_tunnel_host] Opened new client on channel <number>
Dec 26 13:13:51 <hostname> code[4761]: [2022-12-26 13:13:51] info [tunnels::connections::relay_tunnel_host] Error connecting forwarding to <IP_ADDRESS>:5500, Connection refused (os error 111)

My .service file that runs VScode tunnel:
[Unit]
Description=Visual Studio Code Tunnel Service
After=network.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=always
RestartSec=1
User=<my username>
ExecStart=/usr/bin/code tunnel

[Install]
WantedBy=multi-user.target

To wake up the VScode tunnel so i can use it again, i have to restart the service. E.G. service code-tunnel.service restart

Fiirefox7 Enterprise

If you run top/htop in the state where you can't connect, do you see a VS Code server running with high CPU usage? If so, that may be https://github.com/microsoft/vscode-remote-release/issues/6543

If you run top/htop on the host machine in the state where you can't connect, do you see a VS Code server running with high CPU usage? If so, that may be microsoft/vscode-remote-release#6543

I don't, The most I see is a VSCode Node process running with ~0.6% CPU of my not-so-powerful server i'm running it on.
Now I can't connect, but it's not throwing Can't connect to localhost:5500 anymore, bur still can't connect. It's now apparently closed localhost:5500
Now the output of systemctl status code-tunnel is:
sudo systemctl status code-tunnel
● code-tunnel.service - Visual Studio Code Tunnel Service
     Loaded: loaded (/etc/systemd/system/code-tunnel.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2023-01-05 07:21:51 UTC; 10h ago
   Main PID: 26228 (sh)
      Tasks: 92 (limit: 8148)
     Memory: 823.8M
        CPU: 1min 39.918s
     CGroup: /system.slice/code-tunnel.service
             ├─26228 sh /usr/bin/code tunnel
             ├─26243 /usr/share/code/bin/../code /usr/share/code/bin/../resources/app/out/cli.js --ms-enable-electron-run-as-node tunnel
             ├─26256 /usr/share/code/bin/code-tunnel tunnel
             ├─26986 sh /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/bin/code-server-insiders --connection-token=vaKaQBsrfDUehdNBx314CGDafYijS9_U-AXQsjs7YX4 --accept>
             ├─26990 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/out/serv>
             ├─27001 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/out/boot>
             ├─27012 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/out/boot>
             ├─27023 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/out/boot>
             ├─27049 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/extensio>
             ├─27863 /usr/bin/zsh -i
             ├─28561 /bin/sh /home/realfx/.vscode-server-insiders/extensions/ritwickdey.liveserver-5.7.9/node_modules/opn/xdg-open http://<IP_ADDRESS>:5500/
             ├─28576 sh /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/bin/helpers/browser.sh http://<IP_ADDRESS>:5500/
             └─28581 /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/node /home/realfx/.vscode-cli/server-insiders/bin/4acf2d9b46b75748ae687cf3b2952a0799679873/out/serv>

Jan 05 17:37:48 the-fem-coding vsce-sign[27119]: Primary signature status:  OK
Jan 05 17:37:48 the-fem-coding vsce-sign[27119]: Timestamp signature status:  OK
Jan 05 17:37:48 the-fem-coding vsce-sign[27119]: Exit code:  Success
Jan 05 17:41:33 the-fem-coding code[26243]: [2023-01-05 17:41:33] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 3
Jan 05 17:41:34 the-fem-coding code[26243]: [2023-01-05 17:41:34] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 4
Jan 05 17:41:36 the-fem-coding code[26243]: [2023-01-05 17:41:36] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 5
Jan 05 17:44:08 the-fem-coding code[26243]: [2023-01-05 17:44:08] info [rpc.0] Unforwarding port 5500
Jan 05 17:44:17 the-fem-coding code[26243]: [2023-01-05 17:44:17] info [rpc.0] Forwarding port 5500
Jan 05 17:44:18 the-fem-coding code[26243]: [2023-01-05 17:44:18] info [rpc.0] Disposed of connection to running server.
Jan 05 17:44:20 the-fem-coding code[26243]: [2023-01-05 17:44:20] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 6

This is happening to me periodically when I run ng serve to develop Angular apps. I'll specifically run ng serve --host=<IP_ADDRESS> and it will sometimes open port 4200 fine, other times it will immediately crash the connection to VSCode Desktop, but leave the port open. I then have to restart VSCode Server to close the port. If I open vscode.dev in the browser and navigate to my VSCode Server through there, it'll open fine, but still claim that 4200 is in use. Definitely something up with port forwarding

Following up here.
The "Error connecting forwarding" is an error that happens when you have a forwarded port for which a service is no longer listening on the machine. It's followed by the address it tried to connect to, and the network error that it encountered.
If you hit this, something good to check is that you're listening on <IP_ADDRESS> rather than localhost, since sometimes localhost refers to the ipv6 loopback (::1) which we don't currently forward to.


Tested controller

Hi,
I came across your project and found that it would great for my garage. I prefer to use tested code, so I've added test support for this project. Some refactoring of the code was done to improve readability and testability. No new functionality was added. A few bugs were found through testing.
Regards,
JF

This is great.  I'd be happy to merge it in, but I think I merged some of the other changes in first and they are in conflict with your pull request.  Would you mind resolving the conflicts and submitting a new pull request?

Conflicts should be solved now.

Few things:  First of all, the pull request still shows up as conflicted.  Admittedly I'm not all that savvy with Git (more experienced with SVN) so I'm not sure how to go about resolving it.  If you can fix the pull request so that it can be cleanly merged, I can integrate it.
Second, can you explain a little bit about how you refactored the code?  It looks like you split the controller.py file into two separate files (which makes sense), but is there any special build/test process that we would need to follow?

The conflict were solved, but you merged more pull request. I'll resolve the new conflicts.
A lot of the refactor was done to allow testing of the controller and enable some mocking of key functions. You can run the test with the following command:
$ python3 -u -m unittest test/test_garage_controller.py

Conflicts are solved. Since this is a big change, I suggest that you avoid doing minor commits until this get in. Otherwise, conflicts with keep happening.

Thanks!  I'll take a look over the code and merge it in as soon as I get a chance.


Preparing for first release of generated dataproc client

First try following the python documentation.

@lukesneeringer - want me to wait to close this out until we go through the rest of the process? Let me know when you've got time.

Merge away.

@jbolinger @lukesneeringer This merged with broken builds.
In particular, it has broken the docs build

The spanner breakage in your build was fixed in #4620 and rebasing against HEAD in master would have allowed you to run your tests all the way through. (In fact, the only reason Spanner tests ran was because this branch was behind master.)


Added Serbian Cyrrilic translation and corrected Serbian Latin translаtion.

Added Serbian Cyrillic translation and corrected Serbian Latin translаtion.
Description
Short summary of changes (1-2 sentences).
Instructions for Reviewers
Added sr-cyr.json5 translation and modified config files to include this translation. Also slightly corrected Serbian Latin.
List of changes in this PR:

Added Serbian Cyrillic
Modified Serbian Latin
Updated config.example.yml and default-app-config.ts.

Corrected linter errors.

I am not sure what exactly is failing in 18.x. Anyone help with this?

@imilos : The failure in Node 18.x looks to be a random failure, not caused by this PR.  We occasionally have a few tests that fail semi-randomly (which is unfortunate), but we know that they will usually succeed if we rerun the test.  I just triggered a re-run of the 18.x tests on this PR.
So, this looks good.  I'll pull this over to our 7.6.x maintenance board to find a tester so that we can try to include this in 7.6.1.  Thanks!

Thanks @imilos. I tested this on DSpace 7.6 and it looks good. It's also good you caught the minor errors in the Serbian Latin strings. Хвала!


Dynamic options to Radio (t.enums) - validation error despite value selected. "Invalid value supplied to /Path"

Version
Tell us which versions you are using:

tcomb-form v0.9.0
react v0.14.3

Hi,
Am successful in creating a select from
var Gender = t.enums({
  M: 'Male',
  F: 'Female'
}, 'Gender');

var GenderFormType = t.struct({
   gender: Gender
})

<Form ref="form" type={GenderFormType} value={this.state.value} onChange={this.onChange}/>

So far good and the radio (custom template) renders perfect... also the select way works fine.
Now the need is to inject the options dynamically via this.state.options and as per other issue# suggestions have done the following
  var GenderFormType = t.struct({
    gender: t.enums({})
  })
   var genderOpts = getDropdownOptions('gender');
   // the format and options structure looks like below
   // genderOpts = [{"value":"M", "text":"Male"}, {"value":"F", "text":"Female"}]
  ..................
   var options = t.update(this.state.options, {
        fields: {
            gender: {
                options: { '$set': genderOpts }
            }
        }
    });
    this.setState({options:options });
   .................

<Form ref="form" type={GenderFormType} options={this.state.options} value={this.state.value} onChange={this.onChange}/>

Select renders properly and even the default values gets in as expected.
Only issue is with Validation as it always errors out saying (console output as below)
1:Struct
actual:"M"
expected: Enums(value, path)
**message: "Invalid value "M" supplied to /gender: "**
path:Array[1]

Need inputs or suggestion on how to overcome this validation limitation. Or direct me towards correct way of achieving the dynamic value for select without the validation error despite value being chosen.
Expected behavior and requirement is to have this as Radio than Select.
Thanks!

Hi @rajeshps,
the validation fails because you are defining an empty enum:
var GenderFormType = t.struct({
  gender: t.enums({}) // <= empty enums
})

If gender values are static (i.e. just M and F) you should define:
var GenderFormType = t.struct({
  gender: t.enums.of(['M', 'F']) // <= I don't mind the labels
})

and then override the labels with your custom options (as you are already doing):
var genderOpts = getDropdownOptions('gender');
// the format and options structure looks like below
// genderOpts = [{"value":"M", "text":"Male"}, {"value":"F", "text":"Female"}]
..................
var options = t.update(this.state.options, {
  fields: {
    gender: {
      options: { '$set': genderOpts }
    }
  }
});
this.setState({options:options });

However if gender values are dynamic, you could also dynamically define the form type.

Thanks for the response @gcanti.
Yes, gender values are dynamic, basically took gender as an example but there are other similar kind of scenarios which would require dynamic values.
You meant dynamically define field type by using factory?
However, was able to workaround this by initially setting the type to t.String and then in options to set to required type / custom type with options.
Will close this issue for now and thanks a ton for wonderful stack of libraries!


Update required node.js version in CONTRIBUTING.md

https://github.com/acmpesuecc/DrinkWaterBot/blob/a8cf8e61661967de0118e2a3f33ab881b9974d9a/CONTRIBUTING.md?plain=1#L7
The version of node.js specified in the contributing docs is for the current version of the bot. When #78 is merged, the minimum version of node.js required will be 16.6.0. Earlier versions will not work.
This has to be updated in the docs.
This PR will be merge after #78 is merged.

@srujandeshpande Hi, please review my PR for this issue. Thanks

yeah, sure , i will assign the issue to you , you can go ahead and work, please take care of it from next time, thanks for the eagerness to work on the issue :)

hey I want to work in this

I'd like to try this


Use baselines for inlay hints testing

Will make the tests in #54734 easier to update (and review the changes).

This is a great start. One thing I think that gets missed in baselines is that they really should be somewhat human-readable.
So in addition to the raw JSON of every response, I think you should strive to give a preview of the inlay hint text. For example, let's say you have a file like
let x = y;

It would be desirable to have something like the following:
let x: number = y
     ^^^^^^^^
{
    text: ": number",
    position: 5,
    kind: Variable,
    ...
}

@weswigham Could you please take a look?


SimpleInjector lock exception when used with SqlPersistence

When using SqlPersistence, Simpleinjector throws an InvalidOperationException when starting the endpoint. This happens because this library tries to register SqlPersistenceInstaller in SimpleInjectorObjectBuilder.Configure after the SimpleInjector container was locked by SimpleInjectorObjectBuilder.Build (triggered by feature setups).
You don't actually need to configure SqlPersistence to reproduce the problem, it happens by only including the nuget. It should be resolved by registering SqlPersistenceInstaller before the feature setups, but I can't do this because it is internal. I'm not sure if it is a problem with some logic in this project, or if SqlPersistence needs to be changed.
The exception thrown is as follows:
The container can't be changed after the first call to GetInstance, GetAllInstances, Verify, and some calls of GetRegistration. Please see https://simpleinjector.org/locked to understand why the container is locked. The following stack trace describes the location where the container was locked:

   at NServiceBus.ObjectBuilder.SimpleInjector.SimpleInjectorObjectBuilder.Build(Type typeToBuild) in NServicebus.SimpleInjector\src\NServiceBus.SimpleInjector\SimpleInjectorObjectBuilder.cs:line 78
   at NServiceBus.CommonObjectBuilder.Build[T]() in NServiceBus\src\NServiceBus.Core\ObjectBuilder\Common\CommonObjectBuilder.cs:line 28
   at NServiceBus.Features.ReceiveFeature.<>c.<Setup>b__1_0(IBuilder b) in NServiceBus\src\NServiceBus.Core\Pipeline\Incoming\ReceiveFeature.cs:line 20
   at NServiceBus.Pipeline.PipelineSettings.<>c__DisplayClass8_0`1.<Register>b__0(IBuilder b) in NServiceBus\src\NServiceBus.Core\Pipeline\PipelineSettings.cs:line 132
   at NServiceBus.Pipeline.RegisterStep.CreateBehavior(IBuilder defaultBuilder) in NServiceBus\src\NServiceBus.Core\Pipeline\RegisterStep.cs:line 143
   at NServiceBus.Pipeline`1.<>c__DisplayClass0_0.<.ctor>b__0(RegisterStep r) in NServiceBus\src\NServiceBus.Core\Pipeline\Pipeline.cs:line 25
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at NServiceBus.Pipeline`1..ctor(IBuilder builder, PipelineModifications pipelineModifications) in NServiceBus\src\NServiceBus.Core\Pipeline\Pipeline.cs:line 24
   at NServiceBus.InitializableEndpoint.CreateReceiveComponent(ReceiveConfiguration receiveConfiguration, TransportInfrastructure transportInfrastructure, QueueBindings queueBindings, IPipelineCache pipelineCache, EventAggregator eventAggregator) in NServiceBus\src\NServiceBus.Core\InitializableEndpoint.cs:line 153
   at NServiceBus.InitializableEndpoint.<Initialize>d__1.MoveNext() in NServiceBus\src\NServiceBus.Core\InitializableEndpoint.cs:line 65
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at NServiceBus.InitializableEndpoint.Initialize()
   at NServiceBus.Endpoint.Create(EndpointConfiguration configuration) in NServiceBus\src\NServiceBus.Core\Endpoint.cs:line 18
   at NServiceBus.Endpoint.<Start>d__1.MoveNext() in NServiceBus\src\NServiceBus.Core\Endpoint.cs:line 27
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
   at NServiceBus.Endpoint.Start(EndpointConfiguration configuration)

With stack trace:
   at SimpleInjector.Container.ThrowWhenContainerIsLockedOrDisposed()
   at SimpleInjector.Container.AddRegistrationInternal(Type serviceType, Registration registration)
   at SimpleInjector.Container.AddRegistration(Type serviceType, Registration registration)
   at NServiceBus.ObjectBuilder.SimpleInjector.SimpleInjectorObjectBuilder.Configure(Type component, DependencyLifecycle dependencyLifecycle) in NServicebus.SimpleInjector\src\NServiceBus.SimpleInjector\SimpleInjectorObjectBuilder.cs:line 115

Actually, manually registering SqlPersistenceInstaller does not resolve the issue, because it then throws on GetExistingCollectionRegistrationsFor because collectionRegistrations was set to null during Build.

I found a way to solve this issue, but it involves modifying NServiceBus.Core.
The core issue here is that NServiceBus.Features.ReceiveFeature is setup before the installers are run. Because ReceiveFeature's setup function builds some dependencies, the SimpleInjector becomes locked, and the installers can't be registered in the nest step.
My solution is to move the configuration/registration of the installers before the receive feature setup:
            if (shouldRunInstallers)
            {
                var username = GetInstallationUserName();
                ConfigureInstallers(concreteTypes, username);
            }

            var receiveComponent = CreateReceiveComponent(receiveConfiguration, transportInfrastructure, queueBindings, pipelineCache, eventAggregator);

            if (shouldRunInstallers)
            {
                var username = GetInstallationUserName();

                if (settings.CreateQueues())
                {
                    await receiveComponent.CreateQueuesIfNecessary(queueBindings, username).ConfigureAwait(false);
                }

                await RunInstallers(concreteTypes, username).ConfigureAwait(false);
            }

        void ConfigureInstallers(IEnumerable<Type> concreteTypes, string username)
        {
            foreach (var installerType in concreteTypes.Where(t => IsINeedToInstallSomething(t)))
            {
                container.ConfigureComponent(installerType, DependencyLifecycle.InstancePerCall);
            }
        }

        async Task RunInstallers(IEnumerable<Type> concreteTypes, string username)
        {
            foreach (var installer in builder.BuildAll<INeedToInstallSomething>())
            {
                await installer.Install(username).ConfigureAwait(false);
            }
        }

While not ideal, this solves the issue. I can't see a way to solve this in the SimpleInjector library, so maybe we should submit an issue to NServiceBus?

We could also re-introduce the ability to clone a container into a new one. I really don't like that though.
I'll dig around and see if I can come up with something clever...

I raised an issue in core and in the meantime allowed cloning of the container again. It's horrible and has a performance penalty, but until core changes it is the only way to get it running.
Release in 3.0.3.

Great! Thank you, both of you. It works well now.


Add keylocker support

We need another AccessControl device model, based on Doors (with associated management and logging).
Additional requirements:

Another endpoint for the devices to report live changes of state of keys held within the keylocker and whom opened the keylocker most recently.
Checkins for this device class will need to support accepting a json array of key objects as part of regular checkin.
Keys will need a management interface to add friendly names to them as the device will report the 1wire unique eeprom ID of the key.
Removal or insertion of a key should also trigger a discord message, as will opening a keylocker.

Closing this as the key tracker project is no longer active as far as I am aware. Happy to revisit if someone else picks it up.


Spell Correction AC Bug

When hover over suggested terms, the term is being spell corrected, thus resulting in showing results for a different query...

In the above example, you can see the tools suggestion is being corrected when hovered, and then changing the term to tool - this is breaking tests, as we check that the queries agree.

Potential solution:

add custom parameter to preview urlManager for suggested terms
use custom parameter added in #1 to toggle search.query.spellCorrection request parameter

Should be resolved with recent changes to integrated spell correction.


validate_db_connection

Abstract : To validate the db connection because once the director-worker is spawned by the monit , if there is a connection break on postgres DB side then this thread gives a Error i.e not able to connect PG error and no worker Job is processed (create release , delete release).
Solution: Using connection validator extension from sequel , if there is a persistent connection then all things are fine but if connection breaks this extension will validate the connection and worker will process the job.
By default the timeout is 3600 ( 1 hour ) but can reduce in cases where either firewall or other network issues we are loosing connections to database.
Below is error trace:
INFO  DirectorWorker : got: (Job{normal} | Bosh::Director::Jobs::DeleteRelease | [10, "pgpool", {"version"=>nil}])
INFO  DirectorWorker : Running before_fork hooks with [(Job{normal} | Bosh::Director::Jobs::DeleteRelease | [10, "pgpool", {"version"=>nil}])]
INFO  DirectorWorker : Running after_fork hooks with [(Job{normal} | Bosh::Director::Jobs::DeleteRelease | [10, "pgpool", {"version"=>nil}])]
INFO  DirectorWorker : (Job{normal} | Bosh::Director::Jobs::DeleteRelease | [10, "pgpool", {"version"=>nil}]) failed: #<Sequel::DatabaseDisconnectError: PG::Error: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

INFO  DirectorWorker : /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:145:in exec' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:145:in block in execute_query'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/database/logging.rb:37:in log_yield' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:145:in execute_query'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:132:in block in execute' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:111:in check_disconnect_errors'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:132:in execute' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:413:in _execute'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:242:in block (2 levels) in execute' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:425:in check_database_errors'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:242:in block in execute' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/database/connecting.rb:236:in block in synchronize'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/connection_pool/threaded.rb:104:in hold' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/database/connecting.rb:236:in synchronize'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:242:in execute' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/dataset/actions.rb:801:in execute'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/adapters/postgres.rb:525:in fetch_rows' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/model/base.rb:798:in primary_key_lookup'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/sequel-3.43.0/lib/sequel/model/base.rb:117:in []' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.2780.0/lib/bosh/director/api/task_manager.rb:11:in find_task'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.2780.0/lib/bosh/director/job_runner.rb:21:in initialize' /var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.2780.0/lib/bosh/director/jobs/base_job.rb:10:in new'
/var/vcap/packages/director/gem_home/ruby/2.1.0/gems/bosh-director-1.2780.0/lib/bosh/director/jobs/base_job.rb:10:in `perform'

@ronakbanka Nice! We'll pull this in.

By default the timeout is 3600 ( 1 hour ) but can reduce in cases where either firewall or other network issues we are loosing connections to database.

What are you guys setting the timeout to in your environment?

@cppforlife In our Environment we are using much lower timeout of 150 . I used 150 just keeping in mind some release operation on db side.
But my main reason to put 3600 as default is most people don't face a db connection break if they are using a dedicated database. We are using a Postgres HA cluster.

Yes basicaly we created a pgpool release, to make postgres HA and so on.

@shinji62 OSS it or doesn't exists! :)

@frodenas sure We will do it  :)

@ronakbanka Awesome! Thanks!

@frodenas ah ah ah ! Yes we will OSS it, just need some cleanup and more testing !

@shinji62 that sounds awesome. very exciting.

@cppforlife Hi should I open a issue request for the same to add it to tracker story or just this PR is enough?

I've actually already prioritized this PR in the backlog:
https://www.pivotaltracker.com/story/show/88572280
On Tue, Feb 17, 2015 at 8:49 PM, Ronak Banka<EMAIL_ADDRESS>wrote:

@cppforlife https://github.com/cppforlife Hi should I open a issue
request for the same to add it to tracker story or just this PR is enough?
—
Reply to this email directly or view it on GitHub
https://github.com/cloudfoundry/bosh/pull/748#issuecomment-74811763.

Merged first iteration that solves for non-RDS DBs. https://github.com/cloudfoundry/bosh/commit/f41407635c4818bd41f050f5ebec70a82ad2d379

Thanks @cppforlife


BREAK not implemented

As BREAK is not yet implemented, DasherG cannot always function as the system console on real hardware.
It looks as if this serial package https://github.com/distributed/sers provides BREAK, and if other serial requirements are met we should move to it.

Verified working as of v0.9.6


Support for fragments

MvvmActivity allows for easy setup of activities.
A similar MvvmFragment can be added to allow easy setup of fragments.

@manas-chaudhari How do we add/remove fragments from VM? Since adding fragments requires a TAG, LayoutId and FragmentManager a service won't do since that would require a separate method for every fragment(because layoutID can't be passed from VM or can we?). Your thoughts please.

@vinayppatil1989 You're right. VM shouldn't be aware about layoutId. You can pass an interface to the View similar to Navigator in the sample and perform the fragment transaction in its implementation. That way, the fragment logic stays in your view layer (parent fragment/activity)

@manas-chaudhari That way, wouldn't the interface impl get bloated up with a method for every fragment. It gets worse with fragment removing logic.

Yes, it would. But, I think its necessary if you have different parameters for different navigations. If you have common arguments for navigation, you can pass the information as a parameter. For example, you could define a Page enum (or an IntDef) and pass it to the navigation method. The activity/fragment can store a mapping from Page -> layoutIds.

Got that. But before I take that approach, what problems do you see in using R files in VM's?

Problem is that that would couple your layout to the ViewModel. Hence, you won't be able to use the same ViewModel with another layout.


Support plugins for extending funcMap

Note: I would be willing to implement this if others think it is valuable
In working with another generator, I needed a function that didn't exist in the funcMap, and adding it required a PR to the generator.  It occurred to me that it would be very easy to implement a plugin system to allow users to implement their own functions in the funcMap.
Here's my suggestion - plugins are very simple executables that follow this pattern:
If a plugin executable is run with no arguments, it should output to stdout a newline delimited list of function names.  Hugo would run all the plugins[1] at startup and keep a reference of which plugin produced which function name, for when they're called from a template.
When a template calls one of the plugin's functions, the plugin executable is run with with the function name as an argument, and any further arguments are sent as a json array to the plugin's stdin[2].  The result of the program should be json formatted and written to stdout.  If an error is encountered, the executable should exit with a non-zero exit code, and write any error text to stderr.
Bam, now any user can create a plugin in any language they want to extend the functionality of Hugo to support any function they want.
[1] How plugins are discovered by Hugo is left to the developer.  I don't really care if it's a magic directory or specially named executables in the $PATH or whatever.
[2]  We do this to avoid OS character limits on executable arguments.

It would be a very powerful feature for users to be able to extend the funcMap with custom functions.
But from the POV of a theme maintainer I would be facing the following problems:
Plugin distribution: Most themes are publicly accessible as a Git repository which users should only have to clone in order to use it. As themes should work out of the box it would be necessary to track executables in a CVS as well unless there is some dead simple package manager.
Furthermore, executables are mostly platform dependent. Writing a plugin in Go isn't hard but I would have to provide executables for all major platforms (incl. 32 and 64 bit versions). This would create even more bloat.
Versioning: Plugins can change over the time, e.g. through the addition of new features or bug fixes. Sometimes a piece of software can change it's behavior which might cause errors. This makes it harder to detect errors because you can say plugin xx with version 1.xxx is not compatible with the current state of the theme.

This is a very interesting point.  I hadn't thought of this from the vantage of requiring a plugin for a theme, but that does make sense.  I'd just been thinking about hacking up an existing theme and needing different functions for it.
Of course, if it's a script (python or otherwise) it could be included with the theme, but that does then require that the host have python installed, which is a problem for Windows users.
I wonder if something like embedded lua would be a way to avoid that - https://github.com/yuin/gopher-lua  of course, then you have to write the functions in lua :/

Doing template func plugins via os/exec sounds tempting and simple, but there are lots of issues floating to surface once you start thinking about it (performance, security, distribution, support). I have always thought about potential plugins in Hugo on a more granular level; piping a template string into a python trim func  does not sound very fast for 10K pages.

Using an embedded language might be the sweet spot. Distributing executables is a hassle due to the vast amount of platforms and unflexible. Interpreted languages like Python would require a runtime environment.
Embedded languages also might be easier to use than RPC-based plugins (see #1239).
While glancing over the README of the gopher-lua repo I saw the DoFile method to load scripts. It would be neat to have scripts as simple text files in a special directory which is watched by Hugo. This way functions could be added, removed and updated ad hoc. Simple text files
However, I don't know how goper-lua will perform / slow down Hugo, nor how much the Hugo executable would grow. @bep also mentioned other aspects that have to be considered as well.
While this is just wishful thinking and definitely needs a more precise specification it could go beyond template functions.

FYI, we just built a plugin system like this for Gnorm: https://gnorm.org/templates/plugins/
It's basic now, just running an executable in a specified directory.  But I intend to enhance it so it can understand how to run common languages like .py .rb .go etc... yes it'll require that you have that language on your machine, but it's a lot easier to implement this than embedding a whole new language in your binary, and requiring people to write plugins in that language.
Not that I wouldn't also like lua in Gnorm, it's more work.

Hmm... skylark might be better (python is more popular than lua).  Could be distributed as plaintext with a theme.
https://github.com/google/skylark
https://godoc.org/github.com/google/skylark#ExecFile

this issue should be reopened, i need a way to format date to jalali, embeded script seems a very good solution.

POC here: #5521

@sijad, create a separate issue for your calendar/date issue.


Go modules support

Please use go modules for this project. It should be straightforward:
go mod init github..com/Sheridan/smartctl_exporter

Then do a quick go build to populate go.mod and go.sum and check them in.
Thanks!

Looks like there's a Go mod file now. But the release aren't tagged with semver like v0.6.0.

This is now done.


Make optional fields optional and fix the JSON parse

Issue reference:
Issue #37
Submission Checklist:

[ ] Have you followed the guidelines in our Contributing document? Maybe, I don't know.
[X] Have you checked to ensure there aren't other open Pull Requests for the same update/change? No other PRs exist.
[X] Does your submission build? Yep
[ ] Does your submission pass tests? Yep
[ ] Have you run lints on your code locally prior to submission? Nope.
[X] Have you updated all of the cabal/nix infrastructure? No, man that would be a pain if it were actually needed.
[X] Is this a breaking change? Have you discussed this? It breaks broken behavior... so no.

Hey @TomMD, thanks for putting this together and your commitment so far to maintaining this project.
This seems very reasonable to me, so as soon as the tests pass we'll merge it and release it for you.
Thanks


chore: Adding basic CI and fixing README Link Menu video

closes #227
A simple and fast PR that adds basic CI and fixes the Link Menu video in README.md.

I'll have a look later in the day.

I'll close it for now. We are planning to add automatic tests using patrol. I'll have to manually review this setup once the tests are ready


Spurious indenting when putting a table in a table

I'm trying to serialize an XML document that has a table inside a table, like this:
local tb = {
    _attr = { requestType = "Initial"},
    fingerprint = fingerprint,
    deviceType = "standalone",
    clientOS = "Windows 8", -- TODO: make this configurable
    clientLocale = "en",
    clientVersion = "<IP_ADDRESS>765", -- TODO: make this configurable
    targetDevice = {
        softwareVersion = "9.3.58046",
        clientOS = "Windows 8", -- TODO: make this configurable
        clientLocale = "en",
        clientVersion = "<IP_ADDRESS>765", -- TODO: make this configurable
        deviceType = "standalone",
        productName = "ADOBE Digitial Editions", -- [sic] Yes, the real ADE misspells Digital...
        fingerprint = fingerprint,
    },
    nonce = crypto.nonce(),
    expiration = util.expiration(10), -- 10 minutes
    user = user
}
-- serialize it

and I get something like this:
<activate requestType="Initial">
  <clientVersion><IP_ADDRESS>765</clientVersion>
    <targetDevice>
      <clientVersion><IP_ADDRESS>765</clientVersion>
      <productName>ADOBE Digitial Editions</productName>
      <deviceType>standalone</deviceType>
      <clientOS>Windows 8</clientOS>
      <fingerprint>Gp6IvTeq2pzVJs3cY5VsK20p84E=</fingerprint>
      <clientLocale>en</clientLocale>
      <softwareVersion>9.3.58046</softwareVersion>
    </targetDevice>
    <nonce>Pj/Wyl7jV/ixaXD3</nonce>
    <expiration>2022-07-11T21:47:24Z</expiration>
    <fingerprint>Gp6IvTeq2pzVJs3cY5VsK20p84E=</fingerprint>
    <deviceType>standalone</deviceType>
    <clientOS>Windows 8</clientOS>
    <user>urn:uuid:ef4cf545-465e-43ee-96dd-c8ec33d2937e</user>
    <clientLocale>en</clientLocale>
</activate>

See how targetDevice and everything after it is indented?
This seems to be caused by https://github.com/manoelcampos/xml2lua/blob/master/xml2lua.lua#L220, and after I removed it the issue is indeed resolved.
I'm hesitant to simply include that change in my project, though, because I am unaware of any side-effects it might have.

I see. I have to check but and I'm on vacation.
Anyway, indentation is just formatting and doesn't cause and parse issues.

I know, it just makes it look weird 😄, so I thought I'd report it.
I'm modifying it quite a bit already, to add hacks for namespaces and sorting (for signing), so I'll include the change in my version.
Doesn't seem to cause any harm so far, but I'll report here if I notice anything.


⚠ Bofrost.nl has degraded performance

In 5b5f025, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 2151 ms

Resolved: Bofrost.nl performance has improved in 5560b01 after 7 minutes.


New tagged "c": slashes doubled

The following:
console.log(c`/`)

Renders:

//

@marvinroger Thanks. Fortunately this is not a bug that will take me a weekend to fix. I'll cut a new patch ASAP.


feat(node-details): add ability to view and edit Swarm mode nodes

Adds the ability to inspect a Swarm mode Node.
Adds the ability to update a node's name, Availability and Labels.

Close #414

Love it.. approved. Great work Glowbal....

Cool
On Jan 2, 2017 3:18 PM, "Neil Cresswell"<EMAIL_ADDRESS>wrote:

Love it.. approved. Great work Glowbal....
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/portainer/portainer/pull/417#issuecomment-270016078,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGsC4xm62Om-yQMJ8MLHysL4Eb2xiWU7ks5rOVuYgaJpZM4LV8ec
.

Really good work @Glowbal I love it too ! One thing that I dislike though: when loading a node view on a remote node (playwithdocker node for example) or with a poor internet connection, the view will display 'It looks like the node you wish to inspect does not exist.' for a short period of time before displaying the node view. IMO this should be replaced by a loading icon.

I agree. I will make the change.

Awesome, ping me when you've made the changes as sometimes I don't receive a notification for PR updates.

@deviantony I've made the changes. I've also fixed an error that occurred when you did a page refresh or opened the node details page as the first page. The endpointMode variable is not yet defined at that stage. To fix that, I've added recursive call with a timeout, until the variable is available.
I'm not sure if there is a better way to deal with that in AngularJS, but it does seem to work reliable.

@deviantony I've made the requested changes.


Authy push authentication feature

This pull request adds push authentication using Authy (https://authy.com/). If Authy authentication fails, continue with the classic Google OTP. See README.authy.md how to install and use.

@googlebot I signed it!

Oooh, very cool. Things this needs before being mergable:

This new functionality, because it depends on two new libraries, needs to be optional.
The README needs to reflect that it's not a fork. Probably the main README can point to the authy README since there's a fair difference.
The email address I think needs to match, like googlebot said.

I won't have time look at the code today. but looks very promising.

@googlebot I fixed it.

@ThomasHabets: pull request is updated with the suggested changes

@ThomasHabets Hello Thomas, how shall we continue with this pull request?

@krzole I've not had time to look at this more yet.
Although now I'm wondering if it actually belongs in the same module. How is this better than having a separate PAM module that does authy? The fallback logic is normally done in the PAM config.


Expose SignedExtension's implications on transaction construction in metadata.

While discussing how to build transactions with the least dependency on substrate packages with @emostov:
The metadata already exposes something like this:
extrinsic: {
        version: 4,
        signedExtensions: [
          CheckSpecVersion,
          CheckTxVersion,
          CheckGenesis,
          CheckMortality,
          CheckNonce,
          CheckWeight,
          ChargeTransactionPayment,
          PrevalidateAttests
        ]
 }

What it does not expose is what implications these extensions have on the extrinsic construction. Given that (to the best of my knowledge) the aforementioned implication is always either one of:

Cause some data to be appended to the to tx payload
Cause some data to be appended to the signed_payload
(or simply no effect)

I assume we can extend the metadata to expose this information as well. Unless if SingedExtension trait changes significantly, this should be stable and will make a lot of people building transactions offline happy.
extrinsic: {
        version: 4,
        signedExtensions: [
          { name: 'CheckWeight', data: 'None', signed_data: 'None' },
          { name: 'ChargeTransactionPayment', data: 'Balance', signed_data: 'None' },
          // ------------------------------------------^^ This type must be defined elsewhere in the metadata though
        ]
 }

cc @thiolliere @bkchr

I'm not convinced by this request.
What does it brings you when you know that data == Balance? IMHO that doesn't tell you anything.
After we added that, someone will come with the idea, hey what is the algorithm for X to add it to the signed extensions? Could we not expose this via metadata? This is some never ending rabbit hole.
The idea behind adding the signed extensions to the metadata was that each extension has a known implementation. And we just expose which signed extensions the runtime is using. The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

I'm not convinced by this request.
What does it brings you when you know that data == Balance? IMHO that doesn't tell you anything.
After we added that, someone will come with the idea, hey what is the algorithm for X to add it to the signed extensions? Could we not expose this via metadata? This is some never ending rabbit hole.
The idea behind adding the signed extensions to the metadata was that each extension has a known implementation. And we just expose which signed extensions the runtime is using. The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

What does it brings you when you know that data == Balance? IMHO that doesn't tell you anything.

But isn't this how the storage definitions work metadata as well? Somewhere in the metadata of a pallet, it is defined that Balance = u128 and therefore anywhere you see Balance you can replace it. Although, I am aware that I am making an assumption here:
That all the types that signed extensions need in their data or signed_payload, have types that are already defined in some pallet's storage item. Else that type will be undefined and need to be declared as well.

Could we not expose this via metadata? This is some never ending rabbit hole.

I get the point and mostly agree. What I want to point out is that there's spectrum here, and our definitions of what "should" and "should not" be provided to the user can differ, and is very fuzzy tbh. In this case, one end of the spectrum being "our ease" and the other end "user-friendliness". I could have argued the same 2 years ago and convince you that you don't need to expose pallet storage types via metadata, rather just their names, and an external repo should maintain them, right? But then we opted to make things easier for the user. I wonder why not now?

The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

@emostov for your case it might be worth at giving this a shot then :)

What does it brings you when you know that data == Balance? IMHO that doesn't tell you anything.

But isn't this how the storage definitions work metadata as well? Somewhere in the metadata of a pallet, it is defined that Balance = u128 and therefore anywhere you see Balance you can replace it. Although, I am aware that I am making an assumption here:
That all the types that signed extensions need in their data or signed_payload, have types that are already defined in some pallet's storage item. Else that type will be undefined and need to be declared as well.

Could we not expose this via metadata? This is some never ending rabbit hole.

I get the point and mostly agree. What I want to point out is that there's spectrum here, and our definitions of what "should" and "should not" be provided to the user can differ, and is very fuzzy tbh. In this case, one end of the spectrum being "our ease" and the other end "user-friendliness". I could have argued the same 2 years ago and convince you that you don't need to expose pallet storage types via metadata, rather just their names, and an external repo should maintain them, right? But then we opted to make things easier for the user. I wonder why not now?

The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

@emostov for your case it might be worth at giving this a shot then :)

But isn't this how the storage definitions work metadata as well? Somewhere in the metadata of a pallet, it is defined that Balance = u128 and therefore anywhere you see Balance you can replace it. Although, I am aware that I am making an assumption here:

Nope that is not defined, at least for now and that brings some huge problems ;) That should be solved by scale-info.

I get the point and mostly agree. What I want to point out is that there's spectrum here, and our definitions of what "should" and "should not" be provided to the user can differ, and is very fuzzy tbh. In this case, one end of the spectrum being "our ease" and the other end "user-friendliness".

Yeah, it is true that the barrier is relative fuzzy. The point is that we could put much more stuff into the metadata, like how are the fees calculated, but this is really a never ending story. There will always be some stuff you need to be aware of from the application side. You can also have your own signed extensions and if you just know that some custom signed extension takes a Balance, would not help you for anything.

I could have argued the same 2 years ago and convince you that you don't need to expose pallet storage types via metadata, rather just their names, and an external repo should maintain them, right? But then we opted to make things easier for the user. I wonder why not now?

 However for storage types this is a little bit different, because you don't need to know any algorithm for this. When the user wants to read from any random chain a storage field that has as type Balance and you can generate a type info for that, you will be able to decode it and show it as a string. Yes, we still need more metadata to say for example that a certain type is a Balance and some other type is X. Something for the future. However, for all this stuff we don't need any knowledge on how to calculate the value that should be added to the transaction.

But isn't this how the storage definitions work metadata as well? Somewhere in the metadata of a pallet, it is defined that Balance = u128 and therefore anywhere you see Balance you can replace it. Although, I am aware that I am making an assumption here:

Nope that is not defined, at least for now and that brings some huge problems ;) That should be solved by scale-info.

I get the point and mostly agree. What I want to point out is that there's spectrum here, and our definitions of what "should" and "should not" be provided to the user can differ, and is very fuzzy tbh. In this case, one end of the spectrum being "our ease" and the other end "user-friendliness".

Yeah, it is true that the barrier is relative fuzzy. The point is that we could put much more stuff into the metadata, like how are the fees calculated, but this is really a never ending story. There will always be some stuff you need to be aware of from the application side. You can also have your own signed extensions and if you just know that some custom signed extension takes a Balance, would not help you for anything.

I could have argued the same 2 years ago and convince you that you don't need to expose pallet storage types via metadata, rather just their names, and an external repo should maintain them, right? But then we opted to make things easier for the user. I wonder why not now?

 However for storage types this is a little bit different, because you don't need to know any algorithm for this. When the user wants to read from any random chain a storage field that has as type Balance and you can generate a type info for that, you will be able to decode it and show it as a string. Yes, we still need more metadata to say for example that a certain type is a Balance and some other type is X. Something for the future. However, for all this stuff we don't need any knowledge on how to calculate the value that should be added to the transaction.

The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

@emostov for your case it might be worth at giving this a shot then :)

polkadot-js is doing the same and since we have support for it, I know that @jacogr life is much easier in this aspect :D

The user facing side just needs some sort of registry of known extensions where it looks up a particular extension.

@emostov for your case it might be worth at giving this a shot then :)

polkadot-js is doing the same and since we have support for it, I know that @jacogr life is much easier in this aspect :D

The api has a registry for known extensions which contains the payload-only and transaction types. (That is what gets used to build the extrinsic against what the metadata defines)

The api has a registry for known extensions which contains the payload-only and transaction types. (That is what gets used to build the extrinsic against what the metadata defines)

I wonder of #8370 would help with this? If the data field of each extension (i.e. what needs to be encoded) is already described elsewhere in the metadata formally, that would solve the issue, right?

No this will not be solved by the linked issue. You still need a way to provide semantic information on how the data is fetched for these types.
Imo this is already solved by the identifiers of the signed extensions.

My opinion is that we don't need to tell the semantic information, and it is the responsibility of the offchain user to know that. But providing some types to help is better than nothing.
Although you can say knowing the type is also their responsibility, I see the point in that as well :D

My opinion is that we don't need to tell the semantic information, and it is the responsibility of the offchain user to know that. But providing some types to help is better than nothing.
Although you can say knowing the type is also their responsibility, I see the point in that as well :D

Thinking a bit further, I think there's no way around this, and Basti is right that even if we provide the type, the semnatics of how to fetch it still needs to be hardcoded in each application, so they might as well hardcode the whole thing.
 This is slighly better, as that RPC is at least somewhat typed, and you need to know which types of data you need to pass in.
But even this won't solve the main objective of this issue, which is to allow offline signing, with depending only on metadata, not potentially some unknown node.
I won't close this yet, but kinda see that this is a deadlock.

 This is slighly better, as that RPC is at least somewhat typed, and you need to know which types of data you need to pass in.

And then you got a chain that supports tips, so the rpc needs to gets the tip passed. Then there is a chain that doesn't has tips. (tips are clearly just an example here and this is entirely chain dependent)

What comes to mind is maybe an RPC call that is like a payload builder/helper, to which you give a call, and some typed parameters to build the entire payload from. This is slighly better, as that RPC is at least somewhat typed, and you need to know which types of data you need to pass in.

This functionality sounds awfully close to some talk of adding an endpoint to sidecar (or making a new service. The endpoint would build a transaction for you given the call, call params, and signing info, then take your signature and give you back a tx to submit. (see discussion here). This way you just only need to be able to pass in some JSON info and implement the signing crypto, but all other details of creating the tx could be abstracted by the service.
IMO the primary hurdle to something like this is limiting MIM attacks where the attacker gets you to sign there payload because you do not have the ability to decode it and check. You could implement some system like having a shared secret with the service, but requires an attentive and thoughtful sysadmin.

seems like we're fine with just putting the name of the extension there, and asking the 3rd party client to just infer the rest. Not happy, but will close.


CUPS on NixOS [Chrome stopped to print]

Issue description
Chrome stopped to print someday on nixos-unstable

Both Chrome and Firefox look for /run/cups.sock socket but our CUPS module only creates /run/cups/cups.sock
We only listen at <IP_ADDRESS> by default, but both Chrome and Firefox probe ::1 first. Firefox then fallbacks to <IP_ADDRESS> but Chrome by some reason doesn't and so it never prints.

Steps to reproduce
Printing doesn't work in Chrome out of box.
After adding
services.printing.listenAddresses = [ "::1:631" "<IP_ADDRESS>:631" ]
to config it starts to work again.
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.

system: "x86_64-linux"
host os: Linux 4.13.16, NixOS, 18.03.git.6acfa35 (Impala)
multi-user?: yes
sandbox: no
version: nix-env (Nix) 1.11.16
channels(root): "nixos-18.03pre127867.6acfa356ddc"
nixpkgs: /home/gnidorah/tmp/nixpkgs

Do you still have the NixOS generation for which printing does work? That would make it a lot easier to find the commit which caused the change.

@emmanuelrosa Unfortunately no, I've discovered this issue too lately. I don't print often.


Unit tests

oop-school-library: Unit tests
Hello ✋,
In this branch, we have done the following:

Created test files for all the required classes
wrote the unit tests codes with RSpec for those classes
Run all the tests and they passed.

Thank you very much @t-yanick


🐛 [Firebase Core] Unable to set FirebaseOptions at runtime

Bug report
Describe the bug
I have GoogleService-info.plist and google-service.json embedded properly in the project (works as expected).
Then I was also trying to use Firebase.initializeApp(options:) to set a different set of configurations manually during app launch via initState() of the root StatefulWidget, in order to enable the app with multiple environments. But the configurations being picked up were always what was written in the physical google service files.
Steps to reproduce
Steps to reproduce the behavior:

Add GoogleService-info.plist and google-service.json to the iOS and Android project as per described in the documentation.
In the root StatefulWidget, do

final app = await Firebase.initializeApp(options: {OPTIONS});
FirebaseAuth.instanceFor(app: app);

Go through standard username and password sign up process

Expected behavior
User is registered under the corresponding environment

Additional Questions
I think this might be expected behaviour. But if that is the case, when and where should initializeApp(options:) be used? Besides, based on what the physical file contains, it seems more of less a replicate of FirebaseOptions. Not sure why having this physical file is mandatory?

Worth Mentioning
I posted the same bug 21 days ago, but got closed and then ignored even though I followed up and mentioned the thread I was suggested to look at doesn't work.
As our work depends on flutterfire, I had to post a new ticket here.
Hopefully somebody with a more sense of responsibility will care to have a look this time.

Hi @sima-11
Could you please provide your flutter doctor -v and flutter pub deps -- --style=compact?
Are you using the auth instance from the secondary app in all of the method calls?
Thank you

Hi @markusaksli-nc
Thank you for your reply.
Please find results below.
flutter doctor -v:
[✓] Flutter (Channel stable, 2.2.3, on macOS 11.2.3 20D91 darwin-x64, locale en-GB)
    • Flutter version 2.2.3 at /Users/sima/Documents/flutter
    • Framework revision f4abaa0735 (3 weeks ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at /Users/sima/Library/Android/sdk
    • Platform android-30, build-tools 30.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5, Build version 12E262
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)

[✓] VS Code (version 1.58.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.24.0

[✓] Connected device (2 available)
    • iPhone 11 (mobile) • 1896B13E-778B-44EC-8F31-FFFEF1EAC981 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-14-5 (simulator)
    • Chrome (web)       • chrome                               • web-javascript • Google Chrome 91.0.4472.164
    ! Error: *** Si’s iPhone 11 *** is not connected. Xcode will continue when *** Si’s iPhone 11 *** is connected. (code -13)

! Doctor found issues in 1 category.

flutter pub deps -- --style=compact:
Dart SDK 2.13.4
Flutter SDK 2.2.3
kniddo 1.0.0+1

dependencies:
- cloud_firestore 2.2.1 [cloud_firestore_platform_interface cloud_firestore_web firebase_core firebase_core_platform_interface flutter meta]
- cupertino_icons 1.0.2
- equatable 2.0.3 [collection meta]
- firebase_auth 1.3.0 [firebase_auth_platform_interface firebase_auth_web firebase_core firebase_core_platform_interface flutter meta]
- firebase_dynamic_links 2.0.6 [firebase_core flutter]
- flutter 0.0.0 [characters collection meta typed_data vector_math sky_engine]
- flutter_localizations 0.0.0 [flutter intl characters clock collection meta path typed_data vector_math]
- flutter_sfsymbols 2.0.0 [flutter]
- flutter_slidable 0.6.0 [flutter]
- intl 0.17.0 [clock path]
- provider 5.0.0 [collection flutter nested]
- shared_preferences 2.0.6 [meta flutter shared_preferences_platform_interface shared_preferences_linux shared_preferences_macos shared_preferences_web shared_preferences_windows]
- url_launcher 6.0.9 [flutter meta url_launcher_linux url_launcher_macos url_launcher_platform_interface url_launcher_web url_launcher_windows]
- uuid 3.0.4 [crypto]

dev dependencies:
- flutter_lints 1.0.3 [lints]
- flutter_test 0.0.0 [flutter test_api path fake_async clock stack_trace vector_math async boolean_selector characters charcode collection matcher meta source_span stream_channel string_scanner term_glyph typed_data]

transitive dependencies:
- async 2.6.1 [meta collection]
- boolean_selector 2.1.0 [source_span string_scanner]
- characters 1.1.0
- charcode 1.2.0
- clock 1.1.0
- cloud_firestore_platform_interface 5.1.1 [collection firebase_core flutter meta plugin_platform_interface]
- cloud_firestore_web 2.1.1 [cloud_firestore_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins js]
- collection 1.15.0
- crypto 3.0.1 [collection typed_data]
- fake_async 1.2.0 [clock collection]
- ffi 1.1.2
- file 6.1.2 [meta path]
- firebase_auth_platform_interface 4.2.4 [firebase_core flutter meta plugin_platform_interface]
- firebase_auth_web 1.2.0 [firebase_auth_platform_interface firebase_core firebase_core_web flutter flutter_web_plugins http_parser intl js meta]
- firebase_core 1.3.0 [firebase_core_platform_interface firebase_core_web flutter meta]
- firebase_core_platform_interface 4.0.1 [collection flutter meta plugin_platform_interface]
- firebase_core_web 1.1.0 [firebase_core_platform_interface flutter flutter_web_plugins js meta]
- flutter_web_plugins 0.0.0 [flutter js characters collection meta typed_data vector_math]
- http_parser 4.0.0 [charcode collection source_span string_scanner typed_data]
- js 0.6.3
- lints 1.0.1
- matcher 0.12.10 [stack_trace]
- meta 1.3.0
- nested 1.0.0 [flutter]
- path 1.8.0
- path_provider_linux 2.0.0 [path xdg_directories path_provider_platform_interface flutter]
- path_provider_platform_interface 2.0.1 [flutter meta platform plugin_platform_interface]
- path_provider_windows 2.0.1 [path_provider_platform_interface meta path flutter ffi win32]
- platform 3.0.0
- plugin_platform_interface 2.0.0 [meta]
- process 4.2.1 [file path platform]
- shared_preferences_linux 2.0.0 [flutter file meta path path_provider_linux shared_preferences_platform_interface]
- shared_preferences_macos 2.0.0 [shared_preferences_platform_interface flutter]
- shared_preferences_platform_interface 2.0.0 [flutter]
- shared_preferences_web 2.0.0 [shared_preferences_platform_interface flutter flutter_web_plugins meta]
- shared_preferences_windows 2.0.0 [shared_preferences_platform_interface flutter file meta path path_provider_platform_interface path_provider_windows]
- sky_engine 0.0.99
- source_span 1.8.1 [collection path term_glyph]
- stack_trace 1.10.0 [path]
- stream_channel 2.1.0 [async]
- string_scanner 1.1.0 [charcode source_span]
- term_glyph 1.2.0
- test_api 0.3.0 [async boolean_selector collection meta path source_span stack_trace stream_channel string_scanner term_glyph matcher]
- typed_data 1.3.0 [collection]
- url_launcher_linux 2.0.0 [flutter]
- url_launcher_macos 2.0.0 [flutter]
- url_launcher_platform_interface 2.0.4 [flutter plugin_platform_interface]
- url_launcher_web 2.0.1 [flutter flutter_web_plugins meta url_launcher_platform_interface]
- url_launcher_windows 2.0.0 [flutter]
- vector_math 2.1.0
- win32 2.2.4 [ffi]
- xdg_directories 0.2.0 [meta path process]
- ```

@markusaksli-nc And to your question Are you using the auth instance from the secondary app in all of the method calls? - Yes.

So your issue is more that you are not able to create a new firebase app at runtime? Well as you guessed this is expected behavior, as documented for initializeApp:

Initializes a new FirebaseApp instance by name and options and returns the created app. This method should be called before any usage of FlutterFire plugins.

So you will not be able to create new instances off of this app if it isn't initialized first (technically at runtime, but just before you use the other plugins). You should be able to create all of the different apps you need at startup and just reference them later.
Because this is intended, I'm going to close the issue since there isn't really anything to fix. However if you want an answer as to why the plugins work like this, I personally don't have an answer. You can ask in Discussions though.
Thank you


Hook up CADisplayLink for a frame pulse on iOS

Hmm maybe the crash only occurs if the devserver isn't running? I'm (slowly) working on making that experience better as part of #537.


Update readme to show new dark mode theme

Related to #214
Since the new css theme was merged let's update the readme to align documentation to the tuned dark theme.

Trivial, merging myself. /cc @wswebcreation

Tnx


[BEAM-6058] Use vendored gRPC 1.13.1 dependency.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.


setPosition() does not work

I am trying to change the marker's position on click event but every time it gives me an error like:
controllers.js:76 Uncaught TypeError: Cannot read property 'setPosition' of undefined(…)
My code:
PickUpPosition = new plugin.google.maps.LatLng(24.8290593, 67.0221618);
            var marker =  map.addMarker({
                position: PickUpPosition,
                title: "Your PickUp",
                snippet: "This app is awesome!",
                icon: 'img/drop off-01.png'
            })
             var mylatLng = new plugin.google.maps.LatLng(24.843286, 67.053242);
             marker.setPosition(mylatLng);

P.S it also gives me the error as Error in Success callbackId: CordovaGoogleMaps1953897352 : TypeError: Cannot read property 'setPosition' of undefined

Please read the wiki pages before asking.
https://github.com/mapsplugin/cordova-plugin-googlemaps/wiki/Marker
You MUST use callback.
PickUpPosition = new plugin.google.maps.LatLng(24.8290593, 67.0221618);

map.addMarker({
    position: PickUpPosition,
    title: "Your PickUp",
    snippet: "This app is awesome!",
    icon: 'img/drop off-01.png'
}, function(marker) {
    var mylatLng = new plugin.google.maps.LatLng(24.843286, 67.053242);
    marker.setPosition(mylatLng);
});

Thank you! I will give it a try.

It seems to be working. Could you also tell me how this can be achieved on MAP_CLICK event?

Any help will be appreciated.
Thank You

I literally can not do anything with this function outside. Main aim is to put it inside a separate function and call that function inside setTimeout();

Could you show me what you do want?

I am only trying to update the marker's position on a given time interval.
`map.addMarker({
position: PickUpPosition,
title: "Your PickUp",
snippet: "This app is awesome!",
icon: 'img/drop off-01.png'
},
);
        setInterval(function ()
    {                       //code starts for moving marker
        abc();
    },5500);

    function abc(marker) {

        var mylatLng = new plugin.google.maps.LatLng(24.901730, 67.040126);
        marker.setPosition(mylatLng);
    }`

map.addMarker({
  position: PickUpPosition,
  title: "Your PickUp",
  snippet: "This app is awesome!",
  icon: 'img/drop off-01.png'
}, function(marker) {

  setInterval(function() {
      abc(marker);
   }, 5500);
});

function abc(marker) {
    marker.setPosition({ lat: 24.901730, lng: 67.040126});
}

Thank you for your quick response! I am gonna try this now.

Its working fine now. Thanks again!
Could you also guide me on how to slow down marker animation?
Cheers!

map.animateCamera({
  'target': GOOGLE,
  'tilt': 60,
  'zoom': 18,
  'bearing': 140,
  'duration': 10000 // 10 seconds
});

https://github.com/mapsplugin/cordova-plugin-googlemaps/wiki/Map#move-the-camera-within-a-specified-duration-time

Appreciate it! I meant to say marker's transition from point A to B. Such as while seeing a car moving smoothly on the map. I was using a JS library for this but that is not compatible with this cordova maps.


client crashing with TypeError if there are future transactions

The current version of the client seems to be crashing any time there the budget in question has any future transactions scheduled.
I want to believe this has something to do with my environment and not nYNABapi itself, but even when I stripped it down to a bare minimum script with a brand new minimal budget it seems to be the case.  nYNABapi was installed this morning per the readme from the master branch.
I'm happy to provide additional data if needed.
Bare minimum script
from pynYNAB.Client import clientfromargs
import configargparse

parser = configargparse.getArgumentParser('pynYNAB')
args = parser.parse_args()
args.email =<EMAIL_ADDRESS>args.password = 'some_password'
args.budgetname = 'some_budget'
client = clientfromargs(args)
client.sync()

print(client.budget_name)

Working: Sample budget with no future transaction

ssh://vagrant@<IP_ADDRESS>:2222/home/vagrant/venv/bin/python3 -u /vagrant/issue_example.py
some_budget

Process finished with exit code 0

Not Working: The exact same budget with a transaction happening tomorrow.

ssh://vagrant@<IP_ADDRESS>:2222/home/vagrant/venv/bin/python3 -u /vagrant/issue_example.py
Traceback (most recent call last):
  File "/vagrant/1.py", line 9, in <module>
    client = clientfromargs(args)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 16, in clientfromargs
    return nYnabClient.from_obj(args,reset)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 48, in from_obj
    client = nYnabClient(connection, budget_name=args.budgetname)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 42, in __init__
    self.sync()
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 80, in sync
    self.sync_obj(self.budget, 'syncBudgetData', knowledge=False,extra=dict(calculated_entities_included=False,budget_version_id=self.budget_version_id))
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 130, in sync_obj
    self.update_from_sync_data(obj,sync_data)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Client.py", line 109, in update_from_sync_data
    obj.update_from_changed_entities(changed_entities)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Entity.py", line 173, in update_from_changed_entities
    getattr(self, namefield).update_from_changed_entities(changed_entities.get(namefield))
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Entity.py", line 226, in update_from_changed_entities
    self._update_hashes()
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Entity.py", line 199, in _update_hashes
    self._dict_entities_hash = {hash(v): v for k, v in self._dict_entities.items()}
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB-0.3-py3.5.egg/pynYNAB/Entity.py", line 199, in <dictcomp>
    self._dict_entities_hash = {hash(v): v for k, v in self._dict_entities.items()}
TypeError: __hash__ method should return an integer

Process finished with exit code 1

Environment Information:
(venv) vagrant@vagrant:~$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

(venv) vagrant@vagrant:~$ uname -a
Linux vagrant 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

(venv) vagrant@vagrant:~$ python -V
Python 3.5.2

(venv) vagrant@vagrant:~$ pip freeze
aenum==1.4.5
appdirs==1.4.0
cchardet==1.1.1
click==6.6
ConfigArgParse==0.11.0
configparser==3.5.0
dateparser==0.5.0
enum34==1.1.6
et-xmlfile==1.0.1
ezodf==0.3.2
future==0.16.0
ijson==2.3
jdatetime==1.8.1
jdcal==1.3
jsonlines==1.1.0
jsonschema==2.5.1
jsontableschema==0.8.4
linear-tsv==1.0.0
lxml==3.7.0
openpyxl==2.4.1
pkg-resources==0.0.0
pynab==0.6.8
pynYNAB==0.3
python-dateutil==2.6.0
pytz==2016.10
regex==2016.11.21
requests==2.12.4
rfc3986==0.4.1
ruamel.yaml==0.13.4
schematics==2.0.0a1
six==1.10.0
tabulator==0.12.1
toolz==0.8.2
tzlocal==1.3
umalqurra==0.2
unicodecsv==0.14.1
xlrd==1.0.0

Hi,
I think, don't blame your environnement, blame the master branch ^^ ... I don't get enough time to work on it, and there's been regressions in the last few commits in the master. I'm looking into it, the 0.2 version on pypi should be functional enough, I hope.
Sorry about that, AFAIK the error is shown, I've overloaded hash to sort/compare entities/transactions etc, and apparently it's not working well...
Thanks for the report and sorry about the inconvenience.

No worries! It just seemed like a nice way to automate some things I deal with in ynab manually right now.  That anyone is working on this stuff at all is great!

For what its worth, I don't think this issue appeared in 0.3.  I rolled a clean environment and installed 0.2 pypi and still get the same error.  Still, think this thing is neat!
Traceback (most recent call last):
  File "1.py", line 10, in <module>
    client = clientfromargs(args)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Client.py", line 17, in clientfromargs
    client = nYnabClient(connection, budget_name=args.budgetname)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Client.py", line 45, in __init__
    self.sync()
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Client.py", line 71, in sync
    self.budget.sync(self.connection, 'syncBudgetData')
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/roots.py", line 61, in sync
    self.update_from_changed_entities(changed_entities)
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Entity.py", line 173, in update_from_changed_entities
    getattr(self, namefield).update_from_changed_entities(changed_entities.get(namefield))
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Entity.py", line 226, in update_from_changed_entities
    self._update_hashes()
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Entity.py", line 199, in _update_hashes
    self._dict_entities_hash = {hash(v): v for k, v in self._dict_entities.items()}
  File "/home/vagrant/venv/lib/python3.5/site-packages/pynYNAB/Entity.py", line 199, in <dictcomp>
    self._dict_entities_hash = {hash(v): v for k, v in self._dict_entities.items()}
TypeError: __hash__ method should return an integer
(venv) vagrant@vagrant:/vagrant$ pip freeze
aenum==1.4.5
appdirs==1.4.0
cchardet==1.1.1
click==6.6
ConfigArgParse==0.11.0
dateparser==0.5.0
enum34==1.1.6
et-xmlfile==1.0.1
ezodf==0.3.2
future==0.16.0
ijson==2.3
jdatetime==1.8.1
jdcal==1.3
jsonlines==1.1.0
jsonschema==2.5.1
jsontableschema==0.8.4
linear-tsv==1.0.0
lxml==3.7.0
ofxtools==0.3.13
openpyxl==2.4.1
pkg-resources==0.0.0
pynab==0.6.8
pynYNAB==0.2
python-dateutil==2.6.0
pytz==2016.10
regex==2016.11.21
requests==2.12.4
rfc3986==0.4.1
ruamel.yaml==0.13.4
schematics==1.1.1
six==1.10.0
tabulator==0.12.1
toolz==0.8.2
tzlocal==1.3
umalqurra==0.2
unicodecsv==0.14.1
xlrd==1.0.0

Hi tlastowka,
What's the status of this issue with recent versions (the ones using sqlalchemy for object relation management) ?


Lingering rendering bug

After using this mod on the server and playing around with it a bit, one time when I went through the portal, the game stopped rendering any blocks. Relogging didn't fix it. The only way to force the server to render anything is to place a block or interact, and even then, that only shows the subchunk that I was interacting with (unless it's on a chunk or subchunk border). But strangely enough, particle effects from blocks around me kept rendering.
Even after I took the mod off of the server, this persisted. I had to restart my client in order to fix it!
Running lithium and phosphor on the server side, along with some minor ones.
I also have a suggestion: Instead of making this server-side, can you make a client-side version? One that saves chunks and remembers where the portals are linked, and renders it client-side, rather than the server having to send over the blocks on the other side, and not being able to send very much?

I doubt the rendering issue is something I can change. This clearly originates on the client and I shouldn't be sending anything weird enough to trigger it :P
Making this client-side would be a completely different mod, and unfortunately I don't have any expertise in rendering, so it's unlikely that I'll create such a mod.


[e2e]: go tag main config-ldflags-assets-tag slsa3

Repo: https://github.com/slsa-framework/example-package/tree/v20.0.138
Run: https://github.com/slsa-framework/example-package/actions/runs/3326024924
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Trigger: push
Branch: v20.0.138
Date: Wed Oct 26 03:47:32 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v20.0.139
Run: https://github.com/slsa-framework/example-package/actions/runs/3334319978
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Trigger: push
Branch: v20.0.139
Date: Thu Oct 27 03:48:03 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v20.0.145
Run: https://github.com/slsa-framework/example-package/actions/runs/3364400160
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.go.tag.main.config-ldflags-assets-tag.slsa3.yml
Trigger: push
Branch: v20.0.145
Date: Mon Oct 31 20:19:32 UTC 2022
Tests are passing now. Closing this issue.


Integrate AI

translate
@AI-Bot

Perhaps an API a site could use detect and provide their own AI as a user? Perhaps the same API might be able to be used so a site could have official users.


object detection : pls support higher image resolutions

as I found out the tiny yolo network has a quite poor detection performance for my project  compared to the much bigger full yolo model. but when you train with a param setting of 608x608 for image size, its gets quite better.
For me the tiny yolo model is rather useless except when trained with higher image resolutions (I tried this with darknet from AlexeyAB with images size 608 and parameter random=1. which leaded to a 3 times higher training time but far better results).
So I would say you really should provide this and other settings as a param for training.

We are exploring the use or larger networks for users who have more memory and computational budget. We'd love to hear your use case and deployment scenario more.

I just try to build a small app that can recognize tropical fish.
When visiting an aquarium or when people are snorkeling, one is usually overwhelmed by the richness and diversity of the species one is watching. So giving the people an app which can recognize a species and provide further information about it, could be a nice additional experience.

Does this apply to the image similarity model as well? I am noticing poor matching for trained images and wonder if I can force it to use higher quality images.

I did not try - sorry

I'm also have the same problem. For small object detection, the resolution really affects precision. The object_detector.create should really have a resolution parameter. I'm gonna take a look at the code and see if this is easy to implement. Any hints?
Random would be nice, but that could be done when building the sframe, so it's not critical.

probably in object_detector.cpp: GRID_SIZE*SPATIAL_REDUCTION results in  416

Yes, I did some searching / reading and found out about the grid_size variable on turicreate\src\unity\toolkits\object_detection\object_detector.cpp and on turicreate\src\unity\python\turicreate\toolkits\object_detector\object_detector.py. Seems pretty trivial to make that a param in the create function. Any catches? Anything else I have to change?
I'll fork this, change the code and create a pull request :)

I dont know about memory implications
did u manage to use a retrained yolo model in an android app and if yes how :) ?

I am currently trying to train a mobilenet with tf and going from there to an ios and android model

Our object detection toolkit is unfortunately in a bit of a transient state, as we're porting the original Python-based implementation in object_detector.py to the C++-based one in object_detector.cpp. If you want some results sooner rather than later, the Python implementation is the one currently used by Turi Create.


Yet another small uBlock filter list breaks https://edition.cnn.com/

Yet another small uBlock filter list breaks https://edition.cnn.com/

What is broken there? I did not see any issues.
(About a month ago there was one mistake, but now all displays well)

@mtxadmin Works fine here with your hosts file.

Under some circumstances page can really break itself (see details above).
@WoodpeckerBaby Could you please check again.

Under some circumstances page can really break itself (see details above).
@WoodpeckerBaby Could you please check again.

@mtxadmin Yes, for me I tested with a normal fresh install browser with your latest hosts file and it works. So I meant to say the hosts file isn't the issue. Everything else is beyond the scope of your hosts file.

By the way, topic starter was used list and not hosts file.

By the way, topic starter was used list and not hosts file.

Ahh right @mtxadmin, I misread. 👍


Loot Tracker Saving without 30day / 1000 drop restriction

Is your feature request related to a problem? Please describe.
(I am using a runelite account to use the cloud) I got problems a few days ago with the loot tracker removing kills due to the maximum amount of drops restriction., I got frustrated about it because I wanted to make a "huge" loot tab (in the tracker, longer then 30 days) of my drops to see what I made and to resee my rare uniques.
Describe the solution you'd like
Removing the 30 day and 1000 drops restriction.
Describe alternatives you've considered
Making a local (automatic) save when closing the client that hasn't the 30 day and 1000 drops restriction.
Additional context
If the alternative passes a way to import it to another pc would be great!
I know that you can export your last 30days but you can't import/merge it from so far I know.

We can't easily make the client show any more data because swing is too slow to handle that many components. You can see the last 30 days of data on runelite.net, and if you to keep older data you can download it and view it locally in the json


CWire: Introduce prebid server adapter

New CWire prebid server adapter supporting ORTB2 protocol.
🏷 Type of documentation

new bid adapter

📋 Checklist

[x] Related pull requests in prebid.js or server are linked
[x] For new adapters check submitting your adapter docs

prebid-server PR:
https://github.com/prebid/prebid-server/pull/2511


delayers on multikernel RR

Hello hello @mvdoc, I was doing multikernel RR and trying to put delayers in the pipeline, but it didn't work (the pipeline couldn't run with delayers). Is it that we don't need to set it up for multikernel RR or it's just not implemented yet.
Also, I guess I don't fully (statistically) understand the delayer. Is it something similar to FIR? I noticed that in your tutorial, there was no HRF running on the stimulus side before fitting into RR. Is it because we have this delayer so we don't need to do any convolving anymore? (ping @jsmentch, since he has similar questions)
Thank you!

Hello hello @yibeichan!
Yep, we implement the FIR with the delayer. So there is no need to convolve the features by a standard HRF. (You could do that if you want, but then it would be fixed for every voxel, and the model prediction accuracy may be worse.) The fourth tutorial tries to get at that, showing that a model with delays is better than a model without delays, and showing that the FIR can model the HRF independently for each voxel (https://gallantlab.org/voxelwise_tutorials/_auto_examples/shortclips/04_plot_hemodynamic_response.html).
The delayer works with the multiple kernel ridge regression, as shown in the last tutorial. The set up is only a bit more complicated as it needs a ColumnKernelizer object in the pipeline. See https://gallantlab.org/voxelwise_tutorials/_auto_examples/shortclips/06_plot_banded_ridge_model.html

thank you thank you!! This makes a lot of sense!! I played with the multiple kernel RR two months ago, probably didn't find the example by that time. Today jeff and I had a conversation on delayer. Very glad we asked you!!


AKS support for AZs

Please add AKS to the list of AZ supporting services ->
https://docs.microsoft.com/en-us/azure/aks/availability-zones

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

ID: cca70845-100f-2cfd-aba3-34b7fa4a5264
Version Independent ID: 475b26e5-9e23-f769-3bd5-cbc4a678dbf0
Content: What are Azure Availability Zones?
Content Source: articles/availability-zones/az-overview.md
Service: azure
GitHub Login: @cynthn
Microsoft Alias: cynthn

@dvherk Thanks for your question. We are checking on this and will respond to you soon.

@cynthn  Now aks supports Availability zones https://docs.microsoft.com/en-us/azure/aks/availability-zones#limitations-and-region-availability
Can we add this to the table?

@cynthn I added the AKS service to the table and added a link in the end which points to "Creating AKS in Availability zones"
Please validate


Installation fails with "mkdir -p app/lib" on Windows 7

After trying to install with npm install nativefier -g I get the following output:
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "nativefier" "-g"
npm ERR! node v4.2.2
npm ERR! npm  v2.14.7
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>postinstall: `mkdir -p app/lib`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>postinstall script 'mkdir -p app/lib'.
npm ERR! This is most likely a problem with the nativefier package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     mkdir -p app/lib
npm ERR! You can get their info via:
npm ERR!     npm owner ls nativefier
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     C:\Program Files\Git\npm-debug.log

And here's the npm-debug.log file, if it's of any help.

Sorry about that, I overlooked the issue with windows mkdir -p, and it's fixed in v6.5.6. Do let me know if the problem persists!

Everything seems to work fine now! Thanks for the fix!