connection contribution point

Moves from having connection information from extensions being part of the capabilities service that is called after registration, to being a contribution point in the package.json for extensions. This has a few advantages.

We know about there declared capabilities much faster than before. Before, even with @saurabh500 previous change, before we knew about capabilities we would have to wait for the extension to start up then register itself then wait on a request to get their capabilities (i'm ignoring cacheing in this example). Where as package.json parsing happens much sooner in the vscode extensibility lifecycle. This means we can do things with the user regarding extensions before the extensions themselves have started.

Follows the vscode precedent on how they handle extensions registering major features they provide.

I have forgone converting the other things that the capabilities service providers such as serialization providers and backup providers to limit the changes I am making, so the old register providers scenario still exists for those features, but they aren't cached.

@anthonydresser do we want to take this for March?  If so, is it ready to merge today?

@kburtram I think this should wait till after march, since its a large change and extensibility isn't a main goal of this release


Fix a potential identifier bug

Hey!
This might impact the performance of the convnexts4nd baseline. Maybe you want to have a look.
Best,
Cedric

Thank you for your kindly fix. But I think it is not a problem, as when we testing the convnext-s4nd, this file has not been used.
All these files in the folder analyze/convnexts4nd are mainly adopted from the s4 repo , and maybe this bug would affects performance in the paper s4nd.

Thank you for your response!
We are currently testing a tool for detecting bugs in repositories and I noticed the code during our evaluation. But if this is not relevant for you, I think we can close this MR now. Thanks!


Please add build instructions

Please add build instructions to this project. Some open source projects provide build instructions via a top-level file called HACKING (or DEVELOPMENT, BUILD, ...):

bluez
snapd
systemd

You could also add the instructions to the top-level README.
The build instructions should mention:

build tools required (eg. cmake), including which versions are required
what version of libc is required
what version of device-sdk-c is required
a pointer to instructions on how to install device-sdk-c
what version of libdbus is required
how are people supposed to get libdbus? Perhaps offering instructions on how to build on specific operating systems such as Ubuntu, MacOS, CentOS, Fedora, ...
supported architectures
any other relevant details required to build this device service

@FraserG01 at last Monday's WG meeting, @iain-anderson asked me to review the some of the closed out issues in this device service that I'd reported. The changes made to the README are a definite step forward, but I think there's more work to be done here. Also, I realize that some of my comments below apply to more then just the build instructions, however it'd seemed easier to convey all of my comments about the current README in one shot. If you'd like me to break these non-build comments into a separate issue, I'd be glad to do so.
Global comments

the term Device Service is capitalized everywhere, suggest lower case is more appropriate.

Introduction

The BLE Device Service connects Bluetooth Low Energy devices with EdgeX. The Device Service currently limited to Bluetooth GATT devices/profiles.

suggest: This device service currently only supports the BLE GATT profile.

Prerequisites

suggest: you should differentiate between build prerequisites (e.g. cmake, make, library dev packages or headers, ...) and runtime prerequisites (e.g. bluez, dbus). Note, some are both (i.e. libdbus-dev vs. libdbus.*.so).

A Linux build host.

Do we want to list distros/versions supported? tested?
suggest: State that this device service is only supported on Linux, as it requires both DBus and the bluez Bluetooth stack. Although it may be possible to get both running on MacOS or Windows, use on either is considered unsupported.

GCC that supports C11

suggest: gcc 5.x or greater (gcc 5 series defaults to -std=gnu11). Also note, -std=gnu11 is default, which means C11 plus GNU extensions, including those that conflict with C11; for strict C11, you need specify -std=c11. Is the default (gnu11) sufficient?
suggest: if not already present, add an assert for __STDC_VERSION__ == 201112L

Make 4.1

suggest: or greater

CMake 3.1 or greater

question: why do you need to specify both cmake and make minimum versions? The device-sdk-c only requires cmake 3 or greater, and doesn't stipulate a minimum version of make.

Cbor version 0.5

suggest: or greater
suggest: Is it OK for developers to use standard distro packages of this? Maybe mention that packages aren't available for your build host, see github for build instructions?
question: does this device service statically link against the library and/or require this library to be included in a container?
note: the last release of this library was 2017! Doesn't seem well supported.
question: cbor is already a dependency of the SDK, so why it include it here?

Device-SDK-C version 1.0.0 or greater.

note: the first version of device-sdk-c w/a top-level Makefile is v1.1.0, shouldn't we require v1.1.0 or better yet, the latest stable version v1.1.1?

D-Bus version 1.12.2

note: buildtime and/or runtime dependencies (see above)?
suggest: or greater
question: why 12.2? Ubuntu 16.04 includes dbus 1.10.6. Is there something specific required from dbus 1.12 or will it work with 1.10?

Bluez 5.48

note: buildtime and/or runtime dependencies (see above)?
note: libraries and dev packages are available on most distros; does this device service statically link against the library and/or require this library to be included in a container?
question: are there 5.48-specific features (mostly DBus API methods/interfaces) used by the DS? Has the DS been tested with 5.37 (default bluez on Ubuntu 16.04)

Build

Before building the device service, please ensure that you have the EdgeX Device-SDK-C installed

suggest: add a link on how to install Device-SDK-C
suggest: the repository needs to be re-named to device-ble-c, or you need to tell people to re-name when they clone. I suppose the other option is to just request the name change when you finally submit the PR to move this DS from holding to edgexfoundry.
note - my build fails due to lack of C SDK build (see below)

Run

suggest: service name should be device-ble, drop the -c
question: in v1.1.1 of device-sdk-go, --registry was updated from a boolean to a string arg which specifies the address of the registry. Was it updated in device-sdk-c too?
see: https://github.com/edgexfoundry-holding/device-bluetooth-c/pull/7/files

Run the following command in shell to start the Device Service

question: is a shell required to run it?

Here's some separate but related feedback on device-sdk-c, based on my experience trying to build this device service on an Ubuntu 18.04.

Some of our C device services say to use 1.0.0, but the first version to add a top-level Makefile (needed to run make), is v1.0.0
Prerequisite library/packages are listed, without any kind of links.
microhttpd - I couldn't find an Ubuntu package for this, and there's no link to source project
There's no instructions on how to set the env vars required by the Makefile. Ex
LIBMICROHTTP_LIBRARIES LIBMICROHTTP_INCLUDE_DIR
Same for curl (version 7.32 or later), libyaml (version 0.1.6 or later), libcbor (version 0.5), and libuuid (from libutils)
No instructions on how to install the SDK on a system

@tonyespy Here is my responses to your points raised, I have included the AppArmor disclaimer suggestion from https://github.com/edgexfoundry-holding/device-bluetooth-c/issues/4.
Also there is a pull request with these changes. Please could you review it. Cheers, Fraser

I think you should just add a disclaimer to the top-level README that says it's only possible to run this device service fully confined on distros with AppArmor enabled (maybe listing a few), and that at this time, this device service is not supported on any distro with SE Linux enabled by default (I actually wonder if anyone has done a full test of EdgeX on SE Linux?). I'd also file a bug specifically for the issue that the service can't be run on an SE Linux enabled distro (even with --priviledged specified), and close this issue.

Added a disclaimer at the top of the README

Global comments
the term Device Service is capitalized everywhere, suggest lower case is more appropriate.

Fixed

Introduction
The BLE Device Service connects Bluetooth Low Energy devices with EdgeX. The Device Service currently limited to Bluetooth GATT devices/profiles.

Fixed

Prerequisites
Suggest: you should differentiate between build prerequisites (e.g. cmake, make, library dev packages or headers, ...) and runtime prerequisites (e.g. bluez, dbus). Note, some are both (i.e. libdbus-dev vs. libdbus.*.so).

Have separated into different sections, runtime and building

A Linux build host.
Do we want to list distros/versions supported? Tested?

I have added a section saying that only ubuntu 16 and 18 have been tested and 16 needs it bluez updated

suggest: State that this device service is only supported on Linux, as it requires both DBus and the bluez Bluetooth stack. Although it may be possible to get both running on MacOS or Windows, use on either is considered unsupported.

Added this to the README

GCC that supports C11
suggest: gcc 5.x or greater (gcc 5 series defaults to -std=gnu11). Also note, -std=gnu11 is default, which means C11 plus GNU extensions, including those that conflict with C11; for strict C11, you need specify -std=c11. Is the default (gnu11) sufficient?

No extensions are used so the cmake has been changed to set c11 with no extensions
Also changed the readme gcc version to a min of 5.x or greater

suggest: if not already present, add an assert for STDC_VERSION == 20111

Added an assert in main.c

CMake 3.1 or greater
question: why do you need to specify both cmake and make minimum versions? The device-sdk-c only requires cmake 3 or greater, and doesn't stipulate a minimum version of make.

Removed min version of make in line with the device-sdk
Reduced min cmake version down to 3.0 in readme and in the cmake file

Cbor version 0.5
suggest: Is it OK for developers to use standard distro packages of this? Maybe mention that if packages aren't available for your build host, see github for build instructions?

Cbor is both a runtime and build dependency, standard distribution packages are recommended

question: cbor is already a dependency of the SDK, so why it include it here?

It is requirement for building the SDK within the dockerfile of the device service
- @iain-anderson has provided a revised dockerfile for the device service that it makes it clearer as to what is used for building the SDK and what is used for building the device service

question: does this device service statically link against the library and/or require this library to be included in a container?

Added a note that on Alpine there is no standard package for Cbor, so it is downloaded and built automatically in our Docker build.

note: the last release of this library was 2017! Doesn't seem well supported.

Based on the min version specified by the SDK

Device-SDK-C version 1.0.0 or greater.

Have changed to 1.1.1 in the readme and build_deps.sh

D-Bus version 1.12.2
note: buildtime and/or runtime dependencies (see above)?

Has been placed in build and runtime dependencies

suggest: or greater

Added or greater

question: why 12.2? Ubuntu 16.04 includes dbus 1.10.6. Is there something specific required from dbus 1.12 or will it work with 1.10?

Have tested Ubuntu 16.04 and dbus 1.10.6 works so have reduced minimum version

Bluez 5.48
note: buildtime and/or runtime dependencies (see above)?

BlueZ is just a runtime dependency so have moved it to that section

note: libraries and dev packages are available on most distros; does this device service statically link against the library and/or require this library to be included in a container?

Neither as long as the host machine has the minimum version of bluez as we are just using the bluez daemon via dbus

question: are there 5.48-specific features (mostly DBus API methods/interfaces) used by the DS? Has the DS been tested with 5.37 (default bluez on Ubuntu 16.04)

Have tested on Ubuntu 16.04 with bluez 5.37 and it does not work, with an upgrade to 5.48 it does work, so saying that min version required is 5.48

Build
Before building the device service, please ensure that you have the EdgeX Device-SDK-C installed

Have added some general instructions

suggest: the repository needs to be re-named to device-ble-c, or you need to tell people to re-name when they clone. I suppose the other option is to just request the name change when you finally submit the PR to move this DS from holding to edgexfoundry.

Is going to be renamed during the move I believe so should not be an issue

note - my build fails due to lack of C SDK build (see below)

Changed the sdk to v1.1.1 for building and fixes it

Run
suggest: service name should be device-ble, drop the -c

Dropped the c in the binary, makefile and docker image

question: in v1.1.1 of device-sdk-go, --registry was updated from a boolean to a string arg which specifies the address of the registry. Was it updated in device-sdk-c too?

This was updated in the C SDK to allow the string argument to be optional in line with the Go SDK and other services

Run the following command in shell to start the Device Service
question: is a shell required to run it?

Altered the wording to make it sound like its not the only way, only an example

Network Argument required for docker run (Raised by myself)

Added the network argument to the docker run commands

This is looking really good now. A couple of minor things still and this can get closed out.

Cbor version 0.5
suggest: Is it OK for developers to use standard distro packages of this? Maybe mention that if packages aren't available for your build host, see github for build instructions?

Cbor is both a runtime and build dependency, standard distribution packages are recommended

I still think it's weird that you list Cbor here, as it's really a dependency of the SDK, but I'm not going to block closing this over it. That said, you say it's both a build-time and a runtime dependency, but I'm assuming the latter is for the shared library, there's no CBor daemon, or other sort of runtime dependency for Cbor right? Please see my question about static vs. dynamic libraries. It sounds the resulting binary is linked against shared libraries that need to be installed/included in the host OS or container. This also confused me when I saw that you list CBor in the runtime dependencies. If the dependency really is the shared library, then why aren't the other shared libraries used by the SDK listed here? If you really want to keep it, then maybe add in parentheses that it's the library that's required at runtime.
Another option is to statically link the service...

note: libraries and dev packages are available on most distros; does this device service statically link against the library and/or require this library to be included in a container?
Neither as long as the host machine has the minimum version of bluez as we are just using the bluez daemon via dbus

For DBus, it looks like the runtime dependency is for both the shared library and a running system daemon.

I still think it's weird that you list Cbor here, as it's really a dependency of the SDK, but I'm not going to block closing this over it. That said, you say it's both a build-time and a runtime dependency, but I'm assuming the latter is for the shared library, there's no CBor daemon, or other sort of runtime dependency for Cbor right? Please see my question about static vs. dynamic libraries. It sounds the resulting binary is linked against shared libraries that need to be installed/included in the host OS or container. This also confused me when I saw that you list CBor in the runtime dependencies. If the dependency really is the shared library, then why aren't the other shared libraries used by the SDK listed here? If you really want to keep it, then maybe add in parentheses that it's the library that's required at runtime.

I spoke with @iain-anderson and he agrees that it can be removed from the dependencies. A note above the build requirements has been added which explains the SDK is required along with its dependencies instead, including CBor.

For DBus, it looks like the runtime dependency is for both the shared library and a running system daemon.

I have updated the requirements to reflect this.
Changes have been made in PR: https://github.com/edgexfoundry-holding/device-bluetooth-c/pull/26


Privacy policy

Top navbar (logo) is not vertically center.
In medium screen right webp picture is shrinking.

i can help with the privacy policy issue so please assignee me this issue under GSSOC'23

Hello buddies, I would rather suggest to delete the logo, becos it is kind of odd in that page.
And moreover the privacy policy page is built through standard template! and ig redirection back to homepage is not required through the logo itslef. We have also added(linking to main page)  in the copyright section at the end :)


