Seg Fault in Receiver on Ubuntu 17

So I have a fresh install of Ubuntu 17.  Plugged the USB sdr in.  Installed python, etc and then tried to run receive.py and I get
linux; GNU C++ version 6.2.0 20161027; Boost_106200; UHD_003.009.005-0-unknown
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Segmentation fault (core dumped)
Thoughts?

Fixed that part by blacklisting the kernel modules and adding rtl=0 to the receive.py.  Now the decode process is crashing....
String length 99: ----------------__--------__----------------------------------------__-------_--_
String length a1: ----------------__------__-------------------------_--------_-------_------------------
String length a0: --------------_------------------------------_--------------------__-------__--------_
String length 8c: ----------------__------__-----------------__-------_---------------____________
String length a0: ----------------__------__-------------------------_--------_-------_-----------------
String length 86: --------------_-----------------------------------------_---
len 80: ----------------__----__--------------_------------------------------_
Packet Received: 0xfffe8e1fe888aa8c
DeviceID: 0x8e1fe8
Status: 0x88
CRC: 0xaa8c
Segmentation fault (core dumped)

That was fixed by adding a devices file.... now I get some stuff then FIFO closed and the decoder stops.

If the FIFO closes that sounds like an issue is happening in the gnuradio flowchart.  (The FIFO closing causing the decoder to stop is expected behavior).  I'd suggest opening receive345.grc in GNU Radio Companion, disabling the FIFO output, enabling some of the visual sinks, and confirming that everything runs as expected without the decoder running at all.

@efaden - were you able to resolve your seg faults? I just set all this up for the first time (on Ubuntu 16) and am having the same issue (I did not see seg faults on the receiver though - seems to be working fine).
As a reference, here is what I'm seeing:
receiver output:
linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Using Volk machine: sse4_1_64_orc

decode output with no data:
# of Devices: 0
Waiting for FIFO data...
Receiving data...
FIFO Closed

Once I move a magnet to a sensor:
# of Devices: 0
Waiting for FIFO data...
Receiving data...
len 80: _-_-_-_-_-_-_-_-_-_-_-_-_-_-_--__--_-_-__-_-_-_--__--__--_-__-_--_-_-_-_-_-__--__-_--_-_-_-_-_-__-_--_-_-__-_--__-_--_-_-_-_-_-_
Packet Received: 0xfffe<redacted>
 DeviceID: <redacted>
 Status: 0xc0
 CRC: <redacted>
Segmentation fault (core dumped)

From that point, decode345 (c version) will continue to output the same data until the receiver is restarted.
I'm going to work on troubleshooting, but I'm new to radios and have never used gnuradio, but I'm expecting progress to be slow...

The segfault I was receiving was due to line 194 of decode345.c. If you haven't specified a devices file, when it reaches this line:
for (i=NumDevices;i>=0;i--) if (DeviceIDs[i] == DeviceID) break;
it crashes.
I haven't really dug into the code yet, and C is not a strength of mine, but I'm guessing that either DeviceIDs is null or DeviceIDs[0] is undefined..

Thanks for all the notes @kevinfealey
re: different status codes, the ones that are listed as just the bit number (e.g. Bit5-0) were never generated by my sensors, so I had no idea what they did.  My guess was that for they are used for sensors that have multiple trigger mechanisms.  A google search for your sensor seems to confirm this is likely what's going on, as yours has "two zones" -- a reed switch + a contact loop (ref).  Mine only have one zone.  So, bit 5 is probably the status of the additional zone.
re: Seg Fault --- yes, it looks like there's an off-by-one issue in the code that checks against the device list.  When I have an opportunity I'll add a fix.

Fixed that part by blacklisting the kernel modules and adding rtl=0 to the receive.py. Now the decode process is crashing....
  I need to specify rtl=1 but i am not a python programmer so uncertain as to where to place it. Thanks.


fixed nil in checker output

Codecov Report

Merging #253 (5186b61) into main (46ce53f) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##             main     #253   +/-   ##
=======================================
  Coverage   76.48%   76.49%
=======================================
  Files         152      152
  Lines        8523     8526    +3
=======================================
+ Hits         6519     6522    +3
  Misses       1670     1670
  Partials      334      334

Flag
Coverage Δ

unittests
76.49% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

checker/checks-utils.go
75.16% <100.00%> (+0.49%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


BACKPORT: Fixes to libcontainer/user for treating numeric user as numbers

This avoids exploiting /etc/passwd entries such as
1000:x:0:0::/root:/bin/bash
to gain root by running the container as --user 1000
Signed-off-by: Mrunal Patel<EMAIL_ADDRESS>

@rhatdan @runcom PTAL

LGTM

LGTM

could we please get this into the fedora branches as well?

I will create a PR
Sent from my iPhone

On Apr 25, 2016, at 7:59 AM, Lokesh Mandvekar<EMAIL_ADDRESS>wrote:
could we please get this into the fedora branches as well?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub


Fine-Tune example

Hi,
First off, this is a great library so thanks for making it available.
I really like the fine-tune option and was trying to use it but I am just not sure what format is expected in the clean and corrupt files.
For example, if I has a custom word or abbreviations such as AWS and I was to correct mis-spellings for that how do I create a training file for that?
Do I create a clean file with sentences like "how do i use aws" and a corrupt example like "how do i use aaws"?
I tried it like this but it did not seem to "learn" the correct spelling and still auto-correct aws to things like "laws".
Maybe it would be difficult to change the pretrained model (I am using BERTChecker at the moment) since it would have learned the "laws" example already so would need alot of training to relearn a new spelling?
I would appreciate any info you have on this.
Thanks in advance
Cathal

Hi I am also trying the same,
The format of clean and corrupt files you mentioned is correct.
"how do i use aws" will be in clean file and "how do i use aaws"? will be in corrupt file, but still it is not giving the expected output.
I think the reason for this is it doesn't support to add custom vocab file, its using the default vocab file and that is why the output is incorrect.
see:
https://github.com/neuspell/neuspell/blob/master/neuspell/corrector_subwordbert.py#L81
Seems like the only option is to train from scratch.


fix typos

I think all the typos you mention here are not typos, but British grammar.

Indeed, sir, I'd better go and wash my dictionary with soap.


PCM fails on macOS during IOServiceOpen

On macOS Ventura beta (22A5321d), when PCM (and other tools, I presume) runs, IOServiceOpen returns kIOReturnNoMemory, and, from what I could determine based on Dtrace, it comes from
https://github.com/apple/darwin-xnu/blob/main/iokit/Kernel/IOService.cpp#L7263
when the service name is looked up during IOKit client connection.  I'm not an IOKit/kernel programmer, but, AFAICT, there seems to be a mismatch between the IOService name that is being registered during driver initialization and what service name is used on the client side.

After a bit of debugging using Dtrace, and ignoring the project docs which state that Xcode should be used to build the driver, this is because the command line build doesn't compile PcmMsrClient into the kext binary, and when a client connection is made to the driver, I/O tries to look it up and fails.  Easy fix.

If it helps, the Dtrace I cobbled together is below.  Dtrace has some options to run a C/C++ preprocessor over a script to reference kernel structures in the script, but I could not determine the correct defines and include paths, so I just recreated OSSymbol in the script itself, which worked (in this case).  I was able to see that OSMetaClass::allocClassWithName() was being called with com_intel_driver_PcmMsrClient and returning NULL when it could not find it.
`/* _ZN11OSMetaClass18allocClassWithNameEPK8OSSymbol /
/ _ZN11OSMetaClass21copyMetaClassWithNameEPK8OSSymbol */
struct OSSymbol {
int retainCount;
unsigned int   flags:14,
length:18;
char         *str;
};
fbt:mach_kernel:_ZNK12OSDictionary9getObjectEPK8OSSymbol:entry /execname == "pcm"/ {
this->sym = ((struct OSSymbol*)arg1);
}
fbt:mach_kernel:_ZNK12OSDictionary9getObjectEPK8OSSymbol:return /execname == "pcm"/
{
if (this->sym->str == "com_intel_driver_PcmMsr") {
@hgram[probefunc, timestamp, stringof(this->sym->str), arg1, stack()] = count();
}
}
`

If it helps, the Dtrace I cobbled together is below. Dtrace has some options to run a C/C++ preprocessor over a script to reference kernel structures, but I could not determine the correct defines and include paths, so I just recreated OSSymbol in the script itself, which worked (in this case). I was able to see that OSMetaClass::allocClassWithName() was being called with com_intel_driver_PcmMsrClient and returning NULL when it could not find it.
struct OSSymbol {
  int retainCount;
  unsigned int flags:14,
  length:18;
  char *str;
};

fbt:mach_kernel:_ZNK12OSDictionary9getObjectEPK8OSSymbol:entry /execname == "pcm"/ {
  this->sym = ((struct OSSymbol*)arg1);
}

fbt:mach_kernel:_ZNK12OSDictionary9getObjectEPK8OSSymbol:return /execname == "pcm"/
{
  if (this->sym->str == "com_intel_driver_PcmMsr") {
    @hgram[probefunc, timestamp, stringof(this->sym->str), arg1, stack()] = count();
  }
}

/* _ZN11OSMetaClass18allocClassWithNameEPK8OSSymbol /
/ _ZN11OSMetaClass21copyMetaClassWithNameEPK8OSSymbol */


Incompatible with Compact Machines 5

Describe the Bug
When loaded together with Compact Machines 5, game crashes during start.
Reproduction Steps

Install Compact Machines 5 and Create Fabric
Launch the game

Expected Result
Game launches successfully.
Screenshots and Videos
No response
Crash Report or Log
https://mclo.gs/Ft2bdEL
Operating System
Windows 11
Mod Version
0.5.1b
Minecraft Version
1.19.2
Other Mods
Reproducible with only Fabric API, Create and Compact Machines 5 installed.
Additional Context
This issue https://github.com/AlphaMode/CompactMachines-Fabric/issues/7 seems to be relevant, though it does not crash on start.

same reason as #1061


Playground doesnt have any libraries

Simple fix next time playground is upgraded. All no-no related libraries should be supported.

fixed


Update frontpage suggestions.

I still think ideally the title should be fetched from the page directlly and not specified here

agreed :/
Also, you'll have to run npm run lint:fix

@mruwnik I ran the command and got an error in a file I did not modify. The error also shows up on the master branch.
`stampy-ui/node_modules/typescript/lib/tsc.js:93
for (let i = startIndex ?? 0; i < array.length; i++) {
^
SyntaxError: Unexpected token '?'
`

huh. This is a typescript error, which is concerning. Have you updated your node modules recently? Does removing them and reinstalling work (rm -R node_modules && npm install)?

Ubuntu jammy had installed npm v8.5, I manually updated to v22.8.0 and it works.


Added labels on extra lines

Added an optional feature that enables user to assign label on extra lines(both vertical and horizontal supported):

Great PR,
Please update the line_chart.md, and update the line chart sample 8

@imaNNeoFighT Done

Hi, sorry for the delay.
Perfect Implementation
Thanks for your contribution.


[xmonad] Update to latest xmonad

Hello,
I'd like to (try and) update xmonad to the latest version.
In latest cabal, a 0.12 version has been released!
If you were interested by this, what would be the right path?
I'm confused by all the xmonad derivations we can find in nixpkgs.
Thanks for your pointers.
Cheers,

The xmonad window manager module refers to xmonad-with-packages, which in turn refers to applications/window-manager/xmonad/wrapper.nix, which is parameterised over ghcWithPackages. As far as I can tell, xmonad uses ghcWithPackages from the NG branch, which means xmonad will get updated automatically when the NG package set is re-generated from Hackage. @peti will know the actual answer, I think.

Well, this makes complete sense now.
Thanks a lot for clarifying.
So i believe there is nothing to do but wait then ;)
On Thu, 19 Mar 2015 12:28 joachifm<EMAIL_ADDRESS>wrote:

