Correct a technical flaw with the spinlock locking:

The existing spinlock code, used to protect SHAMapInnerNode child lists, has a mistake that can allow the same child to be repeatedly locked under some circumstances.
The bug was in the SpinBitLock::lock loop condition check and would result in the loop terminating early.
This commit fixes this and further simplifies the lock loop making the correctness of the code easier to verify without sacrificing performance.
It also promotes the spinlock class from an implementation detail to a more general purpose, easier to use lock class with clearer semantics. Two different lock types now allow developers to easily grab either a single spinlock from an a group of spinlocks (packed in an unsigned integer) or to
grab all of the spinlocks at once.
While this commit makes spinlocks more widely available to developers, they are rarely the best tool for the job. Use them judiciously and only after careful consideration.

High Level Overview of Change

Context of Change

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

I audited the std::memory_order* stuff the best I could using information I found on the web. It looks like what you've done aligns with the best practices that I found. That said, using anything other than memory_order_sequential makes me nervous since I've seen world renowned experts get this wrong.

Fwiw, I also reviewed this and will leave a similar comment.  I believe you have it right, not because I know what I'm doing, but because I've seen similar uses elsewhere.  This is tricky stuff.

I audited the std::memory_order* stuff the best I could using information I found on the web. It looks like what you've done aligns with the best practices that I found. That said, using anything other than memory_order_sequential makes me nervous since I've seen world renowned experts get this wrong.

Fwiw, I also reviewed this and will leave a similar comment. I believe you have it right, not because I know what I'm doing, but because I've seen similar uses elsewhere. This is tricky stuff.

I'm not a world-renowned expert in memory ordering (although I did read a lot, to try and get this right). I would normally agree with you but the intention here is to squeeze every last bit of performance out of the hardware and I think that the memory ordering will have a (likely small) impact to that.
@HowardHinnant, @scottschurr: who would be a renowned expert that we could ask to review this code?

Today I stumbled across this article on spinlocks from 2019:
https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/
2019 is recent enough that the information is probably still relevant.  That author appears to be knowledgable.  The timings seem useful and instructive.  Notice in particular the implementation of spinlock.  Personally, I like that implementation better than the one I suggested.
Just FYI.

I've tried but failed to get an outside review on the memory ordering.  I still believe it is correct.

Today I stumbled across this article on spinlocks from 2019:
https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/
2019 is recent enough that the information is probably still relevant. That author appears to be knowledgable. The timings seem useful and instructive. Notice in particular the implementation of spinlock. Personally, I like that implementation better than the one I suggested.
Just FYI.

Reading...

Today I stumbled across this article on spinlocks from 2019:
https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/
2019 is recent enough that the information is probably still relevant. That author appears to be knowledgable. The timings seem useful and instructive. Notice in particular the implementation of spinlock. Personally, I like that implementation better than the one I suggested.
Just FYI.

This was a great article. The biggest takeaway is that std::mutex is, at least on Linux, ridiculously good, which is something I found out with my own testing. HOWEVER, I feel the need to point out that the spinlocks here aren't meant to be general purpose locking primitives used instead or in lieu of std::mutex and other std-provided primitives. The latest version of the code documents this pretty clearly, I thought:

Packed spinlocks allow for tremendously space-efficient lock-sharding but they come at a cost.
First, the implementation is necessarily low-level and uses advanced features like memory ordering and highly platform-specific tricks to maximize performance. This imposes a significant and ongoing cost to developers.
Second, and perhaps most important, is that the packing of multiple spinlocks into a single integer, while efficient, can result in poor performance, as it may translate to additional cache-coherency traffic between processors and place heavy load on a processor's load/store units, potentially affecting performance.
To be sure, these locks can have advantages, but they are not general purpose locks and should not be thought or used as such. The use cases for such a construct are likely few and far between, and in the absence of a compelling reason to use it, it's probably best to stay away for spinlocks and use one of the standard locking primitives.

So yes, they are meant for very specific situations, with a good example being the packed_spinlock used by SHAMapInnerNode to provide 16 individual locks, one per child node, without taking up any space at runtime, since the locks fit inside the structure's padding. A single std::mutex would require increasing the size of every instance of the structure by 40 bytes and the equivalent construct with one std::mutex per node would need 160 bytes.
Beyond that, I should point out that my implementation does use the "test-and-test-and-set" mechanism described here (right down to using the right std::memory_order specifications!) although obviously I can't quite use the precise code since I want to allow for "packed" spinlocks.
Ultimately, if you feel strongly enough that this code should just be purely contained within SHAMapInnerNode and only used in that one place for that one very specific and niche case, I can do that.

FWIW, I wrote a smallish test to exercise packed_spinlock today.  It fires up some number of threads on my 6 core (with hyperthreading) machine.  All threads are contending for a single packed_spinlock.  As long as I limit the test to use at most seven threads it runs and shuts down fine (for ten attempts).
However when I use eight threads about half of the time the test hangs when it attempts to join the threads.  The hang suggests to me that this implementation of packed_spinlock is not ready for prime time.  But maybe I have an unrealistic expectation of a spin lock?
Ultimately I'd like to see this test (or something like it) run for 24 consecutive hours and shutdown with no problems before we call the packed_spinlock implementation adequately exercised.
The test is kind of big (and hacked together).  But I'm pasting it here for completeness sake.
int
spinlock_test()
{
    // We need something that gets messed up when it is torn, but is still
    // relatively easy to compute.  We'll use an array of 64 bools that
    // represent an unsigned 64-bit value.  That should get thoroughly hosed
    // if two threads cut loose in there at the same time.
    std::array<bool, 64> total{};

    // Each of the threads keeps track of how many times it has incremented
    // total.  If we sum these values we should  get the same value that is
    // represented by total.
    constexpr int threadCount = 8;
    std::array<std::uint64_t, threadCount> locals{};
    std::cout << "spinlock test with " << threadCount << " threads"<< std::endl;

    // Use stop to signal the threads to stop running.
    std::atomic<bool> stop = false;

    // Store the threads in a vector so they are easy to join.
    std::vector<std::thread> threads;
    threads.reserve(threadCount);

    // The lock that all of the threads will share.
    std::atomic<std::uint16_t> lock;

    // Start the threads.  Each thread has its own index.
    for (int localsIndex = 0; localsIndex < threadCount; ++localsIndex)
    {
        threads.emplace_back([&total, &locals, &lock, &stop, localsIndex] () {

            // The general usage model seems to be
            //  1. create the spinlock
            //  2. lock the spinlock
            //  3. release the spinlock
            //  4. destroy the spinlock
            //  5. repeat.
            // So we'll use that same model.
            while (!stop)
            {
                // Create and acquire the spinlock.
                static constexpr int lockIndex = 13;
                ripple::packed_spinlock sl(lock, lockIndex);
                std::lock_guard lock(sl);

                // Read out total and make sure it matches the sum of locals.
                std::uint64_t t = 0;
                for (unsigned int i = 0; i < total.size(); ++i)
                {
                    if (total[i])
                        t |= 1 << i;
                }

                std::uint64_t l = 0;
                for (std::uint64_t const& local : locals)
                    l += local;

                // Total and locals don't agree.  Probably a locking problem.
                if (t != l)
                {
                    stop = true;
                    std::cout << "Thread " << localsIndex
                        << " detects problem.  Total: " << t
                        << "; Locals: " << l << std::endl;
                }
                else
                {
                    // Advance our local and write out the new total.
                    locals[localsIndex] += 1;

                    ++t;
                    for (unsigned int i = 0; i < total.size(); ++i)
                        total[i] = (t & (1 << i)) != 0;
                }
                // Leaving scope releases the lock.
            }
        });
    }

    // Let the test run for some time and then kill it.
    using namespace std::chrono_literals;
    auto const stopTime = std::chrono::steady_clock::now() + 30s;

    while (!stop && std::chrono::steady_clock::now() < stopTime)
    {
        std::this_thread::sleep_for(1s);
    }
    stop = true;

    // Join all the threads.
    std::cout << "Joining threads" << std::endl;
    for (std::thread& thread : threads)
    {
        if (thread.joinable())
            thread.join();
    }

    std::uint64_t t = 0;
    for (unsigned int i = 0; i < total.size(); ++i)
    {
        if (total[i])
            t |= 1 << i;
    }

    std::uint64_t l = 0;
    for (std::uint64_t const& local : locals)
        l += local;

    std::cout << "Total: " << t
        << "; Locals: " << l << std::endl;

    return t == l ? 0 : 1;
}

Well, there was a bug in the test that I pasted above.  I had misremembered that an std::atomic<std::uint16_t> would initialize itself with the default value.  It doesn't.  Thankfully @nbougalis pointed that bug out to me.  With that fix, my test no longer fails joining with the proposed spinlock.
I understand that @nbougalis is running more extensive tests now.  Thanks!
There are a few other comments I have left on this pull request, and those still stand.  But the primary thing I was concerned about is now resolved.  Sorry for writing a buggy test, and thanks for figuring out the problem!

Looks like all of my comments have been addressed other than the naming issues.  For naming compatibility with this code base the new classes should probably be named PackedSpinlock and Spinlock.  And the new file should probably be named Spinlock.h.

Merged as 7e46f5342b7f1a574c2468ac05a834227898da7a


Redis cannot be found

After following installation instructions, I am getting the following in a symfony2 project...I don't have phpredis extension installed on my windows box
"Error: Class 'Redis' not found in ... app\cache\dev\appDevDebugProjectContainer.php line 673"
That line contains:
$this->services['doctrine.orm.default_redis_instance'] = $instance = new \Redis();
My composer.json contains:
"predis/predis": "0.8.x-dev",
"snc/redis-bundle": "1.1.*@dev",
config.yml contains
snc_redis:
clients:
default:
type: predis
alias: default
dsn: %cache.redis.dsn%
Is there something I'm missing or forgetting to do?
Thanks!
Nick

Did you install phpredis?

I think this issue should be closed. This issue is just a question how to use this bundle and the issue is very old.


[quak cli] slim down on conversions

Keep data type consistent with a Vec<u8>, which is what Request and Response expect to work with anyhow.

sweet, thanks!

Just noticed I'm incorrect from the wry docs:

F: Fn(WebViewId<'_>, Request<Vec<u8>>) -> Response<Cow<'static, [u8]>> + 'static,

Totally up to you style wise, no idea what performance impact there is, if any.


Strip placeholders and branding from forked repo

I've removed my fork and will work on my personal blog in a fresh repo (and of course credit your repo). Sorry again for the noise. I'll keep a fork only if I intend to make contributions back to yours.


Create a Potion object

Create tests for the Potion object.
The Potion object will be used to give the player stat boosts.
If no stat is provided, the stat should be randomly selected.

I've created a Potion object  and a test for the objects


scheduler: improve coscheduling's PostFilter if not collect enough

Ⅰ. Describe what this PR does
If the PreFilter of Coscheduling return UnschedulableAndUnresolvable since do not collect enough pods of a PodGroup, the PostFilter of Coscheduling will mark the schedule cycle invalid. But there is no need to do this, because once the Pods are collected enough, scheduling can be quickly performed instead of having to wait until the next cycle to actually start scheduling.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/lgtm


Feature/124 replace management client

Motivation
Which issue does this fix? Fixes #124
Checklist

[ ] Code follows coding conventions held in this repo
[ ] Automated tests have been added
[ ] Tests are passing
[ ] Docs have been updated (if applicable)
[ ] Temporary settings (e.g. variables used during development and testing) have been reverted to defaults

How to test
everything works as before

Looks good. 👍
Nice touch rewriting content management to management 👍
Let's just sync with @Kentico/developer-experience team according to argument renaming.

I've also changed the console arg "-c" to "-m", representing whether to use MAPI or DAPI. What do you think about that? Isn't it a too much of a breaking change?

Agree. We already have breaking changes in arguments names. It is not a big of a change for customers.


#1267 code formatted

Related Issue
Closes #1267

Description

Screenshots (if applicable)

Original
Updated

original screenshot
updated screenshot

Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

@rohansx please review and merge


Change travis to run with python3.5

Also add a bunch of tests to the test-passing Makefile rule as they pass
on python3.5

See the XXX comment right above the matrix line ;-)

Thank you for your quick reply, but I though you fixed that in https://github.com/ethereum/pyethereum/pull/749

Hi, is there any chance of modifying this PR to support Python3.6?


Add member_count to #get_guild method

It would be useful to have the #get_guild method in the Guild object. I noticed it was present in Discord::Gateway::GuildCreatePayload but I could not access it myself by changing the lib because I am not very familiar with the code base.
Thanks!

The https://discord.com/developers/docs/resources/guild#get-guild didn't use to include any kind of member count, so it was decided not to include it.
Now with all the Intent rework etc this is something we might want to revisit.
As for why member_count isn't cached: This is due to the matter of fact, that 99% of bots will not want/use this info.
If you wish to cache it, you can simply modify your Guild mapping like this: https://github.com/discordcr/discordcr/commit/9ef2bdce723dc927430aa71b1e5f9aed41b54c23
@z64 will have to comment if there are any longterm plans for this
If you wish to discuss this any further (in a more informal setting) feel free to join us in the Discord API server channel: https://discord.gg/puaxPkK

I don't quite follow what is being asked for - I'm not sure what such a method would do.
@greenbigfrog member_count should be added to Gateway::GuildCreatePayload. Otherwise, yes, it may be best to leave it out of Discord::Guild, which the library caches.

Apologies, my brain didn't quite parse the title of the issue. My above comment to gbf maybe suffices then. But I'm still not certain what you meant by #get_guild on Guild?

Nevermind, third times the charm. Correct, we can't add this to client.get_guild. Only the gateway event.

We can add it to get_guild though...

If with_counts is set to true, this endpoint will also return approximate_member_count and approximate_presence_count for the guild.
https://github.com/discord/discord-api-docs/pull/1528

We can add those fields, yes. But not member_count.

yeah that's what I meant sorry. approximate_member_count
On Thu, May 14, 2020 at 3:22 PM Zac Nowicki<EMAIL_ADDRESS>wrote:

We can add those fields, yes. But not member_count.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/discordcr/discordcr/issues/209#issuecomment-628631518,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMTREYONYDPH2BYVX23YEXDRRPWCTANCNFSM4NARPKQQ
.


Add dropdown list to input fields.

This feature is needed for auto formatting phone number input fields. In order to pick the right phone number pattern, user must select country.
Examples:

Semantic-UI Labeled Input field (domain version) - html structure inspiration (I'm up to better solutions if you have any)
2.  Most probably they will be changed in design process. Logic is the most important thing right now :)

I have worked on this issue
Can you help me where to add the code?

/src :)


[storage] Introduce Index

Related: #175 (Finalized Height <> Block index)

[x] Track which files changed since last sync and call sync on those rather than in put (also update Journal)
[x] Add index to put and infer section
[x] Ensure we handle case in Archive where last record is too short (even if key successfully read)
[x] How to prune ~IntervalTree~ (use rangemap)?
[ ] Update comments

@coderabbitai review


Deprecate EVP_PKEY_CTX_ctrl and related functions

Those functions purpose is to serve the legacy implementations and with #13913 they are completely replaceable with get/set params functions.
We need to deprecate them to be able to remove them when the legacy support code is removed.
It would be interesting to deprecate also the EVP_MD_CTX_ctrl and EVP_CIPHER_CTX_ctrl functions but we need to ensure that there are replacements that handle the legacy support correctly.

This also means the following TODOs about deprecating API functions that are tied to the EVP_PKEY_CTX_ctrl will be resolved as those functions should be also deprecated along with EVP_PKEY_CTX_ctrl().
/*
 * This one is currently implemented as an EVP_PKEY_CTX_ctrl() wrapper,
 * simply because that's easier.
 * TODO(3.0) Should this be deprecated?
 */
int EVP_PKEY_CTX_set_rsa_padding(EVP_PKEY_CTX *ctx, int pad_mode)

and
int EVP_PKEY_CTX_get_rsa_padding(EVP_PKEY_CTX *ctx, int *pad_mode)

and
int EVP_PKEY_CTX_set_rsa_pss_keygen_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_set_rsa_oaep_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_get_rsa_oaep_md(EVP_PKEY_CTX *ctx, const EVP_MD **md)

and
int EVP_PKEY_CTX_set_rsa_mgf1_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_set_rsa_pss_keygen_mgf1_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_get_rsa_mgf1_md(EVP_PKEY_CTX *ctx, const EVP_MD **md)

and
int EVP_PKEY_CTX_set_dh_nid(EVP_PKEY_CTX *ctx, int nid)

and
int EVP_PKEY_CTX_set_dh_kdf_type(EVP_PKEY_CTX *ctx, int kdf)

and
int EVP_PKEY_CTX_get_dh_kdf_type(EVP_PKEY_CTX *ctx)

and
int EVP_PKEY_CTX_set_dh_kdf_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_get_dh_kdf_md(EVP_PKEY_CTX *ctx, const EVP_MD **pmd)

and
int EVP_PKEY_CTX_set_dsa_paramgen_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_set_ecdh_kdf_md(EVP_PKEY_CTX *ctx, const EVP_MD *md)

and
int EVP_PKEY_CTX_get_ecdh_kdf_md(EVP_PKEY_CTX *ctx, const EVP_MD **pmd)

and
int EVP_PKEY_CTX_set_ec_paramgen_curve_nid(EVP_PKEY_CTX *ctx, int nid)

OTC: Not for 3.0

It seems like this is a must do in a near term minor release if we are to remove them (ostensibly in 4.0)

I am afraid it is too late to deprecate and remove them in 4.0.

I am afraid it is too late to deprecate and remove them in 4.0.

With an OTC vote it is.

Ok, then someone can open an issue for 5.0 if this is of interest


aarch64 support on Jetson TX1

