Update caching-dependencies-to-speed-up-workflows.md

"false" should be a string: false -> 'false'

Why:
"true" and "false" from 'outputs' are strings and should be quoted otherwise conditions won't work

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for "Automatically generated comment" and click Modified to view your latest changes).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[ ] This pull request impacts the contribution experience

[ ] I have added the 'writer impact' label
[ ] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

@giner Thanks so much for opening a PR! I'll get this triaged for review ✨


List packaging as a dependency

I ran into this error:
----> 1 out = Path("model.json")

File ~/mambaforge/envs/test/lib/python3.11/site-packages/upath/core.py:125, in UPath.__new__(cls, protocol, *args, **storage_options)
    123 # determine which UPath subclass to dispatch to
    124 if cls._protocol_dispatch or cls._protocol_dispatch is None:
--> 125     upath_cls = get_upath_class(protocol=pth_protocol)
    126     if upath_cls is None:
    127         raise ValueError(f"Unsupported filesystem: {pth_protocol!r}")

File ~/mambaforge/envs/test/lib/python3.11/site-packages/upath/registry.py:208, in get_upath_class(protocol, fallback)
    206         return WindowsUPath
    207     else:
--> 208         from upath.implementations.local import PosixUPath
    210         return PosixUPath
    211 if not fallback:

File ~/mambaforge/envs/test/lib/python3.11/site-packages/upath/implementations/local.py:15
     12 from urllib.parse import SplitResult
     14 from fsspec import __version__ as fsspec_version
---> 15 from packaging.version import Version
     17 from upath._flavour import FSSpecFlavour as _FSSpecFlavour
     18 from upath.core import UPath

ModuleNotFoundError: No module named 'packaging'

because packaging isn't listed a required dependency
https://github.com/fsspec/universal_pathlib/blob/569ceabb73503c20521949b6a5c7e3de8c6d411f/setup.cfg#L25-L26
Installing packaging fixed the issue

Thank you for reporting!

Thanks for the quick fix @ap-- !


Undefined index: plugin_data  since tt-rss upgrade

Prerequisites
Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

[x] I am running the latest version
[ ] I checked the documentation and found no answer
[x] I checked to make sure that this issue has not already been filed

Expected Behavior
No errors in update daemon log.
Current Behavior
│2021-07-03T16:09:07.472<PHONE_NUMBER>476 tt-rss.service php[2449707] INFO [tt-rss] E_NOTICE (8) (plugins.local/feediron/init.php:92) Undefined index: plugin_data                                     │
│2021-07-03T16:09:07.474<PHONE_NUMBER>659 tt-rss.service php[2449707] INFO [tt-rss] E_NOTICE (8) (plugins.local/feediron/init.php:142) Undefined index: owner_id                                       │
│2021-07-03T16:09:07.475<PHONE_NUMBER>925 tt-rss.service php[2449707] INFO [tt-rss] E_NOTICE (8) (plugins.local/feediron/init.php:142) Undefined index: plugin_data

Steps to Reproduce
Feediron works correctly with tt-rss revision 6d8f2221b82b6a31becbeed8baf5e05ad9e053fe
It started to fail when I upgraded to cd26dbe64c9b14418f0b2d826a38a35c6bf8a270
Context
Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

Operating System: NixOS 21.05
TTRSS version/git version: see above
PHP version: 7.4

I'm not able to re-produce this issue. That said that looks like some legacy fallback code that shouldn't be running on the latest version.
It should be safe to delete these lines from your feediron init.php: https://github.com/feediron/ttrss_plugin-feediron/blob/41d4bcdc499718b2157b6003ef04261842450dd5/init.php#L90-L99
I'll have to go through and remove all of this fallback code as I don't plan to support anything other than the latest versions

that shouldn't be running on the latest version.

the latest version of what ? I'm on revision  41d4bcdc499718b2157b6003ef04261842450dd5 of feediron, which is current master, and my revision of tt-rss is from 2021-06-21 which is far from old.

I was referring to the latest version of both TT-RSS and Feediron. I'm not 100% farmiliar with the older versions of TT-RSS but it looks like this is old code that allows very old versions of TT-RSS to know if it's seen an article or not. This is no longer needed as TT-RSS nowdays hashes the article before it is filtered by Feediron.
I take it you are running bare metal and not in a docker container? There may be a hickup with the version checking that's allowing this code to run when it shouldn't

Thanks it was indeed a packaging problem where get_version() would fail. Thanks for the pointer !


Update rusqlite

Update rusqlite to the newest version.
Closes #108.

Thanks for updating the dependencies and the code!


perf-test: Introduce performance test

Single Page App that tests and benchmarks Lottie animation performance among thorvg/lottie-player, dotlottie-web and lottie-web

Favicon: thorvg-icon-clear.zip


Update LICENSE.txt

This is the correct writing for MIT License.
With this, you will get MIT licenses tab beside contributors tab.

Hi @rohmanhm, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

@chrisdias Done, sorry my bad miss one line, but now it's clear

@chrisdias Sorry, you can't. If you remove the year, GitHub can't recognize your MIT License and your LICENSE Tab can't show up. Because of invalid format for MIT License.
References

https://opensource.org/licenses/MIT
http://opensource.stackexchange.com/questions/1522/what-should-be-written-in-mit-license-year-full-name
http://softwareengineering.stackexchange.com/questions/210472/is-renewal-of-mit-license-needed-on-github-at-the-beginning-of-each-year

Yes, you can. I make a new commit and it's valid MIT License. You can keep going.

yy


selection checkbox column gets cropped when initialState is defined

mantine-react-table version
2.0.0-beta.5
react & react-dom versions
18.3.1
Describe the bug and the steps to reproduce it
When initialState is included (even if empty {} ), the selection column checkbox gets slightly cropped (see screenshot)
No initialState: {}

Included initialState: {}

Minimal, Reproducible Example - (Optional, but Recommended)
none
Screenshots or Videos (Optional)
No response
Do you intend to try to help solve this bug with your own PR?
No, because I do not have time to dig into it
Terms

[X] I understand that if my bug cannot be reliably reproduced in a debuggable environment, it will probably not be fixed and this issue may even be closed.

Hi, please confirm this is still an issue with the latest beta

yep - still happening with beta 7.
but my workaround is fine instead of
initialState: {
  columnVisibility: {
    "ID": false,
  }
},

I explicitly call setColumnVisibility() afterwards in the workaround.
I notice the mantineSelectCheckboxProps.size was set (sm). Not sure if that is related.


Polymer and Turbolinks doesn't load content

https://www.youtube.com/watch?v=Zqtn9uxI1xs
It seems like Polymer elements aren't loaded after changing page with Turbolinks. Has this something to do with how Turbolinks works?

Please post code or a URL where we can reproduce / investigate.

@nonameolsson sorry, off topic, but what packages are you using to get Polymer working with Rails?


He does not keep the novels in the library

Describe the bug
He does not update the library and repeats the narrations that have been preserved because it does not save a witness at the top of the problem that he repeats the narrations without updating Yes, the narration is repeated when saving again from the source
To Reproduce
Steps to reproduce the behavior:

Go to '.Keeping the novel in the library..'
Click on '..Make an update for the library that doesn't show the new chapters of the novels..'
Scroll down to '..Enter the source again, it appears that the novel is not saved in the library and is repeated again and the same problem as before..'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

sorry, I can not understand what you mean exactly.


Adds CPU brand enums

Useful for determining checkpoint compatibility.

This seems like something we should do server-side? A function isn't necessarily tied to a platform, a checkpoint is. Maybe I'm confused and we can discuss more!

We'll populate the Function definition with information about available checkpoints per platform / CPU brand, i.e. this mapping
map<int32, CheckpointInfo> checkpoint_info = 44;

Roughly translates to:
{
    "amd": { "status": "ready", "checksum": "..."},
    "intel": { "status": "ready", "checksum": "..."}
}

so the worker uses the compatible checkpoint image.


feat: Remove karpenter.sh/managed-by var

Fixes #N/A
Description
Dropping karpenter.sh/managed-by as it is an artifact of a migration path and not something needed in the future. Adding eks:eks-cluster-name to support pod identity sessions.
How was this change tested?
make test
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

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

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

Totals

Change from base Build<PHONE_NUMBER>0:
0.0%

Covered Lines:
8852

Relevant Lines:
11332

💛  - Coveralls

/lgtm


Consider having pyramid_swagger handle basic primitive conversion in query/path/bodies

