text:
fsck progress incorrect

Summary
When running gopass fsck the progress bar shows an incorrect amount of total items to be checked. On my system it actually checks 420 objects, even though it estimates only 418 in total:
420 of 418 objects checked [###################################################################>] 100.00%

Steps To Reproduce
I'm not yet sure if this is an issue with my .password-store or a general counting issue with gopass fsck.

Thanks for reporting this issue. We should try to fix this eventually, but I don't think it's too bad ;)

I agree, it's certainly no showstopper. I haven't had time to look into it myself, but I'll try to get to it this week.

@muesli how many stores do you have mounted? Just one?

@martinhoefling Correct!

Silly bot. Still valid :smile:

Cleaning up old and low prio bugs.
This doesn't seem to warrant much attention.
If it's still an issue feel free to send a PR to fix, otherwise I'm going to ignore it.

Frankly I find that a bit odd. It's still a reproducible bug and it's certainly not invalid. What's the harm of keeping valid tickets around?

Sorry, I'm trying to keep the bug backlog manageable.
At the moment it's hard to see if a bug is still worth paying attention to.
Feel free to reopen if you can verify with a recent release.

Sorry, my bad. I could actually reproduce the issue.
It's not really fixed, but at least hidden.

authors: dominikschulz martinhoefling muesli

repo: gopasspw/gopass

license: mit


text:
feat: add listen method

📑 Description
For issue https://github.com/goravel/goravel/issues/436

@coderabbitai summary

✅ Checks

[ ] Added test cases for my code

Could you introduce how to use this method and what the change of main.go is?

for gin

Okay, what's the change of main.go?

Okay, what's the change of main.go?

Similar to this
	upg, err := tableflip.New(tableflip.Options{})
	if err != nil {
		panic(err)
	}
	defer upg.Stop()

	// Listen for the process signal to trigger the tableflip upgrade.
	go func() {
		sig := make(chan os.Signal, 1)
		signal.Notify(sig, syscall.SIGHUP)
		for range sig {
			if err = upg.Upgrade(); err != nil {
				facades.Log().Errorf("[Graceful] upgrade failed: %v", err)
			}
		}
	}()

	ln, err := upg.Listen("tcp", ":3000")
	if err != nil {
		panic(err)
	}
	defer ln.Close()

	go func() {
		if err = facades.Route().Run(); err != nil {
			facades.Log().Errorf("Route run error: %v", err)
		}
	}()

	// tableflip ready
	if err = upg.Ready(); err != nil {
		panic(err)
	}

	facades.Log().Infof("[Graceful] ready for upgrade")
	<-upg.Exit()

	ctx, cancel := context.WithTimeout(context.Background(), 60*time.Second)
	defer cancel()

	// Wait for connections to drain.
	log.Println("[Graceful] shutting down")
	return facades.Route().Shutdown(ctx)

Oh, so complicated, can we wrap it?

Oh, so complicated, can we wrap it?

Seems unnecessary, users may not use graceful restart.

I think this PR is solving the interruption when upgrading the application, it's unnecessary if User is using K8S, because K8S can build new pods before destroying the old. But if user lanch the application directly instead of K8S, this feature will useful.
Currently, User have to launch the latest version with a different port and use Nginx to listen to it, otherwise, there is a short interruption during the upgrade.

I think this PR is solving the interruption when upgrading the application, it's unnecessary if User is using K8S, because K8S can build new pods before destroying the old ones. But if User launches the application directly instead of K8S, this feature will be useful.
Currently, User have to launch the latest version with a different port and use Nginx to listen to it, otherwise, there is a short interruption during the upgrade.

After using github.com/cloudflare/tableflip , only need to send HUP single to application, then it will restart automatically.

Yes, cloudflare/tableflip is a good feature, it should be better if we can wrap the complicated logic and use a simple way to implement it.

Yes, cloudflare/tableflip is a good feature, it should be better if we can wrap the complicated logic and use a simple way to implement it.

You mean direct use tableflip in there?

Or just a few changes in main.go

Yes, cloudflare/tableflip is a good feature, it should be better if we can wrap the complicated logic and use a simple way to implement it.

You mean direct use tableflip in there?

But the select{} here will prevent tableflip from running.

select{} can be removed if needed. We can make a minimal implement first, to check the logic is expected.

source: gharchive/pull-request

