[bug] Wireplumber module crashes on audio context change

The wireplumber module causes waybar to crash when the wireplumber context changes.
This is probably due to the fact that node.id is not a stable identifier for nodes.
How to replicate
Sway v1.7
Waybar v0.9.16
libwireplumber v0.4.13
config.conf:
{ "modules-center": ["wireplumber"] }

style.css empty
There are several ways to trigger the issue.
Disconnect sink
If you have a USB soundcard, a bluetooth headset or anything that you can disconnect:

plug it
set it as default sink with wpctl set-default <id>
start waybar
unplug it
waybar will crash on next refresh of the module, you can force it by changing your volume for example

Change TTY
For some reasons, wireplumber reassign a new id to every node when I open a new tty.

start waybar
(opt) check nodes id with wpctl status
switch to a new tty (no need to log in)
switch back to sway
(opt) check nodes id again

Output
> waybar -c config.conf -s style.css -l trace
[2022-12-27 10:14:43.318] [info] Using configuration file config.conf
[2022-12-27 10:14:43.318] [info] Using CSS file style.css
[2022-12-27 10:14:43.324] [debug] Output detection done: eDP-1 (Sharp Corporation 0x1453 0x00000000)
[2022-12-27 10:14:43.345] [debug] GTK widget tree:
window#waybar.background.eDP-1..mode-default:dir(ltr)
  decoration:dir(ltr)
  box.horizontal:dir(ltr)
    box.horizontal.modules-left:dir(ltr)
    box.horizontal.modules-center:dir(ltr)
      widget:dir(ltr)
        label#wireplumber:dir(ltr)
    box.horizontal.modules-right:dir(ltr)

[2022-12-27 10:14:43.346] [info] Bar configured (width: 1920, height: 19) for output: eDP-1
[2022-12-27 10:14:47.439] [error] Node 31 does not support volume
> echo $?
1

Note 1: I triggered the error by switching tty2 at ~10:14:47.4
Note 2: Node 31 was the default Audio/Sink node when waybar started
Related issue

If the sink changes, due to hot-plug of a device for example, the module keep showing the volume of the old default sink.
Doesn't seem linked to #1852

Suggestion

Re-fetch the default node each time the module is updated
Add a callback on relevant WP signal (maybe Object Manager objects-changed?)
Use the node.name instead of node.id (doesn't fix the related issue though)

Can you see if this patch fixes it for you? It has in my testing
https://github.com/Alexays/Waybar/compare/master...smoak:Waybar:fix-wireplumber-crashes.patch

It doesn't crash anymore, but volume is not updated.
After some investigation, the issue is with "get-default-configured-node-name" which returns the name of the sink configured to be the default, but not the current selected sink. So in my case, it always gets my configured default aka my bluez output, even when it's not connected.
I changed it to get the name from wp_pipewire_object_get_property instead, like you do in onMixerChanged (cf
node_name.patch.txt). It works well after that.
Also, I understand better what happens during tty changes. When I switch to a tty which doesn't have a session of the same user opened, it "unplugs" devices from the user and "plugs" it to the new user.
If I run wpctl status in the user session while I am in the unlogged tty, it shows no devices, and a single sink (nick="Dummy Output", name="auto_null").
Once I get back to sway, it reaffect/plugs everything back to the user session. This results in new node ids.
Now that the module handle hotplug of a soundcard, it also handle "hotplug" of internal devices. So it should work with node.id as well as node.name. The difference is that the name is likely to stay the same one session to an other.
For curiosity, I quickly tried to remove/swap default_node_name_ by node_id_ (cf node_id.patch.txt), and indeed it seems to work. (I might have broken something else though)

After some investigation, the issue is with "get-default-configured-node-name" which returns the name of the sink configured to be the default, but not the current selected sink. So in my case, it always gets my configured default aka my bluez output, even when it's not connected.

Thanks. That explanation makes sense. I have updated my branch with what you have stated (ie getting the default node name via wp_pipewire_object_get_property) and put it some extra defensive code. I'll submit a PR for this since I believe it should fix everything (including the volume update).

I tested it, it works perfectly after I plug/unplug devices. But there is an issue at startup, onObjectManagerInstalled still uses the configured default.

But there is an issue at startup, onObjectManagerInstalled still uses the configured default.

I don't think this is possible. There is only the default nodes api to use. Otherwise, this module would have to be a full blown manager application in order to access the internals of Pipewire. I could add a config option (e.g. node_name) to override the default node, but that seems like a new feature request that shouldn't hold up the PR merge to fix this particular crash.


Update Docker docs, simplify scripts.

Closes #326
This combines script files to make them more functional.
This changes the location of the .env.template file. This is a requirement of docker
compose. Also, the format of environment flags now needs to follow NAME=value
(no spaces around =)

This worked locally on windows. Merging.


Changes for Spec

Changed directories to match actions render YAML
Updated version in package.json

@bumblefudge - can you please review, this seems to be the issue with lockfile integrity


setting the SPI pins with uf2conv4eve.py does not work

I saw in uf2conv4eve.py that there is an option to configure the SPI pins.
After figuring out how to use "-p" I found it is not working:
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817-unified.blob -i funtype.bin
['MISO', 4]
['CS', 5]
['SCK', 2]
['MOSI', 3]
['INT', 6]
['PWD', 7]
['IO2', 14]
['IO3', 15]
['MISO', 4]
['CS', 5]
['SCK', 2]
['MOSI', 3]
['INT', '7']
['PWD', 7]
['IO2', 14]
['IO3', 15]
Setting SPI pin: [['MISO', 4], ['CS', 5], ['SCK', 2], ['MOSI', 3], ['INT', '7'], ['PWD', '6'], ['IO2', 14], ['IO3', 15]]
Traceback (most recent call last):
File "uf2conv4eve.py", line 431, in
main()
File "uf2conv4eve.py", line 315, in main
pin_select(args.pin)
File "uf2conv4eve.py", line 273, in pin_select
with open(name, "wb") as f:
NameError: name 'name' is not defined
Lines 273 and 274 might be out of place.

Hi @RudolphRiedel, Please try it again with e28fbd6

Hi @RudolphRiedel, please try it with 7983764

Hello,
the fix is almost working.
Reset
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817-unified.blob -i flash.bin
This is what is on the SPI then:

This is what is on the SPI when I use that line a second time without resetting in between:

Ok, reset.
python uf2conv4eve.py -p int-7 pwd-6 -f
Including default EVE3 firmware blob
Including default EVE4 firmware blob
Launching H: (RPI-RP2)
Setting SPI pin: [['MISO', 4], ['CS', 5], ['SCK', 2], ['MOSI', 3], ['INT', '7'], ['PWD', '6'], ['IO2', 14], ['IO3', 15]]
spin= MISO: 4
CS: 5
SCK: 2
MOSI: 3
INT: 7
PWD: 6
IO2: 14
IO3: 15
100%|████████████████████████████████████████████████████████████████████████████████████████████| 8/8 [00:00<?, ?kB/s]
Wrote 67 bytes to H:/SPI_PIN.CNF
Converting to uf2, output size: 16384
Launching H: (RPI-RP2)
100%|███████████████████████████████████████████████████████████████████████████████| 144/144 [00:00<00:00, 824.40kB/s]
Wrote 145408 bytes to H:/NEW.UF2
Timeout
The SPI is the same as with the first image, PD stays low.
python uf2conv4eve.py -p int-7 pwd-6 -f
Now it works.
Reset

drive is named RPI-RP2
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817-unified.blob -i flash.bin
not working, DP stays low, drive is changed to "BTEVE-FLASH", a file SPI_PIN.cnf is in the drive, command has a timeout eventually
python uf2conv4eve.py -p int-7 pwd-6 -f BT817 BT817-unified.blob -i flash.bin
working, PD is high during SPI traffic, nothing is displayed on the screen, after flashing the drive is automatically reset to RPI-RP2

Ok, back to the default configuration with PD on pin 7.
Flashing is not working, now there is nothing on the SPI at all.
And resetting a couple of times does not help.
My application is running after I switched back to pin 7 for PD.

Hi @RudolphRiedel ,
Please try setting CS/SCK pin to 5/2: python uf2conv4eve.py -p cs-5 sck-2, skip PD and INT pin.
Then please check if the EVE is boot up ok, here is how:

Connect an USB-to-Uart cable from PC to Pi-Pico Uart0 (can use an FT232 cable)
Run python uf2conv4eve.py -f BT817
Check Uart terminal make sure you don't see this text:

If the EVE is boot up ok, we will see this:

Hi @RudolphRiedel,

Check Uart terminal make sure you don't see this text:

Please use this debug version to see messages on the terminal:
eve_flash_pico.zip

Hello,
I am starting from the default with no pins changed.
This does not do much: :python uf2conv4eve.py -p cs-5 sck-2
Launching H: (RPI-RP2)
Setting SPI pin: [['MISO', 4], ['CS', '5'], ['SCK', '2'], ['MOSI', 3], ['INT', 6], ['PWD', 7], ['IO2', 14], ['IO3', 15]]
spin= MISO: 4
CS: 5
SCK: 2
MOSI: 3
INT: 6
PWD: 7
IO2: 14
IO3: 15
100%|████████████████████████████████████████████████████████████████████████████████████████████| 8/8 [00:00<?, ?kB/s]
Wrote 67 bytes to H:/SPI_PIN.CNF
There is no output on the serial and nothing on the SPI.
Reset+Boot
-Drive is named RPI-RP2.
Now this: python uf2conv4eve.py -p cs-5 sck-2 -f BT817 BT817.blob
TinyUF2
Coprocessor initialization timeout
Failed to bootup device!
There is traffic on the SPI, but CS stays high.
-Drive is named BTEVE-FLASH.
Second run with no reset: python uf2conv4eve.py -p cs-5 sck-2 -f BT817 BT817.blob
Updating new SPI pins, data =
MISO: 4
CS: 5
SCK: 2
MOSI: 3
INT: 6
PWD: 7
IO2: 14
IO3: 15
SD card not detected
No SD card detected
Bridgetek BT40817
RP2040 Flash Tool
Flash firmware blob OK
Flash serial: ffffffffffffffff
Flash size: 67108864
At this point the drive is named BTEVE-FLASH and the backlight is activated, the display module draws around 2.5W continously without anything beeing displayed.
Running a third time with no reset, same result.
Reset+Boot
-Drive is named RPI-RP2.
python uf2conv4eve.py -p cs-5 sck-2 -f BT817 BT817.blob
-Drive is named BTEVE-FLASH.
-Coprocessor init timeout
-SPI traffic with CS set to high
python uf2conv4eve.py -p cs-5 sck-2 -f BT817 BT817.blob

worked now, output on COM is "Updating..." as above.
drive is named BTEVE-FLASH and the backlight is activated, the display module draws around 2.5W continously without anything beeing displayed.

Reset+Boot
-Drive is named RPI-RP2.
python uf2conv4eve.py -f BT817 BT817.blob
Fails with "Coprocessor initialization timeout", SPI traffic with CS high, drive is named BTEVE-FLASH afterwards and
the shell command returns to the prompt several seconds laters.
The second and third call of that line while the drive is named BTEVE-FLASH result in no output on COM and no SPI traffic, the shell command times out eventually.
Ok, now I swapped CS and SCK.
Reset+Boot
-Drive is named RPI-RP2.
python uf2conv4eve.py -p cs-2 sck-5 -f BT817 BT817.blob
-Drive is named BTEVE-FLASH
-almost the same result, no init, SPI traffic shows no activity on CS - but now the CS line on pin 2 stays low
python uf2conv4eve.py -p cs-2 sck-5 -f BT817 BT817.blob

worked now, output on COM is "Updating..." as above.
drive is named BTEVE-FLASH and the backlight is switch off now

python uf2conv4eve.py -p cs-2 sck-5 -f BT817 BT817.blob
-fail, no init and the SPI traffic looks strange (SCK/CS/MOSI):

Hi Rudol,

When USB drive name "RPI-RP2", SPI pin will not able to change --> EVE will not able to boot up --> cannot write flash.
-> I will improve the tool to support modify SPI pin in this case

When USB drive name "BTEVE-FLASH", SPI pin should able to congiurated and flash file should be written ok, after done flashing, the board will reboot and display "RPI-RP2" drive.

without anything beeing displayed

Can you share your LCD information?
The LCD should display this text in "BTEVE-FLASH" mode:

Can you share your LCD information?

I used a RVT50HQBNWC00-B, so BT817 and 800x480 with 512 Mbit of flash.

The LCD should display this text in "BTEVE-FLASH" mode:

It looked like this before but this changed with the new versions and now I only get a blank screen.

Hi @RudolphRiedel , please try  7b0a3c6 at your side, thanks.

Changing the pins does work now.


[Codegen] Support generating coin test by id

Also, disable overwriting existing tests by default. Adds 2 cmd options: --coin-id  and --no-skip-existing
Description
Implemented codegen improvement as in #2366
How to test
Manually run with new options (--coin-id and/or --no-skip-existing)
Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] Create pull request as draft initially, unless its complete.
[x] Add tests to cover changes as needed.
[x] Update documentation as needed.
[x] If there is a related Issue, mention it in the description.