One major source of repetitive busywork in Pyramid views is casting query and path parameters into their proper type in your view (e.g. /user/1 will appear in Pyramid's matchdict as a string, not an integer). A service's Swagger spec has the necessary context to do this at the tween level, and in fact we already have the mapping available for doing our own validation. For query bodies, we should just be strongly recommending JSON everywhere as it will handle its own typecasting.
This would simplify boilerplate in views which use these parameters, which often looks like:
@view_config('user_search')  # Serves /user/{id}/items?count=5&start=0
def user_search_view(request):
    id = int(request.matchdict['id'])
    start = int(request.params['start'])
    count = int(request.params['count'])
    user_item_search(id, count, start)

Would offering casting for incoming query and path parameters be of interest? The proposal would be to only support the types defined by Swagger, with no plans to implement richer types (that is up to service authors to do separately). As always, we can make the feature controlled by a setting in your Pyramid app's config.

Looking at the code, I think the casting to type is already being done (for the most part, maybe not date/date-time), it just needs to be added to the request somewhere.  With gluapy I added a dict at request.data where the keys were the parameter names, and the values were the already casted python values.  I liked that setup a lot and would be interested in doing the same here.
request.data could be some other property, maybe request.swagger_data ? Parameter names are unique so there should be no chance of conflicts in the dict.
I like this setup because you still get access to the raw request values in their usual place, and you don't have to deal with extracting values from different parts of the request object. They're all available in the same dict.

Good call, https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md#524-parameter-object definitely requires the parameter names to be unique.
Yeah this honestly feels like a relatively easy win, particularly if we make it opt-in by not mutating the core request data like you propose. It can pull things off the wire and instantiate basic python types, then library users are free to build different DTOs, use the data directly, whatever.

@view_config(route_name="findPetsByStatus")
def findPetsByStatus(request):
# Returns thing_id as an int (assuming the swagger type is integer)
thing_id = request.swagger_data['petId']
return {thing_id}
I tested this method http://localhost:6543/pet/findByStatus?status=available/ but I get
'available/' is not one of ['available', 'pending', 'sold'] Failed validating 'enum' in schema['properties']['status']: {'allowMultiple': True, 'defaultValue': 'available', 'description': 'Status values that need to be considered for filter', 'enum': ['available', 'pending', 'sold'], 'name': 'status', 'paramType': 'query', 'required': True, 'type': 'string'} On instance['status']: 'available/'

Please open new tickets for bugs you find (like you did in #108)


danger for import-people

Exporting identities to the developer's computer is dangerous, and we may need a tool that authorizes publishing; exporting identities is only an option that is convenient for the development phase.

同意，这个问题在开发import-people功能的早期就已经讨论过。由于发布app时，必须通过people的私钥给app对象进行签名，如果不使用本地的People私钥，就需要一整套远程签名的机制。而这不是短期可以开发完成的功能
Agreed, this issue was discussed early on in the development of the import-people feature. Since the app object must be signed by the private key of people when publishing the app, a whole mechanism of remote signing is needed if the local People private key is not used. And this is not a feature that can be developed in the short term


Revive updateGeoData.ts

The MaxMind url is old and doesn't exist any more

Fixed with https://github.com/retracedhq/retraced/pull/705


MacPorts support

I'm a MacPorts guy. Is it possible to remove the hard dependency on the Homebrew pkg-config and zmq? Or is that out of your control?

As long as you've got ZeroMQ and pkg-config, it shouldn't matter where they came from. Homebrew is currently serving up<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

That's strange. Right now the installation of Hydrogen still fails with a /bin/sh: pkg-config: command not found when it tries to use pkg-config, just like @speg mentions here: https://github.com/willwhitney/hydrogen/issues/13#issuecomment-104299794

Does running pkg-config --version in the terminal give you 0.28?

Yes, it does give me 0.28.

Shit, sorry, I just realized I missed half of your previous comment. That's pretty mysterious to me.
If your main interest is just getting this running, I have to recommend Homebrew. It's what most people are using and it seems to work fine. If you're interested in getting this working with MacPorts, I'd love the help. Having to build zmq using node-gyp seems to be the source of 80% of the problems people have with installing.

@ksze  did you launch atom by typing atom  command? I happened to have the same error when I installed hydrogen on my mac and realized that it couldn't find pkg-config if atom is not launched this way.

@jzthree +1 — just ran into someone who had this issue while trying to update the package.

The other alternative is to run apm install hydrogen from the command line (to get your full path suite).

@rgbkrk Installing using the apm install hydrogen works. Thanks!


Unhandled vcdlist_c in Dota 2

What is it?

Compilation of .vcd files for a hero. .vcd make the hero avatars move when they speak and I think also include the subtitles

I made a guide on generating these files, perhaps it can be of use?: https://developer.valvesoftware.com/wiki/S2General/Importing_VCDs_to_Source_2


Save fails when the SVG already has an xmlns attribute set

I'm using highcharts to render charts and using saveSvgAsPng to download snapshots, what I've found is that highcharts includes a namespace in the markup it produces, this causes saveSvgAsPng to silently fail.
I've made changes locally to fix this (essentially test to see if the namespace is already set), I can make a pull request if you're interested.

A pull request sounds good.

Should be fixed by #60. Reopen if the problem persists.


Offer typed parameterized query helpers

Pull Request Description
Offer typed parameterized query helpers

Future Release Comment
Features:

Offer typed parameterized query helpers

I spoke with @ArielYehezkely and Amit Ofir, and we agreed that this use case is precisely something an SDK should offer - provide the user helper methods to make complex service formatting requirements transparent.
But I want to discuss this change with @AsafMah in terms of SDK parity.


use a concrete type in connect()

Motivated by discussion in #185, and the recent question on reddit.
There is a zero cost way to have a concrete type for connect(). You can have two definitions of X11Connection that would have an identical api and reexport them based on enabled features. Now these refer to a buffer type through RequestConnection::Buf, so you can use the same trick - each connection has its own distinct Buffer type, but the consumers don't care because public api is exactly the same. Meanwhile each connection can convert to abstract buffer type without any extra costs because it can see its buffer's definition.
From code perspective the result is not very satisfying though because we end up with two pretty much identical files which just forward Connection impls to a inner connection. Also this was a fairly mechanical change so it is entirely possible that I misunderstood how some pieces work.
If you don't want this or my solution is not good enough feel free to close - but given that there were some users asking for this I wanted you to know that there is a way to do this.
Closes #604

From code perspective the result is not very satisfying though because we end up with two pretty much identical files which just forward Connection impls to a inner connection.

Why? If the files are pretty much the same, isn't it possible to only have one copy and use #[cfg] for the small differences?
For example:
#[derive(Debug)]
pub struct X11Connection {
   #[cfg(feature = "allow-unsafe-code")]
   inner: XCBConnection,
   #[cfg(not(feature = "allow-unsafe-code"))]
    inner: RustConnection,
}

Most (all?) "forward to inner"-functions can then just use self.inner and "do their thing".
The different Buffer type could be papered over similarly:
impl RequestConnection for X11Connection {
   #[cfg(feature = "allow-unsafe-code")]
   type Buf = CSlice;
   #[cfg(not(feature = "allow-unsafe-code"))]
    type Buf = Vec<u8>;

Hm... a simpler patch would be the following. I'm not sure what the downsides of that would be. Any ideas/suggestions? @eduardosm
diff --git a/src/lib.rs b/src/lib.rs
index 7116b13..cbe0173 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -182,20 +182,8 @@ use protocol::xproto::{Keysym, Timestamp};
 /// used.
 pub fn connect(
     dpy_name: Option<&str>,
-) -> Result<(impl Connection + Send + Sync, usize), ConnectError> {
-    #[cfg(feature = "allow-unsafe-code")]
-    {
-        let dpy_name = dpy_name
-            .map(std::ffi::CString::new)
-            .transpose()
-            .map_err(|_| ConnectError::DisplayParsingError)?;
-        let dpy_name = dpy_name.as_deref();
-        xcb_ffi::XCBConnection::connect(dpy_name)
-    }
-    #[cfg(not(feature = "allow-unsafe-code"))]
-    {
-        rust_connection::RustConnection::connect(dpy_name)
-    }
+) -> Result<(rust_connection::RustConnection, usize), ConnectError> {
+    rust_connection::RustConnection::connect(dpy_name)
 }

 /// The universal null resource or null atom parameter value for many core X requests

Ah, silly me. Indeed, just cfging the parts of the file that are different would be better.
As for using RustConnection: given current implementation of connect I was under the impression that you want to use XCBConnection when it is available. However, I do lack the knowledge to know if this is actually useful or not. If automatic selection is not necessary then sure, just use RustConnection and don't bother with this pr.

However, I do lack the knowledge to know if this is actually useful or not.

Quick run through history (as far as I remember it; I might be wrong): connect() was written back when RustConnection was quite incomplete. These days, the only reason against it (that I can think of right now) would be something like "I want to use cairo and cairo wants a xcb_connection_t*". Obviously, this is a special case that people can get to work by just using XCBConnection directly.
So, right now I do not really know why connect() should be kept the way it is.
(Also, I'm not sure why exactly CI is failing for this PR. The complaints from rustfmt are "the usual annoyances", but the thread 'main' panicked at 'Ok(()) unexpected', examples/check_unchecked_requests.rs:52:14 puzzles me. But I haven't looked carefully at the patch yet, so this is left as an exercise for the future.)

diff --git a/src/lib.rs b/src/lib.rs
index 7116b13..cbe0173 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -182,20 +182,8 @@ use protocol::xproto::{Keysym, Timestamp};
 /// used.
 pub fn connect(
     dpy_name: Option<&str>,
-) -> Result<(impl Connection + Send + Sync, usize), ConnectError> {
-    #[cfg(feature = "allow-unsafe-code")]
-    {
-        let dpy_name = dpy_name
-            .map(std::ffi::CString::new)
-            .transpose()
-            .map_err(|_| ConnectError::DisplayParsingError)?;
-        let dpy_name = dpy_name.as_deref();
-        xcb_ffi::XCBConnection::connect(dpy_name)
-    }
-    #[cfg(not(feature = "allow-unsafe-code"))]
-    {
-        rust_connection::RustConnection::connect(dpy_name)
-    }
+) -> Result<(rust_connection::RustConnection, usize), ConnectError> {
+    rust_connection::RustConnection::connect(dpy_name)
 }

 /// The universal null resource or null atom parameter value for many core X requests

I think this makes sense. Both impl Connection and the X11Connection from this PR prevents using any XCBConnection specific functions anyways.
However, this part of CI wouldn't work as expected anymore:
https://github.com/psychon/x11rb/blob/424ca2bc4aa0cfff628d5d420aa8cec6afa50fc1/.github/workflows/CI.yml#L124-L129

However, this part of CI wouldn't work as expected anymore:

Hm... right... Meh.
"If all you have a hammer"... we could add a new feature that "does what currently is done" and default to using RustConnection.
Alternatively, we can do something like what is done in this PR: Add a "useless wrapper" just because.
Another alternative would be to keep things the way that are and instead change the docs of connect() to say that people should just use RustConnection directly instead. Also not nice.
I'm not sure what to do.

Is a change from impl Connection to RustConnection a breaking change? No one could name the impl Connection type anyway (maybe aside from nightly features), so what would be the harm in replacing it with a concrete type which implements all needed traits?

Is a change from impl Connection to RustConnection a breaking change?

So far all but one of our releases were breaking, according to semver, so I do not worry too much about this. Rather, when doing a release I look at the changes and then wonder whether this is breaking (or rather: there have always been obvious breaking changes). So let's just hope we do not have to think about this.

so what would be the harm in replacing it with a concrete type which implements all needed traits?

Lots of boilerplate code just to forward calls.
However, it seems like this is the best option we have, so perhaps we should take it.
@jDomantas Do you want to simplify this PR to have less code duplication / only one file with #[feature] checks? I'd then merge this (or someone else merges it).

@jDomantas Ping. What's the state on this?

Another idea would be: Why not use a type alias!
What I mean is the following. Would that work?
diff --git a/src/lib.rs b/src/lib.rs
index 7116b13..3983839 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -171,18 +172,37 @@ pub mod resource_manager;
 #[cfg(test)]
 mod test;

-use connection::Connection;
 use errors::ConnectError;
 use protocol::xproto::{Keysym, Timestamp};

+/// The type of the return value from [`connect`].
+///
+/// Depending on the enabled features, this is either [`XCBConnection`](xcb_ffi::XCBConnection) or
+/// [`RustConnection`](rust_connection::RustConnection). If you need one of these two, it is
+/// recommended to use them directly. This is because calling
+/// [`RustConnection::connect`](rust_connection::RustConnection::connect) always gives you a
+/// [`RustConnection`](rust_connection::RustConnection) while this type might change.
+#[cfg(feature = "allow-unsafe-code")]
+type DefaultConnection = xcb_ffi::XCBConnection;
+#[cfg(not(feature = "allow-unsafe-code"))]
+type DefaultConnection = rust_connection::RustConnection;
+
 /// Establish a new connection to an X11 server.
 ///
 /// If a `dpy_name` is provided, it describes the display that should be connected to, for
 /// example `<IP_ADDRESS>:1`. If no value is provided, the `$DISPLAY` environment variable is
 /// used.
+///
+/// Depending on the enabled features, this returns either
+/// [`XCBConnection`](xcb_ffi::XCBConnection) or
+/// [`RustConnection`](rust_connection::RustConnection).  If you need one of these two, it is
+/// recommended to use them directly. This is because calling
+/// [`RustConnection::connect`](rust_connection::RustConnection::connect) always gives you a
+/// [`RustConnection`](rust_connection::RustConnection) while this function's return type might
+/// change.
 pub fn connect(
     dpy_name: Option<&str>,
-) -> Result<(impl Connection + Send + Sync, usize), ConnectError> {
+) -> Result<(DefaultConnection, usize), ConnectError> {
     #[cfg(feature = "allow-unsafe-code")]
     {
         let dpy_name = dpy_name

Superseded by #613


⚠ SceneTime has degraded performance

In 6d8c939, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 4820 ms

Resolved: SceneTime performance has improved in c6abf5b after 6 minutes.


where to set the initial joint (position + angle) information  when controlling real aloha robot?

System Info
ubuntu 20

Information

[ ] One of the scripts in the examples/ folder of LeRobot
[ ] My own task or dataset (give details below)

Reproduction
Hi Guys, I am using the pr #316 written by Cadene to control the real aloha robot, when running cmd : python control_robot.py teleoperate --robot aloha, I found the follower move fast to HORIZONTAL_POSITION, all arms in HORIZONTAL_POSITION like a line. When I control the follower arm with the master arm, I find that the movement direction of the follower arm is exactly opposite to that of the master arm.
I thinke there may be some bug in code, or my own problem. I tried to figure out the following:

where to set the initial pose info of follower and leader in code
how to solve the opposite moving problem, have you guys met the same problem ?
Thx

Expected behavior
^^

@cong1024 I will be quick, but happy to help further.
First, checkout origin/main to get the latest version (we merged the PR).
Then, redo the calibration precedure by deleting this file: https://github.com/huggingface/lerobot/blob/main/lerobot/common/robot_devices/robots/koch.py#L305
Click on the image urls during the procedure and carefully match the positions with your arms.
Secondly check that the index of the motor corresponds to what you have with DynamixelWizzard
Without Dynamixel Wizzard, you can try to order each one to move seperately by reading their position and writing a delta position:
goal_position_array, self.leader_arms[name].read("Present_Position")
# update each dim seperately
self.leader_arms[name].write("Goal_Position", goal_position_array)

You can also write one value each time and the name of the motor similarly to:
self.leader_arms[name].write("Goal_Position", GRIPPER_OPEN, "gripper")

You can also access their ID and make sure it goes from 1 to 6:
https://github.com/huggingface/lerobot/blob/main/lerobot/common/robot_devices/motors/dynamixel.py#L38-L39
We are working on a precedure to ensure the motor indices are well set.

Thanks for help ! @Cadene , yes ,I have seen the main branch has merged the control of koch robot. For controlling aloha robot, I see the pr is still in draft, maybe working on branch user/rcadene/2024_07_11_control_aloha is better to debug? Since the configuration for  aloha and koch  is different.
For the rest suggestion, Yes, I will try to working on  ! thx~

this branch is not stable, I dont recommend using it

@Cadene  At main branch, I found that there is no calibration process for aloha, but for koch robot,  in code has this procedure,  is that no need for aloha or you guys are still working on it? How to run calibration for aloha?

Once this PR merges, Aloha will be natively supported: https://github.com/huggingface/lerobot/pull/316
Sorry for the wait!


Performance is extremely poor with validation layers

I understand that some performance degradation is expected, but with a lot of API calls the performance even with only core validation is unworkable. We are talking <1FPS where we would easily manage >200FPS on CPU side otherwise.

Getting a sample workload showing the issue, or at least some areas to focus on would be helpful.  In the complex workloads we do have, the performance impact is much less than you are experiencing.

You should ship PDBs for the release validation layers. That way I could do performance profiling without having to recompile anything & it would help debugging in general.

We'll look into doing so.

Thank you, I appreciate it.

We have the same issue on UE4; I'll try to get a Very Sleepy capture and upload it.

@RCalocaO any update?

Here they are, with and without validation.
Sleepy_Vulkan_SunTemple.zip


Document for WebApp Generator

Add the documentation for web generator under doc/src/main/asciidoc/inc/_generator.adoc

WIP

I think I can add documentation during my next update for #825


[BUG] tag_build breaks the use of data files

Environment:

setuptools 68.0.0
Python 3.10

setup.cfg:
[egg_info]
tag_build = +what
tag_date = 0

[metadata]
name = test
version = 1.0

[options]
packages = find:
package_dir =
    =src

[options.data_files]
share/man/man1 = foo.1

setup.py:
from setuptools import setup
setup(headers=['fakehdr.h'])

This results in the following wheel contents:
broken:

test-1.0.data/data/share/man/man1/foo.1
test-1.0.data/headers/fakehdr.h

working:

test-1.0+what.dist-info/METADATA
test-1.0+what.dist-info/WHEEL
test-1.0+what.dist-info/top_level.txt
test-1.0+what.dist-info/RECORD

Notice that tag_build is not included in the naming scheme for files in at least the data/headers schemes. The result is that python -m installer fails to detect that these are part of the wheel .data directory, and installs the entire test-1.0.data/ directory as regular package data into site-packages.
It is "correct" to do so since the wheel is broken. But pip has a quirk and regards any directory ending in ".data" as matching for this purpose, so pip install handles this anyway.
This is the root cause for https://github.com/gentoo/gentoo/pull/29795#issuecomment-1508492454
/cc @thesamesam

Thank you very much @eli-schwartz .
I am having a look. Not sure if this has to be changed directly in https://github.com/pypa/wheel/blob/0.41.0/src/wheel/bdist_wheel.py#L360-L363.

If I had to guess, I would say that the version string is set to its final value after egg_info runs, so using the version string to set bdist_wheel.data_dir before egg_info runs will result in the wrong directory name.

Probably we have to run egg_info.finalize_options() before attempting to use distribution.get_version() to set bdist_wheel.data_dir. Reference: https://github.com/pypa/setuptools/blob/v68.0.0/setuptools/command/egg_info.py#L242.

From some intriguingly coincidental timing, someone discovered that bdist_wheel --build-number XXXX has the opposite effect... the .data directory has the tag, .dist-info does not. :eyes:
See link above.

I believe that --build-number comes directly from pypa/wheel and might not be used in other parts of pypa/setuptools.
I could be worth bringing the discussion to pypa/wheel and maybe opening a PR with a test case?
Who knows, maybe it is already fixed by pypa/wheel#550

I will close this issue now because it is likely to have been solved in wheel==0.41.1.


Use a more recent Hex version

We need to use one that works with OTP 28.
Tentatively trying to fix https://github.com/jelly-beam/rebar3_ex_doc/actions/runs/10856838882/job/30132253914#step:5:16, as per José Valim and Bryan Paxton input on ErlEF Slack's #build-and-packaging.

Well, tests now pass. Now it's on to the generation of ex_doc for priv 😄


Error: socket hang up

Describe the problem you Confuse
A clear and concise description of what you are confusing about.
More detail (optional)
Add any other context or screenshots.

Error: socket hang up


Parameters(method="") - It shows unused methods in IntelliJi

Any plans to improve this on Idea ?

We can not do too much about it because in fact these methods are not directly used. Maybe it's possible to write a plugin and help Intellij recognize usage of these methods but we are not gonna do it. If it is annoying for you (for example when using F2 to jump to first problem/warning) you can annotate given methods with
@SuppressWarnings("unused")


Interchanging the step 3 and 4 may resolve the dashboard loading issue.

Hi @sunishsurendrank,
I was able to get the dashboard by following the updated steps. Can you please verify from your side also.

Note: Above screenshot is taken after the following the changed steps in the launching the containers in the README.MD file
I have just interchanged the steps 3 and 4 and changed the port of the python script from 3000 to 3001. I guess the Grafana container should be active when the python script is running. I could draw only this explanation from the analysis. Let me know comments.
As per previous steps, Grafana and python were being run on the same port in the same network named "COVID19DashboardbNetwork" so that why I have changed the port for python script from 3000 to 3001 and it worked for me.

@qerat97  Thanks for your PR , let me have a check and will merge it.
Also our road map is to integrate worldmap in the grafana dashboard.

@qerat97 Thanks for your PR , let me have a check and will merge it.
Also our road map is to integrate worldmap in the grafana dashboard.

I will check how i can incorporate the changes in grafana to show a worldmap. You need to something like the world map shown below in the screenshot as part of grafana dashboard.

@qerat97 Thanks for your PR , let me have a check and will merge it.
Also our road map is to integrate worldmap in the grafana dashboard.

I will check how i can incorporate the changes in grafana to show a worldmap. You need to something like the world map shown below in the screenshot as part of grafana dashboard.

Absolutely yes !!!! I have once tried it, but that attempt was not successful. Hope you will make it!!! Cheers.


chore: adding explanation of nexus-staging-plugin setup

chore: removing unnecessary site configuration and added explanation on why it's setup like this.

The profile should be specified by "-P".


Upgrade protobuf version to 3.16.0-rc1

This pull request should not be merged but is for just testing for any issues with the upcoming protobuf 3.16.0 release.

@markdroth

@jtattermusch Would you mind adding the necessary labels to run the tests when you have a chance?

@yashykt, since you're the release manager for the upcoming grpc 1.38 release, can you please make sure that there's no issues indicated by this PR, so that we can upgrade to protobuf 3.16.0 once the release is out available?
(upgrading third_party/protobuf is part of the release process). Thanks!

Note that the protobuf version was recently updated to 3.15.8 with #26105

From the previous test runs, it looks like Basic Tests C++ iOS failed. I see log messages of the form -
/Volumes/BuildData/tmpfs/src/github/grpc/workspace_objc_macos_opt_native/test/cpp/ios/Pods/Headers/Private/RemoteTestCpp/src/proto/grpc/testing/echo_messages.pb.h:12:2: error: This file was generated by a newer version of protoc which is
Wed Apr 21 10:37:14 PDT 2021 - #error This file was generated by a newer version of protoc which isWed Apr 21 10:37:14 PDT 2021 -  ^
Wed Apr 21 10:37:14 PDT 2021 - /Volumes/BuildData/tmpfs/src/github/grpc/workspace_objc_macos_opt_native/test/cpp/ios/Pods/Headers/Private/RemoteTestCpp/src/proto/grpc/testing/echo_messages.pb.h:13:2: error: incompatible with your Protocol Buffer headers. Please update
Wed Apr 21 10:37:14 PDT 2021 - #error incompatible with your Protocol Buffer headers. Please update
Wed Apr 21 10:37:14 PDT 2021 -  ^
Wed Apr 21 10:37:14 PDT 2021 - /Volumes/BuildData/tmpfs/src/github/grpc/workspace_objc_macos_opt_native/test/cpp/ios/Pods/Headers/Private/RemoteTestCpp/src/proto/grpc/testing/echo_messages.pb.h:14:2: error: your headers.
Wed Apr 21 10:37:14 PDT 2021 - #error your headers.```

It looks like not everything was updated properly in this PR.


make it optional to include polymer.html

Not sure if it's possible, but it would be great to make it optional to include polymer.html.
Maybe initPolymer can inject everything that is needed for Dartium and we can let the transformers do their work for deployment. For CSP, we could ask that users to include the polymer.html to avoid adding the script dynamically.

This issue has been moved to dart-lang/polymer-dart#192.


Fix typo

examples --> samples

The folder simples doesn't exist !! and the link in the redmefile was
broken !!
Le 6 avr. 2017 12:58, "Dmitry Kuragin"<EMAIL_ADDRESS>a écrit :

Closed #52 https://github.com/api-ai/apiai-nodejs-client/pull/52.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/api-ai/apiai-nodejs-client/pull/52#event-1031995212,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC2365NNBlpbkjSb989V1K50aLzl5Wt8ks5rtMVngaJpZM4Mtf6H
.


Using letters (A, B, C, etc) instead of KEY_A as enums for KeyboardKey is not a great idea

I know it's not within Nim's style to use capital letters to store variable information,, but I think this naming convention is just bound to cause problems, and it's not notably better than raylib's use of KEY_A

You can take a look at readme https://github.com/greenfork/nimraylib_now#enums
So you can use either A when compiler can guess what it is or you can use KeyboardKey.A to fully qualify this enum. You can always use the second option if you prefer.
Does that answer your concerns?

I still think this is not optimal, purely because KeyboardKey.A is much wordier than the regular KEY_A

I agree that there's a trade-off. I thought that it would be more concise to write just A and use namespace only when required, e.g. when you have a constant. Let me know if you have a strong use case against it, we can reconsider

There isn't a particularly compelling reason to do either way I think, ultimately both will work fine. As the repo owner it's your judgement here


Automatic update of RCT-Folly

Summary
When upgrading react-native, the version RCT-Folly defined here can change. If that happens, if you run pod install after yarn install, you will get a similar error to this:
[!] CocoaPods could not find compatible versions for pod "RCT-Folly":
  In snapshot (Podfile.lock):
    RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)

  In Podfile:
    RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)

    React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on
      RCT-Folly (= 2<IP_ADDRESS>-v2)

This error occurs because Cocoapods does not update pods that point to a local podspec. Locally, you could resolve this issue by running pod update RCT-Folly --no-repo-update. On the CI, you have to do a clean checkout (in case you cache the Pods folder which we do). All of this makes upgrading react-native painful - for the whole community and for us @shopify
There are other users who have struggled with this, such as here. The suggestion there is to delete Podfile.lock which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing.
To mitigate these issues, react_native_pods.rb automatically marks RCT-Folly as changed in the detect_changes_with_podfile method from Pod::Lockfile if the version in node_modules/react-native/third-party-podspecs/RCT-Folly.podspec and Pods/Local Podspecs/RCT-Folly.podspec.json mismatch.
Instead of automatically updating the local podspec (in Pods/Local Podspecs directory) we could also:
a) integrate RCT-Folly as a local pod (such as React-Core and others)
b) integrate RCT-Folly as an external dependency (going through Cocoapods' centralized repository)
I don't have enough context on why RCT-Folly is bundled the way it is, so I am open to suggestions here.

Changelog

[iOS] [Fixed] - Fix pod install when RCT-Folly version has been updated.
Test Plan
I have created a repository where you can reproduce the issue. You can simply:

clone the repo (git clone https://github.com/fortmarek/react-native-upgrade-reproduction)
Run yarn install && cd ios && pod install
Change react-native version in package.json to 0.66.3
Run again yarn install && pod install
Observe error

To test the fix, you can then:

copy-paste the react_native_pods.rb file from this branch to react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb
run pod install again

This time, the pod install command should succeed.

Hey @fkgozali @sota000, would you have some time to look at this? :pray:

Hi @fortmarek, sorry for the delayed response! My question would be that if RCT-Folly has the problem, wouldn't some other modules with the same setup have the same problem?
As for local vs. third party set up, I don't really have the history context either. It might be possible that it was done it because how the podspec file for RCT-Folly was set up. Maybe a better solution could be try to make it a local podspec?

Hey @sota000!

My question would be that if RCT-Folly has the problem, wouldn't some other modules with the same setup have the same problem?

Correct, I have updated the PR to automatically update all podspecs in third-party-podspecs directory. Good catch!

As for local vs. third party set up, I don't really have the history context either. It might be possible that it was done it because how the podspec file for RCT-Folly was set up. Maybe a better solution could be try to make it a local podspec?

Currently, it is a local podspec. The alternatives are:

local pod -> for this we need to have the sources locally. Unfortunately, that does not really suit us since the code for e.g. Folly is in a different repository. We could introduce git submodules to have the files locally but it's not really ideal.
remote pod -> we'd need to publish local podspecs such as Folly to the cocoapods directory. The podspecs could even keep living in the react-native repository. However, there is some maintenance tied to publishing cocoapods.

I'm leaning to keeping the current solution, although migrating to remote pods might be a good solution as well. However, that's something I cannot help with since the remote pods would have to published by Facebook employees/React Native Core group.

@sota000 any updates on this one?

@sota000 any updates on this one?

I can provide a short update. We're mostly fine with the proposed approach.
I'd like to get a final pass from @fkgozali
(sorry for this PR taking way longer than usual).

Hi there! I was looking into this issue.
AFAIU, what's happening is that react-native has a strong dependency with RCT-Folly but there is no process that enforces that.
The proper fix should be that, every time we release a new version of react-native, we had a process which bumps the RCT-Folly version as well. This should avoid any Cocoapods black magic. Those podspecs are already complex and hard to maintain. I think we should find a better way t handle these issues, instead of adding patches to the script.
That said, for the time being, I think we can live with this patch. Improving how the pods work would be an effort that we have to carry out soon, to reduce complexity and technical debt.


Could you please add support for BatchEmbedContents

I see BatchEmbedContents is available on the generated veneer client v0.3.0 already.
I'm just not sure what parameter would be optimal for the "parts..." for the batch API.  Let me know and I'll create a PR since it looks straightforward

PTAL at #7 - we're trying to hash out the right design for this.


linux_testing: enable Rust by default if available

The first assumption[1] we had was that the aarch64-unknown-none target was missing from rustc and that this was the cause for the regression.
However, it turns out that the relevant code from rustc wasn't used anyways because the Makefile does --sysroot /dev/null[2] which prevents rustc from using its own libcore. So luckily we don't have to patch the Rust bootstrap to get aarch64-linux back working[3].
In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I decided to not bother since none of those are longterm versions.
So what's left here?

Enabling Rust for aarch64-linux because it clearly works[5].

Turning off NFS_LOCALIO for aarch6y4-linux because breaks the build like this:
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected GOT/PLT entries detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: Unexpected run-time procedure linkages detected!
/nix/store/f3k0rdhcd2cx57phx755c2xixgifw5m5-binutils-2.42/bin/ld: fs/nfs/localio.o: in function `nfs_local_iocb_alloc':
/build/source/build/../fs/nfs/localio.c:290:(.text+0x324): undefined reference to `nfs_to'
[...]

[1] https://github.com/NixOS/nixpkgs/pull/315121#issuecomment-2135805876 [2]<EMAIL_ADDRESS>[3] Of course I only realized this after I spent some time hacking a rustc
patch together 🙃
[4] This broke with
    error[E0463]: can't find crate for `core`
      |
      = note: the `aarch64-unknown-none` target may not be installed
      = help: consider downloading the target with `rustup target add aarch64-unknown-none`
      = help: consider building the standard library from source with `cargo build -Zbuild-std`

[5] While the build is fine, the VM tests are still panicking, but
that's also the case for kernel-generic because of a 9p
regression:
    switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error
    [    1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
    [    1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS
    [...]

Reported as<EMAIL_ADDRESS>

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

What happens on other targets now that we unconditionally enable Rust?

Could we just enable it on aarch64 and x86_64? I'm not sure if it even supports other arches rn.

Yeah good point, was too focused on getting the aarch64 build done :)

I pushed a potential fix by making the support for CONFIG_RUST by dsefault dependant on whether rustc supports the host platform.
For testing purposes, I decided to build it for powerpc64le (built successfully) and riscv64 which failed to build with
error: unknown argument: '-mno-riscv-attribute'
error: unsupported argument 'medany' to option '-mcmodel=' for target 'unknown'
error: unsupported option '-fpatchable-function-entry=4' for target 'unknown'
error: unknown target triple 'unknown'

This is known and apparently riscv specific<EMAIL_ADDRESS>Current recommendation is to not mix up GCC and rustc apparently. If you want me to, I can fix this in the upcoming days, but I'm not sure if we should delay a fix for a aarch64-linux, a tier1 architecture for that.
Anyways, is this (i.e. availableOn) the direction we want to go? cc @alyssais

Current recommendation is to not mix up GCC and rustc apparently. If you want me to, I can fix this in the upcoming days, but I'm not sure if we should delay a fix for a aarch64-linux, a tier1 architecture for that.

I wouldn't worry about this one for now.

Although I guess if we're fixing the conditional anyway, might as well add a !(stdenv.hostPlatform.isRiscV && stdenv.cc.isGNU) check…

@OfBorg build linux_testing


integrations: Add webhook payloads for Insping.

Link to GCI task: https://codein.withgoogle.com/dashboard/task-instances/5335230552473600/

@Privisus: This is good! The only thing is, Travis is failing with some errors about your JSON. I would suggest you fix those. The best way to do that is to copy paste the JSON into this JSON formatting website and use that to generate the file. Thanks! :)

Closed. Refer to the most recent PR (7952).


/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Android/Xamarin.Android.Common.targets(3,3): Error: java/lang/Object;I)V: defining a default interface method requires --min-sdk-version >= 24 (currently 13) for interface methods: com.google.android.exoplayer2.Player$EventListener.onTimelineChanged : (Lcom/google/android/exoplayer2/Timeline;Ljava/lang/Object;I)

🐛 Bug Report

Expected behavior
Reproduction steps
Configuration
Version: 1.x
Platform:

[ ] :iphone: iOS
[ ] :robot: Android
[ ] :checkered_flag: WPF
[ ] :earth_americas: UWP
[ ] :apple: MacOS
[ ] :tv: tvOS
[ ] :monkey: Xamarin.Forms

Use d8 as compiler. Also see other closed issues.

How to use d8 compiler.
@martijn00
Thanks for reply.
Is this the solution ?

Use VS2019 16.2 or higher. Open Android properties > Android options > Dex compiler > select d8.


[SMALLFIX] Use a heartbeat thread to update metrics.

Calling MultiValueMetricsUpdate incurs some costs, such as querying ufs for available space. Also, this gets call on each heartbeat which can be very frequent. Instead, do this on a best effort basis periodically.

Merged build finished. Test FAILed.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20380/Failed Tests: 1org.alluxio:alluxio-core-server-master: 1alluxio.master.metrics.MetricsMasterTest.testMultiValueAggregator
Test FAILed.

Merged build finished. Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/20384/
Test PASSed.


getTopSelectable/autoselect as an option

In version v0.10.5 there was the option to allow autoselecting the first option. Now with v0.11.1 it is hard wired. Would be nice to make it an option again.
If necessary I can provide the necessary code

I posted a pull request #1252


Need help with Export --config commandline

I have installed Preview latest 15.9 and also i have installed 2017 Enterprise 15.8.9. I wanna export config so i can use it later.
What im a doing wrong - tried different installPath but none works
.\vs_enterprise__preview.exe export --installPath "C:\Program Files (x86)\Microsoft Visual Studio\Preview" --config "C:\.vsconfig"
Can someone give me a working example of export config?

@mrweiland The command needs to be passed directly to the installer that is on your system. e.g. "C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe" export --installPath "C:\Program Files (x86)\Microsoft Visual Studio\Preview" --config "C:.vsconfig"

I see that the examples are pointing to vs_enterprise.exe. I will work on updating those to use vs_installer.exe instead.


Adds Natspec to Contracts

What does this pull request do? Explain your changes. (required)

Added Natspec comments to LPT gateway contracts
Specific updates (required)

check commit history
How did you test each of these updates (required)

Does this pull request close any open issues?

closes #44
Checklist:

[x] README and other documentation updated
[x] All tests using yarn test pass

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
241

Relevant Lines:
241

💛  - Coveralls


The home page not loading correctly . let me fix that

Hello! 😊 I'd appreciate being assigned this task for GSSoC 24.

please assign this to me under GSSoC'24

I can fix the issue. Kindly assign this task to me under GSSoC'24

@arghadipmanna101
It appears that the home page is not loading correctly. I'm ready to address this issue and ensure that the page loads properly for all users.
You can find examples of my previous work and projects on my LinkedIn profile https://www.linkedin.com/in/prajna-paul-117086256/ and my GitHub account https://github.com/prajna321/.
Please assign me this task, and I'll work on fixing the home page loading issue promptly.
Thank you!

Thanks a lot @arghadipmanna101


Remove SPIRV 1.3 limit from target triple

In https://github.com/intel/intel-xpu-backend-for-triton/pull/1195, we changed target triple from spir64-unknown-unknown to spirv64v1.3-unknown-unknown, since some SPIR-V 1.4 features that are not backported to the SPIRV translator used by IGC.
This issue is to track changing target triple back to spir64-unknown-unknown, when SPIRV 1.4 features are backported to the branch used by IGC, and delivered in a release driver.

https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/2533 is merged.

@vlad-penkin Please feel free to assign this issue back to me once an external ticket is created.

Tested with pre-released agama driver 950.4, test/unit/language/test_core.py::test_interleave[True] fails when changing from spirv64v1.3-unknown-unknown to spir64-unknown-unknown.

Verified with agama 950.9, we can remove the workaround when it is released.


Remove jake dependency and use NPM scripts instead

[x] removed jake dependency
[x] removed test-jake NPM script (as duplicate of test script)
[x] replaced Jakefile.js with test,js script
[x] replaced Jake's build with NPM build script
[x] moved all scripts to scripts catalog
[x] added shebang comment line with node executable to JS scripts (which may require node symlink for nodejs on Debian/Ubuntu - added that info to contributing docs)
[x] updated docs

What's wrong with Jake?


Add CDNJS version badge in README.md

This badge will show the library version on CDNJS!

Hi @bigspotteddog  Sorry to bother you.
May I know can this PR can be merged?
I think it would better to close it if it can't be merged.
Thank you. :)


chore(POL): Change the displayed currency name on the card to POL

MATIC → POL Migration Coming September 4th.
ref: https://polygon.technology/blog/save-the-date-matic-pol-migration-coming-september-4th-everything-you-need-to-know

Task linked: CW-21791 Change the displayed currency name on the card to POL


Add support for specifying the Java toolchain for invoking R8

It would be awesome if this:

defaulted to the project-wide java toolchain
one could override if needed

https://docs.gradle.org/current/userguide/toolchains.html#sec:plugins
There's a comment in Gr8Task as well that this could be helpful - https://github.com/GradleUp/gr8/blob/c1a40865db903d5d8b47fec9bb8e6b7680895376/plugin-common/src/main/kotlin/com/gradleup/gr8/Gr8Task.kt#L86

Good callout 👍 . Any idea what options to expose override this? I guess it should take a path?
gr8 {
  javaHome.set("path/to/java/home")
}

ideally should expose setting the toolchain launcher itself, while defaulting to the toolchain provided by the Java extension by default, check the section "Toolchains for JVM projects" here:
https://docs.gradle.org/current/userguide/toolchains.html#sec:plugins
that way if someone does something like
java {
  sourceCompatibility = JavaVersion.VERSION_11
  targetCompatibility = JavaVersion.VERSION_11

  toolchain {
    languageVersion.set(JavaLanguageVersion.of(11))
    vendor.set(JvmVendorSpec.AZUL)
  }
}

you can get that toolchain picked up automatically.
If you have a Property<JavaLauncher> you can turn it into a java.home File with something like:
val javaHome = launcher.get().executablePath.asFile.parentFile.parentFile

Property<JavaLauncher>

Thanks that sounds perfect 👍
Do we want to be able to run R8 using e.g. Java 20 while still passing it Java 11 runtime jars? That'd save launching a new JVM if your main build is using 20. But maybe it's not worth it?

I forked the task (only needed a handy R8 invoke task :)), that's exactly what I'm doing (invoking on Gradle the JVM Gradle is running on) while runtime jars are passed in from the launcher. I guess it would make sense to name it differently or actually use it for launching, for the latter afaik the Worker APIs had nice falities to create isolated tasks that run on a different JVM.

