Tangent frames are deformed using JavaScript SurfaceOrientation$Builder

Description
Tangent frames are incorrect when using the JavaScript bindings to create them and set them into the vertex buffer.  See this discussion for screen shots: #4434 and #4441
To Reproduce
Here is some sample TypeScript code which illustrates the problem.  The WebGL material shader used is the same as in this issue: #4441
`
private testTangentFrames(engine: Filament.Engine, scene: Filament.Scene, matInst: Filament.MaterialInstance) {
        // Geometry
        var vertices: number[] = [
            -3.0, 1.0, 35.0,
            3.0, 1.0, 35.0,
            3.0, 1.0, 37.0,
            -3.0, 1.0, 37.0
        ];

        var indices: number[] = [0, 1, 2, 0, 2, 3];

        var uvCoords: number[] = [
            -2.5, -0.5,
            1.5, -0.5,
            1.5, 3.0,
            -2.5, 3.0
        ];

        var normals: number[] = [
            0.0, -1.0, 0.0,
            0.0, -1.0, 0.0,
            0.0, -1.0, 0.0,
            0.0, -1.0, 0.0
        ];

        var vertCount = vertices.length / 3;
        var triCount = indices.length / 3;

        // Create vertex buffer
        var vStride = 20;  // Pos + UVs (12 + 8)
        var vBuffer = Filament.VertexBuffer.Builder()
            .bufferCount(2)
            .vertexCount(vertCount)
            .attribute(Filament.VertexAttribute.POSITION, 0, Filament.VertexBuffer$AttributeType.FLOAT3, 0, vStride)
            .attribute(Filament.VertexAttribute.UV0, 0, Filament.VertexBuffer$AttributeType.FLOAT2, 12, vStride)
            .attribute(Filament.VertexAttribute.TANGENTS, 1, Filament.VertexBuffer$AttributeType.SHORT4, 0, 0)
            .normalized(Filament.VertexAttribute.TANGENTS)
            .build(this._engine);

        // Create index buffer
        var iBuffer = Filament.IndexBuffer.Builder()
            .bufferType(Filament.IndexBuffer$IndexType.USHORT)
            .indexCount(indices.length)
            .build(engine);

        // Create tangents
        var sob = new Filament.SurfaceOrientation$Builder();
        sob.vertexCount(vertCount);
        sob.normals(new Float32Array(normals), 0);
        sob.uvs(new Float32Array(uvCoords), 0);
        sob.positions(new Float32Array(vertices), 0);
        sob.triangleCount(triCount);
        sob.triangles32(new Uint32Array(indices));
        var orientation = sob.build();
        var quatsBuffer = orientation.getQuats(vertCount);

        // Interleave vertex data
        var vSize = vStride / 4;
        var interleave = new Float32Array(vertCount * vSize);
        var bBoxMinX, bBoxMinY, bBoxMinZ: number;
        var bBoxMaxX, bBoxMaxY, bBoxMaxZ: number;
        for (var idx = 0; idx < vertCount; ++idx) {
            //Positions
            var posX = vertices[idx * 3];
            var posY = vertices[idx * 3 + 1];
            var posZ = vertices[idx * 3 + 2];
            if (idx == 0) {
                bBoxMinX = bBoxMaxX = posX;
                bBoxMinY = bBoxMaxY = posY;
                bBoxMinZ = bBoxMaxZ = posZ;
            } else {
                bBoxMinX = Math.min(bBoxMinX, posX);
                bBoxMinY = Math.min(bBoxMinY, posY);
                bBoxMinZ = Math.min(bBoxMinZ, posZ);
                bBoxMaxX = Math.max(bBoxMaxX, posX);
                bBoxMaxY = Math.max(bBoxMaxY, posY);
                bBoxMaxZ = Math.max(bBoxMaxZ, posZ);
            }
            interleave[idx * vSize] = posX;
            interleave[idx * vSize + 1] = posY;
            interleave[idx * vSize + 2] = posZ;

            //UVs
            interleave[idx * vSize + 3] = uvCoords[idx * 2]
            interleave[idx * vSize + 4] = uvCoords[idx * 2 + 1]
        }

        // Set vertex and index buffer data
        vBuffer.setBufferAt(engine, 0, interleave, 0);
        vBuffer.setBufferAt(engine, 1, quatsBuffer, 0);
        iBuffer.setBuffer(engine, new Uint16Array(indices), 0);
        orientation.delete();

        // Bounding box
        var bbCenter: number[] = [(bBoxMinX + bBoxMaxX) / 2, (bBoxMinY + bBoxMaxY) / 2, (bBoxMinZ + bBoxMaxZ) / 2];
        var bbHalfExtent: number[] = [(bBoxMaxX - bBoxMinX) / 2, (bBoxMaxY - bBoxMinY) / 2, (bBoxMaxZ - bBoxMinZ) / 2];
        var bBox = new Box(bbCenter, bbHalfExtent);

        // Create mesh
        var newEntity = Filament.EntityManager.get().create();
        Filament.RenderableManager.Builder(1)
            .boundingBox(bBox)
            .material(0, matInst)
            .geometryOffset(0, Filament.RenderableManager$PrimitiveType.TRIANGLES, vBuffer, iBuffer, 0, indices.length)
            .culling(true)
            .castShadows(true)
            .receiveShadows(true)
            .build(this._engine, newEntity);

        // Add to scene
        scene.addEntity(newEntity);
    }

`
Expected behavior
See issue #4441 for screen shots of correct behavior on desktop using OpenGL backend
Additional context
I have done every permutation of parameters and vertex buffer attributes I can think of.  I believe the trouble must either exist in the shader, in SurfaceOrientation$Builder, or somewhere in the marshalling of tangent data between them.

Thanks for letting me know.  If we can get it fixed in the next couple of weeks, we are good.  If not, maybe I could get some pointers on how to approach this for library-level web debugging?

I took a look at our code and I don't see any obvious issue. Here's the getQuats() implementation:
    Filament.SurfaceOrientation.prototype.getQuats = function(nverts) {
        const attribType = Filament.VertexBuffer$AttributeType.SHORT4;
        const quatsBufferSize = 8 * nverts;
        const quatsBuffer = Filament._malloc(quatsBufferSize);
        this._getQuats(quatsBuffer, nverts, attribType);
        const arrayBuffer = Filament.HEAPU8.subarray(quatsBuffer, quatsBuffer + quatsBufferSize).slice().buffer;
        Filament._free(quatsBuffer);
        return new Int16Array(arrayBuffer);
    };

And _getQuats():
class_<SurfaceOrientation>("SurfaceOrientation")
    .function("_getQuats", EMBIND_LAMBDA(void, (SurfaceOrientation* self,
            intptr_t out, size_t quatCount, VertexBuffer::AttributeType attrtype), {
        switch (attrtype) {
            case VertexBuffer::AttributeType::FLOAT4: {
                self->getQuats((filament::math::quatf*) out, quatCount);
                break;
            }
            case VertexBuffer::AttributeType::HALF4: {
                self->getQuats((filament::math::quath*) out, quatCount);
                break;
            }
            case VertexBuffer::AttributeType::SHORT4: {
                self->getQuats((filament::math::short4*) out, quatCount);
                break;
            }
            default:
                utils::slog.e << "Unsupported quaternion type." << utils::io::endl;
        }
    }), allow_raw_pointers());

@romainguy  Nothing pops out as a problem to me, either.  I think it must be something subtle, such as: a SHORT4 value getting treated/cast as signed in one context and unsigned in another, for example.
Were you able to run my code and reproduce the error?  My problem is that I can't tell if the quaternion values the SurfaceOrientation$Builder generates are making it into the vertex buffer unaltered.  I suspect that they are getting interpreted incorrectly at some point in my process (such as signed/unsigned problems), but I can't tell where or how.

@romainguy @prideout
Any new revelations on this?

Thanks for figuring this out! I think we have an open bug already about transfer function related issues in mipgen (https://github.com/google/filament/issues/2422 but it seems ASTC specific). Is the issue here that we interpret the gamma field on normal maps?


rviz2 doesn't display a RobotModel when published with robot_state_publisher

Installed from debs, dashing with Fast-RTPS, version seems to be 20190923 (from the packages).
I'm trying to get a URDF model in rviz2. I have a simple launch file that creates a robot_state_publisher with a path to a URDF file, much like this example from the turtlebot3 repo.
I do this:

open rviz2
create a RobotModel display with the /robot_description topic
launch the robot_state_publisher node with the launch file mentioned above

I would expect the model to appear, but it does not, even if I create the display only after launching the node.
From looking at the source code for robot_state_publisher @ dashing (or 2.2.4), I think this is normal, as it is only published after getting joint positions (which I do not provide/publish since this is a "static" model). This was changed in the ros2 branch to be published in the constructor, so I compiled this branch from source. However, it still does not work.
What does work, though, is the following:

open rviz2
create a RobotModel display with the /robot_description topic
launch the robot_state_publisher node with the launch file mentioned above
in another terminal: ros2 topic echo /robot_description

The model appears in rviz2 right after ros2 topic echo /robot_description, but the message doesn't get printed. Interestingly, this does not work if I swap steps 3 and 4.
@wjwwood mentioned that this might've gotten fixed already (haven't tried using rviz2 from source), but I can't find any related PR here or in robot_state_publisher.
Note: in my case, since I'm using a static model, I just switched to using a "File" description source.

Also, you're using the dashing debs and fastrtps as the rmw implementation, right?

Also, you're using the dashing debs and fastrtps as the rmw implementation, right?

Yep! Sorry, should've included it.

I'm able to reproduce the issue using the latest dashing debs. I'm not able to reproduce using the latest sources or eloquent debs. The robot model shows up regardless which order I start robot_state_publisher or rviz2.
Using dashing I don't see the robot model when running the steps below. I also don't see the robot_model if I launch robot_state_publisher before rviz2. There's no console output from rviz2 to indicate what the issue is.

rviz2
Manually set fixed frame to base_link (no tf data yet, must type manually)
Add RobotModel display set to /robot_description topic
TURTLEBOT3_MODEL=waffle ros2 launch turtlebot3_bringup turtlebot3_state_publisher.launch.py

However, I'm not able to reproduce the model appearing after running ros2 topic echo /robot_description. I haven't found a way to make the model appear in RViz using dashing.

From looking at the source code for robot_state_publisher @ dashing (or 2.2.4), I think this is normal, as it is only published after getting joint positions (which I do not provide/publish since this is a "static" model).

I am able to get the robot model to display in Dashing if I call ros2 topic pub /joint_states sensor_msgs/msg/JointState "{}", so it seems like this should be an issue on robot_state_publisher. Whatever was fixed there for eloquent should be backported to dashing.

So in dashing, robot_state_publisher doesn't publish any transforms at all until at least one /joint_state message is received.  This was changed in Eloquent to always publish the static transforms during the constructor.  I was somewhat hesitant to change it in Dashing, since it is a change of behavior, but it is probably innocuous.  @sloretz if you want to do a backport of that change, I can review it.

@sloretz / @clalancette the relevent PR is this one, I think: ros2/robot_state_publisher#24

