Modified to set to calculate the initial value of g:NERDTreeWinSize.

The initial value of g:NERDTreeWinSize is hard-coded, but not put the direct specific numerical value, the person who has been calculated by WindowSize I tried to fix it I think not to match in many cases

This is an interesting idea but it has some flaws:

If you resize the vim window then the setting will be wrong
It fits the use case where you have the tree open all the time - but people who open the tree and then close it after switching files may not prefer this.

For now I will not pull this. I will reconsider if other people ask for this to be the default setting.
FYI, there is nothing stopping you from having this functionality by putting
let g:NERDTreeWinSize = (&columns / 5)

in your vimrc.
You might want to try something like this:
let g:NERDTreeWinSize = (&columns / 5)

autocmd vimresized * call s:updateNERDTreeSize()
function s:updateNERDTreeSize() abort
    let g:NERDTreeWinSize = (&columns / 5)
endfunction


Automatically set "Regressed By" field or needinfo regression author on fuzzing bugs with a regression range found by bugmon

Fixes #1455
Checklist

[x] Type annotations added to new functions
[ ] Docs added to functions touched in main classes
[ ] Dry-run produced the expected results

Here's the dry run's results:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1647332'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1679601
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1653556'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1645120
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1639161'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1649668
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1567330'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1772557
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1726626'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1678217
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1577238'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1766472
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1734997'}
2022-06-10 13:15:39,131 - INFO - The bugs: 1655519
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1617863'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1689065
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1673497'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1649439
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1341507'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1679478
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1641268'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1752122
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1726626'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1684829
will be autofixed with:
{'comment': {'body': ':mgaudet, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}
2022-06-10 13:15:39,132 - INFO - The bugs: 1671957
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1658416'}
2022-06-10 13:15:39,132 - INFO - The bugs: 1730574
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1727008'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1673649
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1597968'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1649479
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1572627'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1649568
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1632724'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1660160
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1614496'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1658753
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1614499'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1638857
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1038294'}
2022-06-10 13:15:39,133 - INFO - The bugs: 1684832
will be autofixed with:
{'comment': {'body': ':mgaudet, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}
2022-06-10 13:15:39,133 - INFO - The bugs: 1684104
will be autofixed with:
{'comment': {'body': ':mgaudet, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}
2022-06-10 13:15:39,133 - INFO - The bugs: 1754699
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1753633'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1659729
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1630819'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1771253
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1726626'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1656517
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1653556'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1683625
will be autofixed with:
{'comment': {'body': ':mgaudet, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}
2022-06-10 13:15:39,134 - INFO - The bugs: 1683708
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1646224'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1693054
will be autofixed with:
{'comment': {'body': ':pehrsons, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}
2022-06-10 13:15:39,134 - INFO - The bugs: 1659713
will be autofixed with:
{'comment': {'body': 'Setting regressed_by field after analyzing regression range found by bugmon.'}, 'regressed_by': '1614499'}
2022-06-10 13:15:39,134 - INFO - The bugs: 1679598
will be autofixed with:
{'comment': {'body': ':glandium, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?\nFor more information, please visit auto_nag documentation.\n'}, 'flags': [{'name': 'needinfo', 'requestee'<EMAIL_ADDRESS>'status': '?', 'new': 'true'}]}

BugSummary

1772557

          Hit MOZ_CRASH(called `Option::unwrap()` on a `None` value) at /third_party/rust/wgpu-core/src/id.rs:151

1771253

          Hit MOZ_CRASH(called `Result::unwrap()` on an `Err` value: Custom("Invalid bits for ShaderStages")) at gfx/wgpu_bindings/src/server.rs:514

1766472

          Assertion failure: !isInList(), at /dom/webscheduling/WebTaskScheduler.cpp:77

1754699

          Assertion failure: self == DOM_PRIVATE_VALUE, at shell/js.cpp:10338

1752122

          Hit MOZ_CRASH(out of memory: 0x0000000000000060 bytes requested) at /memory/mozalloc/mozalloc_abort.cpp:35

1730574

          Assertion failure: !mContent || !mContent->GetParentElement() || HTMLEditUtils::IsBlockElement(*mContent) || HTMLEditUtils::IsBlockElement(*mContent->GetParentElement()) || !mContent->GetParentElement()->IsEditable(), at /edi

1693054

          Assertion failure: mRawPtr != nullptr (You can't dereference a NULL RefPtr with operator->().), at /builds/worker/workspace/obj-build/dist/include/mozilla/RefPtr.h:315

1689065

          Assertion failure: cx_->hadNondeterministicException(), at jit/WarpOracle.cpp:188

1684832

          Assertion failure: this->flags() == 0, at js/src/gc/Cell.h:764 or Crash [@ Interpret] with --warp-async

1684829

          Crash [@ js::gc::ArenaCellSet::check() const] with warp generators

1684104

          Assertion failure: this->flags() == 0, at gc/Cell.h:764 or various crashes with --warp-generator

1683708

          Hit MOZ_CRASH(assertion failed: self.font_size.map_or(true, |f| f == font_size)) at servo/components/style/rule_cache.rs:29

1683625

          Assertion failure: isRunning(), at vm/GeneratorObject.h:140 --warp-async and classes

1679601

          Hit MOZ_CRASH(assertion failed: self.next < self.max_depth_ids) at gfx/wr/webrender/src/gpu_types.rs:52

1679598

          Assertion `valid()' failed in src/gl.cc:388

1679478

          Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Could not get DocShell from mFrameLoader?), at /builds/worker/checkouts/gecko/dom/base/nsObjectLoadingContent.cpp:550

1678217

          Hit MOZ_CRASH(assertion failed: bytes.len() >= finish as usize) at gfx/wr/webrender/src/texture_cache.rs:1788

1673649

          Assertion failure: index >= 0, at /builds/worker/workspace/obj-build/dist/include/mozilla/RangeBoundary.h:207

1671957

          Assertion failure: mObservers.IsEmpty(), at /builds/worker/checkouts/gecko/dom/gamepad/GamepadPlatformService.cpp:33

1660160

          Assertion failure: !JS_IsExceptionPending(cx_), at /builds/worker/checkouts/gecko/js/src/vm/JSContext.h:1119

1659729

          Assertion failure: !mInStyleRefresh, at /builds/worker/checkouts/gecko/layout/base/RestyleManager.cpp:3144

1659713

          Assertion failure: mNotLost != nullptr, at /builds/worker/checkouts/gecko/dom/canvas/ClientWebGLContext.h:754

1658753

          AddressSanitizer: SEGV /builds/worker/checkouts/gecko/dom/canvas/XRWebGLLayer.cpp:182:44 in mozilla::dom::XRWebGLLayer::Antialias()

1656517

          Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Transition effect has unexpected shape), at /builds/worker/checkouts/gecko/dom/animation/CSSTransition.cpp:333

1655519

          Assertion failure: !Exists(), at /builds/worker/workspace/obj-build/dist/include/mozilla/MozPromise.h:1375

1649668

          RustMozCrash [@ webrender::spatial_tree::SpatialTree::get_relative_transform]

1649568

          Assertion failure: !aAncestorLimiter || aContent.IsInclusiveDescendantOf(aAncestorLimiter) (aContent isn't in aAncestorLimiter), at /builds/worker/checkouts/gecko/editor/libeditor/HTMLEditUtils.h:489

1649563

          Assertion failure: !childNIF || mFrames.ContainsFrame(childNIF) || (pifEOC && pifEOC->ContainsFrame(childNIF)) || (oc && oc->ContainsFrame(childNIF)) || (eoc && eoc->ContainsFrame(childNIF)), at src/layout/generic/nsContainerFrame.cpp:3151

1649479

          Assertion failure: isAzimuthGood, at /builds/worker/checkouts/gecko/dom/media/webaudio/blink/HRTFPanner.cpp:147

1649439

          Assertion failure: !map->mIsSameDirection, at /builds/worker/checkouts/gecko/layout/generic/nsGridContainerFrame.cpp:1668

1645120

          Assertion failure: aTextNode.Length() >= aStartOffset + aLength, at /builds/worker/checkouts/gecko/editor/libeditor/ReplaceTextTransaction.h:53

1638857

          Assertion failure: mMainMaxSize >= aNewMinSize (Should only use this function for resolving min-size:auto, and main max-size should be an upper-bound for resolved val), at /builds/worker/checkouts/gecko/layout/generic/nsFlexContainerFrame.cpp:654

I'm going to file a follow-up to support needinfoing multiple people.

I'm going to file a follow-up to support needinfoing multiple people.

Filed #1475.


wip: play-scala-isolated-slick-example

Currently having issue with Slick code generation. This is probably because slick doesn't support Scala3 and therefore cannot generate Scala3.

In order to run the migration, you will need one of the latest version of flyway. Unfortunately, flyway-sbt still use version 7.4.0, I've manually updated the plugin in this pr: https://github.com/PeuTit/flyway-sbt/pull/1.


add dynamic graph doc description and chart

a BUG of github: "This branch cannot be rebased due to too many changes"
https://github.com/orgs/community/discussions/51612


proposal: Go 2: remove dot imports from the language

This issue is broken out of #29036.
We should remove dot imports from the language (import . "path").  Quoting @rogpeppe:

The official guidelines suggest that a dot import should only be used "to let the file pretend to be part of package foo even though it is not". This is a stylistic choice and strictly unnecessary. The tests can still use package-qualified names with only minor inconvenience (the same inconvenience that any external user will see).
Other than that, I believe the most common use is to make the imported package feel "close to a DSL". This seems to be actively opposed to the aims of Go, as it makes the programs much harder to read.

While experimenting with https://github.com/golang/go/issues/20104 just a few days ago, dot imports were incredibly useful—instead of having to plumb a bunch of context through complicated code generation scripts and carefully conditionally adjust a dozen format strings, I could just dot import ssa in the relocated files. Long term, I would choose to do the work to eliminate the dot import. But it was very helpful as scaffolding. And not just for experimentation: the dot import is a single line change for reviewers, whereas qualifying every package use would have made the diff unreadable (and unrecognizable to git as a file move).

Other than that, I believe the most common use is to make the imported package feel "close to a DSL".

Yes, this is what Goa does; which is used by a lot of people. If we remove dot imports, the entire package will break.
I have no issues either way. Just wanted to point this out.

I can't agree more

I think, why do't import file level ,replace import package, just like ptyhon。
Is that a better way ??

I think, why do't import file level ,replace import package, just like python.
Is that a better way ??

Although dot imports are a feature which should be used sparingly, I can't see the sense in banning them altogether.
There are definitely occasions when they are useful for testing and experimentation and there are some other reasonable uses as well - see for example https://github.com/golang/lint/issues/179.
I often use them myself when importing the math package, so I can just write  Cos instead of math.Cos.  Admittedly this isn't the greatest of use cases but, for me at least, there is no risk of confusion as I would never use the names of math functions as public names in my own packages.

As per mentioned in https://github.com/golang/go/issues/29036#issuecomment-443259313

I've found dot-imports to be useful when writing tests. For instance:
package mypack_test

import . "github.com/deanveloper/mypack"

// ...

I wouldn't really mind the dot-import being removed. I was just adding my particular use case for them.

And to reiterate, I wouldn't mind dot-import being removed. It's just what I use them for.

Most of the popular programming language use some form of "dot import" without any hassles. Hows ftm.Printf is more clear then simple print or echo?

Tests are a great argument for removing dot-imports. I've seen lots of tests that failed to catch extremely redundant identifiers, because the tests and examples didn't include the package name as everyone else would.

At first glance math seems like a great argument for not removing them, but then consider functions like Jn, Y0, and Log: the former two are somewhat obscure, and the latter could easily collide with a similarly-named function in another package. I could see a reasonable argument for dot-importing trigonometric functions and rounding functions, but math overall seems like a bit of a stretch.

Hmm now that I think of it, I feel like I've heard a lot of this stuff before. I feel like this might be a duplicate, but I searched for proposals of removing dot imports but didn't find anything

Dot imports make your code lie.  That's Bad.
When you write AssertEqual(t, got, expected) and your current package doesn't have an AssertEqual function... that code is lying.  If you're reading that in a code review (i.e. not in an IDE with hover text etc), you would not be crazy to think AssertEqual is some function in the current package.
Also, if you then copy that code to a different file in the same package... it will fail to compile, and there's nothing goimports can do to figure out where AssertEqual comes from.  So you have to Just Know™ where it comes from and add the import yourself.  That's bad, too.
I don't believe DSLs of the type made popular in dynamic languages such as python and ruby belong in Go.  Those languages specifically give you tools so that you can make non-native functionality look like native functionality.  Those languages intentionally let you play fast and loose with types and what the code actually does when you type foo += bar can be vastly different depending on what foo and bar are.   Go is not that language.  foo += bar will always be simple to understand in Go.  There's only a couple things it can possibly mean.
DSLs sacrifice clarity of what the machine is doing for clarity of what the code says.   That's not Go's way.  You should not need external context to understand where an identifier comes from and what it is calling or doing.

Maybe the proposal should be "flag dot imports with go vet"?
@ianlancetaylor and others have asserted that Go2 shall not break existing code except where unavoidable for essential new features.

@ianlancetaylor and others have asserted that Go2 shall not break existing code except where unavoidable for essential new features.

This seems to be his proposal, haha. I think that if there's a consensus that a feature is actively harmful that it should be considered for removal. IIRC Russ Cox (maybe it was Rob Pike) have talked about removing shadowing once if we get the check keyword.

Assignment redeclaration would also be flagged by Go2 vet :-)

For now, yes, but what I was trying to say is that a full removal of a feature is something we have already considered (and seem to still be considering, looking at this proposal). Saying that significant members "have asserted that Go2 shall not break existing code [...]" makes it sound like feature removal is something that shouldn't even be listened to, rather than something we'd rather not do.

@deanveloper I should clarify that although I opened the issue, it's really @rogpeppe 's proposal.  I split out of #29036 to clarify that issue.
Personally I'm somewhat against this proposal because I don't think the benefit of clearer code is worth the cost of breaking existing packages.  But I'm willing to be convinced otherwise.

I literally just learned about dot imports last week, and have been looking forward to using them in the future, mostly for the handful of random helper functions which can typically be isolated to one package. That way I can write more compact code that uses those helper functions and the code would be easier to reason about for me or anyone who pays attention to the imports.
Idea: If you want to do away with dot imports, consider allowing only one dot import per file?

For the record, the reason I bundled this issue up with #29036 was that it's necessary to do this if we want to make all imported symbols predictable, which is, I believe a useful property to have globally.
I sympathise with the use of dot imports in @josharian's scenario, but I see it as somewhat of a niche case, which surely could be addressed with a little more additional tooling to make it easier to package-qualify chosen identifiers in generated code. Getting git to recognize diffs of files that move between packages is often a problem anyway. There are many such cases where code is refactored and the diffs are large because the package qualifiers change. I see that as the more general problem here, and dot-imports aren't a good solution in most such cases.
In short, I think that the readability advantages of having properly qualified identifiers everywhere outweigh the occasional extra burden of adding the qualifiers.

I am currently using lxn/walk which has a declarative package for defining forms.
Removing the "." import would brake ALL EXISTING code that uses this package.
And I personally would be very angry having to write "declarative.Button" instead of "Button".
I would have to write the name of the package several thousand times to be exact.
That is not my idea of making code more readable, seems to be more an idea of enforcing restrictions for which I see not a point that they should exist.  The original designer who created the dot-import was correct in providing this functionality.
On the other hand, every programmer should also have the common sense to NOT have multiple dot-imports in the same GO-source.  Because as long as there is only one dot-import it is PERFECTLY clear as to where the methods and types belong.
I would even go further to request that the intellisense of "Visual Studio Code" be improved to understand this.

"I would even go further to request that the intellisense of "Visual Studio Code" be improved to understand this."

Just FYI, GoLand already supports auto-complete on dot imports.

And I personally would be very angry having to write "declarative.Button" instead of "Button".

I agree with this in general with Go. There are a lot of cases when I really wish I could forgo having to prefix with a package name.  I know this is a tangent but it would be great if we could define an alias like so:
type Button alias declarative.Button
Another thing that would be great is if Go would assume the same package when other members of the package are passed in to a func call with a simple dot prefix, e.g. instead of this:
forms.ShowDialog("Do you want to close?" forms.Yes, forms.No, forms.Cancel)
It would be great if Go assume the follow was equal to the previous:
forms.ShowDialog("Do you want to close?", .Yes, .No, .Cancel)
I'll be happy to break these two requests out into new tickets assuming I get positive reactions from those on the Go team.

I agree with this in general with Go. There are a lot of cases when I really wish I could forgo having to prefix with a package name. I know this is a tangent but it would be great if we could define an alias like so:
type Button alias declarative.Button

type Button = declarative.Button
works, but will give you an exported symbol, you can always do
type button = declarative.Button
if you don't want that
See https://golang.org/ref/spec#Alias_declarations

@ianthehat  Interesting. Clearly I did not know that. Thank you!
(So much still to learn about Go...)

I would go with quite opposite. Let's say that you have multiple packages that implement "Client" struct. That's most cases in my experience.
In code I can use multiple of them. For example:
httpClient,err := http.Client(http.MethodGET, URL, parameters) ... cacheClient,err := redis.Client(config.RedisConnenctionString) ... cloudWatchLog,err := logging.Client(config.AWSSdkCredentials) ... sqlClient,err := mysql.Client(config.SqlDbConnectionString)
We could use builders and define NewHttpClient(params).Build(), NewCacheClient(params).Build()... or we could do it manually in code what would make project code grow.
In code you're seeing what you're touching - don't need to make additional import aliasing. Don't see solution for that. Calling variables and base on that variable name? That would be unwise.

@mateuszmmeteo

"I would go with quite opposite"

Even after reading your code it is not clear to me what you are suggesting.

Calling variables and base on that variable name? That would be unwise.

How would it be unwise if the rule is the following?

"Any parameters prefixed with a simple dot (.) would inherit the package of the func being called."

As proposed it is 100% unambiguous.

@mikeschinkel

@mateuszmmeteo

"I would go with quite opposite"

Even after reading your code it is not clear to me what you are suggesting.

Calling variables and base on that variable name? That would be unwise.

How would it be unwise if the rule is the following?

"Any parameters prefixed with a simple dot (.) would inherit the package of the func being called."

As proposed it is 100% unambiguous.

In my example you would be required to write:
httpClient,err := .Client(http.MethodGET, URL, parameters)
...
cacheClient,err := .Client(config.RedisConnenctionString)
...
cloudWatchLog,err := .Client(config.AWSSdkCredentials)
...
sqlClient,err := .Client(config.SqlDbConnectionString)

Do I understand you correctly?

@mateuszmmeteo
No, that is not what I proposed.  My proposal would not be applicable to your example.
Examples that would be applicable, by searching for examples in the Go SDK:
Currently:
f,err = os.Open(os.DevNul)
http.Handle("/tmpfiles/", http.StripPrefix("/tmpfiles/", http.FileServer(http.Dir("/tmp"))))
out = strings.ReplaceAll(strings.ReplaceAll(strings.TrimSuffix(out, "\n"), " ", ""), "\n", " ")

Using proposed:
f,err = os.Open(.DevNul)
http.Handle("/tmpfiles/",.StripPrefix("/tmpfiles/",.FileServer(http.Dir("/tmp"))))
out = strings.ReplaceAll(.ReplaceAll(.TrimSuffix(out, "\n"), " ", ""), "\n", " ")

To clarity:

os.Open() means you can drop os. from .DevNul
http.Handle() means you can drop http. from .StripPrefix
http.StripPrefix() means you can drop http. from .FileServer
strings.ReplaceAll() means you can drop strings. from .ReplaceAll
The 2nd strings.ReplaceAll() means you can drop strings. from .TrimSuffix

Is that clearer?

I'm still thinking about interfaces and multiple implementations that you can use as parameters but yes, looks good.

@mikeschinkel I think your proposal is pretty different than what @rogpeppe had in mind. If you’d like to pursue it, please open a new issue so we can keep the threads distinct. One question you could answer there is: Given a.F(b.G(.X)), is X from package a or b?

@mikeschinkel I think your proposal is pretty different than what @rogpeppe had in mind. If you’d like to pursue it, please open a new issue so we can keep the threads distinct. One question you could answer there is: Given a.F(b.G(.X)), is X from package a or b?

when X is conflict there, we can add the package prefix.

@josharian  Thank you, I will.
Answering your question: package b

if you don't want that
See https://golang.org/ref/spec#Alias_declarations

To follow up, after trying it, this addresses my envisioned use-case:
type (
    Button = declarative.Button
)

I post it here in case people in the future are googling for the same thing I wanted because your example did not work for me I almost did not realize there was an alternative.

That would break maaaany test based on gingko/gomega where dot import really makes huge change in readability of tests.
IMO that would be a huge step backward.

@jellonek Could you point to an example test file that we could experiment with to see what readability difference it makes?

Take a look on https://onsi.github.io/ginkgo/#adding-specs-to-a-suite or on real use in: https://github.com/containernetworking/cni/blob/master/libcni/api_test.go#L129
With dot imports that's close to normal human language description. Adding library name as prefix will simply disfigure this description.
Code like:
	Expect(err).NotTo(HaveOccurred())
	Expect(debugFile.Close()).To(Succeed())

is much more human friendly than:
	gomega.Expect(err).NotTo(gomega.HaveOccurred())
	gomega.Expect(debugFile.Close()).To(gomega.Succeed())

@jellonek Thanks for that code. I agree that the result won't look so "natural", but there's a trade-off here. Those two packages between them export more than 100 symbols. As an external reader of the code, it is really not clear which of those two packages are being referred to in any given case. For example, is Context something in gingko or gomega?
If either of these packages adds another symbol (as they're allowed to under backward-compatibility rules), it will break your code if that symbol clashes with one of the others.
There are two reasonable alternative approaches here:

shorten the import identifier by choosing a shorter one (for example, K or gk instead of gingko). Here's what the source code might look like using K and M or using gk and gm. I've been using this approach for a while with gocheck and quicktest and you get used to it pretty quickly.
define your own identifiers locally. This means you can write exactly the same code you're writing today, at the expense of a few more lines of definition. Here is an example for the identifiers you're using.

The case for these symbols is that you should not be interested from which package the symbol was imported, as it should be interpreted by the meaning of it's name.
Your first proposal is only trying to slightly polish the situation which is the effect of removing the functionality for which these test seems to me as a perfect use case.
Second - looks much better, but requires copying and copying and copying the same boilerplate to each package containing tests (ok, that can be tool assisted, also the tool can keep the list of used symbols). It's more reasonable, but a bit smelly...

The case for these symbols is that you should not be interested from which package the symbol was imported, as it should be interpreted by the meaning of it's name.

You could say that about all names in Go. Some languages, such as C, don't even have package namespaces. Go has made a different decision: it has decided that code is more readable when external names are unambiguously qualified with a package identifier.
In this particular case, we've got some very generic names, such as By and And. How is the reader of the code supposed to infer the "meaning" of such general purpose names without going to the package documentation?
You also haven't addressed the problem that would occur if one of those packages added a symbol that's a duplicate of one of the others.

Your first proposal is only trying to slightly polish the situation which is the effect of removing the functionality for which these test seems to me as a perfect use case.

I'm afraid I can't parse this sentence.

Second - looks much better, but requires copying and copying and copying the same boilerplate to each package containing tests (ok, that can be tool assisted, also the tool can keep the list of used symbols). It's more reasonable, but a bit smelly...

Less smelly than importing an arbitrary set of remote symbols into the local namespace IMHO. I understand your use case, but I don't think it's worth the language compromise.

Case with name duplication was too virtual to be responded, but ok - these packages are carefully maintained and developed together, so such clash would be found/eliminated on their level, before this code could reach my code.
But lets look on that from wider perspective (it can be hard, as English is not my native language and looks from above example that like we can have an issue with that) - ginkgo/gomega are only examples of using dot imports to provide own kind of DSL, where the domain is tests. Same approach could be used (idk if it is already) in other specific domains.
So the question is - do we want to make golang more strict, more pure, or do we want to keep elasticity, having in mind that elasticity always at the end will be abused. What gives us more benefits.
Btw. your point about being non sure to which package the particular symbol is associated is valid only when one is reading the code in some kind of dumb viewer, which does not have functionality of "go to definition". Especially when it's done without understanding the environment in which such code exists (in this case - without being familiar with used DSL).
So again - we can make golang more strict, more sharp, but we should be aware that we are entering the path already faded by python maintainers, which "improved" the language ignoring that there was an user base which were (and are still) using the language in a way which do not follows maintainers "vision".

As it is now, I see a lot of live (closed source) production code where, in conjunction with the go Chi router,  a single Unicode identifier ' χ'  is used for convenience. I find this less readable than a dot import. DSL's are meant to be accessible, often also for non-programmers, for whom the prefix means nothing and is a visual hinderance. For this particular use case, I think dot imports are essential and convenient.

Look here, As a professional user I forbid this change !!!
Stop changing syntax every day based on idealistic theoretical ideas that make no sense.
GOlang has already been poisoned enough with those thousands of new compilation warnings of the last year !!!!
ENOUGH IS ENOUGH stop that foolish theoretical bickering that destroys backward compatibility.

Please don't use emotional tone. That does not help in discussion.

I see the forbiddance of "DSL" code based on dot imports as a feature of this proposal rather than a downside. And the upside from #29036 seems significant.

What is the recommendation for users of DSL libraries like avo and Goa ? Shortening the import identifier does not feel elegant and re-defining identifiers is not scalable because depending on the code, the user needs to add/remove new identifiers.
A huge (guessing from the popularity of these libraries) amount of code will break if we accept this proposal. Seems like a significant cost to pay given the benefit it gives.

Defining local short names for remote names works reasonably well for C++ code. I found a random example from an Abseil test here.
It also works reasonably well in JS's shiny new module system (and similarly in TS). I found a random example from Angular's codebase here.
To be clear, I'm not endorsing everything about these examples, or saying that Go should switch to using this model (I actually think using a single short identifier for external packages is actually a great trade-off). But as a replacement for dot-imports, it seems clear to me that having local short aliases for long names can work in practice.
I think the major downside for this solution would be that it "reexports" these new identifiers (assuming you capital case them). So it is fine in tests, but suboptimal in non-test code.

@agnivade imo the most reliable would be to add a boilerplate file to each package which will define local alias for all used identifiers (maybe all from library) in similar way as @rogpeppe proposed in this example.

Code like:
	Expect(err).NotTo(HaveOccurred())
	Expect(debugFile.Close()).To(Succeed())

is much more human friendly than:
	gomega.Expect(err).NotTo(gomega.HaveOccurred())
	gomega.Expect(debugFile.Close()).To(gomega.Succeed())

@jellonek
I think this is a matter of opinion.  I found this thread after encountering ginkgo/gomega for the first time.
If you are using vim for example and are unfamiliar with this library there is no way to know where to look for a function named Expect.  I found it difficult to read.
I use an IDE I just don't think the features provided by them ought to be a consideration in evaluating the readability of a language, so I use vim above as an example.

I'm vim user - just try https://github.com/fatih/vim-go and use "gd" (go to definition) ;)

The tension in the discussion so far appears to be between the purported ease of use of DSLs enabled by dot imports vs the lack of clarity of the source of symbols that said dot imports cause.
The main issue that I see with dot imports is that it imports all symbols. This is analogous to star imports in Java, which are (mostly) disallowed by most style guides, precisely because of the lack of clarity. If we were to extend the analogy, Java side steps the issue of clarity with individualized imports (both static and non-static).
As @balasanjay suggested, I think we can strike a balance here to satisfy both camps. This of course would work best if Go could provide a way to not reexport the symbols. I came up with two ideas to solve this issue but have not put any thought into the larger consequences for either.
The first is to mimic the Java import strategy and allow for imports of individual symbols from a package. This might look something like import "path/to/package:symbol_to_import". As a side note, I considered not using the / character to delimit the package from the symbol as wiser and thus chose the : character to mimic Bazel. This would allow you to use symbol_to_import directly without qualifying it with the package name. Depending on which camp you're in, you might see the inability to "rename" symbol_to_import to something shorter as an advantage or disadvantage.
The other idea is to use C++ style "using" statements to declare a local non-exported short name. This might look something like using ShortName = package.SomeReallyReallyPerhapsUnnecessarilyLongName. This idea is really close to the type alias concept which might cause confusion.
I personally would hate to lose the ability to develop or use DSL style APIs in Go. I think that if we were to remove dot imports (which seems like a good idea), providing an alternative solution for the provided use cases would be great.

You can already refer to specific symbols using type aliases or const or var declarations.  Those work for everything other than package-scope exported variables, which are not the common case.
For example:
import "fmt"
var Printf = fmt.Printf
func F() { Printf("%s\n", "hi") }
type Stringer = fmt.Stringer

That is, I don't see much benefit to adding support for importing explicit symbols, since we can already inject explicit symbols in the current package scope.

That is, I don't see much benefit to adding support for importing explicit symbols, since we can already inject explicit symbols in the current package scope.

Totally agree. The only issue with your example code is that the symbols Printf and Stringer are re-exported. This can obviously be avoided by changing the names to printf and stringer, but explicit symbol imports would have the advantage of not being re-exported while keeping the same name. To be clear, I'm not necessarily proposing that these changes should be made. I'm only proposing ideas for discussion assuming that the Go team wants to make a change to address some of the concerns brought up in this thread.

Well, I have a situation where I was thinking of using dot imports and found this thread.
My use case is the following. I have a logger package that encapsulates the zap logger  where I do some initialization logic.
// Logger The application logger
var Logger *zap.Logger

func SetupLogger() {
	if Config.Env == "dev" {
		Logger, _ = zap.NewDevelopment()
	} else {
		Logger, _ = zap.NewProduction()
	}
}

If I want to use my Logger, I would need to call logger.Logger which is ugly. Using a dot import solve this problem.
Not sure if there is a cleaner way.
I don't like global variables at all and my inner brain says I should use DI, but I am also trying to be pragmatic and for things like logging and configuration which needs to be accessed everywhere in the application, I am debating if it´s worth injecting all the way down to the data layer or use a global.
Just my 2 cents.

To have some shared code between tests, that shared code could be placed inside a package, so those other test suites can import it.
 Let's call this package apispecs. This package has these two dot imports:
. "github.com/onsi/ginkgo"
. "github.com/onsi/gomega"

Now that shared spec, package apispecs, can be imported by different tests, in different packages.
Having a warning, without a way to suppress it (something similar to what is provided for _ imports - by providing a comment), is both a cognitive load and a setback for the tooling (it's constantly visible on your IDE, for example, and makes the warnings something not important - in time).

The only solution that came to my mind, was aliasing (or wrapping) everything in dot-imported packages (maybe not exactly everything, and they should be obviously public, but details are ignored here for the sake of conversation, and usually, the public surface that has to be covered, is not exactly small).

@codeblooded
In you linked code, it is an anonymous import, not the dot import talked in this thread.

I am not happy that this issue still receives new debate.
If this option is removed that it destroys one of the greatest things in GO and it will break ALL MY EXISTING commercialized code!!!
As software developer this raving lunatics idealistic must-must-must goes not well by me.
There is a good reason why it is part of GO and that some do not which to use it is their decision but I fail to see the need to enforce their misconceptions on the entire world.
This topic is not open for discussion any longer so close it and please finally decide AGAINST this idiotic request.
Please end this topic!

This can be viewed as feature remove. If your go.mod  file specifies an old version in the go directive, then the old code will still compiles by using the newest Go toolchain.
And go fix will help you transit without much effort.

Maybe it’s time to fork Golang project…?

If this issue is accepted, I will name all my dsl packages ᣟ, to be able to get a short, almost invisible import name again. With my excuses to the Canadian Aboriginals.
It goes like this:
ᣟ.go:
package ᣟ

import "fmt"

func Yes() {
	fmt.Printf("yes\n")
}

ᣟ_test.go:
package ᣟ_test

import "applied-maths.com/bnxt/platform/ᣟ"
import "testing"

func TestYes(t *testing.T) {
	ᣟ.Yes()
}

@StephanVerbeeck Please be polite and respectful and follow the Go Community Code of Conduct.  Thanks.

@ianlancetaylor I think we should advance this issue through the proposal process more rapidly. It's been open for over 2 years now without making much progress and this for a feature of Go that is already widely used.
However, as we can see from the emoticon poll and the various discussions, there is no consensus over this issue neither in favor or against it. Perhaps it's time to apply the rule from https://github.com/golang/proposal  "If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves."?  Or should this proposal be placed on "hold"?

@beoran This is an incompatible change, so it follows a different process, one that admittedly tends to move more slowly.  This is indicated by the Go2 label.

@ianlancetaylor I see, I didn't know that. how is the Go2 process different? I looked around and I could find #33892 as the umbrella issue that is tracking this, but not a formal description of the go2 process.  Is that different process already formalized and written down anywhere, and if so could you refer us to it, so we can have an idea of how this issue will progress?

It's a much more casual process, since the bar for incompatible changes is much higher.  We haven't tried to formalize it.

I guess the problem most programmers have with dot-import is not the principle.
Rather I guess they have issues with the fact that code intellisense does never implement it (not working in visual studio code) so Go-users consider the dot-import to be broken while it is rather the code intellisense that is broken.
It is indeed a nuisance that goto-definition is not working for these where this is clearly a decision of the implementor to ignore this because he/she himself/herself is not using it.
So maybe the solution to this topic is to finish the last 10% work rather than undoing the working 90%.

Rather I guess they have issues with the fact that code intellisense does never implement it (not working in visual studio code) so Go-users consider the dot-import to be broken while it is rather the code intellisense that is broken.

I use intellisense and goto-definition, but as a matter of principle I don't think advanced features of any IDE should be relied on to solve code readability issues caused by dot imports.

Just installed GO 1.16.2
Nothing compiles anymore!
So much for the promise of reverse compatibility!
Every release I have to wade through shitloads of changes that force me to rewrite my code!
Who is legally responsible for this disaster that I can sue for the bill this time???

@StephanVerbeeck please file a new issue with concrete details. I’m going to hide your comment here—and mine as well—as neither is germane to dot imports.

The problem why it does not compile is dot-imports (being the title of this topic).
That you decided that is was of topic is a self-delusion based solely on your wrong assumptions.
but don't botter.
This kind of replies (like from you) is all I get on this git forum.
You guys are only defending your errors and don't listen to customers.

If you feel insulted then maybe you got the point.
But my point is valid.
Van: "Josh Bleecher Snyder" @.>
Aan: "golang/go" @.>
Cc: "Stephan Verbeeck" @.>, "Mention" @.>
Verzonden: Donderdag 1 april 2021 13:32:19
Onderwerp: Re: [golang/go] proposal: Go 2: remove dot imports from the language (#29326)
[ https://github.com/StephanVerbeeck | @StephanVerbeeck ] please file a new issue with concrete details. I’m going to hide your comment here—and mine as well—as neither is germane to dot imports.
—
You are receiving this because you were mentioned.
Reply to this email directly, [ https://github.com/golang/go/issues/29326#issuecomment-811844744 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AJT5MQMPUI3SCWWYO5NBMTTTGRKUHANCNFSM4GLEW6OA | unsubscribe ] .

@StephanVerbeeck with regard to the comment that you wrote and then deleted:
(1) I want to help. In order to help, I need concrete details. Please share some.
(2) Even if your issue does pertain to dot imports, the correct place to start discussing it is in a new issue.

I find dot imports extremely useful in internal packages.
Given a package A:

A/B and A/C contain implmenetations of interfaces defined in A.
A/internal contains utilities used by A, A/B and A/C
A/internal/test contains test utilities used by A_test, A/B_test and A/C_test
A/internal/test/shared contains test utilities used by A/B_test and A/C_test

The dependency graph looks like this (LHS is the (sub-)package, RHS are the dependencies)

A -> { A/internal }
A/B -> { A, A/internal }
A/B_test -> { A/B, A/internal/test, A/internal/test/shared }
A/C -> { A, A/internal }
A/C_test -> { A/C, A/internal/test, A/internal/test/shared }
A/internal -> { }
A/internal/test -> { A/internal }
A/internal/test/shared -> { A }

For example, see the following package with such structure (A being pkg/networkserver, and A/B being pkg/networkserver/redis)
https://github.com/TheThingsNetwork/lorawan-stack/tree/bb0f4c7cc2c8c71efe4140ac9078cfb2ee1ddba2/pkg/networkserver
While importing A/internal as internal makes sense in implementation code, importing A/internal/test and A/internal/test/shared with names makes less sense and probably requires aliases to avoid clashes with e.g. external pkg/test. Dot imports make this way cleaner and clearer

Instead of removing 'dot import', consider adding compiler option to incorporate custom coding style spec. Each project will compile with those spec which allow or restrict 'dot import' or anything else.

Go is a beautiful language, because it gives developers a lot of freedom, while having strict guidelines and principles. Its ecosystem is also what makes go so special.
Very neat internal utilities can be created using dot imports, allowing skilled developers to write small modules that can almost act as extensions of the Go builtins; this allows very succinct code to be written. I don't see why the support for these would need to be removed in future Go versions. Is there a concrete technical or functional reason for it, or is it purely based on principle ?
A language, fundamentally, allows its speakers to communicate effectively and conveniently. Intervening and removing something that is convenient for some speakers is totalitarian, and should almost never be done, and even when done, it should only be with extreme care.
I understand that removing dot imports would make some Go project contributors happy, but, just like in general you wouldn't ban a syntax or word entirely from the English language (or any language whatsoever), you shouldn't ban some syntax from a programming language either.
I sincerely hope that this proposal will get rejected, as it doesn't add anything to anyone, except appease some purists who, frankly, just need to look at the imports a bit, and hover their mouse over function names in their IDE.

I understand that Go's development team wants to be simple and clear. However, everyone who is a programmer has their own style and you should not force people to code their code the way you want. I think dot imports are very useful and avoid code clutter. Instead of removing this feature, you should allow it. The following warning should be removed.
should not use dot imports (ST1001) go-staticcheck

The following warning should be removed.
should not use dot imports (ST1001) go-staticcheck

I don't think this warning should be removed. There already is a way to disable this warning for specific modules/packages in staticcheck. See dot_import_whitelist for more info on this.
I would lean towards keeping the status quo on this. At the moment, it's the best compromise: it's discouraged (this pleases the ones in favor of removing dot imports) but allowed (this pleases the ones in favor of keeping dot imports.)
How it's currently being done at the moment is a flexible approach that still puts forward the Go guidelines.

One use-case I thought about and that I almost went and tried today is allowing for a package to expose an API with different implementations via build constraints.
So depending on the build tag, a package implementation would differ.
Not unlike aliasing but coarser. Is this a relevant use-case?
Another case of adding a layer of indirection to solve a problem? ;o)

I am ok with not having those in Go v2, but let me share my usage about dot import currently.
I have GraphQL on front side and SQL on DB side.
I would like share Enums which type defined like this, for example.
type Role string

const (
	RoleAdmin  Role = "admin"
	RoleEditor Role = "editor"
	RoleUser   Role = "user"
	RoleGuest  Role = "guest"
)

With dot import it is really convenient you can just use RoleAdmin or RoleGuest on both layer,
and it is much easier for code generations, which does not need to know details or receiver/pkg's type.
Also having those in separate package, you can import from anywhere without worrying about cyclic imports.
You may think that I should use Role as Int, but that is another story.

It's clear that there are people using dot imports today, including the standard library.  Banning dot imports today would break those users.  The advantage of banning dot imports is cleaner code.  But there are many ways to write code that is hard to understand, and dot imports are just one way.  So this proposal isn't worth doing, at least not by itself.  Closing.


Support for zoom factor

How can I add support for zoom? When editing a small area will be useful to zoom the area.
I both tried using CSS zoom/transform(scale) but during mouse operations (click, drag, ecc.) coordinates are not anymore correct...

Sorry, have no ideia what this refers to


fix(sdk): let value grants override attr grants

If both a value and its attr have a grant assigned, only use the value grant.
Closes #1329

I'm not sure I can approve/attest to the split strategy and tests of different key types, but these lines look good to me regarding a value grant having specificity over a definition grant: https://github.com/opentdf/platform/pull/1318/files#diff-23ebbe4ac8b2e6c1b319e2927a1e6bd56e3dc0aa79e8c7324ee989f423aeef7dR233-R239


Gradle plugin portal submission rejected multiple times

Hi! We have received multiple submissions to the Gradle plugin portal for the net.smoofyuniverse.dependency-exporter plugin. Unfortunately, we could not accept them due to some validation errors. However, we've sent rejection emails with the errors and the steps to correct them. I'm opening this issue to verify whether you've received the emails.

Hi, I receive your emails, except one time when I got rejected without email but every other times I got them. I wasn't sure if I could reply to your emails as I thought it was a semi-auto process.
I tried to prove ownership one time with TXT record:
name : gradle and value : gradle-verification=FAF11932481C7948C769D4818E6F2
And a second time with:
name : gradle-verification and value : FAF11932481C7948C769D4818E6F2
Each time I've waited more than 1 hour before submitting (the TTL of my records) but none worked.
Maybe I've done something wrong. If you accept, I can also send you a mail from admin @ smoofyuniverse . net to prove ownership.

The verification is done manually at the moment. Receiving an email from you from the smoofyuniverse domain should be sufficient.


wildcard listener support

closes #273 #178
adds support for wildcard listeners and also deals with listeners being added and removed from the gateway.
Should work locally. To try it out create a gateway with two listeners 1 none wildcard and 1 wildcard. Attach httproutes.
DNS should be set up for the wildcard and none wildcard and TLS should be set up with a wildcard cert.
Remove one of the listeners, the dns and tls should be cleaned up
Note this updates us to go 1.20 also
Verficatation
Create a gateway with a wildcard listener
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: prod-web
  namespace: multi-cluster-gateways
  labels:
    cluster.open-cluster-management.io/placement: http-gateway
spec:
  gatewayClassName: kuadrant-multi-cluster-gateway-instance-per-cluster
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: wildcard
    hostname: '*.cb.hcpapps.net'
    port: 443
    protocol: HTTPS
  - allowedRoutes:
      namespaces:
        from: All
    name: specific
    hostname: 'specific.cb.hcpapps.net'
    port: 443
    protocol: HTTPS

Attach a HTTPRoute to the wildcard and specific listener
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: echo2
spec:
  parentRefs:
  - kind: Gateway
    name: prod-web
    namespace: kuadrant-multi-cluster-gateways
  hostnames:
  - api.cb.hcpapps.net
  rules:
  - backendRefs:
    - name: echo
      port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: echo2
spec:
  ports:
    - name: http-port
      port: 8080
      targetPort: http-port
      protocol: TCP
  selector:
    app: echo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
        - name: echo
          image: docker.io/jmalloc/echo-server
          ports:
            - name: http-port
              containerPort: 8080
              protocol: TCP

create a DNSPolicy
apiVersion: kuadrant.io/v1alpha1
kind: DNSPolicy
metadata:
  name: prod-web
  namespace: multi-cluster-gateways
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: prod-web
    namespace: multi-cluster-gateways

validate certificates and dnsrecords are present for both listeners and that the endpoints a reachable via the wildcard listener.
Remove a listener
remove the wildcard listener and the records and certificates should be cleaned up.
^ Currently adding to tests to cover this

next step is to look at improving and fixing the existing tests

When this merges it would probably be worth mentioning to people they need to be on go 1.20+.

/approve

/lgtm


Reduce about 4% CPU cost on Intel Core i7 processor

 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.michael seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@Michael-Lfx Can you agree to the CLA, please? We can't pull your PR in unless you do so.

Without the CLA in place, we can't accept this PR.
I implemented these changes separately and compared them against the existing implementation using the following test code:
uint32_t rrCnt = 1e7;
uint64_t rrStartTime = mvkGetTimestamp();
for (uint32_t i = 0; i < rrCnt; i++) {
	mvkDev->retain();
	mvkDev->release();
}
printf("[mvk-trace] Time for %d retain/release cycles: [%.1f ms]\n", rrCnt, mvkGetElapsedMilliseconds(rrStartTime));

I didn't find any consistent difference in performance beyond differences due to noise. I attribute this to a good implementation of atomic ++ and -- in the STL.
However, I DID find a consistent 30% improvement by inlining the retain() and release()functions, which I've included in PR #928
During testing, I also didn't find any performance difference between using uint32_t or uint64_t for _refCount, so I've left it at uint32_t, since it saves 8-bytes per instance, as I described in my analysis in a note above.
I'm closing this PR. If it can be demonstrated that improvements can be found by changing the incrementing implementation, we can reopen.


Builtins that need infinite list support

[ ] #585
[ ] #598
[ ] #599
[ ] #600
[ ] #601
[ ] #602
[ ] #603
[ ] #604
[ ] ḣ (head extract)
[ ] y (uninterleave)
[ ] Y (interleave)
[ ] Þf (shallow flatten)
[ ] j flag (and in general all output joining flags)
[ ] ṗ (powerset)
[ ] ẇ (chunks)
[ ] Ġ (group run lengths, possibly?)
[ ] ȯ (a[b:], positive indices only)
[ ] Ḟ (every ath item of b)
[ ] Þs (slices of a skipping b items)
[ ] ⊍ (set xor)

set xor can't work on infinite lazy lists

set xor can't work on infinite lazy lists

Oh. Oops


Add Synchronizer APIs for USD/ZEC exchange rate

Note
This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation).  For more in-depth discussion of how we think about code review, please see Code Review Guidelines.

Author

[x] Self-review your own code in GitHub's web interface[^1]
[ ] Add automated tests as appropriate
[ ] Update the manual tests[^2] as appropriate
[ ] Check the code coverage[^3] report for the automated tests
[ ] Update documentation as appropriate (e.g README.md, Architecture.md, etc.)
[x] Run the demo app and try the changes
[ ] Pull in the latest changes from the main branch and squash your commits before assigning a reviewer[^4]

Reviewer

[x] Check the code with the Code Review Guidelines checklist
[x] Perform an ad hoc review[^5]
[ ] Review the automated tests
[ ] Review the manual tests
[x] Review the documentation, README.md, Architecture.md, etc. as appropriate
[x] Run the demo app and try the changes[^6]

[^1]: Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs.
[^2]: While we aim for automated testing of the SDK, some aspects require manual testing. If you had to manually test
something during development of this pull request, write those steps down.
[^3]: While we are not looking for perfect coverage, the tool can point out potential cases that have been missed. Code coverage can be generated with: ./gradlew check for Kotlin modules and ./gradlew connectedCheck -PIS_ANDROID_INSTRUMENTATION_TEST_COVERAGE_ENABLED=true for Android modules.
[^4]: Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit.
[^5]: In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass.
[^6]: While the CI server runs the demo app to look for build failures or crashes, humans running the demo app are
more likely to notice unexpected log messages, UI inconsistencies, or bad output data. Perform this step last, after verifying the code changes are safe to run locally.

Rebased on feature-2.2.0 to bring in Kotlin changes from #1532. I also migrated to the latest revision of the Rust crates, which includes bugfixes to ZIP 320 support.

Rebased on feature-2.0.0 and resolved conflicts in Changelog.

I just realised that this PR was also rebased onto the invalid feature branch state, which is now conflicting very badly after the feature branch state was fixed. I'll rebase this branch to fix.

Rebased on the now-fixed state of feature-2.2.0 to undo the merge conflicts.

Force-pushed to fix up a changelog entry that was incorrectly being added to the 2.1.2 section.

@HonzaR is that just what you see in the UI, or did you also confirm what happened to the actual transactions? The iOS issue is that the second transaction shows up in the UI as expired, but is actually mined.

@HonzaR is that just what you see in the UI, or did you also confirm that this happened to the actual transactions? The iOS issue is that the second transaction shows up in the UI as expired, but is actually mined.

It's just about UI. I can confirm that the transaction was mined and that I received the funds at the tex address.

I'm confused about @Milan-Cerovsky merging main into this branch instead of the feature-2.2.0 branch, as it now makes this PR harder to review. But also this PR has been hanging around way longer than I wanted it to, and AFAICT all the necessary changes for the USD/ZEC feature have been implemented and reviewed. So I'm going to merge this PR into the feature branch; any remaining changes should be made as individual PRs targeting the feature branch.


Support functions as values in the theme object

Hi, first of all, great work! My workflow improved a lot since I started using rebass and styled-system.
So, I'm experimenting with styled-theming to create themes with multiple modes/variants.
For example, for text color, I would have 2 variants (primary or secondary) for each mode (light and dark). Then, when styling a theme component, I just pass the function from styled-theming and the component will render the corresponding color depending on the theme's mode and the variant passed to the component.
In the example below, MyTextComponent will render with the #AAAABB color because the theme mode is set to light and the variant prop in the component is set to secondary:
import React from 'react';
import styled, {ThemeProvider} from 'styled-components';
import theme from 'styled-theming';

const textColor = theme.variants('mode', 'variant', {
  primary: {
    light: '#494949',
    dark: '#FFFFFF',
  },
  secondary: {
    light: '#AAAABB',
    dark: '#76767E',
  },
});

const MyTextComponent = styled.div.attrs({
    variant: 'secondary'
  })`
  color: ${textColor};
`;

export default () => (
  <ThemeProvider theme={{ mode: 'light' }}>
    <MyTextComponent>
      Hello
    </MyTextComponent>
  </ThemeProvider>
)

I'm also using rebass components, and I can already do something like this to use my textColor function:
import React from 'react';
import { Text as CoreText } from 'rebass';
import { textColor } from '../themes'

const Text = styled(CoreText)`
  color: ${textColor};
`

export default () => (
  <Text variant="secondary">
    Hello
  </Text>
)

But now I want to store the textColor function in ThemeProvider so I can better integrate everything. I'm not sure if this is already possible, so let me know if I'm missing something.
The way I'm trying to do it is to pass those styled-theming functions as values into the theme prop (as described here) so all my rebass components can access them without having to import the theme function everytime in each component:
// example theme.js

const textColor = theme.variants('mode', 'variant', {
  primary: {
    light: '#494949',
    dark: '#FFFFFF',
  },
  secondary: {
    light: '#AAAABB',
    dark: '#76767E',
  },
});

export default {
  mode: 'light',
  colors: {
    textColor,
  },
};

import React from 'react';
import styled, { ThemeProvider } from 'styled-components';
import { Text } from 'rebass';
import theme from './theme'

export default () => (
  <ThemeProvider theme={theme}>
    <Text color="textColor" variant="secondary">
      Hello
    </Text>
  </ThemeProvider>
)

I might not have a complete answer to the question here, but my initial thoughts are:

styled-theming seems like it's more intended to store values locally in a component, whereas styled-system is intended for storing all values in the theme
If you're switching mode at the ThemeProvider, why not switch the other theme values like textColor instead?
You might be able to achieve what you're going for with nested functional themes where the parent one switches the "mode"

Closing this since it seems out of scope for this library


Manual book is not work

I am playing on 1.18. server,  but manual is not working, and I cant craft everything but manual book i can, where is problem ?
MechConfig_v3.1.0
Mechanization_Datapack_v3.0.4
DatapackUtilities_v2.3.3
Mech_x32_addon_v2.1.0
and resourcepack on server work

Can you be more specific?
You said you can craft the manual but it isn't working; what does that mean? If you are opening the manual and getting a bunch of squares, it means you need to install the resource pack as well. That seems to be the most common manual issue.


Update manifest to v3

This PR includes updating the API from v2 to v3.
with the help of@mariogolden the api for cryptoscamdb.org/scams is also updated

I know it's kind of deprecated and I see most things coming to Metamask.
For non metamask users I think it's still a cool extension.

There's an error throw in the manifest (your js/service-worker.js is not defined).

Any chance you can commit that file also?


CASMINST-4319: Linting

Most files were just linted to remove superfluous leading and trailing blank lines, and adjusted to have the first line in the file be marked as the highest-tier heading. There were also a smattering of spelling, grammar, style, and other minor linting corrections.

Rebased


Ensure observations are not added multiple times

In our app we are calling addContentSubviewToTop: on the same subview multiple times (to move the subview to top). This was causing KVO observations to be added multiple times for the same subview. This guards against this situation to not re-configure and re-observe the subview.

@JimRoepcke Thanks again. I really appreciate your patches.


Check for valid coordinates

latitude is -90 to 90
longitude is -180 to 180

Nice! Now how do you think we can check for those coordinates? Using an if statement?
Something like...
if latitutde is > 90 then alert user


Change it so it says that it doesn't exist

It sends to a rick roll now, idk why

ok the magic man rtm and i saved v4.2.0 of the converter, so it's now on rtm's repo so it exists now :pog:


[Bug]: social media links are not working on clicking

Give a brief about the bug ✍
When we click on social media icons they are not redirecting to that particular social media platform
What is the expected behavior? 🤔
The icons should be clickable and redirected to desired page
Provide step by step information reproduce the bug 📄
I will add the paths of the social media website so it will enhance the UX and function properly
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

@Ridhima10 Please raise any other issue, because someone is already working on it...
If you have any doubt you can directly send message on our discord (https://discord.gg/rZb46cCMmK), we have created seprate chennals for all projects...
Thank you :)


Consistent page publication states

Show “modified on draft” on pages if any contained blocks are modified

Replaced with core GridField component https://github.com/silverstripe/silverstripe-framework/issues/7032


Thread local for storing the user store domain is not cleared properly. This can cause unnecessory NPEs

When the user is authenticated against the user store manager we are setting the thread-local user store domain. Using this method. However, it was not cleared.
Now in a flow where the user is not authenticated from the user store, (i.e. saml bearer grant, JWT bearer grant[2], Email OTP, TOTP, etc.) if we use the "createLocalAuthenticatedUserFromSubjectIdentifier" method[3] instead of "createFederateAuthenticatedUserFromSubjectIdentifier" it can cause intermitted NPE/strange issues due to it.
As a general practice, we need to clear the set thread-local variable during the same request flow from the same thread. Otherwise, this can cause other unidentified issues as well.
[1] - https://github.com/wso2/carbon-kernel/blob/c02225a1299da08ba938c32ec77eb4199af8c86d/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/util/UserCoreUtil.java#L434
[2] - https://github.com/wso2-extensions/identity-oauth2-grant-jwt/pull/42/files
[3] - https://github.com/wso2/carbon-identity-framework/blob/d8ebf42510163048971298e54d4e35c3901c9e67/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/model/AuthenticatedUser.java#L90

The concerned thread-local variable threadLocalToSetDomain is set and get via two utility methods from UserCoreUtil. In the codebase, there are multiple flows that sets this thread-local. The following shows the usages in wso2 and wso2-extensions organizations.

https://github.com/search?p=2&q=org%3Awso2+setDomainInThreadLocal&type=Code
https://github.com/search?q=org%3Awso2-extensions+setDomainInThreadLocal&type=code
Multiple usages in the current development kernel branch(4.6.x).
These usages are from the abstract user store manager, Post authn handlers, Request coordinators, Application authenticators, and carbon server authenticators.

The following shows the multiple flows that gets this thread-local.

https://github.com/search?q=org%3Awso2+getDomainFromThreadLocal&type=Code
https://github.com/search?p=2&q=org%3Awso2-extensions+getDomainFromThreadLocal&type=Code
Multiple usages in the current development kernel branch(4.6.x).
The usages again from the application authenticators, authentication handlers, utility methods which has additional usages apart from the listed ones, call back handlers, grant handlers, authentication handlers, etc.

Therefore it is difficult to actually find specific places where we could simply clear the variable in a particular request flow. For example, the user store domain name set by one of the user store managers, post authn handler etc could be used by the grant handler. It is complex and difficult to come up with a straightforward fix unless performing a full analysis about each available get method usecase. It becomes even difficult as in some scenarios like if we set the variable in one of the post auth handler intended to be used in a separate listener, but another post auth handler might un-intentionally use that value leading to an erroneous behaviour since it was not cleared still.
Therefore this issue needs a further detailed analysis on each usage of the thread local variable throughout the codebase and identify suitable safe solutions to clear it without breaking existing functionalities.

As per the offline chat I had with @mefarazath there is a fix made already regarding this issue.
https://github.com/wso2/carbon-identity-framework/pull/3357
With this, the thread-local is cleared for requests going through the Identity framework. Because in the fix, the request coordinator will clear the thread-local variable once authentication flow is concluded. Allowing listeners in the same request flow to use the variable(since it's the same request flow, the user store domain should be the same throughout) but immediately clearing it once flow is concluded.
What's remaining is the requests that are not going through the identity framework.  We need to check and fix those usages to conclude this issue.

This issue is not reproducible in IS 6.0.0-alpha3 pack. Please reopen the issue if you could reproduce it again


Add timestamp as object to database methods

Issue #, if available:
#1130
Description of changes:
Add timestamp as object to database methods
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-pDO66x4b9gEu
Commit ID: 9f6207ad58f466b89c74ffdec5a7ed131cbe0c47
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-pDO66x4b9gEu
Commit ID: 345ec11f3e9681d676e8dd57667c8223800e8ff9
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-pDO66x4b9gEu
Commit ID: 2bf4203ed55569a0ece3217b9c2884a00dd05f0c
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Expose /_stats on port 5984

Current & Expected Behaviour
Right now, you can access /_system and /_active_tasks on port 5984. However, access to /_stats is buried underneath /_node/<nodename>/_stats, which can be a hassle to get access to.
Hypothetical: you have a local metrics system that you want to be as close to "zero-config" as possible. Unless it is told what the local node's name is, it will be unable to track that machine's stats.

Actually, it turns out you can't access /_system on 5984. I have a different solution I'd like to propose, so I'm closing this issue out.


Revise show name links on observation page

Simplified name links to: "Others Like This", "Look-Alikes" and "Related Taxa" (= other species in the same genus).
Instead of creating the queries here, it just directs the user to an action to create the query.  Sort of "lazy" loading the queries.
Removed the observation counts from next to the name links.
I noticed some excessive db use in show_project.  Revised that a bit to make use of eager-loading to fix it.
While investigating eager-loading, I revised some of the misspelling and synonym stuff in Name to make it possible to take advantage of eager-loading.
Name#misspellings is replaced with a simple ActiveRecord relationship.
Name#synonyms is converted to using ActiveRecord relationships on Synonym model.  But that resulted in a whole cascade of revisions on the three synonyms modification methods (Name#clear_synonym, transfer_synonym and merge_synonyms).  This is super-tricky code.  But I think this version is cleaner.  And I fixed a bug that I noticed a while ago (some unused synonyms were not being deleted).
I'll cut this PR off at this point so that review won't be so difficult. Will build on it in another PR to continue to work on eager-loading.

Coverage decreased (-0.006%) to 92.656% when pulling<PHONE_NUMBER>e27b80fc5dcee49d3b0248e1f3467a on revise-show-name-links into 37655610a50d545f1945510954e0ad674de25635 on master.

Do you want to globally disable it?
On Wed, Oct 14, 2020 at 7:43 PM Jason Hollinger<EMAIL_ADDRESS>wrote:

@pellaea commented on this pull request.
In app/models/name/synonymy.rb
https://github.com/MushroomObserver/mushroom-observer/pull/691#discussion_r505130945
:

@@ -142,21 +129,27 @@ def clear_synonym

after 2:  1, 2, 3

def merge_synonyms(name)

Other name has no synonyms, just transfer it over.

if !name.synonym_id

 transfer_synonym(name)

This name has no synonyms, transfer us over to it.

elsif !synonym_id

 name.transfer_synonym(self)

Both have synonyms -- merge them.

(Make sure they aren't already synonymized!)

elsif synonym_id != name.synonym_id

 name.synonyms.each { |n| transfer_synonym(n) }

if !self.synonym && !name.synonym

Would it be at all possible to disable this cop? I think having the
unnecessary "self" in this method makes it much easier to understand.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/691#discussion_r505130945,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFB2GTPG2BONE2MK7D3SKZOUDANCNFSM4SRLYJKQ
.


Controller pod shuts down with no errors after start

Dear openwhisk team
After some time succesfully playing with the vagrant installation of openwhisk, now I am trying to setup a k8s cluster on google GKE, so far I have been able to deploy and connect all the components but the controller. It's pod stays in CrashLoopBackOff status. I have checked the logs and I found that after starting up and connecting to kafka and couchdb it apparently shuts down with no errors.
Could you please give me some help on what could be the reason?
Thanks in advance!

kubectl logs controller-0 --namespace openwhisk -f
[2018-06-05T11:04:37.293Z] [INFO] Initializing Kamon...
[INFO] [06/05/2018 11:04:38.096] [main] [StatsDExtension(akka://kamon)] Starting the Kamon(StatsD) extension
[2018-06-05T11:04:38.232Z] [INFO] Slf4jLogger started
[2018-06-05T11:04:38.292Z] [INFO] Starting remoting
[2018-06-05T11:04:38.508Z] [INFO] Remoting started; listening on addresses :[akka.tcp://controller-actor-system@<IP_ADDRESS>:2552]
[2018-06-05T11:04:38.510Z] [INFO] Remoting now listens on addresses: [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552]
[2018-06-05T11:04:38.538Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Starting up...
[2018-06-05T11:04:38.603Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Registered cluster JMX MBean [akka:type=Cluster]
[2018-06-05T11:04:38.605Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Started up successfully
[2018-06-05T11:04:38.689Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - No seed-nodes configured, manual cluster join required
[2018-06-05T11:04:39.129Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.triggers.fires.perMinute
[2018-06-05T11:04:39.130Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.sequence.maxLength
[2018-06-05T11:04:39.132Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.concurrent
[2018-06-05T11:04:39.133Z] [INFO] [#tid_sid_unknown] [Config] environment set value for controller.instances
[2018-06-05T11:04:39.133Z] [INFO] [#tid_sid_unknown] [Config] environment set value for whisk.version.date
[2018-06-05T11:04:39.134Z] [INFO] [#tid_sid_unknown] [Config] environment set value for whisk.version.buildno
[2018-06-05T11:04:39.134Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.perMinute
[2018-06-05T11:04:39.135Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.concurrentInSystem
[2018-06-05T11:04:39.136Z] [INFO] [#tid_sid_unknown] [Config] environment set value for runtimes.manifest
[2018-06-05T11:04:39.137Z] [INFO] [#tid_sid_unknown] [Config] environment set value for kafka.hosts
[2018-06-05T11:04:39.138Z] [INFO] [#tid_sid_unknown] [Config] environment set value for port
[2018-06-05T11:05:05.297Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Exiting completed
[2018-06-05T11:05:05.318Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Shutting down...
[2018-06-05T11:05:05.341Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Successfully shut down
[2018-06-05T11:05:05.360Z] [INFO] [#tid_sid_unknown] [Controller] Shutting down Kamon with coordinated shutdown
[2018-06-05T11:05:05.363Z] [INFO] Shutting down remote daemon.
[2018-06-05T11:05:05.364Z] [INFO] Remote daemon shut down; proceeding with flushing remote transports.
[2018-06-05T11:05:05.415Z] [INFO] Remoting shut down

I would expect to see some messages early in the log noting that the controller had managed to create an initial set of topics in kakfa.  Perhaps the topic creation is failing, causing the controller to exit?
Do you have log lines like
[2018-06-04T22:00:19.033Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] created topic completed0
[2018-06-04T22:00:19.328Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] created topic health
[2018-06-04T22:00:19.587Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] created topic cacheInvalidation
[2018-06-04T22:00:19.828Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] created topic events

Did you elide log entries between 11:04.39 and 11:05:05 in your message above?

Probably I did, sorry
here is other log example where the kafka topic creation is skipped due to previous existence.
I have connected to kafka server and seen that logs are being fed with messages coming from controller requesting cache invalidation, I guess it confirms my suspect that they are connecting successfully, here a binary C&P log of kafka
/<IP_ADDRESS>��u0cacheInvalidation%cacheInvalidation/consumer-1-5ed4c13c-2e34-4c35-8c48-777270835fc6
consumer-1

Thanks for your help David

[2018-06-05T09:36:32.198Z] [INFO] Initializing Kamon...
[INFO] [06/05/2018 09:36:33.017] [main] [StatsDExtension(akka://kamon)] Starting the Kamon(StatsD) extension
[2018-06-05T09:36:33.176Z] [INFO] Slf4jLogger started
[2018-06-05T09:36:33.224Z] [INFO] Starting remoting
[2018-06-05T09:36:33.456Z] [INFO] Remoting started; listening on addresses :[akka.tcp://controller-actor-system@<IP_ADDRESS>:2552]
[2018-06-05T09:36:33.460Z] [INFO] Remoting now listens on addresses: [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552]
[2018-06-05T09:36:33.482Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Starting up...
[2018-06-05T09:36:33.553Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Registered cluster JMX MBean [akka:type=Cluster]
[2018-06-05T09:36:33.554Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Started up successfully
[2018-06-05T09:36:33.633Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - No seed-nodes configured, manual cluster join required
[2018-06-05T09:36:34.029Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.triggers.fires.perMinute
[2018-06-05T09:36:34.031Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.sequence.maxLength
[2018-06-05T09:36:34.037Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.concurrent
[2018-06-05T09:36:34.038Z] [INFO] [#tid_sid_unknown] [Config] environment set value for controller.instances
[2018-06-05T09:36:34.039Z] [INFO] [#tid_sid_unknown] [Config] environment set value for whisk.version.date
[2018-06-05T09:36:34.040Z] [INFO] [#tid_sid_unknown] [Config] environment set value for whisk.version.buildno
[2018-06-05T09:36:34.040Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.perMinute
[2018-06-05T09:36:34.041Z] [INFO] [#tid_sid_unknown] [Config] environment set value for limits.actions.invokes.concurrentInSystem
[2018-06-05T09:36:34.042Z] [INFO] [#tid_sid_unknown] [Config] environment set value for runtimes.manifest
[2018-06-05T09:36:34.044Z] [INFO] [#tid_sid_unknown] [Config] environment set value for kafka.hosts
[2018-06-05T09:36:34.045Z] [INFO] [#tid_sid_unknown] [Config] environment set value for port
[2018-06-05T09:36:34.765Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] topic completed0 already existed
[2018-06-05T09:36:35.129Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] topic health already existed
[2018-06-05T09:36:35.488Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] topic cacheInvalidation already existed
[2018-06-05T09:36:35.799Z] [INFO] [#tid_sid_unknown] [KafkaMessagingProvider] topic events already existed
[2018-06-05T09:36:36.398Z] [INFO] [#tid_sid_controller] [Controller] starting controller instance 0 [marker:controller_startup0_count:2367]
[2018-06-05T09:36:38.516Z] [INFO] [#tid_sid_dispatcher] [MessageFeed] handler capacity = 128, pipeline fill at = 128, pipeline depth = 256
[2018-06-05T09:36:38.794Z] [INFO] [#tid_sid_loadbalancer] [ShardingContainerPoolBalancerState] blackboxFraction = 0.1
[2018-06-05T09:36:39.158Z] [INFO] [#tid_sid_dispatcher] [MessageFeed] handler capacity = 128, pipeline fill at = 128, pipeline depth = 256
[2018-06-05T09:36:40.120Z] [INFO] [#tid_sid_loadbalancer] [WhiskAction] [GET] serving from datastore: CacheKey(whisk.system/invokerHealthTestAction0) [marker:database_cacheMiss_count:6094]
[2018-06-05T09:36:40.123Z] [INFO] [#tid_sid_loadbalancer] [CouchDbRestStore] [GET] 'test_whisks' finding document: 'id: whisk.system/invokerHealthTestAction0' [marker:database_getDocument_start:6097]
[2018-06-05T09:36:46.580Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Exiting completed
[2018-06-05T09:36:46.584Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Shutting down...
[2018-06-05T09:36:46.628Z] [INFO] Cluster Node [akka.tcp://controller-actor-system@<IP_ADDRESS>:2552] - Successfully shut down
[2018-06-05T09:36:46.640Z] [INFO] [#tid_sid_unknown] [Controller] Shutting down Kamon with coordinated shutdown
[2018-06-05T09:36:46.649Z] [INFO] Shutting down remote daemon.
[2018-06-05T09:36:46.651Z] [INFO] Remote daemon shut down; proceeding with flushing remote transports.
[2018-06-05T09:36:46.725Z] [INFO] Remoting shut down

ok, thanks.  So it looks like kafka isn't the problem.
Another thought, are you perhaps running 2 controller instances?  One reason I've seen controllers stuck in crash/restart loops is when they thought they were supposed to be part of an akka cluster, but had problems connecting to their peers.

Hello David,
apparently the error was caused by a typo in one of the couchdb configmap parameters definition.
After fixing it starts with no problem.
Thanks for your help

Great, glad it is working now.


Add Fluent class to universal object crates

The Fluent class acts as a wrapper around an array and allows accessing
and setting values through magic methods so it should qualify as a
universal object crate.

[x] Added or updated tests
[ ] Documented user facing changes
[x] Updated CHANGELOG.md

Changes
Marks the Fluent class as a universal object that can accept any property access.

Thank you @ChrisExP !
Very nice finding.
Let's see CI.

Does your IDE support EditorConfig?
https://github.com/nunomaduro/larastan/blob/99e7aec53075882ef3c254a2671baa994b89b188/.editorconfig#L11

Does your IDE support EditorConfig?
https://github.com/nunomaduro/larastan/blob/99e7aec53075882ef3c254a2671baa994b89b188/.editorconfig#L11

Yes but I didn't have it enabled :facepalm:
Sorry

Hi,
I don't think we should add this class to universalObjectCratesClasses by default. If the user wants they can add it themselves. Plus, maybe in the future we can write an extension to Fluent class itself.
Thank you!


Merge pull request #1 from Intellipharm/master

Merge pull request #22 from PBrockmann/master

test to synchronize my fork with your master


PhantomJS has been discontinued, but the tests do rely on it

Describe the bug
As the official sources say, PhantomJS is archived since Mar 2018.
To Reproduce
Just try to install PhantomJs with any deprecation-aware package manager such as Homebrew.
Expected behavior
No changes in behaviour expected
Desktop (please complete the following information):

OS: macOS
Browser PhantomJS/Chrome/Chromium
Version: any

Options are: CasperJS, Puppeteer

@kix good call. I'll test and migrate the lein commands


IOS white Screen

Hello i am trying to install the same on iOS 9.3, using  xcode Version 7.2.1
after launching the app it shows white screen. can u guide

I get the same on serving it just on my browser :/ using ionic serve

Hey @pvmenon, @rynomster. Can you try with the new version?

Closing due to inactivity.


Data sync issues with the Breeze integration

One user reported issues with the Breeze integration. Stopping the timer in Breeze failed to stop the timer in the web app.
The opposite is also true; stopping the timer in the web app doesn't stop it in Breeze.
Unfortunately, I don't have a way to reproduce the issue.

Desk case: 429737

Yes, indeed. Feels completely broken atm.
Issues I'm having:

Stopping the timer in toggl isn't doing that in the breeze and vice
versa: turning off the timer in breeze isn't turning it off in toggl;
Doesn't fetch the project name automatically (toggl project === breeze
project name);
Chrome plugin Project selector dropdown is bugged when you you starting
the timer on the card that is really close to the bottom of active view -
https://monosnap.com/file/nkIgRJ1XqT4j0caCJzoUPPXwKStSDh.png

Hi.
This integration positions the Toggl Button to the left of Breeze's start/stop button.

But there's a CSS rule on Breeze that overrides this position and put Toggl Button overlapping Breeze's start/stop button.

So we get this:

So you can't press one without also pressing the other.
That's probably fine if you only ever use the interface there. But if you have a running breeze timer, and a stopped Toggl timer, you're outta luck.

As for automatically starting/stopping Breeze's timer when starting/stopping Toggl's, we don't currently have these hooks on the extension, so you'd have to click each button separately (if you could).
I tested the 'project name matching' and apparently it's working. Can you please double check this? Remember that it's case sensitive.
I fixed the dropdown height on this PR: #800 . After review we should be good to go.


[Event] Initial seed for capturing event listener

@jdanyow @EisenbergEffect
This is just a seed based on Jeremy's prototype Gistrun

Purpose: Provide a way to listen to capture event

Note: this needs to come together with SyntaxInterpreter class changed. Which depends on probablility of this pr.

I'm not sure if this is in Aurelia team's plan so I only committed this. If ok, then I'll update all other repos where ListenerExpression is used.

Clearly I didn't read the contribution guidelines. If this looks good to go ahead, I'll edit the commit message

I think this would be a nice addition. @EisenbergEffect - thoughts?
@bigopon what do you think about changing eventHandlingMethod from:
const eventHandlingMethod = {
   /**
    * Default strategy, event listener is bound to the listening element
    */
   normal: 0,
   /**
    * Capture strategy, listening on root level during event capturing phase
    */
   capture: 1,
   /**
    * Delegate strategy, listening on root level during event bubbling phase
    */
   delegate: 2
 }

to:
const delegationStrategy = {
   /**
    * No event delegation.
    */
   none: 0,
   /**
    * Capturing phase event delegation strategy.
    */
   capturing: 1,
   /**
    * Bubbling phase event delegation strategy.
    */
   bubbling: 2
 }

This seems like a nice idea provided we don't break the existing behaviors/syntax. I didn't review the full code, just looked quickly at the gist and the ideas. Also, I like the change that @jdanyow recommends for the enum. If @jdanyow is good with it, let's move ahead.

Awesome! @bigopon let's proceed 🚀
If there's anything I can help out with, let me know. Thanks!

Cool. And agree on the naming, in fact I tried eventStrategy, eventBubblingPhase, handlingStrategy, eventDelegateStrategy but failed to come up with delegationStrategy ....
@jdanyow one thing concerns me is that every time we call the handler, a new array is created to store the ordered callbacks. Do you have any better ideas ?

That's a real concern and if there's an idea to prevent that, it would be nice...

@bigopon check the history on that region of the code- any issues tied to that change?

@jdanyow  I don't understand what you meant so I'll explain why I needed to put the array is that event propagates down from parent to child during capturing, we need to store all callbacks for event path and execute them in parent -> child order.
And it's 1am here so I'll try to response asap after this message.

@jdanyow
Just finished test for this. Gonna update other repos.

@bigopon please exclude the package.json from the PR. Typically we only include the src and test artifacts. The version bump happens as part of the release.

@jdanyow Done.
I also committed in

templating-binding : aurelia/templating-binding#99
templating-resources: aurelia/templating-resources#259

Can you have a look. Sorry I don't know to wire them.

Excellent- this is looking good. Are you done with the changes? If so, I will pull this down and do a full review in the next few days.
Also- I think I misunderstood your comment here: https://github.com/aurelia/binding/pull/530#issuecomment-257538698
Would you mind linking to the line(s) of code you're referring to?
Thanks!

Yeah, all changes are done and tests are updated accordingly. Just not wired up so some tests fail because they refers to old version.
I was talking about these line L21-L37

@bigopon sorry for the delay- I finally had a chance to review this. It's looking really good. Regarding the array allocation, I don't think it will be an issue. We can benchmark it after this is merged. Your changes certainly won't degrade perf of existing apps.
Left you one comment above about a variable declaration, once that's resolved I'll get this merged.
Thanks!

Done. I also fixed the starting index in line 38.

Oh that's bad. Forgot to change after changed the constants 😭
@jdanyow
I have one other query related to events, these line L10 - L13
Do we have to create a function for each event ? can we just cache it an assign to every event instead ? It's micro thing but could be good.

good call- want to send a PR?

Does this look good ?
#539

I would like to use event capturing during drag and drop operations.
During the event, I need to know the event the event is attached to in the HTML.
Currently, capture attaches to the document (like event.delegate) instead of the source element(like event.trigger)
So in the event, when I check the currentTarget, the property is set to the root document, not the element.  So I have no way to know which element is the currentTarget.
If event.capture worked more like event.trigger, that would work for me.

I'm guessing the element listening to drag & drop has descendants so you cannot use event.target ? You can use self binding behavior for this. But correct me if I'm wrong as I don't know your use case.

Yes, there are descendants of the dropzone.  The issue is that the when an item is dragged over a descendant, it cause dragLeave to be fired on the parent (when in fact, the cursor is still within the parent, so it should not be). So the parent loses the highlighting.
So what I wanted to do was capture the dragOver in the parent, and stop the propagation down to the child.  This (hopefully) would prevent the DragLeave from being called on the parent.
But in any case, I found a workaround on StackOverflow, and it's working fine.

@gregoryagu
Hmm i remember hitting this annoyance behavior long ago. Maybe you can disable all pointer event on dragenter, it ensures there's nothing will fire dragleave within the element

@bigopon This looks great.  I tried the gist, and yes it does work.  It doesn't look like it is actually using the "self" class.  I forked the gist and tried without it, and it seems to work fine.  Yes, I was using dragCount.  I would much rather use your solution.  In a few hours, I will have a chance to try it on the actual project and will let you know.  I appreciate the help very much.  The finer points of Aurelia sometimes eludes me!

@gregoryagu this is gonna be your wtf moment i guess 😄, if your inner elements are close to the edge of the container and user drag too fast and there is no self binding behavior, the order of the events will be like this: (from the example)
Entering: button
Leaving: button
Leaving: header

It's because when you drag too fast and enter the button, the header will be added a class to make button pointer-events: none, thus triggers the dragleave and bubbles up. This is where self is needed.

@bigopon Interesting.  Yes, I tried it moving the mouse quickly and I did see the effect that self has on it. Awesome.  I just read the doc you wrote on it.  Very interesting.  Good work!  Oh those mouse events!!


[BUG] "print" should not exist in the source code.

🐛 Bug description [Please make everyone to understand it]
In the source code, the "print" function should not exist, as it prevents users from controlling whether or not it prints.
👾 Expected result
use swanlog to print info
🚑 Any additional [like screenshots]

SwanLab Version: v0.1.3

Platform: macos

#169