Android implementation documentation is out of date

The MainActivity.java file in newer versions of React Native is structured drastically different than it used to be. The documentation in the README.md file is out of date.

Good point. Thank you for reporting. Whenever I will find a energy to update it I will make new instructions.
NOTE: As of React Native 0.18 the MainActivity.java is different in the react-native init.

@jasonmerino Update in the master.

Awesome! Thanks @martincik :smile:


Test failure: test_only_update_old_event

Hi,
I'm trying to package khal for GNU Guix [0], but the build process fails during the test phase on test_only_update_old_event.
Specifically, the assertion that cal._db_needs_update() fails.
I've attached the build log: khal-0.7.0-build.txt
Please let me know if I can provide more information or help in any other way.
Here's the logged output of the test suite, cut from the full log:
starting phase `check'
============================= test session starts ==============================
platform linux -- Python 3.4.3 -- py-1.4.23 -- pytest-2.6.1
plugins: cov
collected 154 items

tests/aux_test.py ............
tests/backend_test.py ......................
tests/cal_display_test.py ....x
tests/cli_test.py .....x........
tests/controller_test.py ...
tests/event_test.py .............................
tests/khalendar_aux_test.py ................................
tests/khalendar_test.py .....................F
tests/settings_test.py .....
tests/terminal_test.py ...
tests/vtimezone_test.py ...
tests/ui/test_calendarwidget.py ...
tests/ui/test_widgets.py .

=================================== FAILURES ===================================
__________________________ test_only_update_old_event __________________________

cal_vdir = (<khal.khalendar.khalendar.Calendar object at 0x7ffff1e28518>, <FilesystemStorage(**{'path': '/tmp/nix-build-khal-0.7.0.drv-0/pytest-0/test_only_update_old_event0'})>)
monkeypatch = <_pytest.monkeypatch.monkeypatch object at 0x7ffff0f7b748>

    def test_only_update_old_event(cal_vdir, monkeypatch):
        cal, vdir = cal_vdir

        href_one, etag_one = vdir.upload(cal.new_event(dedent("""
        BEGIN:VEVENT
        UID:meeting-one
        DTSTART;VALUE=DATE:20140909
        DTEND;VALUE=DATE:20140910
        SUMMARY:first meeting
        END:VEVENT
        """)))

        href_two, etag_two = vdir.upload(cal.new_event(dedent("""
        BEGIN:VEVENT
        UID:meeting-two
        DTSTART;VALUE=DATE:20140910
        DTEND;VALUE=DATE:20140911
        SUMMARY:second meeting
        END:VEVENT
        """)))

        cal.db_update()
        assert not cal._db_needs_update()

        old_update_vevent = cal._update_vevent
        updated_hrefs = []

        def _update_vevent(href):
            updated_hrefs.append(href)
            return old_update_vevent(href)
        monkeypatch.setattr(cal, '_update_vevent', _update_vevent)

        href_three, etag_three = vdir.upload(cal.new_event(dedent("""
        BEGIN:VEVENT
        UID:meeting-three
        DTSTART;VALUE=DATE:20140911
        DTEND;VALUE=DATE:20140912
        SUMMARY:third meeting
        END:VEVENT
        """)))

>       assert cal._db_needs_update()
E       assert <bound method Calendar._db_needs_update of <khal.khalendar.khalendar.Calendar object at 0x7ffff1e28518>>()
E        +  where <bound method Calendar._db_needs_update of <khal.khalendar.khalendar.Calendar object at 0x7ffff1e28518>> = <khal.khalendar.khalendar.Calendar object at 0x7ffff1e28518>._db_needs_update

tests/khalendar_test.py:410: AssertionError
=============== 1 failed, 151 passed, 2 xfailed in 59.90 seconds ===============
phase `check' failed after 60.6 seconds

Here's a sorted list of all the dependencies being used to build khal and its dependencies, excluding implicit dependencies such as GCC, tar, make, etc.
acl-2.2.52
attr-2.4.46
bash-4.3.39
bison-2.7.1
bison-3.0.4
bzip2-1.0.6
coreutils-8.24
dbus-1.10.0
expat-2.1.0
file-5.22
flex-2.5.37
fontconfig-2.11.94
freetype-2.6
gdbm-1.11
gettext-0.19.6
glib-2.46.1
gmp-6.0.0a
gs-fonts-8.11
hicolor-icon-theme-0.12
indent-2.2.10
inputproto-2.3.1
intltool-0.51.0
kbproto-1.0.6
khal-0.7.0
libcap-2.24
libffi-3.1
libgcrypt-1.6.3
libgpg-error-1.19
libpthread-stubs-0.3
libx11-1.6.2
libxau-1.0.8
libxcb-1.11
libxdmcp-1.1.1
libxext-1.3.3
libxft-2.3.2
libxml2-2.9.3
libxrender-0.9.8
libxslt-1.1.28
m4-1.4.17
ncurses-6.0
openssl-1.0.2e
perl-5.16.1
perl-xml-parser-2.44
pkg-config-0.28
python-3.4.3
python-apipkg-1.4
python-atomicwrites-0.1.8
python-blinker-1.3
python-cffi-1.2.1
python-click-6.2
python-click-log-0.1.1
python-click-threading-0.1.2
python-configobj-5.0.6
python-coverage-3.7.1
python-cryptography-1.0.2
python-cryptography-vectors-1.0.2
python-dateutil-2.4.2
python-docutils-0.12
python-enum34-1.0
python-execnet-1.4.1
python-httplib2-0.9.1
python-icalendar-3.9.1
python-idna-2.0
python-iso8601-0.1.10
python-jinja2-2.7.3
python-jsonschema-2.4.0
python-lxml-3.4.2
python-markupsafe-0.23
python-minimal-3.4.3
python-mock-1.0.1
python-nose-1.3.4
python-oauthlib-1.0.3
python-pretend-1.0.8
python-psutil-3.0.1
python-py-1.4.23
python-pyasn1-0.1.8
python-pycparser-2.10
python-pygments-1.6
python-pyjwt-1.4.0
python-pytest-2.6.1
python-pytest-cache-1.0
python-pytest-cov-2.2.0
python-pytest-localserver-0.3.4
python-pytest-runner-2.6.2
python-pytest-xprocess-0.9.1
python-pytz-2015.7
python-pyxdg-0.25
python-requests-2.8.1
python-requests-toolbelt-0.5.0
python-setuptools-18.3.1
python-setuptools-scm-1.9.0
python-six-1.10.0
python-sphinx-1.2.3
python-sphinxcontrib-newsfeed-0.1.4
python-tzlocal-1.2
python-urwid-1.2.2
python-vdirsyncer-0.7.3
python-werkzeug-0.11.2
python-wheel-0.26.0
python-wrapper-3.4.3
python-wrapper-3.4.3
python-wsgi-intercept-0.10.3
radicale-1.0.1
readline-6.3
renderproto-0.11.1
shared-mime-info-1.2
sqlite-<IP_ADDRESS>
tcl-8.6.4
tk-8.6.4
tzdata-2015c
unzip-6.0
util-macros-1.19.0
xcb-proto-1.11
xextproto-7.3.0
xproto-7.0.26
xtrans-1.3.5
zlib-1.2.7

