text:
Feature/dark theme

Super hot dark theme, super slick css, all in one nice PR:

Could this be done in a simpler way? For example, if there are more themes in the future - this sets a precedent that they can only be added by PR to this repo. Ideally anyone can write and share their own themes and host them in whatever repo they like.
What do we need to do for GraphiQL to enable that? Are the CSS class names descriptive enough that the only necessary thing is to just add another CSS file to the page? Do we need the ability to set an additional classname on the GraphiQL root node?

I think it's easy enough to add your own body/html class and overwrite the current theme via css selector specificity. I've already done this myself in a few implementations. We could also expose an optional className prop to make this more explicit to users. Mostly this just needs to be documented and, potentially, we have a pre-done dark theme for users.
My final thought is that colors and other backgrounds are defined in numerous places, so theming can be kind of painful since you have to overwrite numerous selectors. This begs for either refactoring the css to make theming easier, or implement some preprocessor so consumers can overwrite variables and generate the css themselves.

I'm going to close this PR and work on another branch that more descriptively shows how to theme, and offers a dark theme as an example

Hrm, doing some digging on color definitions:
ack '\#.*;' css | grep -o '\#.*;' | sort | uniq | tee >(wc -l) => results in around 72 unique color definitions.
Dropping the uniq in my command shows that each color is defined around ~2 times: 139. I'm not sure what the threshold is in moving to a css-preprocessor, but this amount of colors and definitions makes it hard(er) for consumers to apply custom themes as there's a ton of rules to rewrite.

i would be interested in this

And another year later

And two more years later...

@joelgriffith did you ever re-open this PR? this accidentally was cross referenced when merging other repos

authors: acao joelgriffith leebyron prakashn27 rjrobinson sw-yx

repo: graphql/graphiql


text:
Record failed transfers and modify the history page to show them correctly

People who depend on the money they receive on Gittip are rightfully concerned whenever their receiving amount suddenly jumps down after payday. We know that's because of CC failures, but they don't. We should update the history page to show the number of people that have a tip set up for them, but didn't tip anything because their CC failed. This should be shown for each individual payday, though I'm not sure we have that historical data.
Q: how should the wording change to accomidate people who fund their account with something else, like Bitcoin? Perhaps say that they had "insufficient funds"?

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/2918202-record-failed-transfers-and-modify-the-history-page-to-show-them-correctly?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).

+2 from @anselmh @book in https://github.com/gratipay/gratipay.com/issues/3756.

source: gharchive/issue

license: mit

license_type: permissive

license_source: bigquery


text:
Fix bootstrap-debian.sh name

File now has a "-", not "_".

@rohitpaulk This is why I'm not allowed to merge my own commits ;-)

:)

source: gharchive/pull-request

authors: mattbk rohitpaulk


text:
🛑 GrauNeko.com is down