https://github.com/ros/rosdistro/pull/23210

The fix should be in the next Dashing patch release. I'll close this for now.


Construct gopath for automated integration test

@nkubala PTAL

I update the README in the tests/ directory. Is there any reason to split them up into subdir? I think this directory is where we land when we look for tests.

Reminder, do mention how to update the package dependencies of tests/integration/src/app in the readme.  I'm ok with keeping only one readme.


Fixes contact page responsive

Questions
Answers

Description?
Changed col classes that were causing a responsive issue on 767px to 567px screen sizes. col-sm-4 was changed tocol-md-4and col-md-3 was changed to col-lg-3.

Type?
bug fix

BC breaks?
no

Deprecations?
no

Fixed ticket?
Fixes  #33415

Sponsor company
Not applicable

How to test?
See ticket. Navigate to Contact us page  -> Use responsive mode, click F12 -> Shrink the window to width 650px -> See fix > columns now display correctly in tablet.

@Slaveworx Hey, good change. Please, rebase it onto 2.1.x, these merge prs don't work very well. Thank you! :-)

I have completed the rebase onto 2.1.x.

@Slaveworx if you just change the target branch, you also get a lot of unwanted commits
You need to either use git rebase or git cherry-pick
I recommend cherry pick

@Slaveworx if you just change the target branch, you also get a lot of unwanted commits
You need to either use git rebase or git cherry-pick
I recommend cherry pick

Should I just close this PR and submit a new one with the updated branch?


请问下这个错误是什么意思？win10系统，在运行 pip install -e .时发生

(lmflow) PS C:\dev\LMFlow> pip install -e .
Obtaining file:///C:/dev/LMFlow
Preparing metadata (setup.py) ... done
Collecting peft@ git+https://github.com/huggingface/peft@df0e1fb
Cloning https://github.com/huggingface/peft (to revision df0e1fb) to c:\users\zhengshuchang\appdata\local\temp\pip-install-9cde5r5s\peft_d2963c5c488c4da6aa4bfcf8d2db8f1d
Running command git clone --filter=blob:none --quiet https://github.com/huggingface/peft 'C:\Users\zhengshuchang\AppData\Local\Temp\pip-install-9cde5r5s\peft_d2963c5c488c4da6aa4bfcf8d2db8f1d'
WARNING: Did not find branch or tag 'df0e1fb', assuming revision or ref.
Running command git checkout -q df0e1fb
Resolved https://github.com/huggingface/peft to commit df0e1fb
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Collecting trl@ git+https://github.com/lvwerra/trl.git#egg=trl-0.4.1
Cloning https://github.com/lvwerra/trl.git to c:\users\zhengshuchang\appdata\local\temp\pip-install-9cde5r5s\trl_ef2eb4c9fb8241c083f1a3357c8a3760
Running command git clone --filter=blob:none --quiet https://github.com/lvwerra/trl.git 'C:\Users\zhengshuchang\AppData\Local\Temp\pip-install-9cde5r5s\trl_ef2eb4c9fb8241c083f1a3357c8a3760'
Resolved https://github.com/lvwerra/trl.git to commit ed87942a47f26d15e823ca7674737be02e48cc0a
Preparing metadata (setup.py) ... done
Collecting transformers@ git+https://github.com/huggingface/transformers@c612628
Cloning https://github.com/huggingface/transformers (to revision c612628) to c:\users\zhengshuchang\appdata\local\temp\pip-install-9cde5r5s\transformers_6ac4cbbfe28a4bba8cd5cd04e6218993
Running command git clone --filter=blob:none --quiet https://github.com/huggingface/transformers 'C:\Users\zhengshuchang\AppData\Local\Temp\pip-install-9cde5r5s\transformers_6ac4cbbfe28a4bba8cd5cd04e6218993'
error: unable to create file templates/adding_a_missing_tokenization_test/cookiecutter-template-{{cookiecutter.modelname}}/test_tokenization_{{cookiecutter.lowercase_modelname}}.py: Filename too long
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
error: subprocess-exited-with-error
× git clone --filter=blob:none --quiet https://github.com/huggingface/transformers 'C:\Users\zhengshuchang\AppData\Local\Temp\pip-install-9cde5r5s\transformers_6ac4cbbfe28a4bba8cd5cd04e6218993' did not run successfully.
│ exit code: 128
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.
error: subprocess-exited-with-error
× git clone --filter=blob:none --quiet https://github.com/huggingface/transformers 'C:\Users\zhengshuchang\AppData\Local\Temp\pip-install-9cde5r5s\transformers_6ac4cbbfe28a4bba8cd5cd04e6218993' did not run successfully.
│ exit code: 128
╰─> See above for output.
note: This error originates from a subprocess, and is likely not a problem with pip.

This issue has been marked as stale because it has not had recent activity. If you think this still needs to be addressed please feel free to reopen this issue. Thanks 😄


Acrobat: footer disappears on pages with only (block) image

I've added an example on an extra branch on one of our repos: https://github.com/vogellacompany/com.vogella.tutorials.nattable/commit/c52ee8a45b6663a15e4d195fc380ddadde76139d
The example needs to get called with our theme: [...]/asciidoctor-pdf/bin/asciidoctor-pdf -d book -a pdf-style=[...]/com.vogella.tutorials.nattable/themes/basic-theme.yml 001_book_print_test.adoc
I've also attached already converted pdfs that show the bug. The last page of the example pdf is affected.
If the generated pdf contains a page with only an image, without text, the footer doesn't get printed and Acrobat complains about an error.
We have seen this error in Acrobat 8, Acrobat 9 and Acrobat Pro DC.
When the pdf is opened with other readers the footer gets shown without an error.
This is a problem for us because the print shops tend to use Acrobat products only.

book_nattable_with_text.pdf
book_nattable_without_text.pdf
CC @jnerlich, thank you for initial report

@fap- so far https://github.com/vogellacompany/com.vogella.tutorials.nattable is a private repo. I talk to Dirk, if we can make it publish. I see no reason against it, but Dirk wrote most of the content, so I need to check with him.

Ah, theoretically an asciidoc file with only one page and an block image should do the trick too, but I can't test it right now, need to get an Acrobat version running first.

Variations of this issue have appeared before. The problem seems to be that a page requires certain PDF objects to be present or defined. Prawn doesn't seem to verify that the PDF structure is correct, so we end up with cases when the objects aren't constructed properly. When that happens, we see missing content in Acrobat. If I understood what to look for, I would have a better idea of how to solve this problem globally. So far, I've only been able to come up with workarounds or hacks.
So the key here is to open up the PDF source and try to study what is different about the page that has the error...or what seems missing. It often has to do with pages that have no text. Hopefully, we can finally get to the bottom of this.

I'll share that one of the workarounds I've used in the past is this:
update_colors

I call that before starting a new page in this instance.
That seems to add some sort of declaration to the PDF page object that makes the reader happy.

I'm not sure how you did this.
Which function would we need to overwrite? Do you put it into the on_page_create block?

When I say "open up the PDF source" I mean open up the PDF in a text editor. It's just plain text (with some encoded parts).
Essential what is missing from the page stream is something like:
/DeviceRGB cs
0.200 0.200 0.200 scn
/DeviceRGB CS
0.200 0.200 0.200 SCN

This declaration has to exist if there is any text on the page. It seems that Prawn does not check to make sure this is in the stream before creating a stamp. So we have to make sure each page has it ourselves. We could add call update_colors in the convert_image method, and that will handle this case. But there are tons of permutations when a page has no text in the content part. I really don't know a solution that is going to work universally yet. We'll just have to keep on trying.

Maybe we can get the running content to add this to the page stream, but I don't know if that will actually work.

Note that Ghostscript will detect this error too, so the PDF is technically invalid if text is written to a page without a color space being set at the start of the stream.

As it turns out, I had a patch for this in the converter already, but only for certain scenarios. I missed the scenario of a page break immediately after an image occurring at the top of the page.

I think I figured out the right fix to handle all scenarios when an image appears on a page by itself. This applies to both raster and vector images.
I also checked inline images that are on a page by themselves. It appears that in those cases, Prawn sets the color space properly, so we're covered there too.

Thanks @mojavelinux, issue is solved with this solution.

Thanks for testing!


Fix to parametize hardcoded JVM value (because 384m turned out to be insufficient for me)

Instead of forcing a default of -Xmx384m, set this value only if no other argument is given.

Target repo is obsolete.


ISPN-5641, ISPN-5640, ISPN-5639 replicated write performance

https://issues.jboss.org/browse/ISPN-5639
https://issues.jboss.org/browse/ISPN-5640
https://issues.jboss.org/browse/ISPN-5641

@wburns I removed timeout().

@danberindei looks good to me :)

Looks good, pulling...

Integrated into master, thanks @danberindei !


Faraday::Error: :json is not registered on Faraday::Response

While running through your example in the README, it seems there's a problem with the way you're using faraday
connection      =   luminati.get_connection(country: nil, dns_resolution: nil, session: nil)
Faraday::Error: :json is not registered on Faraday::Response
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday.rb:189:in `lookup_middleware'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday/rack_builder.rb:203:in `use_symbol'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday/rack_builder.rb:96:in `response'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:99:in `block in build_connection'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday/connection.rb:91:in `initialize'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday.rb:70:in `new'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/faraday-0.9.1/lib/faraday.rb:70:in `new'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:97:in `build_connection'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:79:in `get_response'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:45:in `fetch_master_proxy'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:24:in `get_connection'
	from (irb):6
	from /opt/twitter/rvm/rubies/ruby-2.2.0/bin/irb:11:in `<main>'

Using ruby-2.2.0

Further investigation shows that json was removed from the newer version of faraday:
http://stackoverflow.com/questions/10654232/runtimeerror-json-is-not-registered-on-faradayrequest
I added require 'faraday_middleware'
but now I get:
NoMethodError: undefined method `present?' for "invalid params":String
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:89:in `check_response_for_errors'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:83:in `get_response'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:45:in `fetch_master_proxy'
	from /opt/twitter/rvm/gems/ruby-2.2.0@niche/gems/luminati-0.0.2/lib/luminati/client.rb:24:in `get_connection'
	from (irb):8
	from /opt/twitter/rvm/rubies/ruby-2.2.0/bin/irb:11:in `<main>'

Hey, glad that you're giving the gem a try :).
You are right, the json adapter apparently moved to faraday_middleware a while back. Due to not testing the gem in an isolated environment but rather testing it within a Rails app that included both Faraday/FardayMiddleware (was faster to do it that way when hacking together the gem) I didn't run into that issue. I've fixed it now though, as well as adding specs for testing the gem in an isolated environment.
Also, the error you received in terms of 'present?' means that you probably are not running the gem in an Rails environment. I've updated it to use !.empty? instead (which is the correct way).
Please give the new version 0.0.3 a try and report back if you still run into any issues:
gem 'luminati', '~> 0.0.3'


Ping issue?

I'm not sure it is a proper place for discussion though...
We are using SkyDNS for containers running it as a service on docker host and passing --dns ${PRIVATE_IPV4} --dns-search=skydns.local to the DOCKER_OPTS
People set CNAME's and use them and I was reported that ping failed randomly for them returning ping: unknown host.
Some quick and dirty example to reproduce the issue:
supervisord.conf:
[supervisord]
nodaemon=true

