Breaks the code while adding improvements

Describe the bug
The agent adds the following comments to the code:
{/* Previous imports remain the same */}

{/* ... rest of the code until the destroy confirmation dialog ... */}

But this is of course, not a working piece of code. So the page breaks completely.
Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-6xmany
Steps to reproduce

Prompt to create a UI
Continue with asking for improvements on the page

Expected behavior
It should just add the asked improvements
Screen Recording / Screenshot

Platform
Browser name = Firefox
Full version = 129.0
Major version = 129
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
performance.memory = undefined
Username = ozzdev
Chat ID = e8d8e6977c1a

Additional context
No response

This happened way too many times; my question is, what happens to the wasted tokens? This seems rather a fault on the Bolt.new


Windows workflow keeps failing

The FPGA implementation part of the Windows workflow keeps failing (cut-out from https://github.com/stnolting/neorv32/runs/3562298603?check_suite_focus=true#step:5:27).
yosys -m ghdl.so \
  -p \
  "ghdl --std=08 --no-formal neorv32_UPduino_BoardTop_MinimalBoot; \
  synth_ice40 \
  -top neorv32_UPduino_BoardTop_MinimalBoot -dsp \
  -json neorv32_UPduino_v3_MinimalBoot.json"  2>&1 | tee yosys-report.txt
ERROR:
  This version of Yosys cannot load plugins at runtime.
  Some plugins may have been included at build time.
  Use option `-H' to see the available built-in and plugin commands.

Is this a package problem?!
@umarcor could you have a look? :upside_down_face:

I was just pulling to start rebasing and bringing myself up to date :wink:
As you saw, I've been quite busy in august, but I think I can allocate some hours this weekend to revisit the pending issues/workflows/etc.

As you saw, I've been quite busy in august

Take your time! There is really no need to hurry. This issue is not super urgent+critical.

but I think I can allocate some hours this weekend to revisit the pending issues/workflows/etc.

Thank you so much! 😊 :+1:

This is the reason: https://github.com/stnolting/neorv32/blame/79058c17e1c1b10d1573c8712d754bd22300f0f6/setups/osflow/boards/index.mk#L1
GHDL_PLUGIN_MODULE needs to be set when the toolchain has ghdl-yosys-plugin built as a module. In case the plugin is built into yosys, that must not be set. When adding support to Alhambra and ULX3S, that envvar was unconditionally set.
More precisely, on MSYS2, the plugin is built into yosys, because yosys does not support loading modules dynamically on Windows. Hence, I assume that @zipotron is either a GNU/Linux user, or he was using containers.

Ah I see. I was not thinking about that at all... 🙈
Thank you so much for the quick response!

My pleasure 😃


Add DaMichel's SphericalTanks (DST) from SpaceDock

This pull request was automatically generated by SpaceDock on behalf of zer0Kerbal, to add DaMichel's SphericalTanks (DST) to CKAN.
Please direct questions about this pull request to zer0Kerbal.
Mod details:
name = /mod/2342/DaMichel%27s%20SphericalTanks%20%28DST%29
author = zer0Kerbal
abstract = Parts mod with five SphericalTanks with 1.25 m base from 0.625 to 10 t. (612.5L - 10,000L)
license = CC BY-NC-SA 3.0
Homepage = https://forum.kerbalspaceprogram.com/index.php?/topic/191719-*
description =

DaMichel's SphericalTanks
A continuation of DaMichel's SphericalTanks (DM-Tanks))
originally named DM-Tanks

Parts mod with five SphericalTanks with 1.25 m base from 0.625 to 10 t. (612.5L - 10,000L)

Author
Adopted for curation by zer0Kerbal. Originally created by DaMichel.
SphericalTanks: 1.25 m diameter. Come with B9partswitch fuel patches(player supplied TAC-LS, Kerbalism, SNACKS!, and Karbonite) along with other user supplied patches.  currently only available in veteran orange.
Contains five 1.25m spherical tanks:

Mark 1 Spherical Fuel Tank - 612.5L (0.55m radius)
Mark 1 Spherical Fuel Tank - 1250L (0.70m radius)
Mark 1 Spherical Fuel Tank - 2500L (0.88m radius)
Mark 1 Spherical Fuel Tank - 5000L (1.11m radius)
Mark 1 Spherical Fuel Tank - 10,000L (1.40m radius)

Screenshots

View full album

Installation Directions

Use CKAN

Changelog Summary
See ChangeLog for full details of mod changes

Requires

Kerbal Space Program v1.9.0, may work on earlier versions

Depends

none

Recomends

DaMichel's AeroRadial
DaMichel's CargoBays
DaMichel's Fuselage
Module Manager

Suggests

SimpleLife
MoarKerbals
SimpleConstruction)
Not So SimpleConstruction (NSSC)
SimpleLogistics
[Biomatic
KGEx (coming soon)
B9StockPatches
Hot Beverages Irradiated
On Demand Fuel Cells (Refueled)

Supports

TweakScale
Kerbal Change Log
[B9partswitch]
SNACKS! beta
ModularFuelTanksbeta
TAC-LSbeta
FuelSwitchbeta or IFSbeta
RealFuelsbeta

Tags

mod,DaMichel,zer0Kerbal,parts,fuel,sphere,tank

Replaces

DaMichel's SphericalTanks

Conflicts

DaMichel's SphericalTanks

License
Source: GitHub
License: CC BY-NC-SA 3.0 CC BY-NC-SA 3.0

Attribution-NonCommercial-ShareAlike (CC BY-NC-SA)

All bundled mods are distributed under their own licenses
All art assets (textures, models, animations) are distributed under their own licenses

Permission granted by original author:

Source: https://forum.kerbalspaceprogram.com/index.php?/topic/55842-**)
License: Content originally created by DaMichel
Licensed under CC-BY-SA-3.0 (Attribution, Share Alike)
Original: Thread:
Source/License: Source and license are included in the zip.)
v<IP_ADDRESS> original: 11 Aug 2018 zed'K | updated: 17 Feb 2020 zed'K
https://creativecommons.org/licenses/by-sa/3.0/

Will merge into #7714 since this cluster of mods has lots of interrelationships.


As a team, we can finish the sprint by clicking the cog icon next to the sprint name above the "To Do" column then selecting "Complete Sprint" >> Try closing this sprint now

➤ Nick Skinner commented:
Created 28 days 5 hours 14 minutes ago Joined Sample Sprint 1 21 days 10 hours 20 minutes ago

➤ Nick Skinner commented:
To Do to In Progress 7 days 4 hours 26 minutes ago In Progress to Done 6 days 2 hours 38 minutes ago

➤ Nick Skinner commented:
Joined Sample Sprint 2 7 days 9 hours 10 minutes ago


Can't manage to rename class names

Hi,
I'm just starting playing with grunt, it looks awesome. I installed seamlessly on my ubuntu box and it runs fine, but I have no success renaming class names. I plan to use filenames such as "joe_barr.svg" and "john_doe.svg", and I'd like to call them just with "icon icon_joe" and "icon icon_john", leaving the part behind "_".
So I tried this:
        options: {
          autoHint: false,
          rename: function(name) {
             var origName = path.basename(name);
             // return (origName); that's fine
             var newName = origName.split('_', 1);
             return (newName.toString()); // displays garbage
             var moreName = [origName, 'bar'].join('-');
             // return (moreName);  // displays garbage, too
           }
        }

but I just get garbage in icon.html, and I can't read the generated ttf file either.
I'm probably missing something...
Thanks for your code and your help !

I've attempted to replicate your issue using the configuration below, but I've had no success.
grunt.initConfig({
	webfont: {
		icons: {
			src: 'src/*.svg',
			dest: 'build',
			options: {
				rename: function(name) {
					var origName = path.basename(name);
					var newName = origName.split('_', 1).toString();
					return newName;
				}
			}
		}
	}
});

Everything operates as intended. Is there anything in particular I've missed regarding the issues with your implementation?

Thanks for helping ! I'm a total newbie on the node / grunt things - although I manage around 30 linux servers...
I tried again with your code, but still no luck. The names, css, html files are generated correctly - but all the font files seem broken. If I generate for 3 svg files with option: font="ifaceok" and origName, then "ifaceko" and newName,  I get a ifaceok.ttf with 2100 bytes, but ifaceko.ttf is just 1368 bytes and displays garbage. I attach them if it can help.
iface ok and ko.zip
I'm running ubuntu 14.04, npm 1.3.10, grunt-cli v0.1.13, grunt v0.4.5, grunt-webfont 1.0.2., fontforge  20120731 20150824 (updated without better results)
May I ask you to paste your whole Gruntfile.js ? Here I (felt that I) have to add those lines before your code:
var path = require('path');
module.exports = function(grunt) {

and after:
// Load the plugins that do the task.
grunt.loadNpmTasks('grunt-webfont');

// Default task(s).
grunt.registerTask('default', ['webfont']);
};

... but of course I might as well be completely wrong. To be frank I don't feel very easy with Grunt doc, it's not really easy for beginners.
I'll be glad to provide with any more details which might help.

@fredt34 If you're having trouble with the font-gen engine itself (rather than with font-renaming, as your earlier post made it seem), it's possible that one of your one of your SVG's isn't playing nicely as @sapegin mentions in the README.
That said, if your concerns are more on the Grunt set-up side of things, this may not be the best place to address your question, as discussion here should be limited to items that are specific to grunt-webfont itself. I'm happy to help out if you move it over to a StackOverflow thread or something of the like - just let me know.

So it was a problem with rename...
I spent hours trying, until I started to run with "grunt -dv" to go verbose, and add debug statements in /node_modules/grunt-webfont/tasks/webfont.js and node_modules/grunt-webfont/tasks/engines/fontforge.js, to discover that after being renamed, files were copied to a /temp/something directory - and they just had a name, but no extension.
So I finally came with
          rename: function(name) {
				var origName = path.basename(name);
				var newName = origName.split('_', 1).toString() + path.extname(name);
				return newName;
			},

where " + path.extname(name)"  adds ".svg" back to filenames, after what fontforge is happy again and generates the font properly. The problem doesn't occur with "node" engine.
I'd suggest adding this tip about extension to the readme.md; I also notice that the "Normalize" option is missing in that doc.
...hope this helps other users to avoid this trap...

I don’t understand what you’re trying to do. Extensions aren’t necessary in the rename function as in the example in the readme and here. Extensions will be removed later anyway.

Thanks for your help. I guess I'm just trying to get fonts generated ok...
I've just removed the "add extension" part again, and "grunt -v" displays this warning - although there's no fatal error:
fontforge: Warning: Font contained no glyphs
fontforge: Warning: Font contained no glyphs
fontforge: Number out of range: 2.14748e+09 in type2 output (must be [-65536,65535])

The font is generated (I enclosed a font in my previous answer), but displays weird characters:

Perhaps fontforge benefits of more "magic" on Mac than on my Ubuntu ? Anyway, adding extension does solve the problem here.


HHH-9638 - Testcase

https://hibernate.atlassian.net/browse/HHH-9638

When integrated, the issue can be closed because this testcase shows what the user requests works properly.

Applied upstream, thanks


[GLUTEN-3237] Fix a bug about replacing spark sort agg with gluten hash agg

What changes were proposed in this pull request?
Fix a bug about replacing spark sort agg with gluten hash agg

When the Final SortAggregate fallback, the Partial SortAggregate should also fallback to ensure data accuracy

How was this patch tested?
Add a unittest.
Before the PR:

After this PR:

Nice catch, and how about set TRANSFORM_UNSUPPORTED tag to logical agg node when we meet found a fallback node, then check that logical agg node before validate partial agg node?  I think this way is more make sense.

Thanks for your fix!
What if partial/final sort agg are separated by shuffle into different stages? It may need more considerations. Right?

thank you @weixiuli , do you mean, the velox does not support some aggregate functions with final mode but support partial mode ? Does ObjectHashAggregate has same issue ?

Run Gluten Clickhouse CI

Hi @weixiuli, as mentioned in https://github.com/oap-project/gluten/issues/3391, one proposed solution is, moving unsupported post project to an independent project operator. Thus, we can make final agg transformed and just make post project fall back.


error: module Alamofire was not compiled for testing (similar issue to #652)

If you carthage update on the latest version of the 3.3 branch you will get error included:
*** Building scheme "Alamofire iOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire OSX" in Alamofire.xcworkspace
** BUILD FAILED **
The following build commands failed:
CompileSwift normal x86_64 /Carthage/Checkouts/Alamofire/Tests/MultipartFormDataTests.swift
CompileSwift normal x86_64 /Carthage/Checkouts/Alamofire/Tests/ServerTrustPolicyTests.swift
CompileSwift normal x86_64 /Carthage/Checkouts/Alamofire/Tests/CacheTests.swift
CompileSwift normal x86_64 /Carthage/Checkouts/Alamofire/Tests/SessionDelegateTests.swift
CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
(5 failures)
/Carthage/Checkouts/Alamofire/Tests/SessionDelegateTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ResultTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ValidationTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/NetworkReachabilityManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/SessionDelegateTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ResultTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ValidationTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/NetworkReachabilityManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/SessionDelegateTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ResultTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ValidationTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/NetworkReachabilityManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/SessionDelegateTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ResultTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/ValidationTests.swift:23:18: error: module 'Alamofire' was not compiled for testing
/Carthage/Checkouts/Alamofire/Tests/NetworkReachabilityManagerTests.swift:23:18: error: module 'Alamofire' was not compiled for testing

First make sure you're running the latest version of Carthage and Xcode 7.3. Also make sure you're xcodebuild is updated to 7.3. Then you need to clean the project, wipe derived data and possibly the Xcode cache. If you're still seeing issues, reboot. After all this, you will see that Alamofire 3.3.0 and 3.3.1 do compile successfully with Xcode 7.3.

It will not compile with Xcode 7.2.1 and below.

Cheers. 🍻


Getting error code 141 when running on docker CentOS 7 image

Hi,
I got wix (using version 2.1.4) running correctly on my MacOS Sierra local machine, but our CI runs in a docker CentOS 7 container with Jenkins, and when running on Jenkins, I get this error when mysql is starting up:
20:06:07.708 [Test worker] INFO  com.wix.mysql.EmbeddedMysql - Preparing EmbeddedMysql version 'Version 5.6.35'...
    20:06:07.882 [Test worker] INFO  com.wix.mysql.MysqldExecutable - Preparing mysqld for startup
$EnhancerBySpringCGLIB$$29b53469]: Constructor threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mySqlConfig': Invocation of init method failed; nested exception is java.lang.RuntimeException: Command exited with error code: '141' and output: ''

When googling, I found this https://github.com/wix/wix-embedded-mysql/issues/25 which seems to be how I'm running, Jenkins when running on Docker, it runs as root, and locally for test purposes, I ran the tests as root and got an error stating that the tests can't be run as root.
I see issue 25 was already fixed, is there something special I need to setup on my code so that it runs as root without issues?
This is my setup code:
MysqldConfig config = aMysqldConfig(v5_6_latest).withCharset(Charset.UTF8MB4)
                .withPort(port).withUser(username, password)
                .withTimeZone(TimeZone.getTimeZone("UTC")).withTimeout(600, TimeUnit.SECONDS).build();

        SchemaConfig schema = aSchemaConfig("my_dbschema").withCharset(Charset.UTF8MB4).build();
        mysqld = anEmbeddedMysql(config).addSchema(schema).start();

Where username and password are variables pulled from our configuration so the jdbc URL uses those as authentication for logging into embedded mysql.
Thanks!

Sorry, the problem was on CentOS 7, the version installed under docker comes with a weird libaio version, uninstalling and doing a yum -y install libaio installed the latest from CentOS repo and worked as expected.
Thanks!


Feature request: Rules that match sequences of events and support for rules that match the type of record returned by a DNS lookup

Motivation

I was reading https://www.bleepingcomputer.com/news/security/cracked-macos-apps-drain-wallets-using-scripts-fetched-from-dns-records/ just now and a thought occurred to me, as well as a few more while typing this out.

Retrieving TXT records is an effective way for an attacker to get additional code including simple scripts or full-fledged base64 encoded binaries which could be decoded, into an already compromised system of any kind (not just limited to MacOS, but also Linux servers as well as containers running in Docker or Kubernetes) without arousing much suspicion, so I want to be able to detect when there are repeated DNS lookups for any record type other than A, MX, and NS records.
Even without retrieving TXT records from DNS to download attack code, I don't want certain other types of DNS records like AAAA records being retrieved by my containers that only have an IPv4 stack available and so would never interact with IPv6 services, so I would want to detect when lookups of those records happen even once.

Feature

See above
Alternatives

Matching based on IP or name only, and you have to know the domains ahead of time in order to add them to a rule that notifies based on a list of domains, or you have to know all of the domains you talk to in order to add them to a rule that notifies based on NOT matching a list of domains, and the event has to be triggered by something already; it's not possible to match based on just the DNS lookup itself happening.
Additional context

I want to treat DNS as if DNS can't be trusted. A quick google didn't reveal any promising results for how to implement DNSSEC in a container context as a client, so I honestly think this isn't something that could be fixed at the container level. So in my mind, that means that DNS in a container should not be trusted period. Therefore, DNS lookups themselves need to generate an event in Falco that the rules can match. The default ruleset doesn't necessarily need to enable this new type of rule for all users right off the bat, which would allow time for testing and refinement over a few releases of anything implemented towards closing this issue.

Assign this feature to me. I can build this feature.

.take

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

@rashim27us I think you can make a fork of the project, and then write your code and open a PR; no need to have the issue assigned to you. I look forward to seeing this implemented :) Thank you in advance!

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.


[WFLY-12019] HostRemove should not remove services unless allow-resource-service-restart=true is set

Issue: https://issues.redhat.com/browse/WFLY-12019
This PR tries to replace #16894 as that has test failures, and creating a new PR based on that will be efficient.
The test failures in #16894 is interacted  tests related, means that some other tests lead to a server state not cleaned, it is not easy to locate that test, but trying to reload the server when trying to modify the server can solve the test failure issue.

@pferraro thanks Paul, I updated the test to avoid hard coding.


Update @popperjs/core dependency

Fixes

Related to #3242 by @obulat
Description

Update @popperjs/core dependency
Testing Instructions

Checklist

[ ] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.
[ ] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@khushi-kothari, the linting errors in the CI and the numbers of lines changed (+3,773 −4,328) show that there are still unrelated changes in the lock file.
I updated the lock file here to only include the changes from this PR:

Checked out the lock file from main to remove all unrelated changes.

git checkout main -- pnpm-lock.yaml

Ran just node-install to update the lock file.
Committed the updated lock file to the branch and pushed the changes.

You will need to do the same for other PRs. After the CI passes, you can mark the PRs ready for review.
Next time, please only open one PR at a time to make the PR writing, reviewing and merging without conflicts easier.

@khushi-kothari, the linting errors in the CI and the numbers of lines changed (+3,773 −4,328) show that there are still unrelated changes in the lock file.
I updated the lock file here to only include the changes from this PR:

Checked out the lock file from main to remove all unrelated changes.

git checkout main -- pnpm-lock.yaml

Ran just node-install to update the lock file.
Committed the updated lock file to the branch and pushed the changes.

You will need to do the same for other PRs. After the CI passes, you can mark the PRs ready for review. Next time, please only open one PR at a time to make the PR writing, reviewing and merging without conflicts easier.

Wow Thankyou very much, for some reason even after doing just node-install or just install lock file wasn't getting updated. This was really helpful of you. Making same changes in all the PRs and hope we'll soon be ready to go 🚀

All thanks to @obulat now this PR is passing all the CI 🎉

I'm glad you liked the changes. Thankyou for reviewing @dhruvkb, and I'm happy to contribute 😄🙌


Sassafras Iteration 3.2

Partially addresses #11515
This iteration has the main objective of integrating a ticket submission system that functions properly.
While it may not be the final version, it is crucial that the necessary structures are established to enable some form of zero-knowledge proof for validating tickets.

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable-int
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2429602


Unknown type "Button" Build Error when trying to use XCC

I am using Microsoft P&P Prism in a universal store/phone app, working in a VisualStateAwarePage and trying to use xcc.  I think I have followed the sample correctly but xcc does not work as easily as the docs suggest and I am left with a strange build error.
After following the sample, I have a page like this:
<prism:VisualStateAwarePage
x:Class="Project1.Views.Page1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
xmlns:core="using:Microsoft.Xaml.Interactions.Core"
xmlns:converters="using:Project1.Converters"
xmlns:prism="using:Microsoft.Practices.Prism.StoreApps"
xmlns:prismMvvm="using:Microsoft.Practices.Prism.Mvvm"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:win81="condition:WINDOWS_APP"
xmlns:wp81="condition:WINDOWS_PHONE_APP"
xmlns:debug="condition:DEBUG"
xmlns:release="condition:!DEBUG"
mc:Ignorable="d win81 wp81 debug release"
mc:ProcessContent="d win81:* wp81:* debug:* release:*"
prismMvvm:ViewModelLocator.AutoWireViewModel="true" >
Then on the page,  have a button that I only want to show in DEBUG mode.
<debug:Button ... stuff ...  />
And I get this build error:
Error	4	Unknown type 'Button' in XML namespace 'using:Microsoft.Practices.Prism.StoreApps'	C:\PROJECTS\Project1.WindowsPhone\obj\x86\Debug\preprocessedxaml\Views\Page1.xaml	60	14	Project1.WindowsPhone
Has anyone seen this or have any insight about what is wrong?
Thanks

Your XAML looks fine. Can you share how the Button is defined in XAML?

I defined a button like this:
<debug:Button Grid.Row="1"
Content="Test Button"
Command="{Binding TestCommand}" />
Which immediately leads to this error:
XamlCompiler error WMC0001: Unknown type 'Button' in XML namespace 'using:Microsoft.Practices.Prism.StoreApps'
I have tracked down the problem to the fact that my pages are inheriting not from Windows.UI.Xaml.Controls.Page but from Microsoft.Practices.Prism.StoreApps.VisualStateAwarePage. I do that because I am using Microsoft's Patterns and Practices Prism library I am also using the Unity library and following the MVVM pattern.
Unfortunately, I don't know enough about how XCC works to know what to fix though.  To eliminate complexity, I created a second, simple test project and found it to work exactly as it should. I think proceeded to

Got it, XCC translates conditional elements to the namespace of the root element. Since your page root element is defined in the using:Microsoft.Practices.Prism.StoreApps namespace, the conditional Button is rewritten to that namespace. Exactly what the error message is describing.
Interesting bug, which requires some thinking.
Thanks for reporting


AI: Scope out interactive/layered "Anatomy of a Kubernetes Cluster" diagram

This is a...

[x] Feature Request
[ ] Bug Report

Problem:
There isn't a very intuitive way to understand how all the different Kubernetes components tie together in the context of higher-level domains like security, networking, etc.
Proposed Solution:
Approximation of idea in https://docs.google.com/document/d/1-fpCxMAEfWucVLaDHKwYthVU3cIE962lsr6OTaqvpJg/edit# (heavily WIP).
TLDR

TODOS

[ ] Flesh out layers (@abiogenesis-now)
[ ] Determine components per layer (@abiogenesis-now)
[ ] Review (everyone -- SIG Docs and many engineers)
[ ] Front-end magic (@chenopis)
[ ] 🎉

cc @chenopis @Bradamant3 @heidecke

The idea is that this diagram would be particular helpful on the What is Kubernetes page.

@alexcontini We might need your help on this too.

/remove-lifecycle stale

/remove-lifecycle rotten


Add metrics aspects

Since the library is somewhat blackbox within the WebhookServer it would be good to augment with metrics for the common operations so that end user integrations can get them if they hook up a connector.
Just as a starter I was thinking:

a status code frequency
latency
retry counter

I'll take a look :)


Coverage spreads to nested cargo invocation

I'm working with code running on GPUs using cuda. I'm experimenting with writing the code being run on the GPU in rust and use a buildscript (build.rs) to invoke cargo with --target nvptx64-nvidia-cuda. I then embed the resulting assembly (ptx) into the final executable using the include_str! macro. The nvptx64 target needs to be build as a #![no_std] target using -Zbuild-std.
It seems like the cargo invocation made in the buildscript for building the GPU assembly is also being called with the -C instrument-coverage flag. This is a problem as it is not supported on #![no_std] targets. It seems to persist even when clearing the RUSTFLAGS env variable or explicitly setting -C instrument-coverage=off for the nested cargo invocation.
Is this the preferred behavior or would it be better to require the nested cargo invocation to explicitly ask for coverage for it to be generated? Are there any known workarounds?

I don't know the details of your build script, so I can't provide any specific suggestions, but any of the following may work:

Passing --target option avoids applying RUSTFLAGS to the build script.
Passing --coverage-target-only option uses CARGO_TARGET_{target}_RUSTFLAGS instead of RUSTFLAGS. (see #167 for more)

Passing --target option avoids applying RUSTFLAGS to the build script.

This doesn't help. It seems like it avoids applying RUSTFLAGS for the build.rs compilation. But the problem is actually the cargo invocation which is performed in the build.rs file and the coverage stuff seems to spreads to that command.

Passing --coverage-target-only option uses CARGO_TARGET_{target}_RUSTFLAGS instead of RUSTFLAGS

This seems to be the correct workaround, but it unfortunately doesn't work alone. I did some digging and it seems like even though the coverage stuff doesn't make it into RUSTFLAGS it still makes it into CARGO_ENCODED_RUSTFLAGS. That is the reason the coverage stuff is spread to the consecutive cargo invocation. If I use std::process::Command::env_remove with CARGO_ENCODED_RUSTFLAGS when invoking cargo it seems to work with --coverage-target-only.
That means I have found a workaround so feel free to close the issue unless you feel like the nested cargo invocation needs first class support. It is admittedly not a common use case so it is totally understandable for this to be a "wontfix". Also let me know if there's anything I can do to help out.

unless you feel like the nested cargo invocation needs first class support

Considering that CARGO_ENCODED_RUSTFLAGS is an environment variable set by cargo for build scripts, it seems impossible to provide first class support for this on the cargo-llvm-cov side alone.


Sonar issues

This should fix most blocker issues in SonarCloud (they were false positives)

Yes, looks good to me!


Merge upstream fork (0.9.1)

Merging changes from the upstream repository.
Our previous fork point pinned dependencies (pycontracts) in a different way to the upstream repository. The upstream repository has resolved this in v0.9.1.
This will be used as the base to merge our own additional changes for supporting session_id and index (which the upstream repository does not currently support).

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
4 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.2%) to 97.259%

Files with Coverage Reduction
New Missed Lines
%

snowplow_tracker/payload.py
1
96.77%

snowplow_tracker/tracker.py
3
98.83%

Totals

Change from base Build 834829179:
-0.2%

Covered Lines:
1987

Relevant Lines:
2043

💛  - Coveralls


pgge should accept generically named input graphs

pgge must become more generic in accepting graphs that do not originate from pggb.
I already worked into that direction, but on further thoughts, it is not generic enough.
Solution: Let the user input a file with the full file name path & the corresponding display name in the PNG.
Read from this file instead of the default input parameter to avoid confusion downstream.

I think I already did that. Will re-open, if issues appear.


Upgrade yard-doctest dependency

The yard-doctest gem is used to test the code examples in documentation.
Upgrade the dependency to include the ability read .yardopts and exclude files.
Add the yard rake task to CI and enable yard documentation warnings.
Include a couple small documentation fixes as well.
[closes #2293, #2296, #2299, #2301, #2314, #2324, #2326, #2329]

I pulled the branch, ran bundle update, then removed existing doc directories. In handwritten libs such as google-cloud-bigquery, I see no warnings. However, in the generated libs that I tried I see warnings:
Chriss-iMac:google-cloud-dataproc quartzmo$ bundle exec rake yard
[error]: Error loading plugin 'yard-doctest'
[warn]: The proxy Google::Cloud::Dataproc::V1::ClusterControllerClient::OperationsClient.self has not yet been recognized.
If this class/method is part of your source tree, this will affect your documentation results.
You can correct this issue by loading the source file for this object before `lib/google/cloud/dataproc/v1/cluster_controller_client.rb'

[warn]: The proxy Google::Cloud::Dataproc::V1::ClusterControllerClient::OperationsClient.self has not yet been recognized.
If this class/method is part of your source tree, this will affect your documentation results.
You can correct this issue by loading the source file for this object before `lib/google/cloud/dataproc/v1/cluster_controller_client.rb'

[warn]: In file `lib/google/cloud/dataproc/v1/doc/google/longrunning/operations.rb':51: Cannot resolve link to Google::Longrunning::Operations::GetOperation from text:
	...{Google::Longrunning::Operations::GetOperation Operations::GetOperation}...
[warn]: In file `lib/google/cloud/dataproc/v1/doc/google/longrunning/operations.rb':57: Cannot resolve link to Google::Longrunning::Operations::ListOperations from text:
	...{Google::Longrunning::Operations::ListOperations Operations::ListOperations}...
[warn]: In file `lib/google/cloud/dataproc/v1/doc/google/longrunning/operations.rb':72: Cannot resolve link to Google::Longrunning::Operations::ListOperations from text:
	...{Google::Longrunning::Operations::ListOperations Operations::ListOperations}...
[warn]: In file `lib/google/cloud/dataproc/v1/doc/google/longrunning/operations.rb':81: Cannot resolve link to Google::Longrunning::Operations::CancelOperation from text:
	...{Google::Longrunning::Operations::CancelOperation Operations::CancelOperation}...
[warn]: In file `lib/google/cloud/dataproc/v1/doc/google/longrunning/operations.rb':87: Cannot resolve link to Google::Longrunning::Operations::DeleteOperation from text:
	...{Google::Longrunning::Operations::DeleteOperation Operations::DeleteOperation}...
Files:          14
Modules:        18 (   10 undocumented)
Classes:        55 (    1 undocumented)
Constants:      60 (    9 undocumented)
Attributes:    103 (    0 undocumented)
Methods:        18 (    0 undocumented)
 92.13% documented

I didn't update the GAPIC-generated gems to fail on YARD warnings, only the veneer gems. But I don't see any warnings on dataproc, nor do i see the warning on CircleCI or Kokoro.

I should clarify, I don't see any warnings in the ci output.

Hmm, I also do not see the warnings on rake ci. What happens to them?
Chriss-iMac:google-cloud-dataproc quartzmo$ bundle exec rake ci
[error]: Error loading plugin 'yard-doctest'

######################################
### BUILDING google-cloud-dataproc ###
######################################
...

bundle exec rake doctest
[error]: Error loading plugin 'yard-doctest'
The google-cloud-dataproc gem does not have doctest tests.

nm, I get it, rake ci only runs rake doctest, not rake yard.

I don't think this PR should close issues such as #2297 (and similar), since it does not resolve the YARD warnings, which can still be seen when running rake yard for these gems.

The following veneer gems still have documentation warnings, and are being allowed to raise documentation warnings because their warnings are still unaddressed:

Bigtable
Datastore
Error Reporting
Firestore
Logging
Spanner
Vision

This PR isn't closing #2297, or any other generated gem. It is only closing hand-written gems that no longer have warnings.

@blowmage There's nothing we can do in generated gems to prevent this error, is there?
[error]: Error loading plugin 'yard-doctest'


Update a local installation of hubot

Is there an automated way to update hubot when installed via "npm install hubot"? "npm update" can install the new version, but removes the old one completely with its package.json.

@philippbeckmann I use npm-check-updates to update all of my npm packages easily. This works for your hubot installation and in general for any npm-managed project.  just install that and run npm-check-updates -u and npm install which will update your package.json and install the updated packages, including hubot


Add Typescript, use Jest, use linting rules, use up to date packages and use react-intl

all common and up to date packages for a better and easier start

@oakstair FYI

Not the maintainer, but some feedback

hugely useful to have the libraries updated
Jest and react-intl align more nicely with community direction
"Successfull" is spelt "Successful".

however

Switching the entire frontend project over to Typescript without discussion though is the sort of thing usually frowned on.  Consumers of a project don't always have the capacity or capability to make the change.  React itself isn't Typescript, so that's a choice that doesn't align with the core community.

Yeah, I was in rush and needed it personally. Later, after the PR, I also thought about point 4. and I would totally understand the decision not to merge it some day.
Personally, I think, Typescript is quite easy to learn and makes complex Webapps so much more easy to develop, understand and debug, also for beginners. I also didn't reintegrate the Redux Devtools again. If you like, feel free to continue the work and get rid of Typescript. It should be enough to remove all types and remove the Typescript loader in Webpack again.

Hello @floric, I just wanted to say that I have seen your PR and I'm really grateful you took the time to submit it :1st_place_medal:
I really like the version bump and I think maybe the move to react-intl is the good one.
I'm a big proponent of typecsript and I wouldn't use react without it but maybe it belongs to a fork.
I'm not sure pushing yet another technology to the stack will satisfy everyone here.
It is very difficult for me to review this PR as it is. It does too much.
If you're still motivated I would gladly review and merge seperate PRs for:

Bump of the dependencies
React-intl
jest

Hey @geowarin,
I can totally understand this. I'm not sure, when I can do this, but I will have a look. Your base project helped me a lot for mine, so giving something back is the least I can do. :)
Personally, I still think always using Typescript would make JS development even for starters so much easier and more predictable (as long as the libraries and type defs are synchronized and up to date)


fix TypeError: (0 , c.jsxDEV) is not a function

Current dependencies on/for this PR:

main

PR #9   👈

This comment was auto-generated by Graphite.


Happy 2 ^ 16

Congratulations, 0 issues! We can all go home now!

sent from my 8086

Sounds solved.

Apparently today we passed<PHONE_NUMBER> unix time.


pysnmp.proto.error.ProtocolError: Bad IP address syntax

As discussed in https://stackoverflow.com/questions/75001418/python-snmp-bad-ip, this library does not yet handle IPv6 addresses, so likely causes such errors.
The address length check should be revised.

It seems that IPv6 addresses should be passed via IpV6Address textual convention, https://datatracker.ietf.org/doc/html/rfc2465 So, no need to change any code.


Remove json_max type

While removing json I came across json_max and wondered what that is for. So when I deleted it, I figured out it works this way:

There is a top-level Yojson module which has a type t, that contains all the variants.
That module has another module, Yojson.Pretty which has the prettyprinter for the "biggest" type.
All the Yojson.{Basic,Safe,Raw} variants upcast their t type to this biggest type and and then use the functions from Yojson.Pretty.
(Amusingly, it is therefore possible to get a  `String in a variant that does not define STRING on the CPPO level, since it always uses  `String instead of  `Stringlit, though this is mostly a weird behaviour and probably not a bug)

This PR changes it in a way that every of the variants has its own Pretty module which is specialized to only pretty-print the specific variant.
I've made this a separate PR since I would like to know your input:

The code is in my opinion somewhat easier to understand since all the different variants (Basic, Safe, Raw use their own Pretty module.
Potentially faster, since the pattern match is smaller, but I'd be surprised if it makes a nontrivial difference
The generated code is larger since Pretty exists 4 times now instead of once.

This is separated into its separate PR since I don't want to press it on the one that is important for the 2.0.0 release.
(Note this PR is branched off #100)

I was also confused why removing this alias would ripple through so much code, until I understood what it is used for. I'll try to explain what is going on.
The current code has one Pretty module, Yojson.Pretty. This module has functions to pretty-print a very specific type — json_max, which includes all the possible variants (note that it includes mutually exclusive variants like  `Int and `IntLit, so no parser ever generates values of json_max type).
Then each of the Basic/Safe/Raw has its own write2.ml which takes a {Basic,Safe,Raw}.t and uses Yojson.Pretty to pretty print it. Since these specialized types are subsets of json_max they get upcast (which is safe) to json_max so they can use the functions in the top-level Pretty module.
Removing the json_max name means:

Either I have to write out the full type by hand for the upcast which is very tedious
Or I have to have a Pretty module that actually matches the type t and not a superset of it.
Maybe some other solutions, but I couldn't think of anything on the spot, input welcome

I chose to do number 2, thus I made CPPO generate Pretty modules that would operate on the respective {Basic,Safe,Raw}.t types, so I had to add all the #ifdefs and now each of the modules has its own specialized Pretty module that only pretty-prints the exact subset of t.
Having gone through all this I am not sure it was worth it. It certainly is more code and the printer looks worse. On the other hand, I think it is now slightly more understandable, since the Basic/Safe/Raw variants do not share a mysterious Pretty module under the hood.
Hence this PR is somewhat more on the "well, I'll ask for input from others" side, since I am not sure it is a win or not.

Haven't looked at the PR, but if pretty was just a private module,
thanks to dune, it would be an implementation detail so there's no
downside in keeping it, I think?
 I tend to use a lot of codegen based on dune these days (I can
show examples in containers) instead :-)

Haven't looked at the PR, but if pretty was just a private module, thanks to dune, it would be an implementation detail so there's no downside in keeping it, I think?

The json_max type is public so I thought I might remove it for 2.0.0 so I started pulling the string and the whole thing came with it.
But I can try to solve it in a different way, where the Pretty that works on json_max is in its own submodule and can be accessed without needing the json_max alias. Though personally I don't really like how Pretty just has to support everything.
I also dislike CPPO, for the same reason. I was thinking whether replacing the whole misery with functors or just using composition of functions that operate on polymorphic variants would work better. But reducing the need for this duplicated code and code generation (#105) would be even better.


Can not find tools/bpy-2.82.1

Hello, I found the file convert2fbx.py containing "tools/bpy-2.82.1", but I can not find it. Can you share me? Thank you.

Oh, that doesn't work anymore, so I delete it.
Maybe this would help, I haven't try it yet:
https://github.com/TylerGubala/blenderpy/releases
But there should be many related project about this.


Support new item type: registry

JSKOS Registries are used in Cocoda to manage data sources and in BARTOC for the list of terminology registries. The latter is managed in a plain NDJSON file but should be moved into a jskos-server database (https://github.com/gbv/bartoc.org/issues/70). By now, registries are only referenced in GET /voc.
Requires additional endpoints:

GET /registries
GET /registries/:_id
PUT /registries/:_id
DELETE /registries/:_id
GET /registries/suggest

Registries should also be returned by GET /data endpoint for known URI.
And maybe:

PATCH /registries/:_id (I don't think we actually need this but if its two lines of code why not)
POST /registries (requires minting new URIs, we don't use UUID URIs in BARTOC so better not)

We should also review existing registry data in Cocoda config and in BARTOC to possibly adjust registry data model.

We should also review existing registry data in Cocoda config and in BARTOC to possibly adjust registry data model.

Absolutely. The term is used for different things at the moment and it should be clarified.

POST /registries (requires minting new URIs, we don't use UUID URIs in BARTOC so better not)

How do registries get into the server without a POST endpoint? It does not necessarily require minting URIs with UUIDs if we decide how URIs are built (e.g. with the notation in lowercase). It also doesn't have to be publicly accessible, but I'd rather have it implemented like this for easier import.

How do registries get into the server without a POST endpoint?

Ok, POST with existing URIs in the posted records should be possible!

Requires https://github.com/gbv/jskos/issues/110. As discussed there, a JSKOS Registry corresponds to a (subclass of) dcat:Catalog and it may have one or more services. These services (currently given in non-standard field API) correspond to cocoda-sdk registries and to dcat:DataService.


create GPIO/I2C/SPI DSL

+1
On Tue, Apr 28, 2015, 19:46 Greg. A<EMAIL_ADDRESS>wrote:

—
Reply to this email directly or view it on GitHub
https://github.com/camel-labs/camel-labs/issues/46.

Spec for GPIO
gpio(id).high().to()
gpio(id).low().to()
gpio(id).toggle().to()
from().gpio(id) #use body value
from().gpio(id).high()
from().gpio(id).low().to()
from().gpio(id).toggle()

Spec for I2C
i2c(bus,id).poll().to() "use body value
from().i2c(bus,id)

sample code here
https://github.com/apache/camel/tree/master/camel-core/src/main/java/org/apache/camel/model/rest

@hekonsek what do you think about creating an component (maven) like this "camel-iot-dsl" ?

Actually I prefer splitting the DSL into the more specialized modules. For example camel-iot-gpio-dsl .

Just to avoid keeping all possible DSLs in a single jar.

Hi @gautric,
@sbunciak would like to push forward the topic of the implementation-agnostic DSL / modules.
The first question is - DSL for what exactly we would like to create in the first place? GPIO? I2C?

Moving to the next release.

Hi @hekonsek,
I'm not completely familiar with the implementation details of common DSLs in Camel, however I'd first create some kind of common API/SPI that all the "connector" components (camel-pi4j, camel-bulldog) needs to implement.
As for the DSL itself, GPIO + I2C + SPI (+ UART?) will do the thing I guess. The spec by @gautric seems fine.

spec : https://gist.github.com/gautric/85c68f3b204398b523b1

I would start with committing camel-bulldog component first. Then creating DSL module and implementing DSL in pi4j and bulldog components. DSL is really an addition to the components. The latter can be used even without DSL - using endpoint URIs.

Closing old tickets. Feel free to reopen it you would like to contribute an actual code.


Transfering a name

I have been unable to find any directions for using the app at ENS Registrar. If this exists, please tell me where it is.
After running into many errors with this software, I have finally finalized a bid on a name. I would now like to transfer ownership from this account to MyEtherWallet account. The software is asking me this question:
"Account to transfer the name to:"
Can I simply enter my public key for MyEtherWallet account, or is it looking for some other piece of information?

This repository is for issues with the ENS solidity code and associated utilities. For the registrar DApp, please open an issue here: https://github.com/ethereum/ens-registrar-dapp/issues/new


Add glyphs to Particle Renderer

Fixes #3009 by adding glyphs to the particle
7a8f2cb4768102acc416f1f990cdf1c71373dd3f: clangTidyOutput.txt

@StasJ @shaomeng @clyne,
The idiosyncrasies of the Flow Renderer have been removed.  Caching has been added for performance, as well as the option to render with legacy code.  Performance comparisons are shown below, which are run on a dataset containing 1 million particles.  Note: Both the legacy Particle renderer and the one in this PR will crash when rendering 1M particles, as reported in issue #3102.  See #3102 for a modified version of generateExampleDCP.py that will generate a test file.
Uncomment ParticleRenderer.cpp:46 to print timing info on legacy and glyph rendering.

Stride
Legacy
Glyphs

4*
61397
122237

4
50888
66478

4
50637
66224

4
50592
66728

2*
67615
206448

2
66607
135185

2
65748
133497

2
65849
133344

@sgpearse will validate timing on legacy particle rendering vs current again!

@clyne @StasJ @shaomeng  - I've updated the table in my previous post with tests done on cisl-acworth.  I'll copy them below for convenience as well.
@StasJ - I see what you mean about the particle generator code replication.  I've added a switch so this code can be used with the legacy renderer and glyphs.  While the new code is not identical to the legacy code, it's functionally the same.

Scott, this code is very difficult to understand. It uses both a glm::vec4 and a flow::Particle to represent a particle, and it seems to do some conversion between the two. I don't see why flow::Particle is needed honestly; it seems to only complicate things...

@shaomeng I see what you mean.  I've removed the usage of flow::Particle, and broken Legacy and Glyph codes into their own functions that don't depend on many "if (legacy)" switches.  There's just one switch now at ParticleRenderer.cpp:113.  The new functions that should make things easier to read are listed below.
_genrateParticlesLegacy()
_generateParticleGlyphs()
_renderParticlesLegacy()
_renderParticleGlyphs()

@shaomeng - You're right about clang-tidy not working.  I looked into this and it's not simple, and goes beyond the scope of this PR so I'm going to file a new ticket.
@stas - I thought I had removed "renderDirection" but I guess not.  Fixed.

@stasj Any thoughts on this?  Copy/pasting from above:

They're still not being cached.

@StasJ - The generation of the particles is being cached. Check out line 92, where if the cache is dirty, regenerateParticles is set to true, which issues a call to _generateParticleGlyphs(). We always want to call _renderParticleGlyphs() even with a clean cache.

@StasJ - The generation of the particles is being cached. Check out line 92, where if the cache is dirty, regenerateParticles is set to true, which issues a call to _generateParticleGlyphs(). We always want to call _renderParticleGlyphs() even with a clean cache.

@StasJ - The generation of the particles is being cached. Check out line 92, where if the cache is dirty, regenerateParticles is set to true, which issues a call to _generateParticleGlyphs(). We always want to call _renderParticleGlyphs() even with a clean cache.

Line 269 inside _renderParticleGlyphs() uploads particle data to the GPU.

I agree.  I've renamed as follows:
_renderParticleGlyphs() to _generateTextureData()
_generateParticleGlyphs() to _generateParticleData()
After checking the cache, _renderParticlesHelper() is called regardless of cache state.

@clyne We're all set now, thanks!


[Bug] Dataset Events not publishing when AIRFLOW__COSMOS__ENABLE_DATASET_ALIAS enabled

Astronomer Cosmos Version
12.1.1
dbt-core version
1.8.7
Versions of dbt adapters
No response
LoadMode
AUTOMATIC
ExecutionMode
AZURE_CONTAINER_INSTANCE
InvocationMode
None
airflow version
2.10.2
Operating System
Astronomer Deployed
If a you think it's an UI issue, what browsers are you seeing the problem on?
No response
Deployment
Astronomer
Deployment details
No response
What happened?
When setting the AIRFLOW__COSMOS__ENABLE_DATASET_ALIAS to True, any task that we have that was previously producing dataset events and was not in a task group, stopped producing the events. I suspect there's something wrong with the following function:
https://github.com/astronomer/astronomer-cosmos/blob/cfb6bf20ddacb84433af094969602467475fd4bc/cosmos/dataset.py#L7
Relevant log output

How to reproduce
When AIRFLOW__COSMOS__ENABLE_DATASET_ALIAS is set to true, and when using the DbtRunLocalOperator or DbtSnapshotOperator, dataset events were no longer being published. Dataset events are being published however when using the DbtTaskGroup operator.
All operators successfully published dataset events when AIRFLOW__COSMOS__ENABLE_DATASET_ALIAS was set to False
Anything else :)?
No response
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Contact Details
<EMAIL_ADDRESS>

Hi @nishant-gupta-sh, which version of Cosmos are you using? You mentioned 12.1.1 in the ticket description, but the last release of Cosmos was 1.7.1.
Did you recently change from executing Cosmos using ExecutionMode.LOCAL to ExecutionMode.AZURE_CONTAINER_INSTANCE? This could justify the problem. Currently, Cosmos only supports emitting datasets when using ExecutionMode.LOCAL and ExecutionMode.VIRTUALENV:
https://github.com/astronomer/astronomer-cosmos/blob/main/cosmos/operators/local.py
I'll update our docs to make this more evident: https://astronomer.github.io/astronomer-cosmos/configuration/scheduling.html.

Hi @nishant-gupta-sh, which version of Cosmos are you using? You mentioned 12.1.1 in the ticket description, but the last release of Cosmos was 1.7.1.
Did you recently change from executing Cosmos using ExecutionMode.LOCAL to ExecutionMode.AZURE_CONTAINER_INSTANCE? This could justify the problem. Currently, Cosmos only supports emitting datasets when using ExecutionMode.LOCAL and ExecutionMode.VIRTUALENV: https://github.com/astronomer/astronomer-cosmos/blob/main/cosmos/operators/local.py
I'll update our docs to make this more evident: https://astronomer.github.io/astronomer-cosmos/configuration/scheduling.html.

Hi Tatiana, apologies, we're using 1.7.1 for Cosmos and the CeleryExecutor for the ExecutionMode


Fix the eth qa tests

This PR fixes all but 4 eth qa tests.
The two failing tests are:

eth_refund_moderated.py
eth_reject_direct_offline.py

The crypto-listings tests are also failing:

eth_market_price_modifier.py
eth_purchase_crypto_listing.py

Coverage remained the same at 39.637% when pulling fc43d334c759cf78e3b20fd2c68ab67e9b0cfcce on eth_qa_fix into d76213ea9f2444ddf27496b6a308f71ffb1c093d on ethereum-master.

@cpacia Ashwin and I had a chat about this PR and here's the summary:

Ashwin's not sure why the failing tests are failing (i.e. is it due to his local env or something else)
Crypto-listings hasn't been a focus of Ashwin's work so it would be best if you made whatever changes to get those working again

If fixing these tests is going to take more than an hour, then I suggested we spin-off a new issue and immediately merge the QA test fixes included in this PR.

Merge conflict @cpacia, can we fix that up and merge or are you wanting to commit something additional?


Remove wrong comment

I just noticed all your PRs are against main. Needs to be `dev. See #1084

Done.

You need to rebase your branch. See file changes.

Now good?

 No idea how all these changes ended up in my PR. Also can't get the rebase stuff to work. – Can I just start anew with my PRs, this time in the dev branch?

You can, but I recommend you learn to rebase, it's a useful skill to have. Many guides don't emphasise that you must force-push after rebase. Try this: https://docs.gitlab.com/ee/topics/git/git_rebase.html

Thanks, that link was helpful to understand a couple of things. Still wasn't able to get rid of the "garbage" in my PR above though. So ended up with a new one that uncovered a couple more issues in the README file. → #1216 – hope that works now. This PR here can be closed/removed.


session error?

I found some error : Get the elevated current session acccess token failed, returns -2147023584，I just try to open the program but raise that, i want to know how to solve this problem.
By the way, i try to run as  the administrator, but the result is same.

I read the other issue and try to run NSudo.exe to open Adobe-GenP-3.0.exe i found it can run actively, but still can run with RunMe.exe, i dont know what problem is it

same

same

直接跑Resources里的Adobe-GenP.exe就行了，好像也没什么影响，都能打上不定

same

直接跑Resources里的Adobe-GenP.exe就行了，好像也没什么影响，都能打上不定

有用！感谢


Listen ScrollView contentOffset and set it

hi there, I'm late for the party. As title, can we using this library to do something like this? Listen ScrollView contentOffset and set it. Sorry if I asking question at wrong place.

In iOS 14 you can use: ScrollViewReader to set the content offset.
In iOS 14 for listening to the contentOffset you could do something like this (although with the current version you will need: PR https://github.com/siteline/SwiftUI-Introspect/pull/56 or another fix for issue https://github.com/siteline/SwiftUI-Introspect/issues/55)
import SwiftUI
import Introspect
import Combine

struct ScrollViewDidScrollViewModifier: ViewModifier {

    class ViewModel: ObservableObject {
        var contentOffsetSubscription: AnyCancellable?
    }

    @StateObject var viewModel = ViewModel()
    var didScroll: (CGPoint) -> Void

    func body(content: Content) -> some View {
        content
        .introspectScrollView { scrollView in
            if viewModel.contentOffsetSubscription == nil {
                viewModel.contentOffsetSubscription = scrollView.publisher(for: \.contentOffset)
                .sink { contentOffset in
                    didScroll(contentOffset)
                }
            }
        }
    }
}

extension ScrollView {
    func didScroll(_ didScroll: @escaping (CGPoint) -> Void) -> some View {
        self.modifier(ScrollViewDidScrollViewModifier(didScroll: didScroll))
    }
}

struct ContentView: View {
    var body: some View {
        ScrollView {
            ForEach(1..<21) { _ in
                Text("Hello, world!")
                    .padding()
            }
        }
        .didScroll { contentOffset in
            print(contentOffset)
        }
    }
}

This is not an Introspect Issue, also @lucastimeless has also provided a nice solution. That said I will close this issue.

if viewModel.contentOffsetSubscription == nil {
                viewModel.contentOffsetSubscription = scrollView.publisher(for: \.contentOffset)
                .sink { contentOffset in
                    didScroll(contentOffset)
                }
            }

Please be careful with this solution, as sinking the publisher within the view creates a retain and your view (and related viewmodels) will not be de-allocated.
Here's the fix:
import Foundation
import SwiftUI
import Combine

struct ScrollViewDidScrollViewModifier: ViewModifier {
  class ViewModel: ObservableObject {
    @Published var contentOffset: CGPoint = .zero

    var contentOffsetSubscription: AnyCancellable?

    func subscribe(scrollView: UIScrollView) {
      contentOffsetSubscription = scrollView.publisher(for: \.contentOffset).sink { [weak self] contentOffset in
        self?.contentOffset = contentOffset
      }
    }
  }

  @StateObject var viewModel = ViewModel()
  var didScroll: (CGPoint) -> Void

  func body(content: Content) -> some View {
    content
      .introspectScrollView { scrollView in
        if viewModel.contentOffsetSubscription == nil {
          viewModel.subscribe(scrollView: scrollView)
        }
      }
      .onReceive(viewModel.$contentOffset) { contentOffset in
        didScroll(contentOffset)
      }
  }
}

extension View {
  func didScroll(_ didScroll: @escaping (CGPoint) -> Void) -> some View {
    self.modifier(ScrollViewDidScrollViewModifier(didScroll: didScroll))
  }
}

@lucastimeless thanks for the answer! However it keeps publishing values and the CPU usage is at 100% - is there a way to only listen to value changes?


move batch from ocf-datapipes

I wonder if we should move ocf-datapipes batch into this repo for the moment.
We could use Batch.gsp.name here and similar other place, to use a string not a Enum. The Enum we have had problems in the past, when we change the.
Later on we can add a Batch class with load, save, plot methods e.t.c TODO make issue

Happy to pick this one up and create the issue for the Batch class

Shall we put this as done and create a new issue saying "create batch class"?


Changing package name & signing the app.

Hi,
Thanks to your work, I have been developing an "accessibility" launcher based on LB Launcher.
I wanted to change the package name but when I did, I went through a lot of issues. Are there any steps that I need to follow to change the package name?
Also, I would like to release this app at some point and I cannot create release apks as of now. Can you help me with that?

Thanks for your reply!


[work in progress] Switch from Retrieve and Rank to Discovery

This will fix #60 and #53

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@97abc9a). Click here to learn what that means.
The diff coverage is 13.41%.

@@            Coverage Diff            @@
##             master      #61   +/-   ##
=========================================
  Coverage          ?   13.15%
  Complexity        ?       12
=========================================
  Files             ?       10
  Lines             ?      266
  Branches          ?       29
=========================================
  Hits              ?       35
  Misses            ?      224
  Partials          ?        7

Impacted Files
Coverage Δ
Complexity Δ

...versation_with_discovery/rest/WinkApplication.java
0% <ø> (ø)
0 <ø> (?)

...s/conversation_with_discovery/utils/Constants.java
0% <ø> (ø)
0 <ø> (?)

...is/conversation_with_discovery/utils/Messages.java
40% <ø> (ø)
2 <ø> (?)

...ation_with_discovery/discovery/DiscoveryQuery.java
0% <ø> (ø)
0 <ø> (?)

...onversation_with_discovery/rest/SetupResource.java
0% <ø> (ø)
0 <ø> (?)

...sation_with_discovery/payload/DocumentPayload.java
0% <ø> (ø)
0 <ø> (?)

...versation_with_discovery/listener/SetupThread.java
0% <ø> (ø)
0 <ø> (?)

...onversation_with_discovery/rest/ProxyResource.java
42.64% <42.64%> (ø)
7 <7> (?)

...tion_with_discovery/discovery/DiscoveryClient.java
6.25% <6.25%> (ø)
2 <2> (?)

..._discovery/listener/AppServletContextListener.java
7.69% <7.69%> (ø)
1 <1> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 97abc9a...d87cbe1. Read the comment docs.

@stevenpkg this seems to be working but we need to make sure the app works after you set the credentials

@manattanasio have tested with conversation and discovery we created the other day on watson platform service

@germanattanasio


Adding cpp code to generator so you can retrieve the string represent…

…ation of an enum.

Closing this as it is out of date.


Change output cache folder

in the constructer of a controller class, i try to change the cache folder:
 public function __construct() {
            parent::__construct();
            $this->config->set_item('cache_path', APPPATH. '/cache/cards/');
            $this->output->cache(7200);

The files are created in the desired folder. The cache files are however not used but newly generated at each request.

You can't change the cache path at this point ... cached output is detected before controllers (and when that happens, it is still using the value from your config.php), because that's the whole point - not to execute dynamic logic if the response is already cached.


"Device Profile" link is broken

it is in the "Authenticate" https://docs.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-5.1#authenticate
Row describing non-interactive client-side

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

ID: a0ab71a0-a2df-fa37-83fa-080dece952f6
Version Independent ID: f74b7d51-aede-ed93-437e-601654d8fa7e
Content: Get started with the REST APIs for Azure DevOps Services and Team Foundation Server - Azure DevOps Services REST API
Content Source: index.md
Product: devops
Technology: devops-ecosystem
GitHub Login: @elbatk
Microsoft Alias: elbatk

Correct link would probably be: https://github.com/Azure-Samples/active-directory-dotnet-deviceprofile


Separate generic plugin config template, maybe until 'none' mode for generic plugin is supported.

@cedricbu ty for comments. updated. Pls take another look.


Laravel 6 support

I've started developing my apps in Laravel 6, which requires newer versions of illuminate than your API supports.  Would it be possible to also allow illuminate 6.x?
I think changing the illuminate requirements to the following is all that is required (but I don't know much about Composer, so I could be causing other problems down the road):
        "illuminate/cache": "5.x||6.x",
        "illuminate/filesystem": "5.x||6.x",
        "illuminate/container": "5.x||6.x",

I've made a local copy of your package and installed it via composer without any issues, but I imagine you have more things you could test.

I updated composer.json as suggested and it seems to work just fine.  If you find something that doesn't work, let me know and I'll have a look at it.


Implement workflow engine

Implement a workflow engine on top of the job API.

Moved to https://github.com/Blazebit/blaze-job/issues/1


Update describe.py to fix n_infinite

Hey guys I was reading through the code and came across this:
count = series.count()
n_inifinte = count - series.count()

So I am pretty sure n_infinite is always 0. I believe the following expression is correct:
leng = len(series)
count = series.count()
n_inifinite = leng - count

Hope this helps

Thanks for reporting this, greatly appreciated. This is somewhat legacy code.
The tests are failing now. In at least one case (test_describe.py) it recognizes None as an infinite value. There is no test case containing infinite values, we should add one.
We can merge the PR once the tests are updated, would you have time for that?

Superseded by #432.


Upgrade cargo-deb?

We're currently locked to v1.38.4. This actually traces back to Routinator commit [https://github.com/NLnetLabs/routinator/commit/1ec204ff0c74b20daa4a0142d107a8b9eaa844ec] prior to their being a single unified Ploutos workflow in use at NLnet Labs.

So, we were locked to a specific version of cargo-deb because of a problem, but now we just lock to a version to avoid unexpected headaches caused by automatic use of a newer version, not because there's a known problem with a newer version.
Cargo-deb releases are always a bit difficult to follow as there are neither change log nor release tags with descriptions to consult to see what has changed in any given version. The latest version at the time of writing is v1.42.1. To find out what has changed we will have to examine every diff from one tag to the next, e.g. https://github.com/kornelski/cargo-deb/compare/v1.38.4...v1.39.0.
We should also clearly document which version of cargo-deb we support otherwise users might try using cargo-deb features which are only in a version newer than the one we use!

The Ploutos v7.0.0 release upgraded cargo-deb to latest to resolve issues with Cargo workspaces.


VIDECO-8308 - Passing videoHost URL into Node Video SDK incorrectly

See https://github.com/Vonage/vonage-node-sdk/tree/3.x-wip/packages/video#standalone.


126 airflow cognito integration

Purpose

Integrate Cognito with Airflow (Flask AppBuilder) authentication so that users will only need to keep track of one set of credentials when interacting with the system.

Proposed Changes

[ADD] Cognito Airflow integration via the customization of webserver_config.py.

Issues

#126 - Airflow Cognito integration

Testing
Implemented locally and then deployed to unity-venue-dev for testing:

Confirmed hand off to Cognito for user authentication

Confirmed log into Airflow UI and user role

Pending items:

I have enabled SSL on the load balancers as the Cognito app client requires an HTTPS address for the callback/redirect URIs. I am not sure if we want to enable this going forward or if there is a different URL we should use?
I did not write any unit tests for webserver_config.py, is this something we would like to see in place?

I tested this branch on a custom "unity-luca-1" deployment and it worked - great job!
But we do need to address the SSL issue. For one thing, the OGC API will not work now because the custom deployment does not have a DNS name that matches the SSL certificate.

Just a note regarding the venue-services proxy; I believe you'll need to modify the unity_proxy_airflow_ui and unity_proxy_ogc_api SSM parameters.
They've got http references that need to be https, and we'll need to add a SSLProxyEngine On directive as well, like so:
resource "aws_ssm_parameter" "unity_proxy_ogc_api" {
  name        = format("/%s", join("/", compact(["unity", var.project, var.venue, "cs", "management", "proxy", "configurations", "016-sps-ogc-api"])))
  description = "The unity-proxy configuration for the Airflow OGC API."
  type        = "String"
  value       = <<-EOT

    SSLProxyEngine On
    <Location "/${var.project}/${var.venue}/ogc/">
      ProxyPassReverse "/"
    </Location>
    <LocationMatch "^/${var.project}/${var.venue}/ogc/(.*)$">
      ProxyPassMatch "https://${data.kubernetes_ingress_v1.ogc_processes_api_ingress_internal.status[0].load_balancer[0].ingress[0].hostname}:5001/$1"
      ProxyPreserveHost On

Modify Terraform to query SSM parameter store for parameter that contain Cognito app client data. Can confirm that sensitive data is not shown when running Terraform plan.
Terraform will perform the following actions:

  # module.unity-sps-airflow.helm_release.airflow will be updated in-place
  ~ resource "helm_release" "airflow" {
        id                         = "airflow"
        name                       = "airflow"
      ~ values                     = [
          # Warning: this attribute value will be marked as sensitive and will not
          # display in UI output after applying this change. The value is unchanged.
          ~ (sensitive value),
        ]
        # (27 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Waiting on how the client id and client secret will be stored in SSM parameter store and whether it falls under SPS to store these values.


Use swiftenv local version

I just improved the setting of TravisCI.

Use the version of .swift-version file generated by swiftenv local 3.1.
Add swift build  in a script phase.

See also: https://swiftenv.fuller.li/en/latest/integrations/travis-ci.html

@pixyzehn Seems like the Travis CI build is failing though 😮

@JohnSundell Fixed:)

@JohnSundell
That's right. This was my preference. I took it out:)

It is no longer necessary to run swift build before running swift test (it will always regenerates the build manifest when necessary). In addition, it now accepts (and requires) the same -Xcc, etc. options as are used with swift build

https://github.com/apple/swift-package-manager/blob/43cc5da9ef3e65d9b6bff555b4d18866abd5b0a0/CHANGELOG.md#swift-30

@pixyzehn so what improvement does this PR bring over the current CI script? 🤔

I thought it's better to use .swift-version just for clarity if we use swiftenv in Travis.
If you don't think so, I'll close👍

Thanks:)


net: buf: remove data from end of buffers

Adds a family of functions that remove data from the end of a struct net_buf.
This rounds out the capabilities of struct net_buf, data can now be added and removed from both the start and end.
Implements #31069

Any use case in mind?

Sometimes I wish to attach a temporary piece of context information to a net_buf when passing them between threads via FIFO's (add the context before net_buf_put remove after net_buf_get).
Context information can be added in 3 places:

In the user_data parameter
Before the main data (after reserving headroom)
After the main data

I have already increased the user_data size and do not wish to increase it further to accommodate occasional requirements.
I already have a defined use for the headroom and don't want to add a secondary use.
Sometimes it just seems cleaner to append temporary information than to prepend it.
I couldn't see a reason why we shouldn't have the option to remove data from the end as well as the front.

Any use case in mind?

Sometimes I wish to attach a temporary piece of context information to a net_buf when passing them between threads via FIFO's (add the context before net_buf_put remove after net_buf_get).
Context information can be added in 3 places:

In the user_data parameter
Before the main data (after reserving headroom)
After the main data

I have already increased the user_data size and do not wish to increase it further to accommodate occasional requirements.
I already have a defined use for the headroom and don't want to add a secondary use.
Sometimes it just seems cleaner to append temporary information than to prepend it.
I couldn't see a reason why we shouldn't have the option to remove data from the end as well as the front.

I have already increased the user_data size and do not wish to increase it further to accommodate occasional requirements.
I already have a defined use for the headroom and don't want to add a secondary use.
Sometimes it just seems cleaner to append temporary information than to prepend it.
I couldn't see a reason why we shouldn't have the option to remove data from the end as well as the front.

That is a neat idea. There has been some discussion earlier about this kind of API as normally one would parse, for example networking data, starting from beginning of the buffer, so this kind of API was not really needed. But for this kind of use case, putting stuff at the end of net_buf, this kind of API is indeed useful.

I have already increased the user_data size and do not wish to increase it further to accommodate occasional requirements.
I already have a defined use for the headroom and don't want to add a secondary use.
Sometimes it just seems cleaner to append temporary information than to prepend it.
I couldn't see a reason why we shouldn't have the option to remove data from the end as well as the front.

That is a neat idea. There has been some discussion earlier about this kind of API as normally one would parse, for example networking data, starting from beginning of the buffer, so this kind of API was not really needed. But for this kind of use case, putting stuff at the end of net_buf, this kind of API is indeed useful.

I'm not opposed to this, but the use case sounds a bit hackish to me, since you're mixing meta-data in the same storage space where the actual data is located. I do understand the reasoning though, since increasing user data would impact all net_buf instances in the system, i.e. the memory overhead would be greater.

I'm not opposed to this, but the use case sounds a bit hackish to me, since you're mixing meta-data in the same storage space where the actual data is located. I do understand the reasoning though, since increasing user data would impact all net_buf instances in the system, i.e. the memory overhead would be greater.

I'm not opposed to this, but the use case sounds a bit hackish to me, since you're mixing meta-data in the same storage space where the actual data is located. I do understand the reasoning though, since increasing user data would impact all net_buf instances in the system, i.e. the memory overhead would be greater.

I understand that its hacky, but the shakiness of this particular use case doesn't diminish the general usefulness.
If it makes you feel better pretend that I'm using net_buf_simple as a simple stack, push/pop style :)

I'm not opposed to this, but the use case sounds a bit hackish to me, since you're mixing meta-data in the same storage space where the actual data is located. I do understand the reasoning though, since increasing user data would impact all net_buf instances in the system, i.e. the memory overhead would be greater.

I understand that its hacky, but the shakiness of this particular use case doesn't diminish the general usefulness.
If it makes you feel better pretend that I'm using net_buf_simple as a simple stack, push/pop style :)

Unrelated to this PR, but I'll mention it here anyway: we should really convert the wrapper defines that map net_buf APIs to corresponding net_buf_simple APIs to use static inline functions instead. This would give us better type checks/safety. If anyone wants to submit a PR for that it'd be more than welcome :)

Unrelated to this PR, but I'll mention it here anyway: we should really convert the wrapper defines that map net_buf APIs to corresponding net_buf_simple APIs to use static inline functions instead. This would give us better type checks/safety. If anyone wants to submit a PR for that it'd be more than welcome :)

If anyone wants to submit a PR for that it'd be more than welcome :)

I'll have a go after this is merged

If anyone wants to submit a PR for that it'd be more than welcome :)

I'll have a go after this is merged


pyethereum -> py-evm conversion

According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866167#20 upstream pyethereum is a deprecated project, and its functionality is being replaced by py-evm, and may already be broken, see: #264 ". pyethapp should use py-evm for anything it is currently using pyethereum for.
System/environment

OS: Debian-derived
python version: 3+

Just FYI, trinity is being designed as a node on top of py-evm, and should (I believe) completely replace pyethapp functionality. Because of that, there may not be much momentum for doing maintenance work on pyethapp.

...is there a link for trinity?  Is it on github?

trinity is in the beginning build-out. It's not merged into master, which itself isn't in alpha release yet. trinity is currently a module in py-evm, on the trinity branch: https://github.com/ethereum/py-evm/tree/trinity/trinity
The expectation is that it will eventually get moved out to its own repo.


fix #1588

Why are these changes needed?

Related issue number
#1588

Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

@luisquintanilla can you review it when you have time?


Fixing #53 #38, allows deleting tokens with backspaces when user has a custom keyboard

@ayanonagon, can you please review and merge this?

1 tiny fix, then we can merge. Thank you for the pull-request! :balloon:


RP2040 looses Micropython after plugoff

In Boot-Mode I can install the  firmware.uf2 via drag and drop. After copying the file, it is possible to reach the rp2040 with Thonny and try some examples. After plug-off and  plug.in the usb it is not possible to reach the RP. The USB-port is not availible. It seems , that RP "forgets" micropython?
What is my mistake? Or is RP damaged?

It means that only the initial upload of mpy firmware can be connected normally. Unable to connect after reset? Does clicking the Thonny reconnect button also not work?

Installing Firmware. Uf2 is only possible in bootmode. The other Option via thonny is not possible, because there is no USB-Port. Trying the other way in thonny "install Firmware..." is not possible, because the answer is that the validity of the certicate has ended.
As long as i don't plug off the RP.. I See a com-Port. Pluggoff and plug on : no com Port?

... now I plugged the rp to power supply 5 volt, first nothing happens. After pressing the "run" button about 60 to 100 times (!) the main.py program starts. Thats strange.

If it still exists, then the product may be defective.

I installed the factory firmware:
for RP.. :Xinyuan-LilyGO/T-PicoC3/tree/main/example/factory)/pico/
for ESP: ...factory/factory_MINI-1.bin
After plugoff/plugin the board starts with a Raspberry Pi Logo and switches to a screen, searching availible WLANs, trying to connect with a dummy key.
Windows shows a new Com-Port, but thonny can't connect to the board:
Unable to connect to COM4: Cannot configure port, something went wrong. Original message: PermissionError(13, 'Ein an das System angeschlossenes Gerät funktioniert nicht.', None, 31)
If you have serial connection to the device from another program, then disconnect it there first.
Process ended with exit code 1.
How can I access the board?

booting in RP Mode shows:
Device is busy or does not respond. Your options:

wait until it completes current work;
use Ctrl+C to interrupt current work;
reset the device and try again;
check connection properties;
make sure the device has suitable MicroPython / CircuitPython / firmware;
make sure the device is not in bootloader mode.

Thonny should only be able to read the serial port information, but because the factory firmware is not mpy. So it reported an error I think it should be normal.
What needs to be tested now is whether it is normal every time it is powered on in the Arduino C environment. In addition, the mpy firmware has been made in our factory firmware. I tested it and it works fine.

The usb port number simulated by mpy firmware is inconsistent with the port number in Arduino C. Check, please.

thank you for your efforts. But I don't want to use Arduino. I'm only looking for MPY firmware for the board (RP..) which starts at plugin, or after pressing "run". Then I want to read some sensors (DHT11) and show the values on the display.  Next step is transferring them by WLAN to a Raspberry Pi or to store them in a CSV-file.
But I'm a beginner and have to solve it by trial and error.
FW Version 1.19.1 from 2022-06-18 seems to be right.

I think Arduino is a great help for beginners. Because it has a library of sensors provided by many community members, and can maximize the performance of the chip. If you really don't want to use ARDUINO. The mpy firmware can try to use the firmware we provide. It has integrated the driver displayed by ST7789, and it can be used only by importing the configuration. For more mpy content, please refer to this document
https://docs.micropython.org/en/latest/

Hi, the board was defective. Today I received a replacement - all works fine.


Bring back eslint-plugin-react-hooks and fix issues

Summary
Adds back missing eslint-plugin-react-hooks dependency and fixes all reported issues.
Relevant Technical Choices
Re-enables the react-hooks/rules-of-hooks rule.
To-do

[ ] Fix outstanding lint errors

Fixes #1562

I thought the additionalHooks option in the ESLint config would eliminate most of the reported errors. Am I missing something? 🤔

It seems this plugin "assumes that any function starting with ”use” and a capital letter right after it is a Hook." so I think it should now catch everything.

Code in question: https://github.com/facebook/react/blob/7992ca10df497002e0e91bb5bfbc9661c9c85b88/packages/eslint-plugin-react-hooks/src/ExhaustiveDeps.js#L1492-L1533
I see that version 4.0.0 is brand new and had some breaking changes: https://github.com/facebook/react/blob/master/packages/eslint-plugin-react-hooks/CHANGELOG.md
Hmm, turns out they now treat any hook ending in Effect the same as useEffect (https://github.com/facebook/react/pull/18580), but doesn't seem to be in 4.0.0.
Also, refs shouldn't need to be in the dependencies list.

@swissspidy So it looks like the linter wants us to rearrange arguments in the keyboard hooks? Is this at all configurable? Stylistically, for these components, it's better to have two last arguments to be function + deps. But it looks like the linter always wants the first two?

Right 🤦 somehow I didn't see the forest for the trees here.
Yes, the linter expects the first two to be callback + deps. See https://github.com/facebook/react/blob/edf6eac8a181860fd8a2d076a43806f1237495a1/packages/eslint-plugin-react-hooks/src/ExhaustiveDeps.js#L1492-L1533
This is currently not configurable, however they might be willing to allow this. They seem to be very open about contributions to the lint rule.

This is currently not configurable, however they might be willing to allow this. They seem to be very open about contributions to the lint rule.

Ok. Let's try it. I sent them a pull request: https://github.com/facebook/react/pull/18861. But we may have to be prepared to change signatures if it doesn't move fast enough. This is an important linter to avoid bugs.

@dvoytenko Your upstream PR now has a merge conflict. Could you resolve that one?
In the meantime, I propose patching this package directly using patch-package (already in use in the repo) while waiting for this to  be merged.

Small nitpicks, but we are looking good.

@swissspidy sorry for delay. I just rebased the original proposal pull request. patch-package for this is a brilliant!


Modern look and feel

Would something like this be possible to do?

Thank you for your request!
The actual differnces compared to the current implemantation I can identify from the editor in your picture are:
Visual stuff:

[ ] Bindable background colors for the line number column and the text area (in this case it's both transparent to get the mica/acrylic effect shine through)
[ ] Bindable font (to select MonoLisa/Fira/... instead of Consolas)
[ ] Bindable selected line number color
[ ] Different shades for selected and unselected line numbers
[ ] Vertical indentation lines inside of the text area with the same color as unselected line numbers
[ ] Current line has a semi-transparent shade of the unselected line number color (instead of the current rounded frame)

Logical stuff:

[ ] Bindable current member hierarchy for external display e.g. as a breadcrumb bar

Lots of good ideas; I will work on that.

Yep, mainly things like the font and the colors used. I am willing to help on making these changes.

I implemented some of the ideas:

Font (string) and ShowIndentGuides (Enum: None, Line, Dashed) are new DependencyProperties that can be set in xaml with your ViewModel data:
<codewriter:CodeWriter x:Name="CW" Grid.Row="1" Margin="12,0,0,0"
CornerRadius="{StaticResource OverlayCornerRadius}"
Background="Transparent"
Font="{Binding Font}"
Language="{Binding EditorLanguage}"
Text="{Binding Text, Mode=TwoWay}"
TextChanged="CW_TextChanged"
ErrorOccured="CW_ErrorOccured"
FontSize="{Binding FontSize, Mode=TwoWay}"
TabLength="{Binding TabLength}"
RequestedTheme="{Binding RequestedTheme}"
ShowIndentGuides="{Binding ShowIndentGuides}"
ShowControlCharacters="{Binding ShowControlCharacters}"
ShowLineNumbers="{Binding ShowLineNumbers}"
ShowLineMarkers="{Binding ShowLineMarkers}"
IsFoldingEnabled="{Binding IsFoldingEnabled}"
IsWrappingEnabled="{Binding IsWrappingEnabled}"
ShowScrollbarMarkers="{Binding ShowScrollbarMarkers}"
ShowHorizontalTicks="{Binding ShowHorizontalTicks}"
ShowScrollbars="True"/>

Regarding Fonts: I tried to add Fira Code and JetBrains Mono. The first seems to work but the text rendering gets reeeally slow. The second one does not work at all (I guess only specific types of ttf files are allowed). So as of now we are stuck to the preinstalled Windows monospaced fonts. I added the ones I know to the TestApp: "Consolas", "Courier New", "Lucida Sans Typewriter", "Cascadia Code", "Cascadia Mono".
Regarding 'colors used': All editor colors are exposed as public properties. They are not yet implemented as DependencyProperties but you can change all colors at runtime by e.g.  by setting CodeWriter.Color_Background in C#.  To change colors that are used to draw stuff in the Win2D Canvas (like CodeWriter.Color_LineNumber) at runtime you need to additionally call CodeWriter.Invalidate(). I will consolidate the Colors by removing redundancies and I will turn then into bindable DependencyProperties with automatic invalidation.
If you meant the syntax highlighting colors: They can be set globally by the static publicly exposed Dictionary<Token, Color> EditorOptions.TokenColors. Or (as shown in the TestApp) you can define a bindable List<TokenDefinition> to directly update the syntax colors at a color change:

For the line number and the indent guides to change color depending if the corresponding line is selected, I need to change the way how the stacked Canvases work. I will deal with that once I do the general code refactoring mentioned in the discussion https://github.com/WelterDevelopment/CodeEditorContol-WinUI/discussions/9#discussioncomment-3259809.

Well done man!!!! I'm impressed.

Haha thanks, but .NET is just a hobby for me.
Well, the docs used to be sooo good back in the UWP days. Now that Win32, WPF, UWP, Windows App SDK and .NET MAUI all coexist, it is very messy. There is no good documentation for Windows App SDK, even though it is supposed to be the main tool for developing Windows apps. I started learning UWP development with Bob Tabor who made a very good and extensive video course on Channel 9 (now called Microsoft Learn): https://docs.microsoft.com/en-us/shows/windows-10-development-for-absolute-beginners/. Most of the XAML and C# syntax and namespaces haven't changed (exception: Windows.UI (=old UWP Controls) turned into Microsoft.UI (=new WinUI 3 controls)), so you can follow the course even using the Windows App SDK. Once you understand how MVVM and DataTemplates work you are good to go to develop for any .NET-based runtime; the basics haven't changed since WPF.

Closing in order to clean up my feed, thanks for implementing some of the changes ;)


Your Money, Your Goals menu broken in IE

Short description explaining the high-level reason for the new issue.
Current behavior
Error (1):

Visit /educational-resources/your-money-your-goals/ in IE9
Click on a mega menu item, such as Data & Research
See error in console SCRIPT5007: Unable to get value of property 'getDom': object is null or undefined

Error (2):

Visit /educational-resources/your-money-your-goals/ in IE10
Click on a mega menu item, such as Data & Research
See error in console Invalid character

Expected behavior

No errors in IE and user should be able to navigate menu.

Can't reproduce in IE9. Still need to get an IE10 VM downloaded after business hours when I'm off the VPN.

Can't reproduce in IE9. Still need to get an IE10 VM downloaded after business hours when I'm off the VPN.

Looked again, are you clicking the Data & Research heading? Once you do that the menu will not expand anymore:

Probably my authored bug 👅

Hmmm, OK, I'll take another look. I think I missed the instruction to click.

Confirmed this behavior. Not so sure on a fix.

Just saw this bug in Chrome on OS X but can't replicate.

Likely this error in New Relic

With the new menu release I'm not able to reproduce this and I don't see the getDom error in new relic any more.


[docs] Fix dead links

What changes were proposed in this pull request?

Change few dead links in documentation flagged by CI checks

How was this patch tested?

Manually and existing documentation CI check

We need to find a long term solution for this dead link check - either remove it completely or find an alternate or fix the check to work for all links.


Add indexing progress bar

Adding a progress bar in the view panel would help users know if indexing is proceeding normally.

Seeing how fast things are going would help users notice unusual stalls, crashes, etc. Could help reveal configuration issues?
Especially useful when processing large traces that take some time to get through (more than 10-15 seconds).

This an intermediate step towards showing progress for the whole server processing (indexing + analysis #284). Implementing an indexing progress bar requires way less extensive changes than showing analysis progress.
Bar could be placed here:

The status bar already gives some indication when trace indexing is ongoing. It updates with the current number of trace events read.

It doesn't track the progress, i.e. percentage of read trace events.

Oh hey! I never noticed that. @bhufmann Is this information shown in the status bar (rather than in a toast-like box like finding traces, opening traces and merging traces are shown in) because it's a number and not a progress bar? Or was the intention to make it look more like a background task?
For reference:
https://user-images.githubusercontent.com/28311615/126668417-38bd95b4-d8dc-4c07-ad03-59c03c6d2f34.mp4

After a quick discussion with @tahini, I'm less convinced of the relevance of an indexing progress bar. I'll start with some more off-github discussion before proceeding with this issue.