text:
API feedback - Code splitting, co-location and verboseness

I hope a new issue is the right place to discuss this. I've seen parts of this discussed elsewhere, but I have a holistic take I wanted to note down and I didn't want to add noise to #15.
First of all, great job on this, I'm excited and really want this to succeed! 🎉 I've been using Redux in different apps for many years now and you are well on your way trying to solve a huge pain point here. I want to make it clear up front that I like a lot of the current API and even though the feedback is kind of "deep", I think it can be fixed with tweaks as opposed to bigger rewrites.
This feedback comes partly from having been involved in discussions around Redux lazy-loading, partly from having been tangentially involved in React Query and partly from my experiences as a long time consumer of Redux, though I do want to note I haven't used RTK extensively yet.
I have a few concerns, but I think a lot kind of centers around this from the docs:

With RTK Query, you usually define your entire API definition in one place

While allowing you to do that is certainly great, I think making this the default is a mistake that ignores previous pain points in Redux.
Before diving into details, these are my high level concerns:

Code splitting the users code should be the default (small library size doesn't really matter if this isn't in place since the effect of the library on userland code is usually a bigger problem)
The current API is more verbose than it should have to be (see above)
Co-location of data fetching code with where it is used is an important use case

I think these are more interrelated than it might seem at first glance and might have a common solution.
Background
As you know, how Redux is used has gone through quite a journey over the years and I'll try to keep this short since you already know this part, but it's still important for context.
In the beginning, it was popular to have separate files for reducers and actions, and selectors weren't even used by many. After a long time of that, the pains became visible to many. It was hard to get an overview and change stuff since things were spread out in multiple files. Many projects had a /redux folder where all this was kept, or top level /reducers and /actions folders. Among other things, this often meant that even when you removed some components no longer in use, stuff got left around. Also, this didn't lend itself very well to code splitting, so most Redux state was included in the main app bundle, even if it was huge and bloated.
The strength of the ducks pattern was the realization that separation of concerns is not the same as separation of reducers/actions/selectors but instead a single file containing all of these for some piece of functionality is a better kind of separation. An effect of this is that you can keep that file close to where it is actually being imported and used. When you do that, it's also easier and more obvious that you should code split the Redux-stuff with the rest of the code.
(As an aside, createSlice is a great evolution of this, but I'm a bit sad that there is still no first class built in way to code split it in RTK (as an aside-aside, I think it should even accept middleware and code split that too)).
All of this is more painful the larger the app becomes. In large applications, my experience is that it becomes unfeasible to have a top-down approach where you declare all reducers etc up front. This is not only because of code size, but also because as more teams becomes involved, good separation becomes more important.
Concerns

With RTK Query, you usually define your entire API definition in one place

Imagine if the Redux docs (2020) said:

With Redux, you usually define your entire state definition in one place

I'm being a bit hyperbolic here to make a point and make the link to the background above clear, but I do think this is problematic.
You did also note the following:

Our perspective is that it's much easier to keep track of how requests, cache invalidation, and general app configuration behave when they're all in one central location in comparison to having X number of custom hooks in different files throughout your application.

I think this is a balance and a scale between fully global and very local where the best tradeoff differs from app to app. APIs can have hundreds of endpoints in which case it becomes important that separate teams can own just parts of it and the app and change those without fear. Also, some APIs (or parts of APIs) might just be used on some pages (or for lazy loaded content below the fold on a page), in which case it makes no sense to load that code for all other pages or before it's needed.
Just consider the case of adoption. A huge audience for RTK Query is existing Redux apps that have not and might not want to migrate to RQ or SWR etc. A single team might want to try implementing RTK Query on their part of the site, what is the user journey for that currently? The docs currently recommend them to just create an API definition and include that at the top which adds both the RTK Query code and their userland code into the main bundle.
The DX of RTK Query is currently, in one aspect, kind of the opposite to React Query, SWR, Apollo, URQL etc. What I mean by this is that in those libraries, you usually first define the query you want to make inside the component that needs the data and you are ready to go. Later you lift it out of there to be reused elsewhere if needed, or if it just fits better in a separate file. If you squint, you can see similarities to why the ducks-pattern became popular. I see this as a bottom up approach.
RTK Query in contrast requires you to create an API-abstraction and include the reducer output from that into the store when you are creating it. Then you need to import the hooks generated and use those in the component. I see this as a top down approach. (You can code split the reducer if you bring your own solution for that, but you still need to inject that before using the query, so it's still top down for the developer and a lot of ritual to go through and figure out).
I think there are a lot of reasons the mentioned libraries have become popular, but I think a big reason is this bottom up approach and the lack of boilerplate. I think it's too hard to get started with RTK Query at the moment and I think it's too cumbersome to create a new query.
(As a separate question, why the verbose builder syntax is necessary?)
Suggestions
Note that these are naïve suggestions, without having looked very deep into the code base. These are not finished solutions, more like something to jolt discussion around alternatives. If you agree these are actual issues and not just differing opinions/philosophies, I'm sure you can come up with better solutions. 🙂
The goal here is to support something like this as the entire first setup needed:
import { createEndpoints } from '@rtk-incubator/rtk-query'

const { useGetPokemonByNameQuery } = createEndpoints({
  reducerPath: 'pokemonApi',
  endpoints: (builder) => ({
    getPokemonByName: builder.query({
      query: (name: string) => `https://pokeapi.co/api/v2/pokemon/${name}`,
    }),
  }),
});

export default function Pokemon() {
  const { data, error, isLoading } = useGetPokemonByNameQuery('bulbasaur');

  return 'Omitted';
}

In this example, the useGetPokemonByNameQuery detects that there is no API with the reducerPath:'pokemonApi' currently in the store. It creates a default API and injects that reducer and middleware into the store before making the query.
If you want API configuration, maybe something like this?
import { createApi, createEndpoints } from '@rtk-incubator/rtk-query'

// This part is probably created in a different file and reused:
const api = createApi({
  reducerPath: 'pokemonApi',
  baseQuery: fetchBaseQuery({ baseUrl: 'https://pokeapi.co/api/v2/' }),
});

const { useGetPokemonByNameQuery } = createEndpoints({
  api: api,
  endpoints: (builder) => ({
    getPokemonByName: builder.query({
      query: (name: string) => `pokemon/${name}`,
    }),
  }),
});

export default function Pokemon() {
  const { data, error, isLoading } = useGetPokemonByNameQuery('bulbasaur');

  return 'Omitted';
}

So how would we get here? Lets look at what a manual store setup would look like (also supported):
import { configureStore } from '@reduxjs/toolkit';
import { injectApi } from '@rtk-incubator/rtk-query';
import { pokemonApi } from './services/pokemon';

const store = configureStore(/* ... */);

injectApi(store, pokemonApi);

For this to work inside of React, something like a useInjectApi hook is needed that injects both the reducer and middleware, which probably means RTK should support lazy loading of these and RTK Query should use that abstraction.
This hook should only inject if needed and would be used inside of the generated hooks. Also, this hook would create a default API if one was not provided (the generated hook would provide reducerPath).
End
This is all very rough of course with lots of unsolveds, though I'm pretty certain something like it could be done. It would also allow for up front creation of APIs as outlined in the docs today. In essence, I think that by having something smaller than an "API" as a primitive and by finding some way for the useGeneratedQueryHook to inject the APIs/those primitives behind the scenes when necessary, these three could be solved with one stroke:

Code splitting
Terser API
Natural co-location of data fetching code when desired and at different granularity levels

yayyyy, long detailed and highly relevant user feedback!
uh... busy atm so I'll have to look through this later, but thank you very much for writing this :)

No worries, this is very much a wall of text and I fully expect it to take time to ingest and answer. 😄

(side note: I see you mentioned "code splitting in RTK". could you file a separate issue over in the RTK repo to discuss that and expand on your ideas?)

Sure thing! I remember us having a few good and very long threads about splitting back in v6, but I think this is both a better time and RTK a better place to implement it. 😄 I don't have time to get into the nitty gritty as much this time around, but should be able to write something up in the next few days. I'll find those old threads and PRs and link them in as well for context.

Thanks for your comments!
I'm trying to think about how this is a better solution than what is described in the code splitting docs. I honestly can't wrap my 🧠 around it.
Regarding the points about boilerplate, I don't exactly understand. If you're coming from a react-query mindset, here's a comparison: https://github.com/msutkowski/rtk-query-rq-custom-hooks-conversion/pull/1/files. It's actually less code than what you're asking for.
I'll think about this some more either way, and I'm sure @phryneas will have some feedback about any type of feasibility in regards to TS issues.

I think what you are looking for is kind of there in two variants:

You have the classical code splitting approach described in the docs, splitting one API into multiple files that can be lazy-loaded. An example for this can be found in this codesandbox
Having that createEndpoints method completely decoupled from the API as you are suggesting is not possible, if we want half-decent TypeScript support. There is just no way to create a "connection" between the two and validate or enrich stuff on a type level. So I believe we have found a pretty good compromise between type-safety and ease of use here.

The other approach would be just to inject multiple full apis, and there we are actually missing one key piece: late-injecting middlewares.
This is something on the list - something like a "collective" middleware you can just register all your apis in. But given that we already have the normal bundle-splitting so you could just inject multiple empty apis end enhance them later, it's not really a priority right now.

As for Apollo and urql: while these seem to have no prior setup required, once you get into the nitty-gritty details, you come very fast to a point where you have a LOT of bundle size to be provided up-front, like typePolicies and possibleTypes in Apollo (believe me, I run code generators for those because it's not feasible to write that by hand :facepalm:) and as far as I understand it, urqls TypeCache requires similar amounts of config.
But yes, generally this DX that feels opposed to SWR/React-Query is kind of a design target. The goal of RTK Query is not to take over the world and be the best solution for everyone, but to create something that Redux developers are more familiar with: a solution where the business logic is defined separate from the components - while still providing the ease of use in the components people love so much in SWR/React-Query.
Just creating a clone of React Query would not be of much benefit for everyone - providing options is though.
Still, I want to pick out some small things:

which adds both the RTK Query code and their userland code into the main bundle.

The RTK query code at the current moment is (once we have the new build for tree-shaking) about 4-5kb plus RTK & immer. The main bundle will contain both of these at the current state. All userland code can be lazy-loaded, apart from an almost-empty createApi call, so maybe another 50 bytes.

separate teams can own just parts of it

I'm viewing an API here not as the conglomerate of all APIs the application will ever talk to. But pretty much as one service. If it is one (micro)service, I would not want it to be split up, even - or especially - when multiple teams were using it. In the best case, you will have code duplication where overlap exists, in the worst case you will have duplicate code that slightly deviates between two different implementations and that does not get updated all the time, because it is littered around.
So if something is so much a "defined unit" as a service you are talking to: keep it in one central place. Maybe use the code splitting option to put it into multiple files (next to each other) for smaller bundle sizes, but still handle it as a unit. Something on the server changes? Exactly one place in your application to change.
Different (micro)service? Could be a good reason to define another api. Of course, you won't get automatic invalidation then, but usually that is not required over the borders of services and in the worst case a few manual invalidations can be added.

As a separate question, why the verbose builder syntax is necessary?

TypeScript support. Which you also benefit from as a JavaScript user if you use a modern IDE. Since those are repeated patterns, they are very compressable by the way ;)

I think it's too hard to get started with RTK Query at the moment and I think it's too cumbersome to create a new query.

As for "amount of code to write", ee already have a code generator from OpenAPI schemas finished in a first draft and will add code generators for graphql.
Realistically, the amount of setup should be somewhere between React-Query (instant, but if you don't have a clear concept of what you do, you'll end up with spaghetti code) and Apollo (which might take you hours to days if you also want to set up your editor & TypeScript code generation).
Also, adding a new endpoint is far less code than, say, writing a graphql query. ;)
Anyways, this answer might seem a bit chaotic, but I think I covered a lot and it is 1am here, so have a good night ;)