Looks good.
There is also an invocation of generate_coin_test_file in https://github.com/trustwallet/wallet-core/blob/master/codegen/bin/newcoin#L145 ,
maybe it would be better to explicitly put the optional parameter here, the overwrite_existing = true would be more appropriate here.

lgtm, we have some legacy tests not using id as folder, let's fix it? chaning the folder name or add some mapping like (XRP -> Ripple)

Build failed for Ripple tests (at least) after renaming directories. I will track it as a separate issue for later (#2491).


Prepare e-h 1.0.0-alpha.9 release

r? @therealprof
(rust-highfive has picked a reviewer for you, use r? to override)

@eldruin I went ahead and did the release. Hope haven't missed anything: cargo publish, created the git tag, and created the release on github with the release notes. Is that all? :D

That's all, thanks!


[5.8] Fix variable names in alias method

If we take a close look, it is obvious that the variable names are wrong.
The first one is the Alias, and the second one is the Original class name.
Sample working usage :
AliasLoader::getInstance()->alias('DB', DB::class);

we should pass original class path as the second argument.
Also it contradicts what we have on line 80 :
https://github.com/laravel/framework/blob/1003c27b73f11472c1ebdb9238b839aefddfb048/src/Illuminate/Foundation/AliasLoader.php#L80
Definition of native class_alias :

I think it is not a change in method signature and does not pose any problems for people overriding it, hence I created this on to 5.8. (Please tell me if I am wrong, and this should be on 5.9)

I guess the original version was viewed as you provide the class name and then the class you want to alias?

That is, that's why the arg was called alias.

This is meant to be used like this:
AliasLoader::getInstance()->alias('DB', DB::class);

otherwise throws an error.
Obviously, it is accepting the alias as the first and the original class name as the second.
but variable names are miss leading for a human. although CPU does not care.
Sorry if I am wrong about that.
@GrahamCampbell

If it was intended to work like this :
AliasLoader::getInstance()->alias(DB::class, 'DB');

when it was first written.
we should consider it as a bug. and it would be nasty for laravel package maintainers using it.
They have to check for the laravel version to see in which order the should pass their arguments.

No, I'm just explaining why the names might be backwards. The alias variable in the original version is the name of the class to be aliased.

I think your PR looks fine. :)

There's no bug, the names are just confusing, and switching them as you suggest, is probably a good idea.

I'm not changing this right now.


Added tests and fixed a bug where upload_binaries would try to update…

…_tracks with no version codes if no apks passed in
Fixes #11632
Before this

Could not solely "promote" an app between tracks

This was due to requiring metadata or apk(s)

Now

Can just "promote" using track and track_promote_to
Added new verify_config! method with tests to make sure this doesn't happen again
Also fixed a bug where upload_binaries could clear what was selected in a track by passing an empty array

@janpio Gah! I ran rubocop but it didn't automatically make the changes for me 😱 Manually fixing them now and then repushing


Investigate best path to writeable textures in memory for basic drawing functions.

"You can create an empty texture and then fill it with writeTexture(). You can also create a mapped buffer, fill it on the CPU side and then copy it to the texture with copyBufferToTexture()"

I recently added https://github.com/foxnne/pixi/blob/dd7180f030f3ca95ce9639a022774b75206a3807/src/editor/editor.zig#L72-L116
but now I'm seeing that I get random freezes with no crash and flashing magenta screen on arm macOS, and both on arm macOS and Windows the files seem to load and draw randomly. Sometimes certain layers don't draw, sometimes no layers draw at all.

Okay, I've discovered that only the first layers in a file were not drawing. I've fixed this issue in a recent commit so texture loading and drawing seems to be working now.
However, still, occasionally on macOS I get a magenta screen when opening a file after a hard freeze. I believe the magenta screen is being thrown up by dear imgui as a shader issue, but I don't know yet if it's a bug with my code or if maybe the timing of loading the file causes an issue with it.


Running a motor in loop is laggy

Hey, love the library so far!
I am trying to create a controller for roller blinds. I am using the AccelStepper library and it requires that the stepper be run in the loop function. It seems, though, that the homeSpan.poll() function tends to be blocking at times and is causing unexpected issues with driving the stepper motor.
The issue I am seeing is that the stepper doesn't smoothly accelerate anymore due to what I am assuming is the poll function blocking the loop. Is there a recommended way of implementing something like this where the stepper run function can operate more smoothly?
I will include my code although I don't know how much it will help. I have also added some extra debugging code to flip the target position outside of the update function.
#include <Arduino.h>
#include <AccelStepper.h>
#include <HomeSpan.h>