The Jetson TX1 would make a pretty decent build server for aarch64, so I'm trying to get mine running under NixOS. I'm using this issue as an umbrella issue to track all of the known defects. I will update it as I encounter new issues or resolve old ones.
I'm using @dezgeg's aarch64 install image, found here:
https://www.cs.helsinki.fi/u/tmtynkky/sd-image-aarch64-linux.img
The board ships with an NVIDIA-modified version of u-boot. The Debian wiki suggests that you need to install mainline u-boot to boot Debian, but that does not appear to be a requirement for NixOS, though NixOS will work (more or less) with mainline u-boot as well. (See discussion below for pros/cons.) If you want to install Debian's U-Boot to the board, follow the procedure shown here: https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TX1
(When I originally posted this issue, I was using Debian's u-boot, but I am now using the NVIDIA u-boot from the NVIDIA L4T R24.2.1 release, as that seems to have the fewest issues. See below.)
Next, you must tell U-Boot how to find the DTBs that NixOS installs for this board. From the U-Boot prompt (interrupt the boot process to get there):
env set fdtfile "nvidia/tegra210-p2371-2180.dtb"
env save

Issues

[ ] nouveau driver fails
[x] xusb.bin firmware needed in initrd
[ ] Only 1 CPU is recognized

nouveau driver fails
If you use mainline u-boot on the Jetson TX1, the install image will attempt to load nouveau. On my board, this caused problems: https://gist.github.com/dhess/aee9edcdf672e6ddffb10bee7791a84c (Note that @dezgeg got it to work with the mainline 2017.07 version of u-boot on his board; see below.)
As a workaround, I manually blacklisted nouveau in /boot/extlinux/extlinux.conf in the install image, and added it to boot.blacklistedKernelModules in my final config.
(As @dezgeg notes in the thread below, with the stock NVIDIA u-boot, the kernel will not attempt to load the `nouveau' driver. I can confirm this works on my board as well.)
xusb.bin firmware needed in initrd
This has been fixed in the latest install image by @dezgeg.
Only 1 CPU is recognized
cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 38.40
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x1
CPU part        : 0xd07
CPU revision    : 1

This problem, too, is mentioned on the Debian wiki. This patch fixes the issue (I have now tested it and confirmed):
https://patchwork.ozlabs.org/patch/744215/
@dezgeg also discovered that if you use the stock NVIDIA u-boot from the NVIDIA L4T R24.2.1 release (version U-Boot 2015.07-rc2-g78c8468 (Nov 09 2016 - 19:39:36 -0800)) and set the following u-boot environment variables:
env set fdtfile "nvidia/tegra210-p2371-2180.dtb"
env set fdt_copy_node_names /cpus:/psci
env save

then all 4 CPUs are recognized without the need for the patch cited above. However, in my testing, this is the only NVIDIA u-boot version for which this works. Notably, the latest R28.1 u-boot does not appear to enable MP support without the cited patch.

For the xusb thing, I only now realized that the fix should be as simple as:
diff --git a/lib/systems/platforms.nix b/lib/systems/platforms.nix
index ae4fc355c7..54ed8f3c12 100644
--- a/lib/systems/platforms.nix
+++ b/lib/systems/platforms.nix
@@ -543,6 +543,10 @@ rec {

       # Cavium ThunderX stuff.
       PCI_HOST_THUNDER_ECAM y
+
+      # The default (=y) forces us to have the XHCI firmware available in initrd,
+      # which our initrd builder can't currently do easily.
+      USB_XHCI_TEGRA m
     '';
     uboot = null;
     kernelTarget = "Image";

I will try that out.

Ahh, good catch. It's much better than the hacks I needed to get initrd to include it!
I've made some progress on this. The system is stable, all 4 CPUs are usable with that dtb patch, and I'm using it as an aarch64 build server for NixOps deployments.
However, when I try to compile GHC and friends, the system becomes basically unusable (though not quite dead) and I start getting page allocation stalls:
Jul 27 20:56:05 heaviside kernel: systemd-journal: page allocation stalls for 13900ms, order:2, mode:0x17000c0(GFP_KERNEL_ACCOUNT|__GFP_
Jul 27 20:56:35 heaviside kernel: systemd-journal cpuset=/ mems_allowed=0
Jul 27 20:56:41 heaviside kernel: CPU: 0 PID: 527 Comm: systemd-journal Not tainted 4.12.0 #1-NixOS
Jul 27 20:56:42 heaviside kernel: Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
Jul 27 20:56:42 heaviside kernel: Call trace:
Jul 27 20:56:42 heaviside kernel: [<ffff00000808a168>] dump_backtrace+0x0/0x290
Jul 27 20:56:43 heaviside kernel: [<ffff00000808a4d4>] show_stack+0x24/0x30
Jul 27 20:56:43 heaviside kernel: [<ffff0000084abb28>] dump_stack+0x98/0xb8
Jul 27 20:56:43 heaviside kernel: [<ffff0000081f9548>] warn_alloc+0xe8/0x170
Jul 27 20:56:43 heaviside kernel: [<ffff0000081fa134>] __alloc_pages_nodemask+0xad4/0xe48
Jul 27 20:56:43 heaviside kernel: [<ffff0000080cdef4>] copy_process.isra.7.part.8+0x13c/0x15b8
Jul 27 20:56:43 heaviside kernel: [<ffff0000080cf50c>] _do_fork+0xbc/0x3e8
Jul 27 20:56:43 heaviside kernel: [<ffff0000080cf9ac>] SyS_clone+0x4c/0x60
Jul 27 20:56:43 heaviside kernel: [<ffff00000808378c>] __sys_trace_return+0x0/0x4
Jul 27 20:56:44 heaviside kernel: Mem-Info:
Jul 27 20:56:44 heaviside kernel: active_anon:699676 inactive_anon:140671 isolated_anon:102
                                   active_file:1023 inactive_file:877 isolated_file:0
                                   unevictable:0 dirty:6 writeback:22116 unstable:0
                                   slab_reclaimable:5131 slab_unreclaimable:7161
                                   mapped:1459 shmem:76 pagetables:2522 bounce:0
                                   free:15906 free_pcp:0 free_cma:3203
Jul 27 20:56:44 heaviside kernel: Node 0 active_anon:2798704kB inactive_anon:562684kB active_file:4092kB inactive_file:3508kB unevictabl
Jul 27 20:56:44 heaviside kernel: Node 0 DMA free:37848kB min:18976kB low:23720kB high:28464kB active_anon:1064840kB inactive_anon:37390
Jul 27 20:56:47 heaviside kernel: lowmem_reserve[]: 0 1982 1982
Jul 27 20:56:49 heaviside kernel: Node 0 Normal free:25776kB min:26076kB low:32592kB high:39108kB active_anon:1735004kB inactive_anon:18
Jul 27 20:56:50 heaviside kernel: lowmem_reserve[]: 0 0 0
Jul 27 20:56:50 heaviside kernel: Node 0 DMA: 74*4kB (UMEC) 53*8kB (UMEC) 50*16kB (UMEC) 50*32kB (UMEC) 27*64kB (UMEC) 23*128kB (UMEC) 1
Jul 27 20:56:50 heaviside kernel: Node 0 Normal: 153*4kB (UMEH) 144*8kB (UMEH) 146*16kB (UMEH) 107*32kB (UMEH) 45*64kB (UEH) 14*128kB (M
Jul 27 20:56:50 heaviside kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 27 20:56:50 heaviside kernel: 36554 total pagecache pages
Jul 27 20:56:50 heaviside kernel: 34514 pages in swap cache
Jul 27 20:56:51 heaviside kernel: Swap cache stats: add 409923, delete 375441, find 228513/239106
Jul 27 20:56:51 heaviside kernel: Free swap  = 542612kB
Jul 27 20:56:51 heaviside kernel: Total swap = 1048572kB
Jul 27 20:56:51 heaviside kernel: 917504 pages RAM
Jul 27 20:56:53 heaviside kernel: 0 pages HighMem/MovableOnly
Jul 27 20:56:53 heaviside kernel: 37867 pages reserved
Jul 27 20:56:53 heaviside kernel: 4096 pages cma reserved
Jul 27 20:56:53 heaviside kernel: top: page allocation stalls for 11316ms, order:0, mode:0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRAC
Jul 27 20:56:53 heaviside kernel: top cpuset=/ mems_allowed=0
Jul 27 20:56:54 heaviside kernel: CPU: 1 PID: 1954 Comm: top Not tainted 4.12.0 #1-NixOS
Jul 27 20:56:54 heaviside kernel: Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
Jul 27 20:56:54 heaviside kernel: Call trace:
Jul 27 20:56:55 heaviside kernel: [<ffff00000808a168>] dump_backtrace+0x0/0x290
Jul 27 20:56:55 heaviside kernel: [<ffff00000808a4d4>] show_stack+0x24/0x30
Jul 27 20:56:55 heaviside kernel: [<ffff0000084abb28>] dump_stack+0x98/0xb8
Jul 27 20:56:55 heaviside kernel: [<ffff0000081f9548>] warn_alloc+0xe8/0x170
Jul 27 20:56:55 heaviside kernel: [<ffff0000081fa134>] __alloc_pages_nodemask+0xad4/0xe48
Jul 27 20:56:55 heaviside kernel: [<ffff0000082560ac>] alloc_pages_current+0x9c/0x140
Jul 27 20:56:55 heaviside kernel: [<ffff00000825fa80>] new_slab+0x378/0x618
Jul 27 20:56:55 heaviside kernel: [<ffff000008261ff8>] ___slab_alloc+0x380/0x5c8
Jul 27 20:56:55 heaviside kernel: [<ffff000008262294>] __slab_alloc.isra.23+0x54/0x70
Jul 27 20:56:56 heaviside kernel: [<ffff000008263434>] kmem_cache_alloc+0x24c/0x280
Jul 27 20:56:56 heaviside kernel: [<ffff00000830518c>] proc_alloc_inode+0x24/0x50
Jul 27 20:56:56 heaviside kernel: [<ffff0000082a8e84>] alloc_inode+0x2c/0xb8
Jul 27 20:56:56 heaviside kernel: [<ffff0000082ab068>] new_inode_pseudo+0x20/0x60
Jul 27 20:56:56 heaviside kernel: [<ffff0000082ab0d0>] new_inode+0x28/0x48
Jul 27 20:56:57 heaviside kernel: [<ffff000008309854>] proc_pid_make_inode+0x2c/0xf0
Jul 27 20:56:57 heaviside kernel: [<ffff000008309a08>] proc_pident_instantiate+0x38/0xd0
Jul 27 20:56:57 heaviside kernel: [<ffff000008309b54>] proc_pident_lookup+0xb4/0x128
Jul 27 20:56:57 heaviside kernel: [<ffff000008309c90>] proc_tgid_base_lookup+0x38/0x48
Jul 27 20:56:57 heaviside kernel: [<ffff00000829afd8>] path_openat+0xe88/0xfe0
Jul 27 20:56:58 heaviside kernel: [<ffff00000829c374>] do_filp_open+0x6c/0xe8
Jul 27 20:56:59 heaviside kernel: [<ffff00000828774c>] do_sys_open+0x14c/0x220
Jul 27 20:56:59 heaviside kernel: [<ffff0000082878a4>] SyS_openat+0x3c/0x50
Jul 27 20:56:59 heaviside kernel: [<ffff000008083730>] el0_svc_naked+0x24/0x28
Jul 27 20:56:59 heaviside kernel: Mem-Info:
Jul 27 20:56:59 heaviside kernel: active_anon:700406 inactive_anon:140700 isolated_anon:32
                                   active_file:1534 inactive_file:1904 isolated_file:0
                                   unevictable:0 dirty:40 writeback:21244 unstable:0
                                   slab_reclaimable:5044 slab_unreclaimable:7193
                                   mapped:2754 shmem:77 pagetables:2613 bounce:0
                                   free:13801 free_pcp:0 free_cma:3203
Jul 27 20:56:59 heaviside kernel: Node 0 active_anon:2801624kB inactive_anon:562800kB active_file:6136kB inactive_file:7616kB unevictabl
Jul 27 20:56:59 heaviside kernel: Node 0 DMA free:29720kB min:18976kB low:23720kB high:28464kB active_anon:1015108kB inactive_anon:42337
Jul 27 20:56:59 heaviside kernel: lowmem_reserve[]: 0 1982 1982
Jul 27 20:56:59 heaviside kernel: Node 0 Normal free:25484kB min:26076kB low:32592kB high:39108kB active_anon:1786608kB inactive_anon:13
Jul 27 20:56:59 heaviside kernel: lowmem_reserve[]: 0 0 0
Jul 27 20:56:59 heaviside kernel: Node 0 DMA: 61*4kB (UMEC) 37*8kB (UMEC) 42*16kB (UMEC) 35*32kB (UMEC) 13*64kB (UMEC) 3*128kB (UEC) 3*2
Jul 27 20:56:59 heaviside kernel: Node 0 Normal: 171*4kB (UMEH) 162*8kB (UEH) 142*16kB (UMEH) 97*32kB (UMEH) 45*64kB (UMEH) 12*128kB (UE
Jul 27 20:56:59 heaviside kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
Jul 27 20:56:59 heaviside kernel: 28079 total pagecache pages
Jul 27 20:56:59 heaviside kernel: 24538 pages in swap cache
Jul 27 20:56:59 heaviside kernel: Swap cache stats: add 441834, delete 417331, find 228544/239159
Jul 27 20:56:59 heaviside kernel: Free swap  = 415124kB
Jul 27 20:56:59 heaviside kernel: Total swap = 1048572kB
Jul 27 20:56:59 heaviside kernel: 917504 pages RAM
Jul 27 20:56:59 heaviside kernel: 0 pages HighMem/MovableOnly
Jul 27 20:56:59 heaviside kernel: 37867 pages reserved
Jul 27 20:56:59 heaviside kernel: 4096 pages cma reserved

This does not appear to be a commonly-reported error on this hardware, but not many people are running a mainline kernel on it, either. I have only tried Linux 4.12 so far, so it's possible that an earlier kernel will not have this issue.
I think my next step will be to create a derivation to build the official NVIDIA Linux 4.4 kernel. Besides hopefully fixing this allocation issue, there are a bunch of important features missing from the mainline kernel for this hardware, like power management, fan settings, CPU and memory speed settings, etc. (not to mention all the GPU stuff).
Most of the changes I've made so far are pretty hacky and not yet ready for a pull request, but one thing that was straightforward and should be clean enough to merge is the u-boot support I added for Jetson TX1 and Jetson TX2. Are you interested in that?
(BTW, I now have a Jetson TX2, as well. It cannot currently boot NixOS at all. Using the aarch64 installer image, it hangs after udev is activated. When I try to boot the SD card that I'm using in my TX1, it can't even mount rootfs and keeps generating LVM read errors over and over. I haven't had time to look into that yet as I'm concentrating on making the TX1 completely stable first.)

I pushed the XUSB patch which solved the problem as expected.
I can't reproduce the nouveau problem on the unit I managed to borrow. On the stock U-Boot (U-Boot 2015.07-rc2-g78c8468 (Nov 09 2016 - 19:39:36 -0800)) nouveau doesn't even attempt to probe and on a mainline one (2017.07) it probes and I do get a /dev/dri/renderD128.
BTW the stock U-Boot boots fine with multiprocessor support when the following is done (from http://elinux.org/Jetson/TX1_Upstream_Kernel):
Tegra210 (P2371-2180) # setenv fdtfile "nvidia/tegra210-p2371-2180.dtb"
Tegra210 (P2371-2180) # setenv fdt_copy_node_names /cpus:/psci

I'll flash the stock U-boot again and see if that fixes either of those problems. I've been running mainline U-boot on this TX1 since I got it.

Which kernel are you using with the TX1?

Never mind about the kernel version, I booted from your new install image using the latest NVIDIA u-boot ().
You're right that the nouveau problem doesn't manifest with the NVIDIA u-boot, and the xusb.bin problem is resolved with your new install image. On my board, at least, I still don't get MP support with the fdtfile and fdt_copy_node_names settings:
[    0.000000] /cpus/cpu@1: missing enable-method property
[    0.000000] /cpus/cpu@2: missing enable-method property
[    0.000000] /cpus/cpu@3: missing enable-method property

See https://gist.github.com/dhess/74d8304344f5ef218b2d0ad950b08a3d for the full bring-up log, including where I interrupted the boot to print the values of those u-boot environment variables.
I guess I'll try an older NVIDIA u-boot.

Wow, I didn't think it would work, but flashing the same u-boot that you're using (U-Boot 2015.07-rc2-g78c8468 (Nov 09 2016 - 19:39:36 -0800)) and setting those u-boot environment variables does work for me as well; I can see all 4 CPUs using your new install image!
That seems awfully fragile, though. I suspect that if you try a different NVIDIA u-boot that you will not see all 4 CPUs. I tried the L4T R23.1.1 release, and the L4T R28.1 release, and activates all 4 CPUs. Only the R24.2.1 u-boot did.

@dezgeg BTW, since you seem to have a working system, what happens when you try to nixos-install to the eMMC?
I'm getting some very strange behavior when I do that. During the copy stage, the copy is completed, but then this happens:
...
  /nix/store/mvwl4g8qfplcypjqv16hqs8vmr4h90cl-acl-2.2.52...
  /nix/store/ndkhnl1v8ni2gg1gi5bdrhdzrqph0zp8-libatomic_ops-7.6.0...
  /nix/store/nhbd93khxhs1jvsl3cl6ib3s87ym24sy-zlib-1.2.11...
  /nix/store/ql68w5gna1d2v1vk8g745238q9wmzwa0-attr-2.4.47...
  /nix/store/s67ds1ak32p99q080wiqj5p9yzwyl7jg-gcc-5.4.0-lib...
  /nix/store/xzvcrw7iyg9cn30qnh0vmlhbf5akzicw-perl-WWW-Curl-4.17...
  /nix/store/y2k0iya6880yrp6ldb8ir9hzg5lzd659-nix-1.11.13...
  /nix/store/yvzr105f2g3yasaymmj3ssa18jb00vdl-xz-5.2.3-bin...
  /nix/store/yz3x5585pc1rrqcyk3x59ls7hy7z09hm-curl-7.54.1...
error: changing modification time of ‘/nix/store/0qpk3lf0nwbk2ixy33sw0pg9msfa7ywv-perl-DBD-SQLite-1.50’: Read-only file system

I have no idea why this is happening. Everything works fine when I nixos-install to the SD card.

The install image generator seems to put bad timestamps to the image. I've fixed that now (1d72474df7fa361d72a04d2a3ec4589b286ab6f2, didn't upload a new image though) but I suppose this can be used to repair an existing system:
mount -o remount,rw /nix/store
find /nix/store/ -printf '%T@ %p\n' | grep -v '^1\.0' | cut -d' ' -f2- | xargs touch -c -h -d @1
reboot

Your fix for /nix/store on the existing image worked great, thanks!

Indeed fdt_copy_node_names doesn't seem to exist on the latest U-Boot environment and it's also ripped out from the sources, so that can't be relied on.
So indeed it could be best to package the U-Boots in nixpkgs.

@dhess, did you make a follow up issue regarding the TX2? If not, did you ever get it booting on NixOS?

@Wulfsa Sorry, it's been so long since I opened this issue, or used any Jetson hardware, that I don't recall. Based on my git logs for my NixOS configuration repo, it doesn't appear so.


Add rules

Wanted a way to be able to add more rules to the base list of rules. Using this to create a "theme" for a site without adding the same rules for every element that needs them. Adheres to the atomic idea as their specificity would be 0, 0, 1, 0 and can easily be overridden.
Added some globals for ESlint so it doesn't complain and removed an option in the README.md which would never work in practice.
Thank you.

It looks like a good idea.  I'm reviewing it.

Okay, so after reviewing all I can say is that I'm very impressed.  I couldn't find the documentation for acss.addRules() but I looked at the source code and it looks very useful indeed.  Did you just somehow know about it or did I just miss it in the docs?
I know that the version on NPM was broken but I'm going to bump the major version number just to be safe.


Repeatedly calling mute/unmute will update the muted state of the call locally, but other participants on the call do not see the same muted state of the remote participant

Package Name: @azure/communication-calling
Package Version: 1.23.2-beta.1
Operating system: MacOS
[ ] nodejs

version:

[x] browser

name/version: chrome/124.0.6367.62

[ ] typescript

version:

Is the bug related to documentation in

[ ] README.md
[ ] source code documentation
[ ] SDK API docs on https://docs.microsoft.com

Describe the bug
When the mute/unmute SDK operations are repeatedly invoked enough to trigger throttling, the isMuted field on the call is still updated. The other participant(s) on the call no longer see the correct muted state of the user. This can result in a situation where the local user believes they are muted but the other participant(s) on the call can still hear them.
To Reproduce

Start a call (either 1:1 or 1:N)
Repeatedly mute/unmute the local user (more than 15 times in a 30 second window) to trigger a 429 - Too Many Requests error

Expected behavior
The isMuted state of the call matches the isMuted state of the user seen by the other participant(s) on the call. The isMutedChanged event is only raised when the local user is actually muted or unmuted for the other participant(s) on the call (meaning other participants on the call can either no longer hear them or hear them).
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context

There is a 429 (Too Many Requests) error seen in the console, but this error is not thrown by the mute/unmute functions. There is no way for consumers to capture this error and decision on it
The isMutedChanged event is raised even though the call to mute/unmute was throttled
This call id had the out of sync muted state when the call ended

0c16b95f-62ad-4c56-9c52-c844a6fdd9b7

hi @christopher-tobin-pwc there's a logic on the service that will throttle subsequent requests to mute/unmute and result in a local mute state of a remote participant to be out of sync with actual state of mute.
Currently thresholds are set around 20 actions in 30s sliding window - which in usual scenarios - should enable proper functioning
and given that we'd consider this as a desired behavior - we will document this better.
Can you please explain your scenario - is this part of your app logic to mute/unmute participant that often?
If this was purely testing exercise - I would like to consider this as "by design" and propose to close this ticket

hi @christopher-tobin-pwc there's a logic on the service that will throttle subsequent requests to mute/unmute and result in a local mute state of a remote participant to be out of sync with actual state of mute. Currently thresholds are set around 20 actions in 30s sliding window - which in usual scenarios - should enable proper functioning and given that we'd consider this as a desired behavior - we will document this better. Can you please explain your scenario - is this part of your app logic to mute/unmute participant that often? If this was purely testing exercise - I would like to consider this as "by design" and propose to close this ticket

This was uncovered during testing so this would not be something that would occur during normal operation of the application.
However, I would still expect the local state of the call to reflect correctly if the user ends up getting throttled. As is, this is very confusing for the local user if they end up in this state


Error finishing download on the built version on the launcher

It works inside visual studio but when i build it then try i get this error

Well considering it can't find the file, check all your file paths? Make sure they are all correct even when you build it, although I'm really not sure why it would work in Visual Studio but not as a build—especially if you haven't made any of your own changes/additions to the code...
Assuming you followed along with the tutorial, you could also try downloading the entire project from GitHub and running that (don't forget to change file paths and download links). I'm not sure if a difference in the code would produce the behavior you're seeing, but it might still be good to rule out.

I found that it works when I run it as an administrator, the reason why It only works when I run it as administrator is because ive put the launcher in the ProgramFiles folder. I'll just make it run as administrator by defualt. Thanks for reply though the tutorial was very useful.


Dealing with PPG in GRIFFIN

@VinzenzBildstein and I were discussing how to best handle the PPG in GRIFFIN. After some deliberation we decided that perhaps the best thing to do is to discard the PPG at the fragment->analysis step. Instead of writing the PPG to every hit (which would be the proper thing to do), we would instead use this step to determine the length of time of the different components of the cycle. This would be written to the Run info for that run, and could be modified by hand if needed. This could in fact lead to scripts that allow us to analyse how our PPG is behaving, and find even more precise cycle times. Having the PPG in TGriffin will not work if our rates get high enough to cause our analysis tree entries to become very large.
We would then be able to figure out what stage of a cycle we are in by checking the hit timestamp % cycle length against the run info. This would of course assume that the length of every cycle is the same, but if they are not, we have bigger fish to fry. I waned to check this over with @pcbend because I know you've thought about this a bunch and I was wondering if you can think of a problem with this method. I think we have to come up with a new method from what we currently have, and this seems like the best option to me.

bump?

Related information: there has been some discussion of including a PPG event outside of the GRF2 events. I don't think this is going to happen before the next experiment, but it's on the "desired firmware developments" list.

Ok, we just have to also make sure that it isn’t one of our infamous dropped events if we go this route.

On Jun 24, 2015, at 2:51 PM, SmithJK<EMAIL_ADDRESS>wrote:
Related information: there has been some discussion of including a PPG event outside of the GRF2 events. I don't think this is going to happen before the next experiment, but it's on the "desired firmware developments" list.
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/355#issuecomment-114978959.

There is also a static member in there called fLastPPG. I would prefer to handle this without a static member as I am planning on writing an example selector for the analysis tree. With the way we have grouped out analysis tree entries, it makes sense to create a selector to use with PROOF. This will allow very fast scripting with TChains of entire runs. I think static data members might make this impossible.

Update on PPG pattern (currently being implemented/bug-tested):

There will be a PPG event in the GRF2 bank every time the PPG changes. Due to data latency, this event should make it into the data stream well before any of the events coming from after this PPG change.
The event will have 6 words. The first will be a header (0x8 identifier) with the DataType set to 3 (GRIF-C identifier) and the channel address will be 0xFFFF. The second word will have an identifier of 0x9 followed by 28 bits containing the old PPG pattern. The third word will have an identifier of 0xa followed by 28 bits containing the new PPG pattern. The fourth word will have an identifier of 0xb and contain the 28 low bits of the timestamp. The fifth word is a network packet ID. The sixth is a trailer (0x9 identifier) with 28 bits containing the old PPG pattern, to check for data corruption.

Just out of curiosity, what tests have been done with this PPG? Does it consistently make it to disk?

On Aug 5, 2015, at 6:48 PM, SmithJK<EMAIL_ADDRESS>wrote:
Update on PPG pattern (currently being implemented/bug-tested):
There will be a PPG event in the GRF2 bank every time the PPG changes. Due to data latency, this event should make it into the data stream well before any of the events coming from after this PPG change.
The event will have 6 words. The first will be a header (0x8 identifier) with the DataType set to 3 (GRIF-C identifier) and the channel address will be 0xFFFF. The second word will have an identifier of 0x9 followed by 28 bits containing the old PPG pattern. The third word will have an identifier of 0xa followed by 28 bits containing the new PPG pattern. The fourth word will have an identifier of 0xb and contain the 28 low bits of the timestamp. The fifth word is a network packet ID. The sixth is a trailer (0x9 identifier) with 28 bits containing the old PPG pattern, to check for data corruption.
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/355#issuecomment-128173619.

We ran a test where all the data cables were disconnected and basically the only items we got were the PPG events, so it... let's say "regularly" makes it to MIDAS. We have not done thorough tests to ensure that none of these are being dropped.
Additionally, I think we're going to also include the high timestamp bits.

The high time stamp is a good idea. Once this is in, let me know and I will add it to the data parser. Does this remove the ppg word from a standard fragment?
As I see it, we now have four options for building events in the code.

We can keep track of the last timestamped ppg and write that ppg to each hit.
We can keep track of the last timestamped ppg and write that to each mother class.
We can keep track of the last timestamped ppg and write that to the GRIFFIN mother class.
We can create a PPG branch that gets written along side the other TGRSIDetectors.

I don’t like options 1 or 2 as they seem like overkill.
Options 3 and 4 are my personal favourites. However, I find option 4 particularly interesting. The reason is that, although I am not certain, I would assume that the data in a mother PPG would be compressed very well. Also, drawing events in a certain PPG window would be very easy, and fast, as it would just have to look at a condition of the PPG branch. It would take a bit of retooling on the event building side, but we could just force the code to write a copy of the last PPG instance in the newest entry.

On Aug 5, 2015, at 7:24 PM, SmithJK<EMAIL_ADDRESS>wrote:
We ran a test where all the data cables were disconnected and basically the only items we got were the PPG events, so it... let's say "regularly" makes it to MIDAS. We have not done thorough tests to ensure that none of these are being dropped.
Additionally, I think we're going to also include the high timestamp bits.
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/355#issuecomment-128182575.

The PPG pattern is part of the Master Filter word, so that word won't disappear. I don't know if the PPG pattern will disappear from that word though.
"We can keep track of the last timestamped PPG": There will be some latency after reading the PPG pattern (on the order of microseconds), during which the GRIFFIN events being written to disk will still belong to the previous PPG pattern. So we'd probably need to keep track of two PPG patterns: the "current" and "previous". Perhaps more if the cycle times are short. This may be obvious, but I thought I'd clarify anyway.
@r3dunlop, are you listing options for writing the PPG to the fragment file or to the analysis file?
More on potential effects of dropping this word: We've dropped the percentage of events that are dropped to ~3% on rates up to ~50 kHz. The network loss is currently steady at 0.7%. Chris is also investigating the non-standard PPG cycle length (0.8% longer than expected, see https://elog.triumf.ca/Tigress/GRIFFIN/3021) and thinks that might be correctable. If we drop a PPG event, I think the worst case scenario is that we have to drop that cycle. However, even with the 0.8% difference, the cycle lengths are stable, so there's a good chance you could recover the data.

In the 8pi, we never used CAMAC events in order to rebuild cycles. We trusted the controller to use the proper time. In my opinion, the PPG word is for trust in something we don't trust yet, and makes the analysis easier. We should never throw out cycles based on missing the word. This could get bad when you consider experiments where a cycle might last an hour or so.
My above suggestions were for the analysis tree. I would assume that we would make the PPG fit into the fragment tree in a fragment. Some of the data members may be empty, or not strictly correct, but I think it would work fine. The data would then become time-ordered (however we plan on doing that), so is latency a real issue here? I agree keeping both the previous and current and making a check against both can't hurt though.

Ah, good. My concerns about latency were principally for the fragment file. If we're time-ordered, I agree that it shouldn't matter.
As is, the PPG pattern that's being read into the fragment is quite close to what the word should be, so I'm satisfied with using that in the FragmentTree - it would allow for some quick, rough checks.
As for the best way to incorporate this, what will a user be doing with the PPG event contents? The contents will be used to identify the type of cycle the event was collected during, and to calculate the cycle time. Is there a situation where one might want to enumerate the cycles within a run and pull that information out? Obviously, putting these values in every hit is the brute force method for doing this, and I agree with Ryan that it seems a bit like overkill. Whichever solution we choose though, should enable the easy extraction of the information we can predict that the user will want.
I'm also intrigued by the 4th suggestion. What would the extraction of cycle time look like once this was implemented?

It would be trivial in an analysis script.
TGriffin *grif;
TPPG *ppg;
//Set up branches like usual.....
Tree->SetBranchAddress.....

for(int i =0; i < Tree->GetEntries();++i){
  Tree->GetEntry(i);
  cycletime = grif->GetHit(i)->GetTime() - ppg->GetTime();
  //do stuff with cycle time
  gammaCyc->Fill(grif->GetHit(i)->GetEnergy(), cycletime);
}

In a draw command I think it would be very similar
Tree->Draw("griffin_hits.GetTime() - ppg.GetTime()") or something? I always mess up the cross branch draw commands.

So in this case, the PPG branch would have an entry for every event that has the PPG identifier and the timestamp of the beginning of that cycle. I can see how that would work. I like it.
What happens though, if the PPG switches during a constructed event?

These are decisions we are always going to have to make, even if we write the PPG on a hit-by-hit basis. At what part of the cycle did that gamma-gamma event occur at? However, I agree that this could muddle things up at the microsecond level. We do have free bits in the TGRSIDetectorHits right now that we can store this information. This might just be the place to put it. It won’t take up any more space than the data currently takes up. Having thought more about it, I think we are going to be measuring quite a few nuclei with tens of microsecond lifetimes as we push to the neutron rich side…

On Aug 5, 2015, at 8:46 PM, SmithJK<EMAIL_ADDRESS>wrote:
So in this case, the PPG branch would have an entry for every event that has the PPG identifier and the timestamp of the beginning of that cycle. I can see how that would work. I like it.
What happens though, if the PPG switches during a constructed event?
—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/355#issuecomment-128195879.

I have decided that I would like to write the PPG to each hit. We have the room to do so. @SmithJK let me know if data with this PPG event is available so I can have it ready for the next experiment.

Should be available later today or early tomorrow, in some calibration data. I'll let you know when it happens. Or you can just watch the ELog.

Data is available. Run 4370 has data with PPG transitions in it. Slightly modified format and example events detailed in the ELog.

Also, looks like DataType is actually set to 4...

Ok. I will try to get this in this evening. I think it's more crucial...and doable... before the next experiment than anything else I am currently working on.

I came up with an idea, but I think it only works well if we are spitting out this PPG event. When we get a PPG event, I create a new Object which gets written to the file called PPG. This PPG contains a set of numbers (PPG status vs time). Then when one wants the ppg, they ask TGRSIDetectorHit::GetPPG() which queries the ppg object and calls a static function PPG::GetStatus(time), which returns the last PPG that occurred given the time argument.
This has a few benefits:

we can look at the whole spectrum(?) of ppg statuses very easily and see if it is behaving properly. We can even write functions that see if we are missing PPG words, or find the average cycle length etc.
This PPG information is independent of detector system.
It's small.
Latency is not an issue
Even if we want to write the PPG to the hit, using this method makes it easy to do so.
There doesn't need to be a place for the ppg in non-griffin data
It's easy.
I am working on this today + my flight, so if you see a potential pitfall please let me know! I really like the encapsulation of the PPG and I definitely think it will help during these debugging days of GRIFFIN.


Fix some broken links

We run the link checker nightly rather than on every PR these days because of too many false positives, ie. when checking links, those often time out or are unreachable temporarily.


Explore Your Generated OData Service

Tutorial URL: https://developers.sap.com/tutorials/odata-07-explore-generated-odata-service.html
Please specify the step you are referring to 4
it still takes multiple tries to build, run, and restart the service before it can be properly delivered through the web into the browser. a little hint to the student wouldn't hurt.

just a comment.

@qmacro FYI


Convert GitHub event on actions and fix some pull_request events.

Follow #22680
Partially Fix #22958, on pull_request, opened, reopened, synchronize supported, edited hasn't been supported yet because Gitea doesn't trigger that events.

@KN4CK3R done.

CI fail is related.

Codecov Report

Merging #23037 (ffa3571) into main (d56bb74) will increase coverage by 47.09%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff            @@
##           main   #23037       +/-   ##
=========================================
+ Coverage      0   47.09%   +47.09%
=========================================
  Files         0     1154     +1154
  Lines         0   152178   +152178
=========================================
+ Hits          0    71666    +71666
- Misses        0    72037    +72037
- Partials      0     8475     +8475

Impacted Files
Coverage Δ

modules/actions/github.go
0.00% <0.00%> (ø)

modules/actions/workflows.go
0.00% <0.00%> (ø)

... and 1152 files with indirect coverage changes
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Maya: Reduce amount of code for Collect Looks

Changelog Description

Refactor get_file_node_files because popping from paths by index should have been done in reversed order anyway. It's now changed to not need popping at all.
Removed unused RENDERER_NODE_TYPES and if-branch which collected node_attrs list which was unused + collected members which was also done outside of the if branch and thus generated no extra data.
Collected all materials from look set attributes at once instead of multiple queries
Collected all file nodes in history from a single query instead of per type
Restructured assignment of instance.data["resources"] to be more readable
Cached PXR_NODES only ones (Note: plugin load is checked on discovery of the collect look plugin) instead of querying plugin load and its nodes per file node per attribute
Removed some debug logs or combined some messages

Additional info
Also mentioned on Discord here
Testing notes:
Preferably publish looks with different file node types (e.g. file and aiImage with and without UDIMs or sequences) for each renderer type:

Publish looks

[x] arnold (mtoa)
[x] redshift
[ ] renderman
[x] v-ray

Ensure look assignments still work as intended

[x] shader assignments
[x] render stat attributes on meshes
[x] (Redshift) mesh parameters object sets, etc.

All tested and functional!
*missing test for Renderman which I m missing license for. Will resolve asap.

@LiborBatek did you manage to get a Renderman license?

@BigRoy could you resolve the conflict?


feat: allow to configure file dictionary path

Adds fileDictPath configuration, akin to userDictPath.
The implementation and documentation mirror the existing implementation of userDictPath, and hence only make the smallest set of changes required to provide a configurable file dictionary path.

We might have to revisit this once I start work on #147, but it looks great as is!


fix: correct CKBRPC.createBatchRequest() types

Description
This PR aims to correct CKBRPC.createBatchRequest() types.
// Before
createBatchRequest: <N extends keyof Base, P extends (string | number | object)[], R = any[]>(params?: any) => any;

// After
createBatchRequest: <N extends keyof Base, P extends (string | number | object)[], R = any[]>(params?: [method: N, ...rest: P][]) => [method: N, ...rest: P][] & {
    add: (n: N, ...p: P) => [method: N, ...rest: P][];
    remove: (index: number) => [method: N, ...rest: P][];
    exec: () => Promise<R>;
};

Magic number 30000 is used in CKBRPC, which blocks commits.
I have to add a rule in .eslintrc.next.js to commit code.
Type of change

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

How Has This Been Tested?
$ npx pnpm build
$ npx pnpm test

Hi, can you add a changeset for @ckb-lumos/rpc for this PR?
npx changeset add

Added.


Badge Support

Is your feature request related to a problem?
I'm trying to add a Generated badge to my API docs section, and it doesn't seem to work. (Using the spread operator):
sidebars: [
  {
    ...typeDocSidebarGroup,
    badge: {
      text: 'Generated',
      variant: 'note',
    },
  },
  // ...
]

Describe the solution you'd like
An option within StarlightTypeDocOptions with the badge parameters from @astrojs/starlight would be nice. (like being able to set the sidebar as collapsed)

Would hopefully look like this:

Describe alternatives you've considered
No response
Additional Context
No response

Thanks for your report :raised_hands:
I just released v0.12.1 which includes a fix for this issue.
Using the syntax from your first code block will now work as expected:


set toggle

what is this feature?

It saves your map toggle button states into the user attributes, so when you refresh the page, they are persisted.

Great feature !!!
...and the button just to the left with position mark?
THANKS

Save map position and zoom.

Very good too !!
By the way ... if it could be to give the map buttons a gray shading with more contrast (using a smart phone is very difficult to differentiate between both states)
THANKS

Hopefully Sencha fixes it in one of the next themes.

I just saw that it is not by the contrast of the gray ... to 3 of those buttons they lack the cross bar on the icon

There is no crossed out icons for other buttons, so it's not an option.


test: replace check string

Proposed changes
The registration e2e tests sometimes fail. The issue is because of the way that we check if the test succeeded, and not because the test does not really succeed. We are checking the logs of the agent. However, if the execution reaches a degenerate round, then it starts looping and logging very fast the same exception. This results in the test not detecting the expected logs - probably because of a buffer filling - even though they have been logged, and falsely reporting the e2e test to have failed.
Therefore, we replace the check string with another one that happens a bit before reaching the degenerate round but still ensures that the test has succeeded.
However, this solution does not guarantee that the e2e test will not falsely report a failure again but decreases the chances.
Two more appropriate solutions would be to:

Decrease the interval of checking the logs.
Raise and stop the execution when a degenerate round is reached instead of looping.

Fixes
n/a
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[ ] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have locally run services that could be impacted and they do not present failures derived from my changes

Further comments
n/a

Two more appropriate solutions would be to:
1. Decrease the interval of checking the logs.

2. Raise and stop the execution when a degenerate round is reached instead of looping.

in case of "stop the execution", we would need to make sure that any "catch up" test does not rely on the other agents being present (as in registration with ACN is the case). Since the degenerate round is always an end state from which agents do not recover (to the best of my understanding), we could implement a mechanism for them to "slumber" and report less frequently. We could also consider a test-specific degenerate round, but I am not sure this is needed or even desirable. I think opening a ticket on this may be warranted.

Opened #1121.


f as first argument of print() leads to unwanted file content

Lines look like this:
<_io.TextIOWrapper name='./triletter_dict.txt' mode='w' encoding='UTF-8'> isf 3251
After the change:
isf 3251

@zenogantner thanks for your contribution! We'll review the code asap :)
Besides, the current master branch will be completely replaced by matchzoo 2.0 once it's ready (in 2 months). If you're interested, feel free to checkout to 2.0 branch and take a look!
Best!

@zenogantner can you clarify a little bit on why do you think we shouldn't print the file?

Hello @bwanglzu, see my first comment: Before my change, there were 3 columns in the created file, where the first column was the string representation of the wrapper object -- this is not the information you want to store in the file.

@zenogantner thanks. @faneshion please take a look on this one.


ProgressBar is not shown

Problem description
The ProgressBar is not displayed on the screen at all. The issue only occurs on iOS.
Environment

Tabris.js version: 3.0.1
Device: iPhone 6
OS: 12.2

Code snippet
const { Composite, ProgressBar, contentView } = require('tabris');

let composite = new Composite({ left: 0, top: 0, right: 0, bottom: 0 });

composite.append(
  new ProgressBar({
    left: 0, right: 0, bottom: 100,
    selection: 30,
    tintColor: 'green',
    background: 'red'
  })
);

composite.appendTo(contentView);

The issue is fixed on master.


Turn Loop into full-fledged data structure

It's a great way to handle ordered data, but it can be a pain in the butt to deal with. Promoting this to a full-fledged data structure would be really nice, either through exported functions or a class-based implementation.

We removed loop.


Consider switching to universal devcontainers image

This is the default image for GitHub Codespaces if none is specified:
"image": "mcr.microsoft.com/devcontainers/universal:linux",

It adds no storage cost, unlike other images, and already has Python installed.
It seems to launch quickly for me, which is presumably because it's cached. Maybe that's no advantage if prebuilds are used.
The research template only uses a Python-specific image because that's what seemed sensible, when I first configured it through VSCode.

One downside of this is that the version of the image or of Python can't be pinned. Whereas with the Python image, you can require 3.11.
This has two benefits:

we don't get out of sync of versions of Python that run the OpenSAFELY CLI without realising (say the image upgrades to Python 3.12)
there's a more definite image version to upgrade, because going from a 3.11 to 3.12 image will eventually ensure that any Docker image gets upgraded

I expect we'll want to install python 3.10, like version 2 of the python action image. So, I think anything that doesn't allow us to specify that exact version will not be a good idea.
We'll also probably want to install the relevant python (and maybe R packages, see https://github.com/opensafely-core/codespaces-initiative/issues/9) into the image, rather than install them at start up, so I expect we'll want to have a custom Dockerfile.
I'm going to close this issue for now, but if I've missed anything please comment or reopen it.


feat(Sleek): Adds Eldritch scheme

Adds the Eldritch scheme to Sleek theme 😄
https://github.com/eldritch-theme/eldritch

@harbassan This github action seems to be failing? anything I can do? it looks like it was going to assign it to you based on the actions logs

might add this theme to dribbblish if i have time, nice theme you made!

nice scheme!

might add this theme to dribbblish if i have time, nice theme you made!

if you do feel free to add the instructions to my repo https://github.com/eldritch-theme/spicetify


Merging keyvault preview back to dev for release.

This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[ ] I adhere to the Command Guidelines.

@tjprescott I've made the requested updates PTAL

Closed since the changes have been included in https://github.com/Azure/azure-cli/pull/6702#issuecomment-403101028


bump: [#4684] Replace nanoid with native module crypto

Addresses #4684
#minor
Description
This PR replaces the micro-library nanoid with the native module crypto to generate a random ID. Nanoid can't be upgraded as, in its latest version, it is an ESM-only package.
Specific Changes

Updated botbuilder-test-utils/jwt.ts replacing the use of nanoid with crypto.

Testing
The following image shows the unit tests passing after the change.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Details

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 84.89%

Totals

Change from base Build<PHONE_NUMBER>9:
-0.4%

Covered Lines:
20362

Relevant Lines:
22942

💛  - Coveralls

@tracyboehrer, conflicts solved!


nick.com and paramountplus.com doesn't work anymore

I'm reporting a broken site support
My youtube-dl --version is 2021.12.17
They urls are working in the browser
i tried with ' and " and other arguments but it doesn't work.
i didn't found a post with the same issue so that's why i post it.
Output 1: (nick.com)
youtube-dl -v https://www.nick.com/episodes/cbum0f/the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://www.nick.com/episodes/cbum0f/the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.19041
[debug] exe versions: ffmpeg 5.0-essentials_build-www.gyan.dev, ffprobe 5.0-essentials_build-www.gyan.dev
[debug] Proxy map: {}
[generic] the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2: Requesting header
WARNING: Falling back on generic information extractor.
[generic] the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2: Downloading webpage
[generic] the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2: Extracting information
ERROR: Unsupported URL: https://www.nick.com/episodes/cbum0f/the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2
Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 815, in wrapper
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 836, in __extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 534, in extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\generic.py", line 3489, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: https://www.nick.com/episodes/cbum0f/the-loud-house-the-boss-maybe-family-bonding-season-5-ep-2
Output 2: (paramountplus.com)
youtube-dl -v "https://www.paramountplus.com/shows/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH"
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-v', 'https://www.paramountplus.com/shows/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH']
[debug] Encodings: locale cp1252, fs mbcs, out cp850, pref cp1252
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.4.4 (CPython) - Windows-10-10.0.19041
[debug] exe versions: ffmpeg 5.0-essentials_build-www.gyan.dev, ffprobe 5.0-essentials_build-www.gyan.dev
[debug] Proxy map: {}
[generic] pa7hNJyhGqjW35UIALIsYVypeBc1G2oH: Requesting header
[redirect] Following redirect to https://www.paramountplus.com/shows/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH/
[generic] pa7hNJyhGqjW35UIALIsYVypeBc1G2oH: Requesting header
WARNING: Falling back on generic information extractor.
[generic] pa7hNJyhGqjW35UIALIsYVypeBc1G2oH: Downloading webpage
[generic] pa7hNJyhGqjW35UIALIsYVypeBc1G2oH: Extracting information
ERROR: Unsupported URL: https://www.paramountplus.com/shows/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH/
Traceback (most recent call last):
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 815, in wrapper
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\YoutubeDL.py", line 836, in __extract_info
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\common.py", line 534, in extract
File "C:\Users\dst\AppData\Roaming\Build archive\youtube-dl\ytdl-org\tmpupik7c6w\build\youtube_dl\extractor\generic.py", line 3489, in _real_extract
youtube_dl.utils.UnsupportedError: Unsupported URL: https://www.paramountplus.com/shows/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH/
If i want to download something from nick.com and paramountplus.com it just shows me unsupported URL.

Regarding Paramount+, try adding a component after .../shows/ (doesn't matter what): https://www.paramountplus.com/shows/x/video/pa7hNJyhGqjW35UIALIsYVypeBc1G2oH/
However you may also have to install PR #30085.

The Nick extractor is obsolete. You could try yt-dlp. Let us know if it works as I can merge in the changes from that version.

can confirm nick.com does work with yt-dlp


Mutiple edits to draft isn't syncronised to IMAP (gmail)

Expected behavior
Performing multiple editing sessions on a draft message in K9 should synchronise all changes to IMAP, allowing to start a message in K9 while on mobile to continue and finish it using an IMAP desktop client.
Actual behavior
The first draft saved from K9 is synchronised to IMAP, subsequent changes done using and present in K9 draft folder are not synchronised, the draft on IMAP remains the first saved.
Nothing I have attempted can trigger a message synchronisation, I have had IMAP drafts sitting stale for weeks; forcing K9 synchronisation, restarting K9, rebooting phone, resynchronising IMAP client. The remedy I resort to is either sending the mail to myself, or creating a new draft with copy-pasted contents.
This used to work but I have experienced this consistently since a recent K9 update (I remember upgrading from a release dated Nov 2019).
Steps to reproduce

First edit; Write new mail with some contents (body="Body", subject="Subject"), see screenshot 1
Save as draft (back->Save as draft or menu->Save as draft), see screenshot 2
Second edit; Reopen draft message, write some more text ("Additional body"), see screenshot 3
Save as draft (back->Save as draft or menu->Save as draft), see screenshot 4
Observe that only the first edit of the message is present in IMAP folder (fx. Thunderbird IMAP client or gmail.com web interface), see screenshots 5 & 6

Environment

K-9 Mail version: 5.717, see screenshot 7
Android version: 7.0, see screenshot 8
Account type (IMAP, POP3, WebDAV/Exchange): IMAP (gmail)
Phone model: Samsung Galaxy S8, SM-G950F

Screenshots
Done using Danish (dansk) locale.
Quick parlour;

skrive = write
fra = from
til = to
kladder = drafts

1 - first edit

1 - saved first edit

3 - second edit

4 - saved second edit

5 - IMAP Thunderbird

6 - IMAP gmail web interface

7 - K9 version

8 - Android version

Log
Please take some time to retrieve logs and attach them here:
k9-log_redacted.txt
This was redacted from the plain log using: sed -e s/example.com/"<redcated domain>"/g -e s/user/"<redacted user name>"/g k9-log.txt >k9-log_redacted.txt
First edit start: 2020-07-08T19:59:55+02:00
Second edit end: ~2020-07-08T20:02:00+02:00
Activity thereafter shows another unrelated draft being composed (for screenshots transfer).

I just updated from 5.6 to 5.717 and run into this issue. The behavior is exactly as described above. I'm using a different mail provider than gmail.
(Beside this, it is great to see all the improvements of the current beta version!:-)

Hello there, I use 5.721 on Andoid and I have the same issue. No chance to get the drafted content to the server. Is there anything I can help to figure out?

 Had the hopes that the log details I collected would make it easier to diagnose, but it doesn't seem so. Unfortunately, I'm unfamiliar with the K9 codebase and not daily into Java/Android, so haven't had the resources yet to dig into it personally,

I removed some code that I believed was unused. Turns out it was a very quirky mechanism that made replacing drafts on the server work. I'm not going to restore that code. Instead we'll do it "the right way". This is part of a larger effort and will take some time to complete.

Works since 5.724 - great work, thank you so much!


[BUG] No folder or file created on registration. Code 0 on first start. No preferences.toml.

Go Hass Agent Version
Go Hass Agent: v10.1.1
Describe the bug
The registration works and shows up in HA, but the go-hass-agent folder is not created nor any files. If I then try to run go-hass-agent it fails with FATAL Error checking registration status. error="device registration failed: could not register device: code 0: ". After that, the go-hass-agent folder has been created, but only contains agent.log and sensorRegistry/sensor.reg. The first contains all errors shown on first run, the second is empty.
Maybe related to #223?
To Reproduce
Steps to reproduce the behaviour:
0. (Delete all folders and stop the daemon if no clean install)

run go-hass-agent register --force --terminal --server _URL_ --token _TOKEN_
run go-hass-agent --terminal run
See error and empty folder

Expected behaviour
I would expect go-hass-agent to create the preference.toml file and start.
Logs
Sep  5 22:45:47.860 DEBUG Setting language. lang=[]
Sep  5 22:45:47.861 DEBUG Read sensor registry from disk. file=sensor.reg
Sep  5 22:45:47.867 FATAL Error checking registration status. error="device registration failed: could not register device: code 0: "
Sep  5 22:45:47.867 DEBUG Agent done.
Sep  5 22:45:47.868 WARN Could not connect to D-Bus. bus=SessionBus error="could not connect to bus: write unix @->/run/user/1000/bus: use of closed network connection"
…

Desktop (please complete the following information):

OS: Linux
Distribution Arch Linux ARM
Version 6.6.34-2-rpi

Hey @dflvunoooooo, that's an odd one. I unfortunately cannot reproduce in my arch test system, but it is amd64 not arm., but none of those messages hint that this could be an architecture issue.
Can you start again clean and run with debug logging enabled (add --log-level debug to the command-line)? That might give us more clues as to what might have happened. Please upload/attach the log to this issue (be sure to check and sanitize it for any private information).

Hm, that is strange, sorry for that. I did a clean install (removed go-hass-agent and the .config/go-hass-agent folder). Installed go-hass-agent again and ran go-hass-agent register --force --terminal --server http://IP:PORT --token _TOKEN_ --log-level debug wich told me
Sep 10 19:15:31.644 DEBUG Setting language. lang=[]
Sep 10 19:15:31.676 INFO Agent registered.

and the entity showed up under home assistant with one entity. Then I ran go-hass-agent --terminal run --log-level debug and got the same errors as bevore
Sep 10 19:16:06.880 DEBUG Setting language. lang=[]
Sep 10 19:16:06.881 DEBUG Read sensor registry from disk. file=sensor.reg
Sep 10 19:16:06.887 FATAL Error checking registration status. error="device registration failed: could not register device: code 0: "
Sep 10 19:16:06.888 DEBUG Agent done.
Sep 10 19:16:06.888 WARN Could not connect to D-Bus. bus=SessionBus error="could not connect to bus: read unix @->/run/user/1000/bus: use of closed network connection"
Sep 10 19:16:06.889 WARN Could not connect to D-Bus. bus=SystemBus error="could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.889 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor for active applications: no portal present"
Sep 10 19:16:06.889 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor for active applications: could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.890 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor for desktop settings: no portal present"
Sep 10 19:16:06.890 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor location updates: unsupported hardware"
Sep 10 19:16:06.891 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor for network connections: could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.891 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor laptop sensors: unsupported hardware"
Sep 10 19:16:06.891 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor power profile: could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.892 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor power state: could not connect to bus: write unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.892 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor power state: could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.892 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor abrt problems: could not connect to bus: write unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.893 WARN Could not start a sensor worker. linux.controller=sensor error="unable to monitor power profile: could not connect to bus: read unix @->/run/dbus/system_bus_socket: use of closed network connection"
Sep 10 19:16:06.893 DEBUG Processing sensor updates.
Sep 10 19:16:06.894 DEBUG Stopping all sensor controllers.
Sep 10 19:16:06.894 DEBUG Stopping cron scheduler. controller=scripts
Sep 10 19:16:06.894 DEBUG Exiting script controller. controller=scripts

and with still one entity in Home Assistant.

Hey @dflvunoooooo just following up to let you know I haven't forgotten about this issue and am still looking into ways to reproduce. I have not made progress there, but all the same, it's on my mind.
I would be curious if the latest 10.2.x version is any different?

Thanks for reaching out to me again and for not forgetting about me. It is indeed working with 10.2.x as expected. I will close this issue.


Auto update(r)?

This is just a creative idea at hand for feature posibility.
GitHub provides JSONized information about the repositories and maybe even in branch form, could an occasional timer be executed to compare the hashes of the project files of which will compile a list of changed files in the master branch, then prompt the user for update?
After calculating the hashes locally and comparing, in theory couldn't the latest files be downloaded by prefixing them with https://raw.githubusercontent.com/surfbirdapp/surfbird/master/?
My reason for considering this is to just simplify and reduce time of downloading the repository changes each time a stable update is applied in the future.

I could build that with Squirrel later on, not in any kind of focus right now!


feat: new styling for tags in blog list

Proposal for new tag list styling
Before:

dark:
light:

After:

dark:
light:
hover:

ship it! 👍


Complete refactor: notes as follows

The update endpoint no longer points to an actualy download link, just the clone hero main page
Instead I've changed the functionality to crawl the download page and look for the appropriate download link & download it from there. Kind of brute forcey but it works
Folder/file names are set once in the establishFileName function, easier for page crawling & file moving.
Mega no longer used (though could be an option because it's still on the download page)
Some error formatting (for debugging curiosity)

One issue persists: The unarr library returns "unarr: Error Read" for some reason or another, that I can't seem to figure out. Maybe the clonehero site is sending weirdly zipped files? I'm at a loss. Modifying the library to not panic seems to fix the issue and the game runs fine, but that's hard a solution lol.

@JoshuaDoes Let me know what you think, and any possible solutions to the unarr issue listed above! Hopefully we can get this thing back off the ground

It's all good! The versions API endpoint is setup and ready to go, I've just gotta get around to implementing it now.


Conflict between declare_strict_types and header_comment

$ php -v
PHP 7.1.2 (cli) (built: Feb 15 2017 08:01:35) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Xdebug v2.5.1, Copyright (c) 2002-2017, by Derick Rethans

$ php-cs-fixer -V
PHP CS Fixer version 2.1.1 by Fabien Potencier and Dariusz Ruminski (e0e33ce)

I have
'declare_strict_types' => true,

and
'header_comment' => ['header' => $header, 'separate' => 'none'],

in my .php_cs and
<?php
/*
 * This file is part of foo
 *
 * (c) Sebastian Bergmann<EMAIL_ADDRESS> *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

declare(strict_types=1);

namespace SebastianBergmann\Foo;

class Bar
{
    // ...

is transformed into
<?php
/*
 * This file is part of foo
 *
 * (c) Sebastian Bergmann<EMAIL_ADDRESS> *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

declare(strict_types=1);
/*
 * This file is part of foo
 *
 * (c) Sebastian Bergmann<EMAIL_ADDRESS> *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

namespace SebastianBergmann\Foo;

class Bar
{
    // ...

Hi,
Sorry you got hit by this issue. There is a bit of talk about here;
https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/2058
https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/2062
Unfortunately nobody found the time to fix this yet.

@sebastianbergmann, maybe you want to help with that ?

I was hit by this issue. If you need to remove the header from a PHP file between the opening tag and the namespace declaration, you can use this command:
find src -name '*.php' | xargs -L 1 sed -i '' '/^..php/,/^namespace .*;/{//!d;}'

thanks @marcw for the pointer,
sadly we didn't get around fixing this within the fixer yet...

I added https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/4883 but I don't know the cs fixer code or token system very well. I tried it in our project and it seems to work.

Closing in favor of #3467.


fix(core): fff

Please fill in the template below before submitting your pull request. This helps keep a consistent structure for project history.
Metadata

[ ] Feature: a new feature.
[ ] Bug: a bug fix.
[ ] Refactor: a code change that neither fixes a bug nor adds a feature.
[ ] Style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.).
[ ] Test: adding missing tests or correcting existing tests.
[ ] Performance: a code change that improves performance.
[ ] Documentation: changes to documentation.
[ ] Build: changes that affect the build system or external dependencies.
[ ] CI: changes to our CI configuration files and scripts.

Changes
A description of the pull request changes. What is the motivation for this change?
Checklist

[ ] This PR contains only a single concern and is small enough to be reviewed easily.
[ ] Documentation for this issue has been added or updated with this PR.
[ ] Unit tests have been added, if applicable.

Screenshots
Please include any relevant screenshots if this PR pertains to a visible UI change.
Additional Information
Please include any additional notes you feel are necessary here.

:tada: This PR is included in version 1.0.20 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


bad redirection semantics

Problem description
When hitting redirections listed in frontmatter headers (like /mackit/), we are not getting a 301 HTTP Code.
From my understanding, it should be the case.
https://support.google.com/webmasters/answer/93633
$ curl -v https://docs.docker.com/mackit/
*   Trying <IP_ADDRESS>...
* Connected to docs.docker.com (<IP_ADDRESS>) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: docs.docker.com
* Server certificate: RapidSSL SHA256 CA - G3
* Server certificate: GeoTrust Global CA
> GET /mackit/ HTTP/1.1
> Host: docs.docker.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 436
< Connection: keep-alive
< ETag: 47c5-1b4-58251905
< Last-Modified: Fri, 11 Nov 2016 01:04:05 GMT
< Server: WEBrick/1.3.1 (Ruby/2.3.1/2016-04-26)
< Date: Fri, 11 Nov 2016 05:41:57 GMT
< Cache-Control: max-age=600
< Strict-Transport-Security: max-age=15768000
< X-Cache: RefreshHit from cloudfront
< Via: 1.1 8a78b675adb2cce925860f2fe4383e71.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: 5E2yIGA8JWo8ehdUO4d9RrWqppXkRFFzCthpyxZZkH2ElGtOB6-drg==
<
<!DOCTYPE html>

<meta charset="utf-8">
<title>Redirecting…</title>
<link rel="canonical" href="https://docs.docker.com/docker-for-mac/">
<meta http-equiv="refresh" content="0; url=https://docs.docker.com/docker-for-mac/">

Redirecting…

Click here if you are not redirected.

* Connection #0 to host docs.docker.com left intact

Problem location
All paths listed under redirect_from in frontmatter headers, like /mackit/.
https://docs.docker.com/mackit/
Project version(s) affected
current stable

This is a limitation of using Jekyll/WEBrick as a package -- for more info see here: https://superdevresources.com/redirects-jekyll-github-pages/
The good news is that 301s are not the end-all-be-all; the URLs we produce still have canonical and refresh tags that are ABSOLUTELY supported by search engines.
I don't think there's much we can do about this without massively rethinking how the container image works, and I'm trying to step away from being concerned about that right now and focus on content. Any help would be appreciated on getting to a 301 world.

Thank you for having done some research.
On the practical aspect, this ticket is more a request for improvement than a real issue, but from an SEO point of view, it's probably an issue. The refresh meta + canonical link is a trick that doesn't have the intended semantics (it doesn't express the "permanent" aspect of the redirection)
From the article:
using a server side 301 redirect is a much better option and supported by all search engines
While Google doesn’t recommend its use, it has listed the meta refresh tag in its list of supported meta tags.
Let's keep this issue for the SEO discussions and work.

Yes, let's. Thanks, @gdevillele !

This should be fixed now that we are serving the docs using Nginx.


What is your question?
Is there a way to scrape data from a website similar to using the yt --transcript command?

Have you tried running a curl command? I have tried against markdown file url
curl --silent --show-error https://raw.githubusercontent.com/MichaelCade/90DaysOfDevOps/main/2022/Days/day01.md | fabric --pattern summarize --model mistral:instruct --stream

动 know


Faster division?

Division uses Knuth long division routine.
Is it possible to implement a faster division scheme?

Maybe worth reading: https://danlark.org/2020/06/14/128-bit-division/

Maybe worth reading...

Indeed it is. Thank you for providing this information.
This has also motivated yet another issue to potentially specialize mul/div for 128-bit uint with 32-bit limbs

Although only partly related to this issue, general rework and cleanup of the classic division algorithm has been mostly done in 2e9e8ce52a0cd619c96bf3c492685d017b223cb1

Based on discussions in #362, in particular here, this comment reminds us to look into division optimization(s).
Thninkin out loud...
I wonder if is worth-it to try unrolling four-by-n or eight-by-n division. Thjis might lead to a lot more written code depth, but maybe not much reward in the area of speedup. Or perhaps this kind of optimization might yield more significant improvements.
Cc: @maksymbeva and @johnmcfarlane

It's really up to you, but you might want to look into the extent to which -O3 can unroll your loops. It's generally tidier to leave this kind of thing up to the optimiser. That means the user gets to choose: minor speedups at the expense of code size, or something a little more balanced...

A little bit of handwaving and some of the estimations from my experience.
When doing performance optimizations, I've seen that on the Intel x86 architecture (before Skylake) a lot of time is spent just waiting for div/idiv operation to finish, around 50%. Given a comparison of the speed for Intel processors, the speed of multiplication has a latency of 1 clock cycle, while division is 30-80 (64bit registers). With Skylake+ it has been decreased to ~20 and even ~10 or so for Adler Lake.
Given this, I suppose the unrolling for Intel processors might not have that much sense unless used with Adler Lake. Please correct me if I'm wrong.
However, since the library is multiplatform, I suppose architectures like ARM and ESP32's processors are also considered. With this forum post, I see that multiplication is just 2 cycles and division is 4 cycles for ESP32. Removing all of the rest of the for-loop instruction and invocation burden can potentially help to speed it up for those processors.
The second most time-consuming (~10%) part in the Knuth division I spotted was surprisingly multiply-and-subtract. I used -O2 so, no for-loops unrolled. Maybe this is an interesting point for optimization or unrolling in the division.

Hi Maksym (@maksymbevza)
Many, many thanks for your very insightful comments.
With great enthusiasm I read your previous comments and these all make sense to me.
Division is a thing that I know I need to work on, ... but I sigh a breath of stationary relief that is works and has been tested on billions of cases.
I can't tell you how many times I found small defects in long division until it worked. Well it was a lot.
So I'm generally interesed in all your points, also the case(s) of division n / (1/2) n.
If, when, and, ... if I don't break anything else, I'm going to look into these.
Of course, long Knuth division will never reach logarithmic or smaller order complexity and I've not written it to use any Karatsuba. But i could. Again, a long-term interest.

After long deliberations, I've closed this. The wide_integer library is probably not going to go up to hundreds of thousands or millions of decimal deigts. So we stick with Knuth long division. The experienceof #378 and #379 show us that long division is implemented quite will in master. So we leave this one alone.


fix for unregistering a "general" event receiver

Contains
unregisterEventReceiver did not unregister receivers that had no components associated with them (general vs specific receivers). Adds a clause for handling this case (and a test to prove it)
How to test
Run the test suite :3

Hooray Jenkins reported success with all tests good!


including files from urls

Is that feature documented anywhere? If not please do.
It took a while to figure out how to make raw links work for Github as the links you get from them don't: https://github.com/[user]/[repo]/raw/[branch]/[path]
You need to replace the base url with https://raw.githubusercontent.com and remove the /raw/ part.
Not sure if compiler-explorer can do anything about that.

Compiler Explorer also has the ability to include raw text to your source, by abusing the #include directive.
#include <url_to_text_to_include>
...
(See this link a live example: https://godbolt.org/z/Pv0K0c)
Note that the URL has to allow for cross domain requests for this to work.


Add bomb sound effect

The game currently has sound effects for attacking and healing, but no sound plays when the player uses a bomb.
We'd like to use a sound effect like this to play when the player uses a bomb: https://freesound.org/people/Taira Komori/sounds/215595/
Please make sure you credit the original author in Sound.cpp!

Hello, I've been checking this project out and it seems interesting, would love to try my hand at adding this 😁

@LaloCode Yeah sure, go for it! 🙂

Closed by #109