User reported java.lang.Error: Watchdog with Clutter mod clutter-1.20.1-0.3.9.jar

hi, a user of our darkrpg serverpack reported a crash on their server (log below).  When clutter mod was removed the crash went away. Please can you look into this
Full log - https://pastebin.com/a8d3Lykh
---- Minecraft Crash Report ----
// Daisy, daisy...

Time: 2023-07-29 21:33:43
Description: Watching Server

java.lang.Error: Watchdog
	at java.base@17.0.8/java.util.ImmutableCollections$SetN.probe(ImmutableCollections.java:1017)
	at java.base@17.0.8/java.util.ImmutableCollections$SetN.contains(ImmutableCollections.java:938)
	at net.minecraft.class_6880$class_6883.method_40220(class_6880.java:184)
	at net.minecraft.class_4970$class_4971.method_26164(class_4970.java:1182)
	at net.minecraft.class_14.method_58(class_14.java:570)
	at net.minecraft.class_6.method_17(class_6.java:294)
	at net.minecraft.class_14.method_64(class_14.java:429)
	at net.minecraft.class_6.method_25(class_6.java:264)
	at net.minecraft.class_14.method_29302(class_14.java:480)
	at net.minecraft.class_14$$Lambda$14972/0x00007f0431aa1000.get(Unknown Source)
	at it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap.computeIfAbsent(Long2ObjectOpenHashMap.java:448)
	at net.minecraft.class_14.method_29303(class_14.java:480)
	at net.minecraft.class_14.method_63(class_14.java:476)
	at net.minecraft.class_6.method_47893(class_6.java:71)
	at net.minecraft.class_6.method_21(class_6.java:60)
	at net.minecraft.class_13.method_52(class_13.java:43)
	at net.minecraft.class_1408.method_18416(class_1408.java:207)
	at net.minecraft.class_1408.method_35142(class_1408.java:179)
	at net.minecraft.class_1408.method_6348(class_1408.java:156)
	at net.emilsg.clutter.entity.custom.ButterflyEntity$ButterflyWanderAroundGoal.method_6269(ButterflyEntity.java:285)
	at net.minecraft.class_4135.method_6269(class_4135.java:41)
	at net.minecraft.class_1355.method_6275(class_1355.java:107)
	at net.minecraft.class_1308.method_6023(class_1308.java:771)
	at net.minecraft.class_1309.method_6007(class_1309.java:2673)
	at net.minecraft.class_1308.method_6007(class_1308.java:550)
	at net.minecraft.class_1296.method_6007(class_1296.java:128)
	at net.minecraft.class_1429.method_6007(class_1429.java:58)
	at net.minecraft.class_1309.method_5773(class_1309.java:2419)
	at net.minecraft.class_1308.method_5773(class_1308.java:351)
	at net.minecraft.class_3218.method_18762(class_3218.java:739)
	at net.minecraft.class_3218$$Lambda$14885/0x00007f0431a89480.accept(Unknown Source)
	at net.minecraft.class_1937.mixinextras$bridge$0$accept(class_1937.java)
	at net.minecraft.class_1937$$Lambda$14886/0x00007f0431a896b8.call(Unknown Source)
	at net.minecraft.class_1937.wrapOperation$ccg000$neruina$catchTickingEntities(class_1937.java:3066)
	at net.minecraft.class_1937.method_18472(class_1937.java:480)
	at net.minecraft.class_3218.method_31420(class_3218.java:385)
	at net.minecraft.class_3218$$Lambda$14855/0x00007f0431a7c9f0.accept(Unknown Source)
	at net.minecraft.class_5574.method_31791(class_5574.java:54)
	at net.minecraft.class_3218.method_18765(class_3218.java:353)
	at net.minecraft.server.MinecraftServer.method_3813(MinecraftServer.java:897)
	at net.minecraft.class_3176.method_3813(class_3176.java:283)
	at net.minecraft.server.MinecraftServer.method_3748(MinecraftServer.java:824)
	at net.minecraft.server.MinecraftServer.method_29741(MinecraftServer.java:671)
	at net.minecraft.server.MinecraftServer.method_29739(MinecraftServer.java:265)
	at net.minecraft.server.MinecraftServer$$Lambda$13050/0x00007f0431784508.run(Unknown Source)
	at java.base@17.0.8/java.lang.Thread.run(Thread.java:833)```

Hi, it's an error with the way Butterfly pathfinding is handled, it's a known issue and should be fixed in the next update.

Hi, it's an error with the way Butterfly pathfinding is handled, it's a known issue and should be fixed in the next update.

hi, thanks for the update. Do you have an ETA on the next update? so I can also plan modpack update around it

Not really since I don't want to stress it but I'd say in a week or two. Maybe earlier if everything currently planned for the update goes smoothly.

FYI, 0.4.0 Releasing later today.


Spevacus: Watch universalfumigationservice.com

Spevacus requests the watch of the watch_keyword universalfumigationservice\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

universalfumigationservice\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Daniil in Charcoal HQ


CAF edit request: [Maintenance] CAF Readiness checklist document refresh

This PR completes a quality check. Minor editorial changes were made, and the locale was removed from links. Links were checked for correct functionality.

@dominicallen This PR is ready for final review and sign off. Thanks!

@jmart1428 - This needs a more than just a quality check.  Please review the instructions in the work item and reach out to me if you need additional information.  Putting this in Draft for now.


Support for custom attributes

I would like the ability to add custom attributes to the model that I could use to configure my generated API. For example I would like to define certain access control rights in the same file as I define the model rather than having a duplicate elsewhere. It would also come in handy to apply other API level modifiers where appropriate such as custom function calls before write or after read.
model Post {
  id        String   @default(cuid()) @id @unique
  createdAt DateTime @default(now()) @rbac.role('system')
  updatedAt DateTime @updatedAt @rbac.role('system')
  published Boolean @env('development') // only expose in development mode
  title     String @onRead("toUpperCase") @onWrite("toLowerCase")
  content   String?
  author    User?
}

Currently I am reading schema information from the dmmf class and using it to generate my API, Ideally I would be able to call upon custom attributes at this point to shape the filters/abstraction rather than relying on an additional external config.
//
const photon = new Photon()
const { queryType, mutationType, modelMap } = photon.dmmf;

//
const Query = objectType({
  name: 'Query',
  definition(t) {
    forEach((f) => {
      if (typeof t.crud[f.name] === 'function') {
        // additional filters and abstraction here
        t.crud[f.name]();
      }
    }, queryType.fields);
  },
})
...

Currently I pull the information in separate from a config like so but it sure would be great if I could add the additional information in the same place as the model definitions some way.
---
Post:
 createdAt:
  rbac.role: system
 updateAt:
  rbac.role: system
 published:
  env: development
 title:
  onRead: toUpperCase
  onWrite: toLowerCase

I would like custom attributes as well.  I'm evaluating .prisma to be the way I define a source of truth for all things related to a schema but I need the ability to extend how I can decorate the attributes.  All I need to happen is for them to not throw an error and show up in the DMMF

Yes I also support this as this is the base of a plugin system that could enable privacy filtering and other cool features.

@do4gr to validate if we error or ignore custom attributes. They are not surfaced in DMMF currently.

Privacy and security features are important features which can be supported via extensions with custom attributes. Would be great to see this added.

Any updates on this? I really think this feature would enable so many possibilities to use the Prisma schema. Just imagine auto-generating GraphQL resolvers without worring to remove internal fields (e.g. passwords), just add a custom attribute like @graphql.omit.

Related: https://github.com/prisma/prisma/issues/1660

This is also related to #3102 I put a comment that is very similar to what has been mentioned here.

I am also interested in this topic, it makes sense to me to keep application-specific attributes close to the model definition

Is there anything here in this issue not covered by https://github.com/prisma/prisma/issues/3102? Otherwise I think we should close this one and focus on #3102.

Definitely need this also


Seatmap improvements

add space around the seatmap in which you can still double tap
fix the point of zooming by adding layout=fill to the amp-selector

@sebastianbenz the div strategy is necessary as explained in the comment as adding a padding directly to the svg interacts with the amp-pan-zoom sizing, while just having a margin outside the amp-pan-zoom makes the margin not clickable for zooming.
@pbalaram FYI

@sebastianbenz ping

@sebastianbenz PTAL


drag ending prematurely

I have a situation in which the drag of a piece is immediately and unexpectedly aborted while I am still dragging.
The sequence of calls to my drag source are: canDrag (returning true), beginDrag returning the item, and endDrag (with isDropped being false, as expected).
The application is a scrabble-like game, where pieces can be dragged to/from a board from/to a rack. Dragging a piece from the rack works. Dragging it from the board does not work - is aborted immediately.
In both cases I am using the same React component to represent the piece as the drag source.
I'd really appreciate any hints on how to go about debugging/troubleshooting this issue.
Thanks.
Azad
P.S. Using React 15.4.2, React DND 2.4.0, Webpack 1.12.1, and Chrome 58 on MAC OS/X.

I managed to reproduce a similar problem with a minor tweak to the Chessboard example.
I cloned the latest react-dnd repository, and made sure the knight can be moved as expected.
Then I edited examples/00\ Chessboard/Tutorial\ App/BoardSquare.js to return true all the time for canDrop:
const squareTarget = {
canDrop(props) {
return true;
// return canMoveKnight(props.x, props.y);
},
Now when I bring up the application, I cannot drag the knight.
Not sure why this is happening. But I hope figuring out this simple test case can shed light on my original problem of inability to drag pieces.
Thanks in advance for hints on what is going on here and how to fix it.
Azad

same here, but only in Firefox. Firefox stops calling canDrop after 3 times while Chrome is continuously calling it.

I hit that problem in Firefox 58.0b4 as well. canDrop is called a few times and then endDrag, though I'm still dragging element.

Same issue here only on Firefox I'm using 52.6.0 ESR

My colleague Allen Haim (@misterfish) found the following workaround which for now is working for me. I have not, however, done exhaustive testing on all major platform x browser combinations.
His idea is to make sure the drag item has actually moved before allowing a drop. Exactly why this solves the problem, I am not sure.
Here is what my working code looks like:
const MIN_MOVEMENT = 15;
const vectorMagnitude = (x, y) => Math.sqrt(x ** 2 + y ** 2);
const isMinimallyMoved = ({ x, y }) => vectorMagnitude(x, y) > MIN_MOVEMENT;

canDrop: function (props, monitor) {
  let piece = getMonitorPiece(monitor);
  let point = props.point;
  let legal = props.isLegalMove(piece, point);
  // A workaround to avoid react dnd glitch preventing drag.
  let minimallyMoved = isMinimallyMoved((monitor.getDifferenceFromInitialOffset()));
  return minimallyMoved && legal && props.enabled;
},
// ...

If you do experiment with this technique, please share your findings and insights.
Cheers.
Azad

Not sure whether it is related but I sometimes end up here:

Which means dragging ends right after dragging starts.. Haven't been able to reproduce when exactly this happens but it seems like that some drag sessions are not finished correctly so it ends up here.
I'd say that this is an issue inside this library as it shouldn't fail like this when this situation occurs.

I am experiencing this issue as well. I have a dragSource and a dropSource that are siblings in a component. They sit on top of one another and the draggable has interactive elements inside as well. Whenever I go to change the Z-index of the sibling and my drag handle is over the changed area; the drag handle is lost and the endDrag method is called terminating the drag sequence. We are getting this in Chrome. FF works without issue.

Hey.
I have a similar issue with chrome, but the root cause is different.
Hope that this information will help someone in the future.
https://stackoverflow.com/questions/59172584/javascript-dragend-event-fired-immediatly-after-dragstart

anyone has found a proper solution or a good explanation ?

I'm experiencing this as well. I've managed to make a small example https://codesandbox.io/s/7vmz86mpq
It works in Firefox and Edge just fine, but doesn't work in Chrome.
This example is also containing a workaround, replace it in Panel.js:
-let canDropIt = canDrop
+let canDropIt = canDropSafe

Hey, having the exact same issue as your example. Did you have a solution ?

@Guenolekikabou What do you mean? You've quoted a solution for the problem → Instead of relying on react-dnd's state for canDrop I'm keeping my own state for this property. Just check out the codesanbox example I provided and yes, I'm still using this solution as a workaround for broken canDrop prop.

I noted the canDrop gets cancelled because when you first drag it detects you are throwing the draggable over itself.
My implementation includes evaluating that we are not over the same index.
` canDrop(item: any, monitor) {
const { draggingElemIndex } = item
    const notSameIndex = draggingElemIndex !== dropIntoElemIndex
    const canDrop = notSameIndex && monitor.isOver()

    if (canDrop) {
      return true
    } else {
      return false
    }

},`


TagInfo: capital=yes is equivalent to capital=2

See:
https://github.com/openmaptiles/openmaptiles/blob/master/layers/place/capital.sql

Huh.  Curious.  Looks like capital=2 is barely used in fact.
Is it permissible to set an array in the "values" block? @1ec5 ?

Is it permissible to set an array in the "values" block?

The documentation does not mention such a possibility.


Installing latest version is throwing error because of Bluebird package update.

I am installing latest version<EMAIL_ADDRESS>When I see npm list I see below (Notice invalid)
+--<EMAIL_ADDRESS>invalid
| +--<EMAIL_ADDRESS>| +--<EMAIL_ADDRESS>extraneous
| +--<EMAIL_ADDRESS>extraneous
| `--<EMAIL_ADDRESS>If I reinstall<EMAIL_ADDRESS>it works fine.
Getting below error:

WARNING in ./node_modules/bluebird/js/release/util.js
Module not found: Error: Can't resolve 'async_hooks' in '\node_modules\bluebird\js\release'
@ ./node_modules/bluebird/js/release/util.js 410:18-40
@ ./node_modules/bluebird/js/release/using.js
@ ./node_modules/bluebird/js/release/promise.js
@ ./node_modules/bluebird/js/release/bluebird.js
@ ./node_modules/request-promise/lib/rp.js
@ ./server.ts

ERROR in ./node_modules/bluebird/js/release/promise.js
Module not found: Error: Can't resolve 'async_hooks' in node_modules\bluebird\js\release'
@ ./node_modules/bluebird/js/release/promise.js 34:4-26
@ ./node_modules/bluebird/js/release/bluebird.js
@ ./node_modules/request-promise/lib/rp.js
@ ./server.ts

Please help.

same problem

any updates on this?


Cartoonized simulated RGB image

❓ Questions and Help
How to get the Cartoonized simulated RGB image (top left in red circle) shown in the repo home page? Is it just from a specific dataset?

I tried to search the config in the source code but with no luck. Only found COLOR, DEPTH and SEMANTICS. Any help would be appreciated.

Yes, this is just a model from a particular dataset. There is no "cartoonized" render mode.

@aclegg3 Did you happen to know which dataset? Matterport3D and Gibson use real images.

@msavva ?

It's from a dataset that is no longer publicly available. We are unable to comment further because of an ongoing litigation.


[Breaking change]: Regexes that has ranges in the pattern and used with RegexOptions.IgnoreCase option might break

Description
Regex was incorrectly handling casing of some ranges in .netframework, .NET 6 and below. The two patterns in below example should produce the same result, because the range from \xD7 through \xD8 is just same as \xD7 and \xD8, since there's nothing in between them.
The fix for this bug could cause a breaking change in case your Regex had a bug that is not revealed because of this bug or if you had a workaround for this bug. See a broken Regex example from https://github.com/dotnet/runtime/issues/78609
Version
.NET 7
Previous behavior
The first match correctly produces false whereas the second incorrectly produces true:
Regex.IsMatch("\xF7", @"^(?i:[\xD7\xD8])$", RegexOptions.IgnoreCase | RegexOptions.CultureInvariant);
Regex.IsMatch("\xF7", @"^(?i:[\xD7-\xD8])$", RegexOptions.IgnoreCase | RegexOptions.CultureInvariant);

New behavior
As the bug fixed in .NET 7, now both cases produce false correctly.
Type of breaking change

[X] Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
[ ] Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code may require source changes to compile successfully.
[X] Behavioral change: Existing binaries may behave differently at run time.

Reason for change
The previous behavior was incorrect, as the Regexes in the example should produce the same resullt
Recommended action
If you Regex has a hidden bug, fix it, if you had a workaround for this bug, remove the workaround.
Feature area
Core .NET libraries
Affected APIs
The change is introduced in the Regex range handling, not for any specific API

CC @stephentoub

@ericstj, is there a particular reason this bug fix deserves a breaking change document?

I think the reasoning was discussed here: https://github.com/dotnet/runtime/issues/78609#issuecomment-1346922775.  Customer was broken by the change, we decided it was by design and a good fix. To help others who might encounter it in the future we can document it as breaking and intentional.  The goal here would be to leave enough of a trail so that the next person might see that and not open an issue but instead find a solution.
Note: I unchecked binary incompatible - this is not a binary breaking change, it's only a functional difference.


Bing Search creation failed with error message {"code":"InternalServerError","message":"Specified resource could not be retrieved"}

Using Accelerator option when trying to deploy the bing search creation failed with error message {"code":"InternalServerError","message":"Specified resource could not be retrieved"}. Look screenshot for more information. Not sure if i have to register any namespace for target subscription. Please advice.

Namespace is also registered and even getting the same error during deployment


Track InheritedElement dependencies in diagnostic properties

Information can be surfaced from command line or widget inspector. Allows users to see which widgets are currently being depended on via a .of(context) or similar InheritedWidget pattern.
Some work towards https://github.com/flutter/flutter/issues/27100

Can you add a dedicated test for this? If we ever decided to delete the Table widget, this would be untested :)

A fair point :)


Update powerline tutorial with oh-my-posh and terminal-icons

The Powerline tutorial was fairly out-of-date, so I modified it to use Oh-My-Posh and Terminal-Icons.

Docs Build status updates of commit 6660fe7:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error-PullRequestMergeConflict] Cannot sync git repo to specified state. Please make sure the pull request is mergeable.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a5fc89c:
:warning: Validation status: warnings

File
Status
Preview URL
Details

TerminalDocs/TOC.yml
:warning:Warning
View
Details

TerminalDocs/cascadia-code.md
:warning:Warning
View
Details

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md
:warning:Warning
View
Details

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md
:warning:Warning
View
Details

TerminalDocs/images/custom-prompt.png
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/custom-prompt-setup.md
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/powerline-setup.md
:white_check_mark:Succeeded

TerminalDocs/TOC.yml

Line 46, Column 17: [Warning-file-not-found] Invalid file link: 'tutorials/powerline-setup.md'.

TerminalDocs/cascadia-code.md

Line 27, Column 254: [Warning-file-not-found] Invalid file link: './tutorials/powerline-setup.md'.

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md

Line 15, Column 3: [Warning-file-not-found] Invalid file link: './../tutorials/powerline-setup.md'.

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md

Line 15, Column 3: [Warning-file-not-found] Invalid file link: './../tutorials/powerline-setup.md'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a0acea5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

TerminalDocs/TOC.yml
:white_check_mark:Succeeded
View

TerminalDocs/cascadia-code.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md
:white_check_mark:Succeeded
View

TerminalDocs/images/custom-prompt.png
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/custom-prompt-setup.md
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/powerline-setup.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 2ea831c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