In e8711a5, GrauNeko.com (https://graueneko.com) was down:

HTTP code: 403
Response time: 2001 ms

Resolved: GrauNeko.com is back up in 574da02 after 10 minutes.

repo: graueneko/status-page

license: MIT

license_source: github-api


text:
Issue/5399 add icon

fix gravitee-io/issues#5399

:tada: This PR is included in version 1.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: gcusnieux graviteeio


text:
feat(cart): shard packages

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/graycoreio/daffodil/blob/master/CONTRIBUTING.md#commit
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Fixes: N/A
What is the new behavior?
Does this PR introduce a breaking change?
[x] Yes
[ ] No

Moves many imports. Removes DaffCartModule.
Other information

The DaffInMemoryBackendCartRootService | Unit tests are pointing to source files instead of dist.

@lderrickable good catch, changed.

I think the injection tokens for the DaffCartResolver and DaffEmptyCartResolver tests should come from dist instead of source.

I think the tsconfig.dev.json needs updated. ng serve demo-dev doesn't work right now

@lderrickable

I think the injection tokens for the DaffCartResolver and DaffEmptyCartResolver tests should come from dist instead of source.

done. I made this change in the guard tests as well.

I think the tsconfig.dev.json needs updated. ng serve demo-dev doesn't work right now

Good call, I was able to use wildcard paths for that as well. fixed

lgtm

repo: graycoreio/daffodil


text:
First attemt at supporting explicit discriminant numbers on tag variants

Towards issue # 1393.  Still need error checking and more testing.
At very least should check that the same discriminator is not specified
twice.
Note, sending for an initial review on coding style, etc.  Do not expect
it to be accepted just yet. May also rebase this branch.

You will need to update more of the code.  Doing a quick search, I think at least these functions need to be changed:

trans_var() in the nullary variant case;
trans_tag_variant()
iter_structural_ty()

There are likely more places too.

Also, I suggest converting the iteration over a vector where you do not need the index to use vec::iter() (or vec::iteri() if the index is required).

Finally, we probably want to allow arbitrary const expressions for the discriminant values.  I am not sure where the const machinery is in the compiler today though.

Yeah, I need to do a more thorough conversion.  I wanted to make sure I am approaching it correctly before I change too much code.

I made some minor improvements over the weekend.  There is a big FIXME in there, fixing that might relate to handle the encoding and decoding of the crate metadata, especially if the disr. values are stored in LLVM constants, which is what I believe Graydon was trying to tell me about on IRC.

nikomatsakis: I did not see how trans_tag_variant() or iter_structural_ty() need to be updated.

trans_tag_variant() initializes the discriminant in the following code:
    let llblobptr =
        if is_degen {
            fcx.llretptr
        } else {
            let lltagptr =
                PointerCast(bcx, fcx.llretptr, T_opaque_tag_ptr(ccx));
            let lldiscrimptr = GEPi(bcx, lltagptr, [0, 0]);
            Store(bcx, C_int(ccx, index), lldiscrimptr);
            GEPi(bcx, lltagptr, [0, 1])
        };

The line Store(bcx, C_int(ccx, index), lldiscrimptr); in particular stores the index into the discriminant field.  You probably want this to be the discriminant value, not the index of the variant.
iter_structural_ty() switches on the discriminant to decide what code will execute.  The relevant code is this line             AddCase(llswitch, C_int(ccx, i as int), variant_cx.llbb);, where you probably want to change i as int to be the discriminant value, not the index.

nikomatsakis: Sorry, okay iter_structural_ty is tagged I meant to say trans_var instead of trans_tag_variant?
I looked again at (trans_var) and don't see how it needs to be updated. It seams to use lookup_discriminant to get the value.

Regarding trans_var, in the case of a nullary variant where there is exactly one variant, we hardcode the discriminant value as 0:
            let d = if vec::len(*ty::tag_variants(ccx.tcx, tid)) != 1u {
                let lldiscrim_gv = lookup_discriminant(bcx.fcx.lcx, vid);
                let lldiscrim = Load(bcx, lldiscrim_gv);
                lldiscrim
            } else { C_int(ccx, 0) };

I'm not really sure why we do this.  Micro-optimization? You could probably just take out the if and always use lookup_discriminant().

Another place that needs to be updated: trans_constant() in trans.rs, which contains the code that initializes the global variables storing the discriminants.

Fixed trans_var, trans_constant already fixed, let me know if I missed something.

oh, right, that was in your original patch. sorry about that.

I added encoding of discriminator in crate metadata see commit 2537537.
With that I think this pull request is about ready to be accepted.  Note that rust with valgrind is failing on my machine so I can't test my changes with valgrind.
If you are happy with everything please let me know and I will rebase (likely just squash everything into one commit).

After several hours of digging I finally figured out how to get the disr. value out of a tag value, hence...
I added support for casting tag types to scalar values, but only when they are "enum-like", that is all constructors are nullary.
Safely going the other way is a lot more complicated as somehow a check needs to be made that the scalar value is within the range of values the enum-like type represents.
Again, need to rebase before this gets accepts, so please let me know.

Okay, I just rebased. As I feared Graydon's comments on commit 1678b109 were lost.
I think it is ready to go.
Niko: I opened an issue for removing global variables that store the discriminant IDs per variant (#1488).

Actually the comments are not lost, find the comments here: https://github.com/kevinatk/rust/commit/1678b109.
The autolink pointed to the commit in grayton/rust even though that commit should't exist in that repo, odd.

Integrated, thanks.

authors: graydon kevinatk nikomatsakis

repo: graydon/rust


text:
Don't pass the entire model state list to a module

When running a module, the framework passes the contents of the model state list (contained in ModelState.Rda file) to the module function along with the datasets specified by the module. The primary use of this has been to make the 'Seed' value available to a module to use for setting the random seed. However, the model state list includes a lot of other information that modules don't need to use and including it might encourage module developers to interact other than through the API functions they should be using. I think the data that is passed should be limited to that which is absolutely necessary. At this point it only looks like the seed value is necessary.

We decided this is insignificant.

authors: bstabler gregorbj

repo: gregorbj/VisionEval


text:
Level Up Demo

Now that the monorepo is up and running, I want to stand up a fully working demo that everyone can see at https://nextjswp.com

[x] Connect this repo with Vercel
[x] Purchase nextjswp.com and point at Vercel
[x] Configure Vercel to deploy frontend (ENV vars, etc...)
[x] Configure Vercel/Turbo??? to deploy the backend (Docker) to Digital Ocean?
[x] Point this repo at nextjswp.com

This is all set!

Frontend (on Vercel): https://nextjswp.com/
Backend (on Dreamhost): https://nextjswp.dreamhosters.com/
Github Action https://github.com/gregrickaby/nextjs-wordpress/blob/main/.github/workflows/deploy-backend.yml

repo: gregrickaby/nextjs-wordpress


text:
Cached version message, project doesn't load after alert

You will now see the cached version of this file. To view the latest version, setup your personall access token.

@rameez-s
Hi. You are seeing this message because you've loaded your design previously, but no more valid (personal) access token found. You can fix this by clearing the index db on code.grida.co

authors: rameez-s softmarshmallow

repo: gridaco/code


text:
lots of compiler warnings in renderer_gl_common.inl (Visual Studio)

Not sure if I didn't  set something right, but Visual Studio shows me these warnings, which would be nice to fix:
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(291): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(291): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(311): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(311): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(303): warning C4244: 'initializing': conversion from 'float' to 'unsigned int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(332): warning C4244: 'function': conversion from 'float' to 'size_t', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(341): warning C4244: 'function': conversion from 'float' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(322): warning C4244: 'initializing': conversion from 'float' to 'unsigned int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(323): warning C4244: 'initializing': conversion from 'float' to 'unsigned int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(366): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(818): warning C4244: '=': conversion from 'float' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(820): warning C4244: '=': conversion from 'float' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(823): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(823): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(826): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(826): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1048): warning C4244: '=': conversion from 'float' to 'Uint8', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1049): warning C4244: '=': conversion from 'float' to 'Uint8', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1050): warning C4244: '=': conversion from 'float' to 'Uint8', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1051): warning C4244: '=': conversion from 'float' to 'Uint8', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1125): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1125): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1593): warning C4244: 'function': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1694): warning C4244: 'function': conversion from 'float' to 'GLint', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(1694): warning C4244: 'function': conversion from 'float' to 'GLsizei', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(2210): warning C4244: 'function': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3306): warning C4244: 'function': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3357): warning C4244: 'function': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3491): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3492): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3640): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3641): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3658): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3660): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3683): warning C4244: '=': conversion from 'float' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3684): warning C4244: '=': conversion from 'float' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(3716): warning C4244: 'function': conversion from 'int' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(4044): warning C4018: '<': signed/unsigned mismatch
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(4050): warning C4018: '<': signed/unsigned mismatch
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(4558): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_gl_common.inl(4559): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(196): warning C4244: '=': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(203): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(204): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(207): warning C4305: '*=': truncation from 'double' to 'float'
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(208): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(209): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(222): warning C4305: '*=': truncation from 'double' to 'float'
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(223): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(224): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(273): warning C4244: '=': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(280): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(281): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(284): warning C4305: '*=': truncation from 'double' to 'float'
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(285): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(286): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(308): warning C4305: '*=': truncation from 'double' to 'float'
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(309): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(310): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(331): warning C4244: 'initializing': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(334): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(335): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(363): warning C4244: 'initializing': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(367): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(368): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(405): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(406): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(412): warning C4244: 'initializing': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(415): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(416): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(456): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(457): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(459): warning C4244: 'initializing': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(462): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(463): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(542): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(543): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(544): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(545): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(553): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(554): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(555): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(556): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(604): warning C4244: '=': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(616): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(617): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(620): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(621): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(624): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(625): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(635): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(636): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(640): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(641): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(652): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(653): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(657): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(658): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(668): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(669): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(673): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(674): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(832): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(825): warning C4244: 'initializing': conversion from 'double' to 'int', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(841): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(842): warning C4244: 'initializing': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(941): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(943): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(950): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(956): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(961): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(967): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(972): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(978): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(983): warning C4244: '=': conversion from 'double' to 'float', possible loss of data
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\src\renderer_shapes_gl_common.inl(926): warning C4305: 'initializing': truncation from 'double' to 'float'

Thanks!  These are all implicit conversion warnings.  They should be fixed.  Some are missing explicit casts and some are using double-precision trig functions that were only standardized in C99 (which was not a strict dependency of SDL_gpu until recently).

I made some changes in 49e166ed01104c3bc1b9bdbd29af1ce78eae6323 for this, but there might always be a bunch of warnings in Visual Studio because of how this project is set up.

Thanks. There are three remaining warnings:
1>  main.c
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\demos\tutorial-space\main.c(99): warning C4244: 'function': conversion from 'double' to 'float', possible loss of data
1>  demo-font.c
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\common\demo-font.c(171): warning C4244: '=': conversion from 'int' to 'float', possible loss of data
1>  common.c
1>c:\users\michael\documents\work\sdl2-2.0.5-libraries\sdl-glu\common\common.c(125): warning C4244: '=': conversion from 'Sint64' to 'int', possible loss of data


text:
feat(parseFunctionDeclaration): improve formatting detection

In the regex that dispatches the different parts of the function signature, it doesn't need to have the function prefix at the start at the moment. This can lead to inconsistencies.
For example, if by mistake, the name of the function is forgotten, this would cause a signature of type function (bytes32 args, bytes32 r, bytes32 s) external;. In this case, the parser would understand that function is the name of the function, which of course leads to inconsistency and the impossibility of calling this function because it does not exist.
So I suggest that the function prefix be mandatory (it could also be totally removed, but it's mostly present and it adds more meaning in the signature writing) at the beginning. In this way there can be no ambiguity. And if the function prefix is not present then the Invalid function declaration error is thrown.
Similar to #103 but related to function signature.

@tcoratger I think it would be a better idea to keep this because:

I don't remember where but I am afraid that some components already depend on the no-function format, fixing this will break them.
Additionally, I also don't think this error is likely, as function name is very important and not at the beginning of the signature, it is hard to imagine how it can be missed. :)

I do understand that it is a good idea to prevent this issue, I would suggest to add another regex check to detect and reject this (Something like ^\s*function\s*\(), in this way we can avoid the issue and keep the old behavior. What do you think?

@SAPikachu Agreed, @juniormp can you handle this in both #109 and #110? as well as adding the corresponding unit tests to verify that it is indeed impossible to have function (bytes32 offerId, address destAddress, uint256 amountOffer) external payable returns (bytes32) or event (bytes32 indexed _offerId, address indexed _token, uint256 _chainId);?

authors: SAPikachu tcoratger


text:
Are there plans to support LINUX?

Are there plans to support LINUX?

No, not for grocy-desktop - would be technically also a whole other thing.
I would recommend any of the available Docker images, if you want to have a "simple" setup.

repo: grocy/grocy-desktop


text:
Variables give an error

The variables {{date}} {{time}} in the front matter give an error. Looks like that {{date}} {{time}} does not need to be mentioned.

Did you activate the Obsidian core plugin "Templates"?

The {{date}} {{time}} will automatically be inserted when using "Insert template" from the menu. More about: https://help.obsidian.md/Plugins/Templates

authors: ViTuDia groepl

repo: groepl/Obsidian-Templates


text:
Tricky to use without SPM

Unless I'm missing something it's kind of tricky to use GRDBCombine today if the project is not setup to use SPM for everything.
I'm currently using GRDB through a git submodule and adding the project file to my workspace and building the framework as a dependency to my app.
The dependency on GRDB defined in the package manifest makes it so that GRDB is downloaded as a package when generate-xcodeproj is run to generate a Xcode project to use in a similar manner to how I'm currently using GRDB.
That same dependency also means that Xcode starts fetching a second copy of GRDB when the package is added to the workspace.
The only solution (except for switching to SPM for everything) that doesn't result in two downloads of GRDB in my project is to download the source files and import them directly into the project. Which becomes hard to maintain instead.
I can't say I have a good solution for this. Could a project without any references to SPM be included in the repo perhaps?

Hi @simme!
Indeed today GRDBCombine is SPM-only.

I can't say I have a good solution for this.

I don't see many.

Could a project without any references to SPM be included in the repo perhaps?

Thats one solution, which could lead to something similar to the existing GRDB manual installation. Ideally, this project would contain one target per supported platform. I don't quite know how it would itself integrate with GRDB.
Another solution would be to merge GRDBCombine inside GRDB itself. That's indeed a trend: many libraries come with built-in publishers, instead of shipping a separate library.

I don't quite know how it would itself integrate with GRDB.

Since the source files of GRDBCombine import GRDB it seems like that would be up to the developer in the manual installation case? Just make sure GRDB is also linked and included in the app bundle it shouldn't be a problem. Right?

You can also copy GRDBCombine sources in your own app.

This is what I'm probably going to do now, since I really want to play around more with GRDB and combine in this data layer refactor I'm doing. Maintaining the dependency will be a little more error-prone, that's ok though.

A last solution would be to merge GRDBCombine inside GRDB itself.

From my perspective I could see this being nice. Seeing as Combine is a "first class citizen" of Apples platforms now. Although the modular approach is clean, for sure.
I can also understand that there's a certain hesitancy since GRDBCombine isn't considered a 1.0 yet.

I can also understand that there's a certain hesitancy since GRDBCombine isn't considered a 1.0 yet.

Fortunately, GRDB has the Experimental flag: we can break anything at this level ;-)

Fortunately, GRDB has the Experimental flag: we can break anything at this level ;-)

What are we waiting for!? :D

In short, I think this is the way to go. Until GRDBCombine is merged in the main repo, I'm sorry it's not that easy to use it without SPM.

Yeah, that's what I'll do. Thanks for the response, as usual! :)

Maybe I should create a new issue for this, but while we're at it: What do you feel is missing from GRDBCombine to make it into a 1.0 now that Combine is out of beta?

That makes perfect sense.
I'm going to try and use it a bit in my app and see what happens. I immediately ran in to issues with @DatabasePublished though, since it needs some static/global reference to a Database to be initialized.
I'll report any other findings or bugs!

I immediately ran in to issues with @DatabasePublished though, since it needs some static/global reference to a Database to be initialized.

Yep, that's exactly the issue about "dependency injection" I was talking about. Related: https://github.com/groue/GRDBCombine/issues/17#issuecomment-536248985
In all honesty, my advice would be to pick one of those two paths:

Forget about DatabasePublished, use plain observation publishers, and build your app.
Clone GRDBCombine, try to make DatabasePublished able to deal with real-world problems, build your app much more slowly, and maybe reach a point where you feel comfortable setting up a pull request.

Thanks for the input!

authors: groue simme

repo: groue/GRDBCombine


text:
Completely changes the structure of the lib

Due to my misunderstanding of the API, I was going with a solution which
realied greatly in class methods. Turns out that we're going to need the
user's token for each request, and it is probably going to be different
at each request.
This means that we need a Bitreserve::Client class that we instantiate
with that token and go on from there.
My approach was to make the client have a huge public API with all of
the methods available (provided their are being mixed in).
I also moved those mixins into a directory called api and moved the
actual classes into a directory called entities.

@naps62 The build is breaking because I'm using keyword arguments, which ruby 1.9.3 does not support. I really love keyword arguments and would be willing to drop 1.9.3 support on that fact alone.
However, there are other reasons for dropping 1.9.3 support, such as the Hampton's Ruby Survey that says almost 80% of people have moved on to ruby 2, and the fact that 1.9.3 will be EOL in less than a month.
What do you say?

Given those numbers, I don't have a problem with dropping 1.9.
Actually (and just for the record), Semaphore's numbers from 6 months ago show that more than 40% of ruby projects were running 1.9 (https://semaphoreapp.com/blog/2014/08/27/ruby-version-usage-in-commercial-projects-2014-edition.html)
So, assuming both statistics are accurate, that's a significant decrease in the last 6 months, which is also a pretty good number

That survey is not comprehensive, but it does show trends. IMO the EOL coming is a bigger reason to change. I'll remove it from the test matrix, then.

@naps62 What about the new structure?

:+1:

repo: groupbuddies/bitreserve


text:
Area2D disappearing

Hi.
I have encountered some strange behavior of Area2D, while trying to handle area intersection with area_entered signal.
Here is some code fragment with connect of OnAreaEntered handler to signal:
func (i *InteractionManager) Ready() {
	// ...
	i.Area.AsObject().Connect(i.Temporary.StringName("area_entered"), i.Temporary.Callable(i.OnAreaEntered), 0)
}

func (i *InteractionManager) OnAreaEntered(o gd.Object) {
	if a, ok := gd.As[*InteractiveArea](i.Temporary, o); ok {
		fmt.Println("area entered: ", a)
	}
}

This code results to this:
https://github.com/user-attachments/assets/30b0beaf-e10e-4600-818d-8374615cd476
So after OnAreaEntered handler, entered InteractiveArea just disappears.
InteractiveArea is custom gd.Ared2D
type InteractiveArea struct {
	gd.Class[InteractiveArea, gd.Area2D]
	CollisionShape gd.CollisionShape2D
	Radius         gd.Float `gd:"radius"`
}

This might be related to #44, because if I trying to cast the entered object to *gd.Area2D instead of *InteractiveArea, I'm getting nil, true as a result.
func (i *InteractionManager) OnAreaEntered(o gd.Object) {
	if a, ok := gd.As[*gd.Area2D](i.Temporary, o); ok {
		fmt.Println("area entered: ", a)
	}
}

area entered:  <nil>
area entered:  <nil>

Also this is probably related to #53, because it's actually the same project and I can't take gd.Area2D as handler argument because of panic:
panic: reflect.Value.Convert: value of type gd.Object cannot be converted to type gd.Area2D

I was able to workaround this by using gd.Object as handler argument or by replacing InteractiveArea to a manually created Area2D with CollisionShape2D in editor:

This also fixed i.Area.GetOverlappingAreas method. But area disappears anyway after OnAreaEntered handler or after taking area from gd.ArrayOf by index.
Initially I was trying to connect two signals area_entered and area_exited like this:
i.Area.AsObject().Connect(i.Temporary.StringName("area_entered"), i.Temporary.Callable(i.OnAreaEntered), 0)
i.Area.AsObject().Connect(i.Temporary.StringName("area_exited"), i.Temporary.Callable(i.OnAreaExited), 0)

But this resulted in an error about trying to remove child from busy node or something. Here is the log file
error.log

Thanks for reporting this, I'll have a look at this over the weekend.

I notice you are trying to cast the object to a pointer type gd.As[*gd.Area2D]. This needs to be a value type for Godot classes. Do you still run into the problem if you use gd.As[gd.Area2D]?

Yes, the same behavior with gd.As[gd.Area2D]. Just checked, this problem appears even without any casts, with just empty handler. If i create Area2D and connect area_entered signal to my handler via editor, everything works fine. So probably it is something about Connect in Go.

Thanks for the additional information, I think this is an issue with Go Callables that accept class arguments. I suspect gd is incorrectly taking ownership of the arguments and freeing them when it returns.

repo: grow-graphics/gd


text:
Relative url support for g.url()

Been thinking about this a little bit. We've come across situations where it would be nice if g.url could generate a relative URL for a document (from the current document).
Is this something that has been considered before, and Is this something you think Grow should support and that you'd be open to exploring (via the medium of a pull request)?

Yes, think we should add this!

Do middleman or jekyll support url generation in this way?
What do you think would be a reasonable way to indicate that I want a relative URL instead of an absolute one?
And, should we allow the user to generate relative URLs from documents other than the current, rendering document?

BTW – I think this should probably be part of the Url object (doc.url) – or if not part of, interface with it – and not the g.url tag, since the g.url tag is just a little shortcut for accessing the url property of a doc.

A cursory look shows Jekyll users use a macro:
http://ricostacruz.com/til/relative-paths-in-jekyll.html
And middleman has it built-in via the relative argument to link_to.
https://middlemanapp.com/basics/helper_methods/

My initial thought was to add an argument to g.url so that you could do something like:
Home

Do you think this is a reasonable interface?
I can't think of a use case where being able to generate a relative URL from a document other than the current document would be useful (but that doesn't mean that there isn't one...).

To make your snippet more maintainable (specifically, the link title), I'd suggest not using g.url and instead using g.doc. Example:
{% set link = g.doc('/content/pages/index.html') %}
{{link.title}}

The problem with the above is that relative_path wouldn't know what the current document/context is, unless we injected it into g.doc. We could do that, it might just get nasty.
Another way to do it that's more explicit, though maybe needlessly verbose?
# Where "doc" is the current document.
{% set link = g.doc('/content/pages/index.html') %}
{{link.title}}

Any more thoughts?
(Side note: Grow supports multiple document titles per page, so you could do the following for increased awesome maintainability.)
# In /content/pages/index.html
$title: Homepage
$titles:
  navbar: Home
$view: /views/base.html

# In /views/base.html
{% set link = g.doc('/content/pages/index.html') %}
{{link.titles('navbar')}}

Despite my previous hesitation, I actually don't think it'd be too bad to inject the current document automatically onto the g.doc template tag. That would enable you to simply do the following:
{% set home = g.doc('/content/pages/home.yaml') %}
{{home.title}}

It would also work with g.url to meet your example case:
{% set url = g.url('/content/pages/home.yaml') %}
{{url.relative_path}}

Think that'd be OK?

repo: grow/pygrow


text:
cloud_to_prod_auth:default:python:jwt_token_creds Timeout

Seen on the 1.3.x branch
https://grpc-testing.appspot.com/job/gRPC_interop_pull_requests/13452/console

Seems obsolete.

repo: grpc/grpc


text:
Allow passing service name to client stubs for dynamic mapping

Currently, all client stubs statically include the service name, e.g. the c++ stubs generated by protoc.
It would be a simple change to allow passing a service name to a stub.
This way, gRPC would enable pseudo-polymorphism, dynamic capabilities and dependency injection.

We already support generic stubs .

And you think that is enough? I could also do a raw HTTP/2 call or Morse code.


text:
Creating a ClientContext possibly causes a memory leak?

What version of gRPC and what language are you using?
1.28.1 and 1.19.1
What operating system (Linux, Windows,...) and version?
Archlinux / Ubuntu 18.04
What runtime / compiler are you using (e.g. python version or version of gcc)
GCC 9.3 / GCC 7.4
What did you do?
I created a simple cpp source file with one main:
#include <grpcpp/grpcpp.h>
#include <google/protobuf/stubs/common.h>

int main(void)
{
    grpc::ClientContext context;
    google::protobuf::ShutdownProtobufLibrary();
}

When building and running this compiled 'program' in valgrind, it reports memory leaks: 'still reachable' blocks:
==96788==    still reachable: 24 bytes in 3 blocks
(see below for the full information).
What did you expect to see?
All heap blocks were freed -- no leaks are possible
What did you see instead?
==96788== Memcheck, a memory error detector
==96788== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==96788== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==96788== Command: /test/grpc/grpc_valgrind_test_test
==96788==
==96788==
==96788== HEAP SUMMARY:
==96788==     in use at exit: 24 bytes in 3 blocks
==96788==   total heap usage: 4 allocs, 1 frees, 72,728 bytes allocated
==96788==
==96788== 8 bytes in 1 blocks are still reachable in loss record 1 of 3
==96788==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==96788==    by 0x14A2E5: grpc::internal::GrpcLibraryInitializer::GrpcLibraryInitializer() (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x148535: _GLOBAL__sub_I_client_context.cc (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x217B2C: __libc_csu_init (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x5BD8B27: (below main) (libc-start.c:266)
==96788==
==96788== 8 bytes in 1 blocks are still reachable in loss record 2 of 3
==96788==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==96788==    by 0x14A2A5: grpc::internal::GrpcLibraryInitializer::GrpcLibraryInitializer() (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x148535: _GLOBAL__sub_I_client_context.cc (in/test/grpc/grpc_valgrind_test_test)
==96788==    by 0x217B2C: __libc_csu_init (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x5BD8B27: (below main) (libc-start.c:266)
==96788==
==96788== 8 bytes in 1 blocks are still reachable in loss record 3 of 3
==96788==    at 0x4C3017F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==96788==    by 0x14853F: _GLOBAL__sub_I_client_context.cc (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x217B2C: __libc_csu_init (in /test/grpc/grpc_valgrind_test_test)
==96788==    by 0x5BD8B27: (below main) (libc-start.c:266)
==96788==
==96788== LEAK SUMMARY:
==96788==    definitely lost: 0 bytes in 0 blocks
==96788==    indirectly lost: 0 bytes in 0 blocks
==96788==      possibly lost: 0 bytes in 0 blocks
==96788==    still reachable: 24 bytes in 3 blocks
==96788==         suppressed: 0 bytes in 0 blocks
==96788==
==96788== For counts of detected and suppressed errors, rerun with: -v
==96788== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Anything else we should know about your project / environment?
I built and executed this in two environments:

Ubuntu 18.04 in a project where I build grpc and protobuf myself.
Archlinux with a grpc and protobuf installed on the system.

Both give the same result.
adding grpc_shutdown() before returning does not help as well.
PS of course my test is not in '/test/' but I removed the path in front of that.

Hi, gRPC Core and C++ do have some some global data structures that are allocated once and never released. We are basically depending on them being cleaned up automatically on process shutdown.
(Same as #22527)

authors: maaikez yashykt


text:
Bump version to 1.4.3

And run generate_project.sh

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

[trickle] Performance differences noted:
Benchmark                                      svr_transport_stalls_per_iteration
---------------------------------------------  ------------------------------------
BM_PumpStreamServerToClient_Trickle/128M/128M  -99%

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

authors: grpc-jenkins stanley-cheung


text:
Add Another Repro for RefCountedPtr Issue

Error message:
LAPTOP ~/Desktop/grpc [ref-counted-ptr-part-2] (0) $ make ref_counted_ptr_test
[CXX]     Compiling test/core/gprpp/ref_counted_ptr_test.cc
In file included from test/core/gprpp/ref_counted_ptr_test.cc:19:
./src/core/lib/gprpp/ref_counted_ptr.h:55:48: error: 'IncrementRefCount' is a private member of 'grpc_core::RefCounted<grpc_core::testing::(anonymous namespace)::Parent>'
    if (other.value_ != nullptr) other.value_->IncrementRefCount();
                                               ^
test/core/gprpp/ref_counted_ptr_test.cc:196:26: note: in instantiation of member function 'grpc_core::RefCountedPtr<grpc_core::testing::(anonymous namespace)::Child>::RefCountedPtr' requested here
  FunctionThatTakesChild(child);
                         ^
./src/core/lib/gprpp/ref_counted.h:78:8: note: declared private here
  void IncrementRefCount() { gpr_ref(&refs_); }
       ^
1 error generated.
make: *** [/Users/ncteisen/Desktop/grpc/objs/opt/test/core/gprpp/ref_counted_ptr_test.o] Error 1

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,976,225      Total (=)      1,976,225

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,770,430      Total (>)     10,770,429

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

authors: grpc-testing ncteisen


text:
Remove expected results in server interceptor test

Potential stopgap test change. Will also try to prepare an alternative fix.

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Better fix coming.

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 2,019,388      Total (=)      2,019,388

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
11,154,185      Total (<)     11,154,189

 No significant differences in binary sizes

authors: grpc-testing vjpai


text:
WIP Only Unary Stream partially implemented

Draft implementation of the Unary Stream Client Interceptor for receiving early feedback. There are still some missing pieces, and many tests are missing but the way that the developer will be using the interceptor is well defined and ready to receive feedback.
The rationale is to keep using the same technique used by the current stack, so providing to the user a way of adding an iterator, in the use case of the  Unary Stream Client Interceptor a response iterator, for intercepting messages that are being sent by the RPC and acting as a proxy to the iterator consumed by the caller.
So the idea would be having a final PR that would provide support for the Unary Stream Client Interceptor.

Hi, @gnossen @lidizheng changed the way how response iterator is being intercepted, by following a similar strategy of the current stack, where the user needs to return only a new iterator.
The PR is still in draft, some tests are failing, but if there is anything that could be a blocker by you, my plan is to open a new PR with the final code this weekend or at most by Monday.

Closing in favor of #22713


text:
Improve python3 compatibility of the task_runner.py script

I was running the script on a machine that only had python3 and ran into some small issues, so I create a PR to fix those (as at some point we will probably want to get rid of python2 entirely)
task_runner.py is being used for building artifacts, packages and distribtests.

Android CI failure is unrelated and was fixed by https://github.com/grpc/grpc/pull/23998.


text:
Support RDS updates on the server

Note that graceful shutdown is still remaining.

This change is

Known issues: https://github.com/grpc/grpc/issues/26886
Thanks for reviewing!


text:
XdsClient: don't ignore resources after an invalid Resource wrapper

Previously, if we encountered a resource wrapped in a Resource wrapper message, we would stop processing the response at that point -- i.e., we would ignore any subsequent resources in the response that might still have been valid.  This PR fixes the behavior so that we no longer ignore subsequent resources.  It also uses the resource name from the Resource wrapper in NACK messages in cases where we previously did not report the resource name in the NACK message.

I have no reason to believe that any other language has this bug, but I mentioned it in the chat for them to check.


text:
Backport "Make legacy artifact -> packages -> distribtest jobs a noop" to v1.49.x

Attempt to build packages successfully on v1.49.x
Currently, the macos artifact build job is failing to install dependencies.

@apolcyn  I suspect this might not be what you want. If you provided the link to the failed build, I'd know more.
If you're actually trying to build the artifacts / packages on 1.49.x (rather than just trying to silence an error), this PR is likely not going to help you.  I suspect the macos artifact build might be failing because of the recent MacOS monterey migration?
You might want to backport e.g. this instead: https://github.com/grpc/grpc/pull/31125

@jtattermusch there were Ruby and Python setup failures in the macos artifact build job.
The ruby failure was here: https://fusion2.corp.google.com/invocations/e4fd00c9-d2ae-40e1-915a-36150d86eb44/targets/grpc%2Fcore%2Fmaster%2Fmacos%2Fgrpc_build_artifacts/log. This PR would stop trying to use macos entirely, for the ruby artifact build.
I can't find the link to the Python failure, but it was happening on this command, I believe because it couldn't find python2.7. This PR would stop using that script entirely.

From your log:
++ rvm get stable
Archives path '/Users/kbuilder/.rvm/archives' not writable, aborting.

would be addressed by https://github.com/grpc/grpc/pull/31125.

I created https://github.com/grpc/grpc/pull/31697.
The python issue would IMHO be addressed by backporting https://github.com/grpc/grpc/pull/31126/.
A PHP fix is here: https://github.com/grpc/grpc/pull/31567 (also backport if that's what you need).

Looks like this was superseded. I'm going to close, feel free to reopen if still needed.

authors: apolcyn jtattermusch


text:
Global regular expression "Linux disks for autodiscovery" does not exist

Hi @100Mbps,
Can you please show me your configuration for custom.vfs.discover_disks? Do you have any regex configured?

repo: grundic/zabbix-disk-performance


text:
Change the order of cloud-nuke to delete IAM policy first before IAM groups

Change the order of cloud-nuke to delete IAM policy first before IAM groups

Description
Fixes https://gruntwork.atlassian.net/browse/CORE-330.
Testing

Created a test IAM policy and IAM group via AWS UI
Inspected that both element exist by running the command:

aws-vault exec demo-logs -- ./cloud-nuke inspect-aws --resource-type iam-policy --resource-type iam-group

Ran the cloud-nuke command to delete both resources at the same time:

aws-vault exec demo-logs -- ./cloud-nuke aws --resource-type iam-group --resource-type iam-policy

Final confirmation from the cloud-nuke CLI:

Checked the AWS UI and verified both resources have been deleted successfully.

TODOs
Read the Gruntwork contribution guidelines.

[x] Update the docs.
[x] Run the relevant tests successfully, including pre-commit checks.
[x] Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
[x] Include release notes. If this PR is backward incompatible, include a migration guide.
[x] Attention Grunts - if this PR adds support for a new resource, ensure the nuke_sandbox and nuke_phxdevops jobs in .circleci/config.yml have been updated with appropriate exclusions (either directly in the job or via the .circleci/nuke_config.yml file) to prevent nuking IAM roles, groups, resources, etc that are important for the test accounts.

Release Notes (draft)

Added / Removed / Updated [X].
Updated [Switched the order of operation from iam-group <-> iam-policy]
Migration Guide

No migration needed

Can you update the description - todos and release notes section

Can you update the description - todos and release notes section

Updated. Let me know if there's anything I missed!

Hmm I tried to look through the API documentation and existing set of tests in the code base, but it doesn't seem like there's a way to create IAM group with inline policy.

I think you will need to use PutGroupPolicy for creating inline policies
https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#PutGroupPolicy

repo: gruntwork-io/cloud-nuke


text:
feat: extend the shared libraries

Description
Extend the shared libraries from the terragrunt repository https://github.com/gruntwork-io/terragrunt/tree/master/pkg

@eak12913 , thanks for review!

repo: gruntwork-io/go-commons