Sometimes, like with Google Fonts, there's no extension at the end of the URL

Hi,
Sometimes, like with Google Fonts, there's no extension at the end of the URL. Then we'll need to set the resource type to help toast to load the resource as expected :
load('[css]https://fonts.googleapis.com/css?family=Open+Sans');
it requires to modify code with something like
`  if (/.css$/.test(path)) {
isCss = true;

// css
e = doc.createElement('link');
e.rel = 'stylesheet';
e.href = path;

} else if (/^[css].+/.test(path)) {
isCss = true;

// css
e = doc.createElement('link');
e.rel = 'stylesheet';
e.href = path.substring(5);

} else if (/^[js].+/.test(path))  {
// javascript
e = doc.createElement('script');
e.src = path.substring(4);;
e.async = async === undefined ? true : async;

} else {
// javascript
e = doc.createElement('script');
e.src = path;
e.async = async === undefined ? true : async;

}`
Regards
Michel

Thanks for the suggestion! This issue actually came up recently (https://github.com/muicss/loadjs/issues/23) and at the time we decided to recommend that users add #.css as a workaround until we come up with a more permanent solution (i.e. loadjs('https://fonts.googleapis.com/css?family=Open+Sans#.css')).
If we want to handle this in a more permanent way, I'm partial to using "css+" as a prefix over "[css]" but I'm curious to hear what others think. Is there a standard syntax for indicating the expected content-type of a file in a url?

Not really. As I know require.js uses "css!".

Ok, thanks. Can you use #.css for now until we get more feedback?
Do you have a preference between "[css]", "css+", "css!" syntax?

@michelollivier I added support for "css!" prefix to the latest version of LoadJS (3.5.0):
https://github.com/muicss/loadjs
https://www.npmjs.com/package/loadjs
Let me know if you run into any problems using the feature.


Nodejs specify the image size

Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

Consider checking out SDK examples.
Have you looked in our documentations?
Is you question a frequently asked one?
Try searching our GitHub Issues (open and closed) for a similar issue.

All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

Required Info

Camera Model
{ D400 }

Firmware Version
(Open RealSense Viewer --> Click info)

Operating System & Version
Ubuntu 18.04

Kernel Version (Linux Only)
(5.4.0-54-generic)

Platform
PC

SDK Version
2.50

Language
nodejs

Nodejs
v10.22.0

Segment
Robot

Issue Description
Hello, I am currently use node-lirealsense for nodered. Here is the camera.js of our custom node. I am wondering if there is a way to specify the image size like this issue for nodejs. Where should I modify my code snippet? Could you please give me some hints? At the moment, the image size is 7201280, however, we would like to take image size of 512512. Thank you very much!!!!
// export the node module
module.exports = function(RED) {
    // define the node's behavior
    function RealSenseCameraNode(config_node_red) {
        // initialize the features
        RED.nodes.createNode(this, config_node_red);
        const node = this;
        const rs2 = require('/home/caixiaoni/Desktop/librealsense/wrappers/nodejs/index.js');
        const align = new rs2.Align(rs2.stream.STREAM_COLOR);
        const pipeline = new rs2.Pipeline(); //main work pipeline of realsense camera
        // Colorizer is used to map distance in depth image into different colors
        const colorizer = new rs2.Colorizer();

        profile = pipeline.start();
        // register a listener to get called whenever a message arrives at the node
        node.on('input', function(msg) {
            node.status({ fill: "green", shape: "dot", text: "connected" });
            const raw_frameset = pipeline.waitForFrames(); //get a set of frames
            const alignedFrameset = align.process(raw_frameset);
            let color = alignedFrameset.colorFrame;
            let depthFrame = alignedFrameset.depthFrame;

            // Build the color map
            const depthMap = colorizer.colorize(depthFrame);

            // handle incoming message
            msg.payload = color;
            msg.depth_colorized = depthMap;
	        msg.depth_data = depthFrame;
	        msg.profile = profile;
            node.send(msg);
        })

        node.on("close", function(done) {
            rs2.cleanup();
            done();
        });
    }

    // register the node with the runtime
    RED.nodes.registerType('realsense-camera', RealSenseCameraNode);
}

Hi @caixiaoniweimar   If your goal is to define a custom Node.js window size then how some of the RealSense SDK's Node.js example programs handle this is to import a pre-made script called 'glfw-window.js' and then specify the window size.  These instructions are placed in the script before the pipeline start instruction.  The link below highlights this window setup code in the nodejs-capture.js example program.
https://github.com/IntelRealSense/librealsense/blob/master/wrappers/nodejs/examples/nodejs-capture.js#L10-L14

Hi @caixiaoniweimar  Do you require further assistance with this case, please?  Thanks!


Use SqueakDisplayEntry in request for paginated rpc methods

Rather than including latest_block_height, latest_squeak_time, etc.

This should also fix: https://github.com/yzernik/squeaknode/issues/1151

https://github.com/yzernik/squeaknode/pull/1177


The documentation of abort/_set_abort_behavior should mention legacy behavior

In some circumstances, the Universal CRT's abort will use the Win32 function ExitProcess to end the current process. Due to implementation details, this will call back some global destructors, which clearly violates the C++ standard. For details, see the bug report I've filed about this phenomenon. In this bug report, I was told by Steve Wishnousky (@stwish-msft) that this is legacy behavior required because of compatibility reasons.
I think this should definitely be mentioned in the documentation page of both abort and _set_abort_behavior.

The intent of abort is clear: to terminate the program without any cleanup

+1. There's a both pragmatic and conceptual need for a standard, portable
fail-fast primitive.
Debating the finer points for where/how the DLLs fit into the overall
picture sounds like an interesting topic but it's a red herring regarding
abort(). Preserving broken behavior for back compat reasons is
understandable (up to a point) but it doesn't change the fact that that
it's it's a bug.
I'd urge the CRT team to take a closer look at this. Quoting from the
original bug report:
we found a large amount of code is dependent on the CRT calling

ExitProcess, primarily because it allows threads in other DLLs to continue
to run.

No, you don't want to allow other threads to run in a corrupted process
state.
On Wed, May 2, 2018 at 8:23 AM Donpedro13<EMAIL_ADDRESS>wrote:

I think it's wiser to approach this from a practical standpoint (instead
of playing the "the concept of a DLL is an implementation detail, so we can
do whatever we want" card, if you don't mind me being a bit sassy 😈).
The intent of abort is clear: to terminate the program without any
cleanup. The original case that made me file the bug report provides a
perfect practical example:

The OpenGL driver of a major graphics vendor encountered an
unrecoverable internal error
Because of this, they wanted to tear down the process, and they
called abort to do so
But due to this compatibility quirk, global destructors in DLLs ran
One of the destructors ended up calling into the OpenGL driver
This call crashed inside the driver, because it was in a corrupt
state (that's why it called abort earlier in the first place)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/cpp-docs/issues/219#issuecomment-386016668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANLyKSabrVA6TqniYmo1TQIPiggVJ5P1ks5tuc9hgaJpZM4Tty5v
.

Unless I bring it to their attention, the product team probably won't see any discussion here. If you want to argue for changes in the UCRT, which is maintained by the VC team but is now owned (in the sense of deciding what goes in and what can change) by the Windows team, I recommend you hash it out in the Developer Community forum, which does get read by the people who can make such decisions.
I'll agree the abort behavior is most problematic in a DLL that acts like a C++ library. But the DLL issue is hardly a red herring. After all, there's no reason to assume that a DLL is even written in C++, and the behavior of its runtime support is unknown. You can link any DLL at load time and call into it like a static library as long as it presents an appropriate ABI interface and you have the required header definitions, but you might have no idea what's under the hood. You can't make any assumptions about its runtime termination behavior, though a well written DLL will leave dynamic memory alone for the system to deal with on process termination. And even if a DLL is written in C++, remember, it's an independent image, and it gets its own copy of the CRT and runtime support, which means it gets its own runtime initialization code as well as its own cleanup code, which independently constructs statics and globals on init and calls their destructors on termination.
If you terminate a DLL without giving it a chance at an orderly disconnection from your process via a DLL_PROCESS_DETACH message, if that DLL that doesn't strictly adhere to the DLL guidelines, perhaps it could conceivably put other clients of that DLL in an inconsistent state. I don't know, but I'd guess that's why ExitProcess is called as a last option in the abort implementation, and not TerminateProcess.  Don't go there unless you know what you're terminating, and that it's okay to do so.
Just an idea, if you do own the DLL code, and you want abort behavior in it as well as your app, you could create an abort handler in the DLL to tell it to terminate itself without cleanup and then invoke it in whatever function you set with _set_abort_handler in your app. I haven't thought through all the details, but it seems doable. Or you could avoid creating global objects and independent statics in the DLL in the first place.

I'll agree the abort behavior is most problematic in a DLL that acts like
a C++ library. But the DLL issue is hardly a red herring. After all,
there's no reason to assume that a DLL is even written in C++, and the
behavior of its runtime support is unknown.

Correct, which is one of the reasons I said that DLLs are not special (and
a red herring): hybrid processes are not uncommon - you can have a
combination of native code, managed runtimes and JITTed code, etc. DLLs are
just a mechanism to load a mix of code & data into a process - but the
latter (the process) is the "program" in the Win32 world.
I'd love to see the C++ committee continuing the trend towards stricter and
clear specification of core concepts (similar to the treatment of threading
and memory models). But in this case the situation is already fairly well
defined:

[support.start.term]The function abort() has additional behavior in this
International Standard:— The program is terminated without executing
destructors for objects of automatic, thread, orstatic storage duration and
without calling functions passed to atexit() (3.6.3).*

If you terminate a DLL without giving it a chance at an orderly
disconnection from your process via a DLL_PROCESS_DETACH message, if that
DLL that doesn't strictly adhere to the DLL guidelines, perhaps it could
conceivably put other clients of that DLL in an inconsistent state.

I'm not sure what this mean. A process can abruptly terminate for a
multitude of reasons (you can't prevent that), so a robust system must
account for that already.
On Thu, May 3, 2018 at 1:37 PM Colin Robertson<EMAIL_ADDRESS>wrote:

Unless I bring it to their attention, the product team probably won't see
any discussion here. If you want to argue for changes in the UCRT, which is
maintained by the VC team but is now owned (in the sense of deciding what
goes in and what can change) by the Windows team, I recommend you hash it
out in the Developer Community
https://developercommunity.visualstudio.com/spaces/62/index.html forum,
which does get read by the people who can make such decisions.
I'll agree the abort behavior is most problematic in a DLL that acts
like a C++ library. But the DLL issue is hardly a red herring. After all,
there's no reason to assume that a DLL is even written in C++, and the
behavior of its runtime support is unknown. You can link any DLL at load
time and call into it like a static library as long as it presents an
appropriate ABI interface and you have the required header definitions, but
you might have no idea what's under the hood. You can't make any
assumptions about its runtime termination behavior, though a well written
DLL will leave dynamic memory alone for the system to deal with
https://msdn.microsoft.com/library/windows/desktop/ms682583(v=vs.85).aspx
on process termination. And even if a DLL is written in C++, remember, it's
an independent image, and it gets its own copy of the CRT and runtime
support, which means it gets its own runtime initialization code as well as
its own cleanup code, which independently constructs statics and globals on
init and calls their destructors on termination.
If you terminate a DLL without giving it a chance at an orderly
disconnection from your process via a DLL_PROCESS_DETACH message, if that
DLL that doesn't strictly adhere to the DLL guidelines, perhaps it could
conceivably put other clients of that DLL in an inconsistent state. I don't
know, but I'd guess that's why ExitProcess is called as a last option
in the abort implementation, and not TerminateProcess.  Don't go there
unless you know what you're terminating, and that it's okay to do so.
Just an idea, if you do own the DLL code, and you want abort behavior
in it as well as your app, you could create an abort handler in the DLL to
tell it to terminate itself without cleanup and then invoke it in whatever
function you set with _set_abort_handler in your app. I haven't thought
through all the details, but it seems doable. Or you could avoid creating
global objects and independent statics in the DLL in the first place.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/cpp-docs/issues/219#issuecomment-386428575,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANLyKZ4EZaKzNx_JOpIfjUbvvbtaFf8Qks5tu2p1gaJpZM4Tty5v
.

I'll grant you the common process argument. I was trying to figure out what kind of DLL process would require a thread still running in this situation, and as you imply, it all seemed far-fetched. So I went and looked more closely at the UCRT source code published in the Windows SDK, which was enlightening.
As near as I can tell, it's not possible to execute the abort implementation code path that calls ExitProcess in a release build, unless perhaps you go and edit the registry or your image to set a global flag (FLG_APPLICATION_VERIFIER) that is, shall we say, unusual for a release build. Just eyeballing what's going on in the source code in exit.cpp (in the ucrt\startup directory), this looks like an issue where ExitProcess is called only for debug builds,  specifically (according to the comments) so analysis tools have a chance to run. Otherwise, TerminateProcess gets called.
Am I reading this correctly? As near as I can tell, you can only get the complained-about abort behavior when you follow a particular sequence in dealing with the termination handling UI, and only in debug builds.

Thanks for looking into it. Unfortunately, hitting the _exit(3) path is as
easy as clearing the _CALL_REPORTFAULT flag:
_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT);
This is not uncommon in environments where the debug dialogs are not
desirable (here's a quick example
https://github.com/google/googletest/blob/43776990663c08c4d207658bc5756058da1040bf/googletest/src/gtest.cc#L4655).
Then, the _exit() implementation is problematic (as in trying to do way too
much). In particular, by default it will call ExitProcess() for desktop
applications (the function comment for should_call_terminate_process() is
relevant here).
That ship has sailed though. My concern, and the reason I chimed in here,
was the attempt to rationalize the current behavior as conformant: it is
not, and a word of caution seems appropriate (the OP's request).
On Thu, May 3, 2018 at 5:44 PM Colin Robertson<EMAIL_ADDRESS>wrote:

I'll grant you the common process argument. I was trying to figure out
what kind of DLL process would require a thread still running in this
situation, and as you imply, it all seemed far-fetched. So I went and
looked more closely at the UCRT source code published in the Windows SDK,
which was enlightening.
As near as I can tell, it's not possible to execute the abort
implementation code path that calls ExitProcess in a release build,
unless perhaps you go and edit the registry or your image to set a global
flag (FLG_APPLICATION_VERIFIER) that is, shall we say, unusual for a
release build. Just eyeballing what's going on in the source code in
exit.cpp (in the ucrt\startup directory), this looks like an issue where
ExitProcess is called only for debug builds, specifically (according to
the comments) so analysis tools have a chance to run. Otherwise,
TerminateProcess gets called.
Am I reading this correctly? As near as I can tell, you can only get the
complained-about abort behavior when you follow a particular sequence
in dealing with the termination handling UI, and only in debug builds.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/cpp-docs/issues/219#issuecomment-386478377,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANLyKWa25LA1jb4qHGG3GOl49hAQIp3hks5tu6SIgaJpZM4Tty5v
.

An update is visible now.


Understanding the need for random variable and placeholder id's

I'm having difficulties trying to understand the need for the optional :id's that can be assigned to random variables and placeholders. I'm also trying to understand how to use them.
For example, in demo 1, the following script defines two random variables to which the id's :m_x_t_min and :v_x_t_min are implicitly assigned.
# declare priors as random variables
@RV m_x_t_min # m_x_t_min = Variable(id=:m_x_t_min)
@RV v_x_t_min # v_x_t_min = Variable(id=:v_x_t_min)

Afterward,  2 placeholders are defined to which the exact same id's are assigned, but this time explicitly.
# Placeholders for prior
placeholder(m_x_t_min, :m_x_t_min) # placeholder(:m_x_t_min) does not work
placeholder(v_x_t_min, :v_x_t_min)

When feeding data to the algorithm, the id's are vaguely referring to the placeholders and not to the random variables (they both have the same name).
# Prepare data and prior statistics
data = Dict(:y_t       => y[t],
            :m_x_t_min => m_x_t_min,
            :v_x_t_min => v_x_t_min)

I find this somewhat obscure. Is there a way in which we could make these id's transparent to the user?

From a technical perspective, we may say that the Variable with id :m_x_t_min has a belief associated with it that is a dirac-delta function for which the location parameter is read in from data[:m_x_t_min]. I agree that this is too confusing and we should simplify the exposition, especially in the first demo.
My suggestion is to remove the prior declarations and trailing placeholders for the prior statistics, and directly define the state prior as
@RV x_t_min ~ GaussianMeanVariance(placeholder(:m_x_t_min), placeholder(:v_x_t_min))

This better underlines the idea that prior statistics can be fed to the algorithm via the data dictionary.


[ Functionality ] : Addition of Self+Line Following logic in this project

Adding a separate folder for the Line and Self balancing
Should be written according to the latest ESP-IDF (v5.1)
Testing the code with the latest hardware

Updates on the issue:
Code for the Line+Self was written and tested on a prototype bot without a battery pack, it wasn't very stable and couldn't follow the line over a considerable distance.
The code can be found here: Link
The following changes can help the contributors:

Try running the robot in a straight line without line sensor readings and without making the bot fall
Note the optimum setpoint, and speeds (PWM) for the above case, and then use the same parameters for self-balancing as per the previous test and then try tuning the bot for line following task

I will add the videos of previous test as soon as I find them


Add information on manually installing Typescript plugin. (#2727)

What kind of changes does this PR include?

New or updated content

Description

Closes #2727
What does this PR change? Adds information on how to manually install typescript plugin.
Did you change something visual? A before/after screenshot can be helpful.

Thanks for this PR, this needs to be documented!
This should go in the TypeScript guide, rather than the Installation guide, as the TypeScript guide covers tsconfig.json and is where someone would go if they're experiencing weird TS behavior in their editor. We can then link to it from this installation guide.
Feel free to move it, or let me know and I'll push to this branch.

Just checking up on this @feraleyebrows! I know there was discussion about this, and we decided this should go on the TypeScript page itself. I'm sure @Jutanium is still happy to move this there for you, if that's easier!

I’ll try and get round to it

@sarah11918 @Jutanium done


Adopt the native metrics format of OpenTelemetry

As we discussed today, I open this issue to track the progress about adopting the native(GA recently?) native metrics format from OpenTelemetry collector. We should support to transfer the data to our MetricFamily, and MAL engine could support this consistently.

@liqiangz Could you take a look about this?

@liqiangz Could you take a look about this?
@wu-sheng I will try to finish it～

I think as same as OpenTelemetry logging, we could accept supporting their native format, or adding our native meter exporter to there, or both.

Now the interface provided by MeterReportService is One period data through one stream. There is no problem with a small amount of data as the agent. However, when a large amount of data is transmitted from the server to the server, the overhead of frequently creating streams is very large.
Maybe we can provide a encapsulated request like opencensus, so that we can use keep-alive-stream to improve performance.
The follow is the benchmark in https://github.com/liqiangz/opentelemetry-collector-contrib/blob/log-3/exporter/skywalkingexporter/skywalking_benchmark_test.go
keep alive stream
The number of goroutines:1,  The number of streams:1,  Sent: 10000 items (196/millisecond),  Receive: 10000 items (192/millisecond)
The number of goroutines:2,  The number of streams:2,  Sent: 10000 items (294/millisecond),  Receive: 10000 items (285/millisecond)
The number of goroutines:4,  The number of streams:4,  Sent: 10000 items (357/millisecond),  Receive: 10000 items (357/millisecond)
The number of goroutines:5,  The number of streams:5,  Sent: 10000 items (434/millisecond),  Receive: 10000 items (434/millisecond)
The number of goroutines:10,  The number of streams:10,  Sent: 10000 items (476/millisecond),  Receive: 10000 items (416/millisecond)

One stream One Request
The number of goroutines:1,  Sent: 10000 items (2/millisecond),  Receive: 10000 items (2/millisecond)
The number of goroutines:2,  Sent: 10000 items (5/millisecond),  Receive: 10000 items (5/millisecond)
The number of goroutines:4,  Sent: 10000 items (15/millisecond),  Receive: 10000 items (15/millisecond)
The number of goroutines:5,  Sent: 10000 items (18/millisecond),  Receive: 10000 items (18/millisecond)
The number of goroutines:10,  Sent: 10000 items (40/millisecond),  Receive: 10000 items (40/millisecond)

and opencensus proto
// Service that can be used to push metrics between one Application
// instrumented with OpenCensus and an agent, or between an agent and a
// central collector.
service MetricsService {
  // For performance reasons, it is recommended to keep this RPC
  // alive for the entire life of the application.
  rpc Export(stream ExportMetricsServiceRequest) returns (stream ExportMetricsServiceResponse) {}
}

message ExportMetricsServiceRequest {
  // This is required only in the first message on the stream or if the
  // previous sent ExportMetricsServiceRequest message has a different Node (e.g.
  // when the same RPC is used to send Metrics from multiple Applications).
  opencensus.proto.agent.common.v1.Node node = 1;

  // A list of metrics that belong to the last received Node.
  repeated opencensus.proto.metrics.v1.Metric metrics = 2;

  // The resource for the metrics in this message that do not have an explicit
  // resource set.
  // If unset, the most recently set resource in the RPC stream applies. It is
  // valid to never be set within a stream, e.g. when no resource info is known
  // at all or when all sent metrics have an explicit resource set.
  opencensus.proto.resource.v1.Resource resource = 3;
}

message ExportMetricsServiceResponse {
}

@wu-sheng @kezhenxu94 @mrproliu Could you please give some suggestions about this?

@liqiangz Thanks for the feedback, but I am a little confused about what you are asking for.
This service is already streaming, which means you could deliver the metrics in a bulk mode, rather than once per time.
https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto#L31

@liqiangz Thanks for the feedback, but I am a little confused about what you are asking for.
This service is already streaming, which means you could deliver the metrics in a bulk mode, rather than once per time.
https://github.com/apache/skywalking-data-collect-protocol/blob/master/language-agent/Meter.proto#L31

@wu-sheng A ResourceMetrics in the OTLP protocol contains a collection of metrics from a Resource. This is a suitable unit for converting metricList to meter system processing. Now skywalking otel-receiver-plugin also does the same. But now the meter service is a metricList in a stream.
    @Override
    public StreamObserver<MeterData> collect(StreamObserver<Commands> responseObserver) {
        final MeterProcessor processor = processService.createProcessor();
        return new StreamObserver<MeterData>() {
            @Override
            public void onNext(MeterData meterData) {
                try (HistogramMetrics.Timer ignored = histogram.createTimer()) {
                    processor.read(meterData);
                } catch (Exception e) {
                    errorCounter.inc();
                    log.error(e.getMessage(), e);
                }
            }

            @Override
            public void onError(Throwable throwable) {
                processor.process();
                log.error(throwable.getMessage(), throwable);
                responseObserver.onCompleted();
            }

            @Override
            public void onCompleted() {
                processor.process();
                responseObserver.onNext(Commands.newBuilder().build());
                responseObserver.onCompleted();
            }
        };
    }

If we want to transmit another metricList, we must open another stream. My opinion is to add a service like
 rpc collect (stream MeterDataList) returns (Commands) {
     },

so we can use one stream to transmit multiple MeterDataList.

Another solution is to implement format conversion in skywalking like otel-receiver-plugin, so that using the otlp protocol for transmission, there is no need for a metriclist in a stream.

OK, so you means entity reused, right?
The metricList includes metrics from one entity?

OK, so you means entity reused, right?
The metricList includes metrics from one entity?

@wu-sheng   Yes, and the new rpc interface rpc collect (stream MeterDataList) returns (Commands) {       } can also be reused.
Do you think we can add a new grpc service like this?  If can,  I will use this  to complete this issue.

Yes, I think it is reasonable to add. We need to review protocol first.

@liqiangz What is your progress?
There is another update about OTEL's native metrics format, https://github.com/open-telemetry/opentelemetry-specification/pull/2104. It seems finally being stable.

And I noticed, implementation of https://github.com/apache/skywalking-data-collect-protocol/pull/56 has not been updated in OAP side. Is that coming soon?

@liqiangz What is your progress?
There is another update about OTEL's native metrics format, open-telemetry/opentelemetry-specification#2104. It seems finally being stable.

I should be able to finish it in this week.

Reopen this, as OpenTelemetry side work is still in TODO status.

@wu-sheng  I have submitted a pr in opentelemetry https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/6528. Gauge, Sum, Histogram have been supported. However, the Summary type is not yet supported for two reasons:  1. Protocol does not support summary  2. Mal does not support summary

Thanks. And yes, we don't support summary directly.
We supported this in OAP Prometheus fetcher by using 2 guage metrics instead of a new type.

Thanks. And yes, we don't support summary directly. We supported this in OAP Prometheus fetcher by using 2 guage metrics instead of a new type.

@wu-sheng
I saw the conversion of the Summary type to the quantile tag data in the PrometheusMetricConverter, but at present I have not found a way to deal with this kind of data in the SampleFamily. The other two guage metrics should be count and sum.

Could you be more clear about what you can't do in SampleFamily?

Could you be more clear about what you can't do in SampleFamily?

@wu-sheng We converted the Histogram data into the data of the le label. There is a method histogram in mal to process the data of this kind of le label. There is no similar processing method for the data of the quantile tag.

The codes of Prometheus fetcher was added first, but little used because most use OpenTelemetry collector or Satellite to do that. So, you could add quantile tag in the exporter directly. MAL doesn't have to be aware of this tag in the kernel level, the people writing MAL script knowing this should be enough. You could put this kind of added-tags logics in the document.

The codes of Prometheus fetcher was added first, but little used because most use OpenTelemetry collector or Satellite to do that. So, you could add quantile tag in the exporter directly. MAL doesn't have to be aware of this tag in the kernel level, the people writing MAL script knowing this should be enough. You could put this kind of added-tags logics in the document.

Ok, I will put the label directly.

The codes of Prometheus fetcher was added first, but little used because most use OpenTelemetry collector or Satellite to do that. So, you could add quantile tag in the exporter directly. MAL doesn't have to be aware of this tag in the kernel level, the people writing MAL script knowing this should be enough. You could put this kind of added-tags logics in the document.

Ok, I will put the label directly.

Thanks. Later(after that gets merged), we could discuss where we should describe these labels in the documents. I think you have seen the v9 is coming, so, we have enough time about this new input.

@liqiangz Any update about this at OpenTelemetry collector side?

@liqiangz Any update about this at OpenTelemetry collector side?

It’s still under review. I guess it should be possible to be merged within a week.

@wu-sheng the pr has been merged.

Cool! We should update this doc as well, https://skywalking.apache.org/docs/main/latest/en/setup/backend/backend-meter/

Cool! We should update this doc as well, https://skywalking.apache.org/docs/main/latest/en/setup/backend/backend-meter/#meter-collection

Okay, I will update the document in these two days.

Rename Meter collection to Report Meter Telemetry Data. One is today's manual APIs, another is OpenTelemetry Exporter.
Also, this doc should be updated, https://skywalking.apache.org/docs/main/latest/en/setup/backend/opentelemetry-receiver/#opentelemetry-receiver. All existing parts belong to OpenCensus exporter, we should guide users to meter doc page if they want to use SkyWalking Exporter.


Make Thing RPC interruptable and thread-safe

modified cli, also uses poller

[ ]  Make RPC non-blocking, but no timeout on calls.
[ ] Make Thing thread-safe, so socket cannot get locked.


Top Bar PFP

Gets rid of the user icon next to your name in the menu bar (the one with home, profile, etc.) to be more accurate to 2016

@anthony1x6000 ?

mb - it would better the faithfulness of the style to roblox in 2016, but I don't want to take away the functionality of the site.
Preferrably, I would like to process this change as an optional feature.

mb - it would better the faithfulness of the style to roblox in 2016, but I don't want to take away the functionality of the site. Preferrably, I would like to process this change as an optional feature.

Yea feel free to do that, I don't mind you changing things. I tried to add this is as an option using "@var checkbox" but it didn't work out for me (im a css noob).

i looked into some documentation I found here and tried the @ var and advanced tags but i could not get them to work.
Theres probably something conflicting within the style that is preventing the expected functionality.
I'm gonna have to dedicate some time trying to figure it out because the userstyle has gotten really messy and unorganized over the years I've been updating it - I started as a css noob too maintaining this style in 2019 so there's a lot of redundant rules scattered throughout the style 😔

Either way if you cant figure it out dont worry about it, someone could find a fix and contribute and if not then people could always just paste my css at the bottom. Also I usually don't contribute to projects but I found that your userstyle was the only accurate non-broken and complete 2016 theme so for that I give props.
Also you should check out making this guy's themes compatible because they are 1:1 with 2016:
https://uso.kkx.one/browse/styles?search=%401185261

I see mostly public domain licenses by them so I might paste in what they created already. Thanks, it'll def save a lot of work

kk found the thing messing with variable functionality and fixed it in a recent commit


Only show mismatched data between received & verified when failing on build server/terminal

Is the feature request related to a problem
When verification of an object fails in a build server context, the entirety of both files (received & verified) are printed to the server's output. If the object being verified is a really large object (in my case, an entire DbContext instance using the .AllData() extension) the output window is flooded with two copies of the object which could be thousands of lines long - when only one line in the file could be different.
Describe the solution
Instead of dumping the full extent of both files, I would suggest a setting to "fold" or omit unchanged lines from the output should the verification fail. This keeps the overall output from the test small while still presenting the user/developer with the required information to fix the test.
I would also suggest that x amount of lines around the diffed line should be shown to provide context & line numbers should be preserved. This could also be a setting, but equally ~5 lines by default is probably fine.
Describe alternatives considered

Splitting the single "large" test into individual tests for each property (or entity set in my case)

This will blow out the size of my test fixtures and just provides more code for the same value

Only snapshotting/verifying the data that's expected to change

This makes sense in most cases, but the for tests I'm having this problem with I want to ensure that the entire object/DbContext hasn't changed

Additional context
Assuming you're happy with the design, I would be more than happy to implement this feature as it benefits both my work and personal projects using this library. Love the library, found it through Dan's Unhandled Exception podcast 🎉

perhaps Diffplex with Compact output would work? https://github.com/VerifyTests/Verify.DiffPlex#output-types

I think that solves my problem. I'll double check later today and if that's the case, I'll close this issue off. Cheers Simon!

did that work for you?

Sorry, yes it did! Cheers.

@jammehcow glad it worked


Virtlet docs describing networking and SyncPod workflow

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


update installation steps, document EL installation

Fixes https://github.com/packit/packit/issues/278

You were faster, by my #252 is more verbose :-)
I borrowed your section titles into it.
You've been assimilated, muhehehehe

Okay then,


[BUG] IP Pool create/edit menu does not allow specifying guestCluster or project scopes, only namespace scope

Describe the bug

The IP Pool's scope[1] can be limited via namespace, project, or guestCluster, but the UI only allows selecting a Namespace scope.
When a guest cluster uses cloud-provider-harvester and creates a Service of type: LoadBalancer, the Harvester load balancer is stuck in a pending state with this error:
Allocate ip for lb default/x failed, error: fail to select the pool for lb default/x,
error: no matching IP pool with requirement &{
    Network:default/NET-NAME
    Project:x Namespace:default
    Cluster:CLUSTER-NAME
}

The workaround is to edit the IP Pool YAML:
spec:
  selector:
    network: default/NET-NAME
    scope:
      - guestCluster: 'CLUSTER-NAME'
        namespace: 'default'
        project: '*'

Or make it a global IP Pool:
spec:
  selector:
    network: default/NET-NAME
    scope:
      - guestCluster: '*'
        namespace: '*'
        project: '*'

[1] https://github.com/harvester/load-balancer-harvester/blob/f126dae3da1a2bec44bff4966d3519c793d31a02/pkg/apis/loadbalancer.harvesterhci.io/v1beta1/ippool.go#L50
To Reproduce
Steps to reproduce the behavior:

Go to Harvester dashboard > Networks > IP Pools
Click Create > Selector
Click Add scope
Observe that only the Namespace scope can be specified on the UI.

Similar steps can be used for a pre-existing IP Pool, just click Edit Config > Selector.
Expected behavior

Support bundle

Environment

Harvester ISO version:
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Hi @connorkuehl In order to configure the project and the guest Kubernetes cluster fields when creating a load balancer IP pool, you'll need to enter the Harvester dashboard from the external Rancher Manager's Virtualization Management page.

And yes, directly creating/editing the IPPool manifest does not have such limitations.


Implement New Properties and Events of Date Picker Component

https://ix.siemens.io/docs/controls/date-picker/
Added properties

i18nDone
locale
weekStartIndex

Deprecated properties

textSelectDate

Added events

dateChange
dateRangeChange

Bunu implement etmek istiyorum.

Please don't forget to add this component into README file too. @GokceOzkan

eventDelimeter is also deprecated (see dateChange)

you are right! @GokceOzkan. I edited the comment.

#43


Bug: Space after frontmatter is not respected when frontmatter is created

[x] I have verified that I am on the latest version of the Linter

Describe the Bug
When a new frontmatter block is created, the space after is not also created. This results in linting twice in a row producing different results.
How to Reproduce
Steps to reproduce the behavior:

Ensure the "Add Blank Line After YAML" setting is enabled
Enable any YAML timestamp
Create a new note without any frontmatter
Lint that note
Observe that there is no space between the frontmatter and the content
Lint again

Expected Behavior
I expect the linting to be idempotent.
Device

[x] Desktop
[x] Mobile

Additional Context
I believe this is irrespective of which rules result in the creation of frontmatter, so I skipped my whole rule config, etc.

Hey @chmac . This is expected behavior. The description of that rule says Adds a blank line after the YAML block if it does not end the current file or it is not already followed by at least 1 blank line. So if the file does not currently have content after the YAML frontmatter that is not whitespace, no blank line is added until some content is added after the frontmatter and the file is linted again.

Is this still an issue given the description of the rule?

@pjkaufman I think so, yes. The situation I'm describing is starting without any YAML block, just any content in the file. Then the YAML block gets inserted, and does not have a blank line after it. From my understanding there must always be a blank line, unless the file ends after the block, which is not the case I'm describing.
For examlpe, after running the linter the first time I get this:
---
created_at: xxx
---
Content

But if I lint it immediately again, I get this:
---
created_at: xxx
---

Content

Sorry, I could have posted the example in my original issue, would have been clearer. I think the first example doesn't comply with the rule if I understood it correctly.

Ah. I see. This is another order of operations issue.

The issue is that this rule needs to run after the YAML timestamp rule if the frontmatter does not exist and before it if it does. That is a fixable problem, it just needs a little work to run that way.

@pjkaufman Makes sense. What about running the rule twice? Don't know if that makes anything easier, was just a thought. :)

I believe I have a fix for this scenario. I am just adding one more integration test for this to make sure it is indeed working.

Looks like it passes the tests. I will go ahead and create a PR for this change.

The fix for this should be on master and go out with the next release. If there is an issue with either please let us know.

@pjkaufman Thanks so much. I'm really impressed with how responsive you've been to the couple of issues I posted. Obsidian Linter makes my Obsidian experience a whole lot better, thanks. 🧡

I am glad to hear that. I can often forget about issues, so I am trying to get better at that.
Thanks for bringing up these issues! The more issues that are fixed, the better the Linter can be.


Test Class Not Executing as Expected

If I create a class with the single test its discoverable (it can be seen in the Test Explorer) and executable:
public class ClickLinkTests()
{
    [Test]
    public async Task ClickLinkTest()
    {
        //My Test Code...
    }
}

But if I make that class a subclass and add a MethodDataSource attribute it is no longer discoverable.
public class ClickLinkTests() : SauceryTBase
{
    [Test]
    [MethodDataSource(typeof(RequestedPlatformData), nameof(RequestedPlatformData.AllPlatforms))]
    public async Task ClickLinkTest(BrowserVersion requestedPlatform)
    {
        //My Test Code...
    }
}

Using TUnit 0.4.83
EDIT:
Subsequently got discoverability (with a List<Func<>>) but ParallelLimiter seems to be failing after the first batch. Limiting the parallel batches is important in my context cause SauceLabs accounts have parallel test limits, so the test driver needs to restfully check SauceLabs for available headroom and feed in tests in a controlled manner.

Can you try v0.4.83?

Kinda works with TUnit 0.4.74 but not really. No better or worse with v83.
Had hoped ParallelLimiter would make it work. It did a little but now tests are hanging after the first batch. 2 of the first batch failed on SauceLabs due to command time out after 90 seconds.
TUnit is just hanging it seems:

I don't have this problem with NUnit and XUnit integration with SauceLabs.

Have a look at these:
https://github.com/Sauceforge/Saucery/tree/master/Merlin.TUnit
https://github.com/Sauceforge/Saucery/tree/master/Saucery.TUnit

TUnit has some really nice features.  Must be something I haven't quite done right.
The DataDrivenTest.cs is not currently being discovered by TUnit

I'll try and clone and take a look when I get some time

I'll try and clone and take a look when I get some time

You'll need a trial SauceLabs account to use Saucery.

The DataDrivenTest.cs is not currently being discovered by TUnit

It is but it's failing initialization. Because your test data is throwing an exception. BrowserVersions is null and you're trying to do a LINQ query on it:

Let me check when I have time and I'll report back

Is this sorted now?


400 Invalid Resource - Products

I'm attempting to do some e-commerce work and make a call to /ecommerce/stores/{store_id}/products but I'm getting the following error. The variants field is definitely an array.
["title"]=> "Invalid Resource",
["status"]=> 400,
["detail"]=> "The resource submitted could not be validated. For field-specific details, see the 'errors' array.",
["instance"]=> "",
["errors"]=> array(1) {
[0]=>  array(2) {
["field"]=>"variants",
["message"]=>"Schema describes array, object found instead"
}
}

@Rizsti
Dear Andrea,
How have you fixed the problem ?
Thank you.


Startup directory related routing bug ASP.NET core targeting net461

Hello,
I hope this isn't the wrong place for this. If so, please point me to where I should post this. Thanks in advance!
I'm using net461 (the bug seems to appear on net451 for that matter) and having a test project with a TestStartup class that, internally, uses the original Startup class from the main project. However when I try to create a TestServer and use it's test client to access my controllers I keep getting 404 errors.
A small, reproducing repository example can be found at https://github.com/erik-lundgren/net461-startup-repro.
If I switch to netcoreapp1.0 in the reproducing repository the issue goes away (try it yourself by switching to the desired branch. However, because I am dependent on several projects that don't target netcoreapp1.0 I can't switch to it in my real project.
If I move the TestStartup class to the main project it also works perfectly, but I don't want to pollute that project with my testing mocks and such, so it's not a good solution for me either.
If this is intended behaviour, how can I use a separate startup class for my test project (to mock out certain webservices or the like)?

Check the following code which is used to do in-memory integration tests in MVC. I guess you might need to something like the highlighted line here? cc @javiercn
https://github.com/aspnet/Mvc/blob/1.0.0/test/Microsoft.AspNetCore.Mvc.FunctionalTests/MvcTestFixture.cs#L65

That resolves the issue for me in my project, thanks a lot for the help.
For reference I added these lines to my TestStartup ConfigureServices method, after startUp.ConfigureServices(services); (line 33):
var startupAssembly = typeof(Startup).Assembly;

 // Inject a custom application part manager. Overrides AddMvcCore() because that uses TryAdd().
var manager = new ApplicationPartManager();
manager.ApplicationParts.Add(new AssemblyPart(startupAssembly));

manager.FeatureProviders.Add(new ControllerFeatureProvider());

services.AddSingleton(manager);

Still curious if it's intended that netcoreapp1.0 behaves differently than net461. If so, you can close this.
Thanks for the help!

It would be good to know why this is necessary and whether it is the most appropriate solution — thanks in advance.

Hi,
I've put together a blog post and a sample on how to do this with test server.
The blog post is here:
https://blogs.msdn.microsoft.com/webdev/2017/12/07/testing-asp-net-core-mvc-web-apps-in-memory/
The sample is here:
https://github.com/aspnet/samples/tree/master/samples/aspnetcore/mvc/testing/TestingMVC
It's important to note that you need to run the tests using either Visual Studio or dotnet test. There are some issues that we are investigating regarding running the tests with dotnet xunit at the time.
If you still have problems after this, feel free to reopen the issue.


Registers as success even when an EXPECT_CALL fails

Thank you very much! This library has a really nice set of functionality which I missed in gmock. I just started to experiment with jomock and observed that tests seem to register as success even when an EXPECT_CALL fails. I also added a gmock test (OrderTest.Fill) without using jomock to check the behaviour there.
[==========] Running 2 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 1 test from OrderTest
[ RUN      ] OrderTest.Fill
GMOCK WARNING:
order.cpp:44: Too few actions specified in EXPECT_CALL(warehouse, hasInventory(50, "Talisker"))...
Expected to be called twice, but has only 1 WillOnce().order.cpp:44: Failure
Actual function call count doesn't match EXPECT_CALL(warehouse, hasInventory(50, "Talisker"))...
Expected: to be called twice
Actual: called once - unsatisfied and active
[  FAILED  ] OrderTest.Fill (0 ms)
[----------] 1 test from OrderTest (0 ms total)
[----------] 1 test from example
[ RUN      ] example.sum_zero
[       OK ] example.sum_zero (0 ms)
[----------] 1 test from example (0 ms total)
[----------] Global test environment tear-down
[==========] 2 tests from 2 test suites ran. (0 ms total)
[  PASSED  ] 1 test.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] OrderTest.Fill
1 FAILED TEST
Failure
Actual function call count doesn't match EXPECT_CALL(*::jomock::MockerCreator::getJoMock<::jomock::TypeForUniqMocker<0>>(aMaster_initialize, "aMaster_initialize"), stubFunc())...
Expected: to be called twice

Please share the code example for this failure case.
OS?
Compiler?
non-virtual function? and so on..

The mocked functions are a set of free functions.
The calling code is:
#include <gtest/gtest.h>
#include <gmock/gmock.h>
#include <jomock.h>

#include <Master/Sm/MasterSm.h>

TEST(MasterSM, init)
{
    EXPECT_CALL(JOMOCK(aMaster_initialize), JOMOCK_FUNC()).Times(testing::Exactly(2));
	MasterVSInitAll();
}

OS: Ubuntu 20.04
Compiler: gcc 9.3

Same behaviour on Windows 10 with VS2019

from your first report, "hasInventory" method called once with argument, (50, "Talisker").
please check the second method call has different argument and you also specify the argument in the JOMOCK_FUNC with (50, "Talisker") only.. then gmock's error code can be displayed like that.
for the second case..
is the MasterSm an external library? can you share how the "aMaster_initialize" function is declared?

UnitTesting.zip
I have created a minimal cmake project to show my observations.
The expected behaviour is that both tests fail.

I just got the result of your test code in vs2019

First of all,
It seems that the target methos are not called twice.
TEST(MasterSM, init)
{
    EXPECT_CALL(JOMOCK(aMaster_initialize), JOMOCK_FUNC()).Times(testing::Exactly(2)); // should be Exactly(1)
	MasterVSInitAll();
}

and...
    EXPECT_CALL(warehouse, hasInventory(50, "Talisker"))
        .Times(2) // should be .Times(1)
        .WillOnce(Return(true));

After changing it to "1" result is clean.

vs2019_example (2).zip

Call hierarchy is as below:
OrderTest.Fill ->
order.fill ->
warehouse.hasInventory (return true) ->
warehouse.remove ->
mailService.send ->
return
return
return

I have just added the OrderTest to show that gmock without jomock gives the expected results.
When the OrderTest is fixed, I get wrongly two passed tests even though the method aMaster_initialize was not called twice:

add clear function at the end of JOMOCK test.
TEST(MasterSM, init)
{
    EXPECT_CALL(JOMOCK(aMaster_initialize), JOMOCK_FUNC()).Times(testing::Exactly(2));
	MasterVSInitAll();
	CLEAR_JOMOCK();
}

then you can get the right result as below

Thank you very much! This does the job.


[stable/parse] Add support to Cloud Code scripts & lint chart

Signed-off-by: juan131<EMAIL_ADDRESS>Is this a new chart
No
What this PR does / why we need it:
This PR adds support to pass custom Cloud Code scripts to Parse Server. It also lints the chart.
Which issue this PR fixes

fixes https://github.com/bitnami/charts/issues/1500

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test
/lgtm


Emissive materials only rendering when lit by directional light

Was experimenting with emissive materials for spheres and noticed that only the lit areas were rendering.
When testing I found that if I turned on ambient light and det the diffuse color to something other than black it rendered out the part that should be emissive in the diffuse color.
So basically emissive materials only render the faces of a mesh that are lit by a directional light.
Modified the cube example to demonstrate this: My fork's example edit
Hope to get this resolved!
/Albin

Changes

@cwfitzgerald

Idk just reminding about this... I don't know if it's fixed in the main branch but it isn't in 3.0, if it's fixed please close the issue @cwfitzgerald


Incoming Transactions - Tokens showing more 0's than they should

Problem:
In the following image the tokens REP, BAT and ZRX are showing more than they should. It should be 100 REP, 100 BAT, 90 ZRX

URL: https://safe-team.dev.gnosisdev.com/app/#/safes/0xc3214e72A53695faC3A124C92FcA3f161D193299/transactions
Steps:
Just faucet some tokens from here: https://app.compound.finance/
Then transfer them to the safe

Would be good to know if this is rinkeby exclusive or if ERC-20 decimals are also falsely displayed on manner. Because if only on rinkeby, I would consider this low priority, if mainnet then medium to high priority.

Merged with #751


[SPARK-25299] Use the shuffle writer plugin for the SortShuffleWriter.

looks good to me!

Ok I'm going to merge this - we have some incoming suggestions for the shuffle writer API but we should get the implementations with the existing APIs merged first. Thanks everyone who reviewed!


sys passes stdin?

Whenever I try to do sys subl -n (subl being the executable for Sublime Text, symlinked from inside the application, and -n specifying a new window), Sublime opens with a file called /private/tmp/subl stdin <alphanumeric>.txt. I can't reproduce this in bash or zsh. Any insight on how system() in C++ works that might be helpful?

I'm honestly not sure how system works. I usually do a comination of fork and execv, however this was not possible due to something with Carbon iirc, fork failed.

ok so, subl has an option where it can take input when you do subl -. eg. ls | subl -. for some reason, it's doing this and ignoring the n in subl -n

huh. it works when i run the kwm executable from terminal, but not when it's running from launchctl...

If that is the case you need to tell launchd what your $PATH is.

@dominiklohmann yeah, for the PATH key in the plist, the value includes /usr/local/bin which is where my subl executable is. Is that what you meant? Also to be clear, using launchctl it runs the command, but ignores the n at the end for some reason.

Ohhh... I haven't seen the second but last post before mine. Nvm then, ignore what I said above.
The actual issue seems to be a parser issue then? Does it work with subl --new-window?

nope, I tried that earlier, and it does the same thing.

Does it work if you create a shell script for Kwm to execute that runs subl?

Same result.

The latest master now uses fork() and execvp() instead of system().
I do not think this will fix your problem, as the environment used when running under launchctl differs
from the when used by your user.
The syntax for running external commands have been changed from sys to exec.
Also, I would advice using the implemented variable-system to provide the full path to an executable.
define nvim /usr/local/bin/nvim
kwmc bindsym cmd-return exec nvim arg1 arg2 ..

This commit broke a lot of functionality for me. Many of my binds don't function, including focusing windows.

including focusing windows.

That makes no sense, there has been no changes to how this works in this commit.

It's very possible I just did something dumb. I'll try again tomorrow.

The tilde operator does no longer expand I believe, in case you have ~ used in the binds that fail.

Ok, works fine now, I have no idea what was causing the issue... also yeah, the subl thing still isn't working, but it's not a kwm issue so ill go ahead and close this.


[front-end] crashes when connected to wrong network without a visible user error

When connected to any other network other than Rinkeby, the front-end crashes, showing no visible error to the user. Changing the network doesn't resolve the issue, a refresh is needed.
Uncaught (in promise) Error: web3 is connected to wrong network
    at new s (app.e16483494b1250262f36.js:16)
    at new s (app.e16483494b1250262f36.js:1)
    at Object.init (app.e16483494b1250262f36.js:16)
    at Object.<anonymous> (app.e16483494b1250262f36.js:16)
    at Generator.next (<anonymous>)
    at app.e16483494b1250262f36.js:16
    at new Promise (<anonymous>)
    at c (app.e16483494b1250262f36.js:16)
    at setTimeout (app.e16483494b1250262f36.js:16)
s @ app.e16483494b1250262f36.js:16
s @ app.e16483494b1250262f36.js:1
init @ app.e16483494b1250262f36.js:16
(anonymous) @ app.e16483494b1250262f36.js:16
(anonymous) @ app.e16483494b1250262f36.js:16
c @ app.e16483494b1250262f36.js:16
setTimeout @ app.e16483494b1250262f36.js:16
setTimeout (async)
x35b @ app.e16483494b1250262f36.js:16
n @ manifest.ae31751258e1833ee059.js:1
window.webpackJsonp @ manifest.ae31751258e1833ee059.js:1
(anonymous) @ app.e16483494b1250262f36.js:1

app.e16483494b1250262f36.js:1 Uncaught (in promise) TypeError: Cannot read property 'currentUser' of undefined
    at o.<anonymous> (app.e16483494b1250262f36.js:1)
    at Generator.next (<anonymous>)
    at app.e16483494b1250262f36.js:1
    at new Promise (<anonymous>)
    at LYHj.i (app.e16483494b1250262f36.js:1)
    at setTimeout (app.e16483494b1250262f36.js:1)

The second snippet is unrelated - it's due to a page load race condition that we've fixed in #43

Verified, works now.


Shutdown legacy luigi pipeline

Finally deprecate the legacy luigi pipeline and rely only on the airflow based one.
Mentioned by @darkk in https://github.com/TheTorProject/ooni-pipeline/pull/62

That's done since https://github.com/ooni/sysadmin/commit/b9e8e914d56f1d69e6116ee76ea08208794e444d and https://github.com/ooni/sysadmin/pull/233
So I'm closing the ticket.


Implement edit events

Implements the EditEventCommand
Closes #79

Codecov Report
Base: 73.21% // Head: 74.92% // Increases project coverage by +1.70% :tada:

Coverage data is based on head (f242307) compared to base (5ea697a).
Patch coverage: 94.31% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #89      +/-   ##
============================================
+ Coverage     73.21%   74.92%   +1.70%
- Complexity      539      565      +26
============================================
  Files            89       91       +2
  Lines          1643     1731      +88
  Branches        186      205      +19
============================================
+ Hits           1203     1297      +94
+ Misses          391      383       -8
- Partials         49       51       +2

Impacted Files
Coverage Δ

...edu/address/logic/commands/event/EventCommand.java
100.00% <ø> (ø)

...address/logic/parser/event/EventCommandParser.java
78.94% <0.00%> (-4.39%)
:arrow_down:

...logic/parser/profile/EditProfileCommandParser.java
92.59% <ø> (ø)

...ess/logic/parser/event/EditEventCommandParser.java
92.30% <92.30%> (ø)

...address/logic/commands/event/EditEventCommand.java
96.72% <96.72%> (ø)

...in/java/seedu/address/logic/parser/ParserUtil.java
93.47% <0.00%> (+4.34%)
:arrow_up:

...rc/main/java/seedu/address/model/ModelManager.java
95.23% <0.00%> (+4.76%)
:arrow_up:

src/main/java/seedu/address/model/AddressBook.java
87.50% <0.00%> (+7.50%)
:arrow_up:

src/main/java/seedu/address/model/event/Event.java
97.29% <0.00%> (+8.10%)
:arrow_up:

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

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Callback Handlers

Some are already done, but should implement functions listed in
https://love2d.org/wiki/Category:Callbacks
for consistency

Gamepad/joystick integration put off indefinitely. Won't add unless needed in future projects

missed mouse scrolling, will look to add that bit


Can CFE support moving IP prefixes in AWS?

Do you already have an issue opened with F5 support?
No.
Description
AWS recently announced the ability to configure an ENI with a range of IP address, as opposed to /32 address. There's a few limitations in the details, including that IPv4 prefixes must be /28 and IPv6 must be /80.
I have tested with CFE v1.9, where I had an A/S pair and the Active device was configured with IPv4 address, multiple IPv6 addresses, and an IPv4 range of /28. Upon failover, CFE worked as expected (IPv4 and IPv6 addresses failed over), but the IPv4 range did not fail over.
Could we see support for moving of IP prefixes in AWS in future? I have not had this as a requirement from a customer yet (I think the announcement of the feature was yesterday) but I expect that customers will find these prefixes a popular option.
Environment information
For bugs, enter the following information:

Cloud Failover Extension Version: 1.9
BIG-IP version: 16.1
Cloud provider: AWS

Severity Level
3

Thanks for bringing this to our attention. We are now tracking it internally with ID AUTOSDK-560.


Update package README.md

Add some general sections at the top.
Add sections on Connections and Inference.
Still missing is a description of Evaluations at the top. See "TODO" at the top bullet list.
Still missing are example sections on Evaluations.
Make some minor updates to the Agents section to align with the rest of the README.md
Update Agents code snippets by running python ..\..\..\tools\azure-sdk-tools\ci_tools\snippet_update\python_snippet_updater.py .
Also in this PR is a fix to address Johan's code review comment. Use Typing.Self as the hint of the return type from the from_connection_string method.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-projects


Allow Tilt to reuse k8s objects from previous executions of Tilt

Sometimes a service has a long startup time. At the moment, Tilt injects various labels into any k8s objects it deploys, which means any time a user starts Tilt, it restarts all of its workloads, even if nothing has changed, which can result in the user unnecessarily waiting for a long startup time. There is currently no workaround for this.
(any solution might involve much of the same work as #1668)

@nicks looks like the work you've been doing recently will resolve this -- can you close this issue when your stuff is verified?

Yep, this should work now


Add Canvas and TimelineView to DOM renderer

This is built on the HTML canvas, and is compatible with the iOS 15 Canvas view. TimelineView with an .animation schedule only runs with Canvas at the moment with a special implementation using requestAnimationFrame, but could be adjusted to work with other views as well.
Here's a demo of confetti using Canvas:
https://user-images.githubusercontent.com/13581484/133929292-4b98926c-3e0a-468c-ad23-28d8a87e3c77.mov

Disregard the snapshot test comment, I realize this won't be possible right now because we can't test TokamakDOM directly, and this is implemented in TokamakDOM.

Haven't done much cleanup yet, but did add support for symbols:
Canvas { context, size in
  // Draw axes on the canvas.
  context.stroke(Rectangle().path(in: .init(x: size.width / 2, y: 0, width: 1, height: size.height)), with: .color(.green))
  context.stroke(Rectangle().path(in: .init(x: 0, y: size.height / 2, width: size.width, height: 1)), with: .color(.green))

  // Resolve and draw the symbols, looking them up by tag.
  guard let aSymbol = context.resolveSymbol(id: "a"),
        let bSymbol = context.resolveSymbol(id: "b") else { return }
  context.draw(aSymbol, at: .init(x: size.width / 2, y: size.height / 2), anchor: .topLeading)
  context.draw(bSymbol, at: .init(x: size.width / 2, y: size.height / 2), anchor: .bottomTrailing)
} symbols: {
  Text("A")
    .frame(width: 100, height: 100)
    .background(Color.red)
    .cornerRadius(10)
    .tag("a") // Tagged with "a"
  Text("B")
    .frame(width: 100, height: 100)
    .background(Color.blue)
    .tag("b") // Tagged with "b"
}

To look up Views by their tag, I added support for _VariadicView (matching SwiftUI's) which provides access to child views as a RandomAccessCollection, as well as access to _ViewTraitKeys. The basic usage in Canvas is like so:
private struct SymbolResolverLayout<ID: Hashable>: _VariadicView.ViewRoot {
  let id: ID

  func body(children: _VariadicView.Children) -> some View {
    ForEach(children) {
      if case let .tagged(tag) = $0[TagValueTraitKey<ID>.self],
         tag == id
      {
        $0
      }
    }
  }
}

// Then used like so:
_VariadicView.Tree(SymbolResolverLayout(id: id)) {
  _storage.symbols
}

Off-topic, but _VariadicView could be used to solve some issues with Picker. It can allow for the use of tag(_:) to specify items alongside ForEach:
Picker("Choose...", selection: $selection) {
  ForEach(items) { Text($0.title) }
  Text("Clear").tag(Item.clear)
}

or for re-tagging:
Picker("Choose...", selection: $value) {
  ForEach(items) {
    Text($0.title)
      .tag($0.value)
  }
}

Would this be ready for review soon? It would be great to keep the PR relatively small, and then additional features could be implemented in a separate PR, for easier review, and to have separate commits for such features in the main branch history.

Yes, it can reviewed now.


Guard to avoid initialization fail.

Next example resulted in error:
TERM="foo"  # Change $TERM to foo
./demo # executing cppurses demo
# Instead of executing (error prints -> from ncurses::initscr())
Error opening terminal: foo.   # With exit code (1)

Pointing that there is maybe a problem, it might be solved some other (better) way.
Tried to fix it with this patch:
1) If could initialize with $TERM -> okay
2) if not then -> Try to initialize with xterm-256color
3) if both failed then -> Handle error (TODO)

This solution prevents potentially undesired exit(), but on the other hand, hint that there is a problem with $TERM (shown at exit) might be useful for the end user.
Compiled library and tested with demos (everything looks fine).

Looks good, I'm going to make a few changes so that it throws an exception if the screen cannot be initialized


emacs: merge env in body of derivation

Description of changes

Fixes regression caused by #252244.
env was defined on its own in the first attrset and merged into the second attrset:
https://github.com/NixOS/nixpkgs/blob/c7bb13c661e20f49cbe3af71e61e66968ec803bf/pkgs/applications/editors/emacs/generic.nix#L143-L148
... which was overwritten when env.NIX_CFLAGS_COMPILE was specified in the second attrset.
https://github.com/NixOS/nixpkgs/blob/c7bb13c661e20f49cbe3af71e61e66968ec803bf/pkgs/applications/editors/emacs/generic.nix#L344-L347
https://github.com/NixOS/nixpkgs/pull/252244#issuecomment-1701454930
CC @alyssais, @Atemu, @AndersonTorres
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[X] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Oh, the classic shallow //:
https://nix.dev/recipes/best-practices#updating-nested-attribute-sets


Add support for InstantClient 12.2

http://www.oracle.com/technetwork/database/features/instant-client/index-097480.html

Strangely, OS X clients haven't been added.


Losing limbs doesn't change a mob's sprite

Try to commit suicide via microwave. You'll lose your head but the sprite won't change.

Fixed by some iteration of body system at some point in my life


v1.9.0 update is breaking website CSS

Using Firefox 63.
[class^="icon-"], [class*=" icon-"], [class^="icon-"]::before, [class*=" icon-"]::before
The above CSS is from DSB's content.css and is overwriting styles on one of my forums.
I have no idea how styling extensions can "leak" like that as I'd have thought they'd be sandboxed somehow.
Maybe you'll need to put all of your styles behind a certain id like #dsb instead?

Seeing the same thing here. Sites with specific icons are having the icons replaced with letters. Wouldn't have thought a browser status bar would break sites.

This should be fixed in 1.9.1, please update and let me know if it's still happening.

Seems to be working correctly now. Thanks.


Non-deterministic behavior of gradient registration

The following snippet for testing the numerical consistency of the registration output lead to non-deterministic behavior since not all test-runs gave exactly the same output.
...
    val iterations = (for(i <- 0 until 10) yield {

      val regIt = Registration(
        metric,
        L2Regularizer(transformationSpace),
        regularizationWeight = 0.0,
        LBFGSOptimizer(maxNumberOfIterations = 300)
      ).iterator(DenseVector.zeros[Double](transformationSpace.numberOfParameters))
      val regItPrinting = for (it <- regIt) yield {
        it.value
      }
      regItPrinting.toIndexedSeq.sum
    }).toIndexedSeq

    val firstResult = iterations.head
    for (i <- 0 until iterations.length) {
      iterations(i) should be(firstResult)
    }

The reason seems to be an issue of the parallel calculation of the sum in the MeanPointwiseLossMetric.scala in line 81. Changing there the line to the following by adding a toIndexedSeq, the test passes and all runs are consistent. It has been tested mainly on 0.18.
I will make a PR with a test and a fix.

Interestingly, I did now run the consistency test on the current develop and the issue seems to be fixed.

Unfortunately, this is not yet fixed. I tested on the recent develop branch at v0.91-RC3. The MeanPointwiseLossMetric uses the ParVector and therefore has some numerical inaccuracies. I used the snippet below to check it:
import breeze.linalg.{DenseMatrix, DenseVector}
import scalismo.common.interpolation.TriangleMeshInterpolator3D
import scalismo.common.{DifferentiableField, Domain, EuclideanSpace, EuclideanSpace3D, Field, PointId, Scalar}
import scalismo.geometry.{EuclideanVector, NDSpace, Point, _3D}
import scalismo.kernels.{DiagonalKernel3D, GaussianKernel3D, MatrixValuedPDKernel}
import scalismo.mesh.{TriangleCell, TriangleList, TriangleMesh, TriangleMesh3D}
import scalismo.numerics.{FixedPointsUniformMeshSampler3D, Sampler}
import scalismo.registration.RegistrationMetric.ValueAndDerivative
import scalismo.registration.{GaussianProcessTransformationSpace, ImageMetric, MeanPointwiseLossMetric, MeanSquaresMetric}
import scalismo.statisticalmodel.{GaussianProcess, LowRankGaussianProcess}
import scalismo.transformations.TransformationSpace
import scalismo.utils.Random

import scala.collection.parallel.immutable.ParVector

object TestPointMetric extends App {

  scalismo.initialize()
  implicit val rng: Random = Random(1024L)

  val mesh1 = generateRandomMesh()
  val mesh2 = generateRandomMesh()

  val zeroMean = Field(EuclideanSpace3D, (_: Point[_3D]) => EuclideanVector.zeros[_3D])
  val cov: MatrixValuedPDKernel[_3D] = DiagonalKernel3D(GaussianKernel3D(sigma = 20) * 5.0, outputDim = 3)
  val gp = GaussianProcess(zeroMean, cov)

  val interpolator = TriangleMeshInterpolator3D[EuclideanVector[_3D]]()

  val lowRankGP = LowRankGaussianProcess.approximateGPCholesky(
    mesh1,
    gp,
    relativeTolerance = 0.1,
    interpolator = interpolator)

  val transformationSpace = GaussianProcessTransformationSpace(lowRankGP)
  val fixedImage = mesh1.operations.toDistanceImage
  val movingImage = mesh2.operations.toDistanceImage
  val sampler = FixedPointsUniformMeshSampler3D(mesh1, numberOfPoints = 1000)(rng)

  // THE PROVIDED METRIC HAS NUMERICAL INACURACIES
  // val metric = MeanSquaresMetric(fixedImage, movingImage, transformationSpace, sampler)

  // THE METRIC WITH REMOVED PAR IS SLOWER BUT PROVIDES ALWAYS THE EXACT SAME VALUE
  val metric = SequentialMeanPointwiseLossMetric(fixedImage, movingImage, transformationSpace, sampler)

  val coefficients = DenseVector.fill(lowRankGP.rank)(rng.scalaRandom.nextDouble())

  val reference = metric.value(coefficients)
  val values = (0 until 1000).map{i => println(i); metric.value(coefficients)}
  println(s"max diff: ${values.map(value => math.abs(value-reference)).max}")
  println(s"${values.count( _ == reference)} identical values")

  def generateRandomMesh(numberOfPoints: Int = 400, numberOfTriangles: Int = 500) = {
    TriangleMesh3D(IndexedSeq.fill(numberOfPoints)(Point(
      rng.scalaRandom.nextDouble(),
      rng.scalaRandom.nextDouble(),
      rng.scalaRandom.nextDouble()
    )),TriangleList(IndexedSeq.fill(numberOfTriangles)(
      TriangleCell(
        PointId(rng.scalaRandom.nextInt(numberOfPoints)),
        PointId(rng.scalaRandom.nextInt(numberOfPoints)),
        PointId(rng.scalaRandom.nextInt(numberOfPoints))
      )
    )))
  }
}

case class SequentialMeanPointwiseLossMetric[D: NDSpace, A: Scalar](
                                                               fixedImage: Field[D, A],
                                                               movingImage: DifferentiableField[D, A],
                                                               transformationSpace: TransformationSpace[D],
                                                               sampler: Sampler[D]
                                                             ) extends ImageMetric[D, A] {

  override val ndSpace: NDSpace[D] = implicitly[NDSpace[D]]

  val scalar = Scalar[A]

  protected def lossFunction(v: A): Double = {
    val value = scalar.toDouble(v)
    value * value;
  }

  protected def lossFunctionDerivative(v: A): Double = {
    2.0 * scalar.toDouble(v)
  }

  def value(parameters: DenseVector[Double]): Double = {
    computeValue(parameters, sampler)
  }

  // compute the derivative of the cost function
  def derivative(parameters: DenseVector[Double]): DenseVector[Double] = {
    computeDerivative(parameters, sampler)
  }

  override def valueAndDerivative(parameters: DenseVector[Double]): ValueAndDerivative = {
    // We create a new sampler, which always returns the same points. In this way we can make sure that the
    // same sample points are used for computing the value and the derivative
    val sampleOnceSampler = new Sampler[D] {
      override val numberOfPoints: Int = sampler.numberOfPoints
      private val samples = sampler.sample()

      override def sample(): IndexedSeq[(Point[D], Double)] = samples
      override def volumeOfSampleRegion: Double = sampler.volumeOfSampleRegion
    }

    val value = computeValue(parameters, sampleOnceSampler)
    val derivative = computeDerivative(parameters, sampleOnceSampler)
    ValueAndDerivative(value, derivative)
  }

  private def computeValue(parameters: DenseVector[Double], sampler: Sampler[D]) = {
    val transform = transformationSpace.transformationForParameters(parameters)
    val warpedImage = movingImage.compose(transform)
    val metricValue = (fixedImage - warpedImage).andThen(lossFunction _).liftValues

    // we compute the mean using a monte carlo integration
    val samples = sampler.sample()
    samples.toIndexedSeq.map { case (pt, _) => metricValue(pt).getOrElse(0.0) }.sum / samples.size
  }

  private def computeDerivative(parameters: DenseVector[Double], sampler: Sampler[D]): DenseVector[Double] = {
    val transform = transformationSpace.transformationForParameters(parameters)
    val movingImageGradient = movingImage.differentiate
    val warpedImage = movingImage.compose(transform)
    val dDMovingImage = (warpedImage - fixedImage).andThen(lossFunctionDerivative _)
    val dMovingImageDomain = Domain.intersection(warpedImage.domain, fixedImage.domain)
    val fullMetricGradient = (x: Point[D]) => {
      val domain = Domain.intersection(fixedImage.domain, dMovingImageDomain)
      if (domain.isDefinedAt(x))
        Some(
          transform
            .derivativeWRTParameters(x)
            .t * (movingImageGradient(transform(x)) * dDMovingImage(x).toDouble).toBreezeVector
        )
      else None
    }

    // we compute the mean using a monte carlo integration
    val samples = sampler.sample()
    val zeroVector = DenseVector.zeros[Double](transformationSpace.numberOfParameters)
    val gradientValues = new ParVector(samples.toVector).map {
      case (pt, _) => fullMetricGradient(pt).getOrElse(zeroVector)
    }

    gradientValues.foldLeft(zeroVector)((acc, g) => acc + g) * (1.0 / samples.size)
  }
}

PS: A much simpler test, illustrating the problem, is the following snippet using scala-cli
//> using scala "2.13"

//> using lib "org.scala-lang.modules:scala-parallel-collections_2.13:1.0.4"

import scala.collection.parallel.CollectionConverters._

object test_ParVector extends App {

  val rng = scala.util.Random

  val values = IndexedSeq.fill(10000)(rng.nextDouble * 10000)
  val parValues = values.par

  val reference = parValues.sum
  println((0 until 10000).count { _ =>
    val current = parValues.sum
    if (reference != current) {
      println(reference - current)
      true
    } else {
      false
    }
  })
}

If we impose an order on the Parvector summing (with .toIndexedSeq.sorted.sum) we could still leverage some parallelization while remaining deterministic.
I tested replacing line 121 of your first snippet with:
samples.par.map { case (pt, _) => metricValue(pt).getOrElse(0.0) }.toIndexedSeq.sorted.sum / samples.size
and it seems to work (approx 3x faster than sequential)

Are the errors we get so large that the order we sum up the terms has a practical impact in the optimization or is the problem just that the two resulting number are not exactly equal? If the former is true, we should maybe look more carefully at the numerics and see how we could stabilize the computations? It would mean that the result we get depends on sheer luck any particular order that we enforce could still be suboptimal. If it does not have a real impact in the results, we should maybe just make our tests more tolerant.

I would like to come back to this issue as reproducible results are important for our deliverables.
In the end, there were 2 issues causing the non-deterministic behavior:

the order of parallel summation of Doubles does indeed introduce numeric differences
the current caching mechanism in SurfaceSpatialIndex results in different values for the same point when ran in parallel

Back then, we published our own Scalismo version v0.90.0-deterministic to fix these issues (https://github.com/Shapemeans-GmbH/scalismo/commit/86e6818307b2f95e643798ebeeadb4c76993b12c) .. However, long term, it would be great if this is integrated into the main branch somehow.

Thanks for reviving this discussion.
I think we really need to fix point 2 of your list. This is a clear bug. I am still reluctant to the fix for point 1. To me it seems that if the differences are tiny, we should not incur a huge performance penalty just to have perfect reproducibility. Results from a floating point computation should never be compared to an exact value but always lie withing an epsilon range. Of course if large differences are observed, we should do something against it. But if the range is small, and the differences just multiply due to a downstream task (as Andreas mentions above) then I think it is a bug in the downstream task.
Do you have any experiments that quantify the differences of the metric numerically?

The short version:

great that you agree that point 2 needs to be merged
for us it would also be OK if point 1 is not merged. This we can implement as our own metric on the application layer as Andreas suggested.

The bit longer version:
I disagree with the claim that if differences multiply due to a downstream task then this would mean there is a bug in the downstream. If the downstream task is stochastic (for example MCMC), currently, we can very well ensure deterministic results by seeding all random generators properly.
However, if some "randomness" comes for the upstream result, which was assumed to be deterministic, this can lead to different results with the same input. And as Andreas noted, the scale of the differences from the upstream is not really what is important here.
For Scalismo to be used in practical applications (e.g. medical devices), the same input needs to give the same result at different runs.
As said above, these arguments do no affect this issue since this can be solved with the 2 bullet points above. Just important for future developments in my opinion.

@Ghazi-Bouabene After an (offline) discussion with @thogerig , the problem is more clear to me now. As you suggested above, it should be sufficient to modify line 121. But instead of sorting the collection, we should be able to just use .seq to convert it back to a sequential collection, and thus have the sum method be performed sequentially (see the doc for details).
new ParVector(samples.toVector).map { case (pt, _) => metricValue(pt).getOrElse(0.0) }.seq.sum / samples.size
Maybe you could see if it solves your problem and do a PR?

Are there any news on this issue? Does the fix with .seq solve the problem, or will you use your own implementation of the metric?

The fix we implemented in the metric was to convert the values to BigDecimal before performing the sum (https://github.com/Shapemeans-GmbH/scalismo/commit/86e6818307b2f95e643798ebeeadb4c76993b12c). As previously said, if there is objection to changing the metric, we can fix this on the application side and not necessarily in Scalismo. For the other issue related to the Spatial Index cache, we will push a PR soon.

Great, thanks for the clarification. Then we leave the metric as is.
Maybe it is still worthwhile to give .seq a try at some point. If you have a large number of points,  .seq should be much more efficient than conversion to BigDecimal. It has constant complexity and, I suspect, that addition of big decimals is also less efficient than addition of double values (not sure about this point, though).


Image component onLoadingStart/onLoadingFinish/onLoadingError props

Not sure if this is on your radar, but I'm playing around with RCTNetworkImageView and its manager to see if I can expose them. It's mostly so I can fade in the image (vs. simply appearing) when onLoadingFinish is called, but they could be useful for other use cases :)

Just took a stab at it since I'm working on a prototype that needed the feature.

Closing issue as there is now a corresponding pull request :smile: thanks


Add new icons to add/edit host view.

Sorry, the latest merge from @alescdb broke your keyboard reference.

Fixed. Thanks for catching it.

Should we be using svgs like @alescdb described in https://github.com/connectbot/connectbot/pull/321

Switched to SVGs.


[Proposal] Index Environment Metadata for every benchmark

Environment Fields
Problem
benchmark-wrapper is meant to run in many different environments. However, many times the results don't show environment information, or if they do it's from a user-defined CLI arg (i.e. cluster-name) that may or may not be accurate. This makes analysis hard as we can't query on things about the environment and instead have to find uuids/run_ids and figure out how they map.
How we can solve
This is a proposal to implement a one-time, non-blocking, post-benchmark step for environment metadata collection after the run of a benchmark. We can make the wrapper take a new flag (--environment) at the top level (prone to error), or we can define methods to detect the environment in the wrapper (more usable but trickier).
This would probably be a new package in snafu, at snafu/environments where each module corresponds to an Environment definition which should contain the fields to index, methods grabbing the field values from the environment, and a method to detect whether or not the runtime is in that environment.
Each benchmark would then gather the environment metadata after a run and index it alongside the results.
Thoughts?
@learnitall
@jtaleric
@rsevilla87

Talked about this with @whitleykeith on slack. Since backpack already collects all the data prior to any run we could simply have it write its json output to a shared storage or just the bits we care about to redis and then have snafu read it in. It would be a pretty trivial change to backpack and snafu then. thoughts?

My only concern with backpack is that it seems like a pretty heavy dependency. Would the automotive team be able to use backpack for environment information?
Also, what sort of information are we looking to collect?
I like the idea of having snafu/environments for a location of Python modules that pull env metadata. Another idea that might work, since some env collection could be done in straight-up bash, is the following:

Create snafu/environments as a collection of tiny executable scripts which take no arguments and output environment data in the form of KEY=VALUE, with each key-value pair on a separate line. If no key-value pair was found in the output, or if the return-code is non-zero, then assume the script isn't applicable for the environment.
Create a module called environment.py which runs each of these bash scripts one by one, collects the output, and saves the key-value pairs to a dataclass which we can then export.

From this perspective, we can do metacollection using bash, perl, python, whatever. It'll be super lightweight, easy to maintain, easy to test and have minimal external dependencies.
But at the disadvantage that we now have to maintain code that does the same thing as backpack.

My only concern with backpack is that it seems like a pretty heavy dependency. Would the automotive team be able to use backpack for environment information?

They would never use backpack -- backpack is specific to OCP. They would use the underlying Ansible roles which is Stockpile.

Also, what sort of information are we looking to collect?
I like the idea of having snafu/environments for a location of Python modules that pull env metadata. Another idea that might work, since some env collection could be done in straight-up bash, is the following:

Create snafu/environments as a collection of tiny executable scripts which take no arguments and output environment data in the form of KEY=VALUE, with each key-value pair on a separate line. If no key-value pair was found in the output, or if the return-code is non-zero, then assume the script isn't applicable for the environment.
Create a module called environment.py which runs each of these bash scripts one by one, collects the output, and saves the key-value pairs to a dataclass which we can then export.

From this perspective, we can do metacollection using bash, perl, python, whatever. It'll be super lightweight, easy to maintain, easy to test and have minimal external dependencies.
But at the disadvantage that we now have to maintain code that does the same thing as backpack.

IMHO This is a step backwards. We already do this today. Check out Stockpile and Scribe.

My concern with Scribe was that it seemed like a large dependency, which was where that bash idea came from, but if we are willing to do use it then all the merrier. My bad on the confusion.


DID Cache - Implement lastProcessedTransaction

Addressed by commit https://github.com/decentralized-identity/sidetree-core/commit/46b687d600bf2d931533d80d8bef940d0948b214.


Multi Realm Authentication

Hi guys,
Currently I face a problem where I need to authenticate JWT token from 2 different realm in one gateway. Currently my company is using this library to handle authentication process of the token, but from what I read it only handle 1 configuration for 1 authentication.
Is there a way to handle multi realm using this library ? If not do you guys have a suggestion how I can implement this ?

It is not supported out of the box, but you could try something like following:
https://github.com/NikiforovAll/keycloak-authorization-services-dotnet/discussions/123#discussioncomment-9881517

Thank you, I'll try to implement it.


DeprecationWarning: datetime.datetime.utcnow() on version 1.3.48 (using python 3.12)

Description
When running terraform_compliance 1.3.48 with python 3.12 I'm getting multiple DeprecationWarnings on the usage of datetime.datetime.utcnow().
Although terraform_compliance still works, this makes it difficult to read the output.

To Reproduce
Just run terraform_compliance with any feature file on python 3.12
Feature File:

Given I have ....
When it contains ...
Then it must ....
And it must ...

Plan File:

Sample Terraform Code:

resource "aws_s3_bucket" "example_code" {
   bucket = "This is just a sample code"
}

Used terraform-compliance Parameters:

Running via Docker:
 Yes

Error Output:

. Converting terraform plan file.
🚩 Features     : /workspaces/tf_btp_info/tfscripts/tests/
🚩 Plan File    : /workspaces/tf_btp_info/tfscripts/mission_3774/step1/plan.out.json

🚩 Running tests. 🎉

/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:38: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  feature.starttime = datetime.utcnow()
Feature: Certain variables should always be defined  # /workspaces/tf_btp_info/tfscripts/tests/naming_standards.feature
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:44: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  scenario.starttime = datetime.utcnow()

    Scenario Outline: Naming Standard on all available variables
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:50: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  step.starttime = datetime.utcnow()
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:68: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  step.endtime = datetime.utcnow()
        Given I have not defined variable foo or moo
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:50: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  step.starttime = datetime.utcnow()
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:68: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  step.endtime = datetime.utcnow()
        Then scenario should fail
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:62: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  scenario.endtime = datetime.utcnow()

    Examples:
        |  |
/usr/local/lib/python3.12/site-packages/radish/extensions/time_recorder.py:56: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  feature.endtime = datetime.utcnow()

1 features (1 passed)
0 scenarios (0 passed)
0 steps (0 passed)

Expected Behavior:

Clean output without deprecation warnings.
Tested Versions:

terraform-compliance version: 1.3.48
terraform version: 1.9.1
python version: 3.12.4

Additional Context:

Same here.
terraform-compliance version: 1.3.48
terraform version: 1.9.3
python version: 3.12.4

Hi, is there any update on this please ?

Sorry for this guys, let me update it.

Just released 1.3.49b1, have a try and let me know if you are still having problems, based on your response, I'll remove beta.

I seem to still be seeing the same warnings on the beta (Python 3.12):
/Users/fakeUser/.local/pipx/venvs/terraform-compliance/lib/python3.12/site-packages/radish/extensions/time_recorder.py:56: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  feature.endtime = datetime.utcnow()

$ terraform-compliance --version
terraform-compliance v1.3.49b1 initiated

1.3.49b1

Deprecation output continues on version 1.3.48:
$ cat /etc/*release
Fedora release 40 (Forty)
NAME="Fedora Linux"
VERSION="40 (Workstation Edition)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation
Fedora release 40 (Forty)
Fedora release 40 (Forty)
$ which terraform-compliance
~/.local/bin/terraform-compliance
$ terraform-compliance --version
terraform-compliance v1.3.48 initiated

1.3.48


test/logging: add log.toml file test

Add a test for log.toml logging. The log.toml file is detailed with comments on usage unlike the previous log.toml which existed in examples and was wrong in its content (i.e. there were invalid formats which could not produce a working sample).

This change is

r? @canndrew
(maidsafe_highfive has picked a reviewer for you, use r? to override)

r? @afck

Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions.

test/log.toml, line 3 [r1] (raw file):
Nit-pick: I'd put a space after the "#", make "URL" uppercase, capitalize the first word and add full stops to user-facing documentation, even if it's just an inline comment like this. (Also below.)
(But I'm happy to do this in another commit.)

test/src/main.rs, line 1 [r1] (raw file):
Should this be 2016? (But I'm also fine with 2015 since most of the code has just been moved here, right?)

Comments from Reviewable

Reviewed 5 of 5 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


[CSL-1956] Show in the Swagger documentation the full list of errors

Issue here: https://iohk.myjetbrains.com/youtrack/issue/CSL-1956
Solution here:

If you solve the conflicts by regenerating the swagger specs I will merge

I didn't regenerate swagger.json as it produces invalid swagger. I have just merged the one from base branch


Schedule

Add schedule, change student FAQ, fix typo

I've requested a review from @aga11313 just to make sure she's happy with the schedule, but I'm happy with the changes


CLOUDSTACK-8855 Improve Error Message for Host Alert State and reconnect host API.

@DaanHoogland and @marcaurele I opened a new PR because it gets easier for me to fix problems and conflicts that may appear.
This closes #2380
This also closes #837

@bvbharatk care to review this?

@DaanHoogland I fixed that test that was not working. I isolated it, and then everything started working just fine. I think it was a concurrency problem.
@marcaurele  would you mind finish the review here?

@borisstoyanov could you run tests here?

@blueorangutan package

@borisstoyanov a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos6 ✔centos7 ✖debian.

Let me run smoke tests again, but I think we've seen them quite frequently on random PRs.
@blueorangutan test

@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests

ok, thanks.
@DaanHoogland have you approaved this PR?

@rafaelweingartner i did i think but my approval is kind of stale. Let me find time to revisit it, please

Sure, no problem.

@DaanHoogland since your approval the code did not change. I only isolated a smoke test case that was causing problems.

@rafaelweingartner sorry for sickness and €dayjob preventing me to review again, can you resolve conflicts?

@DaanHoogland done.

@DaanHoogland thank you very much!
We will finally push this PR forward.

Trillian test result (tid-2373)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 19887 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2387-t2373-kvm-centos7.zip
Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
Smoke tests completed. 66 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_hostha_enable_ha_when_host_in_maintenance
Error
0.93
test_hostha_kvm.py