[program:etcd]
priority=1
command=/etcd-v3.0.9-linux-amd64/etcd

[program:etcdctl-lol]
command=/etcd-v3.0.9-linux-amd64/etcdctl set /skydns/local/skydns/lol '{"host":"google.com"}'

[program:skydns]
priority=2
command=/skydns -nameservers <IP_ADDRESS>:53,<IP_ADDRESS>:53

FROM debian

RUN \
    apt-get update && \
    apt-get install -y --no-install-recommends dnsutils curl wget supervisor && \
    curl -kL https://github.com/coreos/etcd/releases/download/v3.0.9/etcd-v3.0.9-linux-amd64.tar.gz -o etcd-v3.0.9-linux-amd64.tar.gz && \
    tar xzvf etcd-v3.0.9-linux-amd64.tar.gz

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
COPY skydns /skydns

CMD ["/usr/bin/supervisord"]

Skydns^^^ binary just precompiled and copied from the folder with Dockerfile.
$ docker run --dns=<IP_ADDRESS> --dns-search=skydns.local  skydns-check
WARNING: Localhost DNS setting (--dns=<IP_ADDRESS>) may fail in containers.
/usr/lib/python2.7/dist-packages/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
  'Supervisord is running as root and it is searching '
2016-09-22 14:29:13,450 CRIT Supervisor running as root (no user in config file)
2016-09-22 14:29:13,450 WARN Included extra file "/etc/supervisor/conf.d/supervisord.conf" during parsing
2016-09-22 14:29:13,459 INFO RPC interface 'supervisor' initialized
2016-09-22 14:29:13,459 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2016-09-22 14:29:13,460 INFO supervisord started with pid 1
2016-09-22 14:29:14,463 INFO spawned: 'etcd' with pid 7
2016-09-22 14:29:14,464 INFO spawned: 'skydns' with pid 8
2016-09-22 14:29:14,469 INFO spawned: 'etcdctl-lol' with pid 9
2016-09-22 14:29:14,738 INFO exited: etcdctl-lol (exit status 0; not expected)
2016-09-22 14:29:15,740 INFO success: etcd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-09-22 14:29:15,740 INFO success: skydns entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-09-22 14:29:15,742 INFO spawned: 'etcdctl-lol' with pid 23
2016-09-22 14:29:15,760 INFO exited: etcdctl-lol (exit status 0; not expected)
2016-09-22 14:29:17,764 INFO spawned: 'etcdctl-lol' with pid 27
2016-09-22 14:29:17,782 INFO exited: etcdctl-lol (exit status 0; not expected)
2016-09-22 14:29:20,789 INFO spawned: 'etcdctl-lol' with pid 31
2016-09-22 14:29:20,808 INFO exited: etcdctl-lol (exit status 0; not expected)
2016-09-22 14:29:21,809 INFO gave up: etcdctl-lol entered FATAL state, too many start retries too quickly
...

$ docker ps
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS              PORTS               NAMES
09cba0de4071        skydns-check                             "/usr/bin/supervisord"   12 minutes ago      Up 12 minutes                           fervent_banach

$ docker exec -ti 09cba0de4071 /etcd-v3.0.9-linux-amd64/etcdctl get /skydns/local/skydns/lol
{"host":"google.com"}

So, nslookup, host, dig(FQDN-only) always work. Name resolution works.
wget and curl and all internal mechanisms for communicating via http work as well.
I need to mention that the above example with google.com is not a good one because wget and curl seem to not perform the request successfully returning something like:
$ docker exec -ti 09cba0de4071 curl -Lv lol
* Rebuilt URL to: lol/
* Hostname was NOT found in DNS cache
*   Trying <IP_ADDRESS>...
* Connected to lol (<IP_ADDRESS>) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: lol
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=UTF-8
< Content-Length: 1561
< Date: Thu, 22 Sep 2016 14:48:14 GMT
<
<!DOCTYPE html>

  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>

404. That’s an error.

The requested URL / was not found on this server.  That’s all we know.
* Connection #0 to host lol left intact

But that's ok because the host resolves successfully into the ip address.
But when we go to ping we get something like:
$ for i in {1..100}; do docker exec -ti 09cba0de4071 ping -c1 lol > /dev/null 2>&1 || echo notok; done | wc -l
      15

ping utility being shipped with at least debian and ubuntu works like this one above returning ping:unknown host randomly. busybox-based (alpine for instance) distros which rely on busybox-brewed toolset always resolve this lol CNAME.
So for now I can only blame ping for using obsoleted methods but if you could have a look on this from your perspective and perhaps shed some light I would highly appreciate!

This is prolly #217
Note that I'm working on a (better) replacement for SkyDNS: CoreDNS (https://coredns.io) and I would love to get some production feedback on that.

will do and get back with the results shortly, thanks!

what should my Corefile look like for the above setup?
I use
.:53 {
    etcd skydns.local {
        upstream <IP_ADDRESS>:53 <IP_ADDRESS>:53
        debug
    }
    cache 160 skydns.local
    proxy . <IP_ADDRESS>:53 <IP_ADDRESS>:53
}

but it does not help resolve lol

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." ]

what should my Corefile look like for the above setup?
I use
.:53 {
   etcd skydns.local {
       upstream <IP_ADDRESS>:53 <IP_ADDRESS>:53
       debug
   }
   cache 160 skydns.local
   proxy . <IP_ADDRESS>:53 <IP_ADDRESS>:53
}

but it does not help resolve lol

interesting... Corefile looks about right.
	IN	A

;; AUTHORITY SECTION:
skydns.local.		160	IN	SOA	ns.dns.skydns.local. hostmaster.skydns.local.<PHONE_NUMBER> 7200 1800 86400 60

;; ADDITIONAL SECTION:
.			160	CH	TXT	"client: etcd cluster is unavailable or misconfigured\; error #0: unsupported protocol scheme \"\"\010\; error #1: unsupported protocol scheme \"\"\010"

;; Query time: 9 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Sep 26 07:57:08 UTC 2016
;; MSG SIZE  rcvd: 259

