how can i get zipkin version from zipkin-ui?

how can i get zipkin version from zipkin-ui?
i update zipkin, but don't know how to get zipkin-ui version from web.

@dragontree101 Are you running Zipkin server (the self-contained executable jar zipkin.jar), or serving the zipkin-ui some other way?
Also to clarify your question, you want to know what the current version number of a running Zipkin instance is, or are you looking for something else?

i run newest version, use zipkin.jar  (zipkin-server-1.5.1-exec.jar),
i just want to get zipkin version from  web ui,  i have not found any version in web.

@dragontree101 thank you for the quick response! I understand what you're expecting and I don't think there is any way to get that information currently. We should be able to add it easily enough though. I will submit a pull request for review with a potential solution tomorrow or the next day.

@shakuzen thanks!


Added sample react farmer assistance web app to index.json

Added sample react farmer assistance web app to index.json
Description
I have added the name, description and gitUrl of my react farmer assistance web app in the index.json.

 Kindly check #1587.

Toma will review it!


Cross-build Scala 2.13 and 2.12, remove support 2.11

Motivation:
Use the library in Scala 2.13 project.
Modification:

Extract compiler flags
Remove Scala 2.11 support, because HTTP4s DSL is not published for 2.11
anymore.
Add Scala Collections Compat to cross-compile for 2.13 and 2.12.

Result:
in sbt both pass:
> + compile
> + test

Thank you!

Hi and thank you for the PR !
As said in another issue (we should make a disclaimer somewhere, sorry) we are on gitlab, this is mainly a mirror for visibility.
I created a PR on Gitlab, fixed the conflict and added you as a co-author if that is okay with you ?
https://gitlab.com/colisweb-open-source/scala/scala-opentracing/-/merge_requests/82

Repo has been updated,

Thanks @LitlBro! Sorry, I haven't seen that you prefer PRs at GitLab.


⚠ Bofrost.nl has degraded performance

In 64fead5, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 5139 ms

Resolved: Bofrost.nl performance has improved in 705824c.


Add option to disable automatic buffer conversion

I'm doing somethings that want typed arrays, and am experimenting with an option to allow typedarray buffers from filereader-stream.

Never mind! This was a bad idea.


Https

Hacktoberfest notes:

due to volume of submissions, we may not be able to review PRs that do not pass tests and do not have informative titles.
please read our contributing guidelines
be sure to check the output of Travis-CI for linter errors
if this is your first open source contribution, make sure it's not your last!

What does this PR do?
Add Resource
For resources
Description
Added how https work.
Why is this valuable (or not)?
it has a best explanation of how https work. the best part is it has interactive emojis(comic) with title so you might not get bored.
How do we know it's really free?
it is available free online everyone with internet access can view it
For book lists, is it a book? For course lists, is it a course? etc.
Checklist:

[x] Not a duplicate
[x] Included author(s) if appropriate
[x]  Lists are in alphabetical order
[x] Needed indications added (PDF, access notes, under construction)

be sure to check the output of Travis-CI for linter errors.
should probably go in the networking or security sections.
for clarity, I would render the title as "How HTTPS works" (A good example of library catalog style)

added to #5079


Increase indentation of log snippets

What does this PR do?

Fix indentation of YAML snippets in log_configuration.yaml.
Motivation

Prompted by https://github.com/DataDog/integrations-core/pull/7891/files#r557275622
Goal is to have these snippets align with the 1. and 2. items, instead of being at the regular left-hand side of the content area.
Take a look at the RethinkDB readme in prod: https://docs.datadoghq.com/integrations/rethinkdb
The logs snippets were dedented when adding docs specs: https://github.com/DataDog/integrations-core/pull/8355/files#diff-cc5366001ead2c6612aa8bc99ee3be2594b38d422259ae6e434a245788508c17L52-R63
Additional Notes

Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

Hmm, after syncing the result in the README is actually this:
2. Add this configuration block to your `rethinkdb.d/conf.yaml` file to start collecting your RethinkDB logs:

    ```yaml
logs:
  - type: file
    path: "<LOG_FILE_PATH>"
    source: rethinkdb
    service: "<SERVICE_NAME>"
\```

Which makes the rendering look like garbage…

I think it needs textwrap.dedent somewhere, or something.

Hmm, after syncing the result in the README is actually this:
2. Add this configuration block to your `rethinkdb.d/conf.yaml` file to start collecting your RethinkDB logs:

    ```yaml
logs:
  - type: file
    path: "<LOG_FILE_PATH>"
    source: rethinkdb
    service: "<SERVICE_NAME>"