Thanks for your answers! 😍
I realize now that I'm a bit more awake myself that my main point got kind of muddled in that wall of text, so here it is hopefully formulated a bit clearer:

Code splitting should not be an afterthought or require extra work on the users part, it should be the default behavior.

In other words, I think if you code split a part of your application, data fetching logic only used in that part should be code split as well without extra work.
Everything else I wrote is details or secondary, and as I wrote the suggestions were included just for discussion around alternatives but I think they just muddled the point and problem description, so lets ignore those for now.
I'm not worried about the capabilities of the library, I can see that there are technically two different low level ways to code split currently even if some plumbing is work in progress (and having two ways might be confusing?). Entire APIs can be injected into the store after store creation and endpoints can be injected into APIs after API creation. I think these are still lacking high level polish and ease of use though, mainly because it's also missing from RTK.
This criticism can just as well be applied to (React-)Redux, or to RTK of course and I'll open an issue there, but I'm pointing it out here because this is a new library that I think has the opportunity to create better defaults.
Every Redux app I've worked with, I've had to help create lazy loading abstractions for and refactor to that. Huge parts of the main bundle has consisted of Redux code only used in certain parts of the application. This has been cumbersome and time consuming work not unique to these applications, and I think defaulting to putting stuff in the main bundle unless the developer figures out the pretty complex area of lazy loading in Redux and does extra work to implement that is not a good default. Figuring out lazy loading with SSR is especially complex btw.
When I read it again I think most of the rest of the wall of text was just a long way of saying that for any solution to this problem you can come up with, I think there can be positive spin off effects on the API. 😄

@Ephem I think it would be really helpful to see some examples of those "lazy loading abstractions", and descriptions of what use cases they're trying to handle.

I think it would be really helpful to see some examples of those "lazy loading abstractions", and descriptions of what use cases they're trying to handle.

I'm glad you're trying to guide me to make things clearer! If we are talking about RTK Query specifically, this is what I tried to provide under suggestions in the original post. injectApi would be the imperative function and useInjectApi would be the hooks-version. The goal of those suggestions however was to hide needing to call either explicitly in most cases, instead automatically doing that for the user in the useGeneratedQueryHooks. On a higher level, I think the key would be to:

Not ever include include the reducers or middlewares on store creation, enhance the store after instead (you can enhance the store right after creation and not have code splitting of course, but docs should steer away from that)
Make it easy, or even better automatic to enhance the store with the specific endpoints used when and where they are used

As for use case, consider this:
import { useSomeQuery } from './api';

function SomeComponent() {
  const { data } = useSomeQuery();

  return 'Omitted';
}

Imagine useSomeQuery is only used in this component, the following is problematic in the current default approach (up front definition):

useSomeQuery is included in the main bundle, even if SomeComponent is lazy
If we remove SomeComponent or remove the usage of useSomeQuery from that without removing the code for useSomeQuery itself, useSomeQuery is not dead code eliminated and stays in the bundle indefinitely

Wiring up the bits needed inside of Redux for an endpoint to work should by default and transparently to the user happen lazily when needed, not eagerly. This would allow at least 1. to be solved by default and without extra work on the users part. Remove an import, that API is no longer a part of the bundle. Import an API in a lazy loaded component, the build tool takes care of determining what/which bundles to include that code.
Nr 2. is trickier since endpoints are currently part of a bigger API-structure. Maybe this is necessary for other stuff to work well in which case I could live with that, 1. is the most important one.

So, just to reiterate this:
At the current moment, you can, if you really insist on doing so, even declare new endpoints in your component file, which - as long as that component file itself is properly code-split - will not require any additional code-splitting magic:
For everyone reading this, please reconsider actually doing so!
Not everything that is possible is good style and this library is written with the mindset of having your API definition in one place.
You might be more happy with another library?
import { api } from 'src/api';

const { useGetPostsQuery } = api.injectEndpoints({
  endpoints: build => ({
    getPosts: build.query({
      query: () => 'posts',
      provides: (result) => result.map(({ id }) => ({ type: 'Posts', id })),
    }),
  }),
});

function MyComponent() {
  const result = useGetPostsQuery();
  return <div>...</div>
}

As I actively discourage the approach presented above, this is what I recommend doing instead:

Put a file posts.js adjacent to the file where you configured your api in the first place.

import { api } from './api';

export const { useGetPostsQuery } = api.injectEndpoints({
  endpoints: build => ({
    getPosts: build.query({
      query: () => 'posts',
      provides: (result) => result.map(({ id }) => ({ type: 'Posts', id })),
    }),
  }),
});

And in your code-split component, import this hook:

import { useGetPostsQuery } from 'src/api/posts';

function MyComponent() {
  const result = useGetPostsQuery();
  return <div>...</div>
}

Again, in that case: the code will be properly split into bundles and only loaded when it is imported by your bundle.

Apart from that: Yes, you have to put your api into your store. Another point of this library is that it is simply a wrapper around plain RTK, no additional magic.
If there will be a "default" way to inject reducers and/or middlewares into your Redux store after the fact, that will be invented over in RTK, not here.
One additional thing:

and having two ways might be confusing?

See it this way: All your api is served from example.com/pet-store-api? That is one Api and should be handled as one.
Do you have data that is served from amazon.com/users, github.com/posts and another graphql endpoint over at facebook.com? Those are three different APIs and handling them as one will only hurt you down the line.

I think the two of you are talking past each other a bit, as far as I can tell :)
Part of Fredrik's point is that there is no built-in way to handle the "re-combine reducers and replace reducer" dance that's typically used for code-splitting slice reducers, and that something like that really ought to be in RTK so that there's at least a baseline implementation people don't have to keep re-inventing.
@ephem fwiw, I was actually asking more for examples of non-RTKQ Redux-related code-splitting that you've done in other apps, although that might be better suited for the issue over in RTK itself.
I think for both of you, it would probably be good to have a couple working examples demonstrating A) what actual problems may still exist with code-splitting in RTKQ atm, and B) how code-splitting does actually work atm.

Oh, I started my answer before @Ephem wrote his last post ;)
But generally: that's why I added the

If there will be a "default" way to inject reducers and/or middlewares into your Redux store after the fact, that will be invented over in RTK, not here.

We can discuss that over there if you want to & have good suggestions - discussing the "injecting stuff into the redux store" itself is out of scope for this repository.
So let's keep the "RTKQ Code-Splitting" discussion here and the "RTK Code-Splitting" discussion there, okay?

Yeah, I reeally wish I hadn't mixed in co-location in this discussion, that's not the main point. 😄 Also, as I stated, I don't worry about what is possible to do when it comes to code splitting, I worry about what patterns are the default and encouraged when it comes to code splitting.

So let's keep the "RTKQ Code-Splitting" discussion here and the "RTK Code-Splitting" discussion there, okay?

Totally agree and this is what I've been trying to do, though they are intermingled of course. I'll open an issue there when I get some time to formulate it better than I did this one.. 😓 That said, even if there is a default way to code split in RTK, that is different from RTK Query doing code splitting by default which is what I'm arguing is important here.

doing code splitting by default which is what I'm arguing is important here.

If by that you mean a pattern of declaring endpoints in different files by default, without having a central definition - that's simple: that just won't happen.
It is not possible to create that with even remotely safe TypeScript. Which is something I'm not willing to sacrifice.
There are explicit relationships here:

the return value of a queryDefinition's query function is the input to the baseQuery
the return value of baseQuery is the input value to transformResponse
provides/invalidates is heavily linked to entityTypes
api.util.updateQueryResult/prefetchThunk is linked to all query definitions

All that will either be 100% type-checked (it is right now) or completely loose if you disconnect it.
As an example:
Right now, you can define three hooks with the same API key and completely different types in libraries like SWR or React-Query. This will definitely cause a bug, as those queries will override each other's cache, so 2/3 of your code will use the wrong types at any given time.
Nobody will stop you from doing that, and frankly, they can't. Because they are disconnected. I do not want to repeat that mistake.
Also, I will argue that "code splitting by default" is required for everyone and that it is too urgent a requirement. This is an advanced use case many people will just not care about.
As an example: This file defines 19 endpoints and is probably more than enough for a small to mid-size application. Transpiled and gzipped, that comes down to 657 bytes. Assuming that your application also ships with at least one jpeg, it just doesn't matter where those bytes are.

This is an advanced use case many people will just not care about.