hmm.... client: etcd cluster is unavailable or misconfigured\; error #0: unsupported protocol scheme \"\"\010\; error #1: unsupported protocol scheme \"\"\010
# curl localhost:2379/v2/keys/skydns/local/skydns/lol
{"action":"get","node":{"key":"/skydns/local/skydns/lol","value":"{\"host\":\"google.com\"}","modifiedIndex":7,"createdIndex":7}}```

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." 	IN	A

;; AUTHORITY SECTION:
skydns.local.		160	IN	SOA	ns.dns.skydns.local. hostmaster.skydns.local.<PHONE_NUMBER> 7200 1800 86400 60

;; ADDITIONAL SECTION:
.			160	CH	TXT	"client: etcd cluster is unavailable or misconfigured\; error #0: unsupported protocol scheme \"\"\010\; error #1: unsupported protocol scheme \"\"\010"

;; Query time: 9 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Sep 26 07:57:08 UTC 2016
;; MSG SIZE  rcvd: 259

hmm.... client: etcd cluster is unavailable or misconfigured\; error #0: unsupported protocol scheme \"\"\010\; error #1: unsupported protocol scheme \"\"\010
# curl localhost:2379/v2/keys/skydns/local/skydns/lol
{"action":"get","node":{"key":"/skydns/local/skydns/lol","value":"{\"host\":\"google.com\"}","modifiedIndex":7,"createdIndex":7}}

Other names work, it is just 'lol'? 'cause json looks OK (also I think you would
then get an actual json error).
Also debug queries FTW!

dig o-o.debug.google.com @localhost works for instance
I'm trying to figure out why I get this:

;; ADDITIONAL SECTION:
.	160	CH	TXT	"client: etcd cluster is unavailable or misconfigured; error #0: unsupported protocol scheme ""\010; error #1: unsupported protocol scheme ""\010"

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." ]

dig o-o.debug.google.com @localhost works for instance

That's prolly going out and not going to the etcd cluster.
Note your logs are full of:
2016-09-22 14:29:15,740 INFO success: skydns entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-09-22 14:29:15,742 INFO spawned: 'etcdctl-lol' with pid 23
2016-09-22 14:29:15,760 INFO exited: etcdctl-lol (exit status 0; not expected)
2016-09-22 14:29:17,764 INFO spawned: 'etcdctl-lol' with pid 27

I'm trying to figure out why I get this:

;; ADDITIONAL SECTION:
.	160	CH	TXT	"client: etcd cluster is unavailable or misconfigured; error #0: unsupported protocol scheme ""\010; error #1: unsupported protocol scheme ""\010"

--
You are receiving this because you commented.
	IN	A

;; ANSWER SECTION:
lol.skydns.local.	160	IN	CNAME	google.com.
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>

;; ADDITIONAL SECTION:
lol.skydns.local.	160	CH	TXT	"google.com:0(10,0,,false)[0,]"

;; Query time: 23 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>)
;; WHEN: Mon Sep 26 09:36:54 UTC 2016
;; MSG SIZE  rcvd: 249

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." ]

ok cool
Setting up the endpoint explicitly like

cool :)

.:53 {
   etcd skydns.local {
       upstream <IP_ADDRESS>:53
       endpoint http://localhost:2379
       debug
   }
   proxy . <IP_ADDRESS>:53
}

did the trick!

also interesting. Let check/fix that.

root@0dc01a1d4d65:/# dig o-o.debug.lol.skydns.local

;; ANSWER SECTION:
lol.skydns.local.	160	IN	CNAME	google.com.
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>
google.com.		160	IN	A	<IP_ADDRESS>

Looks very much OK to me. Is ping still unhappy? When happens when you point
to example.org as that has only 1 IP instead of the 8 that google.com uses.
And what happens when you use www.google.com instead of google.com?
/Miek
--
Miek Gieben

testing with our local setup shows that multi-dot hosts and 1-IP hosts work ok.
ping is happy and it is definitely because of #217

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." ]

testing with our local setup shows that multi-dot hosts and 1-IP hosts work ok.
ping is happy and it is definitely because of #217

Ack. Yes that shouldn't happen with CoreDNS, I haven't backported that fix to
skydns though

can CoreDNS be considered a production-ready drop-in replacement for SkyDNS?
I will test it by myself of course but the main question is what is the future of SkyDNS and will CoreDNS replace SkyDNS in Kubernetes?

[ Quoting<EMAIL_ADDRESS>in "Re: [skynetservices/skydns] Ping is..." ]

can CoreDNS be considered a production-ready drop-in replacement for SkyDNS?

well.. yes, but's newer. Production ready is when people use it in production.
The etcd code is lifted from SkyDNS and cleaned up, but there could still be
bugs lurking.
I want people to use it in prod and report bugs, so they can be fixed. I'm using
CoreDNS in production myself, but only as an authoritative server without using
the etcd backend.

I will test it by myself of course but the main question is what is the future of SkyDNS and will CoreDNS replace SkyDNS in Kubernetes?

The hope is CoreDNS will replace SkyDNS in k8s, yes. See the 002 milestone bugs
in CoreDNS's issue tracker; when those are fixed, CoreDNS should more than capable
of replacing SkyDNS in k8s.
/Miek
--
Miek Gieben


Edit Public Chat!

Hello James...I Want To Edit The Public Chat But I Don't Know How Maybe You Could Add Public Chat Format In The Config.. Thanks

I think this plugin not handle public chat!
You should use other plugins (like Deluxechat or EssentialsChat) to handle public chat

im ok now thanks...I find out that I can Edit it With The Faction Plugin
ChatFormat
On Fri, Feb 24, 2017 at 12:07 PM, Tuanjr<EMAIL_ADDRESS>wrote:

I think this plugin not handle public chat!
You should use other plugins (like Deluxechat or EssentialsChat) to handle
public chat
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/James137137/FactionChat/issues/32#issuecomment-282198847,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AYpS5_fxOWF3f-OaLOqBe0eieYhjYirWks5rfldmgaJpZM4MIlPT
.

tuanjr is correct. FactionChat doesn't handle the public chat


v1.0 - empty package compatible with psr/log 1.1

1st part of #4 (before #6)
Add tests to track compatibility in future versions. Tests don't have to run on old versions of PHP: the tested classes will not be updated.

Tests are running on my fork: https://github.com/GromNaN/log-util/actions/runs/1684548606

Thank you :+1:


Day251

Resolves #517 .

Pull Request Test Coverage Report for Build 970

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 968:
0.0%

Covered Lines:
5

Relevant Lines:
5

💛  - Coveralls


Could not find gem 'be_gateway' in rubygems repository

With config from readme:
gem 'be_gateway'

I have this error:
Could not find gem 'be_gateway' in rubygems repository https://rubygems.org/
or installed locally.

Hi @mario-amazing
Good notice! We have to update the readme, cause gem is not hosted on RubyGems.
Nevertheless, you could define source from github in your Gemfile like this:
gem 'be_gateway', tag: '1.0.3', git: 'https://github.com/begateway/client_ruby.git'

Nice, could you update Readme? @shveikus


Remove deprecation warnings (staticfiles, logger.warn) ahead of Django 3.0 upgrade

Testing

python3 -Wa manage.py test orchestra >test-orchestra.log 2>test-orchestra.log
grep Warning test-orchestra.log
Address relevant warnings
Smoke test Orchestra by clicking around the experience.

Coverage remained the same at 92.545% when pulling 5e8dbdc4c990f00182bc177a02f3c4bca572e485 on django-2.2.-remove-warnings into d93c027e2789cf9d9495b18e790175eafb59c21d on main.


Delta updates

Is it possible to add observations to a model without having to fit the entire model again? I'd like to see how kickscore performs when it has observed all matches before a certain match for all matches in my dataset, but this is not feasible when I have to run .fit each time with 70000 matches.

Hi @liampwll you can definitely add observations after fitting a model. When you call fit() again, it doesn't start from scratch, but instead uses the score estimates from the previous call.
Here are some ideas on how to save time if you want to retrain & evaluate on many matches:

you could limit the number of iterations to 1 or 2 per call fit(max_iter=1) after adding every match. (Every 100 matches or so, it would probably be good to let it run to convergence again, with a higher number of iterations)
typically you don't need to retrain after every match. I typically batch together matches that occurred on the same day.

This being said, I don't know the exact application you have in mind.
Also, if you're OK with slightly less accurate predictions, you can check out (TrueSkill)[https://trueskill.org/], which has constant-time updates.


flake8 everything - prep for precommit

closed in https://github.com/niaid/image_portal_workflows/pull/208


Files break when I try to open the WSL filesystem

Description
Files break when I try to open the WSL filesystem.
WSL 2
Ubuntu-20.04
Steps To Reproduce

Open File
Try to open the WSL dir

Expected behavior
Can open the WSL dir on Files
Files Version
Versión: <IP_ADDRESS> OS Version: 10.0.19043.1466
Windows Version
Windows 10 Home 19043.1466
Relevant Assets/Logs
debug.log
debug_fulltrust.log

@david-minaya is this still an issue in the preview version? https://files.community/download/preview


Add types aliases used in flet into aliases.md.

Add types aliases used in flet into aliases.md. For types that have information in /docs/reference/types, I have added a link to them. But I have left linking Animation, Offset, Rotate and Scale as they are not present there.

Thanks again.
I am just from noticing that we lack these types you mentioned (rotate, scale, ...).
You can add them if you wish, simply by following the already present types.
Also, please don't forget to mention this aliases where possible. For example, all the padding-related props should have "Value is of type PaddingValue...", same for the border-radius-related props, etc.

@ndonkoHenri
I have "copied" the documentation from flutter docs (Transform widget docs).
Also, I have left the alignment property of Rotate class because I had no clue what would the property do.

Thanks again for your efforts!

Also, please don't forget to mention this aliases where possible. For example, all the padding-related props should have "Value is of type PaddingValue...", same for the border-radius-related props, etc.

If you have time, you could also do this. 🙂

By the way, you need to include the new files in the sidebar.js for them to be visible on the website.

yes. I was thinking about how the files in the types folder go into their specific "types" in the documentation on web. Didn't know it was sidebar.js (by the way I don't know js)

Should I mention type aliases of many controls in this same pull request. I was thinking there could be pull requests one after the other.

Okay, so merge this pr. I will do remaining in next prs


Certain legacy server versions crash while trying to load mods

When trying to load a 1.7.2 server with Quilt and a mod, the game crashes due to a MixinTargetAlreadyLoadedException. With the help of @SpaceWalkerRS, we tested on other versions and found that the same issue exists in 1.8.9, but not 1.9 nor 1.6.4.
I looked into it more deeply and found that the log4j2.xml file in 1.7.2 is slightly different from the one in 1.9; more specifically, the packages attribute in the Configuration element lists net.minecraft and com.mojang in 1.7.2, whereas 1.9 only lists com.mojang.util. I guess while trying to find Log4j plugins, the class loader loads every class within the listed packages, in turn loading Minecraft classes earlier than anticipated and breaking Mixin processing. (The server jar started bundling Log4j in 13w39a, any older versions don't have the class loading issue, seemingly because they don't use Log4j.)
While stepping through the code in a debugger, I found that there's a mechanism in KnotClassDelegate that restricts certain classes from being loaded, so I think this issue might have something to do with that?

mechanism in KnotClassDelegate that restricts certain classes from being loaded
I think the problem is just showing there, that's not the place to fix it.

I think it should be fixed by making log4j only load when the class loading + mixin applying is set up.
Because from my understanding of reading this, the loader does:

log4j plugins finding loads classes for checking for logging stuff
mixin setup is finished
mc entry point is called

I think in this case, the log4j trying to load classes while mixin isn't ready is the problem
care should be taken in ensuring classes only attempt to load classes from the knot class loader after the knot class loader can load + apply mixins to classes


Remove version: BeagleSoftware.BeagleEditor version 2024.4

It is old and it has a bug and should not be used
Microsoft Reviewers: Open in CodeFlow

URL: https://github.com/beaglesoftware/beagleeditor/releases/download/v2024.4/BeagleEditor-2024.4-Installer.exe
OK
(Automated message - build 923)


Store locations of expenses

To close #18 I implemented a first iteration for storing locations of expenses. It adds a new card to the expense form where users can see and change the location of where an expense was made.
Users can choose between having their current location determined (by accessing navigator.geolocation) and manually setting/correcting it by dragging the position marker on the map; alternatively they can also place it somewhere by clicking/tapping on the map.
Locations are stored in a separate table Point, which has a 1:1 relationship to Expense, this way it is ensured that a position always consists of both latitude and longitude (or otherwise it just does not exist). Initially my plan was to use the point datatype of Postgres for storage, but unfortunately at this point the Prisma ORM does not support the PG geometric data types (and apparently it will not any time soon).
Screencast
https://github.com/spliit-app/spliit/assets/31203844/31c86ad0-ba88-4bd1-9c84-a602329a82d3

Awesome feature, great job!
Extra suggestion: Could you maybe add a textfield (e.g. under the expense date) that allows you to freely describe a location without having to put a marker on a map? Then you could add a button right next to that textfield that links towards the Location card to further specify it/put an exact marker.

Thank you for the feedback! @dcbr

Could you maybe add a textfield (e.g. under the expense date) that allows you to freely describe a location without having to put a marker on a map? Then you could add a button right next to that textfield that links towards the Location card to further specify it/put an exact marker.

Intuitively it feels a bit like creating a redundancy, as such a free-text description/mentioning of a location can already be done as part of the existing input fields (title or notes). I find myself usually writing the name of a place, where an expense was made, into the title, i. e. "Dinner at 4 seasons". Also I can imagine that for users it might be a bit confusing to have two different points in the app page where to store location-related details (the input field in the top card and then further down the location card with the map view). From your perspective, what would be the benefit to add another input field to the already existing ones?

My idea was that this free text location description could be used in the expense overview list (which doesn't make sense for coordinates only). I quickly drew an example on the figure below (extracted from your video).

That's a bit cleaner than putting the location information in the title (or notes), in my opinion. It might also make location based filtering easier if that would be added in the future.
Regarding the UI inside the expense form, we might have to fine tune that a bit. But I guess if both the text input and map view are close together, it shouldn't be too confusing.
Now that I think about it, it might be possible to extract the city name automatically from the marker location? That would also "suit my needs", although others might want to specify alternative descriptions (including street names for example, or only the country), hence why I would make it free-text. Or maybe we could make this a group setting (e.g. show country only, country + city, city only, city + street)?


Window Data Folder Fix

Make sure the xdg.data folder is created on windows

Fixes #115

Tested this in v0.0.15-pre1 on a windows 10 machine that never had VSCode installed I still get the same error as reported.

Pushed a commit to fix a stray bracket and tested everything against 15-pre3 :rocket:
But it did spawn another issue after launch #119


Update api

I have no idea what all these changes are?

this was just for testing the go-swagger openapi code generation, but its still faulty.
its not meant to be merge, sry for leaving it open


Restore the behavior that failing to create a venv fails the pipeline.

Restore prior behavior:  when venv fails to install, fail the execution, but add  actionable logs. See: #26792 for context.

R: @lostluck
cc: @robertwb @phoerious

tested both default and opt-out codepaths on Dataflow.

R: @liferoad

Failure not related to this PR, merging
Thanks!


Helper features for direction value (orthogonal direction, toward nearest point at line, etc.)

Description
tl;dr: Entering directions numerically as degrees leads to guesses, trial-and-error. Many directions could be derived by existing features or by use of aerial imagery and simply pointing in the correction direction.
More detailed:
As directions are usually parallel or orthogonal with existing features it would be helpful to use derived values from these features as options.
At the moment it is hard to figure out whether a chosen direction matches existing features' directions (e.g. sides of a building where the direction is not specified as a tag, but could be derived from the two points for that line segment). Currently the direction feature simply accepts numerical input as well as increment/decrement in 5 degree steps. It is not easy to know the correct direction in advance.
A workaround is to move the new feature next to the existing feature and changing the direction manually and simply eyeballing whether the the circle sector ⌔ lines up nicely. But this is cumbersome and usually requires trial-and-error when entering a specific direction.
This might break the simplicity principle of iD. However these are mainly suggestions for ease of use and no more complicated in the user interface than adding a new context menu feature. iD can already derive that information for existing features and we should make use of that.
Using existing non-connected lines
Several features usually face specific other features, e.g. benches that often face a path, road or pond, or face directly away from the side of a building.
Some features usually run in parallel with specific other features, such as a traffic sign mapped as a separate node.
Placements directly on walls and other ways
A plaque or other feature hanging on a wall would usually face in an orthogonal direction. Based on the type of feature the default suggestion could be in the direction e.g. facing away or into/inside a building wall/way.
This would simply be a suggestion of (calculated way direction ± 90 degrees). For a corner it might be the average of the two directions (again, facing inward or outward based on the circumstances).
Implementation
Following the simplicity principle of iD this should not be more advanced than e.g. moving a node.
My suggestion is to add a "Set direction" option when right clicking a node.

The direction should be facing the user's pointer (making it easy to set a correct direction based on aerial imagery as opposed to guesstimate degrees).
If the pointer hovers over a point the direction should face the point.
If the pointer hovers over a line the direction should face the nearest point on that line segment.

As some directions should be orthogonal and other should be parallel by their nature this could also be taken into consideration. Otherwise changes in 90 (or 45) degrees steps should be easily possible as opposed to clicking the increment/decrement 18 times to rotate by 90 degrees.
There is already the possibility of flipping the direction (hotkey: v) for a feature. Actually selecting and setting the direction should be just as easy.
Screenshots
Example of a bench where the direction could have the possibility of having its direction set facing the nearest position on a selected way (even if that position on the line does not exist as its own point)

This would be a huge time-saver for me as I map stuff like traffic signs and historic markers.
I suspect that anything involving a new gesture-based mode would be tricky to design and implement. Maybe as a half-measure, we can address the need by having the direction field’s increment and decrement buttons “snap” to nearby ways’ tangents as well as the 5-degree increments? The choice of nearby ways to consider could differ based on the current preset. It would require more clicking than what you’re proposing, but the direction cone in the canvas will update interactively to show the user how close they are to the desired angle.


added GH sponsors link in navigation

@m1ga might you have a look at this?

@caspahouzer why did you delete this?

@m1ga Erased hastily by mistake

recreated: https://github.com/tidev/titanium-docs/pull/123


Update PR template

Let's use new PR template 😂

@rahmanunver, can you please review and share if you have some additions, suggestions.


question about "ExitOnForwardFailure yes"

is there a difference between "ExitOnForwardFailure yes" and "ExitOnForwardFailure=yes"?

Yes, laziness and inconsistency. #mybad
-o ExitOnForwardFailure=yes and -o "ExitOnForwardFailure yes" is the same thing.
Semantically, the one with the = sign is a "command-line option", while the one with the " (quotes) is a configuration file option.
In some applications, environment variables may overwrite command-line options may overwrite configuration file options.  There could be some hierarchy.  I do not know if ssh(1) has that case, I certainly did not write it with a hierarchy in mind, it was just pure laziness in not making it consistent.


Credo does not respond with the newest non-revoked credentnial

We previously added logic to the proof acceptance mechanics to address #308 where Credo (formerly AFJ) was not automatically selecting the newest non-revoked credential. This logic may non longer be required as of Credo 0.4.x or 0.5.0. When we upgrade to 0.5.0 we should experiment and determine if this logic is still warranted.

Issue multiple credentials in various order and states of revocation;
Allow Credo to automatically select credentials and confirm if its choosing the newest non-revoked credential when the proof request does not specify either newest or not-revoked.

If the behaviour remains the same, refactor the proof screen so the logic and code documentation better reflects its purpose. Extract logic to a helper file called credhelper, helpers, or credentias.ts for clarity. Make sure code is shared with PersonCredential.tsx so they follow the same logic.

Still an issue. Tested with 1.0.17 Build 1740 w/ Lawyer showcase. It did not select the un-revoked lawyer credential but rather a revoked one and I was able to select the correct one manually to complete the proof. I think this should be automatic. See screen shots below.

When handling credential revocation status, it often relates to a specific date mentioned in a proof request. If the proof request doesn't include this revocation information, Credo can't determine whether a credential is revoked or not during its automatic selection process. As a result, it might pick a revoked credential that technically satisfies the request but isn’t the best choice from the user's perspective.
This automatic selection works well in scenarios without a user interface (headless mode), but it can be confusing in a UI, as showing a revoked credential can be misleading. This issue highlights why we needed to create our own custom credential selection logic, as discussed in Issue #308.
@cvarjao


Where can I edit the functions?

Question about an existing feature
I am trying to attempt making a pull request, changing the blur() function a bit, but I don't know where to find it.
What are you trying to achieve?
Find the blur() function and modify it.
When you searched for similar issues, what did you find that might be related?
I didn't get the wanted results.

I am trying to attempt making a pull request, changing the blur() function a bit

Are you able to explain a little more about the proposed change, if only to help me direct you to the right place.


fedora-iot: move bootupd to f41

This PR moves the addition of bootupd to the iot-commit package set from Fedora 40 to 41.
The change to include bootupd was deferred to Fedora 41 and causes issues with the bootloader in F40

@pcdubs had some issues running check_source so I'll run it in this PR.


Tag Syncing

Is your feature request related to a problem? Please describe
Not a problem with Grabber. Just a feature idea.
Describe the solution you'd like
Since tags can be stored any number of ways (and I'm sure many users don't store them at all), this may be too difficult to standardize. This also may be too big of a haul on the servers for people with large libraries. I was just wondering if it you had any ideas for how to sync image tags so that if the source tags change, the image would update. This would be relevant on images where tags have a "tagme" tag or that sort of thing. Over time, tags can change. Maybe an image could be manually updated, or maybe you could update all images that have X tag.
Again, no idea how you would even code this since there's not really a standard for downloading and storing the tags. I just wanted to throw this out there in case you had any thoughts. I want to respect the servers, so this may not be realistic.
Let me know what you think. Feel free to close this if it's an obvious no. I just wanted to pick your brain and hear what you had to say @Bionus. Thanks for all you do on this project!

Since tags can be stored any number of ways (and I'm sure many users don't store them at all), this may be too difficult to standardize

Indeed, but technically you wouldn't store the tags. What you would want to do is store when you last checked if the tags changed.

This would be relevant on images where tags have a "tagme" tag or that sort of thing

For those images, that would definitely be a good thing. For example, if someone were to setup some monitoring on their favorites, and automatically download new images as soon as they are added, he would end up with sub-par tagging for most images, as they are very often uploaded with minimal tags.

This also may be too big of a haul on the servers for people with large libraries

This is the big pain point of your suggestion. For people that have millions of images, this would be a huge burden on the server: you'd have to make as many requests to the server as the user has images.

Here's how your suggestion could technically be done (note that I have no plans to do this yet):

Keep a database of (file, re-check date) pairs
Every time an image is downloaded, add it to the database, with a re-check date of now + PERIOD, with PERIOD changing depending on how much time passed since the image was created, how many tags it has, and if it has a tagme tag
Every minute, Grabber checks if any re-check date was passed, and if so, take the first image only,  re-check its tags, and moves/renames/updates the image accordingly, then re-add the image to the re-check database

With this, even if the user has thousands of images, they will all be checked eventually, without overloading the servers (limit to 1/minute). This is actually how the favorite monitoring works (except with searches instead of images).
Issues with this solution:

You need to keep Grabber open
If you have really a lot of images, you'll reach a point where Grabber doesn't check images fast enough
The "every minute" should take into account websites, instead of being done globally (i.e. if you have 3 images from 3 different sources, there's no need to wait 1 minute between each check)

Thanks, those are some good ideas. I also didn't realize that you could monitor favorites, so that's cool. I need to look at Grabber in more detail because it sounds like there are some great features that I'm not taking advantage of.


Bluetooth: controller: Generate LE Conn Complete on cancellation

When using the LE Create Connection Cancel command, the controller is
supposed to return a Command Complete first and then an LE Connection
Complete Event after. Since the Link Layer does not generate an event in
this case emulate the behavior in the HCI layer instead.
Signed-off-by: Carles Cufi<EMAIL_ADDRESS>

Codecov Report

Merging #6475 into master will increase coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master   #6475      +/-   ##
=========================================
+ Coverage    53.2%   53.2%   +<.01%
=========================================
  Files         436     436
  Lines       41353   41353
  Branches     7937    7937
=========================================
+ Hits        22001   22002       +1
+ Misses      16128   16127       -1
  Partials     3224    3224

Impacted Files
Coverage Δ

kernel/posix/pthread.c
63% <0%> (+0.5%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b7ac977...173a5b9. Read the comment docs.

@jhedberg comments addressed, build hopefully fixed. Thanks!

@cvinayak comments addressed, thanks!


boards: lpcxpresso55s69: custom pinmux code in board file

Describe the bug
Board contains hardcoded pinmux related configuration. This should be handled somehow by the pinctrl driver.
To Reproduce
https://github.com/zephyrproject-rtos/zephyr/blob/bfa0a87277c31d9e1b36104a29b17f3fc1a47444/boards/arm/lpcxpresso55s69/pinmux.c#L12-L55
Expected behavior
Boards should not have pinmux related code.
Impact
N/A
Logs and console output
N/A
Environment (please complete the following information):

OS: Linux
Toolchain: Zephyr SDK 0.16.1
Commit SHA or Version used bfa0a87277c31d9e1b36104a29b17f3fc1a47444

Additional context
Discovered as part of a round of SYS_INIT usage cleanups

Even though the function contains the word pinmux, this looks more like custom clock control?

I think the function name here is wrong, because this is not actually setting up pinmux

NXP already discussed internally how we want to move this code into DT somehow but have not had a chance to look into it yet. This file is not the only place where sysctl is configured by kconfig like this, I have made an issue to track this enhancement desire #68903

The code seems to be actually related to pinctrl, eg:
 #if (DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm6), nxp_lpc_i2s, okay)) && \
 		(DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm7), nxp_lpc_i2s, okay)) && \
 		CONFIG_I2S
 	/*
 	 * Flexcomm 6 and 7 are connected to codec on board, and shared signal
 	 * sets are used to enable one I2S device to handle RX and one to handle
 	 * TX
 	 */
 	CLOCK_EnableClock(kCLOCK_Sysctl);
 	/* Set shared signal set 0 SCK, WS from Transmit I2S - Flexcomm 7 */
 	SYSCTL->SHAREDCTRLSET[0] = SYSCTL_SHAREDCTRLSET_SHAREDSCKSEL(7) |
 				SYSCTL_SHAREDCTRLSET_SHAREDWSSEL(7);

Seems like you're setting sharing of SCK/WS signals. Can't this be handled by pinctrl driver itself? Looks like any board based on this SoC will need to have such hacks at board level otherwise.

The code seems to be actually related to pinctrl, eg:
 #if (DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm6), nxp_lpc_i2s, okay)) && \
 		(DT_NODE_HAS_COMPAT_STATUS(DT_NODELABEL(flexcomm7), nxp_lpc_i2s, okay)) && \
 		CONFIG_I2S
 	/*
 	 * Flexcomm 6 and 7 are connected to codec on board, and shared signal
 	 * sets are used to enable one I2S device to handle RX and one to handle
 	 * TX
 	 */
 	CLOCK_EnableClock(kCLOCK_Sysctl);
 	/* Set shared signal set 0 SCK, WS from Transmit I2S - Flexcomm 7 */
 	SYSCTL->SHAREDCTRLSET[0] = SYSCTL_SHAREDCTRLSET_SHAREDSCKSEL(7) |
 				SYSCTL_SHAREDCTRLSET_SHAREDWSSEL(7);

Seems like you're setting sharing of SCK/WS signals. Can't this be handled by pinctrl driver itself? Looks like any board based on this SoC will need to have such hacks at board level otherwise.

The system control block is a different IP than the pinctrl IP. We have platforms that have this system ctrl IP but a different pinctrl IP ie different driver. Some driver for the system control block IP is a feature we don't have yet, we discussed it before internally and we just didn't have time to address this yet.
I completely agree I don't want this code in the board level as a hack and we talked about this before internally, which is why I just made the enhancement issue about it now that you also brought it up, but I do not think this can be solved by just adding something to the iocon pinctrl driver right now, as that would also be a hack
I prefer to keep the technical debt contained to the platform files rather than spread across the tree in different drivers

The "pinmux" misnomer was fixed during HWMv2. This issue is not a bug, it's a feature request. Very simply, sysctl block is not a pinctrl IP and therefore cannot be handled by this pinctrl driver. The enhancement request to add sysctl support to DT is already being tracked by this issue https://github.com/zephyrproject-rtos/zephyr/issues/68903, so I am closing this one as a repeat.


API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container

Expected Behavior

Docker-slim should minify a 5GB docker image

Actual Behavior

level=fatal msg="docker-slim: failure" error="API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container c6558fa8fa08e1ccbfd7c28bd23da098788d369fb42e9e57d991bf1bafb1d5eb" stack="goroutine 1

Steps to Reproduce the Problem

Grab this docker file, from here
Build docker image (standard) docker build -t rembg
This will produce a 5.0 GB rembd docker image
Invoke docker-slim to minify this image docker-slim build rembg --http-probe=false

Specifications

Version: 1.37.3
Platform: MacOS - Darwin

Logs
$ docker-slim build rembg --http-probe=false
docker-slim: message='join the Gitter channel to ask questions or to share your feedback' info='https://gitter.im/docker-slim/community'
docker-slim: message='join the Discord server to ask questions or to share your feedback' info='https://discord.gg/9tDyxYS'
docker-slim: message='Github discussions' info='https://github.com/docker-slim/docker-slim/discussions'
cmd=build info=exec message='changing continue-after from probe to nothing because http-probe is disabled'
cmd=build info=exec message='changing continue-after to enter'
cmd=build state=started
cmd=build info=params target.type='image' target='rembg' continue.mode='enter' rt.as.user='true' keep.perms='true' tags=''
cmd=build state=image.inspection.start
cmd=build info=image size.human='5.1 GB' id='sha256:ebf916f1382706af6dc7f172e4dd10db8e53c4016accdfe759e678a44a6c9951' size.bytes='5086630999'
cmd=build info=image.stack index='0' name='rembg:latest' id='sha256:ebf916f1382706af6dc7f172e4dd10db8e53c4016accdfe759e678a44a6c9951'
cmd=build state=image.inspection.done
cmd=build state=container.inspection.start
cmd=build info=container status='created' name='dockerslimk_24613_20220222043146' id='c6558fa8fa08e1ccbfd7c28bd23da098788d369fb42e9e57d991bf1bafb1d5eb'
cmd=build info=cmd.startmonitor status='sent'
cmd=build info=event.startmonitor.done status='received'
cmd=build info=container id='c6558fa8fa08e1ccbfd7c28bd23da098788d369fb42e9e57d991bf1bafb1d5eb' target.port.list='' target.port.info='' message='YOU CAN USE THESE PORTS TO INTERACT WITH THE CONTAINER' name='dockerslimk_24613_20220222043146'
cmd=build info=continue.after mode='enter' message='provide the expected input to allow the container inspector to continue its execution'
cmd=build prompt='USER INPUT REQUIRED, PRESS <ENTER> WHEN YOU ARE DONE USING THE CONTAINER'

cmd=build state=container.inspection.finishing
time="2022-02-22T10:04:54+05:30" level=error msg="ipc.Client.GetEvent(): event channel error = EOF\n"
time="2022-02-22T10:04:54+05:30" level=warning msg="docker-slim: warning" error=EOF stack="goroutine 1 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x65\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.WarnOn({0x19cd600, 0xc0001960f0})\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:38 +0x5e\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).FinishMonitoring(0xc0002f2000)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1104 +0x205\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(_, _, {_, _}, _, {_, _}, {_, _}, {0x0, ...}, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1079 +0x5937\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc0005689a0)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:629 +0x4166\ngithub.com/urfave/cli.HandleAction({0x176ff00, 0x18cef98}, 0x5)\n\tgithub.com/urfave/cli@v1.22.4/app.go:526 +0xa8\ngithub.com/urfave/cli.Command.Run({{0x18878cf, 0x5}, {0x0, 0x0}, {0x1f96dd0, 0x1, 0x1}, {0x18c20a3, 0x6c}, {0x0, ...}, ...}, ...)\n\tgithub.com/urfave/cli@v1.22.4/command.go:174 +0x652\ngithub.com/urfave/cli.(*App).Run(0xc00041e000, {0xc0001a4040, 0x4, 0x4})\n\tgithub.com/urfave/cli@v1.22.4/app.go:279 +0x80c\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x38\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x17\n" version="darwin|Transformer|1.37.3|latest|latest"
time="2022-02-22T10:04:54+05:30" level=error msg="channel.CommandClient.Call: c.Read error = EOF"
time="2022-02-22T10:04:54+05:30" level=error msg="ipc.Client.SendCommand() cmd channel call error=EOF\n"
time="2022-02-22T10:04:54+05:30" level=error msg="dockerutil.CopyFromContainer: dclient.DownloadFromContainer() error = API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container c6558fa8fa08e1ccbfd7c28bd23da098788d369fb42e9e57d991bf1bafb1d5eb"
time="2022-02-22T10:04:54+05:30" level=fatal msg="docker-slim: failure" error="API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container c6558fa8fa08e1ccbfd7c28bd23da098788d369fb42e9e57d991bf1bafb1d5eb" stack="goroutine 1 [running]:\nruntime/debug.Stack()\n\truntime/debug/stack.go:24 +0x65\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.FailOn({0x19cd920, 0xc00037a720})\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:28 +0x5e\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).ShutdownContainer(0xc0002f2000)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1023 +0x18a\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(_, _, {_, _}, _, {_, _}, {_, _}, {0x0, ...}, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1082 +0x5992\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc0005689a0)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:629 +0x4166\ngithub.com/urfave/cli.HandleAction({0x176ff00, 0x18cef98}, 0x5)\n\tgithub.com/urfave/cli@v1.22.4/app.go:526 +0xa8\ngithub.com/urfave/cli.Command.Run({{0x18878cf, 0x5}, {0x0, 0x0}, {0x1f96dd0, 0x1, 0x1}, {0x18c20a3, 0x6c}, {0x0, ...}, ...}, ...)\n\tgithub.com/urfave/cli@v1.22.4/command.go:174 +0x652\ngithub.com/urfave/cli.(*App).Run(0xc00041e000, {0xc0001a4040, 0x4, 0x4})\n\tgithub.com/urfave/cli@v1.22.4/app.go:279 +0x80c\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x38\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x17\n" version="darwin|Transformer|1.37.3|latest|latest"

@kcq  Hey Kyle, can you help with this, i am trying to minify a 5GB image (dockerfile) using docker-slim , but it breaks

@ksingh7 let me take a look

Problema comum de praticamente todos aqui: Reduz a imagem e depois não funciona. Me parece uma perda de tempo.

Problema comum de praticamente todos aqui: Reduz a imagem e depois não funciona. Me parece uma perda de tempo.

Naturally it'll be common in bug reports... That's the whole point of reporting bugs. Nobody opens issues just to say they successfully minified their image :-) In this case it's a memory use issue in the sensor. Either way, some apps do require additional configs and it does take a few tries to arrive at the right combination of flags

Hey there, I had exactly the same error with a large (30GB) image. I ran it with the --debug flag, the results of which are below, if they're of any help.
you mentioned it was a memory use issue, which i guess makes sense given the size of the container. I know i'm not running out of memory on the machine itself.
cmd=build state=container.inspection.finishing
time="2022-04-22T21:32:58Z" level=debug msg="RunContainer: Docker event monitor stopped" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:32:58Z" level=debug msg="ipc.Client.SendCommand() cmd channel call data='{\"name\":\"cmd.monitor.stop\"}'\n"
time="2022-04-22T21:32:58Z" level=debug msg="channel.CommandClient.Call: calling c.Write()"
time="2022-04-22T21:32:58Z" level=debug msg="channel.Client.Write: remote=<IP_ADDRESS>:32779 -> local=<IP_ADDRESS>:38762 - conn.Write wc=110 err=<nil> [time=1650663178591688638]"
time="2022-04-22T21:32:58Z" level=debug msg="channel.CommandClient.Call: calling c.Read()"
time="2022-04-22T21:32:58Z" level=debug msg="channel.Client.Read() - (0xc0005c90e0)reader.ReadString => err=<nil> raw=\"[<|]{\\\"tid\\\":\\\"1650663178591618800.c64981855ad8681d\\\",\\\"type\\\":\\\"ft.response\\\",\\\"body\\\":{\\\"status\\\":\\\"ok\\\"}}[|>]\\n\""
time="2022-04-22T21:32:58Z" level=debug msg="channel.Client.Read: got raw frame ='[<|]{\"tid\":\"1650663178591618800.c64981855ad8681d\",\"type\":\"ft.response\",\"body\":{\"status\":\"ok\"}}[|>]\n'"
time="2022-04-22T21:32:58Z" level=debug msg="channel.Client.Read: frame data => tid=1650663178591618800.c64981855ad8681d type=ft.response body='{\"status\":\"ok\"}'"
time="2022-04-22T21:32:58Z" level=debug msg="channel.CommandClient.Call: c.Read() (tid=1650663178591618800.c64981855ad8681d type=ft.response) result.data='{\"status\":\"ok\"}'"
time="2022-04-22T21:32:58Z" level=debug msg="ipc.Client.SendCommand() cmd channel call response='{\"status\":\"ok\"}'\n"
time="2022-04-22T21:32:58Z" level=debug msg="'stop' monitor response => '&{ok}'" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:32:58Z" level=info msg="waiting for the container to finish its work..." app=docker-slim command=build component=container.inspector
time="2022-04-22T21:33:26Z" level=debug msg="channel.Client.Read() - (0xc0005c9200)reader.ReadString => err=EOF raw=\"\""
time="2022-04-22T21:33:26Z" level=debug msg="channel.Client.Read: connection done..."
time="2022-04-22T21:33:26Z" level=error msg="ipc.Client.GetEvent(): event channel error = EOF\n"
time="2022-04-22T21:33:26Z" level=debug msg="sensor event => '<nil>'" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:33:26Z" level=warning msg="docker-slim: warning" error=EOF stack="goroutine 1 [running]:\nruntime/debug.Stack(0xc00031d570, 0x49f472, 0xc00012e0c0)\n\truntime/debug/stack.go:24 +0x9f\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.WarnOn(0x10cb3c0, 0xc000116030)\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:38 +0x54\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).FinishMonitoring(0xc000491600)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1287 +0x3b1\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(0xc00013f260, 0xc0003e8300, 0x7ffc2223802c, 0x59, 0x0, 0x0, 0x1748a78, 0x0, 0x0, 0x0, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1304 +0x449d\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc00055a800, 0x86, 0x130)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:662 +0x3688\ngithub.com/urfave/cli/v2.(*Command).Run(0x16dee00, 0xc000522580, 0x0, 0x0)\n\tgithub.com/urfave/cli/v2@v2.3.0/command.go:163 +0x4ed\ngithub.com/urfave/cli/v2.(*App).RunContext(0xc000134000, 0x10e2d20, 0xc00012a010, 0xc000132000, 0xc, 0xc, 0x0, 0x0)\n\tgithub.com/urfave/cli/v2@v2.3.0/app.go:313 +0x81f\ngithub.com/urfave/cli/v2.(*App).Run(...)\n\tgithub.com/urfave/cli/v2@v2.3.0/app.go:224\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x6c\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:15 +0x54\n" version="linux|Transformer|1.37.5|86fbd29ab3549fa564e87e4770178480cb0542d3|2022-03-21_06:10:20AM"
time="2022-04-22T21:33:26Z" level=debug msg="sensor event => '<nil>'" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:33:26Z" level=debug msg="ipc.Client.SendCommand() cmd channel call data='{\"name\":\"cmd.sensor.shutdown\"}'\n"
time="2022-04-22T21:33:26Z" level=debug msg="channel.CommandClient.Call: calling c.Write()"
time="2022-04-22T21:33:26Z" level=debug msg="channel.Client.Write: remote=<IP_ADDRESS>:32779 -> local=<IP_ADDRESS>:38762 - conn.Write wc=113 err=<nil> [time=1650663206288823211]"
time="2022-04-22T21:33:26Z" level=debug msg="channel.CommandClient.Call: calling c.Read()"
time="2022-04-22T21:33:26Z" level=debug msg="channel.Client.Read() - (0xc0005c90e0)reader.ReadString => err=EOF raw=\"\""
time="2022-04-22T21:33:26Z" level=debug msg="channel.Client.Read: connection done..."
time="2022-04-22T21:33:26Z" level=error msg="channel.CommandClient.Call: c.Read error = EOF"
time="2022-04-22T21:33:26Z" level=error msg="ipc.Client.SendCommand() cmd channel call error=EOF\n"
time="2022-04-22T21:33:26Z" level=debug msg="error sending 'shutdown' => 'EOF'" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:33:26Z" level=debug msg="'shutdown' sensor response => '<nil>'" app=docker-slim command=build component=container.inspector
time="2022-04-22T21:33:26Z" level=info msg="shutting down 'fat' container..." app=docker-slim command=build
time="2022-04-22T21:33:26Z" level=error msg="dockerutil.CopyFromContainer: dclient.DownloadFromContainer() error = API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container 76a81c862c47b72897aef67a278f3cc0a4eff25c338e54aa6bf2d4b8766e5c84"
time="2022-04-22T21:33:26Z" level=fatal msg="docker-slim: failure" error="API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container 76a81c862c47b72897aef67a278f3cc0a4eff25c338e54aa6bf2d4b8766e5c84" stack="goroutine 1 [running]:\nruntime/debug.Stack(0xc000046000, 0xc00031d6b8, 0x419c85)\n\truntime/debug/stack.go:24 +0x9f\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.FailOn(0x10cb7e0, 0xc0005cb760)\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:28 +0x54\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).ShutdownContainer(0xc000491600, 0x4, 0xc00031e2a8)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1198 +0x648\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(0xc00013f260, 0xc0003e8300, 0x7ffc2223802c, 0x59, 0x0, 0x0, 0x1748a78, 0x0, 0x0, 0x0, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1307 +0x450f\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc00055a800, 0x86, 0x130)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:662 +0x3688\ngithub.com/urfave/cli/v2.(*Command).Run(0x16dee00, 0xc000522580, 0x0, 0x0)\n\tgithub.com/urfave/cli/v2@v2.3.0/command.go:163 +0x4ed\ngithub.com/urfave/cli/v2.(*App).RunContext(0xc000134000, 0x10e2d20, 0xc00012a010, 0xc000132000, 0xc, 0xc, 0x0, 0x0)\n\tgithub.com/urfave/cli/v2@v2.3.0/app.go:313 +0x81f\ngithub.com/urfave/cli/v2.(*App).Run(...)\n\tgithub.com/urfave/cli/v2@v2.3.0/app.go:224\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x6c\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:15 +0x54\n" version="linux|Transformer|1.37.5|86fbd29ab3549fa564e87e4770178480cb0542d3|2022-03-21_06:10:20AM"

Hey there, I had exactly the same error with a large (30GB) image. I ran it with the --debug flag, the results of which are below, if they're of any help.

Hey Sam :-) Can you also add the --show-clogs command level param. It'll understand what happened with the sensor in the container. The creport.json should be there unless the sensor crashed :)

I ran in debug mode with --show-clogs, the complete logs are here:
slim-logs.txt
the container is an open source project, the dockerfile is here: https://github.com/CyrusBiotechnology/RoseTTAFold/blob/main/Dockerfile, i can provide a command line and reasonable minimal input if it would be useful to you.
I did notice that after the application in the container completed successfully the sensors were using a lot of cpu, as was dockershim, for about 40 minutes.  Is it possible that due to the container things have gotten "behind" in some way and i should wait for the sensors to become idle before pressing enter?

I have the below error when trying to slim the image, the actual image size is 4.24GB.
Below are commands I used to build and slim the images respectively
docker build --network=host -t moon:${VERSION}
docker-slim build --target moon:${VERSION} --tag moon:${VERSION} --http-probe=false --include-path /
Error below:
cmd=build state=container.inspection.finishing
time="2023-05-10T15:16:19+05:30" level=error msg="ipc.Client.GetEvent(): event channel error = EOF\n"
time="2023-05-10T15:16:19+05:30" level=warning msg="docker-slim: warning" error=EOF stack="goroutine 1 [running]:\nruntime/debug.Stack(0x0, 0xc0005962e0, 0x533665)\n\truntime/debug/stack.go:24 +0x9f\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.WarnOn(0xfca5e0, 0xc000072040)\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:38 +0x54\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).FinishMonitoring(0xc0004abb00)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1104 +0x271\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(0xc0004f6960, 0xc0004c74f0, 0x7fffb8799b44, 0x1e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1079 +0x409d\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc00047b4a0, 0x0, 0xc0004b36f0)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:629 +0x321b\ngithub.com/urfave/cli.HandleAction(0xd2e100, 0xeca9b0, 0xc00047b4a0, 0xc00047b4a0, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:526 +0xfd\ngithub.com/urfave/cli.Command.Run(0xe824d9, 0x5, 0x0, 0x0, 0x1564aa0, 0x1, 0x1, 0xebe395, 0x6c, 0x0, ...)\n\tgithub.com/urfave/cli@v1.22.4/command.go:174 +0x58e\ngithub.com/urfave/cli.(*App).Run(0xc0003656c0, 0xc000030090, 0x9, 0x9, 0x0, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:279 +0x7e8\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x54\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x25\n" version="linux|Transformer|1.37.3|97eb3c8c7f8c4e295a26c13882feb3f0539ab50f|2021-12-10_09:37:29AM"
time="2023-05-10T15:16:19+05:30" level=error msg="channel.CommandClient.Call: c.Read error = EOF"
time="2023-05-10T15:16:19+05:30" level=error msg="ipc.Client.SendCommand() cmd channel call error=EOF\n"
time="2023-05-10T15:16:19+05:30" level=error msg="dockerutil.CopyFromContainer: dclient.DownloadFromContainer() error = API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container 08dd4c141ff290a918cd791874f796cb58683e3c207d25242995bea860c9eaad"
time="2023-05-10T15:16:19+05:30" level=fatal msg="docker-slim: failure" error="API error (404): Could not find the file /opt/dockerslim/artifacts/creport.json in container 08dd4c141ff290a918cd791874f796cb58683e3c207d25242995bea860c9eaad" stack="goroutine 1 [running]:\nruntime/debug.Stack(0xc000050800, 0xc000596260, 0x419c85)\n\truntime/debug/stack.go:24 +0x9f\ngithub.com/docker-slim/docker-slim/pkg/util/errutil.FailOn(0xfca900, 0xc0005025c0)\n\tgithub.com/docker-slim/docker-slim/pkg/util/errutil/errutil.go:28 +0x54\ngithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container.(*Inspector).ShutdownContainer(0xc0004abb00, 0x4, 0xc000596e00)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/inspectors/container/container_inspector.go:1023 +0x65a\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.OnCommand(0xc0004f6960, 0xc0004c74f0, 0x7fffb8799b44, 0x1e, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/handler.go:1082 +0x410f\ngithub.com/docker-slim/docker-slim/pkg/app/master/commands/build.glob..func1(0xc00047b4a0, 0x0, 0xc0004b36f0)\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/commands/build/cli.go:629 +0x321b\ngithub.com/urfave/cli.HandleAction(0xd2e100, 0xeca9b0, 0xc00047b4a0, 0xc00047b4a0, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:526 +0xfd\ngithub.com/urfave/cli.Command.Run(0xe824d9, 0x5, 0x0, 0x0, 0x1564aa0, 0x1, 0x1, 0xebe395, 0x6c, 0x0, ...)\n\tgithub.com/urfave/cli@v1.22.4/command.go:174 +0x58e\ngithub.com/urfave/cli.(*App).Run(0xc0003656c0, 0xc000030090, 0x9, 0x9, 0x0, 0x0)\n\tgithub.com/urfave/cli@v1.22.4/app.go:279 +0x7e8\ngithub.com/docker-slim/docker-slim/pkg/app/master.Run()\n\tgithub.com/docker-slim/docker-slim/pkg/app/master/app.go:15 +0x54\nmain.main()\n\tgithub.com/docker-slim/docker-slim/cmd/docker-slim/main.go:8 +0x25\n" version="linux|Transformer|1.37.3|97eb3c8c7f8c4e295a26c13882feb3f0539ab50f|2021-12-10_09:37:29AM" ```