authors: devhaozi hwbrzzl

repo: goravel/framework

license: MIT

license_type: permissive

license_source: github-api


text:
Make sure the eSample method of CaloCluster is translated

For example, we have methods that don't translate because of this:
ERROR: Cannot translate class 'xAOD::CaloCluster_v1::CaloSample': ROOT's type system doesn't have it loaded.

Turns out this is going to be a little more complex than a straightforward adding of enum's.

Any class should be scanned for enum's, and each class should get a listing of them in the output dump
Argument parsing should trigger loading a class with an enum definition even if the class isn't used.
There are typedef's that are being used in the code - we may well need to pay attention to that.

These are all small things that will need to pull together in order to enable this. Probably. We'll get away with as little as possible.

The following sequence will trigger CaloSample to be loaded, and then inspected:
[bash][atlas AnalysisBase-21.2.247]:func-adl-types-atlas > root -b
   ------------------------------------------------------------------
  | Welcome to ROOT 6.20/06                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Jun 10 2020, 06:10:57                 |
  | From tags/v6-20-06@v6-20-06                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |
   ------------------------------------------------------------------

root [0] j = TClass::GetClass("xAOD::Jet_v1")
(TClass *) @0x7fffeecccec8
root [1] cc = TClass::GetClass("xAOD::CaloCluster")
(TClass *) @0x7fffeecccec8
root [2] cs = TClass::GetClass("CaloSampling")
(TClass *) nullptr
root [3] methods = cc->GetMethodAny("eSample")
(TMethod *) @0x7fffeecccec8
root [4] cs = TClass::GetClass("CaloSampling")
(TClass *) @0x7fffeeccceb8
root [5] es = cs->GetListOfEnums()
(TList *) @0x7fffeecccec8
root [6] es->GetSize()
(int) 1
root [8] es->At(0)->GetName()
(const char *) "CaloSample"
root [9] en = es->At(0)
root [14] te = (TEnum*) en
root [19] seq = te->GetConstants()
(const TSeqCollection *) @0x7fffeecccec8
root [30] a_new_const = (TEnumConstant*) seq->At(0)
(TEnumConstant *) @0x7fffeecccec8
root [31] a_new_const->GetValue()
(long long) 0
root [32] a_new_const->GetName()
(const char *) "PreSamplerB"

source: gharchive/issue

repo: gordonwatts/func-adl-types-atlas


text:
Implement maxOp's .Do() method

Turns out the Max function is defined, but the actual doing method  is not implemented.
#229  highlights the issue

@chewxy Has the problem been solved?  the max op still can't work in the master version.

Closing this issue the maxOp implementation seems ok in master thanks to #269.
https://github.com/gorgonia/gorgonia/blob/93e238839b7603ce80c10bb7cff058a77869ea33/op_reduction.go#L111-L120
https://github.com/gorgonia/gorgonia/blob/93e238839b7603ce80c10bb7cff058a77869ea33/op_reduction_test.go#L201-L237
Feel free to reopen if needed.

authors: chewxy owulveryck zltgo

repo: gorgonia/gorgonia


text:
adding [hidden] display: none !important style rule

Hi,
I add this rule because when i try to use it on Polymer app, somehow hidden is not working on pause and error icon.

@kadriansyah Can you provide a minimal plunkr or jsfiddle that demonstrates the bug with the hidden property?

ok, let me create it first...
On Mon, Dec 19, 2016 at 1:06 AM, Nadí notifications@github.com wrote:

@kadriansyah https://github.com/kadriansyah Can you provide a minimal
plunkr or jsfiddle that demonstrates the bug with the hidden property?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gorork/paper-audio-player/pull/33#issuecomment-267836321,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8IIqcKm4FuJNLn9QHEiqfKAdr5zFSvks5rJXYMgaJpZM4LDg9Q
.

authors: gorork kadriansyah

repo: gorork/paper-audio-player

license_source: bigquery


text:
First radio button doesn't work when rendered on server side

I'm trying to render Radio components on server side using emotion-server (renderStylesToString API call). This results in emotion adding style tags in the first input tag, which means the selector :checked + span::after doesn't work as the immediate sibling element to input is a style element now.
Is there a way to work around it? Quickly skimming through I cannot find a straight forward alternative, any suggestions would be greatly helpful.

