Update service-bus-performance-improvements.md

@akakhalil : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off
@MicrosoftDocs/apex-docs-pr-reviewers - please merge this PR. Thanks.

@spelluru: I'm sorry - only the author of this article, @axisc, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

You are welcome
From: Sreedhar<EMAIL_ADDRESS>Sent: Thursday, December 17, 2020 11:17 AM
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] Update service-bus-performance-improvements.md (#67833)
@spelluru approved this pull request.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fpull%2F67833%23pullrequestreview-554761910&data=04|01||9dce47b9acf346b0cd5708d8a2a74049|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637438186500559437|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=GLF4D5Z1LbjwbgKoPwOF7wDAAAJv6uvkugaWei7WsAM%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAOYED7EKZ2IRLHOM4HFH7T3SVIVJTANCNFSM4U7YBJ4A&data=04|01||9dce47b9acf346b0cd5708d8a2a74049|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637438186500569428|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=SCqnC9lJ23QtED%2FBQHgnD%2FNtaXFpF%2F2Vbmfs6Qk099Y%3D&reserved=0.


Support authentication on the level of ElasticClient

Addresses https://github.com/Philippus/elastic4s/issues/3122. I copied authentication settings that were introduced in http4s PR https://github.com/Philippus/elastic4s/pull/3118, will be happy to remove them from http4s PR after this will be merged.
Also, they are now can be removed from AkkaHttpClient, that also implements adding credentials by itself.
By defining credentials on the ElasticClient level there is now a single place where credentials are used, so there is no need to rely on client-specific implementations of credential passing.

Sorry @Philippus I haven't added tests yet. I was thinking whether I should make an IT-test, e.g. try to setup a credentials in ES, and then test against it, or just do a unit test? I was kind of blocked by not being able to choose, maybe you could share what would be the preferred way?

Sorry @Philippus I haven't added tests yet. I was thinking whether I should make an IT-test, e.g. try to setup a credentials in ES, and then test against it, or just do a unit test? I was kind of blocked by not being able to choose, maybe you could share what would be the preferred way? Will be happy to add tests after ☺

I think ideally, set up an Elasticsearch test container requiring credentials and test against that. But I don't know how easy it would be to set that up. I'm fine with someone adding that in a later PR.


Implement SetSpeed() for joint class

Since we are wanting to control the speed of the rover it might be handy to have a Setter and Getter for joint class

done


smaller offset handling

another 2 gone :)

Nice! After I "unpacked" the lea I knew there was something like this in those lines but didn't come to do this after all...

Nice! After I "unpacked" the lea I knew there was something like this in those lines but didn't come to do this after all...

Yes, before the last PR I was playing around with different versions without LEA but left it because I didn't get anywhere.
In hindsight this now is pretty obvious.
I guess you have spotted that theoretically one more could be saved if you allow the snake's starting position to be off center at 0xA20.

Yeah actually I did notice that but decided not to because it just looks better starting from the middle but then remembered I was willing to "throw" once in a while food  out of the borders so this is obviously OK 😅


Implement a Token Provider interface

#3819.
The token replacement code is very exposed through public and protected members. My implementation leaves all of those in place to avoid breaking existing functionality. Therefore, all the core tokenization code still lives in the BaseCustomTokenReplace, BaseTokenReplace and TokenReplace classes.
If the provider is different than the CoreTokenProvider, it calls that provider instead. The CoreTokenProvider also has a simple implementation that calls the TokenReplace class. This is in case someone decides to use the provider instead of calling TokenReplace directly.
The changes I did also consolidate all parameters related to tokenization into a single TokenContext class that can be easily passed around.
Tested on DNN 9.6.1 with some simple scenarios and everything seems to work as before.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: bogdan-litescu sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

did you test with modules implementing custom TR, like "DNN Form & List"?

did you test with modules implementing custom TR, like "DNN Form & List"?

I haven't tested Form and List yet. I tested the HTML module, which also uses a derived TR HtmlTokenReplace and the skin tokens, such as the language flags.

tokenReplace was originally developed as part of Form&List module, which still uses it more extensively than HTML, Skin or Newsletter module.

@bogdan-litescu this contribution looks great!  There are some failing tests, though.  I'm assuming you'll need to adjust how some things are created in the tests, maybe by creating mock implementations.  Feel free to ask questions if you have trouble tracking the issues down.  Thanks!

@bogdan-litescu this contribution looks great! There are some failing tests, though. I'm assuming you'll need to adjust how some things are created in the tests, maybe by creating mock implementations. Feel free to ask questions if you have trouble tracking the issues down. Thanks!

@bdukes Thanks for pointing this out. I registered the CoreTokenProvider in the ComponentFactory and that seems to do the trick.


Support githubRepo property in configuration

Same as websiteUrl and vcsUrl, it would be great if githubRepo could be specified programmatically. Otherwise developers have to manually edit the package to add this value. Additionally, if this value is set it would also be great to turn on the README from github (with a boolean flag).

+1


Executor Memory Full after multiple merge

Hi
I am doing merges on several tables.
when I create a new spark context for each merge, this works fine.
however, when I use the same spark context for sequential merges, the executor memory
is full and the process breaks.
 ERROR YarnScheduler: Lost executor 14 on host: Container killed by YARN for exceeding memory limits. 10 GB on 9 GB

how to  release of the executor memory between merges ?
thanks

It is worth investigating what is occupying the memory in the executor. You can look in the Spark UI to investigate. In the merge operation, we dont explicitly cache any RDD/DataFrame that could occupy the executor memory. However, it could be that the merge operation internally is causing a broadcast join and the broadcasted data would occupy the executor memory. However, the broadcasted data should be automatically dropped when there is memory pressure (that is, next merge needs to broadcast something new). So I am not quite sure how it could lead to this error.
I am not familiar with the YARN setting, but maybe the YARN container memory limit and the executor heap size limit are not correctly configured? Hence the executor is trying to use more memory and YARN is killing it?

I managed to overcome the problem by increasing spark.executor.memoryOverhead.
I haven't been able to reproduce the sequential problem so i guess the problem was more related to a bad spark executor configuration than a yarn configuration problem or a delta-lake merge problem. thanks


@conda-forge-admin, please add user @xylar

Additional comment:
No response

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added user @xylar in conda-forge/google-cloud-datastore-feedstock#31.


Some firefox shortcuts don't work

For some reason shortcuts like cntrl+w or cntrl+t don't work in firefox)

@And329

For some reason shortcuts like cntrl+w or cntrl+t don't work in firefox)

yeah so it seems. I will try to fix it, Thanks for making this issue!

@And329

