Spine Two-Color Tint Bug

axmol version: 2.1.2
devices test on: M1 Macbook Pro
developing environments

Xcode version: 15.2
cmake version: 3.29.0

Steps to Reproduce:

After getting the Axmol project building and running on M1 Macs, update the Spine runtimes to the latest version off GitHub.
Add the Spine Cocos2d-x runtimes examples into the new Axmol project, and use the Spine Cocos2d-x runtimes AppDelegate.h instead of the one packaged with Axmol.
Change line # 60 from auto glview = director->getOpenGLView(); to auto glview = director->getGLView(); and line # 65 from director->setOpenGLView(glview); to director->setGLView(glview);
To better see this issue change line # 107 of AppDelegate.cpp from director->setAnimationInterval(1.0f / 60); to director->setAnimationInterval(1.0f); (This gives us longer to see the first frame failing to render properly.)
In AppDelegate.cpp include "RaptorExample.h", un-comment line # 113 and then comment out line # 114, this way the AppDelegate loads up directly into the example that uses two-color tinting.
Add the following lines to the RaptorExample.cpp before it's added as a child (e.g. between lines # 53 and # 54): skeletonNode->setDebugBonesEnabled(true); skeletonNode->setDebugMeshesEnabled(true); (This shows that the skeleton is loaded and should be rendered on the first frame, but isn't while two-color tint is enabled.)
Run the project on your arm64 Mac, and observe that the Spine-boy Raptor skeleton doesn't render anything except the debug bones and meshes for the first frame, and then renders correctly after that.
For posterity, comment out line # 52 of the RaptorExample.cpp class to disable two-color tinting here, and then re-build and re-run the project, observe that this time the Spine-boy Raptor skeleton properly renders on the first frame, as well as subsequent frames.

This bug also exists in Cocos2d-x v4.0, but not Cocos2d-x v3.17.2, likely due to all the Renderer, GL, and Shader changes made to support Metal on Apple devices.
I've submitted a bug report to the Esoteric Software team as well, but it's very possible that their fix will need to be back ported to Axmol from Cocos2d-x (it'd be nice if they started supporting Axmol officially since Cocos2d-x is dead, but I don't see that happening anytime soon).
I will mention that in my use case it sometimes takes 24 frames or more before the skeleton renders for the first time, and not a single frame like the repro steps I provided.
I've played around with trying to update the skeleton, and the SkeletonTwoColorBatch with deltaTime = 0.0f, I've tried to force flush for the lastTwoColorTrianglesCommand on each draw, I've tried disabling culling, setting the skeleton to its setup pose, and updating its world transforms, but nothing solves the issue.
This does bring up two additional Spine related bugs:

The version of Spine packaged with Axmol contains the following bug, and should be updated the latest source code from GitHub to fix this bug. This is a critical issue that causes the game to crash when attempting to load a skeleton that contains mesh deformations (which was a headache I had to deal with last week).
CC_USE_CULLING is used in the SkeletonRenderer.cpp code for the Spine Cocos2d-x runtimes, and thus the Axmol runtimes without modifications, but CC_USE_CULLING is never defined to be an alias for AX_USE_CULLING. This causes the Spine runtimes to ignore the Axmol AX_USE_CULLING config option in the Configs.h file.

You means update to 4.1 branch: https://github.com/EsotericSoftware/spine-runtimes/tree/4.1

Okay I just triple checked and in Axmol the commit that updates the Spine runtimes to 4.1-54fac9d was done on February 26th of this year, and the 2.1.2 Axmol Release was cut on February 24th of this year. I got Axmol from the 2.1.2 release: so that explains why I had the bug until I updated the runtimes.

Why reopen, does this issue still require any changes?

Why reopen, does this issue still require any changes?

I only closed it by accident. The main issue for this still exists, and that is that the two-color tint bug with Spine Skeletons that I outlined with the majority of this bug report.

An update on this bug report.
The team behind Spine, Esoteric Software investigated the issue and are pushing the fix back to the maintainers of Cocos2d-x (and/or it's forks, i.e. Axmol). They say that the Spine runtimes are working properly based on their findings and that the issue is with the Cocos2d-x two-color tint renderer itself.
I've copy and pasted badlogic's response below for brevity:

Two-color tinting is implemented with a custom batcher (SkeletonTwoColorBatch.cpp) which submits custom commands (TwoColorTrianglesCommand) to the Cocos2d-x renderer.
Following the repro steps for the RaptorExample, I've confirmed that on the first frame, the SkeletonRenderer actually submits render commands to the batcher, which submits them to the Cocos2d-x Renderer, which you can see here:

This happens in CCRenderer.cpp:371. These submitted commands are ultimately processed in Renderer::processRenderCommand()

I can also confirm that the commands are submitted to the GPU:

In subsequent frames, the exact same code paths are executed, but result in the commands actually being rendered.
Another indicator that we do everything correctly is that in our example, the Cocos2d-x backend reports the number of vertices and draw calls correctly for the first frame, despite nothing being rendered.

The second issue you described might well be a "follow-on" error from the original issue that causes the first frame not to be drawn.
I'm afraid I have no idea how this can be. On our end, we are not doing anything different between the first and subsequent frames. My guess is that this is a bug in Cocos2d-x with regards to custom rendering commands. As such, we might have to loop in the Cocos2d-X folks. (or fork maintainers) to fix this. I'm afraid I'm not familiar enough with Cocos2d-X internals to fix this myself.
So, ultimately, this needs to be passed to whoever is now maintaining Cocos2d-X (or a fork). I'm afraid on our end there is not much we can do, other than recommend to not use the two-color tinting renderer.

Hopefully this information is helpful to fix the issue. I attempted for about a day and a half and made no progress on this issue, I ended up disabling two-color tinting on our skeletons in the meantime. However this really sucks, since we use the two-color tinting system in order to telegraph specific attack types to our players...

@TyelorD Just for clarification. does this issue only occur when using the Metal renderer backend? The reason I ask is that I can't seem to reproduce this issue when using the OpenGL renderer.

If you look at the spine two color tine fragment shader in Axmol, you see this:
#version 310 es

precision highp float;

layout(binding = 0) uniform sampler2D u_tex0;

layout(location = COLOR0) in vec4 v_light;
layout(location = COLOR1) in vec4 v_dark;
layout(location = TEXCOORD0) in vec2 v_texCoord;

layout(location = SV_Target0) out vec4 FragColor;

void main() {
    vec4 texColor = texture(u_tex0, v_texCoord);
    float alpha = texColor.a * v_light.a;
    FragColor.a = alpha;
    FragColor.rgb = ((texColor.a - 1.0) * v_dark.a + 1.0 - texColor.rgb) * v_dark.rgb + texColor.rgb * v_light.rgb;
}

Change the main() method to this, which ignores the v_light values:
void main() {
    vec4 texColor = texture(u_tex0, v_texCoord);
    float alpha = texColor.a;
    FragColor.a = alpha;
    FragColor.rgb = ((texColor.a - 1.0) * v_dark.a + 1.0 - texColor.rgb) * v_dark.rgb + texColor.rgb;
}

You should notice that the texture appears correctly on the first frame.  The v_light value doesn't seem to be valid for a certain period of time, being 0,0,0,0 for RGBA, so when it is multiplied in float alpha = texColor.a * v_light.a;, it ends up as 0, which is completely transparent.  You can verify this by using allowing the v_light.rgb to be multiplied, but still ignoring the v_light.a:
void main() {
    vec4 texColor = texture(u_tex0, v_texCoord);
    float alpha = texColor.a;
    FragColor.a = alpha;
    FragColor.rgb = ((texColor.a - 1.0) * v_dark.a + 1.0 - texColor.rgb) * v_dark.rgb + texColor.rgb * v_light.rgb;
}

On the first frame, this appears:

You can see that v_light.rgb contains 0,0,0, and also that the texture is actually valid.
The color is set in SkeletonRenderer::draw(), so that may be the source of the problem, and not the SkeletonTwoColorBatch implementation.

@TyelorD If you have a bit of time, can you please try this:
In SkeletonRenderer.cpp:461, find this section of code for the two color tint:
} else {
   TwoColorTrianglesCommand *batchedTriangles = lastTwoColorTrianglesCommand = twoColorBatch->addCommand(renderer, _globalZOrder, texture, _programState, blendFunc, trianglesTwoColor, transform, transformFlags);

    V3F_C4B_C4B_T2F *vertex = batchedTriangles->getTriangles().verts;
    for (int v = 0, vn = batchedTriangles->getTriangles().vertCount; v < vn; ++v, ++vertex) {
        vertex->color = color4B;
        vertex->color2 = darkColor4B;
    }
}

Change it to this:
} else {
    V3F_C4B_C4B_T2F* vertex = trianglesTwoColor.verts;
    for (int v = 0, vn = trianglesTwoColor.vertCount; v < vn; ++v, ++vertex)
    {
        vertex->color  = color4B;
        vertex->color2 = darkColor4B;
    }
    lastTwoColorTrianglesCommand = twoColorBatch->addCommand(renderer, _globalZOrder, texture, _programState, blendFunc, trianglesTwoColor, transform, transformFlags);
}

Check if that fixes the issue for you.  I can't tell with the Raptor example, since it now appears correctly, but I don't notice any two color tinting, so I'm not sure what to look for.

Check if that fixes the issue for you. I can't tell if this affects the two color tinting though, since the Raptor example still looks the same, and I'm not even sure if the Raptor example has two color tinting on any of the slots.