Showing Directors and movie cast

themoviedb also provides cast and directors details. I would like to add that as GSSOC'23 Contributor
Could you please assign this issue to me?

I would like to work in this, it totally goes with my techstacks . Could you please assign this to me?


Differences between channels in futures and std

I'm wondering whether there are any high-level rules driving the design of channels in futures. At first sight, it might seem that futures::sync::mpsc and std::sync::mpsc are trying to mirror each other - the former channels work with asynchronous tasks and the latter channels work with threads. Other than that, they look very similar.
Closing/disconnection
But then there are some peculiar differences. For example, channels in futures have Receiver::close. If this method is useful, is there any reason why channels in std don't have it, too? Or, put differently, was this method added because it fits into a certain model of how futures should be used, or just seemed like a nice addition at a certain time?
Unbounded channels
Another difference is that futures doesn't have unbounded (sometimes called asynchronous) channels, while std does. Is there a reason for that? Golang considers unbounded channels dangerous because they don't provide backpressure. Still, they have their uses (e.g. in Servo), hence why we have them in std. Will we ever have them in futures, too?
Capacities of bounded channels
Next, bounded channels in futures have unusual capacities. Each Sender has its own reserved slot in the channel, which means the actual capacity of a channel is the initial capacity + the number of active senders. There are technical reasons for this - I believe capacity behaves like that simply because it's hard to make it constant without sacrificing performance. These technical hurdles can be overcome, however. In any case, it can be surprising to discover this behavior.
Learnability
There's also a case to be made for learnability. If the Rust book teaches inter-thread communication using std::sync::mpsc, are newcomers not going to expect channels in futures to behave the same way? But there sure seem to be a few important differences, or 'catches' one has to be aware of.
I'm personally a fan of thinking of channels in futures and std as virtually the same, except for what kind of threading/task mechanism they operate on. Or maybe making these channels as similar as possible is simply not a goal we should pursue?

It's that the Unbounded channels you mentioned?
https://github.com/rust-lang-nursery/futures-rs/blob/master/futures-channel/src/mpsc/mod.rs#L376

@kamyuentse Oh, I wasn't aware of the new unbounded channels because they don't show up on docs.rs/futures yet. Never mind about the lack of unbounded channels then. :)

@stjepang I just notice it when I check the code before. Thanks for your great conclusion about the difference.

I use futures 0.1.25 and got an unexpected panic from the channel.
The scenario is sending from a stream (tokio runtime) to a GUI std::thread which calls poll on the Receiver.
If all Senders (and their runtime?) is dropped, poll() panics on the receiver - I would expect an Error.
Am I doing it wrong? I found no way to have futures::::Sender with std::::Receiver.

@stsydow if you have a stack trace it would be good to open a new issue for it. Skimming the code I don't see any way that closing the channel should cause a panic to occur.

I'm reviewing issues that are blocking the 0.3 milestone and I'd like a contributor to weigh in on the status of this issue. I'm unclear what action would be needed to resolve this, or whether it's still relevant since its original filing.

I don't think this issue is still relevant-- if there're more changes wanted here, please file an updated issue. Thanks!


Visualizations mosaic faceting - if keeping vertical layout, add margin-top to facet headings in multi-contingency table

The facet "headings" should be closer to the table they apply to (below them) than the one above.
Might be better with a margin-bottom on the table, or some fancy if-not-first CSS rule.

Also, empty facets don't need to have quite so much min-height or whatever is causing the gaps.  A "No data for this facet" might be more appropriate.

@bobular On main the cont tables are arranged horizontally. Is that the final arrangement as opposed to the vertical arrangement shown here?

Hi Connor, it's obviated now due to the horizontal layout, which to my eye doesn't need any urgent work either.


[Docs] Explain function subtyping and variance

I'm not an expert at type theory, but trying out the previous function subtyping example seemed to convince me that it was not correct because it explained that inputs and outputs should both be subtypes, whereas inputs should actually be a super type.
I'm also not an expert at technical writing, so please let me know (or just edit) if my tone and style don't fit with the rest of the docs.
I tried to add a light explanation of function subtyping that might help for simple cases, while still pointing to the Variance page for a more detailed discussion.
(Note that, in reading the Variance page, I notice that it mostly focuses on variance as applied to OO class hierarchies. I think there might be room for a simpler explanation of function input/output types. There is also probably a need for some examples of just functions with complex cases: arguments that are callbacks, whose arguments are in output position and therefore covariant, arguments that are written to, and therefore invariant, etc.)

@jbrown215 thanks for your feedback! I completely agree with all of it. I've updated the text to reflect your suggestions and add some more concrete cases.

Thanks again for these changes. I think your examples make the docs way clearer!


Custom arguments' help is not shown when calling locust --help

Prerequisites

[X] I am using the latest version of Locust
[X] I am reporting a bug, not asking a question

