Add pytest unit tests

Summary
This pull request introduces a refactored directory structure and adds unit tests for existing Python code. Key changes include:

Separated source (src) and test (tests) code for better organization.
Added comprehensive unit tests using pytest to enhance code reliability.

Test Plan

Will the test tool errors be resolved after merging it?


Puppeteer tests failing

Hello,
Some of the puppeteer changes were failing due to warnings that we were constantly receiving.

I made the required changes:

headless: true to headless: 'new'
Added proper timeout so that the tests don't fail.

pull the latest changes or rebase it


[WFLY-13101] Tests for Microprofile Health 2.2

This PR adds a test case for validating HealthCheckResponse class, which has been defined as concrete in the latest MicroProfile Health 2.2 release. This is basically the main change introduced by this last version of the spec from the end user point of view.

Please be aware that this PR depends on https://github.com/wildfly/wildfly/pull/12983 and thus shouuld not be merged before the latter is, as well.

JIRA issue: https://issues.redhat.com/browse/WFLY-13101

This test case was run against the Wildfly feature branch which already has the MicroProfile/SmallRye upgrade, see [1].
The test failed, because there's a mismatch in the spec between a property name and the actual payload JSON schema. An issue to MicroProfile Health project has been filed [2] and the test case has been marked as ignored for this reason.
[1]
https://github.com/jmesnil/wildfly/tree/WFLY-13048_upgrade_microprofile-health_2.2
[2]
https://github.com/eclipse/microprofile-health/issues/243

[x] Pull Request title is properly formatted: [WFLY-XYZ] Subject or WFLY-XYZ Subject
[x] Pull Request contains link to the JIRA issue(s)
[x] Pull Request contains description of the issue(s)
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Attached commits represent units of work and are properly formatted

Can one of the admins verify this patch?

this is ok to test

@jmesnil If these changes are ok can you pull them into your branch(es) for the upgrade? Your submitting the commits as part of your PR counts as the necessary approval of them.

Hi @jmesnil although the spec doesn't mandate for the HealthCheckResponse class to map to the protocol JSON schema, I see that the use case [1] which was referred by the PR [2] that brought the change in is actually about deserialization with - for instance - REST Client. This would help the end user (Wildfly end user, in this very case) to leverage such tools easily. WDYT?
Also @xstefank what are actual plans on HealthCheckResponse class in future? Is mapping to the JSON schema going to be a requirement?
[1]
https://github.com/eclipse/microprofile-health/issues/194
[2]
https://github.com/eclipse/microprofile-health/pull/218

@jmesnil I believe this is an oversight on the spec side. I will raise this in the community. However, this kind of test can be added as an actual new TCK test in my opinion. So I agree that this test is not necessary for wfly test suite.

The MP Health TCK already uses extensively the HealthCheckResponse class.
This test does not bring any additional assertions to what is already tested by the TCK.

@jmesnil It seems that TCK uses JSON-P, not JSON-B/Jackson

@marekkopecky that's correct. One more reason to move that test in the microprofile-health tck to make sure that https://github.com/eclipse/microprofile-health/issues/243 is properly addressed.
However that does not change my opinion that this test does not belong to WildFly integration test suite.

PR can be closed as necessary test coverage will be added to https://github.com/eclipse/microprofile-health, see https://github.com/eclipse/microprofile-health/issues/243
Thanks for your feedback @jmesnil, @xstefank, @marekkopecky and @bstansberry


Add Hashcorp Packer 1.8.6

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow
Microsoft Reviewers: Open in CodeFlow

It looks like to passed merge check.
Where's validation error?

@wingetbot waivers Add Validation-Executable-Error

This package is expecting arguments:
Usage: packer [--version] [--help] <command> [<args>]

Available commands are:
    build           build image(s) from template
    console         creates a console for testing variable interpolation
    fix             fixes templates from old versions of packer
    fmt             Rewrites HCL2 config files to canonical format
    hcl2_upgrade    transform a JSON template into an HCL2 configuration
    init            Install missing plugins or upgrade plugins
    inspect         see components of a template
    plugins         Interact with Packer plugins and catalog
...


Feature:  Non-serial PTT / COS control

A write-up inspired by off-topic discussion from Issue #11.  I wanted to describe in detail several options for PTT besides RS-232 control lines used by other devices, as well as introduce the possibility of using AIOC more advanced applications like ASL/HamVoIP nodes and other similar full-duplex radio uses.
Currently, AIOC supports PTT control by presenting a virtual RS-232 port via USB and using status "pins" to trigger PTT (v1.0.0: DTR Low/RTS High; in the future likely just DTR High).  This is a classic PTT control mechanism in the Amateur Radio world, dating back to when computers actually had physical RS-232 ports -- and very few other ports!  Serial ports were the only convenient way to trigger a relay, which was the most straightforward way to control PTT!  Well, none of that is true today:  are there other ways to control PTT that might be both easier and more effective?
Alternatives for PTT control
Because we're not trying to trigger relays with actual RS-232 ports, we have a lot more flexibility in triggering PTT.  Here are some alternatives:

VOX-based triggering

Computers are not the first time where people wanted to get away from having to activate a mechanical switch or relay just to transmit.  VOX is a very common solution to this:  when the sound level is loud enough, start transmitting.  This, though, has issues:  if the background is too noisy it can activate incorrectly; if the signal is not loud enough it may not activate properly at all; and because the sound we might want to transmit is not continuous (like pauses between letters or words), the VOX needs to keep transmitting after the silence begins because it can't be sure that the transmission is yet complete.  These issues make radio-based VOX unreliable, especially for digital signals that may need to transition from send to receive very quickly.
However, with AIOC, we have some advantages.  First of all, there is no microphone, so there's no background noise.  If noise is received from the computer, something intentionally generated it, so we can switch to VOX immediately.  Second of all, there is no "loud" or "quiet".  If the computer is playing sound, sound data is flowing into the AIOC -- even if a human might perceive that sound as "quiet' or even "silence".  Therefore, there does not need to be additional VOX 'hang time'.
The beauty of this is that neither the sound-generating software on the computer nor the AIOC really have any need for any out-of-band PTT-signalling mechanism.  The sound itself is a reliable signal.  On higher-end computer radio interfaces, VOX has become a common technique and has proven to be very effective.  The most common example of this is the SignaLink USB:  https://www.tigertronics.com/slusbmain.htm  This is used in numerous digital applications, including AX.25 packet, which requires fast send/receive turnaround.
This really isn't the same as traditional microphone-based VOX.  Don't think of it as VOX:  think of it as Auto-PTT.  :)  And as you have previously mentioned, Auto-PTT would allow AIOC to support applications where serial ports are difficult to use or are just not supported -- like APRSdroid.  Sound data would simply magically flow into APRSdroid, and when sound data flows out of APRSdroid, it would automatically engage the PTT.

GPIO-based triggering

Even if there is a desire for an out-of-band PTT-signalling mechanism, there are alternatives to RS-232 signalling.  A GPIO interface can be used instead.  This is already used by software that targets the Raspberry PI; in addition, some more advanced software (such as AllStarLink) has the ability to use GPIO pins provided on CMedia CM108/119A sound chips.  In fact, modifying USB sound dongles to expose these pins and interface them to radios is one of the most common radio interfaces for AllStarLink.  (Ref: https://wiki.allstarlink.org/wiki/Radio_Connections#Modified_CM108.2FCM119_USB_FOB )
GPIO and RS-232 signalling are very similar.  However, for RS-232, those signals are only a small part of the RS-232 standard.  There's lots of other factors involved, and some of them are not under the control of the application.  At the very least, the operating system is also involved, and it may not understand -- or care -- how those status pins are being used.  With GPIO, there is a lot less going on.  These pins are designed to simply turn on or turn off (or sense if they're turned on or off), and that's exactly all we want to do with them.  Therefore, there's a lot less possibility for things to go wrong.
This technique is used in certain voice and digital applications; however, these are more common in repeater controller or digital node applications, where more advanced control is needed.  However, these applications need more than just PTT.  This is covered in the next section.
Full flow control:  COR/COS
PTT is a common and well understood need:  the radio is not smart enough to know when to send or not.  After all, there's sound data at the microphone all the time, so theoretically there's always data that could be sent.  The radio has to be told when there is actually data that needs to be sent.  And that's what Push To Talk (PTT) does:  it signals the radio when it needs to actually start sending data.
But imagine a more complex configuration such as a repeater or a node.  These can be thought of as two radios connected together, the microphone of one radio connected to the speaker of the other, and vice-versa.  Those radios may be directly connected or might be connected across the Internet, but the concept is the same either way.  In this case, there isn't just a single source of data, there are now two radios, both capable of sending and receiving data.
Just like with a single radio, each radio needs to be told when when there is data that needs to be transmitted.  That signal is PTT.  Each radio also needs a way to tell the other radio when it has legitimate data that it is trying to pass it along.  That signal is called COS:  Carrier Operated Switch.  (The original name was COR:  Carrier Operated Relay.  It's the same thing.)  The COS is an outbound signal on one radio that is connected to the inbound PTT of the other radio, and vice-versa.  When one radio receives a radio carrier (i.e. receives legitimate data), that radio activates the COS signal, which is passed to the other radio's PTT, which causes it to then transmits that data.  (For more details and history, see "So What's The COR or COS?? " here: https://www.repeater-builder.com/tech-info/repeater-term.html)
As you can see, because both radios can move data in two directions, both radios need both PTT and COS, to deliver signals in both directions.  And yes, this is exactly the same type of flow control you see in numerous other applications, such as RS-232 RTS/CTS or DTR/DSR!
COS is really only essential when you trying to connect two radios together, such as in a repeater or node.  This is exactly what you are doing with something like an AllStarLink node:  bridging a remote repeater to a local radio.  This literally allows you to connect to a far-away repeater and use it as if it were right in your home.  And you can do this even with a simple Baofeng and a Raspberry Pi -- if you have COS...
Unfortunately, most radios do not have a COS signal.  Because they simply receive and pass along data any time they are not actually being asked to transmit, there is no need for a specific two-way flow-control signal like COS.  If you think about it, though, radios do kind of have a COS signal:  that is the exact purpose of squelch!  When squelch is blocking the data, this is the same as the COS signal being inactive:  the radio is telling you "there's no legitimate data here."  When the squelch opens up and the radio passes the data along, this is the same as the COS signal being active:  the radio is telling you "I have legitimate data:  please do something with it."  In fact, this is how a COS signal is usually gotten from a radio that doesn't actually have one: go inside the radio and tap into the squelch signal!
In order for AIOC to provide a COS signal to a computer, there needs to be two elements:  A way to get a COS signal from the radio, and a way to pass it along to the computer.  Passing it along to the computer is relatively straightforward.  Most software that expects COS uses some sort of GPIO to do this.  Whatever GPIO is used to handle PTT could likely handle COS as well.  (Theoretically, DSR or CTS could be used as well.)  Actually getting the COS signal from the radio is more difficult.
Getting the COS from the radio, though, is more difficult.  The most effective way is to open up the radio and tap into something that could substitute for the COS signal.  Simply using the RX LED signal could be sufficient.  But seeing as this requires opening up the radio, it's probably not a good match for the AIOC.
Another choice would be to use the AIOC microcontroller to detect the presence of audio from the radio -- VOX.  Because this is VOX on an analog source, it will have some of the same limitations as a radio's VOX system for PTT.  However, because the radio's squelch can listen for CTCSS/DCS tones and will be completely stopping extraneous noise from being sent to the AIOC -- and because we are dealing with electrical connections and not an actual microphone -- the VOX detection should be much more straightforward and reliable.
In short, once COS as well as PTT is available, the AIOC would allow the simplest possible connection between a computer trying to function as a node and a radio:  just the computer (such as a Raspberry Pi), the AIOC and the radio.  In order to do this, we need to generate a COS signal (probably from the analog audio data coming into the microcontroller) and a way to pass it to the computer that is compatible with the software (probably GPIO, such as the CM108/119A most commonly used today).
For further reading:

AllStarLink, the original worldwide network of repeaters and nodes:  https://www.allstarlink.org/
HamVoIP:  A parallel software fork that uses the same technology and network:  https://hamvoip.org/
How to connect a radio to an ASL node (N.B. Modified CM108/119A Fob):  https://wiki.allstarlink.org/wiki/Radio_Connections
RA Series interfaces:  'pre-modified' CM119A-based interfaces designed for nodes:  http://www.masterscommunications.com/products/radio-adapter/ra-description.html
Examples of modifying Baofeng radios to connect to nodes (most connected via modified fobs):

https://allstarsetup.com/modify-the-baofeng-888s-for-allstar/
https://hamvoip.org/hamradio/baofeng888/
And a zillion more:  https://www.google.com/search?q=allstarlink+baofeng

Thanks a bunch for the extensive writeup. That's a lot for me to digest for the next days :-)

I started with implementing basic CM108-style PTT control. I request heavy testing :-)
https://github.com/skuep/AIOC/releases/tag/v1.2.0-rc.1

Thanks again for all the information. I have taken some time and sorting through the information.
In the information below, I am talking in the context that we now have CM108 support, i.e. full GPIO input and output is supported on the USB Interface.
COS taken from inside of radio

Currently, the GPIOs are hardcoded as outputs in the AIOC, however the current hardware version V1.0 does indeed have the possibility to read-back the PTT1 one pin (using USART1-TX, while the UART-Transmitter is high impedance)
However PTT1 will very likely be used for actual PTTing the radio. Unfortunately, PTT2 does not have that read-back capability, but I am considering to include this in a V1.1 version. It can't hurt and is a totally backwards and forward compatible change.
Hardware: COS from Radio could currently only being used, by using PTT2 for PTTing the radio and using PTT1 as input. This definitely requires a totally custom wiring between the AIOC and the radio. However, getting the COS signal from the radio is already some kind of wiring effort, this could be acceptable, although high maintenance and documentation effort.
Software: We would just need to make the GPIOs direction configurable, add some GPIO readout in the firmware and done. Easy. This would be transparent and would not require any configuration of the AIOC.

COS via "reverse-VOX"

The AIOC could try to detect if there is an audio signal at the input and report this to the USB-host. This solution still has a lot of question-marks in my head. (e.g. If the host does not "open" the soundcard (and request the sound-card to actually record data and send it to the host), the AIOC does not record any data on its ADC and could not detect anything)
I started thinking if it wouldn't be better if the actual PC software just does the CTCSS detection and stuff like this, but you are right, that it represents some kind of symmetry if we have VOX (or Auto-PTT) actually in both directions. For RX and TX. And if there is one thing I like, than it is symmetry.
Software: We would need to implement the Auto-PTT feature for both RX and TX, because when I am already at it, I would implement both at the same time. However this would require the AIOC to be somewhat configurable right? I am thinking Auto-PTT tail time, or enabling Auto-PTT at-all. The alternative would be to make Auto-PTT the de-facto default (and if people wanted, they could configure the AIOC back to the old, manual way). Both, Auto-PTT and GPIO/DTR controlled PTT would not be possible, I think. And I am a bit hesitant changing the default settings of the AIOC so drastically. I guess it boils down to: a) Would it be acceptable for AllStarLink folks having to configure the AIOC once (using a tool) to set it into the correct mode? Or b) is it better to make Auto-PTT the default. Of course your argument with the AIOC being the simplest way there is, to make an AllStarNode (assuming Duplex-Auto-PTT is the way to go) is quite intriguing...

I will reply in detail when I can, probably in a few days; but I want to add a really quick note for the moment.
Right now, the most common way to get a COS enabled sound interface is to break out a soldering iron.  The entire system is a raw Asterisk system with no real GUI.  The idea of a simple command line utility that you use to make some basic configuration changes once is not even in the top 10 list of hurdles to this entire process. :-). (It needs to run on Linux, and of course ideally also run on Windows; but seeing as you are a Linux guy anyway, the Linux side certainly won’t be a problem.)
Also, perfect is the enemy of good enough: as a first pass, a command line utility would be just fine. GUIs can be wrapped around such tools later. :-)
It will definitely be next week before I will have a chance, but I am very, very excited to test out the GPIO  support.
Conceptually, I’m not sure why auto PTT and DTR based PTT are mutually exclusive. I haven’t looked at the source code or anything, but as a basic state machine, it seems pretty straightforward: is DTR enabled? Raise PTT. Is audio detectable? Raise PTT. Otherwise, drop PTT.  Whether auto PTT is enabled by default or not to me should be determined by how well it works, but once it works well, I don’t see a reason why they both can’t be enabled at the same time. If you don’t touch the serial port, nothing will happen. But needing to configure it at set up one time isn’t exactly a problem.

Are there any status updates for VOX / Auto PTT?
I'm making and selling these at my local club and this is the most requested feature as this would be excellent for APRSDroid. The rest of the features are good nice-to-haves but that's really the only "This is why Im not buying / making this" I'm running into.

I have not really worked on this. I am assessing how much interest there is for it 😁 This would be the first feature where we need some way of configuring/enabling it. For this I need to implement an interface and python script to do so.
Maybe I will have a look in the next days how much work this is

I'd really appreciate it, and I can confirm there would be a lot of interest. This is what would bring it from a more compact USB sound card and cat cable setup to a Signalink alternative. It would be plug-and-play super easy to use and would be very valuable to many hams.
Everyone I've talked about this to, literally everyone, asked if it had vox ptt trigger.

Got ya. I have thought about how I could go about it with my slim resources. What about the following plan:

Implement a simple Auto-PTT and Auto-COS using a threshold of the digital data and a time-out. Is the data above the threshold, enable PTT and reset the time-out. If the time-out expires (e.g. 1ms or 10ms), disable PTT
For now, release two firmware binaries, one with Auto-PTT enabled and also the "regular" firmware (PTT via serial/CM108 only).
~Profit~ At some point in the future, set Auto-PTT as default, if it turns out, that it is more requested, than the current default (serial/CM108). And/or include a configuration feature, where you can configure the AIOC using a python script (and a currently unused HID endpoint). Enable/Disable various PTT sources and set threshold/timeout.

Whats your opinion on that?

That would be super helpful, yes!

How about "CATless-PTT" to show when you'd use it?

Good news everyone, I started working on some basic Automatic PTT and COS functionality (to be renamed of course ;-)).
Since this issue is about Non-serial PTT/COS in particular, I want to move further discussion over to issue https://github.com/skuep/AIOC/issues/19.

I just wanted to point out that there is a simple way to do hardware COS without opening the radio on Baofeng UV-5Rs. There's a DC bias in the speaker output that you can use to trigger a GPIO pin when the squelch is open. You can also see it used in this YouTube video.
I added a diode and resistor to my AIOC and then ran it to a GPIO pin on a Raspberry Pi. I imagine you could do something similar on the AIOC PCB and then return the COS status vi CM108 emulation (or some other way). I tried wiring it up on the schematic but got really stumped trying to fit anything onto that tiny little PCB. It's my first go in KiCad.
Anyway, this is what I was thinking:


Adding Data Structure Algo of Fenwick Tree

What the program do ?
This is a Effiecient Algorithm of the Trees
In what programming language it is written?
This is Given in three Programming Language

Java
CPP
Python

This pull request do not contains files in specific folders. Please fix it and reopen


branch-3.0 fix coredump of function StDistanceSphere and StAngleSphere (#45508)

pick https://github.com/apache/doris/pull/45508

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.
Please clearly describe your PR:

What problem was fixed (it's best to include specific error reporting information). How it was fixed.
Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
What features were added. Why was this function added?
Which code was refactored and why was this part of the code refactored?
Which functions were optimized and what is the difference before and after the optimization?

run buildall


Content in vSphere API docs

Problem description
There are a few pages in the vSphere API docs that have double dots between vSphere and the name of the function (like vsphere..ContentLibrary). That results in links going to a 404 page. Examples:

https://www.pulumi.com/docs/reference/pkg/vsphere/getcontentlibrary/
https://www.pulumi.com/docs/reference/pkg/vsphere/getcontentlibraryitem/

On some pages, the name of the function doesn't match the example given in Go (the other languages seem to be okay, though). As an example, this page is called GetContentLibraryItem but the Go example lists LookupContentLibraryItem (the other languages have the correct form).
On the main page for the vSphere provider, might I suggest the Go example to be slightly different? I'd suggest
package main

import (
	vsphere "github.com/pulumi/pulumi-vsphere/sdk/v2/go/vsphere"
	"github.com/pulumi/pulumi/sdk/v2/go/pulumi"
)

func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {
		dc, _ := vsphere.NewDatacenter(ctx, "test", &vsphere.DatacenterArgs{
			Name: "Production-DataCenter"
		})

		return nil
	})
}

I think this would help devs that want to get started with a complete working sample.
Affected product version(s)
Pulumi Docs

Regarding Get vs. Lookup, please see https://github.com/pulumi/docs/issues/3075

Sorry if I missed it, but I wasn't sure which links you're referring to that 404? The double .. is indeed odd, but I didn't see a broken link there?

There are a few pages where the double dot seems to result in a broken link. For example https://www.pulumi.com/docs/reference/pkg/vsphere/distributedportgroup/ has a link for vsphere..DistributedVirtualSwitch where the target is https://www.pulumi.com/docs/providers/vsphere/r/distributed_virtual_switch.html. The latter page doesn't exist. The issue also exists on https://www.pulumi.com/docs/reference/pkg/vsphere/getdatastorecluster/ where there are links for vsphere..NasDatastore, vsphere..VmfsDatastore and vsphere..VirtualMachine. These links all result in 404 pages.

Thanks for pointing me to #3075 (which does seem to be closed?) for the Get vs Lookup. I agree with @justinvp that adding a note would be helpful for Go devs, especially since both functions exist (as mentioned here https://github.com/pulumi/pulumi-gcp/issues/330 as well).

I opened #4598 to track the third point which is broader than vSphere.  I don't see any instances of ...  Going to close this one out for now.


Python PulsarClient::create_reader() doesn't accept MessageId instance

Python pulsar-client package
Describe the bug
Attempting to provide the function PulsarClient::create_reader() with the param start_message_id as an instance of pulsar.MessageId raises an error. It only accepts a _pulsar.MessageId, which is the internal implementation of MessageId.
To Reproduce
    import pulsar

    pulsar_client = pulsar.Client(
        PULSAR_URL,
        authentication=pulsar.AuthenticationToken(PULSAR_TOKEN),
    )
    message_id = pulsar.MessageId(ledger_id=LEDGER_ID, entry_id=ENTRY_ID)
    pulsar_client.create_reader(TOPIC, message_id)

Traceback (most recent call last):
    ... # my code
    pulsar_client.create_reader(TOPIC, message_id)
  File "/opt/conda/envs/base/lib/python3.8/site-packages/pulsar/__init__.py", line 825, in create_reader
    _check_type(_pulsar.MessageId, start_message_id, 'start_message_id')
  File "/opt/conda/envs/base/lib/python3.8/site-packages/pulsar/__init__.py", line 1338, in _check_type
    raise ValueError("Argument %s is expected to be of type '%s' and not '%s'"
ValueError: Argument start_message_id is expected to be of type 'MessageId' and not 'MessageId'

Expected behavior
Should allow a pulsar.MessageId instance to be provided. Current workaround is to either access the private property message_id._msg_id, or serialize & deserialize to get a _pulsar.MessageId instance.
Here is the line that performs the instance check and throws the error.
Versions

pulsar-client==2.10.0
Python 3.8.13

Close it by https://github.com/apache/pulsar-client-python/pull/95


[4.x] Dynamic config source

Environment Details

Helidon Version: 4.0.6
Helidon SE

Problem Description
Provide a way to create a config source with values wrapped by suppliers, where the suppliers are invoked every time the value is requested.
Use case
An Helidon example demonstrates how to use a client to connect to a remote service, however the example will call the current server to simulate the service.
We can use config to configure the URI to use for the remote service, the main config hard-codes a port so it can also hard-code the URI to use that same hard-coded port.
I.e. application.yaml:
server:
  port: 8080
  host: <IP_ADDRESS>

app:
  client-uri: http://localhost:8080

We use Config.global() in the HttpService to initialize the WebClient instance lazily:
class MyService implements HttpService {

    private final LazyValue<WebClient> clientSupplier = LazyValue.create(() -> WebClient.builder()
            .baseUri(Config.global().get("app.client-uri").asString().get())
            .build());

    @Override
    public void routing(HttpRules rules) {
        rules.get((req, res) -> {
            WebClient client = clientSupplier.get();
            res.send(client.get().requestEntity(String.class));
        });
    }
}

However the test uses a dynamically allocated port, and the routing is initialized before the server is started (meaning that the port is not yet known).
@ServerTest
public class MyServiceTest {

    static String serverUri;

    @BeforeAll
    static void beforeAll(URI uri) {
        serverUri = uri.toString();
    }

    @SetUpRoute
    static void routing(HttpRouting.Builder routing) {
        Config.global(Config.create(
                // wrap the value of serverUri with a supplier
                DynamicConfigSources.create(Map.of("app.client-uri", () -> serverUri)),
                ConfigSources.classpath("application.yaml"),
                ConfigSources.classpath("application-test.yaml")
        ));
        routing.register(new MyService());
    }
}

See a simplistic implementation of DynamicConfigSources:
public class DynamicConfigSources {

    public static ConfigSource create(Map<String, Supplier<String>> map) {
        NodeContent content = NodeContent.builder()
                .node(new DynamicContentNode(map))
                .build();
        return (NodeConfigSource) () -> Optional.of(content);
    }

    private static final class DynamicObjectNode extends AbstractMap<String, ConfigNode>
            implements ConfigNode.ObjectNode {

        private final Map<String, Supplier<String>> delegate;

        private DynamicObjectNode(Map<String, Supplier<String>> delegate) {
            this.delegate = delegate;
        }

        @Override
        public Optional<String> value() {
            return Optional.of(toString());
        }

        @Override
        public Set<Entry<String, ConfigNode>> entrySet() {
            return delegate.entrySet().stream()
                    .map(e -> Map.entry(e.getKey(), (ConfigNode) new ValueNodeImpl(null) {
                        @Override
                        public Optional<String> value() {
                            return Optional.ofNullable(e.getValue().get());
                        }

                        @Override
                        public String get() {
                            String s = e.getValue().get();
                            return s != null ? s : "?";
                        }
                    }))
                    .collect(Collectors.toSet());
        }
    }
}

Note that the code above only works because ValueNodeImpl is public and non-final. This allows us to create an implementation that is backed by Supplier<String> instead of String. Also the code above does not handle list values.

In a previous discussion of dynamic config sources we came up these characteristics (which go beyond what is requested in this issue):

The set of keys is unbounded and not known in advance
Lookups are expensive
Caching of values and control of caching policies is important
Defining the key space (with key patterns or prefixes) is important to guard against spurious lookups and to define the range of keys supported by the config source
Values in the config source may change at any time via external mechanisms

Note that the secrets-config-source also dabbles in this area.

Related issue: #7745


Using ros from inside a system-docker container

How do I map the ros binary into a system-docker container so that I can enable services from inside it?  I have a 'bootstrap' container that runs on system-docker and is supposed to take user input via a web GUI, generate a Rancher service file, enable it, and reboot the box.  The service file is generated and the reboot command works, but ros is not in $PATH so the ros s enable command fails.
Here's the bootstrap service file so you can see the config I'm using.  I've tried several permutations of mapping /usr/bin/ros, all-volumes, and links with no luck.  I have the sneaking suspicion that I am missing something obvious...
yolk:
  image: yolk:test
  privileged: true
  links:
    - cloud-init
  ports:
    - "8000:8000"
  restart: always
  environment:
    - "URL=https://<IP_ADDRESS>:8443/rest/ova"
    - "TLS_NO_VERIFY=1"
    - "MTIAAS_LOGDIR=/var/log"
  labels:
    - io.rancher.os.scope=system
  volumes:
    - /var/lib:/var/lib
    - /var/run/docker.sock:/var/run/docker.sock
  volumes-from:
    - all-volumes
  ipc: host
  pid: host

What am I missing?

To answer my own question: I had volumes-from instead of volumes_from -_-


[QUESTION] Internet Connection

Does the Plug need an Internet connection?

The connection works over the local network so an internet connection isn't required but a connection to the local network is. Hope this answers your question :)


Complete removal of TLS

Codecov Report

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

@@            Coverage Diff             @@
##           master     #128      +/-   ##
==========================================
+ Coverage   61.46%   61.63%   +0.16%
==========================================
  Files          36       36
  Lines        1199     1199
  Branches       12       12
==========================================
+ Hits          737      739       +2
+ Misses        462      460       -2

Impacted Files
Coverage Δ

core/src/main/scala/laserdisc/protocol/KeyP.scala
92.68% <0%> (+2.43%)
:arrow_up:

Continue to review full report at Codecov.

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


Add missing lmdb package and pin the version numbers of other third party dependencies

Currently lmdb is being imported in lsun datasets, but this is not part of third party dependency in the requirements file.
https://github.com/pytorch/vision/blob/master/torchvision/datasets/lsun.py#L15
Also, it is a good practice to pin the version numbers of third party dependencies to protect backwards incompatibility that third party packages can introduce.

lmdb is not a hard dependency, which is why it  was not included. it is only required to use the lsun dataset and nothing else.
we don't have a hard pinned set of versions we need.

I am not sure I understand the argument of hard dependency.
If that would not be part of requirements.txt, it should be in dataset-requirements.txt as datasets submodule has a dependency on the this particular package.
As a user if I install the pytorch package and go over readme, I would get import error when I try to load lsun package. We should fix this.
For hard pinned set of versions, I am curious if pytorch would build with numpy 0.0.1. If not please consider at least specifying a minimum version in the requirements.txt for third party dependencies. For more information, please take a look at PEP 0440: https://www.python.org/dev/peps/pep-0440/ which details version spefication and identification.
Pinned version numbers make sure that you have a repeatable build process and stable environment where the package works.

We are not going to go for pinned version numbers. At some point we'll have to declare minimum version numbers, will have to come around to that.


Questions about the evaluation

Very nice work!
I have a question about the data pre-processing for image input.
I notice that during training, the data will be processed by:
      input_batch = model.process_batch_for_training(batch)
      input_batch = model.postprocess_batch_for_training(input_batch, obs_normalization_stats=obs_normalization_stats)

But during evaluation, as shown in the /docs/modules/algorithms.md,
policy.start_episode()
obs = env.reset()

horizon = 400
total_return = 0
for step_i in range(horizon):
    # get action from policy (calls @get_action)
    act = policy(obs)
    # play action
    next_obs, r, done = env.step(act)
    total_return += r
    success = env.is_success()["task"]
    if done or success:
        break

It seems that there is no data preprocessing for input. Shall we add the processing procedure by ourselves? Or Is this procedure included in the policy inference ? Thank you!

Great question! The same operations will happen at eval-time, but in different locations.
Observation processing will happen in the environment (for example here) and observation normalization will occur as part of the RolloutPolicy object that wraps the model during inference (see here).


Cluster Mgmt: Move PSP resource to Advanced section

QA TEST PLAN
Scenarios

Scenario
Test Case

1
As a standard user, navigate to Cluster Management and validate that Policy Security Policies is in the Advanced section

Validated this against v2.7-head https://github.com/rancher/rancher/commit/d1249b5c6907bd326e09ec79d9ac8d9c22782d0d. Details below:
ENVIRONMENT DETAILS

Rancher install: Helm
Rancher install: v2.7-head https://github.com/rancher/rancher/commit/d1249b5c6907bd326e09ec79d9ac8d9c22782d0d
Browser: Chrome

TEST RESULT

Scenario
Test Case
Result

1
As a standard user, navigate to Cluster Management and validate that Policy Security Policies is in the Advanced section
:white_check_mark:

VALIDATION STEPS
Scenario 1

Setup Rancher, created a standard user and logged in as that user.
Navigated to Cluster Management > Advanced.
Validated that Pod Security Policies appears underneath:


Feature/createuser

Resolves #35, Resolves #36.
Description:

External User sign up
Internal User sign up
Email Service
Validators

@Mitikaa please review


corrupted wallet file / odd behavior

I loaded with wallet with errors many many times over the week, I was now using a backup version.
For some weird reason the wallet ended up loading properly at last while I was documenting this.
The behavior was before was "Wallet load error" popup and all accounts would show but postmix would not.
Can close this issue once ACK
2022-12-15 00:13:32,259 ERROR [JavaFX Application Thread] c.s.s.AppController [null:-1] Error opening wallet
java.util.ConcurrentModificationException: null
	at java.base/java.util.TreeMap$PrivateEntryIterator.nextEntry(Unknown Source)
	at java.base/java.util.TreeMap$KeyIterator.next(Unknown Source)
	at com.sparrowwallet.drongo/com.sparrowwallet.drongo.wallet.WalletNode.copy(Unknown Source)
	at com.sparrowwallet.drongo/com.sparrowwallet.drongo.wallet.Wallet.copy(Unknown Source)
	at com.sparrowwallet.sparrow@1.7.1/com.sparrowwallet.sparrow.io.Storage.restorePublicKeysFromSeed(Unknown Source)
	at com.sparrowwallet.sparrow@1.7.1/com.sparrowwallet.sparrow.AppController.openWallet(Unknown Source)
	at com.sparrowwallet.sparrow@1.7.1/com.sparrowwallet.sparrow.AppController.openWallet(Unknown Source)
	at com.sparrowwallet.sparrow@1.7.1/com.sparrowwallet.sparrow.AppController.lambda$openWalletFile$39(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
	at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
	at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.EventHelper.fireEvent(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Service.fireEvent(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Service.lambda$new$4(Unknown Source)
	at javafx.base@18/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase.markInvalid(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase$Listener.invalidated(Unknown Source)
	at javafx.base@18/com.sun.javafx.binding.ExpressionHelper$SingleInvalidation.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase.fireValueChangedEvent(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase.markInvalid(Unknown Source)
	at javafx.base@18/javafx.beans.property.ObjectPropertyBase.set(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Task.setState(Unknown Source)
	at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.lambda$call$1(Unknown Source)
	at javafx.graphics@18/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at javafx.graphics@18/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Unknown Source)
	at javafx.graphics@18/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
	at javafx.graphics@18/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
	at javafx.graphics@18/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

Thread race condition avoided in 064708f0. Should be a slight performance increase too for very large wallets.


Orbit uPort integration

Orbit uPort integration
This post describes a way to relatively quickly integrate uPort with Orbit. The user will be able to use their uPort name and profile picture in Orbit as well as provision a signing key that will sign Orbit messages. It will not require any changes to the uPort mobile app.
User Flow (connecting uPort):
Orbit shows a QR code, the user scans it with her uPort app, this connects your uPort and provides Orbit with the address/identifier of your uPort (See web.whatsapp.com for the general idea). A random private signing key is generated in Orbit. Orbit displays another QR code, when scanning this the public key is added to the attributes of your uPort, stored in IPFS. (Two QR codes is not ideal UX-wise, but works without changes to the mobile app). This in effect “provisions” the Orbit key since it would be indirectly signed by your main uPort device key when data is added to the Ethereum registry. QR code scanning and related stuff is in the main uport-lib repository.
Orbit can pull the users attributes (name, photo) from the IPFS hash stored in the uPort registry, using the uport-persona library. When sending a message the Orbit user can have their uPort address in the “from” field, and they can sign the payload of their message as a JSON web token using something like this.
When another user fetches the message they can query Ethereum for the IPFS hash of  attributes belonging to that identity, as well as their Orbit public signing key. They can then save these attributes locally. The public signing key is used to verify the signed messages.
Bonus
If there is interest we can also provision an encryption key in a similar way. This would allow for encrypted direct messages and group messages for predefined groups. We would need to clean up some of the encryption libraries for this.
Action items

Make sure @haadcode and @jbenet has access to the uPort iOS app through TestFlight (@christianlundkvist will need their iCloud email addresses for this, does @haadcode have an iPhone?)
Make sure @haadcode and @jbenet can access the uport github repos to see how to integrate
@christianlundkvist can help with more detailed descriptions of the steps to integrate.

This is fantastic Christian! Pretty much how I imagined it to work, and how Orbit used to work. I don't have an iPhone but we'll arrange one.
There's some work I need to in both in Orbit and orbit-db to support signed messages.
Not sure yet if we should try to support encrypted messages, it's fairly large amount of work and there's quite a few unknowns. But what you described will get us started and towards a great demo!
I'll get back to you with more questions as soon as I start working on this (couple of weeks ish)

Cool, sounds good! Agreed that encryption support is a big task to do correctly. Let me know if there is anything you need further.

Dependencies:

[ ] https://github.com/haadcode/orbit-db/issues/57
[ ] https://github.com/haadcode/ipfs-log/issues/34

@christianlundkvist can i get uPort iOS app?

@jbenet

I can haz uPort iOS app?
Of course! I just need the email you use for iCloud so we can add you to TestFlight. Install TestFlight and you should be able to install uPort once we add you.

Great!
-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v2.0.55
Comment: https://keybase.io/crypto
wcBMAwmqT7D1KI2uAQf+NJQTkuZuKYh794kWI8OZk7ZuBf+S0zpBquoh0kY2ojjO
fqhafX5wE0Ie0f5SueR11sdwgfU5eAgVQp2mgXVyqYPZyp1pbCogBTb5myT2vLdv
pFCOni3KP1R4sVsY4lnS4TUU0OX2YtP6SUGJAmNJptUk1nPpPoV9r1bhi5cMnQbV
ockFnsHuNX5dx22NpG4bPZmNqWF/FuefyD5+CcyghCt7uwTgbcodCCZbYw13an0O
kiId+CuagvC6mv9O1LqD0SVu3IMNjggWKnpmWtYyYhkqJ9O/nkK2QdHTL46AEGdp
E3SX0EDs1tYilPqsf8VWMH2m4RpuVM1+XuZGTgOROtJJAQOA++lLjTCT2d/Jsqub
usJrpLK0tj7LKaLl1tAOyJC4uot7TkMLW0//y4nOFRoVa5q88d12t/zHWsKtZj2q
uNvcSaS3u0cmlQ==
=Sv6w
-----END PGP MESSAGE-----
wow PGP is ugly.

Thanks @jbenet! I'm adding you and @haadcode to the TestFlight program so you can get the app!
Cheers,
C

Got it and have it running with a profile. Will start working on this tomorrow.

Progress:

cc @christianlundkvist

On the internet, nobody knew you were really a cat. Until uPort!

😹 😹 😹

@haadcode that's great! 👍

Haha awesome job! Glad you managed to push through despite the issues! 😃 @haadcode are you adding an orbit signing key to the uPort profile? Or is that the uPort signing key you're displaying?

Would be good to derive one for orbit.
@christianlundkvist do you have some standard / recommended way to derive keys?

@christianlundkvist atm neither. there's still an issue in the uPort app re. getting the pub signing key from Persona and I was thinking using that. I'll do a test to add the Orbit signing key to the profile and use it (right now I'm using Orbit signing key, it's just not added to the profile).

We will actually need to derive various keys over time, so we'll need 1 key to be Orbit root key, and then derive keys (HD? or something else?) because we'll be signing a ton. (the more you sign with a key, the easier it is to attack. you dont want to use the same key for signing millions of things)

@jbenet @haadcode I think here we don't need to strictly derive a key from the master key here, we can just generate an orbit key randomly and add the public key to the profile. If you look at the attestation-demo repo we are adding profile data.
The master pubkey is not supposed to leave the device so it would be cumbersome to sign each message with that key, so we do want a specific key for orbit

Ah, sounds good 👍

Sounds good! I'll work on this further tomorrow and will keep you posted.

@haadcode great! you should be able to add it using the uport-profile library.

@jbenet if we want to avoid having long-lived orbit keys we could rotate the orbit key at regular intervals and update the uPort registry accordingly. We will have to think about revocation etc later on but for now it might be enough to have an expiry date for the keys.

Status update:
(see screenshots below)
I've gotten it all working now with Orbit signing key as an attribute in the uPort profile. That is to say: it works now :) The keys generated are stored locally (in Orbit's data directory), so when you sign in, Orbit will use your existing key (as opposed to generating a new one every time). Upon first login, uPort will ask you to sign the attribute (orbitKey) with another QR code. It was quite a bit of work to make it all work nicely, and this included to implementing the whole concept of "Identities" in Orbit as we didn't have that before. Now you can login with uPort or with a username+key combination (automatically handled by Orbit). Should be easy to add more/different providers in the future.  I also made sure that if you change your name in uPort, all messages sent with the old name now display the new name.
The work happens here: https://github.com/haadcode/orbit/tree/uport. However, it's not quite working out of the box yet, I need to do some cleanups/documentation. If you do want to give it a try, see below (run the following commands in order).
You need to have access to the private uport- repos in order for this to work!*
On that note, @christianlundkvist, what's your plan on releasing the uport modules to the public? Without them being public, I can't put the integration to the master branch in Orbit as people won't be able to pull the uport-* repos/modules. So it'd be great to make them public sometime soon...
git clone -b uport https://github.com/haadcode/orbit.git
npm install
cd client/
npm install
npm run build
cd ..
npm run electron

Let me know if you have any troubles!

@haadcode Wow, awesome! That is so cool! 😃

what's your plan on releasing the uport modules to the public?

These modules will definitely be public at least by Devcon, but we could also make them available sooner. We want to improve some of the flows, like for instance it's nicer if when signing an attribute only the attributes gets sent to the phone (via QR) and you assemble the complete JSON on the phone instead of just signing the transaction on the phone as is done now.

Planning to merge all of this to master sometime this week.

Awesome! We're also improving the attestations flow, so you'll soon be able to easily scan your Orbit key, sign it with your uport key and add that to your uport profile.


Precise Dropper not accepting Pipe/Hopper Input

Minecraft version & Mod Version:
MC: 12.2.2
Cyclic: 1.14.2
Single player or Server: Single Player
Describe problem (what you were doing / what happened):
Simply put, the precision dropper does not accept input from entities such as hoppers/pipes
Crash log (if any): N/A

https://minecraft.curseforge.com/projects/cyclic/files/2542723


v0.2.1

New features

A basic package structure to be able to utilize the sequence_jacobian as a python package. Top-level functions and modules located within sequence_jacobian/__init__.py.

steady_state, which automatically solves for the steady state values of the parameters/variables for a given model specification, e.g. a set of blocks, fixed parameter/variable values, unknowns, and targets.
Implemented a rudimentary new block type, HelperBlock, which allows users to include partial steady state solutions as a "block" in the blocks argument provided to steady_state to speed up the computation of the rest of the steady state values, e.g. in the Krusell Smith model, the firm's problem can be solved so steady_state effectively only needs to solve the household problem.

Enhanced SimpleBlock with more flexible displacement handlers (Ignore, Displace, and the newly implemented IgnoreVector and AccumulatedDerivative [replacing Reporter and Perturb]) to allow for more general specifications of equations within a SimpleBlock.
This includes the ability to call time displacements on variables newly defined within a SimpleBlock, to evaluate variables using arbitrary functions—single-argument functions are called by invoking the .apply(f) method of any variable within a SimpleBlock, and multi-argument functions are called by invoking apply_function(*args)—while maintaining displacement-relevant information, and to write equations that involve arbitrary compositions of newly-defined variables with input arguments into the SimpleBlock.

A pytest testing suite located in sequence_jacobian/tests/base, which unit tests for the basic functionality of the Sequence Space Jacobian package. This includes testing most of the computations displaced in the Jupyter notebooks included with this package.

hetoutput—functions of the individual-level policy variables from a given HetBlock—can now be included as outputs users get from steady state and transitional dynamic computations by using the add_hetoutput features in sequence_jacobian/blocks/het_block.py. Currently hetoutput are limited to being the same dimension as the cross-sectional distribution D and hence there is no capability for "custom" aggregation of hetoutputs. All hetoutputs are aggregated linearly across D, just as the standard individual-level policy variables are aggregated across D.
An example of a hetoutput is the adjustment_costs of agents across the two-dimensional asset distribution in the two asset HANK model located in sequence_jacobian/models/two_asset.py. This hetoutput can be added to the household block using household.add_hetoutput(adjustment_costs).

Work-in-progress features
These features exist in the code currently but in an unfinished state.

CombinedBlock in sequence_jacobian/blocks/combined_block.py currently works when included in the set of blocks called in steady_statei, i.e. .ss for a concrete instance of the block works; however, transitional dynamics (.td) and calculation of the Jacobian (.jac) have yet to be implemented.
HelperBlock in sequence_jacobian/blocks/helper_block.py currently works when included in the set of blocks for steady state, transitional dynamics, and Jacobian calculations; however, most of its functionality is not contained within the HelperBlock class itself, but rather in other code such as block_sort, which checks if blocks are of HelperBlock when deciding how to conduct the sort. May revisit the design principle behind having a block that is virtually identical to a SimpleBlock albeit with more limited abilities as a stand-alone class simple as a way for methods to inspect differently.
Block, and Model in sequence_jacobian/primitives.py are meant to be abstract base classes to provide more unifying concepts within the Sequence Space Jacobian package.
Performance-based tests in sequence_jacobian/tests/performance and more granular unit tests in sequence_jacobian/tests/base and sequence_jacobian/tests/robustness.

Breaking changes

Re-organized most of the file locations when implementing the basic package structure. Absolute/relative imports of local modules changed due to this.
In particular, sequence_jacobian/utils.py has been broken up into separate modules contained in the sequence_jacobian/utilities directory to make it easier for users to locate utilities and define new ones.
Moved SimpleSparse class to sequence_jacobian/jacobian.py
Changed all keyword arguments noisy, set to True if the user wanted a particular function to provide print statements of its functionality, to verbose to be more descriptive.
Changed attach_hetinput to add_hetinput and instead of returning a new instance of the HetBlock, it modifies the existing HetBlock in place. Note add_hetinput has an overwrite kwarg to allow users to switch out existing hetinputs for new ones.
Changed the names of the various attributes of HetBlock to be slightly more descriptive. Some examples include: non_back_outputs -> non_back_iter_outputs, and inputs_p -> inputs_to_be_primed.

Updated with fixes to notebook code and unit tests! Released as the patch v0.2.1

I will introduce these changes onto a new branch in the repository for now, so as to not disrupt work currently happening on the `develop' branch


502 bad gateway Nginx

Hello!
I launched an entirely new instance just for huginn, and all the installation steps went by very smoothly; however, when I tried accessing it via my browser, I got a Nginx error 502 'bad gateway'. Any suggestions?
Please note im very new to programming.
Here is what I found in my Nginx error log:
2017/02/04 19:04:56 [error] 8962#8962: *1 connect() to unix:/home/huginn/huginn$
2017/02/04 19:04:56 [error] 8962#8962: *1 connect() to unix:/home/huginn/huginn$

What's your serve memory?
In my case, It cannot work perfectly both nginx and huginn on a 512M VPS without any optimization.
I got 502 bad gateway.

did you edit your Procfile as in the instructions to choose one pair of settings there?

Please post the contents of all logs listed in the troubleshooting section. 502 errors usually mean either the unicorn server is not running or not configured properly.

I am closing this issue. Please feel free to reopen if you need further assistance!


Change journey map to journey mapping

When I work with my clients, I notice a hyper - focus on the artifact of the journey map, when really, I want us to emphasize the engagement - the verb - of using this activity as a brainstorming exercise. I think that a simple way to do this is to change the framing from map to mapping.
cc/ @pamela-drouin  @isaacdurazo @susanjrobertson - thoughts on this?

Makes sense to me!
On Wed, Feb 1, 2017 at 5:38 AM, iamjessklein<EMAIL_ADDRESS>wrote:

When I work with my clients, I notice a hyper - focus on the artifact of
the journey map, when really, I want us to emphasize the engagement - the
verb - of using this activity as a brainstorming exercise. I think that a
simple way to do this is to change the framing from map to mapping.
cc/ @pamela-drouin https://github.com/pamela-drouin @isaacdurazo
https://github.com/isaacdurazo @susanjrobertson
https://github.com/susanjrobertson - thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bocoup/opendesignkit/issues/224, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFrJSdCvTA7v4VhlbWbWYEBjveHbTNVYks5rYIrYgaJpZM4Lz30S
.

--
Pam Drouin
UX Designer @Bocoup

@susanjrobertson I made this change & PR is ready for review

This was fixed and is live on the site, so gonna close the issue.


Installing<EMAIL_ADDRESS>failed

lang-gdscript does not install on my system
OS: Ubuntu 20.04
Atom: 1.46.0
here are the logs :

Hey, thanks for posting an issue. I'm not sure why this would happen. Can you attach the complete debug log?
Also, try updating to the latest atom version. Right now it's 1.47.0. Although it should work for 1.46.0.

Ok

The issue was the version,I reinstalled atom to update it and it worked

Thank you for letting me know!


Prevent user from interacting with likes/dislikes, when user is not signed in

User should not be able to interact with like/dislike buttons, cause the backend server ignores this type of request, cause the user is not authenticated.

fe0fff3a5519634c14ab79845ea4c21de5bb6364

Bug fix for logged in users in 2a9f6cfb6552e782eba9382d5320696e50bb086a


several calls

Hello.
Thanks for the greate tool.
Can you please look into adding several method calls inside one session (like authorizing in grpc session and then do several calls in the same session).
Thanks again

Hello,
Similar questions have been asked before. There is no really easy way to accomplish this using the CLI. My suggestion would be to script a test using the Go package API. Alternatively you may be able to accomplish something using one of the other testing tools such as hazana perhaps (note I have never used it). Hope this helps!


Chair already occupied message even when seat is free

BetterChairs-v1.6.0.jar on Paper version git-Paper-458 (MC: 1.19.4) (Implementing API version 1.19.4-R0.1-SNAPSHOT) (Git: 5100822)
Pretty low priority, as you can just turn off the messages.
If AllowSwitchingSeats: and AlreadyOccupied: are both set to true. The already occupied message will show even when the "seat" is empty. Trying to switch seats to one the player already occupies pops the message twice.
I'll update the ticket when I test this with other players :)
Video.
https://user-images.githubusercontent.com/19421154/226197852-063d588c-3808-4584-a581-bc43208c391a.mp4

Well that looks weird 😄

Thanks for your report again! Honestly, I forgot about this 😅
I think I fixed it in the release I published today - Would you be able test and see if it is fixed now?

All good brother, I also forgot, everything looks good to me! Thanks for your work!


Split out the semantics logic from object.dart somehow

From https://github.com/flutter/flutter/pull/1309#discussion_r50804786:

I wonder if we can extract a SemanticsProvider interface from RenderObject that we can use in these classes instead of RenderObject. That might let us move this code out of object.dart into semantics.dart.

I'm going to close this because it's something that will either happen naturally when we are working in this code, or something that won't happen, but realistically it'll never be something we do for its own sake.


test: remove workaround for withastro/action, for #195

The Issue

#195

How This PR Solves The Issue
My workaround is no longer needed as the fix has been merged upstream.
Checking if the tests work without it.
Manual Testing Instructions
Automated Testing Overview

Related Issue Link(s)
Release/Deployment Notes

Pull when you're happy with it.


⚠ Bofrost.at has degraded performance

In cca0f4b, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2510 ms

Resolved: Bofrost.at performance has improved in 2dfd92f after 6 minutes.


Missing types in C++ API

It looks like there are some missing types in tensorflow/core/framework/types.h, such as uint32 and uint64. This means I can't make tensors of these types in C++.

Hi, I can work on this. Starting with the open source for the first time. Can I get more details regarding the issue. Thanks.

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!


Guzzle long-term support plans?

Drupal has used Guzzle for a number of years. We will be shipping Drupal 9 next year, and are hence evaluating all of our dependencies. Hence this issue :)
Will Guzzle 6 be supported through at least the end of 2023 (which is when Drupal 9 will go EOL)?

Is Drupal built on Symfony components. Symfony has a new HTTP Client component which is becoming stable in Symfony v4.4.0 and v5.0.0, and will be supported for a long time. Maybe that would be a good replacement for Guzzle, with well defined maintenance and security periods?

Thanks @GrahamCampbell. Part of the reason for us reaching out is exactly that we need to decide whether to add a dependency on the HTTP client component, and whether we do that for Drupal 9 (released June 2020 and EOL probably in Dec 2023) or Drupal 10 (release schedule not yet totally defined but we might have to ship it in June 2022 or so because Drupal 9 is going to depend on Symfony 4.4 and therefore be tied to their end-of-life. Currently, symfony/http-client is missing some functionality we need that Guzzle provides.
If we know more about the Guzzle maintainers' longterm plans for Guzzle itself, that will help us plan for the future. We actively collaborate with Symfony maintainers and so the new component is interesting to us, but Guzzle has also historically been really great for us about security coverage for old minors and coordinated disclosure, and given our release schedule and the current state of symfony/http-client it would be less disruptive for us if we can depend on Guzzle 6 at least through Drupal 9's end of life. :) Right now we are just looking for insight into Guzzle's support future (especially security coverage).
Thanks so much!

Right. Thanks for the details. :)

Our long-term plan for Guzzle (probably 7) is adding PSR-18 support and dropping PHP 5.x support. Actually PSR-18 requires PHP 7, so it depends on whether we decide to drop PHP 5.x support in Guzzle 6 or 7. There are pro-contra arguments on both sides.
Other than that there isn't much that we plan to change.
In case we decide to drop PHP 5.x in Guzzle 6 (BTW: would that be a problem for you?), it will remain the main version. If not, Guzzle 5 will become EOL and Guzzle 6 and 7 will be the supported versions. Since the code will essentially be the same, we will support both versions.

This is exactly the information we needed; thank you so much for the reply!
We've dropped support for PHP 5 already (the last release that both supported it and used Guzzle will be EOL in 3 months). So Drupal at least is okay if you make a chance to the PHP version requirements of Guzzle 6 to be 7.0+, and we can continue to depend on it for a few more years.
As an aside, something to consider. We heard a lot of concerns when we increased our PHP version requirements in a minor release, folks saying it was too disruptive and against semver philosophy. A third path might be:
Guzzle 7: Exactly like Guzzle 6, just requiring PHP 7+
Guzzle 8: PSR-18 and any other BC-breakable things
Like I said, this won't affect Drupal one way or the other just so long as Guzzle 6 has BC other than the PHP version change and security coverage through (in our case) December 2023. :)
Thanks again. This is great news for us.

@sagikazarmark Yep agreed, thanks so much. We also did the PHP major version bump with the same reasoning, but we got pushback about it because even though we were following the semver spec, there is a really widespread expectation that semver means only doing major dependency updates in major versions. :) And thanks for the clarification about PSR-18; I remember wondering about the PHP 7 requirement when I looked at that PR awhile back.

I think the root cause is the fact that PHP 5.x to 7.x upgrade is not necessarily easy, especially in ...hm, "traditional" web development environments (aka. the sysadmin installed PHP with apt).
With the spread of container technologies where upgrading a PHP version is really just a push of a button this will probably get better. But we are not there yet. 😕
PSR-18 requiring PHP 7 was also a decision for the crowds, at least for the few loud people shouting on the FIG mailgroup. Mainly because the exception implements Throwable and tools like PHPStan don't complain. Other than that (and the return type) it has no advantage at all.

TLDR:

Will Guzzle 6 be supported through at least the end of 2023 (which is when Drupal 9 will go EOL)?

No, we cannot make this promise.

Will Guzzle 7 be released soon?

Yes. Hopfully this year

What should Drupal and other projects do?

Depend on an interface, not an implementation. Use PSR-18.


Improving support for unions of Iterators

Many methods in Iterator break when the receiver is a union of Iterators, for example:
it = Iterator.of(1) || Iterator.of(true)
it.map(&.to_s) # Error: no overload matches 'Iterator::Map(Iterator::Singleton(Int32), Int32, String).new' with types Iterator::Singleton(Int32), Proc(Bool, String)

This happens because the &.to_s block is always inferred to a single type, in this case Bool -> String, even if multi-dispatch occurs. Thus the same block fails to match all dispatches that could happen.
It is possible to manually flatten the iterator by using an identity wrapper and inhibiting multi-dispatch, but it feels cumbersome:
module Iterator(T)
  struct Identity(I, T)
    include Iterator(T)

    def initialize(@iterator : I)
    end

    def next
      @iterator.next
    end
  end

  # *iter* is possibly a union of `Iterator`s
  def self.identity(iter : Iterator)
    Identity(typeof(iter), typeof(Enumerable.element_type(iter))).new(iter)
  end
end

it = Iterator.of(1) || Iterator.of(true)
Iterator.identity(it).map(&.to_s).first(5).to_a # => ["1", "1", "1", "1", "1"]

Is this something that could be solved in the standard library? What would happen instead if the compiler makes it so that &.to_s is typed separately for each overload? Does it even make sense to do so? (I am guessing that it would cause even more problems for uncaptured blocks than captured ones like here.)

It seems that we can change map and Map to this and it works:
  def map(&func : T -> U) forall U
    Map(typeof(self), typeof(func), U).new(self, func)
  end

  private struct Map(I, F, U)
    include Iterator(U)
    include IteratorWrapper

    def initialize(@iterator : I, @func : F)
    end

    def next
      value = wrapped_next
      @func.call(value)
    end
  end

And we can probably do a similar thing with select, reject, etc. (everything that takes a proc)

Ah, right. Maybe the block should have two differen types, one for each overload? After all the dispatch will only choose one of them. Of course this requires a language change and I'm not sure how challenging that is to implement, whether it will solve this problem or even introduce other problems :-)


Set shorter timeouts when calling AWS services

boto3 default timeout is 60 seconds for connect and read/write. This
is higher than the max 29 second timeout for API Gateway calls to Lambda
functions. Lowering the timeout when calling Kinesis and DynamoDB to
avoid Lambda functions terminating without any error handling or logs.

 Timeout ved skriving til Kinesis i event-collector


Minimum iOS platform version requirement

Why has the platform dependency changed to require iOS12? This makes it such that any app that requires supporting a past OS version can't use the Pod even though from a code perspective it still fully supports them. Upgrading to Swift 4.2 shouldn't require a minimum version dependency change from 11 to 12. Could this please be changed back? Jumping from iOS 8 to 12 is a huge change.

Hi, you can use the version 0.0.4 for older version. This library hasn't reached its stable version 1.0.0 yet. So it might constantly be updated.

Except you can't. The only version that supports Swift 4.2 is the 0.0.5 version which you can't use if your builds target anything lower than iOS 12. In other words, if you wan't to use this pod, your app can only be built to support iOS 12 (whose adoption is less than 30% currently). Anyone who wants to support the larger 70% of iOS users can't use it. I just don't understand this decision especially because from a technical point of view there is zero reason for it. Literally the only change is to make the podspec listed as iOS 11 instead of 12. No other code needs to be changed.

Of course you can! You don't have to use the latest version in any of your projects.
If you have projects that target iOS version lower than 12, you can use the version 0.0.4. If you have projects with iOS 12 you can use 0.0.5 our even 0.0.4 and add a post install configuration ordering it to be ran with Swift 4.1. No changes have been made except for the update to Swift 4.2, so this is not a big deal. Anyways, I've regressed the library back. You can use 0.0.6 from now on.


The x axis not moving

Im trying to make this chart
but it the x axis wont moving like the examples

<script src="vendor/moment.js"</script>
<script<EMAIL_ADDRESS>
i already add the js to my file.
Any help?

How did you fix it?

I fixed it by down grade lib to version 1.8.0


Changed Flow to Power Automate

Changed "some" of the Flow references to Power Automate. In front of a customer rn :)

@fmigacz : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@fmigacz I've moved your commit into the private repo, where I did some additional rename work. You can review the other changes here before I merge into master.

#please-close


As connext eng, I want a script that does a check-up on asset configuration for all supported chains.

Problem
Just want something that takes inventory step-by-step, with minimal input, checking to make sure whether an asset is set up on each chain. I'm imagining it produces a list of each chain and whether the asset is not set up, partially set up, or fully configured for that chain (in the console)
Ideas to solve this
Script that takes an input of a canonical ID and then just making sure the asset's configured correctly. If the asset is partially configured, mark all parts where the configuration is messed up.
As an additional bonus, might be nice to hook in the Deployer keys and then just have it "autofix" the problems... but that could be a second follow-up task from this one.

Closing per grooming with Layne/Rahul


Fix the issue where start/end time defined in SegmentGeneratorConfig is not picked up by IndexCreator

When generating segment, if start/end time is defined in SegmentGeneratorConfig, use the one in the config
Move the SIMPLE_DATE time value conversion logic into IndexCreator from SegmentIndexCreationDriver
New logic is covered by SegmentGenerationWithTimeColumnTest

How are we catching these issues? Can we add appropriate unit tests with the fix?


Doesnt want to start

After starting MudaeAutoBot.py there is nothing happening in terminal

turn console logging on in the code and you will see if there is an issue there

Thank you it was long text i think was token misstake i fixed it it works but for somereason after start it claimed 2 times randomly

oh okay i was looking at claim part a little i think issue was in not havving anything in series list , i put "0" will it work fine or should i change to something else ?

No 0 will not work as anything with 0 in it will be claimed

seemed to work fine , i changed to some random text tho thank you for help :)


fix(local): skip OS environment for detached processes

Part of the effort for https://github.com/go-vela/community/issues/54
I was playing around with the CLI locally trying to run pipelines on my workstation.
I noticed that when I was running services with a specific image that I would get errors trying to execute them.
Here is a snippet from the pipeline I was using:
services:
  - name: postgres
    environment:
      POSTGRES_DB: example
      POSTGRES_PASSWORD: somePassword
      POSTGRES_USER: example
    image: postgres:latest
    ports:
      - "5432:5432"
    pull: not_present

The error message I was getting looks like this:
[service: postgres] /usr/local/bin/docker-entrypoint.sh: line 82: initdb: command not found

At first I thought I was crazy because I had previously tested running services locally with other images:
services:
  - name: mongo
    image: mongo:latest
    ports:
      - "27017:27017"
    pull: not_present

And:
services:
  - name: redis
    image: redis:latest
    ports:
      - "6379:6379"
    pull: not_present

After some digging, it turns out that injecting the OS environment variables for services can cause issues.
From what I saw, if your OS environment contains "system" level variables like USER, HOME, PATH etc. that can cause a conflict and overwrite the defaults provided in an image that depends on those i.e. postgres
The reason this wasn't caught earlier is most of my testing involved using the mongo and redis images.
I found it best to skip injecting OS environment variables all together, for anything under the services section of YAML.
EDIT:
Like @davidvader pointed out, this also exists for steps with detach: true as that is functionally equivalent to services.
I've augmented this to no longer inject OS environment variables if a step is setup to run in a detached mode.

does the same occur for step images that use system variables such as PATH ?
https://github.com/go-vela/compiler/blob/e3e30fec5ef6ac7d385188b209007806249d4b4c/compiler/native/environment.go#L57-L66
For example if I wanted to use postgres with detach: true? Would the same issue occur?

have we considered making this.... optional? sort of like docker run and the -e flag?

does the same occur for step images that use system variables such as PATH ?
https://github.com/go-vela/compiler/blob/e3e30fec5ef6ac7d385188b209007806249d4b4c/compiler/native/environment.go#L57-L66
For example if I wanted to use postgres with detach: true? Would the same issue occur?

Yes that is correct 👍

@davidvader I believe I have updated the PR to address your feedback 👍


Adding name to contributors.md

test comment

Did not get the issue with commit ?

@mkfeuhrer what do you mean?

@urdarinda tushalien commented previously  'test comment' , then i replied this.


Build-CMakeBuild fails if there's only a single preset, and one isn't explicitly specified

The following code snippet is used to get all of the preset names from the presets json:
    $PresetNames = GetBuildPresetNames $CMakePresetsJson

But if there's only a single preset, then $PresetNames is a string, rather than a collection of stings. And then the code does:
        $Presets = , $PresetNames[0]

hoping to get the first specified preset as a default. The [0] gets the first item from a collection, but the first character in a string. So if there's only a single preset in the CMakePresets.json file - say, 'windows-x64' - the default is chosen to be 'w', which isn't a preset and things fail horribly. If the code were to $Presets = , ($PresetNames[0] | Select-Object -First 1), then things seem to work as expected.

Fixed with #14.


ERR Failed to execute 'invoke' on 'CreateURLCallback':

use built-in debugger
run the "VS Code" launch config
often, not always see the error below

ERR Failed to execute 'invoke' on 'CreateURLCallback': The provided callback is no longer runnable.: Error: Failed to execute 'invoke' on 'CreateURLCallback': The provided callback is no longer runnable.
    at BrowserScriptLoader.load (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:682:52)
    at OnlyOnceScriptLoader.load (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:618:32)
    at loadNextPath (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1677:41)
    at ModuleManager._loadModule (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1689:13)
    at ModuleManager._resolve (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1774:26)
    at ModuleManager.defineModule (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1421:18)
    at ModuleManager._relativeRequire (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1455:18)
    at result (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/loader.js:1629:30)
    at vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/textMate/browser/abstractTextMateService.js:171:113
    at new Promise (<anonymous>)
    at TextMateService._getOrCreateGrammarFactory (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/textMate/browser/abstractTextMateService.js:171:74)
    at Object.createTokenizationSupport (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/textMate/browser/abstractTextMateService.js:200:59)
    at TokenizationSupportFactoryData._create (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/editor/common/tokenizationRegistry.js:117:63)
    at TokenizationSupportFactoryData.resolve (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/editor/common/tokenizationRegistry.js:112:45)
    at TokenizationRegistry.getOrCreate (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/editor/common/tokenizationRegistry.js:58:27)
    at ExtensionPoint._handler (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/textMate/browser/abstractTextMateService.js:120:54)
    at ExtensionPoint._handle (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/common/extensionsRegistry.js:87:22)
    at ExtensionPoint.acceptUsers (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/common/extensionsRegistry.js:80:18)
    at AbstractExtensionService._handleExtensionPoint (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/common/abstractExtensionService.js:1041:28)
    at SandboxExtensionService._doHandleExtensionPoints (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/common/abstractExtensionService.js:992:46)
    at SandboxExtensionService._startLocalExtensionHost (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/electron-sandbox/electronExtensionService.js:444:18)
    at async SandboxExtensionService._scanAndHandleExtensions (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/electron-sandbox/electronExtensionService.js:412:13)
    at async SandboxExtensionService._initialize (vscode-file://vscode-app/Users/jrieken/Code/vscode/out/vs/workbench/services/extensions/common/abstractExtensionService.js:613:17)

It looks like the trusted types factoring for creating urls is somehow becoming invalid. I only see this when debugging and not in when running VS Code for real. This recovers after a renderer reload

@jrieken The stack points to this line which came in with the trusted types work in the loader. I'm happy to help with loader problems as best I can but this seems to be a problem of combining trusted types and debugging. Maybe we need to disable trusted types when debugging?

There seem to be assorted issues in Chromium regarding that error, and a few more that are closed. There is one open issue that evaluating trusted types while the debugger is paused fails, but that doesn't seem to be what you're encountering here. I don't like the idea of turning off trusted types while debugging, since that makes it easy to create something that only breaks 'in production'.
Do you notice any pattern to this happening that we could potentially use to inform a Chromium bug report?

since that makes it easy to create something that only breaks 'in production'.

I don't think that's a good idea because it will simply delay fatal failures which we should spot early on.

The stack points to this line which came in with the trusted types work in the loader. I'm happy to help with loader problems as best I can but this seems to be a problem of combining trusted types and debugging

I know where this coming from but I also know that this was working for the longest time and only became an issue recently (roughly six weeks ago). So, I wonder if was caused by

debugger changes?
electron changes?
changes that we made for bundling main/CJS resources?

Chromium issue search turned up 1131368, could that be the root problem?

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!

This does seem to be a bug in Chromium. The error message indicate some unsoundness issue; there's several upstreams issues on Chromium about this problem which remain open.


Change to HTTP readiness probe for build-server (#1323)

The TCP probe tends to have issues, especially when running with linkerd. This change switches the probe to an HTTP GET probe, which is already enabled in the build-server.
A special note about this change: since this is changing the deployment spec for the build-server, all currently running build-servers will be restarted once this fix is pushed out to users.
If redeploying all currently running build-servers is not acceptable, then altering these changes to take affect only when the BuilderInstance generation changes would be possible, however, would be more involved. I pushed it this way because of the simplicity, but am happy to implement the more involved logic.
Checklist

[x] The title of this PR would make a good line in Acorn's Release Note's Changelog
[x] The title of this PR ends with a link to the main issue being address in paranthesis, like: This is a title (#1216). Here's an example
[x] All relevant issues are referenced in the PR description. NOTE: don't use GitHub keyworkds that auto-close issues
[x] Commits follow contributing guidance
[x] Automated tests added to cover the changes. If tests couldn't be added, an explanation is provided in the Verification and Testing section
[x] Changes to user-facing functionality, API, CLI, and upgrade impacts are clearly called out in PR description

Issue: https://github.com/acorn-io/acorn/issues/1323

I think restarting buildkit service is fine for now. Have we make sure that once we switch to this, simply watching deployment.status.replicas > 0 would be sufficient to wait for buildkit to be up?

@StrongMonkey Even with this change, we still need to do the PingBuilder call. It is possible that Acorn recognizes that the pod is ready and tries to move on before Kubernetes adds the pod to the service load balancer. I saw a few instances where the first GET call in PingBuilder failed with a timeout error, but the second one passed.
The difference between the readiness probe and PingBuilder is that PingBuilder uses the endpoint and the readiness probe uses the pod IP.


Unify Azure.Core Response and Cosmos Response

Cosmos sources: https://github.com/Azure/azure-cosmos-dotnet-v3/blob/master/Microsoft.Azure.Cosmos/src/Resource/Response.cs
We should not ship Response<T> in Cosmos. We should either unify to one Response<T>, or ship two "response" types in Azure.Core.
The reasons Cosmos has a separate response type are:

It supports faster headers lookup (avoids dictionary access). We should measure performance and do optimizations in Response
Allows for inherited response types. This is for both perf and for usability (adds strongly types APIs to subtypes). We should explore using extension methods for this.
Cosmos Response<T> is not Disposable

Also, we should unify headers collection (even if we cannot unify response)

Another big difference is Cosmos.Response is not disposable and has no access to the stream. This prevents users from needing to wrap every response in a using statement.

Related https://github.com/Azure/azure-sdk-for-net/issues/6841

In Cosmos we found that there was 2 types of users. One that wants performance and only wants to deal with streams. The other wants a simple typed world and doesn't want to deal with memory leaks from missing using statements. We originally tried doing a merged response like Azure.Core.Response, and found that it was a bad experience for both users. The solution we arrived at was having 2 different responses. One for the typed responses Response and one for the stream responses ResponseMessage.

FYI, we've merged a change making the Response non-disposable


Ambari dependency for streamline

hello i have finished to compile registry + streamline  and they  run side by side
but a dependency to Ambari is mentioned  in the streamline GUI ( config/service pool)
please is it mandatory  to  experiment streamline with Ambari ? or can i expect
run it with just a dependency to storm and  registry ?
best regards

No ambari dependency to create service pools. You can add storm/zk/kafka etc with manual service pool configuration by giving respective component's configuration.

Actually there is some issue to register services manually. #780 is one of them.
Copying comment from #780:

Thought about manual registration more, and I also found what I was missing: configuration file doesn't have default value hence and we can't get the default value anyway.
We need to define required fields for service and let user also input on registering. Since we add resource file for Hadoop / HBase / Hive in topology, we may not need to define required fields for those services, but need to define for others.


New paper

Hi!
Thanks for creating the repository. It was really useful for literature review!
I believe that our paper: https://arxiv.org/abs/2409.18025 fits the topic of your repository. Could you add it?
Best,
Jakub

Hi!
Thanks for mentioning it. I have included your paper in the latest commit. Great work, by the way!
Closing this issue now.


Write a blog post related to WebSockets

Description:
$subject.

https://bhashineen.medium.com/go-real-time-with-ballerina-websockets-58c40ac11d6


Sprotty Visibility Bounding Box Fix

Use model source element boundingbox for sprotty visibility checking.

Workaround in #105.


187056474 numberline open points

Fulfills the following ticket:
[NLine] Numberline open points

LocalHost
http://localhost:8080/?appMode=demo&demoName=dennis&fakeClass=1&fakeUser=teacher:1&unit=example-config-subtabs&problem=1.1
Deployed Link
https://collaborative-learning.concord.org/branch/numberline-open-points/?appMode=demo&demoName=CLUE&fakeClass=1&fakeUser=teacher:1&unit=example-config-subtabs&problem=1.1

@scytacki I don't believe any of the failing regression tests are due to me and I noticed some that were skipped in master as well. I did fix one related to numberline on my end though.

Got all the tests to pass and re-requested review @scytacki

Got it, and I just updated the branch and I believe we're back to QA (@johnTcrawford ) merging it correct? @scytacki ?

In case QA @johnTcrawford finds an issue where we create a point and then set the min greater than it, and the point persists off the numberline (when it should disappear) - then please ignore that edge case - we'll address that in a later ticket
https://www.pivotaltracker.com/n/projects/2441242/stories/187232408


Fix support for TypeScript 5.x which throws error TS7016

Trying to use Ember CLI Page Objects 2.0.0 with TypeScript 5.1.6 throws the following error:
error TS7016: Could not find a declaration file for module 'ember-cli-page-object'.
'node_modules/ember-cli-page-object/dist/index.js' implicitly has an 'any' type.
There are types at 'node_modules/ember-cli-page-object/types.d.ts', but this result
could not be resolved when respecting package.json "exports". The 'ember-cli-page-object'
library may need to update its package.json or typings.

This seems to be related to this issue.
Updating the page objects package.json locally (as suggested in the issue above) does appear to address the issue for me, but I'm not sure about any side effects or backwards-compatibility issues the change might cause.

Further context -- I believe this is specifically related to using "moduleResolution": 'bundler', and this patch (applied via patch-package or similar) fixes it for me:
diff --git a/node_modules/ember-cli-page-object/package.json b/node_modules/ember-cli-page-object/package.json
index cddb866..e92c917 100644
--- a/node_modules/ember-cli-page-object/package.json
+++ b/node_modules/ember-cli-page-object/package.json
@@ -25,7 +25,10 @@
   "license": "MIT",
   "author": "Santiago Ferreira",
   "exports": {
-    ".": "./dist/index.js",
+    ".": {
+      "import": "./dist/index.js",
+      "types": "./types.d.ts"
+    },
     "./*": "./dist/*",
     "./addon-main.js": "./addon-main.js"
   },

Hey, thanks guys 👋
It feels reasonable for me to provide a few test scenarios to check the build against a couple of  major typescript versions. Probably via ember-try scenarios...
I'll appreciate a PR! Otherwise, I'll try to take a look on a fix this weekend.

When I update package.json as follows:
"exports": {
  ".": {
    "import": "./dist/index.js",
    "types": "./types.d.ts"
  },
  "./*": "./dist/*",
  "./addon-main.js": "./addon-main.js"
},

... then tsc --noEmit passes, but ember build fails with the following error:
ERROR in ../../../../private/var/folders/7s/082kb7n942s1xm4t8_tpb65r0000gn/T/broccoli-20572FT45LJQ4uBmn/cache-574-webpack_bundler_ember_auto_import_webpack/tests.cjs 15:102-134
Module not found: Error: Package path . is not exported from package /private/var/folders/7s/082kb7n942s1xm4t8_tpb65r0000gn/T/broccoli-20572FT45LJQ4uBmn/cache-574-webpack_bundler_ember_auto_import_webpack/node_modules/ember-cli-page-object (see exports field in /private/var/folders/7s/082kb7n942s1xm4t8_tpb65r0000gn/T/broccoli-20572FT45LJQ4uBmn/cache-574-webpack_bundler_ember_auto_import_webpack/node_modules/ember-cli-page-object/package.json)

cleaning up...
Build Error (WebpackBundler)

webpack returned errors to ember-auto-import

However the following works for me with both tsc --noEmit and ember build.
"exports": {
  ".": {
    "import": "./dist/index.js",
    "require": "./dist/index.js",
    "types": "./types.d.ts"
  },
  "./*": {
    "import": "./dist/*",
    "require": "./dist/*",
    "types": "./types.d.ts"
  },
  "./addon-main.js": {
    "import": "./addon-main.js",
    "require": "./addon-main.js",
    "types": "./types.d.ts"
  }
},

I was able to make some progress adding a new ember-try scenario, but currently the scenario passes even without the accompanying change to package.json.
{
  name: 'ember-release-typescript-5',
  npm: {
    devDependencies: {
      '@ember/string': '^3.1.1',
      'ember-cli-typescript': '^5.2.1',
      'ember-resolver': '^10.1.1',
      'ember-source': await getChannelURL('release'),
      'typescript': '^5.1.6',
    },
  },
  env: {
    EMBER_OPTIONAL_FEATURES: JSON.stringify({
      'jquery-integration': false,
    }),
  },
}

As I said, I'm pretty sure this has nothing to do with the typescript version, but rather using "moduleResolution": 'bundler'. I ran into this because my project uses @tsconfig/ember as the base for tsconfig.json and when I upgraded from v2 to v3 (which switches the moduleResolution) I started running into this error.
So you might be able to get a failing test by updating the test app to extend @tsconfig/ember and then have an ember-try scenario that uses v3 of @tsconfig/ember. Since this is a v2 addon, you could also just write a separate test app to test this scenario 🤷

I've opened https://github.com/san650/ember-cli-page-object/pull/614 to address this. Please let me know if you have any feedback, happy to iterate on this.
Thanks @bendemboski for the tips!

Just published the fix https://github.com/san650/ember-cli-page-object/releases/tag/v2.1.0. Thanks everyone!


[SPARK-21694][MESOS] Support Mesos CNI network labels

JIRA ticket: https://issues.apache.org/jira/browse/SPARK-21694
What changes were proposed in this pull request?
Spark already supports launching containers attached to a given CNI network by specifying it via the config spark.mesos.network.name.
This PR adds support to pass in network labels to CNI plugins via a new config option spark.mesos.network.labels. These network labels are key-value pairs that are set in the NetworkInfo of both the driver and executor tasks. More details in the related Mesos documentation:  http://mesos.apache.org/documentation/latest/cni/#mesos-meta-data-to-cni-plugins
How was this patch tested?
Unit tests, for both driver and executor tasks.
Manual integration test to submit a job with the spark.mesos.network.labels option, hit the mesos/state.json endpoint, and check that the labels are set in the driver and executor tasks.
@ArtRand @skonto

Test build #80498 has started for PR 18910 at commit 255e519.

Test build #80498 has finished for PR 18910 at commit 255e519.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80498/
Test PASSed.

@susanxhuynh have you tested how spark jobs behave with a real cni network, just curious should be no difference right?

Test build #80555 has started for PR 18910 at commit d261593.

Test build #80556 has started for PR 18910 at commit dc09312.

Test build #80555 has finished for PR 18910 at commit d261593.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80555/
Test PASSed.

@skonto @ArtRand Thanks for the feedback. I have fixed the documentation and added NETWORK_NAME to the config object. Please let me know what you think.
@skonto I have not tested this particular change on a real CNI network. I think the only difference is that a Spark job runs on a different network, but there's no change in the Spark functionality.

Test build #80556 has finished for PR 18910 at commit dc09312.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/80556/
Test PASSed.

LGTM.

@vanzin Would you mind helping review this PR? Thanks.

@srowen Sean, would you like to review this PR? Thanks.

Test build #81051 has started for PR 18910 at commit 38e3b4d.

Test build #81051 has finished for PR 18910 at commit 38e3b4d.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/81051/
Test PASSed.

@srowen Thanks for reviewing. I've removed those spaces; please take a look.

Merged to master


Integer values becomes strings in construction but not when calling set

When creating a Immutable.Map and passing a object-map of integer keys it transforms the keys to strings, but when calling map.set, it does not transform the integer to string and instead creates a duplicate..
var items = Immutable.Map({ 1: "hi" })
console.log(typeof(items._root.entries[0][0]) === "string"); //= true (should be a number?)
items = items.set(2, "hello");
console.log(typeof(items._root.entries[1][0]) === "string"); //= false

Is this a issue? A solution is to use .toString() when calling set or get, but I think it is weird that it choose change the type in the first place..

This is very similar to #282 which I suggest you read.
The TLDR is that object keys are always strings. Javascript lets you omit quotes for keys when writing the literal form, but they are still read and stored as strings.