The xmonad window manager module refers to xmonad-with-packages, which in
turn refers to applications/window-manager/xmonad/wrapper.nix, which is
parameterised over ghcWithPackages. As far as I can tell, xmonad uses
ghcWithPackages from the NG branch, which means xmonad will get updated
automatically when the NG package set is re-generated from Hackage. @peti
https://github.com/peti will know the actual answer, I think.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/6890#issuecomment-83518363.

Where do you see xmonad version 0.12? http://hackage.haskell.org/package/xmonad doesn't seem to have that.

I ran a
cabal update
cabal list xmonad

And saw 0.12.
On Thu, 19 Mar 2015 13:00 Peter Simons<EMAIL_ADDRESS>wrote:

Where do you see xmonad version 0.12?
http://hackage.haskell.org/package/xmonad doesn't seem to have that.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/6890#issuecomment-83523682.

There's xmonad-extras 0.12, could that be what you saw?

After cross checking, I misread!
I must have read the xmonad-extras version.
And as I have read last week on the xmonad mailing list that they were discussing about a new release... I must have been too excited!
@joachifm @peti Sorry for the noise.
@joachifm Still I learn some interesting things. Thanks for that.

There's xmonad-extras 0.12, could that be what you saw?

Yes, that must be it

Here is the thread about it https://mail.haskell.org/pipermail/xmonad/2015-March/014593.html.
But indeed, nothing was released yet.


Exclude tags

Move filtering to a separate function (DRY)
Allowing ignoring (excluding) groups that contain a nonempty value in a specific tag. Multiple tags can be specified.

ping

Thanks for PR :smiley:
I'm sorry merge is delayed

Thank you for the merge. I was afraid you've gone away :)

@winebarrel please ping me when it's included in a proper gem version
Thanks!

@BackSlasher I'm sorry release is delayed.
I'm going to release new gem today.

No rush :)
Nitzan Raz
http://backslasher.net
On Sun, Oct 18, 2015 at 8:38 AM, Genki Sugawara<EMAIL_ADDRESS>wrote:

@BackSlasher https://github.com/BackSlasher I'm sorry release is
delayed.
I'm going to release new gem today.
—
Reply to this email directly or view it on GitHub
https://github.com/winebarrel/piculet/pull/18#issuecomment-148980324.

@BackSlasher v0.2.9.beta2 has been released! Please try it out :smiley:

Thanks, will do!
Nitzan Raz
http://backslasher.net
On Sun, Oct 18, 2015 at 10:49 AM, Genki Sugawara<EMAIL_ADDRESS>wrote:

@BackSlasher https://github.com/BackSlasher v0.2.9.beta2
https://rubygems.org/gems/piculet/versions/0.2.9.beta2 has been
released! Please try it out [image: :smiley:]
—
Reply to this email directly or view it on GitHub
https://github.com/winebarrel/piculet/pull/18#issuecomment-148987416.


Trident fails with K8s 1.19 despite being listed as a supported version in the docs

Describe the bug
The docs at https://netapp-trident.readthedocs.io/en/stable-v20.07/support/requirements.html#supported-frontends-orchestrators state that v20.07 supports the latest kubernetes version 1.19
When running on a cluster with 1.19.3 I get the following:
time="2020-10-21T12:58:01Z" level=fatal msg="Could not create Kubernetes k8sclient." error="unsupported Kubernetes version; Trident-Operator 20.07.0 supports Kubernetes versions in the range [1.14, 1.18]"
I can't see anything in the change log for v20.07.0 or v20.07.01 that suggests v1.19 is supported. Are the docs just wrong?
Environment
Provide accurate information about the environment to help us reproduce the issue.

Trident version: 20.07.0
Trident installation flags used: operator installed using default bundle (kubectl create -f deploy/bundle.yaml)
Container runtime: Docker 19.03.8-CE
Kubernetes version: 1.19.3
Kubernetes orchestrator: kubeadm
Kubernetes enabled feature gates: none
OS: RHEL 7.8
NetApp backend types: Not yet hooked up to a backend

To Reproduce
Kubeadm deployed cluster at 1.19.x with the trident operator.
Expected behavior
Trident to work

@cjreyn support for k8s 1.19 is available with Trident 20.07.1

Thanks @balaramesh I missed that in the changelog. I will update.


The FaceMesh does not work in some static images at ios platform

Have I written custom code (as opposed to using a stock example script provided in MediaPipe)
None
OS Platform and Distribution
ios 14.0
MediaPipe version
latest
Bazel version
5.2.0
Solution
FaceMesh
Programming Language and version
objective-c & swift
Describe the actual behavior
I want to detect faces of the static image with `smoothed_face_landmark_front_gpu_image`, but some pitures that can be detected faces when using the camera couldn't be detected faces.

in the swift file, I convert the UIImage to CVPixelBuffer.

extension CGImage {
    public func pixelBuffer() -> CVPixelBuffer? {
        return pixelBuffer(width: width, height: height, orientation: .up)
    }

    public func pixelBuffer(width: Int, height: Int,
                            orientation: CGImagePropertyOrientation) -> CVPixelBuffer? {
      return pixelBuffer(width: width, height: height,
                         pixelFormatType: kCVPixelFormatType_32BGRA,
                         colorSpace: CGColorSpaceCreateDeviceRGB(),
                         alphaInfo: .noneSkipFirst,
                         orientation: orientation)
    }

