PinJoint2D Motor has weird units

Tested versions
4.2.1
System information
Godot Engine v4.2.1.stable.official.b09f793f5 - https://godotengine.org OpenGL API 4.6 (Core Profile) Mesa 23.2.1-1 - Compatibility - Using Device: AMD - AMD Radeon RX 5600 XT (navi10, LLVM 16.0.6, DRM 3.49, 6.1.0-5-amd64)
Issue description
PinJoint2D's motor_target_velocity has units of either radians per second (if you believe the documentation) or degrees per second (if you believe the inspector).
Given these units, I would expect a constant rotation at that speed.  Instead, a force seems to be applied.  That force seems to be proportional to the supplied motor_target_velocity.  But it is not proportional to the mass of the attached PhysicsBody2D objects -- nor does it seem to consider the distance of their CG from the joint.  (I see in the code something about the inverse inertia, but I don't understand how that could possibly be correct -- surely if you wanted a constant speed, you would want to have a force proportional to the non-inverse inertia).
So at minimum, the bug is that the units are not correct (that is, they are not off by a constant factor; they are the entirely wrong sort of unit).
Of course, if I want truly constant motion, I could use a KinematicBody2D and do the rotation myself.  But that wouldn't help if I want the motorized item to push other PhysicsBody2D objects (I think?).
What I think I really want is a motor which applies a certain maximum amount of force, and aims for a certain maximum speed.  Of course, I could (and probably will) do this myself by hooking up a PID controller to this value -- but that would still leave the documentation/description of this feature wrong.
Steps to reproduce
The attached file (based on one by @Ughuuu, author of this motor stuff) shows four motors:  the top-left is set to 4,000 deg/s (which would be over 600 RPM); it's actually just barely making it over the top until it gets up some momentum.  The top-right is set to 3,000 deg/s but doesn't have enough power to push the ball over the top, so it's actually not rotating at all at a steady state.  The bottom left is too heavy -- it's the same as top-left but the ball weighs 2kg instead of 1.  Bottom right is just like bottom left except the ball is closer to the center, so it can make it over the top.
Minimal reproduction project (MRP)
PinJointMotorWrong.zip

It's radians, it's edited as degrees, this is normal, this is done everywhere, like angles for rotation

I was clearing up your confusion about that part, the rest needs to be looked into, there's probably more to this and related to force and torque, not familiar with the specifics

Just as a note to the next person that comes across this: a PID controller worked more-or-less fine without a lot of tuning.  But I ended up just using an area with no physics, and controlling the rotation through a tween; when I detected a hit with another object, I applied an impulse to that object.  This looks great: think of a baseball bat hitting a baseball -- the bat doesn't perceptibly slow down, and the ball jumps away at great speed. Of course, it's not physically accurate, but that's not needed for my game.  (Of course, this bug should still be fixed)

For your interest, this is where the value is used in the default Godot physics implementation:
https://github.com/godotengine/godot/blob/4b6ad349886288405890b07d4a8da425eb3c97ec/servers/physics_2d/godot_joints_2d.cpp#L220-L245
As of writing I do not understand it myself.

There is comments in code on what the code is based of, from chipmunk physics engine. I just copied that one and tested it.
I could investigate more, but not a big fan of current physics engine. And physics is hard. In box2d this just works, same rapier i believe. But the default chipmunk repo uses that stuff that is so weird and strange.
Wish godot physics was based on another 2d physics engine.

The bug is also present in Chipmunk -- you can see this if you modify https://github.com/slembcke/Chipmunk2D/blob/master/demo/Joints.c thus:
index 3a7f23a..ea96586 100644
--- a/demo/Joints.c
+++ b/demo/Joints.c
@@ -252,8 +252,10 @@ init(void)

        // Simple Motor - Maintain a specific angular relative velocity
        boxOffset = cpv(-160, 0);
+       cpVect posC = posB;
+       posC.y += 13;
        body1 = addBar(space, posA, boxOffset);
-       body2 = addBar(space, posB, boxOffset);
+       body2 = addBar(space, posC, boxOffset);
        // Add some pin joints to hold the circles in place.
        cpSpaceAddConstraint(space, cpPivotJointNew(body1, staticBody, POS_A));
        cpSpaceAddConstraint(space, cpPivotJointNew(body2, staticBody, POS_B));

(then run the demo and press M to see the motor struggling to turn the bar -- note that it's actually a weird demo because from the visual, I would expect the two bars to be driven independently, but in fact they are driven against each other for some reason)
Maybe the right thing to do for Godot is just to change the units to ... well, it's complicated, because in a physical system, distances would be measured in meters, but here, distances are measured in pixels.  So what would be a Newton is instead kg-(pixels/s)^2.  I don't have a name for that unit.  We could pretend one pixel is one cm (since gravity defaults to 980) and call it a newton-centimeters. I think this is actually close to right.  If I put a body 1m to the left of a pin with a motor, and set the motor "speed" to about 5700 deg, that's about 99 radians, and the motor just barely holds the body horizontal against the force of gravity.
On reflection, maybe it's not quite right.  If you take the repro (attached above), and turn off gravity on the top left joint, the one that's supposed to be going at 4k degrees per second, it doesn't -- it maybe goes at 500 or 600 degrees per second.  In a vacuum, with no gravity, if you impart a constant force to an object, it should just continue to accelerate forever (modulo relativistic effects, which I'm pretty sure Godot doesn't simulate).  That's not what's happening here.  It hits a certain speed (which is, again, not 4k degrees per second), and stops accelerating.  So something is pretty wrong about this code.  It's also not a constant factor -- if I double the "speed", it doesn't seem to double the observed RPM.

Can't change the units without breaking compatibility, so unless it's unavoidable we need a solution that doesn't

So there's no way to fix the implementation without altering the units? It'd be confusing if the unit isn't a velocity (which it's intended to be here)
Adding a separate variable would work but it requires that the old variable works, because the feature here isn't completely unusable it just seems to not work as expected entirely, but I'm not sure no one is using it at all and making it work

To preface this: I don't know anything about physics simulation (or about physics overall -- I think I got a D in college physics 25 years ago).
One could imagine a motor that exerts a potentially infinite force to attempt to reach the target velocity, I think?  Indeed, the chipmunk docs warn against this:
"You will usually want to set an force (torque) maximum for motors as otherwise they will be able to apply a nearly infinite torque to keep the bodies moving."
Note that in fact, as my example shows, they do no such thing, but if the model is that you have some target rate, it's easy to see that you might indeed have to apply quite a lot of force to reach that rate.
It seems to me quite hard to get the force correct without using something like a PID controller.  Consider the situation of a rotating bar, with a pin joint at on end, no gravity.  A baseball bat.  How much force is needed to achieve a certain speed?  Well, it's suddenly more if a ball hits the bat.  It's even more if the bat suddenly hits a (heavy but not static) wall.
As for whether anyone could use it, I managed to make the current thing work using PID (then I deleted the code because I realized I could solve my problem much more simply since I didn't care at all about correctness but cared a lot about appearance).  But PID typically requires some tuning.  Of course, Godot could expose those tuning parameters, but that's rather heavyweight.

It probably does need some kind of max_impulse or other controller features like HingeJoint3D does, worth looking at the code there and see if it works and what can be found from the differences
But the important part is to figure out what is actually wrong, it does sound like it's simply not accounting well for physics, like gravity and other things, and fails to work well in situations that aren't ideal

It's not just that it's not accounting for gravity (or any other forces), although that is one problem.  Even without gravity or any other forces, it's not hitting the right rate (for reasons I don't understand).

It shouldn't account as such, it's a target velocity, it has to work with physics, naturally it won't if the force is too low, that's why allowing more force would solve this part
But the maths there needs to be looked at before messing with any units, it should be split into velocity and impulse/force/etc. rather than making a new, hard to work with unit IMO

But if it doesn't account for other forces acting on the body, how will it know how much force to apply to get the desired effect? The only answer I can see is by getting feedback about the effect of applying forces -- e.g. PID.
On January 30, 2024 3:16:25 PM EST, A Thousand Ships @.***> wrote:

It shouldn't account as such, it's a target velocity, it has to work with physics, naturally it won't if the force is too low, that's why allowing more force would solve this part
But the maths there needs to be looked at before messing with any units, it should be split into velocity and impulse/force/etc. rather than making a new, hard to work with unit IMO
--
Reply to this email directly or view it on GitHub:
https://github.com/godotengine/godot/issues/87513#issuecomment-1917819213
You are receiving this because you authored the thread.
Message ID: @.***>

But if it doesn't account for other forces acting on the body, how will it know how much force to apply to get the desired effect? The only answer I can see is by getting feedback about the effect of applying forces -- e.g. PID.
…
On January 30, 2024 3:16:25 PM EST, A Thousand Ships @.> wrote: It shouldn't account as such, it's a target velocity, it has to work with physics, naturally it won't if the force is too low, that's why allowing more force would solve this part But the maths there needs to be looked at before messing with any units, it should be split into velocity and impulse/force/etc. rather than making a new, hard to work with unit IMO -- Reply to this email directly or view it on GitHub: #87513 (comment) You are receiving this because you authored the thread. Message ID: @.>

Looking at the code that @Mickeon posted earlier, it seems that the motor solve is a proportional solution, so any resistance (including angular damp) will reduce the true rate of rotation.
	// Compute normal impulse.
	//wr is the desired change in motor velocity
 	real_t j = -(bias_velocity + wr) * i_sum;
 	real_t j_old = j_acc;
 	// Only enable the limits if we have to.
 	if (angular_limit_enabled && is_joint_at_limit) {
 		if (bias_velocity < 0.0) {
 			j_acc = CLAMP(j_old + j, 0.0, j_max);
 		} else {
 			j_acc = CLAMP(j_old + j, -j_max, 0.0);
 		}
 	} else {
 		j_acc = CLAMP(j_old + j, -j_max, j_max);
 	}
 	j = j_acc - j_old;

@novalis Have you tried disabling angular damp on your objects to check if the full angular velocity is achieved?

Angular damp is already zero. Is there another way to disable it?

ProjectSettings has a default linear and angular dampening, so you need to set the combine mode to "replace" to overwrite global dampening.


[VL] Aggregate window gets the wrong result in 1.2.0

Backend
VL (Velox)
Bug description
Aggregate window gets the wrong result
-- Data
(for { x <- 1 to 4500 } yield { (x,1) }).toDF("id", "order_num")

-- Query
SELECT
  id,
  SUM(num) OVER(ORDER BY num DESC) AS sum
FROM test

Expect: sum: 4500
Actual: sum: 4096 ... 4500
Spark version
None
Spark configurations
No response
System information
No response
Relevant logs
No response

cc @kecookier

This issue can be solved by disabling RowsStreamingWindowBuild. I guess that RowsStreamingWindowBuild might not be compatible with some aggregate case. I tried copying the logic of 'supportRowsStreaming()' from the update branch, but it didn't work. cc @JkSelf

@ccat3z I will look at this issue later. Thanks.

@ccat3z Can you help to verify https://github.com/facebookincubator/velox/pull/10979 in your env? Thanks.

@ccat3z Can you help to verify facebookincubator/velox#10979 in your env? Thanks.

It works. Thanks.

Fixed in https://github.com/facebookincubator/velox/pull/10979.


Bebop ADB push fails with "no space left on device"

Flashing PX4 onto a brand new Bebop, and the ADB uploader fails with a "no space left on device" when copying over the PX4 executable. Also tried pushing it manually with adb push px4 /usr/bin, and the same problem occurs.
This issue did not happen when I manually pushed over the mixer and config files to /home/root.
I verified using df that there is indeed enough space (there should be, considering that it's an untouched filesystem).
Checked again, maybe I missed it on the first go :
Filesystem           1M-blocks      Used Available Use% Mounted on
ubi1:system                 42        36         4  91% /
udev                       145         0       145   0% /dev
shm                        145         0       145   0% /dev/shm
tmp                        145         0       145   0% /tmp
ubi0:factory                 5         0         4   2% /factory
ubi2:data                    9         0         8   2% /data
ubi2:update                 28         0        27   0% /update
/dev/mmcblk0              7339       146      7193   2% /data/ftp/internal_000

So potentially the ubi1:system partition is too small for the 11.9 MB px4 file. What to do?
@eyeam3 @jberaud

I don't have the hardware with me right now, but it seems that the firmware-binary has increased in size recently. So far I had enough memory on the Bebop and had no issues when copying.
I will have a look at it tomorrow, but for now, you could run:
${RPI_TOOLCHAIN_DIR}/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-strip build_posix_bebop_default/src/firmware/posix/px4
The binary will then be about 2MB in size and fit into memory. However, you have to copy it by hand to the Bebop.

Okay, that's fine. Strip should work. We should track down why the binary recently increased in size, however. I'm also curious as to why I the root partition has just 9% free in the first place.
@jberaud Anything I can clear out safely? There might be leftover files from the auto update it did via the FreeFlight app when I first connected (?)
@eyeam3 Can you please post the output of  df here when you have the hardware with you.

@mhkabir you wouldn't want to do that. There is nothing leftover as the update process wipes everything except the media directory.
If you want to have more room, you can execute everything from the emmc, which is mounted in
/data/ftp/internal_000/

Okay, I looked into the issue. About three weeks ago there were two commits b1708f3 and 8ff237c which remove the size optimization from modules and add it back for the nuttx platform. These changes are the reason, why the binary is to large to fit into the system partition now. However, it was already tight-fitting and adding other modules eventually would have caused the same error.
This is the memory usage on my Bebop:
Filesystem           1M-blocks      Used Available Use% Mounted on
ubi1:system                 42        34         6  86% /
udev                       145         0       145   0% /dev
shm                        145         0       145   0% /dev/shm
tmp                        145         0       145   0% /tmp
ubi0:factory                 5         0         4   2% /factory
ubi2:data                    9         0         8   2% /data
ubi2:update                 28         0        27   0% /update
/dev/mmcblk0              7339      1120      6219  15% /data/ftp/internal_000

I then tried to optimize for size during the build process and added -Os back. In addition, I tried various build flags which indeed reduce the binary's size but would not solve the problem in the long term. I would also prefer to have the executable in /usr/bin for ease of use and suggest to strip the binary before uploading. This could be done in ./Tools/adb_upload_to_bebop.sh by adding the lines:
${RPI_TOOLCHAIN_DIR}/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-strip \
    -R .comment -R .gnu.version \
    ../build_posix_bebop_default/src/firmware/posix/px4

The resulting 2MB executable would definitely fit into memory and if needed one could still compile the Firmware, upload it by hand to the emmc and run it from there.

@eyeam3 Can we add the strip step to the default build steps for now?

I just added a PR #5693. In that case it would be executed when uploading the default build, but the build itself would not be changed.
Is this also okay?

Makes sense - I'll close this for now.


Begin using git token with Rich Nav task

A recent update to our service requires a Git token with all indexing requests. With this change, the Rich Nav task will have access to the aforementioned token to make requests to our service.

Codecov Report

Merging #1163 into develop will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             develop    #1163   +/-   ##
==========================================
  Coverage      35.47%   35.47%
  Complexity       548      548
==========================================
  Files            103      103
  Lines           4631     4631
  Branches         710      710
==========================================
  Hits            1643     1643
  Misses          2838     2838
  Partials         150      150

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 651f489...584640a. Read the comment docs.

Thank you @jepetty and @xuachen.


Space is added on reordering

When two lines are reordered, a space is sometimes added:
Before:
[build-system]
requires = [
  "hatchling",
]
build-backend = "hatchling.build"

After:
[build-system]
build-backend = "hatchling.build"

requires = [
  "hatchling",
]

Interesting, this doesn't show up if I add a unit test, but it does show up if I add it as an integration test.


Capabilities support in the CS API

Documentation: https://docs.google.com/document/d/10t3Ehz1JZWdDCSAS3SvxZZwb3cXYnJBoOPL4tcIKNYg/edit#heading=h.h8g8a1l2xtks
Sorry, I should have done this as a markdown MSC; consider it the last of a dying breed.

Fixes https://github.com/matrix-org/matrix-doc/issues/490 (from the looks of it)

A couple of notes:

as far as I know, this will be the first time the spec mentions the "unstable" namespace. Thought needs to be given to whether it's appropriate to include that in the spec and what "unstable" would mean in such cases.
Should modules start being versioned separately from the overall spec? This seems like a good idea especially for something like lazy loading that's special-cased a bit on the chat use-case and might need some iterations to get perfect. If we version modules, this seems like the right proposal to introduce the concept with.
We should consider a richer set of primitives for module requirements. Specifically, if a module is landing in a minor release of the spec as optional (to avoid violating semver) but is expected to become required in a future version, it's probably a good idea to communicate that somehow.
Might it not be a good idea to require servers to advertise all the modules they support (including required ones) for symmetry and in case modules go from required to optional or vice-versa in the future?
While versions is being touched, would it be a good idea to add a field with the name and version of the homeserver being run?

as far as I know, this will be the first time the spec mentions the "unstable" namespace. Thought needs to be given to whether it's appropriate to include that in the spec and what "unstable" would mean in such cases.

Unstable is mentioned throughout the spec. It's even listed as a possible version.

as far as I know, this will be the first time the spec mentions the "unstable" namespace. Thought needs to be given to whether it's appropriate to include that in the spec and what "unstable" would mean in such cases.

It slightly surprises me that we don’t mention unstable anywhere, but not that much. Might as well define it now as a prefix for experimental new stuff which hasn’t been versioned and released in the spec yet.

Should modules start being versioned separately from the overall spec?

Probably not, imo, in line with the antigoals section. The point of the monolithic version number of the CS API is to define the set of endpoints (and thus modules) which play form a single well defined release of the spec - even if some of those modules are optional.

This seems like a good idea especially for something like lazy loading that's special-cased a bit on the chat use-case and might need some iterations to get perfect. If we version modules, this seems like the right proposal to introduce the concept with.

If a module’s API needs backwards incompatible changes we’d just bump the overall version for the CS API to reflect it. Plus I’m hoping we might get the LL stuff right before it is baked into a release version number of the CS API.

We should consider a richer set of primitives for module requirements. Specifically, if a module is landing in a minor release of the spec as optional (to avoid violating semver) but is expected to become required in a future version, it's probably a good idea to communicate that somehow.

Hm, this feels quite feature creepy to me...

Might it not be a good idea to require servers to advertise all the modules they support (including required ones) for symmetry and in case modules go from required to optional or vice-versa in the future?

I guess i was trying to keep the response size small and avoid redundant info. After all, optional modules should very much be the exception rather than the norm, and by the time they become compulsory the clients will assume they’re available and not care about the /versions response.

While versions is being touched, would it be a good idea to add a field with the name and version of the homeserver being run?

It’s feature creepy, but i agree it’d be really nice to fix that at last.

e2e key backups seem like another possible use for this

I actually really like the idea of having modules be versioned separately from the main spec, and I don't see it at all in the vein of XMPP fragmentation. The idea is more akin to how some PLs are now versioning their language separately from their standard library. We get a solid foundation of functionality from the main matrix spec (the general set of abstractions that matrix uses: rooms, users, events, devices, etc.) and then modules build convenience features on top of that.
Since the modules are by definition not basic functionality of the matrix protocol (this is how it is now, too, not just in the hypothetical future I'm painting), it might be more necessary to iterate faster on the shape of those apis/conventions. Basically, I'm advocating for separate versioning of modules because of the following advantages I see:

People working on developing modules aren't held back by the pace of the general spec release timeline. Because modules tend to have less fundamental features ("convenience features"), more iteration is often necessary to get things "right".
This keeps the pace of releases of the main spec from speeding up too much (difficult for client or server authors to keep up) since it isn't necessary to increment the major version number for every breaking change to a module.
This enables client authors to upgrade piece-meal since they can continue using older versions of modules while upgrading others.

Disadvantages: this requires some sort of negotiation of which version of modules is used by client/server. This requires servers to potentially maintain multiple versions of the same functionality. More care must be given to how modules are written to make sure that they can take part in whatever "module version handshake" is chosen above. This is discussing almost entirely a different proposal than the one written here (the reason I bring it up is that implementation of this proposal begins to preclude versioning of modules).
I definitely see the disadvantages, but I'm really not super content with the current shape of lazy-loading and m.room.message, and I'd prefer not to have to wait until r2 (assuming r1 comes this month) to get those right.

I guess i was trying to keep the response size small and avoid redundant info. After all, optional modules should very much be the exception rather than the norm, and by the time they become compulsory the clients will assume they’re available and not care about the /versions response.

Not including all of the fairly small number of modules because of response size feels like premature optimization to me (different matter if we were talking about sync response of course). I'm really not convinced that we'll believe the same set of modules are required vs optional for all time, and then if we change it in the future, it's a larger burden on old clients to upgrade properly with their feature-checking code.

as far as I know, this will be the first time the spec mentions the "unstable" namespace. Thought needs to be given to whether it's appropriate to include that in the spec and what "unstable" would mean in such cases.

Unstable is mentioned throughout the spec. It's even listed as a possible version.

What I'm getting at I guess is that nowhere on the C2S spec page does it say something like "Endpoints for versions with major version number x will be found under the /_matrix/rx/ path. Endpoints for features being tested but not yet released in a stable spec release should be placed under the /_matrix/unstable/ path. That isn't there yet.

What I'm getting at I guess is that nowhere on the C2S spec page does it say something like "Endpoints for versions with major version number x will be found under the /_matrix/rx/ path. Endpoints for features being tested but not yet released in a stable spec release should be placed under the /_matrix/unstable/ path. That isn't there yet.

It is though - it could potentially be made clearer, however the table on the index has a list of the current versions for the all the specs. Each spec then has a list of versions that are available. It looks like we do have a bug where the unstable c2s spec no longer has /unstable in the path - I've filed https://github.com/matrix-org/matrix-doc/issues/1498 for this.
The intention is that by clicking on "unstable" (or HEAD as it's called for some reason) the endpoints reflect what version prefix to use. Likewise, if we ever hit an r1 then clicking on an r0 spec should show r0 for the endpoints.

The intention is that by clicking on "unstable" (or HEAD as it's called for some reason) the endpoints reflect what version prefix to use. Likewise, if we ever hit an r1 then clicking on an r0 spec should show r0 for the endpoints.

Okay that's fine in general (although I'd prefer an explicit statement of the organizing scheme rather than implicit), but endpoints under "unstable" are frequently implemented or changed before a spec PR has even landed to the unstable spec, so I feel like we should have a note somewhere about how endpoints under that prefix may be experimental (or some other similar verbiage).

From the MSC:

The client is expected to know how to interpret the compatibility of a given module at different versions.  So if a module is announced as available at r0.4.0, but the server also supports r0.5.0 and the client knows about r0.5.0 and knows that the module API is compatible between r0.4.0 and r0.5.0, it should feel free to use it.  However, if the client knows the API breaks at r2.0.0, and the server doesn’t explicitly list support for r2.0.0 in its modules response, then the client should consider it unsupported at r2.0.0.

This feels very complex and something that might be better handled by spelling it out rather than having implicit inheritance. With the proposed approach it is easy for a client to assume that r0.x will have lazy loading provided it knows how to speak r0.4 to the server. An older client would then not pick r2 as a viable option anyways because it wouldn't understand it, however a newer client might understand r2. With the client's previous assumption, it would be very possible that the client would try the r0.x lazy loading against r2 if the server didn't advertise it, as the client is trying to figure out how the versioning works.
As mentioned, the solution could be explicitly listing supported versions. For the example scenario, lazy loading would have ['r0.4.0', 'r0.5.0', 'r2.0.0'] even though r0.5 inherits from r0.4, however the client doesn't get an opportunity to make a wrong assumption.

My main concern with letting module versions drift from spec versions is that there is going to be a lot of cross dependencies between versions of the spec and versions of the modules, in terms of implementing the features.
I really want to avoid a soup of ifdefs on clients where it says things like "if we are on r0.5.0 of main spec and version r0.6.0 on the module, then we can do it like this...", and really, its just going to be a pain to implement, test and maintain client side. And it'll be fragile when a new server comes along and has a different mix of module version.
There are very real benefits to having separate versions, but I also feel that we don't want to be bumping versions of modules that much more often than the main spec anyway, for exactly the same reasons.
I vote at the very least that if your server supports an optional module it must support the same version as the latest version of the main spec the server supports, i.e. if your server supports [r0.3.0. r0.4.0], then it must also support r0.4.0 of any optional modules it supports

I've updated the googledoc to reflect erik's feedback (and out-of-band feedback from travis & vdh), and propose a simpler solution for now: that we should pause on the question of negotiating optional modules (and thus whether optional modules should need their own version numbers, and what the semantics should be for servers which only implement modules at given versions of the spec), and instead simply advertise feature flags for experimental features which have not yet landed in the spec.  Thus there's now a proposal for an unstable_features response to /versions which does just this.
Meanwhile, I think the whole question of how much to ratify "/unstable" as a version or prefix is slightly orthogonal to the question of cap neg, and eitherway can be punted for now in light of the simpler proposal.

I think the "simpler proposal" is a good idea. I'm not sure after having slept on it if separately versioned modules are actually a good idea for matrix, which tells me the general design of "optional" features needs some more thought before given structure in the spec.

Having a separate unstable_features key works. I'm slightly concerned that it will be abused and features will get released under unstable and there'll be no way of doing versioned changes, e.g. how do you discover that the server supports a newer form of lazy loading?
Three options spring to mind:

Declare that if you reach that this should never happen because they're unstable features and should be stabilised when ready
Have something like dated version, e.g.: "m.lazy_loading": "2018-08-03". The problem with this is that there's no way of supporting older clients that expect an older version (assuming the version strings are opaque), even if the newer version is backwards compatible.
Have things like "m.lazy_loading.v1": true, i.e., make a new entry for each new iteration of the feature the server supports

I was thinking of using option 3 if we ever hit that scenario for incompatible new experimental versions of an existing feature.

I vote that this MSC should enter the final comment period with the view of having it be a spec PR next week. Can the Spec Core Team either approve going into FCP or comment with any concerns. Those outside the team with concerns/suggestions are also welcome to raise them.

[ ] @anoadragon453
[ ] @ara4n
[ ] @dbkr
[ ] @erikjohnston
[ ] @KitsuneRal
[ ] @mujx
[ ] @richvdh
[x] @turt2live
[ ] @uhoreg

The watered down version that made it into synapse is working fine so far and is pretty uncontroversial. 👍from me.

(that synapse PR being a subset of https://github.com/matrix-org/synapse/pull/3589 )

@richvdh agreed. Shouldn't take too long.

I've fixed up the MSC. @richvdh, @anoadragon453 , @erikjohnston, PTAL again.

I guess this has happened by default, because LL relies on it and it is implemented in synapse and riot.

I'm renaming this to make way for an MSC for a feature which fits the 'capabilities' name better.


fix(navbar): close navbar dropdown on link click

Fix to solve this => https://jira.zopa/browse/SHOPDEV-7585

:tada: This PR is included in version 4.7.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fixes admin URLs for subclassed TextPlugins

Changed code as to your suggestion @czpython regarding issue #413

Hey,
I adjusted the tests but obviously not correctly. Looks like the test run into 404s but I have no clue why... Would you mind pointing me in the right direction?
Regards
Jakob

@jakob-o
Just need to change the import as shown here https://travis-ci.org/divio/djangocms-text-ckeditor/jobs/197365066#L221
Don't worry about the other failure.

Coverage remained the same at 77.924% when pulling f63ea91fb7c7b9bee5f970602efab25000055651 on jakob-o:bugfix/subclass-admin-urls into 3da2d58756e4e1e3328eed88f03126bfce95bd0e on divio:master.

Done


Missing instruction for environment setup.

Contact Details
<EMAIL_ADDRESS>What happened?
Missing instruction for environment setup.
I want to fix this issue of missing instruction under JWOC
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

@Poras-oss iwoc or Jwoc Please mention.

@Poras-oss iwoc or Jwoc Please mention.

I have mentioned the JWOC in the description.


Update C# wrapper to support both desktop and UWP projects...

The C# wrapper project has been changed to a NETStandard (1.1) PCL allowing it to be consumed by any project targeting .NET4.5 or greater including .NETCore and UWP projects...  The C# wrapper uses P/Invoke to call into the Native Yoga DLL...
The "Yoga" C++ project has been updated to support ARM builds...
Added the ability to generate nuget packages for the C# wrapper that supports copying the native DLLs to the target output directory.

Why did you include image assets here? I think those should be removed. For the other stuff I'll delegate to @splhack or @mattpodwysocki who knows much more about the .NET stack.

@emilsjolander those image assets are mainly for the test runner for the UWP tests, so unfortunately you have to install the app, and those are the icons it uses for the tile, taskbar icon, etc.  It's best to keep them for now unless you want to swap them out with any official Facebook icons.

What license are the icons under and where do they come from?

The icons come from the default "Unit Test App (Universal Windows)" template in Visual Studio 2015... As Matt pointed out they are part of the Unit Test Runner for the Universal Window Unit tests... Since UWP requires an app container they create an application with a GUI to run the tests.

Looks like the Travis CI is failing for unrelated reasons, since no files related were modified in this PR:
BUILT 14/26 JOBS 0.2s //:yoga#iphonesimulator-x86_64,preprocess-Yoga.c.i110b516b
YogaKit/Tests/YogaKitTests.m:12:9: fatal error: 'UIView+Yoga.h' file not found
#import "UIView+Yoga.h"
        ^
1 error generated.

What do you guys think about this directory hierarchy?
csharp/Windows [NEW]
csharp/Windows/Facebook.Yoga.Desktop.sln
csharp/Windows/tests
csharp/Windows/...
csharp/Xamarin.iOS [New]
csharp/Xamarin.Mac [New]
csharp/Xamarin.Android [New]
csharp/Facebook.Yoga (plain C# code)
csharp/tests (plain C# test)
csharp/Yoga (native code)

@matthargett yup, that test is now passing on master. sorry about that.
@splhack That looks good to me. However I'll leave it to people more familiar with .NET to decide.

Only comment is do you to describe what "flavor" of windows that is (UWP, etc)?

@chamons I'm not so familiar with Windows platforms. maybe csharp/UWP or csharp/Windows/Facebook.Yoga.UWP?

@splhack As the Xamarin.Mac guy, I know very little about Windows myself anymore

@splhack excited to see this land on Xamarin.  Would definitely like to see this with Xamarin.Forms as well

@splhack @dhaligas We are definitely interested in the Linux platform and Xamarin as an extension to React Native... Since the csproj is targeting NETStandard we don't see why it wouldn't be compatible with Mono, Xamarin, or any other platform that supports NETStandard.  I'm not an expert in those other platforms so it would be helpful if we could test this approach on those platforms...

@splhack I agree the directory structure might be improve to support all the different flavors of .NET... It's probably something we could work on in a future PR?  There are new techniques for creating cross-platform NETStandard libraries that we could surely employ to create an effective code structure...

@pre10der89 Do you mind to move Windows specific files to csharp/Windows directory? It's difficult?

@splhack It would be simple enough to move the code into a Windows folder... I would go even
further and suggest a folder structure as follows:
\NuGet
\Shared
\Yoga
\Facebook.Yoga
Facebook.Yoga.Shared.shproj
Facebook.Yoga.Shared.projitems
*.cs
\Facebook.Yoga.Tests
Facebook.Yoga.Shared.Tests.projitems
Facebook.Yoga.Shared.Tests.shproj
*.cs
\Unity
\Windows
\Build
\Facebook.Yoga
\Facebook.Yoga.Desktop.Tests
\Facebook.Yoga.Universal.Tests
Facebook.Yoga.sln
Facebook.Yoga.Desktop.sln
Facebook.Yoga.Universal.sln
\Xamarin.Android
\Xamarin.IOS
\Xamarin.Mac
The shared code is encapsulated into a shared folder and we use shared projects that are supported by both visual studio and xamarin and perhaps other .NET projects... I recommend
shared projects so that we don't have to have maintain links in the Windows projects. Using
the shared projects themselves would be optional for any platform.  The new "Shared" folder and the rename of the "tests" to "Facebook.Yoga.Tests" would break all the builds so indivdiual contributors for the other platforms would need to fix their structure...
It is beyond the scope of this PR, but there may be a better solution in the future that would involve using a Mult-targeted .NET Core project (xproj) that would allow us to build all our concerns from the same project... I don't currently have enough experience with this approach to know whether it will work for all parties.  It is a future consideration that would allow us to collapse much of the complexity in the directory structure...
Thoughts?

:shipit:

@pre10der89 before finalizing, please remove the icons for now and Facebook will provide their own

Is there anything wrong with providing the stub icons that are generated by Visual Studio until they can be replaced?

@rozele It's easier to provide icons (or just colored squares) which we make our own to avoid any licensing questions / issues.

@emilsjolander I will erase the contents of the icons in the Assets folder... They will appear as solid black... Will this work?

@splhack I will be uploading a change that will isolate all Windows related code into a windows folder... I will leave the three shared folders as they are (e.g. I will not place them into a "shared" folder)...
Here is the layout... Let me know if there is anything you'd like to see different...
csharp\Facebook.Yoga
csharp\Facebook.Yoga\Facebook.Yoga.Shared.projitems
csharp\Facebook.Yoga\Facebook.Yoga.Shared.shproj
csharp\Facebook.Yoga*.cs
csharp\NuGet\
csharp\tests\Facebook.Yoga
csharp\tests\Facebook.Yoga\Facebook.Yoga.Shared.Tests.projitems
csharp\tests\Facebook.Yoga\Facebook.Yoga.Shared.Tests.shproj
csharp\tests\Facebook.Yoga*.cs
csharp\Windows\Build
csharp\Windows\Facebook.Yoga
csharp\Windows\Facebook.Yoga.Desktop.Tests
csharp\Windows\Facebook.Yoga.Universal.Tests
csharp\Windows\Facebook.Yoga.sln
csharp\Windows\Facebook.Yoga.Desktop.sln
csharp\Windows\Facebook.Yoga.Universal.sln
csharp\Yoga\

@pre10der89 That sounds good! Thanks

@emilsjolander Have you received our signed CLA?  I don't see the CLA Signed tag on this PR...

@pre10der89 looking into it

@pre10der89 Hi! Did you sign an individual CLA or are you through a corporate CLA? And did you sign online or sign/scan via email? Thanks!

@pre10der89 can you rebase this PR to the master? For example, Native.cs YGNodeInit is already gone in the master.

@JoelMarcey My director signed the corporate CLA... I believe the CLA was signed online... @matthargett

@splhack Thank you for pointing that out... That was a merge conflict mistake... I have removed the YGNodeInit from my PR...

@pre10der89 What is the company that the CLA would be under?

We had a bit of backlog in the corporate CLA processing but we're caught up so you should be ok (and this comment should trigger the bot to come in an comment).

ETA for merge? We'd like this updated package published so we can integrate it into the next React-Native-Windows release. https://github.com/ReactWindows/react-native-windows/pull/941

@matthargett maybe today (or tomorrow)!

@matthargett unfortunately we're having some tool issue now, and holiday season, maybe it'll take a bit longer...

@matthargett I am going to try to resolve the problem for this particular issue sometime between today and the end of the weekend.

@pre10der89 do you mind to rebase this PR to the master again? #297 changed Native.cs and project.json.

@pre10der89 Once you rebase this pull request, I have an idea on how we can get this imported internally successfully, and thus landed. Thanks!

Any progress on this?

Once this pull request is rebased, I should be able to get this synced up manually.

@JoelMarcey I've rebased my PR and updated the project with the new files... All tests appear to pass... Please let me know if you see any issues...

The failing tests are unrelated. Another PR is currently working on solving those. @JoelMarcey go ahead and import

Travis should be fixed now. If you rebase all tests should pass.

@pre10der89 can you rebase so @pre10der89 can import

@rmarinho This was rebased yesterday by @pre10der89. Are we waiting for another rebase or can I go on and try to manually import?

@JoelMarcey we can go on!

D4381455 internally

Looks like this is good now. Just having @emilsjolander look at the internal diff for a final check and then we can ship.

Hey @pre10der89 can you email me to try some packages ?

@rmarinho The package has been published to NuGet... Search for Facebook.Yoga...

@pre10der89 By whom? Would love to get us in charge of that so that we can make sure to keep it up to date with the latest changes.

yeah @pre10der89 i saw that.. but that's missing all the other platforms.. what i wanted is help trying the packages im creating via CI for..  i have a VSTS setup that's working building the projects both on OSX and Windows, and the idea is nuget will support Mac, iOS, Android, as well as the windows platforms and UWP ..

Hey @emilsjolander , @rozele created a private repository from which the deploy scripts and secrets are stores (with Yoga as a submodule), and added us (BlueJeans) as a member. I was under the impression he did that after synchronizing with someone on the Facebook side about the deployment plans, but I'm sorry if we moved forward without that loop being closed. @rozele should be back online next week from his paid time-off, and he can add you to the private repository or transfer ownership as need be.

@rmarinho you can definitely add more platforms to the nuget package so it's reference-able in Xamarin Studio/VS2017 Mac, and there's actually interest from @MartinJohns to add Mac (and Linux) support to the ChakraCore nuget package we contributed there. We're happy to support that work by reviewing changes and getting basic test coverage in a CI like we have elsewhere so all platforms stay well-supported. Advanced NuGet has a bit of a learning curve, as @pre10der89 can attest, but can be very powerful for delivering an awesome developer experience. Let us know how we can help :)

@matthargett ok good to know, i did not know about this. Can you set up an email thread between us so we can get that sorted out? I'm emilsj @ fb


Linux on aarch64 support for Flutter

Description
Submitted per Ian Ward's request.
Working on a project using a Raspberry pi4 to run a flutter application that requires realm with flexible sync to retrieve data and persist transactions.
Installation steps to build and load application:

Application directory is opened in a docker container with balenalib/raspberrypi4-64 base image
App is built with "flutter build linux"
Release folder is uploaded to rpi4

When the app is started it immediately crashes with the following:
[ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Invalid argument(s): Failed to load dynamic library 'librealm_dart.so': librealm_dart.so: cannot open shared object file: No such file or directory
#0      _openRealmLib (package:realm/src/init.dart:81)
#1      initRealm (package:realm/src/init.dart:105)
#2      new RealmCore. (package:realm/src/native/realm_core.dart:68)
#3      new _RealmCore (package:realm/src/native/realm_core.dart:76)
#4      realmCore (package:realm/src/native/realm_core.dart:49)
The .so file packaged in the release folder is x86_64
~/Desktop/release/bundle/lib $ file librealm_dart.so
librealm_dart.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=e82f6eae35d31178157e461cd12e7dc9fdedce11, not stripped
Our project requires a aarch64 librealm_dart.so
How important is this improvement for you?
Dealbreaker

Hey @leclairem,
AFAICT Flutter doesn't support Raspberry Pi (or Linux cross-compilation in general). But it should be possible to compile the Realm SDK for aarch64. I'm not familiar with the balenalib/raspberrypi4-64 image, but a cursory search through their documentation reveals that there are extra steps necessary to enable cross-compilation.
In any case, I don't know enough about the Balena images to be able to offer specific guidance, but if you use something like https://github.com/Pro/raspi-toolchain to build the Realm SDK from source then it's just a matter of setting the CMAKE_TOOLCHAIN_FILE environment variable to point to the toolchain file and then run scripts/build-linux.sh to manually produce the aarch64 librealm_dart.so you need.


nix-shell -p gcc no longer works if argv[0] is not equal to nix-shell

Issue description
I have an alias to nix-shell called ns. This alias is passing the argv[0] of the actual alias to the command, which used to work before but doesn’t any longer with the following error
$ strace -e trace=execve ns -p gcc
execve("/run/current-system/sw/bin/ns", ["ns", "-p", "gcc"], 0x7fff7471c4c0 /* 40 vars */) = 0
execve("/nix/store/ymnw2mphwf1bc33v2vvh7z4vswmhj7lw-nix-2.0/bin/nix-shell", ["ns", "--run", "fish", "-p", "gcc"], 0x7ffe6a0b88b8 /* 40 vars */) = 0
these derivations will be built:
  /nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv
building '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv'...
builder for '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv' failed to produce output path '/nix/store/m6810cjvq5mkaqr681h345hf07fwa4hf-shell'
error: build of '/nix/store/2ppfqblnfjnswz4gm9qd7mr1qx9i7qg5-shell.drv' failed
+++ exited with 1 +++

Making sure that argv[0] = "nix-shell" is passed makes the build work again. This is a regression from, I believe, nix 2.0 upgrade.
Steps to reproduce
Compile the following program with cc -o /tmp/test and run /tmp/test:
#include<stdlib.h>
#include<unistd.h>
static char *ARGS[1024] = { NULL };
int main(int argc, char **argv) {
    ARGS[0] = argv[0];
    ARGS[1] = "-p";
    ARGS[2] = "gcc";
    ARGS[3] = "--run";
    ARGS[4] = "gcc --version";
    return execv("/run/current-system/sw/bin/nix-shell", ARGS);
}

Technical details
 - system: `"x86_64-linux"`
 - host os: `Linux 4.15.17, NixOS, 18.09pre137207.92f0d31b949 (Jellyfish)`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.0`
 - channels(root): `"nixos"`
 - channels(nagisa): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs`

Yes, I think this is a bug in Nix: https://github.com/NixOS/nix/blob/master/src/nix-build/nix-build.cc#L92

Closing because there is not much we can do here. If needed, you can open an issue in NixOS/nix.


Help with publications setup

Hi,
First of all, thank you very much for this template! It was extremely easy to setup and with basic html and jekyll knowledge it is pretty straightforward to customize.
I am trying to setup my publication template in a similar way as yours (https://www.cs.cmu.edu/~mshediva/publications/). The main thing I am having trouble automating with jekyll scholar is having the publication venue/conference on the left and also having links to the paper  pdf, poster, and abstract. Do you add those links manually?
Thanks!
Felipe

Hi! I'm glad you found the template helpful.
The template for the publications page is locate in _layouts/bib.html. You can see here how the links are generated. Basically, you need to add fields such as pdf, arxiv, etc. to your bib-entries in _bibliography/papers.bib. Here is an example of a bib-entry from my homepage:
 @inproceedings{cisse2016adios,
   title={ADIOS: Architectures Deep In Output Space},
   author={Ciss\'e, M. and Al-Shedivat, M. and Bengio, S.},
   abstract={<long text of the abstract>},
   booktitle={Proceedings of The 33rd International Conference on Machine Learning,},
   year={2016},

   abbr={ICML},
   code={https://github.com/alshedivat/adios},
   pdf={adios-icml16.pdf},
   supp={adios-icml16-supp.pdf},
   poster={adios-icml16-poster.pdf},
}

As you notice abbr, code, pdf, suppandposter` are custom bibtex fields.

Sweet! That was an easy fix. Thank you very much!


404 hyperlink in Infrastructure deployment into Azure via Azure DevOps documentation

Current behavior
The link for "[Getting Started - Advocated Pattern Owner]"(https://github.com/microsoft/cobalt/blob/master/devops/providers/GETTING_STARTED_ADD_PAT_OWNER.md)" is not working
Expected behavior
The link should display the right page
Steps to reproduce the issue

Go to https://github.com/microsoft/cobalt/tree/master/devops/providers/azure-devops#step-1-account-setup
Try to click the hyperlink in the first step "Getting Started - Advocated Pattern Owner "
Page opens with a 404 status

Cc: @nmiodice

More 404 hyperlinks found here as well

PR: https://github.com/microsoft/cobalt/pull/385

PR merged


No changelog

There is no change log associated with this project.
https://keepachangelog.com/en/1.0.0/

Read commit log for now, please close this.
For future released, @williamkapke please use np package.
https://github.com/sindresorhus/np
If you use np, then once the version is package/tagged/pushed to GitHub (automatically), a page will open to GitHub releases with a draft release, which you can then use as the Changelog (the GitHub releases tab).  I use this across all my projects to manage changelog.

Thanks to @williamkapke I can now contribute here and on npm.  See the Releases <https://github.com/williamkapke/bson-objectid/releases tab moving forwards, I'm about to publish an update here and there will be a new release there.


Accordion Component

https://www.figma.com/design/vzQz0IgCT37UxdEbgn1nPw/🌕-tbd-web---reviews?node-id=5983-76215&t=v1ZhnEgeEJ91VWu2-4

[ ] Desktop Design
[ ] Mobile Design
[ ] Hover state
[ ] Pressed State
[ ] Focus State
[x] Disabled

Props:

Title/Header(?)
Body

@dayhaysoos is this ready for QA? https://developer-new.tbd.website/component-guide/accordion


Add radial-gradien color around the main temperature number

As a end user,
When i remove the colored circle on the VTherm,
I need to quickly see what the hvac_mode of the VTherm.
Before the circle was colored with the hvac_mode so it was easy to see the hvac_mode. Now you just have the hvac_mode button displayed and it is not very easy to see in whatr mode you are especially if this button are masked.

Hi !
Could we please have a preference to disable the display of the gradient color ?
Otherwise, the new display is great :)
thanks !

Hi,
Don't you like my radial color ? 🥹
Could you please open a new issue ? I should have close this one because it is already released in 1.0.0.
Thank you

Disons que j'aime bien le look plus épuré :)


Implement support for code linters

Ace has built-in linters that seems to be configurable: https://github.com/securingsincity/react-ace/issues/250

#49 might help in reading linter configs from files


OOP school library: add Person, Student and Teacher classes

OOP school library: add Person, Student, and Teacher classes
Hi Reviewer,

Learning objectives

Implement classes and objects in Ruby.
Implement encapsulation and inheritance with Ruby.
Run a program using the command line.

Description
In this project, I started building my school library app. In this initial step, I implemented the classes to represent students and teachers.
General requirements

Made sure that there are no linter errors.
Made sure that I used correct Gitflow.
Made sure that I documented my work in a professional way.

Ruby requirements

Followed the list of best practices for Ruby.

Project requirements

Created class Person with  the following:

Instance vars: @id, @name, and @age.
Constructor with name,  age, and parent_permission as parameter. name and parent_permission are optional and have default values of "Unknown" and true.
Getters for @id, @name, and @age.
Setters for @name and @age.
Private method is_of_age? that returns true if @age is greater or equal to 18 and false otherwise.
Public method can_use_services? that returns true if person is of age or if they have permission from parents.

Created class Student with the following:

Inherits from Person.
Constructor extends parent's constructor by adding @classroom and a parameter for it.
Method play_hooky that returns "¯\(ツ)/¯".

Created class Teacher with the following:

Inherits from Person.
Constructor extends parent's constructor by adding @specialization and a parameter for it.
Overrided can_use_services? so it always returns true.

Each class is saved in a separate file.

Work and submission mode

I submitted this activity individually.

Appreciation

Thanks for the review, it means a lot 🙃

Thanks @mukhammadrizooff  for the heads up, It is really appreciated 🙂

Thanks @Rustamxon7


Fix build errors on rustc-1.45.2

This PR fixes the following const fn related errors:
error[E0658]: `match` is not allowed in a `const fn`
  --> src/types/initialization_vector.rs:56:9
   |
56 | /         match *self {
57 | |             Self::Aes128(v) => Some(u128::from_be_bytes(v)),
58 | |             Self::Number(n) => Some(n),
59 | |             Self::Missing => None,
60 | |         }
   | |_________^
   |
   = note: see issue #49146 <https://github.com/rust-lang/rust/issues/49146> for more information

error[E0658]: `match` is not allowed in a `const fn`
   --> src/types/initialization_vector.rs:97:9
    |
97  | /         match &self {
98  | |             Self::Aes128(v) => Some(*v),
99  | |             Self::Number(v) => Some(v.to_be_bytes()),
100 | |             Self::Missing => None,
101 | |         }
    | |_________^
    |
    = note: see issue #49146 <https://github.com/rust-lang/rust/issues/49146> for more information

   --> src/types/key_format_versions.rs:147:45
    |
147 |     pub const fn capacity(&self) -> usize { self.buffer.len() }
    |                                             ^^^^^^^^^^^
    |
    = note: see issue #57563 <https://github.com/rust-lang/rust/issues/57563> for more information
    = help: add `#![feature(const_fn)]` to the crate attributes to enable

Codecov Report

Merging #63 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #63   +/-   ##
=======================================
  Coverage   74.88%   74.88%
=======================================
  Files          45       45
  Lines        1887     1887
=======================================
  Hits         1413     1413
  Misses        474      474

Impacted Files
Coverage Δ

src/types/initialization_vector.rs
94.73% <100.00%> (ø)

src/types/key_format_versions.rs
88.42% <100.00%> (ø)

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 42b5eb5...eff1e67. Read the comment docs.


HIVE-28026: Reading proto data more than 2GB from multiple splits fails

What changes were proposed in this pull request?
HIVE-28026
Why are the changes needed?
Query: select * from <table_name>
Explanation:
On running the above mentioned query on a hive proto table, multiple tez containers will be spawned to process the data. In a container, if there are multiple hdfs splits and the combined size of decompressed data is more than 2GB then the query fails with the following error:
"While parsing a protocol message, the input ended unexpectedly in the middle of a field.  This could mean either that the input has been truncated or that an embedded message misreported its own length."
This is happening because of CodedInputStream i.e. byteLimit += totalBytesRetired + pos;
byteLimit is getting InterOverflow as totalBytesRetired is retaining count of all the bytes that it has read as CodedInputStream is initiliazed once for a container. https://github.com/apache/hive/blob/564d7e54d2360488611da39d0e5f027a2d574fc1/ql/src/java/org/apache/tez/dag/history/logging/proto/ProtoMessageWritable.java#L96
This is different from issue reproduced in https://github.com/zabetak/protobuf-large-message as there it is a single proto data file more than 2GB, but in my case, there are multiple file total resulting in 2GB.
Limitation:
This fix will still not resolve the issue which is mentioned https://github.com/protocolbuffers/protobuf/issues/11729
Does this PR introduce any user-facing change?
NO
Is the change a dependency upgrade?
NO
How was this patch tested?
On a cluster

@zabetak, can you please review?

why do we have this copy of ProtoMessageWritable in tez package namespace in hive code? @harishjp, do you know anything about this?
https://github.com/apache/tez/blob/master/tez-plugins/tez-protobuf-history-plugin/src/main/java/org/apache/tez/dag/history/logging/proto/ProtoMessageWritable.java

why do we have this copy of ProtoMessageWritable in tez package namespace in hive code? @harishjp, do you know anything about this?
https://github.com/apache/tez/blob/master/tez-plugins/tez-protobuf-history-plugin/src/main/java/org/apache/tez/dag/history/logging/proto/ProtoMessageWritable.java

see HIVE-19288, looks like at that time copied code was in unreleased version of Hive. Now since it's available we can just drop the copy and use Tez libs.
That said, I think, patch should be done in Tez

Yes, patch should be done in tez and these files in hive should be removed. It was added because tez changes were not yet released and we wanted this in hive at the moment.
I think I made a big mistake back then, the Writer and Reader should have been in hadoop and both tez and hive should be using the Writer and Reader. I was hesitant to co-ordinate between 3 projects and wait for releases in correct order to commit changes to each of the projects. Anyways, right now we can remove the tez code in hive and only have it in tez.

Yes, patch should be done in tez and these files in hive should be removed. It was added because tez changes were not yet released and we wanted this in hive at the moment.
I think I made a big mistake back then, the Writer and Reader should have been in hadoop and both tez and hive should be using the Writer and Reader. I was hesitant to co-ordinate between 3 projects and wait for releases in correct order to commit changes to each of the projects. Anyways, right now we can remove the tez code in hive and only have it in tez.

no worries, thanks @harishjp for clarifying, I think this is not the first and not even the last time we do such thing :)
created https://issues.apache.org/jira/browse/HIVE-28028

Have written a java program to reproduce this issue: https://github.com/Aggarwal-Raghav/proto-reader
Hope this helps

Please correct me if I am wrong but it seems that the consensus so far is to fix this in the Tez repo and do nothing here. From a Hive perspective what we should do is move forward with HIVE-28028. Are we all on the same page?

Ok, I will raise this PR in TEZ then.

Thank you @Aggarwal-Raghav! Could you please after the tez change remove this unnecessary file?

Sure

Have created the PR in tez TEZ-4540. Hence closing this PR


Release ArcAppliance 0.2.23

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

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
The precondition is to put your code inside this repository and upgrade the version in the pull request but do not modify src/index.json.

Do we need to keep 0.2.21?

ArcAppliance


Schedule all binding updates on Dispatcher/UI thread

Makes all changes to bound values be observed on the Dispatcher for the UI thread. This lets users write updates to their models without having to worry about marshalling back updates to the UI thread.

Looks good to me - question is do we want to merge this before rolling a new alpha release or after? It looks like it shouldn't break anything.

Well so much for "looks like it shouldn't break anything". It's broken the BindingTest sample application.

It looks like our JobRunner infrastructure can't handle having jobs posted to it as fast as this change causes them to be. This change causes every update to go through the JobRunner. I've tried a few changes, but the JobRunner still gets backed up a lot and causes the changes in the rendering loop to get delayed, which just delays the updates more and causes the whole thing to freak out.

Yeah I assumed it'd be something like that. I assume the scheduler should be changed to just call the method directly if it's already on the main thread.

I tried that. It caused a StackOverflowException if you checked one of the bound checkboxes.

Hmm, I can't understand why that would be the case - it should just be functionally the same as not using the scheduler surely?

I'm really not sure. Maybe there's a shortcut that Rx uses internally when the scheduler isn't in use? I'll investigate.

Hey @grokys, I just tested without any of the scheduler changes and I'm still getting the stack overflow. I did fix the crazy glitchiness though in the next commit

It's still being a little glitchy so there's more work to be done.

@grokys I fixed all the glitchiness in BindingTest.

Looks good - will take a proper look tomorrow. I also wanted to add a test of the functionality to the BindingTest sample - am I ok to push it to your branch when I do?

Yeah! Go for it!

Pushed a small update to the BindingTest sample to test bindings from a b/g thread,

Current coverage is 67.07% (diff: 40.00%)

No coverage report found for master at 5259ce7.

Powered by Codecov. Last update 5259ce7...4c17963

@grokys I think your test in the BindingTest application is good.


Component in keep alive receives activated event when being deactivated

Version
3.2.29
Reproduction link
code : github.com
demo : netlify.com
Steps to reproduce

Click https://vue-3-keep-alive-lifecycle.netlify.app/
Open devtools, console tab.
Click About link.
Clear console.
Click Home link.

What is expected?
Since it's being deactivated NestedAbout component should not receive the activated lifecycle event
What is actually happening?
NestedAbout component is receiving the activated lifecycle event

We can also notice that NestedHome is mounted twice, as reported here:
https://github.com/vuejs/router/issues/626#issuecomment-1004182965

Can you create a reproduction without the router? This will help to move forward. You can use this playground as a starting point

component of a nested view, are not deactivated
allowing its hook to be called.

Hello @posva,
I can't reproduce the bug without vue-router (activated event is not called on deactivated component anymore)
I let you check if my repro is valid, but I think this issue can be moved to vue-router repository.
SFC playground

The repro is not exactly the same because, in Vue Router, nested components are dynamic and keep rendering (cf the issue you linked) which is why they get activated/deactivated, the nested children are rendered twice. It's similar (but not exactly the same) as this
Let's close this in favor of https://github.com/vuejs/core/issues/5386 because solving that would solve this too.


chore(deploy): use the new rolling strategy

Fix #1

Looks promising, one quick question is if you have tried to run your change yourself? Thanks @abdonrd!

@asudoh I tested locally like this:

@asudoh yeah, I was trying to get the CI to work... Do you know what i'm doing wrong?

Ready! It's already green!
How can we prove it now?

How can we test it now?

Thank you for asking @abdonrd! The test should be creating a pseudo repo that integrates the action and pushes to a pseudo CF app. Note that you can use a commit hash as the GH action version.

@asudoh seems that it works:
https://github.com/IBM/pwa-lit-template/runs/1257059707?check_suite_focus=true#step:9:224

Super thank you so much for testing @abdonrd! 🎉


Link log_type with selected tenant

Fixes: https://issues.redhat.com/browse/LOG-3758

/hold

needs #92 to fix the e2e tests

/unhold

/hold


bitwise operators ~ | & |= &=

When I first designed the language, I realized the need to use & and | to represent union and intersection of types. Thus, at the value level, it made sense to interpret them as the same operations on Sets. Ceylon didn't have bitwise operations at all, because:

At the time I didn't view it as a language for pushing bits and bytes around.
We didn't even have a Byte type, nor the Binary abstraction, and, furthermore, Integer did not specify its representation.
I didn't want to have operator overloading for & and |.
I robbed ^ for exponentiation, and gave it a higher precedence than |.
Parsing the bitshift operators >> and << is really much too painful, and I'm always getting confused between >> and >>>.

Since then, we introduced a Byte type, we added well-defined bitwise and bitshifting operations to Integer, and ultimately I've found myself using Sets much less than I expected, and Bytes much more.
Therefore, I propose to overload the operators |, &, |=, and &= to apply not only to Sets, but also to Binarys, and introduce a prefix ~ for bitwise complement.
Note:

I'm not proposing to add ^ (xor), <<, >>, or >>>.
Overloading these operators introduces an ambiguity, for types that inherit Set & Binary, but I think that problem is pretty easy to resolve.

I've now got this working for the Java backend, and pushed it to the bitwise branch.
I still need to implement it for the JS backend.

Alternatively, if you guys really want xor and bitshifting, we could name the bitwise operators (~), (|), (&), (^), (>>),(<<), and (>>>). And that means no need for overloading. Just let me know.

Isn’t it possible to do the following?

Do the overloading thingie;
Deprecate the operators for Set;
After a while, remove the operators for Set, keeping them only for bitwise operations.

Or do you still think they are useful for sets?
Personally, I don’t mind either way; I have used bytes and needed bitwise operations in the past whereas I have rarely used sets (and never needed to perform intersection/union on them), but I don’t think I’ve needed bitwise operations enough for me to care about operators. It’s not like imma do fancy bitwise shenanigans in Ceylon as one would do in C for example.
So, whether you keep the operators for sets, for bitwise ops, for both, or remove them altogether, I wouldn’t really mind. (Although I don’t really like the idea of operator overloading that much, to be honest.)
Oh and another thing, how would assignment operators look for the parenthesed operators?

While it is rare to use union and intersection on sets, it is by no means so rare that having operators wouldn't be useful.

This functionality is now complete and available on master.
Unless anyone has any objections, I'm pretty much happy and ready to close this issue.

Done. I'm going to close, but feel free to post feedback here, if any. I can easily reopen the issue.


Undefined variable in bread browse.blade

Laravel Version: 5.4.36
Voyager Version: 0.11.14
PHP Version: 7.0
Database Driver & Version: MYSQL 5.7.9

Description:
Undefined variable error in TCG/Voyager/resources/views/bread/browse.blade.php line 45. Is it better to do it like @if(isset($item->{$row->field . '_page_slug'}) instead of current one @if($item->{$row->field . '_page_slug'})

Labels: question, possible bug

We're always open to pull requests as long as you can justify the reason for the change


Set the in-git crate version to the latest release version to unblock cargo patches

We'd like to lock to the git version if possible, and use the latest commit https://github.com/hyperium/hyper/commit/1dd761c87de226261599ff2518fe9d231ba1c82d from there. Currently, we can't do it via cargo,'s patch mechanism due to the difference in versions.
Is this intentional?
If not - please set the in-git-tree crate version to something 0.13-ish so it's possible to use the following annotation at Cargo.toml:
[patch.crates-io]
hyper = { version = "0.14.0-dev", git = "https://github.com/hyperium/hyper", rev = "21dea2114574bbeda41bad5dff5e8e3613352124" }

I'm not sure what you mean with this issue. The master branch is not directly compatible with 0.13, as it has several breaking changes in it.

Yeah, sounds good, I later discovered the 0.13 branch. We've just backported that commit there for now, see #2363.


Scala Stream Collector: Setting the encoding?

Hi @alexanderdean, in the Scala collector, I currently have the encoding hard-coded to UTF-8, but I assume this isn't correct in general. Will trackers always set a cs attribute in the query param we can access for this?
https://github.com/snowplow/snowplow/blob/feature/scala-rt-coll/2-collectors/scala-stream-collector/src/main/scala/com.snowplowanalytics.snowplow.collectors.scalastream/ResponseHandler.scala#L59

This hasn't cropped up again, closing


CRS test containers are now broken by default

Describe the bug
Since the official CRS Docker containers were modified recently to no longer support root by default, the testing in the CRS repo is broken out of the box. We must fix this.
Steps to reproduce
Run the test containers using the default configuration we ship with CRS.
Both the Apache and Nginx test setups are broken currently:
$ sudo docker compose up modsec2-apache
⋮
modsec2-apache  | AH00526: Syntax error on line 205 of /etc/modsecurity.d/modsecurity.conf:
modsec2-apache  | ModSecurity: Failed to open the audit log file: /var/log/modsec_audit.log
modsec2-apache exited with code 1

$ sudo docker compose up modsec3-nginx
⋮
modsec3-nginx  | nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
⋮
modsec3-nginx  | 2024/06/19 13:07:13 [emerg] 8#8: open() "/var/log/access.log" failed (13: Permission denied)
modsec3-nginx exited with code 1

Expected behaviour
As a CRS user, I expect the vanilla test suite / docker-compose.yml file that is shipped with CRS to work out of the box. It did indeed work until very recently.
Additional context
Workaround 1: Modify docker-compose.yml to pull an older, working image and it works fine:
image: owasp/modsecurity-crs:4.1.0-apache-202404070904

This is not an ideal solution because: it depends upon using an old build of the containers.
Workaround 2: Use chmod to add write permissions for 'other' (o+w) for the directories that live under tests/logs/
This is not an ideal solution because: as far as I can tell, it isn't possible to push Unix-style directory permissions into git, so users would have to manually fix this each time they clone our repo. We should aim to fix the problem rather than add more onus to all users.
Your Environment

CRS version (e.g., v3.2.0): 4.3.0/4.4.0-dev
Paranoia level setting: n/a
ModSecurity version (e.g., 2.9.3): n/a
Web Server and version (e.g., apache 2.4.41): Apache/Nginx CRS containers
Operating System and version: Linux

Well... can't reproduce this one:
❯ docker-compose -f tests/docker-compose.yml up modsec2-apache
[+] Running 3/3
 ✔ Network tests_default      Created                                                                                0.0s
 ✔ Container tests-backend-1  Created                                                                                0.3s
 ✔ Container modsec2-apache   Created                                                                                0.1s
Attaching to modsec2-apache
modsec2-apache  | /usr/local/bin/generate-certificate: generating new certificate
modsec2-apache  | Warning: No -copy_extensions given; ignoring any extensions in the request
modsec2-apache  | /usr/local/bin/generate-certificate: generated /usr/local/apache2/conf/server.key and /usr/local/apache2/conf/server.crt

❯ docker images --digests | rg 9c20dd4756378de04c3587911efdf37c15614403c0540e008f16ca1cdbc63cba
owasp/modsecurity-crs                                                           4-apache-202404131004                     sha256:9c20dd4756378de04c3587911efdf37c15614403c0540e008f16ca1cdbc63cba   15d39956c2b9   2 months ago    259MB

OH, you are saying that, in the future, when we update containers in the pipeline, this might break?


Add labels to tabs

Goals
Add labels to tabs in editor mode and preview mode.
We use the title of the charts.
The behavior of the tabs is as follows:

Each tab is of the same size for consistency
The ellipsis of the title is done by a semi transparent element
The tabs have a minimum width
The tabs list content can scroll once the tabs are too numerous and cannot shrink
The tabs list also indicate cut-off content via semi transparent element

How to test

Open a chart
Add 4 to 5 charts
Add titles to each of the charts

Result
https://github.com/visualize-admin/visualization-tool/assets/465582/97d19e39-bea6-4a4e-9d3d-af874f5a25ae

Sure, both behavior were not wanted ;) I fixed them.


Fix broken examples

Fixes #380
We'll need to redeploy the website after this (or does that happen automatically?)

The website repo needs to pull in the latest commit of this repo after merging. I can take care of that.


add networkpolicy workload

Description
depends on https://github.com/cloud-bulldozer/benchmark-operator/pull/588
Fixes

thanks @Harshith-umesh


Add GitHub wofklow that tags PR

Body
Implement a GitHub workflow that automatically assigns labels to PRs.
Fur this purpose consider to use the following GitHub action: https://github.com/actions/labeler
ToDos:

[ ] provide config file to define labeling rules
[ ] implement GitHub workflow that runs for every created PR and assigns labels to it

Metoring
As this ticket is marked as good first issue: one of @dominikriemer, @tenthe, or @bossenti are happy to provide help for getting started, just tag (one of) them if you want to start working on this issue and need some help.
It would be great if you discover our repository by yourself (this is a great oppurtinity to get to know the basic StreamPipes components) and come up with a proposal for labeling rules. But if you struggle with that we are happy to help you making a first draft.
StreamPipes Committer
I acknowledge that I am a maintainer/committer of the Apache StreamPipes project.

Hello,
I would like to contribute in this issue

Hi @Harry262530, awesome 🤩
Do you need any help for getting started?

Okay, the first step is to fork this repository to your own GitHub account.
Next, check out your own fork and create a branch which should ideally be named 1104-add-github-wofklow-that-tags-pr (or similar).
Then you already can start with implementing the GitHub workflow.
You can find all our existing workflows in .github.
Once you have the workflow ready, you can create a PR in this repository and we will review you it
Feel free to reach out in case you get stuck :)

sure
i'll try my best

I need a little Guidance,
I have created a branch of  this repo and I have thoroughly gone through labeler repo and workflow of this repo, now I am stuck at how to start working with the workflow and including labels.

Okay, so at first we want to have an additional workflow. So there is no need to integrate with the existing ones.
You can create a new file and call it e.g. pr-labeling.yaml.
This workflow should be executed when a PR is created.
Here you can follow the example of labeler pretty close: https://github.com/actions/labeler#create-workflow
The more difficult part is the configuration file. If you want to, you can take some time and familiarize your self with our existing labels and the codebase and come up with a proposal.
But you don't need to, you can also just provide the workflow itself and we will then come up with the configuration file.
Does this help you?

This might be also of help: https://github.com/actions/labeler#create-workflow

I have created a pull request for the workflow and config file
can you please go through them


appends when executed multiple times

It seems when I run it locally multiple times it appends the same content to the same phar.
➜  Project git:(master) ✗ php -d phar.readonly=off ./tools/phar-composer.phar build .
[1/1] Creating phar project.phar
  - Adding main package "eftec/project"
  - Adding composer base files
  - Setting main/stub
    Using referenced chmod 0644
    Applying chmod 0644
  - Overwriting existing file project.phar (5470.5 KiB)

    OK - Creating project.phar (10941.1 KiB) completed after 1s
➜  Project git:(master) ✗ php -d phar.readonly=off ./tools/phar-composer.phar build .
[1/1] Creating phar project.phar
  - Adding main package "eftec/project"
  - Adding composer base files
  - Setting main/stub
    Using referenced chmod 0644
    Applying chmod 0644
  - Overwriting existing file project.phar (10941.1 KiB)

    OK - Creating project.phar (16411.7 KiB) completed after 1.1s
➜  Project git:(master) ✗ php -d phar.readonly=off ./tools/phar-composer.phar build .
[1/1] Creating phar project.phar
  - Adding main package "eftec/project"
  - Adding composer base files
  - Setting main/stub
    Using referenced chmod 0644
    Applying chmod 0644
  - Overwriting existing file project.phar (16411.7 KiB)

    OK - Creating project.phar (21882.3 KiB) completed after 1.4s

Overwriting existing file project.phar

So it is not overwritten? At least it also seems the binentry is not used only once.

@DanielRuf Thanks for reporting!
I understand where you're coming from and agree that this looks strange to say the least, but this is indeed expected behavior at the moment:
When running phar-composer, it will bundle all files from the local directory, i.e. it will include your existing project.phar into your new project.phar which causes the archive to grow on each run.
At the moment, this can be prevented by running this in a temporary build directory like #91. We will also likely add an option to ignore certain files via #5. I'm open for more input :+1:

Hi @clue,
thanks for the feedback. I really appreciate the time that you invest into this and the other projects. I switched to the maintained box fork as this brought many improvements and worked for my needs.
I will revisit #91 in the next weeks and try this approach. Thanks for the links. I was already aware of #5 but I was not aware of #91 =)


Unable to resolve migrations for package

🐞 Bug report
Command (mark with an x)

[ ] new
[ ] build
[ ] serve
[ ] test
[ ] e2e
[ ] generate
[ ] add
[x] update
[ ] lint
[ ] extract-i18n
[ ] run
[ ] config
[ ] help
[ ] version
[ ] doc

Is this a regression?

 Yes, the previous version in which this bug was not present was: ....
^12.0.0
Description
 A clear and concise description of the problem...
I opened this issue for @angular/cdk https://github.com/angular/components/issues/24862, but I think this may instead be a CLI issue.
I have custom schematics that include @angular/cdk in the package.json "packageGroup". When running ng update my-custom-schematics I get the following error:
Unable to resolve migrations for package (@angular/cdk). [Package subpath '././schematics/migration.json' is not defined by "exports" in [project<EMAIL_ADDRESS>At first I assumed this was an issue with CDK's package.json. However, this seems to work fine if I call ng update specifically for @angular/cdk. When updating through my custom schematics though, note the double '././' path reference in '././schematics/migration.json'. Looks like packagePath is not getting set properly and we're catching the exception here: https://github.com/angular/angular-cli/blob/1c634cd327e5a850553b258aa2d5e6a6b2c75c65/packages/angular/cli/src/commands/update/cli.ts#L494.
🔬 Minimal Reproduction

🔥 Exception or Error

Unable to resolve migrations for package (@angular/cdk). [Package subpath '././schematics/migration.json' is not defined by "exports" in [project<EMAIL_ADDRESS>
🌍 Your Environment

Anything else relevant?

Can you please provide the output of ng version?

FYI, I'm actually running npx ng update my-custom-schematics because I don't have CLI installed globally.
So, if I run npx ng version, I get:
Angular CLI: 12.2.17
Node: 12.22.7
Package Manager: npm 8.2.0
OS: darwin x64

Angular: 12.2.16
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1202.17
@angular-devkit/build-angular      12.2.17
@angular-devkit/core               12.2.17
@angular-devkit/schematics         12.2.17
@angular/cdk                       12.2.13
@angular/cli                       12.2.17
@angular/material                  12.2.13
@angular/material-moment-adapter   12.2.13
@schematics/angular                12.2.17
rxjs                               6.5.5
typescript                         4.3.5

I've also tried npx -p @angular/cli@13 ng update my-custom-schematics but get the same error.
npx -p @angular/cli@13 ng version yields:
Angular CLI: 13.3.4
Node: 12.22.7
Package Manager: npm 8.2.0
OS: darwin x64

Angular: 12.2.16
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1202.17
@angular-devkit/build-angular      12.2.17
@angular-devkit/core               12.2.17
@angular-devkit/schematics         13.3.4
@angular/cdk                       12.2.13
@angular/cli                       13.3.4
@angular/material                  12.2.13
@angular/material-moment-adapter   12.2.13
@schematics/angular                13.3.4
rxjs                               6.5.5
typescript                         4.3.5

Looks like if I manually install CLI at v13 globally and then run ng update my-custom-schematic, I don't get the error. Only happens with npx ng update my-custom-schematic.

As far as I recall using npx -p will cause the version specifier to not be used, at least I remember several issues in the past about this.
Can you try to use the below command.
npx @angular/cli@13 update my-custom-schematics

That doesn't work either. Same error. Looks like some discrepancy in the path resolution when npx installs a temporary version, vs if I have it installed globally.

I don't know if this would make a difference, but I'm also using NVM to manage different Node versions. Perhaps an issue with that and npx?

Unfortunately, without a reproduction it's hard to tell what is happening here. Can you please setup a minimal reproduction?

I'm sorry, but we can't reproduce the problem following the instructions you provided.
Remember that we have a large number of issues to resolve, and have only a limited amount of time to reproduce your issue.
Short, explicit instructions make it much more likely we'll be able to reproduce the problem so we can fix it.
If the problem persists, please open a new issue following our submission guidelines.


𝕏 (formerly, Twitter) icon not showing in website footer

This is a Feature Request

What would you like to be added

The k8s.io website footer doesn't have a link to its 𝕏 account (@kubernetesio), which is now maintained by the Kubernetes community alongside CNCF. I suggest we should add that.

Why is this needed
Comments

I guess I should add it to the left group. Let me know if there's any feedback.

/assign

Thank you for reporting this issue! It appears that there is already 𝕏 detail in the footer (as seen the HTML source below), but the icon isn't rendering.

This looks like a bug.
/remove-kind feature
/retitle 𝕏 (formerly, Twitter) icon not showing in website footer
/kind bug
/area web-development

Previously, the old Twitter logo was rendering properly (refer to the v1.28 docs website (here)).
I think it's after our work involved to update to " 𝕏 " that the logo stopped rendering (refer to the commit  https://github.com/kubernetes/website/commit/803bb6b16b6d678fd5b3ecef1debde6e81865081 where it was added). It could be that the version of Font Awesome being used by the current version of Docsy is outdated and doesn't include the new icon.
The footer  𝕏 icon details are pulled from hugo.toml (refer below).
https://github.com/kubernetes/website/blob/44669d56d7329c0a12eeaac31318f3025a91e51e/hugo.toml#L252-L255

We should fix this issue in the footer.
/priority backlog
/triage accepted

fontawsome 4.7.0 doesn't include this icon, the rename only happened a short time ago.

Oh got it! Thank you for explaining and providing the links @dipesh-rawat!

Try search "x-twitter" on https://fontawesome.com/v4/icons/.

I did, v4 does not include the X Twitter icon, even v5 doesn't have it, it was introduced in the latest version (v6) of fontAwesome.

It could be that the version of Font Awesome being used by the current version of Docsy is outdated and doesn't include the new icon.

I just checked the latest Docsy release, where they have bumped fontAwesome to the latest release version 6.5.2 (see #1925)
Which means, updating the icon name in hugo.toml (to fa-brands fa-x-twitter, which are the classnames for x-twitter in the latest release)  should fix this issue, right?

fontawsome 6.5.2 includes x-twitter icon,
https://fontawesome.com/v6/search?q=twitter&o=r

@sftim and I were discussing this very topic this week. I checked FontAwesome too and couldn't distinguish the differences.

It could be that the version of Font Awesome being used by the current version of Docsy is outdated and doesn't include the new icon.

I just checked the latest Docsy release, where they have bumped fontAwesome to the latest release version 6.5.2 (see #1925)

Yes, it looks this uses an older version of Docsy and an upgrade to the latest/newer version of Docsy is required to get newer fontawesome fonts.  Of course, that impacts the entire site.

FontAwesome is a submodule of Docsy if I recall. That could be updated independently I would imagine. I do manually adds to my personal site's iconography routinely.
cc @jberkus


provision type of chef-solo error

Hi, I'm trying to use your template (ubuntu 14.04) and modifying the provisioner to use chef-solo but it errors out and I seemed can't figure out why. I'm wondering if you know what seem to be the issue? Thanks. Here the new provisioner.
  "provisioners": [
    {
      "inline": [
          "sudo apt-get -y install curl"
      ],
      "type": "shell"
    },
    {
      "cookbook_paths": [
        "./chef/cookbooks"
      ],
      "roles_path": "./chef/roles",
      "run_list": "role[base]",
      "type": "chef-solo",
      "install_command": "curl -L https://www.chef.io/chef/install.sh | {{if .Sudo}}sudo{{end}} bash"
    }
  ],

Error output:
$ packer build -only=virtualbox-iso template.json
virtualbox-iso output will be in this color.

==> virtualbox-iso: Downloading or copying Guest additions
    virtualbox-iso: Downloading or copying: file:///Applications/VirtualBox.app/Contents/MacOS/VBoxGuestAdditions.iso
==> virtualbox-iso: Downloading or copying ISO
    virtualbox-iso: Downloading or copying: http://releases.ubuntu.com/14.04/ubuntu-14.04.3-server-amd64.iso
==> virtualbox-iso: Starting HTTP server on port 8214
==> virtualbox-iso: Creating virtual machine...
==> virtualbox-iso: Creating hard drive...
==> virtualbox-iso: Creating forwarded port mapping for SSH (host port 3690)
==> virtualbox-iso: Executing custom VBoxManage commands...
    virtualbox-iso: Executing: modifyvm packer-virtualbox-iso-1442350660 --memory 512
    virtualbox-iso: Executing: modifyvm packer-virtualbox-iso-1442350660 --cpus 1
==> virtualbox-iso: Starting the virtual machine...
==> virtualbox-iso: Waiting 10s for boot...
==> virtualbox-iso: Typing the boot command...
==> virtualbox-iso: Waiting for SSH to become available...
==> virtualbox-iso: Connected to SSH!
==> virtualbox-iso: Uploading VirtualBox version info (5.0.4)
==> virtualbox-iso: Uploading VirtualBox guest additions ISO...
==> virtualbox-iso: Provisioning with shell script: /var/folders/dj/dxbc5c3j69b07bfmcs2hs2rm0000gn/T/packer-shell308345912
    virtualbox-iso: sudo: no tty present and no askpass program specified
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Script exited with non-zero exit status: 1

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Script exited with non-zero exit status: 1

==> Builds finished but no artifacts were created.

figured it out. Thanks


Polkadot account causes compilation error on client-side applications

Problem
Polkadot sdk uses BigInt which are only supported on modern browser with no polyfill alternatives for older browser.
Some common module bundler (ex: Webpack, Vite) still target those.
Error log
../typescript-sdk/node_modules/@polkadot/util/bi/sqrt.js:6:30: ERROR: Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)
../typescript-sdk/node_modules/@polkadot/util/bi/sqrt.js:14:14: ERROR: Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)
../typescript-sdk/node_modules/@polkadot/util/bi/sqrt.js:26:30: ERROR: Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)
../typescript-sdk/node_modules/@polkadot/util/bi/sqrt.js:28:33: ERROR: Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)
../typescript-sdk/node_modules/@polkadot/util/bi/toU8a.js:5:12: ERROR: Big integer literals are not available in the configured target environment ("chrome87", "edge88", "es2020", "firefox78", "safari13" + 2 overrides)

How to replicate
This only occurs in browser based applications, when importing the whole accounts object from the lib index, ex:
import { accounts } from 'aleph-sdk-ts'

Or when using the Polkadot chain specifically.
Possible workaround

As of now you can import individual accounts from ./src/[account-name] (if you don't need the DOT utils).
Change the transpilation browserlist in your application bundler
Provide a polyfill (ex: https://www.npmjs.com/package/@polkadot/x-bigint)

For a working example in the browser using vite, you can check the configuration files of the toolshed


Code Release

@fregu856  any tentative dates for code release??

Hi,
I'm very sorry for the delay, code will be released before the end of April.
//
Fredrik

I will unfortunately have to delay the code release even further, it will be up before the end of May.


Refactoring of 'ExecuteCommand'

(#1196) It's about the Refactoring of the function "ExecuteCommand". Table driven looks more clear. Three function interfaces are changed for unifying all XXXOp functions although some parameters are not used in these three functions. Maybe it's a better implemention? ^_^
I can't use C++11 beacuse of boost library. So if std::function and std::unordered_map is availiable, it works better.

Good idea 👍  , why you close this pr?

sorry I will make a new pr, this one is just a test  : )


Sidekick Library does not copy separator

In the product cards we use --- separator. The sidekick ignores the separator and doesn't copy it to clipboard.
https://main--bitdefender--hlxsites.hlx.page/tools/sidekick/library.html?plugin=blocks&path=/sidekick/blocks/products&index=0

let me check if we can simply get rid of separators

Maybe it resolves automatically when we update the sidekick lib in the project?


Add load by URL example, keywords and link to docs in RADME

Codecov Report

Merging #14 (fed33a3) into main (6bfc23e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #14   +/-   ##
=======================================
  Coverage   33.55%   33.55%
=======================================
  Files         126      126
  Lines        6372     6372
  Branches     1569     1569
=======================================
  Hits         2138     2138
  Misses       3939     3939
  Partials      295      295

Flag
Coverage Δ

unittests
33.55% <ø> (ø)

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

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 6bfc23e...fed33a3. Read the comment docs.