IDF monitor fails to parse coredumps from uart (IDFGH-6439)

In the current implementation, it is possible for some bytes to be missing from coredump data received over UART. The branch that processed incomplete lines (referenced below) does not update the coredump processor at all:
https://github.com/espressif/esp-idf/blob/07bfc09d0c8837b4d149e1151c57635a0c02755a/tools/idf_monitor_base/serial_handler.py#L105-L120
The conditions where this may happen:

Data is received that contains an incomplete line
AND timer flushes the serial input buffer by calling handle_serial_input with finalize_line=True

Effect: monitor dumps a bunch of base64 encoded coredump data to the console, failing to process it due to missing bytes - either the base64 becomes invalid, or the data becomes shorter than expected.
I'm experiencing the issue with esp-idf 4.3.1, but looking at the implementation, master should still be affected.

Hi, @bugadani. Thank you for reporting the issue. We'll take a look soon.

@bugadani Could you please provide more detailed steps to reproduce the issue? E.g. example of C code to be monitored in the device.

I can't, unfortunately, I have a pretty complicated rust project only. But let me try to provide more details, let's hope I don't get the facts terribly wrong.
Before that, one thing to note: I opened this issue for esp-idf v4.3, where I made a similar patch to the PR I closed, that solved this issue for me. Right now, I'm experiencing this issue with esp-idf v4.4. For the previous version, the patch looked like this:
diff --git a/tools/idf_monitor.py b/tools/idf_monitor.py
index 490178e53a..7f8dc1ddd1 100755
--- a/tools/idf_monitor.py
+++ b/tools/idf_monitor.py
@@ -640,8 +640,14 @@ class Monitor(object):
         if self._last_line_part != b'':
             if self._force_line_print or (finalize_line and self._line_matcher.match(self._last_line_part.decode(errors='ignore'))):
                 self._force_line_print = True