invoking on Gradle the JVM Gradle is running on while runtime jars are passed in from the launcher

Nice. I think that's a good default, no need to downgrade the JVM just to get the runtime jars.

Closed with https://github.com/GradleUp/gr8/pull/16


Transfer of project bootstrapped

bootstrapped is an open source project that I maintain on github: https://github.com/facebookincubator/bootstrapped/
Thomas Grainger did me a kindness and uploaded bootstrapped to pypi to make is more accessible for all.
Now I am having trouble getting into contact with Thomas (I have sent a couple of emails) and I have some issues stacking up on the project (namely that it is broken on pypi): https://github.com/facebookincubator/bootstrapped/issues
I am cited as an author of the library but I would very much like to be able to uplaod new packages.
Thanks!

@graingert Are you able to transfer this project to @spencebeecher?

Hi @graingert !!! it is: spencebeecher
Thank you very much!
-Spencer

@graingert - will you have a chance to look at this soon?

added

confirmed.

Depending on the intended outcome, I might suggest that @graingert elevate @spencebeecher from "Maintainer" to "Owner" of the project if the intent is a complete transfer of the project.


update folder

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.minghui.qmh seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Extract TS evaluation code from md/script/evalCodeBlocks to ts/evaluate

See: 9aa955428f85c9224ffb6f6a7d41fa61027edafb