[0]
http://www.gnu.org/software/guix/

Thank you @lfam for building a package and reporting this bug, I'll have a closer look ASAP.

Sorry for not getting back to you earlier. I have finally been able to reproduce this (sometimes), but I haven't really found the cause yet and therefore not fixed it yet. But I haven't forgotten about this.

Interesting! It seems to be completely reproducible within the Guix build system.

By the way, I added the package:
https://www.gnu.org/software/guix/package-list.html#khal
If you click on the package's name you can see the packaging, which disables this test.
Here is an image of Khal's dependency graph, excluding implicit dependencies like GCC and the tar used to unpack the source tarball:
http://imgur.com/xgsq0j4

Reading the new bugs I noticed https://github.com/geier/khal/issues/320. I wonder if this bug has a similar cause.

I believe you are right and those are related.  Could you perhaps either test the current MASTER or patch v.0.7.0 so that lines 395 in tests/khalendar_test.py contains sleep(1)?

The build fails when setuptools-scm can't figure out the version of something (Khal itself?). Any idea how to work around that?
```starting phase `build'
running "python setup.py" with command "build" and parameters ()
Traceback (most recent call last):
File "setup.py", line 54, in
"Topic :: Communications",
File "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/site-packages/setuptools/dist.py", line 269, in init
_Distribution.init(self,attrs)
File "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/distutils/dist.py", line 280, in init
self.finalize_options()
File "/gnu/store/13n8xbi9wv9pigfyhir007qadr81jq46-python-3.4.3/lib/python3.4/site-packages/setuptools/dist.py", line 325, in finalize_options
ep.load()(self, ep.name, value)
File "/gnu/store/x7zdfc3b3hc50npbgnisy4ydmbiwgl76-python-setuptools-scm-1.9.0/lib/python3.4/site-packages/setuptools_scm-1.9.0-py3.4.egg/setuptools_scm/integration.py", line 19, in version_keyword
File "/gnu/store/x7zdfc3b3hc50npbgnisy4ydmbiwgl76-python-setuptools-scm-1.9.0/lib/python3.4/site-packages/setuptools_scm-1.9.0-py3.4.egg/setuptools_scm/init.py", line 77, in get_version
File "/gnu/store/x7zdfc3b3hc50npbgnisy4ydmbiwgl76-python-setuptools-scm-1.9.0/lib/python3.4/site-packages/setuptools_scm-1.9.0-py3.4.egg/setuptools_scm/init.py", line 36, in version_from_scm
LookupError: setuptools-scm was unable to detect version for '/tmp/nix-build-khal-0.7.0.drv-0/source'.
Make sure you're not using GitHub's tarballs (or similar ones), as those don't contain the necessary metadata. Use PyPI's tarballs instead.
For example, if you're using pip, instead of https://github.com/user/proj/archive/master.zip use git+https://github.com/user/proj.git#egg=proj
phase `build' failed after 0.7 seconds

Make sure you're not using GitHub's tarballs (or similar ones), as those don't contain the necessary metadata. Use PyPI's tarballs instead.

On Mon, Jan 18, 2016 at 03:41:58PM -0800, Markus Unterwaditzer wrote:

Make sure you're not using GitHub's tarballs (or similar ones), as those don't contain the necessary metadata. Use PyPI's tarballs instead.

I am not using a GitHub tarball. I'm building from a checkout of HEAD.
Are there extra steps I need to take to make such a checkout buildable?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-172683231

You need to have git installed, and the checkout must still be a git repo (i.e.
./.git must still be there)
On Mon, Jan 18, 2016 at 03:44:37PM -0800, lfam wrote:

On Mon, Jan 18, 2016 at 03:41:58PM -0800, Markus Unterwaditzer wrote:

Make sure you're not using GitHub's tarballs (or similar ones), as those don't contain the necessary metadata. Use PyPI's tarballs instead.

I am not using a GitHub tarball. I'm building from a checkout of HEAD.
Are there extra steps I need to take to make such a checkout buildable?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-172683231

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-172683615

Ah, that is impossible with Guix, because the .git subdirectory is non-deterministic and thus ruins the content-addressable-ness of the Nix / Guix system.
I will try geier's other suggestion, patching the relevant file directly. I wanted to build from HEAD because seems that a lot has changed since the last release.

I used Guix to check out the sources of 0.7.0. This involves deleting the .git metadata as mentioned above. I initialized a new git repository in the unpacked sources and generated the patch below with git-format-patch.
The test suite passes with this change. There are still two "xfails" that don't seem to cause the whole thing to fail. I didn't report them earlier because I figured they weren't important if the build process succeeds without them. They are:
tests/cal_display_test.py ....x
tests/cli_test.py .....x........

Patch:
From 707d9638df05b4b97fa8cedb72dd35b654fc4aa9 Mon Sep 17 00:00:00 2001
From: lfam
Date: Mon, 18 Jan 2016 18:52:50 -0500
Subject: [PATCH] Sleep for debugging test failure

---
 tests/khalendar_test.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/khalendar_test.py b/tests/khalendar_test.py
index 5040df6..e5e2ab1 100644
--- a/tests/khalendar_test.py
+++ b/tests/khalendar_test.py
@@ -393,6 +393,8 @@ def test_only_update_old_event(cal_vdir, monkeypatch):
     old_update_vevent = cal._update_vevent
     updated_hrefs = []

+    sleep(1)
+
     def _update_vevent(href):
         updated_hrefs.append(href)
         return old_update_vevent(href)
--
2.6.4

To get the last cal_display_test running, you need to install the cs_CZ.UTF-8 locale, the xfailing cli_test is currently xfailing everywhere because it tries to set the current date to a predetermined date and this doesn't work yet.
I will soon release a new version, either 0.7.1 with only this change or 0.8.0, but I'm not sure yet.

While reading tests/cal_display_test, I noticed that the relevant test's name is test_vertical_month_unicode_weekdeays. Is weekdeays a typo?
Also, is it testing something specific to the Czech locale, or can I patch it to use some other locale?
I ask because the full suite of locales is a very heavy dependency (450 MB) for users using Guix on distros besides GuixSD. Guix has a second locale package (glibc-utf8-locales) (6 MB) that is often used for testing; it contains "de_DE" "el_GR" "en_US" "fr_FR" "tr_TR".
What if I patched the test to use something from that list?

We are using Czech because their weekname abbreviations contain non-ascii characters. Turkish or Greek might work as well, I'll have a look tonight.
And yes, that is a typo.

Ah, that is impossible with Guix, because the .git subdirectory is non-deterministic and thus ruins the content-addressable-ness of the Nix / Guix system.

I believe that a shallow clone of a certain tag should always be identical, maybe you can use that?

On Tue, Jan 19, 2016 at 05:18:26AM -0800, Hugo Osvaldo Barrera wrote:

Ah, that is impossible with Guix, because the .git subdirectory is non-deterministic and thus ruins the content-addressable-ness of the Nix / Guix system.

I believe that a shallow clone of a certain tag should always be identical, maybe you can use that?

Perhaps. I believe this was discussed on the guix-devel mailing list
recently and some workarounds were suggested. But it is not a big
limitation in this situation — patching the file from the release
tarball was sufficient.

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-172850030

I've just added a test for the greek locale, it really shouldn't matter which one you run.

On Tue, Jan 19, 2016 at 04:09:06PM -0800, Christian Geier wrote:

I've just added a test for the greek locale, it really shouldn't matter which one you run.

Thanks!
Do you want me to submit the "sleep 1" patch from upthread or do you
want to deal with the issues with this test some other way?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-173029851

At least with current master, sleep(1) shouldn't be necessary, something like sleep(0.01) should suffice. I'll need to experiment on that. So, you don't need to submit the patch, and I really hope that in the next release you won't have to patch the code at all.

On Wed, Jan 20, 2016 at 02:41:05AM -0800, Christian Geier wrote:

At least with current master, sleep(1) shouldn't be necessary, something like sleep(0.01) should suffice. I'll need to experiment on that. So, you don't need to submit the patch, and I really hope that in the next release you won't have to patch the code at all.

Thanks! I'll wait for the next release.

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-173167164

Have we agreed on using sleep in the tests? I have another instance where tests are failing locally.

Do you have a better idea?

No I don't think so
On 3 February 2016 14:24:22 CET, Christian Geier<EMAIL_ADDRESS>wrote:

Do you have a better idea?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-179226898

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

I pushed a commit to master that fixes another testfailure (at least I had one
locally).
On Wed, Feb 03, 2016 at 05:24:22AM -0800, Christian Geier wrote:

Do you have a better idea?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-179226898

Thanks, I believe that one also errored several times on travis.
Quoting Markus Unterwaditzer (2016-02-04 20:35:13)

I pushed a commit to master that fixes another testfailure (at least I had one
locally).
On Wed, Feb 03, 2016 at 05:24:22AM -0800, Christian Geier wrote:

Do you have a better idea?

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-179226898

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/309#issuecomment-180016587

@lfam this one, too?

Yes, this one is also fixed in 0.8.1!

thank you for confirming!
Quoting lfam (2016-04-26 18:36:11)

Yes, this one is also fixed in 0.8.1!

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/pimutils/khal/issues/309#issuecomment-214804542


Code snippets for .NET v12 are incorrect

await blob.GetPropertiesAsync returns a Response<BlobProperties> not BlobProperties
// Get the blob properties
BlobProperties properties = await blob.GetPropertiesAsync();

// Display some of the blob's property values
Console.WriteLine($" ContentLanguage: {properties.ContentLanguage}");

should be
// Get the blob properties
BlobProperties properties = (await blob.GetPropertiesAsync()).Value;

// Display some of the blob's property values
Console.WriteLine($" ContentLanguage: {properties.ContentLanguage}");

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

ID: c6c6dc17-5057-abdd-506d-4d7b294925d9
Version Independent ID: 64ad32f4-f946-61f7-d105-8cd9205505f3
Content: Manage properties and metadata for a blob with .NET - Azure Storage
Content Source: articles/storage/blobs/storage-blob-properties-metadata.md
Service: storage
Sub-service: blobs
GitHub Login: @mhopkins-msft
Microsoft Alias: mhopkins

@LanderVe Thanks for the question! We are investigating and will update you shortly.

Hi @LanderVe
The code in the article is correct. There is an implicit cast to BlobProperties.
Thanks,
~ Mark
#please-close


Insufficient CSS Purge on variants after build

Description
I've written a button component with 3 color variants and 3 variant variants. (Checkout the project below for complete description):
import { defineRecipe } from '@pandacss/dev';

export const buttonRecipe = defineRecipe({
  className: 'button',
  description: 'The styles for the Button component',
  base: {
    color: 'neutral.700',
    p: '4px',
  },
  variants: {
    variant: {
      contained: {
        bg: 'blue.500',
      },
      outlined: {
        borderWidth: '4px',
      },
      text: {},
    },
    color: {
      blue: {},
      indigo: {},
      purple: {},
    },
  },
  compoundVariants: [
    {
      variant: 'contained',
      color: 'blue',
      css: {
        bg: 'blue.500',
      },
    },
    {
      variant: 'outlined',
      color: 'indigo',
      css: {
        border: 'indigo.500',
      },
    },
   ...
   ],
}

I only use color=blue and variant=contained in my app. When I build the app, I expect the Just-in-time compiler to remove unused variants styles from the final CSS file. But here is the end of CSS file:
...
@layer recipes {
 .button--variant_outlined {
   border-width: 4px;
 }
 @layer _base {
   .button {
     color: var(--colors-neutral-700);
     padding: 4px;
   }
 }
}
@layer utilities {
 .bg_blue\.500 {
   background: var(--colors-blue-500);
 }
 .bg_indigo\.500 {
   background: var(--colors-indigo-500);
 }
 .bg_purple\.500 {
   background: var(--colors-purple-500);
 }
 .border_blue\.500 {
   border-color: var(--colors-blue-500);
 }
 .border_indigo\.500 {
   border-color: var(--colors-indigo-500);
 }
 .border_purple\.500 {
   border-color: var(--colors-purple-500);
 }
}

As it can be seen, the border-{color} and bg-{color} has been generated for all of the color and variants (that has been written in compoundVariants section)
Here is the question, why PandaCSS can not remove unused and extra border-{color} and bg-{color} classes since we don't use them at all?
Link to Reproduction
https://stackblitz.com/edit/vitejs-vite-ygnv7y?file=src%2Fcomponents%2Fbutton.style.ts
Steps to reproduce

install packages
build the app
checkout CSS file placed in dist dir

JS Framework
React (TS)
Panda CSS Version
^0.17.3
Browser
No response
Operating System

[x] macOS
[ ] Windows
[ ] Linux

Additional Information
No response

compoundVariants generates atomic CSS in the @layer utilities
due to static limitations, it's way easier to reason about if we just generate that CSS no matter the usage in your code (just like cva/sva)
if we JIT'd this as well, users would often expect those styles to be generated in simple cases that involves dynamic stuff
things like
const Button = ({ color, children }) => {
    const [variant, setVariant] = useState("contained")
    // ...
    return
{children}

}

which compoundVariants CSS should we generate in that case ? do we not generate anything unless using config.staticCss ? that doesn't look like a good DX

btw for your use-case, it looks like you're looking for colorPalette
https://panda-css.com/docs/guides/virtual-color#using-with-recipes


Internal transpiler error in CommutativeCancellation

Environment

Qiskit Terra version: main @ f37dcf9
Python version: 3.9
Operating system: macOS

What is happening?
Randomised testing has detected a reliable reproducer for transpiler failures in the commutative cancellation pass, showing TranspilerError("internal error").  I imagine it's related to the instruction-level condition, but I don't know entirely.
I bisected the failure to #8184.  The line triggering the error is in CommutativeCancellation, though, which wasn't directly touched: https://github.com/Qiskit/qiskit-terra/blob/f37dcf9d9c879867140b3072483a3dbd36cb5c1f/qiskit/transpiler/passes/optimization/commutative_cancellation.py#L132-L143
How can we reproduce the issue?
import qiskit
from qiskit.providers.fake_provider import FakeAthens

qc = qiskit.QuantumCircuit(3, 3)
qc.u(0, 0, 0, 1)
qc.ccx(2, 1, 0).c_if(qc.cregs[0], 0)
qc.measure(2, 2)
qiskit.transpile(qc, FakeAthens(), optimization_level=2)

This gives a transpiler error:
Traceback (most recent call last):
  File "/Users/jake/code/qiskit/terra/repro.py", line 8, in <module>
    qiskit.transpile(qc, FakeAthens(), optimization_level=2)
  File "/Users/jake/code/qiskit/terra/qiskit/compiler/transpiler.py", line 341, in transpile
    _serial_transpile_circuit(
  File "/Users/jake/code/qiskit/terra/qiskit/compiler/transpiler.py", line 434, in _serial_transpile_circuit
    result = pass_manager.run(circuit, callback=callback, output_name=output_name)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/passmanager.py", line 511, in run
    return super().run(circuits, output_name, callback)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/passmanager.py", line 224, in run
    return self._run_single_circuit(circuits, output_name, callback)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/passmanager.py", line 279, in _run_single_circuit
    result = running_passmanager.run(circuit, output_name=output_name, callback=callback)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/runningpassmanager.py", line 124, in run
    dag = self._do_pass(pass_, dag, passset.options)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/runningpassmanager.py", line 167, in _do_pass
    dag = self._run_this_pass(pass_, dag)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/runningpassmanager.py", line 196, in _run_this_pass
    new_dag = pass_.run(dag)
  File "/Users/jake/code/qiskit/terra/qiskit/transpiler/passes/optimization/commutative_cancellation.py", line 143, in run
    raise TranspilerError("internal error")
qiskit.transpiler.exceptions.TranspilerError: 'internal error'

What should happen?
This is a regression - the same reproducer succeeds before #8184, so some logic might have got a little tangled.
Any suggestions?
No response

Sorry for breaking this, submitted a fix.

No worries, it's not a problem - that's why we have the randomised testing!


feat: provider deployments on provider console

Create a deployments page which allows the provider to see all the deployments hosted and their details.
Provider Deployments page should have both active and closed deployments.
It should have a table containing information about deployment like owner address, dseq, spent, monthly cost, resources (GPU, CPU, memory, storage)
The provider deployments details page should have the details below.
Status, DSEQ, Owner, Created Date/time, TimeLeft, Cost, Amount Spent, Balance, Transferred, Resources
It should also take note of multiple gseq, if any.

I have fixed all the issues mentioned in the comments. Some of the comments were general, so I tried to fix them in all the files.


Support for webp raster data.

Hi @lygstate - while we would like to support the most popular image formats, since WebP is currently only supported by Chrome/Chromium-based browsers, I don't feel that it clears this bar at this time.
Though I have not tried it, WebP images used in Tangram JS should load fine in Chrome.
For Tangram ES, you could look at adding support in a fork, and we might consider a Pull Request if you're interested though I will defer to @blair1618 on that.

Interesting idea! WebP has some nice theoretical advantages over JPG and PNG, but like Brett said it's unlikely that we would want to include built-in support for WebP in tangram-es right now, simply because support in viewing and editing software is relatively scarce.
The usable image formats in tangram-es are currently those that can be decoded by stb_image. Supporting WebP would require compiling an entirely new decoding library, and that burden doesn't seem worth the payoff for us.


fix(jsii-diff): detect interfaces inherited via interfaces

jsii-diff is currently throwing on CDK because it thinks interfaces
are being removed from the inheritance chain, even if they've actually
been moved to base classes.
This is because the ClassType.getInterfaces() method of jsii-reflect
was only returning its direct interfaces, even when run with
inherited=true (as opposed to recursively returning the interfaces
all the way up the tree).
Q: Why did you not add a unit test in jsii-reflect?
A: The set suite of jsii-reflect is quite anemic, and basically only
tests that we can mostly deduce the types that are present in an
assembly. It doesn't have good testing infrastructure for actually
asserting things about arbitrary small pieces of typescript, instead it
mostly works on the generated assemblies from the jsii-calc etc.
examples. jsii-diff does have that testing infrastructure, and so
jsii-diff serves as the test suite for jsii-reflect at the moment...

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 9d3bec3c7bbd34fd74e8bc9cef29e2e071b2051f
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 80b7236a586ae3ba1bd59cd26eb8ab703b332315
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: ac6ddc73c436171329b1f0d4748ce95d0f0a34ec
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AutoBuildProject6AEA49D1-Blkkw9bQFn8A
Commit ID: 201ab41f443011a6c0c36e7730156eebc434dc8b
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Update dependencies

MetaData -> Metadata

rename auxiliary data
https://github.com/input-output-hk/cardano-ledger-specs/pull/2052

Rename the type family Core.Metadata to Core.AuxiliaryData.
Rename the Allegra & Mary Metadata to AuxiliaryData.
Rename ValidityInterval accessors:
validFrom -> invalidBefore
validTo -> invalidHereafter

Parameterise era-independent types over the crypto instead of era
https://github.com/input-output-hk/cardano-ledger-specs/pull/2038
A bunch of types were parameterised over the era, while they were really
era-independent. It is confusing to parameterise something over the era while
it really is era-independent. Moreover, it requires much more needless
conversions/coercions.
(Nearly?) all of them are now parameterised by the crypto instead of the era.
The Cardano API has been updated to reflect this. In most places, the
ledgerera parameter has been replaced by StandardCrypto.

Typically, I would squash the two commits into one, as all changes are needed to get to a buildable state (otherwise git bisect is broken). But to make the review easier, I cherry-picked #2160 and made the remaining changes in another commit.
So if we want a buildable history, we should squash before merging.

I pushed another update, which brings in https://github.com/input-output-hk/ouroboros-network/pull/2811.
That commit can be squashed before merging.

Can I squash and merge this? I'm afraid it will get stale and that someone else will try to duplicate this work.

Please do!

Please do!

Ok, will do :slightly_smiling_face:
I have rebased, but not squashed. I don't know what the preference is for this repo: buildable commits or logical commits that can be reviewed in isolation.
I went for the latter in this case, because of the big "MetaData -> Metadata" renaming.

bors merge

For a dependency update like this, I would have just squashed it into a single commit, but whatever.


Team contract and Contributing.md

Team Contract
Licence
Contributing.md
Code of Conduct

Team contract
All other documents are added in the repository.


Handle rotation in metadata

EXIF (and probably other metadata formats) can store the intended display orientation of the image. Fairly commonly used by cameras. Pictus currently doesn't support this, but would be quite nice if it did.

There are eight distinct orientations that can be stored in EXIF metadata, finding test data for that will be fun.

Some minor rounding issues remain, otherwise all modes seem to work.


PR: Pin Jedi to 0.9.0

I ran our tests with the new 0.10.0 version and several of them are failing.
Besides, our new completions for Numpy and Matplotlib are failing with that version too.

Debian Stretch will ship with jedi v0.10.0, how should we proceed?

We are aiming at being compatible with Jedi 0.10 in version 3.1.4, to be released in a month or so.
If the addition of Jedi 0.10 is imminent in Debian Stretch, then users will have to depend on Rope until 3.1.4 is out.

If the addition of Jedi 0.10 is imminent in Debian Stretch

It is there already.

users will have to depend on Rope until 3.1.4 is out

Rope is Python 2 only on Debian (version 0.10.3). Upstream got reliable support for Python 3 only recently (version 0.10.4), unfortunately not in time for the freeze. How important are rope / jedi for spyder ?

How important are rope / jedi for spyder ?

They provide code completion for the Editor, so I'd say pretty important :-)

I meant spyder actually works fine without any of rope / jedi installed right? Sure, it would be a missing feature (whose importance is relative), but the rest of the editor will remain perfectly usable am I correct?
Otherwise, how far are you from having compatibility with 0.10.0? Is that something which could be cherry-picked on top of 3.1.3?

Otherwise, how far are you from having compatibility with 0.10.0?

I found some problems with 0.10.0 that we either have report upstream as errors or fix in our side. So I don't know when we'll be compatible with 0.10.0.
And there's also PR #4121.

Is that something which could be cherry-picked on top of 3.1.3?

I'd think you can cherry-pick our changes, yep.

So, the corresponding patch to PR #4121 would make spyder 3.1.3 work with jedi 0.10.0 or is there more to be done?

is there more to be done?

Yes, there is. Our test suite is not passing with 0.10.0 even after applying #4121.


elfkickers: 3.1a -> 3.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/elfkickers/versions.
meta.description for elfkickers is: "A collection of programs that access and manipulate ELF files"
meta.homepage for elfkickers is: "http://www.muppetlabs.com/~breadbox/software/elfkickers.html"
meta.changelog for elfkickers is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/ebfc passed the binary check.

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/elfls passed the binary check.

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/elftoc passed the binary check.

Warning: no invocation of /nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/infect had a zero exit code or showed the expected version

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/objres passed the binary check.

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/rebind passed the binary check.

/nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin/sstrip passed the binary check.

6 of 7 passed binary check by having a zero exit code.

6 of 7 passed binary check by having the new version present in output.

found 3.2 in filename of file in /nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2

directory tree listing: https://gist.github.com/4f9b485f6c2ba1488fdd5e82a956e59c

du listing: https://gist.github.com/e464adf20a8174c2463c2625f60feb83

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
elfkickers

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A elfkickers https://github.com/r-ryantm/nixpkgs/archive/bd365579a6ac4d9a1d057dfe027477249aae9c64.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2
ls -la /nix/store/89c6wn65xi24v6m8qgwgv5na2gfqxafg-elfkickers-3.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

elfkickers

Maintainer pings
cc @dtzWill for testing.

Result of nixpkgs-review pr 124178 at bd365579 run on x86_64-linux 1

1 package built successfully:

elfkickers

2 suggestions:

warning: unclear-gpl
gpl2 is a deprecated license, please check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/development/tools/misc/elfkickers/default.nix:20:5:
   |
20 |     license = licenses.gpl2;
   |     ^

error: no-flags-spaces
makeFlags cannot contain spaces, please use makeFlagsArray in Bash.
Near pkgs/development/tools/misc/elfkickers/default.nix:12:3:
   |
12 |   makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc prefix=$(out)" ];
   |   ^

Utilities seem to work in my basic testing :), but to address the build warnings (whoa those are neat!):

* `gpl2` is a deprecated license, please check if project uses `gpl2Plus` or `gpl2Only` and change `meta.license` accordingly.

Checked: file headers mention "GPLv2+" so I think it's safe to go to gpl2Plus :).

* `makeFlags` cannot contain spaces, please use `makeFlagsArray` in Bash.

I think this can be fix by replacing with makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" "prefix:=${placeholder "out"}" ];.

Let's see if I can restore enough setup to add commits for these... :innocent:  (gimme a few minutes :))
Also:
@GrahamcOfBorg build pkgsMusl.elfkickers
(works locally FWIW)
Also, mostly self-note:
Cross is broken because of hardcoded reference to 'ar' in a few makefiles (easy to fix), as well as attempting to build+run a utility that's not worth working around (IMO) presently, but just wanted to note it :).


Plasma5 lock of no return

Issue description
I was using a dual screen setup, then removed the USB-C cable feeding audio/video, etc. I closed the lid to go in suspend and then opened the lid again to find... that my mouse cursor of the touch pad was not being displayed in what's supposed to show the lock screen. I suspect that it was still showing the lock screen somewhere, but just not in a visible area.
This rendered me unable to login to this laptop, until I killed my desktop session. Not cool.
This never happened with 18.03, but it might just have been a coincidence.
Steps to reproduce
Unknown
Technical details

system: "x86_64-linux"
host os: Linux 4.14.76, NixOS, 18.09.git.a4c4cbb (Jellyfish)
multi-user?: yes
sandbox: yes
version: nix-env (Nix) 2.1.3
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

(reporter was banned #51078)


Consolidate keyring interactions on extension and mobile

Today both extension and mobile use the eth-keyring-controller package, but they each have their own wrapper methods for safely interacting with this underlying keyring controller. These wrapper functions handle things like:

Keeping other controller state in-sync with keyring state
Input parsing
Setup and cleanup steps for hardware wallets
Routing messages between the keyring controller and the message signing controllers

Mobile has these wrapper functions in @metamask/keyring-controller, but extension has them as part of metamask-extension.js. Most of the functionality is similar between the two, but there are many differences as well.
We should consolidate this code between extension and mobile where possible, so that both projects are using @metamask/keyring-controller. We can normalize the behavior between them both where possible. In cases where we do need some project-specific code, we can migrate that into the client repositories directly.

All issues closed, closing the epic


Why the title casing?

This is going to sound ridiculous (and oh boy, it is) but the fact that the package is named Chart.js and not chart.js is driving me crazy.
It causes (nearly) no technical issues, but it just strikes me as very odd that the title-casing was the casing of choice.

Staring at a list of neatly hyphen-delimited lower-cased package names, he scanned through the dependency list when suddenly his eyes were accosted by

Is it crazy to ask that you (re)consider your package name casing choice?

I've realized that I've not followed the template; so:
Expected Behavior
chart.js
Current Behavior

Possible Solution
Rename the package to chart.js
Steps to Reproduce (for bugs)

Rename the package to chart.js (in the next major/minor)
Profit

Context
It drives me bananas :banana:
Environment
UTF-8

@crystalcode-io looking at npm we should already being installing using chart.js all lower case. Bower on the other hand uses the repository name which includes the capital 'C'.

We changed Bower to use the same convention as npm: bower install chart.js --save

If we decide to change the repository name, I think it would be better to use chartjs (no uppercase, no dot), since we started to prefix charts and plugins by chartjs-.

Ah, okay; some hosted services/CDNs still use the capital "C" (for both the package and filenames)

https://cdnjs.cloudflare.com/ajax/libs/Chart.js/2.6.0/Chart.js

I wasn't sure if there was already discussion of this occurring between the core contributors. However, considering there is now a naming disparity as mentioned, between CDNs, Bower, npm, etc., and also considering the direction of de-facto conventions in the JS package universe, I think it'd be valuable to decide on this concretely.
As a breaking change, it would make sense to defer this to the next major; is there a target date for 3.0 yet?

@crystalcodesoftware I think that cdnjs is the outlier here as far as the package name goes. That's maintained outside our control. I'm guessing you could change it to lowercase by renaming this directory: https://github.com/cdnjs/cdnjs/tree/master/ajax/libs/Chart.js. Feel free to send them a PR
We're currently working on 3.0 and have released an alpha. I suppose we could rename this repo and the distribution file names. I personally don't think those are worth changing though. @kurkle @etimberg thoughts?

I filed an issue with cdnjs to discuss in case anyone has thoughts: https://github.com/cdnjs/cdnjs/issues/13962

Package renamed to lowercase here: https://github.com/chartjs/Chart.js/pull/7416
All that remains is deciding whether to do anything about cdnjs: cdnjs/cdnjs#13962


Parse FpML notional schedule parameterized form

Extend FpML swap parsing to handle notional schedules fully.
See #1241

Closed by #1241


Different authentication mechanisms support with plugins

As I promised, I've created SASL GSSAPI support without compile time dependencies via callback module in config

Please bump version to 2.5 in Makefile and brod.app.src

All done

@ElMaxo I have zero experience on kerberos.
Do you have a quick guide on how to set it up for testing ?

I have zero experience as an administrator too, I've tested it on ready
environment. I'll contact my system administrator, may be he has some guides
2017-05-24 11:30 GMT+03:00 Zaiming Shi<EMAIL_ADDRESS>
@ElMaxo https://github.com/elmaxo I have zero experience on kerberos.
Do you have a quick guide on how to set it up for testing ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/klarna/brod/pull/209#issuecomment-303655344, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFZL5RA5kRYUGdMEL82oo4KUIe-Zl286ks5r8-qLgaJpZM4Njc9c
.

--
С уважением, Давиденко Максим

Code looks good.
I'll try to setup a test environment to play with it a bit before merging.
Thanks a lot! @ElMaxo

You are welcome. Very glad to contribute

@ElMaxo I have changed the base branch of this PR.
Please squash commits into one.
I'll make some nitpicking changes myself and send an other PR for master branch.

@zmstone, Should I create new branch at my fork or how to squash commits into one?

I guess you can squash your master branch

@zmstone, all done


How to do Unit Tests?

I tried the equivalent function to the react library but composeStory does not render to screen.

I figured out a basic solution:
import {describe, it, expect} from 'vitest';
import Meta, {Primary} from './Button.stories';
import {Button} from './Button.tsx';
import {render} from '@solidjs/testing-library';

describe('It should create test on stories', () => {
  it('Tests stories', async () => {
    const args = {
      ...('args' in Meta ? (Meta as unknown as {args: Record<string, any>}).args : {}),
      ...('args' in Primary ? (Primary as unknown as {args: Record<string, any>}).args : {}),
      backgroundColor: 'blue',
    };
    const renderedStory = render(() => <Button {...args} />).container;
    expect(renderedStory).toHaveTextContent('Button');
  });
});


Bundle intermediate certs again

The behavior was changed in go-acme 4.9.0 to only bundle if specified. Do this again to restore the previous behavior.

I'll copy it manually to test


support optional tag for pointer fields

Sorry, this is a mistake. I was trying to PR to a forked repo.


How to call iconify globally with vue 3

I would like to be able to call iconify globally and use it anywhere within the app without import but still shouldn't load all the files as well, only those passed to the v-bind:icon prop

What exactly are you trying to do?

i dont want to have to import iconify in every vue file when i want to use it, im currently using it in mamy files, and i just want to be able to call if like   at anywhere in the app

So you want to use component without importing it? Then register it. See https://vuejs.org/guide/components/registration.html


[Cosmos] Fix failing unit tests

This PR fixes the failing unit tests in the Cosmos pipeline, which is the majority of tests at the moment.

/azp run python - cosmos - tests

API change check for azure-cosmos
API changes are not detected in this pull request for azure-cosmos

/azp run python - cosmos - tests

Initial state:

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests

/azp run python - cosmos - tests


fix soname of libgerbil on darwin

Description of changes
The soname/identification of libgerbil on darwin is not correctly fixed up, resulting in any binaries linked with libgerbil to attempt to link to libgerbil in the temporary build dir from the gerbil derivation. This means that any compiled gerbil program won't work as the propagated soname will result in the binary being unable to correctly link with libgerbil.
Adding an Darwin-only step to use install_name_tool to fix up the soname of libgerbil fixes this issue. We're using realpath here as the qualified path to libgerbil is $out/gerbil/$version/lib/libgerbil.so and this is an easier way to obtain the qualified path.
Fixes NixOS/nixpkgs#272967.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Tagging @fare as the maintainer of the gerbil package.

Is that all? You don't need to patch bach and gxc to point at the right library?

Is that all? You don't need to patch bach and gxc to point at the right library?

gxc (at least on Darwin) seems to statically link libgerbil, so it's unaffected (libgambit was always linked correctly):
bash-5.2$ otool -L /nix/store/hvdcfh7ipwsky5mv8j904ks5pjvfa9lf-gerbil-0.18.1/bin/gxc
/nix/store/hvdcfh7ipwsky5mv8j904ks5pjvfa9lf-gerbil-0.18.1/bin/gxc:
        /nix/store/hvdcfh7ipwsky5mv8j904ks5pjvfa9lf-gerbil-0.18.1/gerbil/v0.18.1/lib/libgambit.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

Same deal with bach/gerbil:
bash-5.2$
/nix/store/hvdcfh7ipwsky5mv8j904ks5pjvfa9lf-gerbil-0.18.1/bin/gerbil:
        /nix/store/hvdcfh7ipwsky5mv8j904ks5pjvfa9lf-gerbil-0.18.1/gerbil/v0.18.1/lib/libgambit.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

Looks good to me, modulo doing it The Right Way™ with respect to how nixpkgs expects you to fixDarwinDylibNames or not.

Result of nixpkgs-review pr 273803 run on aarch64-darwin 1

1 package failed to build:

glow-lang

2 packages built:

gerbil
gerbil-unstable

From testing and reviewing hydra, it appears glow-lang has been failing on Darwin for some time. Running nix run nixpkgs#glow-lang on recent nixpkgs-unstable produces the same result.

glow-lang failing to build is a known issue: some recent bug fix changed some order of evaluations and caused unit tests to fail that depended on the previous one for the exact numbering of gensyms.


importing in_app_purchase fails

I am trying to use in_app_purchase plugin, and it fails to import.
To reproduce create a new flutter project on stable, and add
  in_app_purchase: ^1.0.6 as dependency
then:
~/s/f/test λ flutter pub get
Because in_app_purchase >=0.6.0 depends on in_app_purchase_android ^0.1.0 which depends on test ^1.16.0, in_app_purchase >=0.6.0 requires test ^1.16.0.
So, because test depends on in_app_purchase ^1.0.6 and test is 1.0.0+1, version solving failed.
Running "flutter pub get" in test...
pub get failed (1; So, because test depends on in_app_purchase ^1.0.6 and test
is 1.0.0+1, version solving failed.)

This is a side effect of https://github.com/flutter/flutter/issues/86894, so closing as a duplicate.
You can avoid this by not calling your project test, which is the name of a widely-used package.


getBlocksFrom() should return a mutable array

Commit explains it.
@Geod24 is there a way I can avoid doing the cast() here? Otherwise I'm getting the mutable/immutable array compare mismatch error:

source/agora/test/Ledger.d(69,12): Error: array equality comparison type mismatch, Transaction[] vs immutable(Transaction[])

Maybe we just need to implement opEquals manually?

ah this change is bad, I should not pass around mutable. I realized it shortly after making the pr. :)

I'm gonna close this for now. My original intention was to remove the need for a write + read (+ deserialization) here: https://github.com/bpfkorea/agora/blob/d2931dd0d0f552997bc80e799a5275f5c3cecff5/source/agora/node/Ledger.d#L241


InternalAPI has PublicId in methods - should be Id

Edit, putting in place depreceated functions

Record and RecordCreate classes


perf(prometheus) use lua-resty-counter on hotpath counter increments

Previously counters in prometheus plugin are implemented with shm
counters. Multiple shm operations happen with request, and each
requires shm level lock across all workers. The lock overhead is
especially noticable while running Kong with large amount of cores.
To improve performance, prometheus plugin now uses lua-resty-counter
for counter and histogram metrics. It replaces per request shm
operation with cheaper worker level Lua numbers and sync to shm timely.
Need https://github.com/Kong/lua-resty-counter/pull/1 first to and bump dependency luarocks version.

kong branch is temporary targeted to 1.4.0 to let CI run.

@fffonion since #72 was merged, it should be possible to target next on CI again

@hishamhm Thanks!


XGBoost Evaluator Project Implementation

Hello! This is our cleaned-up implementation of the XGBoost Evaluator project, which was recently approved by the Google Team. Your input and feedback is much appreciated!

According to the proposal, this evaluator will be at tfx_addons/xgboost_evaluator and packaged. Has that plan changed?
https://github.com/tensorflow/tfx-addons/blob/main/proposals/20210707-xgboost_evaluator.md#project-directories

According to the proposal, this evaluator will be at tfx_addons/xgboost_evaluator and packaged. Has that plan changed?
https://github.com/tensorflow/tfx-addons/blob/main/proposals/20210707-xgboost_evaluator.md#project-directories

That is correct.

@rcrowe-google we don't have write permissions for this repo, so we must use PRs unfortunately 😅

(also we should avoid pushing to main branch directly to avoid merge conflicts)

CC @rcrowe-google can you reopen the PR please 😄

@rcrowe-google we don't have write permissions for this repo, so we must use PRs unfortunately 😅

Right, forgot about that, sorry.  Also I don't think I fully grokked the power of codeowners, or lack thereof.

Let me know when you're ready for me to review and merge.

@rcrowe-google Ready for review!


Jenkins refactor chart values

Most chart follow lowerCamelCase. I figured it was time we brought this chart into line for reference.

@viglesiasce @seanknox

I'm torn on this one. While agree that some consistency among charts is ideal, I'm not sure we have anything in place that dictates camel case. My other hold up is that this is a fully API (values file) breaking change. I'd rather not do something like that in a minor release.
Can we wait until there is a more substantial functional change before making this cosmetic one? Then we can bump to 1.x.

My 2 cents are that having consistency in values.yaml files across the repo will be less confusing for chart users. For example, I've seen a lot of folks assume that the persistence.enabled value is the same in every chart, and whilst it may or may not make sense to assume that persistence can be configured in every chart, we can at least avoid more confusion by having a convention where this value is used. Calling this Persistence.Enabled is just as annoying as calling this Volume.Enabled or something else as it requires me to learn the values that are specific to this chart.
Agree that this is a breaking change, and should be bumped to 1.0.0, however I don't think it needs to wait for other substantial changes. @viglesiasce are there any specific changes you'd like to rope in with this?

I was trying to achieve some consistency even if not required. I also think lowerCamelCase is easier to read (but that's subjective) I've received a bunch of comments as to why this chart doesn't look like other charts that are out there. Also was trying not to bundle a cosmetic change with a functional change so that we can isolate any bugs we caused in this change.

I'm good with just a version bump and not requiring further changes.

@lachie83 want to rebase this one and bump the version? Marking as stale in the meantime

I'm happy to close this. There's not enough interest currently


btn-group has inconsistent focus/active states when combined with hover states

Code example taken directly from the docs:
<div class="btn-group" role="group" aria-label="Basic example">
  <button type="button" class="btn btn-primary">Left</button>
  <button type="button" class="btn btn-primary">Middle</button>
  <button type="button" class="btn btn-primary">Right</button>
</div>

Left button active, middle button hovered:

Middle button active, left button hovered:

Operating system: macOS Catalina 10.15.7
Browser: Chrome 90.0.4430.212

I guess this could be fixed by using z-index:2 on focused button, and z-index:1 on hovered button.

Agreed with the diagnosis, we need to decouple both states' z-index here.

hey, if anyone's not working on this I can give this a shot - would like to try to start contributing :)


Add Datememe

first dating pwa https://www.datememe.com

Added in the datememe branch, will test it a bit more and merge. Thank you for suggestion!

Added, will be deployed soon.


make machine sim drawing work properly

still missing parts and "ink" could be thicker but the geometry lines up


chore: kill http-server on failed tests

Instead of making a check to see which OS are you using (needs an extra lib and extra code), I just kill it twice, better be sure it is dead.
No problem on Mac, but let see Windows.

Apparently the Linux on travis doesn't like it at all, so I will keep investigating.

Fixed it at last, thanks to Filipe.

Fixed at #1561


Remove NavCoinM8 from wallets page.

NavCoinM8 is currently not being supported.
Moved from #255
Checklist

[x] Have you assigned/claimed the issues you've resolved in this pull request?
[x] Have you checked there are no merge conflicts?
[x] Have you tested the changes work across both mobile and desktop?

https://deploy-preview-256--navcoin.netlify.com/en/wallets/
https://deploy-preview-256--navcoin.netlify.com/es/wallets/
https://deploy-preview-256--navcoin.netlify.com/it/wallets/
https://deploy-preview-256--navcoin.netlify.com/ru/wallets/
https://deploy-preview-256--navcoin.netlify.com/kr/wallets/
https://deploy-preview-256--navcoin.netlify.com/zh/wallets/
https://deploy-preview-256--navcoin.netlify.com/jp/wallets/

moved from #257
Remove novaexchange.com from buy-navcoin.
https://deploy-preview-256--navcoin.netlify.com/en/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/es/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/ru/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/it/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/kr/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/zh/buy-navcoin/
https://deploy-preview-256--navcoin.netlify.com/jp/buy-navcoin/

https://deploy-preview-256--navcoin.netlify.com/en/wallets/
https://deploy-preview-256--navcoin.netlify.com/es/wallets/
https://deploy-preview-256--navcoin.netlify.com/it/wallets/
https://deploy-preview-256--navcoin.netlify.com/ru/wallets/
https://deploy-preview-256--navcoin.netlify.com/kr/wallets/
https://deploy-preview-256--navcoin.netlify.com/jp/wallets/
https://deploy-preview-256--navcoin.netlify.com/zh/wallets/


Hotfix: Ansible install, python2 depricated

As of 23rd January, 2021, pip v21.0 depricated python2
and removed support for python2. As of now, ansible seems to use
python2 for deployment.
https://github.com/pypa/pip/issues/6148
This broke the installation. For hotfix, added custom pip install
command based on Vagrant's ansible local documentation
https://www.vagrantup.com/docs/provisioning/ansible_local
testing
vagrant up

Note: Requires fairly recent version of vagrant

❗ Issue: The web interface seems to be broken.
I am not sure if the issue is related or not yet.

❗ Issue: The web interface seems to be broken.
I am not sure if the issue is related or not yet.