Following code seems to workaround the issue (moved to ~ from +)
const SelectRadio = styled(Radio)({
  '& input:checked ~ span::after': {
    opacity: 1
  },
  '& input:focus ~ span::before': {
    boxShadow: `0 0 0 4px ${YELLOW}`
  },
  '& input:disabled ~ span': {
    opacity: '.4',
    pointerEvents: 'none'
  }
});

Do you think change to CSS selector is useful as a separate PR?

@penx Any comments on work around/PR?

@opensourcegeek I need to reproduce the issue and have a think, will try tonight or tomorrow. A codesandbox or GitHub repo that reproduces issues would be handy so there isn't a barrier to recreating :-)

Our checkboxes should be brought inline with the following CSS:
https://github.com/alphagov/govuk-frontend/blob/master/src/components/checkboxes/_checkboxes.scss
And the following template:
https://github.com/alphagov/govuk-frontend/blob/master/src/components/checkboxes/template.njk
This doesn't seem to use ~ so I imagine may fix the issue

Our radios should be brought inline with the following CSS:
https://github.com/alphagov/govuk-frontend/blob/master/src/components/radios/_radios.scss
And the following template:
https://github.com/alphagov/govuk-frontend/blob/master/src/components/radios/template.njk
This doesn't seem to use ~ so I imagine may fix the issue

I believe we are tracking the following CSS:
https://github.com/alphagov/govuk-frontend/blob/4b3c08191297405c1cecabc5d0aceb9ce19b575f/src/components/radios/_radios.scss#L121-L123
...so doing something different would bring us away from govuk-frontend which I'd rather not do if it can be avoided.

@opensourcegeek can you make a basic github repo that reproduces the issue after an npm install and npm start?

also do you get the same issue when using next.js? You can try it out on codesandbox, I had started something here https://codesandbox.io/s/1q99004kml
Also a screenshot of what "not working" looks like would help so I can be sure I'm recreating the issue correctly

Just seen you have a reproducable example in another ticket. Will try check that out tomorrow

@penx thanks - the problem is this happens only when rendered on server side, we came across it when testing no JS journey. I don't think the project I've linked you will work as it's vanilla create-react-app.
I'm happy to set a project for you which could help you diagnose the problem. But the issue is when rendering on server side with emotion-server it adds style tags that disturbs the sibling selector in govuk-frontend. So one option is to find a way to get emotion-server to not do that, but my experience with emotion server is very minimal so I couldn't find a work around that way. The other option was to change the selectors so that it still works if it's not immediate sibling in DOM. This does the trick for now, but your suggestions to work around this issue using whatever approach would be very useful.

@penx please checkout https://github.com/opensourcegeek/govuk-react-playground, if you have any issues please let me know.

Pretty sure using extractCritical would solve this:
https://emotion.sh/docs/ssr

Thanks @penx - I'll give that a try and let you know

We're no longing using emotion so closing this issue as stale, please reopen with an example if it's still an issue

authors: opensourcegeek penx

repo: govuk-react/govuk-react


text:
feat: chat-completion-client retries by default - to disable via env

Depends on https://github.com/gptscript-ai/chat-completion-client/pull/3
Disable retries by setting env GPTSCRIPT_DISABLE_RETRIES to anything.
E.g. in Otto8 if I wanted to disable retries on the website-cleaning tool:
task, err := h.invoker.SystemTask(ctx, thread, system.WebsiteCleanTool, string(content), invoke.SystemTaskOptions{
				Env: []string{"GPTSCRIPT_DISABLE_RETRIES=1"},
			})

LGTM

repo: gptscript-ai/gptscript


text:
cmd/groundstation: Use femto for status submission.

This allows removing JSON and HTTP method logic from the HandleStatusSubmission function.
It also means all the methods are on the same mux.
Doing this requires moving the API stuff into it's own library, so it can be tested nicely. We'll also want this for when the web api, and ground API are on the same binary.

saw aproval from mila on discord

repo: gpuctl/gpuctl


text:
31/12/2013 → MM/DD/YYYY

moment.parseFormat('31/12/2013') parsed to MM/DD/YYYY, I expected: DD/MM/YYYY.
Other test cases:
moment.parseFormat('12/31/2013') parsed to MM/DD/YYYY => Correct
moment.parseFormat('31-12-2013') parsed to DD-MM-YYYY => Correct
moment.parseFormat('12-31-2013') parsed to MM-DD-YYYY => Correct