TerminalDocs/TOC.yml
:white_check_mark:Succeeded
View

TerminalDocs/cascadia-code.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md
:white_check_mark:Succeeded
View

TerminalDocs/images/custom-prompt.png
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/custom-prompt-setup.md
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/powerline-setup.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 25549dd:
:warning: Validation status: warnings

File
Status
Preview URL
Details

TerminalDocs/tutorials/custom-prompt-setup.md
:warning:Warning
View
Details

TerminalDocs/TOC.yml
:white_check_mark:Succeeded
View

TerminalDocs/cascadia-code.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md
:white_check_mark:Succeeded
View

TerminalDocs/images/custom-prompt.png
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/powerline-setup.md
:white_check_mark:Succeeded

TerminalDocs/tutorials/custom-prompt-setup.md

Line 77, Column 1: [Warning-file-not-found] Invalid file link: '../../images/settings-powershell-font.png'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit f7eac15:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

TerminalDocs/TOC.yml
:white_check_mark:Succeeded
View

TerminalDocs/cascadia-code.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/frosted-glass-theme.md
:white_check_mark:Succeeded
View

TerminalDocs/custom-terminal-gallery/powerline-in-powershell.md
:white_check_mark:Succeeded
View

TerminalDocs/images/custom-prompt.png
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/custom-prompt-setup.md
:white_check_mark:Succeeded
View

TerminalDocs/tutorials/powerline-setup.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Deprecate Upload task

Fixes #10796

@bot-gradle test and merge

Your PR is queued because #16846 is being built.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test and merge

OK, I've already triggered a build for you.

@bot-gradle test and merge

Your PR is queued because #16850 is being built.

Pre-tested commit build failed.

OK, I've already triggered a build for you.

Pre-tested commit build failed.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.


Command Retry

It would be worth added a retry to commands... this would retry to the command upon failure.  Controls might include:

number of retries
amount of time to retry
timeout for retry
freq of retries

a number of "themed" tasks for commands are in v0.7.0... grouping there.


Refine initial designs based on feedback

Dependant on https://github.com/developmentseed/wb-agrifood-frontend/issues/2 and https://github.com/developmentseed/wb-agrifood-frontend/issues/3.
Once feedback from WB team is received, and once/while user research is conducted, designs should be refined based on:

WB team feedback
User feedback
Technical scope/limitations

Sharing Mockup below
https://github.com/developmentseed/wb-agrifood-frontend/assets/10764915/624d9d40-ef71-4fed-b81f-1df1b8ece967
Decisions:

Evolving Dustin's general prototype with a very clean interface
Using one of the World Bank's secondary colors 006068
Using text + components from Tailwind
Not incorporating filters until after we see search results, but we can consider a toolbar on top of the message box for filters


a bug in tensorflow/core/graph/gradient.cc

in the above file, i think that in line 257 there is a error
for (const Edge* e : y->in_edges()) {
if (e->IsControlEdge()) continue;
BackpropAlongEdge(y_grad_node_outputs_[i], { e->src(), e->src_output() });
}
i think y->in_edges() should be y->out_edges(). please check this out as soon as possible, thank you

sorry,  i think just modify the above is not right . from line 254 to line 263 should be considered carefully to make it right.

if there is one node y has more than one output , then the node would be counted more than one time.

@cuiguoxin, you might have misunderstood the code. The code is initializing the backprop state starting from y(s). So it needs to look at y's inputs. If you think it's wrong,  do you mind constructing a test case to show it?

@zffchen78 ,does y_grad_node_outputs mean the gradient of y_node_outputs? To be clear, think the function y = 3 * x. Now i konw the node y, x and dy, and i want to compute the dx. The source code just put dy in x's backpropedGradient and i think it is wrong.

@cuiguoxin Thank you for your comments. I think that some of this confusion is due to this API being in an intermediate state (it currently just supports functions and not general graphs). As commented in the header file, this API is under construction, and will be changing frequently. Currently, the gradients passed in 'y_grad_node_outputs' are passed through to the input of the 'y_nodes', but these nodes are handled in a specialized way in the current implementation (i.e. function arg nodes). In a future version, the 'y_grad_node_outputs' will contain the gradient node outputs corresponding to the 'y_node_outputs', and will be propagated into the 'y_nodes' during backprop init.

@andydavis1 . Thanks. Does it mean that if I construct a graph and I want to auto differentiate the graph from the y to x, I still can't use the api in gradient.cc? Can you show me how to do it in c++ api?

I would not recommend using gradients.h/cc as it is currently under construction and will change frequently (as mentioned in the header file). If you need to auto differentiate your graph, for now, you need to use the python API (see code at tensorflow/python/ops/gradients.py)


Advanced filters documention differs from portal

In the CloudEvents section, these key values are listed: eventid, source, eventtype, eventtypeversion
In the Azure portal, in the advanced filters section of the Event Subscription page, a different list is seen:

Valid keys for currently selected event schema:
id, source, type, specversion
Custom properties, using "." as the nesting separator. (e.g. key, key1.key2)

It seems the ones in the Azure portal are ok. The text needs to be rewritten?

You can also use extension context attributes in CloudEvents 1.0. In the following example, comexampleextension1 and comexampleothervalue are extension context attributes.

Is this correct? It's not mentioned in the Azure portal.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 1b572f63-312f-4567-5f06-d09bcccf303e
Version Independent ID: df817c5f-24e4-bdc7-511c-141d07a53d15
Content: Event filtering for Azure Event Grid - Azure Event Grid
Content Source: articles/event-grid/event-filtering.md
Service: event-grid
GitHub Login: @spelluru
Microsoft Alias: spelluru

@sandervandevelde
Thanks for your feedback! We will investigate and update as appropriate.

@sandervandevelde - Thanks for the feedback. I have fixed the issue in the article.
Regarding the extension attributes: yes. they are supported as per the product team.
#please-close


Overflow in button on Create Wallet screen

Steps to reproduce:

Hit the "Create Wallet" button on the launch screen

(MacOS 10.12.6)

Could not replicate.


Wix user information [PERMISSION_DENIED] Error in nextjs

Hello,

I would like to obtain user information from Wix in order to use Wix's payment system on the web I operate.
I created a Wix client and entered all key values correctly.
However, an error occurs as shown in the picture below. Please tell me the solution.

If this can be resolved, I will load the user information into Wix , log in the user, and proceed with the payment.
Please let me know if this is a realistic logic after resolving the error. You will use a different domain than the domain of the web page created by Wix. I want to load information about Wix from that domain and enable the loaded users to make payments.

Why did this problem occur, and is there a way to solve this problem?
I attach the code below.
My webpage is composed of nextjs.

useEffect(() => {
    async function fetchSession() {
      const session = await getSession();
      if (session) {
        setUserEmail(session.user.email);

        const client = createClient({
          modules: {
            authentication,
            members,
          },
          auth: ApiKeyStrategy({
            apiKey: process.env.API_KEY,
            accountId: process.env.ACCOUNT_ID,
            siteId: process.env.SITE_ID,
          }),
        });

        console.log(session.user.email);

        const user  = await client.members
        .queryMembers()
        .eq('loginEmail', session.user.email)
        .find().catch((error) => {
          console.error("=====>>" + error + "<<====");
        }
        );
      }
    }

    fetchSession();
  }, []);

make sure you set the permission config for this table - take a look here, under permissions, how you can do it.


CI: Remove macos-11

The macos-11 runner is slated for removal by the end of the month with brownouts scheduled to occur in the weeks leading up to that.

This seems hard to object to given that the facility won't even exist soon. I will merge it.

This seems hard to object to given that the facility won't even exist soon. I will merge it.

I mean, I mildly object to doing it earlier than necessary, but whatever.


; is not a valid sentence delimiter

@nevenjovanovic requests that we treat ; like , and not deem it to be a sentence delimiter

Some additional information to what @balmas wrote may be helpful: I suggest a change made to the Latin tokenizer; the semicolon (;) seems to me to have functions similar to the comma -- sometimes it marks the end of a sentence or clause, sometimes not. If we are not making guesses about clause ends in the case of comma, we should not make it in the case of semicolon. And, finally, at least around these parts, people don't expect a Latin sentence to end on a semicolon; it would have a full stop if it needed to end.
Of course, if there is a strong treebanking argument on why we want to split a sentence on a semicolon, I'll gladly accept that and explain it to my students.

consensus is generally no change for Greek, drop the semicolon as delimiter for Latin, with a wishlist item of making this configurable.

Agree absolutely.

One last question @nevenjovanovic -- do we want to automatically annotate it as AuxX as we do for commas?

@balmas -- yes, I would treat the semicolon as a punctuation mark automatically.

@nevenjovanovic this is deployed now. Just be sure to refresh your browser on the treebank input form page to get the latest code. It will now default to NOT using the semicolon as a delimiter for Latin texts (as long as the Latin language option is properly selected).  You can override this by opening the advanced options and checking or unchecking the Semicolon delimiter option before submitting. Let me know if you have any problems with the changed behavior.


unset NAPARI_OCTREE no longer works

🐛 Bug
Not sure if we should just begin dropping the NAPARI_OCTREE env variable, but now that we have the settings remembering the tiled rendering case, if you do export NAPARI_OCTREE=1 from the command line it will turn on the tiled rendering setting, which gets saved. If you then do unset NAPARI_OCTREE the env variable gets cleared, but you still have the setting, so you have to go into the GUI and clear this too.
That might be ok, but we might want to add this to our documentation somewhere so people don't get confused. Curious what @ppwadhwa and @goanpeca think is best here, and if the behaviour is actually happening as I suggest.