Exactly, you are making this an advanced use case (I think it shouldn't be), so people won't care about it. I think this is a mistake, you don't and I respect that. You are designing the API and have a vision and more context for what you are trying to achieve and the tradeoffs. 😄
Thanks for listening! 🌹

authors: Ephem markerikson msutkowski phryneas

repo: rtk-incubator/rtk-query


text:
Org map to svg file

Changes

Lgtm!

source: gharchive/pull-request

repo: rubberdok/indok-web

license: MIT

license_type: permissive

license_source: github-api


text:
Replace specific mention of LDAP

It's unlikely that we'll have a public LDAP service, so replace the
mention of Rubin Observatory LDAP in section 3.2 with a more general
reference to a Rubin Observatory authorization service.

@womullan you're going to merge the PR as neither Russ nor I have write access to this repo

authors: frossie rra


text:
Default config does not respect Department Exclude

(not sure if this belongs to rubocop-rspec or rubocop)
Description:
rubocop-rspec default Exclude option does not respect project's RSpec/ department Exclude
e.g. for the cop RSpec/BeforeAfterAll, Exclude is defined here
https://github.com/rubocop/rubocop-rspec/blob/b814f81f529adb684171e5ef6380ce49b9207a0d/config/default.yml#L124-L127
When we define a departmental exclude in a new .rubocop.yml in a project:
RSpec:
  Exclude:
    - foo_spec.rb

foo_spec.rb will be overriden, and RSpec/BeforeAfterAll will be fired on this file.
Expected:
As a user, I would not want a default cop-specific exclude to override my project's department-wide settings.

Additional notes:
I have made an example repository demonstrating what happened.
GH Action failed after excluding the file in RSpec department configuration on .rubocop_department_exclude.yml but not when excluding it on a specific cop configuration.
Here is the department exclude that is not respected:
https://github.com/dswij/rubocop-rspec-exclude-example/blob/97eb80b3ad271769baf17693657b84c3d3f2ef94/.rubocop_department_exclude.yml

@koic @bbatsov @jonas054 Can you please transfer this to rubocop?
I don't think there's anything we can do on rubocop-rspec side.

@dswij Do you mind closing this and opening the same ticket against RuboCop itself?

Closing as there's nothing we can do on our side.

source: gharchive/issue

authors: dswij pirj

repo: rubocop/rubocop-rspec


text:
Autocorrect vs auto-correct

~/code/rubocop$ grep -iro "autocorrect" . | wc -l
    1971
~/code/rubocop$ grep -iro "auto-correct" . | wc -l
    1551

Both autocorrect and auto-correct are used frequently in RuboCop. Should we be consistent? If so, which one?
Any change should only affect comments and other string content, not method names.

I've been thinking about this myself at some point. I like "auto-correct" better, as it's easier to read, but I assume many people prefer "autocorrect" as it's easier to write. :D According to the dictionaries "autocorrect" is the right spelling, so I guess we should stick to it. (https://www.dictionary.com/browse/autocorrect)

Btw, I've noticed that we're using --auto-correct in the cmdline options, which means the change is going to be a bit more involved, as we'll also have to deprecate those. Anyways, not a big deal.

authors: bbatsov dvandersluis

repo: rubocop/rubocop


text:
New cop idea: Use Comparable#clamp, Array#{min,max} instead of comparison operators

Is your feature request related to a problem? Please describe.
Today I suggested using Comparable#clamp instead of comparison operators in a private project, like the following.
# bad - I feel it's not readable...
user_input > threshold ? threshold : user_input

# good - I can imagine the intention of this code easily!
user_input.clamp(..threshold)

I think RuboCop can aid with this problem, but there is no cop to detect this problem.
Describe the solution you'd like
Add a cop to detect the comparison operators' usage. The cop suggests user_input.clamp(..threshold) instead of comparison operators.
Array#min
The following code has the same meaning as the above example also.
[user_input, threshold].min

Which of these is appropriate depends on the situation. If one of the values is a threshold, clamp clarifies the intention. But if both values are user inputs, min is better than clamp.
# It's good
[user_input_a, user_input_b].min

# It's strange...
user_input_a.clamp(..user_input_b)

Therefore I think the cop should suggest both min and clamp.
Array#max and a.clamp(x..y)
By the way, the cop can detect cases for Array#max and clamp(lower_threshold..upper_threhold) (or clamp(lower_threshold, upper_threhold)).
Describe alternatives you've considered
nothing
Additional context
There are performance differences between comparison operators, clamp, and min.
require 'benchmark/ips'

require 'benchmark'
Benchmark.ips do |x|
  a = 42
  b = 43

  x.report('ops') { a > b ? b : a }
  x.report('min') { [a, b].min }
  x.report('clamp') { a.clamp(..b) }

  x.compare!
end

$ ruby -v rubocop-clamp-min-performance.rb
ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin21]
Warming up --------------------------------------
                 ops     2.035M i/100ms
                 min     2.203M i/100ms
               clamp   879.718k i/100ms
Calculating -------------------------------------
                 ops     20.230M (± 1.4%) i/s -    101.765M in   5.031438s
                 min     21.694M (± 1.5%) i/s -    110.157M in   5.078819s
               clamp      8.694M (± 1.9%) i/s -     43.986M in   5.060963s

Comparison:
                 min: 21694180.2 i/s
                 ops: 20229721.8 i/s - 1.07x  (± 0.00) slower
               clamp:  8694430.4 i/s - 2.50x  (± 0.00) slower

Operators and min have almost the same speed because the VM executes min with an Array literal as an optimized instruction (opt_newarray_min).
$ ruby --dump=insns -e '[a,b].min'
== disasm: #<ISeq:<main>@-e:1 (1,0)-(1,9)> (catch: false)
0000 putself                                                          (   1)[Li]
0001 opt_send_without_block                 <calldata!mid:a, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0003 putself
0004 opt_send_without_block                 <calldata!mid:b, argc:0, FCALL|VCALL|ARGS_SIMPLE>
0006 opt_newarray_min                       2
0008 leave

I think this difference does not affect the entire application's performance. Probably it's a good idea that the document mention the performance.

Is the readability of Comparable#clamp better in this case? So I wonder about the replacement to Comparable#clamp.
Background:

RuboCop can parse Ruby 2.0 and above
Comparable#clamp was introduced in Ruby 2.4
Comparable#clamp introduced accepting Range as an argument in Ruby 2.7
Beginless range was introduced in Ruby 2.7

So, in terms of readability, replacing the > and < operators with min and max seems more appropriate than clamp.
Comparable#clamp is may useful for comparisons in nested arrays:
https://andycroll.com/ruby/clamp-for-min-max-values/
What do you think?

my 2¢ -- #clamp() seems more natural when it has two limits. A substitution strategy like this would make sense to me:

original
replacement

a > b ? a : b
[a, b].max

a < b ? a : b
[a, b].min

[[x, low].max, high].min
x.clamp(low, high)

Thanks for your comments, @koic and @vlad-pisanov!
Personally I like clamp to round a value with a max or min limit, even if it takes only either max or min. But I can easily imagine your opinion, min or max are preferred for this purpose.
I prefer the following replacements.

original
replacement

a > b ? a : b
[a, b].max or a.clamp(b..) (depend on context)

a < b ? a : b
[a, b].min or a.clamp(..b) (depend on context)

[[x, low].max, high].min
x.clamp(low, high)

I guess we have three options for a > b ? a : b and a < b ? a : b.

Suggest Array#max or Array#min always

@koic and @vlad-pisanov perfer