+
+                if self._decode_coredumps != COREDUMP_DECODE_DISABLE:
+                    if self._reading_coredump == COREDUMP_READING:
+                        self._coredump_buffer += self._last_line_part.replace(b'\r', b'')
+
                 self._print(self._last_line_part)
                 self.handle_possible_pc_address_in_line(self._last_line_part)
+                self.check_coredump_trigger_after_print(self._last_line_part)
                 self.check_gdbstub_trigger(self._last_line_part)
                 # It is possible that the incomplete line cuts in half the PC
                 # address. A small buffer is kept and will be used the next time

Symptoms
Most of the time when my program panics and outputs a coredump, esp-idf fails to parse this coredump and prints it's base64 raw representation instead. This is usually a 20-30kB dump.
There are two distinct error messages I get:

Invalid base64-encoded string: number of data characters (53) cannot be 1 more than a multiple of 4, the exact numbers are random. A variation of this is Error: Incorrect padding
and the other is a data length mismatch (I don't have the exact error message at hand).

Trying to decode this raw, printed buffer manually, in some of the cases (corresponding to error message 1), some of the lines are invalid base64, because data is missing from them. I suspect, that, in the other cases, the buffer was rejected with a data length mismatch, because in those cases, bytes were missing in such a way, that the buffer still represented a valid base64 string.
I know that data is missing, because when I debugged this issue, I suspected the C code to generate invalid buffers and I printed the raw coredump buffer in a different way, and observed, that what I printed and what esp-idf read from the serial input, were slightly different.
Possible causes
The error is probablilistic, but because of the size of my coredump, I hit it more often than not.
Examining the code paths that process coredump info, we can see that in the code branch in the issue description, data can be lost without adding it to the coredump buffer. I suspect this is the root cause of this issue.
This code is part of the handle_serial_input function, which has two call sites: it is used to handle the following events in idf_monitor.py _main_loop:

TAG_SERIAL
TAG_SERIAL_FLUSH

I believe the problematic code is hit, when a TAG_SERIAL_FLUSH event is generated, but it does not correspond to the actual last line of the serial data. I know this can happen, because, if I place a print like below, I get the following:
        elif event_tag == TAG_SERIAL_FLUSH:
            print("Flush")
            self.serial_handler.handle_serial_input(data, self.console_parser, self.coredump,
                                                    self.gdb_helper, self._line_matcher,
                                                    self.check_gdb_stub_and_run, finalize_line=True)

Hi @bugadani, thank you for a detailed and clear explanation of the problem. You are right. The issue is caused by invoking the wrong branch of the code (TAG_SERIAL_FLUSH ). The problem is the longer time required to receive serial data. We reproduced the issue, and our temporary solution is to increase the last line time interval - see the line:
https://github.com/espressif/esp-idf/blob/f51eaf17467717e5a4c96ac2bb9877f00971c73d/tools/idf_monitor_base/constants.py#L85
Please, consider increasing the time interval LAST_LINE_THREAD_INTERVAL (maybe even to 1 second), and please, let me know if the temporary solution works for you as well.

Hi @sio13 indeed, increasing the timeout works well enough, thanks!.

@bugadani, Thank you for verifying the solution.  We also found out that increasing the UART console baud rate using idf.py menuconfig resolved the issue. We needed to increase it to 2M. That might be more convenient than modifying the code.

I hope both of these solutions are treated as a workaround only :)
Well this isn't important, but modifying the code isn't an issue on my end, as I have other patches I need to apply for small fixes that aren't released, or haven't been backported yet. The baud rate increase is interesting, I need to verify if 2M works with my physical setup. It has the added benefit of making my log calls faster, as I've been able to verify that in my system, logging is actually IO bound, even using 460800.
Regardless, thank you for providing workarounds, being able to see coredumps is certainly more helpful than not seeing them. :)