This was closed by #26. I neglected to reference this issue in the commit, so it doesn't appear in the history above.


Is this project dead?

I'm looking for a free animation tool and AnimateMate is pretty good so far, except I'd really like to:

See a preview without having to export
Easily jump between keyframes to make adjustments

I see these are in the roadmap, however I'm cautious to start using this plugin since the last time it was updated was 10 months ago.

You can jump between keyframe since version 0.1.9
https://github.com/Creatide/AnimateMate/releases/tag/v0.1.9

But yeah, as you already said. This is mainly prototype plugin and I do not have so much time to focus it anymore. Still it's useful for my own projects...

That's fine, I understand ;) Thanks for commenting.


Add event at handleAddition

@melenaos any update?

@melenaos any update?

I will commit it today.
I have made the space change and I am waiting for your reply on the spec change

I commit one change, is it automatically added to the merge request?


The error message doesn't make sense if typing one character into 'Starting partition key' field on the 'Shared Access Signature dialog' for one table

Storage Explorer Version: 1.29.0-dev
Build Number: 20230324.2
Branch: main
Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Ventura 13.2.1 (Apple M1 Pro)
Architecture: ia32/x64
How Found: From running test cases
Regression From: Not a regression
Steps to Reproduce

Expand one storage account -> Tables.
Create a table -> Right click the table.
Click 'Get Shared Access Signature...'.
Type '1' to the 'Starting partition key' field.
There is an error message.
Check whether the error message makes sense.