Suggest (Array#max or Array#min) and Comparable#clamp

@pocke prefer
Because I'd like to use both depending on the context

Suggest Comparable#clamp always

I'm not sure anyone prefers it...

By the way, this cop should be marked as Safe: false. Because even if a value has < method, it's not necessarily Comparable.

Because I'd like to use both depending on the context

Hm, are there any use cases where you prefer a.clamp(b..)  over [a, b].max?

There is still consider about Comparable#clamp. On the other hand, it seems common to prefer [a, b].max to a > b ? a : b.
First, I opened PR #11341 to create a cop that enforces [a, b].max. Because I think it's better to have a separate cop for Comparable#clamp. This is because the different Ruby versions that can be targeted.

Because I'd like to use both depending on the context

Hm, are there any use cases where you prefer a.clamp(b..) over [a, b].max?

Ah, sorry, I forgot to describe the context. I think clamp is more appropriate if one of the values is a limit or threshold.
For example: Limit per page on pagination
MAX_ITEMS_PER_PAGE = 100

def index
  raw_per_page = params[:per_page].to_i

  # With `clamp`
  per_page = raw_per_page.clamp(..MAX_ITEMS_PER_PAGE)

  # With `min`
  per_page = [raw_per_page, MAX_ITEMS_PER_PAGE].min

  @items = Item.all.per_page(per_page)
end

min means "Pick out minimum count from raw_per_page and MAX_ITEMS_PER_PAGE".
clamp means "Limit raw_per_page to MAX_ITEMS_PER_PAGE".
In this case, I prefer clamp to min because I feel clamp is more intentional. min just means minimum value, but clamp expresses that the argument is a limit value.

Because I think it's better to have a separate cop for Comparable#clamp. This is because the different Ruby versions that can be targeted.

Well, if a.clamp(..b) case is also acceptable, two cops warn the same code with different messages, right?
For example, for per_page = per_page > MAX_ITEMS_PER_PAGE ? MAX_ITEMS_PER_PAGE : per_page, Style/MinMaxComparison cop suggests using min, but Style/ClampComparison cop suggests using clamp.
It may be confusing.

Thanks for explaining your use case.
I wonder if it may be a bit difficult for user to choose whether to use {min, max} or clamp. So, I think it would be clear to user to provide autocorrection for {min, max}. {min, max} are traditional simple methods.
And I'm also concerned about the slowness of clamp. Maybe only documented for clamp against # good case and text in #11341.
So the next steps are:

Add documentation about clamp to #11343
Provides a new cop proposing x.clamp(low, high) instead of [[x, low].max, high].min. It's a different police than #11341

It may be confusing.

This probably won't cause that confusion. OTOH, the only my concern is that {min, max} is chosen for use cases where clamp is preferable, but user can refactor it to clamp userself.
What do you think of this design, which is different from the original intention of the issue?

So the next steps are:

It looks good, thanks for your suggestion!

OTOH, the only my concern is that {min, max} is chosen for use cases where clamp is preferable, but user can refactor it to clamp userself.

I think so too. The user maybe doesn't notice the existence of clamp. I think your suggestion is a good compromise 👍

And I'm also concerned about the slowness of clamp.

min and max are also slower than the operators on old Rubies.
$ docker run --rm -it rubylang/all-ruby env ALL_RUBY_BINS='ruby-2.0.0-p648 ruby-2.1.10 ruby-2.2.10 ruby-2.3.8 ruby-2.4.10 ruby-2.5.9 ruby-2.6.10 ruby-2.7.7 ruby-3.0.5 ruby-3.1.3 ruby-3.2.0' ./all-ruby -rbenchmark -we 'a=42;b=43;p Benchmark.realtime{100000.times{[a,b].min}}; p Benchmark.realtime{100000.times{a > b ? b : a}}'
ruby-2.0.0-p648 0.195302542
                0.035441417
ruby-2.1.10     0.175730625
                0.035914958
ruby-2.2.10     0.194358040811494
                0.04013233305886388
ruby-2.3.8      0.18656654190272093
                0.035134333884343505
ruby-2.4.10     0.03193425014615059
                0.03173887496814132
ruby-2.5.9      0.03606400010176003
                0.03370579099282622
ruby-2.6.10     0.03306250018067658
                0.028806084068492055
ruby-2.7.7      0.030842124950140715
                0.02505087503232062
ruby-3.0.5      0.03810958401300013
                0.02866741712205112
ruby-3.1.3      0.04034850001335144
                0.03262170893140137
ruby-3.2.0      0.028015041025355458
                0.027625084156170487

min is slower than the operators on Ruby 2.3 or older. Should we treat this difference on the cop's implementation?
I guess it does not affect the performance of an entire application in most cases. It's enough that the documentation mentions the performance.

min and max are also slower than the operators on old Rubies.

Hm, I think it depends on the operands. For example, a > b ? a : b evaluates to either a or b twice. So if a or b is a slow method call, I think max is better. In other words, the results may change depending on the benchmark data or usage context, right?

min and max are also slower than the operators on old Rubies.

Hm, I think it depends on the operands. For example, a > b ? a : b evaluates to either a or b twice. So if a or b is a slow method call, I think max is better. In other words, the results may change depending on the benchmark data or usage context, right?

True. The summary is the following:

Replacing min has a performance risk until Ruby 2.4 because it doesn't have the optimized instruction.

OTOH, it may improve the performance as you said.

Replacing min has no performance risk since Ruby 2.4 because it has the optimized instruction.

It also may improve the performance as you said.

I'm not sure the document should describe the performance. It will be helpful to decide to follow the cop. But it may too detailed.

JFYI, this issue is solved by #11341, #11364, and #11365.

authors: koic pocke vlad-pisanov


text:
Calling .[] with wrongly indented args doesn't register violation

Expected behavior
Example 1
# frozen_string_literal: true

module Services
  module Internal
    # Publisher
    class PostPublisher
      def call(post)
        proc = ->(arg) { call(arg) }

        proc[
post
      ]
      end
    end
  end
end

I would expect this be a Rubocop violation, and autocorrect would align the post to one level deeper than the start of proc (And also make sure the ending bracket is the same level of indentation as proc.)
Example 2
dry-auto_inject & dry-system uses a special syntax to import dependencies: include Import["my_service"]. On a single line, this is no problem, but when separating onto several lines, Rubocop doesn't care about the indentation level of the args at all.
# frozen_string_literal: true

require 'system/container'
Import = Application.injector

require 'import'
module Services
  module Internal
    # Publisher
    class PostPublisher
      include Import[
  'logger',  # indentation here is way off but rubocop doesn't complain
  'external_service',
  repo: 'post_repository',
      ]
      # ...
    end
  end
end

I would expect this be a Rubocop violation, and autocorrect would align the 'logger', 'external_service' and repo: 'post_repository' lines to one level deeper than where the include starts.
Actual behavior
No violations. I can change the indentation level to 0 or 20 and Rubocop doesn't care. Rubocop does catch if they're not all the same, but it doesn't care about its indentation relative to what it's called on. It also doesn't care where the closing ] is indented to.
For /Users/sean/oss/rubocop_demo: Default configuration from /Users/sean/.asdf/installs/ruby/3.3.3/lib/ruby/gems/3.3.0/gems/rubocop-1.65.0/config/default.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/sean/oss/rubocop_demo/demo.rb
.

1 file inspected, no offenses detected

Notes
I guess this can be fixed by making the Layout/*Indentation* cops smarter, since the [] is a method call.
Steps to reproduce the problem
rubocop demo.rb (if above is demo.rb)
RuboCop version
Include the output of rubocop -V or bundle exec rubocop -V if using Bundler.
If you see extension cop versions (e.g. rubocop-performance, rubocop-rspec, and others)
output by rubocop -V, include them as well. Here's an example:
> rubocop -V
1.65.0 (using Parser 3.3.4.0, rubocop-ast 1.31.3, running on ruby 3.3.3) [arm64-darwin23]

Updated this with a more generic example (as Example 1), which deals with procs being called with []

This seems to be working as expected (please see tests added in #13563).
If you are using EnforcedStyle: with_first_argument for Layout/ArgumentAlignment, all that is enforced is that all the arguments are aligned with each other, which is the case in your example. If you'd like them to be aligned relative to the method call, use EnforcedStyle: with_fixed_indentation.
I'm going to close this as I don't see any bugs, but feel free to comment or open a new issue if I'm overlooking something.

authors: cllns dvandersluis


text:
Support TargetRubyVersion 3.2 (experimental)

RuboCop AST 1.6 supports Ruby 3.2.
https://github.com/rubocop/rubocop-ast/pull/223.
This PR supports TargetRubyVersion 3.2.

Before submitting the PR make sure the following are checked:

[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
[x] Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

Thanks!

authors: bbatsov koic


text:
Proposal: Report relative paths to VS Code to support remote debugging

Your proposal
rdbg reports absolute file paths to files on disk to VS Code. If rdbg had an option to report file paths relative to a specific root directory, then it could support remote debugging in VS Code across multiple machines.
Additional context
In our remote debugging setup, VS Code runs on one machine, but the process being debugged is on a second machine. Both computers have the same source tree, but at different absolute file paths.

Sorry I couldn't understand your proposal.
Understood:

You have two machines, which have same src tree but different absolute path.
For VSCode integration (DAP support) we use absolute path.

Couldn't understand:

VSCode support remote login and it mounts remote directory. How to use the absolute path from rdbg on other (host?) machine?

You have two machines, which have same src tree but different absolute path.

Correct!

VSCode support remote login and it mounts remote directory. How to use the absolute path from rdbg on other (host?) machine?

We are not using VS Code's remote login support. We need rdbg to report relative paths so that they resolve on the machine running VS Code.
I hope that makes things clearer!

I might be able to contribute this feature if you feel OK with it.

Sorry I couldn't understand yet.
Assume
(1) machine M1 has src tree.
(2) machine M2 also has src tree.
Q1. Where do you want to run the VSCode and rdbg?
Q2. Now VSCode integration using UNIX Domain socket and it can not connect to the different macine (ex: M1 -> M2). How to connect it?

👋 I work with jvilk at Stripe, so I can help answer some of these question for him:

Q1. Where do you want to run the VSCode and rdbg?

VS Code is open on a laptop, editing local files on the laptop (in our case, running macOS). VS Code is not using built-in remote development support. The files being edited have paths like /Users/jez/stripe/pay-server/...
When edits happen to files open in VS Code, they get saved to the local (laptop) file system. An custom script running watchman and rsyncwill notice file changes and send the new files to a remote development machine (in our case, running Ubuntu). It will sync the files to a folder like/pay/src/pay-server/...`
Meanwhile, rdbg will be running the code on the remote development machine. The file contents will be the same as those on the laptop, but the files will have different absolute paths.

Q2. Now VSCode integration using UNIX Domain socket and it can not connect to the different macine (ex: M1 -> M2). How to connect it?

The plan is to use TCP/IP to connect to it. The rdbg process will bind to a port on the remote linux machine, and we will connect to it like jez-dev-machine.<stripe-intranet-domain>:$RUBY_DEBUG_PORT. It's secure because the <stripe-intranet-domain> is not available to the public internet—we have a custom proxy server that will allow connecting directly to the TCP port on the remote linux machine from the macOS laptop over TCP.
Basically, to rdbg's eyes, it looks the same as if it were bound to localhost on the linux remote development machine. The only problem is that it has to work with relative paths like lib/foo.rb when setting breakpoints, instead of absolute paths.
Please let me know if that helps clear things up, or if it makes it more confusing.

Ok, I understand the situation.
There are several points the full-path shows.

DAP event

Caused exception in Ruby

Do you want to solve case 1?

Yes I believe that the DAP event case is what we care about.

All right. It's clear. We can support by debug.gem or vscode-rdbg (maybe), let me take a time to consider about it.

Thanks! If there’s anything I can ever help answer, or you’d like us to test something out, please don’t hesitate to @mention me.

All right. It's clear. We can support by debug.gem or vscode-rdbg (maybe), let me take a time to consider about it.

here is the (start of) vscode-rdbg solution: https://github.com/ruby/vscode-rdbg/pull/42

+1 This is important for teams using VSCode and Docker setups too.

We are running into the inability to use the official debugger running in Docker in tandem with VSCode due to this path resolution issue. We're currently tracking @firien 's implementation but would not be opposed to an upstream fix in the Gem if possible, either.  =]

authors: booleanbetrayal firien jez jvilk-stripe ko1 mbsmartee

repo: ruby/debug


text:
[perf] Historical cache job is taking over 5 minutes.  This seems excessive.

Summary
The job that creates the cache for the historical trends graphs is regularly taking well over 5 minutes.   Tune it so it isn't.
Details
The job in question is found at lib/tasks/cache_historical_data.rake    Figure out what is causing the slowness, and address it.  I suggest benchmarking it first, so you can demonstrate that it has sped up, because the amount of data on local is much smaller.
We're pretty sure this is largely a matter of query optimization / making fewer queries.
Other info
I think this is using redis on production, though not on staging or dev
Criteria for completion
-[ ] The job runs faster
-[ ] All the current tests around historical data still pass.

🙋🏻♂ I'd like to take a crack at this

Go for it!

@isidzukuri not sure what happened here... was this issue assigned to you before?

@dorner i started to looking into when it was unassigned. phonghpham picked it up. Than ive created PR few minutes after. I didn't say that i will work on it. It created confusion. https://github.com/rubyforgood/human-essentials/pull/4121 can be rejected, it won't upset me

@phonghpham thoughts? The PR is already up, do you want to hand it off or try a different approach?

@dorner , @isidzukuri , i took a slightly different tack and addressed the N+1 issue with preloading and handled aggregation at ruby level, but doing the aggregation of line_items all in single query is probably going to be more performant as the approach i took will still result in additional query for the includes to fetch line_items. Dealer's choice!

@isidzukuri: @phonghpham 's solution is slightly faster, and I also feel like it's a bit cleaner because it doesn't try to mix values and totals in the same hash. OK to close yours and focus on that one?

to make the experiment more scientific let's run benchmark on the same machine:
2 items with 10 line_items phonghpham:4116-historical-cache-job-issue:
  0.005795   0.000000   0.005795 (  0.006698)
  0.002803   0.000000   0.002803 (  0.003757)
  0.002886   0.000000   0.002886 (  0.003799)
  0.002734   0.000000   0.002734 (  0.003278)
  0.004008   0.000000   0.004008 (  0.005314)
  0.002632   0.000000   0.002632 (  0.003246)
  0.000074   0.002679   0.002753 (  0.003707)
  0.002718   0.000000   0.002718 (  0.003381)
  0.003394   0.000000   0.003394 (  0.004389)
  0.002641   0.000000   0.002641 (  0.003555)

2 items with 10 line_items isidzukuri:4116_tune_historical_cache_job
  0.005494   0.000350   0.005844 (  0.007407)
  0.002570   0.000000   0.002570 (  0.003229)
  0.002266   0.000000   0.002266 (  0.002927)
  0.002343   0.000000   0.002343 (  0.003012)
  0.003048   0.000000   0.003048 (  0.003626)
  0.002801   0.000000   0.002801 (  0.003434)
  0.003016   0.000000   0.003016 (  0.003713)
  0.002220   0.000000   0.002220 (  0.002784)
  0.003093   0.000000   0.003093 (  0.003751)
  0.002990   0.000000   0.002990 (  0.003560)

#########################################################################

100 items with 10 line_items
  100 items with 10 line_items phonghpham:4116-historical-cache-job-issue
  0.060800   0.004141   0.064941 (  0.105788)
  0.076584   0.000199   0.076783 (  0.113180)
  0.074910   0.000000   0.074910 (  0.110090)
  0.067650   0.000073   0.067723 (  0.108604)
  0.066736   0.000427   0.067163 (  0.102943)
  0.067041   0.000001   0.067042 (  0.101563)
  0.092875   0.000251   0.093126 (  0.131682)
  0.082340   0.000399   0.082739 (  0.117478)
  0.066077   0.000000   0.066077 (  0.102329)
  0.062868   0.000322   0.063190 (  0.098498)

100 items with 10 line_items isidzukuri:4116_tune_historical_cache_job
  0.040786   0.000000   0.040786 (  0.077770)
  0.031690   0.000000   0.031690 (  0.073534)
  0.026976   0.000000   0.026976 (  0.064940)
  0.026619   0.000000   0.026619 (  0.061805)
  0.036582   0.000000   0.036582 (  0.071233)
  0.037792   0.000000   0.037792 (  0.077403)
  0.028354   0.000092   0.028446 (  0.064191)
  0.028481   0.000107   0.028588 (  0.064373)
  0.029115   0.000000   0.029115 (  0.068713)
  0.028534   0.003777   0.032311 (  0.070685)

looks cleaner - yes.
im OK with closing

actually on 1000 items with 10 line_items phonghpham`solution is faster. It was unexpected for me 😅
I tried to understand why. Profiling results ruby-proof:
1000 items with 10 line_items phonghpham:4116-historical-cache-job-issue profile:

%self      total      self      wait     child     calls  name
 36.36      2.409     2.409     0.000     0.000        1   PG::Connection#exec_params
  4.91      0.325     0.325     0.000     0.000    23036   Class#allocate
  2.80      0.288     0.186     0.000     0.102    11012   Hash#transform_values
  2.70      0.303     0.179     0.000     0.124    12015   ActiveRecord::Associations::JoinDependency::JoinPart#extract_record
  2.61      0.193     0.173     0.000     0.020   541266   Hash#[]
  2.40      3.860     0.159     0.000     3.700    23122  *Array#each
  1.50      0.482     0.099     0.000     0.382   108331  *Hash#fetch
  1.18      0.078     0.078     0.000     0.000   391527   Integer#+
  1.17      0.077     0.077     0.000     0.000   380574   Array#[]
  1.10      0.357     0.073     0.000     0.284    35044   ActiveRecord::Associations#association

1000 items with 10 line_items isidzukuri:4116_tune_historical_cache_job profile:

 %self      total      self      wait     child     calls  name
 88.10     14.229    14.229     0.000     0.000       12   PG::Connection#exec_params
  0.61      1.676     0.098     0.000     1.578    22495  *Array#each
  0.56      0.271     0.090     0.000     0.181    33000   ActiveModel::LazyAttributeSet#default_attribute
  0.55      0.137     0.088     0.000     0.049   147040  *Hash#fetch
  0.39      0.064     0.063     0.000     0.000   227013   Hash#[]
  0.38      0.440     0.061     0.000     0.379    56004   ActiveModel::LazyAttributeSet#fetch_value
  0.34      0.445     0.055     0.000     0.390    33000   ActiveModel::LazyAttributeSet#key?
  0.30      0.897     0.048     0.000     0.849    22000   ActiveModel::AttributeMethods#method_missing
  0.29      0.349     0.047     0.000     0.303    33000   ActiveModel::AttributeSet#[]
  0.28      0.053     0.045     0.000     0.008    33029   ActiveModel::Attribute#initialize

1000 items with 10 line_items raw sql via `ActiveRecord::Base.connection.execute(sql)`

%self      total      self      wait     child     calls  name
 80.16      2.290     2.290     0.000     0.000        1   PG::Connection#async_exec
  6.62      0.189     0.189     0.000     0.000    50062   String#inspect
  3.57      0.102     0.102     0.000     0.000    10014   IO#write
  3.51      0.426     0.100     0.000     0.325    10012   Hash#to_s
  2.42      0.074     0.069     0.000     0.005    10012   Time#inspect
  2.17      0.062     0.062     0.000     0.000    20026   Integer#inspect
  0.89      0.553     0.026     0.000     0.528        1   IO#puts
  0.27      0.008     0.008     0.000     0.000        1   PG::Result#each
  0.19      0.005     0.005     0.000     0.000    10012   Integer#round
  0.03      0.001     0.001     0.000     0.000        2   Kernel#caller
  0.01      0.000     0.000     0.000     0.000        1   PG::Connection#exec_prepared

i guess PG::Connection#exec_params  makes the difference, in isidzukuri 12 calls vs 1 in phonghpham. I suppose thanks to ome ActiveRecord optimizations.
However raw query should be faster than anything else. Why? Because it makes exactly one query which does not go thru all ActiveRecord`s magic, it returns only required data and saves bandwidth, and after all is not mapped into model object

i see in isudzukuri this line generates 12 PG::Connection#exec_params calls
https://github.com/rubyforgood/human-essentials/pull/4121/files#diff-df9a1e011625864a7c7ef056ca7115a966808f9c82f8dce705acb121c450b7fdR12

this benchmark(on my machine) makes me think that find_each performs better with higher quantity of rows despite on more requests to db
1000 items with 100 line_items phonghpham:4116-historical-cache-job-issue
  0.737198   0.008508   0.745706 ( 18.267496)
  0.790622   0.004461   0.795083 ( 18.733116)
  0.888244   0.000086   0.888330 ( 18.296511)

1000 items with 100 line_items isidzukuri:4116_tune_historical_cache_job
  0.370500   0.016109   0.386609 ( 15.950086)
  0.348660   0.004235   0.352895 ( 15.883579)
  0.305426   0.007781   0.313207 ( 15.916332)

Additional benefit of find_eachis that it protects from memory exhaustion.

Lets summup speed comparison:
2 items with 10 line_items: relatively equal
100 items with 10 line_items: isidzukuri's
1000 items with 10 line_items: phonghpham's'
1000 items with 100 line_items: isidzukuri's

100 items are definitely closer to our actual data. I'm less concerned with the 10 millisecond or whatever difference and more with how the code looks, to be honest.

authors: cielf dorner isidzukuri phonghpham

repo: rubyforgood/human-essentials


text:
4407-showing all the item fields in the item view

Resolves #4407
Description
All Item fields are shown now in Item view.
Guide questions:

What motivated this change (if not already described in an issue)?
So the banks have one stop for all the info on the item.

Type of change

New feature (non-breaking change which adds functionality)

Screenshots

@Naraveni thanks! (For next time, please don't force push branches that have active reviews, as it makes reviewing the new changes harder.)

authors: Naraveni dorner


text:
Security fixes according to Brakeman

Related to issue #336

@vpetrusenko I have pushed the changes. I will wait until all specs will success.

It works well: deposits / withdraws / trading.

@yivo thank you for help with this patch!

authors: vpetrusenko yivo

repo: rubykube/peatio


text:
设置summaryLength自动获取的字数不对

设置summaryLength自动获取的字数不对，设置为3就显示了几十个字数

summaryLength

加上 hasCJKLanguage = true 就可以解决。
https://discourse.gohugo.io/t/limit-the-summary/4103/12

加上 hasCJKLanguage = true 就可以解决。
https://discourse.gohugo.io/t/limit-the-summary/4103/12

恩，中日韩字符 @LazyBonesLZ

authors: 651016236 LazyBonesLZ rujews

repo: rujews/maupassant-hugo


text:
Unable to create an instance of the specified Rule class <> with fact and result type specified.

Hello, just moved to 0.8 from 0.7.  Prior to and after the update, I'm getting these debug statements in my output when trying to build rules.  However, the rules are being loaded and executed properly as all my testing is passing successfully.  I've tried different variations of below and still end up with the log statements.  Any ideas?
14:30:59.143 [main] DEBUG c.d.rulebook.lang.RuleBuilder - Unable to create an instance of the specified Rule class 'class com.deliveredtechnologies.rulebook.model.GoldenRule' with fact and result types specified
`public class CanadaRules extends CoRRuleBook{
Override
protected void defineRules() {
addRule(getCalculatorRuleBuilder()
.when(fact -> isRequestTypeDonation(fact.getOne()))
.then((fact, result) -> {
Map<Item,List> appliedItemRateMap = getAppliedItemRateMap(fact.getOne());
result.setValue(createResult(appliedItemRateMap));
}).stop().build());
private RuleBuilder<CalculatorFact, BusinessRulesResult> getCalculatorRuleBuilder() {
return RuleBuilder.create().withFactType(CalculatorFact.class).withResultType(BusinessRulesResult.class);
}
}`

RuleBuilder builds Rules of type GoldenRule by default. Since you could implement your own Rule, instead of using the default GoldenRule, it uses reflection to create an instance of the Rule implementation. One of the possible constructors accepts a Fact type and a Result type, which GoldenRule doesn't use. If that constructor fails then it moves on to a constructor that just specifies the Fact type, which GoldenRule does use. And since you got a debug instead of an error log, it likely worked as expected.
The change that you are seeing is the addition of some debug logging. If you turn off the debug logging level (maybe set it to INFO + WARN + ERROR + FATAL), then that should resolve your issue.

I suppose a good question might be "Why does RuleBuilder look for a constructor that accepts a Fact type and a Result type if GoldenRule doesn't even implement that constructor?" I think the original thought is that GoldenRule would have such a constructor. But since it doesn't and probably won't, it might be worth evaluating whether or not that logic should be changed in a future release. But in the meantime, it's not hurting anything ;)

Yes this answers my question, thank you!

repo: rulebook-rules/rulebook

license_source: bigquery


text:
[Question]: Obtain source of information with OpenAIAgent

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
If I use an OpenAIAgent I cant get the source of information and I dont have any idea why:
Build CohereRerank post retrieval processor
api_key = os.environ["COHERE_API_KEY"]=""
cohere_rerank = CohereRerank(api_key=api_key, top_n=2)
qa_tmpl_str = (
"Context information is below.\n"
"---------------------\n"
"{context_str}\n"
"---------------------\n"
"I am an assistant specialized in Azure and its architectures. ONLY TAKE INFORMATION FROM KNOWLEDGE OF THE CONTEXT. IF NOT TELL THAT YOU DONT KNOW"
"answer the query.\n"
"Query: {query_str}\n"
"Answer: "
)
qa_tmpl = PromptTemplate(qa_tmpl_str)
#llm = OpenAI(model="gpt-3.5-turbo", temperature=0, max_tokens=256)
query_engine = index.as_query_engine(
llm=llm, text_qa_template=qa_tmpl,similarity_top_k=10,node_postprocessors=[cohere_rerank]
)
from llama_index.agent import OpenAIAgent
from llama_index.tools import QueryEngineTool
tool = QueryEngineTool.from_defaults(query_engine, name="query", description="I am an assistant specialized in Azure and its architectures. ONLY TAKE INFORMATION FROM KNOWLEDGE OF THE CONTEXT. IF NOT TELL THAT YOU DONT KNOW")
agent = OpenAIAgent.from_tools([tool], verbose=True)
response_agen=agent.chat("Can BIM data from providers other than Autodesk Forge be used in the solution?")
response_agen
AgentChatResponse(response='Yes, the solution can work with BIM data from providers other than Autodesk Forge. The solution is designed to be flexible and can integrate with various BIM data sources. It can consume BIM data from different providers and use it to generate insights and perform analysis.', sources=[], source_nodes=[])

I want the source of the retrieved embeddings while using an openai agent

@alvarojauna If sources/source nodes is empty, that means no tools or source were used

authors: alvarojauna logan-markewich


text:
[Question]: Getting corresponding retrieved document information (metadata, text...) from a KnowledgeGraphRAGRetriever Query

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
Hi, I am wondering whether there is a way to get corresponding retrieved document (with metadata, text) when querying with KnowledgeGraphRAGRetriever?  Since I check output response of query, it only contains a list of relevant triplets.

I have already used include_text=True in first place, but the retriever did not include full document details

@dosu I have already used include_text=True in first place, but the retriever did not include full document details. Please give more detailed how to get it from retriever.

@dosu My nodes from nodes = retriever.retrieve(QueryBundle("foo")) has only 1 item. And the output of nodes[0].node.get_content() is as below:
The following are knowledge sequence in max depth 2 in the form of directed graph like:
`subject -[predicate]->, object, <-[predicate_next_hop]-, object_next_hop ...` extracted based on key entities as subject:
Login{name: Login} <-[relationship:{relationship: Requires}]- Application{name: Application} -[relationship:{relationship: Needs increase in}]-> Font size{name: Font size}
Login{name: Login} <-[relationship:{relationship: Requires}]- Application{name: Application} -[relationship:{relationship: Displays}]

As you can see, the retrieved output contains only triplets, there is no document metadata and text in it.
Is there something wrong here?

@dosu I do not load Index from Neo4jVectorStore. I use vector_index = VectorStoreIndex.from_documents(document) instead. Also, I use Nebulagraph instead of Neo4j. Please give  a suitable example.

@dosu The documents variable in kg_index = KnowledgeGraphIndex.from_documents(documents, storage_context=storage_context) contain their own metadata and text content. How can I get those particular metadata and text content of retrieved documents when making queries with KnowledgeGraphRAGRetriever?


text:
[Documentation]: JSONalyze_query_engine example oudated

Documentation Issue Description
When running the example in https://docs.llamaindex.ai/en/stable/examples/query_engine/JSONalyze_query_engine/, it seems that the module is deprecated and is moved to experimental, as per https://docs.llamaindex.ai/en/stable/api_reference/query_engine/JSONalayze/, i.e., the imports should change
from
from llama_index.core.query_engine import JSONalyzeQueryEngine
to
from llama_index.experimental.query_engine import JSONalyzeQueryEngine
Documentation Link
https://docs.llamaindex.ai/en/stable/examples/query_engine/JSONalyze_query_engine/

Should I submit a PR?


text:
compliation issue

I am  having issues compiling ...any  help  is much  appreciated
Loading cobertura support for rundeck-salt-plugin
:clean
:compileJava
/root/tmp/salt-step/src/main/java/org/rundeck/plugin/salt/version/SaltApiVersionCapabilityRegistry.java:65: incompatible types; no instance(s) of type variable(s) K,V exist so that java.util.TreeMap<K,V> conforms to java.util.SortedMap<java.lang.String,org.rundeck.plugin.salt.version.SaltApiCapability>
found   : <K,V>java.util.TreeMap<K,V>
required: java.util.SortedMap<java.lang.String,org.rundeck.plugin.salt.version.SaltApiCapability>
versionRegistry = Maps.newTreeMap(new Comparator() {
^
1 error
:compileJava FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':compileJava'.

Compilation failed; see the compiler error output for details.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

What version of java are you compiling with?
Apologies for the late response.

authors: sfdc-kho suchisubhra

repo: rundeck-plugins/salt-step


text:
Add bank-menu-entry-swapper

Adds config for the new bank-menu-entry-swapper plugin which provides shift-right click menu config capabilities within the bank interface. This works in the same manner as the new npc/inventory shift-right click menu configuration.

I've have some people recommend I make a PR for this to the actual menu-entry-swapper plugin, so i'll be trying that!

repo: runelite/plugin-hub


text:
Create Skull Prevention Plugin (but cool)

Create Skull Prevention Plugin (but cool)

What is the difference between this plugin and the recently merged plugin?

What is the difference between this plugin and the recently merged plugin?

not much, this one blocks turning it off and has a funny picture for its indicator. I made it as the same time as the other dude as a request from a friend.

Could you maybe PR the features to the other plugin then?


text:
Add offset value for Eternal Teleport Crystal in the ItemsKeptOnDeath plugin

With the 2020 Easter Event update, Jagex made the Eternal Teleport Crystal "prioritised over a greater selection of other items on death". As the store price of the item is the same, the item will now have an offset for use in death scenarios.

@Hydrox6  how do we determine the offset value?

The vanilla kept-on-death interface shows the value of the item with offset if you're risking it.

The offset is 78500

repo: runelite/runelite


text:
Add a way to restrict camera rotation and for the game to memorize camera rotation upon hopping worlds

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always
frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've
considered.
Additional context
Add any other context or screenshots about the feature request here.

this is two requests the latter of which is a duplicate of #12193, can you edit it to only request the restricting.

authors: Alexsuperfly Yepplease


text:
Agility plugin does not increment laps at the agility pyramid

Because of the variable bonus experience at the end of an Agility Pyramid run the agility plugin does not increment your lap counter once you've completed a lap.

What would be the preffered way to handle this? It would be possible to update this with a hardcoded pyramid edge case:
		if (course == null
			|| Math.abs(course.getLastObstacleXp() - skillGained) > 1
			|| (course.getCourseEndWorldPoints().length > 0 && Arrays.stream(course.getCourseEndWorldPoints()).noneMatch(wp -> wp.equals(client.getLocalPlayer().getWorldLocation()))))
		{
			return;
		}
```
Or something like anglerfish, although that seems a bit overkill for 1 course

I would add the location for the end of the course to the agility plugin and make the last obstacle xp optional.

So check if the object interacted with is at the same location of the final obstacle of the course?
Wouldn't you need to use a different subscriber for that?

@MIK0MIK0MIK0 If you're talking about the skill calculator, this issue is completely unrelated to that.

@MIK0MIK0MIK0 If you're talking about the skill calculator, this issue is completely unrelated to that.

oh ok im sorry
how would i go about requesting to add the agility pyramid to the skill calculator?

authors: Adam- Ishadijcks MIK0MIK0MIK0 Nightfirecat


text:
Unable to download setup/Unable to delete setup

Please check if your issue is not a duplicate by searching existing issues
Describe the bug
I am having trouble installing the client. When I download the Win64 setup using the Brave browser, it downloads the file until 0 left, but then doesn't complete the download. The, I cannot delete the downloaded file in any way, except marking as 'delete on reboot' and rebooting. Every other way to delete the file crashes.
Environment (please complete the following information):

OS: Windows 10
Browser: Brave Version 0.63.55 Chromium: 74.0.3729.131 (Official Build) (64-bit)

This really feels like a security bug, could the setup executable be poisoned?

This isn't a security bug. The executable is fine and hasn't changed for ~10 months.

Look, can you just download it from the site and verify the checksum, or even wipe runelite from windows and download and install fresh from the site?
I just tried again with Edge, and same problem. It's been "Checking file with antivirus" for half an hour with no end in sight.

tried again with 32bit and jar versions. Same problem


text:
Add PluginMessage event

A simple way for plugins to communicate over the EventBus while allowing listeners to know the source plugin and filter by messageName. While it's already possible to do this by e.g. posting/subscribing to String, HashMap, etc., providing a proper object for EventBus communication simplifies the problem and makes it possible to identify the event source.
This makes no attempt to verify objects in the data map are visible to other classloaders.
Example Usage
Event Posting:
Map<String, Object> data = new HashMap<>();
data.put("location", new WorldPoint(x, y, plane));
eventBus.post(new PluginMessage(this, "example:doThing", data));

Subscriber:
@Subscribe
public void onPluginMessage(PluginMessage message)
{
    String messageName = message.getMessageName();
    if (!messageName.startsWith("example:"))
    {
        return;
    }

    String command = messageName.substring(messageName.indexOf(':') + 1);
    if (command.equals("doThing"))
    {
        WorldPoint location = (WorldPoint) message.getMessageData().get("location");
        doThing(location);
    }
}

added in 0b12333eafcb9ae1b394849fd65b0526a4e3a8f9


text:
Cooking plugin

Hereby I present a cooking plugin. It contains an overlay with some basic information.

Nice addition.
You might want to remove the 'Cooked/hr' row and just place its text behind the 'Cooked' amount. This would give you: Cooked: 6 (66 h/r).

Here's the updated UI:

Also; the width is slighty wider to make all the text fit nicely.

This is like 4th "session" related plugin, maybe there should be some common structure added, because now it is just duplicate code all over the place, or maybe even have them all in 1 plugin imo.

Aw, when I read "Cooking plugin" I started imagining a cookbook panel.

authors: SoyChai deathbeam jorisrs jpabeem


text:
Add cape rack to menuentryswapper settings.

This is for the Achievement Gallery cape hanger. It swaps Admire for teleport (normal skill capes) and Perks (Max Cape).

This looks like it should be closed by the already-merged #5994

Yeah this is already added. Or well, the perks isnt, so just rebase and add only that

The first half of this was done in #5994 as previously mentioned, and the second half was done by db in #6180 - this can be closed

authors: Nightfirecat deathbeam thesnell xDemoN


text:
GGUF compatibility

I've used the runpod/worker-vllm:0.3.0-cuda11.8.0 container for several different LLMs and it has worked fine so far.
I've just been given a requirement to test GGUF model (specifically https://huggingface.co/impactframes/llama3_if_ai_sdpromptmkr_q4km) and it keeps generating errors:
Entry Not Found for url: https://huggingface.co/impactframes/llama3_if_ai_sdpromptmkr_q4km/resolve/main/config.json.
Is this an issue with the model, or the worker? Is there a known workaround?
Thanks

vllm itself doesn't support GGUF, therefore the worker cannot support it either:
https://github.com/vllm-project/vllm/issues/1002

@ashleykleynhans’s answer is correct

vLLM support gguf now, would RunPod support it by single  command line as usual?
Steve

authors: adam-clarey alpayariyak ashleykleynhans thusinh1969

repo: runpod-workers/worker-vllm


text:
Pytorch cuda image nvidia driver not installed?

RuntimeError: Found no NVIDIA driver on your system. Please check that you have an NVIDIA GPU and installed a driver from http://www.nvidia.com/Download/index.aspx

That is not RunPod issue as you run it on your own hardware. Drivers are handled on host level so it's saying that your PC do not have NVIDIA CUDA drivers installed.

authors: crapthings kodxana

repo: runpod/containers


text:
Crash while training on COCO 2014

While training on COCO 2014 dataset, I'm running into the following crash:

both bg_inds.numel() and fg_inds.numel() is 0, which leads to a crash in keep_inds = torch.cat([fg_inds, bg_inds], 0)
I'm using pytorch on windows, running the program using the following parameters:
--imdb coco_2014_train+coco_2014_val --imdbval coco_2014_val --weight C:\path-to\pytorch-faster-rcnn\data\imagenet_weights\res50.pth
As you do in your training shell scripts, I added an extra element to the anchors:
cfg.ANCHOR_SCALES = [4, 8, 16, 32]
any ideas? Sounds like there should be an exit from the function if no background or foreground regions are found?

This happens in the middle of the training. The full python stack trace is here:

rpn_loss_box: 0.032325
loss_cls: 0.576470
loss_box: 0.398267
lr: 0.001000
speed: 0.460s / iter
iter: 21910 / 70000, total loss: 2.657034
rpn_loss_cls: 0.975540
rpn_loss_box: 0.671567
loss_cls: 0.625927
loss_box: 0.384000
lr: 0.001000
speed: 0.460s / iter

PYDEV DEBUGGER WARNING:
sys.settrace() should not be used when the debugger is being used.
This may cause the debugger to stop working correctly.
If this is needed, please check:
http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html
to see how to restore the debug tracing back correctly.
Call Location:
File "C:\Anaconda3\lib\bdb.py", line 251, in set_trace
sys.settrace(self.trace_dispatch)

c:\telesens\dev\ml\pytorch\pytorch-faster-rcnn\lib\layer_utils\proposal_target_layer.py(142)_sample_rois()
-> keep_inds = torch.cat([fg_inds, bg_inds], 0)
(Pdb) dbcont
*** NameError: name 'dbcont' is not defined
(Pdb) continue

PYDEV DEBUGGER WARNING:
sys.settrace() should not be used when the debugger is being used.
This may cause the debugger to stop working correctly.
If this is needed, please check:
http://pydev.blogspot.com/2007/06/why-cant-pydev-debugger-work-with.html
to see how to restore the debug tracing back correctly.
Call Location:
File "C:\Anaconda3\lib\bdb.py", line 258, in set_continue
sys.settrace(None)
Traceback (most recent call last):
File "C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.4\helpers\pydev\pydevd.py", line 1599, in
globals = debugger.run(setup['file'], None, None, is_module)
File "C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.4\helpers\pydev\pydevd.py", line 1026, in run
pydev_imports.execfile(file, globals, locals)  # execute the script
File "C:\Program Files\JetBrains\PyCharm Community Edition 2017.2.4\helpers\pydev_pydev_imps_pydev_execfile.py", line 18, in execfile
exec(compile(contents+"\n", file, 'exec'), glob, loc)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools/trainval_net.py", line 139, in
max_iters=args.max_iters)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\model\train_val.py", line 348, in train_net
sw.train_model(max_iters)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\model\train_val.py", line 265, in train_model
self.net.train_step(blobs, self.optimizer)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\nets\network.py", line 452, in train_step
self.forward(blobs['data'], blobs['im_info'], blobs['gt_boxes'])
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\nets\network.py", line 394, in forward
rois, cls_prob, bbox_pred = self._predict()
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\nets\network.py", line 366, in _predict
rois = self._region_proposal(net_conv)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\nets\network.py", line 259, in _region_proposal
rois, _ = self._proposal_target_layer(rois, roi_scores)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\nets\network.py", line 157, in _proposal_target_layer
rois, roi_scores, self._gt_boxes, self._num_classes)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\layer_utils\proposal_target_layer.py", line 49, in proposal_target_layer
rois_per_image, _num_classes)
File "C:/Telesens/dev/ML/PyTorch/pytorch-faster-rcnn/tools..\lib\layer_utils\proposal_target_layer.py", line 142, in _sample_rois
keep_inds = torch.cat([fg_inds, bg_inds], 0)
File "C:\Anaconda3\lib\site-packages\torch\autograd\variable.py", line 88, in setitem
return SetItem.apply(self, key, value)
File "C:\Anaconda3\lib\site-packages\torch\autograd_functions\tensor.py", line 117, in forward
i._set_index(ctx.index, value)
RuntimeError: invalid argument 2: out of range at c:\tmp\pytorch\aten\src\thc\generic/THCTensor.c:23
Process finished with exit code 1

I just met the same issue as your case. When I ran the codes in my local mahcine everything is fine (after some modification to make the codes working without adding extra configs...) but this issue (Pdb) happens when I run my codes in remote server. I'm using PyTorch in Linux.

@ankur6ue Hi, just wondering did you solve this issue in your case? I've tried to change some cfgs but still not working.

I haven't yet, as I got looped into other stuff, but basically what is
happening is that neither foreground nor background regions are being found
for that image so it should simply be skipped (no loss computation or back
propagation should be performed). We'll need to add some if's in the code
to handle this case instead of breaking.
On Mon, Dec 18, 2017 at 12:19 PM YingweiZhou notifications@github.com
wrote:

@ankur6ue https://github.com/ankur6ue Hi, just wondering did you solve
this issue in your case? I've tried to change some cfgs but still not
working.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ruotianluo/pytorch-faster-rcnn/issues/48#issuecomment-352493912,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF8Z4xMDQCkTdbJe0X0ITEZegosJUuriks5tBp6fgaJpZM4Q3-yy
.

@ankur6ue It's weird that after thousands epochs of training, the model seems less likely to produce better bboxes with larger value of overlapping, since the direct reason for this issue is NO value is larger than the threshold which is 0.5 by default. Training the model for thousands of epochs is supposed to make the max_overlaps better not worse. The loss value through my trianing process is larger than the loss of my local machine as well.
fg_inds=(max_overlaps >= cfg.TRAIN.FG_THRESH).nonzero().view(-1)
bg_inds=((max_overlaps < cfg.TRAIN.BG_THRESH_HI) + (max_overlaps >= cfg.TRAIN.BG_THRESH_LO) == 2).nonzero().view(-1)
It's an even more weird and confusing thing that the codes runs fine in my local machine but when I move the codes to a remote workstation this issue keeps happening no matter how many times I tried to re-setup the codes/ dataset/ environments (using same version of PyTorch and TorchVision). I'll do a deep diging on the codes and try to make it working....

Did anyone solve this issue ?

hello, did u fix it？
I meet the same error and i tries it all day with no help.
If you know why it happens, please tell me, i will be very appretriate!

Did anyone fix it?

repo: ruotianluo/pytorch-faster-rcnn


text:
[Add] <Free3Dicon to the Frontend/Icons category>

Site URL
https://free3dicon.com/
Description of the above provided site
We need to add Free3Dicon to the frontend/icons category. Free3Dicon offers a collection of free, beautiful, trending 3D icons, that you can use in your website, app or in any project.
Category
Frontend
Sub Category
icons
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[ ] I am a GSSoC'23 contributor

@AhorIsaac you may start working on this

authors: AhorIsaac rupali-codes

repo: rupali-codes/LinksHub


text:
Update Poco with latest 1.8.1

Can you please update the PocoCPP library with the latest 1.8.1?  It appears there may be a feature branch already and a release, but the cmake file that defines the available versions does not have an entry.
I would gladly submit the PR myself but was unsure how/where the checksum field was calculated.
Thank you.

Just saw there was already a PR.  Closing.

repo: ruslo/hunter


text:
SNS: SetEndpointAttributes call malformed

Found in https://github.com/rusoto/rusoto/pull/1229 : we need to add the same kind of .entry. addition to the query string parameter for the SetEndpointAttributes call.

Hi,
I came across another endpoint in SNS that needs .entry when setting the attributes as a part of its call that does not appear to be doing so currently.  That endpoint is Subscribe

Fixed by https://github.com/rusoto/rusoto/pull/1591

authors: Mr-Byte itsHabib matthewkmayer

repo: rusoto/rusoto

license: mit


text:
emacs install instructions

Hi! I'm trying to get this working with emacs as it does look like there's support, but there's no instructions and anything as easy as the vscode install. I'd like to be able to use this since I have a large work code base that's too big for things like rls/racer. Any help on that front would be greatly appreciated, as I'm sure I'm not the only one! 😄

have you seen https://github.com/rust-analyzer/rust-analyzer/blob/master/editors/emacs/ra-emacs-lsp.el ? :)

Well, admittedly there are basically no instructions there :smile: It's quite possible that I am currently the only user of ra-emacs-lsp.el, so it's probably not going to be completely frictionless. But I think the steps would be roughly

install ra_lsp_server with cargo
install recent version of emacs-lsp (and dash and ht, but I think emacs-lsp requires them anyway?), and set that up
add ra-emacs-lsp.el to load path and require it
run lsp in a rust buffer, and hopefully it will start rust-analyzer...
maybe bind join-lines and extend-selection to keys

@matklad I found that, which is why I thought there was emacs support, but the code there doesn't say the instructions, and having it not be in the README in the /editors folder was confusing to me. Does that make sense?

Also thanks @flodiebold I'll give it a shot!

Yeah, docs are a bit of a mess right now: we have a ton of info, but it is scaterred over gazilion of files, and it is not clear which are user docs and which are developer docs. Fixing this is on my TODO list.

Got it working! Had to point it at the project root but the linting shows up! 😄 Appreciate all the help!

@mgattozzi how good does this work? this might be the path forward for the rust spacemacs layer

This now is documented at https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/user#emacs

authors: flodiebold gnzlbg matklad mgattozzi

repo: rust-analyzer/rust-analyzer


text:
fix: Type mismatch when last expression is noreturn asm

When last expression in a function body is noreturn asm, then analyzer
complains about the type mismatch by highlighting entire body. This
fixes it by introducing loop {} in the expanded code.
Fixes: #11820

Thanks!
bors r+

I thought that didn't actually matter in practice (for type inference), but I suppose it does.

authors: lnicola weirdsmiley


text:
Fix wording on clear_current

The current wording implies the next call to has_wrapped() after clear_current() always returns false. According to the arm docs this is not always true:

thanks!

repo: rust-embedded/cortex-m


text:
Update build-it.md

Make it clear how to ensure optimizations will be turned off just using the provided Cargo.toml and cargo build line.

bors r+

authors: DaQue therealprof

repo: rust-embedded/discovery


text:
New resource system

No more magic paths, hopefully.

Fixes #8

This PR will probably need to be squashed in spite of the magnitude of changes since most of the commits don't compile :)

The improvements on the VM layer are massive, the vm/mod.rs module on its own got halved in size effortlessly.

repo: rust-firecracker/fctools


text:
Openbsd cleanup

The following PR is the result of running libc-test under OpenBSD, and corrects all problems.
I have keeped separated commits for reviewing.
Some commits touch BSD globally (getnameinfo for example). In these cases, I have tried to review definitions in system code source.
Please note that this version of libc will break openbsd target for rustc. There are three breaking change:

OpenBSD don't have HW_AVAILCPU: it will break num_cpus() inside src/libtest/lib.rs
the NR_GETENTROPY constant don't exist under this name (it is SYS_getentropy). But I also remove it and declare the function getentropy() which should be a more stable API. The current use is inside src/libstd/rand/os.rs
the type of siginfo_t.si_addr isn't compatible with the current definition of  siginfo_si_addr() in src/libstd/sys/unix/stack_overflow.rs

For all these problems, I have pending patches.

Thanks! I think it's fine to have some breakage here because this isn't a "tier 1 platform" of this library currently (e.g. there's no CI set up for it), but this is a great foundation to start from now!

@alexcrichton I don't understand the failure for mips-unknown-linux-gnu
the previous one (6b84742) was ok, and adding 6c8a63a would make a linkage problem with undefined reference to 'secure_getenv' ?

Thanks @semarie! I'll work on getting this merged (mips failures are likely unrelated)

authors: alexcrichton semarie

repo: rust-lang-nursery/libc


text:
Add info about emitting lints and errors

Since I was just working on this, I thought I would write something up.
We should wait to merge this until https://github.com/rust-lang/rust/pull/48309 merges.
r? @estebank @Manishearth
cc #14 #50

@Manishearth @estebank Thanks for the feedback! I think I addressed all the comments.

@bors r+

https://github.com/rust-lang/rust/pull/48309 merged

authors: estebank mark-i-m

repo: rust-lang-nursery/rustc-guide


text:
cargo doc and cargo test erroneosly detect a documentation test

Problem
The following code snippet causes cargo test to fail.
pub mod m1 {
    /** This const

    has a multiline document string.
    */
    pub const GOOD_DOC: u32 = 1;

    pub mod m2 {
        /** This const

        has a multiline document string.
        */
        pub const BAD_DOC: u32 = 0;
    }
}