@bugadani sure, the root cause was adding line breaks into the core dump data that led to issues in decoding. The fix should be merged and backported to the older versions soon. Thank you for reporting and helping with this issue.


19 player and keyboard tests

Added play and keyboard js tests
Changed order of wall collision detection to eliminate wall bounce-back

Looks good. Also, we could add tests for collisions other than the right side of the ball. We could test diagonal movement going forward, but it's not a priority now.


change some terms in architecture.md

this pr aim to use some kubernetes terms exchange unstandard terms in docs/architecture.md. Make it easy to read.Some reader who don't understand terms like configmap or apiserver can easily using google to search the related infomation.

@paolomainardi is there something wrong with ci?

Retriggered the CI job, looks like a flaky error.

@knightXun thanks for the PR.

thanks @murali-reddy


Replace Xinput with SDL2

Objective: Replace Xinput with SDL2
Reason: Since XtendedInput currently kills DirectInput, this allows it to be brought back in a way that doesn't affect the rest of functionality and keeps the core xinput functionality too as SDL2 already deals with that. It manages controllers in a standardized way so that A,B,X,Y buttons and such are handled the same for every controller regardless if it's xinput or not. Also no need to use external wrappers such as Xoutput or ds4windows, it works out of the box.
Tested with: DualSense controller in NFSU2
Platform: Windows 11
Notes:
Make sure to copy SDL2 32bit dll to the scripts folder in order for it to work
This can be extended further too, SDL2 supports adaptive triggers on the PS5 controller, LED Color lights for PS4/PS5 controllers and vibration for any controller
This method possibly works for NFS-XtendedInput