    public func pixelBuffer(width: Int, height: Int,
                              pixelFormatType: OSType,
                              colorSpace: CGColorSpace,
                              alphaInfo: CGImageAlphaInfo,
                              orientation: CGImagePropertyOrientation) -> CVPixelBuffer? {
        assert(orientation == .up)

        var maybePixelBuffer: CVPixelBuffer?
//        let attrs = [kCVPixelBufferCGImageCompatibilityKey: kCFBooleanTrue,
//             kCVPixelBufferCGBitmapContextCompatibilityKey: kCFBooleanTrue,
//        ]
        let attrs = [kCVPixelBufferCGImageCompatibilityKey: kCFBooleanTrue as Any,
             kCVPixelBufferCGBitmapContextCompatibilityKey: kCFBooleanTrue as Any,
                      kCVPixelBufferIOSurfacePropertiesKey: [:]
        ] as [CFString : Any]

        let status = CVPixelBufferCreate(kCFAllocatorDefault,
                                         width,
                                         height,
                                         pixelFormatType,
                                         attrs as CFDictionary,
                                         &maybePixelBuffer)

        guard status == kCVReturnSuccess, let pixelBuffer = maybePixelBuffer else {
          return nil
        }

        let flags = CVPixelBufferLockFlags(rawValue: 0)
        guard kCVReturnSuccess == CVPixelBufferLockBaseAddress(pixelBuffer, flags) else {
          return nil
        }
        defer { CVPixelBufferUnlockBaseAddress(pixelBuffer, flags) }

        guard let context = CGContext(data: CVPixelBufferGetBaseAddress(pixelBuffer),
                                      width: width,
                                      height: height,
                                      bitsPerComponent: 8,
                                      bytesPerRow: CVPixelBufferGetBytesPerRow(pixelBuffer),
                                      space: colorSpace,
                                      bitmapInfo: alphaInfo.rawValue)
        else {
          return nil
        }

        context.draw(self, in: CGRect(x: 0, y: 0, width: width, height: height))
        print(pixelBuffer)
        return pixelBuffer
      }

}

the kCVPixelBufferIOSurfacePropertiesKey: [:] of attrs  is to avoid the proble followed:
gpu_buffer_storage_cv_pixel_buffer.cc:57]
Check failed: cv_texture_temp && !err
CVOpenGLESTextureCacheCreateTextureFromImage failed: -6683

in oc file, use the function sendPixelBuffer.
- (void)processVideoFrame:(CVPixelBufferRef)imageBuffer {
  const auto ts =
      mediapipe::Timestamp(self.timestamp++ * mediapipe::Timestamp::kTimestampUnitsPerSecond);
  NSError* err = nil;
  NSLog(@"sending imageBuffer @%@ to %s", @(ts.DebugString().c_str()), kInputStream);
  auto sent = [self.mediapipeGraph sendPixelBuffer:imageBuffer
                                        intoStream:kInputStream
                                        packetType:MPPPacketTypeImage
                                         timestamp:ts
                                    allowOverwrite:NO
                                             error:&err];
  NSLog(@"imageBuffer %s", sent ? "sent!" : "not sent.");
  if (err) {
    NSLog(@"sendPixelBuffer error: %@", err);
  }
}

### Describe the expected behaviour

_No response_

### Standalone code/steps you may have used to try to get what you need

_No response_

### Other info / Complete Logs

_No response_

test images:
image1

image2

image3

the image1&2 didn't detect faces, and image3 did.

Hello @BTLDXX-x
The face mesh has certain limitations. If you check page 2 of face mesh model card, it mentions

Videos should be captured in "selfie" mode. As such, it's not suitable for detecting faces:

looking away from the camera (more than 80°),
inclined from the vertical orientation (more than 8°),

The faces in the first image is inclined and that is why the face mesh is not able to detect face. You can try image transforms to process images better.
Also, you can try to see if the python solution can detect faces in the same images. Please let us know if it is the case. This will help us narrow the problem to the iOS solution.

@ayushgdev
thanks for your reply.
The python solution can detect faces in the same images.

Hello @BTLDXX-x
We are investigating this issue. Please allow us some more time.

@ayushgdev, thank you! Looking forward to it!


.excalidraw.md files are not deleted + feature ideas

Hello,
Is it normal that .excalidraw.md files aren't deleted with .* and even with .excalidraw.md or .excalidraw.* ?
I also tried *.excalidraw.* and *.excalidraw.md but those seems to be incorrect expressions (they are deleted instantly when I close the settings panel). Maybe it is because it ends with ".md" ? (that expression doesn't work either, thankfully ahah, for security reasons I suppose)
Also I have an idea, when the deleting prompt appears it would be nice if we could check for each file (or even folder) whether we delete it.
Another little thing is that it would be nice in the setting panel if the textbox had a min-width (according to its content, or not, as you wish).
Thanks in advance.

Hmm this might be because of the .md suffix which might make it so that the plugin assumes that is is a normal markdown file and does not do further processing (other than the file being completely empty).
I'll need to look into this further.
As for the file extensions you tried, I think you should have tried the following: .excalidraw.* and .excalidraw.md, as in omitting the initial *.
Regarding the check for each file (and/or folder) to be deleted, do you mean just inspection or to select if they should be deleted or not as in a checkbox, if so this is in the works (however taking some time) with the following issue #58
As for textbox min-width in settings, this I agree with wholly.

Yup, I think I have already tried it when I opened the issue but I didn't want to bother writing all my tests.
To be sure I just did it right now and it doesn't work.
Yes something like a checkbox for each element! Because when I clear my files there could be a situation where I don't want to remove a certain file right now.
Furthermore, you could also create an option to ignore certain files (as you did for folders), and in addition creating a button next to the checkbox and the file/folder name to add it to the ignored list (when the user wants to clear the vault).
Thank you very much for considering my suggestions! Implement them if you wish and perhaps gradually ;)

So, I've had a look at why the excalidraw files are not deleted.
They do use their own format, however it does follow markdown standard so it is possible to parse and determine if they are empty or not.
My main issue is that Excalidraw by default compresses the files to make the drawings take less space (not a bad thing at all it just complicates things), this seem to use an external library which I kinda do not want to include in this plugin for this one specific case.
What I am however thinking off is to make it possible so that if the Excalidraw files are not compressed (which can be toggled in Excalidraws settings), I can clean them up by inspecting the content and verify that they are empty.
This will unfortunately take a bit of time to get it working.
However with the rewrite I did back in June will make it a bit easier as I did make it possible to further inspection code blocks etc (which Excalidraw uses to contain the drawing data).
As for the size of the text boxes, I have prepared a fix and will be releasing it shortly (#63), they will now be resizable within a certain range and wont freak out like before. :)

Hi @Iphinis, I have now prepared a pull request to add support for Excalidraw files (see #66).
As mentioned in my previous comment, this will require the user to disable compression in Excalidraw.

I think the issue you're talking about is what is mentioned in #68
If I understand it correctly excalidraw files should have been handled like attachments instead of how they are now, is that correct?
If so, please also leave a comment in the mentioned issue above so I can track it there. :)


Minor fixes for sn mainnet

This change is

End to end tests are failing
Did fail also on main for test_safe.py.
It seems to be related to async fixture like last time.
After a look:

test_cairo_precompiles.py: cairo_counter_caller  and cairo_counter should have a scope "module"
test_dual_vm_token.py:  starknet_token and dual_vm_token should have a scope "module"
test_pragma_precompiles.py: cairo_pragma should have a scope function


Preprint-Published Pairs Vector Distance Experiment

This PR is based on comparing various distance metrics when determining preprint-published document pairs. Common approach in the field is to use cosine distance to determine "document similarity" as this metric is magnitude agnostic. For my paper I didn't use cosine distance I used pure euclidean distance. Based on this fact, a reviewer wanted to see if cosine distance makes a difference and results I found is that it does not for this particular task.
I also viewed how abstracts only fairs against using full text.
FYI: cosine proxy is basically using euclidean distance to mimic cosine distance (L2 norm of vectors)

Looks good! Why do you use the proxy of the cosine similarity instead of the true cosine similarity? Is it that the dataset is too big to run cosine in a reasonable amount of time?

So cosine similarity (distance) is not a true distance metric as it violates the triangle inequality. Algorithms such as k-nearest-neighbors need to a true distance metric in order to operate efficiently (runtime not performance). Given this caveat, a proxy to the cosine distance can be used. I included it in this analysis to show that the proxy performs as well as the original metric.


binarycaching: Default NuGet push timeout to one hour

Related to this issue https://github.com/microsoft/vcpkg/issues/18483
As mentioned in the issue, ideally this timeout value could be configurable, but I'm not sure the best way to approach that in this code base. Help would be greatly appreciated!
Needs the extra second due to some potential issue with how NuGet calculates the timeout:
https://jfrog.com/knowledge-base/how-to-resolve-nuget-push-failures-after-5-minutes-even-though-timeout-value-is-set-as-greater-than-5-minutes-300-seconds/

Thanks for the PR!
I think we will eventually want this setting to come through the binary caching configuration string. To preserve our ability to fuse multiple NuGet calls together, I think this means it will need to come from a separate entry:
nuget,<url1>;nuget,<url2>;nugettimeout,3601

we will eventually want this setting to come through the binary caching configuration string

Just to confirm: You are referencing the valid source strings section and VCPKG_BINARY_SOURCES environment variable/--binarysource CLI option in the documentation on binary caching, and adding a new keyword nugettimeout?
If so, that makes sense to me! Thank you.

@ras0219-msft I've tried implementing a solution to what you described. I'd appreciate a review when you get a chance. Thank you!

Could you also add the new documentation to docs/users/binarycaching.md?

I'd be happy to! Just one question, how does that work? It looks like that file lives in the main vcpkg repo, and a PR to update the doc should also bump the vcpkg-tool to a commit that has this PR merged. But a bump to the vcpkg-tool version look like it requires a release (so that Windows users can download a pre-built executable).
Am I missing something?

It also looks like there is now a conflict with binarycaching.cpp file. I will try to fix that today at some point.

Ah, you're absolutely right. Sorry for my confusion! Still getting used to the split repos I suppose :)
Thanks again!


Android RN 72 Support - Update build.gradle w/ Namespace

RN Team Update:
https://github.com/react-native-community/discussions-and-proposals/issues/671
Fix:
https://github.com/react-native-community/discussions-and-proposals/issues/671#issuecomment-1598892444

Hi @alexhernandez, thanks for the submission! I'll take some time this week to review.


Add Unmanned Tech from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of Oneiros, to add Unmanned Tech to CKAN.
Mod details:
name = /mod/1969/Unmanned%20Tech
author = Oneiros
abstract = Minor changes to stock parts in the tech tree to create an unmanned start for career and science mode
license = MIT
Homepage =
description = Moves around a few stock parts to create an unmanned start to the game
Requires Module Manager (not bundled)
Please direct questions about this pull request to Oneiros.

This was added in #6705.


Dev2 1835 - do not modify the old suffix in case multiline suggestions

problem:
Tabnine returns the  old_suffix  to be replaced by the new_prefix (current suggestion)
for now, this logic is relevant only in single-line suggestions.
example:
in the case of console("H<caret>")  and new_prefix :ello") Tabnine will return  old_suffix: ") to be replaced by the new_prefix
notes:

this logic s not relevant to multiline suggestions because it is already handled here
we have the same workaround in vscode as well https://github.com/codota/tabnine-vscode/blob/c0a9a7d5a19e4a9ef23579ce8688d216d1aab439/src/provideInlineCompletionItems.ts#L87
this logic is calculated here
and because it is used by the Ycmd mode, for now, I've decided to handle it on the plugin level, moving forward  we should consider removing it from the binary

Lgtm Not sure why you suggest removing the logic completely from the binary though
my suggestion was to remove the 'old_suffix` initialization in case of multiline, the caller should not care whether the suggestion is multiline or not


Deploy pip package

[x] pip install git+https://github.com/CoreDotToday/CoreDotFinance.git 설치 테스트
[ ] coredottoday로 배포
[ ] pip install coredotfinance 설치 테스트

EC2 에서 pip install git+https://github.com/CoreDotToday/CoreDotFinance.git 설치 테스트
Collecting git+https://github.com/CoreDotToday/CoreDotFinance.git
  Cloning https://github.com/CoreDotToday/CoreDotFinance.git to /tmp/pip-req-build-ykceoq59
  Running command git clone -q https://github.com/CoreDotToday/CoreDotFinance.git /tmp/pip-req-build-ykceoq59
Collecting beautifulsoup4>=4.9.3
  Downloading beautifulsoup4-4.9.3-py3-none-any.whl (115 kB)
     |████████████████████████████████| 115 kB 1.6 MB/s
Collecting numpy>=1.8
  Downloading numpy-1.20.3-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (15.4 MB)
     |████████████████████████████████| 15.4 MB 2.7 MB/s
Collecting pandas>=0.14
  Downloading pandas-1.2.4-cp38-cp38-manylinux1_x86_64.whl (9.7 MB)
     |████████████████████████████████| 9.7 MB 30.5 MB/s
Collecting plotly>=4.14.3
  Downloading plotly-4.14.3-py2.py3-none-any.whl (13.2 MB)
     |████████████████████████████████| 13.2 MB 29.3 MB/s
Requirement already satisfied: requests>=2.7.0 in /usr/lib/python3/dist-packages (from coredotfinance==0.0.1) (2.22.0)
Collecting soupsieve>1.2; python_version >= "3.0"
  Downloading soupsieve-2.2.1-py3-none-any.whl (33 kB)
Collecting python-dateutil>=2.7.3
  Downloading python_dateutil-2.8.1-py2.py3-none-any.whl (227 kB)
     |████████████████████████████████| 227 kB 32.2 MB/s
Collecting pytz>=2017.3
  Downloading pytz-2021.1-py2.py3-none-any.whl (510 kB)
     |████████████████████████████████| 510 kB 30.2 MB/s
Requirement already satisfied: six in /usr/lib/python3/dist-packages (from plotly>=4.14.3->coredotfinance==0.0.1) (1.14.0)
Collecting retrying>=1.3.3
  Downloading retrying-1.3.3.tar.gz (10 kB)
Building wheels for collected packages: coredotfinance, retrying
  Building wheel for coredotfinance (setup.py) ... done
  Created wheel for coredotfinance: filename=coredotfinance-0.0.1-py3-none-any.whl size=37712 sha256=7e0416a07888517e53ff65352cb284cfdbefe1274a55d6f11765bec8
4b3c5523
  Stored in directory: /tmp/pip-ephem-wheel-cache-3ko5rjex/wheels/8d/09/a8/290ab4d31ae52c08c22143ec969756440a615da398d513c42f
  Building wheel for retrying (setup.py) ... done
  Created wheel for retrying: filename=retrying-1.3.3-py3-none-any.whl size=11430 sha256=2769107755e24c49b2154dd25f5c0dde6fc2e57986967a02d3aff8f5d88606d4
  Stored in directory: /home/ubuntu/.cache/pip/wheels/c4/a7/48/0a434133f6d56e878ca511c0e6c38326907c0792f67b476e56
Successfully built coredotfinance retrying
Installing collected packages: soupsieve, beautifulsoup4, numpy, python-dateutil, pytz, pandas, retrying, plotly, coredotfinance
  WARNING: The scripts f2py, f2py3 and f2py3.8 are installed in '/home/ubuntu/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed beautifulsoup4-4.9.3 coredotfinance-0.0.1 numpy-1.20.3 pandas-1.2.4 plotly-4.14.3 python-dateutil-2.8.1 pytz-2021.1 retrying-1.3.3 sou
psieve-2.2.1


Server Timeout

Hello,
I was wondering if there is a way to increase server timeout, because of a long processing request.
Thank for the good work

thank you!


Image Size Problem

Hi,
very thankful to your released code, it helps me a lot!
I have tried running on my own dataset.
If the image size is 3x32x32, all things go well.
However, when I set image size to 3x64x64, I got the error "/usr/local/bin/luajit: bad argument #2 to '?' (out of range at /root/torch/pkg/torch/generic/Tensor.c:913)"
Could you please help me with this problem?

Hi, thanks,
I think that is because you did not change the network architecture, which still take 32x32 images as inputs. You need to define your own network architecture to train the model on images with size 64x64.

Hi, thanks for reply!
Therefore, I should change it in models_def, right?

yes, exactly.

OK, I will close it, thanks!


laravel mix fails if the working dir path contains and exclamation mark "!"

ERROR  Failed to compile with 2 errors                                                                                12:41:30 PM
These dependencies were not found in node_modules:

/var/www/!htdocs-new/resources/assets/js/app.js in multi ./resources/assets/js/app.js ./resources/assets/sass/app.scss
/var/www/!htdocs-new/resources/assets/sass/app.scss in multi ./resources/assets/js/app.js ./resources/assets/sass/app.scss

Did you forget to run npm install --save for them?
Asset      Size  Chunks             Chunk Names
/js/app.d41d8cd98f00b204e980.js    6.5 kB       0  [emitted]  /js/app
mix-manifest.json  53 bytes          [emitted]
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/opt/node/bin/node" "/usr/local/bin/npm" "run" "dev"
npm ERR! node v6.9.5
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR! @ dev: node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @ dev script 'node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node node_modules/cross-env/bin/cross-env.js NODE_ENV=development node_modules/webpack/bin/webpack.js --progress --hide-modules --config=node_modules/laravel-mix/setup/webpack.config.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /var/www/!htdocs-new/npm-debug.log
I guess all would be ok with a ! instead of ! (in the specified paths)

It might be related to this: https://webpack.js.org/concepts/loaders/#via-require

so how would one escape the "!"? shouldn't the PWD be escaped?

looks like its not specific to mix. Here's a couple of similar issues i found:
https://github.com/jantimon/html-webpack-plugin/issues/530
https://github.com/davezuko/react-redux-starter-kit/issues/916#issuecomment-231394811

This still exists, took me almost half a day to figure this one out, tried different npm/node versions to no avail. Finally moved the whole project to a different folder and it all magically started to work. I think it would be worth reopening this one and taking a second look at escaping ! in the path.