Based on a quick smoke test, this solution does indeed appear to fix the issue I was experiencing. Our skeletons which use two-color tinting are also still tinting properly, while also rendering correctly on the first frame.
Thanks a ton @rh101, I assumed we'd have to engineer a different solution to the effect we were getting by using two-color tinting, but you seem to have saved the day!
I recommend submitting your solution as a PR as well :)

Based on a quick smoke test, this solution does indeed appear to fix the issue I was experiencing. Our skeletons which use two-color tinting are also still tinting properly, while also rendering correctly on the first frame.
Thanks a ton @rh101, I assumed we'd have to engineer a different solution to the effect we were getting by using two-color tinting, but you seem to have saved the day!
I recommend submitting your solution as a PR as well :)

Excellent! One thing to note though, this may not just be an issue with two color tints, since the code for the single color also has the same problem, but it may not have been obvious that the initial frame(s) were incorrect, since the shader operates differently.
I noticed the post on the Spine repo, so I assume they'll be fixing it there themselves.  The Axmol runtimes are here, and this issue is for all versions in that repo.  @halx99 I'll create PR in Axmol to fix this, but do you want me to generate a PR for each of the different versions in the axmolengine/spine-axmol repo, or will you merge the changes when they fix them in the official run-time?

Based on a quick smoke test, this solution does indeed appear to fix the issue I was experiencing. Our skeletons which use two-color tinting are also still tinting properly, while also rendering correctly on the first frame.
Thanks a ton @rh101, I assumed we'd have to engineer a different solution to the effect we were getting by using two-color tinting, but you seem to have saved the day!
I recommend submitting your solution as a PR as well :)

Excellent! ~One thing to note though, this may not just be an issue with two color tints, since the code for the single color also has the same problem, but it may not have been obvious that the initial frame is incorrect, since the shader operates differently.~ The non-two color tint shouldn't be affected, even thought it does update the data after the render command is added to the queue, because the vertex data seems to be used at a different point in the rendering process. In the #1875 the code has been changed to change the behaviour for both normal and two color tint, just in case.
I noticed the post on the Spine repo, so I assume they'll be fixing it there themselves. The Axmol runtimes are here, and this issue is for all versions in that repo. @halx99 I'll create PR in Axmol to fix this, but do you want me to generate a PR for each of the different versions in the axmolengine/spine-axmol repo, or will you merge the changes when they fix them in the official run-time?

@rh101 I invite you as collaborators of repo: axmolengine/spine-axmol , you can push fix all branch directly without PR.

@rh101 I invite you as collaborator of repo: axmolengine/spine-axmol , you can push to fix all branches directly without PR.

No worries, I'll update all the runtimes today.


[a11y]: Tooltip documentation changes necessary

This is an omnibus ticket, summarizing key problems with the content of the Usage and Style pages for the Tooltip component. (Specific problems with tooltip implementation are captured in https://github.com/carbon-design-system/carbon/issues/12921.)
Detailed considerations, edits and suggestions are captured in pdf exports of the pages: usage.pdf and style.pdf. These documents should be reviewed in detail.
The key considerations are:

It's critical to make users understand that tooltips are for exposing the names/information of things that ALREADY take focus (in other words, one cannot click to see the tip because clicking the trigger will cause another action to happen)
the information icon (i) should not be used with tooltips, but should be reserved exclusively for toggletip. The information on MDN supports this:

The tooltip is not the appropriate role for the more information "i" icon, ⓘ. A tooltip is directly associated with the owning element. The ⓘ isn't 'described by' detailed information; the tool or control is.

It is recommended that Carbon remove the “Standard tooltip” guidance entirely. It’s likely to confuse everyone and perpetuate the noise
reduce information on popover content (and on a related note, we suggest you make popover a pattern, not a component)
It is recommended that Carbon make the definition tooltip always display on hover and focus. You could consider making it also display on click/activation (since AFAIK there is not other action associated with a defn tooltip) but it would be less likely to muff people up if it was just hover/focus. Let's make tooltip consistent for interaction, regardless of the context.
This is a lesser priority, but Carbon could consider providing an example/implementation of a tooltip on an input. Option 4 in this demonstration provides a poor-ish example. The potential advantage of this is where you don't want the user to have to activate an inforamtion icon to toggle on more pronounced help. 👈 not a priority

When not to use section: The "i's" aren't tooltips. We need to change the image and update the guidance based on the differences between Tooltip vs Toggletip
Variant section: needs reworked. Lots of Toggletip action in there.
Lots of popover references: needs to be reworked. It makes more sense for that to be in the popover area.
DefinitionTooltip should be default appear on hover on focus. Currently the prop has to be set to enable this.

closing in favor of tracking through https://github.com/carbon-design-system/carbon/issues/13521


Reuse storage slots with ring-buffers

See https://github.com/taikoxyz/Taiko-Preconf-AVS-copy/discussions/11
Reduce SSTORE from 20K to 5K for lookaheadPosters and blockIdToProposer

Thank you for the changes!
I have raised an alternative PR (#171) with two additional commits on top of yours:

To follow convention:

I refactored and placed constants on top of the mappings they are being used within.
Shifted struct declarations to IPreconfTaskManager

Regarding buffer size, I think we can have a discussion on what values when this system goes to mainnet. For now, this is my rationale behind selecting their values:

LOOKAHEAD_BUFFER_SIZE: I decided to bump it up to 128 from 64. If the dispute period (for a lookahead slot) itself is two epochs, having just 2 epochs worth of lookahead in the buffer is not enough. Except the first slot in the first lookahead, no other slot gets to go through the full dispute period.
BLOCK_ID_TO_PROPOSER_BUFFER_SIZE: Our system has a dispute period of 2 epochs, so ideally we would not need to store more than 2 epochs worth of blocks in the buffer. Our nodes have a cap of 4 L2 blocks per slot, making it 256 blocks in 2 epochs.
LOOKAHEAD_POSTER_BUFFER_SIZE: I did not completely understand the reason behind using PreconfConstants.SECONDS_IN_SLOT * BLOCK_ID_TO_PROPOSER_BUFFER_SIZE as the value in your commit. The rationale I used here is that since we have 4 epochs worth of lookahead at any moment, we may safely have this buffer contain the posters of just those 4 epochs.

Closed and will continue on https://github.com/NethermindEth/Taiko-Preconf-AVS/pull/171

LOOKAHEAD_POSTER_BUFFER_SIZE: I did not completely understand the reason behind using PreconfConstants.SECONDS_IN_SLOT * BLOCK_ID_TO_PROPOSER_BUFFER_SIZE as the value in your commit.

This is incorrect in my previous PR. No need to have SECONDS_IN_SLOT in the calculation at all. Good catch.


%run -d [filename] doesn't stop on breakpoints, nor does calling a function w/ breakpoint from ipdb

Issue Report Checklist

[✅] Searched the issues page for similar reports
[✅] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[✅] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[✅] Could not reproduce inside jupyter qtconsole (if console-related)
[✅] Tried basic troubleshooting (if a bug/error)

[✅] Restarted Spyder
[✅] Reset preferences with spyder --reset
[✅] Reinstalled the latest version of Anaconda
[✅] Tried the other applicable steps from the Troubleshooting Guide

[✅] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
After running a file with %run -d [filename], Spyder skips breakpoints. It only seems to work if you type the much more verbose debugfile([filename], post_mortem=True, current_namespace=True), which is annoying if you want to pass command line args.
What steps reproduce the problem?

Set breakpoint
Type $run -d [filename]
Breakpoint is skipped

What is the expected output? What do you see instead?
It just skips the breakpoints entirely; I would like it if it followed the breakpoints.
Versions

Spyder version: 5.0.0
Python version: 3.9.4
Qt version: 5.9.7
PyQt version: 5.9.2
Operating System name/version: Darwin 17.7.0

Dependencies

# Mandatory:
applaunchservices >=0.1.7     :  0.2.1 (OK)
atomicwrites >=1.2.0          :  1.4.0 (OK)
chardet >=2.0.0               :  4.0.0 (OK)
cloudpickle >=0.5.0           :  1.6.0 (OK)
cookiecutter >=1.6.0          :  1.7.2 (OK)
diff_match_patch >=20181111   :  20200713 (OK)
intervaltree >=3.0.2          :  3.1.0 (OK)
IPython >=7.6.0               :  7.22.0 (OK)
jedi =0.17.2                  :  0.17.2 (OK)
jsonschema >=3.2.0            :  3.2.0 (OK)
keyring >=17.0.0              :  22.3.0 (OK)
nbconvert >=4.0               :  6.0.7 (OK)
numpydoc >=0.6.0              :  1.1.0 (OK)
parso =0.7.0                  :  0.7.0 (OK)
pexpect >=4.4.0               :  4.8.0 (OK)
pickleshare >=0.4             :  0.7.5 (OK)
psutil >=5.3                  :  5.8.0 (OK)
pygments >=2.0                :  2.8.1 (OK)
pylint >=1.0                  :  2.7.4 (OK)
pyls >=0.36.2;<1.0.0          :  0.36.2 (OK)
pyls_black >=0.4.6            :  0.4.6 (OK)
pyls_spyder >=0.3.2           :  0.3.2 (OK)
qdarkstyle =3.0.2             :  3.0.2 (OK)
qstylizer >=0.1.10            :  0.1.10 (OK)
qtawesome >=0.5.7             :  1.0.2 (OK)
qtconsole >=5.0.3             :  5.0.3 (OK)
qtpy >=1.5.0                  :  1.9.0 (OK)
rtree >=0.8.3                 :  0.9.7 (OK)
setuptools >=39.0.0           :  52.0.0.post20210125 (OK)
sphinx >=0.6.6                :  3.5.3 (OK)
spyder_kernels >=2.0.1;<2.1.0 :  2.0.1 (OK)
textdistance >=4.2.0          :  4.2.1 (OK)
three_merge >=0.1.1           :  0.1.1 (OK)
watchdog >=0.10.3;<2.0.0      :  1.0.2 (OK)
zmq >=17                      :  20.0.0 (OK)

# Optional:
cython >=0.21                 :  0.29.23 (OK)
matplotlib >=2.0.0            :  3.3.4 (OK)
numpy >=1.7                   :  1.20.1 (OK)
pandas >=1.1.1                :  1.2.4 (OK)
scipy >=0.17.0                :  1.6.2 (OK)
sympy >=0.7.3                 :  1.8 (OK)

I'll make my question even clearer - I just want to put things into some mode such that I can type function names into the console, and try different things, and have breakpoints activate when they are reached. Is there any way to do this? Can I somehow put the entire console into debug mode?

I really doubt there's something we can do about it because debugfile is required to use our own debugger instead of regular ipdb.
@impact27, what do you think?

It would maybe be useful if there were just a different %magic that calls
debugfile, but uses the %run -d filename arg1 arg2 arg3 syntax.
Something like %sdbg or something, for "spyder-debug" (and similarly
%srun). Is that something that's possible to do?
Mike
On Thu, Jun 3, 2021 at 8:34 PM Carlos Cordoba @.***>
wrote:

I really doubt there's something we can do about it because debugfile is
required to use our own debugger instead of regular ipdb.
@impact27 https://github.com/impact27, what do you think?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/15780#issuecomment-854272058,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMW7AR2PCIPGM6IZ5JLTRANRXANCNFSM46BWDPKQ
.

1 - Why do you want to use %run -d instead of the debugfile? It has the same functionality. For args use the args keyword. Also you can set all the options in the settings.
2 - if you want to debug a function from the debugger you need to have a recursive debugger. so from pdb instead of calling f(), use the debug command debug f()

Also %run -d does stop at the breakpoints. Do you have a reproducible example where it doesn't?

Breakpoints don't work with %run -d on my machine and the behavior is perfectly reproducible. If I am interpreting @ccordoba12 's prior comment correctly, that seems to be the standard behavior and has to do with which debugger is being used. If it's working on your machine with %run -d, I'd like to know how...

Sure:
1- Create a file named "test.py" with a single print(0)
2- in the console, run %run -d test.py
3- Check that it did stop at the breakpoint as expected.
@ccordoba12  could you check that this works as expected on your machine?

This only works because %run -d [filename] automatically sets a breakpoint on the first line regardless of what it is, or if you've set a breakpoint there or not. This doesn't work
print(0)
print(1) # breakpoint here

No matter what you've set, %run -d [filename] will automatically breakpoint before the print(0) just because it's line 1, and skip the breakpoint at print(1).

@ccordoba12 could you check that this works as expected on your machine?

It seems @battaglia01 is right:

For this to work we probably need to patch %run -d to get breakpoints from Spyder and set them in Pdb. However, that's what we already do in debugfile, so it's not something I'd like to put resources into.
Of course, if you'd like to give us a hand with that @battaglia01, you're more than welcome.

Sure, I can try - is there some way to programmatically get Spyder's list of breakpoints from the console?

@impact27, could you point him in the right direction?

I tried to checkout spyder 5.0.0 and spyder-kernels 2.0.1 but %run -d still stops on the breakpoints, so I don't know what is going on. Also, I can't think of anything special that debugfile does to the debugger compared to %run -d. It mostly exists to make sure we call runfile from the debugger to use all the spyder options, but otherwise doesn't really do anything special to the debugger.
You can access the debugger breakpoints from the debugger with the b command.
If you want more advanced access:
shell = get_ipython()
pdb_obj = shell.kernel._pdb_obj
pdb_obj.breaks

This only works if the debugger is running, otherwise you will get None for _pdb_obj

Ok, but how do I get Spyder's breakpoints from the command line (to put
into pdb to begin with), not the ones that pdb already has put into it?
On Wed, Jun 9, 2021, 2:51 AM Quentin Peter @.***> wrote:

I tried to checkout spyder 5.0.0 and spyder-kernels 2.0.1 but %run -d
still stops on the breakpoints, so I don't know what is going on. Also, I
can't think of anything special that debugfile does to the debugger
compared to %run -d. It mostly exists to make sure we call runfile from
the debugger to use all the spyder options, but otherwise doesn't really do
anything special to the debugger.
You can access the debugger breakpoints from the debugger with the b
command.
If you want more advanced access:
shell = get_ipython()
pdb_obj = shell.kernel._pdb_obj
pdb_obj.breaks
This only works if the debugger is running, otherwise you will get None
for _pdb_obj
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/15780#issuecomment-857434146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMQATF3NUPPCTG74MJTTR4FQHANCNFSM46BWDPKQ
.

Ah, sorry, the "more advanced access" method gave me what I was looking for

thank you
Mike

On Wed, Jun 9, 2021 at 3:06 AM Mike Battaglia @.***> wrote:

Ok, but how do I get Spyder's breakpoints from the command line (to put
into pdb to begin with), not the ones that pdb already has put into it?
On Wed, Jun 9, 2021, 2:51 AM Quentin Peter @.***>
wrote:

I tried to checkout spyder 5.0.0 and spyder-kernels 2.0.1 but %run -d
still stops on the breakpoints, so I don't know what is going on. Also, I
can't think of anything special that debugfile does to the debugger
compared to %run -d. It mostly exists to make sure we call runfile from
the debugger to use all the spyder options, but otherwise doesn't really do
anything special to the debugger.
You can access the debugger breakpoints from the debugger with the b
command.
If you want more advanced access:
shell = get_ipython()
pdb_obj = shell.kernel._pdb_obj
pdb_obj.breaks
This only works if the debugger is running, otherwise you will get None
for _pdb_obj
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/15780#issuecomment-857434146,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMQATF3NUPPCTG74MJTTR4FQHANCNFSM46BWDPKQ
.

Wait b and pdb_obj.breaks should return the exact same thing. The command line doesn't know anything about spyder. If you want to have access to spyder console, go to View > Panes > Internal console
From there you can get the breakpoints by:
from spyder.config.manager import CONF
CONF.get('run', 'breakpoints', {})

It looks like once the debugger has been run at least one time, shell.kernel._pdb_obj is no longer None.
It looks like that code you gave also runs from the regular console (e.g. internal console not required) which is good, because I will probably just need a general API for spyder stuff from the regular console... Is there some documentation for this?

OK to @ccordoba12 and @impact27 , I think I figured this out...
The very first time you call %run -d _____, it seems to set all the breakpoints correctly, as @impact27 said. But, once you call it twice, it doesn't work anymore.
This seems to be a larger problem with %debug in general, and I just wrote another issue in #15830. But, now that I'm doing it, I think it's all part of the same thing, which is that Spyder only sets the ipdb breakpoints correctly the first time you type either debug or %run -d ___ or etc from the console, and then doesn't set them correctly afterward.
For instance, this is the file:
#!/usr/bin/env python3
# breakpointtest2.py

print("line 1!")
print("line 2 - breakpoint here!")

Now let's call %run -d:
>>> %run -d breakpointtest2.py
*** Blank or comment
*** Blank or comment
*** Blank or comment
*** Blank or comment
NOTE: Enter 'c' at the ipdb>  prompt to continue execution.
> /Volumes/Shared/Projects/Python/breakpointtest2.py(4)<module>()
      1 #!/usr/bin/env python3
      2 # breakpointtest2.py
      3
----> 4 print("line 1!")
      5 print("line 2 - breakpoint here!")

We're pausing at the first line. Before we continue, we will look at the breakpoints and see that we get
IPdb [1]: b
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /Volumes/Shared/Projects/Python/breakpointtest2.py:5

They are set correctly. Then if we continue:
IPdb [2]: c
line 1!
> /Volumes/Shared/Projects/Python/breakpointtest2.py(5)<module>()
      1 #!/usr/bin/env python3
      2 # breakpointtest2.py
      3
      4 print("line 1!")
1---> 5 print("line 2 - breakpoint here!")

So it does successfully get the breakpoint the first time. Now if we run it again:
>>> %run -d breakpointtest2.py
NOTE: Enter 'c' at the ipdb>  prompt to continue execution.
> /Volumes/Shared/Projects/Python/breakpointtest2.py(4)<module>()
      1 #!/usr/bin/env python3
      2 # breakpointtest2.py
      3
----> 4 print("line 1!")
      5 print("line 2 - breakpoint here!")
# ^^ Pausing on first line, So far so good

IPdb [1]: b
# ^^ breakpoints empty?!

IPdb [2]: c
line 1!
line 2 - breakpoint here!
# Runs everything without breaking!

So this and the problem in #15830 seem to be equivalent; if you do any debugger thing from the console it seems to only set breakpoints correctly the first time and then doesn't afterward. (Perhaps these two issues should be merged now that this is clear...)