Good catch! Would you mind sending a PR? I'm happy to walk you through what it takes, if you need any guidance

closed via #40. Released as https://github.com/gr2m/moment-parseformat/releases/tag/v2.0.1


text:
Add support for defining environment variables in launch configuration

It's fairly common when running or debugging an application to want to specify environment variables. Other launchers I've used support the env property, accepting a map of key:value pairs. It would be really nice if this were configurable for the GraalVM launcher as well. My use case is running and debugging code on TruffleRuby.

This is fixed by https://github.com/graalvm/vscode-extensions/commit/e1d627805538926b42971efc002809418a6e2964
env property can be specified, it's value is an object of "key" : "value" pairs. To delete a property, use "key" : null
A new version of GraalVM extension 0.5.25 was released today, which contains this fix.

authors: entlicher nirvdrum

repo: graalvm/vscode-extensions


text:
feat: Add Coverage Check To GitHub Workflow

🍰 Pullrequest
dito
Issues

relates #122

Where is the review?

repo: gradido/gradido


text:
decay with the value 0 is no longer displayed

🍰 Pullrequest
decay with the value 0 is no longer displayed.
the button is no longer displayed and there is no additional information about a transaction.
Issues

fixes #758

What about those, where you have two outgoing or incoming transactions shortly after each other?

authors: ogerly ulfgebhardt


text:
Remove the dependency resolution data capturing Gradle sample

The purpose of this sample is to capture configurations which were resolved by Gradle during configuration (e.g. because of dependency substitution).
As of Gradle Enterprise 2021.3, this information is already available in Build Scan dependency resolution.
I suggest we remove this data capturing sample in favor of the information provided natively by a Build Scan.

@bigdaz Can you double check that these do the same thing?

@erichaagdev Just for your info: the data is captured and visualzied in build scans natively, but it is currently not queryable unless you use custom values provided by this snippet.

authors: erichaagdev etiennestuder runningcode


text:
Docs of input/output annotations should state that usage on Kotlin properties is supported

Declaring the following Kotlin property in a Task implementation, causes the value of myInput to be tracked as an input.
@Input
val myInput = objects.property<String>()

Expected Behavior
The Javadoc of @Input currently states:

This annotation should be attached to the getter method in Java or the property in Groovy.

Current Behavior
It should state:

This annotation should be attached to the getter method in Java or the property in Groovy or Kotlin.

Context
Our Kotlin samples all use @get:Input so it's unclear if this is officially supported.
Related issue: #9030

We should improve the Javadoc.

We should improve the Javadoc.

Mh, reading this thread I thought I can drop get:, but this doesn't work: I get This annotation is not applicable to target 'member property without backing field or delegate'
@InputDirectory
abstract val inputDir: Property<Path>

Hi. from this issue it is not clear to me whether just specifying the annotation on a property (without get:) works and the java-doc is wrong, or it doesn't work.
My opinion is it should work.

authors: chkpnt fab1an marcphilipp wolfs

repo: gradle/gradle


text:
Dependency locking should not persist lock state on build failure

Expected Behavior

When asking Gradle to persist lock state using the --write-locks CLI option, I may want to write custom validation tasks for my dependency graph. A failing build should not write lock files to disk.
Current Behavior

Even if my custom validations fail the build, lock state is still persisted.
Workaround
For now, my best thought will be to concatenate my validation step and persisting lock state as two separate Gradle invocations. This is obviously not desirable:
$ gradle myCustomValidationTask && gradle resolveAndLockAll --write-locks
Context

As mentioned above, I would like to write custom validations about the expected state of the resolved configurations. If this expectation is not met, my custom task will throw a GradleException and fail the build.
More specifically, @ljacomet and I have discussed a potential future feature by which a centrally-declared dependency should take precedence over transitively-resolved versions of the same component. In the custom validation use-case which exposed this feature request, I am failing the build if the version of my first-order centrally-declared dependency is resolved to a higher version via transitive conflict management. I believe this would also be a nice-to-have feature.

Perhaps a better description would be "Dependency locking API should have an option to not persist lock state on build failure". Otherwise this could be too severe of a modification to existing behavior.

Not writing the lock file on build error makes compete sense and it happening was an overlooked side effect of dealing with a single file per project.
This is planned for addition in Gradle 7.0.

authors: DPUkyle ljacomet