This still exists, took me almost half a day to figure this one out, tried different npm/node versions to no avail. Finally moved the whole project to a different folder and it all magically started to work. I think it would be worth reopening this one and taking a second look at escaping ! in the path.

Sorry about it... Also took me some time. Hope it will save people some time in the future. Just abandoned "!" paths.
Good luck

This still exists, took me almost half a day to figure this one out, tried different npm/node versions to no avail. Finally moved the whole project to a different folder and it all magically started to work. I think it would be worth reopening this one and taking a second look at escaping ! in the path.

I am having the same issue,dont know this ! path.Can anyone help me out for this


JS error after image selection in file finider: TypeError: c.process is not a function

Hi @orthes ,
I get "TypeError: c.process is not a function" in my web console once I select an image to upload. Any pointers on how I can resolve this?
Thanks

I've never encountered this problem. Can you reproduce it on https://jsfiddle.net/?

This issue is fairly old and there hasn't been much activity on it. Closing, but please re-open if it still occurs.


Tony branch

Added functionality to create an Equity Curve based on D3.js. Cleaned up code and added more comments to explain functionality.

approve


Document "magic" file names picked up by MSBuild: Directory.build.props, *.sln.targets, etc

There should be documentation on all file names recognized by MSBuild that are auto-included if present on disk, but never explicitly mentioned.
Examples that I know of:

Directory.Build.props
Directory.Build.targets
.sln.targets
Before..sln.targets (??)

File names and file locations. Guessing it's not well known that MSBuild will also import these files from user locations. This is all the known ways that we have found they are imported
https://github.com/dotnet/roslyn/blob/master/src/Workspaces/CoreTestUtilities/Resources/Directory.Build.props

There are target files you can apply to SLN files? What does that do?

Those targets run once before/after all the projects in the solution, very useful but hidden feature.

Feedback on MicrosoftDocs/visualstudio-docs#816 would be great: anything I missed? Got more questions about these mechanisms?

@rainersigwald overall looked good. Added some feedback.
One set of items I didn't see documented there was essentially all of the stuff listed in this file.
https://github.com/dotnet/roslyn/blob/master/src/Workspaces/CoreTestUtilities/Resources/Directory.Build.props
I actually don't even know if these are valid extension points or if I'm disabling the properly. IIRC I essentially did a /pp on a build, looked for every Import.*Before/After and added a disable.

Looks good, just added some nit comments

docs PR closed. Thanks, folks--please continue to request documentation as you see the need for it!


Add quotes for PHP versions

Just one question: Why? :-)

Oh my sorry for the rogue merge.
Short story long, because otherwise version numbers are interpreted as numbers instead of strings and could be an issue in some cases; documenting it without quotes was a mistake on Travis part.
For the longer version see https://github.com/api-platform/core/pull/449#discussion_r55392343


Rewrite RedundantPar functionally

Title is self explanatory

We decided that the code was less readable when written functionally.