That is odd since env variables should not be saved.
Does the same happen with theme (an easy one to test with)?

I just reproduced the bug.  I tried both the octree setting and I also tested with theme.  If you set something in the environment, it will overwrite the setting and disable the widget.  It is weird, because I am fairly certain I had tested that the setting was not overwritten before and I don't remember seeing this behavior.  I am wondering if #2848 affected this?

So, I just reverted a bit of code that was changed in #2848, and the settings are not overwritten when setting environment variables.  So, this bug does seem to have been introduced with #2848.

Hum, my guess is that when set with the env variable it is seen by the code that remove the default as having been modified, and hence it saves it.
That seem coherent as if I set the env variable I immediately get
experimental:
  octree: true

in my setting file.

Working on a fix for this.

I can reproduce with pre- #2848 so I doubt this is due to it.
if you set NAPARI_OCTREE to 1 then start napari
experimental:
  octree: true

is stored in the settings anyways and because of
        @classmethod
        def customise_sources(
            cls,
            init_settings: SettingsSourceCallable,
            env_settings: SettingsSourceCallable,
            file_secret_settings: SettingsSourceCallable,
        ):
            cls._env_settings = env_settings
            return (
                init_settings,
                env_settings,
                yaml_config_settings_source,
                file_secret_settings,
            )

Yaml config then takes precedence.
I'm also concern that this also affects things that might be in file_secret_settings, and that if someone write something in their secrets file, then it might get propagated to their normal YML settings file. Though I don't see anything in napari about secrets, though maybe in a plugin ?


fix the position of the scroll to top button

I want to fix the position of the scroll to top button.
This is what it looks like currently:

This is a(n):

[x] Update to an existing Animated Button
[ ] Any Error
[ ] Proposal to the Repository
[ ] Documentation / README.md changes

Details:

This is what it should look like:

Please check #1346

Sorry for the inconvinience, but we are closing all the issues! Please open a new issue if you want to contribute anything. Also now you can create a new button from the website itself! You will get points for those too! I will add the instructions on how to create a new button soon and create an empty pr for the same to get points!


YouTube video tutorial

Hi,
As promised I'm back with another tutorial (this time series) on this awesome repo of yours.
You can take a look at it here:
https://www.youtube.com/watch?v=1R-VIzjD4yo&list=PL_csAAO9PQ8bLfPF7JsnF-t4q63WKZ9O9
I used it in several of my apps and thought I make a video tutorial on how to use it!
If you like it consider adding it to your README with the following image:

Alex.

Welcome. Thanks for adding my site url in your README file. Appreciate it.
Next up on my list is Dodo, than Moa (simply love it).
Thanks again for sharing these libraries you created.
Keep in touch and will let you know if the new tutorials when they are ready.


Checking for changed order in JSON with NSOrderedSet

Hi there,
I'm not sure whether this is a bug or if this might be solvable through configuration.
As far as I know arrays in JSON are ordered and CoreData allows ordering as well using NSOrderedSet. So in my opinion Sync should change the data when the order of an array has changed, which does not happen at the moment.
I forked SyncAppNetDemo and built a many-to-many relationship with humans and cars to illustrate the issue. Start the app and let Sync do its job. Then change the order of the cars in global.json and start the app again. Now I think the ordering in CoreData should be updated and the changeNotification for updated objects triggered.
How do you guys think this should be handled?

Hi @dersvenhesse,
You're right, this isn't handled correctly. The piece of code that should include this functionality is here.
Right now it just checks if the relationship has being added, before it adds it, it doesn't check if the position has changed. It does this to avoid triggering KVO notifications if changes haven't been made.
To be able to implement this feature, I think we would need to know the previous index of the evaluated relationship, if it has changed we could use any of the fancy NSMutableOrderedSet methods to move elements.
Do you have any suggestions on how we could do that?
Also, why using sorted relationship instead of sorting by X using a NSSortDescriptor?

Since the data structure itself does support ordering, I don't see why an extra attribute should be used to order. ;)
Furthermore, the ordering might be an attribute on the relation rather than an object. For example, when using images, the same image might be on first place in one object, but on third in an other.
I do think as well it will be necessary to compare indexes and then use something like moveObjectsAtIndexes  or exchangeObjectAtIndex. But, tbh, I don't have an exact implementation in mind yet.

Maybe pulling the entire list of changes, looping through it and verifying if the index is the same. Could be a good option. If the index is not the same, figure out the new index and change it's position on the set

💥  -> https://github.com/SyncDB/Sync/issues/327


Update por.po from X86Max

This is a pull request from their fork.

it looks good

it looks good


Run Distributed Tests: Tests not getting executed

Hi!
I am using the distributed test task to run my ui tests (mstest) on my machines. For some reason only one machine does execute all tests. I use the test plan selection, and use one build that is configured and parameterized so that I can use the multi configuration option to run the same set of tests on different machines.
For some reason I do not get results for all tests on my environments (except the one where everything works!)
The execution DTA logs are attached.
In the results later I see that two of the selected test suites were successfully executed and the test cases of the other suites are there but have "none" as outcome.
DTAExecutionHost.txt
DTAExecutionHost - proper.txt
This is how it looks like on the faulty runs:

This is how it should look like:

It does not matter how I trigger the tests on those machines, I have been cloning the build definitions already and running it as a non multi config build and it also does not work...

@hubertusgr did you enable "Distribute tests by number of machines" in Run Functional test task?

@nigurr  No I did not enable this, should I?
because I have only one machine inserted.

For your info:
Even before I switched over to having one test run with multi configuration, the test runs on the other machines (except the one where it works fine) where not executing all tests.
In the results of the run there are also less trx files attached.
Can you read out anything that might be wrong from the dta logs?

@kaadhina will look into this

@hubertusgr I'm not sure if i got you right.
If you are trying to execute your test cases once, but distribute them over multiple machines: ensure you enable "Distribute tests by number of machines" to distribute equal number of test cases across the machines you have specified. And provide the logs collected from each of those machines.
If you are trying to run all the test cases multiple times, each time on different machine, by specifying multi-config: what is the issue here? The task would have triggered multiple times, each time with different config value. Provide us the build logs for this if this does not work.
You can mail us at devops_tools[at]microsoft[dot]com with the information.

Also, there is a new version available for the Deploy test agent task. You can switch to the new one if not already done.

About the new version: As far as I know this does not work with on premise before 2017U2 comes out?
About your first question:
We are trying to execute all tests multiple times with different config values. The following screenshot show that we execute three builds at the same time with different configurations pointing to different machines. (The title run tests ***test.dll is misleading because we do take the tests from a test plan! Also please ignore the one failing at the copy task...)

On the machines only on the machine TE06 all tests are actually executed. On the others only 2 or 3 test suites are being executed and then the run states to be done (even if more test suites are selected...)
In the summary you can see that all test cases which should have been executed are actually listed but most of them are never run and can be seen with the outcome others:

This is the execution log where all selected tests are getting executed (config that starts with te06)
DTAExecutionHost - TE06.txt
These are the others:
DTAExecutionHost - TE05.txt
DTAExecutionHost - TE04.txt
These are the others:

Hi!
I have found one suspicious line in the dta log:
I, 5020, 15, 2017/06/13, 03:13:48.983, VIE1QATC04\DTAExecutionHost, DefaultTestRunEvenHandler.OnTestRunMessage : VstestAdapter.Execution - RunMessage : An item with the same key has already been added.
The following git hub issue seems to have a similar problem:
https://github.com/Microsoft/vsts-tasks/issues/2308
Could it be that I have a similar issue? What is the automated test ID and how can I check if this is not properly set on some tests. (the environment which is working is executing a reduced set of tests as it has a configuration that does not allow all tests to run, this might be the cause why this environment is running through and the other wich execute the full set of tests run into this issue....)

Hi,
I can see that there is a mismatch in the number of test cases discovered to begin with. One reason I can think of is, the binaries in some machines might be stale. I would suggest you to clean up the test drop locations on all machines and retry.
The duplicate IDs might have been the issue here. You can check if you have multiple test cases linked to the same test method. In the test plans page on the server, use "add column options" to add Automated test id column to check this. Or you can also simply check the FQDN of the associated test method

The number of test cases is mismatching because not all test cases have all 4 configurations assigned. The one that is working has the least number of test cases assigned so if duplicate ids are the issue they must be in those test cases that are not being executed by the working environment. I will report back after checking the linkings...

I  have found some issues with double linking and now it seems to be fine and all tests are getting executed.
Thanks for your help here!


Feature/issue 119 fix fake redis delete incr incrby

Some fixes to make return types conform better to real redis
delete needed to return True / False depending on success of operation
incr must return an int, but leave the stored incremented value as a string for future get operations,
furthermore, if the current value can't be cast to an int, it is treated as a zero.

Looks good. I'll trust that you've actually verified all the behaviour with the real redis client. :-)

jerith: red testing on real redis ...
been doing that in my 107 branch - that's what set this in motion - this makes FakeRedis compliant for the range of func. used by the smpp client


Google Not allowing to create app name with 3 length charactor

I created a project named GCP1 because Google does not allow me to use a name that is three characters long.
When I try to sync my calendar, it is not letting me do so.

I was wondering if there is a workaround for this.

I don't think this is not an issue of this plugin, so closing.

I think this is not an issue of this plugin.


Tutorial link in README.md is not work

Tutorial Select
Image Classification
Feedback
Tutorial Page Not Found
Tutorial link in README.md is not work.

Tutorial link in README.md is 'https://playtorch.dev/docs/tutorials/image-classification'.  But it is linked as Page Not Found.

You should probably set the path to 'https://playtorch.dev/docs/tutorials/snacks/image-classification/'
It's minor, but I think it'd be nice to fix it :)

Hi @cjfghk5697, thanks for reporting the broken link.
The link to the image classification tutorial that you provided is the correct link
https://playtorch.dev/docs/tutorials/snacks/image-classification/
Do you want to submit a PR?

Of course, Can i submit a PR?

Sure, I submit PR(https://github.com/facebookresearch/playtorch/pull/75).
Thank you for your kind reply.

@cjfghk5697 the change looks good. Can you check out the automated response in #75?

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

We can merge the change when the CLA check passes

Thanks for your help! I posted a PR(https://github.com/facebookresearch/playtorch/pull/76) again.


Documentation for func.yaml

Is this something I write myself or is it always generated by fn?
What are the required and optional fields? I'm assuming the answer to this will help me debug this error:
$ fn routes create myapp /hello
error: function image name is missing
$ ls
func.yaml hello.go
$ cat func.yaml
name: adelevie/hellogo
version: 0.0.1
runtime: go
entrypoint: ./func
$ cat hello.go
package main

import (
    "encoding/json"
    "fmt"
    "os"
)

type Person struct {
    Name string
}

func main() {
    p := &Person{Name: "World"}
    json.NewDecoder(os.Stdin).Decode(p)
    fmt.Printf("Hello %v!", p.Name)
}

I think someone must have been broken in some recent commits. That should work and I just verified and got the same error.
cc @pedronasser @seiflotfy

I'm actually working on that fix at this moment.

I don't see whats broken....
fn routes create myapp /hello iron/go
the image is missing and it has to be accessible via docker or locally

@seiflotfy it used to read the image name from func.yaml, now it doesn't seem to work.

Should be fixed now, get latest cli and try again.


Add rules

@ntwb Sorry, I've only just seen your comment about setting up this repo. I totally missed it when the issue was closed and we were celebrating the first release of the linter!
Better late than never though :)
I've added some basic tests to make sure the config isn't malformed. I've given you access to the repo though, so you can change anything to your liking :)
Please don't hesitate to give me a shout if you need a hand with anything. And sorry again for the delay!

Awesome, thanks, I'll take a look around and we'll start to get things moving :+1:

@ntwb I wanted to test out the options validator we've just added to stylelint, so I took a quick stab a round-one of the config.
I'm thinking of releasing 0.1.0 now we have a config. Does that sound good to you?
( p.s. the options validator caught a typo in the config, which was nice :) )

Yes, please do, I'll go create a patch for WordPress and get some more eyes on it.
On 31 Jul 2015, at 7:48 pm, Richard Hallows <notifications<EMAIL_ADDRESS>wrote:
@ntwbhttps://github.com/ntwb I wanted to test out the options validator we've just added to stylelint, so I took a quick stab a round-one of the config.
I'm thinking of releasing 0.1.0 now we have a config. Does that sound good to you?
( p.s. the options validator caught a typo in the config, which was nice :) )

Reply to this email directly or view it on GitHubhttps://github.com/stylelint/stylelint-config-wordpress/issues/1#issuecomment-126629110.

I've added a couple of patches and comments https://core.trac.wordpress.org/ticket/29792#comment:34
Just need to dig around and iterate on our defined rules and/or standards to bring both in sync

I've just released 0.1.0 for you :)

I've added a couple of patches and comments https://core.trac.wordpress.org/ticket/29792#comment:34

It's great to see the linter tried against such a large css codebase!
Feel free to give me a shout if you have any questions. I'm going to close this issue now. You have write access to this repo, so feel free to clone and make PRs. Likewise, if you have a npm user I can give you access to publish new versions yourself.

Just need to dig around and iterate on our defined rules and/or standards to bring both in sync

Good stuff. If you're looking for inspiration on refining your standards then I recommend checking out , if you haven't already, the very sensible SUITCSS HTML/CSS code style. It's a slightly stricter (read: better for a linter) version of the popular idiomatic CSS i.e. it's explicit about things like double quotes and alphabetically order properties, whereas the idiomatic one is a bit more ambiguous. The SUITCSS also aligns nicely with the Wordpress one, with a couple of extra holes plugged in.

I've just released 0.1.0 for you :)

Awesome, thanks very much

Likewise, if you have a npm user I can give you access to publish new versions yourself.

My NPM username is netweb https://www.npmjs.com/~netweb
(I'm netweb at most places on the interwebz :smirk: )
Will also check out the other resources you've linked to help plug any holes we have in our current standards :+1:

I've added you to npm. Feel free to make releases :) I'm not sure if you'll find it useful, but we've been using https://github.com/MoOx/setup/blob/master/bin/npmrelease to help out with releases. Just change the package.json version number and "Head" bit of the changelog, then run the script for a nice github release :)
Just a thought... tackling those 4000 issues doesn't sound like much fun. Have you thought about running the codebase one-time through csscomb (https://github.com/csscomb/csscomb.js) and postcss-remove-prefixes (https://github.com/johnotander/postcss-remove-prefixes). That'd hopefully address most of issues. Once the codebase is clean, you can then move to stylelint to enforce your styleguide going forward.

From the original Trac ticket: There may also be a thing or two that we could enforce per our own standards, such as requiring a comment to follow any declaration with !important.

Also, if you're feeling up to it, you can plugin your own rule to support this. Although, that's probably for much later down the line :)

https://github.com/MoOx/setup/blob/master/bin/npmpublish + https://github.com/MoOx/setup/blob/master/bin/npmrelease ;)

Thanks, and I think you meant this https://github.com/MoOx/setup/blob/master/functions/npmpublish plus https://github.com/MoOx/setup/blob/master/bin/npmrelease :smirk:
I'll definitely take a look at these when it comes time to package up and release a new version and as I've never done said task before I'll take a closer read then, but again much everything you've all done, it is greatly appreciated :smile:
I'll take a look at those ~4000 issues later next week and whittle down that list significantly, one thing we don't do is code refactoring should not be done just because we can, we did pretty well when we previously looked at using CSSLint for all this, I think we can get to a decent place without to much work, but I'll know for better or worse next week ;)

I'll take a look at those ~4000 issues later next week and whittle down that list significantly, one thing we don't do is code refactoring should not be done just because we can,

Makes a lot of sense :)


WIP/MESOS: Pass through proxy logs to executor log output

Fixes https://github.com/mesosphere/kubernetes-mesos/issues/417
The log output looks like this:
I0728 09:38:09.865143     182 service.go:573] proxy: I0728 09:38:09.865111     191 iptables.go:193] running iptables -N [KUBE-PORTALS-CONTAINER -t nat]

An alternative would be to use https://github.com/natefinch/lumberjack and rotate the proxy.log file.

The kubelet-executor launches the proxy internally because it helped keep deployment simpler for development at the cost of adding a process lifecycle dependency between the two procs. As ugly side affect of this was the the executor piped the proxy logs to a separate file to keep the log files easier to read.
Honestly I really don't like the idea of the executor mantaining the lifecycle of the proxy process in a production setting. The processes should be completely independent. We should be aiming to more closely align our process lifecycle model after upstream. Piping the logs from the proxy through the executor's stderr stream works against this idea and also further complicates the log files.
Please, let's avoid this approach.

I don't disagree. But we really need something simpler than copying around installer tar files, patching the system with bind bind mounds and so.

Superseeded by #11928


Refactor FormFieldWrapper components

Description
We have a shared component called FormFieldWrapper. There are some parts of it that use old patterns that we'd like to update.
There are these get getter type functions that return JSX. Really these should be components that return JSX in accordance with modern patters.
This would would be to assess those parts of FormFieldWrapper and refactor and improve them.
For example, this getHintContent, should be a component called HintContent:
  const getHintContent = hintContent => {
    return hintContent ? (
      <span
        id={getHintContentId()}
        className={cx(
          tintContentSecondary,
          display("block"),
          padding("top", "xxs"),
          textSize("s")
        )}
      >
        {hintContent}
      </span>
    ) : null;
  };

The same thing for getValidationErrors.
With these updates make sure to do regression tests and everything should work in the exact same way.

Contribution Guide
If this is your first time contributing to UI Kit, please review the How to Contribute guide beforehand.

Can I be assigned this issue?

@Chirag-Nanda sure - I've assigned you to that issue.

can you explain a bit more on what exactly is the job needed to be done? Should I replace the entire getHintContent by HintContent?

can you explain a bit more on what exactly is the job needed to be done? Should I replace the entire getHintContent by HintContent?

That's correct. getHintContent should become a functional component and you can replace it's usage everywhere possible and then remove the getHintContent function once that is completed.  You can isolate the work for getHintContent into one pull request and you can do the validation errors in a separate pull request if you have interest in refactoring that one as well. Let me know if you have any other questions around that all.

@nataliepina I have made the changes can you please verify them?


feat: add image.digest value to deployment and cronjob

Add an optional image.digest field to Deployment and CronJob resources.

@aslafy-z Validation Successful

@aslafy-z can you plz add description to the PR as well? And great thanks for the PR

@aslafy-z can you plz fetch changes from main branch?

@rasheedamir done :)

@aslafy-z  digest can be added as tag in values.yaml. what is the use case of having this as separate value?

@hanzala1234 I made a mistake, it's now fixed. @ should be used as a separator instead of : as per https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy. Please take another look.

@aslafy-z can you plz update the changelog? my apologies for delay; missed the PR

@aslafy-z can you plz resolve merge conflict and change version to 1.2.10

@rasheedamir Done

thank you @aslafy-z for the PR! looking forward to more PRs


Migration support for classic vnet with App Service Environment

Hi team,
I am from the App Service Environment team managing the cloud services retirement and migration for that product. We have a scenario where App Service Environment v1 that is in a classic vnet that needs to be migrated to App Service Environment v3 in an ARM vnet. For now, our guidance is that customers will need to manually recreate their new App Service Environment v3 since our automated migration feature doesn't support migrations for classic vnets. Wanted to know if migrating classic vnet that contains an App Service Environment to ARM vnet was in your roadmap. For this scenario, once in an ARM vnet, customers would be able to use our automated migration feature to get them to App Service Environment v3.
Thanks in advance!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: abb30484-04e7-3ba3-2d5c-51b312ad5c69
Version Independent ID: f9a80b3f-ad3e-2985-dfbf-b69b6f614daa
Content: Overview of platform-supported migration of IaaS resources from classic to Azure Resource Manager - Azure Virtual Machines
Content Source: articles/virtual-machines/migration-classic-resource-manager-overview.md
Service: virtual-machines
Sub-service: classic-to-arm-migration
GitHub Login: @tanmaygore
Microsoft Alias: tagore

Hi @seligj95 thanks you for the detailed question. We are currently investigating to see if this scenario is possible and will update you when we have accurate information to provide.

@seligj95
I checked with internal team on this ask. Requesting you to please check the retirement announcement for App Services and follow guidance shared in here.
Hope this helps.

Hope the provided information is helpful.
We will now close this issue. If there are further questions regarding this, please tag me in a comment. I will reopen it and we will continue the discussion.


dbeaver/dbeaver-ee#899 add universal code to handle tree with checkboxes

It is not clear fixTree does. Requirement to call it manually for every tree looks poor (you could do this in constructor).

I believe I've found a better approach.


docs: fix simple typo, collapseable -> collapsable

There is a small typo in deps/nuklear.h.
Should read collapsable rather than collapseable.

I’d even go for “collapsible”, which seems to be recommended by various dictionaries.


fix prettier

Proposed changes
Uniform coding style
Types of changes
What types of changes does your code introduce to the project: Put
an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation (improve documentation)
[ ] Continuous Integration (functionality that improve automation or testing)
[ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to
ask. We're here to help! This is simply a reminder of what we are going
to look for before merging your code.

[x] I have read the CONTRIBUTING doc
[x] I have signed the Contributor License Agreement
[x] I have updated the RELEASE NOTES
[x] I have added tests that prove my fix is effective or that my
feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in
downstream modules

Further comments
N/A

@Valecant I will merge this after the other two open PRs.
code will need to be linted before merging

@Valecant can we merge this pr?


Python3.6 compatibility upgrade for xdis zopetesting

Motivation for this change
Python3.6 compat
Things done

[ ] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Thanks!


gallery-view

Title and Issue number

Title : Gallery page destination is fixed #73
Issue No. : #73
Code Stack : HTML, CSS
Close #73

Video/Screenshots (mandatory)

travel_guide.webm
Checklist:

[X] I have mentioned the issue number in my Pull Request.
[ ] I have commented my code, particularly in hard-to-understand areas
[X] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Are you contributing under any Open-source programme?

@Lavanya-Sathya thank you for your valuable contribution


proposal: time: improve performance of calendar algorithms and clarify its specification

TL;DR:
The proposal is to improve the performance of Go's time package using the recent algorithms developed by Neri and Schneider [1]. Their algorithms are faster than alternatives and they have been adopted by libstdc++ (the GNU implementation of the C++ Standard Library) [2], the Linux Kernel [3], .NET [4] and Firefox [5]. My benchmarks confirm performance improvements in Go as well. (See below.)
To achieve better performance we should change the supported range of dates: instead of supporting years taking any int value, they should be restricted to a much smaller range which still spans tens of thousands of years.
Check the benchmark results that I obtained after implementing Neri-Schneider algorithms in Go source code.

Implementation:
Cassio Neri and I have implemented in Go source code the 32-bits versions of Neri-Schneider algorithms. They support dates from -1,468,000/Mar/01 to 1,471,745/Feb/28. Unfortunately, the current documentation of
`func Date(year int, month Month, day, hour, min, sec, nsec int, loc *Location) Time`

doesn't explicitly state the range of supported dates but, since the argument year has type int, one might expect that any year from math.MinInt to math.MaxInt is allowed. This is further confirmed by the test TestZoneBounds which uses math.MinInt32 as a minimum year. Only this test fails when I replace the current implementations with Neri-Schneider algorithms.
The main goal of this issue is to argue that the range supported by Neri-Schneider algorithms is more than enough for all practical applications (*). We also believe that the specification of the time package should explicitly state the range of supported dates. Moreover, this range should be smaller than the one supported by Neri-Schneider algorithms just in case faster but more restrictive algorithms are found in the future. Consider, for instance, the range specified by other popular programming languages:
C++ [6]:
from 1970/Jan/01 - 12,687,428 days to 1970/Jan/01 + 11,248,737 days, that is,
from -32,767/Jan/01 to 32,767/Dec/31.
C# [7]: from 0001/January/01 to 9999/Dec/31.
Ecma Script (a.k.a. JavaScript) [8]:
from 1970/Jan/01 - 100,000,000 days to 1970/Jan/01 + 100,000,000 days, that is,
from -271,821/Apr/20 to 275,760/Sep/13
We believe that any of those ranges are more than enough for the large majority of users and, concretely, suggest to set Go to use the same range as C++. (As mentioned above, the 32-bits implementations support a much larger range.) If you agree that it is fine, then I could submit the PR showing how it was implemented.
Follow the time's package benchmark. As you can see other functions got the benefits as well.

(*) It's worth mentioning that the Gregorian calendar is still not perfectly aligned to Earth's motions and a small error is accumulating. In a few thousands of years the error should be quite noticeable. Furthermore, Earth's rotation is slowing down which amplifies the problem [9]. The point here is that it's virtually impossible for the Gregorian calendar to remain in use in the next few thousands of years, let alone in billions of years.
References:
[1] Neri, C, Schneider, L. Euclidean affine functions and their application to calendar algorithms. Softw Pract Exper. 2023; 53(4): 937–970. doi:10.1002/spe.3172
https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3172
See also Cassio Neri's presentation on calendar algorithms at C++Now 2023.
https://www.youtube.com/watch?v=0s9F4QWAl-E
[2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/chrono;h=10e868e5a036924177cf952a81f4bce10c497106;hb=HEAD#l1673
[3] https://github.com/torvalds/linux/blob/master/kernel/time/timeconv.c#L78 and https://github.com/torvalds/linux/blob/master/drivers/rtc/lib.c#L68
[4] https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/DateTime.cs#L1377
[5] https://searchfox.org/mozilla-central/source/js/src/jsdate.cpp#217
[6] https://eel.is/c++draft/time.cal.ymd#members-20
[7] https://learn.microsoft.com/en-us/dotnet/api/system.datetime.minvalue?view=net-7.0#remarks and https://learn.microsoft.com/en-us/dotnet/api/system.datetime.maxvalue?view=net-7.0#remarks
[8] https://262.ecma-international.org/14.0/#sec-time-values-and-time-range
[9] Duncan S. Marking Time: The Epic Quest to Invent the Perfect Calendar. 1st ed. John Wiley & Sons; 2000.

kindly CC @rsc (per https://dev.golang.org/owners)

We also believe that the specification of the time package should explicitly state the range of supported dates.

It should be possible to split codepath into slow and fast versions depending on the year value without defining any new constraints on the yer value, shouldn't it?

We also believe that the specification of the time package should explicitly state the range of supported dates.

It should be possible to split codepath into slow and fast versions depending on the year value without defining any new constraints on the yer value, shouldn't it?

Thanks @AlexanderYastrebov . It's possible, but I'm not sure if it's suitable. I've changed some functions, like absDate, daysSinceEpoch and Date, and we would add some complexity (and another branch) for a range of date that is unusal and that other languages already don't support. IMHO we should even add some asserts and panic if the year is outside the "new" specification. Make sense?

@normandesjr

IMHO we should even add some asserts and panic if the year is outside the "new" specification. Make sense?

Panicking is a bit extreme, innit?
If I understand Cassio Neri's example C++ code correctly, he restricts values only for the duration of the calculation.  Something like this (but also handling negative years):
	const (
		CycleLength     = SomeNumberIDK
		DaysPer400Years = 146097
		YearCycle       = 400 * CycleLength
		DayCycle        = DaysPer400Years * CycleLength
	)
	cycles := year / YearCycle
	year %= YearCycle
	days := CalculateDate(year, month, day)
	days += cycles * DayCycle

I would propose limiting timestamps to those that can be represented by int64 (i.e., handling overflow), or close to it (capping the year value to prevent overflow), and using the mechanism above to deal with calculations whose intermediate values may overflow.

Furthermore, Earth's rotation is slowing down which amplifies the problem

UTC is not the only kind of UT, so this shouldn't prevent me from printing the time when atoms started forming with nanosecond precision ;)

@unixdj

[...] there may well be code out there that operates on values far away from now (e.g., for carbon dating or astrophysics), formatting the time as fmt.Sprintf(-t.Year() / 1000000, "million years ago").

Indeed, astrophysicists might be interested in billions of years. But this is a niche domain with clever people that are very capable of rolling their own algorithms.

Because if Go supports timestamps of almost 300 billion years from now, why roll your own?

For two reasons.

Supporting billions of years rules out algorithms that require fewer instructions (save memory, especially in instruction cache), are faster and spend less energy. Hence, if Golang support billions of years, every user will bear the costs for, presumably, the benefit of a few specialists in niche domains.

The clever people from these niche domains might not be interested in Time.Year() after all! Indeed, Time.Year() calculates the "year" that most of us consider in everyday live, i.e., year in the Gregorian calendar. (As you said, the "perpetual Gregorian calendar is a fiction anyway", so who uses it for calculations of billions of years?) Astronomers talk about sideral year, solar year, tropical year, vernal year, etc. They have their own time keeping system called Julian Day Number (JD) invented by Joseph Scaliger in 1583 and based on the average Julian calendar year of 365.25 days. Here is a quote from the International Astronomical Union (IAU) [1]:

Although there are several different kinds of year, the IAU regards a year as a Julian year of 365.25 days (31.5576 million seconds).

Hence, even if Time.Year() supports billion of years, for astronomers, it produces the wrong result and they won't use it.
Furthermore, from the number of SI seconds since the JD epoch, they can get the number of years by a simple division by 31,557,600. In summary, for astronomers Time.Year() is wrong and slower than what they can implement.
[1] https://www.iau.org/public/themes/measuring/

@cassioneri

Although there are several different kinds of year, the IAU regards a year as a Julian year of 365.25 days (31.5576 million seconds).

Interesting, I didn't know this.

But this is a niche domain with clever people that are very capable of rolling their own algorithms.

True.  But I suspect that in many cases time.Time is probably involved at some point, which is what I meant by "why not" (it's there, might as well use it).  I suspect that people working, say, with dates in Ancient Rome might wrap Time and override some methods for converting dates to use old Roman calendars before a certain date and call standard methods after, and astronomers might display the time as Julian years but convert it using Time.Unix for storage.  Go enables this approach quite well, and I've done it with Time (for other reasons).
In any case, the Go core team will likely insist that the Go 1 compatibility promise is not broken.
Look, I understand your point.  You never need to display the time of the formation of a galaxy as -11000000000-08-06 11:23:05.123456789 +0200 CEST.  And I see that your algorithms are so fast that doing div-mod of the time by 10,000 or 100,000 years (perhaps conditionally after a comparison) will make calculations significantly slower.
Not the whole range works now, mind you.  The time pkg doesn't convert dates before year -292277022399 of the perpetual Gregorian calendar, some 250 years after 1970-01-01 - 1<<63 seconds, correctly, and I expect weirdness on the other end too.
But I'm just not sure how much you can further restrict the range without breaking the compatibility promise that the Go team takes quite seriously.
And I hope you can see why panicking is not a good solution for Go, or at least for Go 1.  I'm pretty sure the Go team would prefer to cap the value, return sentinel values or even document the limitation and return garbage.
Speaking of which, wouldn't a check like
if uint64(t) >= yearOneMillion {
	cycle, t = t / millionYears, t % millionYears
}
y, m, d := calculate(t)
y += cycle * 1000000

be almost as fast as this, for times within the range?
if t < lowLimit || t > highLimit {
	panic("what are you, an immortal?")
}
y, m, d := calculate(t)

As I wrote in https://github.com/golang/go/issues/63844#issuecomment-1810175085 it should be possible to have two implementations conditioned on the year value. The existing implementation would need to stay anyways to verify correctness of the new code. Once proof of the pudding exists it might be easier to establish new API constraints.

There is also a related https://github.com/golang/go/issues/56909 that reports year overflow above/below certain values

I believe there's a misunderstanding about the scope of the proposal. Let me clarify.
It does not propose limiting all functionalities of time to smaller ranges. It covers  only functions based on the Gregorian calendar, namely, Date, Year, Month, Day, ISOWeek, YearDay and AddDate.
Functions that only need the number of ticks from epoch remain the same. Going back to the astronomers example, they can get IAU year by calling t.Unix() and dividing the result by 31,557,600. The proposal would not change anything on this perspective and billions of IAU years would still be supported in this way.
@AlexanderYastrebov: There's no need to add an if. The 64-bits version of our algorithms can support billions of Gregorian years. This is more effective than adding the if but still more costly than using the 32-bits version (which supports "only" millions of years.) I'd prefer avoiding extra costs altogether since supporting billions of Gregorian years, as I'm trying to say, is meaningless.
As we can see from comments on other issues, as far as time is concerned, Go is very vague on its promises. People have revoursed to reverse engineering or to look very deeply in the sources to find out supported ranges. IMHO, the current situation is quite messy and fragile. I think this proposal is a step in the right direction to fix many issues. It sets out a reasonable range of dates that is enough for the vast majority, if not all, real users and brings clarity, speed and energy savings for them.

The 64-bits version of our algorithms can support billions of Gregorian years.

I took @normandesjr's code from https://github.com/normandesjr/go/blob/feat/date-algorithm/src/time/time.go and converted absDate and Date to use uint64.  It works beautifully.  Check this out (I used it outside the Go source tree, to avoid stashing my changes):
https://gist.github.com/unixdj/e31f75d5b49b5a2b3b4fbbae69368937

This is more effective than adding the if but still more costly than using the 32-bits version (which supports "only" millions of years.)

How much overhead does it add?
FWIW, a quick benchmark shows that my version of absDate runs faster.  I looked at the assembly and eliminated one addition, but I don't speak amd64.   First column: original, second: after changing the beginning of absDate as below, third: uint64, times for 100M runs.
        const (
                s = 3670
                K = 719468 + 146097*s
                L = 400 * s
        )
        N := uint32(abs/secondsPerDay - uint64(unixToInternal+internalToAbsolute)/secondsPerDay + K)

743.328392ms    708.183141ms    644.01476ms
718.081683ms    691.610367ms    653.935377ms
738.729335ms    701.506694ms    656.245927ms
736.034086ms    702.445939ms    641.974361ms
725.429312ms    688.144645ms    639.662721ms
722.263895ms    773.823083ms    657.371755ms
719.608441ms    696.451653ms    649.812959ms
715.551736ms    692.676515ms    647.024967ms

As we can see from comments on other issues, as far as time is concerned, Go is very vague on its promises.

True, unfortunately.

@normandesjr Can you also change isLeap to @cassioneri's algorithm?

@normandesjr Can you also change isLeap to @cassioneri's algorithm?

Done.

I've just did an update with @cassioneri's patch, follow the new benchmark:

Now takes more time now?  That's weird.

It does not propose limiting all functionalities of time to smaller ranges. It covers  only functions based on the Gregorian calendar, namely, Date, Year, Month, Day, ISOWeek, YearDay and AddDate.

So what would the behavior of Date be for a Time value produced by calling Add with a positive duration on the maximum supported time.Time?
I think we should not only limit the range, but also limit the intermediate values so that they don't exceed that range: it would be surprising to reject a value in time.Date only to have exactly that same value returned from a call to the Date method on a time.Time variable.

(compare: https://github.com/golang/go/issues/20678#issuecomment-309590702)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

@cassioneri, I really enjoyed reading your paper. Thanks very much for taking the time to do the research and write it up. Lots of great ideas in there.
@normandesjr, thanks for taking the time to write a PR and file this issue and start this discussion.
The year is limited to 16 bits in C++ because it is limited that way in C, and the limit in C comes from originating on 16-bit machines in circa 1969. I don't see a strong reason to adopt that limit in 2024, especially retroactively. I understand and agree with the point that times more than 32,767 years before or after now are meaningless, but since they worked in earlier versions of Go, you can bet that some code somewhere is using times with larger years as sentinels. For example something like:
var forever = time.Date(100000, January 1, 0, 0, 0, time.UTC)

Sure enough, here's a real example and another and another. Even though no one is planning for the year 100,000 or thinks the code will be running then or even thinks the Gregorian calendar will still be in use, times like that are still useful in a program. Programs create their own worlds.
Since those times can be constructed, it is important to be able to print them correctly and without panicking. It does not make sense to say they are valid but can't be printed, which is what it would mean for methods like Year or Date to panic or return incorrect results. Nor does it make sense to break a program that has defined an arbitrary future time like forever above.
The fact is that 32,767 is a fairly small number. People are very likely to reach for larger ones, as shown by the real examples. Those might as well work, and they do today. We won't take that away. Although it's not documented explicitly, package time aims to work for times with years up to the signed 64-bit second limit, give or take, which is around ±292,277,022,000. If your limit is 32,767, then yes it is important to specify exactly what it is, because 32,768 or 99,999 is a plausible number you might try, and also because if you really are near the year 32,767 now you have to worry about whether it the limit applies to the year in UTC or the year in the local time zone or both. In contrast, when the limit is 292 billion, it is less important to specify these boundaries with significant precision. For practical purposes, there is no limit: one less thing to worry about.
It may be worth noting that Go is different from languages like C and C++ in that it has only one time type that represents both a time instant and a civil time in a specific location. We did that quite intentionally, after seeing how much code gets confused by decisions like whether to use time_t or struct tm in C. While it may be defensible to impose the 32,767 constraint on struct tm, not being able to print a time.Time in Go is like not being able to print a time_t in C.
Another reason to permit a very wide range of years is for interoperability with existing systems that permit larger ranges. It is useful to be able to round-trip the times from these systems into time.Time and back losslessly. For example:

PostgreSQL timestamps range from year -4,713 to 294,276; dates range from -4,713 to 5,874,897.
CockroachDB infinity times are in the years -4714 and 294,276.
Apache Cassandra uses signed 64-bit Unix milliseconds, so -292,275,054 to 292,278,994.
Other systems use signed 64-bit Unix microseconds, so -292,275 to 292,278.

Another reason is bugs and debugging. I do from time to time make mistakes :wink:, and when I do, I appreciate being able to debug them. If I have a bug in my program that accidentally creates a time with the year 100,000, I need to be able to see that value in order to understand what I've done. Again, times that can be constructed must be printable.
The cost of a few 64-bit operations at the start of the algorithm is one we will gladly pay to keep compatibility with all the existing Go programs in the world and to keep programs debuggable. An argument was made about energy savings and the like, but that's not based on any realistic math. We are talking about a few nanoseconds per call, and there are basically no programs anywhere that spend any appreciable amount of their time in these routines. I checked our internal production profiling at Google, and time.Date and time.Time.absDate are currently taking less than 0.01% of Go cycles. One frustrating hours-long debugging session caused by not being able to print an erroneous time.Time will cancel out years of accumulated savings.
Aside from the year restriction, the code in the pull request is not written in a way that we can easily adapt as needs arise over time, and it makes different calculations in the package use different epochs. I took some time and implemented the ideas in the paper in more idiomatic Go and in a way that fits more harmoniously into the surrounding time package. I've posted that change at https://go.dev/cl/586257. I got very good performance results, copied below, even better than what @normandesjr posted.
It's clear from my change that we can reap essentially all the benefits of the improved, faster algorithms without making any kind of backwards-incompatible API changes about which years are valid. And if we don't narrow the range of valid years, then no proposal is necessary. Instead, we can close this issue as declined/retracted, and I will work on getting my change reviewed and submitted. I'm inclined to do just that, leaving the question of which years are valid to another day and a separate discussion.
I expect the change will be part of Go 1.23 or Go 1.24. Please feel free to leave comments on https://go.dev/cl/586257 if I have missed anything.
Again, it's also important to remember that despite the very large percentages in the benchmark report, the absolute savings is quite small, especially in typical programs: a few nanoseconds here and there. Realistically, it's going to take quite a while for the accumulated savings to exceed the 10s of trillions of nanoseconds I spent reading the paper and implementing this. On the other hand, I had fun, I learned some new things, and the new algorithms are more elegant than the ones I'd used before, so it's a welcome improvement.

Instead, we can close this issue as declined/retracted, and I will work on getting my change reviewed and submitted.

Firstly, I wish to address a social aspect. Although you did thank @normandesjr for his contribution, IMHO, this is not enough to give the credit he deserves. If the above is done, then @normandesjr won't have any credit for his contribution in the repo's history and I find this very unfair.
It's OK to think that @normandesjr's patch is not in idiomatic Go and you can do better. When I implemented these algorithms in the Linux Kernel, in libstdc++ and in Firefox, none of my initial patches where good enough. The maintainers took their time, guiding me to improve my patches until they were all accepted and I got authorship credit. Although it required more work, I felt happy about that and keen on keep contributing. If they have dropped my patches and made theirs instead, I would never consider contributing to these projects again. Please don't get me wrong: I don't mean to imply any wrongdoing. I believe this is an oversight that needs to be properly managed.
Perhaps, you could add a tag Co-Authored-By: normandesjr if that suits him.
My technical remarks in decreasing order of importance follow:

"Undocumented range".

For practical purposes, there is no limit: one less thing to worry about.

I disagree. There has been too much emphasis on ±32,767 but this is a minor point, an arbitrary choice which I personally think is good enough but if you guys disagree, then pick a larger one. But please do pick one! Don't pretend there's no limit because there's a hidden one. As @normandesjr and I have repeatedly said and I can't stress that enough, whatever the range is, it must be explicitly documented.

Although it's not documented explicitly, package time aims to work for times with years up to the signed 64-bit second limit, give or take, which is around ±292,277,022,000.

Here you acknowledge that a limit does exist. Is there any unit test that checks these extreme values in different platforms? I doubt. Actually, if I'm not mistaken, with the current design, the limit is below the one you state. Indeed, consider the specification of functions Date and Year:
func (t Time) Date() (year int, month Month, day int)
func (t Time) Year() int

Clearly, year is of type int. The documentation states that int has an implementation-specific size which can be either 32 or 64 bits. Hence, if int has 32 bits, then year must be in [-2,147,483,648, 2,147,483,647]. In particular, they can't have all values in ±292,277,022,000.
Moreover, in the implementation there are lines of code similar to:
year := int(some_64_bits_value)

Hence, if some_64_bits_value has a value larger than the range of int, then the resulting year is wrong.
@normandesjr's PR doesn't have this bug mostly because it states the limits. If the user goes outside these limits then, its their fault (not Go's). If that happens, the user will immediately be made aware through the panic. I think this behavious is better than caring on using an year value that is completely wrong. However, as @normandesjr has said panicking is just a suggestion and a minor point of the proposal.
I assume that portability is important for Go designers and users. In this case, the arguments above show that year must be within the 32-bits range. This range is too large for my taste but it's definitely one that works. The 64-bits versions of many algorithms (not only mine) support this range. (But, without panicking, they are still subject to aforementioned silent conversion errors.)

Constructs like var forever = time.Date(100000, ...).

This point is very good. Preferring not breaking code using such constructs is fair and desirable and I find useful that you provided real use cases. (Rather than speculating who could use large year values.)
Nevertheless, these use cases clearly show that programmers wished to use something like Date.Max. However, the language doesn't document what the limits are, let alone provide a programmatic way of referring to them (i.e., Date.Max and Date.Min). Users are forced to work around this problem and choose some large year numbers (99999, 999999 or 40000).

Interoperability with DB systems.

This is a very good point against the ±32,767 limit but not against having a well documented limit. At the contrary, you have just increased the list of computer systems that clearly specify the supported date ranges. So far we've got: C++, C#, JavaScript, PostgreSQL, CockroachDB, Cassandra. Why shouldn't Go do the same?

C++'s choice.

I don't think the reason for ±32,767 is to keep compatibility with C. In any case, this value is not important. Only the existence of a reasonable limit is.
A summary of my thoughts
Please give @normandesjr the credit he deserves for his implementation.
Having a robust specification is far more important than the choice of algorithm. One can discuss how large the range might be but the existence of limits and the need for them to be documented should not be questioned. Hence, closing this issue as declined/retracted seems very wrong to me. Instead, I suggest renaming this proposal to something that in my opinion better states its main point: Restrict and document the supported range of years and Dates.
Although not my preference, one can use the 64-bits version of my algorithm (or any other) which does support billions of years. (In any case, years must fit inside the range of int32.) Once again whatever the algorithm, years and Dates have limits which must be clearly documented. (Have I say that before?)
Although I'd prefer panicking, this is yet a minor point. Drop it if you wish.

Thanks for the reply @cassioneri.
I do hear you about documenting the range of valid years in the Go code. There are other issues filed for that. This issue doesn't have to be about that. You are also right that the Date method and Date function work in terms of an int-typed year, making the potential years expressible at those moments smaller than the years that can be stored in a time.Time. For better or worse, the API is the API and we can't easily change it. (Compatibility again.)
Credit in open source is always a difficult issue, and I sympathize with wanting to have contributed code directly to Go. Any time I take anyone's code and revise it, I absolutely credit them in the commit message. That's required both ethically and legally for copyright reasons. That's not what happened here, though. I saw the linked CL 548155, but I didn't understand the code at all, and I knew from the discussion here that it contained range limitations that we couldn't accept. So I read the paper and wrote new code from scratch using only the paper, to make sure I understood it and could maintain it and also that it didn't contain any hidden assumptions about valid time ranges.
There are many approaches to open source generally, and also many approaches that can be appropriate for a specific suggested change. If a change needs minor work to get submitted, then it absolutely makes sense to work with the contributor of that change. However, if, as the author and maintainer of Go's time package, I agree with the idea but would rather implement it in a completely different way, it can make more sense and save time for everyone involved to write the code anew myself. If you read both changes, perhaps you will see what I mean about it being completely different. In some cases it's common not to know exactly what the desired form is until I've done the exercise of writing the code, because only then do I understand what's going on. There were a variety of things that needed adjusting and cleanup in package time to properly accommodate the new algorithm, and those things are better done by the maintainer than someone new to the code base.
Note that there are a variety of ways to approach open source and some projects don't even accept outside contributions at all. The Go project is not that extreme. While we do try to help contributors revise their changes whenever possible, sometimes that's simply not possible, as happened here. I apologize that it means @normandesjr will not have an Author line in the Go Git repo from this PR. What matter most is getting to the right change that fits well into the existing Go source code, is readable, and will be maintainable for the next decade.
I did update the CL 586257 commit message to credit and thank both of you. Again I very much appreciate the time and effort that got us to this significant improvement, even if the code itself was not directly used. The most important output of engineering is understanding. The code is only a vehicle to achieve that understanding. The understanding you both contributed was critical to landing this improvement. Thank you again.

The optimization CL is pending and should be in Go 1.24. We just froze the tree for Go 1.23 and it didn't make it into that. There are also potential compatibility problems that would be good to give more time to shake out.
That said, with the optimization taken care of, the only thing left in this proposal is narrowing the year range. For the reasons above, we almost certainly shouldn't do that, so I will mark this proposal as likely decline.
Even though it says likely decline, the new algorithms will land. Thanks again.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

No change in consensus, so declined.
— rsc for the proposal review group


#18553 Get host and port from url for native tools if connection is by url

Dump and Restore should work for PostgreSQL and MySQL when connection was configured by specifying host and port and when connection was configured by url,

Verified


error in frontend

[default] C:\wamp64\www\loopback-angular2-auth-demo\client\src\app\pages\login\login.component.ts:50:14
Property 'id' does not exist on type '{ username: any; email: any; password: any; type: any; }'.
getting this error while running code in client directory.
Please mention every step to setup this directory.

Similar issue here:
[default] /../loopback-angular2-auth-demo/client/src/app/app.module.ts:7:10
Module '"/../loopback-angular2-auth-demo/client/src/app/sdk/index"' has no exported member 'SDKModule'.
[default] /../loopback-angular2-auth-demo/client/src/app/pages/login/login.component.ts:50:14
Property 'id' does not exist on type '{ username: any; email: any; password: any; type: any; }'.
The server starts without problems. Second thing is how to disable mailgun?