\```

Which makes the rendering look like garbage…

I think it needs textwrap.dedent somewhere, or something.

I found what seems to be an ugly hack that works very well, using a custom string formatter to apply textwrap.indent onto a parameter. I'm not super happy of how specific this new code (basically addressing a single use case now, yet taking significant LOC), so happy to consider other ways to fix this… However the result is a properly aligned logs snippet:

I found what seems to be an ugly hack that works very well, using a custom string formatter to apply textwrap.indent onto a parameter. I'm not super happy of how specific this new code (basically addressing a single use case now, yet taking significant LOC), so happy to consider other ways to fix this… However the result is a properly aligned logs snippet:

Coolio. Thanks!

Coolio. Thanks!


Add method to get a list of LogFiles

As a user,
I want a method to retrieve a list of the logfiles from a gameserver,
so I can determine what to download.
Logs should be sorted by modified date.

fmt.Sprintf("%s/services/%v/gameservers/file_server/list?dir=/games/%s/noftp/dayzxb/config", s.BaseURI, svc.ID, svc.Username)


toPlainObject when nested object is null should serialise correctly

toPlainObject fails when serialising a value object containing a nested object, whose value is null.
I think we should check for null values and serialise them correctly

Oops sorry @PaulCampbell I merged a fix for this before seeing your PR! Thanks anyway, fix is released in v0.1.2


Alarms created for ApiGateway using monitorScope uses the default stage "prod" instead of the stage deployed

Version
v4.0.9
Steps and/or minimal code example to reproduce
Since the stacks created at my organizations are deployed to multiple environments (development, staging, production etc) and depending on the environment it exists in the stage in the ApiGateway is different. When I use monitorScope for apiGateway it is creating alarms for the stage prod (which appears to be the default when apiStage is not provided) instead of what I have in the ApiGateway that is deployed. I'm not seeing a way to specify apiStage when using monitorScope. Shouldn't that automatically deduce that when it uses Aspects or is there a way to specify it when using monitorScope that I missed?
Below is an example code that I use:
 monitoringFacade.monitorScope(this, {
        apiGateway: {
          props: {
              add5XXFaultRateAlarm: {
                Warning: {
                  maxErrorRate: 0.1,
                  datapointsToAlarm: 2,
                  treatMissingDataOverride: TreatMissingData.NOT_BREACHING,
                },
              },
              add4XXErrorRateAlarm: {
                Warning: {
                  maxErrorRate: 0.2,
                  datapointsToAlarm: 2,
                  treatMissingDataOverride: TreatMissingData.NOT_BREACHING,
                },
              },
          },
          enabled:  true,
        }
     }
   );

Expected behavior
The alarms that are created for ApiGateway when using monitorScope uses the stage that exists in ApiGateway based on the template. Alternatively, provide a way to override the default if there are challenges to made this deduction using aspects.
Actual behavior
The alarms are created for stage prod
Other details
No response

Here it does not add the apiStage using the deploymentStage information from the apiGateWay https://github.com/cdklabs/cdk-monitoring-constructs/blob/fbd348c4eaa2e406c86727359d88d1c70ae72d80/lib/facade/MonitoringAspect.ts#L108
And since it is not added the default prod from https://github.com/cdklabs/cdk-monitoring-constructs/blob/fbd348c4eaa2e406c86727359d88d1c70ae72d80/lib/monitoring/aws-apigateway/ApiGatewayMonitoring.ts#L114 gets used.
The code I'm pointing to above is 5.x of the cdk-monitoring constructs, but 4.x is probably similar. This results in the alarms created for the wrong deployment stage in my case when I use monitorScope.

This might need to be re-opened.  Following the notes here, I'm monitoring an APIGW and neither the dashboard title nor CW metrics reflect the configured stage name:
        restapi = apigateway.RestApi.from_rest_api_id(self, "RestApi",
            "nqfaopfeuk"
        )
        monitoring.monitor_api_gateway(api=restapi, api_stage='latest')

CloudWatch dashboard source (snippet)
"metrics": [
                    [ "AWS/ApiGateway", "Latency", "ApiName", "RestApi", "Stage", "prod", { "label": "P50 (avg: ${AVG})", "stat": "p50" } ],
                    [ "AWS/ApiGateway", "Latency", "ApiName", "RestApi", "Stage", "prod", { "label": "P90 (avg: ${AVG})", "stat": "p90" } ],
                    [ "AWS/ApiGateway", "Latency", "ApiName", "RestApi", "Stage", "prod", { "label": "P99 (avg: ${AVG})", "stat": "p99" } ]
                ],

APIGW in question only has a single stage (latest) and definitely does not have one named 'prod'.

@corey-cole The bug fix applied here was done for the monitorScope method where it was not passing the ApiGateway deployment stage when it internally invoked monitorApiGateway and that resulted in the default prod as the stage name always because there wasn't one supplied. Before the fix I was able to workaround it by directly invoking monitorApiGateway  and passing along the stage name. With the fix in place, I went back to using monitorScope.  In my use case I have stage names like development, production etc depending on where my stack is deployed and the fix works for me and the correct stage name is reflected. I'm using the Typescript version of the library.
The fix added deployment stage to monitorScope https://github.com/cdklabs/cdk-monitoring-constructs/blob/main/lib/facade/MonitoringAspect.ts#L109
In monitorApiGateway the default prod is only used if apiStage was not provided https://github.com/cdklabs/cdk-monitoring-constructs/blob/main/lib/monitoring/aws-apigateway/ApiGatewayMonitoring.ts#L118
In your example I see you are passing the api_stage but looks like it isn't being reflected. While it is unrelated to this fix as this was done to monitorScope and did not change the behavior of monitorApiGateway the code in the monitorApiGateway does use the apiStage when passed at least for the Typescript based library. I'm not sure why it isn't working in your case. Maybe one of the contributors can weigh in and you could consider opening a new bug.

I don't see a good reason why it wouldn't use your supplied api_stage unless there's some JSII-weirdness going on. Can you open a new issue with more details including what version you're using, and ideally a minimal project that reproduces the issue?


Support arbitrary blob signing

Spec updates for Arbitrary blob signing. Proposal https://hackmd.io/ewbJr2ZnT4a8U1ObDVXcSw?view#CLI-Spec
More changes to Plugin spec, signing&verification workflows, trust policy spec, are coming in a separate PR.
Issue : https://github.com/notaryproject/specifications/issues/281
Signed-off-by: rgnote<EMAIL_ADDRESS>

@rgnote  maybe we missed the updates on the following documents

https://github.com/notaryproject/specifications/blob/main/specs/signing-and-verification-workflow.md
https://github.com/notaryproject/specifications/blob/main/specs/trust-store-trust-policy.md

@yizha1 I'm raising a separate PR for them. I'm fine if we want to hold off until we have that PR ready.

@yizha1 Actually, made changes to rest of the specs in this PR itself. Please review when you get a chance.
https://github.com/notaryproject/specifications/blob/main/specs/signing-and-verification-workflow.md
https://github.com/notaryproject/specifications/blob/main/specs/trust-store-trust-policy.md

trust-store-trust-policy.md still needs to be updated with the new CX that is proposed in https://hackmd.io/@-KPyDkW6QfGA-pldFa13pA/ByuHffALa

We will also need to update https://github.com/notaryproject/specifications/blob/main/specs/plugin-extensibility.md#signature-envelope-generator because Notation needs information about the digest algorithm it should utilize for calculating blob digests.

@priteshbandi I will chat with you offline about this.


govendor update github.com/keybase/client/go/protocol/keybase1/...

Vendor from https://github.com/keybase/client/pull/8211

client side merged


JsonSchema for bare_call_config is incorrect

Schema specifies that a minProperties for CallConfig is 1, however it is valid for a smart contract to have no bare methods

Fixed in v2.2.2


Payments to the Same Node are not Resstricted

The node is restored on two devices.
I sent a payment from one of them to the other and It charged me the fee.
It should be restricted paying the same node:

l-breez.logs (14).zip

@hydra-yse we should expose the sync's run_event_loop() to the sdk so it can manually trigger a pull/push before validating the invoice is not a self transfer


Connect this driver to the "Behat\MinkExtension" project

Currently, there is no way to use this driver in the Behat, because there is no corresponding driver in the https://github.com/Behat/MinkExtension/tree/master/src/Behat/MinkExtension/ServiceContainer/Driver .
The driver key would be webdriver-classic instead of selenium2. The current Selenium2 driver could be used as a starting point.
@uuf6429 , please submit a PR to that repo.

@aik099 / @stof just one question, out of curiosity, why are the driver factories in the behat/mink-extension package, instead of each individual driver package?

I've just noticed a huge banner on top of https://github.com/Behat/MinkExtension that recommends using https://github.com/FriendsOfBehat/MinkExtension instead.
@stof , isn't there a way to have a single repo?

@stof

there is a single repo for the MinkExtension now: the FriendsOfBehat one

FriendsOfBehat/MinkExtension is a bit of a mess:

it lacks proper documentation/readme, referring to the old/to-be-archived one instead (even though it has its own doc dir)
it claims not take any updates/features/improvements, unless they are compatibility bugfixes
looking at the code, it could do with some updating, but the previous point makes that unlikely to happen

I'll open a PR nonetheless, but this situation, (on top of the lack of feedback in Behat PRs/issues), doesn't inspire much confidence in Behat/Mink TBH.
@aik099 I'm closing this issue since it doesn't have anything to do with webdriver-classic-driver anymore.


Support python 2

Support python 2
What Did I Do?
Updated to run under python 2.7
Other improvements:

xfail tests when running on unsupported hardware or drivers
added temp and fan speed tests
added build and test Docker automation

Why Did I Do This?
The library needs to be used in a python 2.7 project.

Sorry about the broken Jenkins build. I intended to have it fixed by your morning, but then I ran out of time.
The build is a little convoluted because docker cannot use GPUs during the build. So there have to be at least two docker commands: build and run. The build sets up python and tox and moves in the code. The run runs tox which tests and makes wheels. I'm not aware of a command that can run a docker container without executing docker build first. docker-compose should be able to do this, but it's not one of our standard tools.
After reading some docs, I could not find a use for the tox-wheel plugin. My understanding is that it pre-builds the wheels to be used in all of the environments. This is useful as an optimization when testing library combinations. There is no clean and obvious way to extract that wheel for publishing.

@xaker00 I created an example what I meant with tox-wheel and Jenkins runner here: https://github.com/mobius-medical/pynvml/compare/feature/ias_support_python2...mobius-medical:pynvml:feature/ddr_embed_into_ci?expand=1
I use tox-wheel to generate the wheels and actually test them (instead of testing on the sdist). And then upload the wheels. Not sure what you meant with there's no clean way to get the wheels. tox provides all of that, we just swap out sdist to wheel: https://tox.wiki/en/latest/config.html#conf-distshare
Please note what I would still change on my branch:

The builds should be only uploaded from the master branch, not the development branches
Currently there's an issue with the pnvml version when building the wheel: The wheel come out with unknown as version number: https://uspa-artifactory.varian.com/artifactory/webapp/#/artifacts/browse/tree/Properties/m3d-playground/pynvml-0+unknown-py2-none-any.whl Hopefully you can figure out why's that the case.

@DavidCDreher I missed distshare in tox-wheel. Thanks for the example. I fixed the version. It was none because git was not installed. I also used a stock Ubuntu image because docker brings in enough nvidia stuff from the host to make this build work. Conditional upload is implemented as well.
I kept the build script as it helps me test everything up to the Jenkinsfile on any dev machine with Docker and a GPU.


Problem implementing garage door - Home app doesn't show correct status

I'm implementing the GarageDoor interface, however I'm finding that the iOS Home app doesn't display the correct door state. Here's my implementation:
public class RemoteGarageDoor implements GarageDoor {
	/**
	 * A connection to the door which allows data to be sent and received.
	 */
	private final GarageDoorConnection connection;

	private final int id;

	private final String label;

	private final String manufacturer;

	private final String model;

	private final String serialNumber;

	/**
	 * Futures passed to {@link #getCurrentDoorState()} which must be completed next time the door
	 * status is updated.
	 */
	private final Set<CompletableFuture<DoorState>> getDoorStateFutures =
			ConcurrentHashMap.newKeySet();

	/**
	 * Futures passed to {@link #getObstructionDetected()} which must be completed next time the
	 * door status is updated.
	 */
	private final Set<CompletableFuture<Boolean>> getObstructionDetectedFutures =
			ConcurrentHashMap.newKeySet();

	/**
	 * Future from the last call to {@link #setTargetDoorState(DoorState)} which must be
	 * completed when the door reaches the target state.
	 */
	private CompletableFuture<Void> targetStateReachedFuture;

	private DoorState lastKnownDoorState = CLOSED;

	private boolean lastKnownObstructionDetected = false;

	private DoorState targetDoorState = CLOSED;

	/**
	 * Whether or not the current target door state has been sent to the door.
	 */
	private boolean targetHasBeenRequested = true;

	private HomekitCharacteristicChangeCallback doorStateCallback;

	private HomekitCharacteristicChangeCallback targetDoorStateCallback;

	private HomekitCharacteristicChangeCallback obstructionDetectedCallback;

	public RemoteGarageDoor(final GarageDoorConnection connection,
			final int id,
			final String label,
			final String manufacturer,
			final String model,
			final String serialNumber) {
		this.connection = checkNotNull(connection, "connection cannot be null.");
		this.id = id;
		this.label = checkNotNull(label, "label cannot be null.");
		this.manufacturer = checkNotNull(manufacturer, "manufacturer cannot be null.");
		this.model = checkNotNull(model, "model cannot be null.");
		this.serialNumber = checkNotNull(serialNumber, "serialNumber cannot be null.");

		// Use a background thread for looping
		Executors.newSingleThreadExecutor().execute(() -> {
			while (true) {
				try {
					loop();
				} catch (final Exception e) {
					Lumberjack.log(ERROR, "Error occurred in RemoteGarageDoor loop.", e);
				}
			}
		});
	}

	@Override
	public String getLabel() {
		return label;
	}

	@Override
	public String getManufacturer() {
		return manufacturer;
	}

	@Override
	public String getModel() {
		return model;
	}

	@Override
	public String getSerialNumber() {
		return serialNumber;
	}

	@Override
	public int getId() {
		return id;
	}

	@Override
	public void identify() {
		Lumberjack.log(WARNING, "identify() not implemented for RemoteGarageDoor.");
	}

	@Override
	public CompletableFuture<DoorState> getCurrentDoorState() {
		final CompletableFuture<DoorState> future = new CompletableFuture<>();

		// Save the future so that it can be completed by the looper
		getDoorStateFutures.add(future);

		return future;
	}

	@Override
	public CompletableFuture<DoorState> getTargetDoorState() {
		return CompletableFuture.completedFuture(targetDoorState);
	}

	@Override
	public CompletableFuture<Boolean> getObstructionDetected() {
		final CompletableFuture<Boolean> future = new CompletableFuture<>();

		// Save the future so that it can be completed by the looper
		getObstructionDetectedFutures.add(future);

		return future;
	}

	@Override
	public CompletableFuture<Void> setTargetDoorState(final DoorState targetDoorState) throws
			Exception {
		final CompletableFuture<Void> future = new CompletableFuture<>();

		if (this.targetDoorState != targetDoorState) {
			// Deliver callback if necessary
			if (targetDoorStateCallback != null) {
				targetDoorStateCallback.changed();
			}

			// Save the new target state
			this.targetDoorState = targetDoorState;

			// Save the future so it can be completed by the looper
			targetStateReachedFuture = future;

			// Indicate to the looper that the new target has not yet been requested
			targetHasBeenRequested = false;
		}

		return future;
	}

	@Override
	public void subscribeCurrentDoorState(final HomekitCharacteristicChangeCallback callback) {
		doorStateCallback = callback;
	}

	@Override
	public void subscribeTargetDoorState(final HomekitCharacteristicChangeCallback callback) {
		targetDoorStateCallback = callback;
	}

	@Override
	public void subscribeObstructionDetected(final HomekitCharacteristicChangeCallback callback) {
		obstructionDetectedCallback = callback;
	}

	@Override
	public void unsubscribeCurrentDoorState() {
		doorStateCallback = null;
	}

	@Override
	public void unsubscribeTargetDoorState() {
		targetDoorStateCallback = null;
	}

	@Override
	public void unsubscribeObstructionDetected() {
		obstructionDetectedCallback = null;
	}

	/**
	 * Requests that the door open/close etc. or requests a status update from the door. The
	 * former has priority.
	 */
	private void loop() {
		if (targetDoorState != lastKnownDoorState && !targetHasBeenRequested) {
			requestDoorStateChange();
			targetHasBeenRequested = true;
		} else {
			final ResponsePacket response = connection.sendRequestAndAwaitResponse(
					RequestPacket.newGetStatusUpdatedRequestPacket());

			// The door may not always be reachable.
			if (response != null) {
				processUpdate(response);
			}
		}
	}

	/**
	 * Sends a request to the door to change state.
	 */
	private void requestDoorStateChange() {
		//TODO implement confirmation return oacket, OK for now while using a wired connection
		if (targetDoorState == OPEN) {
			connection.sendRequest(RequestPacket.newOpenDoorRequestPacket());

		} else if (targetDoorState == CLOSED) {
			connection.sendRequest(RequestPacket.newCloseDoorRequestPacket());

		} else if (targetDoorState == STOPPED) {
			connection.sendRequest(RequestPacket.newStopDoorRequestPacket());

		} else {
			throw new RuntimeException("The target state is invalid.");
		}
	}

	/**
	 * Processes a status update from the door. Pending futures are completed if appropriate and
	 * the necessary callbacks are delivered.
	 *
	 * @param update
	 * 		the update from the door, not null
	 */
	private void processUpdate(final ResponsePacket update) {
		// Copy the current status
		final DoorState oldState = lastKnownDoorState;
		final boolean oldObstructionDetected = lastKnownObstructionDetected;

		// Update the current status
		lastKnownDoorState = update.getDoorState();
		lastKnownObstructionDetected = update.getObstructionDetectedStatus();

		// If the target state has been reached, complete the relevant future
		if (targetDoorState == update.getDoorState() && targetStateReachedFuture != null) {
			targetStateReachedFuture.complete(null);
			targetStateReachedFuture = null; // Completed, so discard
		}

		// Complete futures of getDoorState()
		for (final CompletableFuture<DoorState> future : getDoorStateFutures) {
			future.complete(update.getDoorState());
			getDoorStateFutures.remove(future); // Completed, so discard
		}

		// Complete futures of getObstructionDetected()
		for (final CompletableFuture<Boolean> future : getObstructionDetectedFutures) {
			future.complete(update.getObstructionDetectedStatus());
			getObstructionDetectedFutures.remove(future); // Completed, so discard
		}

		// Deliver door state change callback if necessary
		if (oldState != update.getDoorState() && doorStateCallback != null) {
			doorStateCallback.changed();
		}

		// Deliver obstruction detected changed callback if necessary
		if (oldObstructionDetected != update.getObstructionDetectedStatus()
				&& obstructionDetectedCallback != null) {
			obstructionDetectedCallback.changed();
		}
	}
}

Problems occur when the door state is changed. For example:

The iOS home app shows the status of closed. This is expected and reflects the internal representation of the door state.
Using the home app, a request to open the door is made.
The mock door opens and my garage door implementation completes appropriate saved futures.
New calls to getCurrentDoorState() result in the future being completed with a status of open.

Despite this, the home app continues to show "Opening..." as the door status.
My unit tests show that the futures are being completed as expected and the correct callbacks are being delivered. Also right now I'm mocking out the connection to the physical door, so there's no packet loss or other networking issues.
Any ideas?

After further investigation, I've found that execution blocks when HomekitCharacteristicChangeCallback.changed() is called in void processUpdate(final ResponsePacket update). I mocked these callbacks in my unit tests which would explain why they passed by my integration tests don't. Is this blocking behaviour expected?

@beowulfe
Is there an expected response time from the characteristic requests? I'm trying to do something somewhat similar to Matthew, in which I want to delegate all the actual work to the microcontroller on the garage door, and have my HAP server send MQTT requests and correlate the responses.
Currently I make a CompletableFuture when the value is requested. Any subsequent requests while I'm waiting for a response are given the same instance of the CompletableFuture. Then when I get a response back over MQTT I notify the subscriber (if any), and then complete the future, satisfying all the pending requests.
However since the controller may be offline, I need to do something meaningful if I don't get a response back in a reasonable time, or the gets for will block for long periods.
Is this a suitable approach to take, and what would be reasonable timeout behavior? I think returning null generates errors in the framework, but perhaps a suitable "no response" behavior in iOS will still happen.
If you can answer these questions I'd be happy to write a bit of documentation on the wiki page, and update the demo, perhaps add something a bit more complicated than the light.

Are you still having problems with the latest main branch?

I abandoned my project years ago.


KeyError: 'NNI_OUTPUT_DIR'’    How can I do? help.

Environment:

NNI version:1.9
NNI mode (local|remote|pai):local
Client OS:windows10
Server OS (for remote mode only):
Python version:3.6
TensorFlow version:1.15.0
Is conda/virtualenv/venv used?:conda
Is running in Docker?:no

Log message:

nnimanager.log:
dispatcher.log:
nnictl stdout and stderr:

What issue meet, what's expected?:
When I use keras-mnist, the error has happened ‘Traceback (most recent call last):
File "E:/ML/NIItry/mnist-keras.py", line 34, in
TENSORBOARD_DIR = os.environ['NNI_OUTPUT_DIR']
File "D:\Users\HSSS\Anaconda3\envs\tensorflow-gpu\lib\os.py", line 669, in getitem
raise KeyError(key) from None
KeyError: 'NNI_OUTPUT_DIR'’
How can I  deal with it?
How to reproduce it?:
Additional information:

Did you use nnictl to start the experiment?
NNI experiments must be launched with nnictl create --config CONFIG.YML. You can see more details in the tutorial

hello @xiajingjie, I will close this issue as it has not been updated for more than three months, feel free to reopen it if you still think it an active issue.


Updated JavaScript string escaping (#17)

Should cover #17.
Would it be useful to correctly escape unicode characters as well?

This change is

Thanks for the improvement.  I'll accept it once you get your CLA approved.
Regarding unicode: Yes, we would like complete support for all the JavaScript escapes, including unicode. There are also octal, hex, and control character escapes in JavaScript.  The sequential .replace(..) approach probably isn't the best solution for these, but at least it cover the most common use.


Left Navigation loading issue with SingleWebPartAppPage

Category

[x] Bug

Describe the bug

Create a SingleWebPartAppPage and added SPFx Webpart.

Using it in modern TeamSite template

Clicking on some link in the webpart when loading any URL the left navigation in Chrome is showing "Loading..." many times and nothing happens in left nav. It is working fine in IE / Edge. This problem started happening since last few days only. So existing running apps are also getting affected.

OS: Windows 10

Framework: [SPFx]

Browser(s): [Chrome]

Tooling: [e.g. VS Code, SPFx]

Unable to repro this... can you please provide more context & more detailed steps to repro?

@andrewconnell this is somewhat similar behaviour I have observed earlier. There's a problem with loading SPFX webpart in Single page webpart layout. You can reproduce it by adding two SPFX webpart pages from create a new page screen. Click the link on left hand navigation, the page with a SPFX webpart loads fine but when you click the other link, the page doesn't refresh but shows the same SPFX webpart of the previous page.  Here's the link to the related issue. Now the issues is available in production https://github.com/SharePoint/sp-dev-docs/issues/5211

Unable to repro this... can you please provide more context & more detailed steps to repro?

I have added the screen shot; please see it above.

This is causing much difficulty with our customers - we've had to put out a support bulletin telling them to click the links twice to navigate.     Is there any acknowledgment of this issue yet?

This is causing much difficulty with our customers - we've had to put out a support bulletin telling them to click the links twice to navigate. Is there any acknowledgment of this issue yet?

Now the similar issue is happening for us as well. It was perfect couple of weeks before also.

@ng-marcus said:

Is there any acknowledgment of this issue yet?

Yup... I've alerted SP engineering.

any target date to fix this please?

Why is this marked as closed????

This request is still open,  there is one more newly created duplicate incident is closed.

Can you please share the any duplicate incident link as I need to follow up and answer to client?

@subhasishmukhopadhyay look at the timeline of this issue... related issues are added to the timeline as mentions.

@subhasishmukhopadhyay look at the timeline of this issue... related issues are added to the timeline as mentions.

It is good to give the reference of the open issue before closing it and write proper comment; sorry I do not get which one you mean!

I get the the same issue navigating between client side pages that have had their layout type set to SingleWebPartAppPage.

Do you have any further update please?

Probably also related to this one: https://github.com/SharePoint/sp-dev-docs/issues/4975
You need to click twice when you navigate back from the OOB events page to a Single part app page to get the content loaded.

So many issues with same problem:
https://github.com/SharePoint/sp-dev-docs/issues/2398
https://github.com/SharePoint/sp-dev-docs/issues/4975
https://github.com/SharePoint/sp-dev-docs/issues/5211
https://github.com/SharePoint/sp-dev-docs/issues/5227
https://github.com/SharePoint/sp-dev-docs/issues/5235
https://github.com/SharePoint/sp-dev-docs/issues/5352
https://github.com/SharePoint/sp-dev-docs/issues/5448
And no relevant answer.
Please, is it possible to fix this?

So many issues with same problem:
#2398
#4975
#5211
#5227
#5235
#5352
#5448
And no relevant answer.
Please, is it possible to fix this?

We truly need solution for this....

Temporary solution. Put it into your webpart.

As Array.from is not working so I have changed a little bit and added. But no change in that. All links in the page and left nav needs to click twice.
var elements = document.getElementsByClassName('ms-HorizontalNavItem-link');
var elementsArray: any[] = [];
Array.prototype.forEach.call(elements, (el) => {
elementsArray.push(el.tagName);
});
elementsArray.map(
x => {
x.setAttribute("data-interception", "off");
}
);

Hi please try this class "ms-Nav-link".
var elements = document.getElementsByClassName('ms-Nav-link');
//sorry  ms-HorizontalNavItem-link is top navigation

Getting the error "TypeError: Object doesn't support property or method 'setAttribute'" in browser console and no page is loading so I have reverted the changes.

Is there any plan to fix it and any deadline please? ... it is almost 2 months since the issue was reported

Is there any plans to fix this please?

Any updates on this issue, we are seeing this issue as well? any workarounds?

Any plan to fix it? Why no comment since long and no update on this?

The above workaround can only partially address the issue, mainly due to the selector not targeting all possible link elements on the page. It also can't fix links that aren't yet there when the web part loads, such as the side menu navigation when it is collapsed due to the smaller screen width breakpoint. The links only exist when that is opened, and destroyed for brand new instances the next time. These transient anchor elements can be targeted with polling or mutation observers, but that comes with negative performance considerations.
We are also concerned about needing to apply a hack on the page to fix this SharePoint bug, and the possibility that our fix will conflict with the official fix from Microsoft whenever that finally comes. It seems SPFx overall is meant to address developers making too many modifications to native SharePoint elements, by providing official sanctioned outlets for customization. But issues like this, where the only workaround is to modify native SharePoint elements, sort of conflict with that point.
Our customers are instructed to report the issue for their tenants through normal support channels. Hopefully we will see progress soon. Thank you!

folks, I just tried to repro this with the Leads app from PnP Samples and it does not repro. Do you have an environment I can take a look at or a solution you can share where the problem reproes constantly?

Hey Luca.  Our app isn't open source, but happy to assign you an account in our dev tenancy and give you access to it if that helps you work on this.  Ping me if that would be useful.

Thanks Luca. Maybe it's a bit chaotic to track the actual problem, as there are several github issues all related to this. It's possible a related mentioned above would have been more appropriate for me have commented on.
The key to repro for me is navigation from one single part app page to another single part app page, using a single click on an anchor element that does not have the data-interception="off" attribute. It doesn't seem to have the problem when navigating between a single part app page and a regular site page.

I have opened Premier with MS Case #:20221834. They have reproduced in their test environment and the engineer is working with product team to solve this issue. I hope we can get the fix soon.

I'm going to close this specific issue (the nav component not loading).  We are looking into the navigating issue (clicking multiple times, etc.) as part of this issue - https://github.com/SharePoint/sp-dev-docs/issues/5227


Logging Filter Source Code Header

The logging filter source code files (see #144) should have this header:
/**
 * Copyright (C) 2015 Agro-Know, Deutsches Forschungszentrum für Künstliche Intelligenz, iMinds,
 * Institut für Angewandte Informatik e. V. an der Universität Leipzig,
 * Istituto Superiore Mario Boella, Tilde, Vistatec, WRIPL (http://freme-project.eu)
 *
 * This source code is derived from the Spring MVC Logging Filter
 * (https://github.com/isrsal/spring-mvc-logger) by Israel Zalmanov.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *         http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

This header is different from the header we use elsewhere. It needs to be used in 4 source code files.
@ArneBinder is this compatible with the Maven License Plugin?

We will handle the source code headers of these files manually. To do so, they have to be excluded in the exclude section of the apache maven license plugin.
Waiting for a list of the affected files, see comment in #144.

I added them to the exclude section here https://github.com/freme-project/Broker/commit/8b024786b7a0fc189c984c9452b88d665c283284

Ok, thanks! I will add the Headers.


Revert "Added a build type to the version string."

Reverts LunarG/gfxreconstruct#1264

CI gfxreconstruct build queued with queue ID 177696.


helix-machines gets mad if an image is cancelled

Sometimes I trigger image creation for testing, then cancel the images because I feel bad about wasting compute time. Then I am reminded that IF remembers the image state for a given definition. The helix-machines image-generation code does not know how to handle this case and crashes. It should instead just pretend it was a failed image and retry it.
Release Note Category

[ ] Feature changes/additions
[ ] Bug fixes
[x] Internal Infrastructure Improvements

Release Note Description
Teach Image Factory CLI to retry "cancelled" images.

PR: Pull request 34810: Handle cancelled images as failed images - Repos (azure.com)


free: implement --lohi

-l, --lohi
       Show detailed low and high memory statistics.

as far as i understand this flag, this is supposed to be used with --count and output a minimum and a maximum

Implemented in https://github.com/uutils/procps/pull/70


feat: more downloader metrics

Adds a metric for the number of in-flight requests as well as a metric for the number of buffered responses
Draft because I need to 1) finish integrating this with the headers downloader and 2) remove the unrelated change I made to the error metric

Codecov Report

Merging #1189 (0415372) into main (75692bc) will increase coverage by 0.25%.
The diff coverage is 34.78%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1189      +/-   ##
==========================================
+ Coverage   75.30%   75.56%   +0.25%
==========================================
  Files         335      335
  Lines       36438    36717     +279
==========================================
+ Hits        27440    27744     +304
+ Misses       8998     8973      -25

Flag
Coverage Δ

unit-tests
75.56% <34.78%> (+0.25%)
:arrow_up:

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

Impacted Files
Coverage Δ

crates/net/downloaders/src/metrics.rs
11.11% <0.00%> (-13.89%)
:arrow_down:

crates/net/downloaders/src/bodies/bodies.rs
88.61% <85.71%> (-0.06%)
:arrow_down:

...tes/net/downloaders/src/headers/reverse_headers.rs
76.14% <100.00%> (+0.07%)
:arrow_up:

crates/rpc/rpc-builder/src/lib.rs
24.75% <0.00%> (-6.90%)
:arrow_down:

crates/stages/src/test_utils/test_db.rs
72.02% <0.00%> (-1.00%)
:arrow_down:

crates/net/network/src/config.rs
69.19% <0.00%> (-0.61%)
:arrow_down:

crates/stages/src/stages/sender_recovery.rs
90.86% <0.00%> (-0.54%)
:arrow_down:

crates/net/network/src/manager.rs
49.06% <0.00%> (-0.19%)
:arrow_down:

crates/net/network/src/peers/manager.rs
84.24% <0.00%> (-0.10%)
:arrow_down:

bin/reth/src/node/mod.rs
0.00% <0.00%> (ø)

... and 10 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Write trust setpoint to correct field for logging

Not flown this yet, but there's not much to it.
Fixes #1951

Thanks!


Fix some test cases that weren't getting executed

Fix some test cases that weren't getting executed for one reason or another. See this analysis for background. This is not intended to fix all cases, just some that are easy to fix.
The check for test cases that are never executed (informational in https://github.com/ARMmbed/mbedtls/pull/3458, mandatory in a follow-up that is yet to come) will ensure that these bug don't come back.

Mistakes in dependencies.
PSA crypto metadata tests for algorithms that are not implemented.
SSL tests skipped because a ciphersuite is not supported, but that are testing that the ciphersuite is rejected.

None of the changes here apply to 2.16 or 2.7. All the changes in unit tests are for new cases added since 2.16, and the bug fix in ssl-opt.sh is caused by requires_ciphersuite which was added after 2.16.

These are bug fixes that should be backported where applicable, but it turns out that all of them are in new code that didn't exist in 2.16.


The GYP issue: where, how and who to maintain

So we have https://github.com/refack/GYP, I don't know what its current state is but I know things have been merged here straight into gyp/ that probably conflict with it so I assume we're in a messy out-of-sync state.
https://github.com/nodejs/admin/issues/247 was closed, I guess @refack doesn't want to transfer it to the org. IMO that's in no way a prerequisite to using it as our GYP upstream so I don't consider that a problem if @refack wants to continue maintaining it under his own name.
I'd just like clarity on where GYP changes are going, who approves them, how we keep things in sync here, with an upstream and with nodejs/node.
@refack do you still have the stomach to continue with maintaining it?
@nodejs/python some input from you folks too would be great. This is well outside my comfort zone and I'd rather node-gyp be concerned with wrapping GYP, not being the primary place it's maintained. That separation of concerns would also make issues and PRs here easier to manage and we have an appropriate place to point people who want to make GYP changes instead of everything getting tangled.

I can find nodejs/node#26620 is on progress... So I think we should wait for it?

I think @refack may have lost interest in helping maintain this tooling and we might be needing an alternative solution. We also have gyp.js and ninja.js in the picture, I'm about to put up a pull request for including gyp.js (the 3rd pull request to date) and see if we can work toward an opt-in for it and gradually work to full compatibility. But we need a strategy for maintaining it too, I don't believe @indutny is interested in pursuing these two projects and it'd be good to have a collective space for a group of people to maintain them.
For now I was thinking that setting up a new lightweight github org to maintain a collection of gyp and gyp-related tools might be a good approach, at least for the short term. Pull in GYP / GYP3 (or some synthesis of what's been done here, in nodejs/node and refack/GYP), gyp.js and ninja.js if @indutny wants to give them up, and use it as an upstream for node-gyp and anything else using gyp (nodejs/node, libuv?). I'd love to hear others' thoughts on this.

LGTM

I'd be happy to transfer both gyp.js and ninja.js to nodejs org upon request.

My preference would be to put our efforts into gyp.js and get rid of the python-based gyp, at least for add-ons.
TBD how to deal with Node's build system. I regret I didn't push my cmake-based fork but I ran out of time. If someone wants to dust it off and take all the credit, you're welcome. :-)

Also related to node/build#1789

use  GN

@bnoordhuis
https://github.com/electron/node
Chrome has given up gyp, we should use GN.   like   electron.

There's less than zero interest in investing in another Google produced, maintained, and gatekept tool, only to have it abandoned once an entire ecosystem is invested in it, like GYP. This goes especially for one that is only supported on a limited number of platforms. Our preference is toward more open and broadly supported and understood tools

@rvagg
Node-gyp is a legacy of history that has been cast aside.
Just like callback, we need time to transition to async/await .
We want node.js to be better, not just usable.

If it is not because of ecology, what language would you choose?
.net core / Dart / Go /Rust is better.
However, if node.js can do better, then does backend development also consider node.js as the first choice?

@zuohuadong There's nothing mandating the use of node-gyp for addons and right now if you were writing a new addon you have other choices such as cmake-js.
We were discouraged by Google from using GN (see https://github.com/nodejs/TSC/issues/648 and preceding https://github.com/nodejs/TSC/issues/464).
For the thousands of existing addons that do use node-gyp this project will still need to exist (whether continuing to use the Python based gyp or transitioning to a JavaScript based implementation).

@richardlau
We should recommend developers to use cmake or others.
The alternative node-gyp became the official recommendation.
Such as node-bazel, node-gn, node-cmake one of them.

@richardlau
We should recommend developers to use cmake or others.
The alternative node-gyp became the official recommendation.
Such as node-bazel, node-gn, node-cmake one of them.

@zuohuadong I'd suggest you raise an issue over in the main Node.js repository (or PR directly against the addons docs in the main repository). This issue/repository isn't the place to discuss that.

So... To get back to the issue at hand.  My vote is that we pull the GYP3 changes into node-gyp.  There are many solid decisions and fixes that went into GYP3 and with the inclusion of pyenv, it will make a more stable platform for continuing our Python 3 compatibility work.  In the long run, we should drop the need for Python but in the near term GYP3 is a better platform for getting to Python 3 compatibility before yearend.

@cclauss
Not many people like python3 and node.js at the same time.
Based on js or even ts can get more support and faster development.

Here's my suggestion for how we view the current status and immediate future plans:

Given @refack's clarification of status @ https://github.com/nodejs/node-gyp/pull/1845#issuecomment-515531372 I'm happy with vendoring in GYP3 from refack/GYP, we just need to get the doc & licensing right in there so we don't step on legal toes.
Work on gyp.js, ninja.js (and any other .js needed, something for msvc is going to be needed at a minimum) as a full replacement for Python dependencies. The path to this isn't going to be quick but the next step is to simply ship a version of node-gyp with an opt-in --gypjs mode available. Once we have that we can iterate to full support.

By pushing both GYP3 and gyp.js (and other supporting libraries) out of this repo we can clarify the specific domain that we're focusing on here and push all other issues to those edges. The challenge will be making sure that those edges don't become dead ends, so we'll need to make sure we have active communities around GYP3 and gyp.js because that's really been the biggest problem for node-gyp historically.
Fedor doesn't want to maintain gyp.js so we're going to need to pull that into this org (I would have liked a less heavyweight way to manage it but Fedor's preference is to transfer to the nodejs org). I'm fine with vendoring in a GYP3 maintained under @refack's GitHub in absence of any problems managing it that way.
In case it's not clear to anyone reading this: this is purely about ecosystem add-on builds and doesn't solve the nodejs/node dependency on GYP, that's a separate discussion but perhaps a more healthy GYP3 helps alleviate that pain.

@rvagg FWIW, I don't have strong preference about transferring or not transferring it. I'll be happy with whatever way of managing you think would be best for it.

@rvagg @cclauss

@zuohuadong ok, but you realise this is just more fuel for the anti-GN sentiment, right? "it's successor was already deprecated too" isn't correct either, its successor is GN—if you take Google build tooling as canonical for "successor", and some of us aren't blinkered into believing that Node is tightly tied to Google's product decisions, certainly not like Electron which is is hopelessly linked to Chromium codebase.
We have a very large and complex ecosystem to manage here, it doesn't turn on a dime. The Electron ecosystem seems to be much more comfortable with the rapid breakage of tying itself to the V8 upgrade cycle, Node takes a much more conservative approach and leans more toward classic server-side upgrade cycles than the rapid Browser change-o-rama. In JavaScript you get "JavaScript one" backward compatibility guarantees, we just don't get that with C++ or build toolchains, it's breakage all the way down and we have to make some very difficult compromises.

@rvagg @nodejs/node-gyp You asked somewhere (I just can't find it) if its time to re-publish node-gyp, and I think it is, or pretty close to. We've got node tests starting to go green when built/tested with py3 over in https://github.com/nodejs/node/pull/29451, and the last trouble was with the<EMAIL_ADDRESS>in npm, so if we could get a 5.0.4 published that would get us, once npm updates and is re-vendored into node's deps, a py3-working node.
At that point there is still remaining work --- figure out what to do in CI, what versions should be default, etc, but it would be quite a milestone! A huge thanks to @cclauss for keeping the pressure up on this, and everyone who has helped out.
This is all the shortest, hackiest way of getting py3 support, and in no way derails from the broader question of the gyp fragmentation, the "where, how, and who to maintain" is still very much an issue.

@bnoordhuis @rvagg @Fishrock123 You have publish rights, see :point_up:, this needs publishing for py3 capability to make it into npm -- or a pointer to what needs to be fixed before it can be published.

It looks to me like master would require a  node-gyp 6.0.0 due to https://github.com/nodejs/node-gyp/commit/c6e3b65a23948aa0cc7d909ec580a3b6dd52776e?

I don't normally publish this but I could if necessary. I'd prefer for either Ben or Rod to chime in if possible.

nodejs/node has an indirect dependency (through npm) on nodejs/node-gyp.
Given that we have 100 days left until Py2 EOL and we gotta publish so that npm picks that up so we can re-update our indirect dependency on ourselves...
I would recommend that we first publish a minor release without https://github.com/nodejs/node-gyp/commit/c6e3b65a23948aa0cc7d909ec580a3b6dd52776e and then once we have made more Py3 progress, we bundle up c6e3b65 and other semver-major PRs for a major release.

@Fishrock123 @bnoordhuis I don't know how you'd prefer to manage node-gyp.
You could revert c6e3b65a23948aa0cc7d909ec580a3b6dd52776e on master after doing a merge --fast-forward of master onto https://github.com/nodejs/node-gyp/tree/v3.x Then, 3.x can collect semver-majors.
The opposite, more node-like approach is possible, too, to allow master to have semver-majors,and make a 2.x branch and keep semver-majors off of it. /shrug.

will sort out a release asap, I just have a bit of a backlog that I'm working through to mentally get on top of things

aside: I hope this isn't off topic, I can move to another issue if its helpful, but I don't want to fragment the conversation unnecessarily.
Just to set the ground rules:

any change that breaks a currently working use of node-gyp is semver-major
choosing py3 over py2 is semver-major, at least until we KNOW that everything that  worked with py2 also works with py3. Its possible we may never get to that level of comfort, I don't really know, but we aren't there yet.
choosing py3 if no py2 is found... maybe not semver-major, since py3 may not work, but the build would have failed anyhow with no py2 found
choosing py3 when explicitly requested, even without  EXPERIMENTAL_NODE_GYP_PYTHON3, probably not semver-major, in the vein of "you asked for it, you got it"

@rvagg What I suggest doing is a staged approach:

semver-patch: master has fixes required when py3 is explicitly used (which currently requires EXPERIMENTAL_NODE_GYP_PYTHON3=yes). It also has some semver-major changes. I suggest releasing the non-semver major changes on master in a 5.0.4, which will unblock explicit testing of py3 for downstream (npm, node, node-pre-gyp, napi, etc.)
semver-minor: Remove the requirment to have EXPERIMENTAL_NODE_GYP_PYTHON3 set in order to use py3 when it is EXPLICITLY requested. The env var is not very documented, so it hinders people's experimenting. Once we have working builds in the major projects we know about, lets let other people use py3 easily so they can report bugs.
semver-minor/major?: Allow py3 to be "found" if no python2* executable exists, or if python is version 3. As more and more environments are provisioned with py3 but no py2, people will start to be running py3 all the time, and we will hear about problems (though hopefully they were found in 2. via explicit testing).
semver-major: Choose python3 before python2 if it is found. Honestly, I'm not sure if we should ever do this, but we aren't close yet.

@nodejs/npm As a (the?) major consumer of node-gyp, do you have any comments on the suggestions above?

Complicating things is that we should probably get https://github.com/nodejs/node-gyp/pull/1689 back in, which was reverted in https://github.com/nodejs/node-gyp/pull/1828 and should be considered semver-major. The problem with it for upstream is that it should probably be considered semver-major for Node too and only go in for a semver-major break, but node-gyp is a transitive dependency via npm so we require some kind of coordination there too.
My plan was to start a 5.x branch and manage 5 and 6 at the same time so we can do a proper major and also some patch/minor releases. I don't have strong opinions about any of the Python stuff so will take advice on that. My inclination is to not bother with a patch release, does anyone care enough for the distinction between patch and minor? Are we talking about risk for the changes that are semver-minor? Is it that they're untested and we have low confidence in them? Will a semver-patch prior to a semver-minor actually help matters at all? (i.e. is it really necessary for steps 1 and 2 above to be separate things?).
btw I started getting master in order yesterday but it's taking longer than expected. I'll get at least 2 release proposals up for discussion, one for 5 and one for 6.

I'm OK with bundling what I called 1. and 2. together in a semver-minor, as long as the next release of npm gets it, and it looks like they would: https://github.com/npm/npm-lifecycle/blob/e2270ff3fd49ca8d0af2af13d404e60e296b4244/package.json#L35
I think 3. needs a bit more time baking, and there is no hurry, node-gyp can be released again after we've got some more green in ci in various projects.
And a 5 & 6 branch seems pretty reasonable to me.

https://github.com/nodejs/node-gyp/pull/1893 for a 5.0.4 proposal and https://github.com/nodejs/node-gyp/pull/1892 for a 6.0.0. I expect the latter to take a while before it gets out so let's focus on 5.x for now.
@sam-github if the 2. in your list isn't ready yet then maybe we just take your staged approach. I was imagining we could just push all this stuff out but I guess I'm wrong.
Happy to take advice on what else needs doing, otherwise I guess I'll just pump out the v5.0.4.

5.0.4 is out now, has our whole backlog minus the one semver-major that's queued up for a 6.0.0. We have a v5.x branch now so are prepared to do more 5.x releases as needed.
If anyone has any more semver-major changes maybe you should get them in so we can get a 6.0.0 out?

@claudiahdz @isaacs @nodejs/npm Will the next npm patch release bundle<EMAIL_ADDRESS>as a matter of course, or is intervention required? Any estimate on when that will occur?
@cclauss there is some precedent for floating node-gyp patches in nodejs, see nodejs/node#c3caf21bd3, so perhaps we could do that in the short-term, though I assume we wouldn't want it actually picked in nodejs/node#v12.x

Done in npm/cli#260

Back to the original topic of this thread.
This is delicate, and I mean no disrespect, but at this stage I don't believe that relying on refack/GYP3 is what's best for this project at this time. It's important that we have a GYP that can receive timely updates and be maintained by more than one or two people. A lot of work has gone in to GYP3 and I'd hate to see that go to waste but my personal preference for node-gyp is for stability and a straightforward path to receiving contributions from people comfortable hacking Python.
It seems to me that having GYP in a separate repo would be a good thing, isolating node-gyp's concerns from GYP's concerns. But it's not urgent. We first need to come up with a name for it that's different enough from GYP to indicate that it's not Google's GYP project. "gyp-ng", "gypnext", something like that. Having a separate repo might make it easier to set up proper testing, documentation, a contribution process and even a dedicated team of Python people. We can vendor it in, use submodules or even publish GYP directly to npm and pull it in as a dependency to node-gyp. If someone here is feeling particularly inspired with a new name then speak up and maybe we should get the ball rolling? We should give a proposal to the TSC for action on this front before taking action because this is not a trivial matter and involves Google+legal concerns (the naming thing has come up already).
If Refael finds a path to come back to actively contributing to Node.js and wants to re-engage then this would be a perfect place to do so and I'm sure he would be heartily welcomed due to his obvious high level of expertise in the nexus of toolchains+python. But for now, I think we have to move forward on something that we are in more direct control over.

I'm still not up to speed with the git situation, things I don't understand ATM:

Do we have to do anything, other keep plugging patches into node-gyp here as needed? From an external point of view, it seems to just work.
How would gyp-ng be different from node-gyp? From refack/GYP3?

Refael's involvment or not is there any reason refack/GYP3 would not be used as the basis for "gyp-ng"?

In other words, what are the problems to solve?

py3 compat is being solved by patching the things that don't work (and appears to be getting close to working)
not enough people involved seems to be a problem --- but its not clear that taking up the development of gyp-ng would draw in more contributors

I like the idea of gyp.js, but my impression is it foundered not on technical difficulties, but once again, on not enough contributors.
Everything seems to come down to getting (and keeping) contributors.
Both the gyp.js approach @bnoordhuis and @indutny mention or gyp-ng sound like reasonable enough plans to me, but we need people to do the work.

@sam-github good questions, and my comment above didn't include gyp.js, my proposal for which in https://github.com/nodejs/node-gyp/issues/1791#issuecomment-516220798 still stands.

Do we have to do anything, other keep plugging patches into node-gyp here as needed? From an external point of view, it seems to just work.
How would gyp-ng be different from node-gyp? From refack/GYP3?

node-gyp is the JavaScript tooling wrapper around GYP, it's always vendored it in but when Google dropped it we ended up with two orphaned GYPs, one here and one in nodejs/node, and we've not resolved that relationship, nor have we formalised how we are treating these two codebases. We've just patched things where needed to keep them working. I'd like to at least formalise what GYP is and where it is canonically located or how the relationship between forks is. This confusion keeps on popping up in nodejs/node too.
My preference is to separate concerns. We have a GYP codebase that's Python and focused on a particular language (the GYP language) and how it defines an interaciton with toolchains. We have a JavaScript codebase that is focused on the interaction between GYP and Node.js / npm. I'm not at all comfortable hacking on GYP itself. I'm entirely comfortable hacking on the JavaScript in node-gyp and understand the interface down to the GYP layer. I'd like there to be a GYP place where people can go to deal with Python and toolchain concerns. Then node-gyp and nodejs/node could be consumers of that piece of the puzzle, both vendoring in the same Python code.

Refael's involvment or not is there any reason refack/GYP3 would not be used as the basis for "gyp-ng"?

Because the divergence is now quite large. Refael has done a ton of work in GYP3, so it's an entirely different beast. In parallel, and since then, we've done a lot of work here. I'd love someone to do a reconciliation but I don't know who is going to put in that effort. My preference is to stick with what works and evolve from there, which would mean using the GYP we have in here and perhaps patching in some nodejs/node changes. Then perhaps we could consider GYP3 changes on top of that, but so far it's entirely untested for the purpose of node-gyp so I don't think it's suitable as a starting point.

not enough people involved seems to be a problem --- but its not clear that taking up the development of gyp-ng would draw in more contributors

Yep, people is a problem no matter how we dice it. And we're shackled to GYP at least in the medium term because there's a massive ecosystem built around assumptions of its existence and the way it operates.
My proposal in this thread is to accept that, but migrate away from Python over time, investing in gyp.js, which does work for trivial projects (on limited platforms) already. We have way more JavaScript hackers around this org than Python hackers so it seems reasonable to me that people will just show up to fix their little corner cases as we expose it and start suggesting that it's going to eventually replace the Python version.
Alternatives include:

Accept Python GYP and keep maintaining it.
Adopt some new toolchain and come up with a migration path for our ecosystem.

The second one of these gets mentioned regularly with the two main suggestions being GN (see comments in this thread for e.g.) and CMake (which I'm more in favour of if we were to make a switch). And maybe we could invest in migration tooling for addon authors if we were to do one of these thing, and even bake them in to our next gen tooling so older stuff still works—this is not even mutually exclusive with the gyp.js as our "next gen" thing, perhaps we have a next-next gen that favours CMake input but is able to parse older binding.gyp with gyp.js and generate appropriate intermediate CMake output.

So, I spent a little time looking at the divergence between nodejs/node:tools/gyp ("tools gyp") and nodejs/node-gyp:gyp ("node-gyp").
There is a lot.... some of it is just textual, or project meta data, but the rest doesn't look easy to reconcile, see https://github.com/nodejs/node-gyp/compare/master...sam-github:compare-to-tools-gyp?expand=1 and https://github.com/nodejs/node/compare/master...sam-github:compare-to-node-gyp?expand=1
As some background, repeating some of what @rvagg explained:

chromium gyp was a general purpose build tool (well, build file generator), later abandoned
node-gyp's fork has diverged to specifically build Node.js addons
nodejs's fork (tools gyp) has diverged specifically to build Node.js itself (and its dependencies, v8, openssl, uv, etc)

I assume GYP3 was intended to bring the forks together and work for both node itself, and node addons, and just generally, but its untested.
A straightforward vendor of node-gyp's gyp/ directory into node's tools/gyp fails to even run, much less build Node.js, which didn't surprise me at all.
My thoughts on where we should go:
For addons:
I agree with @rvagg that we should encourage and hope for gyp.js to develop to the point it can be used to build Node.js addons, but would like to note that the addon community might be moving past gyp, see https://github.com/nodejs/node-addon-api/issues/445#issuecomment-536057129
Still, besides the many many existing addons with gyp configuration that we can't just abandon,
the downside of the https://github.com/nodejs/node-addon-examples/tree/master/build_with_cmake approach is that it has to be installed globally, and depends on cmake, which is a big deal -- node-gyp is present by default everywhere the npm CLI exists, though it does depend on Python (though most modern systems have that by default).
I think there is room here for new developments, I'm hopeful that if development continues on the various approaches, one or might become viable enough to become the defacto standard, then later, perhaps even "the" standard (and added to the npm CLI).
For node.js
What Node.js does to build itself from source is completely unrelated to node-gyp, AFAICT, and while the discussions of "what to do about gyp" for node.js and addons get linked together sometimes, they aren't dependent on each other.
I'm not convinced the technical and inertial hurdles to get the node-gyp and node.js forks of gyp merged can be overcome, or even need to be. While tools/gyp is being used for node.js, if any relevant changes land in either fork, they can be cross-ported, which is what happend for Python 3 support. If at some point Node.js gets a new build system (which at this point I think mostly involves someone actually doing the work and making sure it works across all our supported platforms), then tools/gyp would just be deleted, and node-gyp would have the only maintained gyp still in use.

Thanks for this...  I am in agreement.
I believe that tools/gyp needs a new name (that does not contain the word gyp).  An effort should be made in slim tools/gyp down to its bare essentials so that it can either be maintained or or rewritten in JavaScript.

Good writeup @sam-github, +1 to everything there I think.
I wasn't aware cmake.js was so mature, that's great news frankly and I'd be glad to see more addons head that way. The legacy problem remains though so we should still do our best to make sure node-gyp doesn't represent significant rot and technical debt for Node. I think we've made great progress as a team, particularly this year.
Next steps I propose:

New name for gyp
Extract gyp to a nodejs/newname repo, add the node-gyp team to it
Vendor it back in to node-gyp (somehow, copying is fine at least to start with and just redirecting contributions to the new repo).
Move gyp.js and ninja.js into the nodejs org and add the node-gyp team to them
Release a node-gyp that has --experimental-gypjs support

I think we're circling around some form of agreement of the general trajectory from there onward.

Given https://github.com/nodejs/gyp-next are we ready to close this issue?

Yep, can someone who's keeping track of gyp-next do a PR to sync us with the latest when it's "ready", we have the recent sync but it looks like even more work has gone in. Once that's done let's just push out a version 7.


Huge mess in documentation. Can it be resolved?

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
Search google for "anything" related to Bootstrap. Even make the effort and add in Bootstrap 5, just to be sure you are not picking up Bootstrap 3, 4 ...
Find results, and - even if I develop almost daily - always realise you are probably on the wrong documentation.
There is https://getbootstrap.com/docs/5.3/, which has a "latest" option to choose from.
There is https://getbootstrap.com/docs/5.2/, which has a "latest" option to choose from, but it is not the latest! Above is! Yet the darn thing features the same "older" versions as the 5.3 doc does!
(And many more other doc pages, all for a bit of version)
I would suggest, please, pretty please, put that stuff onto one page, make it default to the latest first and open and active, and the user can then select older, any older from the dropdown - without having to have nightmares to doubt if they are or not on the right doc.
This is really horrific.
Thank you.
Reduced test cases
Navigate the web. Search for Bootstrap.
What operating system(s) are you seeing the problem on?
macOS
What browser(s) are you seeing the problem on?
No response
What version of Bootstrap are you using?
LATEST

And where is said duplicate?

Maybe not in the same exact words but https://github.com/twbs/bootstrap/issues/28581 and https://github.com/twbs/bootstrap/issues/39212 are already mentioning this issue.
We did something as a first step in that direction by adding a "There's a newer version of Bootstrap!" in almost all the previous versions. Changing the dropdowns would mean changing the previous versions of the documentation that are generated at the release time: not everyone in the team is in favor of doing it.
We still need to work on it obviously, but we're currently focusing on finalizing the color modes right now.

Why would you keep an old version of bootstrap doc with a dropdown saying "this is the latest", even if it is wrong?
It seems there is a new banner "There's a newer version of Bootstrap" on top, that's a great start. But that defies the purpose of the version dropdown. I googled to come to a specific page, now you bring me to latest homepage, and I need to start searching again for the content I was initially looking for. The version dropdown should just bring me to the latest version of that dedicated page.


fix: change the signature of some functions to prevent heap allocation

NewMapString
MapString.Copy
MapString.CopyUnsafe

Codecov Report

Merging #8 into master will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master        #8   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            8         8
  Lines          310       305    -5
=========================================
- Hits           310       305    -5

Impacted Files
Coverage Δ

safe/map_string.go
100.00% <100.00%> (ø)

safe/map_string_unsafe.go
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Write a Scala program to find lcm of two numbers

Description
Write a Scala program to find lcm of two numbers
LCM (Least Common Multiple) of two numbers is the smallest number which can be divided by both numbers. For example, the LCM of 15 and 20 is 60 and LCM of 10 and 15 is 30.
Input  : 12 18
Output : 36

How to contribute

Save the solution in findLcmOfTwoNumbers.scala file
Add findLcmOfTwoNumbers.scala file in find-lcm-of-two-numbers folder

!assign


solves GH-70 extend chain with state of the world service

@sennui Review completed, I requested clarification on supervision tree.

Applied all requests from @lucafavatella. The sup tree is corrected.


How to configure the RISC-V ISA parameters in stdlib?

In the comment. We should have efficient approach to configure the parameter riscv_type, vlen, elen and so on in stdlib.

Moved to https://github.com/orgs/gem5/discussions/838


Fix memory leak in ecp_mul_comb() if ecp_precompute_comb() fails

Description
In ecp_mul_comb(), if (!p_eq_g && grp->T == NULL) and ecp_precompute_comb() fails (which can
happen due to OOM), then the new array of points T will be leaked (as it's newly allocated, but
hasn't been assigned to grp->T yet).
Symptom was a memory leak in ECDHE key exchange under low memory conditions.
Status
READY
Requires Backporting
Yes? This is quite a subtle and uncommon bug. Will follow advice from maintainers about whether it should be backported or not (and to where).
Migrations
NO
Additional comments
Submission is from Espressif Systems and falls under corporate CLA..
Todos

[x] Changelog updated
[ ] Backported

Steps to test or reproduce
This is quite difficult to reproduce easily (or write a unit test for) as there needs to be enough free memory that the calloc() inside ecp_mul_comb() succeeds, but then later allocations in ecp_precompute_comb() will fail. It was only reported under very certain circumstances.

@projectgus Thank you for your contribution!
Since this is a bug fix, we do backport it to our LTS branches, which today are mbedtls-2.1 and mbedtls-2.7.
We will look into this

@gilles-peskine-arm Got it. Comment added.
@RonEld I see, thanks. Please feel free to edit my comment under "Requires Backporting" with whatever info is pertinent.

@projectgus I hope you don't mind I took backported your fix to branches 2.7 and 2.1 , in #1886 and #1887

Removing the "needs backport" label as This PR and its backports have been fully approved
cc @Patater

retest

Approved and CI passed. Likewise for backports. This is ready for merge. Thank you!

@RonEld Certainly do not mind you backporting, thanks for that!
I've fixed the ChangeLog merge conflict for an easier merge to development (no code changes in this update).

Oops, sorry for the rebase folks. Now I know!


Is there an option not replace \t to 4 space?

Is it danger if don't do the replace? Why it is important and how can I disable this option.
I examine the Parsedown.php file and not found any possibility do this, except comment following lines in private lines method:
            if (strpos($line, "\t") !== false)
            {
                $parts = explode("\t", $line);

                $line = $parts[0];

                unset($parts[0]);

                foreach ($parts as $part)
                {
                    $shortage = 4 - mb_strlen($line, 'utf-8') % 4;

                    $line .= str_repeat(' ', $shortage);
                    $line .= $part;
                }
            }

Please help do this correctly.

it'd work but it won't consider text indented with tabs as a code block and nested list items as nested

Thanks!
if that makes sense, it would be perfect if in next version it can be done without changing the original Parsdown.php file.
Maybe take out this part of code in single protected method. Or add corresponding setting for class.

now I noticed that parser broke such \t too:

	// it's one tab, not spaces

\t becomes 4 space, because of code I mentioned before. It's maybe good when parsedown parse code itself in ~*~ or any else. But here I have pre tag, why parser need to touch code inside the tag?
I thought parser don't touch code inside html tag at all... Except I would do it myself.
All this looks like bug.

This is expected and consistent with the other Markdown parsers.

Yes, but I need it and maybe I'm not lonely. If it possible, would be perfect to add such option, or give chance to do it without changing private lines method. Now I have no choice. \t is important for me...

I understand, but there are a lot of other things that are higher priority, so I can't promise.

Anyway thanks!

In the end I solved the problem (replace 4 space on tabs) in another way. After all parsedown manipulations have been occured, I filter resulting text with such code (it's fast anought):
$text = preg_replace_callback('/^[ ]{4,}/m', function( $m ){
	return preg_replace('/[ ]{4}/', "\t", $m[0] );
}, $text );

P.S. maybe better close this thread

Hello. I would also find it good if tabulators remain tabluators. Especially for the indentation of code one has actually only to use tabulators (everything else is semantically wrong and inflexible). What would happen if I defined in CSS that a tab should be displayed in the HTML pre-tags like 12 spaces (tab-size: 12;)? This does not work because the CSS does not find any tabulators, but only four hard blanks. If the user places a tab anywhere within its text or source code, the tab should always remain a tab. Especially within HTML pre-tags where I may post my source code which is semantically correct indent with tabs! If the markdown parser replaces my tabs, the code isn't anymore THE code I've inserted.
If this is my original code which I want to put into my markdown (tab indentation) …
class Foobar {
	protected $propertyA = 1;
	protected $propertyB = 1;
}

… Parsedown will make this, which is not my code anymore:
class Foobar {
    protected $propertyA = 1;
    protected $propertyB = 1;
}

If you compare the two code examples, you'll see that GitHub also retains the tab indentation in the first example and uses a width like 8 spaces for displaying them (8 is the default width in HTML pre-tags for tabs). And this is EXACT the same code I entered in the issue editor. The second example is not my code because tabs were replaced by spaces. This is inflexible if someone would copy the code into his IDE in which he uses, for example, a width like 15 spaces for displaying tabs.
Shortly: Tabulators should remain tabulators. :)


multiple "scan: Open: open /X permission denied" record only "1 errors"

restic 0.14.0 compiled with go1.19.8 on linux/amd64 - debian bookworm

run restic as user
two directories, which can be accessed only by root
restic show only "1 errors"
should't every inaccessible folder generate an error ?

4 drwxr-xr-x 6 user user 4096 Aug 31 00:00 .
4 drwxr-xr-x 9 root root 4096 Aug 31 00:00 ..
4 drwxr-xr-x 2 user user 4096 Aug 31 00:00 01_user
4 drwxr-xr-x 2 user user 4096 Aug 31 00:00 02_user
4 drwx------ 2 root root 4096 Aug 31 00:00 03_root
4 drwx------ 2 root root 4096 Aug 31 00:00 04_root

open repository
enter password for repository:
repository 00000000 opened (repository version 2) successfully, password is correct
created new cache in /home/user/.cache/restic
lock repository
no parent snapshot found, will read all files
load index files
start scan on [/mnt/restic/]
start backup on [/mnt/restic/]
scan: Open: open /mnt/restic/03_root: permission denied
scan: Open: open /mnt/restic/04_root: permission denied
scan finished in 0.735s: X files, X TiB
error: Open: open /mnt/restic/03_root: permission denied
[00:00] 0%  X files X GiB, total X files X TiB, 1 errors ETA 00:00:00

just for record i just have to wait until all directorys have backed up.
restic only gives errors after the backup process could not be accessed.


graph-tool installation via conda not working

Comment:
I used below commands to install graph tool but it's giving me ModuleNotFoundError: No module named 'graph_tool' error message when I do import graph_tool.all as gt
conda create --name gt -c conda-forge graph-tool
conda activate gt
conda is in the latest version, up to date. How can I address this issue?

What OS are you using? Can you provide the output of the conda commands you are running?

Also provide the output of “conda --info”, please.

active environment : base
    active env location : /scratch/user/anaconda3
            shell level : 1
       user config file : /home/user/.condarc
 populated config files : /home/user/.condarc
          conda version : 23.7.4
    conda-build version : 3.26.1
         python version : 3.11.5.final.0
       virtual packages : __archspec=1=x86_64
                          __cuda=12.4=0
                          __glibc=2.35=0
                          __linux=5.15.0=0
                          __unix=0=0
       base environment : /scratch/user/anaconda3  (writable)
      conda av data dir : /scratch/user/anaconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /scratch/user/anaconda3/pkgs
                          /home/user/.conda/pkgs
       envs directories : /scratch/user/anaconda3/envs
                          /home/user/.conda/envs
               platform : linux-64
             user-agent : conda/23.7.4 requests/2.31.0 CPython/3.11.5 Linux/5.15.0-107-generic ubuntu/22.04.4 glibc/2.35 aau/0.4.2 c/AzXW8LigKWlDxTADFvRs4A s/0nHj0vA62XCZwqrEX-H7Nw e/NtKMpYYuakPq65NqOuBpBQ
                UID:GID : 5527037:50006
             netrc file : None
           offline mode : False

@stuarteberg running on Ubuntu 22.04.4 LTS using Mac

I just tried conda install conda-forge::graph-tool, and it's stuck at Solving environment....

Did you activate the gt environment after you created it?  Run conda activate gt and then check the output of type python.  If the environment was properly activated and graph-tool still isn't working, then proceed with the instructions below.

Your version of conda is slightly out-of-date.  Just to make sure we're on the same page, try updating:
conda install -n base 'conda>=24.5.0'

And then try installing graph-tool-base with the following command:
conda create -n gt --override-channels -c conda-forge 'graph-tool-base>=2.68'

And check to see if it was installed properly:
conda activate gt
python -c 'import graph_tool.all as gt'

If that works, you can try installing the full graph-tool package (which includes drawing dependencies).
conda install -n gt --override-channels -c conda-forge `graph-tool>=2.68`

running on Ubuntu 22.04.4 LTS using Mac

Linux on a Mac?  Are you running in a Docker container?  That should work fine, though I'm not certain about the drawing features in that case.

I'm having the same issue on MacOS. Even after following the instructions you posted above I still get a moduleNotFound error.

@HoldenN7 please paste the output of “conda info” here, as well as the transcript of output you see when following the commands above.


Add Emberall to showcase

I'm really excited to finally have been able to share with the world the app that I've been building with React Native for the last six months! Emberall is the best way to save and share family videos, and record special moments with your kids as they're growing up. (@vjeux ping me if you want a premium account for free :P ) More details are on our company blog.
I've been heads down for a while just getting this out the door, but I'll try to have a blog post out soon with lessons learned in getting the app finished and published in the App Store.

By analyzing the blame information on this pull request, we identified @brentvatne and @manonthemat to be potential reviewers.

<3 <3 <3

@facebook-github-bot shipit

Thanks for importing. If you are an FB employee go to Phabricator to review.


Output not scrolling if oversized

I'm trying this tool - it looks really great and useful. I'm just running into what might be a possible bug. After expanding the output to "table view" and whenever that output doesn't fit current cmd line window, the output does not scroll when I get to the last line at the very bottom of the window and then I want to move further down (the highlight for cursor is lost and there's no scrolling happening). Is there any key shortcut to manually scroll the output or is this just a bug? Thanks.

I'm not sure how it's related, but I can reproduce 100% with 58853c7dbfc84143909aa0a9686f5640bcf13e65. With fed69798883f5df1b249cec98a2b89889697ff19, it all works as expected.


Duplicate exposed-modules

This seems to be caused by source-dirs being specified at the root level, as well as under library.
This is a simplified minimal case - so possibly it might not make sense, the actual file I'm using has a library+executable defined hence the need for the  root source-dirs.
minimal:
source-dirs: src
executables:
  pitanga:
    main: Main.main
license-file: LICENSE
build-type: Simple
maintainer: Chris Stryczynski
dependencies:
- base >=4.11 && <4.15
name: platinumpitanga
version: '<IP_ADDRESS>'
extra-source-files: ChangeLog.md
author: Chris Stryczynski
license: BSD3
default-extensions:
  - LambdaCase
library:
  source-dirs: src

My actual hpack.yaml:
source-dirs: src
executables:
  pitanga:
    main: Main.main
license-file: LICENSE
build-type: Simple
maintainer: Chris Stryczynski
dependencies:
- base >=4.11 && <4.15
- turtle
- aeson-pretty
- strings
- rainbow
- lens
- aeson
- bytestring
- split
- text
- time
- old-locale
- directory
- pretty-simple
- string-conversions
- optparse-applicative
- vector
- attoparsec
name: platinumpitanga
version: '<IP_ADDRESS>'
extra-source-files: ChangeLog.md
author: Chris Stryczynski
license: BSD3
default-extensions:
  - LambdaCase
library:
  source-dirs: src

Minmal generates:
cabal-version: 1.12

-- This file has been generated from package.yaml by hpack version 0.31.2.
--
-- see: https://github.com/sol/hpack
--
-- hash: 583e36627543e61f7831d296258c5ae42ec7226e08ed7c7f1c88136717c37ce7

name:           platinumpitanga
version:        <IP_ADDRESS>
author:         Chris Stryczynski
maintainer:     Chris Stryczynski
license:        BSD3
license-file:   LICENSE
build-type:     Simple
extra-source-files:
    ChangeLog.md

library
  exposed-modules:
      Common
      Export
      Log
      Main
      MyDebug
      ResumeTask
      StopTask
      Types
      Common
      Export
      Log
      Main
      MyDebug
      ResumeTask
      StopTask
      Types
  other-modules:
      Paths_platinumpitanga
  hs-source-dirs:
      src
      src
  default-extensions: LambdaCase
  build-depends:
      base >=4.11 && <4.15
  default-language: Haskell2010

executable pitanga
  main-is: Main.hs
  other-modules:
      Common
      Export
      Log
      MyDebug
      ResumeTask
      StopTask
      Types
      Paths_platinumpitanga
  hs-source-dirs:
      src
  default-extensions: LambdaCase
  ghc-options: -main-is Main.main
  build-depends:
      base >=4.11 && <4.15
  default-language: Haskell2010

This can be worked around (or perhaps I was using the wrong syntax in the first place), by setting source-dirs under the executable, as opposed to the root level / indent.
  But it's easy to address (see #356).

On Hackage.

Thank you!


CSS Mangement

There is no system in which we are managing CSS. It's apparent that it will soon be out of control so check various ways in which we can manage CSS

Use partials and rn the css is in in very good state making it better  is over engineering


Fix google-api-python-client installation in dockerfiles

Fixes C# breakage on master:
https://fusion.corp.google.com/projectanalysis/current/KOKORO/prod%3Agrpc%2Fcore%2Fmaster%2Flinux%2Fgrpc_basictests_multilang
I've rebuilt C# dockerfiles recently, and they are now failing because google-api-python-client doesn't work without also installing oauth2client. We will likely see similar problem for other languages soon if we don't fix it.
Example error:
https://source.cloud.google.com/results/invocations/eef719c8-51a7-4110-ab4a-f5b0262e7398/targets/github%2Fgrpc%2Faggregate_tests/tests
Traceback (most recent call last):
  File "tools/run_tests/run_tests.py", line 1873, in <module>
    build_only=args.build_only)
  File "tools/run_tests/run_tests.py", line 1827, in _build_and_run
    upload_results_to_bq(resultset, args.bq_result_table,
NameError: global name 'upload_results_to_bq' is not defined
  adding: reports/ (stored 0%)
  adding: reports/index.html (deflated 22%)
+ DOCKER_EXIT_CODE=1
++ mktemp
+ TEMP_REPORTS_ZIP=/tmp/tmp.H4Cvytyhnv
+ docker cp run_tests_715fc6da-e36f-4fad-9008-0bc2e13aec3c:/var/local/git/grpc/reports.zip /tmp/tmp.H4Cvytyhnv
+ unzip -o /tmp/tmp.H4Cvytyhnv -d /tmpfs/src/github/grpc
Archive:  /tmp/tmp.H4Cvytyhnv
  inflating: /tmpfs/src/github/grpc/reports/index.html
+ rm -f /tmp/tmp.H4Cvytyhnv
+ docker rm -f run_tests_715fc6da-e36f-4fad-9008-0bc2e13aec3c
run_tests_715fc6da-e36f-4fad-9008-0bc2e13aec3c
+ exit 1
Traceback (most recent call last):
  File "tools/run_tests/run_tests.py", line 1577, in <module>
    env=env)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'tools/run_tests/dockerize/build_docker_and_run_tests.sh' returned non-zero exit status 1

****************************************************************

libgrpc.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

CC @stanley-cheung

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,965,335      Total (=)      1,965,335

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,888,225      Total (<)     10,888,235

 No significant differences in binary sizes

@jtattermusch Ack

FTR https://github.com/google/import-mailbox-to-gmail/issues/41


fix(fetch-packages): remove only titles from loaders and plugins docs

When fetching packages title is removed by a regular expressions, but in README.md files like the one from style-loader, there's no a title heading using the pattern # .... Instead, its first line that matches this pattern is a sub-header. Since the purpose is only to replace a title, this PR changes the RegExp to match this kind of issues and maintaining other docs working as usual.
Fixes #2692

Done in https://github.com/webpack/webpack.js.org/pull/2693.
@ivandevp Sorry, we are working a new version of the website, that work is under rebuild branch, I moved your commit into a new branch: https://github.com/webpack/webpack.js.org/tree/rebuild-fix-process-readme.


Feature/choose route (work in progress)

This PR does not include a finished feature.
It implements some functionality that is needed to continue working on the route setup.
It doesn't break any existing functionality either, so check it out and let me know whether some changes are necessary.

Adjusted this so it can be merged, no longer in an WIP state. Cycling through routes now possible.

Great work on those changes. Flutter state is a very interesting concept. Unlike in React we can actually call methods using the state of the widget. Who would have thought that. May be discouraged by flutter according to some references I have read (eg. https://stackoverflow.com/a/51033284/5630207). But generally I don't see any reason why we shouldn't do it.
Just one question, why did you introduce all these underscores in the file names?
I'm sure you had a good reason. Everything else seems good to me so I'm going to approve and merge these changes now.


Add threads options

Coverage decreased (-0.2%) to 81.412% when pulling 3ccea72033a6001bf745811c9af5728440b17940 on waitingHao:master into b7a9bd525a68c48e306f4e9150a069880ecb2f37 on bramp:master.

Thanks! Would you mind adding a quick test?

Coverage decreased (-0.4%) to 81.169% when pulling b41f19a916b6e5c5cb6002c1979475ff61be4660 on waitingHao:master into b7a9bd525a68c48e306f4e9150a069880ecb2f37 on bramp:master.

It looks like you just pushed an unrelated change to Progress.java.

Coverage decreased (-0.4%) to 81.169% when pulling faa97454d8984193b48234260a0776320d5961be on waitingHao:master into b7a9bd525a68c48e306f4e9150a069880ecb2f37 on bramp:master.

Coverage decreased (-0.2%) to 81.394% when pulling 885bdeca4e807f5c42118a80546caad1e2cdfca0 on waitingHao:master into b7a9bd525a68c48e306f4e9150a069880ecb2f37 on bramp:master.


Mitigate value type torn writes during LRU update (enqueue)

During update check if the value is write atomic

If it is, just update it in place
Else make a new item, update the dictionary (now the item can be read after without tearing), mark the old item as removed and enqueue the new item

Queue cannot be updated in place, so we need to pollute with a dupe for this key in this case

The disadvantage of this approach is that for a large number of updates, the effective size of the cache will be reduced. This is not intuitive, and for very heavy update workloads would likely lead to worse write performance than locking on read/lock contention.

Superseded by https://github.com/bitfaster/BitFaster.Caching/pull/593


SOC from Victron SmartShunt

Is your feature request related to a problem? Please describe.
Hallo, is it possible to use the SOC reported from Victron SmartShunt instead the internal calculated SOC from JK?
Describe the solution you'd like
With dbus-spy I can read the SOC from Victron SmartShunt. So where do I have to tell the driver to use and show this value to the Victron system instead of the one reported from JK?
Describe alternatives you've considered
No response
Additional context
No response

On Venus console - Settings, system setup, Battery monitor

Sure but this doesn't fix the wrong SOC reported to the Victron system.
For example my system, Serial Bat says 75% SOC, as calculated by JKBMS. Victron SmartShunt says 50%.
If I set a SOC discharge limit in Voctron system to e.g. 50% it would still discharge the battery, until JKBMS reports 50% which might end up in 20% seen by the Victron SmartShunt.

True but which charge and discharge algorithm is used than? If you chose serial battery as monitor, it uses the values in the driver for charge and discharge limits.
If you set the monitor to SmartShunt, I guess charge and discharge limits are set by the victron algorithm?
The Problem is not, whos shows what in VRM. The problem is, who controls the limits.

Think you need to read through the options in config.default.ini

@Vitalic66 if you want the Smart Shunt to control the battery you need to set up the smart shinzo as Battery Monitor (Venus console - Settings, system setup, Battery monitor). This setup controls SOC, current and Voltages of the system
Additionally setup DVCC and setup controlling BMS - this setup will be used the control CVL, CCL and DCL

@DirkReudenbach thanks for the advice. Always thought that the choosen battery monitor overwrites DVCC settings from serial battery.

We will not add different SOC as the SOC from the battery itself. With the latest beta/nightly or stable from my branch you can correct the reading from the BMS. Since you have a SmartShunt you can perfectly adjust the BMS readings and make it more accurate.
https://github.com/Louisvdw/dbus-serialbattery/blob/5e025e66ff4887ee5ce3665789e5d2a14e63ec23/etc/dbus-serialbattery/config.default.ini#L152-L172


Add OpenApiSpec items in SDK projects by default

Motivation
Simpler and more consistent with C# projects.
Modifications
Automatically collect .json, .yaml, and .yml files in the project
directory and treat them as OpenApiSpec items. Add properties to
disable this behavior.

/merge


major patch

file fixes in release notes

no
From: codesandbox[bot] @.>
Sent: Tuesday, 15 October 2024 7:16 AM
To: SockyCat/Text-Adventure @.>
Cc: 25RobAnd @.>; State change @.>
Subject: Re: [SockyCat/Text-Adventure] major patch (PR #1)
Review or Edit in CodeSandbox
Open the branch in Web Editorhttps://codesandbox.io/p/github/SockyCat/Text-Adventure/patch-codespace-1?mode=review&utm_source=gh_app * VS Codehttps://codesandbox.io/p/vscode?owner=SockyCat&repo=Text-Adventure&branch=patch-codespace-1&utm_source=gh_app * Insidershttps://codesandbox.io/p/vscode?owner=SockyCat&repo=Text-Adventure&branch=patch-codespace-1&insiders=true&utm_source=gh_app
Open Previewhttps://codesandbox.io/p/devtool/preview/SockyCat/Text-Adventure/patch-codespace-1?task=preview&port=51423&redirect=true&utm_source=gh_app

Reply to this email directly, view it on GitHubhttps://github.com/SockyCat/Text-Adventure/pull/1#issuecomment-2412286425, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQA3GJHQP6BJM7ILNR2TMHDZ3QUPRAVCNFSM6AAAAABP5XMCE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJSGI4DMNBSGU.
You are receiving this because you modified the open/close state.Message ID<EMAIL_ADDRESS>