Expected Experience
The error message makes sense.
Actual Experience
The error message doesn't make sense.

Verified this issue on the build main 20230331.5. Fixed. So, we are going to close it.


AttributeError: module 'neomodel' has no attribute 'StructuredRel'

Hi!
I am super confused because I was using neomodel for my project for weeks now and it was working flawlessly:
import neomodel

class EveCompabilityMixin:
    """
    Extend neomodel classes to make them compatible with Eve API functions.
    """
    def __contains__(self, item):
        return item in vars(self)

    def __getitem__(self, item):
        return getattr(self, item)

    def __setitem__(self, key, value):
         setattr(self, key, value)

class Relation(neomodel.StructuredRel, EveCompabilityMixin):
    """
    Node model for relations in the graph.
    """
    label = neomodel.StringProperty()
    data = neomodel.JSONProperty()

But suddenly today, after wanting to run my code, I received the following error:
Traceback (most recent call last):
   File "/Users/admin/Desktop/bigworldgraph_/bigworldgraph/bwg/run.py", line 14, in <module>
from bwg.neo4j import Neo4jLayer
   File "/Users/admin/Desktop/bigworldgraph_/bigworldgraph/bwg/neo4j.py", line 14, in <module>
import neomodel
   File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/neomodel/__init__.py", line 2, in <module>
from .core import *
   File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/neomodel/core.py", line 8, in <module>
from .util import Database, classproperty, _UnsavedNode
   File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/neomodel/util.py", line 11, in <module>
from neo4j.v1 import GraphDatabase, basic_auth, CypherError
   File "/Users/admin/Desktop/bigworldgraph_/bigworldgraph/bwg/neo4j.py", line 31, in <module>
class Relation(neomodel.StructuredRel, EveCompabilityMixin):
 AttributeError: module 'neomodel' has no attribute ‘StructuredRel'

Any ideas where this error originates? Thanks in advance!
P.S.: I am using neomodel version 3.2.3 with Python 3.5.3 on MacOS 10.10.5.

One of my modules was called neo4j.py, which produced this error. Sorry and never mind!


Ctrl-V and Sending keys to iframe seems not work

I embed an webpage in neutron gui, I can input by typing, but Ctrl-C, Ctrl-V, and Send keys are not working.

Can you share some code that demonstrates your issue?

I just embed the Bing translator.
And I found a solution for activex using WM_KEYDOWN message handler  , but I have not tested if it works for Neutron yet.

Can you share some code that demonstrates your issue?

The html with iframe to load is modified from the simple.html example file, and with only an iframe in the body.
<!DOCTYPE html>

  <meta http-equiv="X-UA-Compatible" content="IE=edge">


Change view of DB2TablespaceChooser dialogArea

Change view of DB2TablespaceChooser dialogArea
Delete NLS unused message in org.jkiss.dbeaver.ext.db2.ui.internal.DB2Resources

verified


Fixed command schema to allow value / original for command definitions.

The schema current only supports title.

This is not necessary anymore. With the new code we put in place the original string is now read automatically.


When using -mt >time please include all requests that timeout to detect sqli time-based

When using ffuf -mt >time , there are many times that timed out requests are actually the detected sql injection (for time-based).
Alternatively, could you please add an option to verbosely show all timed out requests, thank you ?

Ok so as the response is never received, we cannot use the "normal" match route. For now the fix is to print out timeouts if time based matching is active.


chore(ci): add codecov.yml

Add a codecov.yml file with configuration settings, and makes Codecov informational, rather than gating pull requests and failing the status: https://docs.codecov.com/docs/commit-status#informational
note: I'm actually on the fence about this, as I don't want us to let our code coverage slip either, but sometimes the coverage change is -0.1% and it still fails. I know we can change the threshold, but I figured maybe making it informational makes more sense? Let me know what you think.

Is the gating is only on the red/green status but we can merge anyway?
I think it is a good thing to have the red mark even for -0.1%. At least, it is forcing to think about it seriously and provide a justification why we evaluate that there is no need to test (some parts of) the added code.

@apupier thanks, in that case do you think increasing the threshold to 0.50% would make sense, or even then we shouldn't have a failed status?

@apupier thanks, in that case do you think increasing the threshold to 0.25% or 0.50% would make sense, or even then we shouldn't have a failed status?

I think we should always have the failed status as soon as the coverage is decreasing. To force either to write the test or to explain why it is not worthy/not possible.


Is the project dead?

Title.
If it is indeed dead, is there any other alternative for lazy loading for angularjs?
Thanks

I guess no answer is an answer. Sorry for it. I also need an alternative

Yeah, I think as much. however, I got it to work I think (dont remember, got moved to another project)


Expand Vocal Pitch and BPM Research

Please add at least 3 more songs to https://github.com/PatrickDuncan/cleansio/wiki/Beats-Per-Minute-(BPM)-Research and https://github.com/PatrickDuncan/cleansio/wiki/Vocal-Pitch-Research

Added more songs to BPM Research. Concluded that BPM did not significantly impact lyrical transcription accuracy.


Have vote select menus automatically submit new vote.

Only affects javascript in vote_popup.js.  (Tweaked a comment in ajax controller, too.)
Should disable affected select menus and prevent leaving page until success confirmed.  If there is an error it will reset the menus to their previous state.

Coverage remained the same at 86.197% when pulling c9e5b60fa464c83b3eb632317820a9642091c1a3 on ajax-votes into 9501a0e4cd82970edb9db8bc939a7b52b8fdbce1 on master.

This logic is not perfect, but not in the way you think... I think. :)
After either error or success it will re-enable all the menus again,
regardless whether they were disabled or not.  But if the user has managed
to submit another vote in the meanwhile, then it will re-enable that
request's disabled menus prematurely.  Hmmm.  I should probably have it
just disable everything to restrict it to one vote at a time, shouldn't I?
On Thu, Dec 22, 2016 at 7:18 AM, Nathan Wilson<EMAIL_ADDRESS>wrote:

@mo-nathan commented on this pull request.
In app/assets/javascripts/vote_popup.js
https://github.com/MushroomObserver/mushroom-observer/pull/247#pullrequestreview-14171919
:

     $change_vote_selects.each(function () {

     if ($(this).data().id != changedNamingId && $(this).val() == "3.0")

       $(this).val("2.0");

     var _this2 = $(this);

     if (_this2.data("id") != naming_id && _this2.val() == "3.0") {

       _this2.val("2.0");

       _this2.attr("disabled", "disabled");

I note that _this2 never gets "disabled" set to null like _this does.
Could this be a problem?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/247#pullrequestreview-14171919,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADE2tU7Ove2DK5HvIIcsllLC7K2KIBMlks5rKpTHgaJpZM4LTWtP
.

I like the idea, but it's still not clear to me if this achieves that.  It now looks like it only disables if there is a second votes that's getting down voted.  I feel like I'm missing something.

Coverage remained the same at 86.197% when pulling 2c8e1a361ae5ca2c67527bd07083775a2ce95831 on ajax-votes into 9501a0e4cd82970edb9db8bc939a7b52b8fdbce1 on master.

Hmmm.  Maybe I mucked it up, but I just pushed a change which disables
everything.  I can't run it because of a migration pending in the user
highlighting PR.  Grrr.  I'll ask how to get around this problem in another
email.  I must be doing something wrong with git...
On Thu, Dec 22, 2016 at 7:47 AM, Nathan Wilson<EMAIL_ADDRESS>wrote:

I like the idea, but it's still not clear to me if this achieves that. It
now looks like it only disables if there is a second votes that's getting
down voted. I feel like I'm missing something.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/247#issuecomment-268827083,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADE2tapRZPz7igwxkD_Lea6r9o1_BgM9ks5rKpusgaJpZM4LTWtP
.


OSCP HTTP client and other apps could benefit from improvements in cmp_http.c

When @mpeylo submitted his CMP implementation to OpenSSL a couple of years back he got the feedback that it should not use libCURL but OpenSSL's own HTTP client, which so far is used mainly for fetching OCSP responses (but also CRLs and certificates) .
So we changed CMPforOpenSSL to make use of the implementation in crypto/ocsp/ocsp_ht.c.
Unfortunately this HTTP client is tailored for use with OCSP and is very primitive - in particular, handling of delayed responses and errors is very poor and there is no support for more advanced features such redirection and use of proxies.
One of the next chunks of our current CMP contribution contains the HTTP client to be used for CMP, which will reside in crypto/cmp/cmp_http.c. The current state of its development can be found in https://github.com/mpeylo/cmpossl/blob/cmp-dev/crypto/cmp/cmp_http.c
This implementation is based on the mentioned HTTP code in ocsp_ht.c, while it contains improvements for those of its shortcomings critical for CMP: it

can send and receive any types of ASN.1-formatted requests and responses
does not include a potentially busy loop when waiting for responses
but makes use of timeout mechanism integrated with socket-based BIO
returns more useful diagnostics in various error situations
supports the use of HTTP proxies and of TLS (including TLS over proxies)

I've already shaped the code in cmp_http.c such that several portions of it could more or less directly generalize and improve the existing HTTP client code in ocsp_ht.c, apps/ocsp.c, apps/s_client.c, and apps/lib/apps.c.
What is your view on these improvements - should I push them upstream (as a couple of independent PRs) for general use or should we keep them in cmp_http.c?

It would be a shame to have two pieces of code that do the same thing.

I agree with @richsalz. Please make a generic http client that can be used by both CMP and OCSP. I'm not sure where it should be located in the end, but crypto/http/ is at least a start.

Agree with @levitte and @richsalz.

Fine. I've meanwhile started implementing this.
Though I'm on vacation this week I estimate to be able to present a first version on Friday.

Phew, implementing this generalized HTTP client was more work than expected.
I've moved most of the generally useful code into crypto/http/http_client.c (and a few functions into crypto/http/http_lib.c and as tentative a minor extension of crypto/bio/b_sock.c).
Doing so, the former crypto/ocsp/ocsp_ht.c (which is now called crypto/ocsp/ocsp_http.c), crypto/ocsp/ocsp_lib.c, and crypto/cmp/cmp_http.c have become pleasantly tiny.
Using the generalized code I also have been able to simplify apps/ocsp.c, apps/s_client.c, apps/lib/apps.c, and apps/cmp.c (which has not yet been submitted as part of our CMP contribution).
I've also updated the existing docs, while doc for the new functions is still to be done.
I invite you to take a look at https://github.com/mpeylo/cmpossl/tree/prepare_http/crypto/http (as well as on the other files I've just mentioned) and give me feedback on the changes I've made.
The branch prepare_http is a kind of preview of a proper pull request, which I'll provide ASAP (within a couple of days).

I had a quick look, and good start.
Something that became immediately obvious is the naming issue with public symbols. All new APIs must have names starting with OSSL_ so we don't pollute the name space further. An example of a "new" API is the STORE, with all its public symbols starting with OSSL_STORE.

Thanks for this quick first reaction.
I've prefixed all new and adapted exported (BIO_* and HTTP_*) functions with OSSL_.

Is there anything else, in particular regarding the overall code structure, that I should change before doing the PR?

Heh, BIO_ isn't necessary, 'cause that's an already existing API which you are just adding to.

Re the rest, I need a bit of time to have a deeper look.  Quite frankly, a PR works just as well, and you might want to mark it as WorkInProgress.  I assume you know how.

Heh, BIO_ isn't necessary, 'cause that's an already existing API which you are just adding to.

I didn't get what you mean -
replace OSSL_BIO_wait by OSSL_wait (which would be too unspecific in my view)
and OSSL_BIO_connect_retry by OSSL_connect_retry?

Re the rest, I need a bit of time to have a deeper look.

I understand - this code is non-trivial. While the bulk of it has just been moved around,
there are a couple of improvements (taken from our to-be-contributed CMP implementation) which I mentioned above, some of which are a bit tricky, in particular the proxy & TLS support.

Quite frankly, a PR works just as well, and you might want to mark it as WorkInProgress. I assume you know how.

I guess you mean prepending "WIP:" to the title of the PR?
Unfortunately the prepare_http branch (at least so far) touches also our current CMP master branch, but after I've sorted this out (likely tomorrow or Wed) I can do.

Sorry, didn't express myself well. What I meant is that the BIO_ prefix is already established, so functions having names starting with that do not need further prefixing (BIO is not a new API). However, functions with names starting with HTTP_ constitute an entirely new API, which means they need the additional OSSL_ prefix.

All right, reverted renaming the two new BIO_* functions to OSSL_BIO_*.

Closing this issue since #10667 implementing it has been merged.


MQTT Broker disconnect causes tcp_read error spam (IDFGH-8549)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
esp-idf-v5.1-dev-962-g787c69a2cc
Operating System used.
Windows
How did you build your project?
Eclipse IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
Custom board
Power Supply used.
External 3.3V
What is the expected behavior?
No spam.
What is the actual behavior?
When the brokers shuts down, the mqtt client tcp connection will start to spam 'transport_base: tcp_read error, errno=Socket is not connected' messages. The frequency of these messages causes starvation and triggers the task watchdog.
Steps to reproduce.

Connect to broker (mosquitto)
Exit the broker
Spam begins

Debug Logs.
<CUT, many more of the same message here>
E (78504) transport_base: tcp_read error, errno=Socket is not connected
E (78514) transport_base: tcp_read error, errno=Socket is not connected
E (78514) transport_base: tcp_read error, errno=Socket is not connected
E (78524) transport_base: tcp_read error, errno=Socket is not connected
E (78534) transport_base: tcp_read error, errno=Socket is not connected
E (78534) transport_base: tcp_read error, errno=Socket is not connected
E (78544) transport_base: tcp_read error, errno=Socket is not connected
E (78554) transport_base: tcp_read error, errno=Socket is not connected
E (78564) transport_base: tcp_read error, errno=Socket is not connected
E (78564) transport_base: tcp_read error, errno=Socket is not connected
E (78574) transport_base: tcp_read error, errno=Socket is not connected
E (78584) transport_base: tcp_read error, errno=Socket is not connected
E (78594) transport_base: tcp_read error, errno=Socket is not connected
E (78594) transport_base: tcp_read error, errno=Socket is not connected
E (78634) transport_base: tcp_read error, errno=Socket is not connected
E (78634) transport_base: tcp_read error, errno=Socket is not connected
E (78634) transport_base: tcp_read error, errno=Socket is not connected
E (78644) transport_base: tcp_read error, errno=Socket is not connected
E (78654) transport_base: tcp_read error, errno=Socket is not connected
E (78664) transport_base: tcp_read error,E (78664) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (78664) task_wdt:  - IDLE (CPU 0)
E (78664) task_wdt: Tasks currently running:
E (78664) task_wdt: CPU 0: mqtt_task
E (78664) task_wdt: CPU 1: IDLE
E (78664) task_wdt: Print CPU 0 (current core)

<CUT backtrace shows it was stuck in uart_write/log_write>

<CUT many more tcp_read error here>

E (82624) transport_base: tcp_read error, errno=Socket is not connected
E (82634) transport_base: tcp_read error, errno=Socket is not connected
E (82634) transport_base: tcp_read error, errno=Socket is not connected
E (82644) transport_base: tcp_read error, errno=Socket is not connected
E (82654) transport_base: tcp_read error, errno=Socket is not connected
E (82654) transport_base: poll_read select error 104, errno = Connection reset by peer, fd = 54
E (82664) mqtt_client: Poll read error: 128, aborting connection

More Information.
No response

Thanks for reporting this bug! We missed one error translation in tcp-transport component, this patch should fix the issue:
tcp_transport-Fix-error-propagation-on-tcp_read.patc.txt

v5.1-dev: dc1f6b3aefe26541e884e4c59b81287b3e643f0a
v5.0: 3caeaece6b62b29b6d8b8cde312c10869aa6dd25


cyanrip: 0.8.0 -> 0.8.1

Motivation for this change
Updating per upstream request.
https://github.com/cyanreg/cyanrip/commit/63cda87824c5255ffad87a20cec115d0bf8685d6#commitcomment-65143949
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ryantm Is this something nixpkgs-update can handle automatically? It's just a simple fetchFromGitHub package.

Is this something nixpkgs-update can handle automatically? It's just a simple fetchFromGitHub package.

I think nixpkgs-update can handle fetchFromGitHub packages without adding passthru.updateScript.

nix-community/infra: infra/build02/nixpkgs-update.nix#L80
ryantm/nixpkgs-update-github-releases: loadMetaFromPath.nix#L22
ryantm/nixpkgs-update-github-releases: main.py

But I think your are faster than r-ryantm in both 0.7.0 -> 0.8.0 and 0.8.0 -> 0.8.1 so there is no chance for r-ryantm to open PRs for this package and thanks for keeping the package well-maintained :-)


Group standard suites on frontend

After https://github.com/diktat-static-analysis/save/issues/327 we can group suites by language. This field needs to be added into the DB and then passed to the frontend.

Closed in #457


[BEAM-570] Performance optimization in fileio for compressed sources.

Moving from a string-based buffer to a cStringIO based on in order to help with performance of compressed sources.
Dropping some TODOs for doing similar performance improvements in GcsIO.
Making _CompressedFile conform to standard Python IO function names.

Hi @chamikaramj, can you please take a look?
R: @chamikaramj

LGTM

Hi @robertwb, could you merge this in?
R: @robertwb

Thanks for the merge @robertwb! Closing...


[BUG] Setting specific cell fill applies to entire column

🐛 Bug Report
When I try to set a specific cell fill using worksheet.getCell('A2'), the fill is applied to all cells in A column.
Lib version: 4.2.1
Steps To Reproduce
const Excel = require('exceljs');
const workbook = new Excel.Workbook();

(async () => {
  await workbook.xlsx.readFile(
    './exampleSpreadsheet.xlsx'
  );
  const ws = workbook.getWorksheet('example sheet');
  ws.getCell('A2').fill = {
    type: 'pattern',
    pattern: 'solid',
    fgColor: { argb: 'FFFFFF00' },
  };
  await workbook.xlsx.writeFile(
    'exampleSpreadsheet.xlsx'
  );
})();

The expected behaviour:
A2 cell color is changed to argb FFFFFF00 (yellow)
Actual behaviour:
All 'A' column cell colors are changed to argb FFFFFF00 (yellow)

I got the same problem, and set cell.font also aplied to entire column

It appears that the style object of a cell can be shared among multiple cells or ranges, so changing the fill of one cell affects all of the cells that reference the same style object.   If you want to force color a specific cell, a work around is to just create a new style object and assign it to the cell's style property.


Switch to rTorrent stickz project

rTorrent stickz is a project maintained by a core collaborator of ruTorrent. https://github.com/stickz/rtorrent
The rTorrent stickz project focuses on performance and stability of the torrent client. It is designed to be fully compatible with ruTorrent. Also, it does not seek to modify the torrent software in any way that may be undesirable for users.
It includes significant performance and stability optimizations for the rTorrent software. It also ensures full compatibility with link time optimizations during the build process. It is a drop in replacement for rTorrent with all the core patches from this docker container included. It also improves the implementation of UDNS to make it more reliable.
As a result, it is a perfect candidate for this docker container! Let's start off by removing 1354 lines of code and adding 16 lines!

@crazy-max I also forgot to mention, the rTorrent stickz project has GitHub Actions runners for both amd64 and arm64. The project is designed to be compatible with ARM. All development changes are tested against the ARM platform. No other rTorrent project goes to this depth, to ensure the software works properly on ARM. We intend to keep the ARM platform supported!

I have been using this for the last few weeks and it has significantly improved my performance. @crazy-max  this would be an amazing addition

I'm afraid a lot of private trackers which have strict policies for valid clients will refuse/ban this rtorrent because of unrecognized build.

I'm afraid a lot of private trackers which have strict policies for valid clients will refuse/ban this rtorrent because of unrecognized build.

Special care is being taken to ensure it remains compatible with private trackers.
Also, they will have to ban seed box providers if they do that. One of the largest seed box providers is going to be deploying it in a few weeks. They funded it's development. One of the stipulations is for all private tracker mechanisms to work properly.


Cant push docker image / Missing certificate

Hi everyone, actually i'm trying to implement notary remotely using self-signed certificates. The problem I have is that when docker push an image to my remote registry, I get the following message:
[root@host1 notary]# docker push my.registry:443/redis:v1
The push refers to a repository [my.registry:443/redis]
056fcf7d69e2: Layer already exists
e32b18adb96a: Layer already exists
2f13461ea8e4: Layer already exists
95be465fad9c: Layer already exists
2774a8f46ae9: Layer already exists
60ab55d3379d: Layer already exists
v1: digest: sha256:b9162e881718b326f9e1bad041fdbfe320b7e63d85eaf468e1148037a1fa39e0 size: 1568
Signing and pushing trust metadata
Error establishing connection to notary repository: Missing client certificate my.registry.cert for key my.registry.key
Missing client certificate my.registry.cert for key my.registry.key

Notary configuration files
Client:
{
  "trust_dir" : "~/.docker/trust",
  "remote_server": {
    "url": "https://notary-server:4443",
    "root_ca": "./root-ca.crt",
    "tls_client_cert": "./my.registry.pem",
    "tls_client_key": "./my.registry.key"
  }
}

Server:
{
        "server": {
                "http_addr": ":4443",
                "tls_key_file": "../certs/my.registry.key",
                "tls_cert_file": ".../certs/my.registry.pem"
        },
        "trust_service": {
                "type": "remote",
                "hostname": "notarysigner",
                "port": "7899",
                "tls_ca_file": "./root-ca.crt",
                "key_algorithm": "ecdsa",
                "tls_client_cert": "../certs/my.registry.pem",
                "tls_client_key": "../certs/my.registry.key"
        },
        "logging": {
                "level": "debug"
        },
        "storage": {
                "backend": "mysql",
                "db_url": "server@tcp(mysql:3306)/notaryserver?parseTime=True"
        }
}

signer:
{
        "server": {
                "grpc_addr": ":7899",
                "tls_cert_file": "../certs/my.regsitry.pem",
                "tls_key_file": "../certs/my.registry.key",
                "client_ca_file": "./root-ca.crt"
        },
        "logging": {
                "level": "debug"
        },
        "storage": {
                "backend": "mysql",
                "db_url": "signer@tcp(mysql:3306)/notarysigner?parseTime=True"
        }
}

In my host I currently use centos 7.
I would like to solve this problem of certificates, I remain attentive to your comments since you have much more experience than me. Beforehand thank you very much.
UPDATED:
to solve this problem, the certificates created must be .cert because docker daemon uses a normal certificate as .cert and as CA certificate those that end in .crt.

Thanks for working this out, I have to say I haven't tried mutual TLS auth from the docker client to the Notary Server.


Interplay with Documenter.jl

I think it'd be nice to have LiveServer play nicely with Documenter.jl in that when you compile the docs you typically want to have a look at them too.
One thing to do (I'm working on it) is to make serve take an argument dir which can specify a directory to watch that is not the current one. That's not too hard just requires get_fs_path to use the root.
Then we'd have to see how the two can play well together, I'm sure that would get some Julia folks interested.

Ok I have a working prototype for this and it's quite nice. See servedocs.

Had this (passing a dir to serve) in my mind since the beginning. Thought that we'd be starting to build a full-blown static server though, so I did not implement it right from the beginning. (Compare e.g. NGINX; you can configure it to server arbitrarily many directories at arbitrary URL paths.)
Now that there's a cool use case, I think just being able to tell serve which directory to serve is a good thing.

yay!


[10.x] Added methods for querying by route key

Route keys are a well-known concept in Laravel when it comes to Eloquent Model. They can be defined for any model by overriding the getRouteKeyName method and are used by the framework when resolving substitutions inside requests.
However, in order to query models by route key, you currently need to instantiate a new object just to get what is actually a configuration variable, by doing things like:
// Get a post by its route key (typically a slug)
$post = Post::query()
    ->where((new Post())->getRouteKeyName(), $mySlugThatCouldBeInRequestBodyOrQuery)
    ->firstOrFail();

This PR proposes treating route keys as being as important as primary keys, by introducing methods for querying by route key to the Eloquent Builder, modelled after the already existing methods for querying by primary key:

New method
Equivalent when querying by primary key

findByRouteKey
find

findByRouteKeyOrFail
findOrFail

findByRouteKeyOrNew
findOrNew

findByRouteKeyOr
findOr

findManyByRouteKey
findMany

whereRouteKey
whereKey

whereRouteKeyNot
whereKeyNot

Usefulness
A point could be made that since route keys are just that, keys to be used by the router, a need for manually querying by them outside of substituting bindings is not that stringent. However, I found myself needing this several times when developing applications.
For example, I like to keep consistency in the way I expose the identity of entities to consumers by only using route keys.
So, I use the route key both when referencing a certain seller for example in routes, like /api/sellers/{seller} , when referencing it in the body of a request (e.g create a new order section for a specific seller, where the sellerKey would be passed in the request body) and when referencing it from query parameters (api/products?filters[sellerKey]={seller})

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.


fix(e2e): Fix tests that expected that no org was been selected

Description
After some changed to Backend API, when creating an organization we set it as last active organization to the user that created the organization, the test's have been updated to match this behaviour.

Checklist

[ ] npm test runs as expected.
[ ] npm run build runs as expected.
[ ] (If applicable) JSDoc comments have been added or updated for any package exports
[ ] (If applicable) Documentation has been updated

Type of change

[ ] 🐛 Bug fix
[ ] 🌟 New feature
[ ] 🔨 Breaking change
[ ] 📖 Refactoring / dependency upgrade / documentation
[ ] other:

For future reference the internal ticket ID that caused this is ORGS-4


Rating to recipe

As a cook, I want to have a rating system so that I can see what meals are good or not.

test

@caiton1

@caiton1 whoop whoop

/reset

/reset

/new_user


« Content-Disposition : filename="filename.ext" » handling

Given the following
$ bat -download=true http://<IP_ADDRESS>:8080/3,0140231f47.jpg
HTTP/1.1 200 OK
Last-Modified : Thu, 29 Oct 2015 13:06:15 GMT
Date : Thu, 29 Oct 2015 13:33:31 GMT
Accept-Ranges : bytes
Content-Disposition : filename="dog-spoon-lobster.jpg"
Content-Length : 70059
Content-Type : image/jpeg
Etag : "d1ca1636"

Downloading to ""dog-spoon-lobster.jpg""
68.42 KB / 68.42 KB

The file resulting is literaly "dog-spoon-lobster.jpg" it should have been dog-spoon-lobster.jpg
$ ls -l
total 184
-rw-r--r-- 1 me users 70059 29 oct.  14:33 "dog-spoon-lobster.jpg"

It looks like Content-Disposition does not remove double quotes ?

I put together a simple python script to repro this. It's a simple http file server that forces the Content-Disposition header to be included.
# Download script from gist: https://gist.github.com/nicr9/d3d0a96f39c4ac7956dfad74b5b411c6
$ wget -O content_disposition.py https://gist.githubusercontent.com/nicr9/d3d0a96f39c4ac7956dfad74b5b411c6/raw/89eb60f547285fb7993cf61940a29e1d83bddc87/content_disposition.py

# Run file server in cwd
$ python content_disposition.py &

# Download server file
$ bat -download http://localhost:8000/content_disposition.py

# Check that the filename
$ ls -alF *.jpg*
-rw-rw-r-- 1 nic nic 450 Apr 29 21:47 "content_disposition.py"


Fix scaling of the buffer on macOS

Currently the size of the buffer on macOS is interpreted in logical pixels, which
is inconsistent with the other platforms. Instead,
we should apply the same scale factor that applies to regular rendering.
Fixes #22

Moving this to https://github.com/rust-windowing/swbuf/pull/6


(beta 2.0.0) Can't add to Plank Dock (again?) and icon is weird.

So I downloaded beta 2.0.0 and right off the bat the "Keep in Dock" option for my Plank Dock is not present. Again. I say again because when the app.html thing happened, the updates fixing that issue either wouldn't allow me to dock the app or would allow me to dock the app but with a duplicate icon. V 1.5.0 solved this issue entirely. However, if I attempt to go back to 1.5.0, the "Keep in Dock" option is not present. I tried many things, modified various files, and now opening 1.5.0 displays an njws error. I'm going to stay in v2.0 so that I can keep being up to date, and fix the docking issue right away.
I don't know if all this is a Plank problem, a problem with the app itself, or maybe a problem with Lubuntu (I'm using Lubuntu 16.04 64-Bit).
Now, the icon that appears in my Plank dock (which I can't keep) is way too low res, as it looks all blurry. On top of that, the icon is just the Whatsie icon, but colored blue.

Please, please fix the dock issue, as it has been bugging me for a little while now. Bring back the old icon as well, which was way prettier. And please also tell me if I'm complaining too much. Thanks.
Regards,
Frantik02

We're still working to fix all these annoying bugs.
I changed the icon to prevent any possible inquiries from Facebook. I want to make it even more obvious this is an unofficial app.

I see. The blue Whatsie icon doesn't really bother me, but it bugs me just a bit that it is low-res. I hope you can fix the docking issue soon. This is a great app, man. Cheers and thank you.

For the backport, you need to delete the cache folder (see the wiki).

Please try the latest version: https://github.com/aluxian/Messenger-for-Desktop/releases