I can reproduce that. I will take a look when I have time.
One important thing is that Spyder and the kernel might not run on the same machine, so CONF.get('run', 'breakpoints', {}) has no garantee to return the right stuff hwen run from the ipython kernel. All the code for spyder pdb can be found here: https://github.com/spyder-ide/spyder-kernels/blob/master/spyder_kernels/customize/spyderpdb.py
The breakpoints are set in this file by:
pdb_settings = frontend_request().get_pdb_settings()
self.set_spyder_breakpoints(pdb_settings['breakpoints'])

Is that what sets Spyder's internal breakpoints? Where is the code in which
Spyder communicates those breakpoints to pdb/ipdb?
On Thu, Jun 10, 2021, 4:17 AM Quentin Peter @.***>
wrote:

I can reproduce that. I will take a look when I have time.
One important thing is that Spyder and the kernel might not run on the
same machine, so CONF.get('run', 'breakpoints', {}) has no garantee to
return the right stuff hwen run from the ipython kernel. All the code for
spyder pdb can be found here:
https://github.com/spyder-ide/spyder-kernels/blob/master/spyder_kernels/customize/spyderpdb.py
The breakpoints are set in this file by:
pdb_settings = frontend_request().get_pdb_settings()
self.set_spyder_breakpoints(pdb_settings['breakpoints'])
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/spyder-ide/spyder/issues/15780#issuecomment-858415372,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHZFMSONMKXTJLGVQTPESLTSBYJDANCNFSM46BWDPKQ
.

Is that what sets Spyder's internal breakpoints?

It's the second line of the code @impact27 posted in his last comment.

Where is the code in which Spyder communicates those breakpoints to pdb/ipdb?

It's in the first line.

preloop is called each time you stop somewhere. So if I press continue and the debugger stops at a breakpoint, preloop is called again. In this case we don't want the breakpoint set by the user in the debugging session to be removed.

@ccordoba12 @impact27 debugger is still not stoping at break point after spyder 5.0.4 and spyder_kernels


chore(prqlc): bump MSRV to 1.70.0