const float stepAngle = 1.8;
const int microStep = 16;
const int weirdMultiplier = 4;
const int stepsPerRevolution = 360 / stepAngle * microStep * weirdMultiplier;
const int maxSpeedRpm = 60;
const int maxStepsPerSecond = stepsPerRevolution * maxSpeedRpm / 60;
const float rotationsToClosed = 2;
const int closedPosition = stepsPerRevolution * rotationsToClosed;

int getStepPositionForPct(float positionPct) {
  return positionPct * closedPosition;
}

struct RollerBlind : Service::WindowCovering {

  int stepPin;
  int dirPin;
  int enablePin;
  SpanCharacteristic *currentPosition;
  SpanCharacteristic *targetPosition;
  AccelStepper *stepper;

  RollerBlind(int stepPin, int dirPin, int enablePin) : Service::WindowCovering() {
    currentPosition = new Characteristic::CurrentPosition();
    targetPosition = new Characteristic::TargetPosition();

    this->stepPin = stepPin;
    this->dirPin = dirPin;
    this->enablePin = enablePin;

    stepper = new AccelStepper(AccelStepper::FULL2WIRE, stepPin, dirPin, enablePin);

    Serial.println("stepsPerRevolution: " + String(stepsPerRevolution));
    stepper->setMaxSpeed(maxStepsPerSecond);
    stepper->setAcceleration(stepsPerRevolution);
  }

  boolean update() {
    float positionPct = targetPosition->getNewVal() / 100.0;
    int position = getStepPositionForPct(positionPct);
    stepper->moveTo(position);
    Serial.println("Move To " + String(stepper->targetPosition()));

    return true;
  }

};

RollerBlind *rollerBlind;

void setup() {
  Serial.begin(115200);

  homeSpan.setLogLevel(1);
  homeSpan.begin();

  new SpanAccessory();

  new Service::AccessoryInformation();
    new Characteristic::Name("Roller Blind");
    new Characteristic::Manufacturer("HomeSpan");
    new Characteristic::SerialNumber("123-ABC");
    new Characteristic::Model("Blind");
    new Characteristic::FirmwareRevision("0.9");
    new Characteristic::Identify();

  new Service::HAPProtocolInformation();
    new Characteristic::Version("1.1.0");

  rollerBlind = new RollerBlind(32, 33, 25);

}

void loop() {
  homeSpan.poll();

   // Debug CodeChange direction at the limits
  if (rollerBlind->stepper->distanceToGo() == 0) {
    if (rollerBlind->stepper->currentPosition() > 0) {
      rollerBlind->stepper->moveTo(0);
    } else {
      rollerBlind->stepper->moveTo(closedPosition);
    }
    Serial.println("Move To " + String(rollerBlind->stepper->targetPosition()));
  }
  rollerBlind->stepper->run();
}

Here's an example without HomeSpan that works as expected
AccelStepper stepper1(AccelStepper::FULL2WIRE, 32, 33, 25);
void setup()
{
  Serial.begin(115200);
    stepper1.setMaxSpeed(maxStepsPerSecond);
    stepper1.setAcceleration(maxStepsPerSecond);
    stepper1.moveTo(closedPosition);
    Serial.println("Move To " + String(stepper1.targetPosition()));
}
void loop()
{
    // Change direction at the limits
    if (stepper1.distanceToGo() == 0) {
      if (stepper1.currentPosition() > 0) {
        stepper1.moveTo(0);
      } else {
        stepper1.moveTo(closedPosition);
      }
      Serial.println("Move To " + String(stepper1.targetPosition()));
    }
    stepper1.run();
}

Also, as a second question (let me know if I should raise another issue)
What would be the recommended way to update the PositionState characteristic since it would need to be updated outside of the update method? My plan is to just updated it in the loop when I've detected that the position is either open or closed

you can try to put this code or homespan.poll() to 0 core
 if (rollerBlind->stepper->distanceToGo() == 0) {
    if (rollerBlind->stepper->currentPosition() > 0) {
      rollerBlind->stepper->moveTo(0);
    } else {
      rollerBlind->stepper->moveTo(closedPosition);
    }
    Serial.println("Move To " + String(rollerBlind->stepper->targetPosition()));
  }
  rollerBlind->stepper->run();

https://github.com/HomeSpan/HomeSpan/discussions/262

Unfortunately AccelStepper may not be useable with HomeSpan since it requires frequent calls, which leads to lags as you've noticed.  The HomeSpan polling function needs to do a lot of work, monitor for incoming connections, requests, etc., and can be interrupted if needed.  But that requires libraries written using interrupts - AccelStepper seems to measure clock time and "bit-bang" using digital writes as needed.
A while ago I exploring using the ESP32's native Motor controller, but it was not as robust as I would have liked and I did not bother trying to embed into HomeSpan (I may revisit this and see how the MCPWM functions work with the ESP-S2 and -C3 chips).  Also, it seems that stepper motor controllers have become very cheap and I think the preferred method is to use a dedicated controller so that the main microcontroller does not have to manage the individual steps.
For some more info, see Discussion #58.  There is another library (https://github.com/gin66/FastAccelStepper) that may be better suited for use with HomeSpan, though I have not tried it myself.
As for your second question, in general I recommend adding this type of logic to the loop() function of the Service itself (see, Tutorial Example-13 for an example using doors and windows).

@danilkorotkov that was exactly the solution I needed! I configured homeSpan.poll() to occur in the prioritized core 0 and now all of my lag is gone from the stepper driver

Hello,
For some more info, see Discussion https://github.com/HomeSpan/HomeSpan/discussions/58. There is another library (https://github.com/gin66/FastAccelStepper) that may be better suited for use with HomeSpan, though I have not tried it myself.
Have you tested it already? Any good result? I am doing a smart curtain and I am planning to use a stepper motor.

@danilkorotkov that was exactly the solution I needed! I configured homeSpan.poll() to occur in the prioritized core 0 and now all of my lag is gone from the stepper driver

that's interesting, how did you do that?


💲[Native Checkout] Shipping Location Cell 2/3 (Currency formatter 🤯)

📲 What
Adds the ability to create formatted attributed string based on designs.
🤔 Why
This should be a flexible solution for us to display amount values with specific currency symbol and fraction digits based on the designs.
🛠 How
Using an attributed string (don't worry, everything is tested :))))))
📍Note
In order to being able to see the screen you can navigate to ProjectPamphletContentViewController and change the behaviour of goToRewardsPledge function to the following
let vc = PledgeViewController.instantiate()
vc.configureWith(project: project, reward: reward)

let nc = UINavigationController(rootViewController: vc)
self.present(nc, animated: true)

👀 See

Before 🐛
After 🦋

But wait, there's more..
There's now a new playground that allows you to see various formats and allows you to test new ones as well.

✅ Acceptance criteria

[ ] Currency is formatted as a superscript
[ ] Amount's (decimal numbers before the decimal point) are formatted normally
[ ] Amount's (decimal numbers after the decimal point) and the decimal point itself are formatted as a superscript

I don't think I've ever written these many tests...hopefully they sanity check this formatter a bit

A different approach to a formatter...let me know if you prefer to pair on this @justinswart

There's now a new playground that allows you to see various formats and allows you to test new ones as well.

Sick! Keen to learn more about this stuff.


Capturing docks: Enemy inside door-less container

Version: develop
Mods: ACE
Mode: MP
Although most enemies were above the containers, one enemy was inside a container that did not had any doors. Multiple grenades and shots were fired to get him killed through the metal.

This is a difficult one since the spawn is done by UPSMON, and that is the one causing the problem.
This bug is evidence supporting the hypothesis of @StefArma on issue #24.
Solving this would be done by e.g. counting the number of door of the building using
_class = configFile >> "CfgVehicles" >> typeOf _building;
	_num = getNumber (_class >> "numberofdoors");


Use dict in place of ordereddict in marshal

This aim to fix our problems of memory, it's a complicated but let say
that each ordereddict create at least one cyclic list: a list than
contain itself. The garbage collector of python handle that kind of
thing pretty well, but for performance reason collection of long lived
objects is not done too often. As explained here:
https://github.com/python/cpython/blob/master/Modules/gcmodule.c#L86
collection of old objects is only done when at least 25% of the old
objects has not lived a full collection yet.
On long request, typically isochrone, the ordereddict from the response
live long enough to be considered has old objects, for most fast
requests objects don't live long enough to become "old", so we almost
never trigger a full collection exempt on isochrone request.
So memory don't grow without control, but a lot of the memory allocated
for an isochrone request isn't really released until the next isochrone
request.
Test have been made with an isochrone request on fr-idf with a max
duration of 1H30, memory is measured at the end of the request:

dict
orderedDict

memory
180mo
500mo

duration
12sec
17sec

great job!

Excellent :)


Feature | Cost Efficiency | Review and implement simple budget actions examples

What?
Review and implement simple budget actions example