private method `open' called for URI:Module

we receive this error when we use tmethod upload_video in account.rb

Hmm, we should support that, if we still want to support Ruby 2 @justinhoward
Related to https://github.com/nullscreen/yt/pull/412

@kangkyu It seems like there is still a lot of community support for Ruby 2.6+ or Ruby 2.7+, but if it feels like a burden to drop support for those, it seems like reasonable decision.


Consolidation Issue for open points release management

Problem description
Currently, there are several open issues (7 in total) which touch the topic of release management, and some are even duplicates.
Expected action
This issue will provide a consolidated view of all open issues for release management under commonalities.  This will help the TSC to address the topic in a more structured way.
Under this issue, contributors are also requested to nominate themselves if they would like to participate in the release management concept work that will be undertaken in the TSC. Would be very useful if you could also specify if you wish to be an active contributor or just a reviewer, or both (depending on your interests and the time you can spend on the topic).
Additional context
Current open issues and categories:

API Versioning (Alpha/Beta vs Semantic...)
https://github.com/camaraproject/Commonalities/issues/36
https://github.com/camaraproject/Commonalities/issues/25

API Family versioning
https://github.com/camaraproject/Commonalities/issues/60

Release Branches
https://github.com/camaraproject/Commonalities/issues/66

API Release 1.0 and general conformance
https://github.com/camaraproject/Commonalities/issues/12
https://github.com/camaraproject/Commonalities/issues/63#issuecomment-1729293667
https://github.com/camaraproject/Commonalities/issues/13

Camara-wide release
Though there are no open issues on this topic, it has been discussed on several occasions in commonalities.

Do you think this PR is potentially related to this topic as well -  Define mandatory end points URL in each project
#63?
My thinking is that it could be since it is related to "conformance" - i.e., when is an API conformant if it only implements a subset of the endpoints? What should be the behaviour when not all endpoints are implemented.

Thanks @shilpa-padgaonkar! I volunteer to contribute and review ... it's a very important topic for CAMARA.
Another issue with input the topics 1-4: https://github.com/camaraproject/Governance/issues/85. Another point to add would be "Step-by-step instructions to create a release within a sub-project", plus potential tooling to automate/enforce these.

Thanks @shilpa-padgaonkar - also related,
Governance#95: Automate API design tests to ensure CAMARA compliance

Some questions derived from the issue consolidation:

Do we need a Camara wide release? If yes, how often?
Do we need another explicit API Family versioning?
API versioning: Semantic versus Alpha-Beta style
What are the important aspects to decide Camara conformance?

Please feel free to extend this list

Thanks @shilpa-padgaonkar
Completely aligned to prepare this discussion.
I'm fine with this list. The Camara Conformance is a huge topic and perhaps we have to split it in several pieces:

What will be targeted to conformance (endpoint ? attribute?)
How we describe this conformance (test collection? md document?)
How we loop with Open Gateway Product stream ? We should agreed conformance with them when they were at the origin of the API.
How we loop with GSMA that will 'run' effectively the conformance test?

I agree @bigludo7 -

How we loop with GSMA that will 'run' effectively the conformance test?

I would just say 'How we align with GSMA certification', which are additional tests.
CAMARA releases should be automatically checked (GitHub Actions) for OAS 3.0.x conformance, conformance against a linting ruleset based on Commonalities API Design Guidelines, and (I think) a 'Security by design' check which can detect intrinsic vulnerabilities.
Then when the API is implemented, the GSMA certification tests can check that the implemented API matches the CAMARA release, and other tests (including performance) that may be required.

On the fact that we are planning to do release mgmt for "API families". Unless there is any specific advantage to do this,
I think we should not mix working groups with release mgmt. Working groups is about the definition of the API. IMHO only the outputs of teh work groups should fall under release mgmt (especially as API families are sort of "arbitrary, can change name, etc.). and it adds a level of complexity.
Also what would be the criteria to do a "CAMARA wide release" ? is it to release every e.g. 3 months the latest version of all stable APIs. ?
for an example look at the 3GPP API forge - especially the readme part, and maybe discuss with the person doing the maintenance as it is quite well done IMHO, and including the automated linting pipeline etc..  - see https://forge.3gpp.org/rep/all/5G_APIs

Signing up as an active contributor to this work item (based on Shilpa's request to make an explicit note).

Yes please add me to 'active contributor' :D

Hi @shilpa-padgaonkar , great initiative to start this structured way of addressing - thank you!
I would like to be a reviewer for 'API Release 1.0 and general conformance' section please - this is a huge topic in of itself and a good one.
cc: @gmuratk

5. Camara-wide release
Though there are no open issues on this topic, it has been discussed on several occasions in commonalities.

There is no issue for that, but already a paragraph within the ProjectStructureAndRoles.md:

Each Sub Project shall have a release management. The release cadence shall be determined by the TSC and on a regularly published schedule. Milestones shall be set up within each Sub Project to ensure the ability of each Sub Project to meet the release schedule as defined by the TSC.
Goal is that all Sub Projects updated are released at the same release milestone so that the implementors of the APIs become accustomed to the regular release cadence.

Sharing here Ericsson’s current thinking on some aspects of this topic. This thinking is based on the discussion in TSC on Oct 19, 2023 (PR to MoM). This input could be considered by @hdamker / DT when preparing the release management proposal.

We think applying semantic versioning (semver) at the “endpoint / API” level makes perfect sense but semver at API Family / CAMARA APIs is not needed.

We do not understand what benefit versioning “API Family” brings. In fact, we think applying semantic versioning to the “API Family” or “CAMARA APIs” is misleading. The rationale for this is, on this "group" level, using semver provides no additional information about what has changed in the underlying specifications. Perhaps a date / quarter+year / or simply a sequential number approach makes more sense to version "grouped" things for periodicity / marketing purposes. (Note that this thinking is largely aligned with @tanjadg’s view above).

As the TSC MoM notes, the notion of an “API Family” is confusing. While discussion the topic, it became obvious that even the notion of an “API” is currently not formalized in CAMARA and is used differently by different API subprojects. It would be good to formalize with some written text what we mean by an API.

In our best understanding, an “endpoint” is an API that will have semver based versioning. And the characteristic of the endpoint is that the “top-level” / “base path” name is unique across all CAMARA APIs.

We agree with the TSC proposal that there are either “released /stable” APIs or “work-in-progress” APIs (and here we mean the specification part of the work – see below for more). Hence, we do not need alpha / beta etc. in the versioning phases. The current proposal suggests using “alpha” to denote the “work in progress” status. We have seen that some API subprojects are using “wip” instead of “alpha” which is more reflective of the situation. While result would be the same regardless of “wip” or “alpha”, we prefer “wip”.

What is a “release” and when does it occur? Semver tracks major/minor changes since recent released state – therefore, knowledge of what released and when as well and when next release will happen is very important for API versioning.

Once the API subproject “releases” a (candidate) version, it then must go to the “readiness tests”. There could presumably be error corrections that are identified during the tests. A mechanism for error correction would be ideal to setup already in the beginning. Perhaps in addition to “wip” stage, we also need an “rc” phase?

Should CAMARA also propose a deprecation policy for the versioned API endpoints. If over time, an API has 3 or 4 or 5 versions and different providers implement different versions, it would make interoperability a big challenge. This could presumably be solved by specifying a minimum/maximum number of allowed parallel “stable versions” as well as guidelines for duration on deprecation.

We think periodic CAMARA level releases make sense for two reasons – one to set a cadence for the various working groups and second for marketing purposes. The comment/link above from @hdamker seems to echo this view (link. 3GPP seems to work in a similar way and some of those learnings could be adopted in to CAMARA. Linux foundation may have its own mechanisms which could be explored too.

There is now the new repository https://github.com/camaraproject/ReleaseManagement as agreed within the last TSC meeting. To collaborate there on Release Management for CAMARA and its sub projects kindly subscribe to the mailing list https://lists.camaraproject.org/g/release, e.g. by sending a mail to<EMAIL_ADDRESS>Consider also to volunteer as a maintainer within the new working group by commenting on https://github.com/camaraproject/ReleaseManagement/issues/1

@shilpa-padgaonkar @rartych would it be ok to transfer this issue here over to the new repository? Which other issues should be transfered with it? All the ones listed above?

@rartych Any update on my question above?

@hdamker I am sorry for lack of earlier response.
I think that all issues labeled with release management label can be transferred  to Release Management repository.


c. Clone the mmdetection repository. Not working.

I open up the Anaconda Prompt, everything goes fine until I reach
`c. Clone the mmdetection repository.
git clone https://github.com/open-mmlab/mmdetection.git
cd mmdetection`
Then I get this error
(open-mmlab) C:\user\Scott\c. Clone the mmdetection repository.
git clone https://github.com/open-mmlab/mmdetection.git
'git' is not recognized as an internal or external command, operable program or batch file.

It is irrelevant to the codebase but the environment. 1. git is not installed in your environment. 2. windows is not officially supported.


I don't see the chart, but just the nodes as text

Trying to implement sankey to the latest version of Angular. I followed this gist, but the only thing I get is the Nodes in plain text instead of the graph.
I made a plunker with a minimum installation to reproduce the issue
Short story,
I import the libraries on my component:
    import * as d3 from 'd3';
    import * as d3Sankey from 'd3-sankey';

Called a DrawChart() on ngOnInit:
    ngOnInit() {
          this.DrawChart();
    }

Implement the DrawChart() function:
    private DrawChart() {

                var svg = d3.select("#sankey"),
                    width = +svg.attr("width"),
                    height = +svg.attr("height");

                var formatNumber = d3.format(",.0f"),
                    format = function (d: any) { return formatNumber(d) + " TWh"; },
                    color = d3.scaleOrdinal(d3.schemeCategory10);

                var sankey = d3Sankey.sankey()
                    .nodeWidth(15)
                    .nodePadding(10)
                    .extent([[1, 1], [width - 1, height - 6]]);

                var link = svg.append("g")
                    .attr("class", "links")
                    .attr("fill", "none")
                    .attr("stroke", "#000")
                    .attr("stroke-opacity", 0.2)
                    .selectAll("path");

                var node = svg.append("g")
                    .attr("class", "nodes")
                    .attr("font-family", "sans-serif")
                    .attr("font-size", 10)
                    .selectAll("g");

                d3.json("../../../assets/vendors/uk2015.json", function (error, energy: any) {
                    if (error) throw error;

                    sankey(energy);

                    link = link
                        .data(energy.links)
                        .enter().append("path")
                        .attr("d", d3Sankey.sankeyLinkHorizontal())
                        .attr("stroke-width", function (d: any) { return Math.max(1, d.width); });

                    link.append("title")
                        .text(function (d: any) { return d.source.name + " → " + d.target.name + "\n" + format(d.value); });

                    node = node
                        .data(energy.nodes)
                        .enter().append("g");

                    node.append("rect")
                        .attr("x", function (d: any) { return d.x0; })
                        .attr("y", function (d: any) { return d.y0; })
                        .attr("height", function (d: any) { return d.y1 - d.y0; })
                        .attr("width", function (d: any) { return d.x1 - d.x0; })
                        .attr("fill", function (d: any) { return color(d.name.replace(/ .*/, "")); })
                        .attr("stroke", "#000");

                    node.append("text")
                        .attr("x", function (d: any) { return d.x0 - 6; })
                        .attr("y", function (d: any) { return (d.y1 + d.y0) / 2; })
                        .attr("dy", "0.35em")
                        .attr("text-anchor", "end")
                        .text(function (d: any) { return d.name; })
                        .filter(function (d: any) { return d.x0 < width / 2; })
                        .attr("x", function (d: any) { return d.x1 + 6; })
                        .attr("text-anchor", "start");

                    node.append("title")
                        .text(function (d: any) { return d.name + "\n" + format(d.value); });
                });
            }

        }

No error on console or something that will point me to the right direction.

you can console.log(energy) to help you debug

Please use Stack Overflow tag d3.js to ask for help. Stack Overflow provides a better collaborative forum: thousands of D3-related questions have been asked there, and some answers may be relevant to you.
When asking for help, please include a link to demonstrate the issue, preferably as an Observable notebook. It is often impossible to debug from code snippets alone. Isolate the issue and reduce your code as much as possible before asking for help. The less code you post, the easier it is for someone to debug, and the more likely you are to get a helpful response.
If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.
Thank you! 🤗

Increase the canvas height.


npm install fails again

Seems a nan breaking change again:
$ npm install sleep
|
><EMAIL_ADDRESS>install /private/tmp/node_modules/sleep
> node-gyp rebuild

  CXX(target) Release/obj.target/node_sleep/sleep.o
In file included from ../sleep.cc:2:
In file included from ../node_modules/nan/nan.h:2104:
../node_modules/nan/nan_weak.h:363:42: error: cannot create a non-constant pointer to member function
    v8::PersistentBase<T>::SetWeak(wcbd, wcbd->invoke);
                                         ^~~~~~~~~~~~
../node_modules/nan/nan_object_wrap.h:56:18: note: in instantiation of function template specialization
      'Nan::Persistent<v8::Object, v8::NonCopyablePersistentTraits<v8::Object> >::SetWeak<Nan::ObjectWrap>' requested here
    persistent().SetWeak(this, WeakCallback, WeakCallbackType::kParameter);
                 ^
In file included from ../sleep.cc:2:
In file included from ../node_modules/nan/nan.h:2104:
../node_modules/nan/nan_weak.h:378:42: error: cannot create a non-constant pointer to member function
    v8::PersistentBase<T>::SetWeak(wcbd, wcbd->invoke);
                                         ^~~~~~~~~~~~
2 errors generated.
make: *** [Release/obj.target/node_sleep/sleep.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:269:23)
gyp ERR! stack     at ChildProcess.emit (events.js:110:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1074:12)
gyp ERR! System Darwin 13.4.0
gyp ERR! command "node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /private/tmp/node_modules/sleep
gyp ERR! node -v v0.12.7
gyp ERR! node-gyp -v v2.0.1
gyp ERR! not ok
npm ERR! Darwin 13.4.0
npm ERR! argv "node" "/usr/local/bin/npm" "install" "sleep"
npm ERR! node v0.12.7
npm ERR! npm  v2.11.3
npm ERR! code ELIFECYCLE

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

npm ERR! Please include the following file with any support request:
npm ERR!     /private/tmp/npm-debug.log

$ npm version
{ npm: '2.11.3',
  http_parser: '2.3',
  modules: '14',
  node: '0.12.7',
  openssl: '1.0.1p',
  uv: '1.6.1',
  v8: '<IP_ADDRESS>',
  zlib: '1.2.8' }

Mac OS 10.9.5

Same here :/
{ npm: '2.7.4',
http_parser: '2.3',
modules: '14',
node: '0.12.2',
openssl: '1.0.1m',
uv: '1.4.2-node1',
v8: '3.28.73',
zlib: '1.2.8' }

This is fixed as as<EMAIL_ADDRESS>is released....

Perfect, now it works :D


[FLINK-17445][State Processor] Add Scala support for OperatorTransformation

What is the purpose of the change
Currently there's no way to use a Scala DataSet with the OperatorTransform object. This PR adds support for the Scala DataSet in this part of the state processor API.
Brief change log
(for example:)

Created new scala module, flink-state-processing-api-scala
Mirrored OperatorTransform's bootstrapWith method to accept a Scala DataSet

Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): yes
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Also, the build is failing due to missing license headers and checkstyle issues. If you run mvn verify from within flink-state-processing-api-scala locally you can check these issues.

@sjwiesman Thank you for the thorough review I really appreciate it. I'll make the advised changes / clean up and get back.

Scala APIs are deprecated and will not be further extended.


Crashing when open Offline Edit Menu

Checklist

[x] Bug Report - The issue you are reporting might be there already. Please search on the issues tracker before creating or reporting a issue.
[ ] Before reporting, please ensure (if you can) that you have tested it with the latest (dev) version of the software.

Summary:
Crashing app when Open Offline Edit Menu
Steps to reproduce:
How can we reproduce the issue?
Expected behavior:
What did you expect the app to do?
App must me open Offline Edit
Observed behavior:

Device and Android version:
Android Emulator API 26
Screenshots:

Please review issue @nicolasleger

@nicolasleger is not working on the Android app

Could you give more details about it like stack trace? And are you able to reproduce it?


Improve C scanner conditional inclusion

Simplistic macro replacement is now done on the contents of CPPDEFINES, to improve accuracy of conditional inclusion as compared to the real preprocessor (ref: issue #4623).  The replacement will happen for both the Conditional and the original C scanner, but since the original does not attempt to process the logic around conditional includes, it will simply have no effect on it.  EDITED: now only applied to Conditional scanner.
This should have no doc impacts: we don't say how scanners determine implicit dependencies, so a small tweak to that process is more like a bugfix.
Contributor Checklist:

[X] I have created a new test or updated the unit tests to cover the new/changed functionality.
[X] I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
[X] I have updated the appropriate documentation

Seems like this could have significant performance impact? And really it's only impacting the conditional C scanner?

Seems like this could have significant performance impact? And really it's only impacting the conditional C scanner?

For the vast majority of cases, it's a single iteration over the dict made from CPPDEFINES. Doesn't seem that expensive.  If there are replaceable elements, it will make as many additional passes as needed. As noted (somewhere...), this could be guarded by a flag, or moved to the conditional scanner - although it's a little bit more awkward to implement there.

I'd say 5 loops is sufficient, I'd definitely note this in the release/changes.
as long as it doesn't impact regular c scanner.
I'd even say make two versions of the function so it can't affect regular c scanner.
Since the scanner gets hit very hard in a decent sized build.

One solution is to keep a dictionary of the initial value and the processed values.  If the processed value is in the dictionary before adding it, then a cycle is detected.
If a cycle is detected, there is a question of which value should be returned.  One school of thought is the "prior value" before the cycle (i.e., the most "forward" progress).
This technique was used in my own work for multiple levels of environment variable substitution which is effectively the same problem.

Yes, of course there are ways to detect it (and thanks for the note!!).  Trying to keep it lightweight, at the moment... a cycle should be a super-uncommon case. I hope.

A Thanksgiving gift.
Bugs likely, feel free to ignore.
from typing import Dict

### PR IMPLEMENTATION

def _replace(mapping: Dict) -> Dict:
    old_ns = mapping
    loops = 0
    while loops < 5:  # don't recurse forever in case there's circular data
        ns = {k: old_ns[v] if v in old_ns else v for k, v in old_ns.items()}
        if old_ns == ns:
            break
        old_ns = ns
        loops += 1
    return ns

### ALTERNATE IMPLEMENTATION

def _replace_alternate(mapping: Dict) -> Dict:

    # Depth-first replacement.
    # Cache intermediate replacement results.

    replace_list = []
    resolved_map = {}

    for key, val in mapping.items():
        if val in mapping and val != key:
            replace_list.append((key,val))
        else:
            resolved_map[key] = val

    if replace_list:

        mapping = dict(mapping)  # modified copy (necessary?)

        for key, val in replace_list:

            if key in resolved_map:
                mapping[key] = resolved_map[key]
                continue

            expansion_state = [val]
            expansion_seen = set()

            while val in mapping:

                if val in resolved_map:
                    val = resolved_map[val]
                    break

                if val in expansion_seen:
                    # cycle detected
                    _ = expansion_state.pop()
                    val = expansion_state[-1]
                    break

                val_key = val
                val = mapping[val_key]

                expansion_state.append(val)
                expansion_seen.add(val_key)

            for resolved_key in expansion_state:
                resolved_map[resolved_key] = val

            mapping[key] = val

    return mapping

### TESTING

for CPPDEFINES, expect in [
    (
        # no replacements
        [("STRING1", "VALUE1"), ("STRING2", "VALUE2"), ("STRING3", "VALUE3")],
        {"STRING1": "VALUE1", "STRING2": "VALUE2", "STRING3": "VALUE3"},
    ),
    (
        # single replacement
        [("STRING", "VALUE"), ("REPLACEABLE", "RVALUE"), ("RVALUE", "AVALUE")],
        # Alternate algorithm replacement steps:
        #   [REPLACEABLE] RVALUE -> AVALUE
        {"STRING": "VALUE", "REPLACEABLE": "AVALUE", "RVALUE": "AVALUE"},
    ),
    (
        # multiple replacements
        [("AAA", "XXX"), ("BBB", "YYY"), ("CCC", "VALUE1"), ("DDD", "VALUE2"), ("XXX", "DDD"), ("YYY", "CCC")],
        # Alternate algorithm replacement steps:
        #   [AAA] XXX -> DDD -> VALUE2
        #   [BBB] YYY -> CCC -> VALUE1
        #   [XXX] VALUE2
        #   [ZZZ] VALUE1
        {"AAA": "VALUE2", "BBB": "VALUE1", "CCC": "VALUE1", "DDD": "VALUE2", "XXX": "VALUE2", "YYY": "VALUE1"},
    ),
    (
        # cycles
        [("ABC", "DEF"), ("DEF", "GHI"), ("GHI", "ABC"), ("XXX", "YYY"), ("YYY", "ZZZ"), ("ZZZ", "DEF")],
        # Algorithm replacement steps:
        #   [ABC] DEF -> GHI -> ABC
        #   [DEF] ABC
        #   [GHI] ABC
        #   [XXX] YYY -> ZZZ -> DEF -> ABC
        #   [YYY] ABC
        #   [ZZZ] ABC
        {"ABC": "ABC", "DEF": "ABC", "GHI": "ABC", "XXX": "ABC", "YYY": "ABC", "ZZZ": "ABC"},
    ),

]:
    mapping = {k: v for k, v in CPPDEFINES}

    rval_scons = _replace(mapping)
    if rval_scons == expect:
        print("SCONS PASS")
    else:
        print("SCONS FAIL", rval_scons)

    rval_cycle = _replace_alternate(mapping)
    if rval_cycle == expect:
        print("CYCLE PASS")
    else:
         print("CYCLE FAIL", rval_cycle)

Observations
There is an asymetric difference in behavior between backward references (i.e., a value refers to an earlier key) compared to forward references (i.e., a value refers to a later key).
For example:

Best case - backward references (8 entries: 1 iteration):
mapping8BC = {
    "A": "0",
    "B": "A",
    "C": "B",
    "D": "C",
    "E": "D",
    "F": "E",
    "G": "F",
    "H": "G",
}

Loop               0     1
-------------     ---   ---
mapping8BC["A"] =  0  =  0
mapping8BC["B"] = "A" =  0
mapping8BC["C"] = "B" =  0
mapping8BC["D"] = "C" =  0
mapping8BC["E"] = "D" =  0
mapping8BC["F"] = "E" =  0
mapping8BC["G"] = "F" =  0
mapping8BC["H"] = "G" =  0

Worst case: forward references (8 entries: 3 iterations):
mapping8WC = {
    "A": "B",
    "B": "C",
    "C": "D",
    "D": "E",
    "E": "F",
    "F": "G",
    "G": "H",
    "H": 0,
}

Loop               0     1     2     3
-------------     ---   ---   ---   ---
mapping8WC["B"] = "C" = "D" = "F" =  0
mapping8WC["C"] = "D" = "E" = "G" =  0
mapping8WC["D"] = "E" = "F" = "H" =  0
mapping8WC["E"] = "F" = "G" =  0  =  0
mapping8WC["F"] = "G" = "H" =  0  =  0
mapping8WC["G"] = "H" =  0  =  0  =  0
mapping8WC["H"] =  0  =  0  =  0  =  0

For every loop variable value N (i.e., the initial value of variable loops), trails of forward references with a length greater than 2N will not be fully resolved (i.e., the loop count is exceeded but there is not a cycle).
While exiting due to exceeding the loop count due to a cycle is the most likely reason, it is not guaranteed.
In the post above,

Experiments 10, 20, and 21 have cycles.
Experiment 19 has a forward reference trail of length 33.

The current and modified algorithms in the post above exceed the loop count for experiments 10, 19, 20, 21.  Timing comparisons to the alternative algorithm for these four experiments are not necessarily meaningful.
Algorithms
The results for python versions 3.7 to 3.11 are very different from the results for python version 3.12.
For python versions prior to 3.12, the modified algorithm appears to be faster than the current algorithm in most all cases.
The three algorithms in the post above are:

Current algorithm:
The equality test condition is likely most expensive when the two dictionaries are equal.
Exiting due to the loop count means that:

there are one or more cycles, and/or
there are one or more trail lengths of forward references greater than 2NLoops.

def _replace(mapping: Dict) -> Dict:
    old_ns = mapping
    loops = 0
    while loops < 5:  # don't recurse forever in case there's circular data
        ns = {k: old_ns[v] if v in old_ns else v for k, v in old_ns.items()}
        if old_ns == ns:
            break
        old_ns = ns
        loops += 1
    return ns

Modified algorithm:
Replace the dictionary comprehension and equality test with a loop and boolean exit condition.
Exiting due to the loop count means that:

there are one or more cycles, and/or
there are one or more trail lengths of forward references greater than 2NLoops.

def _replace_mod(mapping: Dict) -> Dict:
    old_ns = mapping
    loops = 0
    while loops < 5:  # don't recurse forever in case there's circular data
        again = False
        ns = {}
        for k, v in old_ns.items():
            if v in old_ns:
                ns[k] = old_ns[v]
                if not again and ns[k] != v:
                    again = True
            else:
                ns[k] = v
        if not again:
            break
        old_ns = ns
        loops += 1
    return ns

Alternate algorithm:
Cycles are detected.
Long chains of backward references might be slower than the modified algorithm.
def _replace_alt(mapping: Dict) -> Dict:

    replace_list = []
    resolved_map = {}

    for key, val in mapping.items():

        if val not in mapping:
            resolved_map[key] = val
        elif val != key:
            replace_list.append((key,val))
        else:
            # cycle (self-referential)
            resolved_map[key] = val

    if not replace_list:

        mapping = resolved_map

    else:

        mapping = dict(mapping)

        for key, val in replace_list:

            if val in resolved_map:
                mapping[key] = resolved_map[val]
                continue

            replace_seen = set()
            replace_trail = [val]

            while val in mapping:

                nextval = mapping[val]
                if nextval in resolved_map:
                    val = resolved_map[nextval]
                    break

                replace_seen.add(val)
                if nextval in replace_seen:
                    # cycle detected
                    val = replace_trail[-1]
                    break

                replace_trail.append(nextval)
                val = nextval

            for resolved_key in replace_trail:
                resolved_map[resolved_key] = val

            mapping[key] = val

    return mapping

Current algorithm versus modified algorithm
Profiling measurements are suspect.
The "faster" algorithm is shown in the table.  The color indicates the relative magnitude of the difference.
Table colors:

${\normalsize{\color{#30BA8F}0.0 <= abs(relative\ error) < 10.0}}$
${\normalsize{\color{#FFCF48}10.0 <= abs(relative\ error) < 20.0}}$
${\normalsize{\color{#CB4154}20.0 <= abs(relative\ error)}}$
${\normalsize{\color{#979AAA}current\ and\ modified\ exceeded\ loop\ count}}$

The relative error percentage for comparing the current and modified algorithms is:

relative error percentage = ((current - modified) / modified) * 100.0

Test
3.7
3.7
3.8
3.8
3.9
3.9
3.10
3.10
3.11
3.11
3.12
3.12

01
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

02
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}CUR}}$

03
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

04
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

05
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

06
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

07
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

08
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

09
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}mod}}$

10
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

11
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

12
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

13
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

14
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$

15
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

16
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

17
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

18
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}CUR}}$

19
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

20
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

21
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

Current algorithm versus modified algorithm
Profiling measurements are suspect.  Fastest algorithm shown in table.
The relative error percentage for comparing the current and modified algorithms is:

relative error percentage = ((current - modified) / modified) * 100.0

Table colors:

${\normalsize{\color{#30BA8F}0.0 <= abs(relative\ error) < 10.0}}$
${\normalsize{\color{#FFCF48}10.0 <= abs(relative\ error) < 20.0}}$
${\normalsize{\color{#CB4154}20.0 <= abs(relative\ error)}}$
${\normalsize{\color{#979AAA}current\ and\ modified\ exceeded\ loop\ count}}$

Test
3.7
3.7
3.8
3.8
3.9
3.9
3.10
3.10
3.11
3.11
3.12
3.12

01
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

02
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}CUR}}$

03
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

04
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

05
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

06
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

07
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

08
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

09
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}mod}}$

10
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

11
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

12
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

13
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

14
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$

15
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$

16
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

17
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#CB4154}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$

18
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#30BA8F}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#FFCF48}mod}}$
${\normalsize{\color{#30BA8F}CUR}}$
${\normalsize{\color{#30BA8F}CUR}}$

19
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

20
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

21
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}mod}}$
${\normalsize{\color{#979AAA}CUR}}$
${\normalsize{\color{#979AAA}CUR}}$

Boy, that's a lot. Sadly, with the winter sun shining in my window causing glare, the colors don't really stand out, plus something didn't render in the last row of the last table.
Is there a "short summary" version of all this?

What do you mean by relative error? What metrics are you using for this calculation? time? other?

All of this is much ado about nothing.

Boy, that's a lot. Sadly, with the winter sun shining in my window causing glare, the colors don't really stand out, plus something didn't render in the last row of the last table.

I'm going to delete the content for the previous post until I can figure out how to handle it correctly.  Abusing inline latex for colors again.  Somewhere, I have code to generate html tables. Sigh.
Initially, the last row didn't render here but refreshing the page "fixed" it.  Go figure.

Is there a "short summary" version of all this?

Notes:

The relative timing changes with python 3.12.
The modified version of the PR is usually faster than the existing version by avoiding the dictionary comparison and putting a boolean flag in the loop replacement for the comprehension.
The alternate version is usually faster than the existing version.
The alternate version and modified version reasonably competitive based on the input data configurations (e.g., backward references favor the current/modified algoriths).
The alternate version detects cycles and always terminates.

The modified version is simple and easy to understand.
The alternate version detects cycles and does not have trail length limitations but is more involved.
In the end, the timing differences per invocation are REALLY small.

What do you mean by relative error? What metrics are you using for this calculation? time? other?

Total elapsed time.
    def profile(func, mapping, ncalls=NINVOCATIONS, gcenabled=True):
        gc.collect()
        if not gcenabled:
            gc.disable()
        rval = None
        begtime = time.perf_counter()
        while ncalls > 0:
            ncalls -= 1
            rval = func(mapping)
        endtime = time.perf_counter()
        if not gcenabled:
            gc.enable()
        gc.collect()
        elapsed = endtime - begtime
        return rval, elapsed

The relative error percentage for comparing the current and modified algorithms using total elapsed time is:

relative error percentage = ((total_elapsed_current - total_elapsed_modified) / total_elapsed_modified) * 100.0

Notes:
* The relative timing changes with python 3.12.

Well, the project to substantially speed up Python (that brought Guido out of a brief retirment) landed its first bits for 3.12, 3.13 might make another difference.  All depends on what code paths we hit... differences between versions aren't unusual when I've done other benchmarking - including sometimes things got slower for a release or two!

* The modified version of the PR is usually faster than the existing version by avoiding the dictionary comparison and putting a boolean flag in the loop replacement for the comprehension.

that might be worthwhile... although comprehensions shouldn't normally be slower than an unrolled loop...

that might be worthwhile... although comprehensions shouldn't normally be slower than an unrolled loop...

It is not the loop that is slower; it is the comparison for equality following the loop.  I would think that the worst-case performance of the dictionary comparison is when they are equal (i.e., all elements compared).
By unrolling the comprehension, a flag can be set if the old and new values are different indicating another iteration is necessary.  Once the flag is set, there is no need to compare the values anymore.  There comparisons only take place when writing to keys in which the values need to be resolved.

that might be worthwhile... although comprehensions shouldn't normally be slower than an unrolled loop...

It is not the loop that is slower; it is the comparison for equality following the loop. I would think that the worst-case performance of the dictionary comparison is when they are equal (i.e., all elements compared).
By unrolling the comprehension, a flag can be set if the old and new values are different indicating another iteration is necessary. Once the flag is set, there is no need to compare the values anymore. The comparisons only take place when writing to keys in which the values need to be resolved.

right, makes sense.

Thanks @jcbrill  and @mwichmann - merging!

Thanks for the good work here @mwichmann  & @jcbrill !