The failure is as follows:
running 1 test
test src/lib.rs - m1::m2::BAD_DOC (line 11) ... FAILED

failures:

---- src/lib.rs - m1::m2::BAD_DOC (line 11) stdout ----
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `a`
 --> src/lib.rs:12:5
  |
3 | has a multiline document string.
  |     ^ expected one of 8 possible tokens

error: aborting due to 1 previous error

Couldn't compile the test.

failures:
    src/lib.rs - m1::m2::BAD_DOC (line 11)

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s

error: doctest failed, to rerun pass `--doc`

Moreover, cargo doc generates the documentation of BAD_DOC constant as if it contained a code snippet
.
Interestingly, the GOOD_DOC constant is treated correctly both in cargo doc and cargo test, i.e., no doc-test is created for it and documentation is generated without a code snippet.
This behavior is strange because the doc string is exactly the same in both constants. The only difference is that BAD_DOC is nested in another module m2.
The expected behavior is to treat BAD_DOC the same way as GOOD_DOC:

there should be no doc-test generated and cargo test shouldn't fail
cargo doc shouldn't generate a code snippet

Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.77.1 (e52e36006 2024-03-26)
release: 1.77.1
commit-hash: e52e360061cacbbeac79f7f1215a7a90b6f08442
commit-date: 2024-03-26
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.2 vendored)
libcurl: 8.5.0-DEV (sys:0.4.70+curl-8.5.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Ubuntu 23.10 (mantic) [64-bit]

See also
pub mod m1 {
    /** This const

    has a multiline document string.
    */
    pub const GOOD_DOC: u32 = 1;

    pub mod m2 {
        /** This const

        has a multiline document string.
        */
        pub const BAD_DOC: u32 = 0;
    }

    pub mod m3 {
        /** This const
         *
         * has a multiline document string.
         */
        pub const GOOD_DOC: u32 = 0;
    }
}

Note that m3::GOOD_DOC uses * prefixes on the lines and it works.
Likely whats happening is that * is needed to establish the indent level.  Without that, the raw indentation is passed along to the markdown parser and it is being treated as an indented code block.
However, I'm  unsure how m1::GOOD_DOC isn't treated as an indented code block.
Moving this over for the rustdoc team to triage in case the inconsistency between m1::GOOD_DOC and m2::BAD_DOC is unexpected.

authors: epage r-bk

repo: rust-lang/cargo


text:
Update dependency handlebars to v5 for mdman.

What does this PR try to resolve?
issue #13238

update dependency handlebars 4.5.0 -> 5.0.0
fix code to fit the changes of Handlebars API
RenderError::new() is deprecated. Use RenderErrorReason instead

How should we test and review this PR?
pass all tests in /crates/mdman/tests

Thanks!
@bors r+

:pushpin: Commit 06201b989209698eeec23fe4fa6399c2186ef928 has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit 06201b989209698eeec23fe4fa6399c2186ef928 with merge d069c2419ba810c416024fe52dbcbdf1cb051676...

:broken_heart: Test failed - checks-actions

@bors retry
macOS: The hosted runner encountered an error while running your job. (Error Type: Disconnect).

:hourglass: Testing commit 06201b989209698eeec23fe4fa6399c2186ef928 with merge 87eb374d499100bc945dc0e50ae5194ae539b964...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing 87eb374d499100bc945dc0e50ae5194ae539b964 to master...

authors: WeiTheShinobi bors ehuss epage


text:
Allow examples to be library

This PR allows to specify crate-type to an example in Cargo.toml.
After this PR an example's crate-type can be:

lib
rlib
dylib
proc-macro

Please look at src/cargo/core/manifest.rs:116 because I am not sure whether I done it right.
I haven't added any tests.
I'd like to add them if someone says me how to do that.
Fixes #2358.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Looks good to me, thanks! The line with TODO looks ok to me and the failure on Travis seems relevant (just a style issue).
If you take a look at tests/*.rs you can probably just add a new tests to tests/test.rs

@alexcrichton,
I compiled cargo using cargo build.
Which command should I run to check styles?
I will add some tests.

I allowed an example to be built as a library.
Should cargo test --example work?

@alexcrichton,
What should cargo do if I run test --example <some_example_name>?
I checked it with file:
fn main() {
    panic!("");
}

#[test]
fn f() {
    panic!("");
}

It does nothing.
It writes that it compiles and then nothing.

Which command should I run to check styles?

./tests/check-style.sh
This just checks for lines longer than 100 characters, nothing fancy.

@alexcrichton,
Bot failed because of timeout.

Thanks @KalitaAlexey! Could you also add assertions that the relevant files exist (e.g. dylibs and such) and also remove the TODO?

@alexcrichton,
I will try.

@alexcrichton,
Should cargo test also work?

I don't know how to check whether a library exists.

I have found out that cargo uses rustc to determine the prefix and the suffix of a library.
I have no idea how should I expose that.

@KalitaAlexey you can use the existing_file function to test that a file exists or you could just read the directory and assert some file exists there. I wouldn't worry too much about platform-specific extensions and such, the test can be fairly liberal (e.g. check for any dll, not just the one platform dll)

@alexcrichton,
Should cargo test --example <example> work if  is a library?
Am I right about library prefixes and extensions?

lib, rlib:

Any platform: prefix: lib, extension: rlib

staticlib:

Windows: prefix: none, extension: lib
Not Windows: prefix: lib, extension: a

dylib:

Windows: prefix: none, extension: dll
Not Windows: prefix: lib, extension: so

It should do whatever it does today. If it runs unit tests then it should run unit test. If it just builds the artifact then it should just build the artifact.
On OSX the dylib extension is "dylib", but other than that the info you have I believe is correct.

In the PR cargo test --example <example> where <example> points to an example of some kind of library doesn't compile.

What happens if you point it to an example that's a binary? Libraries should match the same behavior.

@alexcrichton,
Okay.
It requires changes.
I will update the PR.

It works.

Looks like there's a failure on Travis as well?

@alexcrichton,
Why did it fail?
On my machine all tests had completed without failures.

I hope it won't fail again.

@alexcrichton,
Can you include the PR in https://github.com/rust-lang/rust/pull/39199 ?

@bors: r+
Looks good, thanks! I think that rollup PR is for rust-lang/rust, not Cargo, so this can't be included.

:pushpin: Commit e73e270 has been approved by alexcrichton

:hourglass: Testing commit e73e270 with merge de6bce9...

:sunny: Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing de6bce9aaef528572cd2307fbf3b245c0dab8566 to master...

Contrary to what's in OP, cdylib and staticlib are now also supported with this PR. Yay!

Follow up issue in #3572

@alexcrichton,
I want to change http://doc.crates.io/guide.html
because it contains "Example executable files go in the examples directory.".
It should be "Example executable or library files go in the examples directory".
How can I change that?

@KalitaAlexey the docs are in src/doc in this repo, as I think you've found!

I have a minor problem with this change.  cargo metadata now outputs "kind": ["staticlib"] instead of "kind": ["example"] when you have an example library.  I'm working on a tool that uses cargo metadata to determine the command-line arguments to use to build a specific target.  Since there is no longer an indication that the target is an example, it is impossible to know that you need to use --example to build.  Should I maybe open a new issue?

@ehuss yeah want to open a new issue?

Hi @ehuss,
I am sorry about that. When I was working on it I didn't know what it was for.

@KalitaAlexey since we're seeing some breakage want to send a PR to revert back to the original behavior? We can probably add a new field to the metadata which indicates whether an example is a library or not.

@alexcrichton,
I will send a PR today (in 3 hours).

authors: KalitaAlexey alexcrichton bors ehuss jethrogb matklad rust-highfive