For some reason shortcuts like cntrl+w or cntrl+t don't work in firefox)

it should be fixed now. It was ui.key.accelKey in about:config with was set to 91 but i changed this value back to the default of 17 in the firefox module.

@And329
For some reason shortcuts like cntrl+w or cntrl+t don't work in firefox)

it should be fixed now. It was ui.key.accelKey in about:config with was set to 91 but i changed this value back to the default of 17 in the firefox module.

thank you, it's fixed now)


Show form field help text in dashboard

What kind of an issue is this?

[x] Bug report

What is the expected behaviour?
Django help text for form fields should be displayed with the form field.
What is the current behaviour?
There is no help text displayed.
How do you reproduce this problem?
Visit /dashboard/events/create/ and notice that no help text is displayed.
Try to add an attendanceevent ("påmelding") in the admin panel, and notice that it works. https://online.ntnu.no/admin/events/event/add/
Other information
Django admin does this:

Dashboard does not:

Took a while to understand what the help text here meant, so what sklirg is talking about here is the little gray text by the input fields, describing the meaning of the field. Here is what Django has to say about it. Didn't look at it too closely, but it doesn't seem very easy to add on to dashboard.


Not work power toys run

Microsoft PowerToys version
0.41.3
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
I pulse Alt+espace, wrote app name and when pulse enter appears error
2021-06-30.txt
✔ Expected Behavior
run an application
❌ Actual Behavior
appears a missage for send you the bug
Other Software
No response

According to line 297~322, this is a issue duplicating #11970

@santiby
Does it happen on pressing the enter key or clicking on the result?

Closing as duplicate of https://github.com/microsoft/PowerToys/issues/11898


Analysis logs should be available for debugging

It is hard to debug issues without having access to full analysis logs. It'd be great if analysis logs could be stored somewhere, I don't know the right answer where, but there seems to be a need of being able to look at full analysis logs.

Solution
Add new checkbox to the analysis advanced options page:
[ ] Enable enhanced analysis details.

When enabled:

Passes Verbosity=1 to the addon.
The addon enables capture of output for the analyzer-lsp and analyzer-dep commands.
A File is created in the hub and attached to the TaskReport.
Output is appended to the file (uploaded as it's output by the command) to the hub.  This is rate limited <= 1 second using a auto-adjusted backoff.
Short term: the files will be injected to the Task.Activity by the GET /tasks endpoint.

Long term: The files can be listed, viewed and downloaded on a new Tab on the "Analysis Detail" modal.

Closed: #68


Update ipxedust library version:

Description

This new version of github.com/tinkerbell/ipxedust fixes the need to set ASSUME_NO_MOVING_GC_UNSAFE_RISK_IT_WITH=go1.19 environment variable when using Go 1.19.
Why is this needed

Fixes: #
How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:
I have:

[ ] updated the documentation and/or roadmap (if required)
[ ] added unit or e2e tests
[ ] provided instructions on how to upgrade

@mergify queue

@mergifyio refresh

@mergify refresh


chore: adding feature request issue template

Description
Adds an issue template for feature requests.
Type of Change

[ ] ✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🧹 Code refactor
[ ] ✅ Build configuration change
[ ] 📝 Documentation
[x] 🗑 Chore

Closing as this conflicts with our contributing guide.


Blank White Screen on "flutter run"

What platform is this being done on? There currently is a fatal localization bug that may be impacting the render process.

Trying it on Windows with a physical android device.

Ah in that case it is most definitely the localization bug present in the current source.

Umhmm. How do you suggest me to try it?

Yeah, I can for sure say that it is because of our localization switch.
If you want to try dahliaOS, you can download the latest ISO from the releases repo

Alright! Thanks for the help. Closing this issue.

web.dahliaos.io, while clunky is also functional (broken commits did not sync)


add NSAttributedString attributes support for links, support UIColor …

…(not just for Foreground)
Add support for the following attributes for links (default, active, inactive):
NSFontAttributeName
NSBackgroundColorAttributeName
NSForegroundColorAttributeName
NSUnderlineColorAttributeName
NSUnderlineStyleAttributeName
NSStrokeWidthAttributeName
NSStrokeColorAttributeName
NSKernAttributeName
NSLigatureAttributeName

Also uniformly support UIColor for attribute values not just for Foreground color (as it was previously).

before:
self.activeLinkAttributes =  @{
    (NSString *)kCTUnderlineStyleAttributeName:
        @NO,
    kTTTBackgroundFillColorAttributeName:
        (__bridge id)[[UIColor colorWithWhite:0 alpha:0.3] CGColor],
    kTTTBackgroundStrokeColorAttributeName:
        (__bridge id)[[UIColor colorWithWhite:1 alpha:0.5] CGColor],
    kTTTBackgroundLineWidthAttributeName:
        @1,
    kTTTBackgroundCornerRadiusAttributeName:
        @4
};

after:
self.activeLinkAttributes =  @{
    NSUnderlineStyleAttributeName          : @NO,
    NSBackgroundFillColorAttributeName     : [UIColor colorWithWhite:0 alpha:0.3],
    NSBackgroundStrokeColorAttributeName   : [UIColor colorWithWhite:1 alpha:0.5],
    kTTTBackgroundLineWidthAttributeName   : @1,
    kTTTBackgroundCornerRadiusAttributeName: @4
};

This looks great, @galambalazs  I added a few minor suggestions.

Sure whatever way you want to do it. You can either merge it and add your own changes, or simply do your own PR.
I doubt I'll have time to edit this PR in the near future.


Error in "New Set Topics"

ADD_NEW_SET_TOPIC=:::-<datatype< doesn't work.
"-" as separator conflicts with "-" used in regex.

fixed by v3.29


Uncaught ReferenceError: global is not defined

https://github.com/StackExchange/Stacks-Editor/blob/185d3e001e84d82ddb943a05cfcfe31b9e7d5e39/src/shared/prosemirror-plugins/code-paste-handler.ts#L21
Occurs when pasting text/html content into the editor. Bundling with Vite.

Thanks for the report. I believe this is the second time this has happened now, so I've completely turned off Node polyfill support in Webpack in a1f35dd2154503a0b8b82cfd021c0e296536b8c4. This will cause us to catch this problem during development, rather than passing it downstream to our users...


chore!: de_strict_order to default; PartialOrd -> Ord bound for hashcollections

This pr is part of #51 resolution.
It addresses the following comments of review:

Second comment is addressed by second commit: feat!: raise bound on keys in hashcollections PartialOrd -> Ord.
Code with f32 and f64 won't be affected by this breaking change, as f32 and f64 aren't Eq, so it's not possible to construct HashSet or HashMap with these types as keys in the first place (insert in both collections require Eq bound).

It's a bit surprising that that's not the default. Probably makes sense to explain why we need this feature:

@matklad The reasoning for that de_strict_order was not enabled by default is that extra checks add performance hit (https://github.com/near/borsh-rs/pull/162#issuecomment-1612893891), and if any of the dependencies use borsh with default features, there is no way to opt-out. Canonical deserialization does not seem like a crucial feature even for nearcore, so I would keep it off by default to trade correctness for performance.
@dj8yfo What do you think?

Sorry for being confusing, what I meant is:

this is surprising, so it must be documented clearly

not

this is surprising, so it must be changed

Removed commit with making de_strict_order a default feature from history of this pr

So far i've only noticed this example, affected by this PartialOrd -> Ord change, but in this case the types are either already Ord or Ord can be easily added to #[derive(...)]


Update sbt-scoverage to 1.8.2

Updates org.scoverage:sbt-scoverage from 1.5.1 to 1.8.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (1.5.1).
You might want to review and update them manually.
project/plugins.sbt

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scoverage", artifactId = "sbt-scoverage" } ]

labels: sbt-plugin-update, semver-minor, old-version-remains

Superseded by #121.


proposal: intrinsic multiword arithmetic

This is a proposal to speed up crypto/poly1305 using [u]int128 and multiword arithmetic. Arm64 has instructions that let you multiply two 64-bit registers to two 64-bit registers.  It also has instructions for multiword addition. I have implemented some of these intrinsics and intrinsified them in https://go-review.googlesource.com/c/go/+/106376 which improved the performance of crypto/poly1305 by ~30% on arm64 (Amberwing). I have added these intrinsics for arm64 in poly1305 package but they might benefit other platforms as well. I am seeking advice on the design of this implementation. Is poly1305 package the right place to have these intrinsics or should they go in math/big or math/bit? This might also be a use case for #9455

amd64 also has these instructions, and access to them is one of the major blockers to writing performant crypto in Go instead of assembly.
I think the best place for them would be math/bits. Can you give us a preview of the exported APIs?
/cc @vkrasnov @grittygrease (they probably have opinions)

/cc @mundaym @TocarIP too, perhaps

arm64 has an API EXTRconst which can be used to write a rule like (ShrQconst [c] x y) -> EXTRconst [c] x y). If other targets also have EXTRconst this can be generic.

I don't like the idea of polluting math/big. It already has a million godoc entries, but at least they all deal in Int/Float/Rat, while these would split a fixed size uint128 in hi/lo uint64.

arm64 has an API EXTRconst which can be used to write a rule like (ShrQconst [c] x y) -> EXTRconst [c] x y). If other targets also have EXTRconst this can be generic.

Intel should have SHRD.

I don't like the idea of polluting math/big

Maybe create something new? like math/uint128

Is there any chance of writing this in regular Go code without any extra APIs, and having the compiler recognise the pattern to optimise?

are you suggesting a builtin [u]int128 type like how GCC does: https://godbolt.org/g/o6ka5e ?

@mvdan Not really. The high bits of uint64 * uint64 are simply discarded. We would need uint128 in the language. (#9455)

That is probably too big a change for a very niche use case. I think that less than 0.1% of Go projects would need these.

If anywhere these would probably belong in math/bits, not math/big. I think some of them were even mooted during the original math/bits API discussion. (On phone so don’t have issue link handy.)

math/bits seems like the right place.
I think you only need the following building blocks:
func Mul(x, y uint64) (uint64, uint64) // 64x64 -> 128 multiply (low, then high)
func Add(x, y uint64) (uint64, uint64) // 64x64 -> 65 add (low, then high)

(and maybe signed versions?)
Everything else can be written in Go.
Even Add is not really necessary, but might make it easier for the compiler to detect the carry.  (In Go, the carry is low_result < low_x || low_result < low_y or something.)
The expression you would use for a multiword shift should be directly detectable by the compiler.  (It doesn't currently, but it should be straightforward.)

I think AddQQ and AddQW have uint128 inputs, not uint64.
Agreed on not being useful enough to change the language. I don't hate math/uint128, but if we can boil them down to a couple API in math/bits and detecting some patterns, even better.

If we have 64x64 -> 128, we might probably also have 32x32 -> 64 on 32-bit architectures. On 64-bit architectures this would be trivial.

Can't you already get a 32x32->64 multiply on 32-bit archs?  386 can, at least:
func f(x, y uint32) (uint32, uint32) {
	z := uint64(x) * uint64(y)
	return uint32(z), uint32(z >> 32)
}

compiles to
	0x0016 00022 (/home/khr/go/tmp1.go:3)	MOVL	"".x+4(SP), CX
	0x001a 00026 (/home/khr/go/tmp1.go:4)	MULL	CX
	0x001c 00028 (/home/khr/go/tmp1.go:4)	MOVL	AX, "".~r2+12(SP)
	0x0020 00032 (/home/khr/go/tmp1.go:4)	MOVL	DX, "".~r3+16(SP)

32x32 -> 64 can be handled by pattern matching thanks to uint64. This is about filling the uint128 void.

previous conversation about uint128: https://github.com/golang/go/issues/9455

I like an idea about exposing mulWW and divWW, which we already intrinsify, for general use, but I'm not sure about right package. IIRC there was Gophercon talk about optimizing 64x64->128 multiplication, so this looks like something useful for others.
This should also help hash/fnv128, which currently does ugly stuff like this:
                 s1l := (s[1] & 0xffffffff) * prime128Lower
                 s1h := (s[1] >> 32) * prime128Lower
                 s0l := (s[0]&0xffffffff)*prime128Lower + (s[1]&0xffffffff)<<prime128Shift
                 s0h := (s[0]>>32)*prime128Lower + (s[1]>>32)<<prime128Shift
                 // Carries
                 s1h += s1l >> 32
                 s0l += s1h >> 32
                 s0h += s0l >> 32
                 // Update the values
                 s[1] = (s1l & 0xffffffff) + (s1h << 32)
                 s[0] = (s0l & 0xffffffff) + (s0h << 32)

The expression you would use for a multiword shift should be directly detectable by the compiler. (It doesn't currently, but it should be straightforward.)

I think we might not need the intrinsic for multiword shiftright because we can create a pattern that can be detected by the compiler, something like this:
ShrQconst(42, z[5], z[4]) -> (z5<<22 | z4>>42)

I think AddQQ and AddQW have uint128 inputs, not uint64.

Yes, AddQQ takes two uint128 i.e two pairs of uint64 and outputs the result to uint128(hi, lo) and AddQW takes a uint128 and uint64 and outputs the result to uint128(hi, lo).

Sorry, I jumped the gun and assumed we have a consensus on math/bits as the right package for the APIs and took a stab at it in CL106376. My sincere apologies.

I strongly disagree about putting these in math/bits: these are not operations on bits. They may involve operations on bits, but ultimately so does everything.
I really do not want to see math/bits turn into a junk drawer.
The proposed operations are a new class of operations and they deserve their own package for ease of discovery, to make reading code that uses these operations clear, and so that they can have focused documentation.

I don't see a need for both AddQW and AddQQ.  AddQW(x1, x0, y) = AddQQ(x1, x0, 0, y).  The compiler should have no problem constant folding the 0.  Just have a single Add.
In any case, I don't like Q and W.  What do they stand for?  (quadword and word?  That makes no sense here.)

I agree with @jimmyfrasche.
I think math/big makes some sense. They are "big" integers, just not arbitrarily big, but still bigger than uint64.

Agreed on just having Add (and Mul) and detecting constant 0. Let's not leak the instruction names.
They definitely don't fit in math/big. I see the concern for math/bits becoming math/intrinsicutils, but I am not convinced that any other package name would grow past two functions, or have the same issue. And this is about multiplication of high and low bits, even if it's a stretch.

BTW, @bmakam-qdt thanks for doing the prototyping work. It's very valuable even if the proposal is not finalized yet!

@josharian I didn't say coming up with a good name would be easy—just that it's the right thing to do :þ
Can methods be compiler intrinsics? A lot of the naming and documentation could be simplified if it were something like
type Uint struct {
  Hi, Lo uint64
}
func (a Uint) Mul(b Uint) Uint

Maybe then math/math128? The import stutters a bit and the name is slightly unwieldy but it would only be needed for the types and related factories. It could contain math128.Uint, math128.Int, and perhaps even math128.Float.
That's not a great name but hopefully it spurs a better one.

These can't be in math/big.  Personally I think math/bits is OK but I respect the objections.  math/math128 is not bad but sounds to me like a place for the 128-bit integer types, which isn't quite what this is.  It seems to me that we are going for is basically double word operations.  Unfortunately C suggests that double is a floating point value.  Perhaps math/wide?  wide.Mul?

FWIW, I also think they're not a good fit for math/bits since they're about integer semantics rather than the literal bits.
What does everyone think of math/intrinsic with the chance to handle future needs of this type there too?
package intrinsic

type Uint128 struct {
 Hi, Lo uint64
}
func Mul(a, b Uint128) Uint128

Perhaps math/wide? wide.Mul?

I like math/wide; it does double duty, because (a) the types are wide and (b) it evokes "widening arithmetic".
Is there any danger of wanting 256+ bit arithmetic anytime soon? If so, we might want Mul128. Or maybe Mul64, since the inputs are 64 bits?
cc @kortschak @btracey in case they want to weigh in from a scientific computing perspective. (This has all been crypto-oriented so far.)

I don't like math/intrinsic  it exposes implementation details of gc and by that logic we will need to move most of math/bits to math/intrinsic because we already intrinsify  most of it.
On an unrelated note what about 128-bit subtraction? Just express it as an add with -x?

I'm not sure the Uint128 type would let the kind of code this is for flow well. What is now x.Hi can later be something else and now you have to assign it a new name. And it might not play well with SSA (arrays don't). Let's not overcomplicate it, this is for so-low-level-that-it-was-going-to-be-assembly code.
No on math/intrinsic too, they won't be intrinsified everywhere, and it's a "utils"-like name.

(Another advantage to math/wide is that it makes it obvious where saturating arithmetic operations live, should we decide to add them later: math/saturate or maybe just math/sat.)

The biggest issues with math/wide is someone looking at the package index for the first time and thinking "wait, what's wide and what's big?" but the doc synopsis would cover that and that's good enough for me.
My main point with introducing the types is that it would allow the operations on those types to be namespaced so there wouldn't need to be MulU128, MullI128, MulF128, etc.—they could just be T.Mul(T) for T in {Int, Uint, Float}.

For naming, maybe math/split (as in, “a uint128 split into two uint64s”)?
But it seems like if this is worthwhile, we should just do #9455 instead. Intrinsics would require compiler support either way, and a built-in type is much more ergonomic (less risk of accidental transposition and more similarity to integer operations at other sizes).

Mul128, strict{Hi, Lo uont64} and such seem like a poor substitute for a uint128 type.

this is for so-low-level-that-it-was-going-to-be-assembly code.

How much faster is the assembly code? Usually in these packages writing assembly (for larger sequences) tends to expose other optimization opportunities as well.

@rsc This improved the performance of crypto/poly1305 by ~30% on arm64 (Amberwing). There is more optimization opportunity if we use neon/simd instructions.

I could see Add64 (64,64 -> 64,1) and Mul64 (64,64 -> 64,64), but beyond that I don't see much that's generally important. Hard-coding higher-level things like 64,64,64,64 -> 64,64 for 128-bit add seems like going too far.
My question was not how much faster it is to have intrinsics. It was how much additional speed you get from assembly compared to limited intrinsics.

Agreed on just having Add64 and Mul64.

how much additional speed you get from assembly compared to limited intrinsics.
Not sure if I understood this correctly, but if we don't intrinsify these intrinsics, the assembly version is >50% faster.

Based on discussion with @agl and @FiloSottile:
The argument for adding these is not so much for the mainline architectures where we have people to write assembly for larger operations, but instead for the less popular architectures, where intrinsics let us use portable code that executes faster. It sounds like the basic operations are:

func Mul64(x, y uint64) (hi, lo uint64)

func Mul32 not necessary because it's just 64-bit multiply

func Div64(hi, lo, x uint64) (quo, rem uint64)

func Div32 not necessary because it's just 64-bit divide

func Add64(x, y, carry uint64) (sum, carry uint64) // carry assumed to be 0 or 1

func Add32

func Add (uint)

func Sub64(x, y, borrow uint64) (difference, borrow uint64) // borrow assumed to be 0 or 1

func Sub32

func Sub (uint)

For shift it seems like pattern-matching is fine: L/R Shift 128/n -> 64 for example is(x<<n) | (y>>(64-n))
It would be nice to have, say, three specific algorithms to use as test cases and make sure that this set is useful. We don't want to add every last extra thing, but we do want to make sure it covers enough to help.
If someone can identify those algorithms, I'm OK with accepting this.

One good example is x/crypto/ed25519. It's currently a 32-bit implementation on all platforms. I have a 64-bit version with both pure Go and assembly math, and the mul64 emulation overhead makes the Go slower than the existing code. That should not be true, and intrinsic calls should fix it.

Also based on discussion with @rsc, these are going in math/bits.

x/crypto/poly1305 is another example that covers Mul64, Add64 and L/R Shift 128/n -> 64

@rsc What is the rationale for not including the uint-sized versions of Mul and Div as well?  Those are both internal primitives in math/big.
// A Word represents a single digit of a multi-precision unsigned integer.
type Word uint
func mulWW(x, y Word) (z1, z0 Word)
func divWW(x1, x0, y Word) (q, r Word)

We did not include the 32-bit ones as they are easily implemented with uint64, but I agree that the uint sized ones would be good to have anyway.

@rsc @FiloSottile is this accepted? It sounds so from rsc comment but the tag wasn't set.
Also please notice this CL:
https://go-review.googlesource.com/c/go/+/91755
that introduces runtime.mul(x,y uint64) (uint64, bool), based on discussion in other issue which I cannot find now... /cc @martisch

Can't runtime.mul be implemented by pattern matching
hi, lo := bits.Mul64(x, y)
carry := hi != 0

instead?
I think that between runtime, poly1305 and ed25519 we have enough examples
to start prototyping this.
On Sun, May 13, 2018 at 3:22 AM Martin Möhrmann<EMAIL_ADDRESS>wrote:

The issue for runtime.mul is: #21588
https://github.com/golang/go/issues/21588. The use case there is to
avoid costly overflow checks involving devisions or table lookups for
runtime arithmetic when allocating e.g. slices/channels/maps ... . I think
checking the overflow can be easier and more efficient than carrying out
the whole wide mul/add operation and checking the result. Both issues
likely share some backend/ssa work and could alias some of the same
intrinsics and approaches.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/24813#issuecomment-388606879, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABKyTqQ30hxugWIjwDQ2ZftSunyCTIRYks5tx98dgaJpZM4TQzez
.

Can't runtime.mul be implemented by pattern matching
It can but it if its for performance it should not actually carry out the wide multiplication but just check e.g. the overflow flag of the normal multiplication and support the native int size without specifying 64 or 32 bit mul. Runtime would need to be whitelisted to import bits as currently some sys functions are just aliased to the same intrinsics with bits.

https://go-review.googlesource.com/c/go/+/91755 is kind of a prototype for the runtime multiplication overflow check. I am (and others) just not happy that it needs to introduce a new instruction in the ssa backend and would rather it worked by combining the existing mul instruction with an existing flag checking setCC instruction on amd64. This also would lead to optimization rules being able to apply more broadly and not dealing with another Op.

Revising my comment from May, the proposal is to add these to math/bits:
// Add with carry
// The carry inputs are assumed to be 0 or 1; otherwise behavior undefined.
// The carryOut outputs are guaranteed to be 0 or 1.
func Add(x, y, carry uint) (sum, carryOut uint)
func Add32(x, y, carry uint32) (sum, carryOut uint32)
func Add64(x, y, carry uint64) (sum, carryOut uint64)

// Subtract with borrow
// The borrow inputs are assumed to be 0 or 1; otherwise behavior undefined.
// The borrowOut outputs are guaranteed to be 0 or 1.
func Sub(x, y, borrow uint) (difference, borrowOut uint)
func Sub32(x, y, borrow uint32) (difference, borrowOut uint32)
func Sub64(x, y, borrow uint64) (difference, borrowOut uint64)

// Full-width multiply: 32x32->64, 64x64->128
func Mul(x, y uint) (hi, lo uint)
func Mul32(x, y uint32) (hi, lo uint32)
func Mul64(x, y uint64) (hi, lo uint64)

// Full-width divide: 64/32 -> 32,32, 128/64 -> 64,64
// Behavior undefined if hi >= x (because quotient will not fit).
func Div(hi, lo, x uint) (quo, rem uint)
func Div32(hi, lo, x uint32) (quo, rem uint32)
func Div64(hi, lo, x uint64) (quo, rem uint64)

Compared to my earlier comment, I've added uint-sized Mul and Div to complete the set. It looks odd not to do so, especially if one is interested in writing efficient code that doesn't assume a particular size of int/uint. We still don't need 8-bit or 16-bit versions of these since all platforms have uint at least 32 bits, so those can be implemented in terms of uint (or uint32) operations.
It's fine to add a pattern match in the compiler to allow Mul32 to be implemented as
func Mul32(x, y uint32) (hi, lo uint32) {
	z := uint64(x)*uint64(y)
	return uint32(z>>32), uint32(z)
}

but Mul32 should still be included, for the same reasons we included bits.RotateLeft: having the API allows for clearer code and avoids bugs caused by the magic sequence being written over and over. (My first attempt at writing that code typoed to z>>3, for example.)
For now we will leave out shift, because there's not one agreed-upon meaning for a double-precision shift and it's easy to write clear, correct, efficient code for the meaning needed in a given context. (In contrast, it is tricky or tedious or both to write add/sub/mul/div correctly.)
Dropping Proposal-Crypto label, because this should be considered at the main proposal review meeting. I think this has come up often enough and the meaning well-understood enough that we could decide to add these for Go 1.12 without needing crypto benchmark results. It also matters for #25819.

@rsc I think we need also a signed version for mul and div, as those cannot be easily implemented using the unsigned version.
Also what about division by zero? Would that panic?

@rasky Do you have a use case for the signed versions?

Any case where signed multiplication is used in computer science could benefit from having a stable low/hi API. I sometimes work with geometry and signal processing, for instance, and on ARMs you don't always have a FPU so using fixed points is an option. With a 32-bit fixed point, you need a 32x32->64 multiplication.

Proposal accepted per @rsc's comment https://github.com/golang/go/issues/24813#issuecomment-398096235 -- iant for @golang/proposal-review

Porting musl's fma implementation to Go required Mul64 as well. Here is a possible full-width multiply implementation.
// Mul returns the high and low bits from the product of x and y.
func Mul(x, y uint) (hi, lo uint) {
	if UintSize == 32 {
		hi32, lo32 := Mul32(uint32(x), uint32(y))
		return uint(hi32), uint(lo32)
	}
	hi64, lo64 := Mul64(uint64(x), uint64(y))
	return uint(hi64), uint(lo64)
}

// Mul32 returns the high and low 32 bits from the 64-bit product of x and y.
func Mul32(x, y uint32) (hi, lo uint32) {
	z := uint64(x) * uint64(y)
	return uint32(z >> 32), uint32(z)
}

// Mul64 returns the high and low 64 bits from the 128-bit product of x and y.
func Mul64(x, y uint64) (hi, lo uint64) {
	var t1, t2, t3 uint64
	xlo := uint64(uint32(x))
	xhi := x >> 32
	ylo := uint64(uint32(y))
	yhi := y >> 32

	t1 = xlo * ylo
	t2 = xlo*yhi + xhi*ylo
	t3 = xhi * yhi
	lo = t1 + (t2 << 32)
	hi = t3 + (t2 >> 32)
	if t1 > lo {
		hi += 1
	}
	return hi, lo
}

I have a prototype of the extended precision operations over at github.com/smasher164/extprec. All the implementations are adapted from "Hacker's Delight", and the relevant references are provided.
However, it still needs real test cases in order to hammer out any possible bugs. I've only tested it with random hand-picked values.

The above CL ports the go versions of these functions from math/big since those are previously tested.  Additional SSA rules will still need to be implemented as this just handles the simple Mul and Div cases for amd64 and arm64 that are used in math/big.

Really tiny nitpick. Wouldn't it make more sense to have func Div(hi, lo, y uint), instead of func Div(hi, lo, x uint)? Because in all other functions, x is the first  operand and y the second one. hi and lo are 128-bits of the first operand so maybe an y would be more descriptive.

I was curious about this, so I cherry-picked the relevant CLs on top of current Go master and have some preliminary results from my Ed25519 field arithmetic. bits.Mul64 got me about halfway to the speed of an assembly implementation without much effort. I suspect I could make the pure Go a bit faster as well, but haven't tried yet.
Rough benchmarks on a Kaby Lake laptop (i7-7560U @ 2.40GHz):
$ benchstat old32 bits64
name             old time/op  new time/op  delta
KeyGeneration-4  48.5µs ± 0%  33.9µs ± 2%  -30.22%  (p=0.004 n=5+6)
Signing-4        49.6µs ± 1%  34.8µs ± 2%  -29.84%  (p=0.002 n=6+6)
Verification-4    133µs ± 1%    93µs ± 3%  -29.81%  (p=0.002 n=6+6)
$ benchstat bits64 amd64
name             old time/op  new time/op  delta
KeyGeneration-4  33.9µs ± 2%  24.9µs ± 0%  -26.36%  (p=0.001 n=6+7)
Signing-4        34.8µs ± 2%  25.9µs ± 0%  -25.70%  (p=0.001 n=6+7)
Verification-4   93.2µs ± 3%  60.5µs ± 0%  -35.06%  (p=0.002 n=6+6)
$ benchstat old32 amd64
name             old time/op  new time/op  delta
KeyGeneration-4  48.5µs ± 0%  24.9µs ± 0%  -48.61%  (p=0.003 n=5+7)
Signing-4        49.6µs ± 1%  25.9µs ± 0%  -47.87%  (p=0.001 n=6+7)
Verification-4    133µs ± 1%    61µs ± 0%  -54.42%  (p=0.002 n=6+6)

If anyone else is interested in playing with this, it's this code and this Go.

@gtank your mul64 function (which is actually a mad64 AFAICT) should use bits.Add to implement double word-add:
func mul64(accLo, accHi, x, y uint64) (ol, oh uint64) {
 	oh, ol = bits.Mul64(x, y)
        ol, carry = bits.Add64(ol, accLo, 0)
        oh, _ = bits.Add64(oh, accHi, carry)
 	return
 }

at some point that should get turned into ADD+ADC, which would probably get you another boost compared to assembly.

Should this issue be closed now that CL 123157 has been merged in?

Maybe? @randall77, are there plans to intrinsify more of this?

Only Mul has been intrinsified so far.
I think we want Add/Sub intrinsified also (or better, recognize the Go code and generate the add-with-carry instruction).
That said, those tasks don't need to live in this issue, which is more about API. If concerned people can open issues for their architecture, we can close this issue.

Okay, closing.


Category association still shows up in items' "Edit Item Details" screen when categories have been disabled

When you have previously created categories, then gone back and disabled categories and weighting, you will still see the category association (as well as all of the category dropdown options) in items' "Edit Item Details" screens.

Ah good catch. Will fix. I think this was just going off the assignment itself having a category.

Confirmed.


Release for latest telemetry support

Would it be possible to cut a release so telemetry ~1.1 is officially supported?

Maybe prom_ex should actually require ~> 1.0, not ~> 1.0.0.

To add some detail, the latest release does not include #131, so it's not possible to add prom_ex (which depends on telemetry ~> 1.0.0) to a project that is using telemetry ~> 1.1

#193 is merged in so the next release should allow newer versions of telemetry


Perl code generation: dependencies replaced incorrectly.

Summary: Perl code generation, when using custom child widget classes (which introduce dependencies), generates incorrect code.  The first time the source is generated is fairly innocuous.  The second time creates a syntax error in the source file that prevents it from compiling/running.
Version & Platform Info:

Windows 10 Pro, 64-bit, version 1703
Python 3.6.2
wxPython 4.0.3
wxGlade 0.8.3

Steps to reproduce:

Start wxGlade.  In Application Properties, set:

Separate file for each class
Language: Perl
Keep user code: Yes
Output path: C:\temp\wxGladeText (e.g.)

Add a frame to the application.  Leave its class name as MyFrame.
Add a Notebook control to the frame.
In Notebook Properties, set the class name to "MyNotebook".
Generate code for the project.
Look at the generated file MyFrame.pm.  Notice that there are some duplications.  At the top of the file, there's a "use Wx" line, a "use strict" line, and a "wxGlade: dependencies" section.  Then, below the "package MyFrame" line, there's another "use Wx" line (with a different import list), another "use strict" line, and another "wxGlade: dependencies" section.  This is not exactly an error; the program will run just fine this way, but it may be a clue to the next problem.
Go back into wxGlade.  Generate code again.
Look at MyFrame.pm again.  It's mostly the same, but the second "wxGlade: dependencies" section has been replaced with the line
<153496587857908771602565wxGlade replace MyFrame dependencies>
which is a syntax error, preventing the program from running.

Workarounds:

Delete MyFrame.pm before each time you generate code.
Manually remove one of the "wxGlade: dependencies" sections.  This seems to fix the problem longer-term.

Thanks for reporting.
Of the two sections that are generated in the first run, which one is the one that is correct?
use Wx qw[:allclasses];
use strict;
# begin wxGlade: dependencies
use MyNotebook;
# end wxGlade

# begin wxGlade: extracode
# end wxGlade

package MyFrame;

use Wx qw[:everything];
use base qw(Wx::Frame);
use strict;

# begin wxGlade: dependencies
use MyNotebook;
# end wxGlade
```

Or is the one from a single file code generation the best one?
use Wx qw[:allclasses];
use strict;

# begin wxGlade: dependencies
# end wxGlade

# begin wxGlade: extracode
# end wxGlade

package MyNotebook;

use Wx qw[:everything];
use base qw(Wx::Panel);
use strict;

The first one is more correct.
In Perl, "use Foo qw(symbols)" loads the Foo module, and imports the specified symbols into the current namespace (which is declared via the "package" directive).  So in both cases, the first "use Wx" line is superfluous:  It loads the Wx module (good) but then imports the ":allclasses" symbol set into ... no package namespace.  The second "use Wx" line correctly appears after the "package MyWhatever" line, and so the specified symbol set (":everything", which I believe is a superset of ":allclasses") is imported into the package--- which allows those symbols to be used later.  Loading Wx in both places isn't exactly wrong, it's just slightly wasteful.
The "wxGlade: dependencies", similarly, probably ought to occur after the "package" line, but most class libraries do not export symbols, so 99% of the time it's not a real problem, I think.

So this would be the correct header (also moved extracode to the end, where it is e.g. for Python)?
package MyFrame;

use Wx qw[:everything];
use base qw(Wx::Frame);
use strict;

# begin wxGlade: dependencies
use MyNotebook;
# end wxGlade

# begin wxGlade: extracode
# end wxGlade

Yes, that would be correct!

In the source code, there was already a comment "# TODO: Don't add dependencies twice with Perl".
I have left this as it is, but the bug should be gone now in the master branch.

I can confirm that the latest commit of the "master" branch (14e52066ac2bc458db6ca0765e1afb6bcf86ab69, as of 2018-10-16 13:36) does not exhibit the bug behavior described in point 8 of my original report.  So that's good!  Thank you.

0.9.0a1 is available


Consider adding Area column to Sensors list

Really like how 1.5 is shaping up!
Just a thought as I was adding sensors to an area - it isn't immediately apparent at a glance which currently configured sensors are assigned to specific areas. Maybe an additional column between Arm Modes and Enabled?

Entity
Arm Modes
Area
Enabled

vehdoor contact
Away
Garage
True

front door
Away
Home
True

Or some implementation of the dropdown selects you use in other places?
Just a thought. Great work on this.

100% agreed on this one.
Just wanted to push out the beta to get some feedback for the final touches.
In the areas view there’s already a summary of assigned sensors and automations, ideally I want to make them links that bring you to a filtered view of the sensor/actions pages.
This would probably go well with a dropdown on the top for filtering by area, and highlighting sensors which are unassigned.
Stay tuned for more and let me know if you have more ideas 🙂

100% agreed on this one.
Just wanted to push out the beta to get some feedback for the final touches.
In the areas view there’s already a summary of assigned sensors and automations, ideally I want to make them links that bring you to a filtered view of the sensor/actions pages.
This would probably go well with a dropdown on the top for filtering by area, and highlighting sensors which are unassigned.
Stay tuned for more and let me know if you have more ideas 🙂

Hi,
Small update on this.
On the sensors + actions page I added filter buttons:

On the areas page I added shortcuts to these filters:

It should look the same for you if you update to the v1.5.0 (non-beta) release 👍

Hi,
Small update on this.
On the sensors + actions page I added filter buttons:

On the areas page I added shortcuts to these filters:

It should look the same for you if you update to the v1.5.0 (non-beta) release 👍

Nice! That should work a treat - I’ll update tonight!

Nice! That should work a treat - I’ll update tonight!


Permissions error after upgrading to 0.18.1

Describe the bug
A clear and concise description of what the bug is.
I'm using the docker image from ghcr.io/donkie/spoolman:latest.  I rebooted the docker host, and upon restart, I'm getting (this may be similar to #382, but I believe I have version 0.18.1 that is supposed to fix the permissions error, which was for different files anyway):

INFO:     Started server process [1]
INFO:     Waiting for application startup.
spoolman.env               WARNING  Data directory is not writable, trying to fix it...
chown: /home/app/.local/share/spoolman/cache/materials.json: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/filaments.json: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/hishel/.gitignore: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/hishel/7092233f1b6dfd51f4c1d26c6e64c49a: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/hishel/4203b6c338b99a0428310bad4f723b5d: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/hishel: Operation not permitted
chown: /home/app/.local/share/spoolman/cache/hishel: Operation not permitted
chown: /home/app/.local/share/spoolman/cache: Operation not permitted
chown: /home/app/.local/share/spoolman/cache: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.db: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db.5: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db.1: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db.4: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db.2: Operation not permitted
chown: /home/app/.local/share/spoolman/backups/spoolman.db.3: Operation not permitted
chown: /home/app/.local/share/spoolman/backups: Operation not permitted
chown: /home/app/.local/share/spoolman/backups: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log.2024-06-04: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log.2024-06-03: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log.2024-06-02: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log.2024-06-06: Operation not permitted
chown: /home/app/.local/share/spoolman/spoolman.log.2024-06-05: Operation not permitted
chown: /home/app/.local/share/spoolman: Operation not permitted
chown: /home/app/.local/share/spoolman: Operation not permitted
spoolman.env               ERROR    Data directory is not writable. Please run "sudo chown -R 1000:1001 /path/to/spoolman/datadir" on the host OS.
ERROR:    Traceback (most recent call last):
  File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 677, in lifespan
    async with self.lifespan_context(app) as maybe_state:
  File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 566, in __aenter__
    await self._router.startup()
  File "/home/app/spoolman/.venv/lib/python3.11/site-packages/starlette/routing.py", line 654, in startup
    await handler()
  File "/home/app/spoolman/spoolman/main.py", line 117, in startup
    env.check_write_permissions()
  File "/home/app/spoolman/spoolman/env.py", line 374, in check_write_permissions
    sys.exit(1)
SystemExit: 1
ERROR:    Application startup failed. Exiting.

In the host, the files are owned by userid docker, group docker, which is UID 1001, GID 1002.  In the docker environment, I've specified
PUID=1001
PGID=1002

Running chown -R 1000:1001 * in the host data directory does fix things, but shouldn't be necessary I don't believe.
To Reproduce
I'm not sure; I'm not sure why I'm seeing this now as opposed to with version 0.18.0.
Expected behavior
Specifying PUID and PGID in the environmental variables should allow it to access the files.
Spoolman Host (please complete the following information):

Installation type: Docker
Installed version: 0.18.1
OS and Distro: Ubuntu
Database type: SQLite

Desktop (please complete the following information):

OS: [e.g. Windows, Mac, iOS, Android, ...] N/A
Browser [e.g. Chrome, Firefox, Safari, ...] N/A

Additional context
Add any other context about the problem here.

Seems to me like your PUID and PGID settings are not being applied correctly to your container, I just tried myself to change them in the environment section of the docker compose, and the sudo chown command it suggests in the error gets the same PUID and PGID values that I set, e.g. for you it should look like:

But by checking your log it's infact telling you to set it to "1000:1001"


Transparent window on macos

Objective

Example transparent_window doesn't display a transparent window on macOS
Fixes #6330

Solution

Set the composite_alpha_mode of the window to the correct value
Update docs

relevant bevy issue: #6330

This works for me. (M1, MacOS 13.1)
Am I right that this is baking the current workaround into the example, and that there's still some wgpu issue affecting this?


Youtube changes broke current Pytube version

It looks like pytube is broken again due to changes made on the Youtube side. The fix is allegedly queued up at https://github.com/pytube/pytube/pull/1282 but it still needs to be merged. Once a new release is cut, update our dependency version.

[x] #32
[ ] Switch to the new official release once available

Well, I've taken care of all of the other issues on this milestone, but the merge request for the pytube fix has not been merged yet, nor has a release been cut. I was originally planning on waiting for the new release, but I may need to take action to pull from a temporary source with these changes sooner.

The PR was merged and a new pip version of pytube was cut. We should update our fork and switch back to the pip version. If another issue like this comes up, we can always move back to the fork.

This has been fixed, and we have updated to the newest official pytube pip package.


Adding filter InclusiveLevelFilter for cases when it should log DEBUG…

logger := l4g.Global
logger.AddFilter(stdout, ERROR, ...) // logs ERRORS and above
logger.AddInclusiveLevelFilter(stdout, DEBUG, ...) // logs only DEBUG
// in total, it supposed to log ERRORS and above, and DEBUG

This seems like you are trying to solve a problem outside the scope of a logger.  Why would you want to log anything ERROR and above and DEBUG?  That sounds like your log message levels are just incorrect.  This should not be merged.


[WIP] Introduce Test Policy

This will allow to test matcher error messages

Almost 100%, also found a couple of improvements to messages

I cannot understand if it is possible to have a negated message failure for

forbid_actions
permit_actions
forbid_mass_assignment_of
permit_mass_assignment_of

without arguments

Blocked by #57

Now blocked by #66

Coverage report generated for RSpec to /Users/geremia/dev/pundit-matchers/coverage. 362 / 366 LOC (98.91%) covered.

The only four lines that I wasn't able to test are related to empty arrays and the negated matcher

Excellent work. We're now in a much better position when it comes to code coverage, which will make future improvements to the implementation safer.
Based on the discussion in #30, I think we were in agreement about disabling negated matchers as way of simplifying the implementation, unless there's a better proposal.

Ah, it was easy
return false if attributes.count < 1

With a negated matcher, this will return true and so there should not be the possibility to have that error with a negated matcher


Extremely poor performance

The owner of @atom-community here. This package destroys Atom performance when you type. Please remove the feature that causes this until the issue is fixed.
If you don't maintain this package anymore, please make the package empty, register a new version (so the current users upgrade to it), and then unpublish it. Atom users think that the issue is Atom itself, while it is this package.
I have attached the CPU profile:
CPU-20210207T150604.zip

@mrhanlon

@MarcPorciuncula Not sure if you're still maintaining this. If not I can deprecate the package.

Please make the package empty before deprecating in a major version change. This fixes Atom for the current installers of this package.

@mrhanlon I've moved on to VSCode so feel free to deprecate. Thanks

I made a PR deprecating the package: https://github.com/mrhanlon/less-than-slash/pull/62
You just need to run apm publish minor after mering it.

PR merged and version 0.20.0 published. Thanks!

Thank you! I will make sure to add it to the list of deprecated packages.


v0.8.8_06: Warning text is not aligned with X axis description

SEVERITY:  Minor
MODULE: Bubble chart
Platform:

Windows 7 / Chrome 48.0
Windows 7 / Firefox  43.0
MAC / Safari 9.0

RELEASE: v0.8.8
STEPS TO REPRODUCE:

Navigate to the URL : http://static.gapminderdev.org/vizabi/release/v0.8.8/preview/bubblechart.html
Bubble Chart will be loaded.
Note that warning text is not aligned with X axis description

ACTUAL RESULTS:
Warning text is not aligned with X axis description
EXPECTED RESULTS:
Warning text should align with X axis description
SCREENSHOT:

same thing as with "?", need to check alignment on different platforms

https://github.com/Gapminder/vizabi/pull/989


Replace JSONStream

I need to control the json parser. We could override it to serialize object with his type like mongoson.

Done.


HD Mint upgrades and fixes

Add "zapwalletmints" conf setting
Fixes for encrpytion of wallet - now storing all previous mints indexed by pubcoin hash
Various efficiency improvements
Code refactor
Use CMintMeta objects over CSigmaEntry when showing coins in GUI - this allows for data retrieval when wallet is locked (mint secret data is now part of the HDChain and so requires unlock to access) and means that we do not have to regenerate mints for every access
Add walletDB functions to get pairs of serial hashes and pubCoins (for easier regeneration of mint from chain)

Note that due to WalletDB updates, existing testnet HD Sigma mints (ie. those generated after the merge of https://github.com/zcoinofficial/zcoin/pull/392) will not be accessible. The amount of code required to be added to make these accessible is not worth the time at this point. Zerocoins and non-HD Sigma mints are unaffected by this.

@thebevrishot  @levonpetrosyan93 Updated to include fixes for your comments, please review.


multi_tap arbitrary distance support

Is there currently a way to have multi tap events fire regardless of finger distance? I tried editing some InputManager constants to no avail.
PS: thanks a ton for making this! if you're at all interested I can create a pull request for C# compatibility

Yes, setting FINGER_SIZE to infinity (or a large enough number) should do that.
I don't use C#, but feel free to create a PR for C# compatibility if you want! You would be the main maintainer of that C# support. Also see @tuto193 at https://gitlab.com/tuto193/godot-sharp-touch-input-manager as this is probably related.

Yes, setting FINGER_SIZE to infinity (or a large enough number) should do that. Please let me know if it worked so I can close this.
I don't use C#, but feel free to create a PR for C# compatibility if you want! You would be the main maintainer of that C# support. Also see @tuto193 work at https://gitlab.com/tuto193/godot-sharp-touch-input-manager as this is probably related.

that did it, thanks! I can close this for you.
Wow I wish I knew that existed before I went about struggling with how C#/gd interop works 😅 but I'm better for knowing it.
I just ended up piggy-backing off your GD script, which I think is for the best - that way there's a single source of truth. Once I feel like it's ready for prime-time, I'll make a PR!