Description
(I'm not certain you would consider this a bug or a feature request.)
How to reproduce

Create a locust.conf file in the current directory
Add custom arguments
Run locust --help (or even locust -f locustfile.py)

Expected result

I expect locust to load the locustfile.py and run the init_command_line_parser hook
I expect to see my custom arguments' help to be shown in locust --help 's output

Actual result

The locustfile.py is not loaded at all when running locust --help.
The custom arguments' help are not shown in locust --help 's output.

Possible fix
Replace the built-in help action by something that loads the locustfile before printing the help.

Add an explicit --help argument (parser.add_argument('-h', '--help', action="store_true" ...)
Check if args.help == True
Call parser.print_help() and parser.exit() (just like the default _HelpAction does)

Command line
locust --help
Locustfile contents
import argparse

from locust import events

print("top-level")

@events.init_command_line_parser.add_listener
def init_command_line_parser(parser: argparse.ArgumentParser):
    """
    Initialize the command line parser with custom arguments.
    """
    print("init_command_line_parser")

    parser.add_argument(
        "--my-little-argument",
        type=str,
        help="Choose a custom load shape",
        choices=["a", "b", "c"],
    )

Python version
Test with both Python 3.10.12 and 3.12.6
Locust version
2.31.6
Operating system
Ubuntu 22.04.4 LTS and 24.04 LTS

Yea this is a real bug. I think your suggested fix sounds reasonable and would love for you to PR it!

@fstamour is anyone working this ? , would like to have a crack at it

I would like to work on this if there's any chance..? @cyberw

Go for it. I meant to assign it to you.

Hey @cyberw @fstamour I was having some trouble to set up this project locally but after a succcessful setup now I am stuck with how get to the fix.. The possible fix provided when executed refers to a conflict addressing the pre-existence of a default help argument.. If you can maybe elaborate further on the possible fix, I'll get it working

Python's argparse, by default, handles the "--help" argument automatically.
Argparse will print the help message and exit the process when calling "parse argument", which means the process exits before locust can even look at the other arguments
But locust must look at the other arguments to be able to load the locustfile and execute the hook that will add the custom arguments before the help is shown and the process exits
By manually adding a custom arguments "--help", it overrides the default behaviour of printing the help and exiting the process
That way, locust can process the other arguments, load the file, and execute the hook
Once that is done, locust needs to do what the default handler was doing, so it must check the arguments to see if "--help" was passed, and if it is, then call parser.print_help() to print the help and then locust needs to exit the process

@shauryapanchal make sense?


Jest issue?

Describe the bug
Trying to run Jest tests creates an error:
 ● Test suite failed to run

    Styles were unable to be assigned to a file. This is generally caused by one of the following:

    - You may have created styles outside of a '.css.ts' context
    - You may have incorrect configuration. See https://vanilla-extract.style/documentation/setup

      1 | import { style } from '@vanilla-extract/css';
      2 |
    > 3 | export const button = style({
.....

I've tried using import '@vanilla-extract/css/disableRuntimeStyles' in my setupFilesAfterEnv file, but it doesn't seem to effect anything. I followed the webpack tutorial, and everything else seems to be working. Just broken on unit tests.
System Info
Output of npx envinfo --system --npmPackages @vanilla-extract/css,@vanilla-extract/webpack-plugin,@vanilla-extract/esbuild-plugin,@vanilla-extract/vite-plugin,@vanilla-extract/sprinkles,webpack,esbuild,vite --binaries --browsers:
 System:
    OS: macOS 11.4
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 1.43 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.1 - ~/.nvm/versions/node/v14.17.1/bin/node
    npm: 7.19.0 - ~/.nvm/versions/node/v14.17.1/bin/npm
  Browsers:
    Chrome: 91.0.4472.114
    Firefox: 90.0
    Safari: 14.1.1
  npmPackages:
    @vanilla-extract/css: ^1.1.2 => 1.1.2
    @vanilla-extract/webpack-plugin: ^1.0.3 => 1.0.3
    webpack: ^5.11.1 => 5.44.

Have you added the @vanilla-extract/babel-plugin to your babel config for your tests? Outside of that impossible to say without a reproduction.

I do have that in my babel config (works for webpack), but I'm not sure how to make Jest use the same babel config?


Where is v.1.0.0-rc.12 source-code?

I did not find a version tag v.1.0.0-rc.12.
https://www.npmjs.com/package/ng-formly
aitboudad published 3 weeks ago
1.0.0-rc.12

tag added


[BACKLOG-31531] Remove shims from pdi-ce-core.

:gear: Build finished in 1m 34s with command:
mvn clean verify -B -e -Daether.connector.resumeDownloads=false -amd \
-Daudit -pl assemblies/core/client

:exclamation: No tests found!
:information_source:  This is an automatic message


Upstream OAuthenticator features in use by Earthscope

As part of https://github.com/2i2c-org/infrastructure/pull/3618, we have two features in use by earthscope:

[x] Modifying the name of the user after authentication so it's valid https://github.com/jupyterhub/oauthenticator/pull/717
[x] Allowing login only when a specified set of scopes are granted https://github.com/jupyterhub/oauthenticator/pull/719
[x] Appropriately redirect to hub home page when logged out https://github.com/jupyterhub/oauthenticator/pull/722

This ticket tracks getting both these PRs merged upstream, and then bringing them in so we can remove the custom python code in the earthscopes common.yaml config file

two PRs have been meged, and the 3rd has been deemed not necessary! \o/


Linux makefile build serializes during middle of build

The linux build serializes down to a single core during the middle of the build (I'd estimate 90% of the build time is spent in this serialized section). The start and end of the build use all cores as expected. I can't see any dependencies that would be causing this, but I'm no cmake expert.

Try this:
cmake --build . -- -j 7
in other words, you want to pass to Make that it should build in parallel.

I tried -j 20 (I've got 16 cores), also tried omitting it and using MAKEFLAGS=-j16, there is parallelism during the start and end of the build (KSysGuard shows all cores 100%) but the middle section is just using a single core, and only 6% at that.

Hey @gigadude,
If you take a GraphViz export from the CMake it shows that all third parties are linked against the framework. This means that once all third parties are build in parallel the build system more than likely is parsing the framework in a serialized manner. I may be wrong... If you could provide any log dumps or information that you think is valuable to identifying the bottleneck that would be great.
This is poor design, but I would like to highlight that Vulkan Samples is a developer education resource first and the priority here is the samples themselves and not having the most efficient build system. One method to improve the build system would be to split the frameworks components behind interfaces (The best designs are those based from behavior and not a strict application flow). This will allow the framework to be compiled as multiple static libraries which are only linked with third parties which they use. Everything can then be compiled in parallel and linked at the end appropriately.
The difficult aspect here is not the identification of the problem, its clear as day, but more how should we go about solving the problem. Most developers on this project are using their spare time to contribute, review and maintain code and so such a large change can be incredibly hard and slow to introduce to the project.
I am open to more solutions and my comments here may be out of place and not the root cause of the problem, I wanted to highlight how large I think the change is and the road blocks that may stop it in the short term. Please feel free to contribute a proposal or an implementation which helps fix this issue

Here's a profile pass of a build
log.txt
Posting it here for reference for everyone.  I haven't gone through it yet.

This is becoming a pain point for me when trying to test new samples.
I have a 96 core build server and I'm building with -j.
The first 40% of the build takes about 30 seconds. The remainder takes a further 7 minutes.

Looking through the actions. Before Plugins we built in around 25m. After plugins this is now 35m. The biggest change here is compiling samples as static libraries instead of object libraries

You may need to download the above picture to zoom and see it. Here we can see a normal graph of dependencies. The only issue is its circular. Everything links against framework and then everything links against apps which links against framework... CMake is magic but probably not magic enough to resolve this design

I ran into that problem here's how I got past it:
What matters in "circular dependencies" is the linking phase.  CMake correctly says that's bad practice when trying to make non-static libs (i.e. objects that are self contained like executables or shared libs).  The path towards a simple fix is to use the INTERFACE headers defined on the target like so:
target_include_directories( foo PUBLIC $<TARGET_PROPERTY:bar,INTERFACE_INCLUDE_DIRECTORIES>)
set_target_properties(foo PROPERTIES INTERFACE_LINK_LIBRARIES $<TARGET_PROPERTY:bar,INTERFACE_LINK_LIBRARIES)
That way you can maintain the header dependencies.  As well as any consuming application will capture the dependencies as originally envisioned.
However, a better fix is what I'm currently working on.  I hate circular dependencies.... straightening out the path correctly is simpler and easier for people consuming CMake to not duplicate bad practices.


Oh , god ............ harder to use more good tools

realy sad for both can't be downloaded ...............................

Sorry for the delay in answer.
Should be fixed now.
Please, let me know if it's ok for you.
Regards


Update -DomainMode for Windows Server 2016 Domain

Hi, this is important!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot


adding support type hinting for geemap

Description
type hinting in Python allows you to indicate the anticipated types of variables, function parameters, and return values. It serves as a means to provide suggestions or annotations regarding the desired data types to be utilized in your code. Although type hints are not enforced during runtime, they offer valuable insights to developers, static type checkers, and code analysis tools.
example type hinting on function and variable
def calculation(num_first: int, num_second: int) -> int:
 return num_first + num_second

phi: float = 3.14
name: str = "geemap"

type hints enhance code readability, enhance documentation quality, and enable static type checking tools to identify possible errors and enhance code reliability. They are not mandatory in Python and do not impact the runtime behavior of the code.
Source code
type hinting was implemented on some function but not applied for all. for example we can find on
geemap/report.py
import scooby
from typing import Optional

class Report(scooby.Report):
    def __init__(
        self,
        additional: Optional[dict] = None,
        ncol: int = 3,
        text_width: int = 80,
        sort: bool = False,
    ):
        """Initiate a scooby.Report instance."""
        core = [
            "geemap",
            "ee",
            "ipyleaflet",
            "folium",
            "jupyterlab",
            "notebook",
            "ipyevents",
        ]
        optional = ["geopandas", "localtileserver"]

        scooby.Report.__init__(
            self,
            additional=additional,
            core=core,
            optional=optional,
            ncol=ncol,
            text_width=text_width,
            sort=sort

The statement from __future__ import annotations is used in Python to enable more advanced Type Hinting features. In Python 3.7 and below, Type Hinting only supports the use of strings in type annotations, such as def my_function(param: str) -> int. However, by using the from __future__ import annotations statement at the beginning of your code, you can use type annotations as normal expressions, such as def my_function(param: str) -> int.

i think, by removing the unnecessaryif conditions for checking the modulo of the coordinates seems good  cause in Python, when applying the modulo operator % to a number, the result will be zero if the number is already divisible by the divisor. Therefore, the conditions can be omitted, and the calculations can be performed directly.
geemap/geemap/cartoee.py
here's if can build more simple and more efficiency
def _buffer_box(bbox: list[float], interval: float) -> tuple[float, float, float, float]:
    """Helper function to buffer a bounding box to the nearest multiple of interval

    args:
        bbox (list[float]): list of float values specifying coordinates, expects order to be [W,E,S,N]
        interval (float): float specifying multiple at which to buffer coordianates to

    returns:
        extent (tuple[float]): returns tuple of buffered coordinates rounded to interval in order of [W,E,S,N]
    """
    xmin = bbox[0] - (bbox[0] % interval)
    xmax = bbox[1] + (interval - (bbox[1] % interval))
    ymin = bbox[2] - (bbox[2] % interval)
    ymax = bbox[3] + (interval - (bbox[3] % interval))

    return xmin, xmax, ymin, ymax

Good suggestion. Ideally, we want to have type hints for all functions and classes. I haven't had time to work on this yet. Contributions are welcome.

excuse me sir @giswqs ,sorry for mention, i got some miss documentation on function local_tile_pixel_value on common.py
def local_tile_pixel_value(
    lon,
    lat,
    tile_client,
    verbose=True,
    **kwargs,
):
    """Get pixel value from COG.

    Args:
        lon (float): Longitude of the pixel.
        lat (float): Latitude of the pixel.
        url (str): HTTP URL to a COG, e.g., 'https://opendata.digitalglobe.com/events/california-fire-2020/pre-event/2018-02-16/pine-gulch-fire20/1030010076004E00.tif'
        bidx (str, optional): Dataset band indexes (e.g bidx=1, bidx=1&bidx=2&bidx=3). Defaults to None.
        titiler_endpoint (str, optional): Titiler endpoint, e.g., "https://titiler.xyz", "planetary-computer", "pc". Defaults to None.
        verbose (bool, optional): Print status messages. Defaults to True.

    Returns:
        list: A dictionary of band info.
    """

    r = tile_client.pixel(lat, lon, units="EPSG:4326", **kwargs)
    if "bands" in r:
        return r["bands"]
    else:
        if verbose:
            print("No pixel value found.")
        return None

where docstring arguments are different from parameter

Thank you for reporting. Please feel free to fix it as you see fit. Thanks

adding information on function IS_GCS to
"""
Checks if a shapefile is in a geographic coordinate system (GCS).

    Args:
        in_shp (str): Path to the input shapefile.

    Returns:
        bool: True if the shapefile is in a GCS, False otherwise.

    Raises:
        FileNotFoundError: If the input shapefile could not be found.
        TypeError: If the input shapefile is invalid.
"""

close issue, reference from #1565


Merge Development into new 0.3.5 release candidate

This is the pull request to incorporate recent Development changes into the 0.3.5 release branch.  Not everything in Development needs to go (e.g. development notebooks, some HPC-specific configurations, etc.)
The strategy here is to do multiple interim merges of specific major changes, e.g. merge the new timestamp handling separate from new geometry changes, etc.

test_performance - use local .csv copy of module data rather than downloading each time from SAM

Just a quick comment -- pvlib ships with a copy of the CEC database, so pvlib.pvsystem.retrieve_sam(name='CECMod') technically only requires a local file read, not a network download.  However it's kind of big and not an instant read, so it may still be worth avoiding even if it doesn't save a network transfer:
In [5]: %time _ = pvlib.pvsystem.retrieve_sam(name='CECMod')
Wall time: 682 ms


Seems this repo can work in Python3.8 and pg12, pg13

My env is python3.8 and I notice that pg-lock-tracer can only run bigger than 3.9
so I clone and change the setup.cfg to python3.8 and it worked, also for pg12

I fork this repo and run actions for pg12 pg13 and python3.8 they all passed
you can track my passed test:  https://github.com/yihong0618/pg-lock-tracer/actions/runs/4029607444

Hello @yihong0618,
Thank you very much for your contribution. I will merge your PR in a few minutes. I have never tested the lock tracer with PostgreSQL 12 or 13. Feel free to open a PR that adds the PostgreSQL versions to the build matrix and the README.md file.
Best regards
Jan

@jnidzwetzki copy that will open another do that, thanks.


The base URL does not apply

⚠ Please verify that this question has NOT been raised before.

[X] I checked and didn't find similar issue

🛡 Security Policy

[X] I agree to have read this project Security Policy

📝 Describe your problem
I hope to access Kuma through the /uptime path. However, even though I have set the Base URL to xxx.com/uptime/ and configured Nginx to forward /uptime/ to localhost:3001, accessing /uptime still automatically redirects to /dashboard, which conflicts with other services.
📝 Error Message(s) or Log
No response
🐻 Uptime-Kuma Version
1.23.11
💻 Operating System and Arch
Ubuntu 20.04 x86
🌐 Browser
Microsoft Edge Version 114.0.1823.41 (Official build) (x86_64)
🖥 Deployment Environment

Runtime: Docker version 25.0.3, build 4debf41
Database: -
Filesystem used to store the database on: ext4
number of monitors: 0

That is currently not supported and not what said setting is used for.
The setting is used for setting the base path (in https://example.com/status/abc this would be https://example.com)
See this issue:

https://github.com/louislam/uptime-kuma/issues/147

If you need just a status page under a certain subdirectory, see https://github.com/louislam/uptime-kuma/wiki/Status-Page#custom-subdirectory--custom-html-on-status-pages instead


[Cosmos] remove session consistency limitation on client to more easily integrate CosmosDB Integrated Cache

It has been asked recently to fix one specific limitation that is present in the SDK, should be worked on when possible.
Limitation:
The Python SDK client uses session consistency regardless of the account level setting. This makes it tougher to use the integrated cache and can lead to unexpected behavior:

Integrated Cache using the default consistency level, that is "Session". To take advantage of the new Cosmos DB Integrated Cache, it is required to explicitly set CosmosClient consistency level to "Eventual": consistency_level= Eventual.

Closed with merge of this PR: https://github.com/Azure/azure-sdk-for-python/pull/22792


Advocating open BsReactNative and exporting generic names like "Types" could be a problem

FYI, I encountered a conflict with a generic name like "Types". Someone on discord told me I should raise the issue but not sure what to offer as an alternative :)
I made an upgrade to 0.5.0 to 0.6.0 and got issue like "Types.myTypes" is not found etc.
Any idea how we could avoid this generic names?

 That make me try weird things cause I renamed Types to T after adding a non working namespace (but atom was finding my namespace so it created an another layer of confusion). I simply fixed this by renaming my Types.re to T.re (not great I know).
If you are curious (but again pretty dumb diff at the end) https://github.com/MoOx/moox.io/pull/67

If it'd matter, I second this. For what's basically just insets and touchResponseHandlers, having Types which would conflict with application code, is detrimental IMHO.
Since the API encourages opening BsReactNative and it's quite cumbersome to work with local opens, or to have to type alias anything coming from the user application's Types otherwise, I believe that names like Data, Types, Utils, Helpers should be prefixed or even better not being a part of the interface at all.
I know this is the price to pay for opening modules, but more often than not this will be a source of errors.

I don't know. I don't use BsReactNative rn so I don't have a firm opinion but in general I like the module system precisely because you can have non-confusing generic names without the prefixes.

I guess nobody cares about this :)


Push appears to be hung, need some indication it is trying

/kind bug
What versions of software are you using?

I created a Spring component and tried to push it to a CRC instance that was short on memory. It failed the first time, so after adjusting memory I tried again:
>odo push

Validation
 ✓  Validating the devfile [176418ns]

Creating Kubernetes resources for component spring
 ✗  Waiting for component to start [5m]
 ✗  Failed to start component with name spring. Error: Failed to create the component: error while waiting for deployment rollout: timeout while waiting for spring deployment roll out

I increased CRC memory here, then tried again (below).
Actual behavior
>odo push
--- Four minute 'hang' before any output ---
 ✗  Failed to start component with name spring. Error: Failed to create the component: unable to get pod for component spring: error while waiting for pod component=spring: waited 4m0s but couldn't find running pod matching selector: 'component=spring'

Expected behavior
Because there was no command line output for 4 minutes, I thought odo had hung. Suggestion: odo push should always output at least one line before any 'remote' or possibly delayed operation.
e.g. even if it output
>odo push
Creating Kubernetes resources for component spring

I would likely know that it is trying to do something with the cluster and not 'it hung immediately'.

/lifecycle frozen

/lifecycle frozen

Closing this one, I assume this is no longer an issue in odo v3
/close


Deploying the example site

I just spent a LOT of time trying to figure out how to deploy this but also keep the dev experience friendly.
I think the answer will be setting up a Yarn Workspace. If anyone has any ideas on a convenient way to host the example feel free to chime in.
What I plan on doing is making a workspace that will help us to continue using the local package that is use-stripe-cart while we work on it but also allow us to maintain an npm published version.
Right now the issues I'm facing with deployment are keeping this example package nested and being able to get it hosted properly on netlify

An easy way to host the example might be to use codesandbox.io as it's easy to make changes to and make a copy and edit for people who want to try out use-stripe-cart. You can link a CodeSandbox page to a GitHub repo so that when you update the repo the sandbox updates. 👍
As for deploying the package, I would suggest using a branch specifically for deployment. You can also do releases on that branch and have them trigger a GitHub Action that publishes the package.

@ChrisBrownie55
oh wow! I love all of that.
So maybe I'll make a release branch and work on a code sandbox from there. Does that make sense?
I haven't made a github action yet, I'll look into that as well

I'm actually going to launch on netlify as well just to make sure we have the ability to support Serverless #33


Any way of set up of how many messages the receiver wants to process in parallel?

Sample: receiveMessagesStreaming.js
I want to simulate some work on each received message for 2 sec
const onMessageHandler = async (brokeredMessage) => {
await delay(2000);
await brokeredMessage.complete();
};
And expected each new message coming from the queue only after brokeredMessage.complete() occurs (every 2 sec in this example).
But all messages coming at the same time even I set maxConcurrentMessages to 1.
receiver.receive(onMessageHandler, onErrorHandler, { autoComplete: false, maxConcurrentMessages: 1 });
Is it any way to achieve this behavior (kind of prefetch of RabbitMQ)? .Net client has MaxConcurrentCalls option.

Thanks for reporting @igrek2000!
I have a PR out to support your scenario, we will let you know once the changes make it in.

@igrek2000 If you have been using the Service Bus library from source, then the master branch now has the fix such that by default, only 1 message will be processed at a time. You can control this using the maxConcurrentCalls option passed to the receive function.
If you have been using this library from npm, then you will have to wait for a week or 2 until we release the next preview version.
Thanks again for reporting!


fix #44

The issue or feature being addressed

#44

Details on the issue fix or feature implementation

just removed the unnecessary import from the csproj

Confirm the following

[X] I have ensured that I have merged the latest changes from the dev branch
[X] I have successfully run a local build
[X] I have included unit tests for the issue/feature
[X] I have included the github issue number in my commits

Made obsolete by  #47


patch_environment does not revert previously existing keys

System Info
does not matter here

Information

[ ] The official example scripts
[ ] My own modified scripts

Tasks

[ ] One of the scripts in the examples/ folder of Accelerate or an officially supported no_trainer script in the examples folder of the transformers repo (such as run_no_trainer_glue.py)
[ ] My own task or dataset (give details below)

Reproduction
os.environ["FOO"] = "BAR"
with patch_environment(FOO="BAZ"):
     assert os.environ["FOO"] == "BAZ"
assert os.environ["F00"] == "BAR"  # KeyError

Expected behavior
After leaving the context, the initial environment variables should be restored.
I noticed this while going through the code. If this is an issue, LMK and I'll provide a fix + tests. If, in the context that this function is used, it's not a problem, feel free to close the issue.

cc @muellerzr


Add basic syntax highlighting for WAI to the WebAssembly extension

Steps to implement:

[ ] Configure the VSCode-WASM as syntax highlighter for WAI
[ ] Develop a TexMate Grammar for WAI

Implemented in #51 and #46.


Update README.md with helpful note for TS users leveraging fileExtensions

Also, I would love a version bump 🙏

@kylemh  Done :) I also fixed a small bug with fileExtensions option in this commit:
https://github.com/twopluszero/next-images/commit/cebcd24fd250b839577b95f4f3158a0085c96228

🤦♂  nice save!
I mistakenly say the first assignment of fileExtensions as within a destructured object! I wonder why my editor never complained 🤔

@kylemh No worries, it works perfectly now 👍


lang in url (with sveltekit)

Hi, thanks for this library!
I'm trying to use it with sveltekit. I have a path like /[lang]/about. Because I want to use i18n on all pages, and initialize it only once, I do so in /[lang]/+layout.svelte. How do I then access the i18n store in /[lang]/about/+page.svelte?

I found that isLoading doesn't get updated (even though I used it as $isLoading).
Also, I tried moving all the functionality to $lib/i18n.ts or even .svelte, but that definitely doesn't work (with error failed to load module for ssr: /src/lib/i18n).

FYI: It get language auto-detection to work from url using detection: { order: [path]  },


Your test suite must contain at least one test

node -v: 12.16.1
npm -v: 6.14.5

I am getting below error when I try to npm test on v1.10.0
bash-4.2# npm test

<EMAIL_ADDRESS>test /wkc-test-fails/yaml
jest

PASS  tests/cst/corner-cases.js
PASS  tests/doc/comments.js
PASS  tests/doc/types.js
PASS  tests/doc/parse.js
PASS  tests/doc/YAML-1.2.spec.js
PASS  tests/doc/stringify.js
PASS  tests/doc/errors.js
PASS  tests/doc/anchors.js
PASS  tests/doc/foldFlowLines.js
PASS  tests/doc/collection-access.js
PASS  tests/doc/createNode.js
PASS  tests/properties.js
PASS  tests/doc/YAML-1.1.spec.js
PASS  tests/cst/YAML-1.2.spec.js
PASS  tests/cst/parse.js
PASS  tests/cst/source-utils.js
PASS  tests/cst/set-value.js
PASS  tests/cst/Node.js
FAIL  tests/yaml-test-suite.js
● Test suite failed to run
Your test suite must contain at least one test.

  at onResult (node_modules/@jest/core/build/TestScheduler.js:173:18)
      at async Promise.all (index 18)
  at async TestScheduler.scheduleTests (node_modules/@jest/core/build/TestScheduler.js:271:11)
  at async runJest (node_modules/@jest/core/build/runJest.js:372:19)
  at async _run (node_modules/@jest/core/build/cli/index.js:364:7)
  at async runCLI (node_modules/@jest/core/build/cli/index.js:219:3)

Test Suites: 1 failed, 18 passed, 19 total
Tests:       10 skipped, 720 passed, 730 total
Any idea about this?

Some of the tests are in a git submodule. Run this to get it set up:
git submodule update --init

@eemeli Thanks! Resolved!


[All hosts](community call agenda)

Add Outlook agenda item.

Docs Build status updates of commit 471fd82:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/overview/office-add-ins-community-call.md
:white_check_mark:Succeeded
View

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


Build/Release request

@xaksis
2 new features and 1 bug fix have been merged to master:

https://github.com/xaksis/vue-good-table/pull/587 - Add multiselect filter
https://github.com/xaksis/vue-good-table/pull/641 - Collapsable groups
https://github.com/xaksis/vue-good-table/pull/666 - Async column styling

Can you do a build/release to npm?

done!


API_keys issues - mixing CLINE set API keys with Project keys from .env file

Which API Provider are you using?
OpenAI
Which Model are you using?
gpt-4o
What happened?
Spent a long time on it and am furious but found out that after many, and I mean many hours, I'm an amateur and it took me long time to find out that the continuous problems with an openai key in my project were not working, going back and forth to OpenAi to verify the correctness, resetting it, createing new one did not solve the problem till I found out that CLINE was mixing up the key as set in the settings of CLINE itself with the key I wanted to use in my project in VSC. BAD BAD BAD and expensive exercise!
Steps to reproduce

Work with OpenAI in your project with use of OpenAI key
Set the variable for this key in your project folder's .env file
Also set the OpenAI key to use OpenAI in CLINE with a different API KEy from OPEN AI
ANd find out......

Relevant API REQUEST output
No response
Additional context
No response

After I thought it was solved, a little further a few new chats later, a new start of vsc, I am again experiencing the same nonsense, this is bad CLINE! Very bad, as said before, it could be because I do not understand enough due to my lack of experience but I think it is stupid that the api key entered into cline is being mixed up with the key in my project. this is unexcusable !!! You haven't got a clue how much time this cost me, you haven't got a clue how much tokens this has cost me over the last few days. CLINE is stupid in this way, I am extra dissapointed because with the new Haiku it was working perfect and I was a happy guy but now with this nonsense I am very dissapointed, surely i am not the only one experiencing this, could be but for the moment I refuse to even think that, I'm fulll of frustrations on this matter, shame on you!~

Can you please describe your issue clearer? I am having a hard time understanding the full scope of the problem.


A few issues with README:

Hyperlink on png is broken.
looks like there is the README isn't updated or the link to the zip file points to an older version:
2.1. The emoji folder doesn't contain the todo_pause png.
2.2 There is no high folder.

Thanks! I'll get on it

https://github.com/davestewart/todo-emojis/pull/6

Closed by #6


NullreferenceException

Since a few days I get a NullReferenceException in the News window :
An exception was encountered while constructing the content of this frame.  This information is also logged in "C:\Users\jens.SALAR\AppData\Roaming\Microsoft\VisualStudio\17.0_06c96b1a\ActivityLog.xml".
Exception details:
System.NullReferenceException: Object reference not set to an instance of an object.
at DevNews.FeedOrchestrator.d__7.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedOrchestrator.cs:line 74
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DevNews.FeedOrchestrator.d__5.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedOrchestrator.cs:line 52
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DevNews.FeedStore.d__6.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedStore.cs:line 33
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at DevNews.DeveloperNewsPackage.d__7.MoveNext() in C:\projects\developernews\src\DeveloperNews\DeveloperNewsPackage.cs:line 61
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.VisualStudio.Shell.AsyncPackage.<>c__DisplayClass33_0.<b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)
at Microsoft.VisualStudio.Shell.VsTaskLibraryHelper.<>c__DisplayClass54_0.<b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)
at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame.d__150.MoveNext()

Have the same problem, then i closed the tab, if i click again VIEW -> Devoloper News nothing happens

Yep same here ... very annoying since I really like that feature to keep me uptodate ....

Here's another stack trace:
Exception details:
System.NullReferenceException: Object reference not set to an instance of an object.
   at DevNews.FeedOrchestrator. <CreateNewCombinedFeedAsync>d__7.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedOrchestrator.cs:line 74
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at DevNews.FeedOrchestrator. <GetFeedAsync>d__5.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedOrchestrator.cs:line 52
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at DevNews.FeedStore. <GetFeedAsync>d__6.MoveNext() in C:\projects\developernews\src\DeveloperNews\Feeds\FeedStore.cs:line 33
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at DevNews.DeveloperNewsPackage. <InitializeToolWindowAsync>d__7.MoveNext() in C:\projects\developernews\src\DeveloperNews\DeveloperNewsPackage.cs:line 61
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Shell.AsyncPackage.<>c__DisplayClass33_0. <<Microsoft-VisualStudio-Shell-Interop-IVsAsyncToolWindowFactory-InitializeToolWindowAsync>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
   at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)
   at Microsoft.VisualStudio.Shell.VsTaskLibraryHelper.<>c__DisplayClass54_0. <<CancelWhenCancellationRequested>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
   at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)
   at Microsoft.VisualStudio.Platform.WindowManagement.WindowFrame. <CreateToolWindowAsync>d__146.MoveNext()


fix #131: Concurrency issue with CheckRedirect of DefaultClient

@vvelikodny thx for contributing. Have you run the tests before sending the PR?

@marcosnils didn't sorry, I see issues, going to fix it.

@marcosnils all test passed now, let me know what do you think, thanks!

@vvelikodny thx for the update. Is there a chan e you can add a new test for the bug you're fixing? This way we prevent future issues with this functionality

@marcosnils ok, cure, I will add new test to cover it.


Exception in __html__ method causes segfault when autoescaping

The following code fails with a segmentation fault:
from jinja2 import Template

class Test:
    def __html__(self):
        assert False

test = Test()
template = Template('{{ test }}', autoescape=True)
print(template.render(test=test))

Expected Behavior
Running the code completes in some way (either by successfully rendering something or raising the error).
Actual Behavior
The interpreter crashes with a segmentation fault
More Details
This seems to be related in some way to a combination of autoescape=True on the template, and the error being in the __html__ method. In particular:

If I change to autoescape=False in the above example, then the repr of the test object is printed successfully
If I move the error into a __str__ method rather than a __html__ method (with autoescape=True) the assertion error is propagated to the terminal

Not really sure where the bug lies here, but I am guessing it is in the compiled template code. Running with -X faulthandler gives:
Fatal Python error: Segmentation fault

Current thread 0x00007fd45c000080 (most recent call first):
  File "<template>", line 11 in root
  File "/home/james/.local/share/virtualenvs/web-findings-dozQMylR/lib/python3.6/site-packages/jinja2/environment.py", line 1005 in render
  File "/home/james/.local/share/virtualenvs/web-findings-dozQMylR/lib/python3.6/site-packages/jinja2/asyncsupport.py", line 76 in render
  File "test.py", line 10 in <module>

Is there a way to view the compiled template code?
Your Environment

Python version: 3.6.7
Jinja version: 2.10

if python segfaults it might be a bug in markupsafe

Just realized I forgot to say in the above: the example is obviously stupid, but this actually occurred when trying to render a WTForms form that had a broken custom field widget in a flask app - I don't think that jinja2 should be able to handle errors in __html__ methods but it would be helpful to get the stacktrace.

It appears that it is Markupsafe that is at fault. Just running jinja2.runtime.escape(test) also segfaults.
Looks like this has already been reported: https://github.com/pallets/markupsafe/issues/108 so I'll code this


DNS woes with Debian Bookworm

🐛 Summary
@mcdonnnj has reported DNS woes when using a Debian Bookworm base AMI.  He says that DNS resolution requires the FQDN (e.g., kali1.envX.cool.cyber.dhs.gov); simply using the hostname (e.g., kali1) does not work.
The reason for the difference appears to be that Bookworm uses systemd-resolved whereas previous Debian releases used resolvconf.
To reproduce

Build a new COOL AMI from a Debian Bookworm base AMI.
Deploy the new COOL AMI along with an old, Bullseye-based COOL AMI into a COOL environment.
Observe that, in the instance based on the new COOL AMI, DNS fails to resolve without using the FQDN; but, DNS does resolve in the instance based on the old AMI without the FQDN.

Expected behavior
The DNS behavior should remain the same, regardless of whether systemd-resolved or resolvconf is used.

Please note I ran into issues while testing Debian Bookworm with the images used in the CyHy environment. I have not done any testing with Bookworm images used in a COOL assessment environment or similar.

I have identified the source of the problem.  I'd prefer to modify the netplan configuration to ensure that the correct systemd-networkd configuration files are created, but it may be necessary to edit the latter directly after they are created.

See this branch, which together with this branch demonstrates and fixes the problem.  A Debian Desktop instance created via these branches has been deployed to the COOL staging environment env6 if anyone from @cisagov/team-ois wants to inspect it.
@mcdonnnj - Can you make similar changes in CyHy and verify that you can safely move to Bookworm now?  If so then I'd like to do a mini-Kraken that includes cisagov/skeleton-packer#242.

I suspect this was already an issue for our Kali instances, but we didn't notice because they don't rely on getting search domains from DHCP; however, our Guacamole instance may rely on such functionality.  We certainly rely on it in CyHy.

I suspect this was already an issue for our Kali instances, but we didn't notice because they don't rely on getting search domains from DHCP; however, our Guacamole instance may rely on such functionality. We certainly rely on it in CyHy.

This is not the case after all.  Kali does not use Netplan.

After copying the changes in #242 I verified functionality in my testing deployment of the CyHy environment. I confirmed that the cyhy-commander was able to push work and retrieve results. I also verified that I was able to access all of the instances as expected:
$ for host in bastion vulnscan1 portscan1 portscan2 portscan3 portscan4; do ssh "$host".mcdonnnj.cyhy "hostname; lsb_release -d"; done
bastion
Description:	Debian GNU/Linux 12 (bookworm)
vulnscan1
Description:	Debian GNU/Linux 12 (bookworm)
portscan1
Description:	Debian GNU/Linux 12 (bookworm)
portscan2
Description:	Debian GNU/Linux 12 (bookworm)
portscan3
Description:	Debian GNU/Linux 12 (bookworm)
portscan4
Description:	Debian GNU/Linux 12 (bookworm)
$ for host in bastion docker; do ssh "$host".mcdonnnj.bod "hostname; lsb_release -d"; done
bastion
Description:	Debian GNU/Linux 12 (bookworm)
docker
Description:	Debian GNU/Linux 12 (bookworm)

Please see https://github.com/cisagov/cyhy_amis/pull/746.

There are still some PRs around this issue that need to be merged before it can be closed.

There are still one more PR around this issue that needs to be merged before it can be closed.


ShellPipe must not loose exit code if a script ends prematurely

I added a little improvement in ShellPipe operator. When the command ends prematurely, then the exit code is now logged in ERROR level.
I also added some tests for that in the ShellPipeSample.
I think the toolkit.xml files should be ignored by git.

I also added two things:
ShellSource: If the shell command exits with a non zero error code, the pe is aborted
ShellPipe: abort the PE if the process exits prematurely

@ejpring can you please review the pull request ?  Thanks!


Poll for incoming blocks and auto-inspect them

What's this

Adds a script run.py which on start of the container starts polling for blocks it hasn't processed yet and inspects them
breaks inspect_block's logic from the script into its own module
Checkpoints the latest processed block in the latest_block_update table

Reading Roadmap
You can ignore the tilt_modules - those are just locked dependencies
Start with run.py and work your way down

Getting some merge conflicts here!


Fails to Authenticate with TinyTinyRSS

Newsboat version (copy from newsboat -v):
newsboat 2.10.1 - https://newsboat.org/
Copyright (C) 2006-2015 Andreas Krennmair
Copyright (C) 2015-2017 Alexander Batischev
Copyright (C) 2006-2017 Newsbeuter contributors
Copyright (C) 2017 Newsboat contributors

newsboat is free software and licensed under the MIT/X Consortium License.
Type `newsboat -vv' for more information.

newsboat 2.10.1
System: Linux 4.13.9-1-ARCH (x86_64)
Compiler: g++ 7.2.0
ncurses: ncurses 6.0.20170902 (compiled with 6.0)
libcurl: libcurl/7.56.0 OpenSSL/1.1.0f zlib/1.2.11 libpsl/0.18.0 (+libicu/59.1) libssh2/1.8.0 nghttp2/1.23.1 (compiled with 7.56.0)
SQLite: 3.20.1 (compiled with 3.20.1)
libxml2: compiled with 2.9.5
Steps to reproduce the issue:

Added to .newsboat/config:

# Tiny Tiney RSS Config
# ---------------------

ssl-verifyhost      "no"
urls-source         "ttrss"
ttrss-url           "https://TTRSS_URL"
ttrss-login         "`lpass show --username ttrss_reader`"
#ttrss-password      "`lpass show --password ttrss_reader`"
ttrss-passwordeval      "lpass show --password ttrss_reader"
ttrss-flag-star     "s"
ttrss-flag-publish  "p"

Run: newsboat

Other info you think is relevant:
Encountering the issue on two different Arch Linux systems.
Newsboat returns to the console:
Starting newsboat 2.10.1...
Loading configuration...done.
Opening cache...done.
Loading URLs from Tiny Tiny RSS...Authentication failed.

Used newsboat -l 6 -d debug.log to get errors.  Last 4 lines of the log show:
[2017-10-27 22:22:39] DEBUG: cache::clean_old_articles, days == 0, not cleaning up anything
[2017-10-27 22:22:39] DEBUG: utils::retrieve_url(https://TTRSS_URL/api/)[ЧײV]:
[2017-10-27 22:22:39] DEBUG: ttrss_api::run_op(login,...): post={"op":"login","sid":"","password":"PASSWORD","user":"USERNAME"} reply =
[2017-10-27 22:22:39] ERROR: ttrss_api::run_op: reply failed to parse:
[2017-10-27 22:22:39] DEBUG: utils::remove_fs_lock: removed lockfile /home/kamikazejoe/.newsboat/cache.db.lock

Note the [ЧײV]: at the end of the second line.
The same configuration works fine on the last version of Newsbeuter.  It looks like the utils::retrieve_url line is getting cut off.
Equivalent Newsbeuter debug lines below:
[2017-10-28 14:32:46] DEBUG: cache::clean_old_articles, days == 0, not cleaning up anything
[2017-10-28 14:32:48] DEBUG: utils::retrieve_url(https://TTRSS_URL/api/)[{"op":"login","sid":"","password":"PASSWORD","user":"USERNAME"}]: {"seq":0,"status":0,"content":{"session_id":"c82ca9da8eac82b3834909ada3da90ca","api_level":14}}
[2017-10-28 14:32:48] DEBUG: ttrss_api::run_op(login,...): post={"op":"login","sid":"","password":"PASSWORD","user":"USERNAME"} reply = {"seq":0,"status":0,"content":{"session_id":"c82ca9da8eac82b3834909ada3da90ca","api_level":14}}
[2017-10-28 14:32:48] DEBUG: ttrss_api::retrieve_sid: sid = 'c82ca9da8eac82b3834909ada3da90ca'

Thanks for the report!

Note the [Чײ�V]: at the end of the second line.

That was a bug in the formatting function, I just fixed it in the repo. The request itself should've been correct (and it was, judging by the "run_op" line in the log).
Try setting ssl-verifypeer to no (that's what Newsbeuter 2.9 did). Double-check the URL, just in case. if neither of those doesn't help, please tell me what version of Newsbeuter you're running so I can look at the diff between it and Newsboat and get some new ideas to test.

I found this bug report when the same issue happened for me. setting ssl-verifypeer to no allowed me to authenticate against my ttrss instance.

The ssl-verifypeer workaround worked for me as well.

Cool! I'll close the issue then.


Add back the ability to create Addresses from bytes arrays

Not having the ability to create Addresses from an array makes it a bit tricky to check matches in events later on.
e.g.
#![cfg(test)]

use alloc::vec;
use std::println;

extern crate alloc;
extern crate std;

use crate::{Contract, ContractClient};
use soroban_sdk::{symbol_short, testutils::Logs, Address, Env, String};

#[test]
fn test() {
    let env = Env::default();

    // StrKey.encodeContract(Buffer.from('0808080808080808080808080808080808080808080808080808080808080808', 'hex'))
    let contract_address = Address::from_string(&String::from_str(&env, "CAEAQCAIBAEAQCAIBAEAQCAIBAEAQCAIBAEAQCAIBAEAQCAIBAEAQMCJ"));
    let contract_id = env.register_contract(&contract_address, Contract);
    let client = ContractClient::new(&env, &contract_id);

    client.run(&Some(symbol_short!("Aratta")), &None);

    let logs = env.logs().all();

    assert_eq!(logs.len(), 0);

    client.run(&Some(symbol_short!("NotAratta")), &None);

    let logs = env.logs().all();

    println!("{}", logs.join("\n"));

    assert_eq!(logs, vec!["[Diagnostic Event] contract:0808080808080808080808080808080808080808080808080808080808080808, topics:[log], data:\"Aratta\""]);
}

Discord context
https://discord.com/channels/897514728459468821/1183815654487363584

The issue here has that diagnostic events shouldn't output addresses as hex. There's an issue open for this:

https://github.com/stellar/rs-soroban-env/issues/1049

I think we should resolve that issue rather than add from byte arrays back.

In the next protocol release and matching sdk release all cases that hex addresses were outputted have been replaced with C strkey addresses. So I think we should close this issue and not add more exposure of hex forms back. Please reopen if this is an incorrect approach.


Improve the REFERENCE_SERVER_CONFIG import mechanism

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
paymentservice.stellar, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.

What
Currently, the REFERENCE_SERVER_CONFIG (previously REFERENCE_CONFIG) is read from the environment. If it does not exist, the application won't start. This is to improve the import mechanism.
Why
N/A
Known limitations
N/A

Reference Server Preview is available here:https://anchor-ref-pr201.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr201.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr201.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr201.previews.kube001.services.stellar-ops.com/

Reference Server Preview is available here:https://anchor-ref-pr201.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr201.previews.kube001.services.stellar-ops.com/


Change exclude_self parm to include_self

What was wrong?
Negative bool flags lead to double negative checks
that are more error prone, like: if not exclude_self
How was it fixed?
Changed exclude_self param that defaulted to False to include_self param that defaults to True.
Cute Animal Picture

I'm holding off releasing 0.14.0 to get that last bit in to avoid this becoming a breaking change with the next release.


Editor Custom Labels Glob Not Escaping Properly

Type: Bug
I'm trying to create a pattern for the Workbench > Editor > Custom Labels setting that matches any file named [...slug].astro, but I can't properly escape the brackets. If I provide a pattern like **/\[...slug\].astro,, then the title doesn't change, but if I change it to **/*.astro, it works as expected.
I did some digging but could not find any other issues reported like this, and I can't figure out what is going wrong.
I should note, I'm submitting this from the Insiders build as I only have the Astro extension installed there so it serves as a good test bed. I originally found the issue in the 1.89 build, with the following details:
Version: 1.89.1
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:16:23.416Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Linux x64 6.8.0-76060800daily20240311-generic

The content following the separator was auto-provided when I submitted this issue via the Report Issue feature within VSCode.

VS Code version: Code - Insiders 1.90.0-insider (405ce83a24f38fd70751b03438763a1503329fe0, 2024-05-20T23:11:31.993Z)
OS version: Linux x64 6.8.0-76060800daily20240311-generic
Modes:

System Info

Item
Value

CPUs
AMD Ryzen 9 7950X 16-Core Processor (32 x 5289)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
1, 2, 2

Memory (System)
125.01GB (62.16GB free)

Process Argv

Screen Reader
no

VM
0%

DESKTOP_SESSION
pop

XDG_CURRENT_DESKTOP
Unity

XDG_SESSION_DESKTOP
pop

XDG_SESSION_TYPE
x11

Extensions (1)

Extension
Author (truncated)
Version

astro-vscode
ast
2.10.2

A/B Experiments
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
tftest:31042121
vscod805:30301674
vsaa593cf:30376535
py29gd2263:31024238
c4g48928:30535728
2i9eh265:30646982
962ge761:30841072
pythongtdpath:30726887
welcomedialog:30812478
pythonidxpt:30768918
pythonnoceb:30776497
asynctok:30898717
dsvsc013:30777762
dsvsc014:30777825
dsvsc015:30821418
pythontestfixt:30866404
pythonregdiag2:30926734
pythonmypyd1:30859725
pythoncet0:30859736
h48ei257:31000450
pythontbext0:30879054
accentitlementst:30870582
dsvsc016:30879898
dsvsc017:30880771
dsvsc018:30880772
cppperfnew:30980852
pythonait:30973460
showvideot:31016890
chatpanelt:31014475
bdiig495:31013172
a69g1124:31018687
dvdeprecation:31040973
pythonprt:31036556
dwnewjupytercf:31046870
26j00206:31048877

In case it helps, here is a copy of the relevant setting in my stable version of VSCode that shows the ways I was trying this without any success:
"workbench.editor.customLabels.patterns": {
  "**/[...slug].astro": "${dirname}",
  "**/\[...slug\].astro": "${dirname}", // This isn't technically a valid JSON string but I tried it anyway
  "**/\\[...slug\\].astro": "${dirname}",
  "**/\\\\[...slug\\\\].astro": "${dirname}"
}

Here is the documentation of supported syntax for glob patterns: https://code.visualstudio.com/docs/editor/glob-patterns
We do not support the escape character \ due to performance issues
You'll have to come up with a different pattern. For example **/?...slug?.astro could work.


Modified CLK token icon #14550

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] question about the decisions made in the repository
[ ] question about how to use this project

Summary

Need to change CLK token icon in PR #14550

Other information (e.g. detailed explanation, stack traces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

merged


Help with understanding the example

Hi. I believe I can understand the query except for "group newGroup2 by newGroup1.Key;".
I'd find it helpful if the example adds a few sentences to explain why or how newGroup2 can be grouped by newGroup1.Key .
I see each newGroup2 contains the students from a certain year grouped by last name, but I don't get how newGroup1.Key is available to be used as key to group the newGroups2.

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

ID: 728b8960-bd9b-6e47-0697-1ede60319dcc
Version Independent ID: f2080e9b-3a61-ec89-eb34-b61aff1641fa
Content: Create a nested group (LINQ in C#)
Content Source: docs/csharp/linq/create-a-nested-group.md
Product: dotnet-csharp
GitHub Login: @BillWagner
Microsoft Alias: wiwagn

Good luck getting a response.


Add sanitizer coverage feedback evolution support part2

Overview
This a follow up for #44. Clang's sancov data parsing component has been upgraded with runtime coverage bitmaps aiming to identify newly discovered execution paths. Initial sancov feedback parsing was relying solely on maximum global coverage counters for seeds evolution without considering newly discovered basic blocks that don't improve global counters. This PR is introducing a series of upgrades into that direction by implementing fundamental sancov runtime data parsing procedures & book keeping runtime structures.
Following paragraphs provide an executive summary of involved commits. Additional, details are available at each commit's description and accompanied source code comments.
SanCov upgrades
Supported methods
Clang sanitizers' coverage data can be exported with two methods based on environment variable flags:

As individual files per instrumented executable/DSO
Unified into a single raw packed file

Both methods are supported from sancov parsing component, although the later is preferred for performance (reduce File I/O & discovery logic) and efficiency (if sanitizer unhandled signal, such as SIGKILL, raised coverage data are lost - huge problem for Android) reasons. It should be also noted that coverage bitmaps are supported only for the later due to huge performance overhead when parsing data produced with first method. As such, when individual files are selected (coverage_direct flag disabled) only global coverage counters are supported without using BB bitmaps.
Parsing coverage data
When sanitizer coverage is enabled, compiler is injecting a call for the __sanitizer_cov procedure at every basic block identified. Runtime collected coverage data are then stored into generated files from __sanitizer_cov_dump procedure invoked as part of sanitizer's Die steps. Detected hit BB addresses are absolute, thus they need to be adjusted to relative before updating fuzzer's coverage bitmaps (that randomization bits again). This is accomplished by parsing the pid.sancov.map file which contains a minimized version of ProcFS maps that can be used to calculate BB relative addresses using matching map's base address.
When coverage feedback is enabled with raw unpack method, a digital tree (trie) is generated whenever a new input seed is selected for evolution. Loaded executable/DSO map names (as parsed from pid.sancov.map) are used as keys for the trie node actions (insert, search). Additionally, for each node where the matching exec/DSO has coverage instrumentation enabled, a coverage bitmap is allocated and maintained in parallel with trie lifetime. Trie and bitmaps are shared across the fuzzer threads, with each thread (roughly) executing the following steps when parsing coverage data:

Parse pid.sancov.map file
Identify PC register size (required for raw file unpack offsets calculation)
Parse map entries and cache them in memory
Update global trie if new exec/DSO detected
Parse pid.sancov.raw file
Unpack BB absoute addressess
Find matching map entry from cached maps file
Calculate relative address from map's base address
Find matching trie node using map name as search key
Check node's coverage bitmap if BB address has been hit before
If new hit update bitmap and associated counters
Update thread's summary counters (coverage summary, instrumented #DSOs, etc.)
Delete matching pid sancov files

Parsing component takes advantage of addresses locality (next BB addr most probably fits into same map entry) to minimize search overhead by caching last used map entry & trie node. Additionally, a small sorted lookup array of maps' base addresses is generated to speed up the maps index search step when parsing raw files.
Interaction with global data structures is mutex protected to avoid races. Bitmap updates occur in a first-come-first-serve nature ensuring that new BB hits are measured only once from actively running workers.
Evolution metrics
For evolution decisions (discard/keep mutated test cases) fuzz_sanCovFeedback is evaluating worker thread's coverage based on:

Newly discovered (not met before) BBs && total hit BBs not significantly dropped
Improved maximum coverage (total BB hits improved)
Additional instrumented DSOs loaded (dlopen() paths discovered)

For rule 1. the second part of the expression has been temporarily introduced until test case queues are implemented. Currently honggfuzz is using absolute elitism, promoting only one test case (the best) to next iterations. In that case if newly discovered paths are blindly followed without considering global coverage metrics, there's a higher propability that fuzzer enters a dead-end state where target always early aborts. This is a very common case for media decoders/parsers where a potentially malformed chunk triggers additional evaluation/error-handling exec paths, which effectively results into new BB hits. However, such exec path is most probably triggering an early abort call due to malformed data trapping the fuzzer into a dead-end that might never escape until initial seed is replaced due to expiration. When evolution seed queues are implemented previous metrics will be revised.
First execution of new seed selection
The 1st iteration of a newly selected seed from input corpus is perfomed without any content mangling taking place. This will effectively set the initial coverage data with base metrics required to compare against at following evolution. Additionally, to avoid races between worker threads that might result into inaccurate base data creation, only one thread is executing this first round blocking the other threads from continuing before all initial data structures updates are completed.
SanCov display sample
============================== STAT ==============================
Iterations: 9700
Start time: 2016-01-13 03:02:56 (6926 seconds elapsed)
Input file/dir: 'seeds'
Fuzzed cmd: 'target'
Fuzzing threads: 2
Execs per second: 2 (avg: 1)
Crashes: 7165 (unique: 2, blacklist: 590, verified: 2)
Timeouts: 97
Dynamic file size: 59100 (max: 10485760)
Dynamic file max iterations keep for chosen seed (22/512)
Coverage (max):
  - total hit #bb:  6990 (coverage 8%)
  - total #dso:     5 (instrumented only)
  - discovered #bb: 1246 (new from input seed)
  - crashes:        0
============================== LOGS ==============================
[I][31688] fuzz_sanCovFeedback():480 SanCov Update: file size (Cur,New): 59090,59090, newBBs:22, counters (Cur,New): 6987/5,6990/5

Linux: fuzzing with sanitizers
exitcode/SIGABRT monitoring
A common practise when fuzzing with sanitizers enabled for target application, is to set the abort_or_error flag. This will effectively result into a SIGABRT being raised when sanitizer detects an error. If SIGABRT is a monitored signal from fuzzer's ptrace API, crash detection logic will identify the interesting signal and proceed with unwinding & post crash actions.
For some targets SIGABRT monitoring is not desired resulting into abort_or_error flag being useless since some detected errors might get lost. In these case a custom exitcode is registered and monitored per enabled sanitizer (ASan, MSan, UBSan). If ptrace API detects a PID exit with monitored exitcodes, additional crash processing actions are triggered that parse the sanitizer saved report file. linux/arch.c initialization routines detect if SIGABRT is a monitored signal based on common header config and adjust sanitizer flags and reports generation accordingly. Crash counters, uniqueness decissions (including blacklist) and crashes verifier actions have been updated to support for this new crash monitor method.
Additionally, for sanitizers that include unwinded stack traces into reports (such as ASan), crashing thread's trace is parsed to calculate stack hashes benefiting when detecting duplicates and verifying crashes behavior.
Since sanitizer flags are now defined dynamically based on input arguments, linux/arch.c init procedure is generating the appropriate flags once and stores them in global buffers that can be instantly accessed from worker threads when spawning new processes.
Number of major frames
Originally top 7 frames from call stack where used to calculate hash signature. When ASan fuzzing enabled and abort_or_error flag set, the top 6-9 frames are usually occupied with sanitizer internal procs, resulting into crashes being wrongly marked as duplicates and thus being lost. As such when these two conditions are met, arch init procedure is increasing the default 7 major frames to 14, mitigating the problem.
exitcode detected crash report sample
=====================================================================
FUZZER ARGS:
 flipRate     : 0.000500
 externalCmd  : NULL
 fuzzStdin    : FALSE
 timeout      : 30 (sec)
 ignoreAddr   : 0xff
 memoryLimit  : 0 (MiB)
 targetPid    : 0
 wordlistFile : NULL
 dynFileMethod: NONE
 fuzzTarget   : /system/bin/target -i ___FILE___
ORIG_FNAME: 32f4ea6b94720bf2ee7d7adca4228d25
FUZZ_FNAME: ./ASAN.PC.a999d5a3.STACK.1764a787cf.CODE.WRITE.ADDR.0xb29a6ee4.INSTR.[UNKNOWN].fuzz
PID: 20278
EXIT CODE: 104 (ASAN)
OPERATION: WRITE
FAULT ADDRESS: 0xb29a6ee4
STACK HASH:<PHONE_NUMBER>a787cf
STACK:
 <0xa999d5a3> [/system/lib/target2.so + 0xd35a]
 <0xa995a1cb> [/system/lib/target2.so + 0x901c]
 <0xa9a093e7> [/system/lib/target2.so + 0x13f3e]
 <0xa999bff3> [/system/lib/target2.so + 0xd1ff]
 <0xa98f34bf> [/system/lib/target2.so + 0x294b]
 <0xa990973f> [/system/lib/target2.so + 0x3f73]
 <0xa98ddc1f> [/system/lib/target2.so + 0x13c1]
 <0xb580bf7f> [/system/lib/target1.so + 0xb6f7]
 <0xb5819f37> [/system/lib/target1.so  + 0xc4f3]
 <0xb46e74c7> [/system/lib/target0.so  + 0x194c]
 <0xb470f84f> [/system/lib/target0.so + 0x4184]
 <0xb46f221b> [/system/lib/target0.so + 0x2421]
 <0xb59e0333> [/system/lib/libutils.so + 0x1033]
 <0xb5a36aa7> [/system/lib/libc.so + 0x49aa]
 <0xb5a06751> [/system/lib/libc.so + 0x1975]

Misc improvements

Fixed getdelim & getline memory leaks at files component (detected with valgrind)
Updated display messages with more accurate context for sancov data
Updated report writing with appropriate entries when crashes detected via exitcode and not raised signal
Comments upgrades/clean-ups
Check if target exec timeout is big enough to tollerate coverage overhead. Users should monitor for excessive #timeouts and adjust if required.
Enable compatibility with OSX indent
Remove dead helper static functions

Even the smallest comment that might have some performance improvement at sancov parsing or book keeping is super welcome. Evolution seed queues are in the todo list for the near future to get the best out of the coverage bitmaps.

Amazing work, thanks!


Maintenance release for 5.5

We need maintenance release for SLE Micro for Rancher 5.5 to include an elemental-toolkit binary with up to date former libraries. Also to align with harverster.
We also need to make an elemental-operator v1.4.x release to provide a fix for rancher/elemental-operator#629.
This will also be chance to prepare 5.5 project to be ready for continuous rebuilds (GA builds are build in snapshots, not continuous rebuilds) and also to stress polishing rough edges within the current 5.5 release for which the RPM repo structure needs to be fixed.

[ ] Prepare new submission including:

rancher/elemental-operator#629 rancher fix
sle micro OS with the latest elemental-toolkit v1.1.x
sle micro OS including #1258 fix
a rebuild of OS images including latest SLE Micro patches
A channel image including new image versions (should we also include an OS image for #1259 ?)
#1263 ??
Should it also include managedOSImage improvements? rancher/elemental-operator#660 and rancher/elemental-operator#658 NEEDS DISCUSSION

[ ] Test maintenance incident
[ ] Release binaries and release notes

We will not backport fixes but bump Elemental to 1.5 across operating systems.

Closing, release is out
marketplace release is already tracked in another issue rancher/elemental-operator#739


Better string handling

Right now Harlan programs can't do much more with strings than pass them around. Even just adding facilities to convert between C strings and vectors of chars would greatly improve the ability of Harlan programs to manipulate strings.

Cool... so how would I access the chars in a string in harlan?

There's a function, str->vec, which converts a string to a vector of characters. From there you can use vector-ref to access individual characters. For example:
(let ((v (str->vec "hello")))
  (vector-ref v 0))

That should return the character 'h'.

Cool.. will try that out when I get time.. I have twitter word analysis in mind.. but lets see how that can work.. :D

Sounds like fun!
I've been working on a PLY file loader lately which is forcing me to improve Harlan's string and IO facilities. Hopefully that will help you out too.