prqlc can now be binary installed on each platform.
I think the some of current problem with MSRV in dependencies is the prqlc dependency (#3520), so I think it makes sense to only update prqlc's MSRV.

Ah, brilliant!
Because we don't mind about Debian for prqlc, only for prqlr, and prqlr only requires prql-compiler?
This will make managing dependencies much easier...

Because we don't mind about Debian for prqlc, only for prqlr, and prqlr only requires prql-compiler?

Of course I think there is value in keeping MSRV small, but I thought it was worth thinking about this since clap's MSRV is now 1.70.

prql-compiler needs to worry about downstream projects, but prqlc doesn't need to worry about downstream projects, so I think the impact of MSRV is small.
prqlc has binaries in Homebrew and the official GitHub release, so I think many people install it from there.

By the way, Debian testing is now on the migration from rustc 1.67 to 1.69, and 1.70 is now experimental, so there is a possibility that it will be updated to 1.70 soon.
https://tracker.debian.org/pkg/rustc
Ubuntu LTSs are 1.66 now.
https://launchpad.net/ubuntu/+source/rustc

Of course I think there is value in keeping MSRV small, but I thought it was worth thinking about this since clap's MSRV is now 1.70.

Yes very much agree.
To confirm though — is the main reason we stay on a lower version because of prqlr on debian? And not prqlc?

To confirm though — is the main reason we stay on a lower version because of prqlr on debian? And not prqlc?

At least that's true for me.
Of course I'm monitoring Debian's rustc version, so as soon as they reach 1.70 I'll make changes here as well.
(I think setting it to 1.70 makes sense since many crates are starting to set MSRV to 1.70.)

At least that's true for me. Of course I'm monitoring Debian's rustc version, so as soon as they reach 1.70 I'll make changes here as well. (I think setting it to 1.70 makes sense since many crates are starting to set MSRV to 1.70.)

Perfect, thanks for the clarification and agree.


Running builds are not being stopped in LUCI when a PR is closed

Currently on a PR closed event we are stopping running tasks but the tasks are not being killed in LUCI for some reason. More details to come.

\cc @zanderso @eyebrowsoffire @ditman

The relevant method is here: https://cs.opensource.google/flutter/cocoon/+/main:app_dart/lib/src/service/luci_build_service.dart;l=250?q=cancel&ss=flutter%2Fcocoon

@ricardoamador @godofredoc on flutter/packages, the only PRs that I think are closed are mostly created by the auto-roller (it's very rare that any other PR gets closed, unless the contributor abandons it).
Should we attempt to manually cancel the running tasks in LUCI for those PRs while this gets fixed?

@ditman you could do that. Would it be really time consuming? I am going to take a look at this now to see if it is a quick fix.

I was expecting it to be a missing parameter fix but it seems like is not. Let's use https://github.com/flutter/flutter/pull/124213 for testing.

Tasks associated with the PR:
https://chromium-swarm.appspot.com/tasklist?c=name&c=created_ts&c=pending_time&c=duration&c=bot&c=pool-tag&c=state&d=desc&et=1680718900094&f=pool-tag%3Aluci.flutter.try&f=github_link-tag%3Ahttps%3A%2F%2Fgithub.com%2Fflutter%2Fflutter%2Fpull%2F124213&s=created_ts&st=1680632500000
Let's use the rpc explorer to cancel a pending build and a running one. The current implementation only need the buildbucket id. Which is part of the task name e.g. bb-8784632186993589489-flutter/try/Linux web_tests_3-38019 the buildbucket id is<PHONE_NUMBER>993589489

@godofredoc okay let me look into this.

Is this validated? I saw a closed pr running tests. Maybe we need to validate if the PR is closed before triggering tests in the other events?

It was reverted as it was causing issues with the ci.yaml validation test intermittently. The issue comes when the PR is first opened. There is a call to cancel all builds when a PR is initially opened here: https://github.com/flutter/cocoon/blob/main/app_dart/lib/src/request_handlers/github/webhook_subscription.dart#L129. The call to scheduleIfMergeable runs a call to cancelBuilds which is where the problem is coming from. There was some odd logic which looks to be what handles this case.

Okay I did some more investigation and the issue was that when we went to create the ci.yaml checkrun we hit the secondary rate limit and all the retries failed. So reverting the change and redirecting traffic was overkill but we erred on the side of caution in this case.

Okay I found the issue here and will update full tomorrow after some sleep. We are doing a couple of things wrong but in the end I was able to get this:

This is not working due to the fact the change uses the sha and not the pr.


Trouble using Time on x-axis

I am currently using the LineMarkSeries and having trouble applying Time into my x-axis scale. On my x-axis I want it to have a range between minTime and maxTime.
For example, on the x-axis it should have a range of :  minTime = 5:50:00PM to  maxTime = 5:55:00PM
My code as follow:
this.state = {
  minTime: format(Number(new Date()), "h:mm:ss"), //5:50:00
  maxTime: format(addMilliseconds(Number(new Date()), 100000), "h:mm:ss") //5:55:00
};

Let myData = [{x: "5:51:00" y: 0}, {x: "5:51:10" y: 30}, {x: "5:52:00" y: 10}]

<FlexibleXYPlot
  xType="time"
  yDomain={[-120, 100]}
  xDomain={[minTime, maxTime]}>
  <XAxis />
  <YAxis />
  <VerticalGridLines style={{ stroke: "transparent" }} />
  <HorizontalGridLines style={{ stroke: "transparent" }} />
  <LineMarkSeries data={myData} />
</FlexibleXYPlot>

Error I received on the console and what I noticed:

Error:  attribute d: Expected number, "MNaN,86.363636363…".
Label on the x-axis failed to contain minTime and maxTime, currently it is showing nothing.
All of the data coming in are on stacking up on the 0 x-axis
See image. please help?

If you iterate over your data and convert everything to a date object, it should work.  To my knowledge, the d3 time scale functions are based on date objects, so you could just pick a random day, like Jan 1 2018 and make all your times on that day, and convert all of your x-axis points to times on Jan 1, 2018

You could also flip everything to be epochs and then do the xAxis labeling yourself via tickFormat + moment (or which ever date formatter you like)

We've seen this issue come up a handful of times, and while the work around above do get the job done, we should actually just address the issue. Invite a PR from anybody reading to add tests and enable our date handling to be less persnickety.

@mathewleland Thank you. Your recommendation helps!!

@mathewleland Thank you. Your recommendation helps!!


Multi dash

we can now have multiple dashboards at once, and you can press n to move through them. They all keep the same time range as well!


Set up a code generation framework for driver wrappers

The unified driver interface framework in #3313 is designed to be implemented with generated code to call the drivers.
We need a framework to generate this wrapper code for Mbed TLS. The generation code will be in Python 3 since this is our scripting language. This is an investigation task; the outcome is not precisely defined, but will likely be Python code that can handle at least one smoke-test driver, as well as guidelines for the interface (types and function prototypes) between the hand-written code and the generated code.
#3313 has some ad hoc string writing code. This may or may not be the correct answer.
3rd March 2021: We have an hand-made driver wrapper to test the driver delegations we support. For multi-part operations (only multi-part cipher operations supported as time of writing but more to come soon), the driver operation context is dynamically allocated. This should be revisited to avoid dynamic allocations (see https://github.com/ARMmbed/mbedtls/pull/4157#discussion_r585696176).

Fulfilled by #5193 and its follow-ups.


xADCSCertificationAuthority - Fix Get-TargetResource + HQRM cleanup and tests - Fixes #14

This PR addresses the issue raised in #14 .
It also includes the following changes:

xAdcsCertificateAuthority:

Change property format in Readme.md to be standard layout.
Converted style to meet HQRM guidelines.
Added verbose logging support.
Added string localization.
Fixed Get-TargetResource by removing IsCA and changing Ensure to return whether or not CA is installed.
Added unit tests.

xAdcsOnlineResponder:

Change property format in Readme.md to be standard layout.
Added unit test header to be latest version.

xAdcsWebEnrollment:

Change property format in Readme.md to be standard layout.
Added unit test header to be latest version.

Added CommonResourceHelper.psm1 (copied from xPSDesiredStateConfiguration).
Removed Technet Documentation HTML file from root folder.
Removed redundant code from AppVeyor.yml.

I have added integration tests, but they can't be run on AppVeyor yet because installing ADCS on WS2012R2 requires a reboot - WS2016 does not seem to so they should be able to be run on that when it is available as an AppVeyor node.
You can run the integration tests manually though on a WS2012R2 machine with ADCS installed. You do need to provide credentials to the integraiton test script however (set in variables). This will be able to automated in WS2016.

This change is

Thank you so much @Indhukrishna for reviewing. :+1: I'll get the changes made when I get home from work tonight and have them ready for Friday morning PDT.

Review status: 0 of 16 files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

DSCResources/MSFT_xAdcsCertificationAuthority/MSFT_xAdcsCertificationAuthority.psm1, line 142 at r1 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
> Good call. I've managed to figure out the exception that will be thrown and am catching that now.

Done.

Tests/Integration/MSFT_xAdcsCertificationAuthority.Tests.ps1, line 11 at r1 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
> Oh wow! Ok, I didn't know that. I'll see if I can get the integration tests working in AppVeyor.

Done.

Tests/Unit/MSFT_xAdcsWebEnrollment.Tests.ps1, line 65 at r1 (raw file):
Previously, PlagueHO (Daniel Scott-Raynsford) wrote…
> I've converted these back to variables (but not $global or $script).

Done.

Comments from Reviewable

@Indhukrishna - I think I've completed everything.
Thanks again for the tip on AppVeyor reboots - that is definitely a fantastic tip - we should be able to now add Integration tests to the xActiveDirectory resource! 😁

Hi @mbreakey3 - I've actually finished the changes requested for this PR. So just waiting on a review.

@kwirkykat, @mbreakey3, @Indhukrishna - I don't suppose you have anyone over there who can complete this review?
It would be really good to get this one sorted for @theJasonHelmick and @majst32 .

PS: I've updated the resource parameter formats to meet the new parameter format guidelines determined a couple of days ago. I've also removed all the markdown violations from the readme.md.

This PR now also:

Fixes #20
Fixes #21

I may also try and get Integration tests set up for these remaining resources in this PR. This should then make this module HQRM.

Reviewed 7 of 16 files at r1, 2 of 6 files at r2, 1 of 4 files at r3, 8 of 8 files at r4.
Review status: all files reviewed at latest revision, 10 unresolved discussions.

appveyor.yml, line 8 at r4 (raw file):

  - git clone https://github.com/PowerShell/DscResource.Tests
  - ps: |
        Import-Module .\DscResource.Tests\TestHelper.psm1 -force

Add parameter name

appveyor.yml, line 12 at r4 (raw file):

        Install-Module -Name Pester -Repository PSGallery -Force
        Install-WindowsFeature -Name ADCS-Cert-Authority,RSAT-ADCS
        & net @('user','AdcsAdmin','NotPass12!','/ADD')

Could this be replaced by new-localuser in 5.1?
https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.localaccounts/new-localuser

appveyor.yml, line 13 at r4 (raw file):

        Install-WindowsFeature -Name ADCS-Cert-Authority,RSAT-ADCS
        & net @('user','AdcsAdmin','NotPass12!','/ADD')
        & net @('localgroup','administrators','AdcsAdmin','/ADD')

Could this be replaced with Add-LocalGroupMember in 5.1?
https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.localaccounts/add-localgroupmember

DSCResources/MSFT_xAdcsCertificationAuthority/MSFT_xAdcsCertificationAuthority.psm1, line 192 at r4 (raw file):

    }

    return @{

Align on "="

Tests/Unit/MSFT_xAdcsOnlineResponder.Tests.ps1, line 13 at r4 (raw file):

}

Import-Module (Join-Path -Path $script:moduleRoot -ChildPath 'DSCResource.Tests\TestHelper.psm1') -Force

Add parameter name

Comments from Reviewable

Review status: 12 of 18 files reviewed at latest revision, 10 unresolved discussions, some commit checks failed.

appveyor.yml, line 8 at r4 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add parameter name

Done.

appveyor.yml, line 12 at r4 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Could this be replaced by new-localuser in 5.1?
> https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.localaccounts/new-localuser

Really good idea - but unfortunately (as I found out) the AppVeyor build workers are still at WMF 5.0. So will need to wait for a WMF5.1 build worker to be available. I raised an issue though so that when it is available I can convert it.

appveyor.yml, line 13 at r4 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Could this be replaced with Add-LocalGroupMember in 5.1?
> https://msdn.microsoft.com/en-us/powershell/reference/5.1/microsoft.powershell.localaccounts/add-localgroupmember

See above.

DSCResources/MSFT_xAdcsCertificationAuthority/MSFT_xAdcsCertificationAuthority.psm1, line 192 at r4 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Align on "="

Good catch. Done.

Tests/Unit/MSFT_xAdcsOnlineResponder.Tests.ps1, line 13 at r4 (raw file):
Previously, mgreenegit (Michael Greene) wrote…
> Add parameter name

Great catch. I also fixed the ones in the other unit tests and the integration test. This actually comes from the unit/integration test template. So I'll get a PR together to fix this in the template as well.

Comments from Reviewable

Please fix tests

@mgreenegit - would you be able to go into reviewable and approve the changes you requested for this PR? Then I can merge this PR. Thank you - I appreciate you taking the time for the review of this one - it was very helpful.

Note: I merged this even though @mgreenegit hadn't signed off the requested changes. I did make the changes he requested though.


Used carthage with swift 3.

dyld: Library not loaded: @rpath/MDSOfferView.framework/MDSOfferView
Referenced from: /Users/MyUserName/Library/Developer/CoreSimulator/Devices/SomeLink/data/Containers/Bundle/Application/SomeLink/Test.app/Test
Reason: image not found
What's wrong, can u help me?

Everything is work. Thanks


fix(documentation)

Hej Andrew,
First of all, thanks for creating this beautiful learning material for everyone.
I just recognized that the example code needs a fix. You referred to the directory 04-benchmark, but it is actually 06-benchmark.
Cheers!

Thanks @sleeping-barber!


Revert "Fix deprecation warning for fontawesome"

Reverts sylhare/Type-on-Strap#474

overridden by #477


Feature request: play nicely with folder note plugins

(opened in error, please disregard)

Sorry I didn't get a chance to reply before you closed it!


Fix Default App Directory

per lifecycle#77 the default app directory shouldn't be prefixed with /app

i don't know why, but when i pull this branch locally, i see:
$ git diff master..fix-default-app-directory
...
@@ -419,8 +403,7 @@ func (b *BuildConfig) build(ctx context.Context, lifecycle *build.Lifecycle) err
                "builder",
                build.WithArgs(
                        "-buildpacks", buildpacksDir,
-                       "-layers", layersDir,
-                       "-app", appDir,
+                       "-layers", launchDir,
                        "-group", groupPath,
                        "-plan", planPath,
                        "-platform", platformDir,

unsure why Github doesn't show that for me

i think it just needs a rebase

@ekcasey I see some other places that reference /workspace/app or look like they might need to be updated for the directory rename: https://github.com/buildpack/pack/blob/master/build.go#L77

my bad, the rebase fixed it locally for me. sorry :( going to close this.

@sclevine probably shouldn't have put https://github.com/buildpack/lifecycle/issues/77 in done. The lifecycle changes are done which was higher priority b/c we wanted to finish lifecycle beta first so that folks could create their beta builders.
More work need to be done to allow pack to use the new defaults. We need to create a second volume for the app. Until that is done pack need to use the flags to explicitly set values to the original default.


2.1.0

Creates a new release for Dart 3.0, that removes always_require_non_null_named_parameters as per #95.
/cc @goderbauer @mit-mit @jakemac53 @natebosch @bwilkerson

Do we need to make another release of flutter_lints as well once this lands?
https://github.com/flutter/packages/blob/main/packages/flutter_lints/pubspec.yaml

(Sorry for the spam.  I'd like to get a couple more sets of eyes before I land and publish.)

Thanks all!


Don't try to free(3) a pointer to stack.

GCC warning helped to spot a real bug: near line 1185 of
libLumina/LuminaX11.cpp there is a call: free(&hints);, - but the
"hints" is allocated on the stack a few lines above. This looks
like a copy-paste error, since other free(&hints) instances look
like sane (unless I've missed something, of course).

Thanks for fixing that!


Rebuild libtool 2.4.6 with autoconf 2.71

Libtool is a build tool. It must be updated with other build tools:
autoconf https://github.com/AnacondaRecipes/autoconf-feedstock/pull/1 -> automake https://github.com/AnacondaRecipes/automake-feedstock/pull/5 -> libtool
Actions:

Add set -xe command (print shell command before executing it and exit immediately if it fails)
Bump build number to 1009
Add libtool --version to test/commands

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_fdbu2smaoc/clone/recipe/meta.yaml:18: invalid_url: http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz : URL domain redirect ftpmirror.gnu.org ->  mirror.rit.edu
WARNING: /tmp/abs_fdbu2smaoc/clone/recipe/meta.yaml:18: http_url: http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz is not https
WARNING: /tmp/abs_fdbu2smaoc/clone/recipe/meta.yaml:54: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_fdbu2smaoc/clone/recipe/meta.yaml:54: missing_doc_source_url: The recipe is missing a doc_source_url
Errors were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_710ak40zwb/clone/recipe/meta.yaml:18: http_url: http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz is not https
ERROR: /tmp/abs_710ak40zwb/clone/recipe/meta.yaml:18: invalid_url: http://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz : URL domain redirect ftpmirror.gnu.org ->  mirror.us-midwest-1.nexcess.net
WARNING: /tmp/abs_710ak40zwb/clone/recipe/meta.yaml:54: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_710ak40zwb/clone/recipe/meta.yaml:54: missing_doc_source_url: The recipe is missing a doc_source_url
Errors were found

Linter check found the following problems:
The following problems have been found:
WARNING: /tmp/abs_87m5gigfpe/clone/recipe/meta.yaml:54: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_87m5gigfpe/clone/recipe/meta.yaml:54: missing_doc_source_url: The recipe is missing a doc_source_url
Warnings were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_a3_7sz2zsc/clone/recipe/meta.yaml:18: invalid_url: https://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz : URL domain redirect ftpmirror.gnu.org ->  mirror2.sandyriver.net
WARNING: /tmp/abs_a3_7sz2zsc/clone/recipe/meta.yaml:54: missing_doc_source_url: The recipe is missing a doc_source_url
WARNING: /tmp/abs_a3_7sz2zsc/clone/recipe/meta.yaml:54: missing_license_url: The recipe is missing a license_url
Errors were found

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_e7ysepgxyz/clone/recipe/meta.yaml:18: invalid_url: https://ftpmirror.gnu.org/libtool/libtool-2.4.6.tar.gz : URL domain redirect ftpmirror.gnu.org ->  ftp.wayne.edu
WARNING: /tmp/abs_e7ysepgxyz/clone/recipe/meta.yaml:54: missing_license_url: The recipe is missing a license_url
WARNING: /tmp/abs_e7ysepgxyz/clone/recipe/meta.yaml:54: missing_doc_source_url: The recipe is missing a doc_source_url
Errors were found


Commit Parser has the ability to say "ignore this commit" for the purposes of building the changelog

Description
Provide the ability for a custom Commit Parser to signal that a commit should not be output to the changelog, but should be ignored.
Use cases
I've got a monorepo where I want different directories within it to each be independently versioned (using tags like dir_a-v1.0.1), which I can achieve with a custom parser that opts to ignore commits where there weren't any changes in the directories it cares about.
This all works fine, apart from the ignored commits still appear in the changelog
Possible implementation
Add to ParsedCommit a include_in_changelog property which defaults to true.
Use this to decide whether to ignore the commit, in the same way that commits matching exclude_commit_patterns are ignored.
I don't believe that change would break any backward compatibility.

I think a work around is to hardcode the changelog / release templates to ignore these commits (either based on the type, or based on a new property you add in a subclass of ParsedCommit).

@cc-stjm, thanks for the write up! I think I understand your dilemma. Exclude commit patterns alone is too restrictive or simple in logic that does not discern the commits to the same degree you desire, as opposed to your parser which can.
It worries me when you said the ignored commits "still" appear in the changelog because that sounds like a bug?
One possible solution is today is that you can have your parser put it into a custom "ignored" category or "unknown" category via the parsed_commit.type attribute, and then in your changelog template logic, filter out that category?  That is to say you would need to use a custom changelog template. Are you using a custom template now?

It worries me when you said the ignored commits "still" appear in the changelog because that sounds like a bug?

I don't think I can call it a bug, merely an absence of a feature. I was able to get the commits to be ignored from the perspective of deciding whether or not to bump a version number. I realise that in most cases you probably do want the changelog etc. to reflect commits that didn't bump the version number, so I think that's the correct behaviour.

I have recently had a similar need to mark additional information about the ParsedCommit from the parser level. I think the feature we can modify to add a simple attributes dictionary that custom parsers can add fields about a commit, which then custom changelog logic can capture.

I think that if you just subclass ParsedCommit, and refer to your custom fields in the changelog template, that should work now? So it's only the ability to exclude the commit from those passed to the changelog altogether that's necessary to add.

I don't think I can call it a bug, merely an absence of a feature.

OK, thanks!

I realise that in most cases you probably do want the changelog etc. to reflect commits that didn't bump the version number, so I think that's the correct behaviour.

I personally would argue the opposite because in my opinion Changelog's are for the users/consumers so internal development decisions that don't trigger a release are irrelevant to the end user.  Example is a ci, style, or refactor (that isn't performance related), those I don't think are relevant to users and the developers can just look at the code/commits. I only offer that as an alternative viewpoint but something that I leave up to the consumer of this library to decide. "To each his own".

I think that if you just subclass ParsedCommit, and refer to your custom fields in the changelog template, that should work now?

I do believe that would work today if your custom parser passed back a subclass of ParsedCommit. Then your custom template would understand those fields.

So it's only the ability to exclude the commit from those passed to the changelog altogether that's necessary to add.

I will think on this a bit longer but I am leaning towards thinking, this is a good attribute to provide custom parsers by default.

Given the recent commits, it feels like this should not be marked as stale?

Given the recent commits, it feels like this should not be marked as stale?

As this is an issue, I don't believe the bot is considering committing references as updates. I did add the confirmed label now.

I have made a fix but it's currently sitting in a branch waiting for testing and unfortunately have not gotten back around to it. Hopefully sooner than later I will.

No change

Was working on this a bit this past week, should be released in the next few weeks

:tada: This issue has been resolved in version 9.15.0 :tada:
The release is available on:

PyPi package
GitHub release


slicing bug

>> d1 = dask.array.zeros((1, 9, 3), chunks=(1, 5, 3))
>> d2 = d1[0, :, [0, 2]]
>> d2.compute()
ValueError: could not broadcast input array from shape (2,4) into shape (2,5)

I tried looking at the dask dict but I could not notice anything anomalous (besides the fact that the slicing is done in two steps and may have been a bit more optimized).
I tried a bunch of variants of the above:

do not slice on the first dim: WORKS
do not have a first dim: WORKS
slice on the first dim alone, compute to numpy, convert back to dask, and then slice on the third dim: WORKS
select only one element on the third dim: WORKS
have 10 elements in the second dim, so that it can be divided evenly by its chunksize: WORKS
slice on the first dim, and then slice the result on the third dim: DOESN'T WORK

Expanded tests:
https://gist.github.com/crusaderky/87e6e51b22434128a3a57811a4077710

Thanks for the excellent bug report.  Reproduced on my side.

I've done some investigating this bug and it seems to be a basic feature of combined advanced and basic slicing in numpy.
In short, in this example d1[0, :, [0, 2]) falls in the first case (as explained in the link above), i.e. the "advanced" slices are separated by basic slicing (the Ellipsis). In that specific case, the advanced slicing dimension (the third dimension) is then moved to the first dimension in the output:
>> a = np.arange(27).reshape((1, 9, 3))
>> a[0, :, [0, 2]].shape
(2, 9)
>> np.squeeze(a[:, :, [0,2]]).shape
(9, 2)

and a[0, :, [0, 2]].T is going to be equal to np.squeeze(a[:, :, [0, 2]]).
My understanding is that this problem arises in the optimization step where a[0, :, :][:, [0, 2]] gets converted to a[0, :, [0, 2]]. This then reverts to numpy indexing rules yielding an unexpexted array shape to dask.
Because of this, I think there is only one clean option: do not optimize these special cases...

The root bug was fixed in #2313. Specific optimizations for hdf5 were not part of that though. I'm going to close this, but keep PR #1776 open for discussion.


How can I evaluate a photo not in the dataset

I see that test a photo use the function AFM which need the information about some known lines.But I want to test the photo which I dont have the line information.

@cupcakefromchina how were you able to solve the problem if i may ask?

No,I can't fine one function.You can see another issue.

Hi, having the same question here. Is it possible to direct test the model on an image in the wild without any line information? Thank you.


Test Jenkins Github plugin

test this please

test this please

test this please

test

test this please

test this please

test

test this please

Build started sha1 is merged.

Build finished. No test results found.

test this please

test this please

test this please

test this please

test this please

test this please

test this please

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Starteeeeeeeeeed

Failurrrrrrrre
No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

test this please

Build started sha1 is merged.

Build finished. No test results found.

Build finished. No test results found.

Build started sha1 is merged.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

test this please

Build started sha1 is merged.

Build finished. No test results found.

test this please

Build started sha1 is merged.

Build finished. No test results found.

test this please

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.

Build started sha1 is merged.

Build finished. No test results found.


preValdiation doesn't pass the computed state to the validation functions

When you call preValidate the computedState doesn't include the attributes passed to preValidate, but rather the model attributes.
This differs from the regular validate functionality which means validation functions that depend on multiple attributes break (true, not an idea situation anyway, but sometime you need that and the behaviour should be uniform in both usages).

Made a fix and submitted a pull request (https://github.com/thedersen/backbone.validation/pull/303)

I wasn't sure what you versioning and releasing procedure is, so I haven't changed the version - let me know if you wish for me to bump the minor version.

This is a serious problem, but the pull request is almost a year old, and nobody has replied to it!


DHTML Detours

DHTML can be used for websockets, to lag your game, etc..

Tried detouring at least the JS Websocket class, unfortunately seems like you can't monkeypatch it.
That's pretty much all that can be done, unless I just want to try and replace all instances of new WebSocket with new MyWebSocket or something. Closing for now :(


Is there a similar maker or scripts  for IOS

Hi @Javernaut
Do you have similar scripts for IOS or can you point us to any useful links that can be a good starting point.
Thanks much in advance

@pkoppise
You can have a look here
https://github.com/arthenica/ffmpeg-kit


Tobin devsim lvl testing

This fixes up a number of test and ICD issues that I found while testing the mock ICD with different devsim profiles.
It adds in a pre-build DevSim layer along with its json file and 7 initial device profiles from an assortment of vendors.
The Travis-CI regression now runs the LVL test suite 8 times. Once on default mock ICD and then once on each of the 7 different json device profiles.
For tests that require the device profile layer, that will take the place of the devsim layer.
Eventually we can enhance the device profile layer and migrate all tests to just use that but for now this gives us an initial assortment of coverage over some simulated profiles.

merged


Switchgrass Scenario Runs

Dr Cruse has a need for more scenarios, this would be perennial switchgrass over some fraction of the DEP hillslopes with the replacement based on bulk slope.  3, 6, and 10% slope replacement

DEP Scenario
Description
% of Slopes Converted
Status
15 Feb Rerun

0
Baseline
--
n/a
n/a

36
Slopes >= 3% to Switchgrass
67.6%
Done
Done

37
Slopes >= 6% to Switchgrass
46.7 %
Done
Done

38
Slopes >= 10% to Switchgrass
31.0%
Done
Done

As I started the analysis of these runs, the last two scenarios yielded exactly the same summary numbers (ruh-roh).  As I reviewed the code, I noticed no logic to actually govern the conversion of DEP production rotations into switchgrass.  This was resolved by 2912533.  Strangely, scenario 36 had slightly different results, which I don't understand why.  Am reprocessing things now and will have results later today for all three scenarios.

Dave and others would like to see what LAI looks like, so lets rerun these three scenarios.

[ ] add crop folders to baseline directory tree
[ ] add crop option to proctor script
[ ] run scenario 36
[ ] run scenario 37
[ ] run scenario 38
[ ] write script to harvest the output, unsure yet of scope of going to database or what here

Closing as no longer relevant.


The tor-browser-bundle-bin-10.0.17 package fails to install with message: "Assertion failed: size_ < capacity_ (src/libexpr/attr-set.hh: push_back: 54)".

Description
The tor-browser-bundle-bin-10.0.17 package fails to install with message: "Assertion failed: size_ < capacity_ (src/libexpr/attr-set.hh: push_back: 54)".
Reproduction
Steps to reproduce the behavior:
$ nix-env -iA nixpkgs.tor-browser-bundle-bin

Expected behaviour
The package is installed succesfully.
Actual behaviour
The following messages are outputted:
installing 'tor-browser-bundle-bin-10.0.17'
Assertion failed: size_ < capacity_ (src/libexpr/attr-set.hh: push_back: 54)
Aborted

Notify maintainers
@offline @matejc @thoughtpolice @joachifm @hax404 @cap @KarlJoad
Metadata
$ nix-shell -p nix-info --run "nix-info -m"
these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked):
  /nix/store/rmhwi0jcya8f87gzk2jjdwv4hifmmbb4-nix-info
copying path '/nix/store/rmhwi0jcya8f87gzk2jjdwv4hifmmbb4-nix-info' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 5.11.22_1, void, noversion`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.3.9`
 - channels(a): `"nixpkgs-21.11pre294471.51bb9f3e9ab"`
 - nixpkgs: `/home/a/.nix-defexpr/channels/nixpkgs`

Duplicate of #112465
This issue is fixed by NixOS/nix#4634 in Nix 2.3.11+ (you're currently running 2.3.9)


Option to stop polling/querying if tab is not active

A smart and sophisticated way pioneered by Premia to reduce requests and save query fees on The Graph Network is to only send queries as long as the tab/window/document is active or visible. They created a custom Apollo Middleware but I think this could be solved directly in Graph Client.
https://developer.mozilla.org/en-US/docs/Web/API/Document/hidden#browser_compatibility

I just created this WIP PR. You can test with the canaries;
https://github.com/graphprotocol/graph-client/pull/355#issuecomment-1377396543


Openshift 4.5 audit log: There are 2 and the one identified is not correct

What happened:
Installed splunk-connect into an OKD 4.5 cluster
What you expected to happen:
The following 2 audit files identified and sent to SPLUNK:
/var/log/kube-apiserver/audit.log
/var/log/openshift-apiserver/audit.log
How to reproduce it (as minimally and precisely as possible):
100%
Anything else we need to know?:
Environment:

Kubernetes version (use kubectl version):
OKD 4.5 is the upstream Openshift 4.5:
oc version
Client Version: 4.5.0-0.okd-2020-08-12-020541
Server Version: 4.5.0-0.okd-2020-08-12-020541
Kubernetes Version: v1.18.3

Ruby version (use ruby --version):

OS (e.g: cat /etc/os-release):
OKD uses Fedora CoreOS, which is the upstream RedHat CoreOS
cat /etc/os-release
NAME=Fedora VERSION="32.20200629.3.0 (CoreOS)" ID=fedora VERSION_ID=32 VERSION_CODENAME="" PLATFORM_ID="platform:f32" PRETTY_NAME="Fedora CoreOS 32.20200629.3.0" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:32" HOME_URL="https://getfedora.org/coreos/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/" SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=32 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=32 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="CoreOS" VARIANT_ID=coreos OSTREE_VERSION='32.20200629.3.0'

Splunk version:
8.0.5

Others:

I am relaying the methodology and the findings in hopes that it can be incorporated into future releases of splunk-connect (specific for Openshift??).  NOTE:  I find this release extremely useful and reliable.
However, I would like to relay a few points about the process.

The audit logfile location identified in the values.yaml is incorrect for Openshift and does not exist.
Needed to specify the metrics index to prevent installation error, even though not collecting metrics or installing (see below values.yaml provided).

DETAILS:
In Openshift 4.5, the audit file exist in 2 different files on the 3 master nodes, and is not what is specified in the released version of values.yaml.
/var/log/kube-apiserver/audit.log
/var/log/openshift-apiserver/audit.log
According to this values.yaml file:
https://github.com/splunk/splunk-connect-for-kubernetes/blob/53d5b0c1e333ad04c16a556aedd137f15c95a630/helm-chart/splunk-connect-for-kubernetes/values.yaml#L321
The audit file is located here – but it does not in Openshift 4.5:
/var/log/kube-apiserver-audit.log
I included my values.yaml to overwrite and also capture the openshift-apiserver audit log file.  Additionally, all documentation that I could find references helm2 install with tiller.  Openshift 4.5 supports helm3 (with annotations) and that is the process used here.
Thank you very much for your help and once again, this is a great tool.  It is much appreciated.
Please let me know if there is additional information I can provide.
Brian
global:   splunk:     hec:       host: "splunk.example.com"       port: "1234"       token: "REDACTED"       indexName: "OKD-local-audit"   kubernetes:     clusterName: "OKD-local"     openshift: "true" splunk-kubernetes-logging:   containers:     logFormatType:  "cri"     logFormat: "%Y-%m-%dT%H:%M:%S.%N%:z"   logs:     kube-audit:       from:         file:           path: "/var/log/kube-apiserver/audit.log"     openshift-apiserver:       from:         file:           path: "/var/log/openshift-apiserver/audit.log"   nodeSelector:     node-role.kubernetes.io/master: ""   kubernetes:     clusterName: "OKD-local"     openshift: "true" splunk-kubernetes-objects:   enabled: false   kubernetes:     clusterName: "OKD-local"     openshift: "true" splunk-kubernetes-metrics:   enabled: false   kubernetes:     clusterName: "OKD-local"     openshift: "true"   splunk:     hec:       indexName: "OKD-local-metrics"
helm3 install process:
`#/bin/bash
FUNCTION:  check_return_code_function
Check return code from previously run command.
Will display error code and exit with 99 if previous function
is anything but 0.
check_return_code_function () {
RETURN_CODE=${?}
if [ "$RETURN_CODE" -ne 0 ]
then
echo "RETURN_CODE is:  ${RETURN_CODE}"
exit 99
fi
echo
echo "SUCCESS!!!!"
echo
sleep 1
}
OCP_PROJECT="splunk-connect-ops"
wget https://github.com/splunk/splunk-connect-for-kubernetes/archive/release/1.4.3.zip
check_return_code_function
unzip 1.4.3.zip
check_return_code_function
oc adm new-project ${OCP_PROJECT} --node-selector="" --as=system:admin
check_return_code_function
oc project ${OCP_PROJECT}
check_return_code_function
helm3 install splunk-kubernetes-logging --namespace=${OCP_PROJECT} -f values.yaml splunk-connect-for-kubernetes-release-1.4.3/helm-chart/splunk-connect-for-kubernetes/
check_return_code_function
oc adm policy add-scc-to-user privileged -z splunk-kubernetes-logging -n ${OCP_PROJECT}
check_return_code_function
#helm3 uninstall splunk-kubernetes-logging --namespace=${OCP_PROJECT}
check_return_code_function`

Sorry about how the post looks.

Thanks team, more of an experience thing for openshift users..
basically, when "openshift: true" point at known openshift audit log...
Technically the file path is customizable in kubelet settings, but may as well ship well know defaults for openshift.

I opend a PR that provides an OpenShift 4 values example. https://github.com/splunk/splunk-connect-for-kubernetes/pull/546/files

Having being called to a bunch of "woahhhh thats a lot of logs!" calls around audit, I suggest this NOT be a default, but moved to the helm chart so customer can enable, provide path and bonus points for filter!!!

@matthewmodestino indeed true, huge amount of data sent to Splunk. Unfortunately some sites have some requirements to ship and store it for years.

Im totally down with that! But after you as the customer press the big red button. :)
Also I wonder if docker-splunk image solely for audit would be better and leave fluentd to the app teams? any thoughts on that?


1.2.1 compatible?

If this is, would you like me to get CKAN updated with the info?

Yes, version 16 is updated for KSP 1.2.1.


tilde() in math mode looks weird on some capital letter

Description
The following code generate bad result on some capital letter, such as C,D,G,R.
I expect the tilde to appear wider and not lean to one side.
#set text(size: 50pt)
$tilde(A)tilde(B)tilde(C)tilde(D)tilde(E)tilde(F)tilde(G)$
$tilde(H)tilde(I)tilde(J)tilde(K)tilde(L)tilde(M)tilde(N)$
$tilde(O)tilde(P)tilde(Q)tilde(R)tilde(S)tilde(T)$
$tilde(U)tilde(V)tilde(W)tilde(X)tilde(Y)tilde(Z)$

Reproduction URL
https://typst.app/project/rPD5hXmWLKmKVK4FeNtVrY
Operating system
Web app
Typst version

[X] I am using the latest version of Typst

I'm closing this as not a bug.
The appearance is down to the math font, and the font designer's preference.
(Unless you claim it looks different using e.g. LuaTeX with unicode-math)


Possible to disable volume normalization?

In raspotify config it states that "By default, the volume normalization is enabled" and there is a flag for enabling it with custom options. But I see no flag for disabling it in the raspotify or librespot docs. Is this possible?

I think you'll need to add VOLUME_ARGS in /etc/default/raspotify I think the default options for that argument are VOLUME_ARGS="--enable-volume-normalisation --linear-volume --initial-volume=100", so you could just omit --enable-volume-normalisation


TextField cursor moving outside

Hey guys.
I have found strange issue. And cant actually find reason of it, or proper solution.
Can you take a look on this?
Here is an issue - as you can see - cursor is outside of TextField:

Here is my code:

Will appreciate you help.
Thank you in advance

This should be fixed with https://github.com/flutter/flutter/pull/30525

I have same issues now !

@mahdinazmi If you're still seeing this, can you open a new issue with a full reproduction case and tag me?


Setting skip_paths to all the paths hit, stops custom metrics from working

If you configure skip_paths to be a list of all the paths you visit, ie: ["/metrics", "/favicon.ico"] then the custom_metrics functions are never invoked.
I think this is because the logic for the custom_metrics is under the if request.url.path not in self.skip_paths: logic.
I encountered this when using this method to disable the REQUEST_TIME metric.

Can you tell me what result are you trying to get? If you add all the paths to skip_paths, obviously custom_metrics is never invoked, because all paths are skipped.
If you want to disable one of the default metrics, I think I can add an optional parameter for that

Initially I was simply trying to disable the request_processing_time metrics, which I did by setting skip_paths=["/metrics", "/favicon.ico"].
I determined I was never going to use metrics about 404 request processing time to a non-existent favicon.ico, which the default configuration sets:
# HELP requests_total Total HTTP requests
# TYPE requests_total counter
requests_total{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",method="GET",path="/favicon.ico",status_code="404"} 1.0
# HELP requests_created Total HTTP requests
# TYPE requests_created gauge
requests_created{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",method="GET",path="/favicon.ico",status_code="404"} 1.604400990556766e+09
# HELP request_processing_time HTTP request processing time in seconds
# TYPE request_processing_time histogram
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.005",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.01",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.025",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.05",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.075",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.1",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.25",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.5",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="0.75",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="1.0",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="2.5",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="5.0",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="7.5",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="10.0",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_bucket{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",le="+Inf",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_count{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",method="GET",path="/favicon.ico",status_code="404"} 1.0
request_processing_time_sum{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",method="GET",path="/favicon.ico",status_code="404"} 0.00047087669372558594
# HELP request_processing_time_created HTTP request processing time in seconds
# TYPE request_processing_time_created gauge
request_processing_time_created{app_name="myapp",headers="{'host': '<IP_ADDRESS>:8080', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0'}",method="GET",path="/favicon.ico",status_code="404"} 1.604400990556919e+09

The application I'm building has no other endpoints, so it will only ever receive requests to this path (and maybe the default health check path in FastAPI).
What came as a surprise was that I had added some custom metrics, returning some values from a db query and they were not returned once I added "/favicon.ico" to the skip_paths list.
My understanding was that by calling the AddMetric function, any metric could be added, for exposure via Prometheus; if the skip_paths list is set to cover all the endpoint your application contains, custom metrics are never exposed.

The application I'm building has no other endpoints, so it will only ever receive requests to this path
By "this path" you meaning /favicon.ico?

When you want your custom metric to activates? After request to  /favicon.ico?

By "this path" you meaning /favicon.ico?

No, just /metrics.
My apologies I'm not expressing myself clearly; the FastAPI app I'm writing is for executing basic database queries to generate Prometheus metrics. It has no endpoints beyond the /metrics endpoint implemented by your prometheusrocks middleware.
Since there are no other endpoints on the application, and I have no need for the request_processing_time metrics I was attempting to disable them, however the reliance upon another endpoint existing as a trigger mechanism for the custom metrics means that when I attempt to disable the request_processing_time metric by setting the skip_paths variable, I end up with no metrics.
As for /favicon.ico I have no intent to visit that endpoint specifically; it's only happening because I'm navigating to http://<IP_ADDRESS>:8080/metrics in Firefox, and the browser attempts to load favicons by default.

Ah, get it! Thanks for clarification!
If I'll made following changes, will it be helpful in your case?

Opportunity to disable default skip of /metric path
Opportunity to disable default metrics

I think in my use-case, the second is most helpful.
Is the first option not possible currently by setting skip_paths = []?
My concern with it for applications with many endpoints is that it generates a large quantity of multi-label data which if you have a large application being accessed by many browsers would end up with a lot of high cardinal data with the default configuration.

Is the first option not possible currently by setting skip_paths = []?

Unfortunetely, no. Bad architecture solution, as how I understand at the moment.
Hm, your concerns are pretty reasonable, I must think about that.
New version with this features will be as soon as possible, I'll close the issue when it be ready

Updated docs and code, if there will be further problems, let me know!


Cannot run program after installation due to missing settings.json file

After installing the program I'm unable to run it with the following error:

When checking the installation folder settings.json seems to be missing entirely.

@Skyyblaze - Does your Windows account have Administrator privledges? This is required to use the app.
If it does please could you answer the following questions, and then I might be able to suggest a fix:

When you start the app, do you see a 'User Account Control' dialog? Something like this: https://imgur.com/a/fuUKCWr
Navigate to the installation folder. It should be C:\Program Files (x86)\Start Menu Manager. You should see the file Start Menu Manager.exe here. Do you also see a settings.json file? If yes, please post the contents of the settings.json file here.
Are you able to access the Start Menu shortcut folder. It should be at the path C:\ProgramData\Microsoft\Windows\Start Menu\Programs.

Thanks.

@Skyyblaze - Does your Windows account have Administrator privledges? This is required to use the app.
If it does please could you answer the following questions, and then I might be able to suggest a fix:
1. When you start the app, do you see a 'User Account Control' dialog? Something like this: https://imgur.com/a/fuUKCWr

2. Navigate to the installation folder. It should be `C:\Program Files (x86)\Start Menu Manager`. You should see the file `Start Menu Manager.exe` here. Do you also see a `settings.json` file? If yes, please post the contents of the `settings.json` file here.

3. Are you able to access the Start Menu shortcut folder. It should be at the path `C:\ProgramData\Microsoft\Windows\Start Menu\Programs`.

Thanks.

Thanks for trying to help!
I do have administrative privileges on my account and system, to answer your other questions:
1: Yes I see a UAC prompt and the app starts elevated.
2: As mentioned before I do not see a settings.json file next to the .exe, the file simply doesn't exist.
3: Yes I can access the folder just fine.
Any help is appreciated :smile:
One thing I thought of that might throw the program off, my system is one of these very rare edge-cases where my Windows partition actually isn't C: but has another drive-letter.
This happened back when I upgraded from Win7 to Win10 due to some dual-boot shenanigans I had going on but I never had any issues in the 5 or so years I've been running this install so I never bothered to "fix" it.

This happened back when I upgraded from Win7 to Win10 due to some dual-boot shenanigans I had going on but I never had any issues in the 5 or so years I've been running this install so I never bothered to "fix" it.

Ah, that will be the problem. I'll look into it and might get a fix into version 1.1 (which should be released by December).

This happened back when I upgraded from Win7 to Win10 due to some dual-boot shenanigans I had going on but I never had any issues in the 5 or so years I've been running this install so I never bothered to "fix" it.

Ah, that will be the problem. I'll look into it and might get a fix into version 1.1 (which should be released by December).

Alright I'm glad we could pinpoint the cause no matter if you can fix it or not. If you can I'm super looking forward to 1.1 also for Steam support, thanks for the hard work! :smile: