Buggyamb - ASP.NET Core debugging scenarios

Summary
BuggyAmb is just a very buggy ASP.NET Core Razor Pages based application. This application was intentionally created as a buggy application so it can be used as a learning resource to practice troubleshooting some sample problem scenarios:

High CPU or low CPU performance problems, deadlocks.
High memory issues.
Crash issues and unexpected exceptions.

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

Hi Cam,
many thanks, I just removed the .gitignore and .gitattributes files.
Thanks,
AMB
From: Cam Soper @.>
Sent: Thursday, August 19, 2021 12:03 AM
To: dotnet/samples @.>
Cc: Ahmet Mithat Bostanci @.>; Author @.>
Subject: Re: [dotnet/samples] Buggyamb - ASP.NET Core debugging scenarios (#4740)
@CamSoper requested changes on this pull request.
Overall, looks great. Please remove the .gitignore and .gitattributes files, as those are handled at the repo level.
Since you're publishing an article elsewhere to cover the main content, I'm not too worried about doing an edit pass on the README. I think it's fine for a README, but I'd like @IEvangelisthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIEvangelist&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796698635|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ZYu7bzl%2BlJzdAWLn41RdnwD3kV1D6wJLoIgTaytcA9s%3D&reserved=0 to give his opinion, too.
Awesome work, Ahmet!

In core/tutorials/buggyamb/.gitattributeshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23discussion_r691598209&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796708589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=JjDxH8WuMMPqrXK4DnO4jVljCWlmyiaoCKas1X9DOm4%3D&reserved=0:

+###############################################################################

+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto

+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp

+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary

+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary

+###############################################################################
+# diff behavior for common document formats
+#
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain
You should delete this file. The .gitattributes file is set at the repo level.

In core/tutorials/buggyamb/.gitignorehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23discussion_r691599249&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796708589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=UlFhGoUOpZf5XQU3qjBLPDVOJlBStkx3WByY5NC4BZk%3D&reserved=0:

+_UpgradeReport_Files/

+Backup*/
+UpgradeLog*.XML
+UpgradeLog*.htm
+ServiceFabricBackup/
+*.rptproj.bak

+# SQL Server files
+*.mdf
+*.ldf
+*.ndf

+# Business Intelligence projects
+*.rdl.data
+*.bim.layout
+.bim_.settings
+*.rptproj.rsuser
+- Backup.rdl

+# Microsoft Fakes
+FakesAssemblies/

+# GhostDoc plugin setting file
+*.GhostDoc.xml

+# Node.js Tools for Visual Studio
+.ntvs_analysis.dat
+node_modules/

+# Visual Studio 6 build log
+*.plg

+# Visual Studio 6 workspace options file
+*.opt

+# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
+*.vbw

+# Visual Studio LightSwitch build output
+**/*.HTMLClient/GeneratedArtifacts
+**/*.DesktopClient/GeneratedArtifacts
+**/*.DesktopClient/ModelManifest.xml
+**/*.Server/GeneratedArtifacts
+**/*.Server/ModelManifest.xml
+_Pvt_Extensions

+# Paket dependency manager
+.paket/paket.exe
+paket-files/

+# FAKE - F# Make
+.fake/

+# JetBrains Rider
+.idea/
+*.sln.iml

+# CodeRush personal settings
+.cr/personal

+# Python Tools for Visual Studio (PTVS)
+pycache/
+*.pyc

+# Cake - Uncomment if you are using it
+# tools/**
+# !tools/packages.config

+# Tabs Studio
+*.tss

+# Telerik's JustMock configuration file
+*.jmconfig

+# BizTalk build output
+*.btp.cs
+*.btm.cs
+*.odx.cs
+*.xsd.cs

+# OpenCover UI analysis results
+OpenCover/

+# Azure Stream Analytics local run output
+ASALocalRun/

+# MSBuild Binary and Structured Log
+*.binlog

+# NVidia Nsight GPU debugger configuration file
+*.nvuser

+# MFractors (Xamarin productivity tool) working folder
+.mfractor/

+# Local History for Visual Studio
+.localhistory/

+# BeatPulse healthcheck temp database
+healthchecksdb
You should delete this file. The .gitignore file is set at the repo level.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23pullrequestreview-733344958&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796718550|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=JvyKaQme2pL%2B3TkqQksVW%2BNxGWazvSBoXV0ioKaCIiA%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAL2M37SCCBLSSMGPWUXOAVTT5QNXVANCNFSM5CMGGETA&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796718550|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=bKfhOoRIu0B6XpnjLVmrgJ1epHMrVQki%2FUH7MUC9taA%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796728503|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ojq1OwzxluOImJ4Io8gldlFZ4Q55OpbyR0vwK7b8ew8%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796728503|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=byoL%2FuDaQ3Ny4av3Y4Son8MznDfJ8WNBVFPRLd93Mxc%3D&reserved=0.

Sorry, please ignore previous change, I removed wrong files but fixed it.
I have removed the correct .gitignore and .gitattributes files and pushed to the origin.
Thanks,
AMB
From: Ahmet Mithat Bostanci
Sent: Thursday, August 19, 2021 4:21 PM
To: dotnet/samples @.>; dotnet/samples @.>
Cc: Author @.***>
Subject: RE: [dotnet/samples] Buggyamb - ASP.NET Core debugging scenarios (#4740)
Hi Cam,
many thanks, I just removed the .gitignore and .gitattributes files.
Thanks,
AMB
From: Cam Soper<EMAIL_ADDRESS>Sent: Thursday, August 19, 2021 12:03 AM
To: dotnet/samples<EMAIL_ADDRESS>Cc: Ahmet Mithat Bostanci<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [dotnet/samples] Buggyamb - ASP.NET Core debugging scenarios (#4740)
@CamSoper requested changes on this pull request.
Overall, looks great. Please remove the .gitignore and .gitattributes files, as those are handled at the repo level.
Since you're publishing an article elsewhere to cover the main content, I'm not too worried about doing an edit pass on the README. I think it's fine for a README, but I'd like @IEvangelisthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIEvangelist&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796698635|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ZYu7bzl%2BlJzdAWLn41RdnwD3kV1D6wJLoIgTaytcA9s%3D&reserved=0 to give his opinion, too.
Awesome work, Ahmet!

In core/tutorials/buggyamb/.gitattributeshttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23discussion_r691598209&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796708589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=JjDxH8WuMMPqrXK4DnO4jVljCWlmyiaoCKas1X9DOm4%3D&reserved=0:

+###############################################################################

+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto

+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp

+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary

+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary

+###############################################################################
+# diff behavior for common document formats
+#
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain
You should delete this file. The .gitattributes file is set at the repo level.

In core/tutorials/buggyamb/.gitignorehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23discussion_r691599249&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796708589|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=UlFhGoUOpZf5XQU3qjBLPDVOJlBStkx3WByY5NC4BZk%3D&reserved=0:

+_UpgradeReport_Files/

+Backup*/
+UpgradeLog*.XML
+UpgradeLog*.htm
+ServiceFabricBackup/
+*.rptproj.bak

+# SQL Server files
+*.mdf
+*.ldf
+*.ndf

+# Business Intelligence projects
+*.rdl.data
+*.bim.layout
+.bim_.settings
+*.rptproj.rsuser
+- Backup.rdl

+# Microsoft Fakes
+FakesAssemblies/

+# GhostDoc plugin setting file
+*.GhostDoc.xml

+# Node.js Tools for Visual Studio
+.ntvs_analysis.dat
+node_modules/

+# Visual Studio 6 build log
+*.plg

+# Visual Studio 6 workspace options file
+*.opt

+# Visual Studio 6 auto-generated workspace file (contains which files were open etc.)
+*.vbw

+# Visual Studio LightSwitch build output
+**/*.HTMLClient/GeneratedArtifacts
+**/*.DesktopClient/GeneratedArtifacts
+**/*.DesktopClient/ModelManifest.xml
+**/*.Server/GeneratedArtifacts
+**/*.Server/ModelManifest.xml
+_Pvt_Extensions

+# Paket dependency manager
+.paket/paket.exe
+paket-files/

+# FAKE - F# Make
+.fake/

+# JetBrains Rider
+.idea/
+*.sln.iml

+# CodeRush personal settings
+.cr/personal

+# Python Tools for Visual Studio (PTVS)
+pycache/
+*.pyc

+# Cake - Uncomment if you are using it
+# tools/**
+# !tools/packages.config

+# Tabs Studio
+*.tss

+# Telerik's JustMock configuration file
+*.jmconfig

+# BizTalk build output
+*.btp.cs
+*.btm.cs
+*.odx.cs
+*.xsd.cs

+# OpenCover UI analysis results
+OpenCover/

+# Azure Stream Analytics local run output
+ASALocalRun/

+# MSBuild Binary and Structured Log
+*.binlog

+# NVidia Nsight GPU debugger configuration file
+*.nvuser

+# MFractors (Xamarin productivity tool) working folder
+.mfractor/

+# Local History for Visual Studio
+.localhistory/

+# BeatPulse healthcheck temp database
+healthchecksdb
You should delete this file. The .gitignore file is set at the repo level.

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fsamples%2Fpull%2F4740%23pullrequestreview-733344958&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796718550|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=JvyKaQme2pL%2B3TkqQksVW%2BNxGWazvSBoXV0ioKaCIiA%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAL2M37SCCBLSSMGPWUXOAVTT5QNXVANCNFSM5CMGGETA&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796718550|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=bKfhOoRIu0B6XpnjLVmrgJ1epHMrVQki%2FUH7MUC9taA%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796728503|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=ojq1OwzxluOImJ4Io8gldlFZ4Q55OpbyR0vwK7b8ew8%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04|01|Ahmet.Bostanci%40microsoft.com|a7308eb2118f4b9c1a1908d9628b8a73|72f988bf86f141af91ab2d7cd011db47|1|0|637649173796728503|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=byoL%2FuDaQ3Ny4av3Y4Son8MznDfJ8WNBVFPRLd93Mxc%3D&reserved=0.


Only self-update when necessary

If there are no updates, self-update should not do anything, rather than re-install the old version.

@nrc, I think we can save the md5 file in ~/.tiup/bin/ and do nothing while the md5 was unchanged. How do you think?

I think it is a good plan to do initially. When we are thinking about overall architecture we should consider self-update. We probably want a manifest for tiup and then just check the current and new version numbers. We may even be able to treat TiUp like any other component in terms of how and whether we download and install (though actually installing will always be a bit different).

This is covered by the design in #193

Fixed


BPF_MAP_TYPE_PROG_ARRAY permits circular references

Programs stored in a BPF_MAP_TYPE_PROG_ARRAY can hold a reference to the map they are inserted in.
This results in programs that don't get cleaned when the loading program crashes.

@saxena-anurag, please add repo details.

PROG_ARRAY_MAP currently by design allows circular references. This caused issues in case of nested tail calls. Issue #671 provides repro details.
I had made some changes in PR #680 to allow clearing of prog array map from user mode, so that the circular reference can be broken, but in low memory conditions (or due some other issue), if the user mode app exits before clearing the prog array map, then both the map and program do not get unloaded.

@dv-msft Can you create the test cases we discussed?

This fix will require at least two new test cases. Specifically:

A test case with a 'direct' circular reference. For example, program1 -> some_map -> program1. While these results can be indirectly obtained via one of the existing test cases, it would be worthwhile to implement this one as a standalone test case of the MUSTFAIL type.
A test case with an 'indirect' circular reference(s).  For example, program1 -> some_map -> another_map -> ... -> program1.  This is a new test case and also needs of the MUSTFAIL type.


Clatrix not transposing V* matrix in correctly in SVD return

core.matrix API specifics that V* should be the transpose of the V matrix in the SVD decomposition. Clatrix is currently returning the non-transposed V.
See https://github.com/mikera/vectorz-clj/issues/47

@mikera thanks for raising and fixing this over here.
Should we handle this somewhere upstream, too, until it gets fixed in clatrix?
I currently have pending changes to Incanter with fixed tests. However these tests fail now, when using the clatrix implementation. Of course I could add something to Incanter, but core.matrix would seem to be more appropriate.
More importantly: Can we get this fix merged, please?

@nblumoe OK I merged it.... don't seem to have been any objections to this fix.
I can't make official Clatrix releases though

Do you not have Clojar's access? I can fix that.
—
Sent from Mailbox
On Mon, Jun 15, 2015 at 8:37 AM, Mike Anderson<EMAIL_ADDRESS>wrote:

@nblumoe OK I merged it.... don't seem to have been any objections to this fix.
I can't make official Clatrix releases though
Reply to this email directly or view it on GitHub:
https://github.com/tel/clatrix/issues/63#issuecomment-112049898

@tel - actually looks like I do have membership of the clatrix group on clojars....
a) does that mean I can make a release?
b) Should I? (this isn't my project after all!)

Ah, great!
I haven’t been an active maintainer for quite some time, so I don’t want to weigh in on decisions like that. I just wanted to make sure there wasn’t any structural reason you couldn’t release :)
Pinging @Quantisan?
—
Sent from Mailbox
On Mon, Jun 15, 2015 at 10:41 AM, Mike Anderson<EMAIL_ADDRESS>wrote:

@tel - actually looks like I do have membership of the clatrix group on clojars....
a) does that mean I can make a release?
b) Should I? (this isn't my project after all!)
Reply to this email directly or view it on GitHub:
https://github.com/tel/clatrix/issues/63#issuecomment-112093357

Please do @mikera
Looks to me like you've been the maintainer for this library for a while, so you make the call.

I'm happy discussing anything necessary for the release as necessary.

OK I created a 0.5.0 release - hope that works for everyone!

Great! Thanks!


SASSCompiler fails due to incomplete quotes in cwd

Hello! I've been having some trouble with pipeline and after some debugging I found the cause in the SASSCompiler. See code below.
class SASSCompiler(SubProcessCompiler):
    output_extension = 'css'

    def match_file(self, filename):
        return filename.endswith(('.scss', '.sass'))

    def compile_file(self, infile, outfile, outdated=False, force=False):
        command = "%s %s %s %s" % (
            settings.PIPELINE_SASS_BINARY,
            settings.PIPELINE_SASS_ARGUMENTS,
            infile,
            outfile
        )
        print(infile)
        print(dirname(infile))
        return self.execute_command(command, cwd=dirname(infile))

#--------------output-------------------
'C:\...\staticfiles\angular\test.scss'
'C:\...\staticfiles\angular

My print statement revealse that the dirname function accidentally (?) leaves the first of the quotes in the string which causes the command to fail.
adding dirname(infiel).replace("'", "") solves the problem.
Any ideas what is happening and what the root cause is?
I'm developing on windows 8.1 using python 2.7.9
The following sample reproduces the bug on my system
from os.path import dirname

test = "'C:/Users/test.scss'"

print(test)
print(dirname(test))

#C:\Users\Sverker\Desktop>python bug.py
#    'C:/Users/test.scss'
#    'C:/Users

This should effect all other compilers using the cwd command as well (sass, less & stylus)

Fix should be fixed by #519


Fix parsing of the References: header

When we replaced our home-grown mbox parser with a version that uses the mailparser, we did not adjust the regex when parsing the References: header.
As a consequence, our parser got confused when the references stretched over multiple lines (because the regex did not expect Carriage Returns nor Line Feeds).
Let's fix this.
This fixes https://github.com/gitgitgadget/gitgitgadget/issues/904.

Do you think there is a possibility of Message-ID being split over two lines (ie a line-end may need to be removed)?

There might be such a thing, potentially, but I'd have to research more how this would look. For now, I think we should be good enough with the current version.


Backport "chore: Backport changes from Metals" to LTS

Backports #19592 to the LTS branch.
PR submitted by the release tooling.
[skip ci]

No regressions detected in the community build up to lts-19605.
Reference


MINOR: refactor Log#read to avoid using "return" keyword in nested an…

scala throws and then catches NonLocalReturnException to implement the control flow of returning from a nested anonymous function. That is anti-pattern and we should avoid using it in the hot methods.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Are we using return inside an anonymous function here?

Ah, is maybeHandleIOException the issue?

I profiled one of our use case to trace the NonLocalReturnException. Log#read and Log#fetchOffsetByTimestamp produces most of NonLocalReturnException so I only refactor that two methods to keep this patch small.

@chia7712 what are the other cases where we do this in Log?

what are the other cases where we do this in Log?

The use case I mentioned is a heavy IO-load task of my (team) application. I didn't trace other potential hot methods for remaining use cases because it seems to me the IO-heavy is the most important case we have to care.
For another, Log has a bunch of anonymous functions which are using "return" to control flow. Maybe we should fix them at once even if they are not critical methods :)

Yeah, I would fix all the cases in this file at once if possible.

Yeah, I would fix all the cases in this file at once if possible.

sure

org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest > shouldUpgradeFromEosAlphaToEosBeta[true] failed. I test it on my local and it pass. retest this please

only shouldUpgradeFromEosAlphaToEosBeta fails. retest this please

retest this please

retest this please

@ijuma I have attached test result and NonLocalReturnException is gone. Please take a look.

Build / JDK 11 / kafka.api.PlaintextConsumerTest.testLowMaxFetchSizeForRequestAndPartition

pass on my local
Build / JDK 15 / org.apache.kafka.clients.admin.KafkaAdminClientTest.testMetadataRetries

it is already fixed by https://github.com/apache/kafka/commit/e4eab377e1489fc0cc90edec3eeb382b1192a442

Build / JDK 15 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true]
Build / JDK 8 / kafka.api.ConsumerBounceTest.testClose

unrelated failure. rebase to trigger QA

Build / JDK 8 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true]

It is flaky on my local so it should be unrelated to this patch. @ijuma Could you take a look?

Build / JDK 8 / org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta[true]

unrelated error. rebase

All green :)
@ijuma @hachikuji Could you take a look?

org.apache.kafka.streams.integration.StreamTableJoinTopologyOptimizationIntegrationTest.shouldDoStreamTableJoinWithDifferentNumberOfPartitions

org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta

unrelated error. Will merge it to trunk

ok to test

add a trivial change to trigger QA again

org.apache.kafka.streams.integration.EosBetaUpgradeIntegrationTest.shouldUpgradeFromEosAlphaToEosBeta

it is traced by https://issues.apache.org/jira/browse/KAFKA-10017


Support for Alfresco 5.1

The addon seems to work for Alfresco 5.1 releases without changes.
I've been testing it in order to support a colleague: https://community.alfresco.com/thread/214763-keep-only-n-versions-of-document
Can be module.properties updated to produce a new release of the addon?

Yes we can do that

On Oct 13, 2016, at 9:34 AM, Angel Borroy<EMAIL_ADDRESS>wrote:
The addon seems to work for Alfresco 5.1 releases without changes.
I've been testing it in order to support a colleague: https://community.alfresco.com/thread/214763-keep-only-n-versions-of-document https://community.alfresco.com/thread/214763-keep-only-n-versions-of-document
Can be module.properties updated to produce a new release of the addon?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/jottley/alfresco-maxversion-policy/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHats96VEdvmXKJxfPsUPuVt6RytNE-ks5qzk-XgaJpZM4KWCT1.

Version 0.0.9 adds support for 5.1


[Feature] support error bar in cartesian chart

What problem does this feature solve?
extends the spec of cartesian charts like scatter plot, bar chart, line chart to support error bar.
reference: https://plotly.com/python/error-bars/
This is an extension of the normal chart in Python chart. Error bars are added to the data points of the bar chart and line chart to indicate errors in various directions. It is very commonly used in the field of statistics.
What does the proposed API look like?
data=[
x: 'some x value',
y: 100,
error:50
]
const spec={
type: 'line',
xField: x,
yField: y,
errorBar:[  //more than one error bar can be added to the chart
{
orient: vertical or horizontal
field: error //field in data representing the error （usually the standard deviation）
}
]
...
}

antv这个没看懂：https://antv-2018.alipay.com/zh-cn/g2/3.x/demo/other/column-error.html


TimeStepper design

Hi @fverdugo
In this file I have some notes about how I think we should implement the TimeStepper object in Gridap. Please take a look, it is just at an initial stage, before starting to implement anything.
If we agree with the basic design, I can start working on this. I would like to have at least Backward Euler and Crank-Nicolson concrete implementations in the near future.

@santiagobadia I have added a draft the ODE machinery here https://github.com/gridap/GridapTimeStepper.jl/blob/fverdugo_comments/design.jl
Please take a look, and we comment it tomorrow.

Create ODEOperator for simpler cases, like AffineODEOperator

@fverdugo I have created the machinery for ODETools in 61cc1552384f3fba3a0232827960bdd47044b421
Can you take a look and make comments?
I have some questions/concerns:

If we do not consider FE machinery, in ODETools, which solvers can we use? From Julia? Suggested package? The ones in Gridap are more for large problems with linear solvers, etc
Minor issue with fill_entries not defined for standard Julia arrays, do we want to put it in Gridap?
Check how I have handled the cache. Here I have the most important concern, cache is something that we want to be reused at all time steps and thus handled by ODESolutions (see iterate methods). However, the one generating the cache is the NonlinearOperator in the ODESolver, which is created at every time step. I think it is prompt to error, since we are assuming that these nonlinear operator will generate the same cache at all times. I believe it is an acceptable think. We will have to think how to deal with adaptive space discretisation, but I think that this work will be done somewhere else. E.g., provide the time stepper with an error estimator, and stop when remeshing is needed. Then, we start generating a new mesh, project, etc. In any case, it is a quite future development.

@fverdugo I have created the machinery for ODETools in 61cc155

Can you take a look and make comments?
I'll take a look.

If we do not consider FE machinery, in ODETools, which solvers can we use? From Julia? Suggested package? The ones in Gridap are more for large problems with linear solvers, etc

What do you mean by "solver" ? I assume that a time integrator, right? I would start by implementing our own specializations of ODESolver e.g., for backward Euler, as you have provably done. Then, we can look if there is some Julia package that returns the computed time steps not in a standard julia array (like DifferentialEquations seems to do by default) but in an iterator. (At this point I am not aware of any package like this, but I haven't do the research...) Then, you can implement an specialization of ODESolution that wraps this iterator, and a specialization of ODESolver that returns this ODESolution specialization.

Minor issue with fill_entries not defined for standard Julia arrays, do we want to put it in Gridap?

Yes, we should add  a default definition like fill_entries!(a,ai) = fill!(a,ai) somewhere in Gridap.Arrays

Check how I have handled the cache. Here I have the most important concern, cache is something that we want to be reused at all time steps and thus handled by ODESolutions (see iterate methods). However, the one generating the cache is the NonlinearOperator in the ODESolver, which is created at every time step. I think it is prompt to error, since we are assuming that these nonlinear operator will generate the same cache at all times. I believe it is an acceptable think. We will have to think how to deal with adaptive space discretisation, but I think that this work will be done somewhere else. E.g., provide the time stepper with an error estimator, and stop when remeshing is needed. Then, we start generating a new mesh, project, etc. In any case, it is a quite future development.

The cache only works if the underlying non-linear operator has the same sparsity pattern in all time steps and you use the same solver also for all time steps. Obviously, this is true in almost any non-adaptive computation, but not for space adaptivity. In the worse case scenario, the ODESolver can have a user-defined trait that signals if this hypothesis is true or not, and then do dispatch using this trait to use the cache or not. In any case, I wouldn't do this right now. I would wait until we really have space adaptivity

Suggested renamings:

GridapTimeStepper -> GridapTimeSteppers (pluralize package name to mach Gridap/julia style)
jacobian_unknown! -> jacobian!
jacobian_unknown_t! -> jacobian_t!

ODESolver

I would not include get_step_size(::ODESolver) in the ODESolver interface since it is not general. Some solvers will compute the dt as a part of the solution process (i.e. predictor/corrector schemes). Some other solvers can consider a user-definer non-uniform time discretization, etc.
I would only call solve  and not solve_step! in test_ode_solver. Perhaps, some solvers would only implement solve and not solve_step!. I am thinking of solve_step! only as a hook used by the default implementation of solve (solve_step! is not intended to be called anywhere else).  Thus, if the a type only implements solve it is ok and we want the test to pass. In addition, it is oK that solve_step! is not exported.

function test_ode_solver(solver::ODESolver,op::ODEOperator,u0,t0,uf,tf)
   solution = solve(solver,op,u0,t0,tf)
   test_ode_solution(solution)
end

Update the comment on the return type here to include the cache # -> uF, tF, cache :
https://github.com/gridap/GridapTimeStepper.jl/blob/61cc1552384f3fba3a0232827960bdd47044b421/src/ODETools/ODESolvers.jl#L8

ODESolution

I would not do any numeric check in test_ode_solution. The numeric tests will be specific for concrete types. test_ode_solution will only check that the interface is implemented and the corresponding methods return the expected types (you will not need any getter):

function test_ode_solution(sol::GenericODESolution)
  for (u_n,t_n) in sol
    @test isa(t_n,Real)
    @test isa(u_n,AbstractVector)
  end
end

BackwardEuler

Do you really need allocate_cache ?
Move default implementation of fill_entries! to Grida.Arrays

Ok to everything but first renaming, I don't think we have plural in GridapXXX packages. Only Tutorials. Do you mean to change everything? Even the github repos? Let us discuss it at the end.
I keep fill_entries! temporarily here, since I am not using the dev Gridap version... I will check how to use in the project.toml the dev version and eliminate it.
With regard to my questions

If we do not consider FE machinery, in ODETools, which solvers can we use? From Julia? Suggested package? The ones in Gridap are more for large problems with linear solvers, etc

I just ment how to use a Newton Raphson method without the need to implement it. A Julia package? I think you were playing with some nonlinear solvers. The ones in Gridap are more for large problems with sparse linear algebra, etc.

Ok to everything but first renaming, I don't think we have plural in GridapXXX packages. Only Tutorials. Do you mean to change everything? Even the github repos? Let us discuss it at the end.

If a module (a package is a module) provides the type TimeStepper, we usually call the module TimeSteppers. That's why I was thinking of GridapTimeSteppers.  I also like the plural since it denotes that the package provides different time steppers, not just one.

I keep fill_entries! temporarily here, since I am not using the dev Gridap version... I will check how to use in the project.toml the dev version and eliminate it.

The general fill_entries! is already in Gridap#master. So, you only need  add Gridap#master in GridapTimeStepper and remove the unwanted fill_entries! definition.
(GridapTimeStepper) pkg> add Gridap#master

Then add, commit, and push the resulting Manifest.toml file. That's all.

I just ment how to use a Newton Raphson method without the need to implement it. A Julia package? I think you were playing with some nonlinear solvers. The ones in Gridap are more for large problems with sparse linear algebra, etc.

The non-linear solver we use in Gridap (see p-Laplacian tutorial) should work also with dense matrices. Have you tried it?

Closed


Display item icon for what's 'Free'

Problem
End-users see which events have FreeStuff - but not what's free!
Solution
Icons for 'Free Food', 'Free Drinks (Non-Alc)' and 'Free Drinks (Alc)' are a good way to easily show which events they might want to go to.
Tasks

[ ] Design 3x icons
[ ] Add icons to card design (as part of the description?)

Context
Other solutions include

giving users the ability to filter

Using ChatGPT + Dall-E, here are some example images:
[ ]

@danagutu - let me know what you think


Apple support

Unfortunately, Apple dev account is paid, so no support from us...

Unfortunately, Apple dev account is paid, so no support from us...


tf.keras.preprocessing.image_dataset_from_directory includes hidden dirs as classes

I am using google colab, and filed this as an issue there but they told me to file it here instead. https://github.com/googlecolab/colabtools/issues/1824
It seems that google colab uses . prefixed hidden directories .ipynb_checkpoints, which image_dataset_from_directory thinks is a class.
Describe the current behavior:
When passing class names it produces the error:
ValueError: The class_names passed did not match the names of the subdirectories of the target directory. Expected: ['.ipynb_checkpoints', 'no_skip', 'skip'], but received: ['no_skip', 'skip']
When not passing class names it picks up 3 classes, not two.
Describe the expected behavior:
tf.keras.preprocessing.image_dataset_from_directory(...) should not include hidden .directories.
The web browser you are using (Chrome, Firefox, Safari, etc.):
Not relevant
Link (not screenshot!) to a minimal, public, self-contained notebook that
reproduces this issue (click the Share button, then Get Shareable Link):
https://colab.research.google.com/drive/1sI2Zk7-YjIOg3nRDyHtUtczwjevQfdPF?usp=sharing

Was able to reproduce the issue with TF v2.3, TF v2.4 and TF-nightly. Please find the gist of it here. Thanks!

Was able to reproduce the issue with TF v2.3, TF v2.4 and TF-nightly. Please find the gist of it here. Thanks!

@jhihn It looks for a directory structure (as shown here) to infer data and labels. I think .ipynb_checkpoints should not be saved in the data directory. Thanks!

I didn't save .ipynb_checkpoints there. The Google Colab did. I don't have control over that. And I think it should NOT include hidden (.) directories anyway. .ipynb_checkpoints would not appear in a normal unix directory listing unless you used the "-a" option.

@jhihn Colab save notebooks under MyDrive/Colab Notebooks. In this gist, we cannot reproduce the issue. If we manually create ipynb_checkpoints under the data where you have training files, then it will throw an error.
I am not sure about inner details about the tf.keras.preprocessing.image_dataset_from_directory and how to implement the same to exclude hidden files without affecting other modules. If you think you can implement it without breaking other modules, then please feel free to contribute through Pull Request. Thanks!

So it's using Python's os.walk() function which according to https://www.tutorialspoint.com/python/os_walk.htm
includes the . files (hidden)
This us undesired and is covered in this stackoverflow:
https://stackoverflow.com/questions/13454164/os-walk-without-hidden-folders

Hi, I'm having the same problem on Jupiter lab. Is there any workaround for this?

@jhihn ,
tf.keras.preprocessing.image_dataset_from_directory is deprecated from Tensorflow 2.9 version.Could you prefer loading data with tf.keras.utils.image_dataset_from_directory, and transform the output tf.data.Dataset with pre-processing layers.
If you still feel this feature needs to be added, feel free to open a new feature request. Thank you!

The problem still exist after renaming to tf.keras.utils.image_dataset_from_directory
$ python train.py
Traceback (most recent call last):
File "/Users/dkh/Downloads/Data-Centric-AI-Competition/internal-competition/train.py", line 25, in
train = tf.keras.utils.image_dataset_from_directory(
File "/Users/dkh/miniforge3/lib/python3.9/site-packages/keras/utils/image_dataset.py", line 192, in image_dataset_from_directory
image_paths, labels, class_names = dataset_utils.index_directory(
File "/Users/dkh/miniforge3/lib/python3.9/site-packages/keras/utils/dataset_utils.py", line 75, in index_directory
raise ValueError(
ValueError: The class_names passed did not match the names of the subdirectories of the target directory. Expected: ['.gitignore', 'cat', 'croissant', 'dog', 'muffin'], but received: ['cat', 'dog', 'muffin', 'croissant']

@jhihn  can you please reopen?

@volkfox,
Could you please feel free please submit a new issue from this link and fill in the template, so that we can track the issue there. Thank you!


[DOC] include a HOWTO add dependency

I try to generate a WAR for CAS  with Ldap.
Apparently, a dependency to « cas-server-support-ldap » has to be declare but i have no idea how to do it with gradle :-(
It would be great to have a documentation associated with your project explaining to people like me (who  know nothing about gradle) how to add there kind of dependencies.
Thanks anyway for your work, I was surprised how simple it was to build a war for the latest version of CAS.

Dependencies are declared here https://github.com/apereo/cas-gradle-overlay-template/blob/master/cas/build.gradle#L18
Follow the same sort of pattern.

Thanks for your answer.
I could generate a war.
Just in case someone wonders in the future, here is how i declared the LDAP dependencies : https://github.com/24eme/cas-gradle-ldap/blob/master/cas/build.gradle#L22

Very good. I am not sure this is worthy to document yet, because it's superfluous to document what Gradle already has documented perfectly. If you are familiar with Gradle, you'd know how to declare modules and dependencies for any given gradle project. So sorry for not being clearer, but that's as far as we'd go to point you to Gradle itself.
If you find other issues with the gradle build, post back. We'll eventually produce one for 5.


Airflow ClickHouse Plugin v1.2.0 is not available on PyPI

A publishing pipeline failed: https://github.com/bryzgaloff/airflow-clickhouse-plugin/actions/runs/7716663176
It requires several adjustments:

Version of installed Airflow should follow the tag, currently it is hardcoded to 1.1.0.
Constraint file should be specified when installing the plugin.
Bonus: add instructions to the README about the constraint file, referencing Airflow docs: https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html#installation-tools

As a quick fix, you may install it from Test PyPI: the package has already been published there. Use python -m pip install --index-url https://test.pypi.org/simple --extra-index-url https://pypi.org/simple airflow-clickhouse-plugin[common.sql]==1.2.0 to install.

Hi @bryzgaloff !
Do you have any plans here? Do you want to release a new version and skip 1.2.0?
Do you need any help with releasing 1.2.0?

+1

Hi everyone, and thank you for waiting for the issue resolution.
There is a problem in the PyPI publishing workflow, and I have not had much time recently to fix this CI pipeline. I am in the process of fixing it. I hope to complete by the end of this week. I have tons of emails and messages, so I am prioritizing this task much higher now.
Here is a quick summary of what has to be fixed:

The pipeline has a hardcoded version 1.1.0. But it has to be a pushed git tag.
The pipeline should fail if a tag does not follow semver format (1.2.0, not v1.2.0). Maybe PyPI performs the check when a package is uploaded and rejects wrong versioning, but I need to check it on a test upload first.
Airflow for PyPI packages tests should be installed with --constraint: otherwise, tests are likely to fail.
Ideally, the PyPI tests should be run with all supported versions combinations, but I have not made my final decision if it is required.
A preliminary local test should be run before uploading to PyPI.

These steps are intended to avoid publishing a broken package version to PyPI (which is an irreversible action: packages cannot be overwritten even in Test PyPI). A special challenge is that the pipeline itself is not runnable if the package version is already uploaded, which makes testing complicated.

Hello everyone! I'm pleased to announce that airflow-clickhouse-plugin==1.2.0 is now available on PyPI: airflow-clickhouse-plugin/1.2.0 🎉
I've applied a quick fix to address the failed workflow steps, ensuring that you don't need to wait any longer for this release. The publishing pipeline has been successfully executed. So, this version has been tested and is fully functional.
I'm closing this issue now as its main objective has been achieved. However, please note that this was a draft version of the pipeline. I'll continue my work in pypi-workflow-fix-#75 branch to implement proper fixes and conduct further testing.
Excitingly, v1.2.0 has been officially published! Happy coding! 😊
Thank you everyone for your patience kindly waiting for the fixes to be applied 🙏


/quest

How do I make 'start-message' appear when viewing active quests? (can be when you hover your mouse over the quest)

Possible duplicate of #754
You can’t. The start message is only shown when you’ve started that quest/stage.
Sent with GitHawk


Missing chunks in data - is it normal?

I downloaded the data with the default csc fetch-data command. The total size of the data folder after downloading is 38.3GB, so matches the description. However, when I open the s2 level of jrc_cos7-1a in Fiji, this is what I see:

Same goes for any other dataset I opened:

Are they supposed to be like that?

Hi, yes, the default data fetcher, download only the raw blocks that are annotated and they have a GT blocks.
You can check the annotated blocks for each dataset here
If you want to fetch more raw you can parametrize --raw-padding
e.g.
csc fetch-data --raw-padding 128
If the padding reach the total size of the raw the script will download the full raw dataseet. (check storage)


[flutterfire_ui] AppleProviderConfiguration has no clientId parameter

Providers section on documentation (https://firebase.flutter.dev/docs/ui/auth/configuring-providers/#apple) cites a clientId parameter for AppleProviderConfiguration but there isn't one on 0.3.0
sample snippet:
RegisterScreen(
  providerConfigs: [
    AppleProviderConfiguration(
      clientId: '...',
    )
  ],
)

but there isn't one on 0.3.0

@maupleke Which version are you referring here ?

/cc @lesnitsky


Add a compile-time option for layer search paths.

This allows me to embed compile-time search paths into my layer binaries to deploy on the Chromium bots for testing, as well as on developer machines. This is much easier for me than using environment varaibles. Was discussing this with jon@lunarg

fixed build issue on Linux and pushed the commits to master branch

Does this need an update to loader/LoaderAndLayerInterface.md as well?

Perhaps a section could be added on compile time config options  for paths. Since the loader built and shipped would have an empty default path  this feature wouldn't normally be available on either Windows or Linux.


Fix bug in the close_region call in Regions2D.plot

This is a small bug fix that remove the wrong reference of self.Regions2D.close_region in Regions2D.plot. self is already the Regions2D object.

The test failures have nothing to do with the one line change I made in this PR.
Looks like there's something different between regionmask 0.10.0 and 0.11.0. The last merge to main was run with regionmask=0.10.0, and this failure is with regionmask=0.11.0. And, regionmask=0.11.0 as just released 2 days ago!


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/71151

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/71597

Tagbot fix

TagBot fix

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/72009


Including required steps to enable VPN feature

Including additional steps to enable VPN feature under the Anypoint Platform account.

@mcocaro - please verify. Thanks.

@sjsheridan confirms that these steps are unnecessary for normal flow. Only relevant if creating a VPC and VPN in a business group, which this doesn't apply to.


Cluster autoscaler missing critical pod annotation

According to https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment we should mark the cluster autoscaler with the scheduler.alpha.kubernetes.io/critical-pod annotation. While we may by default deploy to controllers only I think it's probably better to have the annotation to mirror the other Deployments we have?

@c-knowles Good catch 👍 I completely agree to your suggestion.
FYI, what make the annotation even more needed is that we can optionally use worker nodes to run cluster-autoscaler by specifying worker.nodePools[].clusterAutoscalerSupport.enabled.


New Pidgin Ipsum Checklist

[ ] I've added Contributed by: [@yourusername](https://github.com/yourusername)
[ ] I've added to the README.md file
[ ] My Story Title starts with ## Pidsum

Please ensure these requirements are met before submitting your pull request.

e go better oo


OBO challenge 2023: go green in CL OBO dashboard

Placeholder ticket inspired by @matentzn 's talk at ICBO 2021. CL does quite well in the OBO dashboard, but we could address those missing definitions between now and 2023 :-)
(BTW @matentzn @dosumis the CL report says 397 missing defs, but the yellow table only shows 200, and I can't see a link to go to a second page? If I download the TSV, it's also limited to 200 entries. I see the same issue in a couple of other ontologies' reports that I checked. Let me know if I should file a bug ticket in the OBO tracker instead.)

I love it thanks so much @paolaroncaglia

I'll self-assign for shepherding purposes. Quick thoughts:

[ ] CL terms that lack definitions may be grouped by broader classes (e.g. neuron types), to facilitate working on related terms in bulk if desider, possibly by editors working on related project;
[ ] Some of this work may be a good first task for novel CL editors, @dosumis if you think it'd be appropriate for the future Cell Annotation Platform (CAP) developer.

Note to self: the OBO report (cl-edit.owl-obo-report.tsv) lives here and is updated at each release. Still 372 warnings for CL missing definitions.

Following up on the 372 CL terms that lack a textual definition:
I looked at the first 5 CL terms (sorted by ascending ID as per cl-edit.owl-obo-report.tsv). 3/5 have an equivalence axiom, e.g.
'neuronal receptor cell' Equivalent To
'sensory receptor cell'
and neuron
and ('capable of' some 'detection of stimulus involved in sensory perception')
Would it be possible to do an automated pass at generating textual defs based on equivalence logical defs? The results should be quite reliable (if perhaps in need of a quick manual revision to check for weird wording). I'll add this to the tech board.

for definitions: if we implement patterns for #450 - a good portion of defs can be autogenerated using DOSDP
for RO terms: @shawn to check terms in http://dashboard.obofoundry.org/dashboard/cl/fp7.html and see how they are used. They should either be in RO or removed. @shawntanzk to make a proposal and bring it up again in a call or ticket

Checking in on this stale ticket...
@shawntanzk and @paolaroncaglia / @paola-scibite, can this ticket be closed?
If not, can the open action items be clearly listed?

I'm happy for it to be closed - did what I can already. @matentzn pinging you just in case you want this kept open

@bvarner-ebi @shawntanzk @@matentzn
Thanks for following up. Atm the dashboard report says 369 missing CL definitions. I can't contribute, and I don't know what the status of available resources is at CL, so I'll be happy with whatever decision you take. Thanks!

Just to add some context:
The dashboard has no reds and the only things up are 4 non-RO properties and a whole bunch of missing text defs
http://dashboard.obofoundry.org/dashboard/index.html
the non-RO properties will likely not be solved - I think there is arguments for keeping some non-RO properties, and some are expansions etc. which are highly specific and will unlikely be accepted by RO.
Missing defs wise, I'm guessing this are auto migrated stuff, and unless we have a way of programmatically pulling in the defs (maybe from xrefs or smth), I think its quite hard for someone to curated 369 defs.
It is why I personally think we have gotten as far as we can with this ticket and it can be closed :)
Hope that helps.

Thanks very much for the context, @shawntanzk.
@matentzn, given the comments above, is it reasonable to close this issue?

I agree, awesome work everyone, this can be closed! 🎉


CSRF?

What's the take on CRSF, being that it ember-simple-auth uses token authentication and there's no persistent session created by Rails?
Thanks!

Well, I guess it doesn't make much sense, since each time the user logs in, a new token is generated and assigned to the clientside session, somewhat like what you'd do with CSRF (either get from the DOM or get form an API endpoint). So, i'd say CSRF only makes sense when using a session in the backend, like Devise with cookies, for example.

Correct, auth tokens basically have the same characteristics as the CSRF token mechanism that e.g. Rails uses.


Subvariables

Dear developer,
is there a possibility to store the results such, that the variable is stored in its components?
E.g. Displacements and sublist x,y,z (callable in Paraview via the components)?

@CWillberg just call your variables displ_x, displ_y, displ_z. Paraview will load this up as a vector and calculate things like vector magnitude for you.

thanks


add a timeout to package tests

If a test doesn't complete in 3 minutes, terminate the conatiner and mark it as
failed. Update the report script to show timed-out tests and also to show the
date on test when showing more than one row for that test.

Test in my fork passed: https://github.com/AWSjswinney/arm64-python-wheel-tester/runs/3655816795?check_suite_focus=true


evp/e_aes_cbc_hmac_sha256.c: give SHAEXT right priority.

Commits other than e_aes_cbc_hmac_sha256.c are commentary updates only. ghash-x86_64.pl commit is not really related, but I figured why not. it's minor commentary update.
This targets all branches to 1.0.2. But if commits other than e_aes_cbc_hmac_sha256.c don't cherry-pick, they'll be omitted. If e_aes_cbc_hmac_sha256.c doesn't cherry-pick, there will be separate request.

((OPENSSL_ia32cap_P [ 1 ] и ( 1 << ( 60 - 32 ))) && / * ? AVX * /
--
  |   | + ((OPENSSL_ia32cap_P [ 1 ] и ( 1 << ( 43 - 32 )))    / * ? XOP * /
  |   | + | (OPENSSL_ia32cap_P [ 2 ] и ( 1 << 29 ))           / * SHAEXT? * /
  |   | + | (OPENSSL_ia32cap_P [ 0 ] и ( 1 << 30 ))))) &&     / * "Intel CPU"? * /


Failing test

it look related to the java_integration, need more investigation.
Using Accessor#strict_set for specs
Run options: exclude {:redis=>true, :socket=>true, :performance=>true, :elasticsearch=>true, :broken=>true, :export_cypher=>true}
FF.F

Failures:

  1) LogStash::Filters::Json parse message into the event "{ "hello": "world", "list": [ 1, 2, 3 ], "hash": { ..." when processed
     Failure/Error: Unable to find matching line from backtrace
     Insist::Failure:
       Expected [1, 2, 3], but got #<Java::JavaUtil::ArrayList:0x41685d91>
     # ./lib/logstash/runner.rb:58:in `run'
     # ./lib/logstash/runner.rb:113:in `run'
     # ./lib/logstash/runner.rb:171:in `run'

  2) LogStash::Filters::Json parse message into a target field "{ "hello": "world", "list": [ 1, 2, 3 ], "hash": { ..." when processed
     Failure/Error: Unable to find matching line from backtrace
     Insist::Failure:
       Expected [1, 2, 3], but got #<Java::JavaUtil::ArrayList:0x4fbfe01c>
     # ./lib/logstash/runner.rb:58:in `run'
     # ./lib/logstash/runner.rb:113:in `run'
     # ./lib/logstash/runner.rb:171:in `run'

  3) LogStash::Filters::Json fixing @timestamp (#pull 733) "{ "@timestamp": "2013-10-19T00:14:32.996Z" }" when processed
     Failure/Error: Unable to find matching line from backtrace
     Insist::Failure:
       LogStash::Timestamp is not a Time
     # ./lib/logstash/runner.rb:58:in `run'
     # ./lib/logstash/runner.rb:113:in `run'
     # ./lib/logstash/runner.rb:171:in `run'

Finished in 0.308 seconds
4 examples, 3 failures

this is what I am seeing now. was this an old version that you saw that error in?
~/Code/es/talevy-logstash-filter-json (master)$ bundle exec rspec
Using Accessor#strict_set for specs
Run options: exclude {:redis=>true, :socket=>true, :performance=>true, :couchdb=>true, :elasticsearch=>true, :elasticsearch_secure=>true, :broken=>true, :export_cypher=>true, :integration=>true}
.....

Finished in 0.201 seconds
5 examples, 0 failures

Randomized with seed 48924

possible it's from November 5 and I think @colin work on that part. :)


Remove tdewolff

https://www.npmjs.com/package/@tdewolff/minify it's like a toy project, with 62 Weekly downloads.

(Disclaimer: I'm not a tdewolff/minify contributor nor maintainer)
I respectfully disagree for the following reasons:

it has merits, including the fastest minification time across (practically) all tests, with uncontested speed
since it's made in Golang, it also provide CLI binaries, making npm just one medium of distribution
if it was a toy project, wow... the "production grade" ones have a lot to improve to be less distant to its speed
even without a meritocratic POV, tdewolff/minify has 3k+ stars on Github, is actively maintained and more than 30+ contributors

Thanks @paulocoghi.
I will not be removing tdewolff/minify. It's a serious project with one of the best performances.
Unfortunately, their npm distribution currently has a bug that's preventing further adoption.

I thought it was a toy project because:

https://github.com/tdewolff/minify/runs/8104468113?check_suite_focus=true the latest CI shows it didn't run with many platforms because of segmentation fault and core dumped.
https://github.com/tdewolff/minify/blob/master/js/stmtlist.go#L72-L88 there are bunches of codes like this


chore(main): release 2.20.0-pre

:robot: I have created a release beep boop
2.20.0-pre (2024-09-05)
Features

Feat 171 create snackbar service (#178) (fb5f617)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/ai4os/ai4-dashboard/releases/tag/v2.20.0-pre :sunflower:


Add working public private key pair

Thanks Mischa!
And sorry for getting your branch name wrong 😞

Don't worry about it


MIT license sometimes recognized, sometimes not

First of all I'm sorry if this is the wrong place to report this, but as I now this gem is powering GitHub's license information, I thought the most knowledgeable people will read this here.
These data-lens and jsfiddle project have the same LICENSE file, which is MIT. Yet the GitHub web UI only displays the license information for the latter. Any idea why that is?
Running licensee locally on these LICENSE file yields
$ bin/licensee ~/Downloads/LICENSE-jsfiddle.txt
License file: LICENSE-jsfiddle.txt
License hash:<PHONE_NUMBER>3f8c5e8ad5e6cbc02fe2a34e59d1ef
Attribution: Copyright (c) 2016 HERE Europe B.V.

Here's the closest licenses:
* Unlicense similarity: 58.49%

Given this, I would assume that also for the jsfiddle project the license should not be recognized. I can fix the recognition by removing the first (long) line from the LICENSE file, which is custom text that does not actually belong to the license. Yet my question is why in the web UI for jsfiddle the license info displays correctly.

@sschuberth this is the expected behavior. The inconsistency is due to the fact that jsfiddle's license was detected with a prior, less strict version. I queued a redetection job, and it is not properly NOT detecting the MIT license for both.
The issue is this line:

Unless otherwise noted in a LICENSE file for specific files or directories, the files in this repository are under the following license.

While Humans understand what that line says, unfortunately, robots do not. That line could say "This project isn't licensed, but here's a copy of the MIT license, because I think it looks cool:". As such, Licensee doesn't know if the line is legally significant, and properly says it's not the MIT license.

The inconsistency is due to the fact that jsfiddle's license was detected with a prior, less strict version. I queued a redetection job, and it is not properly NOT detecting the MIT license for both.

I was assuming something like that. Then my obvious next question is: What makes GitHub re-run the detection job? Changes to the repository? Changes to licensee? If so, when? Once a day?

What makes GitHub re-run the detection job?

I'd like to know this too (see https://github.com/benbalter/licensee/issues/139#issuecomment-252737035)

What makes GitHub re-run the detection job?

It should run near-instantly following a push that touches any matching LICENSE file (but is then cached until the next subsequent push, where it is re-run with the latest version of Licensee).

Thanks for the details. One more question, even if I'm going slightly off-topic: Does GitHub support the case where there are different LICENSE files per (orphan) branch? I.e. if I switch branches in the web UI, is the detected license information supposed to update accordingly?

if I switch branches in the web UI, is the detected license information supposed to update accordingly?

That's not currently supported. There is a one-one relationship between repositories and licenses.

It should run near-instantly following a push that touches any matching LICENSE file

Sorry, yet one more thing: So does that mean no re-run is queued if only licensee is updated? Is that the reason why the jsfiddle license was not updated, as the LICENSE file was not changed, but only licensee was made more strict?

So does that mean no re-run is queued if only licensee is updated? Is that the reason why the jsfiddle license was not updated, as the LICENSE file was not changed, but only licensee was made more strict?

Correct. With nearly 40M projects, it's not feasible to redetect every project's license every time Licensee is updated. If you notice a project that you think may need a bump, feel free to email support and we can redetect the license.


vite: error when initializing ENSInstance (imported.GraphQLClient is not a constructor)

in a vite application loading ensjs I get the following error when initializing a new ENSInstance:
TypeError: imported.GraphQLClient is not a constructor
    at GqlManager.setUrl (GqlManager.mjs:68:21)
    at async ENS.setProvider (index.mjs:127:5)

I'm running the following package versions:
"@ensdomains/ensjs": "^3.0.0-alpha.39"
"vite": "^3.1.8"

here's a minimal reproduction. Just run the app with yarn dev and then check the console.log

After doing a little digging I found a fix for this. I put the fix here: https://github.com/appleseed-iii/vite-ensjs-v3/pull/1/files
The root problem is that vite doesn't easily bundle CJS packages that are imported via ESM packages. In this case graphql-request (CJS) is imported via the ESM ens package.
Documentation from vite for the fix

Closing this since it's not ensjs related


Authentication Failed - You do not have permissions to access the service

I just tried the demo and I get this error:
Error Domain=LastFmServiceErrorDomain Code=4 "Authentication Failed - You do not have permissions to access the service" UserInfo={NSLocalizedDescription=Authentication Failed - You do not have permissions to access the service, method=auth.getMobileSession}
What am I doing wrong?

The API key used in the example app is probably no longer valid. Try to run it with your own key.

I used my own keys. But I keep getting the same error.

I see you removed your comment and closed the ticket. Can you explain the problem/fix for future people with the same problem? Thanks!

It was a problem from my side. There was a mistake in API secret key given to me. Your code works perfectly! Thanks.


[RFC] Blinking a TextInput cursor using periodic animation

Introduction
As discussed in #89, users expect a blinking cursor to signify the current insert position, of a focused text input.
However, implementing this is more complicated than simply updating the TextInput widget, because currently iced widgets can only update in response to user events, or application messages (via the Subscription system).
This document aims to walk through this problem space and propose a minimal solution to enable a blinking TextInput.
Guide-level explanation
Background on current architecture
TextInput widget
Currently, the cursor is always shown (ie: it does not blink) for a focused text input. No cursor is shown for a TextInput which does not have focus.
All changes to the text-input's appearance are driven by user-interaction events.
The runtime
Underlying iced widgets is an Event Loop, whose role is to bring together all the layers of iced. Think of this as the 'dispatch' or traffic light of an iced GUI - it controls the flow. The 'runtime' is composed of a number of separate components (Application, user_interface etc), but these details can be omitted for the sake of this explanation.
The runtime's job is to perform initial setup and then perform the following operations in sequence:

Receive application events and user-interaction (mouse movement, clicks, keyboard etc)
Deliver these events to the widgets, so they can update their internal state to reflect the happenings of the application or the user
Layout the widgets. As the relative size and position of widgets may have changed in response to an event, layout resolves the current position and size of every widget.
Draw the widgets. Drawing involves updating the screen with what the widgets want to show.
Wait. In the current implementation, the runtime waits for a user-interaction or application event before doing it all again.

The widgets
Widgets communicate integrate with the rest of iced (the 'runtime') by implementing the Widget trait. This trait defines:

A way to communicate the size needs of the rendered widget (width(), height()), and resolve its position (layout())
A way to provide a display list (a list of drawing commands) to the visual backend (draw())
A way to update the internal state of the widget based on user interaction or application defined events (on_event())

Notably absent from this trait is any means to indicate to the underlying runtime that an update needs to occur at some time in the future: This current design assumes all updates are the result of user interaction or application events.
Whats missing
Hopefully the background section explains enough that these points are clear:

The iced event loop ('runtime') only updates/re-draws its widgets in response to a user or application event. It has no mechanism to redraw itself on its own whim.
iced Widgets cannot communicate to the runtime that an update/re-draw needs to happen at some point in the future - no such interface exists.
Even if the above was not an issue, the TextInput only updates in response to user interaction, and has no concept of time, let alone a sense of 'blink me 500ms after the last interaction'.

Generalizing the problem
Even though this RFC is written to support a blinking text-input, the more general case of a widget wanting to animate itself is a common use-case. We can generalize this problem to that of periodic animation - providing the ability for widgets to update their appearance based on the passage of time. More details on different animation use-cases, and ideas around implementing this can be found in #31 / https://github.com/hecrj/iced/issues/31#issuecomment-703176958.
Addressing whats missing
1: The event loop
The event loop needs to be able perform an update cycle (ie: handle events if any, update layout if needed, and redraw) when a widget needs it. In the case of a blinking text input cursor, this would be every 500ms, to show/hide the input cursor.
For periodic updates such as these, the behavior of the Wait state needs to be changed. Instead of waiting till the next application event or user interaction, it needs to wait till either the next time a widget needs to be updated, or on the next UI/application event, whichever is first.
2: The widget interface
Widgets need to be able to communicate their need for a update/draw cycle at some time in the future to the event loop, as ultimately the event loop is responsible for updating that cycle.
This necessitates a change to the interface between widgets and the runtime: the Widget trait.
The exact change to enable this communication is a matter of API design. However, any change which communicates the soonest moment a widget would need to update would work.
3: The TextInput widget
The logic of the widget would need to be updated to:

Track the time of the user interaction which affected the cursor position.
Indicate to the runtime that an update is needed in 500ms increments after the last user interaction
Conditionally emit display list commands to blink the cursor: omitting cursor primitives during the 'hide' phase of the animation (1/2 second), and including cursor primitives during the 'show' phase of the animation (other 1/2 second).

Reference-level explanation
TL;DR

The problem of a blinking cursor input can be generalized to periodic animation support.
The iced runtime only performs an update/draw cycle in response to application events and user interaction, but to support periodic animation, we need the runtime to perform a cycle whenever a widget needs it.
The current interface (the Widget trait) between the runtime and widgets has no means to indicate that a widget is animating, and hence requires a re-draw at sometime in the future.

The numbering of these points aligns to that of the guided explanation in the previous section.
1: Event loop changes
The event loop needs to be changed to track the soonest moment which an update needs to occur, and to perform an update/draw cycle at this moment.
The intermediate state of a user interface (at the transition of a update/draw cycle) is stored in the State struct, from native/src/program/state.rs. A new field, next_animation_draw: AnimationState can be added to track the next draw required by widgets. More on the AnimationState type later, but just know that this type encapsulates the animation requirements of widgets, and this value can be obtained by calling a method on the root widget.
Modifying the behavior of the wait state is surprisingly trivial, thanks to the underlying use of winit. Instead of setting the event loops' control_flow to Wait, we just set it to WaitUntil( <time of soonest update> ). This changes the behavior to wait until the next event, or the provided time (whichever is sooner).
2: Widget trait changes
An update is needed to the Widget trait to communicate the animation requirements of a widget - in our case, that the TextInput widget needs to be re-drawn in 500ms.
We propose adding a new method to the trait, with a default implementation that just indicate no animation is taking place:
  fn next_animation(&self) -> AnimationState {
    AnimationState::NotAnimating
  }

Widgets that need to animate (such as our TextInput) can implement this method to indicate an animation is required:
  fn next_animation(&self) -> AnimationState {
    AnimationState::AnimateIn(std::time::Instant::now().checked_add(Duration::from_millis(500)))
  }

Remaining consistent with the stateless and intuitive feel of the widget trait, next_animation is called as part of the update loop, to get the latest set of animation requirements.
3: TextInput changes
The widget needs to keep track of the last time a user interacted with the input. We can do this by adding a new field to an internal state type Cursor:
pub struct Cursor {
    state: State,
    updated_at: Instant, // new field
}

And setting its value when the cursor state is updated:
pub(crate) fn move_to(&mut self, position: usize) {
    self.updated_at = Instant::now(); // add this line
    self.state = State::Index(position);
}

As a corner case, we also need to detect when the input is clicked and gains focus, which we can do by setting updated_at during on_event when we detect that condition.
The AnimationState type
Widgets need to symbolize their animation requirements to the runtime. We propose creating a new enum type to represent this:
pub enum AnimationState {
    NotAnimating, // The widget does not need to animate itself, and will only change in response to events.
    AnimateIn(std::time::Instant), // The widget needs to animate itself no sooner than the provided moment.
}

A new type seems ideal for the following reasons:

It can be easily extended to support future animation use-cases (for instance, continuous/every-frame animations)
The runtime only needs to keep track of the soonest it needs to update/draw the widgets. As such, AnimationState can implement std::cmp::Ord to provide the soonest animation time through min(). This will greatly simplify implementation because widgets which contain widgets need only return the min() of their contained widgets AnimationState values, in response to a next_animation call.
Existing types arent self describing: In theory, we could get away with an Option<std::time::Instant>, but the intent is less obvious then an aptly-named enum.

Drawbacks

An additional method on the widget trait (next_animation()) increases the runtime complexity of the update loop. Further, even though the method has a default implementation, its one more thing to think about when implementing a widget.
Due to the lack of incremental drawing/update in iced, all widgets will be updated & drawn whenever an animation is needed.

Alternatives

Implement a persistent widget tree, and track animation requirements as a persistent property of each widget (#553)

Advantages: Could avoid updating/drawing all widgets for an animation cycle, such a widget tree is necessary for other features like accessibility integration
Disadvantages: Massively complex, sudden and big change from existing architecture, proposal not yet fully fleshed out or understood

Use on_event and messages to signal to the runtime that a redraw is needed

Advantages: Seems somewhat straightforward
Disadvantages: Message is an associated type, so it will either need to be wrapped somehow or converted into a Tuple. Also, the message-based approach seems harder to reason about than a method that signals current animation requirements.

Plumb some indication of animation requirements into a parameter passed to draw()

Advantages: Straightforward, despite being tedious
Disadvantages: Pollutes the responsibilities of draw() and makes it no longer free of side-effects

Future possibilities

Motion (frame-by-frame) animations can be added by extending AnimationState and associated handling in the event loop.

Please let me know what you think. Thanks! =D

Very nice! I have one question. Will this supposed solution make it harder to do incremental drawing, or is it something that can be added later? Some of the widgets I'm creating can get pretty complex, and I imagine text is really expensive too. We can create a separate RFC for this too if you want.

Incremental rendering / persistent widget tree is such a huge change that everything is likely to change anyway, but I think this is a step in the right direction.
Definitely want to develop incremental rendering in a separate RFC.
I have lots of ideas :joy: but I'll keep them out of this RFC.

I implemented this offline to see if there were any gotchas I missed. The only thing ive had to add to this RFC is the addition of a new synthetic event, AnimationTick, which is emitted when an animation fires.
Emitting a new event like this is the easiest way to drive the update cycle, and keeps the simple adage (widgets are only updated in response to messages + events) true. The alternative (making another entry point into the update cycle) seems suboptimal, as it increases complexity.

If you would like to test the prototype and give feedback, update your Cargo.toml with:
iced = { git = "https://github.com/twitchyliquid64/iced", branch = "text_input" }
iced_native = { git = "https://github.com/twitchyliquid64/iced", branch = "text_input" }
# etc

You can see documentation for the updated trait here: https://iced-animations-rfc.tomdnetto.net/iced_native/widget/trait.Widget.html