Hey, this is a pretty big change, so there's a few things I'd like to address.
First off - thank you for this, we could use SDL2 for sure!
Secondly, since I didn't expect this to happen, let me outline my plans with the XtendedInput project(s):

Reorganize units into their own source files
Rework Win32/OS cursor stuff
Proper raw input
Get the remap menu working
Rumble
Wheel support & force feedback
Support for more APIs (even reimplement DirectInput if possible)

That being said, before merging I'd like you to do the following changes:

Keep XInput. I do not see the point in actually removing it outright.  There could be multiple build configurations which use only SDL2, only XInput or both (in which case an option in the ini would have to be added).
The idea behind using XInput was to keep the dependency chain to a minimum. This is a Win32 game, so Win32 stuff is in focus and takes priority. (Also not to mention rumble/FF stuff is a challenge of its own)
Remove SDL2 from the repository itself - put it in a gitignore and distribute externally, or, implement it as a submodule (if possible). I do not want to distribute SDL2 within the repository directly. (This also goes for the dll and lib files)

Hey, this is a pretty big change, so there's a few things I'd like to address.
First off - thank you for this, we could use SDL2 for sure!
Secondly, since I didn't expect this to happen, let me outline my plans with the XtendedInput project(s):
* Reorganize units into their own source files

* Rework Win32/OS cursor stuff

* Proper raw input

* Get the remap menu working

* Rumble

* Wheel support & force feedback

* Support for more APIs (even reimplement DirectInput if possible)

That being said, before merging I'd like you to do the following changes:
1. Keep XInput. I do not see the point in actually removing it outright.  There could be multiple build configurations which use only SDL2, only XInput or both (in which case an option in the ini would have to be added).
   The idea behind using XInput was to keep the dependency chain to a minimum. This is a Win32 game, so Win32 stuff is in focus and takes priority. (Also not to mention rumble/FF stuff is a challenge of its own)

2. Remove SDL2 from the repository itself - put it in a gitignore and distribute externally, or, implement it as a submodule (if possible). I do not want to distribute SDL2 within the repository directly. (This also goes for the dll and lib files)

Please do. I really need rumble on Underground 2. Especially when coming from the PS2 version which has that feature.


Corrupting halo 5 install

It may be because the memory offsets are outdated of something, but after correctly building osiris and launching it, halo 5 forge wouldn't start. I had to reinstall the entire game (i have to thank m$ for not letting users backup their apps...) .

That being said, it might not be osiris's fault, maybe my AV decided to delete the executable of a windows app somehow...


Add Pixel 4a 5G and Pixel 5 support

@flawedworld Can you drop the generate_deltas.sh change for now? Since I'm not actually going to be making builds for them yet and the initial releases won't have deltas.

@flawedworld Can you drop the generate_deltas.sh change for now? Since I'm not actually going to be making builds for them yet and the initial releases won't have deltas.

@thestinger Sorted.

@thestinger Sorted.


cannot compile demo

Hi!
I followed the steps on my mac and I got this result:
CMake Error at /Users/giovanni/esp/esp-idf/tools/cmake/component.cmake:381 (__component_get_property):
  __component_get_property Function invoked with incorrect arguments for
  function named: __component_get_property
Call Stack (most recent call first):
  main/CMakeLists.txt:24 (idf_component_get_property)

CMake Error at main/CMakeLists.txt:26 (target_link_libraries):
  Cannot specify link libraries for target "CONFIG_SOC_MPU_MIN_REGION_SIZE"
  which is not built by this project.

-- Configuring incomplete, errors occurred!

It seems something is missing.
How could I solve it?

I fixed this by commenting the following lines on CMakeLists.txt.
This tinyusb from leebo is optional.
#idf_component_get_property(tusb_lib leeebo__tinyusb_src COMPONENT_LIB)
cmake_policy(SET CMP0079 NEW)
#target_link_libraries(${COMPONENT_LIB} PRIVATE ${tusb_lib})

Had the same issue.
Switched to ESP-IDF v4.4.6 and it works.

Had the same issue. Switched to ESP-IDF v4.4.6 and it works.

 Thank you! Can confirm v4.4.6 works flawlessly.