https://thechief.io/c/news/aws-announces-new-budget-actions/
https://aws.amazon.com/blogs/aws-cost-management/get-started-with-aws-budgets-actions/

Why?

Improve our cost efficiency Well Architected Pillar
In a few words they can trigger actions when the established budget is exceeded
e.g. stop instances or attach policies or directly attach a workflow to ask for approval before proceeding

For the momento we'll focus on improving cost monitoring, and afterwards if needed we can consider budget reactive actions.


Server not responding correctly

At the moment, the server responds with 405 Method Not Allowed to some mappings, and responds to the / mapping with:
200 OK

{
  "_links": {
    "profile": {
      "href": "http://pacmacro.herokuapp.com/profile"
    }
  }
}

I'll need some time to see if I can figure out why this is happening.

Looks like I was using the cURL request wrong, which caused the unusual 200 OK response body.
The 405 Method Not Allowed was because I inadvertently removed the @RestController annotations from the controllers, believing that I could use an interface to apply them to the controllers. This has been resolved in the commit referenced below.

I didn't catch this earlier because my test suite is incomplete; I'll flesh it out comprehensively before implementing the Pacdots controller (see issue #15) so that this doesn't happen again.


@nftmark is not in the npm registry

Trying to pin down this issue, very likely it's my NPM configuration, but wanted to ask.

FIX: npm i @nfte/react
Instead of npm i @nftmark/react

Found the culprit and the fix is in


making proxy and wallet factory lighter + upgradeability

Making proxy and wallet factory lighter  ( commit for review & chat + dev notes )
couple of things to discuss here which I put in dev notes as well (final code will be cleaned up)
Proxy.sol

removed EIP1967 storage slot
commented out singleton to be at 0th storage slot (gnosis uses this way to fetch the target)
storing singleton (base implementation / accountLogic / singleton) at storage slot given by address() opcode [ maybe we should pick one name from above three and use through out ]
removed receive event as it doesn't make sense here
added accountLogic read method to query the implementation address on proxy

SmartAccountFactory.sol

added read method accountCreationCode to get the creation code of Proxy
changed unit -> unit256
isAccountExist is commented out for now it's unnecessary state management unless we absolutely need it
commented out VERSION as versions can conflict with smart account implementation contract versioning [ we can emit an event under initialise to do version tracking ]
commented event SmartAccountCreated. added AccountCreation (which may also emit owner and index. but above event inside init can do that as well)

open for discussion (comparison with Safe factory and others)

need of constructor
versioning plans if constructor args changes
if constructor is removed _implementation address can be part of function args. [goes well with not keeping version variable in factory]
todo : rename wallet to account
possibility of sending initialiser also as another deploy function (create2) but that would require another read method too to get counterfactual address

Wallet deployment now costs about 190k instead of 260k

Also think about which methods

we must make virtual so it's easy to override by inheriting base
are likely to introduce new params but have to follow interface / abstract contracts

need to sit down for implementing Reentrancy Guard again and make a list of all functions and it's parent functions where this guard should be applied. @AmanRaj1608 @filmakarov

made discussed change in the SmartAccountFactory regarding emitting events and making independent of handler and implementation, hence passing both as params and hence also making handler part of the salt.

base implementation / accountLogic / singleton - maybe we should pick one name from above three and use through out

I vote for base implementation

if constructor is removed _implementation address can be part of function args. [goes well with not keeping version variable in factory]

Do you mean, that we
a) remove constructor from Proxy
b) use _implementation from deployCounterFactualWallet function args to make the first init call, in course of which we store _implementation for this proxy?

possibility of sending initialiser also as another deploy function (create2) but that would require another read method too to get counterfactual address

I'm not sure, I get what you mean here. Can you please explain?

I have an idea, what if we add function like
function initSetImplementation(address _implementation) public {
    assembly {
        if (not(iszero(sload(address())) { revert (0,0) }
        if (iszero(_implementation)) { revert (0,0) }
        sstore(address(),_implementation)
    }
}

and we call it in the same deployCounterFactualWallet transaction immediately after deploying proxy.
This will allow us to make creation code independent of implementation and we solve the problem with deploying same wallet address for all chains even if the implementation was changed.

if constructor is removed _implementation address can be part of function args. [goes well with not keeping version variable in factory]

Do you mean, that we a) remove constructor from Proxy b) use _implementation from deployCounterFactualWallet function args to make the first init call, in course of which we store _implementation for this proxy?
Also, what is the reason to remove the constructor? making new proxy address independent of implementation? that would be cool

no no I meant to remove constructor from SmartAccountFactory. check this commit https://github.com/bcnmy/scw-contracts/commit/44aeebb3a876818309f40bd51876f1c8d37e7b92

I have an idea, what if we add function like
function initSetImplementation(address _implementation) public {
    assembly {
        if (not(iszero(sload(address())) { revert (0,0) }
        if (iszero(_implementation)) { revert (0,0) }
        sstore(address(),_implementation)
    }
}

and we call it in the same deployCounterFactualWallet transaction immediately after deploying proxy. This will allow us to make creation code independent of implementation and we solve the problem with deploying same wallet address for all chains even if the implementation was changed.

I was thinking about this in bed.
for this we'd have to deploy proxy with implementation pointing somewhere, which may be zero address as per code logic above. If we do this and then go about doing initSetImplementation then it wouldn't point to correct implementation in the first place, no?
that brings back to changing from UUPS to must have update logic in the proxy.
also above needs formal verification as implementation can be front runned and when we make it at least part of the salt it creates dependency again on the address.

possibility of sending initialiser also as another deploy function (create2) but that would require another read method too to get counterfactual address

I'm not sure, I get what you mean here. Can you please explain?

oh I just meant to have another method like
function deployCounterFactualWallet(address _implementation, address _handler, address _owner, uint256 _index) public returns(address proxy){
can have a cousin
function deployCounterFactualWalletWithInitializer(address _implementation, bytes memory initializer, uint256 _index) public returns(address proxy){

base implementation / accountLogic / singleton - maybe we should pick one name from above three and use through out

I vote for base implementation. Or just implementation.

cool. let me review where all it needs to be modified.

no no I meant to remove constructor from SmartAccountFactory. check this commit 44aeebb

I think factory looks great w/o constructor

If we do this and then go about doing initSetImplementation then it wouldn't point to correct implementation in the first place, no?

What I suggest is to add this initSetImplementation to Proxy itself. So it doesn't move us from UUPS coz it is just one-time function, it's like constructor but can be called after deployment.

also above needs formal verification as implementation can be front runned and when we make it at least part of the salt it creates dependency again on the address.

Yes, that brings the problem with front-running the (deployment+initSetImplementation) txn.
We can introduce verification, like check where does the proxy points ( address() slot ) and if it points to suspicious implementation we can warn user not to send funds there.
However, it doesn't protect users from just cybersquatting addresses. like just frontrun and point proxy to 0xeeeee so it's unusable.
So, I see 2 options:

just make implementation part of creation code (as it is now) so we are protected from front-running, but we can have issues with keeping same address for user on all the chains.

we can introduce additional checks on initSetImplementation
For example it can not just store implementation to address() slot , but it can delegatecall to implementation with "updateImplementation" , so we at least know there is such a method. it's not 100% protection however.

function deployCounterFactualWalletWithInitializer(address _implementation, bytes memory initializer, uint256 _index) public returns(address proxy){

I think that's a good idea.
if we use initializer data the way Safe does
call(gas(), proxy, 0, add(initializer, 0x20), mload(initializer), 0, 0)
and not use it for deploymentData, we won't need other read method I think

need to sit down for implementing Reentrancy Guard again and make a list of all functions and it's parent functions where this guard should be applied. @AmanRaj1608 @filmakarov
let's tackle this as well asap

Let me  study Safe's Guards. They are not very intuitive

function deployCounterFactualWalletWithInitializer(address _implementation, bytes memory initializer, uint256 _index) public returns(address proxy){

I think that's a good idea. if we use initializer data the way Safe does call(gas(), proxy, 0, add(initializer, 0x20), mload(initializer), 0, 0) and not use it for deploymentData, we won't need other read method I think

If we do this and then go about doing initSetImplementation then it wouldn't point to correct implementation in the first place, no?

What I suggest is to add this initSetImplementation to Proxy itself. So it doesn't move us from UUPS coz it is just one-time function, it's like constructor but can be called after deployment.

also above needs formal verification as implementation can be front runned and when we make it at least part of the salt it creates dependency again on the address.

Yes, that brings the problem with front-running the (deployment+initSetImplementation) txn. We can introduce verification, like check where does the proxy points ( address() slot ) and if it points to suspicious implementation we can warn user not to send funds there. However, it doesn't protect users from just cybersquatting addresses. like just frontrun and point proxy to 0xeeeee so it's unusable.
So, I see 2 options:

just make implementation part of creation code (as it is now) so we are protected from front-running, but we can have issues with keeping same address for user on all the chains.
we can introduce additional checks on initSetImplementation
For example it can not just store implementation to address() slot , but it can delegatecall to implementation with "updateImplementation" , so we at least know there is such a method. it's not 100% protection however.

I see with initSetImplementation in proxy but like you said it can open up unknown attack vectors.
with the second point also, since deployCounterFactual is public method we can't do anything access control based from here, probably meaning different implementation can be passed and wallet address won't show change.
1st can be fine if we know which implementation, which handler, which owner and which index to use while deploying. and once done update implementation and (possibly) set new handler.

function deployCounterFactualWalletWithInitializer(address _implementation, bytes memory initializer, uint256 _index) public returns(address proxy){

I think that's a good idea. if we use initializer data the way Safe does call(gas(), proxy, 0, add(initializer, 0x20), mload(initializer), 0, 0) and not use it for deploymentData, we won't need other read method I think

I now think it would be the same thing without any benefit. we either pass handler and owner or pass initialiser data and in both case they have to be part of the salt. in case of initializer we'd have to remember that to create a salt, in current way we have to remember handler to regenerate same proxy address.
only benefit maybe let's say we know handler is wrong and we just needed it for proxy address but want to initialise with right handler afterwards then initialiser data can be sent 0 to save unnecessary init call on proxy.

function deployCounterFactualWalletWithInitializer(address _implementation, bytes memory initializer, uint256 _index) public returns(address proxy){

I think that's a good idea. if we use initializer data the way Safe does call(gas(), proxy, 0, add(initializer, 0x20), mload(initializer), 0, 0) and not use it for deploymentData, we won't need other read method I think

I now think it would be the same thing without any benefit. we either pass handler and owner or pass initialiser data and in both case they have to be part of the salt. in case of initializer we'd have to remember that to create a salt, in current way we have to remember handler to regenerate same proxy address.
only benefit maybe let's say we know handler is wrong and we just needed it for proxy address but want to initialise with right handler afterwards then initialiser data can be sent 0 to save unnecessary init call on proxy.

but no, in above case also i'd have to send initialiser to get the right salt.
so besides owner and index there are this values,
_implementationUsedForDeployment
-implmentationDesired
_handlerUsedForDeployment
_handlerDesired
Also keeping in mind that we can't leave proxy uninitialized

What do you mean by interace for future improvements? in the context of keeping Guard manager like gnosis?

I mean their checkTransaction is now
function checkTransaction(
        address,
        uint256,
        bytes memory,
        Enum.Operation,
        uint256,
        uint256,
        uint256,
        address,
        // solhint-disable-next-line no-unused-vars
        address payable,
        bytes memory,
        address
    ) external override {
        GuardValue storage guard = getGuard();
        require(!guard.active, "Reentrancy detected");
        guard.active = true;
    }

they do not use any of the tx info for the verification.
but since they manage guards thru GuardManager, they will be able to easily migrate to a new Guard implementation with more sophisticated checking algorithm, that may use some of the Tx data. And all of that without migrating to the new implementation.
It also allows in theory for different implementations to even have different Guards.
Also I think that this architecture allows Guards to be not only re-entrancy guards, but also other kinds of guards that allow or disallow certain kinds of operations.
I think this architecture can be used to control some txns from modules. or we can take inspiration from Gelato's tx whitelisting concept (from their Safe automation module). To whitelist certain txns for certain modules. This can even be incorporated with enableModule flow.

I now think it would be the same thing without any benefit. we either pass handler and owner or pass initialiser data and in both case they have to be part of the salt. in case of initializer we'd have to remember that to create a salt, in current way we have to remember handler to regenerate same proxy address.

Yep, I agree here. What I'am trying to say, that passing initializer data is a more universal approach. If we use initializer, even if init args or even name will change in the new implementation, we won't need to deploy new factory.
owner and handler will be the part of initializer  (encoded args of the init function) and the salt will depend on initializer and thus on owner and handler

_implementationUsedForDeployment
-implmentationDesired
_handlerUsedForDeployment
_handlerDesired
Also keeping in mind that we can't leave proxy uninitialized

yes, it's a good idea, we can send implmentationDesired + _handlerDesired to the contract use _handlerDesired in the init call to proxy, since we don't have a function to update handler.

What do you mean by interace for future improvements? in the context of keeping Guard manager like gnosis?

I mean their checkTransaction is now
function checkTransaction(
        address,
        uint256,
        bytes memory,
        Enum.Operation,
        uint256,
        uint256,
        uint256,
        address,
        // solhint-disable-next-line no-unused-vars
        address payable,
        bytes memory,
        address
    ) external override {
        GuardValue storage guard = getGuard();
        require(!guard.active, "Reentrancy detected");
        guard.active = true;
    }

they do not use any of the tx info for the verification. but since they manage guards thru GuardManager, they will be able to easily migrate to a new Guard implementation with more sophisticated checking algorithm, that may use some of the Tx data. And all of that without migrating to the new implementation. It also allows in theory for different implementations to even have different Guards.
Also I think that this architecture allows Guards to be not only re-entrancy guards, but also other kinds of guards that allow or disallow certain kinds of operations. I think this architecture can be used to control some txns from modules. or we can take inspiration from Gelato's tx whitelisting concept (from their Safe automation module). To whitelist certain txns for certain modules. This can even be incorporated with enableModule flow.

Got it. Interesting!
I will add a test case to upgrade to an implementation which supports basic functional guards, even if we don't support it in the first implementation we're confident.

I now think it would be the same thing without any benefit. we either pass handler and owner or pass initialiser data and in both case they have to be part of the salt. in case of initializer we'd have to remember that to create a salt, in current way we have to remember handler to regenerate same proxy address.

Yep, I agree here. What I'am trying to say, that passing initializer data is a more universal approach. If we use initializer, even if init args or even name will change in the new implementation, we won't need to deploy new factory.
owner and handler will be the part of initializer (encoded args of the init function) and the salt will depend on initializer and thus on owner and handler

I see, good idea. I will make this change and update the test cases.

_implementationUsedForDeployment
-implmentationDesired
_handlerUsedForDeployment
_handlerDesired
Also keeping in mind that we can't leave proxy uninitialized

yes, it's a good idea, we can send implmentationDesired + _handlerDesired to the contract and use _handlerDesired in the init call to proxy, since we don't have a function to update handler.
or we can introduce method to update handler and in this case we will be able to deploy proxy, init it with the old data and then update implem and handler from backend but I think just updating from the contract involves less friction

let's take a note of this now and keeping 1st option as way to go.
there is an authorized method to update the handler also ( function setFallbackHandler(address handler) public authorized { )
they will be functional,  just old and can be changed. I will emit implementation, initialiser and index details so backend knows this always for detecting / deploying new smart account with same address on other chain.

_implementationUsedForDeployment
-implmentationDesired
_handlerUsedForDeployment
_handlerDesired
Also keeping in mind that we can't leave proxy uninitialized

yes, it's a good idea, we can send implmentationDesired + _handlerDesired to the contract and use _handlerDesired in the init call to proxy, since we don't have a function to update handler.
or we can introduce method to update handler and in this case we will be able to deploy proxy, init it with the old data and then update implem and handler from backend but I think just updating from the contract involves less friction

If we pass _implmentationDesired and _handlerDesired as argument to function and they are not involved in initial proxy deployment, then its easy to front run this transaction and someone can set another desired implementation & handler....
So if we do it this way, any parameter that's not involved in Proxy deployment, has to be part of user signature which needs to be verified in SCW.

I now think it would be the same thing without any benefit. we either pass handler and owner or pass initialiser data and in both case they have to be part of the salt. in case of initializer we'd have to remember that to create a salt, in current way we have to remember handler to regenerate same proxy address.

Yep, I agree here. What I'am trying to say, that passing initializer data is a more universal approach. If we use initializer, even if init args or even name will change in the new implementation, we won't need to deploy new factory.
owner and handler will be the part of initializer (encoded args of the init function) and the salt will depend on initializer and thus on owner and handler

I see, good idea. I will make this change and update the test cases.

Done. https://github.com/bcnmy/scw-contracts/commit/82730da1407bf4f93ff92edd8cb5f8e5f447452a

If we pass _implmentationDesired and _handlerDesired as argument to function and they are not involved in initial proxy deployment, then its easy to front run this transaction and someone can set another desired implementation & handler....
So if we do it this way, any parameter that's not involved in Proxy deployment, has to be part of user signature which needs to be verified in SCW.

that's right, thank you!
And this gave me an idea.
What if we create an intermediary implementation with 2 functions:

checkSignature - regular signature verification, that signature has been issued by an address that is provided as owner
_implmentationDesired and _handlerDesired are part of the signature
init  - the function that after signature verification sets handler and implementation to _handlerDesired and _implmentationDesired

thus we introduce standardized flow :

we always deploy with a temporary placeholder impementation , that allows us to get same addresses for user
we call init of the temp implementation
the we call init of the full-scale implementation to setup the rest

@livingrockrises @tomarsachin2271 thoughts?

And I want to clarify this as well
if eq(calldataload(0), 0xee9118f700000000000000000000000000000000000000000000000000000000) {
                mstore(0, target)
                return(0, 0x20)
            }

this checking calldata costs us 32 gas for every call to the proxy
Why can't we just have a method getImplementationAddress() external view in implementation? that just returns result of sload(address()

And I want to clarify this as well
if eq(calldataload(0), 0xee9118f700000000000000000000000000000000000000000000000000000000) {
                mstore(0, target)
                return(0, 0x20)
            }

this checking calldata costs us 32 gas for every call to the proxy
Why can't we just have a method getImplementationAddress() external view in implementation? that just returns result of sload(address()

I can add this getImplementation() read method in the proxy and remove IProxy interface.

If we pass _implmentationDesired and _handlerDesired as argument to function and they are not involved in initial proxy deployment, then its easy to front run this transaction and someone can set another desired implementation & handler....
So if we do it this way, any parameter that's not involved in Proxy deployment, has to be part of user signature which needs to be verified in SCW.

that's right, thank you!
And this gave me an idea. What if we create an intermediary implementation with 2 functions:

checkSignature - regular signature verification, that signature has been issued by an address that is provided as owner
_implmentationDesired and _handlerDesired are part of the signature
init  - the function that after signature verification sets handler and implementation to _handlerDesired and _implmentationDesired

thus we introduce standardized flow :

we always deploy with a temporary placeholder impementation , that allows us to get same addresses for user
we call init of the temp implementation
the we call init of the full-scale implementation to setup the rest

@livingrockrises @tomarsachin2271 thoughts?

Hmm I had thought of keeping v0.0.0 implementation immutable in proxy. That was it's pointing to something reliable since birth of it and owner storage slot is set appropriate.
you mean to have this ^ implementation = intermediatory implementation to have above methods? checkSignature and init (rather sets handler and implementation)
but none of these methods or params like _handlerDesired, _implementationDesired would be in deploy method of wallet factory right?
it's basically still two step as our approach 1. but something to think about..

And I want to clarify this as well
if eq(calldataload(0), 0xee9118f700000000000000000000000000000000000000000000000000000000) {
                mstore(0, target)
                return(0, 0x20)
            }

this checking calldata costs us 32 gas for every call to the proxy
Why can't we just have a method getImplementationAddress() external view in implementation? that just returns result of sload(address()

I can add this getImplementation() read method in the proxy and remove IProxy interface.

done

merging this

I can add this getImplementation() read method in the proxy and remove IProxy interface.

I would suggest adding it not to the proxy, but to the implementation. Thi will make proxy deployment cheaper.

I can add this getImplementation() read method in the proxy and remove IProxy interface.

I would suggest adding it not to the proxy, but to the implementation. Thi will make proxy deployment cheaper.

got it. I will change it in c4-remediations branch now

done.
https://github.com/bcnmy/scw-contracts/commit/293efe2f919c636f3baad6c2b1ffce46780aa391

Hmm I had thought of keeping v0.0.0 implementation immutable in proxy. That way it's pointing to something reliable since birth of it and owner storage slot is set appropriate.
you mean to have this ^ implementation = intermediatory implementation to have above methods? checkSignature and init (rather sets handler and implementation)
but none of these methods or params like _handlerDesired, _implementationDesired would be in deploy method of wallet factory right? it's basically still two step as our approach 1. but something to think about..

Yes. that's exactly what I mean. Having minimal and reliable v0.0.0 implementation for all of the proxies at deploy be default, so it allows us to always have same address for newly deployed proxies.
step 1: we deploy proxy pointing to the v0.0.0 impl
step 2: we call preInit on v0.0.0. it verifies that _handlerDesired and _implementationDesired been signed by owner. if it has been signed properly, we can change implementation to _implementationDesired
step 3: we call init of _implementationDesired to set owner and  _handlerDesired and other init stuff.
(btw in this case we have no need of recording handler and keeping it as a part of the salt. only owner is needed. we will just pass  _handlerDesired , that will be signed and verified in v0.0.0)
All the 3 steps should be completed in one txn.
I think this really can work and will allow us to solve this problem with keeping same address for user across chains

Hmm I had thought of keeping v0.0.0 implementation immutable in proxy. That way it's pointing to something reliable since birth of it and owner storage slot is set appropriate.
you mean to have this ^ implementation = intermediatory implementation to have above methods? checkSignature and init (rather sets handler and implementation)
but none of these methods or params like _handlerDesired, _implementationDesired would be in deploy method of wallet factory right? it's basically still two step as our approach 1. but something to think about..

Yes. that's exactly what I mean. Having minimal and reliable v0.0.0 implementation for all of the proxies at deploy be default, so it allows us to always have same address for newly deployed proxies.
step 1: we deploy proxy pointing to the v0.0.0 impl step 2: we call preInit on v0.0.0. it verifies that _handlerDesired and _implementationDesired been signed by owner. if it has been signed properly, we can change implementation to _implementationDesired step 3: we call init of _implementationDesired to set owner and _handlerDesired and other init stuff. (btw in this case we have no need of recording handler and keeping it as a part of the salt. only owner is needed. we will just pass _handlerDesired , that will be signed and verified in v0.0.0)
All the 3 steps should be completed in one txn.
I think this really can work and will allow us to solve this problem with keeping same address for user across chains

hmm I wanna see how code shapes up along with test cases, and also think about signature verification flow and not leaving proxy uninitialized for long, also keeping gas optimisations in mind. we can create new branch out of c4-remediations to test this theory. if done well it can really help client sdk and backend efforts. can keep a call for this sometime next week
cc @talhamalik883 @tomarsachin2271


create debian packages

1. Tell us something about your changes.
create debian packages for clean install into your debian/*buntu system.
current compile looks like that (in short):
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -Wno-dev <other cmake options> ..
make -j 4

above thing still works, but now following is possible:
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -Wno-dev -DCMAKE_INSTALL_PREFIX=/usr -DPLATFORM=rpi-pwm ..
make -j 4
make -j 4 package

then a .deb will be generated. this package can be installed with:
sudo dpkg -i hyperion-*-ambilight.deb
the deb-postinstall script and deb infos aren't perfect yet, but after we can create .deb packages making it perfect shouldn't be hard.
I also add generation of rpm package for people who use suse, fedore, centos, ... it works in general, but postinstall script has to be filled with something usefull. (rpm currently deactivated)
BTW now make install works good. this won't be affecting your config or service file - only effects and the binaries. config and service files are handled by .deb/.rpm package
2. If this changes affect the .conf file. Please provide the changed section
optional changes:
path of effects: /usr/share/hyperion/effects
path of config file: /etc/hyperion/hyperion.config.json
3. Reference a issue (optional)

Great work

I will add a /opt compat layer with symlinks. So hypercon will work with this patch

the debian package create symlinks for opt now. With this hypercon should work as expected

This works? Great, so we could move immediately also with HyperCon to /etc/hyperion/ as storing location for all configs. As long we keep it compatible with older installs (just to a certain point)
I also don´t need to backup the hyperion.config.json during a update, which is great!

we can add both effect paths:
/opt/hyperion/effects and /usr/share/hyperion/effects
to config. Then the opt compat layer forthe debian package is obsolete ...

@redPanther
https://github.com/hyperion-project/hyperion/pull/650/files#diff-af3b638bc2a3e6c650974192a53c7291R25
1 currently we provide just pi with pwm enabled (no user feedback required - no errors hehe).
So i consider to "change" this.
2. I should set SET ( DEFAULT_ZEROCONF  OFF )
to ON? and remove it from .sh

not understand completely what you mean. pwm stuff is only for pi, because it is hardware pi specific.

remove
SET ( DEFAULT_ZEROCONF OFF ) and replace
${DEFAULT_ZEROCONF} with ON. zeroconf is not platform specific

pi-pwm and pi
currently is used during crosscompile?

no, that are 2 different things. see description of make_release function
make_release   [<cmake args ...>]
make_release rpi     rpi-pwm
means: make archive with _rpi name and use cmake platform flag "rpi-pwm"
there is also a rpi cmake platform flag, this is not used in crosscompile script and is same as rpi-pwm except ws281x pwm capability


Updated for Windows 1909

Kernel32.dll and other system files do not have the 18363 build number and instead are kept at their older values.

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

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


Null if check and failing function to taken in account

Code with if (obj == null) and a failing function seems not taken in account properly.
Object obj = model.get(modelName);
if (obj == null) {
	fail("Model attribute with name '" + modelName + "' is null");
}
assertTrue(obj.getClass().getName(), expectedType.isAssignableFrom(obj.getClass()));

With
@Contract("_ -> fail")
public static void fail(String message) {
	throw new AssertionError(message);
}

Generates this irrelevant error:
[NullAway] dereferenced expression obj is @Nullable
                                obj.getClass().getName(), expectedType.isAssignableFrom(obj.getClass()));

Hi @sdeleuze thanks for the report; we can add support for this case.  As a workaround, if you have a fail method that takes both a boolean and a String, that should already be supported.  See this new test:
https://github.com/uber/NullAway/pull/945/files
Maybe that is not an option here for performance reasons?

Thanks, the main reason why I don't have a workaround here is that fail(String message) is part of Spring public API and I can't change it.


Support ctrl key to select tabs for Windows

[ ] Bugfix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)

Proposed changes
Quick wiring supports both meta and ctrl keys but selecting tab supports meta key only. It is difficult for Windows users to select tabs using the meta key (Windows key) because the Windows taskbar is opened when the key is used. I think that the ctrl key is needed for Windows users.
Checklist

[x] I have read the contribution guidelines
[ ] For non-bugfix PRs, I have discussed this change on the mailing list/slack team.
[x] I have run grunt to verify the unit tests pass
[ ] I have added suitable unit tests to cover the new/changed functionality

Coverage remained the same at 77.548% when pulling 361dc194ee1fc3cc9f8bcad6901a7fe00dd88a2b on kazuhitoyokoi:master-fixtabselectkey into 3a1d0f36952f7e01214691ef89355af72ad6e5c9 on node-red:master.

👍


Resolving React Routers redirects in the server

Building an app with auth polices, we had a need to redirect to the login page, but, in order to know if the user is logged in or not, I had to use my service's instance lib.
I'm using the @bobpace branch for adding some context data in the willTransition hooks.
But, the problem is that I can't redirect the response from the onAbort() function, example:
https://github.com/TallerWebSolutions/ambidex/blob/transition-to-context/src/Ambidex.server.js#L379-L398
I tried some things like:
connection.redirect(stack);

then....
connection.redirect(stack);
return connection.call(stack);

nope...
resolve(connection);

errors everywhere....
I'm a little lost here, some help?

May not be the same solution for you, but my onAbort I use with fluxible app looks like this:
    options.onAbort = function serverSideAbort(abortReason, location) {
      if (abortReason instanceof Cancellation) {
        return;
      }
      else if (abortReason instanceof Redirect) {
        var path = this.makePath(abortReason.to, abortReason.params, abortReason.query);
        res.redirect(path);
      }
    };

This issue was resolved, I'll be back with the changes I had to make to make the react-router's onAbort() event interacts with the response of mach.

Glad you got it sorted.  :smiley:

Here's the commit with the solution:
https://github.com/TallerWebSolutions/ambidex/commit/8487bd00172b8f366c0253a3a84fa777e487491c


Add transparent mode for own outgoing traffic

I did a bit of research on how to get PF to also handle own outgoing traffic, it works a bit like this:
Browser -> (outgoing interface) ->  (PF filter rule) -> (lo interface) -> (PF translation rule) -> mitmproxy
There are some limits, the "Browser" needs to run as a different user than mitmproxy as the uid is used as a filter rule to make sure the mitmproxy traffic is also not sent back to it self.
I have a more in-depth explanation of how to do this:
http://tlbdk.github.io/mac/proxy/mitmproxy/fiddler/2016/04/14/redirect-outgoing-traffic-for-user-on-mac.html
All this could be turned into a switch for mitmproxy so it was a bit less work to setup.

Thanks for the fantastic write-up! Easily intercepting traffic for our own machine is certainly on the agenda for mitmweb.
refs #630

Thanks tlbdk for your detailed post, I was stuck testing transparent mode and it helped me understand my errors.
(btw link is not good anymore, found your post here: https://github.com/tlbdk/tlbdk.github.io/blob/master/_posts/2016-04-19-redirect-outgoing-traffic-for-user-on-mac.md)
Now I question myself about seeing the whole traffic of macOS, for all users & system traffic, not only the user running the browser.
I tried a negation of the proxy user like: keep state {not or !} user { <user id running the proxy> } without success.
A solution could be to write a line per other user, but with the possibility to miss one, or to automate by first listing candidate system users and then creating the list:
keep state user root
keep state user macports
keep state user _hidd
keep state user _ctkd
keep state user _softwareupdate
keep state user _mdnsresponder
...

Also not sure if it's technically feasible, but this hard work with pf is done in 1 line with iptables, would compiling iptables work on macOS?

If PF supports user negation and you want to transparently proxy all traffic on the machine, you would only need to run mitmproxy under it's own user/uid.
iptables is Linux only and uses the Linux kernel firewall to do it's magic, PF is the macOS equivalent and does not seem to support filtering based on pid's, so I think the easiest options is to change random uid and add rules for that.

Just stumbled upon this -- I haven't tried it, but I think keep state and user <user> are separate things, and that you could probably do user { != nobody }. I'm not sure how it might interact with "unknown" user traffic. Details here.

 user <user>
      ...
      User and group refer to the effective (as opposed to the real) IDs, in case the socket is created
      by a setuid/setgid process.  User and group IDs are stored when a socket is created; when a
      process creates a listening socket as root (for instance, by binding to a privileged port) and
      subsequently changes to another user ID (to drop privileges), the credentials will remain root.

      User and group IDs can be specified as either numbers or names.  The syntax is similar to the one
      for ports.  The value unknown matches packets of forwarded connections.  unknown can only be used
      with the operators = and !=.  Other constructs like user >= unknown are invalid.  Forwarded pack-ets packets
      ets with unknown user and group ID match only rules that explicitly compare against unknown with
      the operators = or !=.  For instance user >= 0 does not match forwarded packets.
      ...

Thanks, that's interesting indeed, will make some tests.
(And now I feel ashamed of my tests to negate the user, before the user keyword...)

user != nobody works perfectly to see the traffic of all users of your Mac

For the record, here's a possible Linux version: https://medium.com/@aciliketcap/using-cgroups-and-mitmproxy-to-listen-to-traffic-on-your-computer-in-a-transparent-proxy-scenario-668f36cba2dd

We can also already do this on Windows, where one can execute the platform/windows.py script manually with the right options.

I hear this quite often and we maybe should prioritize this - having something like mitmproxy --mode os would be really interesting.

Hey Max - I'm not sure we need to remove the OSX tags, since this is really only tricky on OSX. In Linux, it's pretty easy to configure transparent mode for your own outgoing traffic - you just have to replace PREROUTING in step 4 here with OUTPUT. I implement this in Chomper for Linux. If you think it's worthwhile, I can make a PR to have a note in the docs to use the OUTPUT chain if you're using transparent mode for your own outgoing traffic on Linux.
I'm working on OSX compatibility for Chomper, which really just means figuring out how to solve #1261 for OSX. We've been discussing this a bit in the developer chat, and the most promising stackoverflow link I've found is this one. I can't try it out, since I don't have access to a Mac yet, but @miheerdew is trying to implement the instructions in the stackoverflow link.

I think the main part here is putting that into a mitmproxy switch, and that's not really OS specific. There are roughly three steps that need to be done:

Define an API like platform.start_os_proxy/platform.stop_os_proxy and implement it for at least one OS. Maybe that even includes certificate installation? Make sure that it tears down properly, even if mitmproxy exited ungracefully before.
Add a mode to mitmproxy so that we can say mitmproxy --mode os/self/os-transparent/.... Not entirely straightforward as we AFAIK depend on the mode at some places in the proxy logic.
Implement the API defined in 1 for all other OSes.

I see. It should be pretty easy to implement in Linux. Figuring out how to automate certificate installation is something I'm working on. The mitmproxy docs suggest doing this for Linux, but that won't work for firefox/chrome, both of whom do not use system-wide certificates. Automating iptables configuration would require running mitmproxy as root - would that requirement be okay? If so, I should be able to work on this for Linux within the next week or two.
However, it seems like from the above discussion that no one ever figured out how to get it working with pf, so if @miheerdew figures something out, I'll write about it here.

Any pointers are definitely welcome. For a first version we shouldn't install certificates. That can come later, this is already very tricky to do right cross-platform.

If it's of any help, for the macOS transparent mode, I've digged a lot inside pf to implement it in Debookee and came to the same solution as @tlbdk

Running mitmproxy with user nobody as pf can't redirect only part of a traffic of a user (so it can't make the distinction between mitmproxy outgoing traffic, and users traffic is run with same user)
Few lines of redirect in /etc/pf.conf
It's in production and I'm fully satisfied.

Hi @tomlabaude, have you tested this on MacOS High Sierra? Strangely, I can still access the internet if I block/redirect en0 (or en1). I was looking at tcpdump, and all the traffic seems to passing automatically through lo0 even though I haven't explicitly redirected it.

You need nat (redirection of lo0 to mitmproxy port) and filter (redirection of en0 traffic to lo0 except for mitmproxy user) rules to make it work. Look at those screenshots, or better, if you use macOS, run Debookee in free trial and check pftctl status & pf.conf  when SSL module is running.
Here's a screenshot of both nat and filter rules, mitmdump runs on port 6970 with user nobody,<PHONE_NUMBER> is user nobody

￼

￼

Thanks. Debookee seems to be working fine, but when I manually load the same (nat and filter) rules into the (now empty) "debookee" anchor, my traffic isn't redirected anymore. I am definitely missing something here.

Not sure this thread is the best place to follow such troubleshooting, as the thread is not OS related anymore, maybe @mhils can tell.
Also I could spend some time to troubleshoot & help you make it work if there's a direct enhancement/code of mitmproxy, not another project.

I tried the instructions in OP's link but that doesn't redirect my traffic to mitmproxy, so I am trying to reproduce @tomlabaude's results on my computer.
It would actually be great if the docs are updated with the latest information on how to redirect machines own traffic to mitmproxy transparently for macOS. Once those instructions work, they can be implemented into --mode os-transparent argument.

Superseded by https://github.com/mitmproxy/mitmproxy/issues/6531! :)


Invalid file content. File contains optimization_guide.proto.PageTopicsOverrideList data.

when use netron open a proto bin file, it raise
Invalid file content. File contains optimization_guide.proto.PageTopicsOverrideList data.

@lix19937 there are many different proto formats. Is the file not PageTopicsOverrideList data (can you share the file) or do you expect something else to happen?


Fix api-metadata project to remove deprecation warning

Context

See https://github.com/gradle/gradle-native/issues/890
Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

Incorporated into https://github.com/gradle/gradle/commit/ded498b944982bd6c3b5f0b1d4ee4733bcaad956


NanoIsoform module - create and add two softwares to assign which read belongs to which isoform

Include npTranscript to assign which readID corresponds to each mRNA based on a gtf
https://github.com/lachlancoin/npTranscript
** Used for SARS-CoV2

Include FLAIR to assign which readID corresponds to each mRNA based on a gtf
https://github.com/BrooksLabUCSC/flair

This way we can run NanoMod and NanoTail directly on per-transcript files, rather than per-genome files

Hi! I would need some command lines :) Can we discuss it on Slack?

For npTranscript

Change path to npTranscript in files: scripts/run.sh and scripts/run_extract_cluster.sh
Change path to the bam file(s) to analyse + reference file + coordinates file + output directory in scripts/run_example.sh
Run Rscript run_example

I believe only one process is needed for the whole thing. Input files:

Bam file(s) - it can process one or more bam files at the same time
Reference - fasta format
Coordinates file - already generated by developers for SARS-Cov2 (npTranscript/data/SARS-Cov2/Coordinates.csv) - Example format below:

Name,Type,Minimum,Maximum,Length,Direction,gene
UTR,5'UTR,1,13,13,forward,none
leader,leader,14,75,62,forward,leader
UTR,5'UTR,76,265,189,forward,none
ORF1ab gene,gene,266,21555,21290,forward,ORF1ab
S gene,gene,21563,25384,3822,forward,S
ORF3a gene,gene,25393,26220,828,forward,ORF3a
E gene,gene,26245,26472,228,forward,E
M gene,gene,26523,27191,669,forward,M
ORF6 gene,gene,27202,27387,186,forward,ORF6
ORF7a gene,gene,27394,27759,366,forward,ORF7a
ORF8 gene,gene,27894,28259,366,forward,ORF8
N gene,gene,28274,29533,1260,forward,N
ORF10 gene,gene,29558,29674,117,forward,ORF10
UTR,3'UTR,29675,29893,219,forward,none

Output files:
npTranscript will generate an output directory - specified by user in scripts/run_example.sh
I would output:

File: 0readToCluster.txt.gz - found in the output directory. It contains the raw results
Folder 'clusters' - found inside the output directory. It contains separate files (one per cluster) with the processed results - reads ID belonging to that specific cluster.

There is also a way to plot the results - shall we plot them? Or shall the user do it on his/her own? @enovoa

mmm I don't like the custom input files like this... can we use a standard format like GTF, GFF, BED? I could try then to make the custom format for the program.

This is what the code uses unfortunately… perhaps open an issue in repo of npTranscript asking if they have a script for conversion of gtf to their format of input?

On 16 Apr 2020, at 1:09 pm, Luca Cozzuto<EMAIL_ADDRESS>wrote:
mmm I don't like the custom input files like this... can we use a standard format like GTF, GFF, BED? I could try then to make the custom format for the program.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/biocorecrg/master_of_pores/issues/47#issuecomment-614583693, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDGUPM65ZPTNMEZWNO5TOLRM3RNVANCNFSM4MHSZQBA.

I think is quite easy to make it. I'll do it


vSphere UPI: Indicate in UI if node gets degraded because of config mismatch

Hi,
I played around with some systemd services on my worker nodes (sshed in the nodes and manipulated things).
The machine-config-daemon reported afterwards, that the node has been marked as degraded because of config mismatch.
That's good.
What's not so good: I don't see anything about this degradation in the web ui. I would expect that this degraded state is not only shown in logs but also in the UI. I don't have a chance to fix things, if I don't get a warning or error message.
If was looking for this in UI->nodes.
Maybe that's indicated somewhere else?
Greetings,
Josef

Machine/Nodes don't have a degraded status per se - MCO can degrade on a particular node and not proceed further.
I believe linking a node to a MCO state would require an ehnancement - @LorbusChris WDYT?

The command:
oc get mcp

comes to the resue here. Also in the UI you can easily see that something has degraded in the MCP.
That's what I need.
I'll close this ticket. Thx!


:sparkles: add custom redirects for Map and Set

Because writing !mdn map and !mdn Map should give different results 😠

indirectly fixed with a3f585bbc89502de139cffe687d1e8928ee024a8


[Suggestion] Monochromatic for Darkvision?

Hiya!
Thanks a bunch for this great mod!
I wonder if it would be possible to edit in the choice to use Monochromatic vision mode instead for the standard Darkvision? Not that colors aren't nice but I prefer the monochrome version.
Thanks again!
/Ravenknight
( I'm aware that the effect kicks in if the map is dark. I would just like it as a default even with a light map.)

You want Darkvision to be greyscale regardless of the Darkness Level, correct? Monochromatic is color-blindness (everything is grayscale); I assume that isn't want you want (?).

Darkvision as greyscale regardless of Darkness level. Yep. I think I expressed my suggestion in an odd way.


Fix tests that depend on network/compute

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
API changes are not detected in this pull request.


Design and test a paper prototype with the customer.

We decided not to do this, as we had already come far along with an actual technical prototype to show that instead. We reached the point of no return.


always drops byte

I am using the ultrasonic sensor to measure distance and then I send it to my android application via Bluetooth. I tested it with an app from the play store (Bluetooth electronics) and it gives me the right answer.  I used your code its perfect but it always gives me not the completed distance.
example: if distance 112 it gives me 12, if it 200 it gives me 00, if it 51 it gives me 1
why it cuts the first digit always?

I remember it was an issue while displaying the data, but if you check value in variable it always will be correct as received from Bluetooth sensor.

can I control the time period of receiving data from Bluetooth in android ? or I can control it with the Arduino code only?

You can control from Arduino as well from Android app.


Unexpected token "<" on index.js after npm eject.

Is this a bug report?
Yes
Can you also reproduce the problem with npm 4.x?
Yes
Which terms did you search for in User Guide?
token, eject, start, server, webpack, <
Environment

node -v: 8.9.1
npm -v: 5.5.1

Then, specify:

Operating system: macOS 10.12.6
Browser and version (if relevant): Firefox Quantum Developer Edition 58

Steps to Reproduce

Eject your create-react-app
Stop any currently running npm starts.
Run npm start.
Cry.

Expected Behavior
I expected the development server to run like normal and serve up my application with no errors, since I hadn't changed my project at all since ejection.
Actual Behavior
Instead, the development server spat out this error:

Reproducible Demo
I was unable to reproduce this with a regular project, unfortunately.

I'm currently trying to use Git to rollback to pre-horribleness.

Unfortunately we'll need a copy of your project to help diagnose this. You can probably strip out everything but index.js.

I guess you might have changed either package.json or config/webpack.config.dev.js.
Babel did not transpile JSX to React.createElement calls for some reason.

Here is my project: https://bitbucket.org/christopherdumas/kairos. I'll create an eject branch with everything unnecessary stripped out.

I haven't modified the webpack config at all, in fact the reason I ejected was in order to do that, but I haden't gotten to doing that when the error happened.

@Timer, I was able to reproduce the behavior by deleting everything from my project except the basic files, index.js and App.js like you said. You can get it here: https://bitbucket.org/christopherdumas/kairos/branch/eject.

@christopherdumas it's because you have a .babelrc file which doesn't contain anything required to compile React, ES6+, etc.
Delete that file and things should start working.

As for your master branch, you removed vital configuration out of your package.json. Those entries were required for things to work. 😄

Oh, okay. Thank you!


Input removal

Part of https://github.com/quasar-analytics/quasar/issues/1634

@wemrysi this is ready for review